RIPE 88
IPv6 Working Group
23 May 2024
11:00 a.m.
RAYMOND JETTEN: Good morning everyone. Welcome to the IPv6 Working Group. I hope you had a nice evening last night and you still remember that you are in the IPv6 Working Group room. If you want to go to the other session, get out and go to the other one. Don't come back!!
The RIPE 87 minutes. They have been on TTL website for ages and our mailing list is rather quiet and I haven't seen any ‑‑ not any comments on them. So, this is your very, very, very last chance. Is there anything you want to have changed in them? Don't all come together at the same time. No? All right, the minutes of the RIPE 87 IPv6 Working Group session have been approved.
Now, there comes possibilities you can come to the microphone in this session, and you can ask questions. Before you can do that, however, you state your name and your affiliation, if you have one. And of course we have a COC. I'd really like you to handle that because it's a must.
So, with that, I'll open the session. As, you know, Jan has been around for a while, and actually since RIPE 69, she's been a proud and very, very loved Working Group co‑chair. But now Jan has decided that I have now seen this stuff and well ‑‑ we're almost done, exactly. We would like to thank you for your outstanding work you have been doing for all this time.
(Applause)
We are going to miss you, but like you said this morning, you are not leaving the IPv6 Working Group you are just stepping down as a Chair. You will always be here happily presented with impossible presentations and you never know what.
So, Jan, I know you like bubbles.
TORE ANDERSON: Some chocolate.
JEN LINKOVA: That's why you need to volunteer for being a Chair, you see, there are benefits when you leave it.
RAYMOND JETTEN: Thank you so much Jen.
Now, Jen is stepping down. And I hope we have online our new colleague, Nico, are you there?
NICO SCHOTTELIUS: Hi.
RAYMOND JETTEN: You are still on TTL trial period, you know that!
RAYMOND JETTEN: So, you could actually talk shortly a bit about why on earth would you want to come as our colleagues here.
PRATYASH DIKSHIT: It was a fluke of an idea. I have to say many many many thanks to Jen who has been there for so long and I appreciate all the work. It's big foot steps to step into.
So, why I would want to join this? I have been IPv6 enthusiast for many many many years. I had a short break between 2012 to 2017 or so, but since then, running a lot of IPv6‑only networks, and I actually enjoy being in the RIPE community and being with the IPv6 folks a lot and also challenging the status quo everyday, and I hope, together, I can have a help moving forward the IPv6 adoption and discussion. So I'm really, really happy to join, and really happy to join this crazy ride of IPv6 moving forward.
RAYMOND JETTEN: Thank you.
So, you'll be somewhere here virtually with us. Unfortunately you couldn't be here today, but we'll hope to see you sometime in the future. Our first presentation. No one else than Jen herself about operational issues ‑‑ oh, nothing about that.
JEN LINKOVA: Hello. Congratulations you are not going to have Chair slides and comments any more. But, okay, so, first of all, who watched my presentation at the last RIPE meeting about migrating v6 only? Okay, you might find this kind of boring, or maybe useful, I don't know, but just it will be some duplication of the information here, because I am an old lady, I hated stuff when I tried to find something in the Internet and I could not find any text about anything. It's only YouTube videos. I am trying to find out how to change a battery in my like devices and it's YouTube videos, so there is no clear text instructions.
So, I presented IPv6‑only journey a few times, and at the end of all those trips, I realised that we never wrote down anything about it; it's only videos and PowerPoint. Well PDFs. And apparently I'm not the only one thinking that. So I got a bit of feedback from people about, can you please write this down. So, as a result, I am standing here repeating some of the things I said in Rome because whoever can own the document that I shared with the IPv6 group, where I'm always trying to summarise how we deployed IPv6 mostly network in the enterprise. Not only the enterprise because I got a lot of feedback from people who actually doing the same things in conference like, if you connected to RIPE network here, you probably most likely connected to v6 mostly network as well, right.
So, this document is trying to summarise current operational experience and recommendations. So, what is v6 mostly? How you do it, and why and what you shall expect.
So, let me guide you through the document because I am actually looking for feedback.
So, first of all to different what it is because we came up with that term, v6 mostly. I remember how it happened when we were writing RFC about v6 only preferred to DHCP option. We started talking about how do we call the situation when you give v4 only devices which need it? Like IPv4 is a service apparently term was taken and then like yeah, you actually get a network which is not v6 only, because there are dual stack devices or even v4 only devices.
And you have v6 only devices as well, and you want them to be the vast majority. So, yeah, it's basically v6 mostly network. A network where you own the same network segment you let the devices co‑exist. Some are v6 only and some legacy thinks I still get v4. The problem with writing documents like that, is that I'm trying to make then generally useful but still covering most of the use cases, but then you start talking about specific and people keep coming up with counterexamples. For example, we say that v6 mostly networks usually have NAT64. Some people might say, oh no, I have some special internal network which does not need NAT64 because they never talk to the Internet. Fine, we still call it v6 mostly, but for general like every deployment, I would expect people to have NAT64 for a while right, in the network.
So, again, v6 mostly network, how do we build it? What's the building elements? You take your normal dual stack network. You add NAT64. Then you add some mechanism for devices to become v6 only if they could be v6 only. Normally, again it's option 108 in DHCP 4. And you add the DNS64, I'll talk about it later, because DNS64 is a horrible thing. Every DNS person in this room probably would agree with me. So, it's a necessary evil, and I will have some discussion later about for how long we think it's going to be necessary. And as a result, you get a network which is now not just a dual stack but v6 mostly.
So, we're talking about, not about hosts but endpoints, why? Because traditionally when you talk about enterprise network or conference wi‑fi, we say we have a network infrastructure, routers, switches, firewalls, access points, and then you have hosts. As soon as you start v4, you find out that those devices are not actually hosts because hosts are not supposed to route traffic. Most ‑‑ how many people with Chrome books here? It's not the host, it's a router. You have mobile phone, it's actually not a host, it's a router, right, but if you start talking about in documents like that about routers meaning endpoint, like laptops, people got very much confused. So we started using term endpoint which means something you kind of perceive as a host, but it can perform routing functions as well for some physical or virtual devices behind it. So the fundamental thing is that you want some devices to be IPv6‑only. We call those devices v6 only capable. Yeah, we got to play some game of definition for a while because we need to establish some terminology. But I would really like people not to focus too much on it because whatever definition you give someone will come with a counter example. I think it's kind of clear on the subconscious level what you are talking about. You have some devices which somehow can operate without v4.
Normally, traditionally, and in most of the cases it's device with 464xlat enabled which can take care of all legacy applications running on it because it let's them believe this they have v4, however in some cases, you can have v6 only device without it. For example I have a Linux laptop which works just fine without 464xlat because the only thing I do on that laptop is run nigh browser in SSH and both things work fine. I actually call it v6 only capable without 464xlat so there are always exceptions.
Now, how you make devices v6 only. Again they recommend the traditional way of doing this so to enable option 108, support on endpoints. So what's happened your client when it sends DHCP discover, or DHCP request in v4, it will include in parameter request list a request for option 108. And DHCP server will see they say great you are v6 only capable, go away for X second. Don't come back, you don't need v4. So the device will say great, I'll shut up. And it will become v6 only. However, again, let's talk about corner cases. In some cases you might want to make some devices v6 only and they do not have the option 108 support. In my case, for example, it was some special embedded systems which we know would work on v6 only because they only talk to limited number of destinations. Those destinations have v6 enabled. But obviously they do not want to add option 108 because it's too much work. Those devices have limited stack and it was hard for them to get neighbour discovery done. And I do not want to have additional complexity. So, what you can do and what I'm actually doing doing for example is just apply port ACLs on switch port which is local IPv4 on them. It could be either a static port if those devices don't move or you can use radios, filter ID attribute if you use .1X to authenticate them. You can make devices v6 only without adding option 108 support. It's has escapability implications. It's not nice, but it could be your stop‑gap solution for some corner cases. But again in most of the cases when we talk about v6, mostly we assume that devices support option 108 and just signal that they do not need IPv4.
So, obviously, very important element for almost every v6 mostly network is how your users go to reach Twitter. How they are going to get to v4 only destinations.
So, there is not much to say there, right. NAT64 is basically the same thing as NAT 44. Most of those networks would have something which can do NAT64 unless they are they have been using public IPv4 space which is unlikely so the only thing we want to see in the document currently, the only corner case interesting thing I am aware of is that NAT64 translators must not translate traffic if a well‑known prefix 64:ff9b is used to reach private IPv4 address space. So if we only doing NAT64 to reach Internet destinations you can use well known prefix. If you want to use NAT64 to give access to some private v4 only destinations, don't forget that implementations are not supposed to do translations for that IP kind of package so please pick up /96 from your network and do network specific prefix. It is kind of hidden inside RFCs so I think it's worth pointing out. Would I not be surprised if some NAT64 implementations ignore that requirements but better be safe than sorry.
So, obviously another solution element to make sure your v4 only applications like Spotify work on v6 only is corresponding translation of endpoints, CLAT, which basically present your applications with IPv4 dress and gateway. So your applications are tricked into believing that, in traditional dual stack network, good to go.
So, again, rule of thumb: If you don't want to think about all corner cases, you should only have devices which send option 108 if they have CLAT enabled. However, again, as I say, in some cases you might say no. For example, Linux, there is an CLAT implementations for CLAT but you wouldn't find them normally as a part of normal installation base. You do some work to your system. So, for example, you might want to have IPv6‑only capable endpoints like Linux which would be sent in option 108 if you enable it, but they might not have CLAT. It's up to you, but again normal default recommendationings just combine option 108 and CLAT.
So, to do CLAT, endpoints, or actually to do local since sis for example, like Apple does, application systems need to know what NAT64 prefix is used because as I say, you might not want to use 64:ff9b, you might want to use your own network specific prefix. I'm obviously biased here but I think the best way to do this is to send pref 64 in router advertisement. Because, first of all, it's much faster. Another option is use DNS when your host only IPv4 arpa, but if you have an NRA you get everything in one packet so as soon as your host gets IPv6 configuration, I mean default gateway, DNS, prefix, it also gets pref 64, so CLAT can start right away without additional 1 RTT delay to get your DNS resolution done. Obviously it's much more secure. We all have RA Guard enabled on the network. If you don't have it RA Guard enabled, you are in such deep trouble, so discovered NAT64 prefix is not your biggest problem. So an attacker could not at least spend you spoof DNS response and trick you using the prefix which doesn't work in your network.
And also, by the way, I know that a lot of enterprises like doing this. Your device might have custom DNS servers configured. It might not use DNS servers provided by the network, it might be custom configuration either as a the PA of enterprise policy or because users just configured something like 8888. Or application might use application specific resolvers. So in all those cases, if application does not do exactly the right thing, you might have a problem because your NAT64 provided by the network is not used so you cannot find prefix using DNS resolution. So, pref 64 is basically much more reliable in a faster way and because most vendors, routing vendors currently support this in reasonably new stuff, there is no reason not to use it.
My favourite topic. I actually can talk a lot about this.
So, DNS versus DNS64. So, why we need the DNS64. First of all, because pref 64 wasn't available. We published pref 64 RFC like four years and it took a few years for vendors like Juniper and Cisco to add support for this. OpenSource also, a lot of implementation support it now, but that time when we started doing v6 only, systems can only discover pref 64 using RFC 77050, so the result DNS64 CLAT would not start. Now we don't have that problem.
However, another case for DNS64 is if your system doesn't have CLAT, so it would just use DNS64 instead, but again, it's insecure, DNSSEC would not work obviously. As I say, it might not work if you use custom resolvers. Well, there is a document which updates 7050 which tells you if you are using custom resolverer, you must still do pref 64 discovery through network providers only, but I don't think many resolvers do that anyway. And also, funny thing we discovered, at least for a while, on Apple systems for example, if your application is not properly v6 aware and just trying to use v4, it will go through CLAT and it will work without DNS64. Okay, but if it's doing like bumping the stack stuff and trying to discover the prefix and do synthesis right the way, the recommended way, it will try to rely on DNS64, so if you turn off DNS64 and start using normal DNS, you have some chances of the whole system breaking.
So, I know that.Ondrej, within day RIPE NCC turned off this yesterday, so currently I would really love to hear if anyone experienced any problem accessing v4‑only destinations in the Internet. I'm glad to hear. I know it's supposed to be fixed, but I guess it might be a long‑tail devices. So please let us know if you see anything, because we are trying to do that experiment. I unfortunately very much afraid of doing this in my network because we rolled out DNS64 everywhere a while ago and now like changing is scary. But I think for future pilots, if you are thinking about doing this, I would recommend trying to do it without DNS64 and see, because you might be able to do this. It might depend on your client base, how much you control endpoints and how much you can ensure that they are reasonably up to date. But I think the more we go in into the future, the easier it would be to get rid of this useful, necessary, but still nice hack called DNS64.
Let's find it out. I am really looking forward to the feedback.
Also in this document I probably should have started, the document outlines some solutions why would any sane person do all this stuff?
.
Well, normally because you need IPv4, right. Dual stack doesn't help you with saving Q4 address space. It simplified operations. I hate dual stack. First, like support people have hard time dealing with Happy Eyeballs, sometimes use v4, sometimes use v6, you flip between them. Nightmare. Also by the way, it reduces your dependency on DHCP 4. Why not do just v6 only and maybe provide some feedback. I presented it a few years ago. It kind of works but not very well, because if you have let's say two wi‑fi networks, v6 only and dual stack, your users are going to get confused very much. They will be connecting to the wrong one, so we know that currently if you enable option one way between 70 and 80% of devices becomes v6 only. And like, the vast majority of them just works fine. If you just give them v6 only SSID and dual stack SSID, a lot of them will be sitting on dual stack SSID just because they don't care, which means you are not saving IPv4 address space and you wouldn't know about any problems because people wouldn't report them. Again it's much easier to do incremental migration and you have less escapability issues. Especially if you are not talking about wi‑fi but about multiple VLANs in the network.
So, some recommendations how to do this. To minimise number of angry e‑mails you are going to receive.
First of all, most of implementations do an option 108, such as app em devices an Android devices send them currently unconditionally. In Mac IOS I can you send the file on the DHCP client but for example if you have enterprise protection you wouldn't be anal to do this. So you can consider Apple and Android devices just sending option 108 all the time. As soon as you enable option 108 on your infrastructure for the given sub‑net you basically move all devices there.
Some devices like ChromeOS or Linux allows to you turn it on and off. So ChromeOS sports is but doesn't send it yet by default. Linux you can configure your DHCP client to do so. So for those devices you can do a slow incremental thing if you want.
Favourite topic of any network changes: Roll back: Fortunately Option 108 has an insight. It's number of second for your DHCP client shut up and don't ask for v4 again. Minimal default value is 300 second, which is five minutes. So I would strongly recommend start with that value, so if something goes wrong you just wait for five minutes and your clients will come back. And then as you get confidence and you see that everything works fine, you can just increase it to, I don't know, 12 hours a day, or whatever. So it will drastically decrease the load on your DHCP infrastructure.
Well, in some corner cases, which I'm going to talk about, you might still see ‑‑ we didn't see them but I know some other confidence networks experience that a very little, low number of clients which still need v4 even if they support option 108. So you might at least for initial phases consider having dedicated SSID for example, recommended to keep it hidden or at least password protected so people only can get the password if they tell you what was wrong. Because it's very important to know why people still need this.
My favourite topic. All current implementations for CLAT requires SLACK, even for example Apple device, like MacBook which supports the DHCP address assignment, will need another dedicated address for 464xlat assigned with a Slack. They want to detailed address so you can do stateless translation and do different shapes, because it may be native V traffic or that address should be neutral because developers do not want to deal with every single possible protocol and regulation.
So, you can use your favourite DHCP v6 for address assignment but you also need SLAAC currently if you want to do this for 464xlat.
Security policies:
Well, I would say normally security policy should be protocol agnostic, with obviously some additions about neighbour discovery and so on. But things people tend to forget is that you need to pretty some extension headers. For example, don't forget about fragments, fragmentation in prefix is a fragment extension header. If you ever use radios over IPv6, you might actually find very interesting corner cases when packets get way too big. You'll get a lot of fun if you try to do it with access points for example. And also, by the way, I don't think I put it here in the document but I definitely should, I need a GitHub PR ‑‑ maybe I have a slide ‑‑ if you use ICMP load balancing for Anycast inside the network, as soon as packets get it fragmented you have a pretty good chance of sending different fragments to different Anycast destinations so don't forget to enable load balancing using flow labels in IPv6, because that would at least guarantee you to get all your fragmented radio packets to the same radio server which makes users much more happy, believe me.
ISP heard in IPv6, is not encapsulated. There is no NAT traversal because there is no NAT. You may need to specifically put ISP which is used for VPNs and wi‑fi calling. If you want your phones to use wi‑fi calling you need to let saps now.
The most interesting section of the document obviously is examine kind of problems you are going to expect.
Clarification, we are not talking about implementation bugs because bugs get fixed here here today, they are not going to be here tomorrow, you will get new bugs. We are talking about issues which you can expect no matter what you are using. First of all, I am absolutely sure you'll find out some issues in the network. Because for example, if your network works 99.9% all the time you suddenly discover that 0.1% of v6 broken. This is not acceptable any more.
You will probably find that users disabled IPv6 in some of their laptops. So they will be like why can't I connect to wi‑fi any more? Because your support team told you to disable v6 five years ago and you still keep it disabled.
So please don't do this if you have controlled environment, do auth for those devices and fix them.
Network extensions. Yes, what you think is a host is actually not a host by router, Chrome books have like five or six or seven named spaces inside and use end proxy for them so you are going so see scaleability issues for them because you see 20 addresses for device. If your wi‑fi infrastructure switches want to have only seven addresses per device you will see very interesting scenario when addresses stops working randomly and so on.
Again, I already mentioned DNS config on endpoints. If your device is using custom DNS it will be a problem if you do not give them pref 64 in a router advertise: Fragmentation, already mentioned. Make sure you have sufficient MTU on v6 only site because that packet is always bigger than v4, 20 bytes longer and check that your NAT64 devices are properly configured because most of them do not use interface MTU for translated packets. They always use 1280. It's normally configuration option which needs to be explicitly enabled and mainly implementations.
This is a good one. If you do traceroute for example, people on MacBooks might want to one traceroute 888 and and tell me what you see. Most likely you do not see much. Understandable for v6 only part of the network because how can v4 traceroute represent v6 addresses? Android, for example, using reserved address space NTT L just to emulate some hops, we currently have a draft to have additional ICMP extensions to include that into packets. So your implementations can know what was the actually addresses. Because the translates all source addresses they are not translatable. So we tried to present them to applications using ICMP extensions.
Next step: If you deployed v6 mostly network come and talk to me about what I missed. Please read the document.
And yeah, I am really looking for feedback and different experience because obviously my experience is limited.
And particularly, as I said, I'd like to hear about deploying that stuff without DNS64, let's get rid of it. And eventually publish so people who have not done it yet have some guidance on how to do this.
And questions, comments?
(Applause)
RAYMOND JETTEN: So, we have someone on the queue as well.
JEN LINKOVA: That's why, guys, it's strongly recommended you should, capital letter, use client to join the queue even if you are in the room. This makes Ray's life much, much easier, believe me, not my problem any more, but...
JORDI PALET: Hi. I don't really agree with, if I understood correctly, your recommendation to not use DNS64.
JEN LINKOVA: No, my recommendation would be currently you might still need to use it, but we shall gain some operational experience and see how many legacy systems we have which relied on it, because it's unclear now and ideally we should look for getting rid of it. I'm saying I don't know if it's possible, I don't have that experience, but I'm looking forward hearing from people.
JORDI PALET: Okay. So let me tell you my experience with that. Obviously if you disable DNS64 and you have CLAT, when reaching IPv4 only destinations, you will be doing two translations, the CLAT and the PLAT. This is not a big problem in general, but introduce one extra delay because the CLAT translation, okay. Now, that means also some extra power because any translation means some extra power. My experience actually is that because the very low level of the deployment and usage of DNSSEC in general, they increase deployment of IPv6 in content providers, the ability to enable for example, in BIND don't break DNSSEC, and some hosts are already doing AAAA synthesis. This is not, in general, a problem. In fact, I never found customers in deployments, and I'm talking about deployments even of millions of sub‑subscribers, finding problems with breaking DNSSEC. So, maybe our target more than disabling DNSSEC ‑‑ sorry, DNS64 at this time, should be promoting among vendors of operating systems, that they implement AAAA synthesis, because that resolves the problem, right.
JEN LINKOVA: Yes. Actually, what I'm saying is all modern operating systems will do exactly that and only legacy applications will go through CLAT, but they probably need to suffer at this stage. I'm not sure it's actually a bad thing. It's a questionable ‑‑ it's most probably controversial part of the document but thank you for feedback. Can you send it on the list actually? Thank you.
JORDI PALET: Yeah, I will do.
AUDIENCE SPEAKER: Andrei from the RIPE NCC, RIPE meeting tech team. So, we run this experiment this morning where we disabled DNS64 on the v6 mostly network, the idea behind it is that nothing should break because either the device is running dual stack, and therefore it has native v4 and no need for DNS64, or it's running v6 only. And in that case, all the devices known to us that are supporting DHCP option 108 should support pref 64 option to discover the prefix. There might be some less efficiency regarding what Jordi just said. I would just say that contrary to our expectations we got some people noticing it, for instance we also say to Linux users hey if you want to experience v6 only network just turn off v4 manually on your laptop and you will use v6 only because that's basically how the IPv6 mostly network works. But this didn't really fly because, yeah, of course, then you are reliant on DNS64, also the CLAT utility for Linux doesn't support pref 64. So, we got some issue, but on the other hand, to be honest, all these issues are only from people that actually actively changed the default configuration of their devices. So, I really like I am personally interested in fixes these issues also in Linux and in other places, I am very happy that because I already shared something on Tuesday, that I am very happy that the IPv6 mostly network really works well for us during this meeting, because like more than 80% of connected devices are not using any v4 addresses, therefore we could have sled down the IPv4 pool capacity. So for that I'm very happiey.
JEN LINKOVA: Thank you very much. Because get CLAT done for Linux?
AUDIENCE SPEAKER: I am already doing it. I had given a talk, there is also a project sponsored by NLnet foundation to put SI ID translation into Linux kernel, so things are happening. ‑‑
JEN LINKOVA: Thank you very much. We need to talk more.
AUDIENCE SPEAKER: Hi. We deployed an IPv6 mostly network at APNIC conference in February and we used some enterprise access point, and it's too smart actually. And those access points assured the client has DHCP and IPv4 address, and that those client does not require IPv4, the access point automatically kick out the association, like every ten minutes.
JEN LINKOVA: Cisco was supposed to fix that a while ago, right? I remember ‑‑
AUDIENCE SPEAKER: You need to be careful when you are configuring such an access point. That's my comment.
JEN LINKOVA: Thank you very much. That's a very good point. We need to put that in the document. Thank you. You know where to find me. You can also send comments on the list or just find me and talk to me. Thank you very much.
(Applause)
RAYMOND JETTEN: So, next up is Tobias.
TOBIAS FIEBIG: Welcome everybody. I think by now you know who I am. I do stupid things with packets, Linux and routers and other things. In my day job as a searcher at the Max Planck Institute for Informatics and today here here to talk about IPv4. Which of course belongs to the IPv6 Working Group.
Point being you need to stop doing IPv4 driven addressing plans. IPv4 has been around for 40 years, it still doesn't have a solution for making clean addressing plans. I mean it's a total mess. I always wonder why CIDR, even if it makes me IP. I want to work on Layer3, well go to Layer2 first. And yes, please give me 50 different prefixs in a single Meta. What is that insanity?
.
However, as we already learned and heard during the Opening Plenary, if we embrace a lot and saviour our 8950 we can get rid of this.
A quick refresher. ARP, address resolution protocol, figure out which MAC address to spend packets for an IPv4 address to. Construct ethernet frame with fitting destination Mac. NDP, figure out which MAC address to send packets for an IPv6 address to. Construct ethernet frame with fitting destination Mac.
And you might have noticed that pretty much looks the same. Which brings us to RFC 5549 and 8950, which basically RFC 5549, in 2009, was what if we just put an IPv6 address into that night next hop field of an IPv4 prefix in BGP?
Well, what does happen is, it works. And in addition, there is currently a draft in the IETF ongoing, which is like how do we actually handle that if we do have an IPv4 route with an IPv6 next stop? Essentially being like ask for the MAC address, you'd have to send packets for the IPv6 next hop to. And just send the IPv4 packet there.
And I'm actually looking forward to this draft making it into an RFC. It's actually not pushed by me but by a couple of very awesome people making this work more in practice.
So, how does it look in terms of vendors? Generally, having a BGP address family with what BGP via v6 neighbour with v6 next hops, and exchanging v4 routes works in Junos, Arista, Cisco, extra BGP, FRR, according to some documents, it works in FRR and it works in BIRD. And actually sending packets in terms of like, you know, when it got imported into the FIB, it works on June us, Arista, Cisco, Linux, with net link and quite recently also in FreeBSD. This is not like a thing that doesn't work in a lot of systems. It actually does work.
And then we can look at how you can do addressing with this. And what we have here is a relatively simple example network. We do have three gateways. We are announcing almost favourite documentation prefix, the whole /32. We have 2 virtualisation servers. We are using numbered BGP between the gateways. We can announce the global Anycast address or prefix we assigned to the virtual machine in iBGP or any one of our choice, I think iBGP is the coolest you can get, and then we somehow have to just get the assigned prefix on the virt01 host to the link local address and everything works. And we do have a nice and clean IPv6 addressing plan. Nibble boundaries and everything.
If we now want to have IPv4, we don't really have to do that much. So, if we have our eBGP sessions via IPv6, we just start announcing the extended next hop capability. We send also the v4 route with ourselves as the v6 next hop. We do give our virtual machine a /32 from that /24. We set a static default route to 80 and then we just have to like somehow tell all the other hosts how to get to that v4 place. And we can do that, for example, by statistically injecting into our eBGP a /32 route with the GUA of the virtual machine as the next hop. And that has really, really nice because it means that the v4 address will always follow the v6 GUA, which always mean that you can have a centralised global IPAM and you just do your v6 IPAM as you you would and the addresses will follow. Meaning only one place to really care about mapping prefixes to addresses.
Which always means that if you just migrate this virtual machine as long as you take care of making the IPv6 GW prefix. You don't have to worry about v4, v4 will come along as any other deprecated protocol should, following the future.
The rest remains the same.
What this in summary gives us is that we have very, very fine‑grained routing of IPv4 in our network. So I currently have a test network going with this where I have like the first /32 in a 24 in Dusseldorf, the second one in Berlin, the next one in Dusseldorf again and then one other one in Amsterdam so I can very cleanly route very small v4 networks through my whole Internet setup. We can also handle IPv4 as a complete add‑on. So, imagine you are a large virtual machine hoster, Cloud I think it's called nowadays, and you want to offer your customers the opportunity to not pay for IPv4 because honestly, why should they pay for something they don't need? And then there are also those very special customers who do want to pay for that. Really with this you can easily give that as an add‑on while your overall setup has consistency for v6.
The whole addressing plan can be IPv6 centric, it can be clean, you don't need any IPv4 for transfer, router, network, broadcast, look back, eBGP route. Nothing. You just need IPv4 addresses at the terminus.
We have seen it follows around, which also gives you a lot of flexibility. And technically, there doesn't have to be a loop back IPv4 address on routers. Even though for PathMTU discovery it's often a bit nicer if you can actually send packet to big messages. Sadly somewhat needed.
It also means that you can have like legacy islands, imagine you have like a very specific 70206, of course nobody would still use it in production, right, with some really nice SunOS 6, 7, 8, 9, boxes behind that legacy setup. Well, as long as you can get a router in front of that that does v4 with v6 next hop and that stops itself towards the Cisco you can just get it connected through your v4 with v6 next hop backbone.
And of course, you can also always do this partially. So, as we saw in the Opening Plenary, it's mostly for internal transport, but you could technically also start with eBGP or any other part of your infrastructure.
There is currently also a working group at Euro‑IX which looks into RFC 8950 at the EIX which obviously has a the benefit that renumbering becomes very, very unlikely if you just have to use a /64. In general, IXP prefixes should kind of not be globally reachable anyway, kind of nice. And technically, you should also originate ICMP for IX interfaces from look back anyway because there is some ASes that are dropping anything that's not in the GR T, and if you do originate with your IX address, well ICMP won't make it there, which can have dire consequences if you have an NTU operating nearby.
And we don't have to care about too many members any more. How much time and energy did we put into that policy change to reduce the IX LAN default allocation size?
.
There is a couple of caveats about this. Traceroutes are less. If you only have ICMP sources from router loop backs or completely useless as we have seen in Jen's talk, because if you don't have an IPv4 loop back or don't have any IPv4 in the router you might end up with originations from like the default IPv4 address of last resource certificate.
Some client operating systems certainly are not that good with this. So OpenBSD, which is one of my favourite operating systems, is not that good with IPv4 to IPv6 next hops. You also need vendor support in your routing infrastructure. At the moment I think the biggest vendor that is maybe not so good with this is extreme. Of course, it obviously works best if you do have a clean IPv6 addressing policy. So if you are kind of slithering into this whole new v6 stuff, which has been, you know, new for the past 25 years, then it might be a bit more difficult to get this going cleanly. And of course, you still need working documentation meaning you still need a working IPv6 IPAM, otherwise this will hurt.
So, what do we need to have a lot more fun with this? Better vendor support. So, currently ‑‑ well this has to be updated a bit ‑‑ this injection I showed you, so injecting a she can route with an IPv6 next hop works currently with BIRD and apparently with XWP, thanks to Ruben for testing that just before this talk. This would be kind of nice to have something like DHCP 4 via global IPv4 Unicast, then you can get v4 from one central location in your network only if and when you need it.
It would be cool if you could announce that somehow with some form of router advertisement option, because then you can tell your clients like yeah, if you really need it. Talk to that Unicast server.
There is of course the option to make interface identification and traceroutes better. There could be something like RFC 4950 for v4 with v6 next hop. Some form of RFC 50837 plus plus, what Jen just presented, goes roughly into the same direction.
We need some way to end more in general fix PathMTU discovery. But it might also be easier to just find a way nor nice time travel. And finally, a really nice goal would be an IPv4 free Internet core. Like not only one AS but everything.
I'm allowed to dream.
So, doing this on transport and eBGP for me. So in my own AS, so 59645, I killed IPv4 on all transfer links except for that one OpenBSD router. This works well for a year. I'm using Junos and describe os, which is essentially FRR in Linux. The whole thing uses some form of private ASN based eBGP under lay for loop back and link local distribution. Also works with stupid things like that. And I also set‑up a little test setup which is AS215250 which takes us to the extreme. So there I do not have any v4 on anything, just like in the example I showed, including eBGP. Currently, there is 5 eBGP sessions without IPv4, plus some additional testing things. There is two times upstream from AS21146 to this up. There is peering sessions because I need to harvest a higher local pref. And then there is of course the BGP tools route clever, which worked out of the box, so big big kudos to Ben, because it worked out of the box.
In addition, this VL less AS thing is, as I said, a dedicated test setup. Where I also implemented a couple of testing scenarios, so, there are pathways MTU break and without an MTU break. So one time there is an MTU of 1,400 on the way, and there was are also split in like having actual IPv4 Unicast, ICMP sources on path and not. And I have to be done of also announcing with this AS invalid prefixes. So you can test your filters. And testing is actually a good point. On the whole thing of this AS is that I'm currently bringing it to several IXPs, and there goes also a big thank you to the responders was this... and if you are in any of those IXs and you want to test this there is a pre‑configured passive session, waiting for you, you just have to configure a session on your side, and you can actually try RFC 8950 on eBGP in practice and then use an LN ring nodes and RIPE Atlas probes to see how your network behaves and see how it looks from the inside and outside.
More details on the web. It's here.
And that should basically be it.
RAYMOND JETTEN: Thank you very much.
(Applause)
CHRISTIAN SEITZ: We have two questions online. One from Nico Braud‑Santoni: "You mentioned v4 forwarding to a v6 next hop works on Linux with net link. Could you clarify what you meant and specifically under what conditions this works?"
TOBIAS FIEBIG: I don't have the exact kernel version, but from like ‑‑ well at least with the Debian 12 or Ubuntu 2004, 2204, you can just tell your routing stack on Linux to just use a v6 next hop for a v4 route. It's IP address at ‑‑ IP route at default via dash INET6 FEAD and it sends packets.
CHRISTIAN SEITZ: Another question from Robert cheque: "RFC 9850 support, you didn't mention open BGPd. Didn't you have a look at open BGPd or doesn't it support this?"
TOBIAS FIEBIG: I think it's on the roadmap.
AUDIENCE SPEAKER: Maria: Just a note, thank you a lot for using documentary prefixes for every single place you have in your presentation. I honestly can't remember when I saw such a presentation with using strictly the documentation prefixes even for v4, I think it was like years ‑‑
TOBIAS FIEBIG: Thank you. I am currently teaching data networks and we have a lot of prefixes on the slides and the post dock who has to revise the slides really, really hates me. Take a guess why!
AUDIENCE SPEAKER: Jen Linkova. Thank you very much. Very cool. I just have one comment. You said that you get less capabilities of traceroutes for v4. If your routers do the right thing and send packets from the back‑end you only have one release between two neighbouring routers, you do not lose anything right. You might lose sop capabilities if you have multiple L 3 linking between two devices.
TOBIAS FIEBIG: Yeah, but you are over estimating the amount of v4 in especially the test setup. So, there is no v4 on loop back.
JEN LINKOVA: That's nice.
TOBIAS FIEBIG: As I said, it's nice.
AUDIENCE SPEAKER: Stefan, from AVM Germany. We're doing home equipment wi‑fi routers and stuff like that. Have you compared your approach to other existing protocols that somehow exist with this co‑existing of IPv4 and IPv6, let's say MAP‑T MAP‑E or something we just implemented that goes in the same direction that the provider would need an IPv4 backbone routing stuff any more, did you have a look at this?
TOBIAS FIEBIG: No, I didn't do any comparing, and keep in mind this is this is not a protocol, it's routing. There is no state, there is no translating, we're just forwarding packets and it's mostly something which is also not that relevant for client networks. So this is more really for getting it for example to virtual machines and things that provide services.
AUDIENCE SPEAKER: I'm asking because we have like five or six different modes now in our router that deal with does the provider provide full dual stack, does the provider provide something like DS‑Lite where you have like minor form, do we not have this and if so, how can ‑‑
TOBIAS FIEBIG: I didn't look at it access access access is the wrong side of the stack for me.
AUDIENCE SPEAKER: Okay. Thank you.
AUDIENCE SPEAKER: Hello. I am implementing this system since 2019, 2020. It's just a comment, so not ‑‑ users use it because it makes your network easier and I am happy because I'm working in the environment of v6 as a first class citizen and we are operating a Cloud and it makes the network very, very easy to manage and just tunnel or not tunnelling, just router IPv6, IPv4 addresses to the clients, makes it very, very easy, so use it. If you have greenfield deployment.
TOBIAS FIEBIG: With that, thank you, and if you are accidentally running and IX and would like please drop me an e‑mail, all I need is access to the peering LAN a little bit of backhaul and a virtual machine and your members can play with this. Thank you.
CHRISTIAN SEITZ: Thank you. The next speaker we have on a from the RIPE NCC and he is talking about IPv4 and IPv6 addresses.
ANDREJ CALETKA: So, it's sort of like a recurring thing at IPv6 Working Group we talk about IPv4. So, but I have IPv4 in the title, but I will be talking about IPv6 addresses and AAAA records and situations, where deploying AAAA records is actually not a good thing to do.
So, let's go ahead and start with the point. What is actually an IPv4 mapped address? Well, I should introduce myself. I work for the RIPE NCC. I am part of the RIPE meeting technical team, which is taking care of the network and everything you see here like the presentations and stuff like that, and we are trying as much as possible to remove IPv4 from our meeting network, also for the reason that the number of devices connected to the meeting network is growing every single meeting, and we have our IPv4 pool is limited. Even though it's quite generous, it's still limited and we would like to explore ways how to use it less and less.
But, back to the IPv4 mapped addresses. What are they? You probably already have seen them. Is there anybody who has never seen an address starting: Ffff and then an IPv4 address? There is one person in the room who hasn't seen it yet, two, okay.
Good. The IPv6 addresses like any other. The thing is it's completely valid to write IPv6 address in a way that the last 32 bits of the IPv6 address would be written exactly like an IPv4 address. So don't make yourself fooled by the fact that you see IPv4 address at the end. It's just completely an invalid way of writing prefix address and you could also write those numbers in hacks.
They are invented for one particular reason and that is IPv4 compatibility in IPv6 socket API. And I am already apologising in advance. It is really hard to pronounce right IPv4 and IPv6. So if I make is make by any chance, just shout at me and I will try to fix it.
Let's just quickly talk about socket API, because we are network engineers but I don't know how many of us have ever programmed anything that was actually speaking with network. So, I will do a quick crash course on how to programme IPv6 enabled application using BSD sockets API which is what every operating system is using basically.
So let's start with the case of IPv4 client application. If the application is IPv4 only, it's very simple. It starts with library function socket, which will grade the socket. Then connect will connect the socket to a particle IPv4 address. And once we have connected socket, we can send and receive data. It's easy.
What if we want top expand this up to support IPv6 as well? Well then we have to put something in front of it that will decide whether the address that we want to connect is IPv4, and in that case we go the same path that we went before. Or if it's v6 we go the slightly different path which only differs in that packet family or address family of the socket that we ask the operating system to create for us. The rest is basically the same. So on clients, there is no need for IPv4 mapped address and everything is basically quite straightforward and quite easy to adapt to support v6.
Let's look at the server. The legacy server has a little bit more calls. So you create a socket as well, but you have to BIND it to some particle address. And then you have to listen on that socket and once you do it, you will get a listening socket. And with everything single connection that comes to the listening socket, you will call and accept which will accept the connection and serve that particular connection. So, in IPv4 only case, it's pretty easy, it's this left part of this slide. But if you want to support IPv6, the problem here is you somehow have to support both IPv4 and IPv6 at the same time, so chances are you may spawn a different threat or process that will do exactly the same what you do for v4 but for v6. But if your application that you are trying to fix for support v6, doesn't support threats or you don't want threats or forked process or anything like that for some reason, then you have an issue. So for that you can fix this by do it, let's say, event driven. You can prepare a socket for listening on v4, then you can prepare a socket for listening on v6, after do you this you call a system called collect or poll which will basically you tell you which of the sockets are ready for accepting connection or receiving data and then you will serve every single connection. So it's possible to do. But you can see that the application flow now became much more complex. And the reason this complexity reason could be stopping us from adapting IPv4 only applications to support IPv6. By the way I am talking about situation 20 years in the past nowadays. And this is not a current issue that there will be apps not supporting v6, at least not in the majority of the thing.
So, because of this complexity that might be unnecessary, there is this thing called IPv4 compatibility of IPv6 sockets. So, IPv6 sockets might be able to receive the IPv4 traffic as well. So that means you can only deploy applications that will only open IPv6 socket and yet it will be able to communicate with both IPv4 and IPv6 Internet.
This will make your server applications simpler. So that's the reason why it was invented.
The thing the application is only opening IPv6 sockets regarding the API, and therefore it only sees IPv6 addresses. But as I said, the sockets supports also IPv4 operation. So, that is exactly the use case for IPv4 mapped IPv6 address. So, basically, from the socket you will always get IPv6 address, either it's real IPv6 address if it's IPv6 connection, or it's IPv4 mapped IPv6 address if the connection that the socket is creating is actually IPv4.
It's important to stress that there is no translation happening. The operating system is talking native IPv4. There is no IPv6 address existing anywhere. So no prefix packet existing anywhere that would contain IPv4 mapped IPv6 address inside. No such thing exists. This is not a translation. This is just the way because the API is only allowing you to send you 128 bit numbers so you have to somehow put the 32‑bit number into the 128 number field, and this is how you fill t this is the only way. There is no SSID translation how we know for instance from NAT64.
And in the end, this is not recommended. So, no new applications should be relying on this. It was mostly invented for as I said converting old applications to support v6 with as little effort as possible.
If you are writing a new application that is, you should write it in a way that supports two parallel sockets open at the same time and open one socket for IPv4 and one socket for IPv6, or possibly more of them if you want to listen on more ports or more addresses. So this is the proper solution. This is the only work around for an application that can only open one socket and work with one socket.
The problem with this approach is also that you cannot trust whether IPv6 stack is actually present in your computer, because there are still people who are turning IPv6 off even on operating system that does support it. You might have noticed that Microsoft, for instance, has this knowledge‑based article saying that if you turn off IPv6 support in Windows server, you will get it into unsupported configurations, and things will break because even if your server is operating v4 only, it still needs v6 inside to communicate between components of it.
And there is also this issue that because this has some security implications, OpenBSD deliberate decided no the to support this. So you cannot get IPv4 compatible IPv6 socket in OpenBSD.
Now the question: I said the socket may be compatible. The IPv6 socket may be compatible with IPv4. How this is determined? For that this is an option called IPv6 v6 only which is a socket option that every sensible application should set. It can have two states if it's set to zero that means the compatibility is enabled. This is the default settings for Linux or for macOS. It can be set to 1, which means compatibility is disabled that means IPv6 socket will only get IPv6 traffic and no IPv4. This is the default for Windows and various BSDs, and as I said on OpenBSD this is permanent and read only so you cannot turn this option off.
So, if you write a port table application it should always set this option one way or another, because otherwise you will get problems when you run your application developed on Linux on Windows or vice versa.
If the compatibility is enabled, you will always have ‑‑ it will block the similar IPv6 socket. If you listen on IPv6 socket port 80 for instance, and the compatibility is enabled, you cannot listen on v4 socket with the same port number.
So that was about how programming IPv6 sockets look like. But now let's get to the interesting part, and that our IPv4 mapped IPv6 addresses in the wild.
So just to recap:
IPv4 mapped IPv6 addresses just represent IPv4 addresses in the IPv6‑only socket. It's something that should never leave the host. It should never appear in any IPv6 packet anywhere.
So, it would be very silly to put it, for instance, into DNS.
Yet, people are doing it. And I would like to point out that this was not, this is not my discovery, this was discovered by Thomas Shafer who is sitting here in this room, and he actually started chat with a company behind this domain name to ask them why, why they put AAAA records containing IPv4 mapped address into the DNS together with their A record. That doesn't make any sense. And it actually breaks things. I would just come soon to the fact why it breaks things.
And I have to say that the answer in that public forum is hilarious. So I copied into that slide. And I will now read it.
"We did this to drive down the cost with our DNS provider. Queries for AAAA records that didn't exist, followed by queries for A records, was costing us significantly and we needed to alleviate that.
Our AAAA answers follow the standards, and our local dual stack testing has known no issues. The IPv4 address embedded in the IPv6 answers should be accurate, and should match the A record requests, and should all be routable in the IPv4 space."
.
Yeah... I see people in the room. That's what I had ‑‑ I read this as well.
So, basically, the point here is that this is some German company, and as you might know, that it's ‑‑ the deployment of IPv6 in Germany is getting better, let's say, and one side effect of it is that client operating systems like Windows or macOS, they have this feature, which I personally don't really like, and that is that they are not sending out AAAA queries if they don't see IPv6 connectivity; and once they start seeing it, they will start sending AAAA queries, so basically, before IPv6 was deployed in Germany, they didn't see the issue because clients were mostly querying for only A queries, but now then some ISP has DeLoid deployed IPv6 and this service provider who doesn't do any v6 saw an increase of AAAA queries that were not answered, and I'm not sure if this is really true but if somebody is charging per query and charging more for nonexistent query than for existing query, this is quite silly.
So, let's say now that we laughed at this answer, let's see ‑‑ this is silly or is it actually? Now I got this second thought and I said well, that's something that can be easily tested. So I set up an IPv6‑only website. I only have one, but this IPv6‑only website actually has AAAA record but it doesn't ‑‑ the AAAA record doesn't have v6 address it has v4 mapped v6 address.
This website should be unreachable because putting v4 mapped address into AAAA record is just stupid, and every single operating system or whatever should filter it, ignore it. Yet I can open in my browser.
So then I set up another test website which is actually dual stack, which means is has A record pointing to v4 address and it also has AAAA record pointing to IPv4 mapped IPv6 address somewhere else. So it provides different content. And guess what? My operating system is preferring the AAAA record with the IPv4 mapped address.
So this likes we have a problem. Of course the results can vary. For instance I haven't seen the problem on Android, so kudos to Android developers. I have seen different results on different operating systems, different browsers and different networks. So for instance, its brokenness is on macOS is v6 network but it works correctly on dual‑stack network.
But in any case, all hosts I test ready actually issuing both AAAA records and A records. So one cannot save money on providing v4 address in AAAA record and expecting them not to come back and ask for A records.
So there are some examples here on, where you see that on dual stack on macOS on the left you see it works well. On the right‑hand side you see on IPv6‑only network that you somehow can connect to this AAAA record containing IPv4 mapped address. So, it seems that there is some confusion where even if it comes from AAAA record as IPv6 address, somewhere in the stack of, you know, the, stack of the operating system, the operating system gets confused an once it sees IPv4 mapped IPv6 address it will convert it gracefully to IPv4 native address and communicate with it instead which should not happen. This is basically the reason why OpenBSD decided not to support this at all, because there is always this risk of confusion if you are using different types of addresses for different purposes.
The question is: Is this really a problem? Because, yeah, we have Happy Eyeballs and Happy Eyeballs are very successful in hide broken IPv6 connectivity, and this is just one of the many examples of broken IPv6 connectivity. Because the AAAA record just contains wrong information.
It might break DNS64 but that's a very easy fix and in the meeting when DNS64 is wrong, which will be after this session, there is a filtering set‑up that is not allowing anything else than global Unicast addresses in AAAA records, therefore these addresses will be filtered by dance resolver. But the fact that the computer itself is, let's say, vulnerable, I would not call this vulnerability, but some security people might, it's a little bit concerning.
So, my last slide and take away here is what can we do about this?
.
Well if you are a DNS64 operator, then you should definitely set a filter, set your DNS64 to ignore all AAAA record containing anything else than global Unicast address space because it doesn't make sense to have anything else in AAAA records.
If you are operating system vendor or browser vendor, maybe think about filtering like IPv4 mapped IPv6 addresses from the input from, let's say, from DNS or even from user, because it really has this only one purpose, and it shouldn't be used for anything else.
If you are a DNS hoster, then you probably should not charge people more for empty responses than for responses with data because then people start doing weird things.
And well, anyone volunteering to maybe bring this to IETF? Because there was this problem that actually Thomas was asking on the master done and it was that whether there is like an RFC that is clearly saying that you should not put an IPv4 mapped address into DNS because apparently nobody thought somebody would be silly to do it so nobody wrote it explicitly anyway.
And with that, this is my presentation. And I just have one more advertising slide, because we are learning and development in the RIPE NCC are running e‑learning course as academy [at] ripe [dot] net. If you want to learn something about IPv6 and you can give it a try.
(Applause)
RAYMOND JETTEN: Thank you very much, Ondrej, for your representation. We have some comments on the chat.
Marie
AUDIENCE SPEAKER: Maria:
MARIA MATEJKA: I just wanted to comment that you should have fair used fax to contain the German company. They will take it seriously.
ANDREJ CALETKA: That's actually good comment. Thank you very much.
RAYMOND JETTEN: Then from Nico Braud‑Santoni: "Could DNS providers authoritative or resolvers alleviate the problem by providing A records as auxiliary date on AAAA queries? Maybe only if no native IPv6 address is available?"
ANDREJ CALETKA: Perhaps. I guess so.
RAYMOND JETTEN: Then, Alexander: "Cost for missing AAAA might be caused because of less caching time. Anyway a solution should be to implement IPv6 service."
ANDREJ CALETKA: Of course, if somebody implements IPv6, that's, that's the best way to go how to solve this.
JEN LINKOVA: So, really interesting, thank you. Obviously it's not the only case of DNS, LinkLocal and other stuff, right. I totally agree we need to provide clear guidance. And by the way I think where it really should go, perfect timing, Happy Eyeballs 3 draft is currently being discussed, and it actually has a section about broken AAAA records, so I think it should go there. I guess you can send the PO or I can do it because I think the text is on GitHub, I think it's there. So we definitely need to document it.
TOBIAS FIEBIG: We recently got like a lot of DNS data, do you want to know how bad it is? Like, I don't know at the moment, I would have to ask a student to run the data. But do you want to know?
ANDREJ CALETKA: I think you can share it with the IPv6 Working Group or DNS Working Group wherever you find it appropriate if it's like about broken DNS.
TOBIAS FIEBIG: Somebody likes pain, I will ask them to do it.
AUDIENCE SPEAKER: I'm Alexis: So a few comments. One, the v6/v4 compatible is a very bad idea for another reason. V4 is not mentioned it. It can break layers in a very strange way, for example I ported my application that way, old application. And later in a very hard way I found that my restrictive ACLs doesn't work because I was expecting v4 kind of address and not v6 one, and my application was way more, let's say, not restrictive than it should be. Second question was actually related to previous comment. It would be very interesting to run some global survey on some big DNS registry databases and see how much kind of something we have in it.
ANDREJ CALETKA: Thank you very much. Actually you reminded me that just about the time when we were discussing this in the mailing list of IPv6 Working Group, there was also this incident report from GitHub, I am pretty sure. They started preparing for IPv6 rollout which we all expect for years already, and if there is somebody from Github, hey we are waiting, still here. Then they find this issue that IPv4 mapped IPv6 addresses started causing trouble for them, yes.
RAYMOND JETTEN: Before thing before you start. Guess what Ondrej? You have a volunteer.
ANDREJ CALETKA: For what?
RAYMOND JETTEN: For what you just asked for.
ANDREJ CALETKA: You mean deploying v6?
RAYMOND JETTEN: And it's Jordi.
BLAKE WILLIS: Thanks for this really good stuff. You will find that folks that may be running 6P E in their no, meaning IPv6 with a labled Unicast next hop which is would be v4 Unicast BGP sessions, at least? JunOS the router will synthesise one of these address with ffff: And the v4 loop back of BGP network the the next hop is a label but it needs something to resolve the next hop 2 that's what it uses. I don't think that the actual packet has a v6, you know, map, or a v4 map next hop on the wire, but you'll see it for sure.
ANDREJ CALETKA: Yeah. I think this is exactly the same case like if the host behaviour. I didn't consider routers but I feel this is the came case because you basically have 128 bit field and you have to fill it somehow with 32‑bit number.
AUDIENCE SPEAKER: Philip. Two things. So, I always consider this kind of addresses as oh it's actually a v4 address so I think the behaviour is quite consistent to what I would have expected. No matter that we don't ‑‑ we really should be putting this in AAAA records, the behaviour is what I would ever expected. So, did you try to use it to force a NAT64 ‑‑ sorry, a DNS64 IPv6‑only host to use the Cloud because this is what I would expect that should work? To take your macOS, take that kind of AAAA record and see whether you could avoid DNS64 synthesis, and instead go through the plot and whether that works.
ANDREJ CALETKA: I'm not sure whether I follow but feel tree to try.
TORE ANDERSON: Do it in the break.
RAYMOND JETTEN: The last one and then we'll close.
AUDIENCE SPEAKER: Tom Hill from BT. A quick question: Was the record DNSSEC signed?
ANDREJ CALETKA: Yes. Of course.
AUDIENCE SPEAKER: Of course. Are you aware of NSEC. So NSEC is designed to prove that something didn't really exist, which is quite interesting. It's also quite intensive to be able to reply ‑‑ make up on‑the‑fly replies. So not having a record if NSEC is enabled will cost you quite a lot of money potentially.
ANDREJ CALETKA: Okay...
RAYMOND JETTEN: We have to stop.
ANDREJ CALETKA: That's a good point so maybe the charging scheme of the Cloud DNS provider makes sense, but it doesn't make sense because then people just put wrong data into the DNS.
AUDIENCE SPEAKER: I don't have a good answer for that.
ANDREJ CALETKA: Thank you very much.
RAYMOND JETTEN: Thank you Ondrej. And thank you all for being here. It's almost 70 people online and a lot more people here in the room. It's time for the closing of our session. See you all in Prague. Please rate the talks and get your lunch.
(APPLAUSE.)
LIVE CAPTIONING BY
MARY McKEON, RMR, CRR, CBC
DUBLIN, IRELAND.
