Archives

IPv6 Working Group
.
29 October 2020
.
1 p.m. CET
.

RAYMOND JETTEN: Welcome to IPv6 Working Group. We're having a virtual meeting, unfortunately, but we have around 300 people in the room, which is not too bad. I'll start off with some sliding slides, if this thing works. Yes, it does.

First of all, some agenda stuff, agenda bashing.

The minutes from the last meeting have been on the mailing list for a couple of days now and I haven't seen any comments on them, so far as I see it, we can accept them as they are at the moment. And of course, thanks to the RIPE NCC for doing these minutes and also thanks for the person who is doing them right now.
.
Then about the microphone. There is a couple of tabs on your participant blade where you can ask for the mic. Please do that only after the presentations. If you don't, they will drop you and I'll also have to do some very sharp time‑keeping here.

Please also remember to rate the talks. You can do that once you are logged into the RIPE website with your account and you will see the agenda. It helps a bit figures out what's kind of programme you actually like.
.
So, without wasting any more time, I will hand over to Tim Chown, who is going to have a presentation about RIPE554 and possibly changes to it. Tim.

TIM CHOWN: Thank you very much. So, I am ‑‑ I have just got a quick slot to talk about an update to RIPE554. Hopefully many of you are familiar with this. It's the requirements for IPv6 in ICT tenders and procurements. We have got the original author team again of ‑ Sander and Jan and double Tim being added to it, myself and Tim Winters, who some of you may know from his work with the interoperability lab and conformance testing.

One slide, basically.
.
The idea of this slot today is just to flag that we're taking this on, or planning to take this on, and to get some feedback from the group. So, I sent an e‑mail to the v6 Working Group list yesterday and there's been a few replies to that already. And what we're looking to do, assuming the Working Group agrees, is to progress this version of RIPE554, which is now eight years old, with the original version being ten years old, in my role at Jisc and being responsible for some of the JAnet network and the universities connecting to it and IPv6 there, we do get a number of universities who say that up‑to‑date procurement guidance would be useful, so in sort of my day job I see the value in this. And if we do agree to progress it, we have got a number of strategic questions we want to sort out before we dive into the details.
.
So, for example, should we keep the scope to largely enterprise or should we expand it from that? Should we keep the linkage to the EV6 ready logo programme that's in there? It's still an active programme, it still has value. We could keep that.
.
Are there new classes of equipment to add? So, 554, that is seven or eight classes of equipment that's defined, but things have moved on. Do we want to include IoT or low power class of devices? If it's a university campus, for example, specifying v6 for wi‑fi controllers would be of interest, is that the sort of thing we want to add. Are there specific sections that are out dated or specific new sections we should add? Is the structure of the document generally okay?
.
And another thing we were discussing yesterday as we were reviewing the document, should we add guidance on applying the content of the documents? Should those be separate documents? Should it be a packet loss? For example, if I was going to present 554 BIS to a university audience, I would probably set the context it of the document for them with other little bit of text. Is that the sort of thing we should put in this or keep it separate?
.
Anyway that's the sort of high‑level questions we have currently. There is ‑‑ the author team is using Google doc just to work its way through the document and do obvious changes where RFCs have been obsoleted and updated. We were also working through other potential changes there. You can see a snapshot of the Google doc at that address there, the PDF document. We don't really want to add hundreds of people as commenters on the document yet as it might get a bit crazy. Until we sort out the strategic side of things, we'd prefer to work that way.
.
Please comment to the list or you can mail the author team. It's there on the screen.
.
That's pretty much all I want to same. Just to flag that the work is starting and if you have got ‑‑ not questions now, but we'll be there on the list watching and responding to the comments there. Thank you.

RAYMOND JETTEN: All right. In the queue I don't see any questions at the moment. Haven't had time to type them yet.

TIM CHOWN: I'll be happy to progress with this, or should we not? That's the main question.

BENEDIKT STOCKEBRAND: I hope I didn't jump a queue. As the Chair you can't just join the queue somehow regularly. First off, I think 554 and 501 have proven very, very helpful in a lot of cases and I think it's is a very good idea to continue and update this and keep going. One thing I remember from discussions like, it's really eight years ago, that this thing is getting bigger and bigger and it might be an idea to split it up for different scenarios, different purposes, whatever.
.
I don't want to interfere or ‑‑ with the work you are doing in there, but that might be an option if things get too big to handle in one document.

RAYMOND JETTEN: We have two people on the mic. We have only half a minute left, so I'll give the turn to Dmitry.

DMITRY: I can see only one looking with RIPE General Meeting and it's very difficult to discuss anything because not matters what we group before discussions. So, we only see some exhibitions of the people have done, and at this moment we want to have some discussion about some problems and General Meeting that it may be, we have no ‑‑

RAYMOND JETTEN: Do you have a question?

DMITRY: My question is: What ‑‑ maybe it's possible to give some materials for all members who are used it in RIPE before some discussions. And about IPv6 demeanor, what you say it's a real problems and the one question that I can add that is in a translation to the national language.

RAYMOND JETTEN: You have to follow the mailing list, that is where the things happen.

DMITRY: The mailing list ‑‑

RAYMOND JETTEN: Thank you for ‑‑

DMITRY: It's not for general meetings ‑‑

RAYMOND JETTEN: Thank you for your comment. We are over time, so I'll start to ‑‑ Michael Richardson.

MICHAEL RICHARDSON: My comment would be, don't do anything with IoT, there is lots of BIND things out there already and it's too immature for the scope of the document you are typically doing.

TIM CHOWN: Okay. Thank you, Michael. Good to hear from you.

RAYMOND JETTEN: Okay. Next up is Nico Schottelius and he is going to bring IPv6 everywhere.

NICO SCHOTTELIUS: Thanks a lot.
.
Happy to be here, especially in the IPv6 Working Group. It's always a pleasure, especially physically but also virtually.
.
Let me just come back. There was a RIPE 79 claim I made in a presentation about the IPv6‑only data centre in Switzerland, and the claim was, you can use IPv6‑only resources because you can get IPv6 anywhere. That was a claim just right after the presentation a couple of people came to me and was like, is this really true? And actually over the next days at the RIPE conference, as well as other conferences I was afterwards, I got a couple of comments to my claim there. And one of them is Hurricane Electric, I think everybody knows of them, doing a great job for distributing /48s around the world, doesn't properly work beyond CG‑NAT.

It's a valid point. What we offer here is the IPv6 VPN, which is WireGuard‑Based, and you do need to install WireGuard, you need to create a set of public keys which is for some people already too much to say like okay, this is things I don't want to deal with when ‑‑ I just want to have IPv6. And the claim, even from ‑‑ within the network community was I want something that just works, that I can just take and plug in and it does the job.
.
So, this gave me a little bit of headache, because I claimed that you could get IPv6 everywhere and I still think that you can do. And it took actually quite some time to find something to really give an opportunity to say yeah, well, you really can get IPv6 everywhere.
.
And with this, I would like to introduce the VIIRB, some of you might already have seen it, the VIIRB is the VPN IoT router box and I am claiming it is the world's smallest IPv6 router with or without certification, both of it ‑‑ actually, give me a second, I have just seen this is actually the number one device, so you can see how it looks like in reality. It's compared to me, it's a 3 by 3 centimetres ethernet port USB power box. The sides is one thing. The claim I made before is that you can get IPv6 anywhere, everywhere, and this I really want to stress is possible right now without a lot of effort.
.
How does it look like? In reality, you plug in the ethernet cable, you plug in power on the other side, and it does the job. Some of you might now like raise the eyebrows and say, how is it going to work? And I want to talk a little bit about this.
.
I am not sure, I hope you can roughly see the things.
.
So the VIIRB itself here in the centre actually when you plug it in acquires an IPv4 address from your LAN. It uses that IPv4 connectivity to establish a VPN and to get a /48 IPv6 network routed through the VPN to itself. Now, we have to think a bit about it because this a one cable thing. So, IPv4 gets in here, it connects outside, has a VPN, gets IPv6 inside again in this box, now comes the fun part ‑‑ it is running dnsmasq to use router advertisements to tell every client on the same cable again to tell, hey, I am an IPv6 router. So, pretty much standard for an IPv6 router. But the magic here is it's like in one box with one cable doing all the things.
.
Some details about this. As I said, it's a full /48 network because we think it's the right thing to do. We usually configure the cafe sub‑network because it's something we can all remember and that people always claim IPv6 addresses are horrible and I always say like they are great, you can like do a little wordplay in them. So the default network that is announced here is a /64, it's a cafe sub‑network of this /48.
.
And the big magic here, and for those who are not doing IPv6 everyday, is when you have an IPv6 capable device like Windows computer, like an Android phone, like a tablet, like a Linux computer, everybody when they see router advertisements automatically assigns themselves an IPv6 address, and also a route. So without ‑‑ that's the important ‑‑ without any configuration in your network, you just plug it in. Done. Every machine has IPv6.
.
Some of you will now again raise your eyebrows, correctly, and say everybody is worldwide‑accessible, everybody is exposed. So what we did is, like, on this box, it's actually running an OpenWRT, which is a Linux made for embedded devices basically for routers. We configured the firewall that says by default incoming everything is blocked besides two ports that are open inside your network, one of them being SSH and the second one I think being HTTP. So the idea that you can run an HTTP server in the network or access your devices with SSH from the outside.
.
Right. Under the hood of this thing it's roughly 3 by 3 by 3cm in size. It's tiny. It has 100 megabit ethernet port. Runs a 550 megahertz CPU and the cool thing it has a USB 2 port on this side where you can actually plug in other things like a camera or like a GPS, or anything USB.
.
Everything in here is open source, and this is why I say you can get IPv6 everywhere. So nothing of what I'm telling you today is bound to [umli], we have developed this, we are offering this, that's true. But nothing of this is closed source. You can take all the information I give you today. You can get it out there, buy the same devices, provision them yourself, use OpenWRT, use SSH, install WireGuard and run the stuff, so nothing here is closed, that's very important from my side.
.
So boot in, like if you want to do it yourself, you just find a device, install or upgrade the OpenWRT depending on what you have. You need to be careful to remove some OpenWRT default, because by default it comes with ULA space so you actually get IPv6 address assignments with things that are not routed in the Internet. Obviously you need to install WireGuard. For those who don't know it, you might know OpenVPN. WireGuard is a rather new VPN protocol which ran through a couple of verifiers, looks rather safe and what is much more important from my point of view, it's simple. It uses public/private key pairs, and basically the whole configuration you need to say, this is the other end point I'm talking to, that is their public key, and this is the network I route there. It's a very, very simple configuration. And sorry for bashing IP Sec here. It's not like you need to select a lot of different algorithms because it only supports one. So, yes, that's a draw back as well, but it's very simple to use.
.
One thing we discovered in the first production process was, cannot reship the device with a default password because it is worldwide‑reachable. Even if we say, like, well, we make the password depending on the number or the MAC address, basically because everybody knows the scheme or the generation there, it wouldn't be secure. So every device comes with a randomly generated 32 character route password, so you can do your math on how long you need it for cracking this.
.
So, some things ‑‑ we have started this project I think beginning this year with the VIIRB, mid this year. Some findings we have found there is people are interested in the VIIRB even if they already have IPv6, because a lot of ISPs are doing the old changing the IP address space after a certain time after a reconnect after a week or after a day which actually prevents from using IPv6 as it is intended to be used. Because you want to be able to address your phone, your computer all your things. I'm not saying cannot be interested in like changing your prefix, you might want to do this for privacy reasons if you don't want to have access into your network, but my claim or my understanding here is if you really want to make use of IPv6, you should be able to have a static /48 network, and nothing smaller and I don't think like for most people, something bigger is needed anywhere.
.
So, looking back to the RIPE 79 claim, I'm quite happy to say you can really have IPv6 anywhere. You just get such a device, plug it in and you are done.
.
Now, how does this look like in terms of reality around there?
.
So far, the work was shipped into 15 different countries worldwide. Anything from the US to Switzerland to Australia to Korea. It's quite a mixed bunch here. We are trying to keep the prize as low as possible, so it's plus /minus a zero sum gain from our side. And the motivation there is this is from my side not really targeted to be a commercial project. It would actually also be quite well fitting to non‑profit organisation.

The object of really to support the claim you can get IPv6 anywhere. And the reason why I think this is important is, you don't have an excuse any more saying like I don't have IPv6 connectivity I cannot use IPv6‑only services. So this whole mechanism, one side of the problem of the IPv6 deployment can be seen as solved. You can have IPv6 connectivity, thus you can also host IPv6‑only, at least your own stuff.
.
At the moment, we are having VPN end points in Switzerland mainly. We are actually looking forward in the future to spread them more around the world to Anycast, the IPv4 network that is used for bringing IPv6 connectivity. And we are also looking for partners, organisations everywhere in the world who are interested with a similar spirit to say we want to increase the amount of IPv6 connectivity in your region or in your area, I want to spread the availability and also to aid in education, because basically you can give, if you are a class of 20 students, you can give all your students one of these devices, potentially even reconfigure them to use your own IPv6 space, but they can, practically speaking, test and develop in their own IPv6 network without hindering or interfering with somebody else. It's really nice for doing IPv6 labs in a university, for instance.
.
Then we already have some learnings. As I said before, this is a 100 megabit hub, it's 100 megabit, it's not a hub, it's just one interface. It doesn't work for everyone. This device in theory has a tiny wi‑fi antennae inside but it has a very low range, so we kind of tend to to disable it. We have a new device, which you see here, which we are testing at the moment, which will support IPv6 plus also providing wi‑fi, so if you ‑‑ I mean, most notebooks don't have the ethernet ports anymore, so you just plug it in and you get IPv6 on your wi‑fi.

Then we have the VIMPI, which is the high speed version, which is the MT 7621, and a gigabit interface. We are only peering with the VIGIR, which is the 4G router, this is probably this model. We are still evaluating at the moment. You plug it, you have 4G router and you have full IPv6 connectivity without needing a land line or anything.
.
Then, in terms of Corona, we are doing a test project also to see and feel how much is IPv6 accepted in the world. We have just created a new project named 1,000‑EYE, which is basically based on an extended version of the VIIRB, which will be a worldwide accessible IPv6 camera, same claim there, you just plug it in and you can have ‑‑ you actually get the names; you get, for instance, nico.1,000eyes will be the camera where you can see what I'm seeing
.
That's good in Corona times, especially when you are isolated but you still want to be able to see other people.
.
In general, like, as I said, nothing here is very much magic or anything. All the devices are OpenWRT devices plus WireGuard pre‑configured. If you want to roll your own, contact me and reach out to me, this is really not so hard to do.
.
That said, the VIIRB itself has a website. If you want to read a bit about more of it, APNIC has a great blog article as well as a podcast from the packet pushers. And that's it from my side. I encourage everybody to bring IPv6 everywhere, wherever you can, and yeah, thanks for listening. It's always a pleasure to be in the IPv6 Working Group. Thank you.

RAYMOND JETTEN: So are there any questions for Nico? There is a question from Andrei: Will it break the host network and become dual stacked or even worse if the host network becomes IPv6‑only?

NICO SCHOTTELIUS: No, no, it won't. So the IPv4 connectivity is still there as before, and it will just add IPv6 to it.

RAYMOND JETTEN: Okay. Then there is one from Kurt Kayser: Will GUIP always tell that the web users are in Switzerland?

NICO SCHOTTELIUS: At the moment, yes. And there is a bracket opening as soon as we are able to talk better to the RIPE API to actually change the registration of the /48 networks, it will be easy to actually assign the network to your location where you are. Good point.

RAYMOND JETTEN: Good. Thank you, Nico. There is, yes, one other, Christopher Berkemeier: Is the IPv6 distribution stateless only?

NICO SCHOTTELIUS: Yes, it is at the moment, that's correct, but you can change it if you want to.

RAYMOND JETTEN: Then Veronica asked: Where is the device manufactured? Just curious.

NICO SCHOTTELIUS: Sure. That is fully transparent. It's being manufactured in China. It's being shipped to Switzerland and then we configure it over here.

RAYMOND JETTEN: Okay. They are the questions which I see. There is ‑‑ there was ‑‑ or there is someone at the mic. Dmitry, I am going to give you the chance to talk, but if you start talking about the General Meeting, I'll have to cut you down. If you have questions about this product, please go ahead.
.
DMITRY SCHERBAKOV: Does it have open serial path? You have device and you have several connected ‑‑ open software for use it.

NICO SCHOTTELIUS: Yes, absolutely. The software used is WireGuard and OpenWRT at the moment. So it is fully open source, a hundred percent.


DMITRY SCHERBAKOV: I'm not talking about device. I am talking about server path.

NICO SCHOTTELIUS: This is also WireGuard. It's also completely open source.

DMITRY SCHERBAKOV: What kind of VPN connection you use?

NICO SCHOTTELIUS: WireGuard. That's the open source part.

DMITRY SCHERBAKOV: Thanks.

RAYMOND JETTEN: Then we have Vesna.

VESNA MANOJLIVIC: Hello. Nico, we are having a hackathon about RIPE Atlas software probes in November. Would you be interested in joining and seeing how we can combine your router with RIPE Atlas software probes if at all?

NICO SCHOTTELIUS: Sure, that would be a really cool project. Absolutely.

VESNA MANOJLIVIC: Nice, thanks, I'll be in touch.

RAYMOND JETTEN: Right. Okay. So, there are no more people in the queue. And there are no more questions, as far as I can see. Sorry, there is one. Christoph Berkemeier again: Is there a virtual appliance to enable legacy hosters, for example?

NICO SCHOTTELIUS: To see hosts?

RAYMOND JETTEN: Is there a virtual appliance to enable legacy hosters, for example?

NICO SCHOTTELIUS: What it does, it builds on top of your existing IPv4 network so everything that is legacy existing there still continues to work. It's not a replacement. That's the nice thing about IPv6, we always say it's incompatible to IPv4, it's also a nice thing it runs in parallel to the exiting infrastructure. So the legacy stuff still continues to work.

RAYMOND JETTEN: Thank you, I am going to close the queues for questions and the queues for the microphone. Thank you very much for this. Christmas is coming up so I wonder where can I buy one? How many do you have in stock?

NICO SCHOTTELIUS: You can go to viirb.ch and we are currently having around 100 around here but we are stocking up right now.

RAYMOND JETTEN: Thank you very much for your presentation. All right. Then last but not least, we have Fernando Gont and the presentation about recent improvements in IPv6 addressing. Fernando, please go ahead.

FERNANDO GONT: Yes. Can you see my screen.
.
Yes. Okay. Perfect. I am Fernando Gont, I am glad to be participating in the IPv6 Working Group and this will be a very short update about recent improvements in IPv6 addressing.
.
As a very brief recap, if you look at the types of interface IDs that we have for SLAAC, essentially we have the traditional interface IDs based on MAC addresses which are predictable and stable. And we have also had RFC 4941, is the so‑called temporary or privacy addresses.
.
Recently, there have been efforts in two different areas. On the one hand, a few years ago, RFC7217 and RFC8064 were published to essentially replace the recommended scheme for generating interface IDs for stable addresses. And more recently, we have been working on the provision of RFC4941 to try to address some issues that have been found since the RFC were published.
.
Okay. As I mentioned, RFC7217 essentially it is meant to replace the traditional SLAAC addresses and it produces addresses that are stable per network in the hopes of mitigating address counting attacks and also host working, okay.
.
And 4941 originally was meant to try to mitigate host tracking and the recent draft 4941B is essentially meant to, as I said, to address some of the issues that have been found since then in 4941.
.
So, I will not cover or discuss 7217, but I will simply essentially report on what its implementation status that at times people wonder. There have been multiple independent implementations of 7217. The first one was in the Linux kernel many years ago. But there is also an implementation in network manager. There is also an implication in the DHCP CD package, and there is also an implementation in SLAAC CD in OpenBSD.
.
If I remember correctly, there is also a system D network D implementation of it.
.
If you wonder about operating systems support, essentially all of the recent versions of all of these operating systems ship with 7217 enabled by default.
.
So, you might argue that 7217 has already become mainstream.
.
So let's take a brief look at 4941, which is the one that has received attention lately.
.
So if you look at how 4941 works, essentially the RFC suggests that hosts should produce randomised tokens that are regenerated over time, okay. So, the idea that periodically, according to the 10 preferred lifetime that is specified in the RFC, these randomised tokens are regenerated. But, at any given point in time, if you need to generate a temporary address, you will use that randomised token, okay. So these randomised interface identifiers are only regenerated on a time basis and not on other, you know, on other conditions.
.
And another thing that is important is that these temporary addresses are generated in addition to the SLAAC stable addresses, whether that's 7217 or the original addresses that embed the underlying MAC address.
.
So what are the issues with 4941? So, the first issue has to do with the interface ID only changing on a periodical basis. So if you have a node that is roaming across networks, then at least the implementation that I have checked the node will configure addresses using the same interface ID if time allows, so that means that if the node has not had to regenerate that randomised token, then it will reuse the interface ID even if it connects to a different network and that of course is very good because that allows for host tracking and network activity correlation.
.
The other thing which is kind of related to this previous item is that the same interface ID is employed for all the temporary addresses that you configure at any begin point in time. So that means that your host joins a network and that network is a multi‑prefix network, that is employed multiple prefixes, whether that's ULA, multiple global prefixes whatever, the same interface ID will be employed, and that means, of course, that will allow for ‑‑ allow for correlation of network activity for addresses that belong to different prefixes.

The final one in that respect is that these interface identifiers are essentially generated periodically and that means that it's kind of like simple if there are a few, you know, a reduced number of nodes in a network, it's kind of like simple to essentially infer when a note has generated a new address, because you know the period at which those temporary addresses are generated.
.
Other things. If you look at the lifetime, default by lifetime was specified in 4941, it was a lifetime of one week, and that has two different implications.

The first one is that the valid lifetime has a could recall with the number of temporary nodes you have concurrently. So essentially if you divide the valid lifetime by the preferred lifetime you get the number of concurrent addresses that a node will use, and that means that, by default, a node will use about, you know, around 17 temporary addresses for each prefix, okay. So, that's probably like too much.
.
The other thing is that these addresses are supposed to be temporary, but if you think about it, having the address its around for a week is not really temporary. So that's a very long period of time.
.
And the final issue is that when you look at 4941, essentially the spec argues, or assumes that you are generating temporary addresses in addition to stable addresses.
.
Now for the general case, that's probably a good idea because you want to us auto the stable addresses for incoming connections and only use temporary addresses for like client like activities. Or, for example, if you know for some reason for some application you need a long lead connection, like an SSH session, you might want to do it with a stable address.
.
Now, if you have a kind of node, like you know, a mobile node, like, which is roaming and you don't expect this node to receive IP coming connections or to have long lead sessions, then it might make sense to ‑‑ for the node to only configure temporary addresses.
.
So, another change or an element of identification to 4941 was allow the use of Openflow ‑‑ or the configuration of only temporary addresses.
.
All of these issues are being addressed in Draft IETF 614961 BIS, all right, trying to address all these issues that I mentioned before.
.
Now when it comes to implementations. The document has not yet been published as an RFC but there are already some implementations around. A patch was committed to the Linux kernel in April 2020. So, eventually that will make it to, you know, to the popular distributions.
.
There is also a SLAAC D implementation in OpenBSD. They were doing most of the stuff that these draft describes, but the last bit was committed in March 2020. Essentially in March, they reduced the valid lifetime for the temporary addresses.
.
And last but not least, I produce a patch for the FreeBSD kernel. I submitted it in April 2020. But it has not yet been committed or reviewed. So, if there is a FreeBSD kernel developer around or if you know one, you might want to help and request if they can take a look at the patch.
.
Any questions?

RAYMOND JETTEN: There are some ‑‑ or at least one question at the moment. It's from Osama Barakat, he is from Siemens, and he asks: Does Windows 10 supports the latest IPv6 RFC or is it only Linux‑based OSs that support it?

FERNANDO GONT: So if he is asking about 7217, you could say it's a surprise because one of the authors of the spec worked for Microsoft. But networks they have not implemented 7217 yet. And they have not implemented the update of 4941 either. But in the case of 4941, okay. It has not been published as an RFC, so I'd be more let's say concerned about the support for 7217.

RAYMOND JETTEN: Okay. I hope that answers the question. I don't see any more questions in the row. And there is no one at the mic.
.
So, I'd like to thank you, Fernando, for this presentation, and you may have wondered where Jen is. She is not here at the moment, she is having her birthday party, and of course she says hello, and we cannot open the mic for everyone so we'll start singing her happy birthday song but we all know that we would actually do that.
.
So that this is then the end of the IPv6 Working Group session. Please remember to rate the talks and if you have any problems using your extra time you have because of Corona, do it to implement IPv6. Thank you.
.
(Coffee break)