IPv6 Working Group
11 May 2017
4 p.m.
JEN LINKOVA: Good afternoon. Welcome to IPv6 Working Group. We have, again, busy agenda so I'm going to skip all this administrative stuff, and just remind you that please rate the talks. So, next time we'll try to build a more interesting agenda for you and we were just discussing how many buttons this device actually needs. And there is an opinion we only need one to move forward, because there is no way back. And by the way, our first presentation is going to be that there is no way back any more. Right Martin.
MARTIN LEVY: Dramatic pause ‑‑ they say start a talk with a joke, not me, so I tried the other one. My name is Martin Levey I am from CloudFlare. I am going to talk about this subtle thing that's been in the CloudFlare user interface for quite sometime. I'll get and show you what that is in a moment. But I'm also gig to give you a little bit of a background of what we have been doing, some statistics and hopefully something that's useful.
So, CloudFlare for those people that don't know content delivery network, we span over 113 locations, and the key point is that we deliver v6 from everywhere. And that's sort of a very key point about what we do. We have some nice statistics, but this is as simple a marketing slide as I could get. But what I want to talk about is this background about what we did with this thing called the IPv6 switch within our user face and then show you some of the data based upon some changes that we made.
I'm going to discuss DNS. This is sort of going to be the wonderfully controversial part and then the final part is the key part of the talk about what we're going to remove the switch.
So, first of all, to remind people of what we do, we have the ability to deliver, as a content delivery network, independent protocol. If you have an IPv6 only client or at least a client that truly wants to operate in a v6 only environment, then they can still access a v4 origin because we can do the translation either side of a content delivery network. I think when we started doing this we were fairly unique but I hope that a lot of other content delivery networks can do the same thing. But we have a switch. And we have a switch from very early on. And the switch has the ability to be off or on. And when it's off, that simply means that we don't provide a v6 address to the destination. If it's on, then we provide both a v4 and a v6 address. So when you turn it off, you are not only unable to provide a v6 address, but quite frankly, you are, let's say, backward compatible to a time long, long, long ago and so the default for this switch, because this is the way you think when you do this many, many, many years ago, is the default is off, and so we wait for customers who want to be innovative and move forward to turn the switch on.
Well, if the default is off, you don't get very far. But now we have changed it to be the default is on and I'm going to walk you through that story and what the consequences of that was.
But, with we made one other quick change to the switch, the first change to the switch, which is if you go from on to off, we now throw that up on the screen. Which we simply say you have heading into the dark ages. You are going backwards. You are simply doing something you possibly shouldn't do. And this sort of works only to a certain extent. But as you can imagine, not enough.
So, we wanted to flip the switch. We originally built in a conservative manner, as I said, the switches, the default is off. So we wanted to make the default on, and we wanted to turn it on for every domain not only new but also the old domains, the ones we hadn't touched. So, although I don't really pull it out here, we had actually made the default on over a year ago, maybe two years ago, and that was proceeding, we still had people that were encrypting the switch one way or the other, but there were these millions of zones prior to that that had joined us and had not ever looked at this. So, the algorithm is actually very, very simple. We look at every single zone. We say is the v6 switch off? If it is, when was the last time that they touched that part of the user interface, because the whole user interface is transactional so we can look at that, and if they had never touched that switch, we made this big assumption: You haven't thought about v6, or you haven't thought about being v4 only. In fact you have come to us even though you may have turned up a zone with us, a domain with us many many years ago, you haven't thought about v6. We are going to flip the switch for you. Because you didn't think about it for the last couple of years you probably won't think about it after we do it. So the algorithm of course updates the date in the trust anchors log as whenever we did it and moves on. Now we slowed down this a little bit because we started actually quite at a slow rate just to make sure we were working. But we basically upped it to around about 100,000, 110, 120,000 zones per day. Now we had 4 million plus zones to go through, so, it obviously did take a while.
And people noticed. And this is quite cool because we weren't ready to announce this. We weren't ready to talk about this. These are well known people. One of them are the least is in the audience. But basically, this is sort of midway into the process. So let's look at err's graph because we might as well. This is what we did to the Alexa million. So the Alexa million is queried everyday by Erik, he looks at the number of AAAAs and As and as you can see we seem to have made a rather large difference. By the way there are some other bits that we worked on which we of I'm skipping. We tried different ideas ahead of this massive change.
But it changed. And more importantly, it stuck. We actually have an environment where basically there is a large number of domains that we have enabled for v6 and no one has complained.
So, I'm give some stats and I'm going to talk about these stats with one caveat. These are the stats that we measure. They will be different to what you measure or somebody else measures or Google measures or whomever. Everybody's stats will be different. So we get this wonderful sort of percentage of v6 graph that goes, goes up. This was good we wanted to see this. And then we wanted to find out what was actually driving it. And again looking from our point of view.
So I'm going to pull out a few countries, Belgium has already been in the news today. So, we sort of see some nice high percentages there. But the one that's at the top of the list is Ireland and we know some of the mobile operators there and some of the broadband, we couldn't work out what was going on and then we actually realised that there is a very big user that isn't in Ireland but gets attributed to Ireland. And that's Facebook. So Facebook actually accounts for a very large amount of query as if it looks like eyeballs, in other words it's crawl, it's when you place a page on Facebook, hey look at this cute link of a cat or something important going on. And those queries are coming out of all around the world but they are all registered to Facebook and when we have this sort of methodology of using RIR data and Maxminds and other data, to understand where something is you can get these interesting spikes but there is one stat that's rather nice to know. 80 plus percent of our crawl from Facebook is coming over v6. There are a very biased happy eyeball environment. They definitely put a lot of effort into being v6 wherever possible. And what's interesting for them is that they have actually provided us a clue as to what websites are not v6 and we do still have some and I'll talk about that.
We see some nice jumps in Japan which is good to see. This is actually ‑‑ I mean one of the many countries that it's good to see this happening.
Anyway other people have talked about stats but I want to talk about this one particular stat. This is an X Y graph of the amount of bandwidth. So as you move towards the right, your right. You are seeing more and more bandwidth as you go along. As you go vertical err seeing a higher percentage of v6 traffic. And in fact there is a couple of players that literally sit at a hundred percent, if I was in the Routing Working Group, I would actually go and discuss this further, but this is a lot to do with how people aggregate their routes of their mobile operator sitting behind their IP global backbone or a country backbone where sometimes they are aggregating the routes and announcing them from their mobile AS number or sometimes from the AS number in front. So we have to sort of play around with stats a little bit and group ASes together. We learnt that. But you'll see people like sky in the UK right there, and virgin in the UK right there. Anybody from either company in the room? Because there probably is only one of those companies in the room.
So, we see others, we see Time Warner cable. AT&T non‑mobile and mobile. Comcast is out here with a large amount of bandwidth and that sort of percentage of v4 versus v6. So we were quite happy to see this, there is Facebook up there, again as I said predominantly if not all crawl traffic. And we'd love to call‑out some of the networks at the sort of the near zero level here, but you see this. We put this on a blog.
So here is some other numbers, I am going to run through the rest of these numbers because we have all seen stats and these slides are online on the website so look at them. The usual players and percentages. Here is some of the ones that actually ran in the hundreds. Of course, the China next generation network is in fact a v6 only network so it better with a hundred percent. I'm talk about what's going on in Taiwan, in a little bit, here. As I said the usual players you are just looking at them in different ways.
Device type.
This probably makes the most sense. That getting to see the mobile operators with mobile devices coming up high seems to make sense. IOS versus Android. There is a statistical difference, but at least we have the numbers, hopefully these trend higher.
One person in the audience understands why this is and has the back story, but you know, the phone, the phone, please.
And let's talk about a couple of other things. We look at flood traffic which occurs between v4 and v6, and again wow the numbers for v6 are lower on this one but that may not be a bad thing, okay. Percentages wise, I actually thought that DNS should show up as a higher number because DNS is one of the easier thing to do over v6, but there is no bias between v4 and v6. We provide an equal number of authoritative DNS servers in both protocols. So maybe there is something else going on there.
We played around with this stat for a little bit here but just looking at unique addresses and trying to understand what's going on with DNS in that space, but you know, it's just a set of numbers.
A couple of maps. The map seems to make sense. We see the AAAA queries, queries for AAAAs coming from the appropriate places. We seem to see the percentage of traffic running over v6 coming from the usual suspects, the usual countries. So that's good. We have got fairly broad with this many domains, we have a fairly broad user base. And then there is this.
Who here resource A 6? Keep your hands up... now put your hand down if you never had anything to to with writing the RFC.
Yeah, come talk to me!
Because why should there be any A 6 traffic queries left in the world at this point in time? I mean, I hope the majority of you don't even remember why A 6 existed. And yet it does. And it shows up in various places. And it shows up for one place bigger than way somewhere else. Somewhere in Taiwan there is literally one machine and the number of queries is statistically relevant and I so happen to be going to pie within an in the next three months and I intend to visit the person running that network. It is the research network which is an acceptable excuse for certain things, but not for this. So we actually went back. We couldn't work out what was going on, we thought they were scanning all the query types. So, they are just like you know, an networks map for query types. No, not even close, it's just A 6. So, old things never die. We don't know why. Sorry, I missed a key point. Sending e‑mail to the operator of this network of course went nowhere. But that was the law enforcement guy, a different talk.
So what's next? So we're going to talk fairly quickly on something that we're going within the IETF and we're pushing for some changes to DNS. Why DNS? It's very simple. If you look at happy eyeballs and believe that this is the way forward, and it is, and we look at the methodology, there is one staringly obvious problem. You have to do two DNS queries. You have to query the A record and query the AAAA record. You then can initiate a TCP connection and you delay obviously the v4 and you let the v6 go out first by a few milliseconds. Your number may be different than mine, but you get two answers back. So the answer is area redoing this? And there is wonderful historic and very good reasons why we did it this way, but that was then and this is now.
So, we have been talking to a lot of people. We have been ‑‑ I'll talk about the drafts in a moment ‑‑ but building one of two things. A met a query that returns two values, an A value and a AAAA, so give me the value and I don't care what, which protocol family. Second part is, I want to query an A record because that's what happens and we turn around and do a come Inns key attack and say by the way here is a AAAA report for you as well. If you think about it that is the attack but the good news we can wrap this with DNSSEC and maybe if the DNSSEC is correct you can move forward. So we wrote ‑‑ well two things. I'm missing a part. We have implemented both of these. The first one you can go play with right now. We have got a high type number. This is how one does it. You can dig into our DNS server and get back the values back there. You can try it both with CloudFlare or some other domain is on us. If you don't like Tailor Swift, Moody Blues, you know, there is a whole bunch of different ones. Here is a local shopping domain, here in Hungary. But it works with all domains. Of course, we don't expect anybody to be querying with that type. So there are ‑‑ there is a draft or so for the AAAA record and that code is much more complicated because we do not want to send those responses back. There are three different people that have thought this problem through for different reasons, and these are somewhat similar but subtly different, I hope as we go through the IETF process one of them gets picked. Hopefully ours, but I have a feeling these are going to come into somewhat the same.
And we are building sort of a test network environment for this. And hopefully this, in our measurements it definitely speeds up the ability for happy eyeballs to pick v6.
Okay. The key part, the last slide. This is so obvious in this day and age. But it actually takes a long time to get to it. There are wonderful support, operational issues, but basically this is what he have done. We have taken the v6 switch that I showed you earlier and we have replaced it with nothing. We have removed it from the user interface. And this means that as we go forward and this is not been enabled yet because the switch is still there, but as we move forward, a vast, vast majority of domains on us will simply not have the ability to turn off v6, because in this day and age we know it works the in this day and age we know that we can go this route. I have to stop. But this is sort of the culmination, so to speak, of the make everything v6, both encrypting the switch and then removing the switch afterwards.
That's me. I'll take questions.
(Applause)
AUDIENCE SPEAKER: Matthew from Amazon. Just curious, I get the point taking away the switch. Do you think people will use it though if a lot of these people don't have domains that they haven't thought about v6, will they ‑‑ I mean, you could have it there, because I guess I look at it in terms of ‑ the other option is they move to a different CDN which has that switch if they find v6 doesn't work for them or whatever. Are you better off having a ‑‑ leaving the switch there and going hey, if you use this, you know, give them some help, give them some love, find out why because finding out why might be really interesting.
MARTIN LEVY: Yes, we can't revolve it without that information. And that will be probably when we remove it we will, as most people know, we rather blog prolifically about what we do and that data will go in when we have it. We have got the initial data. We know out of, I think it was 3.9 something million zones that we had left, weren't ‑‑ that had the switch turned off from the beginning of time that we encrypted on. And we have ‑‑ we have the data on how many have then logged in and said what happened? Flip it back. And we have that number the it is statistically small. It is trivial. But we have also looked at why, and we do have some customers flip it on, flip it off, flip it on, flip it off. Come back later, flip it on, flip it off. What are they doing? Why are they doing this? And so, it's a very big business intelligence process to actually go find them, and that's the data that we absolutely onus get before we do that final step of turning it off. Because that's the responsible thing to do. If people don't want v6, go to another CDN, I'm not meant to say that am I? Don't go to another CDN, learn why you want v6 and move on.
AUDIENCE SPEAKER: I love forward to you visiting these people personally and doing a video blog.
MARTIN LEVY: Yes...
AUDIENCE SPEAKER: Lee Howard, retestify a. So, again thank you. Always love to hear what you are doing next. My guess on why people flip it on and off is they see something strange on the Internet and want to end their trouble shooting by twiddling knobs they don't know what they do. On the happy eyeballs and A and AAAA requests, v6 ops Working Group has adopt add draft by using happy eyeballs, there may be interaction there is we might want to look at, I have not looked at the better actions between the three DNS drafts and the happy eyeballs. Still, there is a lot of work to be done on next edition of happy eyeballs, we don't know yet which way to go with T input requested.
MARTIN LEVY: I'll take that back. That makes the trip worthwhile actually, if you know what I mean.
JEN LINKOVA: Thank you Martin.
JAN ZORZ: Okay. I will do the sort of like lightning talk. This was the thing that we have been talking in the BCOP Task Force on Monday and promised to bring it in front of the IPv6 Working Group so you guys can check and girls can check the technical validity of this document.
This is the documentation of the current best operational practice, how to deploy IPv6, specifically how you should choose the size of the prefix for your customers and how to delegate it.
So, actually making the wrong choice when you are designing your IPv6 deployment may lead you into sort of crazy trouble later, because people think of v6 out of v4 knowledge. You need to unlearn your IPv4 in order to deploy IPv6. And IPv6 we have less problems with space than in IPv4.
So, I have been travelling all around the world talking to all the operators, well lots of them, and I hear all over and over again the same question: When we deploy IPv6 for our residential customers and business customers, what is the advertise of the prefix that we should choose? And they completely confused with /48, /56, some of them do /64, some of them ‑‑ they are doing all sorts of stuff. And also, they are confused with should we delegate it statistically or should we follow the practice from IPv4 when we were changing the IPv4 address?
So, we decided to put together a good group of good IPv6 experts and also operators and write this down once and for all, so we will not have to explain this all over and over again.
So, as you see here, these are the authors. We have pretty much from telecom. There is quite a number of people from the operators. For example, Andrew Alston, from Liquidity Telecom. He actually deployed IPv6 in Kenya and other African countries and started doing it dynamically and then he figured out that things are breaking for him, so he went to static and fixed the whole thing. We have a whole bunch of really really good people here that contributed to the document. So draft version 1, I presented it last RIPE meeting. You could get it here. I just checked yesterday, I keep one month worth of log files, and just in the last month, 909 people downloaded the PDF with the first version of the draft. That's quite a good number. Lots of people read the draft and we got lots of feedback.
We got also a number of comments at the BCOP Task Force meeting or ever a, so we promised that a bunch of authors that are present in this meeting convene on Tuesday and dot editorial cycle, do the language pass and then publish the second version of the draft. We published the second version of the draft. You got it all on the mailing list today at 2:44 a.m.. just after the whiskey BoF.
And here is the approve proof. We gathered downstairs in the bar and did the editorial and changed and addressed the majority of the comments that we received.
Right. Fairly quickly. Table of the content. What we added and what is the big changes is the executive summary. Because we figured out that lots of people will not read the whole document. They will just read the first page so we wanted to put all the very short information what's in it on the first page. I wanted to call it conclusion and start with the conclusions. But then I have been told that executive summary sounds better.
Then we have introduction and insentivity and then we discuss size of end customer prefix assignment. First we go into the numbering the WAN link. The link that connects the CPE to your network and here we discuss different ways how to number or not number the link. You can use /64 prefix out of a dedicated pool. Some people use unnumbered for unknown reason. But they do. Some people think of using ULA and here we also explain why this is a bad idea. Then some people use /64 prefix out of the IPv6 prefix that they assigned to the end customer. There are some problems with that. Generalically it should work but when you are deploying your network and if you are a pragmatic, then you don't go with things that should work because then your help desk will burn it down in flames. And in summary we give a sort advice which way to go in which cases. Then we have prefix assignment options and we discuss /48 for everybody. We discuss /48 for business customers and /56 for residential customers. We explain why less than /56 is really really really bad idea. And also we have considerations for the cellular operators.
Further, the second part of the document we discuss end customer prefix assignments, persistent versus non persistent. It took us quite a long time to choose the wording. We had static, dynamic, stable, non stable, at the end, thanks toly and Jordi we came up persistent versus non persistent, we thought that this explains the whole thing. And then we discuss why non persistent assignments may be perceived as easier, then we explain why you should not do it. And then we explain why persistent prefix assignments are recommended.
So, as I said, if you did not read it yet, here is the link. You can download my presentation right from this slide. Read it and we are eager for comments. These are the acknowledgements. Many people commented, many people gave us their suggestions, many people expressed their support. I think there was none that expressed lack of support I think. So, that part went good. And I would like to thank IPv6 Working Group community and IPv6 Working Group working chairs for the support. And with this, I would like to hear some comments, suggestions, ideas, maybe the way forward?
Anyone? The aim is to publish is as a best current operational document together with, as we did it for the help desk document.
AUDIENCE SPEAKER: Natalie RIPE NCC, you are thinking of giving it a RIPE income again?
JAN ZORZ: Yes.
JEN LINKOVA: I will just was told that it's better if people with questions go to the microphone, because the camera looks that way.
AUDIENCE SPEAKER: Andrea, Sisnet. Thank you for thanking me in the comment. I don't think I made any significant contribution but I am just saying it's a good idea, but it's great to read my name there. I would like to ask whether you are willing to continue in this similar fashion when some similar document? For instance I think that the other question that I keep being asked about IPv6 is how do I address my LAN network in my corporate environment like how do I identify using Mac addresses because this is what I do and I want to do it like that and I have my reasons and I want one address per machine and so on. So some document that says that this should be done this and other way and so on.
JAN ZORZ: So, the answer is yes, absolutely. We have the BCOP Task Force that aims to gather these questions and start all these questions and then if it's IPv6, we bring it here to IPv6 Working Group, if it's DNS we bring it to the competing one on that side. Now it's DNS Working Group on that side.
JEN LINKOVA: We are not competing.
JAN ZORZ: Timely competing. But for example now what's going on, Sander and a couple of other people is working on the IPv6 for enterprises document. On Monday we just accepted a few volunteers to start with Sacha Pollok the IPv6 prefixes for hosting providers, so how to address servers, how to do stuff in the hosts environment, operationally, not philosophically, how we do it in real world operationally. If you have other ideas or suggestions, please come forward, more than happy.
BENEDIKT STOCKEBRAND: Enter a nitpicking mode. Talking about less and more when it comes to routing prefixes is a bad thing, just make them longer or shorter because otherwise it just creates a hell of a lot of confusion. But this really is just nitpicking.
JAN ZORZ: The authors are in the room. Jordi or Sander can you take notes please? Yes, I agree for the record. Anyone else? Is there an agreement in the room that we are nearing the ending or ‑‑ we should solicit for feedback for a couple more weeks on the mailing list and then ‑‑
JEN LINKOVA: Working Group last call, right?
JAN ZORZ: Yeah, so, we got one comment on, in the morning from Michael, and I think we will address that fairly quickly because there are fair comments.
AUDIENCE SPEAKER: Jordi Palet. Because it mentioned the last call. Just, if you have some time this week or early next he's week please go through the document. Provide the inputs because next week, well after next week I am presenting it at LACNIC, and I would like to have there, if possible, the almost final version. Okay. So even if we have not done the last call but it would be nice to have all the inputs by then. Okay. Thank you.
JAN ZORZ: At the same time I will be presenting it at Slovenian NOG. An AFRINIC later. Thank you very much. I am not leaving.
(Applause)
So, the next thing, you are not getting rid of me. Sander and I would like to talk to you about basically about the tool at the end that we built, but let me tell you a story of what happens when I get bothered in my lab. I'm still running the institute. For the record I work for the Internet Society but I still run GO‑SIX and G 6 lab, that's the IPv6 lab in Slovenia and then I do all sorts of experiments. I travel around the world and when I hear the same question over and over again I go and test it, right.
So I heard lots of people is deploying IPv6 on mobile phones, and they are using NAT 64 and there is people that is thinking also for using this to make land lines IPv6 only, and sort of provide v4 as a service and translate to v6 and back to IPv4 and access the IPv4 content from IPv6 only network. So I said, okay. Let's have a look into this, how this in reality works.
So, what is the problem statement and real world status? Let me walk you through all 6 degrees of inner turbulence that I have. IPv6 and IPv4 are incompatible on the wire. Thank you Randy for this quote. It is what it is. So we need transition and translation mechanism between the two protocols. Fill solvically we don't want them but they are there. T‑Mobile USA is running around 52 million devices, 52 million phones on IPv6 providing access to IPv4 through NAT 64 XLat. So I was wondering how this thing works.
And I also was a little bit suspicious that some people does weird stuff with their AAAA records and I will show you what these people do. And two important questions came to my mind: Do content providers know how their content is being seen from different environments? And on the other hand, do connectivity providers know what is their user's experience when they provide IPv6 only with translation option, do they understand what breaks? Because lots of mobile operators ask me, do you have any standard set of test tools, do you have any standard set of whatever that we could go and test and see if this is ready for production and the user experience would not break?
So, I went and explored it somehow. First of all let's get this out of the way. Credits, acknowledgements, I would like to thank the Internet Society to dedicate lots of my work time to do these experiments in my lab sitting in Slovenia. Go6 institute provides the environment, the hardware software and everything, the lab environment. Then Sander Steffann, he is sitting next to me, and core in, his girl friends, does the design of the tool that's what we will talk about later.
Okay. What did do first? I set up a NAT 64 device in my lab. And they are aimed at everyone who would like to test NAT 64 and DNS 64 remotely. So if you are IPv6 anywhere in the world, and you follow the instructions on the Go6 labs page you can test T you switch off IPv4 and you start sending IPv6 packets to my lab in Slovenia, they get translated and you can see IPv4 content. How does it work. I am using globally routable IPv6 prefix as a NAT 64 prefix. So if you set my DNS 64 server as your resolver and you ask for a name that has just A record, then my server will synthesise also the AAAA record with the NAT 64 prefix that is global and IPv4 address and hacks and that will be the destination that will lead the packet back to Slovenia into my lab and towards the NAT 64 translation device. So people is busy using that. There is lots of traffic. So that's why I see all these problems that are happening. And the aim is to, for mobile operators to test, not the performance because it's a long way to Slovenia. But to test the functionality. And we are running four different implementations. We have four different instructions how to direct the traffic there and is used by lots of people to test stuff.
There are the instructions. If you go to Go6 lab dot SI they are written in I can't think Yanglish, or English, however you want to put it. This is the copy paste. This is the screen shot. So here is the explained how it works, and here are the instructions, so we have A 10 network. PaloAlto firewall, I have two of them, we have Jool, NAT 64 implementation that is running. If you set your DNS to this one, then it will send traffic to this one. And we also have Cisco SA R1 K sent from Cisco. Interestingly enough, Cisco is using this DNS for their Cisco live conference and when there is a Cisco live conference the temperature in my lab goes up a little bit, I tell you. You saw that.
SANDER STEFFANN: I was a bit surprised to see that I was Joe located to Slovenia for some reason.
JAN ZORZ: This is the hardware. This is not something virtual. This is the hardware. Sander calls this a systematic chaos, so this is the hardware that is supporting this testing. If you want to test NAT 64 go ahead.
So, we have been running this set up for quite sometime now and then we started seeing in the logs that where things are going on and people started complaining, started sending me e‑mail, this doesn't work, that doesn't work, etc. Right. And then I started to investigate a little bit. And you would not believe what kind of crap people put in a AAAA record. This is the enemy inside.
People put in: : Yes this will work : : 1, yes, you are talking to yourself, get help.
: : fff and IPv4 address, right. FE 80 and some will value. 64 FF something. Oh this one was surely copy pasting. 2001 db8. Not going anywhere. And then of course, this breaks NAT 64. If you have dual stack, it would work because the happy eyeballs would just say, we will use IPv4, but if you have NAT 64, DNS 64 will actually receive a AAAA record and will not synthesise the record and translate. To this people is dead. They don't exist on IPv6 only or NAT 64 world. So they cut themselves off the IPv6 Internet. There is lots of people that does that and Dan wing is doing some AAAA stats with all these anomalies inside. Go to this link and see what people is doing.
So, at this point, this was sort of like breaking all the illusions moments for us saying oh NAT 64 solves all the problems, hunger and everything in the world. For example, these people has the host is www.first insight dotcom. And then if you ask for host for first insight dotcom the IPv6 address is : : Wow, and no v4. Brilliant.
Okay. So if you want to build something, you need also to break something usually. So what can we do about it? Right. We can talk about it. And do the naming and shaming and send e‑mails to these people that broke the AAAA records to fix them, if they broke the AAAA records they also probably broke the AMS‑IX records so what's the use, sore we can figure out, if we are running a network with users, we need to protect our users, we need to protect the users experience AMX) remember, if you are not part of solution, you are part of a problem, it always has been like this. So I went looking into this and I realised that okay, if the 2000: : /3 is a global Unicast address pool assigned by IANA, if a AAAA record is outside this, my DNS 64 server should just ignore T because it's not a valid one. And I started experimenting. And I found that in BIND 9 ‑‑ of course none of my presentations can go without some configuration code, right ‑‑ in BIND 9 I figured out that in DNS 64 clause, you can go exclude 0:: /3, that's the first part. Then 4000:: /2, 8000::/1 and I also excluded the documentation prefix. This means if you ‑‑ if DNS 64 server receives a AAAA that is inside anything outside the 2000::/3, it will just I will nor it and create the AAAA with NAT 64 prefix. This actually fixed the majority of the problems that people were complaining about. But then I figured out that lately, and this is the moment of betrayal a little bit. I am a big supporter of DNSSEC. I have done many presentations, I've all my domains signed by DNSSEC, all my validators are doing DNSSEC, but sadly here you need to put in the BIND configuration directive break DNSSEC, yes. Because shortly we are synthesizing the AAAAs and if you make up the AAAA for a zone that is DNSSEC signed you don't have the key to sign the zone, because you just don't have the key. You shouldn't have the key.
So, here we need to break a DNSSEC set to yes, otherwise you will not get anything.
So here is the explanation. If you go without break DNSSEC. So I ask for the AAAA for dot Go6 dot SI, that is for A only to my NAT 64 server plus DNSSEC and I got back nothing basically. Of course, Go6 dot SI is DNSSEC signed. That should be clear. With break DNSSEC yes, I got back the NAT 64 prefix plus IPv4 addressing hacks and then the whole thing worked.
If you want to know more about it, there is the RFC written about DNS 64 and DNSSEC, how it works together and what you should not do. It's on the next slide. But before, just before the stream of consciousness, here is also the example of unbound configuration. As you can see here, I was first collecting all the anomalies and then I just decided to not use that and go for 2000::/3 and be done with it and lots of problems are gone.
Here is more reading. That's the RFC 6147, that's how DNS 64 and DNSSEC can operate together, and what exactly is happening.
So, we wanted to understand more from this point in time what's out in the real world. So, we went for some testing. So it was Sander and I were sitting and trying to figure out how many things on the Internet are broken in this particular way. And this one actually Sander found. Firewalls dotcom. It is secure, right. So here you see IPv4 and here is over NAT 64 and still indeed it is very, very secure. Very secure, it's on ::fff:something. This is the best security possible. Unless it isn't.
Then we have good DNS, bad server from Spain. It's sorted out but it's still on the slides.
So for IPv6 and NAT 64, what does it say here? I cannot... what does this mean.
SPEAKER: It's processing the systems for update.
JAN ZORZ: It's processing the systems for IPv6 update. Here we have good DNS and bad geolocation tool and this one is from Slovenia. So you will not say that I'm just bashing other people. This is sort of like the database where you can put files on, the file server. And it says that pictures can be uploaded just for users from Slovenia. Well, I am in Slovenia, seriously, I am sitting in Slovenia but geolocation tool doesn't work, so it thought I'm coming from God knows where.
Different page on NAT 64, then we have some German people. This is a store. And if you go on IPv6, there are no pictures of what you are selling. You will not sell much over IPv6 if there are no pictures there. Right. I would not buy here. Then we have the gateway‑funded dotcom, also not very attractive thing if you go over IPv6.
S about, we need to emphasise again if your non working AAAA record has broken NAT 64 and also if you still have your server running and as you can see here, this is some sort of household church, I don't know how we found that one, but we found that one, we went through the logs. So this is the IPv6 address that is in AAAA record and the server is responding, as you see. But the web server did not run on IPv6. It was not listening on IPv6. So, therefore, you could not connect to this church if you would be on IPv6 or NAT 64. So... what can you do?
Then we have working AAAA record and IPv4 only content. Of course IPv6 only, just 1% of the content loaded. It said bad gateway and broke. So...
We have lots of this stuff. So here for example we have all the elements, how they loaded and you see here on IPv6 something happened, it says bad gateway, and badly broke.
So, we need some sort of a Looking Glass to spot all these problems. If we are deploying network, if we want to test how all these people sees the content or how content is being seen, we have many things to test. Test on NAT 64, test on IPv6. Did all resources load okay? Does it look good to the user? Did we see any PMTU discovery issue? It started at me building a bunch of script in bash, I am not a programmer, I'm a lousy all of programmer ‑‑ well I'm not a programmer but I wanted to put something together to see if it's possible to build something. And then I showed this to this gentleman here, and he said, Mr., step back from the keyboard. And I will ask you to explain what we did.
SANDER STEFFANN: So, I thought this was a great idea, it was something that needs to be tested. There are just too many things that can go wrong. So, we built a simple service that anybody can use, just put in an URL and see what happens.
This is the overview, you can actually filter, you can search for the results. You can see ‑ I only want results where IPv6 failed or not. This one is of course everything is good so you can also, not only bash the ones that are wrong but also see who did the right thing. And here is some more examples. So, you can see you have the images, and obviously there is something going on here, on IPv6 only it just doesn't work but even on NAT 64, there are some bits missing. So, what we did is ‑‑ we actually made a mouse over system so you see the images side by side but if you move the mouse over the NAT 64 image it will actually do an image different between the v4 image and the NAT 64 image so immediately where the bits are wrong jump out at awe. You can see immediately where the differences are.
We made a conscious decision here. If you properly want to run a NAT 64 service you probably need to run some ACLs so you ignore all the bad records in DNS. For this test we set up a separate NAT 64, DNS 64, where we didn't fix anything. If you did something stupid, it will break. We want to make sure that people can test and see that they are doing the right thing.
So, how do we build this? Well we started with one machine, we have a management server which runs the web interface and from there we coordinate all the different tests. And then we have a couple of servers, well, virtual machines, one with only v4, one with only v6, one with only NAT 64. Jan runs everything on Proxmox using virtual machines there. I have a VM cluster in the data centre to I use Ubuntu there, so we have different setups but following the same structure. We are using phantom JS which is a testing tool and gives a lot of useful output. So for example we can exactly see which resource gets loaded, so we can track not only the HTML itself but see what all the components are. And it's really useful because it doesn't need X Windows or anything, you can just write a script and make a screen‑shot. So, that's how we do the different screen shots.
And in a graphic way like I said we have the master. It's connected to all the machines. And we have a special set of DNS 64 and NAT 64 servers. So, if you want to run this it's all Open Source code but you actually do need to run six different VMs to run it in your own lap. One of the other things we did is, we changed the MTU, we made sure that the server ‑‑ sorry, the client itself thinks it has a 1,500 byte MTU, but then one of the v6 links actually, we intentionally limited MTU to 1280. So that way if you break path MTU, this will break. So some people are complaining my website works perfectly, I tried it and it works and your test says it fails. Well yes, this test checks the worst possible scenario, not the best possible scenario. So, we tried to trigger all the mistakes we can trigger.
So, go ahead and use it. We have an URL you can access, you just type in the domain name and at that point, it's added to the queue, it probably takes a couple of minutes to run and you get the results.
JAN ZORZ: Take the time.
SANDER STEFFANN: So, like it says in the bottom, no need to hit the back button, the test will just run, it's in the background, we're smart enough that if you actually do hit the back button we don't reschedule the test time and time again. We keep the littest results and you can go through, also through the history and see what has happened.
So, test your website. If you are running a website, I even found a tiny bug on the RIPE NCC website. So, there are some little things that can easily go wrong even for somebody with experience.
If it fails, just try to fix it and try again. And I guess I don't have to remind you but if your problem is actually a DNS error, then you have to wait a little bit for the caches to time‑out.
So, if it doesn't work, then this is actually output you get, you can also look at the debug logs by the way. And if things go wrong then it fails. So, there are lots of things that can go wrong.
The source is available in GitHub, like I said you can run it yourself. You do need a couple of VMs, you do need a certain setup with different MTUs and things like that. Just if you want some help running this, just ask us, we'd be happy to help you.
And I guess that brings us to the last slide. So, any questions? What do you think of this? Do you think this is useful? Are you missing something? We'd be happy to add extra features. I have already noticed that phantom G S has been discontinued so the developer gave up on it so I guess we have to find a new tool to test it. But let us know what you think.
JAN ZORZ: And also we need some help. Now it's just Sander and me on ‑‑ Sander on a voluntary basis. We need developers to develop. We got lots of suggestions already what to add to this platform. But we need some help. It's on the GitHub, have a look if you are interested, talk to us.
AUDIENCE SPEAKER: Andrea, Sisnet. This is awesome. I was looking for such a tool and thinking about such a tool for a very, very long time. I was actually thinking of building something for my little website, which is called doesn't work dot EU and I was going to put a test there look how your website looks from IPv6 only network. This adds like ten more levels over it, so it's much much better.
I made some notes. Yeah, first thing with DNS, from the back, so first thing, for DNS propagation maybe, the DNS server at the destination should set Max D T L to some low‑ish value so you can check that you fixed it right even before it propagates. Because you can cap the server over.
The other thing is, yes, today's generic programme, actually most of time I observe programme with properly dual stack server that refuses connections on v6. So, I fixed like two websites like this during last RIPE meetings because I really hit it only at the hype meeting with NAT 64 network. So, and this is the problem that unlike those weird AAAA records, this can not be checked programmically because you never know whether somebody is resolving DNS for a web or for anything else. So but I haven't figured out any way how to make this, but checking a website like this is a very, very good idea.
And my other actually question would be what have we set up at least at the first phase the DNS 64 to four synthesiseers of AAAA record for every single query even if there is a AAAA record originally. So we would get two IPv6 records for dual stack server and we would let brow cert err deal with it.
JAN ZORZ: No. It's a bad idea. Sorry.
AUDIENCE SPEAKER: Okay. Thank you.
AUDIENCE SPEAKER: Julian. Many many thanks for the jobs guys, it's a really impressive task. I will be really happy to start 6 VM on the next week to give it a test. I think you will probably get an e‑mail from me over the next week. And this is really interesting not only from my point of view but we are also deploying more and more IPv6 only servers and we need to access for example Github from the servers and we need so DNS 64 and NAT 64 so this is interesting also from a server point of view. Thanks.
AUDIENCE SPEAKER: I'm which will from AS 1613. Thank you very much very much very much very much very much much. That's amazing. I will go and talk about that if you are going with that because I need to advocate and there will be some resource for the resource people even though they are like well v6 connected and so on. They might need a some help to see that we might have some problems. So thank you again and I would like advocate that for you if you are okay.
JAN ZORZ: Thank you. And just to add currently we have two instances of this system, one is in Go6 lab, one is IPv6lab.net, that's him and me basically. We had quite large machines but we would like to see as many instances around the world running this stuff so we can, then we can also think about, I have in my brain this vision of building a system of interconnected instances that you can compare how content is seen from different vantage point points around the world. We can do many many many things here because we build the platform and we can add‑on many new functionalities.
AUDIENCE SPEAKER: Then I'll try to find also some people who can host some VM for you, that would be great. Thank you again.
MARTIN LEVY: Wonderful stuff. Look, VMs are free, right, or some people keep telling me that and you mention and it was asked originally about MTU values. So you have three tests. You would be quite useful to the community by continuing to do those tests at various MTUs, obviously full MTU and 1280 but maybe a bit more and just load up the VMs to do this and run through additional tests. I think it is valuable to see where the edge cases for a set of domains.
Second question: How many queries is this thing doing at this very second? One, two, 20 people in the room maybe? Could you just run a background test and do the Alexa million and be done with it?
JAN ZORZ: Well we could, I don't know, we can load it on and optimise it a bit and ‑‑ we already tried with 5,000 or 10,000.
SANDER STEFFANN: We took a top 5,000 or whatever list and ran it. So, you know, it's automated you just let it run for a couple of days.
MARTIN LEVY: Come back somewhere with a wall of shame type kind of thing or maybe you find a pattern associated with that which actually may be more valuable. This sometimes won't be on a per domain issue but maybe on a network you know when we go off there for, we have an issue. That's just my thought but wonderful stuff. That's great.
SANDER STEFFANN: This is definitely if you see all the feedback we're getting this is definitely only the beginning.
JAN ZORZ: So currently when I go and talk about this stuff, I see Dan in the stats that sort of like it goes up. But nobody complained about the performance yet, so apparently the big machines are coping.
MARTIN LEVY: One quick other one. 8.29 euro, I could press the button for NAT 64 check dotcom but you didn't seem to register it. Go get a real domain. Let's get this to the masses.
JAN ZORZ: Thank you. Did you buy it?
AUDIENCE SPEAKER: Freddie. That's absolutely awesome and well, what else do they deserve a big hand, Stefan and Jan.
(Applause)
AUDIENCE SPEAKER: Magnus Fruehling from Freifunk Frankfurt. I wanted to ask did you see any special like machines or anything where an MTU problem came up especially.
JAN ZORZ: Jordi, can you respond to this question. Did we see any machines where MTU problems came up?
JORDI PALET: I actually, they asked me to do some kind of better testing of this. I think it was last RIPE meeting and I discovered some MTU problems so actually some of the tests they are doing because the MTU it was because of that right.
JAN ZORZ: And the tests in our tool back then showed that everything is fine, everything is nice and then he tested through the, through his tunnel that was MTU restricted and for him it broke and he came, he kept coming back and saying, it's broken for me, I don't see it. And we kept saying to him no, no, no it works, look recollect the picture, and then... we figured out that if we put IPv6 only VMs on the MTU restricted connection, then yeah, it will break.
SANDER STEFFANN: We have actually seen an interesting one. For example, we do pings at different MTU sizes we sent a small pink, we sent a ping at 1,500 bytes and we sent a ping at a much larger value so the last one we know has to be fragmented. What we have seen is some people block pings on their firewalls, they don't want their server to be pinged but the fragmented one got through.
AUDIENCE SPEAKER: My question actually came from the point because we tried it too and only one company actually were capable of fixing MTU problems if no paths MTU is, or no response comes from them. Google just doesn't care if the MTU is too big or not big enough. They just try and go down. So, your http S connection still starts and then everybody else has problems.
JAN ZORZ: Actually we have been thinking of, it's on the list of improvements. There are tools that can test path MTU discovery and if we see problems with your measurements ‑‑ scupper ‑‑ we discussed that ‑‑ then the tool would automatically run this tool and try to troubleshoot the problems with your network and suggest to you what to do.
AUDIENCE SPEAKER: That's great. Thank you.
JAN ZORZ: Thank you very much.
JEN LINKOVA: I'll try to steal the last minute of our time with one comment and one question. First of all, the idea that it would be really nice to get lex a 1 million tests like can we get an ‑‑ here is my list can you give me the result?
JAN ZORZ: There is a programmic way but only Sander and I have access to T.
JEN LINKOVA: We have human interface to API. Good.
JAN ZORZ: It's through the administration, but we can ‑‑ I don't know, we will figure it out. And if we go and test 1 million domains then I need an air conin the lab.
JEN LINKOVA: Okay. Your slides, especially the one one of the first slides definitely showed that people do read documentation and they actually do copy and paste from the documentation so I expect people in the room or remote participants might do some copy and paste of your configuration. So I would like to point out for some reason I could not see ULA prefix as a prefix which should not be.
SANDER STEFFANN: It's outside 2,000: . /3.
JEN LINKOVA: I think in your example you explicitly deny some prefixes, and that leaves the prefixes which you do not care about.
JORDI PALET: Those that are inside the 2,000.
SANDER STEFFANN: ULA is inside 2000: . /1.
JEN LINKOVA: Very last thing. Have you checked how many of those broken things are broken, would be broken for validation resolver, because they do not only have DNSSEC. It's a feature request. I'm really curious to see numbers.
JAN ZORZ: You could probably see that from the result of the measurements that something went wrong with DNS. But we can ‑‑ you know, this is a platform. We can hook all sorts of new stuff if the platform figures out something is wrong in this direction, we can hook up and start trouble shooting. But this is, probably this will become the full day job for one person if we go in this space.
SANDER STEFFANN: We have got lots of ideas as well, hooking up more tools, providing a dashboard so you can actually set warnings and schedule automatic retests all that kind of stuff.
JAN ZORZ: We need help.
SANDER STEFFANN: The list of ideas is much longer than we're currently capable of handling, so volunteers are really welcome.
JEN LINKOVA: Thank you.
(Applause)
JORDI PALET: Actually, there is one big problem still in many deployments is people don't really take care of MTU and that's the reason I discovered when they asked me to test this, and there is one big German content provider which uses numbers for the name, they deploy IPv6 for all their customers, I have been teasing them during 18 months right now telling them they have a problem with MTU and all their IPv6 websites are broken, all of them. If you are behind connection with slower MTU. So, well it seems they don't care.
So, don't contract your website with that content provider, right.
I have only 15 minutes, so I have ‑‑ ten minutes so, I need to rush a little bit. How many of you here, because I can probably run a bit faster, how many of you here already know what is 464 XLat? About half of the people. Okay, so I need to go through that a little bit. I will try to be quick anyway.
Well, I guess everybody knows, we ran out of of IPv4. So, if you are an ISP, how you are connecting your customers? Of course you will end up connecting them only with IPv6. But there is still a lot of people trying to use things which depend on IPv4 like 6 RD, and things like that. So, that's not going to be the way. And that's why sometime ago we started working in IETF in the Working Group which was basically trying to sort out the problem with more tunnelling. So, we basically decided that we can use L2TP to do one more way of tunnelling IPv6 on top of IPv4, but cannot do that any more because we don't have addresses. As a result of that Working Group, we have some transition mechanisms like DS‑Lite, Carrier‑Grade NAT and light wait 4 over 6 and it seems like those mechanisms are the ones more used in the wider access networks. So, my talk basically is trying to say that we don't really need to go through that way. We can do it easily.
Everybody knows about NAT 444, and that's basically a Carrier‑Grade NAT. For those that didn't read the RFCs, Carrier‑Grade NAT is the easier way to an A F D L which is the real name in the documents for the Carrier‑Grade NAT box. This is the way we do Carrier‑Grade NAT. Then we have ds‑lITE and then we have lightweight 4 over 6. You can look at those slides later and you can come back to me in the break if you need more information. So the point here is all these transition mechanisms bring your network to something like that. So you have one or several big Carrier‑Grade NAT boxes, a million of tunnels and so on. Do you really believe this is something that is sustainable? Do you really belief it's the way to keep growing your network and providing broadband to your customers? That's the key point here.
Do you really believe that with all the things that Carrier‑Grade NAT breaks like those in this list and more that we will discover with the time, it's still the way to go?
So, some of the people said okay, let's go to NAT 64. And of course NAT 64 works perfectly. I think the previous presentation was preferably agreed to talk about that, but if you are using APIs or literals, it will break things. So, again NAT 64 is not despite many people believe so, the way to provide service to your customers. This is a list collected by T‑Mobile of things that are broken with NAT 64. And you have here things like Skype, spot identify and many others, so it's not just things that people don't use. It's a lot of very common used things. And then you have another protocol, which is 464 XLat which actually all these things work perfectly. So that's the main difference between using just NAT 64 or using something else which is 464 XLat.
This is the description of what it is doing. This is the way it works. Basically 464 XLat is a combination of NAT 64 and DNS 64, so the same that has been introduced in the previous presentation, but you have also in the CPE something which is called the customer lat, customer lat, that solves the problem of all those things broken by NAT 64. So it solves the problem of literals and solves the problem of applications using all IP Is, okay.
So, this will be a diagram of how 464 XLat is being used in the infers, because you may not know it because most of the big server providers of US, actually four of them are already using this to deliver IPv6 only access to the customers. So, what actually the C lat is doing is translating when it's needed, not always, in a stateless way from IPv4 to IPv6 so the applications that is still use literals, for example still work and then in the network of the ISP you have the contrary conversion with what we already know as the NAT 64 plus the DNS 64 combination.
So, there are three possible uses of this. It's not three scenarios, it's the same cellular phone do it depends on the application. If the application is using IPv6 and is going to talk to an IPv6 server, there is no translation. The second case it the application that is using a domain name to go to an IPv4 server, then we have the case for the DNS 64 and NAT 64 that was described in the previous talk. And then only those applications that are using literals will make usage automatically of a kind of double translation which is done in the cellular phone itself from IPv4 to IPv6 and then in the provider on the other way around. So at the end, from end‑to‑end, you have no translation, okay. You get the same in both ends.
So now if you look at this slide it looks like I am talking about the cellular world and yes that's true, but if you read the 464 XLat you will understand that is clearly described that this is only one case and 464 XLat also works in any kind of access network, not just cellular networks.
So, this is the point. Can I have an ISP which has different kinds of networks like a cellular one would you saying already 464 XLat and then maybe residential customers also using the same transition mechanics and also corporate customers. Most of the corporate customers don't have their own data centre. They only use the Internet connectivity to browse or to access other networks and so on so in most of the cases they don't really need to have let's say incoming traffic. There is a solution for that as well. But many people don't realise that. Okay.
So, this is actually what I'm building for several customers. I have three trials right now among the three trials we are talking about 10,000 customers, so it's not a small trial. They are in three different countries, three trials in total about 10,000 customers and one of the difficulties we are having is vendors of CPEs don't have support for C lat. That's one of the big issues. This is actually a more, let's say, detailed diagram of what it will be. This deployment which is one example of customer in this side of the slide and the other one how will the CPE network recollect that's the pointer ‑‑ one thing here is this is an optimisation, so the point here is that of course you have IPv6 only access to the customer, so you sort out the problem of having to deliver encapsulation or tunnelling to the customer with IPv4. And then the customer has here full dual stack, the applications will still work as they work today. Again there is nothing special that the customer needs to know. The customer will not realise that it has an IPv6 link. And then all the traffic can go through the NAT 64 and DNS 64 but I have here also a way to optimise so the IPv6 native traffic don't need to go through the machine or the router that is going the NAT 64 thing. So that's even I am using here documentation prefix for post IPv4 and IPv6 network. I think it's very easy to follow but I can talk if someone is interested, you can talk about this later in the break or whatever.
So this is working. I mean it's not something we have in a lab. It's not something that is a few number of customers. It's something that would really need to wake up people to say hey you can avoid Carrier‑Grade in the, you need to have NAT 64 instead but you probably have NAT 64 for other things and so on.
If you wonder about if this is working in millions? Yes, this is the traffic that we have in the server network so we can replicate that also for wider networks.
And I think this is the last slide or almost. This is the support that we have for C lat and for NAT 64, so, most of that we knew that already. But we are using right now basically is open WRT for these trials.
And this is all data. Advantage in performance, we are getting the same figures that Facebook already showed us in cellular networks with an improvement of up to 40% of using 464 XLat instead of other transition mechanics like DS‑Lite and so on. So that's key, I guess.
And I think that this is the real last slide. I don't remember how many I have. What we are doing also at v6 ops is there was a document explaining what are the CPE requirements, so this this document it's being updated and we are including, you'll see it just the support for 6 RD and DS‑Lite, we are including the support for protocols for 464 XLat and also a few others, so please go to v6 ops, read this document, provide inputs and I hope it has been useful.
Thank you.
(Applause)
JEN LINKOVA: Questions? We have very little time... okay, no questions. Great.
AUDIENCE SPEAKER: Lee Howard. Thanks again. You had a slide there that you had taken from comparing the permits of NAT 64 to 464 XLat. Do you know of any modern comparison of the application effects of the various modern transition technologies, dual stack light to 464 Xlat to MAT T MAT E ‑‑ so, there's been some research that's five more years old compare that some applications breakthrough Carrier‑Grade NAT fingerprints, which one would expect to be essentially the same or very close for dual stack light. You showed two comparisons, but there's at least four or five that are in fairly widespread use. Does anybody ‑‑ does anybody have a table showing tests of applications on various transition technologies?
JORDI PALET: You mean actual tables. I got that data from Internet Googling. I tried to find something more modern. I was not able to find it.
AUDIENCE SPEAKER: More research needed. Not more Googling needed. Somebody needs to do testing which means somebody needs funding to do testing.
JORDI PALET: Because I believe this is the right way to do what I am testing is actually with 464 XLat and I didn't find anything that is broken. In fact, in the last IETF, I got a /64 for my machine, my laptop, I was using to run C lat in my laptop and I was running all the week with 464 XLat and everything worked for me.
RANDY BUSH: For the residential and enterprise customers, I think XLat and DS‑Lite get the award for requiring both CGN in the core and forklifting the CPE. I mean there is a real solution, right. I mean, they missed having to change the circuits too.
A friend has whispered in my ear that if some Italian living in Tokyo would clean up their bloody implementation on Androids, map E would solve a lot of this and make it a lot simpler.
JORDI PALET: Maybe, it's one of the possibilities. And in fact in the update of the requirements I am including also support for map E and map D, definitely, that could be another option.
JEN LINKOVA: Okay. I'm going to jump in the line because we are already four minutes over time. I am a bit confused with the table you showed because I do know that my Google dog does work on NAT 64 network, so I'm not sure how all this table you showed us.
JORDI PALET: I can tell you, I know that the T‑Mobile web page where I got the data, but I can check the date.
JEN LINKOVA: Okay. Thank you very much. We have run out of time so I apologise for keeping you so long here.
One last thing. Just a reminder, tomorrow the start, Plenary start, 9:30, not 9, you have half an hour more sleep which all of us probably need. And there is a Plenary will start with some diversity discussion. So please, please try to wake up.
Thank you very much.
(Applause)
