RIPE 83
.
IPv6 Working Group
.
Thursday 25 November 2021
.
13:00 (UTC + 1)
RAYMOND JETTEN: Welcome to the IPv6 Working Group. Today we have only a few but very quality presentations for you.
I would like to start with Nico Shottelius. Anyone who has questions, please type in the question and answer session. The chat section will be monitored but we will not answer questions presented there. And when you have questions, please state your affiliation as well, and if you come up to the mic or want to do the mic and video we might know who you are but there is a lot of people out there who don't know who you are so state your name and affiliation.
Please remember that the session is being recorded, and it will be published later on on various channels.
So, Nico, please go ahead.
NICO SCHOTTELIUS: Thanks a lot Raymond. So, let me see if I can change the slides.
There we go!
.
Thanks a lot for having me. This is really a fun ‑‑ it's literally a fun and profit demonstration, or talk. It's about IPv4 islands and for me it's a really, really fun talk to talk about.
Let me first of all wrap up like why I would talk about IPv4 islands at all. What it is, and how to use it. And if you are listening today, you are probably interested in IPv6, I assume, otherwise you wouldn't be in the IPv6 Working Group slot here. So, generally speaking, we see a notion of networks if you enable IPv6, it makes more sense to go IPv6‑only than to go to dual stack. The reasons are kind of known already. It's like it's way less complex, it's easier to maintain. If you think about it also, way easier to actually build up an IPv6‑only network than to think about how do you manage different types of applications and different dual stacks and different network policies and so on.
So, basically, there is a shift I think everybody agrees with me, and if not, just let me know. But I think there is a general shift to if you build a new network and you go to enable IPv6, it probably makes more sense to go IPv6‑only.
So, this is a problem that some of you will come up with and that is actually real. There are some devices which are not IPv6 compatible. And you can try a lot of things, you can try to update the firmware, you can try to replace the device, but sometimes you are stuck with this, and I want to give you a little bit of an overview of which devices we encountered. Some of them are not so obvious like X‑ray scanners or ultrasound scanners. So if you have been recently in a hospital or you have looked around all the fancy machines that are in a hospital, some of them are really, really old and most of them are really, really expensive, because it's very targeted machines that have to fill high standards which have to fulfil certain certifications, so, replacing such a machine is not always possible, or often not possible for reason of budget, or simply because the machine doesn't exist any more.
Something that we at Ungleich were affected by is, we have this LoraWAN protocol, which is basically a wireless protocol at long range, the devices that were wireless at some point usually they send the payload to the Internet, and this ‑‑ while the devices themselves are not using PIP the gateways are using IP, IPv4 and IPv6, some of them also have old firm wares which only can connect to literal IPv4 addresses. And, well, if you are shifting all your networks to IPv6‑only and you still have a couple of hundred senders around, then it's not really helpful if all of them are going offline by the time you move your gateways.
.
Like one easy example is like old printers don't have IPv6 stack, I think most of them have nowadays, so over the lifetime if you don't have a huge xerox machine that puts paper on one side and copies on the other, you might have a recently new one which supports IPv6. But there are still some where we see it cannot be replaced.
.
Last but not least, you might know where I'm here in Switzerland, in the mountains, we have a lot of water power plants, and these power plants are all driven by the recursive that is just a few hundred metres from where I am sitting now and these power plants are often having very, very ancient technology in them, so you can assume that the switches in there are actually ethernet, which is great, but they are usually at maximum 100Mbit and all the software written there was never written with anything in mind that there might be coming IPv6 at some point.
Now, some of you might wonder like power plants in the Internet? Very different, you know, discussion, I don't want to go into this, but yes, some of them are connected to the Internet, and usually very well protected, but nonetheless, they have connectivity so that they can be remotely modern in case something goes wrong.
You can assume that replacing a whole power plant or even parts of it can be a very, very tricky part especially because it is actually the software back plane in power plants which is written with IPv4 only in mind. But nonetheless, you want to connect them potentially from your IPv6‑only network.
So, how do address this. Generally speaking, you can try to replace the devices, not always possible. Or we can try to get the number of IPv4 devices or IPv4 networks that we have as little and as much down as possible. And the approach I'm talking today about, we call IPv4 islands because they are really tiny islands, they may be one power plant might actually be in the end just one IPv4 device phasing to the Internet because the rest is actually hidden inside their own bus.
The point is, you can, with this strategy, you can go step by step incremental and say, like, for instance, with office network you can easily replace to IPv6‑only because all the modern operating systems IPv4 IPv6 and your printer supports IPv6 but maybe next to the office you have a power plant. Maybe not the typical thing but maybe you have an old printer, so you can do it step by step and say, and say, okay, I still have an island left which is IPv4 only.
Now, how does it work, like, in theory, like how do we use them? So, assuming that we have ‑‑ you can see the IPv6 here on the top and you want to reach the IPv4 only network at the bottom. And obviously this has a problem, it's a different protocol, it's a private IP range, so, generally speaking, you can't easily reach it. However, if you had a NAT64 translator, and I'll come to it later like how they look like, you can just say you assign a range, an IPv6 range to the NAT64 translator, in this example it's there. /120 is 8 bits of network. So it nicely maps to a /24 network in the IPv4 world. The biggest problem or challenge here is that, you know, the IPv6 range is so much bigger, you know, every additional bit doubles the space and we're talking about 32‑bit, to 128‑bit. So there is no chance that we can resemble the IPv6 Internet and map it to IPv4 addresses. So what we need to do is basically, the same thing that we do in CGNAT or in the IPv4 world, we need to squash the huge IPv6 Internet, the 128 bits, down to a single IPv4 address.
So we have all kind of like stateful translations. If it uses large scale, this will not work. You cannot have the whole Internet access your power plant with all IPv6 addresses but that also not usually what you would achieve by running IPv4 islands. What you want to achieve is that those islands can be reached from the IPv6 Internet, that they can still reach the Internet, the IPv4 Internet, via IPv6, so that you can still continue to run them until the lifetime is really, really really over.
But yeah, bear in mind that is not thought to be a solution for like high availability or very high load. That is not the right direction I would take with the IPv4 islands.
To that's the theory. Let's have a look how one can use this in practice.
What we often do is we have all kinds of devices which are OpenWrt routers so you can use any kind of device that supports it, and on this machines, we have Jool running, which is a NAT64 translator written in software, which is a Linux kernel module, and it exists natively in OpenWrt so you can just install it and have it running.
.
So even more practice, how does this really look like, and I want to show you this because I am amazed how easy it is, I will just turn my back to you for a second. And I can get something. Having one of those devices, what you need to do is you basically need to configure the interaction between OpenWrt and the kernel because OpenWrt as a special mode of how it handles IPv6 assignments. So if your router gets an IPv6 assignment from the outside, then you have to load the kernel module which is just a module and then you define which NAT64 prefix you want to use. This is an example I actually used the whole/96 so whatever IPv4 address is behind there I don't care because it is a 32‑bit, you can map a whole IPv4 Internet. So you can have the whole IPv4 Internet behind this router.
Then you have a command says add your instance via net filter and use this IPv6 pool, the 6 address here, for this prefix that's above.
If you don't believe me, and I am always happy like people say this can't be true, well, just go to the website, there is a subdirectory OpenWrt and you will find an IPv4 island script in there which exactly the lines of code are copied from. So it's literally two to three lines of codes that you need to enable it.
So, in practice, what device can you use? I will show one, it's important, this is just one of many devices that you can use. The important thing is, you need anything with two ports, two ethernet ports, basically where you connect your IPv6 antenna on the one side and the IPv4 LAN or island on the other side, and that's it. And the great thing is, and doing the advertisement for OpenWrt because you have such a variety of devices, you can plug them in. But it's very much recommended that you actually reflash them so that you actually have a proper OpenWrt and not the Windows‑specific version because they often like a kernel, the proper kernel module support.
This device here, is even just 100 Mbit device and it comes backs to my previous comment, the IPv4 island approach is not thought to be useful for something like high performance. It's more supporting growing your IPv6‑only networks, but still supporting stuff that you can't migrate.
So, the main takeaway here from my side is, even if you have legacy devices and you will have this in your deployment strategy or in your migration strategy, you probably have comes up, you can still easily switch to IPv6‑only and you have an iterative approach of saying, like, okay, I have here a building, I have here a department, they still have IPv4 only devices, but nonetheless, my core network I can switch to IPv6‑only and then I can go to department to department building by building, if you want to know how this looks like technically, I have linked a speech how to do it in OpenWrt. There is an IPv6 chat and if you have any questions to this topic, I am also going to give you my mail. That's it from the IPv4 islands, and if you have any questions, I am looking forward to hearing them.
RAYMOND JETTEN: Thank you, Nico. Please stay online, because you know what's going to happen next. I don't see any questions in the question and answer part. And on the chat, there is a lot of talk going on. So...
BENEDIKT STOCKEBRAND: Okay. Sorry, my camera is frozen, I hope you can still hear me. Okay. Good. Not so much a question from my side, but actually a comment.
.
There are huge variety of approaches to issues. This is ‑‑ the one you have shown is one and probably very, very important one. If you are stuck with these things and don't know how to proceed with it, that's what we have the mailing list for. So, if you say yeah, what Nico said was pretty good but it doesn't work for us because you'll find some people here who can give you a number of ideas. The point is, if we want to give you some level of overview, it probably would be a half‑day workshop or something like that, to go to other options that you have. This is ‑‑ just don't say I have been at the RIPE meeting, and I thought I'd find an answer, but this doesn't work for us so we have to do IPv4 any more. It's not an excuse.
NICO SCHOTTELIUS: I fully agree.
RAYMOND JETTEN: Then we have a comment from Michael Richardson, saying: "Nico, thanks for explaining this. I have been doing this too. I think that we need each other's name rather than islands."
NICO SCHOTTELIUS: Very open for that. It's a very logical name because basically you have the big sea, which is your network, then you have islands which are somewhat disconnected, which are IPv4 only. But if you have a better name, completely up to that. No strong opinion there.
RAYMOND JETTEN: You could have a discussion on it on the mailing list as well, you could have something to discuss about, perhaps some other people have ideas as well, you never know.
All right, we're not finished with you yet. There is yet another presentation coming up by you, Nico, it's about the ULA or not to ULA.
NICO SCHOTTELIUS: Yes, and I hope the idea is to have a bit more of a discussion there. I am just looking for it. Here it is.
This one is, for me it's a bit of a hot one and I hope I get out here healthy and alive after this presentation.
I don't know who knows about ULA or not. I'll give you a little bit of background before going into the discussion, but my idea is more to have this in open floor later, discussing whether or not this is a good idea or whether or not there are better approaches than the one I'm showing.
ULA, there used to be an ULA registry from 6 that was stopped in 2017. In around 2020, at Ungleich we arranged a new ULA registry and give me a few minutes to what is ULA, why do we need a registry? I'll come to that in a second. Since then, there are around 100 new prefixes registered since 2020.
So, we announced that we are actually running the registry. However, we are actually not using it ourselves. So, the reason why we are running an ULA registry is because our customers and partner companies and networking friends,, people approached us and we are like, hey, can't we have a ULA registry? And usually our answer was like well, there used to be 6, it's not there any more, we really don't have a use case any more because as an LIR we will deploy everything with global addresses anyway.
Now, again, as I said I will try to keep this short, I am happy to get any input today from anybody around here, so this is more a discussion than a presentation.
Shortly recapping. What is ULA? The idea is it's a unique local address. Local in this context means it is local to your network, it's not a globally routing address, it will not be put into a routing table in the Internet. But one of the questions is like, how unique can something be without having a centre registry? The idea of ULA is basically you have two prefixes, I'll come to them, and you can assign yourself a prefix, our usually a /48 in a random manner to yourself. This has some problems already, in terms of collisions and I'll talk a bit about this. Who is actually using ULA. ULA what I see are often used in community networks. So this is not so much of a commercial aspect, I know we have had talks before which recommended using ULA addresses in your network if you have your global prefix actually changing or if you need to go from provider to provider, from upstream to upstream, then you can keep static ULA addresses in your own network and use NAT 66 as your address so you always adapt to the global prefix.
But the use case that I see more or the reason why we have actually set up the website is more like from community networks which came up to us and said, hey, can't we have a registry.
One thing that is very different to regular IPv6 addresses, is the ULA addresses will usually not be seen in the Internet. So we we're not talking about routing. So, there are two ‑‑ now, it gets a little bit more tricky when we talk about ULA ranges. So there are two ranges. In theory, the FC00::/8 was supposed to be running without the registry, kind of like self‑assignment, random addresses. It turns out six at the time used this prefix to register prefixes, I mean they are not official, we are not official, nobody is official when it comes ULA. That's also the problem I want to talk about.
Then there used to be this notion of FC00::/8 which is supposedly managed by a registry but not defined which registry. So, as far as I can see, there is not much use ‑‑ it's not being used a lot, the CF00::/8 prefix and there is no consensus from the IETF mailing list about who should be running it. And this is also the reason why I want to give this talk today is like. The question is like if there is a registry, who is responsible, who should be participating for it? Should there be somebody participating for it? Shouldn't we be using GUA anyway. Shouldn't be we using global unique addresses anyway, should we be kicking out ULA at all? One argument that really speaks against it is the price and being associated with an LIR or being an LIR or having a sponsorship by an LIR is something that doesn't actually come up the community networks or community projects, and this can be anything from hacker maker space like up to the community networks I mentioned before which actually span multiple cities, for example in Germany, and I believe there are other projects in Brazil and so on, that they just need uniqueness in the networks and they are quite advanced, they are building it on IPv6, and they need to know that, let's say, Hanover is one range, Hamburg is another range, where should those people go to? The interesting part is their currency is a money a hard resource, money is not available, but resources in terms of work are often available, so one of the ideas that was discussed is should there be like a proof‑of‑work‑based registry, so that people can get DUA or ULA or whatever, but pay in work, maybe?
I don't know. This is really an open question. Or should ‑‑ or do we actually need ULA or not, in the end?
.
So, I know this is a hot topic, I don't have much more to say but I really wanted to listen to everyone around here and hear your opinions. If you think it's a stupid idea, fair enough. But if you think there should be other work done, fair enough. I just ‑‑ the solution I would like to see is something where we can support more IPv6 growth in the open source community, if we can address that. That's from my side. I think there are some people already.
RAYMOND JETTEN: Yes, there are indeed some questions.
The first one is from Jordi Palet Martinez. It says: "If you want to have a registry, the right way is to review the ULA central work. I tried already in the IETF, there is a need for a possible global policy for running central IANA registry or coordination on that. It didn't work. But maybe it was too early. I am happy to work on that again if there is a community wish in that direction."
.
That's more a comment, but yes...
NICO SCHOTTELIUS: I think, Jordi, I think this might be an interesting approach. I think we had the Aerospace discussion also recently where to register IP addresses for this direction. Maybe this is a way to go. Maybe it could also be a subsection of the different RIRs that they supply GUA community space. I don't know, maybe let's keep the discussion open after this meeting, I will reach out to you.
RAYMOND JETTEN: Then we have Niall O'Reilly, who is, this time, ULA user, and he is also the RIPE Vice‑Chair. But he doesn't have the hat on at the moment.
.
He asks that: "Did you import registrations from SixXS to your new registry?"
NICO SCHOTTELIUS: Yes, we did, and this was also very important, if we want to claim there is a ULA registry, which is very thin ice, I am completely there with everybody, then at least the minimum we have to do is import everything that was in six and everything has been imported and actually some already have been deleted, which is pretty cool, because people came up and were, like, I saw there is a registry, I still have half this prefix which I don't use it any more and they deregistered it, so yes, we did that.
RAYMOND JETTEN: Okay. Then we have Marco Hogewoning, public policy team: "Maybe one of the AOBs ‑‑ your security strategy ponders about legislation but then also mentions the potential to sunset IPv4, all on the caveat that when insufficient progress is made with IPv6 adoption. Would the RIPE community advise on this other than avoiding legislative matters to force a particular technical choice? Force use of IPv6 or discourage the use of IPv4. Mind you, this strategy is focused on all of the market, not just public sector."
NICO SCHOTTELIUS: That is a tricky one, and he didn't make it easy at the end. I don't have an answer right away for this one, to be honest. I think at the moment what actually is a huge raise in price for IPv4, so in this regard the market already does a little bit of its play which we anticipated some years ago, or hoped for some years ago, and I think we do see policies in the US, for instance, where governments are going IPv6‑only, not only IPv6, but IPv6‑only. So, I think in this regard, I think what an RIR like RIPE can do, and should do is give the possibility to everybody to participate in IPv6 deployments and, for me, I have to say, I am coming from the open source world like for more than 20 years now, and open source is an innovator, so giving the possibility to community open source projects to run their own IPv6 space, ULA or DUA, a different question, I think this can enable like a bottom‑up development, where those networks really can go ahead and say, hey, I have my own space and then they can innovate. But the question still is like, how do you maintain this? And who is maintaining it?
RAYMOND JETTEN: All right. Then we have Rudiger Volk. You can speak now.
RUDIGER VOLK: Kind of, I remember the times when the IP ‑‑ well, okay, when Internet number resources were essentially available for free and the one registry was, in fact, funded by the US federal government, and kind of for supporting communities that were outside of the actual very small Internet of the time that wanted to install TCP IP locally or regionally, but okay, with fairly limited perspective of interconnecting globally. Okay, people started to volunteer, essentially, started to hand out stuff, kind of getting centrally allocated space and then doing sub‑registries, and out of that in the end, essentially in Europe, the RIPE registry, or RIPE NCC registry, came out. And I feel that from my experience discussing with parties that were considering what addresses they should be using, my take would be: If the address space that you are using in your technology actually has the free resources for everybody to go globally unique, you should go that way. And if the current ICANN angered registry system does not offer a way for all of the communities to adequately address their needs, well, okay, that should be a trigger for thinking how to do that. Out of my work, back in the days, in the end the precursor in some way of ULA, it asked the RFC‑1918 space was defined, but, well, okay, quite obviously that was meant and declared to be, well, okay, that's just local and, well, okay, you do not need to do a registry there except for the case where in ‑‑ you decide your enterprise network will not be connected to anybody else and there will be no need for interconnecting under acquisitions and mergers and so on, well, okay, yes within your enterprise you may ‑‑ and you may need to run your local ‑‑ your really local registry as a very closed system. So thanks.
NICO SCHOTTELIUS: Thanks. I think I see your point and I think it's also the gut feeling I have a little bit that maybe this should be in a way like a community/volunteer effort, and to some degree, this was already a bit discussed on the IETF mailing list. One of the questions that came up there was like, the usual one: Who is going to pay it? And so, the, the background the idea on the mailing list was maybe we should have somebody giving out GUA, like global unique addresses, the same direction that you are suggesting, which I think is a good way because it would not only give uniqueness but also globally addressable. And yeah, I'm thinking this might be the way that somebody ‑‑ I mean, sponsoring the address space is one thing, sponsoring the workforce behind this is probably another thing, and being recognised is a third thing. I think maybe one or the other needs to be addressed like this. And I am very interested in like if anybody is up for this task, I would love if you can reach out to me.
RAYMOND JETTEN: All right. I have Michael Richardson at the mic. And I have one more question. So, I'll take the question first.
And that's from Peter Hessler. "If the community was to group together and form a LIR to request and manage IPv6 address space, how much space should they request from the RIPE NCC?"
NICO SCHOTTELIUS: I mean that's an easy one for me to answer. I mean with RIPE, you can easily start with a /32 and then it's used up, well then we can request another /32. You don't have anything where you need to ‑‑ you don't need to have consecutive addresses, so ‑‑
RAYMOND JETTEN: There is an exercise where you can get it right away without any clarifications, is a /29 at the moment.
NICO SCHOTTELIUS: That's true.
RAYMOND JETTEN: Yes.
NICO SCHOTTELIUS: I think that that would be plenty, more than enough, if you assume a /48 per assignment, then it's 65,000, isn't it, per /32, yeah.
MICHAEL RICHARDSON: I have been a proponent of some kind of a non‑connected IPv6 address space for a long time. My first experience came across this where I wanted to use it in a data centre, across multiple data centres actually, through VPNs as a management network, and I have experience going back 30 years that, inevitably, these leak, and when you see a leaked RFC‑1918 address, you are just like, I have no idea who to tell. And that's also why I don't like ULA random, is because when they do leak and you see them, then who do you tell? And I think that the value of Whois here is really quite high for quite a number of people, and also, the kind of ‑‑ it provides a little bit more of a feeling that nobody is going to come and stomp on me or do something terrible to me for using this address space. And I think that's really valuable.
And the possibility of reverse DNS actually, well that really matters in IPv6, I think. So, this is why I would like to have a thing, and I'm agnostic as to whether or not it's a /29 of global Address Policy carefully managed and for which RPKI says you shall never announce it, or whether it's, you know, we finally get ULA central working in the FD/8 working. I don't care which one it is. I think that a nominal fee to register it once is acceptable. And some of places where I see there is a need for it, is actually often within the chassis of equipment, not necessarily routing equipment, for instance, the project I work on involves Sonar equipment in fishing boats and we have an IP network from the top to the bottom of the boat, and as I said, it would leak. So I'd rather it wasn't RFC 1918 and I'd rather it was IPv6 and if there is too much paperwork, I'll tell you what the engineers do because the monitors don't want to do the paperwork, they'll use 1.1 or, you know, 11 network or something else like that and RFC. Because they don't want to use 1918 and the reason they don't want to use it because well, that's on the other interface because the other identity side of that device is going to plug into something that's NAT and they can't predict what it is so they have to use something that they think you'll never see out there, and the correct answer is you should use IPv6, right. But they don't, because they run into this well, I can't get any address space to use this right. And it's not obvious that ULA random is really the right choice because they want static addresses. That's correct. You actually probably should do that but it should be within your prefix that you own. So you can be giving out ‑‑ you can be doing /96s if you like with static assignments because you are not doing SLAAC or anything. Or you can make a /64 for each one. That doesn't matter, that's your problem. But I really think we need to enable this. We need to make it whenever is someone is thinking I need a bit of a network that I need to describe it's not public, they should be thinking oh, I am going to go to this address space and, you know, for a registration fee of, I don't know, €7, you get it for the rest of the eternity of the universe, and that's it, continue. So let's do it again. Let's make this happen is what I say.
NICO SCHOTTELIUS: Okay. Thanks.
RAYMOND JETTEN: And ‑‑ I have closed the question and I am closing this part because we're running out of time. Unless you have something really short?
BENEDIKT STOCKEBRAND: A couple of things I sent to the mailing list. Just one thing, one use case that tends to get forgotten in this community because most people are LIRs. If you have provider‑aggregated addresses and want to maintain some sort of independence from your ISP, ULAs are really, really helpful if you need to do your renumbering. There is a big difference v4 and IPv6 in that IPv6 was from the beginning designed to support multiple addresses per interface, unlike IPv4. So, this is where this is really, really useful at times. But, the other thing is don't ‑‑ we should be careful that we don't start a second address space that is sort of connected but not really, and people start to use ULAs across the Internet through tunnels or whatever where they really shouldn't. That's not helpful. Then they should use Quagga right from the start.
NICO SCHOTTELIUS: Everybody, it's very much appreciated, it was a very fruitful discussion for me. Thanks a lot.
RAYMOND JETTEN: Thank you, Nico, very much for your participation. Next up is Jan Zorz with new document, RIPE554bis. Go ahead, Jan.
JAN ZORZ: Hello. Can you hear me?
RAYMOND JETTEN: We can.
JAN ZORZ: Let me ‑‑ you need to make me a presenter probably so I can share slides.
RAYMOND JETTEN: I think you already are.
JAN ZORZ: Okay. Thank you very much. Hello everybody. My name is Jan Zorz, for those who don't know me, and this has been a saga for updating RIPE‑554bis. This is supposed to be a quick update.
For those who don't know who we are. These are the authors, Jan, that's me, I was ‑‑ and Sander, we did the RIPE‑501. That was the first version of the document. Then came RIPE‑554 where Merke joined and this is I think nearly ten years old document and it's quite outdated. So, we decided after a long discussion and many suggestions from the community to actually go for 554bis. So Tim Chown and Tim Winters joined the team and we are now, I hope, in the last edit‑cycle of this document.
So what is RIPE554? That's basically a guidance for procurement when organisations around the world want to buy the equipment, this is the template how to ask for IPv6 capabilities, and the document was quite successful by enterprises and governments all around the world. I think it was translated into 16 or 17 languages around the world.
.
And now it's time that we basically update it, because there were some typos, bad grammar, basically none of us were native English speakers in the past. So, what we did, we updated some RFC references to current versions. We add fundamental FRCs, like IPv6 over ethernet, we removed extend, for example because nobody is doing it anyway. We removed BOUND v6 because it doesn't exist any more. And the following slides are showing just the highlights of what we did. We just added some requirements, for example, handling of overlapping fragments, then we have the atomic fragments considered harmful, then stable opaque addresses for SLAAC and DHCP. RDNSS, then changes for enterprise and ISP switches, we added some mandatory DHCP relay options, added savvy for DHCP as optional. We are modernising it because people, these days, needs to ask for all these questions.
We also added RDNSS support, added that we don't assume /64 and we also added some optional DHCP v6 relay options.
The CPEs, we added mandatory simple security capabilities because we think that this is a good thing to do.
There are some changes for mobile devices section. We removed, basically, the whole section. That's the biggest change that you can basically go for. We now only consider their wi‑fi interfaces, because that actually makes them a normal host. And 3GPP related standards are out of scope because I heard nobody going into RIPE‑554 to read 3GPP requirements.
Then there are some changes for the load balancers, we replace X‑Forwarded‑For with the standard forwarded. And there are some changes for software. So, programmers beware, the expanded ‑‑ we expanded the minimum requirements, like we allow all valid addresses in input, use recommended notation in output, DNS resolving must support AAAA, connections must support IPv6 sockets, and then when connecting use default address selection or Happy Eyeballs 2 and make it explicit that this list is not exhaustive.
So, here is the link to the draft. We are ‑‑ we think we like ‑‑ we would like to think that we are at the end of the update. There are still some small little questions in there that needs to be solved. But basically, this is what it is.
So, I would like to ask, and we all the authors would like to ask this Working Group: Is there a consensus? Because RIPE‑554 is very outdated, and we need to publish an updated version as soon as possible. We decided not to add new sections or new hardware or new type of equipment because we just wanted to do a quick update of 554, bring it up to speed to the current date, and then we might handle those suggestions separately in the future with a new document or with the update of the 554bis, something like this.
So, is there a consensus on publishing the current draft as the new RIPE document, the successor of 554? And is there a suggestion or consensus that we should have a look every two years, if all the RFCs are still valid.
And that's all from my side. Are there any questions, comments?
RAYMOND JETTEN: Yes, there are. There has been some discussion on the mailing list, I think it has been answered well, but here is Blake Willis: "Jan, is RFC 8950, RFC 5549 BGP tunnel signalling in scope for this document?"
JAN ZORZ: Oh... let me see. So, we are mostly putting in here things that are IPv6‑specific. So, I will have to look for 8950. Sander, do you have an answer to this?
SANDER STEFFANN: No, I don't. Sorry.
JAN ZORZ: Currently, 8950 is not in the document, but we could probably consider it for the next version. As I said, we didn't want to expand the scope because then it would get years to get a consensus to publish the updated document.
RAYMOND JETTEN: Okay. Then next up is a question of Eric Vyncke from Cisco and IETF with my IPv6 evangelist: "I cannot find the following changes mentioned in Jan's slides in the bis. Don't use /64 and RFC 8200, now includes atomic/overlapping fragments. There is no need anyway to mention those."
JAN ZORZ: I think we addressed that.
RAYMOND JETTEN: We will explain it a little bit more, I think he has asked for the microphone.
ERIC VYNCKE: Sorry about that. I should be used to Meetecho, but I'm not really. Mainly first, I came on to say hello to Jan and Stefan and to everyone. But basically dual stacks, you put in the slide, I don't see them in to the bis document at all. So, I am just wondering whether ‑‑ the point you put at the end is the latest version, or are the slides slightly outdated compared to this version?
JAN ZORZ: The slides ‑‑ I think the slides were done before the last changes. So, we have 8200 in the requirements for the host equipment.
SANDER STEFFANN: I was the one who made the slides last week for UKNOF, and I didn't think there were many changes to the document, but what I actually did was, I made a text dump of the old document, a text dump of the new document and used plain old diff to get all the changes between them. But I might have made a mistake somewhere.
SPEAKER: I was just wondering.
RAYMOND JETTEN: I have ‑‑
JAN ZORZ: The basis IPv6 specification updated its number and we just updated the number in the document. We didn't want to highlight that just the number change, you know, because it's basically the same document, just updated.
RAYMOND JETTEN: Tim Chown was there for a minute...
SANDER STEFFANN: I also found, I think, the line that Eric was referring to. I think that bit of the presentation came from RFC 7608, which is IPv6 prefix length recommendations for forwarding, which explicitly mentions that prefix lengths longer than /64 must be supported in forwarding.
TIM CHOWN: The other two RFCs you did mention, we did remove them from the bis documents that you requested them. But the slides, as Sander said, ones you used previously and the slides have not been updated. If you look at Google doc, which is the latest snapshot, you'll see that those things have been removed, as you suggested.
RAYMOND JETTEN: Okay, we have one more question from Christoph Berkemeier. "Are you aware of automated or semi‑automated test groups or environments for your recommendations?"
JAN ZORZ: Okay. No, because this is the main and basic mistake that lots of people is doing. This is ‑‑ this document is meant to be used as a template. Because there are inside things like "If such a functionality is required then this RFC is requested." So, for example, "if support for tunnelling and dual stack is required the device must support basic transition mechanism of IPv6 and routers." Then, you know, okay, technically, it could be possible build a script or a system that would go and test, but you would have to set in the script in the mechanism everything that you want or need, that would be quite complex. If somebody wants to do that, well we are more than happy to include it in the next version of the document where this mechanism is, but this a little bit reminds me of a feedback that we got from some people where this document was used in terms of, they put out the tender and they said: Your equipment must be in compliance with RIPE554. That's not possible. You need to go in. This is a template. You need to go in and copy/paste basically parts that you need that are actually requested. So the answer is no. But if somebody builds something like this, well why not?
SANDER STEFFANN: On the chat, Blake Willis is referring to the University of New Hampshire, they have a testing lab that does independent testing.
JAN ZORZ: Yes, so we have in our document, there are, at some RFCs, at some requirements there are asterisks, and that asterisks are indicating that these requirements are being tested by IOL UNH. So if you want just to test this, then you can go to UNH and have a look at their release stuff, certifications.
RAYMOND JETTEN: Okay. Thank you.
JAN ZORZ: Tim Chown is asking an open question on is whether we should add YANG? But I think we wait for the next version of the document, so my question is, should we go forward with this or do we need to change anything else? Do we have a consensus?
BENEDIKT STOCKEBRAND: If you decide you want to do the work, nobody is going to complain.
RAYMOND JETTEN: Shall we do this, that we keep the mailing list open till, say, next Wednesday, and then ‑‑
JAN ZORZ: We can look at the chat and people is going, go for it.
RAYMOND JETTEN: I am very happy to go forward, but just in case if there is anyone ‑‑ this is your very, very last chance, would it be a good idea to do this next week on the mailing list? Or do you want to do it now?
JAN ZORZ: Should we declare this the last, last, last, last, last call?
RAYMOND JETTEN: Yes.
JAN ZORZ: Okay.
RAYMOND JETTEN: Right. I'll do that right after this meeting.
JAN ZORZ: Thank you very much everybody for the hard work.
RAYMOND JETTEN: And I'd like also to thank Suzanne Taylor from the RIPE NCC for doing the scribe of this, which reminds me, we have our previous minutes we have been on the website for a very long time and we have seen no comments on them. So, I also declare those as being the final ones now.
And I really hope to see people next time in Berlin, or at least anywhere we are meeting, and I think no one has any objections against that.
With that, I would like to thank you all for participating, we had some 250 people being here, thank you for joining us. A pity Benedikt had some problems with the cam but ‑‑
BENEDIKT STOCKEBRAND: Sorry about that.
RAYMOND JETTEN: Technique is technique, it's probably not working on IPv6 anyway. So thank you all and see you next time, hopefully live.
(Coffee break)
