RIPE 93
Main hall
29 October 2026
9 a.m.
LIVE CAPTIONING BY
MARY McKEON, RMR, CRR, CBC
DUBLIN, IRELAND.
WOLFGANG TREMMEL: Good morning everybody to your favourite Working Group. You can have IPv6 and you can sleep later.
.
Find your seat, relax and enjoy the session.
.
I am Wolfgang Tremmel and I am chairing this session together with Christian and Raymond. Welcome to the IPv6 Working Group. The agenda: We have a couple of speakers.
It should be interesting. And let's get started. Please keep in mind the Code of Conduct is here to make everybody feel safe. This is also a hybrid session, and it's being recorded. Also, please turn your mobile phone to silent.
And thank you to the stenographers and scribes, it's really early morning for me, sorry.
STENOGRAPHER: Wait till you see what I write!
.
WOLFGANG TREMMEL: We have sent the notes of the last meeting to the list a while ago, there were no comments, so I guess that means the notes are approved. The IPv6 Working Group exists to promote IPv6 adoption and we are including outreach, education, sharing development experiences and discussing and fixing issues if there are still any.
How to participate?
Well, welcome to the room, you can participate in person. If you have a question, go to the microphone, state your name and affiliation, or you can also participate online, use Meetecho, write your question in the Q&A section and we will read it out for you.
How is IPv6 doing here? I found this nice website on APNIC, and it's the IPv6 capital rate, not the usage rate, the capital rate, and if you zoom in, that's here, Bulgaria, and you might notice that in 2022, the IPv6 capability really, really picked up. I have no idea which provider enabled IPv6 at that time, but it's growing, and it will need to continue to grow in the future.
Have a look at the website, the URL is on the slide.
Also, we have to announce a co‑Chair change. We posted a call for co‑Chairs in August. Christian stated he wanted to continue and there were no other candidates, so, welcome back Christian as a co‑Chair.
(Applause)
.
Back to the agenda.
The first talk we're going to have is from Saleem Bhatti, talking about the identifier locator protocol which already talked at RIPE 92. So now we will continue with that. Oh, one more thing. Announcement from the organisers: The voting for the PC election will close today at five o'clock, so please be sure to cast your vote. Also the RIPE NCC members who have registered for the General Meeting, they can vote until nine o'clock in the morning on Friday.
SALEEM BHATTI: Thank you very much, and good morning to you all. So this morning I am going to be talking to you about the identifier locator network protocol, and this is a research project, I am working with Rodney Grimes and Alistair Woodman, with support from the the ICANN grant programme. A bit of background first of all about this talk.
So, at RIPE 92, as Wolfgang mentioned, I gave a talk on the privacy properties of ILNP. After that talk I had people come up to ask me what is ILNP, what does it do. So this presentation is a direct response to that in order to answer those questions, and give a more general picture about ILNP.
Some more background for you, if you are not familiar with identifier locator approaches to addressing in general. This is something that's been debated for quite a while within the community globally. I have just put on there three or four things that you might find particularly interesting. Certainly the first two they are in bold because they influence the original thinking for ILNP and how we got started. That was the name space research group, which was an IRTF research group, also the 8 plus 8 proposal, the draft for that is still available on the data tracker if you are interested and if you are familiar with that, you'll see when I put up a couple of diagrams, the similarities that are there at lease at packet level, although in terms of actual behaviour of the protocol, ILNP goes much further than the 8 plus 8 proposal did. Some of you also may have heard of NIMROD, which had very similar ideas but didn't actually have a working implementation but did have a lot of same terminology and ideas. In fact there was even an attempt to do this with IPv4, almost 40 years ago it was a dapa project and someone pointed me to that earlier this year. I wasn't aware when I started the work but it's interesting to see that this idea has been around for a long time, even attempted to do this with IP version 4.
The basic principle, as far as I'm concerned with the identifier locator approach to addressing is to reduce the semantic overload of the IP address. So, what the IP address does today, it has two main functions. Will it serves and identity for a node, which hopefully is globally unique, and it also acts as a network or topological locator, so that when you see these address values in packets they can be routed and forwarded to the correct place, which of course is what we need.
Discussion about the identifier locator approach appears time to time on the Internet history mailing list, that link there is to the most recent discussion that was in May this year, and ILNP, the identifier locator network protocol that I have been working on is really just one of the solutions in this problem space. Of course that's what my talk will be about, but it's good to have an idea of what other possible solutions exist in the area.. RFC 6115 gives a good summary of various proposals that are available at the time both from the research community and within IETF, and I have just put up there three that you may be familiar with. Those are just different approaches to realising the identifier locator approach. So, there is LISP, there is mainly promoted by CISCO. There is HIP, which was based on cryptographic identities, or cryptographically verifiable identities at least, and then there was Shim6, that was mostly concerned with multihoming but then did go on to look at mobility and other things.
All of these things are also solutions. There were working implementations of those. But they still have this basic problem that they overload the semantics of the IP address, all of them use the IP address and they give it yet more meaning, and that causes confusion as toe had you they are going to be used, you see an address and you think well what is the meaning of this address.
So this is pretty much why ILNP exists. So I work for a university. So for me this was an interesting research topic initially and ILNP is both the same of the protocol and the architecture which was a vehicle for me to investigate an identifier locator approach which didn't use IP addresses at all. You'll see that that's what we have working now. So we don't actually ‑‑ we have addressing, but we do not use IP addresses. So you don't use IP addresses in the protocol stack, instead you use different data types and you have much more dynamic binding of those data types within the protocol stack, but you still get something that works for IP version 6 on the wire, works for routing, routing is happy to route those packets and applications work as you'll see. Again in a wider discussion within the research community over the years, why would you want to have an identifier locator approach? Surely we have IP addresses and they work, isn't that fine? Well people have proposed that if you can come up with a working solution for an identifier locator approach, you can have some properties that fall out pretty much as first class properties of the architecture, and you are able to have those kind of for free. Instead of being additions or extensions or after thoughts, they are part of the architecture. And this involves ‑‑ this includes reduced global routing state, more flexible addressing including for local numbering for sites, improved multihoming and multipath capability. I'll show you a demonstration of that later. You are better support for mobile nodes and networks, you can have improvements in identity privacy and location privacy at the packet level. That's what my RIPE 92 talk was about earlier this year in May.
Now, if those research questions aren't interesting for you, if you think, you know, why would I want to use ILNP instead of IPv6 if I'm not in this research domain, another way of looking at this is an alternative design and engineering pathway for protocols that sit on top of IPv6, and you'll see why you might want to do this later on when I describe how transport state is changed and we see the demonstration.
So this brings up some questions in terms of both research and engineering. So, is it possible to actually build this and deploy it? That's important because we can't have a flag day where I bring out SEK completely new and persuade people to change everything. So this has to be deployable on existing infrastructure. And can I have as many as possible of these desirable properties that I have spoken of? I think you can, I think it is possible. But the deployment issue is pretty important. So can you build something that does have these desirable properties. Can work with new addressing data types, but does have protocol level compatibility with IPv6 at the protocol level, will routers be happy with if? Will applications be happy with it? Can it work with existing API and existing applications? You'll see that at least in the test bed that I have to my lab in St. Andrews and work we have done in the hackathon, it's actually possible. That's pretty much what ILNP is, it is both the name of the protocol and this architectural approach with new addressing data types which I'll explain. Better dynamic binding for these data types within the protocol stack, including for transport layer state, and it does offer, I am proposing, an alternative pathway for design and engineering of protocols if you want to make them work over IPv6. The specification for that is mainly in some RFCs that have been published for a while but very recently there are some new drafts TLA I'll mention later on. These drafts actually just help make ILNP much more IPv6 friendly and improve deployability. Overall ILNP tries to pride as much of their desirable properties as possible that I have spoken of.
It's and end‑to‑end architecture to help deployability. There are no tunnels, no proxies, no address translation involved and you don't need to change anything in the network, nothing in terms of routing or switching changes as far as IPv6 is concerned.
So, here is an example of how things change, and it's a good way explaining how the new data types work and how the state management works for transport. So, here is a very simple picture of two processes, process 1 and process 2 and they are sitting on host 1 and host 2, and for IP, you have addresses for each of them, you have address 1 and address 2. If you look at the transport layer state, you have got the remote and local port number and you have got the remote and local address.
The address is tied to an individual interface. So that means your transport layer state is also tied to that interface. So if you do want to have multihoming, multipath or that flow, you want to make mobile, you have to do something else because the transport layer state is tied to that interface. If you want multiple addresses, that's possible, IPv6 allows multiple addresses on the same interface, you could have them on different interfaces but you still have that additional state overhead.
ILNP changes that in the following way: So instead of addresses we have two data types. You have identifier values that are specific to a node, so we call them node identifiers. And then we have locaters. Now both of those things, for IPv6, a node identifier is a 64 bit value and the locator is a 64 bit value. That is exactly the same in terms of syntax and semantics as an IPv6 prefix.
Transport layer state changes however. So instead of having a full 128 bit address value as part of the transport layer state, you only have the identifier values. These only need to remain stable for the duration of the transport flow, so a node can have multiple identities, it can even generate identities on‑the‑fly. You can have ephemeral identities and that helps with privacy, and again that was what I talked about in May at RIPE 92, and ILNP supports that.
Then in order to be able to send packets across the network, of course you need to have a full 128 bits, so you have a dynamic binding to a local locator value and a remote locator value. And you can use as many of these as you like. They are just dynamically bound to an interface and that dynamic binding is enabled through IPv6. So you wait to see a route advertisement in an interface, so you know what prefixes are available and so you can just dynamically bind that transport state. So potentially every thing in packet that goes out in a transport flow could have a different source locator and destination locator. So you can really have a very agile transport layer flow.
So, how does this all actually work over IPv6?
.
Well, you have compatibility on the wire and you have compatibility with applications. So you have these new addressing data types, the node identifier which is 64 bits, and the locator which is 64 bits. And so, those need support in DNS and I'll say a bit more about that. And you need to modify libc, to get at your info call so that that behaves correctly for existing applications and that's what we have done.
IPv6, the packet format is reused to carry the ILNP data type. So we just treaty it as a data structure to carry ILNP. We also have an additional option header for IPv6 and that's included in every ILNP packet. So a receiver knows that it's got an ILNP packet instead of an IPv6 packet. And to allow dynamic use of locaters, there is some ICMP messages, new ICMP messages that allow a handshake between the communicating hosts. They can tell each other here are my new locator values. And the only part of the overall system we have had to change is the end system stack. So we have changed the network layer handling of these data types a a bit in the transport layer, the protocol control blocks in order to make this work in FreeBSD.
So this is what packets look like on the wire, on the left is a familiar will, packet header, source and destination address. At the end system this is what an ILNP system will see. It sees the place where you would have a source address as a source locator and a source identifier, and again, the destination address, destination locator and a destination identifier, and of course as I said this optional header is present, it's an end‑to‑end header to indicate this is an ILNP packet, so it should be handled using ILNP code and processing rather than standard IPv6 code and processing.
The node identifier and locator values need to be present in DNS. We of course selected DNS, that makes good compatibility, we have existing applications, but you can actually use anything you like, there is no requirement to use DNS if you want some sort of private name resolution system that's entirely possible as well. So the new resource record types are defined in RFC 6742 and happily they are supported by a number of DNS server software and resolver software which is, great.
.
ILNP can also support existing applications. So as I said with modified libc, so get ADRA info has been modified to fetch these new record types from DNS and because the NID is 64 bits and the locator is 64 bits you can form 128 bits which is what you need to pass cross get ADRA info in libc so that keeps the applications happy. As you'll see in the demonstrations later on those are standard IPv6 applications, they haven't been reengineered or recompiled, it's just normal IPv6. And this is the set of drafts that we have that just effectively document our, the changes to the RFCs from our implementation in line ex and FreeBSD over a number of years to make ILNP even more v6 compatible, if you do have the time and want to read through those and give me comments I'd welcome that, and even more welcome if anybody would want to review those so that we can move them along and get those ratified just as experimental RFCs like the original RFCs, so that everyone can build those with a bit more confidence that they have gone through a review process.
So, the demonstration. I am going to show you two short videos. Both are from tests that were run in July at IETF 126 these were test runs were IETF was from the hackathon room back to high lab in Scotland. First demo is very simple. It shows name resolution, using drill, and it just makes a query for a fully qualified domain name to DNS and from that you'll see there are no AAAA records, only NID and L 64 records and then traceroute runs with those values just fine.
And then the second demo shows normal TCP running over an ILNP socket. So once you have those two data types, instead of creating an IPv6 socket you create an ILNP socket and you gain some of these good properties that I have talked about, so you will see normal TCP flow that we have just for demonstration purposes showing that it can run over multiple paths. In fact the multipath part is just to demonstrate the address amendment and the dike binding for ILNP. We're not claiming that this is a replacement for multipath TCP. There is no congestion control in ILNP, That all happens at the network layer, congestion control is still is something that needs to happen in the transport layer.
This is the network configuration. Very simple, on the right‑hand side we have our client running and that was given the fully qualified domain name C 1.IETF.ILNP.net, that was running in the hackathon room. In Scotland in my lab, I was running a server and that had the fully qualified domain name H 1.US TA.ILNP.net.
So if we look at the first demonstration, what you'll see is that both of these nodes just use drill to query DNS for each other's fully qualified domain names. As you see there is no AAAA records, it's only the NID and the L 64 record that comes back. And then traceroute runs, using the same fully qualified domain names. You don't need drill to run, that was just for this demo. Traceroute could run just using those names without having drill run in the first place. And you can see the traceroute just works fine and finds the paths.
.
The second demo use Iperf 3 to run an Iperf server in my lab in St. Andrews and then an Iperf client in the hackathon room. And in the hackathon room I had a little desktop machine, all that little, that little vote photo you saw that was a desktop router that was new, just a cheap router with multiple ports. It was IPv6 Openflow, nothing modified. That router took a/60 prefix that we had been given by the IETF NOC, split that into /64s, and I had a desktop machine in which I had forced in a server NIC with 4 gigabit interfaces, and each of those interfaces was brought up one at a time. So I started the flow with one interface, as you can see while the flow is running, another interface is brought up with another prefix, a third interface then with another prefix and finally a fourth interface with another prefix.
So, those prefixes all happened to be within the same/60 for practical convenience of the experiment but they could be completely separate prefixes, it doesn't matter. As you can see the flow seems to be progressing fairly well. And you'll see on the left before I started the Iperf server, I started TCP dump to capture a PCAP file and from that I got a graph which I'll show you about what the threw put looked like and how the packets were distributed across those prefixes. Remember, this is normal TCP. Just opening an ILNP socket so that you have some multihoming and some multipath and the multihoming and multipath, the path diversity is tiny. It's the little 15 sent metre patch cable between the router around the switch in the hackathon room. So nothing major.
Here five graphs. Time along the bottom axis for the duration of the flow on the vertical axis is data rate and on the bottom line you have the aggregate throughput end‑to‑end between server and client which you can sigh is stable. Each of the other four graphs shows the data that was sent using each of those prefixes. So, you can see initially at the top there was only one prefix. Then we switched to two prefixes, and the data is shared across those two paths. Then a third prefix and a fourth prefix and then the flow ends.
That was with TCP. I haven't got the video for it in this presentation but you can do the same thing with UDP and as you expect a similar thing happens, you get fairly stable data end‑to‑end and you get the data shared across the four paths.
Overall, it seems that ILNP can be used with IPv6. You can have new data types available, and you don't need to use IPv6 addresses. The applications are happy. The network is happy. So you do have this alternative design and engineering path for protocol sitting on top of IPv6. Many, many things on my to do list including trying existing protocols and for the future from a research point of view, if you can make new transport protocols and even applications that are ILNP aware, they could have much more dynamisity and flexible transport layer flows.
So I'm very happy, hopefully we have enough time for some questions, take some questions now, I am around till tomorrow evening, I am around till tomorrow evening, I am around at the dinner this evening. So please come and talk to me about ILNP. Thank you very much.
(Applause)
WOLFGANG TREMMEL: Are there any questions?
AUDIENCE SPEAKER: Hi. Sander Steffann, just speaking for myself. It's really interesting the bit I worry about is debugging if stuff goes wrong. I am not sure if this is a good idea yet but I really like the way you made it work with existing applications in existing environments so that actually gives it a nice chance of actually being deployed. So, I really like the research and I'm curious to see where this goes.
RANDY BUSH: A dinosaur who is stuck 30 years ago. Could you describe the significant differences between this and 8 plus 8?
SALEEM BHATTI: Right. 8 plus 8, the structure of the address is the similarity with ILNP and 8 plus 8. After that, the protocol behaviour, they are signalling with ICMP, all of that is new. So really the only similarity is the 8 plus 8 approach and the fact that that is now you do the split. The other similarity you could argue is 8 plus 8 was, I believe, input into IPng, I was still a student at the time but that was my understanding. So it was somehow input into IPv6. So that's the other similarity. ILNP is based on the use of IPv6 and because some of that fed through the 8 plus 8 structure, you do have this natural split for the prefix and the interface ID in IPv6 anyway, we were able to exploit that. So certainly that was very useful to have that there as input to the original IPv6 that allowed ILNP to work.
AUDIENCE SPEAKER: Mark from AFNIC. So, if you use the DNS to resolve a host name to an ILNP address, so you need to, from what I understand, would you need to send two queries because there are two different resource records type, have you looked into using the fairly new MQ type extension from RFC 1029?
SALEEM BHATTI: I have not, but I will, thank you very much.
JIM REID: Just a question about where you see this stuff going. What's your long term plans for this? Would you like to see it being incorporated into the various OpenSource sources of the BSDs and kernels or is this just plainly a research exercise?
SALEEM BHATTI: Definitely, we'd like to see this in BSD, we'd like to see this in Linux, we'd like to see this people using this, break it, see where it doesn't work. We'd like to have other people working on it. As I said, this is a possible, you know, alternative design and engineering path protocol, so we'd like to see people trying to use those desirable properties that now seem possible from using a totally identifier locator approach.
JIM REID: I just think that you might have trying to get critical mass behind this unless you can get it into the distros because people will look at this, this is too much hard work to try and incorporate into this my own kernel and so on. It would be nice if this was bundled in in the first place.
WOLFGANG TREMMEL: We have one online question.
AUDIENCE SPEAKER: One question from Maria from cz.nic. Do I understand correctly that there is really no need to update routing because it runs on existing infrastructure?
SALEEM BHATTI: Correct.
WOLFGANG TREMMEL: I guess that's it. Thank you very much.
(Applause)
.
Now we have the next talk.
WILHELM BOEDDINGHAUS: Thank you very much. I gave a talk about this topic in Edinburgh, and since then, a few improvements have come to the world and I just wanted to give you a brief update on those.
.
So, what were we talking about? We were talking about Layer3 networks in the office space. So we are talking about enterprise, we are talking about federal agencies, we are talking about Windows clients, we have millions of them in the world, and I would like to have to see that we have Layer3 switches and that we have a /64 per client. So that we have routed networks in the office space, not this large Layer2 LAN anymore. And then you can protect the client much better. But if you have IPv6‑only, what are you doing with all of your old IPv4 applications that cannot open a socket with IPv6?
As long as a client can open an IPv6 socket, you can use NAT64 to reach an IPv4 destination. But if the application cannot open the socket, you are stuck. And I know in enterprises and in agencies and in public agencies we have a lot of these old applications.
So, the technology we can use on the client to make sure that we have IPv6‑only on the outgoing interface comes from the mobiles, it's 464 XLAT. On Windows it is called WinCLAT. Okay, I have three agenda points I want to talk about.
The first is when I gave the talk in Edinburgh, Microsoft still was mapping the IPv6 address that is used for the CLAT mechanism, there is an extra address that comes with stateless address auto configuration, was mapped to run IPv4 continuity prefix with just seven addresses. 192000 is used as default gateway and then you have the addresses 1 to 7. This cannot work. So, now they are changed to an IPv6 address, the second 64 bits of this address, which are just generated randomly.
And they follow in this path operating systems like Apple macOS, this is a very, very good idea, because if you just have seven addresses in the network, you have a small network, if you want to have larger networks, it does not work, and if you have seven networks, seven addresses in the network, the applicator address detection will make sure that your network does not work.
So, they went away from this continuity from mapping the IPv6 address to the continuity prefix. They still use this continuity prefix, which is absolutely fine because IPv4 is just significant on your box in your main memory on your box, and then it is translated on the box into an IPv6 address, like we have done this in the cellular phones, mobile phones for the last decade. So this is a very, very good step forward.
Then we have this DHCP version 4 option, option 108, and this is a communication to the client between the client and the DHCP server where the client says okay I don't need an IPv4 address, the server said okay I have understood it. And it turns on this mechanism on a Windows box. So, the Windows box doesn't feel it is an error, it is a mistake that you don't have an IPv4 address. It's just happy with not having an IPv4 address.
Then someone asked me during a presentation. Yeah, but if I have a centralised DHCPv4, DHCP, a centralised server, how do I reach this server if I turn off IPv4? Well yes, that's a good question. And I came up with maybe one or two solutions.
So, one is you could configure a tunnel. This is ugly, we don't want to do this but it would be possible.
We have two RFC, 7341 and 9928 which makes it possible that you can have DHCPv4 running in IPv6. So that you can use IPv6 as a transport. The first one just make it possible to have IPv4 DHCP in IPv6 and the second one the 9928 is about relaying DHCPv4.
The last option that would be possible is that the local switch runs DHCPv4 to surf just option 108. We don't surf any addresses. We just surf this one option. It does work perfectly well with KIR so let's see what the different Windows can provide there that you run a stateless DHCPv4 service. In IPv6 we have this distinction between stateless and state 4. In IPv4 we usually don't have it because we always give out an address. About you if we just give out one option, then it can be run stateless on each and every switch an then you can turn on this mechanism, everything is fine and you can turn off the centralised DHCPv4 service because then you don't need it anymore, no IPv4 addresses are distributed anymore to your clients in your office space.
So maybe it's time to think of this stateless DHCPv4.
But this is a topic that has to be addressed because we can't say we turn off IPv4 and then we have to turn on IPv4 again just because of this option 108. So we have to find a solution there. So I will do some tests with different Windows and then I will talk about this maybe in one of the upcoming RIPE meetings what I found.
I have good news, this is now not a better software anymore, Microsoft has released it as a regular feature. Will they have now published a block article about it and it comes with updates and it comes to Windows 11, it will not come to Windows 10. Now we have CLAT working on Mac, we have it on Linux, on Windows,s so there is the door is open to IPv6 client only networks and this CLAT mechanism, in my view, is just the mechanism we need to then gain IPv6‑only networks, to have microsegmentation, to gain all of the advantages of IPv6, so that we can switch off Layer2 networking in the office space which will help with security and other problems.
It will help with IPv6 problems. We don't need router advertisement anymore, DHCP snooping, neighbour discover snooping, whatever we have so‑called Layer2 security in IPv6 can be turned off because we don't have any Layer2 other than between the client and the switch in a direct one to one connection.
.
So, the conclusion:
This was my conclusion from the last RIPE meeting. Now, this WinCLAT has come to the most used operating system in the office space. We have millions of those boxes all over the world on all five continents. IPv6‑only enterprise LAN is now possible. Microsegmentation of course helps with security. We all know this. Client traffic can already be secured on the switch because you can put IPv6 access lists on the switch or you can do quality of service because you have a Layer3 interface for your client traffic. Most of the issues in RFC 9898 are mitigated. This is an RFC that shows all of the problems we can have with IPv6 but most of them are mitigated just by doing microsegmentation, and you do it with a network design, you are not going to a vendor and have some fancy software that does anything for you. And now I think we should change from Layer2 network to routed Layer3 network in this office space and this will help with IPv6 migration in enterprises and in agencies, in public agencies, as we know in many countries these two areas are lagging behind, service providers are very far in front of it, and now we can go here and have secure networks.
Thanks for listening. Any questions?
AUDIENCE SPEAKER: Jen Linkova, Google. Thank you very much. I have not been paying attention to Windows recently, so, yeah, I am very glad to see that we are out of public preview and doing it. Do you know, I wasn't able to find the info, has it completed a rollout to Windows 11. I know Windows was receiving updates incrementally. Do you know the current status?
WILHELM BOEDDINGHAUS: I would have to ask, but it is now a regular feature and they have published the versions where you get it.
JEN LINKOVA: Again, I know very little about how Windows gets updated. I know there is automatic way for them to update. If you look in the room, right, do you think most Windows devices should get it already or?
WILHELM BOEDDINGHAUS: I think as soon as they have published this information it will come to all of the boxes. They talked about incremental updates a few weeks ago, now it's public and comes to all of the boxes. You still have to configure it. It's not automatically configured, it is not in the graphical user interface that you can configure it, so you have to configure it on net share, this is a curiosity because they want to deprecate net share and put new features on net share. Or you can activate it by via a group policy from your AD server. This is also possible. It is a little bit of manual work but it does work. Maybe it will get more comfortable in the near future.
LUCIANO LENZINI: I am curious if anyone in the room has Windows and could tell us what they have. It would be very cool.
Another question: I have not got ‑‑ I am a bit confused why do you need stateless DHCP? Can you just not relay the DHCP a packet. The whole idea was I cannot turn off the DHCP but I still do not want some clients to get v4. If you can't turn off the DHCP completely you don't probably even need 108 right?
WILHELM BOEDDINGHAUS: You need the 108 to activate this mechanism, because if you ‑‑
LUCIANO LENZINI: They don't do it even if they see pref 64 and do not get IPv4 at all, they only do it on option 108.
WILHELM BOEDDINGHAUS: They do this CLAT mechanism on 108. And if you don't get 108 from your DHCP server, You get regular IPv4 like usual, so you can take your laptop, go to Starbucks, have IPv4 there, and have ‑‑
LUCIANO LENZINI: My question was what if I disabled DHCPv4 relay on first hop router and your machine does not get v4 at all because there is no ‑‑ it does not get anything. It should activate CLAT.
WILHELM BOEDDINGHAUS: IPv6 works, IPv4 does not. But the Windows operating system sees this as an error state, because then you get this a P PA address.
LUCIANO LENZINI: That's funny because it's clear kind of violation of CLAT RFC we wrote but we'll follow up.
WILHELM BOEDDINGHAUS: Then we have to follow‑up with Microsoft. But have you found large ones that really follow RFCs completely?
AUDIENCE SPEAKER: I had this same question. So, just like when the first version of this CLAT was released in macOS it suffered from the same thing. The only way to activate the CLAT was there has to be option 108. However with the next OS release of macOS it was changed and now you can really have CLAT activated with pure IPv6 network when there is no DHCP. So I hope this is also a transitional state from Microsoft. I was also thinking of some single purpose DHCP server that only servers option 108 but never IPv4 address. But I think this is still run IPv4 service for not having IPv4 after all. So I think this is like a wrong way of doing things and hopefully eventually this will get fixed.
WILHELM BOEDDINGHAUS: Hopefully, yes. So let's see what the future brings. Thank you very much. The
WOLFGANG TREMMEL: Thank you.
(Applause)
JEN LINKOVA: Good morning. So let's talk about boring stuff about documents. Before we start talking about documents, I have a bit more interesting stuff. You probably have noticed that we have been talking about oh how can we get operators come to, please come, why not. ? We have been doing a lot of presentations about this.
So, I think maybe the solution is actually to get IETF come to the operators. So the plan is again it's not a hundred percent confirmed because I still need to submit a BoF proposal. The idea is that in the next RIPE meeting, RIPE 94, we plan to do interim meeting for IPv6 ops Working Group here co‑located with RIPE, probably Monday or Tuesday so you can get your IETF experience for free. Just one hour, so if you don't like it, no strings attached. So, please keep an eye on the agenda for 94 when it's published and to the BoF slots.
So, it's going to be pilot so let's do one Working Group and see how it goes. If you'd like to see some other Working Groups, you could talk to IETF people who are around, like you see some of them around. If you think we can do something else, please let us know. The
.
So, I am going to talk about documents and kind of put them in three packets so let me remind you to get a baseline, how the document lifecycle looks like.
So, obviously anyone can write a draft. You can write a draft about new protocol, like IPv8, IPv10, IPv42, whatever. And that's okay. But then you need to convince a working group that it's a great idea. And then a working group would adopt your document and say okay, great, there is a problem to solve, we like the solution, to let's work on it. So I am going to talk about Working Group drafts, right. I completely ignore what individual documents we have because individual documents do not necessarily describe a problem IETF thinks worth solving. After a while when the document looks good enough it goes to Working Group last call when Working Group looked at this for the last time and said good, let's ship it. Will then it goes to IETF last call. At this stage you still can comment on it but I think it's less desirable because any substantial changes to the document might actually require a document to go back to the Working Group. Because after the Working Group last call the document kind of represents the Working Group consensus, and IETF last call is more like a chance for people outside of the Working Group to say something. So, ideally, stage 3 is where you should stop, not should but it's basically the best moment to review the draft and give your feedback especially if you propose substantial changes.
After that, the directors say let's review and says it's going to RFC, it's normally editorial changes at this stage.
What's happening in v6 ops and Working Groups. V6 ops are responsible for documenting operational part, how to operate v6 networks and 6man responsible for modifying the protocol extension.
So, the v6 ops there is currently a document about IPv6‑only deployments in 5G. I don't know anyone deploy like, anyone operating 5G here? You might want to take a look and tell people. You probably might ‑‑ I hope you find it interesting, so if you have any comments, suggestions, please comment on this. It's still like Working Group document it hasn't been in the last call, so it's a perfect time to provide your feedback.
Second document, for this one we have an author in the room so I am just let Ondrej to tell us about the document.
ONDREJ CALETKA: This is my document. It is stuck in state number 2, so I would really like to see, to get some contributions, maybe I would just ask for last call only for people to read it. It goes to something that I talked about at RIPE 90, which is basically that we have a VPN that is dual‑stack, that means every employee has IPv6 access to Internet services but they cannot use it because when they are not connected to IPv6 network, the operating system decides not to do AAAA queries, and this is not documented, it's wrong, and I decided that the best way how to fix this is to set up a document that says under which circumstances it is good idea or a bad idea to filter AAAA queries from DNS resolver in operating systems. So if you can go ahead and read it and maybe do some, have some comments on it, it would be great. Thank you.
JEN LINKOVA: I will go through the slides quickly, I will put references to any document so if you find anything of interest to you, please take a look.
Please take a look. If there are ISP people in the room, It's an update for the customer requirements. Mostly it's actually related to transition technologies and support for v6‑mostly and v6 only and other transition stuff.
This ‑‑ you should be well aware of this. It is basically RIPE 690, published in the form of RFC. Again it's a working group document, it has not been through the last call. I think it's fairly close to RIPE 690 content. I think Jordi is working on this document, but it has some changes. I tried to summarise them on the slide here, I think the document is talking about/352 now and some IP repetition and stuff.
And Jordi has been doing a great job on promoting some of the existing documents to standard, to Internet standard status. So basically this is not real change to the document content, it's mostly like integrating eradum for those documents, it's basically stateful NAT64 and the translation algorithm for translating v6 to v4 and so on. So there is no real, mostly no changes there in terms of how the protocol operates. But I believe that for NAT64 document, it's operational consideration sections have been altered.
So, my stuff. This document actually was supposed to run through the last call but we just put it back to the Working Group because we found some interesting inconsistencies, I'd like the Working Group to take a look again.
If you try to run traceroute on this network, for example if you are macOS or maybe v6 only Windows now, you probably notice that v6 only hops between your device and NAT64 translator could not be shown because your CLAT cannot translate proper v6 address, there is no way to represent a random v6 address as v4, which confuse like no one can feel support because traceroute and you see no responses, you must have packet loss, what we are proposing, we are proposing that a special IPv4 address will be shown and traceroute instead, it's better than nothing, it is a clear indication that this hop is actually just v6 only router so it doesn't have any v4, actually v6 address of the router will be, may be represented in extension inside ICMP.
.
Look back, we have so many v6 addresses, right, why we have only one v6 address for look back. If you run set ups when you want to have more addresses on your look back, there is a document currently in 6man about allocating end prefix, we still argued what size of the prefix and should we call it look back or something else, but the idea is the same. We might get more addresses for you guys to put on your machines.
Working Group last call, IPv6 node requirements and 6man. So we currently updating the list of things which IPv6 node should actually support and do. So if you care about how hosts behave, this is a document you might want to read, or ask your AI agent to summarise it, whatever.
Some documents as I said said might be past Working Group last call but still IETF last call has not finished so it's still time to comment on them.
So, people who were in the Plenary on Monday, saw much a long presentation about this, there is a document which describes methodology and best current practices for how to test your applications to make sure does it actually work on v6 only? Very good stuff if you want to test your applications, or if you are actually developing applications or just enabling v6 only and want to make sure all your applications in your network work.
Jordi has been working on finally defining what v6 only, v6‑mostly and dual‑stack and all this means because unfortunately those terms are a bit overloaded and might mean different things in different context. Sometimes when you talk about v6 only, access operators tend to think it just v6 only access, but host still have v4. I am more like enterprise stuff, person would think v6 only means end points don't have v4 and so on. Right. So this document is kind of definitions. So it's very good to use in your internal documentation for example, when you talk to vendors, because we all know it's very important to have a common language with vendors and do not tell them just please support IPv6. It normally doesn't go very well.
We wrote a document if you deploy v6 only and v6 mostly and you are using NAT64, you might have a problem, I have seen it in the wild, when you actually want traffic to go through NAT64 not just for Internet destination, but for your corporate stuff. Unfortunately, the current standard does not allow NAT64 devices to use well known prefix to translate private v4 addresses. This is actually a shame because it complicates the topology. If I want to do NAT64 to private space, I would need to have ‑‑ I would need to use network specific prefix which is sometimes inconvenient. So we tried to change this.
So, it's my document, I love it, so everything Ondrej, I and Nick from v6 ops shares, everyone will know how to deploy v6‑mostly and what kind of things you might see, we put in this document. If you have not yet deployed v6‑mostly, you are going to, I recommend you take a look at this just to make sure you learn from our experience.
So, a number of documents which I will read past are all past last calls and are going to be published soon.
CLAT, we basically wrote a list of requirements and defined behaviour of CLAT. That's why I was so surprised to hear that Microsoft implementations require option one way, because the idea was option 108, should indicate you use v6 only, especially if you get pref 64 because it clearly means the network is trying to tell you something. If you are curious how CLAT should behave, read this it's a standard document. Who uses YANG? We now have a model for neighbour discovery. I am quite sure you want to know your neighbour discovery stuff using YANG so here is your document.
Yes, theres a nice talk about neighbour discovery considerations. So after you deployed it and you are monitoring, you might still want to take a look at what kind of issues especially in scaleability and security, you might see, so, this is a very nice read.
And you might notice that we have not exactly standards a number of them how to discover NAT64 prefix. You can try to resolve a well‑known IPv4 only name like IPv4 arpa, or you might send pref 64, so we published a document to summarise this and provide recommendations what method should be preferred. And prefix delegations, are you giving prefixes to your customers over PD? Cool. Yes, so now CPE is actually supposed to delegate prefixes downstream because currently it's a kind of shame you, I hope, not given new customers a /64, you are probably giving them a /56 or something, and the router will use some of those prefixes to interfaces but the rest of the prefix sits unused, and now you can connect another router downstream and extend your connectivity downstream using PD. That's actually zero minutes. Please provide feedback on those documents and I have run out of time, but I'm here till Friday evening.
WOLFGANG TREMMEL: We still have a few seconds for questions, so if you have a short question, that's okay.
Thank you Jen.
Now, our next talk.
REMCO VAN MOOK: Good morning everyone. My voice is still working, that's a pretty good result after last night, let's say.
Nothing left to take away. This is my story of what now has the very inspiring title of draft IETF IPv6 resolved gateway.
Nothing left to take away. Something recognised that phrase. It is from RFC 1925 rule 12 that the network troops. "In protocol design perfection has been reached not when there is nothing left to add but when there is nothing left to take away." We are going to get protocol design perfection for IPv4 by removing everything else.
Because we have now come to this point. IPv4 endpoint identifiers actually no longer require IPv4 infrastructure. Thanks to RFC 8950. Which means that your network can actually transport a v4 destination across v6 hops, which is amazing. And I mean, there is more documents going through the IETF. I think the current one is IETF last call. IETF evaluation. So it's past Working Group last call, it's at evaluation stage. I mean with Jen's lovely chart from earlier. That means we can start doing something also on the host side, which is the last bit that the IETF standardisation hasn't touched yet. Why do I need any of this at all? Well, IPv4, much to the disappointment of this Working Group, is not going to go away. We have residential v4 demand served by dual‑stack, or I mean we have subnets and addressing plans and first hop resilience and dual failure domains, or you would have massive NAT boxes and lots of states to maintain, or any other combination of address translation.
And this is actually the only bit that applications are interested in or want to know about, which is I want to connect an INET socket to 192.0.2.1, port 80. All the routing, all the everything in between, the application doesn't give a shit about. So, what's standing in the way there? I mean everyone seems to love ARP. I don't know. And people say ARP, it's just so delightful, it's simple. It's not simple, it's primitive. And there is a very important distinction here. What is ARP?
A C struct. That's it, nothing else. Actually it's a very bloated C struct, because it really conveys, I mean how many bytes? A very small number of bytes in much more. All of the greyed out stuff in this slide is basically information that is transmitted on the wire with every ARP packet only for the benefit of matching the C struct in the kernel course associated. You can do a lazy copy‑paste of what's in the packet buffer.
None of that matters. So, the only reason when that was even a thing, because this is 1982, where every bit was precious, this was also in the time of co‑ex ethernet, BNC connectors and bridges and repeaters, where you had to have a minimum packet size in order for collision detection, I understand I am using rude words at this point. Were still needed to make a network work.
So, what is ARP? You get I mean the host side has a very dramatically simple table. It's one IP, one Mac, one TTL, or as the network operator you don't get to use the TTL, which the host uses, which is delightful. The network side every resolution is a broadcast, there is literal decades of external crutches, we have EVPN suppression of MAC addresses, we have Mac filtering built in to switches in all sorts of terrible ways, we have rate limiting, ARP caching in some intermediate layer. And we also have spoofing and poisoning and other security issues. Any broadcast segment with multiple tenants on it will run into these.
And really, what you look at, especially in like a hosting environment or even an IXP environment, is nobody really has any much interest to talk to other stations on a broadcast domain anymore, your server wants to talk to the Internet. Your home router wants to talk to the Internet. Mostly not your neighbours, and it certainly doesn't want your neighbours to pretend to be you. But given that we're doing this ARP thing, and there is a whole chain that follows from it, in order for a host to decide whether to ARP locally or ARP through a gateway, it needs to decide whether an address is on link. So that needs a sub‑net, then you need a gateway because you need to be off that, and you have to have a gateway that must survive, so you get the first hop resilience protocols and those are again the crutches with virtual ARP addresses and God knows what else, because ARP is primitive. And then you have sub‑nets need to be sized, you need to plan, need to route it and all of that has to be run so you have to IPAM. I am probably telling nothing new here. All of this exists right now only so a host, or consumer router, can send an ARP to talk to a default gateway.
Now, here is a mechanism in my draft.
It's keep the shape and change what it means.
So, any operating system, any kernel is looking for okay what's my default gateway, and it very deeply codified not just internal code in the DHCP but every back‑end and front‑end system, every single shape, every web interface out there knows for a fact that a gateway for v4 looks like an IPv4 address. So, let's just use one. And let's call it a sentinel ‑‑ I had the audacity to suggest a number earlier and I got very strictly told by Erik that I was not allowed to do that so I'm using a number from documentation space right now, I will be an IANA gets to decide the final number, it could very well look very much like this.
Then what you do on the host that you update is if you find that am in as your advertised default gateway, you just say okay, that's cool, let's not ARP this. Will but let's have a quick sneak peak at the v6 neighbour cache, RFC 4861 default router list of 4191 preference. And just use the MAC address that's in there and don't send any ARP. And any host that doesn't know about this cool magical trick basically just send the ARP address and that works and the router can probably answer just with no MAC address. This trick that the unmodified host is something that already works universally. The I mean every single box I have tested does this. You can have an off link gateway, a gateway address that is completely unrelated to the sub‑net that you are in and the host will ARP for it and it will work.
Run both of these things on the same segment. So none of the intermediate layer, your DHCPv4 client server relay application needs to change. You can configure this statistically, and it works.
So, what does that look like? So, I have got host A, and it has an IPv4 address, a /32, because no sub‑net. And it's got a v6 address. It wants to send a packet to host B, which also has a v4 address. And for host A to go to the first hop, it does, it says okay, I have 1920011 ‑‑ 2.11, Erik, sorry, as my gateway, so I will just pull the MAC address from the v6 network cache, I don't need to send an ARP. Then the router, which is v6 only, receives that packet and I mean since it only has a v6 address configured, but it still understands v4 packet format just fine because that code is in there, and it does have a nice next hop because that's in the whole v4 via v6. So router 1 knows if you want to go there, that packet wants to go, that's router 2, that's over there, and so it basically, think of it as almost failing forward of a packet, where it then goes okay, so the next hop is FE 80, router 2. And then router 2 receives it, oh that's that v4 address, that's local and just drops it at the end. You can do that in multiple ways. Particular either have like ‑‑ you can do something as stupid as a stick ARP table net router, you can also say do you know what, I just use the v6 address of the next host as a hop. Which on the packet level does the same thing. So again no neighbour ‑‑ you get neighbour discovery and no ARP.
Now, this seems like a very poor trick and awfully chunky and hackey. But what you actually gain when you lose ARP? Well,ing a couple offing this things happen because all of a sudden, if you have v4 only delivered across a v6 next hop, your v4 can actually do active multiple gateways on a segment so without actually needing first hop resilience without faking virtual ARP for router gateways, you can do inbound ECMP all the way to the last hop. You can do outbound ECMP from the first hop if you really want. You can do per host migration, because there is no sub‑net to move, there is no considering of where this should go because it's a /32, it's its own thing you just point the routing table somewhere else. And in shared environments, share broadcast segments, the last two become very relevant. No ARP spoofing. Nobody can fake your Mac ‑‑ nobody can fake your IP address anymore on a network and cause things to break, and I mean I have run an interim job as a CTO of a hosting provider. Let me tell you, these things happen quite a bit still, and you can tell the people that they are naughty but you'd rather just go on with your day. Also, no broadcasts, no broadcaster is good, we like no broadcast.
Now, why am I standing of all places in the v6 Working Group going on and on and on about v4 an and ARP? Because this is a transition story. Because implementing this has a single direction of travel, because any segment deployed in this way will never need v4 infrastructure again. You know the goal that we are here for, I mean just not having to build dual‑stack and, you know, the dream.
Hosts can stay dual‑stack, we don't care about hosts we don't need to configure them. There is no translation or state or middleboxes that we need to figure out and do something with. And v4 on the endpoint stays in the exact same shape that applications expect. Your code from 1984 will understand this.
Fits with all the current v6 work. Option 108 Jen already mentioned, this is the sort of v4 fallback that makes IPv6‑mostly deployable without infrastructure. You have the 6 mops that fills the native v4 to dual‑stack hosts on its IPv6‑only segment case in there. CLAT, it's complementary. You can short of have both of them at the same time. And 8950, which is the v4 across v6 routing, this closes the host side first hop gap.
This was brought up in the IPv6 Working Group list in July after I published a RIPE Labs article about this, there were some concerns about this. Neighbour discovery operational health prerequisites. It's amazing how universally disliked IPv6 neighbour discovery is within people who like IPv6.
Multi‑router segments, 4191, the ARP level fallback as a may in the text as a degradation path.
Any large broadcast domain, data centre fabric campuses: FTTH, POP, whatever,
.
Containers and kubernetes are actually interesting, because anyone who has ever did a dive in the networking of kubermetes, you'll find a lot of NAT and ugliness. Imagine just being able to say oh, this endpoint, us just go there, it's fine and no state gets involved.
So no S NAT, no D NAT, no contract, no IPv6 overlay,, and given it's 2026, AI.
GPU clusters incredibly. I mean I had to look at the video documentation for running large GPU clusters, that's done on IPv4. Oh my God! And they are recommending, they have an addressing plan with RFC 1918 space, and if you have 100,000 CPUs which is apparently now sort of a I think this, you actually run out of RFC 1918 space building those clusters. So, you know, having v4 endpoints that you don't have to do aggregation and sub‑netting for is a great help because then 16 million addresses in ten /8 actually becomes 16 million endpoints.
There is running code. On the host side, I build a, python, thing. There is actually a full system network D patch that runs, works completely. FreeBSD. I even built implementations for macOS and windows, incredibly, yes. MacOS and Windows don't support RFC 8950 so you have to do some ARP trickery. The router side: There is example configs for a bunch of OSes. There is a GitHub.
Where we are right now. The draft got a adopted by IETF this summer. Tobias joined the co‑author Working Group. I am very much looking to hear from operators what they think and people who are willing to pilot this.
And that is me. And I have a minute and 40 seconds left.
(Applause)
.
WOLFGANG TREMMEL: We do have enough time for questions. Please.
AUDIENCE SPEAKER: Thomas. We are a residential provider, and we are dealing with an issue that is so like dangerously close to this but we fixed it basically with, we used an off link IPv6 address to make sure that the machines are forced to use the router advertisement for default IPv4. So, I am very happy to see that something is being drafted because this would actually make ‑‑ we could actually use DHCPv4 with this and right now since we have automation on everything, we can basically hammer the way we want everything to work.
REMCO VAN MOOK: That's exactly the idea. So basically all of the tooling just ‑‑ I mean doesn't need to understand this, most of the tooling can be completely oblivious to what this means, and the end hosts either get it or don't but the net result is the same.
AUDIENCE SPEAKER: This is important because we also operate a TV platform which has very high speed requirements and performance. So it's impossible to use translation mechanisms on things like this. So thank you very much for actually doing this.
REMCO VAN MOOK: That's much appreciated. Thank you.
WOLFGANG TREMMEL: Okay. Any more questions? No? Anything online? Okay, thank you Remco. The
.
(Applause)
.
And that basically concludes the IPv6 Working Group. Oh, one more thing. Yes?
AUDIENCE SPEAKER: Can I have an AOB here.
ONDREJ CALETKA: I would, because we were talking about this Windows doing v6 only on our meeting network, also Linux has now network manager 158 which supports it. I would wonder if we can use this last five minutes after we close this meeting, if you have a machine with this, can you come somewhere here and let us, or at least me see, because I am curious, thank you very much.
WOLFGANG TREMMEL: Okay. Please rate the talks. Also be reminded that there are two the elections, there is the PC election still going on, so vote if you haven't done so and also be reminded that if you are a RIPE NCC member, the voting from the General Meeting is tomorrow till nine o'clock. And with that, I thank you. And I'll let you do the testing and go to the coffee break. See you next time.
(Coffee break)