RIPE 85
IPv6 Working Group session
26th October 2022
12 noon
.
RAYMOND JETTEN: Welcome to the IPv6 Working Group participants. We have a hybrid session so there is people going to be online and all of you here are going to be on site. Please, use the Code of Conduct for your behaviour here, and please remember that this session is being recorded.
The minutes, they have been published a long, long time ago on a list and I haven't seen any comments, so with this, if there are no comments here, we can accept them I think.
No one any comments? No, good. They are accepted.
Then we have something I cannot do.
BENEDIKT STOCKEBRAND: Or you don't want to. So, one more thing, for personal reasons, Jen can't be with us this time, she'll try to be with us remotely, but she can't be here with us.
But the reason why Ray wants me on stage for a change, his term as a co‑chair is up, and we have sent a notification to the mailing lists, nobody else decided they wanted to do it, Ray is happy to do the job, I am happy he is doing the job, so, this is your last chance if you are so unhappy with Ray as a working group Chair, that you actually want to take over. 3, 2, 1... okay, your job again.
RAYMOND JETTEN: Thanks. Strange hobbies I have, I know, but it's just the way it is.
First up is Pablo from Cisco, and he will have a presentation on path tracing. Thank you.
PABLO CAMARILLO: Hi. Good morning everyone, many thanks for the introduction, Ray. So my name is Pablo, I work at Cisco and I would like to introduce you to a project that we have been working on for the past 24 months and it's called path tracing. And so first let me introduce the problem that we are going to try to solve.
As always in the routing project we try to go back to the route. We try to go back to the purity of IP and ask questions.
How come that if I have a packet from A to F, you do not know, and likely many of you but maybe most of you, do you not know how this packet was forwarded from A to F. From a reality point of view you do not know because there are there is valid ECMP paths and it's hard to know which one out of those three it taken. There could be a corruption alone the packet delivery path and this packet has taken a completely different path out of these three. So path tracing is going to deliver a solution to this problem. And it's going to tell you how the packet was forwarded in general network and then on top of that it's going to tell you how the time was spent in between the nodes A and F, because maybe we have a router that is introducing a significant amount of latency. Or it could also be TTL case that for example, we have one router that is introducing crazy jittering, on top of the path visibility and the timing we are also going to record what is the load at the egress interface queue so that we have this full visibility.
So, only node path trace something going to give you a full characterisation of how the packet was forwarded. It will tell you what are the routers that the packet was forwarded through and the state of each one of the routers in your network. And we're going to do this by monitoring the most basic pipeline of router. So the actual pipeline that is used forward forwarding your customer packets, which is the most important thing.
And this is really a 40 year old unsolved problem. Up to now we did not have this visibility and really we believe that this is an important step to give this information.
So, let's see how it works. It's very easy. So what we're going to have is we're going to have an IPv6 packet source address A, destination address F, this header is going to be followed by the path tracing header. The path tracing header is nothing more than IPv6 hop by hop extension header. It was defined more than 25 years ago and this hop by hop extension header, what we will have is the path tracing option. It's a new options that going to be a metadata scratch path. It's going to be a blank piece of paper where each one of the routers along the delivery packet delivery path is going to write three things, the outgoing interacity, the time stamp and the load.
So, in this packet in this example that we have here on the right, when this packet is about to leave the route, what is going to happen is router is going to say I am about to forward this packet on interface at this particular time and load. Then the packet arrives to the router B on the router B I am going to perform my regular packet processing so I am going to do my forwarding look‑up, and so on. And then before I put this packet on the US Internet, I am going to record on this header that the packet is about to be forwarded on the interface from B to F at this particular time and load and so on.
So, basically you get all of path visibility and then on top of this path visibility you get a time stamp and the load at each one of the hops. And these full visibility we are getting it with minimum NT overhead. Each one of routers you along the packet delivery path is going to encode these three things using 3 bytes per hop. Okay. And that is really important because to actually to make any solution of this kind work, what we need it is monitor the most basic pipeline of the router. Any solution that would pan this packet to the router CPU and attempt to process this packet using forwarding tables return the same that are the ones used for your customer packets is not going to be useful at all.
So we have to designed this entire header from a scratch so that it can be implemented at line rate effective on any packet. Actually that has been one of the keys when we did this project, that is really to instruct the routers get most of the router capabilities so that everything it be implemented in the regular MPU. Because we do not want use ‑‑ because we want to get the real data and to get the real data you need to us auto the same forwarding path as for your customer packets. Plain and simple.
So, we have minimised the complexity first by doing this smart or simple data plan design on top of it we have also minimised by leveraging as much as possible, let's see... basically what is going to happen is that all of our routers are going to better the pair minimum functionality which is to collect information from the packet forwarding pipeline, and then we are just going to forward all of this information to a commodity server where we are going to have an analytics application that is processing all of this and doing some analytics.
Now, these functionality, the line rate processing and adding of the interface ID, time stamp and the load it's already implemented. It's already under deployment with some operators, it's going to be shipping, which is just a few days away, we have got this general availability in November. And we have this runnnig on the Cisco 8,000 which is based on the silicone run, we have running on the NCT 57,000, aNy Jericho 2 ... etc is going to have it. As well as this. On the Cisco 8,000 as well as on the others, this functionality is native on the ‑‑ you want to white box using a sonic, you will have their the path tracing functionality.
Now as always we are working hard to have our checking system. When we started this system we were sharing this with others. And we iterated several times on the data plain that we accommodated the data plane to all of the different A6 that are out there. On top of that we have worked a lot with different academic institutions to deliver an open source ecosystem. So, we have open source implementations available in the Linux kernel, F ID PP, we have an open source implementation etc.
.
And from an ATF point of view this is released an ongoing standardisation.
So now that we know that this data plane is already working and it's already available it's time to look at the use case that is we are enabling which to me is the most interesting part.
And so, to me this is the most interesting part. And so the first use case, it's EDM which is stands for EMT data plane monitoring and it's related to corruption, eruptions in the hardware. So there are certain situation that is may lead to the drop of traffic that the destined to one or more prefixes. Okay, or maybe instead of dropping this traffic it may lead to forwarding these packets through a path that is completely different from the expected routing path. Now, these may be for different reasons. It could be for example inconsistencies between neighbours, control data plane inconsistencies in the routers or it could be that there is a bug in the hardware itself. And the thing is that we have seen that some of these issues are lasts for more than a year in some networks. So really it's really significant.
Now, the problem is that they are quite challenging to detect. This is quite challenging because it is not all of the traffic that is affected. It's only the traffic that the hashed into the one path where we have the corruption that is hitting this issue so it's difficult. And when we is that right troubleshooting it's not we have many tools available. The first thing we would do is do a show command in the router but the show command it will tell that you everything is okay and not show the issue. Then we will try to do a ping on traceroute, but they are kind of basic and they will neither show the issue nor give you any valuable information. So the only way that we have seen some people trying to solve this issue today is basically by floating the network with probes and then trying to ‑‑ and this approach they don't have the network visibility ‑‑ and then they put all of these huge dataset in some sort of intelligence why the hope of trying to work it out. Extremely complex and expensive.
So, it's really problematic that we have a very basic issue in the network and we do not have any tool to just simply to say whether your network is running okay and it's good. So with path tracing we are delivering a new mechanism to solve this. The way it's going to work is we are going to send a few probes each one with a different flow label it's going to explore all the different. Once of all these packets have been received on the analytic side we are going to have access to two pieces of information. The first one is going to be all of these probes that are recording all of the state of interface IDs that the packets has traversed. We have the forwarding reality. Then the analytics because it's working hand in hand with a PC, it has also all of the topology, it has all of the expected paths based on the routing information. So then we are just simply comparing two pieces of information and we are able to detect if there is any inconsistency in the network.
And so, we are detecting this inconsistency and we can continuously monitor and tell you whether your network is okay, whether you don't have any issue in the network and this is significant because in most of the cases with he do not even know if there is an issue. So, up to some extent a simple analogies like a blood sample, like every year you go to the doctor, you take a blood sample they analyse and they will tell you that you are okay and you can go another year or to the contrary they will tell you they have found something strange and you need to do further troubleshooting. This is the same.
Basically what we are going to detect is three things. We are going to detect an unexpected ECMP path that is disrupting all the traffic. It's basically a black hole. We are going to be able to detect an ECMP path that is going through a path that is not expected that is not the one that should be according to the routing. And then we are going to also be able to do a third thing business incoherent latency between EM CP paths. If we have four different paths I am expecting the four paths to be within the same latency range. If there is one path that has a significantly higher latency, then usually this is not expected. Then this is also something that we are going to highlight to you.
The second use case is going to be related to jitter, if you think about it now with all of these ECMP data plane monitoring what we created is a huge dataset because we have a lot of probes that are traversing the network and for each one of these we have got a time stamp. Each of the intermediate routers along the packet delivery path. We have a time stamp with 0.6 millisecond accuracy. What we are going to do is we are going to reuse this dataset in a different way, we are going to start again the dataset but we're going to folk on a single router and I'm not going to care about which was the source or destination of the probe packet. I am just going to care about all the probes that transfers one particular router. And for all of these probes what I'm going to do is compute for each of the one of the interfaces I am going to compute the jitter. So basically I'm going to take the probe, the time stamp, I am going to take the time stamp on the previous neighbour, I am going to instruct the stable preparation latency, and so what I end up with the latency that is introduced by the node and by the egress interface queue. So with this information I am going to record it over time. And I'm going to create my jitter statistics. I am going to compute the minimum, the average, and so on and I am going to do this across it all.
And this is already quite significant. Because today, we do not have any measurement and so it will be the first time that we have per node jitter measurements with such precision in the live network. So it's already a big step.
And then on top of this what we are going to do with the analytics is continuously monitor the jitter and see how it's evolved. Basically we are going to see if you exceed a particular stress hole and then compare that you will of this jitter information with information for the neighbours, with historical information, what the jitter one week ago same sometime of the day and so on. We are putting this with basic learning tools.
All in all we'll jitter analytics is significant because it's the first time that we will have these analytics. At least with this accuracy and on the live network. And really, that's all when we started the segment routing with we did a lot of simplification already. With did one more step in the simplification by removing the MPLS data plane and now with path tracing we are solving this for the problem. We believe that this, these. The path tracing has significant applicability for all of the transport assurance. The technology from a data plane point of view is seeping, it's already out there and available. We have a recheck system not only between different vendors but with open source. We believe that there are a lot of exciting opportunities with the analytics.
So that you know very much for your time.
(Applause)
RAYMOND JETTEN: Any questions? I see one person coming up.
AUDIENCE SPEAKER: Hi. Ly and row, University of Twente. Thank you for the presentation. One thing that seems similar to me at least, IPv4 record option. Do the same thing, okay, here you have latency and everything, but that one was used to record the path of each route. But it was not ‑‑ it is not more used to the Internet because some security problems. This one, I don't know if it's just planned to run inside the autonomous system or the whole Internet. Can you give me more clue about that?
PABLO CAMARILLO: Thank you for your question. So the intention for this is to run within an autonomous system. Within a service provider network where you have IPv6 enabled for your transport on top of it you add the path tracing to get all of this visibility. And really the key difference, or to me what is the breakthrough with this approach is that we are recording all of the information from the most basic packet forwarding pipeline. And that we are really recording that information at line rate so if you want to do it for all the pacts you could do it because it's really using the same forwarding table as your customer packets. And so to me that is the biggest, the difference and actually that's what led to having this data plane where we are using 3 bytes for each one of the nodes to record the time stamp the load and the interface ID. And yes, it's meant to be used within an autonomous system. Thank you.
AUDIENCE SPEAKER: Another question is, normally you have an identification that you put for the path, yeah? In the solution that you have, you have an identification to identify the path or the router itself that the packet passes.
PABLO CAMARILLO: What we are recording is a sequence of interface IDs.
AUDIENCE SPEAKER: But the input interface I imagine, or the output.
PABLO CAMARILLO: The output interface at each one of the routers.
AUDIENCE SPEAKER: And the identification of the router itself?
PABLO CAMARILLO: You would need to see more details on the solution but basically we only have an idea of the outgoing interface but when you see the entire chain of interface IDs you are able to tell the whole path that the packet went through. You are able to tell the node, the interface node etc.
AUDIENCE SPEAKER: Okay. Thank you very much.
RAYMOND JETTEN: Okay ‑‑
AUDIENCE SPEAKER: Alexander Azimov. I wonder if this technology is supposed to work in the MPLS core?
PABLO CAMARILLO: We could make it ‑‑ I mean there is a data plane designed for MPLS, however to be honest, it is not implemented. We think that IPv6 is providing us some facilities. And what it's already shipping what it's implemented and where we have this functionality it's on IPv6.
AUDIENCE SPEAKER: Okay. I got it, so you are targeting an IPv6?
PABLO CAMARILLO: Yes.
RAYMOND JETTEN: Okay, there were no questions on Meetecho I believe. Okay. Thank you.
(Applause)
.
Next up is Nico Schottelius.
NICO SCHOTTELIUS: Hello everyone. So, thanks again for having me here, it's always a pleasure being at the RIPE conference and today I'm going to speak a little bit about NAT64 on Open Source, or only open source implementations, so for me that was interesting because the majority of the network community is using hardware devices because, you know, we need to forward things at a high line rate. However, from my perspective it's important to look at the open source side of things because there is a lot of innovation happening and you can steer or control things very dynamically or let's say createively.
I guess everybody here in this room is pretty much aware that on the one hand IPv6 deployment is growing, you have seen the graphs and you are aware of this. At the same time, what I see is also a lot of NAT64 deployments are growing basically because we are switching more and move to IPv6‑only networks, which eventually have to actually come to the IPv4 Internet.
.
Obviously there are alternatives like Map T and co but I don't want to talk about those today.
But more about what is the status in 2022 about open source NAT64. Before going into detail, a quick question to the round, maybe everybody raise your hand, who is using NAT64 in their networks? That's maybe five to ten percent. Who is doing it in hardware, like in switches? OK and who is doing it with open source software? Hour there is maybe 70 or 80% overlap. All right, potentially you are actually using already what I am going to talk about, and that's good.
What I'm going to show today is more or less a summary of what we are at Ungleich having a look at or what we are from time to time testing. There might be other solutions and actually if you are aware later at the end of the presentations of other solutions, I would actually like you to come to the microphone and let me know what I forgot because I am always keen to learn from the audience.
So, I am starting with the first one, and I guess everybody who had a look at NAT64 must have run into tying TAGA, for me this is the classic or the most classic not 64 implementation out there. If I'm not mistaken, it's actually released not only released I think the last state of the source code is from 2007, so it's not the most fresh or new software. But it has a very nice approach and that is with TAGA you basically run a user pace. With a Linux you get a device you put in the packet and it does the translation. TAGA does not even do stateful translation so whenever you want to do stateful translation, you have to use the Linux kernel to do NAT64 to NAT 44, which sound a bit weird in the first place, but it's actually in a way quite elegant because as a NAT64 writer you can concentrate on your job at hand which is transform IPv6 to IPv4 and vice versa and don't deal with date mapping which is inherently not an easy task to do especially if you are coming to a lot of devices.
.
The disadvantage of this approach is that in our tests, tag an is somewhat CPU bound, I mean this is kind of expected every software solution will be CPU bound, but it's a bit early CPU bound. So this test is from two years ago, roughly two to three years ago, where the CPU at that time offered up to date Intel CPU with a 10 gig card were maxed out at 3 gigabit per second. That's all could you get there and TAGA's implementation is a single core implementation so you can't really scale out with the course that you have there.
That said, so if you want to solve your problem and go at higher speeds, there is a very nice alternative, which is called JOOL which is mainly coming from nic.amex, so from Mexico being kudos to Umberto, he is in Mexico I think at the moment. He did a magnificent piece of code and it's actually Linux kernel module support stateful and stateless NAT64 translations. And it's rather fast. So, in our test it was running at around 8.2, 8.3 gigabit per second on a 10 gig link. Actually utilising 2 out of 4 cores F I remember correctly. So there is some multi‑threading inside the kernel that is actuallying used by the module. The biggest disadvantage of the JOOL module is that it is actually out of concern kernel so you can't just take your favour Linux distribution and say I am going to use JOOL. You have to actually compile the kernel module or you have to have a Linux distribution such as alpine Linux which is actually shipping the pre‑compiled extra modules for the kernel. So, you have Linux distributions out there where you don't need to compile it yourself but it's still not in kernel so it's a bit of a ‑‑ not the most straightforward approach.
But yeah, then again, you get really fast translation.
Then there is something that is actually based on my team in ETH and there is some people around here who it's good to see from the time. I actually did my masters thesis on NAT64 translations in P4 in a somewhat portable way because P4 it is a language is portable. However, there is always a little bit hardware dependency in there so the promise of P4 for those who haven't heard of it yet, the promise of P4 is basically everything you can do you can do at line rate. Basically you programme inside the hardware or you programme inside the software solution, an emulation of P4, and everything you can do is done at line rate. So that's a very nice promise it sets out there.
The solution I coded at the time is, it's a birth faster than JOOL, there might have been some overhead, but eventually I was measuring around 9.3 gigabit per second on a 10 gig link, so you are ‑‑ I would say you are almost at line rate.
The disadvantage of this solution and to be very blunt, there is no production use whatever for it. So, I don't recommend using it in production, besides you are a bit adventurous, then just go a lead or you have some P4 equipment around and you want to give it a try, feel tree to. It also works with state tracking, so it's a stateful support, which is somewhat interesting because the switches are inherently not very dynamic, so there is an external control of it is actually keeps the state and the switches actually just communicated with the external Linux box to keep the state when there is a new translation that needs to be put in the state table. But then again, if you are planning on using this for production, please take 12 steps back.
.
Then there is something else, which might not be on everybody's radar, and that is Cillium, Cillium is actually ‑‑ we're leaving completely the network world and we're going into the world of containers, super duper infrastructures, large scale scaling and whatnot. And Cillium is mainly thought as a network interface for the communities world where your containers secretary to the world, or to everything.
Now, there is documentation about Cillium supporting NAT64. I haven't been able like to pinpoint where exactly it is, and additionally, because all of our infrastructure is IPv6‑only on the host level, I wasn't able to test it because Cillium doesn't run on IPv6‑only hosts at the moment. There is a GitHub bug for this, it's referenced there, and I am in touch with the Cillium developers so this can be solved.
It's based on EPPF, so it's ‑‑ EPPF is actually an in kernel programming language on the network level. You could say the idea is a bit similar to P4 but in the Linux kernel. So it's a very nice idea.
So having NAT64 solution programmed in EPPF would actually be quite nice. If you actually look at the EPPF documentation, there are hooks in there for the NAT64 translation already, so it's actually quite an interesting path to go down.
However, it is more thought to be used inside, it's not a general purpose NAT64 solution. Nonetheless you could say you have a pod that takes all your IPv4 traffic routed in there and you route it out again. No one stops you from doing that. That's also end solution.
Then there is something which I personally find brilliantly clean and nice, and I would like to get your attention just to the pre‑formatted lines in the middle of the slide. Where this is strictly PF language in OpenBSD. We say there is interface and if it comes in you pass it ‑‑ you accept the traffic, and you actually map from the well known IPv6 prefix to an IPv4 address. And it's just treated like NAT. Isn't that beautiful. We don't even have a notion of NAT64 here. It's just well there is some IP address on this side, some IP address on that side. I really admire this. This is like forget the concept of v4 and v6, it's just packet translation. It's brilliant. I really like it.
I didn't actually have the time to test the speed of this, unfortunately, I am going to do this after the conference, to actually see how fast we can stretch the OpenBSD writing system actually to translate. But from the approach, it's very nice.
Just five minutes actually before this session, I also learned there is an implementation on FreeBSD on IPFW, unfortunately I don't have a slide on this because I only learned just before this. There is yet another one on FreeBSD. Which is quite interesting to see, it looks like the BSD,s are actually in a much more stable or clean state when it comes to NAT64, where as Linux is a bit hack‑ish if you want it so.
In summary, what I see at the moment are TAGA, really easy to deploy if you want to deploy, just go user space networks special manager mission, no special in kernel support needed. Then there is JOOL, which is working great I learned it's also being used here at the conference, not only but also. Then there is P4 NAT solution which works, but hasn't been used in production. And Cillium and the OpenBSD solutions which I haven't tested from the speed. That's it from my side. If you know about more implementations or if you have other ‑‑ in the NAT64 I am very pleased to hear. This is basically an opener for everybody doing NAT64. If you have any questions after that, please see the contact details and then I will hand over to the questions.
RAYMOND JETTEN: All right. Jan.
JAN ZORZ: Thank you for this. It's very nice. Did you try VP P implementation of NAT64? That is supposed to be very fast.
NICO SCHOTTELIUS: Networks but it's very good to know about this.
JAN ZORZ: It does a pretty good job.
RAYMOND JETTEN: Any other questions? No. There is one on Meetecho.
BENEDIKT STOCKEBRAND: Jordi Martinez says "there is one more voice on NAT64, VP P, and he has included URL, so if you want to copy that, you'll find it in the questions and answers in the Meetecho.
RAYMOND JETTEN: There is still one at the microphone.
AUDIENCE SPEAKER: Yes, I will just ask, it's ‑‑ well the address side of NAT64: Do you know of any CLAT implementation, basically a very similar code possibly for Windows because that's one of the operating systems that is missing possibly a user space implementation of considerate?
NICO SCHOTTELIUS: For disclosure, I have no clue about Windows, so I am unfortunately really unable to answer the questions.
AUDIENCE SPEAKER: Thank you.
RAYMOND JETTEN: Okay. No more questions. Okay. Thank you Nico.
(Applause)
.
Then last but not least, on the a from the RIPE NCC, with deploying IPv6 mostly access networks.
ANDREJ CALETKA: Thank you very much. Once again I work for the RIPE NCC. I I am also part of the RIPE meeting tech team, so this is going to be sort of like preliminary tech report, because it happens to be that the main network of this meeting is actually IPv6 mostly, so I'm going now to tell you what that actually means, which is, long story short, written as the second title of this presentation, that means.
IPv6 and dual stack in one network.
First of all, if you are talking about access networks by access networks I mean networks where end user devices like laptops and phones are connected directly. We don't have many options how to deploy IPv6. The most common and the most usually called best mechanism is called dual stack, which basically means that we take IPv4 that is there, and we add IPv6 on top of it. Some people have even considered a transition mechanism but it's really just a transition mechanism to get to v6 only which should be the goal somehow.
This is working. Like there are ‑‑ there is special algorithm which is like ten years old all happy eyeballs which is trying to masking potential problems with IPv6 by switching ‑‑ faster switching to v4 if there are any problems. The biggest issue with this transition mechanism is that it doesn't involve the issue why we deploy v6 and it is that we don't have enough v4 addresses, because we still have to deploy IPv4 addresses and as a number of devices is growing, we have to deploy more and more IPv4 addresses being their NAT or being their even public addresses.
So, then we have the other option for the access networks, and it is NAT 64, NAT 64, out of all those transition mechanism has this night feature that you can use virtually unmodified end user device which will run on IPv6‑only, it's the bottom part of the connection, and the device will be able to reach IPv4 destinations because there is translation box doing NAT64 that will make part of the IPv6 space mapped into v4.
And with support of the DNS 64, the DNS pretends that every single host name on the Internet does have v6 address that is either native v6 or the v6 pointing to this NAT64 space and therefore your client does not have to be modified and works very well, but there are those small things like sometimes, for instance if you type in IPv4 literal into any app, then it will try to connect via v4 and there is no v4 so it will not work. Or you can have some very old software that is programmed how it used to be done in 1980s, or 1990s, with Openflow IPv4 in mind, so the software would not be able to use v6 and that will therefore not work on this network. And then we have this dual stack servers that are announcing in DNS both v4 and v6 address but the v6 is broken on normal dual stack networks this is masked by happy eyeballs by faster switching to v4 but in v6 only network there is no v4 to fall back so it's just broken.
So, because this NAT64 is very popular among mobile operators, actually mobile devices, or mobile operating system that means android and IOS are very ready for running on NAT64 networks by several things. Apple has this approach of trying to fixing the problems in the root. So they started by forcing all Apple developers to support NAT64 and since 2016, you cannot upload an application into app store that would not work well on NAT64. They also did up the Happy Eyeballs 2.0 which is sort of like happy eyeballs but extended for IPv6‑only networks so not only falls back to IPv4 but it always deals with IPv4 little loss or broken IPv6 on dual stack servers. And finally, even though the solution they probably didn't want to make but they actually even implemented the CLAT engine, which is the opposite of NAT64, which is basically a translator that translate v4 into v6 just to be translated to v4 at the other end, so basically double advance legislation, which is far from effective but at the end, it fixes the issue and it's only very small minority of the traffic that is going through this double translation.
In Android they took a much more pragmatic approach and the considerate is only the mitigation solution for everything so as soon as Android is connected to IPv6‑only network with NAT64 the considerate is set up so the applications inside Android consideration even that they use IPv4 or other software it will still work. (CLAT)
.
On the hops it's a little bit worse, because first of all the Happy Eyeballs 2.0 is only inside Apple and even on Apple it's only in apps that use high level IP Is like Safari, but not Chrome for instance, because Chrome is like an application that uses stand out Unix APIs. On Windows, there is virtually CLAT, but it only works when you plug in some mobile modem, but not if you connect to wifi. And on Linux, there is a package called ‑‑ from Tor Anderson, that's about it it's not updated.
Those are the small problems that are like really tiny, but still annoying if you are one of those users that are stuck with v6 only networks.
So the question here is: Can we do somehow IPv6‑only and get rid of this dependency on IPv4 at least for some devices like for the mobiles that are able to do v6 only right now already? And there is an answer for it and the answer is in RFC 8925 which is sort of strange option for DHCP, that is used for IPv4 address assignment, and the option is called IPv6‑only preferred. So, let's just go through first how this old protocol works.
So if the device connects to the network, it will send DHCP discover, and in the discover message it will also asks for parameters that should, it would like to request from a DHCP server like default gateway, DNS servers, NTP servers, whatever. The DHCP will, several DHCP servers will make some offer to this client, offering the client its IPv4 address as well as the parameters that were requested. And if the DHCP client decides that it's a good offer and it would like to use this offer, it will send a message request, and it will confirm yes I would really like to have this IP address, this gateway and so on. And at this moment, the DHCP server will make the reservation, commit the reservation into the database and send acknowledgment and that's what happens every time you attach a device to a network.
And in this case, this RFC makes only one tiny difference and that's this option number 108, that is here, and basically by requesting option number 108, the client is telling the server that even though I am requesting IPv4 address, I will be very happy working IPv6‑only. And in this case, the server is not configured to do anything, so the server is not going to off the option 108, and therefore the DHCP trust anchors continued as usual.
In case the server knows that the network that the client is sitting in is IPv6‑only capable, it will respond with option 108 in the offer to the client, and value of this option 108 would be time for how long the clients should turn off their IPv4 stack. So, basically once the client receives this offer, yeah, the server just is sending this information in this offer, and the client will go silent after the second step, so the trust anchors will not get finished, the IP address is not assigned actually, and the client waits for 30 minutes and then they will start again whether the situation changed maybe. So DHCP is all about dynamic consideration so this is dynamic and can change in time.
And now I was wondering like, is this option, the DHCP 108 because it sounds like a pretty good idea, how to deploy it? And the answer that I got in last RIPE meeting was that it is, because it's already on Android and IOS, it's already on Mac OS, so those three types of operating systems are now actually doing DHCP discovered option 108, so they are announcing to the server, the DHCP servers that they are willing to work on v6 only. This is the measurement I made during RIPE 84 in Berlin, I was actually sniffing all the DHCP packets throughout the meeting week on the network, and I found out that two thirds of the devices were actually requesting v6 only. It's a little bit biased by the fact that all RIPE NCC employees have Apple devices, so there are quite a lot of Apple devices.
So, it seems that devices are ready for this. Networks are a little bit lagging behind. So, now let's see whether we can do something about the network. But first of all, I mentioned Mac OS here and the Mac OS is a special case because in case of Mac OS you are tree to install whatever software you want. It's not like with IOS where you can only have install apps from the app store. You can install even very old software that do IPv4 only, and such software would break if if there was no IPv4 and the network was v6 only. And it turns out that Apple actually has solved this by using CLAT, so there is CLAT in Mac OS and it's very well hidden, but it will get turned op if you actually fulfil these two conditions: First of all the DHCP will respond to this option 108 to turn off v4 and second requirement that is there is also that the NAT64 prefix is shared using route server options that named pref 64. So basically there are two things that have to say fulfilled. That is the pref 64 option? It's just way how to carry the information about what kind of NAT64 prefix is used in that particular network. And because before, there was this discovery using DNS 64 using this domain name only 64 arpa, but it had some security considerations because DNS is not always local and some maybe can do something with the DNS because it's really lard to protect it, so, even though this route advertisement option is not secured in any way, it just shares fate with the other parameters so basically the idea here is that if somebody can fiddle with your router advertisement, they are do much more worse than just announcing NAT64 prefix.
So this is supported by current recent IOS and Mac OS and Android. So the idea here is maybe you can actually use just NAT64 and pref 64 to set up an IPv6‑only network in a way that the pref 64 will activate the CLAT on those devices and all the IPv4 traffic will go through CLAT and you don't need DNS 64 at all. So, DNS would be working as normally. But it seems like this is not the case, because you have to use DNS 64 at least for Safari and for IOS because as soon as Apple device will receive option 108 from DHCP to turn off v4, Safari will refuse to do anything with v4 so it will refuse to use CLAT. Basically the idea is that very like the capital people don't like CLAT, despite the fact they deployed into it the device but they don't like to use it and they dance 64 is less evil than CLAT so they prefer using DNS 64 to fake everything to work over v6 than to put everything through CLAT. So the network setup that is IPv6 most to have NAT64, pref 64 option, DNS 64, and also IPv4 because there are also other devices like Windows and Linux which will just work on dual stack.
But the good thing is the IPv4 pool can be much smaller because, as you saw, 60% of devices are not using the v4 address at all from the pool. So, with the number of devices growing all the time, at least this is the situation where the number of assigned IPv4 addresses don't have to necessarily grow.
If you want to run your own network that is IPv6 mostly, you have to do these things with DHCP and with the route advertisement. The DHCP option, good news it's very easy. Because there is no special requirement for processing on the DHCP server side, so any DHCP implementation that supports custom options can be used for offering option 108. So, it's really not a big issue. The only thing is you always have to have some addresses in pool because if the pool is depleted, the DHCP server will not respond at all. So, then it's no way how to send the message that IPv4 is not necessary if the pool is full.
With pref 64, it is much worse because usually routers have no way to support custom options. That's really something I miss a lot because we already had this issue when DNS service was standardised in advertisements and your old networking gear had to be updated to support announcing DNS service and route advertisement and we are having exactly the same problem again because now all the routers have to be updated to support this option. This is really unfortunate and would I really like to see an idea of doing something about it and then after that vendors as well of course.
However there are some patches for some software routers so if you happen to run route advertisements from some software you can try to look up for those patches, like in this meeting we used patch RAD for announcing this network prefix.
The good thing is by doing these talks, I actually convince people to put more patches so OpenBSD was done by my colleague about two weekends ago after he read my article on this, so this works.
Now, there are some prizes with Mac OS. First of all that CLAT set‑up is actually using ULA address, so basically it will choose randomly a prefix out of the prefixes that are announced and there is no like logic behind it. So, this is a little bit strange. But not necessary harmful.
Then we have the problems that we have on our help desk also. If you use custom DNS server v4 address it will not work because the internal recursive resolver will refuse to use the CLAT so even though you can ping that address, you can do host, it will work but you cannot use the recursive resolver resolver itself to you have to deconfigure your IPv6 servers, that was something people had also in this network.
And the worse thing, but fortunately this was also already fixed in Mac OS that just was released yesterday, when the IPv4 was active was v4 over CLAT of preferred over IPv6. Traffic that went to dual stack went through a double translation instead of going through just natively. But it's already fixed.
That's basically it all from me. So, if I want to sum it up. Good thing is that there is just one network to join. So, users are not that confused. If you don't have other networks like we do here. You don't waste IPv4 addresses for device that is don't need it. And even the US use only minimum of ‑‑ because DNS 64 will force everything that is IPv6 capable via NAT64.
The problem is of course the most complex network setup because you have both dual stack and NAT64. You still need NAT64 so maybe if you already have NAT 44, you replace it with NAT64, it's not a big advantage.
And there are interopability problems. I am really running out of time but I just have one more slide, which is just very recent experience from the network that is deployed right here.
So, good news is still about 60% of devices on the main network are running v6 only. So, they don't use v4 at all. We had this biggest issue with dance servers or even disabled v6 on Mac and if you disable IPv6 and the DHCP v4 will disable IPv4 there is nothing left on your device. So it doesn't work.
Some people we see them on the legacy network, so some people were too shy to ask for help at the help desk and just connected it the other network. The only software that I found that has a problem with this CLAT is Cisco any connect or open connect. It just connects but the data doesn't flow, so if there is somebody who is maybe a developer of this or who can look at it because I don't know what's happening there, it would be nice.
And my biggest fear is that the principal we're not work but the printer prints like a charm on the v6 only device. So that's great. That's everything from me. Thank you very much.
(Applause)
RAYMOND JETTEN: Thank you. Any questions in the room?
AUDIENCE SPEAKER: Leonard Wagner. Berlin. The first audit some present. And second, do you know since which net versions pref 64, DHCP option 108 and CLAT are supported?
ANDREJ CALETKA: I am pretty it's all those that are supported by vendors, so it's maybe like I think Version 11 and up, I am not sure about the older ones but definitely those.
AUDIENCE SPEAKER: Okay. Thank you.
AUDIENCE SPEAKER: Michael Richardson. I am one the authors of the IPv4 only option.
When we wrote the document I never imagined that people would deploy it on DHCP servers and not change anything. It's kind of interesting that that works. And, you know, we kind of assumed DHCP servers would say oh I side this option and then I wouldn't allocate you an address and then I wouldn't run out of addresses in the pool. So that's kind of ‑‑ it's kind of cool that it just works without doing that.
As for any connect, so the server at the other end is v4 only, and it's just created some UDP encapsulated v4 only thing which of course the local end has no idea what to do with that. In feeds of course to encapsulate it in a v6 packet to send it, and I bet you the CLAT doesn't help, at least maybe it works on Mac OS but on other things I can't imagine it will work. IOS will never work until it just makes it v6. Cisco people should be embarrassed about that. So thanks.
RAYMOND JETTEN: Then we have questions on Meetecho.
BENEDIKT STOCKEBRAND: There are two questions. The first question is versus on a can he kill up: Which DHCP server supports RFC 8925?
ANDREJ CALETKA: It's option 108. I am sure that Kea does have explicit support, but ‑‑ well, there are basically two modes. As I said, if you are happy with having some pool of addresses, there will be empty, it's okay to use any DHCP server because it just custom option and the thing that the official supported server will give you is just some bells and whistles that you don't have to put the X numbers. But there could be also support for a DHCP server that would be only used for a network that only ‑‑ that does not want to use any v4 and in such a case, there should be a special DHCP server that the offer any v4 address but just responds to to the query with 108 option, but I'm not aware of any such servers, even Kea cannot be used like this. If the pool is empty it will just not respond, so that's something for DHCP server producers that would be like a really nice feature because without the DHCP 208 the feature doesn't get acted validated.
BENEDIKT STOCKEBRAND: I have two more comments. One from Jordi again. It's worth to mention that most of the CLAT implementation is gesture default NAT64 prefix. This is only a single translation when using ‑‑ there is only a single translation when using the CLAT. Two translations are only need fiduciary there is no DNS 64, see data... even if your network it using NAT, NAT64 will work as well. That's a comment.
Then there is another comment from Radic. Thanks for the presentation. Just a small update on IOS support. The CLAT on IOS 16 also works in apps requiring UNIX/sockets 2 for example, Hurricane Electric tools are ping IPv4 only targets via the CLAT.
ANDREJ CALETKA: Okay, good to know, so that's useful even on IOS, that's good to know. Thank you very much.
RAYMOND JETTEN: Okay. Thank you all for visiting here and being online. A special thanks to the scribe and the RIPE NCC for the technique and get out of here, it's lunch time.
(Lunch break)
.
LIVE CAPTIONING BY
MARY McKEON, RMR, CRR, CBC
DUBLIN, IRELAND.
