Thursday 21 May
IPv6 Working Group
Main room
RIPE 92
9 a.m.
CHRISTIAN SEITZ: Good morning to the IPv6 Working Group session in Edinburgh. I am Chris, one of the co‑chairs of this Working Group, and I'm doing this together with Wolfgang Andrei, and this nice IPv6 cat the RIPE has put on the new T‑shirts is.
STENOGRAPHER: Very smooth slam
CHRISTIAN SEITZ: We put and agenda together and found four great speakers for today, but we have some administrative matters before.
First of all, the RIPE PC election voting will close at 5 p.m. today, please remember to vote. And the RIPE NCC members who have registered for the General Meeting can vote until 9 a.m. on Friday.
Please, we have a Code of Conduct for this meeting and please make sure to be polite to each other, treat everybody with respect, so everyone feels good at this meeting.
Remember this is a hybrid session, the session is being recorded, are so please turn your mobile phones to silent mode. Thanks to the stenographers and our scribes. The scribes also took the minutes from the RIPE 91 session, Ray sent them to the list some months ago, and there were no comments.
RAYMOND JETTEN: No, I haven't heard or seen anything, so no...
CHRISTIAN SEITZ: They are on the website. If there are no comments now, they are approved.
Okay, thank you.
We have some newcomers here like on every meeting, and just a few words about the IPv6 Working Group. It exists to promote IPv6 adoption, we still need to do that in 2026. And we always find, try to find some presentations that cover these topics, for example also experiences from IPv6 IP deployment, share those experiences because not everybody has to make the same faults or have the same issues after deploying IPv6 and we are trying to make the IPv6 world better with presentations.
So, if you are in the room, you can simply go to the microphones if you have a question, please don't forget to state your name and affiliation. And if you are participating remotely, just add the question to the Q&A section in Meetecho and we will make sure to give it to the speaker after his presentation.
WOLFGANG TREMMEL: Happy Birthday IPv6. I am doing this videos and workshops and in my IP workshop I had the idea how old is IPv6 actually? IPv6 was first specified in December 1995. So, that makes it more than 30 years old. And IPv4 was specified in 1980, it's 46 years old, that means that IPv4 is just 16 years older than IPv6. And in 2010, most of you should remember 2010, you were all using the Internet already I guess, and in 2010, IPv4 was that old as IPv6 is today, and some people still struggle and think it is not mature. IPv6 is 30 years old, it's definitely a mature protocol now.
CHRISTIAN SEITZ: This may also be a lack of training or knowledge, so I would like to point out the RIPE IPv6 trainings in the RIPE NCC Academy. There are already three of them. Just one exam you can make, but three trainings, and I look for the content and from my personal point of view, this is really good work from the RIPE NCC, and this is really good training material, so, if you want to learn something about IPv6 or how to secure IPv6 networks, this is a real good start.
The trainings are open for everybody with the RIPE NCC access account. If you want to take the exams, you need a voucher from an LIR. Each LIR gets three vouchers per year and you have to use them within the calendar year, but you can also give it to somebody outside of your organisation who wants to take the exam.
Now, we start with our presentations. The interesting part of the session. And we begin with Ondrej Caletka from the RIPE NCC who will talk about the year of IPv6‑only desktop, and he will also bring the IPv6 cat with him.
ONDREJ CALETKA: Hello. Thank you very much for the introduction. I am working for the RIPE NCC, actually learning and development. So, I am part of this people that are bringing you training courses to locations but also the questions for the certification exams and also the content for the RIPE NCC academy, which there for empty. Give it a look. And maybe after the session if you stop by at our stand here and look, sign up for the advanced IPv6 exam, you might get this T‑shirt as well. At least that's what I heard.
Anyway, so the talk here is about something that you might have heard before, that is the year of something, something desktop. It's usually like the running joke is the year of renewal of the desktop which happens the next year always. So I have this idea that maybe next year would be actually the year of IPv6‑only desktop and I will try to get through this presentation to convince you why I think this might happen. But let's first start by looking at some funny cat pictures because if my talk is boring, you can entertain yourself by looking at lots of animations there are throughout this slides.
This slide is about this IPv6 cat called hacks that is in the box of IPv4, is it in the box? Well because apparently you cannot, you cannot just transition to IPv6 without considering IPv4. IPv4 is the protocol of the Internet, everybody needs IPv4, so your transition to IPv6 has to somehow consider IPv4.
The most obvious solution is dual‑stack. That basically you have IPv4 as you have it and you just deploy IPv6 next to it. I can say that after all these years we can sort of like conclude that dual‑stack failed in this because just by the fact that on top of what you already do with IPv4, you start doing something more with IPv6, you will never transition to IPv6, you'll just have IPv6 as an extra burden on top of your IPv4 burdens and of course this means that your focus will be always on IPv4, all the work is doubled, and the worst of all is that all IPv6 programmes that you have are pretty masked by the safety net of IPv4.
So, I have some examples with RIPE meetings, so this is how we tried and failed during RIPE meetings. So, in Athens in 2013 during RIPE 67, we introduced this IPv6‑only experimental network as a second SSID, which supported NAT64 so you could reach IPv4 destinations and it sort of works but back then, like many things failed like basically no Apple iPhone worked for instance and so on.
However, we kept doing this so we used to provide two networks at the RIPE meeting, up until RIPE 84 in Berlin 2022. In Berlin 2022, the situation was much better, actually many things worked. Normally you barely noticed any brokenness on the IPv6‑only network. But there was this issue basically, there were two networks, one was working all the time and one was working almost all the time and the first one was the default and the second one was the outer native. So basically even though it the outer native worked well, nobody was using it, because why would you use some outer one if you can use the main thing.
You see some participants that kept asking about whether the IPv6‑only network could be the default. This is the one from RIPE 79 in 2019, and yeah, eventually that person got hired by the RIPE NCC, got himself a side job of running RIPE NCC meeting tech and then that person changed the main network settings in RIPE 85 to be IPv6‑mostly. So now the main network does have IPv4 but it hides it for many participants. So basically the main conference that work at work is now IPv6‑mostly, that's this new‑ish concept and it basically means that many devices on the network basically all mobile phones and MacBooks are opting out from IPv4, the IPv4 is there but they are not using it they chose not to use it. The nice thing is the device vendor to decide that IPv4 is not going to be used, which means that the device vendors knows better than you what you want to do with your computer.
The good thing is there was no big drama observed we kept doing this and right to this day, so we still have the main conditions of network is IPv6‑mostly, we have backup network which is called legacy, which is the dual‑stack but we keep changing name every meeting so we don't accidentally connect to it if you try it once. And we have this trend of more and more devices opting out of IPv4 I will show in a moment how many.
So, this sort of seems like this is working and this is sort of like pushing us a bit forward. So the question is now: What needs to be done if you want finally to go IPv6‑only? So there are things that have to be done on the network said and there are things that have to be done on the host side.
So, from the network side, the most obvious but not so easy to achieve thing is that if you want IPv6‑only, well your IPv6 has to work without issues is. And maybe you can say of course, I have a dual‑stack in my wi‑fi for ten years, of course it works without issues. You wish. Well we have unfortunately an example right at this meeting where we have been chasing some strangers with a new access point in this and the room next door which gives connectivity issues to some people. These connectivity issues are only happening over v6, as I said most people are using only v6 in this network so for them it manifests as no connectivity at all.
The other requirements for IPv6 network is you have to have NAT64 in your networks to be able to reach IPv4 because as I said, you cannot transition to IPv6‑only without some support of IPv4 except for some of course special cases, don't take my word for granted.
Anyway, an important point here is that yes, there might be sponsor we are transition technologies that are better in one or the another, but no you cannot choose this, industry has already chosen NAT64 and all this MAP‑T, Map‑E, lightweight, 4 over 6. No, for networks where people connect their devices you unfortunately cannot choose.
NAT64 has NAT in its name and it's as annoying as any other state for that. So scaling it is a problem. High availability is a problem. State sharing is a problem. Cycling between different IP for addresses for the same end point is a problem especially with video on demand services. It is still annoying but that's how annoying the Internet gets until finally everybody reaches IPv4.
So, maybe the question why did NAT64 win? Well, I feel that NAT64 has one interesting and unique feature, that is basically that it makes the client devices send normal IPv6 everywhere. They don't care whether the destination is IPv4 or IPv6. They just send IPv6 everywhere, it's a network problem if it happens to be IPv4 to translate it into IPv4 or IP or over whatever and deliver it to the destination. Which is also good for network engineers because that means that they just IPv6 packets everywhere and it doesn't matter whether they get translated at one point or not it's still IPv6 packets that they can inspect just like native IPv6 transition. Of course also all the other transition mechanisms are usually like two box solution where there is one box before, so there is a dual‑stack, then there is box before that will make it IPv6‑only, and then it goes wider network with IPv6‑only to another box that is after which makes it dual‑stack again. Typical example is the slide where the boxes are actually called B4 and AFDR, like before and after.
So, the NAT64 in theory, like, is the only, the after box, it basically just gets normal IPv6 on left side and produces normal IPv4 on the right side.
This is the network side. What about the device side?
.
First of all, if you want device to work on IPv6‑only, there has to be zero IPv4 dependences. Typical example for most devices if the DHCPv4 client fails to get address, it doesn't mean you produce error saying you have no connectivity or the network doesn't work. Maybe it works even if DHCP didn't give you any address.
But also, and this is the annoying part for all general purpose devices like computers, this applies to all applications as well. So every single application has to support generating IPv6 traffic. This might be easy to achieve in some closed network like IP telephones, I remember many companies basically when they ran out of the IPv4 addresses the first thing they do is just migrate their IP phones into IPv6‑only because they supported it and they only talk to restricted set of end points.
The other option is the one that Apple is using for their IOS, where they said that from 1 June 2016, which will be ten years soon, they were just not accept any application that would not work well on IPv6‑only. And that is it. If you have this power over all the applications that are running on the platform, this is also easy. But they are still operation things like free for people to run whatever software they like, in that case the only help is here so the sort of operation system work around which is called CLAT, customer translator, that will save the day in this case. Which sort of negates what I just said in the previous side because if they add CLAT to NAT64, aren't we just creating a transition mechanism? Yes, we are doing exactly this, it's called 464XLAT. There are still some advantages. First of all, not every packet has to go through CLAT, because it's work around broken applications so most non‑broken applications should generate IPv6 packets and be done with it.
Anyway, you cannot stop people from running broken applications so definitely if you want to run IPv6‑only network and you want people to have a good experience there has to be CLAT one way or another or, on such a computer. So it's something that unfortunately is needed.
And then of course, something that you might have heard from me but just in case you are new to this and you heard IPv6‑mostly for the first time like five minutes ago, how this thing works.
Well it's pretty clever actually because it's a dual‑stack network that has this one extra option in DHCP version 4 server. This option is is numbered 108 and because its name is v6 underscore only underscore preferred. Everybody just calls it 108 because it's easier.
The protocol is pretty simple. Basically the network will indicate by putting this option in the list of offered options that that part of the network segment the client is connected to supports IPv6‑only operations. So basically in other words, it will tell the client there is NAT64 in this network so if you prefer you can use NAT64 instead of native IPv4.
And then the device is the thing that is making decision based on this, so that if the device is capable of IPv6‑only operation and it prefers it, then it will just like opt out of IPv4, not use IPv4 anymore, and in other words, a device should only do this if there is CLAT ready to be used for if there is the case of Apple IOS when there is enforced capability like enforcing the applications.
In theory, it should not opt out if IPv6 is disabled because like, if IPv6 is disabled and you opt out out of IPv4 you end up with no connectivity, but in practice, this happens and this is one of the biggest issues on people with MacBooks cannot connect to RIPE meeting network because they at one point in time turned off IPv6 and it always was in the programme until they came here and they had IPv6 off and IPv4 is refused to use by the computer because it's capable of IPv6‑only. So then it ends up with no connectivity.
This brings me to the point of the year of IPv6‑only desktop.
So, in order to be able finally to get rid of IPv4 from networks that are, that our DHCPs connect to we basically need to have all the desktop computers supporting this mode of CLAT and opting out of IPv4, which we are already quite there because it already started when we started back in those three years ago. It was already, you know, all Android and IOS devices have been opting out because with mobile phone devices, NAT64 is the translation mechanism of choice for mobile network operators. Mobile network operators have quite a strong influence on what mobile devices would support. Because in many countries it's a vertical market where the mobile operators are buying lots of mobile devices to be sold to their customers.
And because Apple likes to do things in similar fashion, macOS was the first operating system, desktop operating system that supported this as well, and it makes it special because macOS is much more respected platform and you can still run whatever software you like there which means you can also run very broken software which doesn't support IPv6 or you can just turn off IPv6. I don't think you can easily turn off IPv6 in your Android phone or iPhone but you can do it on macOS.
Which brings some interesting issues, for instance with broken VPNs, apparently most VPNs are IPv4 only and recently they got this feature called IPv6 switch because they figured out if you are a dual‑stack network and you fire up your IPv4 only VPN the IPv6 is still going and by passing the VPN. In order to stop this bypass most VPN clients have a IPv6 switch this they will IPv6 as soon as the IP for VPN will connect. If this is connecting via v6, It will immediately kill everything. This also then shouldn't be like seen regularly. The first option is that you will you as a user will turn off IPv6 and then you are screwed.
Some stats from our RIPE meetings. As I said we introduced this IPv6‑mostly in RIPE 85 and here you see I am trying every meeting basically count with the same methodology, so I am could you think unique MAC address that I see in the DHCP query logs. And I am could you think how many of these MAC addresses are containing the option 108, so how many of them are opting out of IPv4. And you can see that we started around 74%, and now we are already at 85%. So, you can see that it's a dramatic amount of clients that are not using IPv4 at all already.
And we are still missing Windows, we are still missing Linux, and that is exactly what happened recently. So, last year I believe Microsoft released a previewing version of Windows 11 which supports CLAT and supports IPv6‑only operation without hopefully without any disruption, and for this I will actually send you to the following presentation, which will talk exactly about this, and I don't have any experience with that myself. But, I do have experience and I was also trying to push the other part of it, which is network manager. This one of the most popular network monitors in Linux, it's called network manager, and it got support for CLAT in Version 1.58.
So, I would like to tell you something about. First of all. It's a development version, it's not really CLAT. How does it work? It uses eBPF programme, which is a byte code one time loaded into Linux kernel, it doesn't need any special modules or whatever. It can load into normal Linux kernel and it can do things. In this case it just hooks up on the network interface and every time it tries to generate v4 packet it will translate it into v6.
Unfortunately, it's disabled by default in this version, but you can easily enable it with this configuration option. In order for it to work, it needs pref 64 option in the advertisement. So you need to detect NAT64 prefix by this option that you have to put in your router advertisements. Otherwise it will not detect it when it starts working it's invisible to you as a user. You will notice there is this weird address on your interface and if you look into you're routing table, you will only see the default IPv4 route via IPv6 next hop, which is something that it looks capable of doing and here it's like a nice example of how to make use of it.
So, wrap this up with IPv6‑only operation, right now, we have already IOS, Android and Mac on board. We already have coming soon Windows and Linux. So, when these two will come, we will get to this year of IPv6‑only desktop I am pretty sure and I am thinking maybe next year, maybe the year after that. But definitely soon. Unfortunately there are other devices that people are connecting to networks, which I usually put into a category like IOD and smart home. These are quite bad, but maybe if you run sessions and heard about this Android TV boxes that are doing DDOS attacks, maybe you don't even want these devices in your network, so it might be not be that bad actually to support them.
So, what can we expect then the year of IPv6‑only happens in the number of the DHCP leases will drop close to zero and if you have one or two IPv4 clients is it still worth having IPv4 deployed in that network? Well, probably if you undeploy it you will make treadmills, which is the presentation from Jen Linkova from RIPE 81, but again, that might be acceptable after all. I think you can still use treadmill even fits not second can. It's not the main feature of this device, is it?
.
So, in the end, these IPv6‑mostly networks might have been just a phase, something like Blue Ray in the sense of the long running of time, but it finally seemed to help transition to IPv6‑only. It finally allowed the device vendors to figure out that this is something that is wanted, and implementing it into the desktop operating systems.
On that note, again, Jen Linkova has been busy in the idea of writing a draft about how you deploy and operate IPv6‑mostly networks. She even invited me to join as a co‑author which I am' grateful for and it's a working group group last call, there might be an RFC soon. It might be still useful if you cannot afford to break these treadmills.
And with that, I will just point you to the website that we have now, so after 20 years of saying IPv6 act now, we now revamped the website and now is says IPv6 cat now.
(Applause)
RAYMOND JETTEN: Thank you Ondrej. Are there ‑‑ yes, there are questions.
AUDIENCE SPEAKER: Jen Linkova. First of all, thank you for contribution to the document and again if people who have deployed that, if you have done that we'd like to hear from you, because that document Ondrej mentioned is what we experienced and what we think is the right way of doing this, but you might have different opinions and we'd like to get that.
I was curious Ondrej, we see 85 percent, I am curious if you look how much of it in the same device doing MAC address randomisation because it may be correlated, they may be also doing option 108 and devices which do not. So, I am just curious if you see like distribution by operating system or something to normalise, make sure we are not seeing artificial increase when the same client appears many times.
ONDREJ CALETKA: Unfortunately, I don't, because well the thing with random MAC demonstrations is that they are random so it's hard to figure out whether you can find out whether they are randomised or not. But I believe this normalisation happened already before this RIPE 85, so ‑‑ and also it sort of correlates, if I go back to the slide, there is, you see that the number of the MAC addresses is sort of along the same thing, it's quite higher here in this meeting and the numbers are not final but I attribute this to the fact that we are in minus 2 mobile data doesn't work here so people actually put effort into connect can their phone into the conference wi‑fi which they usually don't these days. So, it seems to me that in this sense, the number of like, if there is randomisation, it was there even before, so it should look the same.
AUDIENCE SPEAKER: Benedikt. You say that IPv6 caused very have you problems. Maybe you should put that into perspective a bit, the number of problems we have with IPv4 in some cases pretty much outweighs the problems we have with IPv6. So, moving towards IPv6 can actually make things better for the user than trying to keep IPv6 up and running with double, triple, quadruple NAT because you have only one address. This is, it's helpful and as interesting as it is, I think we are way past the point where IPv6 causing the problems that really affect people. So another reason why I agree with you we are heading towards IPv6‑only desktops, especially because of the large number of machines that provide dual‑stack is just a double pain in the ass.
AUDIENCE SPEAKER: I want to agree with the speaker before me. In the beginning, you said IPv4 is hiding all your IPv6 problems. What I hear is IPv4 network works and IPv6 still has problems.
ONDREJ CALETKA: Yes, that's because what the vendors are doing. That's exactly what this wi‑fi in this room is doing. IPv4 would work perfectly but we don't use it therefore if IPv6 doesn't work, and you have dual‑stack, you barely notice it. If you have IPv6 that doesn't work and you have IPv6‑only you will notice it quite a lot.
AUDIENCE SPEAKER: Yeah, but that is ‑‑ now we have a problem because you are saying IPv6 is not working properly and IPv4 is working properly and then, you know, people start thinking ‑‑
ONDREJ CALETKA: It will not get better until people start using IPv6.
AUDIENCE SPEAKER: So, where to go from here? I think the next thing we should think about is what to do the network clients that don't even have an IPv4 stack in the cone. So do we need to do something special for example?
ONDREJ CALETKA: Provision them into some special old network that is basically for super legacy devices and don't care about them anymore.
AUDIENCE SPEAKER: No, no. Not without without IPv4 stack.
ONDREJ CALETKA: Okay. I know that there are some experiments to remove IPv4 dependences from Linux for instance, it doesn't really ‑‑ yeah, it's harder than it looks like, so yeah. That's, but that's definitely the next steps. Why would you maintain something that you don't use for 30 years?
WOLFGANG TREMMEL: We have some online comments. We have three comments I am reading out two of them because they actually say the same.
Janas from Telecom remarks dismissing dual‑stack as a transition mechanism in 2026 is easy but also unfair since dual‑stack was our playground 20 years ago and without it I really doubt we would have this progress and conversation today.
.
Also Patrik remarked quite similar.
There was another online, comment also from Robert Jet, thanks for your effort in pushing CLAT support in network manager. Network manager 1.08 is supposed to land releases shortly after RIPE 93.
ULKA ATHALE: Actually, thank you Robert Jet, a lot, because I believe it's your effort that, it got merged into the Internet code. Thank you.
AUDIENCE SPEAKER: It's a good closing word. I want to say thank you for the effort in going ahead with the IPv6 network at RIPE and persisting even if things break, fixing them, improving things, making IPv6 a reality here. Thank you very much.
(Applause)
RAYMOND JETTEN: Our next talk now.
WILHELM BOEDDINGHAUS: So, does my microphone work? Great. Thanks.
So, my presentation follows up on Ondrej's presentation. We are also talking about the desktop and the network that runs the desktop. And we want to get only IPv6‑only there of course and I have got a few ideas how we can hopefully improve our networks.
Okay, if we talk about network design with our customers, we have three areas where we think about IPv6. They ask us should we do dual‑stack or should we do IPv6‑only? I always answer well we have to look into the core, into the data centre and into the office LAN. Maybe the wireless LAN. And in the core we run mostly dual‑stack. It runs just usual on a few routers, maybe a few firewalls so you can have dual‑stack there. You need to transport both of the protocols anyway so it is a good idea to have IPv6 and IPv4 running in parallel.
Maybe in future, we will have IPv6‑only backbones and running IPv4 just as a service on top of it, but today, the reality is we just turn on IPv6 and have it run in parallel.
In the data centre, in a virtualised data centre at least, we usually tell our customers to put in new interfaces for IPv6 so they are intro interfaces in their servers. One for IPv4 and one for IPv6. You will all your security settings separated, all your firewall rules separated and in one day if you don't need IPv4 anymore, you just can turn off this one interface.
Of course, you need the double number of network interfaces but as long as they are virtualised usually you don't care.
.
But this is all not true if you look at the millions of devices we run in our offices. And I'm not talking about the Home Office, I am talking about the real office space where people do their daily work. And there, we have PCs or laptops and usually these devices have just one interface, so we don't have the option like we have in the data centre that we can just put in another interface, because these boxes don't have room for another interface, or cabling in the office building has to room for a second interface, and you don't want to double your rack switches where you connect your devices.
So this is not an option and here we need both protocols to run and one of the options is to run it dual‑stack.
What else do we see today in our networks, in our office networks, very large networks? I have seen it works with more than 2,000 clients in a network. The reason was that they didn't separate it they had to run multicast and they were not able to do multicast routing. I don't know whether it was a lack of knowledge or a lack of features in the hardware but they couldn't run it so they had one flat network in two buildings from the basement of one building to the roof of the other. Not a good network design, was it?
.
When we have our users and these users in these large networks in this office space they open e‑mail attachments with malware so, we have a security threat here and the security threat here and the threat is usually not the box, it is the human being sitting behind the box. So what we sometimes call in the old model the layer 8 problem.
And then you have absolutely mixed networks. So people come back from business trips and bring their not patched laptops back to the office network and they have maybe them picked up some malware because they were connected to unsecure networks like in the hotel, in an airport, in a restaurant, name it, maybe they visited family members and they got their viruses there.
So we have absolutely mixed and insecure environment in our office networks and we have somehow to deal with this.
And we find a lot of old software and you cannot imagine how old software can be in enterprises and in public administrations. They are just not written for IPv6. Some software has been written 20 years ago, and they are happy it still runs. So there is no chance of getting this software to IPv6 but they still need it for some purpose. And you have got very special software in the public administration because they have very special tasks and very special software, let's say who runs an airport? It's a public administration, so they have special use cases.
So NAT64 is not enough because many of these old software is not capable of opening and IPv6 socket, they have IPv4, and they will still with IPv4, so we cannot go to IPv6‑only and we cannot go to pure NAT64 where we ask our client to open IPv6 sockets and then we translate it into IPv4 to reach an IPv4 service. We have to open.an IPv6 socket and we have to offer an IPv6 socket on this client. If we just put dual‑stack into these networks, the IPv6 network design has to follow the IPv4 network design.
So we cannot take advantage of all the new features of the vast address space, of the many addresses we have so we just put IPv6 into the IPv4 networks and it is nothing really gained. As Ondrej said, we don't seen save IPv4 address space even if it is private address space.
So, IPv6‑mostly to the rescues. As you all know, we offer an IPv4 address on the client here on the right‑hand side, we translate it to on our client device and somewhere in the network we do the translation back to IPv4 on NAT64 box. Though this basically is how it works, and how it should work in the office space, not just in the space of mobile phones.
We need our tool kit. Ondrej talked a little bit about it we have the DHCP option 108. We need the router advertisement with our pref 64 prefix. DNS can be used as an alternative, not all client support it. But the router advertisement I think is the preferred way of doing it. And we need our NAT64 gateway somewhere in the network.
This is just the tool kit we have. And remember, 108 is an IPv4 option. So we still need some kind of IPv4 DHCP for it.
Basically the client and the server agree on no IPv4 is needed in this network, and not having IPv4 on the networking interface is the new normal. Still today if you run, if you start a Windows box and you don't have IPv4 on this box, this operating, this system thinks oh this is an error. It is not the new normal, but this option 108 changes this, and on the Windows 11, where this CLAT now is running in better, this exchange of option 108 turns on this CLAT mechanism. Mean if if you are in an network without option 108, it works the regular way we have been seen the last 30 years I think, something like this.
So, this turns on the win CLAT as they call it.
Then for or tool kit router advertisement, CLAT needs SLAAC, we cannot run DHCP v6 for this. DHCP v6 of course can be added and we end up usually with three IPv6 addresses plus the link local address. I call it the main IPv6 address, a temporary IPv6 address if you have this privacy extensions turned on but most of them have and we get a third one, we get the CLAT IPv6 address. So there is a special IPv6 address global Unicast for the CLAT and we see this on all operating systems, not just on Windows.
So, three addresses that make source address selection really nice.
This is a router advertisement, I have taken this from a Linux box from the router advertisement daemon. We have got a prefix you send out, you have got a DNS and you have got the NAT64 prefix. So this is not anything really special. It runs in my home network, this is why we have unique local for the DNS because the Fritz box on my DS line doesn't like this. It does work, everything is fine, I could use another DNS server for this. This is quite easy to set up.
And then it works with many operating systems. I have checked it with Android operating systems, it does work, then it is called 464XLAT. It does work on Macintosh and other Apple devices. Linux now can do CLAT and it gets easier as soon as it is integrated into the network manager but it has been running before with other software. And in Windows, we now are in a private beta.
So, on the Windows operating system, we are talking about Windows 11 not Windows 10 of course and the older operating systems. We now have this in private beta.
Windows was capable of doing CLAT for a long time, but just on their mobile interfaces. So, if they were to connect to a mobile network they had to behave something like a telephone or like a tablet, so the software has been running in Windows for quite a long time, but now it comes to the ethernet interface and it comes to the wireless interface, the wi‑fi interface. And they are in a private beta. We have a few people here in the room who are part of this private beta, I am one of them, and I want to show you what is going on there and how they implemented it.
And then something happened a few minutes ago, the dream of every presenter, Thomas came to me and told me oh Microsoft just announced that they changed things. Great! So we have no idea what they are doing because they will do it somehow in two weeks time and then we will get a new beta version but we have an idea.
So, we are at the edge of new technology here. A dream.
So, why is WinCLAT so important? Because we have millions of devices running Windows, we are talking about the regular office spaces on all five continents in public administration in enterprises and most of them run Windows. Usually you find MAC in enterprises with the technicians and with the Board, because they want to have these shiny devices but the rest of the regular workers have to do Windows.
So, this brings a lot of impact to the desktop, and to our desktop networks.
We have no information so far when this feature will be a regular feature that everyone can use. Today, it is private beta, meaning you even get a little piece of software that activates it on your preview, Windows preview software.
So, there will be a public beta, I suppose, and then there will be regular, the regular software. As we know from Microsoft, even the regular software has to be a few iterations before it runs perfectly well.
It does not run on the older operating system, so if you want to use it, you have to make sure that your network runs Windows 11.
I know of many networks who have bought these extended support for Windows 10, so they will not get this feature at all.
So, how is it implemented? I hope you can read it. It should be large enough.
We have three global unicast addresses here in this example. We have got the temporary address, this is the third one we don't talk about this, we have the regular one, and then we have one, the one in the middle, that ends on C0:0:100:0. This is the CLAT address that is being built just for the CLAT feature. And this maps to the 192.0.0.1 address. This is the same address we use on our mobile phones. This address is just significant to our local computer, it will never be visible in the outside world. And you see that they use the 192.0.0.0 as a default gateway. Ondrej told us that on other operating systems, they use an IPv6 address as a default gateway in Windows today we have it like this. Whether this will be true in two weeks time, I don't know. But this is how they implemented it today.
Do we see any problems with this?
.
Here, you see again the mapping. I wrote out the address in the second line with all the zeros to just show you where the address is embedded here. And this address 192.0.0.1 comes from the IPv4 service continuity prefix, the RFC number is here, and we just have eight addresses. One of these addresses is used as a default gateway, the 0.0.0. So we have seven addresses in our ‑‑ possible in our network.
.
If we map it like this. This means you cannot have more than seven PCs in your local network. Most of the networks are larger. And if you do duplicate address detection and of course it does. To hit the one last free address out of seven is not easy. So we will get into trouble there. So they told us that they will change this mechanism in the next beta. So we will see what's going on in two or three weeks time. On MAC, they just use mostly random 64 bit address and don't map on this 1 to 1 here.
Also, what we don't know, really know is if are you work with this mechanism and you get the duplicate address, then you know that your IPv6 address is not valid. But then you have to change your IPv4 address, you have to get this information to the IPv4 stack, build a new address from the service continuity prefix, build a new IPv6 address and then try duplicate address detection again. Basically this will never work if you have more than one PC in your network.
But this mechanism,s as it is today, if you just have one PC in your network, it does work. You can see it quite easily here that I ping a literal, not a name server, I just ping a literal here, it does work, you see the source address, you see the destination address. This is routed to your NAT64 gateway. There, it is translated, the source address and the destination address of course, both of the addresses are translated into IPv4 and it goes to the Google name server, it comes back, it works perfectly well.
So this is how it looks on the network if you want to look into it.
So, what does all of this now mean for our networks? And this is mostly what this talk should be about. What what can we do in our network if we have this kind of mechanism active? Because we said we want to have smaller networks and we don't want to put dual‑stack into the networks, we don't want our networks, our IPv6 networks to follow IPv4 in the network design.
.
So, let's see what we have today in our networks. We're talking about office networks, it's about marketing, it's about accounting, it is nothing special, it is not you and the IT, It is the relevant workforce, and these are some of the protocols that we, today, have just to get office PCs up and running.
So we have IPv4 and maybe IPv4 routing protocols, we have got first up redundancy protocols, choose the one you like best. We have got spanning three, we have got multi‑chassis link aggregation, we have DHCP v4, we have to secure DHCP, can secure spanning tree. Some port security, storm control and because we have two large networks, these two thousand guys in one network we put on another network protocol and this is private VLAN to make sure not everyone can communicate with everyone else. So, instead of changing network design, we put another protocol on top. It seems to be a good idea.
But now, we do dual‑stack. So, we add IPv6. It doesn't really get better, does it? Always remember, you have to ‑‑ this again, you now have even more protocols you run, you have SLAAC, you have neighbour discovery, you do your first up redundancy protocols in dual‑stack, and you get stateful and stateless DHCP, you have to secure that, you get router advertisement guard, you have got all these first hop security and this does not really work out. Because you have to monitor all this, you have to configure it, you have to train your workforce on this protocol, and this is really complicated just to get a PC in your network.
So, I would suggest that we change things, that we go for a network design like this where we have one 64 network per client. And we do routing as soon as possible. So what do we need? We need a Layer3 switch, not all enterprises have it because there are some vendors with a bridge in their logo, they have quite expensive licences for Layer3 switches, and others follow this idea that you need to pay extra. Of course you need a routing protocol. Maybe it's OSPF, maybe it's EIGRP, don't tell me you run ISIS in the office networks, yes in the been, but not in the office. This is not an enterprise protocol. One of those protocols maybe should be used. So you can't buy the cheapest switch but that's it.
Then you can, in this case, turn off a few, not only a few protocols.
So what can we get rid of?
We don't need the IPv4 routing protocols anymore. We need IPv4 in the CLAT, PLAT 464XLAT version. We need IPv6 and IPv6 routing protocols. We need SLAAC as we have learned for this mechanism to work. We need DHCP v4 but just the option 108. So I have a DHCP server running in my home lab and I just added one line to a standard configuration. We need some port security, yes, it's a good idea. We might still need some DHCPv6, maybe it's stateful, stateless, but we can get rid of all this router advertisement first hop security, all this insecurities in IPv6 are gone, if we just have a one to one relationship between a switchboard and our client.
So, this is what we keep. We have to make sure that the client can contact its AD server via IPv6 and of course it would be nice if the client could connect to a DNS server via IPv6, so this maybe is a good idea to activate IPv6 on those two protocols. This is just the basics. We are not talking about monitoring and other stuff, this is just the basics. And then you are done.
And you get rid of most of the insecurities and you get rid of of most of the protocols so our networks get easier, much easier.
If you have Layer3 on your switch, be it on the VLAN port here, be it on a physical port on your switch, you can put access lists on it. So this is the only place in the network where you have the traffic of this client isolated and you can do zero trust, you can put your access lists on this, first access lists, to make sure that these clients don't communicate with any servers they are not supposed to communicate with. You can do sure quality of service if you want to.
In large Layer2 networks, if someone gets malware on their PC, this malware usually tries to find out who else is in the network, and it tries to do some reconnaissance, this is not possible via Layer2 because we don't have Layer2 anymore. So, we get more secure networks and we have one, just a little one, option to mitigate what bad actors malware viruses want to do in our network. So it's a little bit of extra security that we just gain by network design, we don't gain it by buying fancy boxes from window A or B, we just get it by network design if we do IPv6‑only on the wireless LAN and on the ethernet interface.
We we have as an extra, as a bonus, we have relatively new RFC, it's RFC 9898. It's about neighbour discovery considerations in IPv6 deployments. It's just half a year old this RFC, and they put together 12, 13, 15 issues that we have today with IPv6 neighbour discovery, and they grouped them into three main groups and these are multicast. Trust and neighbour cache entry on demand.
And I just want to talk about how this other network design with the one to one relationship between the client and the switch now mitigates this three main areas of this RFC.
So, it's multicast. This is used extensively as we all know in IPv6. I am talking about link local multicast I am not talking about watching TV, and the larger the network the more multicast traffic do we see. Because we see all this neighbour discovery, this neighbour solicitations, neighbour advertisement, router solicitations, and this is a lot of multicast traffic that is running through our networks. And what is special is if we have small devices that is run on batteries, a lot of multicast drains the batteries, because multicast forces this device to answer and to receive usually, to receive a packet is quite cheap. To answer is quite expensive.
Just issues: Well we don't have any trust in IPv6 first hop networks, Layer2 networks, we have address spoofing, we have denial of service with DAD, we have router advertisement, we have redirects that don't work properly. So, these are all issues they have identified, and if you have a one to one relationship, all of these trust issues go away.
And then we have the neighbour cache entry, they found this also as a field of issues, that it takes sometime until, let's say, a router has got the MAC address of the client and can start sending packets. This is not new, the same we have in IPv4 with ARP, so these tables need to fill up. An attacker can try to drain these tables by just putting in garbage. This is true for all tables that we have in the network. Someone can try to fill up all of the memory.
So, microsegmentation , as I said, can mitigate all areas here so this RFC is very useful, but if we change our network design, these issues mostly go away.
So, the conclusion:
.
WinCLAT comes to the most used client operation system and this is good news because now we can do IPv6‑only networks. In enterprise areas and in public administration. Microsegmentation helps with security and if you look in the security papers of the, of many organisations, microsegmentation is one of the network designs that they prefer.
Client traffic can be secured on the switch. That is quite easy.
The RFC 9898 issues are mitigated.
And we can change from Layer2 switch networks to Layer3 routed networks and this will make our networks easier.
Thank you very much for your attention.)
Applause)
RAYMOND JETTEN: Thanks. Any questions?
AUDIENCE SPEAKER: Jen Linkova. Two things: Yeah, it's quite funny for how Windows seem to be currently generating interface ID. It does not have exactly v4 address. I guess they were just trying to make check some neutral with minimum calculations. It could be completely different like Android and macOS does.
For L3 networks, I do agree they are great right, nobody likes broadcast domains. However we need to careful with recommendations because some systems and applications might want to talk to their peers, like L2 neighbours, so I suggest yeah, before doing this to check if your application needs actual communications. I am aware of a number of cases, especially in IoT areas, so it's a great idea but it unfortunately it's not a silver plate.
WILHELM BOEDDINGHAUS: Of course you have to test it, you have to look whether your applications can do it. We are not talking about IoT devices here because they are absolutely special, and they lack features, they have many features. As Wolfgang said they have IPv6‑only, they have IPv4 only. They have broken stacks, so we are not talking about IoT in this field. And yes, if we have applications that must communicate via Layer2, then this does not work, but then I would say the application is not old but it is broken. An application that is 20 years old that use uses IPv4 in my view is not broken, it is just old.
AUDIENCE SPEAKER: Mark. You said that Windows enables CLAT, it configures an IPv4 address in 192.0.0.0/29. You said that because of this no more than eight machines on the same network can do this. Can you ‑‑ I didn't quite understand why.
WILHELM BOEDDINGHAUS: We have got this IPv4 continuity prefix and it is just a prefix of eight addresses from 192.0.0.0 to 7. It is not larger. Usually these addresses are used as 32 addresses so not even in a /29 network, and this prefix is not larger.
JEN LINKOVA: It's not like all your MAC devices using the same address, right, and we all see it on the same network that's fine. I think the problem here is that currently Windows takes that v4 address and use it is in a v6 so all devices will get the same v6 address which is going to be a problem. I guess it's a bug they are going to fix.
WILHELM BOEDDINGHAUS: I think they will fix it. This is what they announced. We have no idea so far how they will fix it, and if this fix really works out. But the problematic part is the IPv6 address that is built from the IPv4 address, this one to one mapping, this seems to be problematic. The IPv4 address from this IPv4 continuity prefix never leaves your box. So it's significant on your local box and is never visible in the outside world.
RAYMOND JETTEN: Thank you very much.
(Applause)
There is no questions on the list or Meetecho. Now the last talk.
MAYNARD KOCH: I would like to give you an update on the deployment of routing loops in IPv6.
So, here, the numbers from the past two RIPE meetings. It decreased from RIPE 92 and RIPE 91, slightly a bit, About 10 million less looping subnets we see. However, it increased again during this RIPE meeting to 149 million sub‑nets /48 that trigger or lead to a routing loop. But we not only observed routing loops, we also observe amplification there for about 10 million /48 sub‑nets. This slightly increased for RIPE 91. And it slightly decreased here for RIPE 92. However, we did not see a significant downwards trend somewhere, so that's why we're here to raise the awareness for this topic.
A quick recap. What is a routing loop? So if we send a packet to let's say this specific /32 network, and the provider assigned a /32 provider address space to its customer around the customer only use a fraction of it, and it has configured a default route, then this packet will get back to the upstream forming a loop. So the packet is just looping back and forth between these routers.
And finally, we will receive an ICMP time exceeded message as soon as the IPv6 hop limit goes down to zero. So, this is not the only problem here. The problem is that there is a router bug that leads to the duplication of packets.
So, the duplicated packets loop as well and first of all they may overload the network between router, between provider and customer, but then finally, each duplicate triggers and individual ICMP time exceeded message which means it floods, in in case, the scanner with time exceeded messages. However, this can be anyone, so not only the scanner, but this can if an attacker is able to spoof the IP addresses we can just, or the attacker can just use it to flood the victim with ICMP time exceeded messages.
So how can we prevent it? We can omit the default route but another option would be for the customer to install null routes for the address space, that way we would actually get rid of the routing loop and also get rid of the amplification.
So, here are some statistics for the RIPE region. We found about 2k ASes that are affected. More than 3 hundred thousand router addresses. And about 86 million /48 sub‑nets that lead to a routing loop and 87 million prefixes for /64 prefixes that lead to a routing loop.
And for the amplification, it's quite less, but still almost 6 hundred ASes affected, almost 4 thousand router addresses that we observed. And there we see that about 2 municipal /48 sub‑nets and 100,000 /64 sub‑nets not only lead to routing loop but also to amplification.
So, what are the takeaways here? Loops of bad of course, amplifications are worse.
But if you just fix these routing loops, it would also remove the amplification threat. And because the address space in IPv6ing is more likely been partially used, they are more likely to occur than in IPv4. And some router implementations, so this is a bug not a feature, they duplicate these echo requests creating huge amounts of amplifications. We can expect an increasing threat potential with ongoing IPv6 deployment.
So, what can you do?
This is a call for action here.
So, check if your network is affected or the networks of your customers. And then fix it. How can you do this? We provide weekly updates about routing loops and amplifications on our web page where you can also check your AS, and if your AS is affected, please fix it. If you don't know how, reach out to us, we can guide you through, we can provide more details on the affected router IP addresses, and as well as the affected sub‑nets that lead to a routing loop.
If you are interested in more scientific details, check out our recent cone X publication, with that I would already like to conclude my talk. Thank you very much. I am happy to answer any questions.
(Applause)
RAYMOND JETTEN: Thanks Maynard.
AUDIENCE SPEAKER: Working for Cisco, I just wonder what kind of routers, if you have been able to identify the most cheap CB or is it a Juniper, Cisco, or whatever router.
MAYNARD KOCH: It depends. We have Juniper and Cisco routers, different models, mostly kind of outdated. We trace this back to a Broadcom chip set where Broadcom said it's product limitations they won't fix it, you just need to get new hardware. That was basically the message.
RAYMOND JETTEN: Okay. Any more questions? No. Next up Benedikt. And we found a killer app for IPv6.
BENEDIKT STOCKEBRAND: Morning everyone. This is just a quick one. A couple of ideas I have come up with doing some weird network stuff again that's not exactly standard and learning a few things about networks that are for change AI generated so I tried that as well.
Right. So, I want to talk about the killer app for IPv6. We have been searching for that for 25 years or so now. I have found it. I thought I had found it before. But no, it's not like I want to talk here the killer app for IPv6 is IPv4, because yes, we need IPv6 to keep IPv4, well, I am not going to alive, that will be a bit exaggerated so I'm not going to talk about all these misery prolonging technologies, whatever they are, which use IPv6 to provide some sort of IPv4. Today I want to talk about Layer2 and IPv6.
One of the things with one of my customers some time ago, I got the chance to learn a bit more detail about how switches work internally which normally don't even get a chance to sign in the air, about it.
I learned a couple of things. First, in my mind, as I was trained basically, routing is slower than switching. But when we talk Layer3 switches, that's no longer true. You can do routing as quickly as you can do switching, at least in contexts we don't talk about core routers.
That has some ramifications because it means performance is no longer a reason for some Layer2 technologies that we use, as I said vendor information is hard to get. Sometimes you have to try things and be lucky and have a customer that has an NDA going on so you get the details. In that case it was about realtime networking inside cars.
And there are two technologies that I think we can largely replace by better alternatives, if you go from move capabilities from Layer2 to Layer3 first on VLANs. Maria an Monday in her tutorial came up with something that I thought was kind of weird by somehow connecting VxLANs and VLANs, because everybody who doesn't actually implement certain things would try to use either one, preferably VXLANs, but combining the two. At first it felt weird of course if you want to migrate from one thing to other, it's just great that somebody actually took care of that. What if we used VXLANs instead of VLAN, moves things from Layer2 to Layer3, I guess you have an idea, I hope, what VXLANs do, so you get more, VLAN IDs or VXLAN. So, you have routing capability, you can move things halfway around the world, blah blah blah blah, it makes things a lot simpler and easier. If you don't want VXLANs, there is Geneve coming up, there is segment routing, and even when we talk VPNs like we use to tunnel IPv6 over IPv4 like 20 years ago, you have all these options. And especially when it comes to VXLAN, once you combine that with microsegmentation, you don't even need the multicast routing part that you need if you want to connect more than two device to say a single VXLAN. That can be interesting, I have been playing around with a couple, I don't know how to explain it with a couple of weird ideas I had and wound up using lots and lots of virtual point‑to‑point links rather than virtual bridges, and once you get the hang of it, it actually makes sense as well, and you can combine all these things.
So, if you are using VLANs and you are in trouble, maybe considering using VXLANs over IPv6 and get rid of a number of limitations.
The other one we had a bit of fun with with a different customer, explaining tree protocols. I don't like them. Not normal spanning tree, whatever, largely because once your networks reach ‑‑ grow, at some point, you connect one hop too many and then things fall apart in a rather weird way. So you don't get any proper error messages. So basically any dynamic routing protocol is better than spanning tree, except RIP NG. There are a people who say it's not a routing protocol anyway, it's more a disaster in the making. We win convergence time. If you use proper protocols you get convergence timings which are good enough to do voice‑over IP over, at least it's reasonably useable.
Then the scaleability. That was what really cause this had trouble getting the network too large, one hop too many and spanning tree, it just doesn't fail properly, sometimes it works, sometimes it doesn't, and it feels like you are chasing something that's ‑‑ like you are chasing a ghost.
Scaleability, error behaviour, spanning tree is an ancient protocol, you do not want to use it.
.
So, the fundamental idea is if you want to deal with these problems or if you are using IPv6, use it even for problems you have in a different protocol. It's counter intuitive but it can actually help. Then of course there is the 12th networking truth, in case you don't know, read the RFC it's only about a page long, it's helpful. So the idea is don't just put new things in there, it applies to protocol design, it's an RFC after all, but the idea is get rid of things you don't actually need. So in our context it means more something like network design, get rid of anything you don't actually need, and then you have got, then you could have a clear, clean design.
Okay, that's it. So they are my contact details if you have questions, if you want to find me, or if you have questions right now.
(Applause)
RAYMOND JETTEN: Thank you Benedikt. Any questions? Okay. Then thank you very much.
We have come to the end of our IPv6 Working Group session. Please rate the talks, and of course remember our cat, and get out of here, it's coffee time.
(Coffee break)
.