IPv6 Working Group session
Thursday 18 October 2018
11 a.m.
CHAIR: Good morning, welcome to the IPv6 Working Group. People are still coming in, we'll start up in a minute.
Hello everyone, good morning, and welcome to the v6 Working Group. If you are looking for anti‑abuse, you are in the wrong room but you can stay, this is far more interesting.
Once you decide to come to the microphone, we have an etiquette that says state your name, your affiliation and all the other important things you have to know about who you are. It would make it easier for the stenographer and for everyone else.
So the last meeting's minutes. They have been on the list a couple of weeks now and we have had only one comment. There was a small slight typo in them, it's been corrected and so far we haven't had anything else. So if there is nothing else here in the room, I declare them to be now official.
So the other thing what you should remember, or try to remember, is to rate all the presentations. You can do that by logging in your RIPE account, if you don't have one you can create one, and after that, you can tell us what you like and what you didn't like about the presentations, so we have some idea about what we have to do next time.
Then the agenda bashing. Is there anything we have missed. We are actually pretty much full so extra things can be included. And if not, then I'll Jen to start with work at the IETF.
JEN LINKOVA: Hi. Just for a change, black and white today. I have been volunteered for this. Actually, I wanted to do it a long time ago, but then I volunteered to give you an update of IPv6 related stuff which is going at IETF.
Actually, it was easy because most of the information had been provided by Working Group Chairs and I just converted it into make sense. I definitely see people in the room who could go back to reading their e‑mails because they most likely know of this. But for the rest of you, let me start why you should not be looking at your e‑mails right now, or Facebook or kittens or whatever, and why you should pay attention.
Because what's happening there is affecting you, maybe not short‑term but definitely mid‑term, right. Whatever ‑‑ all the crazy stuff people invented there, might end up in your network in a few years. So, if you are complaining that you do not like how protocols have been designed, or you think that strange people at IETF are totally disconnected from reality or they do not think about your use cases, you are actually partially guilty for this because you should pay attention, you should come and raise your voice and do not trust your vendors to come and do it for you, because, you know, right they might forget part of your message on the way.
And so, I explained why. Now the question is how? And it's actually not so hard. You don't have to apply to Bangkok in a couple of weeks. You can just sign up to the mailing list and try to read them. I actually keep failing on this, I have a huge backlog of things in my mailbox, especially at IETF descriptions, and you can just join me remotely. It's fun, especially when it's a completely different time zone. Yeah, it's still possible, you don't have to pay money or convince your manager that they should pay money, you can just do everything from the train, or from your sofa.
So the goal of this talk is to save you a lot of time of reading all those e‑mail threats, I'm basically going to give you a short summary of what's going on there right now and I'll try to emphasise things where operators input might be required.
So, as you might know, in November 3rd IETF 103 will start in Bangkok and there are some drafts which will be discussed there, and again for most of them it would be really nice to rather the opinions of operational community. So it's a kind of teaser. I actually, I don't know how much time we will have, so, if we do not have an enough time, I suggest we adjourn do not turn this presentation into every single draft I mention. It's just a suggestion that you if see anything interesting you can go read and comment on the mailing list. But we might have sometime, I don't know yet.
So, just to make sure we are on the same page, this is simplified, lifecycle of documents, so, you will understand the terminology, so basically, if you have a great idea or you think it's a great idea, you can write a draft. Anyone could write a draft about almost anything. You could come to IETF or send it to the mailing list and if you manage to convince enough people in the Working Group that it's a brilliant idea, the Working Group can adopt your draft, it will become not just your draft but a working group document, and then after you spent sometime talking to people and sending e‑mails and discussing your draft, you might say okay recollect it's now good enough, and it will go to the Working Group last call. When people finally will pay attention to your draft, and will give you more comments and when you address them, it will, after some additional, it will go to IETF last call and then it may be published as an RFC.
So, all RFCs are equal, some of them more equal than others. There are standards which people are kind of supposed to follow they do follow standards but they may not. If you just want to document something which is not really a standard, but is a kind of good idea and you expect that most people should follow it, it could be published just as best current practices. Or if you just want the to comment on something which not everyone thinks is a great idea but it could be done, or you just want to share a document from experience, it could be just an informational document. So again not everything published is an RFC must be supported and implemented by everyone, and there is even experimental RFC oh we just invented some crazy stuff and we managed to convince enough people it's cool.
Now, when we cover the terminology and some basics of the process, which groups I'm going to talk about.
There are two main IETF Working Groups you might find interesting and related to what's happening here. The IPv6 maintenance which basically covers the protocol development. And there is an IPv6 ops which concentrates on operational practices. There is also two Working Groups which are too sophisticated for me, I really can't follow. And there was another ‑‑ there was a group which was working on getting rid of legacy protocol, but apparently everyone decided we are done with it so it's been closed. So now we can finally concentrate on IPv6.
Let's start with standards. Let's start with IPv6 maintenance Working Group.
Here is some overview. So, there are some useful links you might click on. They should be clickable on PDF, find the mailing list archives, how to subscribe to em this, basically that group is a place when the protocol is developed. What is IPv6 header? What preliminaryers should you do? Basically all protocol specifications. Any changes to protocols should be discussed and done there. Also, if during the deployment, we find that we need to change something in the protocol, we should go there and discuss it.
So what's going on in this right now. IPv6 only flag draft. So the story is, two or three IETFs ago, we may ‑‑ we ransom experiment. We turned off IPv4 for IPv6 Working Groups during the session, so there was no IPv4 SSID any more, only IPv6, and when we were looking at the results, some people noticed that it was a lot of noise on the network caused by all our devices which are on IPv6 only network but they are still trying to get v4. They are saying the HTTPS is sending some RIR packets and there is things which actually could not go anywhere because it's a pure IPv6 only network. And from that discussion, a document appeared which basically suggested that let's introduce a flag in RA which will signal to host that is this network does not give you any v4. So don't even try. There is no IPv4, don't send DHCP, just use IPv6. Obviously the goal is to reduce the noise and let your host know that it should not actually waste resources on trying to get IPv4.
It's been discussed. I think the new version has been just submitted yesterday or two days ago it's a short document. The most interesting questions which are still open are, what's the implication of this signal? What do hosts do when they receive that packet and how they should react and also what kind of security and other things could go wrong potentially with this? Or is it actually the best way to achieve the goal or maybe it's much simpler and easier just to filter IPv4 ethernet frames. Maybe.
So, please have a look, tell us what you think or if you have something to say.
Segment routing, right. Plenty of people in the room, more than in the previous session, when segment routing was discussed. So, yeah, there are two flavours of segment routing, one is over MPLS and one is with no MPLS just pure IPv6 using these amazing things called extension headers ‑‑ Warren ‑‑ it's one of the best things about the protocol I believe. Anyway, actually, most of the segment routing work is done in the spring Working Group at IETF, but to run a segment routing on top of IPv6 only networks, we need to introduce an additional routing header format, so because it's just related to IPv6 protocol, it's discussed and standardised in 6 man Working Group.
It's been a long story, and normally last call lasts for like two weeks and this one been in last call since March. But, as far as I know, most of open issues have been resolved. And it's getting closer and closer in being published as an RFC but it's still in the Working Group last call, so you still have time. Because I know people do not read anything until it's in the last call, right. You really, really, need to have a hard line for this. .
So this one is ‑‑ actually it's reasonably long, but if you are interested in segment routing and if you don't want to run MPLS, have a look.
I like this one, I might be bias because I wrote this.
So problem statement. We deploy an IPv6 only network and I hope most of this room is actually sitting on IPv6 only SSID. If not, I don't know what you are doing in this room.
So and if you do an IPv6 only you might still want to talk IPv4 only hosts, some were there most likely with need NAT 64 and if you use NAT 64 you do need the DNS 64 and all DNS people hate it because it breaks DNSSEC.
One of the possible solutions is what if your validating resolver on the host would do DNS 64 itself. But for this the hosts need to know which prefix is used. There are standards for this. I actually presented to one of them, it was copen Hague, and I had a lot of DNS people in the room and most of them came screaming because you need to know NAT 64 prefix to be able to do DNSSEC and to discover NAT 64 prefix you need to discuss DNS answer. So I agree it's got some issues. I understand why DNS people do not like it. But yes, there is a common Kay to discover NAT 64 prefix by trying to do name resolution for IPv4 only name, IPv4 only arpa and if you get a AAAA for that name it means that you are either on NAT 64 network or your resolver is lying to you and you have an attacker on the network.
There is also a more sophisticated to get NAT 64 prefix using BCP protocol but to be honest I am not aware of any deployments of this.
So what have I been thinking? Your network definitely knows what's happening if the network is using NAT 64, the router knows that because router masks the NAT 64 prefix to translator. So it looks quite reasonable just to provide NAT 64 prefix together with all other configuration information to the host using slack. So you can in one packet to go with your prefix, DNS, and other things you can get your NAT 64 prefix.
So basically we are suggesting to intro an RIR option to provide NAT 64 to hosts so hosts could do whatever they want. The main question actually is, do we need prefixes which are not /96? I would really love to hear an input from operators, because we basically try not to inflate our I remember option too much because unfortunately RIRs our I remembers could not be fragmented. So keeping the prefix just slash 96 looks like a neat, nice why the, and I am just curious if there are a real live use cases for NAT 64 be prefixes which are not /96.
So, please comment on the draft. I think it's 02 version now we are going to 03, and next week.
Or this one is actually not a topic for Bangkok. It's been discussed for a while. It's like holy word topic about address architecture and shall we have this magic /64 boundaries between the network and the host idea. There is no consensus on this, so 4291 BIS was published because of lack of consensus and the interesting thing is, both sides presented perfectly valid arguments. There is more than one way to skin a cat here. That's just for your researches. Yes, it's been a long discussion. A lot of miles, so I'm not sure a working group chairs even want you to contribute, because I actually promised myself I'm not going to comment on the topic any more.
Oh, path MTU discovery: A new hope.
Some people still have a hope we can fix path MTU discovery in the Internet. You are giving away so easy. Given up.
So, there are some questions again, right. Can we do something or shall we just give away and say okay it's a protocol transport upper layer which needs to take care of this, right? Or, can network layer still give some hints to transport? How? Can we actually discover MTU as a past property and can we do it in one RTT instead of sending a the low of packets, wait for time‑out, and so on? And if we come up with some ideas on how it could be done theoretically, can we come up with something which could be deployable.
So recently, two main ideas have been proposed.
Idea number one: Actually I can remember Andrea Rochenska was talking about this maybe five years ago and now I'm seeing a draft on this. The idea is if your router receives a packet which is too big to be sent to outgoing interface, currently it's expected to drop it and maybe generate ICMP. In reallife it it would the not because most routers have hardware cleanup, right. What have, instead of dropping it, it will truncate it to the size which could be sent through the link. And it will update some destination options, again extension headers, I love this. And send it out, and if there is another router on the way with even smaller MTUs that router will also truncate it and it will send it out. As a result your destination will actually get a packet with clear indication that is it's not a proper packet it's a truncated packet but it will clearly see the MTU and the destination might actually respond with ICMP, with the bit incoming the result in MTU to the source. The great thing about this, it's one RTT and you can get MTU even if you have a kind of cone of MTU and MTU is being decreased along the path.
Also, the interesting thing is you do not rely on ICMP being sent by intermediary, by some transit routers, normally they forward giga bits of traffic and they could not really send a lot of ICMPs, but your destination node might be actually able, even if it's doing some cleaning, it still might be sent enough ICMP to signal MTU back to host.
Okay, one idea, and again it's utilising extension headers which might introduce some issues. But it's not going to make things worse, right, we will not drop packet anyway. It couldn't be worse than it is now so we can only improve the situation I believe.
Second option is, to record MTU on the path. When the router gets a packet and MTU outgoing link is small, it will be recorded in the packet in the special hop by hop option field, and again the destination node will see the proper path MTU and it will signal it back to host. Again basically in both approaches, the main idea is let's stop sending from intermediate routers and move this function to the destination. Active discussion is happening right now on this one.
So, oh, I'm just on time ‑‑ IPv6 operations. So while 6 men is talking about how protocol is designed IPv6 operations Working Group deals with consequences, how we deploy what we designed.
So, again, link to mailing list. How to subscribe to the archive. And the interesting thing, charter has been updated to include IPv6 only because we have done with v4, right, let's just deploy IPv6 only.
One of the recent drafts is summarising operational issues you might see with neighbour discovery in terms of issues with a neighbour discovery attacks when your router might get some resource exhaustion while trying to resolve non‑existing addresses. This draft is actually not introducing any new ideas, it's a new could of nice summary of what has been proposed before. . But still, a really nice reading and understanding what kind of approaches you might take, so from an operational perspective I would recommend this, and when I was preparing this slide deck, I realised that on almost every other draft, I see the same name as a co‑author, so I decided that I'm going to be lazy and I'm asking Jordi to come and talk about the rest of the draft in IPv6 ops.
JORDI PALET MARTINEZ: Disclaimer, I was thinking I need to talk only about my own drafts, right. Because you mention the Joao document, this is not being discussed in Bangkok Joao commented that he wrote it just to let the people think about but it's not ‑‑ his intention is not to go further. And I didn't check it other documents in IPv6 ops so I'm only mentioning my own documents.
There are, in addition to Joao document and my documents, there are I think two more drafts actually live in IPv6 ops, I just checked about that, just if somebody wants to check that to take a look in the data tracker.
Okay, the documents that I'm working right now IPv6 ops, the first one which is in the review isst a kind of extension to a previous document that we have already which is RFC 7084 which was stating what needs to support a CPE, a CE for having IPv6 support. In that document we have support only for two transition mechanisms which were 6 RD and DS‑Lite and as Jen already mentioned, we are moving to IPv6 only networks, at least in the access, so we should have support in the CPEs for what we call IPv6 as a service transition mechanism. So basically they are 646 XLat, DSLite, Liteweight 4 over 6, Nab T and Map E, I think I'm not forgetting any of those. So this document is basically telling the C verdicts and also the hardware designers, the chip set designers, please make sure to support those transition mechanisms. If you are selling a router to an ISP, of course it's up to the ISP to ask you what they need. But if you are selling to a number of ISPs or preparing to go into the retail market, your product should support all of them, so a customer going to the shop to buy a CPE can work in any scenario, and there is also configuration guidelines so actually the CPE will be able to work if you switch from ISP. Of course if the ISP is supporting those protocols, but in general they are basically very, very simple and they exist, the thing is actually just making them work together.
The next document how related to these but concentrating only NAT 64. I started this document looking for how to provide guidelines to operators and actually validators of enterprise networks to deploy for 64 XLat and then the Working Group told me why not you make it wider and also talk about NAT 64. So the document actually is a guideline deployments for NAT 64 and 464 XLat and looking at the different problems that you might find when you go into that scenario, and giving you some hints how to proceed about that. Okay.
I'm getting the warning for its time so I'm going to go faster. If you have any questions I am here the rest of the day, so just approach me later.
We have two documents that we recently merged. One was from T‑Mobile and the other one was one of my own documents that was submitted to sunset 4. Basically these documents are talking about the same more or less, is, we have problems if we use DNS 64, we may make DNSSEC. So let's make sure that everyone implementing a DNS, with DNS stack support also deploys IPv6. That's the thing, and then we are extending that to other records, not just DNSSEC.
There is another document which is IPv6 point to point links. I started this document a long time ago, but then it was not capturing the tension of the Working Group but I restarted it recently. The idea is that most of the people believe that because one document in IETF is telling the router vendors they should support a /127 for the point to point links. That's the recommended way. That's not the case. The document is only telling the vendors you should support one 27 but it's not telling you cannot do a /64 point‑to‑point link. So that's what I'm trying to clarify in the document and explain what are the advantages of that way.
There is another document that it's recent as well, where we are comparing the technologies that I mentioned in the first slide regarding the different IPv4 as a service transition mechanism comparing them in terms of performance and different aspects. This is still a very early stage. It is not even a working group document, and we also are going to do some performance testing to include in the document.
Then we have another document which is this version for RFC 6177, you might remember this document previously was 3177. We did some changes also talking with the registry community to the 3177 a few years ago, and I believe that now the document is less clear and is creating some confusion in the operators community, so we are trying to address those.
There is one protocol which is happy eyeballs, that is done in the host. So we are now doing work to also support happy eyeballs from the network perspective, and adding a previous document that I had which was trying to do some others to operators when happy eyeballs is detecting some failures in the network.
And the last one which right now is sleeping, but I will try to recover it probably in a couple of months, is trying to fix the definition of what is IPv6 only, because many people get confused, we are talking about the complete network or only the axis or not. So that's it. Thank you.
JEN LINKOVA: Thank you. The last thing I wanted to mention is actually not in IPv6 ops but I think it's very or not. We see it more and more issues with multihoming is more having to update link. It's about hosts being connected to two different networks. For example when you connect to this network and run VPN your host actually gets two sets of configuration information and one from this network one from VPN, or mobile phone, which is connected to mobile network and Wi‑Fi. So each set of configurations can be can I find as provisioning domain and the idea is to make the IPv6 host to be fully aware of different sets to be able to differentiate between them and properly use configuration which is only related to the network when sending packets to that network. So this is really interesting work and I do hope it will be ‑‑ we'll start seeing real deployments of this because it's actually kind of been supported in some mobile hosts already.
So, the message is:
We at the IETF needs operators what should be deployed, what you would like to see or change, so please, read the documents, comment on the mailing lists and I don't know if I have time for questions, but I am here till Friday and I see other IETF people here who probably would be happy, and the IETF Chair is here, so any IETF questions or IPv6 questions you can find us
AUDIENCE SPEAKER: I am Pavel from scale way here, I just found out that ‑‑ I do understand that you were talking about drafts and not about adopted RFCs, but I have just found out that RFC 8475 has been adopted just like less than a week ago. Congratulations. Thanks for this job and could you please tell us a couple of words on what it's all about?
LUCIANO LENZINI: I was talking for half an hour last time.
AUDIENCE SPEAKER: Sorry about that.
JEN LINKOVA: About like depricated prefixes. You can find slides from the last time. I just didn't want to waste time on work that's been presented already.
AUDIENCE SPEAKER: Thank you. Marco from the RIPE NCC also an IETF participant by the way.
Thank you for the comprehensive overview. I would like to, and I'm going to try to phrase this question. Draw the attention to a number of IPv6 related individual Internet drafts that have not yet picked up by the Working Group and there is one in particular that I believe proposes to restructure IPv6 addresses based on the E164 phone number system and I realise that IETF has their own working methods that, given the nature of the proposal, people are not really eager to talk about it or comment on it, I have seen that one POP up in other fora, most notely ITU study group 2. It would be helpful if somebody in the community would actually take the time and write a little piece and explain why this particular Internet draft might not be a very good idea, because having such a position coming from the Internet community would help me do my job at ITU. Thank you.
CHAIR: We have good news, we have good news, we have something in the last presentation on this.
AUDIENCE SPEAKER: Serial from secretary air. I will speak on behalf of whole saint Peter's burring telecommunications companies because I do believe that I have a right to do it. This thing I would talk is very supported in telecommunications in saint Peter's burring, some people believe they can fix ‑‑ they do believe in Santa Claus maybe, but ‑‑
JEN LINKOVA: You say Santa Claus don't exist?
AUDIENCE SPEAKER: I don't believe that my voice can change anything about IPv6, but I want want my voice against IPv6 to be raised and to be noticed in public. So, if you want more comments, we can discuss it later.
JEN LINKOVA: We can organise a special Working Group at voices against BGP, RSVP, OSPF and...
AUDIENCE SPEAKER: I'm not talking about against ‑‑
AUDIENCE SPEAKER: A lis a Cooper, I just wanted to say thank you for taking the time to put this together. It's important for us in the IETF to get wider visibility and input from the operator community, so thank you for doing that. And I would just say, even beyond contributing on the mailing list, if you have an idea, if something here sparks a thought in your mind that you want to contribute but you don't know how or you don't feel prepared to contribute on a mailing list, please come talk to me or or any other people who are active IETF participants and we can help you get started. Thanks.
CHAIR: Okay. Thank you Jen and Jordi.
(Applause)
Okay, up next is Oliver gas err from the Technical University of Munich.
OLIVER GASSER: All right. So, Hi everyone. I am from the Technical University of Munich. I am going to talk a bit about IPv6 measurements and more specifically about composing an IPv6 hit list to conduct those measurements.
So, this is a joint work with colleagues from Munich, the Polish academy of sciences, the University of Grenoble, RIPE NCC, and the university of Trenteck.
All right. So, Internet measurements. So why do we actually conduct active measurements. So, Internet measurements are an important tool to understand how specific networks work. For example, you can ask yourself which IP addresses run on a certain ‑‑ run an HTTPS web server or how securely configured are IOT devices in my network, are my DNS servers vulnerable to certain attacks, and so on.
These measurements are used by researchers, security companies, but also they are used by bad actors, so I think it's very important for us to understand and also for network operators to learn measurement techniques which are used in IPv6 compared to those which have been used in IPv4 before.
And also, to understand how devices can be discovered in your own network and maybe also take action by conducting measurements yourself.
So, what are the main differences when conducting measurements in IPv6? Well obviously, as some of you might know, it's quite easily to conduct brute force measurements in IPv4 because the address space is quite limited. So you can do that within just a few hours or even faster.
In IPv6 the story changes a bit. So the address space is just too expansive to conduct BruteForce scanning. Therefore, the go to with an I is to assemble what's called a hit list, basically a target list, a list of IPv6 addresses that you can then use as input for your measurements.
So, how do we actually assemble such an IPv6 hit list? We can leverage the DNS to gather IPv6 addresses simply by resolving to AAAA. We can also exploit structural properties to learn new addresses and when I say structural properties I mean for example how the kind of network is laid out, how the addresses are assigned and so on.
And one other thing that we explored was how do we actually get client addresses and we looked at using crowdsourcing techniques to achieve that.
So three challenges that I want to explain to you a little bit during this talk, when seam link such a hit list are do we actually see clusters in the hit list sources? Is the hit list balanced or not balanced? What about aim asked prefixes? Ill go into that. And how can we actually find reachable addresses, because it's easy to assemble a large set of IPv6 addresses but if they are not reachable, then they are kind of not very useful when conducting measurements.
All right. So the first question arises what is the actual sources where we can learn potential IPv6 addresses? And the important thing is there is this large list, but the take away for you is there are a lot of public sources out there where you can get IPv6 addresses. Of course the go to things like zone files, top lists, also blacklists, any DNS, certificate transparency, where you can just extract all domains from certificates locked in certificate transparency, there are services out there which let you down Bitcoin node addresses, RIPE, the RIPE NCC also offers noise services where you can ex distract addresses, and we did that from the trace route results and from the IP map project. You can use this vast input set and conduct traceroutes yourself to gather even more router addresses.
And here, what he see on the right side is kind of a run‑up of addresses that we gathered with the various sources.
And what we see is that certain sources, especially domain lists and certificate transparency and also trace route, contribute a lot more addresses compared to the other sources.
So, coming back to the clustering and the bias argument, how diverse is the address set that we gather from these sources? And here is the CDF. Just briefly what does it mean or what are the key take a ways?
Some autonomous ‑‑ so basically it's an autonomous system distribution, and what you can see is that for example, for certain sources for example, the domain lists and certificate transparency, you see that 10 autonomous systems already cover more than 95% of the addresses. So that's kind of quite an unbalanced source. Whereas other sources such as addresses gathered from RIPE Atlas are more balanced, as you can see.
We have just 10 ‑‑ so its top 10 ASes cover 25% or so of the addresses in the sources.
That's all good and well, but how much of the actual IPv6 Internet do these IPv6 hit lists cover? And here you see quite an interesting plot where we have all the basically announced prefixes and we have a scale denoting the number of addresses that we find in each of these prefixes. And we see that about half of the prefixes that are out there in BGP are actually covered in our hit list. Some too with kind of a larger coverage, as you see here for example there is one prefix which is, which has a lot of addresses in them and some with less addresses. But I think this shows that it's kind of relatively easy to get good coverage without using the IPv4 BruteForce approach.
So, what are the key take a ways from these kind of analgies of the sources for IPv6 hit lists?
So, as I already know and as most of you probably already knew before, the IPv6 address space is just too fast to conduct BruteForce measurements. Addresses can be gathered from many different publicly available sources. So in the work we try to use only publicly available sources so that it's also possible for you to kind of understand that everybody can do this, so it's not just we having access to some ISP or so, but it's the sources are out there. And about 50% of the announced prefixs are covered in our hit list.
Now coming to our next challenge, so now ‑‑ so we wanted to perform entropy classing. So the question that we asked ourselves was are there similar addressing schemes that we find in our hit list or or are the addresses kind of all over the place? And the approach that we use there is to group addresses to find similar addressing schemes.
And what you see in this block, basically we conducted clustering, and ‑‑ so this is basically a blot can be split foo two parts. On the left side, you see the how many of the prefixes are covered which each cluster. And by the way we have just 6 clusters found in total representing the addressing schemes. And on the right side, you have the actual entropy of the clusters. So what does it all mean?
For example, if we look at the ‑‑ so, each of these boxes represents one nibble, which means one HEX character of an IPv6 address and what we see here is that there are 6 different addressing, 6 different prevalent addressing schemes out there, and some of them we might immediately recognise, for example this one looks a lot like privacy extensions because there is a very high entropy in all of the addresses. Whereas compared to this one, where it's just, we have also high entropy in most of the kind of host part of the addresses but there is also some parts which are low entropy, so most of you probably know this. This is SLAAC or a Mac EU I 64 mapped addresses. Then we have some addresses, some clusters which just show very low entropy in most of the, most of the parts of the IPv6 addresses. In these are kind of the low bit addresses here.
And what this allows us to do and what I will also talk about in a few slides is using this information, if you can kind of understand how a network, or what kind of addressing schemes certain networks uses, you can leverage that knowledge to actually find new addresses that you didn't know before.
So, for example, I could use prefixes which adopt this addressing scheme and just tryout different addresses in this part because it's very likely that I find more addresses there, compared to the low entropy part here.
So, key take a ways.
Most network just use a handful of addressing schemes. As I showed you the 6 addressing schemes that we found, which is kind of good and bad, so industry best practices are followed but also these addressing schemes might uncover hidden host that is we didn't know existed before and are not in any publicly available source, but we can kind of learn.
One other very important aspect when conducting IPv6 measurement is the concept of alias prefixes. So just briefly, what is an alias? An alias is basically multiple addresses belonging to the same host, and an alias prefix is bound to the same host, and this of course introduces some bias as you might expect. As some of the hosts are over represented in your measurement. If I conduct a measurement and want to kind of understand how secure are HTTPS web servers, and I have two to the power of 64 responses from, within one prefix, with insecure configuration, it kind of is a bias because it just represents one host and a lot of different addresses. So the goal is to detect alias prefixes and we did that using a superey random probing technique. Basically going through every prefix size level and going through every branch, probing a random address and which is highly unlikely to be responsive, but if we get responses back, then the likelihood that it's an alias prefix is very high, because it's a randomly generated address.
And we can do that on a lot of different prefix levels so we can exactly pinpoint where the alias prefix starts.
We perform the alias prefix detection on our input set, so that's kind of the input set on the left, and here we highlight all the alias prefixes that we found.
So, the good news is that it's just a few prefixes which are alias as you can see, but the interesting thing is that they make up quite a large part. Almost half, of all of our input set. And we also validated the kind of aliasing using fingerprinting such as the initial TTL, TTP option and also TCP time stamping.
What does that mean?
We can kind of remove the bias of these alias prefixes without losing a lot of coverage from our hit list. So that's a good thing.
So to summarise it this part. Alias prefixes can produce a bias in IPv6 measurement. We can detect them using pseudo random probing, and using aliasing, is detectible if you apply this approach.
One other aspect that we investigated was across protocol responsiveness. That's a fancy way of saying how likely is it that a certain protocol response on an IP address, if I already know that a different protocol response. So to ‑‑ the goal there is to identify relevant addresses for a specific measurement. To make this kind of more specific, we looked at the response behaviour between five different protocols and ports. So HTTPS, HTTP ‑‑ you will up here. And what you can see here, for example, is if I have a host responding on TCP 80, there is a 95% likelihood that it will also respond on ICMP. And what you can generally say, regarding the ICMP is, if I have a host responding on any protocol, then there is at least an 89% likelihood that it will respond on ICMP.
One other interesting aspect which might also be quite straightforward S if we kind of look into the HTTP, HTTPS QUIC space, we see that if a protocol ‑‑ if a host responds on TCP 80, it's quite likely that it also responds on HTTPS and if it responds on HTTPS, it's ‑‑ no the other way around. If it responds on QUIC it's quite likely it also responds on HTTPS. And if it HTTPS on HTTPS it's also quite likely that it HTTPS on HTTP, but the inverse is obviously not true, otherwise all HTTP web servers would also respond too QUIC. And using this information, you can kind of tailor your hit list with the knowledge that you are investigating HTTPS and you are investing in that you can say okay, I am just using the IPv6 addresses that are already responding on HTTP.
So, knowing the responsiveness on one service might also leak information about another service. It's not really necessary to contact any more horizontal port scanning on all devices. And the attacker might pick one port and then just continue from the responses that he gets on that port.
Another aspect that we looked at, if you remember the entropy clustering that I showed you earlier, is how can we learn new addresses from the address that is we already have? And we inspected two different techniques. The first one being entropy IP which was actually already presented by Pavel Forenski at RIPE database 74 in Budapest, and the second one being 6Gen, which was presented at IMC last year, and the basic idea there is to generate new addresses in address regions. So if I already have these addresses in the prefix, then it might be likely that these are also valid responsive addresses.
And what we found was that interestingly, by running those two tools, if we feed them the same input addresses, they generate very different addresses in their machine learning approach. So there is just a very, very small overlap in the output that those two tools generate, and we also have different responsiveness from these two tools. So, 6Gen also finds double the number of responsive addresses.
One also other interesting fact is if we just look at the overlapping addresses that both of the tools generate, they have a much higher likelihood of being responsive. So it might actually be of some value to run multiple of these tools together and just take the overlapping set because that will increase the likelihood of them being responsive.
One other thing that we found was that they actually found different responsive host populations. So you see on the ‑‑ here you see on which protocol the different addresses were responsive. And there you see the distribution for the two tools and we see for example that for DNS entropy IP finds a lot more addresses. But for ICMP, 6Gen is more successful.
So there is some value in running both of these tools.
All right. So, as I showed you, address learning uncovers previously unknown addresses, so we didn't is have them in our address set before. They are techniques to provide complementary address sets.
And kind of hiding in the expansive IPv6 address space might be more difficult than you would have thought.
All right. So, to conclude.
The IPv6 Internet is just too vast to conduct BruteForce measurements. You might be less hidden, as I already said.
The addressing schemes can uncover hidden hosts.
And the responsiveness, as I showed you earlier, of one service might leak information about another service.
.
You can check out this website where we publish results from measurements that we run daily and we publish also the data of the results, so you can actually use the IPv6 hit list and run your own measurement with it.
We also published a paper there and you can also see nice graphs where we show the trend of responsiveness.
All right. That's all from my side. I am happy to take questions.
(Applause)
CHAIR: Thank you.
JEN LINKOVA: I like the conclusion that you might be less hidden than you have thought because I am getting difficulties understanding why you think you should be hidden, why security is the way to go. So I think you should assume I will find you anyway and you should be protected by more proper means.
OLIVER GASSER: I totally agree, and one other comment, there was also a previous paper I think one or two years ago which compared kind of the regionability between IPv4 and IPv6 and to kind of understand ‑‑ so basically the outcome was, for the same domain name, there is ‑‑ the IPv6 address is more likely to respond basically because the author said okay, the firewall rules for IPv6 are not there yet, or people don't care about it and for IPv4, they did.
RANDY BUSH: Responsiveness, the shape of the responsiveness matrix, how does that relate to the same in v4?
OLIVER GASSER: Yes. So there was a paper on IPv4 responsiveness ‑‑ there are some differences we compared IPv6 to IPv4, and the full details are in the paper, so I encourage you to read the paper. I don't know off the top of my head what was the actual difference between the IPv6 and IPv4 responsiveness. But there are some similarities in the ‑‑ across protocol responsiveness and differences.
CHAIR: Any further questions? Okay. Thank you.
(Applause)
And next up we have Jens who was also at the last meeting, and he has a short update on what he has found.
JENS LINK: We don't need IPv6. We just heard a comment that somebody, some people hate IPv6, so ‑‑ yesterday in the DNS Working Group, if IPv6 doesn't work, just turn it off. Nobody cares. I don't name the person here, but there should be videos.
I read some interesting documents lately, and finally, this paper declares IPv6 as a dead protocol and suggests to use newer available protocols in the future.
Jen, IETF working on suggest newer than IPv6?
JEN LINKOVA: Now I feel bad because I was thinking about submitting a lightning talk on IPv6 bullshit being gone and it looks like I need to do this if I see more researches to this paper ever again.
JENS LINK: I find another paper, IPv6 addresses are hard to remember, addresses are larger, we get more traffic. Upgrades costs money. Local networks have to change and we have to run two IP schemes. We could get rid of IPv4 and just run IPv6, but okay...
And I think people want to believe this. Just like in the X files.
Just like by the state of IPv6 implementations or the lack thereoff. I tried to find out if I can from Linux from scratch on an IPv6 only host. The short answer is no. I started asking questions about plans for IPv6 deployments. And I was under the impression that some people were actually working on it.
I got some new interesting answers. Deutsche ban told me that I should use HTTPS. When I asked about IPv6. We are always a little behind, in the Berlin public transport on Twitter.
And there is a little bit older from an adult entertainment site. So we came up at a previous RIPE meeting, came up with the idea of what about porn in IPv6, and I Googled for support of adult entertainment site, and asked them and they told me we are never running out of IPv4 addresses.
Six months later ‑‑ the negative side. B zip .org does not have IPv6 any more. So it got to domain, it only have IPv4 ranked. There wouldn't be any actual content.
And the positive side. And it's not intentional that this slide is empty. So nothing has changed besides all those oh yes we are working on T and yeah, yeah, really soon now, I even got copied on some tickets with IPv6 addresses and reverse delegations and stuff like that, and yeah...
Thanks to Twitter support by not answering my questions about IPv6 support you gave the most honest answer of all. All the other yeah we're working on it and got a plus one, on our to do list, they were just go away, don't care, don't bother us again.
The good news is I stopped asking about IPv6. At least I tried to. People don't care. I'm just playing IPv6 bingo, its much easier.
Why? On Friday in August, a friend asked me to check out the new Wi‑Fi at DB, that's a free wireless network at the German train stations. It's a completely new network. Who of you would agree that setting up a completely new network is the ideal starting point to implement IPv6? Quite a lot. They didn't. Intentionally.
One of the reasons given, "We don't know if RIPE will give us enough addresses. ".
Then I noticed that one special website is hosted at GitHub. As you may not GitHub does not have IPv6 and people are asking for years and years and years and they get we're working on it and it's got a plus one on our to do list. That wouldn't be a problem if the website would be about reading rabbits or something like that, but it's a website for and by people, with a very strong focus on Internet and networking stuff.
I asked, some people said I was unfriendly. Maybe. Some people wrote they would have been very more unfriendly. Then I quit, including the IRC channels.
Speaking of rabbits, that's the German word for rabbit. So people breeding rabbit actually have IPv6.
That's quite easy, you just go to one of the big German hosting companies and have IPv6 automatically.
Reasons for adopting IPv6. I'm currently working for a larger company and the reason for them to adopt IPv6 is the lack of IPv4 addresses. And that's a lack of RFC 1918 addresses, they don't have a public with with public IP space, they have a problem with private addresses.
Some people suggested to use 11 /8. Some people suggest using 100.64.0.0 /10 and actually some people doing this. I have seen several clusters using these IPs.
Thanks to Wolfgang, I have a nice graph from DE‑CIX, comparing IPv4 here and IPv6 there. So there is a lot of work to do.
Some questions still remain. If some people running a website for networking people, how can I ‑‑ and not having IPv6 ‑‑ how can I stand up in front of an audience and tell them that IPv6 is important?
When will there be more prefix traffic than IPv4 traffic? And when will things start to break?
Okay, they started to break but people work around it without implementing IPv6.
One suggestion for Reykjavik, can we please make the default wireless NAT 64 and for people who need IPv4, they should open a ticket with a reason ‑‑) applause)
Thanks.
CHAIR: Thank you. I suppose there is not too many questions. Oh, there is one.
RANDY BUSH: Of course. We actually tried that last at IETF, and specifically for the IPv6 Working Group, and the, whatever you call the IPv6 ‑‑ IPv6 ops, that's it, and it didn't work out as well as we would have liked. We specially were trying NAT 64, etc. Unfortunately there is still work to be tonne.
CHAIR: We have to keep it very short.
JEN LINKOVA: Very short. As far as I remember it did not work very well because of the bug in the networks mostly and the survey which was sent showed that 75% of the responders said they could get work done on IPv6 only ‑‑ 75. I have data.
RANDY BUSH: So when 75% of Google's customers can succeed in search, you'll be happy.
CHAIR: Okay. So thanks again.
(Applause)
And next and last on stage today in our session will be Benedikt doing some ‑‑ well you'll find out.
BENEDIKT STOCKEBRAND: Okay. Hello everybody. For those of you who don't know me ‑‑ first off, if you just read the slides, go and see the video. It doesn't make much sense here, but whatever.
Anyway for those of you who don't know about me, I am Benedikt Stockebrand, German, actually live in Germany right now, I have been doing UNIX, TCP, IP, Internet, architecture stuff, operations stuff, some major cleanup things which is helpful if you work on IPv6, because it always happens together somehow. Start with IPv6 in 2003. Wrote a book about it in 2006. Coauthored a study for the general Federal office for IPv6 security in 2010. Been one of your Working Group Chairs for about four, four and a half years now, except I normally Ray and Jen take over the stage here. Currently work as a programme manager for German government sort of thing deploying IPv6 in the state of Hessen.
And what I want to talk about is how to manage to run out of IPv6 addresses.
Now, I know this is a practical community, as always, but we still need some science.
Slides from training I have had before. You all know we have 2 to the power of 128 addresses which is this number, which is for practical purposes, infinity, unless you have spent too much time in maths doing number theory, but then that's your own fault. And this number and the way it's presented is actually a real problem, because it really makes people believe you can't run out of IPv6 addresses. If you know what you are doing you actually can.
So what I tell people, okay, if you can't handle this number, compare the number of IPv6 address to say the number of IPv4 addresses, you still get a slightly smaller infinity here, but what actually kind of works, it takes a bit longer to explain is original idea how addresses were supposed to be allocated, back in the old days when IANA was still called Jon Postel and had a daytime job as well, you had an is there 24 IP addresses, so we'd have 16.7 million of those. With IPv6, the original idea, RFC 3177 was /48. So we could actually grow by a factor of 2 to the power of 24. Thousand this number doesn't really look much like infinity, but it's something you might manage to imagine on your bank account balance for example.
Not as impressive, but it shows we have quite a bit of chance for growth but it will be finite. And even if you decide okay go for a /56, 4.3 billion, but it's still finite. So we actually have a chance to run out of addresses.
Next thing we need ‑‑ that's what I try to tell people. We have plenty of addresses. The problem is we don't have plenty of bits in addresses.
Then there is this thing called the HD ratio. How many of you know what this is. That's pretty good. But there are some people who are just too busy reading e‑mail I guess.
Now, the HD, the host density ratio, which is actually normal when it comes to IPv6, it should be the sub‑net density ratio, but it doesn't matter, is defined as the log base 2 of the number of addresses used divided by log base 2 of the number of addresses available.
The number of addresses available, you take ‑‑ log base 2 of the number of addresses available is number of bits we need to encode the addresses. Big science. So, for number K addresses we node log to the basis 2k of bits to encode these addresses in bits.
Means, for if we need 5 addresses, we need 2.32 whatever bits. So how mean people here does this actually make sense using a fractional number of bits?
I thought so.
It still works. Seriously. There is this guy called Claude Shannon who recently like, in 60 years ago wrote some work on information theory. You might know that if you have a background in communications, electronics, whatever, or the wrong sort of theoretical computer science, which I happen to have, that you basically works like this. You want to al collate 5 allocations, so how many bits do you need for five subnets or whatever? 3, right. Okay. Hang on it says 2.3 something. Okay, if you have 5 sub calculations for your originalcations, another 5 sub suballocation per allocation. You have a total of 125 final allocations. And you need how many bits for that? 7. Well not quite. We just said we need, 3, 4, 5 allocations, so you need 9. Not if we keep in mind that we can go for fractions of bits. It actually works. First time you see it it's completely strange but it actually makes sense in a way.
We get back to that example a bit later on. It's just one of those things the first time you hear it, it's strange. If you want to have a long explanation, see me over lunch or whatever.
Now, the important thing here is that we measure address space allocation not so many percent of the addresses are used but we actually bring in an algorithm. And that means we count the number of bits we actually need to allocate addresses. So, for 5 allocations we need 2.3 something bits. We do that things start to make sense and as the numbers get smaller that's nice, it makes life easier.
The thing is in think in bit utilisation not in addresses.
So much for science. Let's get some real work done. How can we possibly run out of addresses? . As I said we need to waste bits not addresses. If you start to try and waste individual addresses you'll never get anything done. You never get anywhere near where you want to go. But if you start to waste bits in your addresses, it's only that far to go.
So, if you go for the bits you actually make it. Trust me. I have seen people succeed in this.
Half the work is already done, at least for now. RFC 4291, sess 2.5.1 says ‑‑ okay recollect the last 64 bits are gone already anyway. Combine that with micro segmentation and what happens? Those are gone.
And even if you decide no I don't like micro segmentation, cross out any three of these 9s and the number is still looking pretty bad. So that's the first thing to do really.
If we continue ‑‑ people who have come up with, they actually put some thought into this as far as I can tell. It's just one of these things. Kids don't try this at home, if you do that yourself on the sub‑net prefixes and you are done very, very quickly. So basically, what we have here is we have 18, what's that, quadrillion, sub‑net prefixes to go. Pretty impressive number. Bring the algorithm back in. That's 64 bits, or 8 bytes, or should still say octets. John Postel is dead so we are allowed to say bytes these dates. That's not impressive. We can handle that I'm pretty sure.
The easiest approach. Just sit and wait. I am with a government agency right now as a contractor. I am starting to learn this. The Internet growth, exponentially as far as we can tell. And every time we double the size of the Internet for a suitable definition of size, we basically need another bit. It means the Internet grows at a constant bit rate. And it's difficult to get proper numbers these days.
I found a number of graphs where the Internet growth is going exponentially and then it just flattens off, thanks to DNS light and things I guess, it's very difficult ‑‑ I asked our scientific people here they said they don't get any serious number about how many devices they have on the Internet. This just doesn't work, we can't measure that right now. So there is a bit of guesswork involved here.
Maybe once we are through with IPv6, we can get some reasonable predictions. Anyway in about 50 to 100 years time we will probably outgrow IPv6, roughly.
We're not going to wait that long. So what else can we do. Multilevel delegation.
Basically, we can only delegate subnets at integral bit boundaries. Not these 2.3 something bits, that doesn't work for delegation, it works for other things but not here.
What we do is if we keep delegating addresses, that helps to burn fractionings of bits, but these things sum up. And so we start with IANA, obviously. Then there is the RIPE NCC. Then there is some major international conglomerate with individual businesses and they have national offices and they have local offices and they have local teams and they have some personal five domains and whatever, all of a sudden 8 bits gone, yes. It works like that.
Well except that you also keep to add a few percent extra to have some slack if you need some more and then you do the same thing, on nybble boundaries, that's 4 bits per level and you are done very, very quickly. And yes, people do these things.
Even better, repurpose bits. What are IP addresses there for? Something that people sometimes tend to forget, what are IP addresses there for? To hold routing information. The bits in there are there to make sure that the packet gets where it's supposed to go. And that's it. So, what do people do? Very clever people put in organisational structure, just because these two departments are sitting in the same building on the same campus doesn't mean they get an address allocation for routing things there just because there is a stupid fibre going to that building or whatever. It just doesn't work like that.
Using port numbers for subnets. Now this is really one of the strange things I have had in the training. Explaining to people okay, this is what IPv6 addresses look like and how you use them. Could we talk about an address plan please? Yes, sure. And they start okay, we have things in a specific data centre, if it matches your routing topology, okay, fine. And what row of racks and whatever, that was getting sort of difficult and I was realising we were going the wrong way. And then they came up with okay, but we could encode what services are running in that sub‑net. So something like blah blah for HTTP, blah blah HTTP for 431, hang on folks what you have a server doing both HTTP and HTTPS. Right, we need a bit for ever service. How many service DOS we have. Basically just HTTP and HTTPS. What about DNS, isn't, maybe iMap, maybe ‑‑ observing, so they came up with a list of services that they had and I told them now please work the numbers. And they realised oops our /29 doesn't do. We need more addresses. That's not the funny part. No laughing yet. The funny part was, we have a /16 for IPv4, I don't see any reason why we can't have one for IPv6 as well.
These things actually happen. And it works.
Okay. Geographic co‑ordinates. Running joke at the IETF for so long,
JEN LINKOVA: Extension headers not addresses.
BENEDIKT STOCKEBRAND: There are addresses as well, and I am pretty sure I read about that in the mailing list. Oh know I'm going to kill that threat, I'm not going to read this. Then you could put some magic IoT stuff in there. If that doesn't work out try another buzz word, rinse and repeat. Eventually it's going to work.
Something was around about half a year ago, put in telephone numbers. So you take a /8 IPv6 prefix and then you have 15 digits, just take decent hacks without doing and you can see the address and you have a single sub‑net forever telephone. These things actually get proposed. Cool. Don't tell me we can't run out of addresses. And other things like that.
So basically, the only answer I have to that, why don't we put e‑mail addresses for some technical contact whatever in there. So some people you find outside might actually start sell short e‑mail addresses rather than IPv4 addresses some day, that's the only answer I have to tell people this doesn't work.
Then there is politics. Always then demand more than your peer got. Never mind actual requirements. Just say I want twice as much as he has. And we have had that here before.
Facts are for wimps. Never mind that, perfectly never mind that, you are an ISP you get an allocation large enough to provide every customer with a /48. So you give them a /2262, keep the rest for future years. That works very well. And then well we make one selling IPv4 addresses why shouldn't it work with IPv6 as well.
Then there is the question, things we learn from history. Anybody know this guy. I am disappointed. German philosopher. And he said the only thing we learn from history, we learn nothing from history. In other words the whole problem is going to solve itself. We will run out of IPv6 addresses, history will take care of itself.
Okay. That's it. Thank you.
CHAIR: Thanks. We are already over time and we should be at another meeting at the moment. So, please keep it short. Jan.
JAN ZORZ: Thank you for this. And yes, I second that. It is completely true. I have been seeing this going over, over and over again. People squish everything again on the first bit available and then they fail, and then the next IPv6 addressing plan is like you said, they go over every boundary they have and they usually, if they are very, very lucky, they succeed a third time if they have a good consultant. So, thank you for this.
CHAIR: Thank you all for joining the session. We're done. And it's time for lunch. See you next time.
(Lunch break)
LIVE CAPTIONING BY
MARY McKEON, RMR, CRR, CBC
DUBLIN, IRELAND.
