IPv6 Working Group
25th October 2017
At 4 p.m.:
JEN LINKOVA: Welcome to IPv6 Working Group. Please take your seat. Let's start. My name is Jen, I am one of co‑chairs.
So let me, first of all, thank our magicians, I mean stenographers; and scribes, thanks a lot for RIPE NCC to help us to record everything we are saying. Because I can't remember anything, so I have to re‑read meeting notes. And I am improving, this time I manage to send them to the list before this session. Just 24 hours but I hope at least some will manage to read them. If you have any concerns, corrections, objections, please let us know. Unless if there is no objections or corrections we can assume we can approve them, right.
So microphone etiquette, say your name and affiliation when you go to microphone, so your name and affiliation can be recorded.
Agenda. We have very interesting talks today, but before we start, I would like to quickly go through one last administrative agenda item. We now have a tradition of Working Group Chairs taking down and this time Benedikt, stand up please, Benedikt is stepping down and, at the same time, he stands for re‑election, and this has been announced on the mailing list, and so far, what we have observed is number of support statements for Benedikt. And I have not seen any other volunteers for this job. And I am not surprised because you have to work with me and send me minutes. There is a list. And I haven't heard any objections, so if you have any comments or objections or probably would like to volunteer, speak up now. Jan, are you going to microphone.
JAN ZORZ: No, I just came in.
JEN LINKOVA: Three, two, one. Sold. Congratulations, Benedikt, welcome back.
(Applause)
And the very last thing, please rate the talks because if you are not happy with the agenda, it's all your fault, not mine. Because you did not tell us whom you would like to see on the stage. Today, our first presenter, Geoff, is going to talk about two of my favourite topics, extension headers and DNS, right.
GEOFF HUSTON: Good afternoon. I am with APNIC, I do stuff. Look, this is a talk that I think is going to raise a lot of questions, and the easiest thing for me to do is try and get through this material, so I am going to assume you are really familiar with most of the concepts going on here. If I am speaking too fast, go to a microphone and I will stop and we will sort of explain a bit more in detail. But I will be quick.
In the original design of v6 there were two things that changed quite fundamentally in the area of handling large packets. This was kind of strange in my mind because one of the real reasons why IP itself was such a success in the 1980s and '90s was its treatment of variable packet sizes and fragmentation. The whole reason why we are running IP and not DECNET might well be because of its fragmentation handling was just so much more elastic.
What we found in v6 that a couple of things changed. The first was that the fragmentation control field moved out to become optional. And secondly, the "don't fragment" bit is jammed on, routers cannot fragment on the fly. So in v4 at the tope there, there is always a forward momentum of a packet, if it can't be pushed on to the next‑hop that router is quite capable of fragmenting the packet and sending it on forward as long as they don't fragment it is set on. In v6 it starts to look like a 3G GP network map because by the time this packet hits a router where it cannot move forward it must discard that packet. But before it does it has to generate a diagnostic, ICMP packet too big and that "too big" message is not passed forward, it's passed backwards to the source. And now what the source does depends a little bit on what is going on. It can send the fragments but it probably should not. Now, there aren't many times you need to send a packet from the middle of the network. And for all of you folk running MPLS, that is a good thing, because MPLS is a unidirectional tunnel and you have no guarantee that once you find a problem in the middle of a path, you have any hope of going backwards, because it's certainly not a label path going backwards and you may not have full routing on your tag routers. Just think about that for a second and think about what v6 is asking you to do and try and figure out if you can do it, and the answer probably is you can't.
What happens when a sender receives that ICMP message? That is a really, really good question because it's the sender, not the router. And so the sender, if the first leading part of that fragment contains a TCP control block, you are meant to send that diagnostic back into the relevant TCP control block. And we have now invented a new TCP signal that did not exist in TCP before, it's called a Nack because that message is implicit, I didn't send that, you have to resend with a different MSS. So, in TCP you are never meant to fragment, you are meant to pass the message back to the control black, you are meant to resend with a new TCP MSS size.
For UDP, damn, I have no memory. It's a datagram, it's gone. I have got this little thing saying it didn't make it. What thing? I have forgotten I have sent it. This is a problem. So, some implementations store this in some kind of per host forwarding path going, this is a revised MSS, if ever I need to resend use this MMS and fragment down to that, if you ever need to send that packet again. Some operating systems don't do anything at all. Why do they get the message? I don't get it.
For those running Anycast, who is running Anycast? You are in deep shit. And the reason why is that the return path in any IP network is not necessarily the same as the forwarding path. And if your Anycast deployment is dense, the Anycast instances that are closest to the routers on your return path might not be the Anycast instance that sent the big packet.
So as you see there in this diagram what might happen, fending on your deployment and who is actually talking to you, is that those ICMP messages that are really quite necessary to adapt, will go to the wrong instance of your Anycast Cloud. And at that point, communication stops; you can't adjust because the wrong instance has got the message. There is no fix for this. You can't make this magically go away. And for those running TCP and Anycast, there really, really is no fix for this. Not an easy one at any rate, it becomes incredibly mind‑bendingly complex. For those of you running Anycast on v6, you have my sympathy.
The next path, the v6 fragmentation extension header, there has been a long argument about v6 circles about variability in packet headers. The argument was, if you had variable address links or variable anything, very, very high speed switching equipment didn't have the time to process the header because it has to interpret the header rather than looking at a fix sized bite offset. So we start doing really cheap stuff these days and pushing it very hard. When you insert an extension header, the transport control block moves to an unknown and variable offset in the packet header. If you only have 30 instruction cycles, even with all the Intel DPDKs in the world you might not necessarily find that transport header within the cycles available to process the packet. What we are finding is there is a large amount of equipment out there that when it sees a v6 packet with an extension header, it does the cheap thing, just drops it. Doesn't matter what was in it, it's got an extension header, it's going to drop.
So, fragmentation is looking pretty bad. It's looking pretty bad because of ICMP PTB handling because of the backward signalling because of extension header handling. So who needs it? Well, the DNS.
Here is a good example. Anyone here from.org, the PIR folk, they gave afillious of looking after it, runs Secure64 DNS box and tend to deliver really, really large answers.
Here is an example, I asked for the DNSKEY of dot org, I get back 1625 bytes. I don't know about you but for me that got fragmented, it had to. So you know.
How about this, I like this one: I have a server, an authoritative name server, it only exists on v6, you can't get to it v4, it only delivers big answers in v6 because I can. So when I ask Google over v4 to ask my authoritative name server about a question about my special domain, because the answer is larger than 1,500 octets Google goes no. Over v4 it works just fine, under 15 octets it works just fine and bizarrely, which I find curious the UDP buffer size that Google sent to me was I can handle 4096, send me any packet you want and I did and it goes no. The DNS it obviously expects fragmentation to just work, that is what is going on and the buffer size says I am in control of this but, you know, it doesn't really work that well in v6. Trailing fragments always encounter problems with firewalls and filters we knew that, the the whole issue of mismatch becomes a nightmare and the header becomes just as bad. In the DNS if you really get stuck move to TCP, can't you? Only if you get back a truncated answer, silent drop doesn't cut it, so the silent drop properties of this kind of magical problem don't cause the DNS to use TCP, so in this case TCP isn't really going to get you out of this mess either. Oops.
So is it a problem? As long as you have still got v4, it's not a problem, and none of you are motivated to fix it, not even Google is fixing it immediately because it's really hard to have a user that complains; fixers are coming but not yesterday. This is not a grade A serious user visible problem because v4 saves your bacon, as ever, as long as you can requery using v4 the stuff just works. In some ways this is one of those silent problems that dual stack papers over and goes Internet is fine, everything gets resolved, we haven't got a problem. But the problem is big, as Jen well knows, because she was a co‑author of this particular RFC. Extension header drop rates when sending large packets towards big servers was up around 30 to 40% but who sends big packets towards servers? It's not what you normally do. Servers, whether it's the DNS or the web, send big packets back to you. So, I would have thought curious about this, and thought can I do the opposite: Can I send really, really big v6 packets back to folk and see what happens? Well, you can and it's as easy as the terms Google ads because I use this ad platform to measure large A the Internet in various ways and one you do a get, the DNS answer can be fragmented in v6, so can the URL, the TCP session. So what I am doing in the first instance is sending back fragmented v6.
And I will do a little trick with the DNS just to make sure I understand what is going on. And for DNS weenies, this idea of glueless delegation should go a‑ha because I muck around with the response of the query of the name server name and make it fragmented. You will only ever query for the target name if your DNS resolver successfully received a fragmented v6 answer. And I know who you are. Because you just asked me a question. So, I did this 10.8 million times, I think that is enough, isn't it? We could do it some more but at that point you see enough of the Internet to be representative. Failure rate of those 10.8 million, 4 million, 38%. Which resolvers, 10,000 participated, three‑and‑a‑half to 3600 showed me that they had a problem, so putting up a list of all those is going to be a tedious and long. Here is the top 20. Geocellular in India, Indosat, a lot of people in India and they use very few resolvers so they are top of the list.
Let's do another one, networks by AS, Google is at the top, Sprint down there somewhere is SOnet from from Slovenia I can't, AT&T. These with your DNS resolvers that are incapable of receiving fragmented v6. For whatever reason it just doesn't get to you. So I thought well, okay, that is the DNS, that means no one is serious about running large packets over v6 over the DNS because it just doesn't work. What about TCP? What about you and I? Same approach. What I do is set up a server and modify the packet handler so that it always fragments TCP packets before they get to you. So I ran it and found 1.9 million distinct end points running in v6 and 434,000, it 22% failure failure rate when I try and send them fragmented TCP. If I was an ISP, and the service I was running had a failure rate at 22%, I would not be in business by, what is tomorrow, Thursday. It's horrible.
Who are you? You are Google. You are Microsoft, you are Hughes, you are Hurricane Electric. There is a lot of people over there with fragmented TCP problems, fragmented v6 problems in amongst the folk doing v6, that is funny list, and they are all over the world.
Why? Two problems: The whole issue of fragmentation and firewalls, we knew about that. But the second problem is, mid‑level or even cheap switching gear that wants to see the transport packet header and can't when there is an extension header present so they just drop the packet. So there is an awful lot of network equipment that simply sees the extension header and goes, nah, too difficult. And that is why we see it.
Now, I am being optimistic. I really, really am, believe it or not. Because what I didn't do was also pull in the ICMP PTB message, I just fragmented everything. I didn't wait for you to send me that packet is too big, I just fragment it. This does not take into account the known issues with ICMP PTB messages. Those numbers that I showed you are low, not high, the problem is worse than this.
What do you do about it? If someone says I am running a v6 only Internet the only thing I can assume is they are not running the DNS because it doesn't work together, particularly with DNSSEC. Because if we really are serious about a v6 only network and we really are serious about security in the DNS and DNSSEC, that combination today isn't going to work for you or me. So, we have got to do something about this.
Option A, the v6 design was broken. Let's change extension headers and fragmentation handling, revise all of this. It doesn't sound right. Let's try a different approach and fix up all the hardware because that is easier. There is so much hardware out there and vendors are still marketing this today, so thinking that you can go and find all the broken bits of v6, all the filter rules, everything that says extension headers and fragmentation is going to get dropped and you are going to fix it, I don't think you are going to live long enough. And if we are right about needing v6 people are deploying more of this every day. So the idea that it's fixable doesn't seem to make much sense to me.
Well, maybe we go back to the original plan, let's change the v6 protocol. Yeah, right. Anyone who ever thinks that they can go back now and change those fundamental paths about extension header handling and fragmentation it isn't going to work like that. We are so far down a path we have to live with this. We simply have to make it work. But, this is hard too. So, you know, rock, hard place. Not going so well. Don't fragment. Just don't. And that is the only option we have got left because, quite frankly, all of those have pain and cost, all of them are really hard. And quite frankly, attacking all three is just stupid. So, the only option is not to fragment at all.
Now, for TCP, that is not a big statement it. If you start to very carefully select your MSS and 1500 is a bad place to be, 1280 is probably overkill but somewhere between the two are numbers you can probably live with it. And if you don't like that you better bloody implement 4281 because that is the only other thing that is going to work. You cannot rely on ICMP PTBs. So for TCP, as long as you are very careful and stop doing default 1,500 stupidity and start doing some TCP path MTU discovery, you are probably okay.
UDP. UDP. Why did we ever do UDP? It's a nightmare, the fragment drop is silent, there is no signal back to you, you don't know if it worked or didn't, the applications have to get involved, this is starting to get really, really, really ugly. Because you either have to change the protocol behaviour of things like the DNS and actually change the way the DNS works to send large packets over, or you have got to do UDP MTU discovery discovery or you start doing DNS over TCP. You know why the DNS is free? It's because it's really efficient. Really, really efficient. You know what DNS over TCP is not? Really efficient. It's not. You have to scale up all the servers, all the hardware, all the everything if you really think that you can run the DNS load of so many trillion queries a day over TCP, ain't going to happen on the hardware you have got. So you have think hard about what sort of protocol changes you are going to need and how to signal them. None of that has happening, bits of it is happening and you better hope they come up with answers before you need them, because you will need them, you cannot survive with fragmentation. We would like a plan that allows us to avoid it, we are not sure what that means, we are looking at working around the stuff with applications.
But, you know, the problem is that the IETF overachieved, and instead of just putting out one or two RFCs, here is the Internet have fun, we have managed to put out close to 10,000. I don't know about you, but I'd never read RFC. What is it? 8085, that's right. Do you know why? It says something interesting buried down there amongst that text. You know, if your UDP you can't fragment. Shit. It's a BCP. And in fact, if you're UDP and v6 don't you ever send a packet larger than 1,280 bytes. DNS are you listening? Don't do that because RFC whatever says you can't do that and we are.
So, you know, this is a rock and a hard place kind of situation that our entire naming system and future naming system if we think DNS is good, and I personally do, doesn't seem to work with the way v6 currently works, something has to change. It's a fragmentation problem. Unfortunately, I don't think so. Unfortunately, I think the really big problem is the extension header itself, that the extension header drop is actually really part and parcel of what is going on here. And if that is the more significant issue, it's not just a case of avoid fragmentation; it's like those other control bits in v4 header, the optional bits that we now think aren't optional, you really shouldn't go there. Extension headers are bits where as far as I can see we really shouldn't go there. If you are relying on extension headers stop it. It doesn't work on the big Internet.
Hopefully we have a few minutes for questions. Thank you.
(Applause.)
ALAIN DURAND: Speaking on my own are half as novice user of IPv6. I have a laptop here that is connected to my VPN at home and I am using a browser, I am using two browsers for two different vendors, and on one of them always IPv6 on this laptop ‑‑ on one of them, I can go to well‑known sites that do search engine stuff, on the other one I can't. And if I turn IPv6 off on both browsers I can. Weird.
GEOFF HUSTON: I find this really weird because certainly the whole issue about extension header and fragmentation is meant to happen down here at IP level.
ALAIN DURAND: It seems that depending on which protocol is being used between the browser and the server something weird is happening, if I go to another website that doesn't start with a G, I can do that with both browsers.
JEN LINKOVA: Is it happening here right now?
ALAIN DURAND: Right now.
JEN LINKOVA: It should not happen since this morning.
ALAIN DURAND: It's happening as of two minutes ago.
GEOFF HUSTON: We have a problem, let's all go and work on Alain's problem. It's part of this whole issue that when you start getting these kinds of problems which depend a lot on context, packet size and so on, you start to get user experiences which are difficult and expensive to debug. We did not expect that of v6, that wasn't part of the deal.
LEE HOWARD: I am so glad we get to talk about this again, Geoff, it seems like only weeks since we last had this chat. One of the things you talked about was the hey, you could use smaller MSS for TCP and somewhere between 1,280 and 1,600 is probably ‑‑
GEOFF HUSTON: 1,500.
LEE HOWARD: Where did I get 16 from? I was wondering if ‑‑ can you do some scaling with different packet sizes and see if there is an optimum range, maybe do a CDF showing where the best place is, because you said, you will probably find around somewhere in the middle and I would like to get a better plinth of the probability.
GEOFF HUSTON: Google is quick fragmentation insensitive because it's UDP. So none of the usual ICMP do something is going to work for them.
LEE HOWARD: With retransmits.
GEOFF HUSTON: Currently running by default but they are doing a bit of path MTU discovery from time to time but their work said 1350 at this point.
LEE HOWARD: In the vein of future solution space also some of which you talked about which sounds it would be ripe for be cop. So, gee, I don't know if anybody feels like starting one. I am not going to be the primary author rbut that would be a great place for that. I have already talked to a couple of folks, there is a decent chance now we are going to do a side meeting at IETF in Singapore to talk about some of these issues and see if there are further things we can do, because whether it comes to measuring things and getting ‑‑ changing operator behaviour or changing the protocol, I may be a little more sanguine about it, optimistic about it than you are.
GEOFF HUSTON: I am optimistic but what I am saying is we can't muck around any more. Can't believe that v4 postpones the problem. If you are working in the DNS, your problem is here and now, not tomorrow. If you want to keep running DNSSEC and large answers, a lazy reliance on fragmentation and UDP won't work. And I would issue the challenge, discard UDP, EDNS buffer size, throw it away and see what you are going to do next because you cannot rely on large fragmented UDP packets in v6, now see what you can do without that crutch.
LEE HOWARD: On extension headers I think you said this, but I will argue they are still useful within a network that you control, within your own AS, you decide whether you ‑‑
GEOFF HUSTON: This is big guy Internet. This is the lottery of Alain and his browser.
SHANE KERR: I work for Oracle I am not speaking for Oracle. I have done a lot of work in this fragmentation area mostly in my previous job, application level prototypes so that can be done, it's not cheap or easy, I don't think it's a good idea. We have done work in moving to different protocols, I think there is some hope in that, maybe Brian is going to talk about Quick, I don't know.
AUDIENCE SPEAKER: I am not going to talk about Quick, I can if you want me to.
SHANE KERR: I am nervous about Quick. I think on the DNS area like a lot of areas we are looking towards quick as the thing that is going to solve all of our problems.
GEOFF HUSTON: Did I guffaw at you?
SHANE KERR: My final point and I apologise for going on so long. I am not as pessimistic about TCP as you are, I have seen numbers, scaling factors between 6 and 10, as far as the extra cost of running TCP compared to UDP which is indeed a frightening number but I think we have to consider the fact that current DNS infrastructure is overbuilt by an order of magnitude because it's built on UDP. So, I am less pessimistic about the difficulty of moving to TCP versus ‑‑
GEOFF HUSTON: I know that is long debate in the DNS areas and I know many folk including Paul and others who have strong opinions on this area, but yes, it's not clear that that is an answer. What I would plea is we don't do what we did with transition technologies, having 30 different DNS over food technologies, won't help, it will make it harder, give us one. Thanks everybody IETF.
BRIAN TRAMMELL: I am not speaking for anyone, even for myself at this point. So I look forward to the draft on DNS 64 over DNS 64. I will say to Shane's point that if the problem is TCP scales less well than UDP then Quick is not going to save you. Just because it's got that protocol number 17 on the wire doesn't mean it's not a real transport protocol, it is, it scales like TCP, possibly even worse because you ‑‑ because the security ‑ dish wanted to come up and ask a completely different question, which I have for got en. Oh, yeah, so your last slide asks a question and I want to amplify that question because it didn't have a question‑mark at the end of it. When you are looking at the pain here, it's all about extension headers. And it would be really interesting and I have been trying to figure it out in the line but I want to ask you, how to take your experimental apparatus and set it up so it can differentiate the DNS brokenness from the EH brokenness?
GEOFF HUSTON: This is actually relatively easy. What I have is don't tell anyone but a v6 NAT. And what I have is a normal back end that emits v6 packets and I have a front end which does the NAT function. It also does gratuitous raw IPv6 packets. I can do anything in the header, literally anything.
BRIAN TRAMMELL: Let's talk off‑line because I think we can differentiate this bit and we will get slightly better data. Opinions in some contacts are even very strongly held opinions, are susceptible to measurement, and I think that it probably makes sense to really look into the simulating, emulating or running the scalability of large workloads of it. CP and see how bad it is. I think one order of magnitude is probably right, but it seems like having numbers in our bad pocket for planning purposes are a good idea.
GEOFF HUSTON: One half of the users on this planet 48% use DNS resolvers that will handle v6. Of that 48%, 38% of them cannot receive an answer if the v6 response and that is the only response available, requires extension header fragmentation.
BRIAN TRAMMELL: Anyway we can take this off‑line.
AUDIENCE SPEAKER: Tim from RIPE NCC. A comment made in the chat room from Philip Humberg. TCP and IPv4 only works because of MSS clamping. Obvious solution, implement the same for DNS, i.e., do not try to discover it. But that is more for the DNS community.
GEOFF HUSTON: DNSSEC needs big answers. You can clamp it all the way down you want, but how do you get the big answers, et cetera, et cetera, et cetera. It's a well‑travelled area but the challenge is there before us. We need to think about v6 without relying on fragmentation and potentially without relying on extension headers at all. Thank you.
JEN LINKOVA: I put myself as the last person in the queue because I have 30 seconds. I am thinking this works in particular network because I do know that all my clients is local network has MTU lower than my backbone, right? Is it all this problem because Internet still has MTU 1,500? If all my MPLS backbone has 9K, is it probably time to think that why Internet still like the same as my local network?
GEOFF HUSTON: You would be right were it not for the extension header drop problem, a number of large vendors put out equipment that is sensitive to looking at what is inside the transport part of the header and insensitive to going searching down extension header chains. So even if you do your MTU right, if you put out extension headers no matter what you have got a problem and if do you a 5,000 octet, 20,000 DNSSEC with all the signatures in the world of people going mad with TXT records you are still going to have the same problem and the underlying issue is, it's just not working right. Thank you.
JEN LINKOVA: Thank you.
(Applause)
Next presentation is about this word which doesn't seem to be possible as I can see because it's IPv6 only, and Wolfgang is going to tell us about web hosting, going to use DNS and so on.
WOLFGANG ZEMKER: Welcome everyone. I am going to take you a long our journey to reduce our IPv4 footprint on the Net, and show you what we have done, what problems we encountered so far and well, where we are and where we plan to go.
First to the reason why we did this. Until quite recently we used to offer web hosting for small and medium‑sized websites in a quite simple way using named virtual hosts, on a shared web server. And it was quite easy set‑up, but unfortunately can't do a few things that customers nowadays want to have, so no control over the software environment by the customer. So we phased in a new model where every website we host is run inside a virtual machine and use jails and FreeBSD as virtualisation platform. Jails are lightweight virtual machines, basically extension of the change root model; not only the file system is partitioned but also process table, network and stuff like that.
We combine that with CFS data sets for storage, read only from the host system, and application environment from blueprints, and data ‑‑ application data on read/write data sets.
Well, this is basically what the model looks like from an overviewpoint. You have a physical machine connected to the Internet, we have a virtual bridge connecting all the jails to the outside interface, and every virtual machine running dual stack to the Internet looks simple enough but has some side effect. I think ‑‑ all these virtual machines running the script name dehydrated to acquire SSL certificates. That's the side effect.
On the old model that we sold, we had one pair, one pair of IP addresses, one IPv4 and one IPv6 per physical server. And now the new model we need one pair of addresses per website, which is a lot more. Combine that with a look at our address space, we currently have one /20 and the final /22 for IPv4, which sums up to, well, a bit more above 5,000 addresses, and at the same time we have a /32 for IPv6, which is apparently some gazillion addresses available.
So, looking at these numbers, you might see we have slight bit of a problem, and, at the same time, you can also see where obviously we would look for something to solve that problem. So we revised that model a little bit by making these virtual machines connect by v6 only, and for access, by web users wanting to reach the websites there, we put in reverse proxy on a dual stack.
Well, we expected to, have quite a few problems throwing that out in production, so we decided to start with only a subset of hosting applications. In this case we used next Cloud hosting as ‑‑ next Cloud application hosting as a test‑bed. The good thing, what makes it easier for us, is in this case application comes pre‑installed and the customer that is running that application connects per https only. So that simplifies problem space a bit.
SSL, still these guys want to have certificates, and we took an easy way, running the dehydrated script on the host system only, because the host system has success inside the jail data sets but not the other way around, obviously. And you make for the transactions, we terminate SSL coming in via IPv4 on the host side and proxy to http connection on the inside of the jail.
When we implemented this, let's encrypt registry, was kind enough to ask for ‑‑ to send a challenges to verify that we are the guys that actually want this certificate over IPv4 if we send the request out on IPv4. So that made things easy. A slight problem that came up quite quick, was that this application likes to send mails to users of the service. And surprisingly, there is still some users out there that can't receive on v6. So, we use the dual stack host system as outgoing mail relay.
Well, another problem people like to extend the pre‑installed software with some apps or plug‑ins and the repository is, of course, IPv4‑only. Well, our solution, well, kind of solution, we just switched off the plug‑in model. So users currently cannot install any extensions. Well, and then sometime down the line let's encrypt registry decided, if you get an IPv6 address for the domain that wants a certificate, we send a challenger for IPv6. Well, fair enough. What we tried was to, well, install the dehydrated script in the jail, in the virtual machine directly but that failed because the way dehydrated verifies the certificate chain requires walking back the certification path from the end certificate to the root and there is at least one certificate in the path that can be retrieved on v4 only. So it doesn't work. The solution we chose then was to also set a reverse proxy inside the virtual machine going back to the v6 address of the host system, to, well, to verify the challenges.
Well, the problem that really came only up before I left for Dubai, some web DAV clients fail because apparently they bury URLs inside their requests and they expect the URLs containing https proxy be only to http and then it fails. Probably the solution will be to forget about termination, just proxy on to the https side inside the jail, don't know yet if that works, but probably.
So, that is where we are now. Of course we want to go further, we want to do this for generic web hosting, we expect to see a few more problems coming up. So some customers that have IPv4 only want to reach SSH inside the virtual machine. Well, we will find out. Some people, for strange reasons, install their own software from probably repositories and that is a few small places like GitHub that are still IPv4 only. So we might have to do something like an outgoing proxy or NAT 64 or something like that.
Well, and that concludes my talk. So far, any questions?
(Applause)
AUDIENCE SPEAKER: It's not a question, it's just a recommendation. Probably you need to take a look to CDC ‑‑ to sort out all your problems, you don't need all these reverse proxies because it's actually doing all that so from the perspective of the customer side they will be able to use everything like if it's a dual stack.
JEN LINKOVA: Thanks for stealing my question.
AUDIENCE SPEAKER: Andrei. Just a few notes because I tried something similar, so the inaccessibility of GitHub and other stuff from the web service I deploying NAT 64, DNS 64, which is ‑‑ which works just a way, it's not ‑‑ the only problem is that if you are sharing it with some third parties, and then you get ‑‑ external address of this NAT 64 you have quite a problem to find out who is responsible for that. But it could work.
The other thing is, I use Acme.sh for let's encrypt IPv6 only host and it works perfectly.
JEN LINKOVA: No more questions? Thank you very much, Wolfgang.
And now, you see some people deploy IPv6 only, but there are some part of network world still struggling with enabling dual stack, right, and I think we are going to talk about IPv6 in enterprises. Benedikt.
BENEDIKT STOCKEBRAND: That is the wrong presentation. Sorry about that. There is another one. That should have been deleted by now. That was just a backup in case we ran out of material instead of out of time. I actually prepared another topic in case we ran out of material rather than time, but your presentation this time.
WILHELM BOEDDINGHAUS: We want to talk about IPv6 client networks and if we talk about client networks, we don't think about the residential access networks, we think about the client networks in your office, and enterprise offices, accounting, marketing, sales, all these Windows based PCs that you have in these networks.
So why to talk about this, we have talked a lot about the design of IPv6 and ISP networks, I think the decline is clear and the same is true for data centre and the same is true for all white area networks. We have had a lot of talks, so we think this topic is done.
We have talked about the applications, we know applications are problematic case. Some of them have to be rewritten, but this is not too interesting any more. But we have not talked of the other side of the applications, about the clients' side of the application. We have talked about the databases but not the database clients running in office space. So this is how the idea for this talk came.
BENEDIKT STOCKEBRAND: So what we normally have today in client networks, they are largely still IPv4‑only, some cases possibly kind of dual stack but running in the old IPv4 only set‑up because people just deployed IPv6 alongside it and dual stack people suddenly realised it's not necessarily the best idea. And the big problem is with IPv4‑derived networks is they are a built in a rather crazy way. We have large networks, large in the sense that we have lots of machines in a single Layer 2 domain, sometimes turning 56 IP addresses in one subnet. The worst one I've seen blow up ‑‑ well, not my face, but my colleague's face was about 800 machines in one subnet. In these environments when things go wrong, things go wrong for a lot of people at the same time and it gets management attention, not the sort you actually want. Can be really, really big and real lots of trouble. I am not going to talk about wi‑fi networks like conferences or whatever, that is where things get even worse. And the problem with these networks is that if we have largely two networks, we put a lot of machines in a single trust domain so we have the security issues that people like NRA always talk about, and which are for all practical purposes unmanageable within the single trust domain and we have single failure domain. I guess nobody of you hags heard of somebody accidentally connecting rogue TCP server to IPv4 network, right?
WILHELM BOEDDINGHAUS: So what do we find in these networks, large networks? We have mixed networks, meaning you have clients and printers, in the same network, in the same broadcast domain. You update your Windows boxes or MAC or Linux boxes, you have software there, you update the virus scanner, when have you updated the software on your printer? And there have been hacks that have been done by other printers. And we have clients and clients, some of the clients stay in the office, these little boxes on the desk, and in the same networks we have these mobile PCs where the salespeople from outside come, from the hotel, Starbucks, wherever you connect your PC will come into these mixed networks and we have no real isolation.
BENEDIKT STOCKEBRAND: And basically, the question is, what can we do? The obvious choice is fix the design, build networks that are smaller. Means less machines in a single Layer 2 domain. And you could push that to the point that you have, for every single network port coming out of your walls in your office building, but the general idea is make these networks smaller.
What we do instead, however, is something else: We come up with new protocol things called private VLANs, which are not exactly how TCP/IP was ever meant to be used, but it kind of solves the immediate problem. It does add a bit of complexity, so more work for us, more money for us and we don't have to go out sweeping the streets or anything, but this is not really what we normally want. Normally, we want to have, get money for doing pretty much nothing except being smart. This is what this is really about.
WILHELM BOEDDINGHAUS: So we come up with a network design idea for IPv6 and we did a test lab to test our ideas with the help of a company called XANTRO in Germany. And we want to discuss design idea with you; we want your input and knowledge and ideas. So, IPv6 on only client networks, is that possible today, yes or no? We would like to fix the large network design flaw. We would like to run IPv4 as a service on top of IPv6 and we would like too far smooth migration from the old design to a new design.
So, what are we planning to do? The idea is that if you have a 48 port switch, you run 48 VLAN interfaces on it and you associate one of the hardware plugs to each of the VLAN interfaces. We don't think it's a good idea to have routed interfaces on the switch because next to our VLAN where we do our normal work we have this voice VLAN that comes to our desks. If you see a typical cabling situation on the desk in Germany, it comes from the wall to the telephone to the PC, we need a Layer 2 port. But we have 48 VLANs on the switch like this.
BENEDIKT STOCKEBRAND: And using 48 VLANs, if you think about it, okay, so it doesn't scale because we only have 4 KV LAN ports but we do that in single switch and we have multiple of these, gets us 48 trust and failures domains so we can separate things. We have talked about that for more than ten years but this was when we tried to push it to the limit and see what happens, what breaks. We didn't really manage to break anything, at least in the set‑up we used. What we did was, a /64 per port per network, as of RFC 4291 Section 251, whatever. It's a /64, end of discussion, no matter what your implementations allow you to configure. Run out of configuration. And the one thing you need for the next slide is you want to set the other flag, which means that there is more configuration available via the HCP. Unless you work in environment where you don't need it, the general case that frequently doesn't have, especially if you have some older Windows versions like Windows 10 before update which doesn't do the DNS configuration through DNS SL and rDNS S, and what do you do then is with take the switches, whole pile of them, and we run ‑‑ use layer 3 switches and we run a routing instance on them so we can actually route the aggregated network through them on the individual layer 3 switches.
WILHELM BOEDDINGHAUS: What does that mean? That means that you don't need ‑‑ for DHCP 6 any more, you know which network runs on which network and who is connected. You don't have to consult your DHCP database for knowing who has an address today. The client has to register in the DNS because it just uses slack for configuring its address or the address changes every morning, no problems with data protection there but you don't need stateful DHCPv6 any more, the whole infrastructure can go. If you today authorise database success on IP number which I think isn't a good idea at all, you can do it tomorrow on whole network. This network is reserved for one client and you can have stateless DHCP, of course you need that for DNS, NTP server, you can do this on direct switch if you want to have it decentralised, smaller router that should be enough for stateless DHCP, just for giving out a little bit of information. And we think that this could ease the burden. Stock tock there is this thing about using the interface idea in IPv6 as a public key with 64 bits (stock band) secure nobody ever uses because 64 bit public key doesn't make that much sense even today, let alone in 10 or 20 years from now so the big players generally don't implement it anyway, and because we can't cryptographically secure Layer 2 and we have these issues with neighbour discovery, basically just having a effectively point‑to‑point link between the switch or router, layer 3 switch, and the end device means attacks using Layer 2 attacks, discovery attacks are impossible. And that prevents a lot of trouble. And a long time ago I thought that was an approach only for very extreme set‑ups but it actually works. And even if somebody misconfigures the client or plugs in yet another DHCP server that doesn't belong there it doesn't cause any harm any more and these environments and these set‑ups are real, some of my customers they are running dormitories in universities, probably the most hostile you can be in as a networker because everybody has to try everything themselves, and they keep breaking things where other people actually need network to work. That is where this becomes really, really helpful.
WILHELM BOEDDINGHAUS: So you even gain a bit of security, as soon as you have layer 3 interfaces you can put access lists on it, so you could have 48 with 48 ports, to restrict traffic to what should be allowed or shouldn't be allowed. You can't do that in a Layer 2 network, yes, there is something like VLAN access lists but this is cumbersome, here you can have layer 3 access lists. And we have no Layer 2 attacks other ‑‑ apart from other than the neighbour discovery things we talked about. If you have any Layer 2 attack that comes from a virus, from anything else, it is efficiently blocked because you just have a small, very small network. We still know about the voice VLAN, this might be very, very large in your organisation, but we have not looked into the voice networks and in the telephony systems, this is an area of its own.
BENEDIKT STOCKEBRAND: Yes. And once we move this path, so we have a layer 3 switch, means a switch plus router all in one box, we don't need spinning tree any more, we have point‑to‑point links, and we don't need to worry about making routers redundant. If you have a docking station for your notebook that has two Internet and you want to do failover go for it, go for it, but I have seen anything like that. If the switch fails you are disconnected anyway and the only thing you can do is, buy some reasonably small switches like these 48 port switches plus uplinks so it affects about 50 people but not 500 like big Nexus 9,000s or whatever, and with that you can also do away from the first top redundancy protocols like HSRP VRP which are probably not much of an issue to you but which are an issue to a lot of people doing networks in enterprise environments because they are not necessarily as fit in networking as you are.
And what do we do then? We aggregate the subnets on single switch and do dynamic routing to whatever sort of backbone from these rack switches.
WILHELM BOEDDINGHAUS: So we said yes, what about IPv4? We think we should use a tunnel. You might have done this before, that you have used a VPN from here to your home network, and all of your applications still run, hopefully. So we think we should use the same technology on your workplace so you have a VPN running from your workplace to VPN server somewhere in your local data centre, in‑house, MTU should not be an issue, you can control that because you have all network elements in your hand. Because if you use a tunnel we need some extra bites for the tunnel header. But we have not come up with what VPN we should use. So there are a few options, Microsoft, remote access servers, we have at that built in, OpenVPN, checkpoint VPN, Cisco, pulse, secure, anything could be possible. You just run it in‑house and bring IPv4 with this technology on to your work space.
BENEDIKT STOCKEBRAND: Basically, if you think about it, we are doing 4 over 6. For those remember 6 over 4, which had the basically the same design principle, we have an IPv4 network and we get IPv6 to individual machines. We do it the other way around, we have got that far, finally. So, we deliver IPv4 to individual machines. Nice thing about this is, we can actually turn this off for individual machines as needed, which is much nicer than having to switch it off in data centre because there is this one application that still needs IPv4 no matter what and keeps you from disabling v4 at a large scale. With this, we disable it where we don't need it any more and we tried a couple of things in the lab, Microsoft has some VPN clients with the OS, the reason why we did this now even though we are both now not really Microsoft fanatics, is because in many enterprises people think it's from Microsoft it must be good and secure and whatever. And of course there is also the reason but anything else costs money. Which obviously doesn't apply to OpenVPN. And it works and it's been working ten years ago. And Microsoft also has this remote access server which does this, what doesn't work direct access, because direct access expects to transport IPv6 to the tunnel and with that, we don't know how much longer Microsoft will support this sort of stuff with their own board stuff but we tried OpenVPN and it just works.
WILHELM BOEDDINGHAUS: Yes. What is key is that everything has to be installed automatically. We have to ‑‑ you have to deploy it on the client with your install script. So there would be a lot of work to do for your client people, because you have to change the install scripts, how you install the Microsoft client. The RIS server needs certificate authority, that can be done. But you don't need strong encryption, maybe you don't need at all, because today it runs unencrypted through your network. A littlbe bit of encryption, maybe would make it more secure, some others tell us it does not because we want to see each and every packet in our corporate network. So you could use Opensource software if you can't use the micro source RA S services because maybe extra software is not allowed and maybe the security policy of your corporate customer demands closed source software because Opensource is so dangerous. But if you have closed source software like checkpoint client or a client from Cisco, then you might need to pay extra for licences. This is a disadvantage if you can't use Opensource.
BENEDIKT STOCKEBRAND: On the other hand, I don't think I have seen any customer in the last couple of years who didn't have some sort of VPN client, all notebooks deployed throughout the organisation so they have already paid for it anyway.
How do you proceed with this? You enable routing on your v6 routing on your rack switch. You might want to keep your own VLAN structure around. There is the telephones of course, when you do a migration you don't want to spend a long weekend disabling IPv4 everywhere and starting IPv6 everywhere in entire organisation, it might work in a small place but not in a real one so you just keep your existing VLAN structure for v4 and then start to reassign ports to a new ‑‑ to your new IPv6 world and eventually you find that you are stuck with a couple of things that you can't migrate, then you know where your problems are so you just isolate these, leave them in the whole VLANs and ‑‑ either you pay me money to replace this or you pay me money for keeping this alive with all the extra time I put in.
WILHELM BOEDDINGHAUS: So as a summary we want you to go to IPv6 directly ‑‑ so this is what we suggest at least, no dual stack in the corporate lands, because dual stack as we all know is a great pain. And IPv4 is a service. I know here there are a few people in the room who know this and want to propagate this. We still have some open items with this, the VPN client, can the VPN client register in DNS can clients expect us that everything runs as it did before. They want us, they want their application to be accessible and want to see the interfaces in DNS and everything should work like before. Short of the DHCPv6 that we hopefully don't have to activate, the stateful version. I think this brings us to the end of the presentation. So, please come to microphones and tells us whether we are total idiots or whether this could be solution that might work out. Thank you very much so far.
(Applause)
JORDI PALET MARTINEZ: In one of your slides you said 6 over 4. I am not sure that is what you meant.
WILHELM BOEDDINGHAUS: We said 6 over to 4 to remember that we connected IPv6 islands over IPv4 and we want to go the other way around, in this office network situation it was an example for tunneling and migration technology.
JORDI PALET MARTINEZ: I got that, I think you meant 6 ‑‑
BENEDIKT STOCKEBRAND: We meant 6 over 4.
JORDI PALET MARTINEZ: Over a multicast ‑‑ 6 over 4 is over multicasting ‑‑
BENEDIKT STOCKEBRAND: You find the server using a multicast yes. You could use ICE dep as well. The important part is you assume you have v4 only environment ‑‑
WILHELM BOEDDINGHAUS: We are not using 6 over 4.
JORDI PALET MARTINEZ: You are not talking about 6 over 4 protocol, it's a concept. And you do ‑‑
BENEDIKT STOCKEBRAND: Yes.
JORDI PALET MARTINEZ: You do it on the reverse.
WILHELM BOEDDINGHAUS: We meant it as one example of tunneling technology to show that we use tunneling for IPv4.
JORDI PALET MARTINEZ: Got it. Using one /64 for every host is becoming an RFC in the next couple of weeks. You probably are aware of that.
BENEDIKT STOCKEBRAND: I was aware there was discussion going on ‑‑
JORDI PALET MARTINEZ: It's almost done, it's in the review phase, so actually I think this is a wonderful idea and that is the way we are thinking also in ‑‑ at least some people. I am also trying to let the people understand that IPv4 can be run as a service on top of IPv6 only networks so we are in sync. Thank you.
ROB EVANS: To follow up on what Jordi said, and I was going to mention have you read draft IETF v6 office unique, prefix per host? And if you have, it probably would be worth a name check in the presentation.
BENEDIKT STOCKEBRAND: I am lagging behind reading RFC drafts, there is so many of them these days. It's not like ten years ago where you could read them ‑‑ there were only two of them out there a month or so. Things are picking up speed. I knew there was some discussion going on there in the IETF but I haven't had a close enough look to see what was going on. And the ideas about this are actually not that new, it's just we found some time to spend a bit of time in the lab. We needed an excuse for that.
WILHELM BOEDDINGHAUS: Because if you just think about the fact that you have a /64 per host, it doesn't solve all this Microsoft stuff around it because you want to have this DNS registration and this other stuff, domain membership, you can't ‑‑ can't just say a 64, you need all the other stuff being solved, otherwise this would not fly.
AUDIENCE SPEAKER: Chris talking for myself. I really like this. I will try to do something on this in my office. But I have an older Juniper switch so let's see if I get the DHCP stuff running on it because it sends DHCP packets. This is the first thing. Then I really fear of going with this to a customer but I will try.
Next thing is, question: What do you suggest with wireless clients? Are you suggesting to enterprise with per VLAN?
BENEDIKT STOCKEBRAND: Wireless is really difficult and that is where the ‑‑ to my understanding, the idea of private VLANs came from because they are really difficult to get under control. The point there is that radio is multiple access, no matter what you do, and ‑‑ in the lower layers. I don't think there is a very simple answer to that. However, if we find a way to do this in a simple way, get rid of the problems we have with broadcast and large scale multicasts in large scale networks ware huge problem as such, we only had limited time to play around with these things, and we focused on the real large scale things we have, like 20,000 desktop computers in a single office building, for example. That was the sort of scenario we had in mind because we had to start somewhere.
AUDIENCE SPEAKER: I offer that we can play on the wireless side and find W
P enterprises per VLAN and just try this out, I am open for this.
JORDI PALET MARTINEZ: This document that I just mentioned, unique prefix per host is actually meant for wireless as well, and ‑‑ so it's done.
LEE HOWARD: As a vendor of IPv4 that serve services I applaud this design. I have two questions. The first is, the layer 3 switch, it's been a while since I have work in enterprise networks, I am not in this space right now, isn't a layer 3 switch more expensive than Layer 2 switch? It's just software, don't have you to have to pay more and upgrade your Layer 2 switch?
WILHELM BOEDDINGHAUS: Usually they are a bit more expensive, don't mix up with routers, they don't have the routing capacity. But even if they are ‑‑ a little bit more expensive I think it doesn't really matter. You get so many advantages: Security, scalability, you don't have to run DHCPv6 in the stateful manner. I think the extra cost is not so bad. But yes, you can't buy the cheapest switch from the electronic market next door.
LEE HOWARD: Sort of similar question on using VPNs, it's sort of inside the enterprise network. I notice that you use ‑‑ you talked about it's per client licensing which you probably had because it has VPN already, I might say, all the mobile clients do but desktops may not unless they are included with the operating system, but don't you still need to have a VPN concentrator which may not be the same as what you are using for external access for the trusted perimeter?
BENEDIKT STOCKEBRAND: But it really depends on how much IPv4 traffic you actually have. So if you have users who do video editing all the time over IPv4 yes, it's going to get expensive. But if you only have a couple legacy applications that people occasionally use which are urgently meant for 10 megabit cable Ethernet anyway it doesn't really matter. This is where you have to look at the particular situation, what I need, how much v6 traffic do I have, does it make sense to set up something that doesn't do encryption, like you can disable encryption on OpenVPN but it's extra work or do I use Cisco, any connect that isn't sold on all the desktops? And they are sitting in docking station and it's there and you spend a couple of thousands euros, dollars, whatever, for the server concentrate or whatever and be done with it. That is a decision you have to make in a particular set‑up.
LEE HOWARD: That is a fair point. Did you consider existing transition technologies instead of VPN technology.
WILHELM BOEDDINGHAUS: We don't know how to configure this on regular Windows system because there must be something like geoR tunnels because it is used by other protocols but we have not found the knob to configure it yet. We have to find something that is easy to configure. Think about the ‑‑
LEE HOWARD: Jordi and I will do it and get back to you.
WILHELM BOEDDINGHAUS: We are looking forward to the discussion during the evening.
AUDIENCE SPEAKER: There was a question by ‑‑ do you see scalability issues because of the rooting between hosts instead of L2 switching?
WILHELM BOEDDINGHAUS: Read it out again, please.
AUDIENCE SPEAKER: Do you see scalability issues because of the rooting between each and every host instead of L2 switching?
BENEDIKT STOCKEBRAND: Not if you do it right. If you have a single route to every single switch, an aggregated route for 48 ports or whatever and you connect those to your backbone, you have one route per leave switch, that shouldn't be much of a problem with today's hardware. I haven't seen anything run into really serious problems like that in enterprises I would consider normal by my standards at least. It shouldn't be a problem. Not if you get the aggregation right. That is the binge thing you have to take care of.
ANDREI: Question about the IPv4. Are you considering using like private IPv4 addressing for the machines or private? Because if it's private, I don't really see a reason why we wouldn't you use the same technique like dual stack on every single port with small DHCP server because there is quite a lot of IPv4 space?
BENEDIKT STOCKEBRAND: Dual stack hurts. It's twice as much work, twice as many problems, so that's one of the key reasons why you want to avoid it.
ANDREI: Much VPN is much worse problem I guess?
BENEDIKT STOCKEBRAND: If you have regular, for whatever definition, office network where there is mostly Microsoft and got everything except for Skype to work with IPv6, you don't ‑‑ frequently don't have that many machines you have to worry about. And dual stack makes troubleshooting hard, especially if you have to deal with people who are not that fit with their own networks. And this is going towards sun setting IPv4 really, so there should be all machines involved there. Other than that with private addresses or not, we will leave that for the social because that is a lengthy discussion.
WILHELM BOEDDINGHAUS: There is another reason for not doing this. In IPv6 we have got this neighbour discovery mechanisms, the router announces itself by router advertisement and the client is able to generate an address. This is not possible in IPv4. If you have 10,000 office networks you don't want to have 10,000 DHCP pools with one address in it. Usually you don't want to have that. So how do you get the IPv4 address on the client and on the router and you have static configuration on the client and usually you do not want to do this.
ALAIN DURAND: From ICANN, speaking on my own behalf. I am very happy to see what you are doing. I think it's very interesting. It was envisioned when we wrote the DS‑Lite 6353, if you look at Section 4 it explains how you can start straight from the client, where you are doing is functionally equivalent to DS‑Lite model started by the client itself with or without a NAT. And I think it's great domain of application for this, the idea of removing the v4 routing inside of a network as owe and potential to simplify a lot of things and keeping v4 had as a service like that is great so.
WILHELM BOEDDINGHAUS: We took a lot of ideas, and running IPv4 as a services one of the main reasons for doing this is that you can turn it off and then you are done. You don't have a second migration project from whatever dual stack. You do it in one step. And this is one of the main ideas and then you are done and this is fine.
ALAIN DURAND: One of the things we envisioned back then was to turn it on on demand. If node, just when it needs it.
WILHELM BOEDDINGHAUS: Thank you very much. Get into contact with us on the dinner or we have got our address data in the slides if you are interested. So we are looking forward for the discussion. Thank you very much.
BENEDIKT STOCKEBRAND: And thank you for the encouragement, we weren't exactly sure if we were on a wild goose chase.
JEN LINKOVA: Awesome, it was great. Really lightning talk stage. Jan is going to tell us about what is going on in best current operational practices.
JAN ZORZ: Hello. And I will be very, very quick. As you probably know, in the BCOP task force and in cooperation with all of you, the RIPE IPv6 Working Group we managed to get the consensus on the IPv6 best current operational practices document, and it's about how to assign the prefix delegations to end users and what are the sizes. So this is a little bit of the history. We needed nearly one year from when I created the document on the Google docS and then to get all the team together and it was published as RIPE 690 on 16th October 2017. That is table of contents, as I mentioned this is basically the advice to the operators. If you are ‑‑ I am sure you are, deploying IPv6 to your ‑‑ to the end customers and your business customers, this is what you should read and follow because there is quite a good group of people that agreed on either this is the best operational practice, executive summary, of course, wrong choices when you are designing a RIPE IPv6 network may bite you back later so lots of people, I met lots of people that just were not happy with their decision and the first time and then they had to redo the whole stuff to understand IPv6 is not the same as IPv4, please don't bring old mistakes and bad habits from IPv4 into IPv6, we heard a lot of this today already.
Strongly discourage to assign prefixes longer than /56. There is no technical viability which you shouldn't go /48 for everybody but there are some reasons why some people go down to /56. Don't go with smaller prefixes than that, or as we say longer.
In order to facilitate troubleshooting, please if you want to keep yourself out of trouble, using ‑‑ consider using numbering the one links using the global unique global addresses, and non‑position prefixes are considered harmful. This means that currently, as we stand with the support in the CPEs, if you change prefixes every time your user connects, you will get into trouble. Most probably you will get caught on your help desk.
So, I would like to thank all my co‑authors, if you see yourself on this list, let's do some exercise and please stand up. Please stand up. I think they need a big applause.
(Applause).
Thank you. There was lots of work done.
We also had some ‑‑ a bit more than average active users, active members of the communities sending in suggestions, comments for improvements, they are all on this list. Thank you very much. And also thanks to the Working Group and the co‑chairs for all the support and to guide us through the process and get the consensus at the end. We are done with this, now what? Now we are getting bored a little bit. I heard some new suggestions for BCOPs today. We probably could start the BCOP based on Geoff's work and make some recommendations on how to do this stuff, but I am travelling around the world talking to operators and I started to see again, as for previous BCOPs, I started to see again the common sort of like pattern of a problem, e‑mail, I am asking people why not enabling IPv6 for e‑mail servers and people go yeah, yeah, yeah, we are sending it out on IPv6, that is not a problem. But for receiving e‑mail, we are not enabling IPv6 because there is no anti‑spam system, there is no IP reputation‑based system, so how do we survive on IPv6 if that we can't protect from all the spam and yada, yad, and all this common excuses. So I thought of writing best current operational practices and document some good practice how to run your incoming mail server on IPv6 and actually survive.
So, what we would like to do is together ‑‑ to gather a good group of people, of quarters, that has some operational experience, that are running mail on IPv6 and knows how to do these things and maybe start a new BCOP document. Any takers? Any volunteers?
JEN LINKOVA: We have a volunteer. People will come to you in the coffee break and during dinner.
AARON HUGHES: I know, I am hard to miss. More than happy to help you write the document. I am not sure I would limit it to incoming; happy to write the best current operational practices for config and DNS SPF records, etc.
JEN LINKOVA: I see a few other hands so I am pretty sure those people could find Jan but we are running out of time. We have one more lightning talk. So thank you Jan.
JAN ZORZ: One very, very short question. Do you people think this would be useful? Hands up who thinks this would be useful? Wow. Excellent. Who thinks this would be completely not useful?
AUDIENCE SPEAKER: Can't be done. Technology doesn't exist, too soon.
JAN ZORZ: Thank you very much.
JEN LINKOVA: Thank you.
JORDI PALET MARTINEZ: I was originally told you have 15 minutes but I have only three, like usually happens. So I guess most of you know about Happy Eyeballs. Just a quick reminder Happy Eyeballs was invented in 2012 because transition technologies give preference to IPv6 but sometimes if your IPv6 path is broken you fall back according to the transition mechanism designed, you fall back to IPv4 but sometimes this is taking too long. So with Happy Eyeballs what we are doing is, looking at ‑‑ with Happy Eyeballs what we are doing is we are looking at how much time is taken before v6 and then we decide which one to take. So even if the difference between the IPv4 delay and the IPv6 delay is too short then we still take the IPv6 route. So first thing here is to thanks the authors of Happy Eyeballs which are David and Tommy from Apple because they provided me the graphics so I don't need to make the graphics from scratch myself, this is the way version 1, that is the one that is implemented today in most of the browsers and operating systems is doing, basically is doing ‑‑ it waits for Bot AAAA query and A query response before restarting the TCP SYN. So that is what happens, until you don't get Bot responses you haven't wasted time. So what happens is that Apple has been thinking on this during some years, has been implemented already in, I guess, billions of Apple devices since long time ago, they did a lot of measurements and they started working after they did already test it, this protocol in their devices, they decided to write down an updated version of Happy Eyeballs which we call Happy Eyeballs version 2, and what it's doing is, accelerating the user response because we don't wait any more, for this wasted time, by doing the query asynchronously, instead of waiting for the response we do both queries at the same time and the first that comes it's taken.
So this is the solution for the problem. Okay. Of course, we have still this preference that depending on how much is the delay, we can still decide if we take one way or the other and what we are actually doing is changing the default address selection for IPv6 in a different way. What you have in your lab is the default address selection and on the right you have what Happy Eyeballs 2 is going to result on.
So, is Happy Eyeballs good or bad? Well, for users it's good, but from my experience deploying IPv6 networks it's hiding the IPv6 problems so what happens is that many people, many operators, if they don't do their job correctly they are not monitoring Bot directly for networkds and what happens is because they don't get user complaints, or most of the time they don't get them, they don't realise and I have real customers with this situation for one problem with IPv6 routing broken and they didn't notice it because it's falling back always to IPv4.
So, I decided to start looking at how we can improve that, basically Happy Eyeballs is solving part of the problem as the fall back to IPv4 but not solving the ICMP filtering that Geoff mentioned before, one of the problems that we have and we have no other solution like for that which Happy Eyeballs, I try to see if we can sort it out with Happy Eyeballs but it's not possible, it's a different level. So what I am trying to do and I am not going to extend on the slides, you have all the information on the slides, what I am trying to do is set up a way to use existing protocols which is syslog, with UDP port 514, very simple way to report as a kind of extension to Happy Eyeballs, to report when Happy Eyeballs is falling back. So it means it's finding problems in the network. And I stop here. You have the rest of the detailed information about how I am doing that, I am not inventing anything new, just using existing protocols to solve the problem. I would like to send a new version of this document which right now is in version 0, I would like to send a new version next Sunday, in three days from now, this week, so if you have any comments, it's a short document, please read it, catch me in the social or tomorrow very early in the morning and I am happy to include any comments that we might have on this document right in time for the next TIF.
That is it. Thank you. Four minutes instead of three but it's okay.
JEN LINKOVA: Amazing, thank you very much. And apologies for the time.
(Applause)
So this concludes this session. Please rate the talks and I do hope that actually most of the people will stay because I assume in 25 minutes it will be a workshop here, IPv6 related workshop about transition technologies. So, we can hopefully can live in IPv6‑only world. Thank you very much. See you In Marseilles.
(Applause.)
