These are unedited transcripts and may contain errors.
IPv6 Working Group on Thursday, 27th of September, 2012, at 9 a.m.:
DAVID KESSENS: So, good morning, everybody. This is the second session of the IPv6 Working Group. This session will be, topicswise, a little more IETF orientated. We grouped some of those presentations that's related to that kind of work for today. Very important, this session is on the Internet, so you will, everything will be recorded, everything will be live, everything will be there, so keep that into account.
Yet another slide, we have three co?chairs. Here they are in case you don't know them.
If you are more interested in legacy issues and stuff like that, that's happening next door, but if you want to do IPv6 then please stay here. We are going to start with Layer 2 issues and solutions, some IETF work on operational security and catalogue of IPv6 routers, which is interesting information and very brief presentation by Tom Taylor, and presentation by Andy Davidson. And finally, we get results of the 2012 survey. So anything that's somebody wants to add, we are just going to start, come to me there upfront and we can always see if we can add one slide at the very end.
Anything else? No. Then I give the mike to you.
ERIC VYNCKE: So, and good morning, so let's start as soon as we can, so we can finish on time. And what about Layer 2? People specifically networking tends to consider layer 2 as a plumbing and pipes, which is kind of true. But if you think about your network, it looks like a sand castle, yesterday at the party there was sand below our feet so we could have built this. Look at this. This nice castle, on the top the tower, this is basically all the services that you are delivering through this network. You can even add fire always, right, in this sand castle, and the sand castle is also Layer 2, and if you have built this when you were young, you know where the architecture is coming from. That's the wave. And if you don't get a strong Layer 2, you don't have a strong network, even if plumbing, it's dirty ends and everything. So we need to secure this.
And you are v6 people, right, so we not explain to you much about this rogue attack. Route advertisement and non?authenticated by default and have put a useful, they are needed even if you do DHCP, right, so to get the data link layer of the address then everyone can go away and go to the Internet. We all know that anybody can come and on my slide, you will see quite a fun this guy, and if you look about the colour of his head, you understand it's a black hat, right, in security the black hat and the white hat. This guy is the bad guy. And on purpose because it's ?? but most of the time I have seen it and you have seen most probably as well that misconfigure Windows machine or Linux or whatever and it can send the roguery, then everyone configures itself to Tuesday as the default exit router, and then it's basely a DDoS if this guy forwarding packets to nowhere because it's misconfigured or if very bad guy he can run the man in the middle attack and intercepting all the traffic. This is devastating. We have seen it in universities network everywhere, in IPv6 network or in IPv4?only network. And it's even more severe now because it was by default intercepting only traffic going to v6 websites, which were not so many of them before 6th of June; now, after 6th of June, this attack is even more severe.
And just to give you an idea, a couple of months ago Jan Zorz was kind enough to invite me at the Slovenian submit and the only way to go there and arrive on time was to take a flight very late from Brussels airport, 22:30 p.m. So I was I was expecting traffic jam on my way to the airport but of course on the evening, no traffic jam so I arrived too early, so I am bored there, so what I am doing, all of us are v6, so is there any v6 over there? Look at this, I had to pay to go on the wi?fi and they even gave me an IPv4 shared address, which I am quite offending to pay for something that I am sharing. But anyway...
So, no v6 there. But am I the only IPv6 guy in the airport at 10 p.m. And I am receiving multiple replies, I have got friends there. I phone Marco, whatever. So being really bored, I say next step, what about starting my dinner, OK, putting my Mac into router mode and sending route advertisement, that's obviously what I did. I have done the route advertisement a good way, I was not intercepting the traffic or nothing. I was simply delivering free IPv6 to the airport. And then, if I count the numbers of neighbour IF, I got about 60 of them. Meaning that at 10 p.m., I could have intercepted the traffic for bad reason and nobody would have noticed. In an IPv4 only network so it's really, really important to get this roguery attack fixed.
How can you do it? Multiple ways. And the best way to prevent the attack, again non?malicious user so misconfigure machine, is basically to tune the route ?? the router advertisement, there are two bits that indicates the priority of the router, by default it's medium so all misconfigured machine set to medium. If your router sends it with high, all the machine will be using yours. Usually an attacker will send itself with high priority. So it doesn't help.
You can disable stateless auto configuration, but then you need to configure static route everywhere because does not provide default route. The IETF is work on something called secure Neighbour Discovery, I will be covering this and other techniques like host isolation and so on.
Send. Two RFC, one about what they call cryptographically generated addresses, CDA, and using certificates which is basically Send. You can read this but nobody is using it.
AUDIENCE SPEAKER: Lose all the auto configuration because you need certificates?
ERIC VYNCKE: We know the story, we can use trust certificates. Basically nobody is using it, for multiple reason, and basically a coffin where SeND is still trying to be alive, but in comes Windows, one nail because Windows does not support SeND, in comes Mac, Mac does not intend to support SeND, two nails in the coffin of SeND, it's dead, it will not escape. So let's stop talking about it.
Host isolation, that's one way of doing it. It's basically a way where you will isolate every node from other nodes, and you will only allow the real router to communicate with the normal host. Multiple ways of doing it. On hot spot, you can prevent communication between hosts, between wireless station, on some access network you can do it. On the data centre like hosting provider, you can do private VLAN. The example here is on private VLAN because it's easier to put the picture. Again, the bad guy with the black hat. Normal ?? on private VLAN promise cues port, meaning that this can now be multicasted to every other interfaces. Normal behaviour.
The bad guy sends a rogue RA on isolated port, then it's blocked. Very efficient but if you know the story about IPv6 you will need to manage that because duplicate address detection is also prevented by this, so you will need to use proxy somewhere. You can do it but you need to enforce a few things on the network itself.
Another way: That's what the IETF is designed with RFC 6105. In this case, that's basically the same thing but you deploy explicit configuration, I put Cisco on there, we put specific configuration on port facing host. This is a behind me. It's the same principle, basically.
The normal route advertisement from the router does not hit the specific configuration, so it's multicasted to all the nodes, and the bad guy sending his roguery, it's specific configuration and it's blocked. Multiple ways of doing it.
And not only multiple ways of implementing it but as well multiple ways of configuring it. For instance, I said that SeND is dead, and SeND specific to prevent the roguery like has been said in the room, you need to get a certificate for it, it's difficult to deploy, to all hosts, but you can deploy SeND to all routers and all switches and then switches implementing roguery, that will simply learn from SeND which is the good router, so no need to configure it, right, this is called SeND proxy. And even more, not only can block all the RAs but you can also look inside the RA to see where is the good prefix because you can also misconfigure router so RA?guard in this case you can prevent normal router misconfigured.
So far so good, right? So IETF was happy, everyone was happy because things are starting to shape. In comes a guy, both of us were talking in the IPv6 in Frankfurt, he told me, Erik, I found an issue with RA?guard. Then I was thinking, you fragment them, he says yes, I have a trick against it. So it was very fun day. But remember, we can fragment v6, OK? And we can fragment in ways that are unusual for IPv4. In this case, that's a single data gram in two fragments, right? And you look, it looks nice because destination is there, on the second fragment we start with TCP, so naively we can assume that stateless firewall, I say stateless, right, stateful firewall is is not an issue, but the stateless firewall and RA?guard is stateless, right, because it's wide speed, it needs to inspect and drop packet at wire rate. We can think that on the second fragment we can still pass because we can the lines of hop by hop and routing and fragment, then we know the stat of the fragment, but we do not know what is there, OK? We do not know. Because the fragmentation could have happened as well inside the destination header. Like this one. It's valid. But there is no way for a stateless firewall to understand the lines of this remaining part of the decision header to find an ICMP message which is to prevent the roguery attack. So basically, this kind of fragmentation defeats completely RA?guard. You see Marco this point is THC fake router with all the extension there, so there are multiple ways to enter this, so IETF wants to prevent this kind of fragmentation and I think it's fair. In IPv4, the layer 4 information by ICMP or whatever, must be into the first fragment. Currently, it's a low IPv6 to have them to the second or third fragment, defeating all the stateless access control list, so the IETF want to revert it and. We must have the TCP or into the first fragment, this will solve the problem. There are also couple of switches that enable under demand transport where we can drop all fragments like the first one where do you not have ICMP or TCP. As for now, we have never seen traffic doing this kind of fragmentation, we can drop them. But it's wishful thinking, somehow. That's where we are, anyway.
Next step. Neighbour Discovery spoofing, that's spoofing for v6, same thing. There is no authentication there so we can spoof them. Most of you are mostly using dynamic or snooping or variation of it for IPv4. How can we do this for IPv6? It's slightly more complex and I will come back on this because in IPv6 there are multiple ways of getting your v6 address. In v4 it was usually the HT CP 4, easy. Only have to suspect this, one source of information. It's not the case in IPv6. And the IETF, they got the Working Group called Source Validation Improvement, work to see how we can do it.
How can we fix this? How can we prevent user or CPE basically to steal the v6 address of another CPE of another user. Static configuration, OK? Maybe in the lab or in the data centre but not in real life. We can use SeND, in this case only C G A basically but we have seen SeND is that in the ground, too many nails in the coffin. Switches can do a few things. And the switches we have to learn, the binding between v6 address and the Mac address, and the same shot also show which VLAN you are and which interface you are so we will be able to prevent spoofing as well there on the Mac address layer. And multiple ways of learning the v6 address, I see SeND for instance, DHCP or if you are using slack, the only thing we can do is snoop all the Neighbour Discovery traffic and use the first?come/first?serve. The first one using an IPv6 address will own it, that's weak, but if you think about it, on Internet switches, that's all you learn the binding between the Mac address and port right and you have been doing this on Layer 2 switches for many, many, many years, so there is better than nothing, anyway.
And of course, SeND should have highest rating, and learning to HCP below and binding learn by snooping Neighbour Discovery should be the lowest priority in case of conflict.
How does it work? On this diagram, I put three hosts switch, binding tables and on the right?hand side the DHCP server. First one is easy, host number 1 is basically sending any neighbour solicitation and remember in v6 if you SeND a neighbour, you also include your own address, so the switch basically intercepts all the packets, SeND them to the CPU and we extract the sender Mac aaddress and we put them into the binding table. Easy. Host number two use the DHCP, we simply need to intercept the reply and put the data inside into the binding table. In this case, small surprise of course, was the DHCP is not exactly the same thing as v4. The surprise is that can give multiple v6 addresses to one host, so you need to insert here multiple bindings. Not a big deal.
Complication arrives when, for instance, somebody is using an address which is not yet into the binding table, it starts using it sending data packets first, simply maybe because the switch rebooted or somebody cleared the binding table. Oh, this packet is basically intercepted as well because it's denied to the TCAM, go to the CPU, then CPU can do two things. He can run that duplicated detection for this address and of course, one host multiple hosts in case of somebody spoofing it but assuming it's okay nobody spoofing anybody, the duplicate address detection probe will be replying, advertisement from the real host. Then, it's simply business as usual in the binding table.
Alternatively, he can also ask the switch an extension of DHCP which is query, basically go into the DHCP server and robbing the lease to see who is using this v6 address and then we can put it into the binding table.
Once we have this binding integrating table, we can. So one, you have this binding integrity table ?? built, you reprogramme your T cam basically, this v6 address must be on this, Mac address which is on this port, everything which is not correct is dropped and you get widespread correction and you are defeating here Neighbour Discovery spoofing there.
Talking about NDP, it's not only about spoofing; you can also run DOS attack against Neighbour Discovery, and this was quite new. And the world v6 day last year, I was a little bit scared about this because it was quite hot topic and not a real load of protection over there. We all know how that v6 scanning is impossible is useless, what if the bad guy here scanned the network, sending to ?? the route over there doesn't have those addresses in its neighbour cache who what is he doing? Sending neighbour solicitation, keeping the v6 packets that are packets in memory, a change compared to v4 and repeat it three times. So huge amount of memory and CPU, and the router is DOS. All the other attacks, Neighbour Discovery spoofing, roguery, were local, because you need to SeND a Layer 2 packets. This one is removed. That's what was scary for me, that's a matter of implementation implementation what you need to do, put threshold, put maximum capacity, for instance allow only 100 v6 addresses per interface or 256 v6 addresses per interface. Allow only, let's say, 10 v6 addresses per Mac address. And this kind of thing. If you have one in interface you are receiving too many new addresses that you need to do resolution for, you only do 100 per second. And it's not enough, because we remember in v6 a neighbour is doing there is no traffic, from reachable into still and then in probing, OK, to see whether the neighbour is still there. It's not, right? Neighbour unreachable detection. We need to prioritise renewal above people from remote asking for resolution because we know existing addresses already into the neighbour cache were valid, so they were valid and need to be kept into the cache. Small of use stuff but it was not there in 2011 in most of the code, including Cisco code.
So we had issue here. And now we are doing this, and how many of you have an iPhone or iPad? A lot, right? Those devices, you know what, when they do. V6 count v6 address, you don't use wi?fi and your iPad goes into sleep mode, comes back you ask for a new address, privacy extension. So if you have an iPad and on a wi?fi network it comes up with 16 or 20 v6 addresses per Mac address, and so if you deploy your wi?fi network with iPads on it, most please ? those threshold because we really need to be sure that it's correctly.
Another way of doing it is basically when you are protecting a server, it's using plain old access control list. Look on this one. You cannot do this trick for everyone, but if you have a web server or your cuss summer a web server, very easy. You put a stateless access control list only working layer 3 and basically if somebody is scanning from abroad you only have a permit to one, so we will do the neighbour solicitation, advertisement, everything is fine, packets SeND to 2 and 3, basically are going to the bin and there is no NDDP process involved there so you are on the safe side, it's OK.
So 25 minutes of early morning about security, I guess your brain is already crying, so it's time to go for the summary.
Remember the sand castle, we have strong layer security. Roguery is the most common attack, mostly by misconfigured summon your network must be protected against this attack. Technique host is relation, if your network is suitable for this, be aware you need to get that proxy function. Secondly Neighbour Discovery, no way by implementation. And all those savvy techniques, the one I have described here, right. Getting by snooping the traffic, the Neighbour Discovery cache and forcing it, the binding. Neighbour cache exhaustion, that's a real issue, be sure to have read your code, resistant to this attack. And the good news if you allow me for just ten seconds display a commercial slide, it's exist, OK, in Cisco device and others as well. That's my point. It's not on all the device yet but it's there, so please use those features.
So I don't know whether we have time for questions, and if you don't mind, there are some advertisement for the book I wrote.
DAVID KESSENS: We have always have time for questions because that's the whole point of the sessions here. The floor is open for questions.
AUDIENCE SPEAKER: Benedikt. There is other reasoning you gave is OK, and when it comes especially to the remote attacks, I think it's very important, but unless I have missed something because I was a bit late, you didn't mention that there is yet another way, basically put machines that don't trust each other in separate networks. That's the most fundamental design you can use in a lot of cases, not in airport wave lans but it helps lots in ethernet based company set?up so that's something to keep in mind.
ERIC VYNCKE: Perfectly right, that's what I am talking about, host isolation, I explain it per host but you can get group of hosts easily,
AUDIENCE SPEAKER: The one thing to keep in mind here is we now have multicast routing so the one reason that really, really forced us to put machines into the same network, which was broadcast or effectively not working IPv4 multicast routing, that problem has gone so it really, really helps to solve a lot of trouble with pretty much minimum effort.
ERIC VYNCKE: Correct.
AUDIENCE SPEAKER: The previous speaker already said pretty much the same thing but I like to hear myself talk, it almost seems like it's a bad idea to be on the same Layer 2 network as someone who is planning to attack you, doesn't it?
ERIC VYNCKE: Yes. Absolutely. So you don't use wi?fi here, right?
DAVID KESSENS: Any more questions, remarks, things that need to be discussed based on this? No. Then it's now time for work in the IETF that's for operational security, Merike Kaeo will present that. And as useful the important thing is she wants input, that's why she had here, we are here to discuss these things, if you have questions, come to the mike and ask them.
MERIKE KAEO: Good morning. While they put up the slides I will introduce myself. And I am a Co. author with both Erik and Kieran from Google, in terms of a document called The Operational Security Considerations For IPv6 Networks. And we start this had document, all three of us have had extensive experience deploying IPv6 networks, to myself since about 2004/2005, you know Erik for quite a number of years and Kieran has done it within Google.
So why are we writing this? If you Google for best current practices, I mean you get a slew of documents and the three of us were looking at, I mean when people actually create an architecture their v6 networks first of all nobody thinks about security because they are still trying to figure out how do I get packets from point A to B and we are looking at all the work that has been done in the IETF and the other documents that are written by other people and going if there is somebody new that's looking at the point IPv6 and trying to figure out what to do, and we really want them to start thinking about security from day one, where do they go? So we started looking at all the documents that exist, it does make sense to write yet another document because things are evolving and with this one document we can provide a sanity check in terms of what are operational folks doing today, right, to actually secure their network architectures. And I was just actually looking at how many references we have. We have reference close to 60 RFCs that all have been written in the last ten years. Some of them do need updating, the process of updating takes forever in the IETF, so this particular document is for the operational folks, it's within the operational security Working Group, and because a lot of operational folks don't necessarily participate, we are coming to you. So one of the things that we hope to accomplish, Erik and I are here for the next couple of days, grab us in the hallways and tell us what you are doing because what we would like to do is make sure this document encompasses what people are practically doing to secure their network architectures.
And what does it cover? Very basically, it has a whole slew of stuff under the generic security considerations, and then once we describe those, we will also go into detail, into three specific use cases, enterprise, service provider and residential networks. And from the general security considerations we have split it up into the addressing architecture, why is it important? You know, some people get a /32 and say, yeah, you know, we are going to mimic what we do in v4 we are going to have a couple of /40s and create random addresses, Yahoo. Our recommendation is always take a look at your addressing infrastructure because as a comment that was made a couple of minutes ago, is you want to make sure that you figure out where are you putting your machines, why are you actually doing physical separation, and also it's going to help you in terms of your filtering infrastructure.
Control plane security, logging monitoring, general device hardening, link layer security, routing security, and the transition co?existence technologies. So those are the overall headings for them.
One of the things that we have really want is operator updates, and so we ?? the work was ?? we start this had a couple of months back, about six months ago, it was adopted as a Working Group item about a month ago, and I kept telling people don't read it yet because we want to fill in as much text as possible and then we want to get the feedback to say, is this what you guys are doing, is this still the best practice or have things changed because as you are deploying things you find that oh, that didn't quite work, or you know that's an operational nightmare, i.e. SeND. I mean are you going to use SeND because it's going to protect you against spoofing? Or is it such a nightmare that forget it operationally it's not viable. So specifically, we came up at least these questions that during this week and even maybe today I want to get some answers to. So specifically, is anybody using remotely triggered black hole routing and ?? how many using it for IPv4? How many of you using it for IPv6?
Oh, nice. I like you guys.
And then this one I am not going to ask right now, but or at least get an answer but one of the most effective logging mechanisms in issues to be resolved, if you are using NetFlow, use version 9 to get information on IPv6. How many of you are actually using it? NetFlow 9 has been out, I don't know, ten years, I remember giving a talk in it in 2001, 2002 but how many of you have deployed it? How many of you are still using NetFlow 5? Do you me a favour, later today come up and tell me about some of your deployments because one of the things is unless you actually want to get involved in the Working Group, which I would prefer, but I really want to find out what you guys are doing because from the logging perspective into the lot of detail is really known because nobody is too vocal about it.
Also, this question: Everybody keeps saying that absolutely rate limit your Neighbour Discovery and router advertisements, what are the timers that you use? Because I would like in the document not to say, yes, rate limit, because if I am still running a network I am going, great, but what should I use? Is the default good enough in my vendor equipment and, you know, we all know that the defaults are different in everybody's vendor equipment. So what do I normalise it to? So these are kind of the details that we are trying to get to. Also, is anybody actually using SeND and CGA? A couple of years ago I started laughing because this is really funny, Juniper and Cisco have SeND but Microsoft doesn't. Wouldn't you want it more on your host, do you have it on your local machines, your host machines rather than routers. And I started thinking through, I am like well, SeND ?? I will disagree with Erik because nothing is ever dead, if it's a protocol and somebody has an implementation, somebody is using it, maybe just in a lab environment or because they thought it was cool or they are bored or who nose what. But I am kind of curious, is anybody actually using SeND? Is anybody here using SeND in their environment. We believe nobody is, but I don't make assumptions. So I am going to go around and wherever I travel, I am is anybody using SeND? Probably not, but I want to be pretty sure about that.
So, you know, these are some of the questions. But what we really want is for people to do an?over all review, especially those of you who are or are deploying v6 networks. So, the top pointer here is the draft that got put up a couple of days ago, so we do want comments and feedback on this specific document, it's the latest and we feel pretty comfortable that we have a lot of points we wanted to.
The second pointer is to subscribe to the object Sec mailing list and I would encourage people to do. It's very low bandwidth, we want more operator input, and really, the best way to help move this work forward and some other work in the operational space is to actually participate in the mailing list. Also, Erik, Kieran and myself do follow v6 Ops and HOMENET, we have been on the Gert Doring's clue net list for six, seven years. We are on the mailing list. We monitor, we may not all be vocal but we keep tabs on what are people doing from an operational level so that's why we dethis work and decided to present it here at RIPE, I will probably do it at NANOGs and APNICs and going globally around the world, for this to be useful for other operators, we need to make sure that what people are doing today, in an operational environment, is what we actually accurately document.
So, that's it for me. So if you guys have any questions?
DAVID KESSENS: Answers or questions? No.
MERIKE KAEO: I figured out everybody does remotely triggered black hole routing, that's pretty cool.
DAVID KESSENS: Shell be around in this meeting so after this session and I am sure you can find her and give her answers because she needs answers.
MERIKE KAEO: Usually I don't like talking tech talk during parties but tonight is OK.
DAVID KESSENS: This is a Working Group, this is not a place where we are supposed to do just presentations, you also need discussion, input, whatever.
(Applause)
AUDIENCE SPEAKER: So I was wondering after the question what is using SeND maybe another question would be who here would like to use SeND if it were possible to them? That's not too many.
BENEDIKT: There is actually a reason not to use SeND or CGA, as far as I understand protocol, it's been sometime since looked in there. As soon as you use cryptography in any kind of way, you are requiring extra CPU, you are way more vulnerable to service attacks if, we combine the remote attacks Erik mentioned with SeND, we have a chance that our routers will blast the CPUs to the sky much faster than we do without SeND so that's probably one of the reasons why people stay away from it, aside from the key management issues.
DAVID KESSENS: Any comments, remarks? For or against that? No.
ONDREJ FILIP: Thank you. I am working at cz.nic and I have a presentation about another CP catalogue related to IPv6, so I would like to introduce the project we made.
So the project is called KATR, it's sort of funny name for Cheks but probably not for you, it's meant to be another catalogue for CPE, we call it routers because CPE doesn't sound well for us, whenever I say router I mean CPE, don't be afraid we are talking about big machines.
So, what we wanted to provide and honestly, the project was meant mainly for the local audience, we wanted to provide a list of capable, IPv6 capable CPEs, we wanted to give the end users the answer what CPE can they buy which will probably survive a few years for them. And also we wanted to provide some methodology how we test it so we really tested that equipment in laboratories so all the results that we are showing are from the real test we performed.
And also, of course, to make some compromising filters and last but not least we wanted to do some attention of normal users to IPv6.
We have some history of similar projects: We have been really for a long, long time trying to get into the IPv6 ready certification programme, we wanted to be a proof laboratory but those guys really don't want anyone other to join, so we were unsuccessful with that. I don't know why, I don't understand it, but the communication was really frustrating.
And also, we similar project on similar topic, we have DNS tester project, tested CPE whether they support or are ?? at least DNSSEC is sort of useable with them, so and that was crowd sourced so end users could download some software and test the router plus network.
What we do test and collect, first of all, the IPv6 functions, we test all of the author configuration works and other configuration, auto configuration not just on LAN side like a server in server mode, but also on one side whether it can work as a client, if the provider is sending those information. We show some small subset the large family of tunneling techniques so some of the tunnels. We test whether IPv6 firewall is available, it's just binary test, we didn't go deeper, it's just does it support firewalling or not. Nothing more.
IPv6 pass through, whether at least it's able to resend IPv6 packets and one final things if the device is able to work on network without IPv4, that's really interesting. And DNSSEC support, whether it at least to pass through information, the DNS information.
Also collect some other information related to the size of the device, whether it's mountable to the wall, if ?? what kind of ports does it have, what number of antennas and things like that, to make it for the end use sores more information than just IPv6?related things.
And again, we prepared for the IPv6 world launch because we made a conference the day for the local audience and we are always telling the guys, please if you buy any equipment, be sure that it supports IPv6 and always the question for us, and how can I know my device supports IPv6. So it was sort of attempt to answer this question for the end users.
We work in cooperation with Czech hardware retailer, Czech computers so not very globally targeted company and they sell about 150 devices, and about one?tenth or less claims that it supports IPv6, so we got 11 boxes and nine of ?? eleven box that declared support IPv6 but nine of them just practically did and they are from five different vendors. Here is the URL for the website and the website provides the things you would probably expect, first someone the review page so you can choose your favourite device and try to read all the information about it. There is also the explanation of methodology, FAQ, if you want to find it, there is methodology that we use for the testing, if you would like to verify something. We do, of course, comprise not multiple products, so you don't see it but some of the lines are darker, those lines where the products differ. And of course, we have a filter, if you want to really search some device according to some statistics like number of USB ports or whatever, IPv6 support, it's up to you.
So, what we plan with that, we would like to add some more devices, I said in the beginning it was nine devices tested currently we have ten. We would like to provide critical IP U, requested by some magazine so we are talking about it and I would like to have a broader cooperation with ?? make a sort of IPv6 tested ready logo, I don't know, how to name it. And they also ask us to provide automatic API for them so they could really check if the product is IPv6 ready to make it ready on the retailers' page. What we are doing, it's in Czech and English so if you are somewhere interested we can talk about it, thank you very much.
(Applause)
AUDIENCE SPEAKER: Jan Zorz. This time wearing a different hat of IPv6?ready logo committee member. You said that you communicated with IPv6 ready logo. Who were you talking to?
ONDREJ FILIP: I didn't lead the communication so I can't answer the question, I think we can take it off?line and discuss about it. We wanted to gate status of IPv6 proof for laboratory and my understanding of the process the laboratory approved new members to come in and we tried several times to contact everybody and we got some responses like we are working on that and but after three years, we suddenly decided to stop this project. Zorz the idea is that IPv6 ready logo is working on the specificication of the tests that will come out in November, but you probably, if you are doing the tests you probably have everything specified and everything done, am I correct?
ONDREJ FILIP: Possibly.
JAN ZORZ: It would probably make sense that we probably join the forces together and make something out of it that makes sense.
ONDREJ FILIP: Definitely and we really wanted this since the beginning, so ??
JAN ZORZ: OK, let's talk this over a beer, OK.
MERIKE KAEO: Individual. I just want to make a comment, I think this is really important work. The one thing that I find, and I do testing when I find time, and I actually did a couple of CPE tests, four or five of them, they are all IPv6 ready, yea, and we have a native v6 at home, friends and family, it's not something people can buy. I wanted to get CPE where I configure a /64 my LAN, a /64 my LAN and enable two v6 DNS servers and away I go. And nothing supported that. With the exception that there are a couple of CPEs that I could configure it but I had to configure the v4 for it to actually accept the configuration. So one of the things that I would request, because I don't want this whole chicken and egg thing with people going, well, no, the vendors don't really do it, everybody is using v4. So to get to native v6 at home it would be nice if devices could configure native v6 and be useable. So for all these tests, I would love to have a separate column that says you don't need to configure v4 to do it and you can do native v6.
ONDREJ FILIP: We do such tests, whether it works without IPv4 but I am not sure if that means supporting all the features you said so we can think about it.
MERIKE KAEO: It's very simple.
DAVID KESSENS: More questions, more remarks? No. Thank you. It's now Tom Taylor. He is interested in multicast and whether anybody is using that and especially it needs transition mechanisms, etc.
TOM TAYLOR: Just briefly, I work for Nortel for 34 years and after I retired I took up consulting just so I could continue a hobby of going to standards meetings around the world. But I have been working with While Way on transition techniques or tools for multicast, and we ran into this question of, well do operators really need them? So, basically, I have got a few questions to ask, just to see what requirements there are out there.
So the first question, the baseline question, is, does anybody run native multicast in their network? Yes. OK. That's a relief. All right. This is about the need for address mapping and NATTing and that sort of thing. Does anyone have to serve IPv6 only receivers during the transition period? That's not dual stack but IPv6 only. OK. I have got a couple of hands here. So, then, given that, do they expect to have to get IPv4?only sources, data from IPv4?only sources to those receivers? No. So, we don't need the NATTing, it looks like.
All right. This is network viewpoint. Does anyone foresee dealing with a situation where v4 multicast packets have to transit a v6 only network, or vice versa? I mean an example is DSlite. OK.
We can stop here. I will show just as a matter of interest, a tool that's just about finished in the ?? other than reviewing it, I haven't had anything to do with but in the MBONED D Working Group it's automatic multicast tunneling and that basically relies on Gateway in the isolated site, a relay in the source network and they managed to tunnel stuff across an intervening network as Unicast, but thank you very much, it basically looks like I can forget about the stuff I have been doing.
DAVID KESSENS: Thank you. Are there any additional comments, remarks, for Tom? No.
(Applause)
Let me go to our next speaker. Andy. And just for the record, that's Working Group so if somebody like Tom proposes something and he gets input about that, he is very happy about that, even if it sometimes gives a negative conclusion, that's all fine, we are here to work together.
ANDY DAVIDSON: Thanks very much, David. So, thank you for inviting me to speak about the ?? my views on IPv6 transitional technology and why NAT 6 must win. I present add slightly longer version of this at a v6 conference in Brussels and it was so delightly controversial that the conversation that followed after the presentation was much longer than the time allowed for the presentation in the Working Group, so I have taken some stuff out and tried to make it less controversial but I am afraid these are still my views.
So transitional technology. How might we define it. I think this is the definition from Wikipedia that I shamelessly stole: "Technology to facilitate the transitioning of the Internet from its initial and current infrastructure to the successor addressing and routing system of v6."
Quite a good definition but I prefer: "Crappy little hacks, necessary hacks, rather, add a new cost burden to the ISP, hurt the end?user's experience and disrupt the pace of innovation at content providers."
The problem is, I did actually say they were necessary because they obviously are if they want to carry on trading. But it's really important that transitional technologies if they are to be selected are a step, a genuine step to native v6, and that it's possible to simply sidestep transitional technology when v6 transport is available and that you are able to turn these things off, and turning off transitional technology is absolutely key. If we can't turn off the NAT one day it becomes technology not transitional, it becomes the new way of providing services.
So transition has to be temporary.
So I am going to look at a few transitional technologies and talk about whether they pass the test and use the features or have the features that I have described. And maybe starting with NAT 44444. I think that this certainly not transitional by any stretch of the imagination because you buy your carrier grade NAT boxes today and tomorrow and the day after, it's possibly your vendors' preferred solution but it certainly shouldn't be a service provider's preferred solution. And this technology does have traction and some receive wisdom that this could save the day but even if it can save the day and access ISPs, what on earth or hosting companies and hosting ISPs are going to do? The only possible outcome of this is more NATS and more boxes and more cost.
DSlite, does it pass the test? With this technology, when you boil it all down, v4 connectivity is possible through services, the service provided through NAT and v6 stays native and the goal is of course, that eventually dual stack content will exist or v6 native con excellent exist at some point in the future and it will all work but DSlite is non?deterministic, if you have a v4 NAT address and you have a v6 native address, where will it be routed? Always, are you sure? If you get both addresses back from a ?? from a DNS query or from a DNS query is it always going to use the native v6 where available? I won't repeat the word that Geoff has repeated at RIPE meetings before but certainly go and have a look at Geoff Huston's presentation for previous RIPE meetings about how different browsers and operating systems work because if you have a v4 NAT address your browser and operating system resolvers may certainly decide to use the v4 NAT aaddress over the public ?? over the native v6 address so even when content companies do what we have been begging them to do and have done with v6 launch day, the very likely outcome is more NAT and more boxes and more cost.
Does 6 RD pass the test? Here the ISP has to do extra work but only for v6 so as v6 traffic grows, you are adding more boxes to the access core of your network to cope with extra v6 work. So does adding more boxes and doing more work for v6 seem counterintuitive to anybody in the room? The possible outcome is loads of v6 relays and the complexity and cost. This part of the presentation is ?? the technology that Mark from Cisco presented on Monday was new to me and fascinating, sucks a little bit less because you start out with v4 access traffic from I ball users and you do an A and P?like mashing of the users IP address so that ?? you can basically retain state, if you have a customer's IP address on the port then you know that it's this customer using this slice of the v4 address and not this user who is using the other one, so you take a native v4 packet, you wrap it up in a v6 packet so that you can route it on your v6 aggregation layer and through your network to the edge and then you pop the v6 header off the end and it's a v4 packet again.
Better, but it still doesn't really address the exhaustion issue which is something we should be working about and I am sure we are, and the comments were made at the mike at Monday when this was presented, this technology is absolutely pointless without doing dual stack because it doesn't ?? it's not a transitional technology if people see this as a Band?Aid that means they can carry on using v4 forever. So, this is probably the least sucky of all of the transitional ?? or that offers v4 service with a v4 address. But there is still a risk you will need more boxes and I think there is a genuine risk operators will see this as a technology that will allow them use v4 forever.
So why is this so hard? Does NAT 64 pass the test? Well, here the ISP has to translate v4 traffic and v4 traffic is still growing today, and it's growing enormously, but what is the long?term view? What is the view of the future? And whereas a community of operators do we want to end up? With NAT 64, there is a flash point of NAT for all v4 traffic but no flash point of NAT for v6 native traffic. So, from my point of view, there is an incentive for content companies to make their content available via native v6 because if they want to avoid the squashiness of NAT and the, all the stat logic that ISPs have to retain and want to ?? and latency sensitive and customer?experience aware, because the end user doesn't get a v4 address with NAT 64 any time content is made available over v6 transport it will use the v6 transport. So this is the transitional technology ways genuine step towards IPv6. The best possible outcome is that in time, the NAT 64 state can be reduced or even turned off. Now, things break with NAT 64 which is why we are not all running it today. People who use IP literals in their applications so instead of saying I want to ?? I need your client to go and talk to this DNS name to go and get these resources, if people say well the content one dot 2, that stuff will break because NAT 64 relies a on a trick called NAT 64 to spongify where v4 content is available so it's forced to your NAT 64 Gateway. IP literals do break, end?to?end break and v4 only hosts do break but does that mean that basically all transitional technology is flawed? Well, no, it doesn't mean that, it means that we get the Internet that we deserve. So when we think about transitional technology and when we think about what we want transitional technology to do, more important than thinking about how the protocol can be clever and how to address every unusual case that is before us today, the thing that we have to consider when designing transitional technology is where do we want to be and where do we want the Internet to end up. And also the transitional technology if we are clever should provide an intensive for content companies and application builders on the network ?? on the Internet to make dual stack content because the transitional tech must say to content builders, if you make your services available via v6, then the sponginess that we have to do because we have run out of addresses because we have given them all to I don't know how, you look in the database, that is a genuine way to sidestep the sponginess, it means end users will be using v6 which is the end game.
So, from the faces in the room, I am not sure whether controversy was removed from the presentation. I would love to invite comments and questions on this.
DAVID KESSENS: Thank you for your presentation.
ANDY DAVIDSON: This is what happened before and it was really interesting.
DAVID KESSENS: I think you get what you deserve.
SHANE KERR: This is Shane Kerr, from ISC. So thank you for the controversy, it's cool. I am curious when you said that Map doesn't address exhaustion, I don't know what you mean by that exactly.
ANDY DAVIDSON: Ultimately, when your user base and subscriber base grows you have to either pinch more ports from users and spongify their user experience or if you don't want to do that you have still run out of v4. And if ??
AUDIENCE SPEAKER: I don't understand spongify.
ANDY DAVIDSON: You reduce the number of ports so they can't use more interactive applications.
SHANE KERR: That's kind of NAT, right?
ANDY DAVIDSON: Exactly.
SHANE KERR: In any kind of NAT which is what you need for this transition technology so I do think it addresses conservation in exactly the same way that any other NAT PT does.
ANDY DAVIDSON: It addresses conservation in the say that CIDR did it, it takes a number of addresses and means we use them more effectively by thinking in new ways about efficiency.
SHANE KERR: All we can ever hope for, I think. And I guess, just finally, you are a fan of NAT 64 basically because it adds pain? Right?
ANDY DAVIDSON: It provides an incentive to avoid pain. Quite a good incentive, I think.
SHANE KERR: All right.
LORENZO COLITTI: I think what Shane was saying is NAT 64 and Map do exactly the same thing regarding two exhaustions. So you can't claim an advantage of NAT 64 over Map on that point. What I wanted to say I would like to agree with you but NAT 64 is not deployable today, period. Cameron would like to deploy it and he can't because no manufacturer will ever ship a device that cannot run Skype. And that's even in an environment where our terminals churn every two years and the network is ready and 90% per Cameron's studies, 90% of the apps do support v6. You cannot ?? you cannot use an imperfect substitute to replace what you have today. That's just it. So, the closest thing is 464 but that's IPv4 of a carrier pigeon, you can't run it in lion networks. So I guess the question really is what ?? what would the band reconditions need to be for us to be able to deploy NAT 64, when is the breakage low enough we can say, this is fine? And I don't think we are at that today.
ANDY DAVIDSON: No.
LORENZO COLITTI: We might be able to think about when we are going to be there.
ANDY DAVIDSON: Exactly. And that's certainly a point that I want ?? more importantly than doing some advocacy for a technology that isn't ready today is we get the Internet we deserve and we if we want to take genuine steps towards v6 maytive end?to?end Internet in the future the transitional tech that we do needs to take account of that and I think of all of the transitional technologies that leave users with v4 address of some kind and that's important, Map is probably the one that will cause the fewest breakages because there is less state in places where you don't want State, but the point is, it's only a transitional tech if you can see the end point as well, which might be in five or ten years so this presentation is definitely about the long?term view, but it's so important that it's not used as a Band?Aid to carry on with the world we have today but with NAT. That's my point, the long?term view is the most important view if it's a transitional tech and we have to be able to turn it off.
JAN ZORZ: Now wearing my A plus B hat. The idea of A plus B was to give out the alternative to evil fat big stateful CGN, and Map is a stateless version of A plus B that, that well?defined and guys from Cisco developed further. Why are you suggesting that stateful solution is the best one to choose from?
ANDY DAVIDSON: This, again this is definitely the long?term view, and the point is that I think that if I was to pick a technology today because I needed to use one tomorrow that it would be Map but what I would like to see in five years' time is an Internet that can cope with NAT 64 for new builds, for example, simply because it provides the last bit of incentive that may be necessary to make a feature the one that we want. We get the Internet that we deserve. And stateful is bad, and pain is bad, but when it hurts you go and find something that doesn't hurt. Right?
JAN ZORZ: So we need to go back to the drawing board?
ANDY DAVIDSON: I think, like I say, I think if I was to pick a technology tomorrow, we actually have one in Map, even though I can't go and buy it, at least on the drawing board it looks good but only if it's deployed alongside dual stack, the only time it's going to be useful, you must turn this stuff out, it's not transitional tech, it's the new tech.
JAN ZORZ: Can you put in your slides at the beginning, stateful is bad.
ANDY DAVIDSON: Stateful is always bad, pain is bad. But there is a place for it.
BENEDIKT: No pain is good because it makes people change their habits. Two contradicting comments: First of all, a lot of people don't realise how extremely painful the lack of support for literal IP addresses or IP literals is; for example, if you try to build a zip phone on a micro controller that has about something like 16 kill bites of RAM, and those are the bigger ones actually, that's what I have heard from one of my customers almost ten years ago when it took about half an hour to cool down so much we could continue with the training, when I told him that IPv6 there is no NAT. OK, that was ten years ago. Or eight. Another thing: There is another kind of transitional technology that you won't find useful from an ISP point of view but from a business company point of view, because you have proxies, application level proxies in your firewalls and in many cases from ?? not the home users and not the ISPs but for the business customers, that's frequently the way to go because basically all they need is Internet and e?mail, all you need is a mail proxy and mail relay and DNS forward, OK. But that way they are almost sorted and a company won't use a protocol across the Internet they can't run through the firewall in many cases, so to them, this actually turns out to be a non?problem, in quite a few cases.
ANDY DAVIDSON: The only thing I would say to application gateways is probably SMTP fixup, as an example of how good ideas ?? oh, I have just said something nasty about a vendor's implementation, sorry. But as an example of how you can take a perfectly good idea and break it beyond use. ALGs are more painful I think than putting state in place where is NAT 64 does.
BENEDIKT: They are less painful if you have to use them anyway for security reasons and you get away with just using them and nothing else, then with using them and something else it's adding to the pain as well. So that's where things are getting different.
DAVID KESSENS: More the record, microphone line is now closed because time considerations but we can always discuss in the break with Andy.
AUDIENCE SPEAKER: Andrei. I think one thing needs mentioning here, the net 64 needs DNS 64 and DNS 64 by design breaks DNSSEC.
AUDIENCE SPEAKER: No, come on, we spent years on that. My name is on that. We worked so hard to not break it.
ANDY DAVIDSON: You see this is what I meant by controversy.
DAVID KESSENS: Both of you in front of the mic.
Ondrej: I should pass my next colleague to explain now DNS is ?? DNSSEC is not braked by DNS 64.
AUDIENCE SPEAKER: Co?author of DNS 64 and net 64. So basically, there are two things you can do: You can say I am the client, I know DNSSEC and I know DNS 64 and I do them both and everything is OK or you can say I am the client I know nothing, I ask the DNS server to validate, DNS knows DNSSEC, everything will be OK. The only thing it breaks is when you say I am smart, I know DNSSEC, but what is this DNS 64? This is not what I understand for so I am going to say it doesn't validate. Only that specific case that we think is uncommon will break. So, upgrade your host or trust your server. One of these and you are OK.
So, my question to you is, what you are basically saying is, we can't trust the host toss use the host toss use ??
ANDY DAVIDSON: We can't today. Maybe that's another way around the problem.
AUDIENCE SPEAKER: You think it will be better in the future?
ANDY DAVIDSON: Well, the industry has a great track record of moving towards solutions that are always the best and shipped on time and predictable and every platform and every browser.
AUDIENCE SPEAKER: So. Then when I heard Lorenzo say that nobody is ever going to ship a box that doesn't support Skype, this made me very sad because the way I understand Skype has always these patterns on that 44 traversal so what is their incentive to put themselves out of the patent licensing business, right? My question to you and the rest here; does this mean that IETF should start working on ways to make these literals work through NAT 64 because it's doable if you make the host a bit smarter, that it knows the other 96 bits and puts them in front of them and translate an IPv4 literal and IPv6 literal you bump some stacks, should be doable of course, nothing is ever easy but are you guys saying we should do that?
ANDY DAVIDSON: That's interesting. All ?? my conclusion is we get the Internet we deserve but that sounds like a progressive way to give us options in the future towards maytive v6 so I ?? I would like to see how possible it was and if ?? of course, if it works on paper, sometimes it even works on the computer and if it does maybe we have a way forward.
AUDIENCE SPEAKER: What ?? what I am here to say I don't speak on behalf of the IETF because that would be impossible, but I can tell you if you guys here are all shout we want this, and we heard at the IETF. So, do you want it, yes or no? Nobody cares. OK. IETF is not going to work on it.
DAVID KESSENS: The microphone line was already closed so I am sorry to tell that you because otherwise we run out of time. Shane is going to relay a comment that came in from the Internet and was already earlier on?line, so that's the reason he gets a chance to move ahead.
SHANE KERR: We missed this in the Jabber room but Mark Townsley from Cisco says that the stateless technologies like 6 RD and Map are designed ?? they can be run inline with the edge routers that are handling egress and ingress traffic for the site anyway, unlike stateless technology and even NAT 64 you couldn't need to add a bunch of special purpose boxes.
ANDY DAVIDSON: I think that ?? well, the way that v4 traffic continues to grow today, it doesn't address the exhaustion issue. So, I mean, none of these technologies are perfect because none of them are called native IPv6 is my opinion, there is reasons to like and dislike all of them, and I think ?? I really like Mark's work on the Map stuff, I think that has got the most feature?proof approach to this turbulent period that we have entered.
SHANE KERR: Speaking as me, not Mark, you don't really want future proofing though, right?
ANDY DAVIDSON: I would like native.
ERIK KLEIN: I applaud your focus on supporting an IPv6?only environment. Also, your focus on the end end game, and if there were a NAT 64 IPv6 only Internet service available to me where I live, I would buy it and try it.
ANDY DAVIDSON: That's an interesting perspective. Thank you. The end end ?? if we have run out of v4 in Europe so if we are frightened of how having the conversation about the end?end game, then we will never get to that point.
ERIK KLEIN: As long as IPv4 is available to the host, something will use it.
ANDY DAVIDSON: Thank you, everybody.
(Applause)
DAVID KESSENS: Thanks, Andy for this thought?provoking presentation. Now it's time for Martin for the IPv6 deployment survey.
MAARTEN BOTTERMAN: Good morning, everybody. That was an exciting session, I am to report fourth successful IPv6 survey and these are results show change will not be as dramatic as the session we just have.
Really, this is the first time that the conclusion of the survey can be that IPv6 is becoming reality. This is reflected in the responses we have and I will show those. On the survey, it's, as I said, the fourth time. It was based on survey that was already done by ARIN even longer ago, and has been rolling out worldwide, and every year we ask the question like: Hey, do you think it makes sense to do it again next year and last year they said yes, more than 90%. And lo and behold they said it again, nevertheless I think when you see the results you will find that it may be that next year is the last year and just to confirm the trend that we have seen today.
So, I am just focusing on those where difference shows. If you download the presentation, you will find also some other slides that just are behind there and show that there is no changes, but if you look to what percentage of your customer base uses IPv6 connectivity, you will see that various ?? 60% didn't Tuesday at all in 2010, that's now only 35%. You see there is a clear progression and if you mirror this picture in your mind, then you see the error going up because it's true now, 65% of users does use some level of IPv6.
Another change that happened is the biggest problems with IPv6 in production, lack of demand is still there. Nevertheless, we do see that it's not only preparation that happens but it's also experience comes up, fewer people would say that experience is there.
A similar arrow that should have pointed the other way is when we look at organisation of IPv6 presence, and the no answer has reduceed from 36% at 2010 to 27, now to 24 percent so also there you see that the trend goes up even though the arrow goes down.
So, the other thing is, how considerable is it? Do we have a little bit or does it become more considerable and what we do see is that from 2010 to 2012 that IP version 6 traffic is becoming naturalable overall. Clear trend up again and I love it that you think this is funny.
Good. Now, new in the survey this year were questions about Internet Exchanges and carrier grade networks, and the 55% that said that they contact access, only 20% do does not do that in IPv6, half does it in both, with all the access and as you can see this has become quite normal.
Now, on carrier grade networks, from the people that responded to this question, you see it's a considerable number that still does use carrier grade networks, and in those, the response is that by far most don't do it instead of IPv6 but next to IPv6. There is no trend on this because it's the first time this question was asked.
Now, in terms of implementation plans, it's an overall picture, don't try to read it. This is the line by line indication where people indicate whether they do it already, that's the first green part, or whether they plan it or the red part at the very end is where they don't even plan it. As you can see, that the change isn't that big here, and I think what we saw over the years of development, that it was particular this graph where most was to be seen, where people did step up and started implementing it, to be prepared for whatever the future would bring. I would think that this is stable by now and it's indeed mainly the conclusions that it now has really hit all those participating to the study and it is becoming considerable.
So, what of the things that didn't change is the trouble that you get when implementing IPv6. 60% still says that's with vendor support of IPv6, and that may be a surprise too, that even after those years where the development progressed towards being prepared and we now really for the first time see a real take?up, reflected in the survey, that these things don't change. Something to pay attention to.
So, having said that, this survey was made possible by the NRO and more than 1,400 respondents from all over the world participated, great thanks for that. Our current thinking is that maybe last year ?? next year will be a last time to see whether the trend that has developed now, is setting in. So thank you for your attention, I am happy to answer any questions on this.
DAVID KESSENS: Okay. We are now officially in break time. Any questions, remarks, comments? No.
(Applause)
AUDIENCE SPEAKER: A very quick one. Who was the people who responded or who did you target? I am just wondering because obviously if it's mainly people who were involved in the IPv6 side, then you will get a skewed response, if you see what I mean?
MAARTEN BOTTERMAN: Yes. The responses came from people that were all invited via the RIR mailing lists and about one?third was ISPs, and the others were other parties. That hasn't changed a lot over time so in that way ?? several years in the row are comparable in terms of population.
AUDIENCE SPEAKER: Thank you.
DAVID KESSENS: One final remark because we close the session: We, as Working Group Chairs also felt a little unfortunate that we had this meeting in parallel with the Address Policy Working Group session. We are working to make sure that won't happen again. This is the end of the session. Thank you very much, see you next time.
(Applause)
