IPv6 Working Group
Thursday, 14 May 2020
1 p.m. (CEST)
RAYMOND JETTEN: Just a few more minutes. All right. It's one o'clock, CEST, welcome to the IPv6 Working Group, and we have some presentations for you, but first we have some other things for you.
Thirst of all, we're using Zoom, which means that you have questions for the presenters, you have to us auto the question and answer section. And once you do this, I would like you to always write your full name and your affiliation before your question, and I also hope your question is going to be rather short.
So, I don't have to read an Icelandic saga.
In the Zoom chat, you should select panelists and attendees, otherwise only the group chairs and the tech people from the RIPE NCC will see it.
And one reminder, the sessions are being recorded and will also be published. If you need live transcription, there is a link where you can see the live steno.
Then I would like to kindly remind you that there is a Code of Conduct, which we use, and I hope you will stick to it.
Then, actually, the first real point: The last meeting's minutes.
We have had them quite a while ago on the list, and we asked for comments, but we haven't heard anything from it. So, if you have any comments, you can either write them in the question and answer stuff, or well within a week, let's say, of the mailing list, so, we can, after that, conclude that are they are all accepted.
And then there is a request, which you all should use. You can actually win a prize for it. It's called rate the talks, or rate the presentations. Once you log into the RIPE website and you see the programme, you can also see the presentations, and next to them is a button where you can rate them. This information is used for us so we can actually check out what presentations you actually like and which you don't like, so we can adjust our programme next time.
So, let's start with the real stuff.
The first one we are going to have is by Wilhelm Boeddinghaus, and it's why it is so hard to implement IPv6. Once you share your screen, my screen sharing will be dumped. So, please feel free.
WILHELM BOEDDINGHAUS: Hello everyone. Can you hear me? Then I'll try to share my screen. I hope this works out.
RAYMOND JETTEN: Yes, we can see something.
WILHELM BOEDDINGHAUS: Now, I tried to get this into a real presentation. So you just see the main screen or anything else?
RAYMOND JETTEN: Yes, just the main presentation.
WILHELM BOEDDINGHAUS: So, thanks very much for joining the IPv6 Working Group, and coming for Fernando's and my presentation today. I want to talk about the topic why is it so hard to deploy IPv6? I have done a lot of IPv6 during the last years, my name is Wilhelm Boeddinghaus, I have started with IPv6 in 2008. I worked as a consultant and trainer for IPv6, so I have seen many IPv6 implementations, failed and successful.
My first RIPE meeting was in Berlin a few years ago and I live in Berlin, so it's a pity that we can't meet in person, but this should be possible next year. So you are all welcome. Berlin is a fantastic city.
Why is it so hard to deploy IPv6? There are a few reasons; a few lie in technology and a few lie in people. You can guess what's more complicated, technology or people? So we will see during the presentation.
We have IPv6 on our routers. I think this is mainly done. The router protocols are stable. Everything works fine. They have hop acceleration, so we are done there.
What about is it about firewalls? Sorry, what's on firewalls? And we have an example where we have still some difficulties on firewalls. I'm not going to mention them, but we had the example that the handling of the IPv6 type 3 time exceeded ICMP packet was not done correctly. Just as a reminder, we have a code 0, that means that your hop limit in the IPv6 header turns to 0 and then this packet is dropped and you get this information that your packet has been dropped. And the code 1 is the fragment reassembly timeout. If you don't get all fragments that you expect, then you drop the fragments and inform your sender. And then we experienced that you can configure on a firewall, on a manned line, both of these ICMP codes totally separately. So, code 1 and code 0 are totally different. But in the graphical user interface, code 1 was a subcode of code 10, which is not correct. So if you dropped code 0, code 1 was dropped as well. If you allow code 0, code 1 was allowed as well.
So, today we have wrong firewall rules. From all these administrators who use the graphical user interface. Can this be fixed? Yes, of course it will be fixed, the vendor was contacted and said they will fix it, where can you read about them? In the release notes? Who reads them? Everybody. So everybody who is doing GUI for this firewall vendor might have wrong firewall rules and this makes it very, very complicated to get IPv6 in a decent manner in our networks. If we still have complications like this.
What is it about switches? IPv6 and switches. The switches just pass IPv6 packets through. They just have IPv6 for the management interfaces, but still they play an important role in the IPv6 world.
So I asked the customer, name the switch vendors you use in your network. And I got the usual suspects. They have everyone, they have everyone, I hope I didn't forget anyone. More important. But, you see, the usual suspects were named. But they did not mention all the Linux switching, the bridges, the Linux bridges, the OvS switches, all the VMware switches. These switches are an integral part of your network. I have seen implementations where more than half of the switches used in the network are virtual switches. And the customers just forget about them. So how can you implement IPv6 in networks if you forget half of the switches? But there is a reason why they usually don't mention this Linux switches or this VMware switches. Because the server administrators configure these virtual switches. It's not the networking guys that do it, it is the server administrators. And why? Because they still think in metal boxes. Even if we virtualise, they think in metal boxes. My box is my responsibility. There is no split in responsibility between the hypervisor where the virtual machines run in the network and the underlying network in the virtual environment and this is not a technical issue.
So here, we come from the technical to the people part, where it gets complicated.
So you have to ask the server administrators for, let's say, IPv6 first hop security, maybe you want to have a consistent spending sign in your network and you want to include the virtual switches in your spanning tree. Maybe it's not a good idea to have spanning tree at all but you might have the wish to do so. We want to have VLAN access‑lists. We want to filter on ether type, maybe. We want to monitor per port, how many IPv4 and IPv6 packets run through our network. We want to know the packet sizes and all this monitoring stuff. Maybe if we have virtual routers running in this environment we want even NetFlow data.
So go to the server administrators and tell them you want to have these features, because they are an integral part of the IPv6 deployment. And you usually get two answers:
One is, we don't have the features. The other is we don't have the ‑‑ an idea how to configure this.
So, this cannot be configured for IPv6.
More about people. Why it is so hard to implement IPv6 and technology is usually quite easy. I met some people who want to innovate and others want to keep the status quo. This has nothing to do with the age of the people; I have met 35‑year‑old administrators who told me let's wait now 30 years and then you can implement IPv6. Someone to innovate, even if they are older, they say, well, this is the last project I'm doing in this company before I leave the company at the age of 65. So let's do something innovative.
Someone to learn, some already know everything and these guys are the most difficult and the most dangerous. They know everything. This makes it hard.
You have got little, sometimes large kingdoms in large organisations. If you think of this large in this industrial plans, you have many split up organisations and all of them have a king. And everything that's new is dangerous to kings. So you have to convince them that you need IPv6 in the networks, that it is not a threat, that it is a possibility. That they can show their knowledge in the whole organisation if they implement something so new as IPv6. It's 22 years old, isn't it?
And sometimes you just get the answer: No, you're not going to implement IPv6 in my network and if you don't believe me, ask Benedikt, he experienced this a few weeks ago in a project where he wanted to implement IPv6 and they just said no. This is not a technical problem, is it?
So, we have the good guys. And the good guys want to start IPv6. They try to innovate. They want IPv6 in their organisation in their network, they go to everyone, not just the networking organisation, they go to the server guys, to the software developers and tell them we want to start with IPv6. But where can they start?
They try to find documentation on the Internet. Somewhere on Google, they ask for documentation and they find good documentation, but old documentation.
We have got this very good document, RIPE 554, but it is eight years old. The customer of mine started with filtering ‑‑ building ICMP filters based on a 13‑year‑old document. So all new ICMP types have not been included in this filtering document. So they cannot write rules for this newer ICMP types that have been invented since the last 13 years.
So, what can we do? As a community, we can try to write new documents and I know we all have a daytime job and we all have to earn money. So it goes away from our free time. And there have been initiatives to have a newer version of the RIPE 554, and there have been attempts to have a newer version of this RFC for filtering ICMP traffic, but they have not made it yet to a new publication.
But the customers, the administrators have no idea where to start. They need this documentation. So maybe we should try to work on this again, and I offer my help there.
I have put together a list of IPv6 RFCs ‑‑ you have the link down here ‑‑ to make sure that if you find an RFC that you get a hint whether it is obsoleted, whether it is updated so that you at least get the newest documentation. So, give it a try. It's still not better, but give it a try, maybe it is useful for the community.
Management is sometimes problematic as well. We all know ‑‑ we know that the standard 7 layers and when we say we have an 8th layer is the administrators and the 9th layer is management. I feel that it's always quite difficult if I come into a project and the project says implement dual stack. This means I have no IPv6 only networks, because as soon as I mention IPv6 only networks, they tell me: Hey, sorry, this is out of scope. We don't get any new network design. There have been many talks at the RIPE meetings about mike segmentation. Benedikt and I did one in Dubai. Benedikt did one about many large ‑‑ many small networks a few RIPE meetings before that. And if you implement dual stack, you have double lock files, firewall rules, monitoring, everything has to be done twice. And this means a small evolution and not the revolution we need, and it is just costs. From the viewpoint of an enterprise, this is just cost. You don't gain anything. You have double work and you don't earn any additional money. You don't gain any security. You even make your networks more insecure if you put IPv6 in your IPv4 networks that you run today.
So, just by having the wrong project title, you run into problems in your IPv6 implementation. And then it is hard to implement IPv6 in your networks.
So, if you ‑‑ if we sum up.
When you experience old documents, little kingdoms, and large kings, the wrong project title and that means the wrong project scope, the wrong people doing networking, because the system administrators are very good in running their operating systems and running their applications, but they have ‑‑ many of them have no idea how to run a network, so it is very difficult to get a decent network design from them.
And then we have still vendors who have not implemented IPv6 correctly. Then ‑‑ what then? Then it feels like a wall. And we have to push through this wall somehow. But I think there is also good news. You know I'm in Berlin and no walls are forever. All walls falling at sometime. So, there is hope for IPv6.
Thanks for listening. Thanks for your attention. And now I think we have a few minutes if you have questions. So please go on.
RAYMOND JETTEN: Okay. There is a question from Chris Conway, asking that "What is your experience with using IPv6 with microtech?"
WILHELM BOEDDINGHAUS: I have no experience at all, sorry.
RAYMOND JETTEN: Well, okay.
WILHELM BOEDDINGHAUS: I have never used Microtech. I just try to get the chat somewhere, because I still have the screen sharing on.
RAYMOND JETTEN: You can find it on the top of the screen .
WILHELM BOEDDINGHAUS: Oh microtech still has, I see, problems with IPv6 and OSPF. Yeah, this is not good news. They should have fixed it and there are implementations where they can learn from, I think. If you look at free range routing or other Linux.
RAYMOND JETTEN: Okay. There is one more.
Aleksi Suhonen from TREX Regional Exchange is: "Why exactly would the lock files be doubled?
WILHELM BOEDDINGHAUS: Maybe not the lock files but the lock file entries, because if you have firewall rules say for HTTPS, IPv4 and IPv6, you get lock file rules with both protocols and it's harder to read them, to evaluate them and to find attacks, because the attacks could be mixed between IPv6 and IPv4, and then it's harder to read.
But, yeah, maybe you don't get do you believe firewall rules but you get more lock file entries, but you have double firewall rules because you have to do everything twice. If you run everything on dual stack. Of course if you run the web servers on IPv6 only you don't have IPv4 rules for that service at all.
RAYMOND JETTEN: Okay. Then not really a question but much more of a statement by Jordi Palet Martinez, saying: "Microtech is the worst vendor for IPv6. They only do dual stack and they use the wrong naming for protocols etc. He has even tried to help Microtech for free and they never replied.
WILHELM BOEDDINGHAUS: I have seen one comment that this was not new content. We had the same ten years ago. It's a pity that we still have to talk about it. Technology is getting better, even if a vendor like Microtech still has problems to solve, but we still have these attitude in the organisations that we don't need IPv6, that it's extra work, that we don't gain any benefits from it. So we have to work on this, and we have to make it a little bit easier for the administrators to find a starting point, and this might be have more actual documentation.
RAYMOND JETTEN: Then a question from Maximilian Whilhelm: "What is your solution for servers which might need access to v4 services to provide its service? With dual stack it won't work, with v6 only it's a problem."
WILHELM BOEDDINGHAUS: I think we have to implement dual stack in certain areas where we need both in parallel. But as long as you insist on dual stack everywhere, you don't get any benefits from a new network design.
We are not in a religious war here, so if you need dual stack, do it. But if you name your project dual stack, you can't do IPv6 only, and I have experienced this myself I said hey, we have to do IPv6 only in this network. No it is out of scope. We have to do both.
And this makes it very, very complicated to get the benefits from IPv6 where we have the smaller networks and a new network design. So they just want to put IPv6 in their old network design, this old network design is totally insecure and then you put IPv6 on top of it, that doesn't make it better.
RAYMOND JETTEN: We have some more questions yet. Here is one from Christian Bretterhofer, Enterprise user: "Can we compile a list with working IPv6‑only equipment?"
WILHELM BOEDDINGHAUS: Yeah. Maybe we could do so.
RAYMOND JETTEN: Okay.
WILHELM BOEDDINGHAUS: Why not? Sometimes we have equipment that runs IPv6 but still needs some IPv4 because it is not IPv6 only. Maybe the management interface doesn't work on IPv6. So, who would start, Christian? Would you start to do this list?
RAYMOND JETTEN: We don't know.
WILHELM BOEDDINGHAUS: I'll ask Christian myself.
RAYMOND JETTEN: Good. I'm going to close the question and answer section. I'll take no more new questions. The ones who are there I'll try to handle.
WILHELM BOEDDINGHAUS: Thanks for listening and ‑‑
RAYMOND JETTEN: No, no, no, you can't go yet.
A question: "Is there really no option in certain areas to agree on end of life dates for IPv4? Like for mass volume streaming and work on a common trace out plan?"
WILHELM BOEDDINGHAUS: I think there have been plans on finding an end date. I think there even was a sunset v4 Working Group at the IETF that is not active any more, as far as I know. I don't think that we get to an end date like this. Because we have commercial interests. And I suppose if companies like Facebook or Google lose even half of a percent of their users ‑‑ (sound gone).
RAYMOND JETTEN: Then the second‑last question from Nikolas Geyer:
"Any tips to get developers on board to develop IPv6‑enabled apps. It's not uncommon for the companies to exclude IPv6 from ‑ viable product as it is too hard."
BENEDIKT STOCKEBRAND: I'm not sure if just me but a general problem. But apparently William's connection got stuck or frozen.
RAYMOND JETTEN: All right. I think we are running out of time as well. So, sorry, there is a few questions that could not be answered at the moment. I'll try to put them later on the list and see if other people can answer them or even Whilhelm himself. I think it's time for our next presenter, and it's Fernando Gont: IPv6 SLAAC and renumbering events.
FERNANDO GONT: You can see the full slide, right?
RAYMOND JETTEN: Not yet. But you have to share your screen, I think.
FERNANDO GONT: It is sharing.
STENOGRAPHER: We can see it, it's okay.
FERNANDO GONT: I am trying again. It says here that the other presenter is sharing his screen. And I am supposed to be able to override that, but I don't know if it's working. Is it working now? It says it's working.
So, good morning or afternoon or night. My name is Fernando Gont and I will be doing this presentation about IPv6 SLAAC and renumbering events. Ironically, I was always meaning to join the RIPE meetings and this is the first time that I join remotely, but glad in a way.
So, let's start.
This is a presentation about the effect of renumbering events on SLAAC. Essentially, when you have a renumbering event, the local prefixes may change from one moment to another. In theory, that is supposed to be done in a graceful way with all prefixes being phased out and the new prefixes being introduced, but in many different scenarios, it just happened ‑‑ this just happened to change from one moment to another.
It's often the case that nodes are unaware about the network configuration information that becomes stale. And the result of that is that you may end up in a network where hosts end up using both stale prefixes and new prefixes.
This slide contains just two different possible scenarios. There are many of them. The one on the left‑hand side, is the typical IPv6 deployment scenario at home, where you have a CPU router that is doing the DHCP prefix delegation and ASAC on that side. And, for example, you consider the case where the CPU writer might crash and reboot. If the ISP were to list a different prefix than the previous one to the CPU router, it could easily be the case that the CPU router gets the new prefix and starts advertising the new prefix, or sub‑prefixes of that on the local network without knowing that the prefix has actually changed.
So the nodes on the local network end up configuring addresses for the new prefix but still keep the addresses for the old one. So, this is the same router that crashes, reboots and just is advertising new information and forgetting about the previous one.
Then on the right‑hand side you have ‑‑ like, I try to illustrate a different scenario in which a host is moved from one point of the network to a different point of the network. So it was receiving the first prefix, prefix 1 in the first port of at that. . Then it's moved to a different point of the network but without a link down and up event. So, it doesn't discard the configuration that it had before. So we end up in the same kind of scenario, so the node ends up with an old prefix and a new prefix. The only thing that may have changed here is that, in this case, since the node was moved from one point of the network to another, the first router kind of just disappeared. So the first node ‑‑ the first router disappeared. You don't continue receiving the same information and before I have a new router that starts advertising new information.
Obviously, this is problematic, because the end result is that you have costs using stale network configuration information, particularly prefixes.
So, essentially, there are a number of things that we can do to mitigate these problems.
The first mitigation is operational. Just avoid dynamic prefixes. That's what's recommended in RIPE document 690. And it's also discussed in an IETF draft that we author with Jan Zorz and Richard Patterson, that contains the problem statement and the operational mediation.
Then there are protocol‑based mitigation that is we are proposing, meaning that things that we can do, improvements that we can do to SLAAC, so that there is ‑‑ so that SLAAC can handle renumbering events more gracefully. This is discussed in Draft Gont 6 man SLAAC renum.
And finally, there are CPE‑based recommendations. Essentially a recommendation of how you could do things on the CPE device such that this issue can be mitigated. And these recommendations are specified in a different document. It's here.
I will go through the protocol base and the CPE‑based mitigations because obviously the operational ones just don't to dynamic prefixes.
So, when thinking about the protocol‑based mediations, both ‑‑ if you want to understand them but also when we were engineering them, you have to consider the different scenarios in which you may face this problem. One has to do whether you have the same router that continues operation, so same router has changed the information that it is advertising but it is the same device and in the other case it's just the previous router just disappeared. Now, in the case that you have ‑‑ these are essentially the two cases that I describe in the first slide.
So, same router that continues operation is the typical, you know, IPv6 home deployment. Whereas the one in the case where a router disappears can be the case where you move the system from one place to another point of the network.
Now, even in the case where the same router continues in operation, there are two possible cases. There are cases where the router might be aware that the information has changed. This could be the case if you have the router record on stable storage, the least prefixes. So when it crashes and reboots, and gets lists a new prefix, it can compare the new prefix with the one that it had stored. So it can tell if the information had changed. But in most cases, you know, they don't store the prefixes on stale storage. So when they come up, they have no knowledge about what was the previous prefix that was being advertised. So they are unaware if the information has changed or not.
There are all questions and other things to consider. For example, where would you apply changes? Like in the host side, on the router side? And, you know, what we are proposing is improvements in both of these parts.
But, what we think is that the most important part where you should do the improvements or the most important ones are the host side improvements. And why? Well, because if you do the host side improvements, then it doesn't matter, you know, the network that you attach to, but you will be able to deal with this renumbering events more gracefully. Otherwise you are somehow relying on the, for example, CPE routing being updated and that is probably not feasible. Okay.
So, first of the proposals that have to do with protocol‑based mitigations.
If you think about the current recommended default values for the PIO options, prefix information options, we have referred preferred lifetime of seven days and default valid lifetime of one month. These are values that are used for timers. And obviously the idea of a timer in a protocol is that you set a timer because it will go off in, you know, in a meaningful period of time. Obviously, setting a timer to seven days or one month will never go off in a meaningful time. You don't fix a problem in app month. It doesn't make any sense at all.
So, what we propose here is to, you know, change or have devices override the default value that they use for these two lifetimes, or these two timers, to set the preferred lifetime of the PIOs to the same value of the router lifetime. This is typically in the order of 35 minutes, 45 minutes, and to set the valid lifetime of the PIOs to a small multiple of that, it could be twice the router lifetime.
Now, again, this is overriding how you set these two parameters on the router side.
So, if you update the routers, then you'd be sending other ICMPs with these values, but of course what happens if you are attaching to a network where, you know, the routers have not been updated?
Well, you will be using the old and wrong values. What we propose essentially is to also cap the lifetimes on the host side. There are some deals behind this, so this is, let's say, the summarised version of it, but the idea is that no matter, you know, what's the value that you receive, the value that you end up using is of, at most, the router lifetime. So, if for example, you receive a PIO with a preferred lifetime of seven days, you use for the preferred lifetime, at most, the value that you receive in the router lifetime. So 45 seconds or the like.
Something similar for the valid lifetime. So what's the point of this is that now the timers are actually meaningful, because, you know, with the values currently in 4861 they will never go off. Now in the normal case, where things are working, you get the preferred timer, they always get refreshed, but if the guys advertising this, they go away, you don't get the RAs that are supposed to refresh this, and eventually these timers do go off, and you'll get rid of the stale information.
So, that's part of it.
Second one has to do with honouring small valid lifetimes. If you look at RFC 4861, essentially the spec prevents nodes from reducing the valid lifetime to anything smaller than two hours. So, if you get a PIO that claims a valid lifetime of 0, for example, you don't really use the valid lifetime to 0 but at most 2 hours. Now, the claim is that they implement this check for security reasons, okay. But from our point of view, you do first hop security or you don't. Because you have so many vectors in SLAAC that other carrier with will not care about this. They have others. Spoof, prefix information options, disable the routers, you know, so many. So addressing in this way on this particular one is not going to buy you anything, and as another carrier, I have so many others to use, so I don't care about this particular one.
So the proposal is, you know, just to have 4861, a low nodes to actually honour all, you know, valid lifetimes in a PIO, so if you have a router on the local network that positively knows that, you know, a prefix has become stale, so now you can advertise the prefix with a valid lifetime of 0 and you'll actually get rid of the prefix or the prefix which right now you can. But cannot actually get rid of it.
Then, the last one when it comes to protocol‑based mitigations, is the goal of trying to infer from a received RA that there is information that has changed. If you think about the case where you have the CPE router in a typical you know home deployment, it was advertised in some prefix, it crashes, reboots, gets a new prefix from the ISP and now starts advertising a new prefix. Okay. So what we try to do here is try from the received RAs, try to infer or try to find out if there is information that has become stale. And the logic is quite simple. If you have a router that was advertising prefixes, now it stops advertising the same router, stops advertising that prefix, and starts advertising a new one, then we consider that that's an indication that the previous prefix has become stale.
So, this is the simplified version of it. There are smaller details. But the idea is that if you receive an RA, it has PIOs, but it doesn't contain the previous PIO you consider that that previous PIO is stale. So what you do is, you reduce the prefix lifetime and the valid lifetime. The specific values, for example, for the preferred lifetime, we set it to were reduced to a few seconds to accommodate for the theoretical case where the information might be split into multiple RAs, for example. Okay.
Now, the idea of this is that now, based on the RA that you have received, you not only get the new prefix but you can also infer that the previous prefix that nobody is using any more has become stale and you can get rid of that and invalidate the addresses in a top layer.
In the case where you have multiple routers announcing the same prefix, of course what you do, you don't just disable or authenticate the prefix, you just disassociate the prefix with that particular router.
And just to highlight, I mean, it's implicit from the previous discussion, but prefixes only get implicated if you have old or new prefixes, okay. Because in order to you know, deprecate the prefix, you require that the same router is announcing older prefixes but not the previous one. For example, if you don't get RAs at all, you are not going to deprecate anything. In the draft, I didn't include it in this slide, but what we do is we separate the case ULAs and the regional addresses. So new ULAs deprecate ULAs but not old addresses but the same for global addresses, so they are separate.
So, that's it for the protocol‑based mitigations.
So now these are the CPE‑based mitigations, so these are mitigations how you should do things on the CPE.
First one, this is repeating recommendations from our specs. You know, the lifetimes. PIOs should never span the prefix delegation lifetimes. That's a hundred percent understandable.
Second one, is, you know, as discussed before, use smaller lifetimes for the prefixes that you are advertising, otherwise those prefixes are going to stick forever. So, same as before, you use the router lifetime for the preferred life and you use the valid life ‑‑ and you use, for example, a multiple of the router lifetime for the valid lifetime.
We have a number of other benefits. For example, it has been reported that, for mobile devices, when you get RAs that have changing values all the time, we would normally be the case, that's bad for the battery, but if you get RAs that always have the same values, you know, they deal with those with no problem.
Now, if you are using reduced values for the lifetimes that you advertise on the LAN side, since they are smaller than the prefix delegation lifetimes, you are always, when things are working okay most of the time, you are going to get RAs that are all the same all the time so you won't see them decreasing the lifetime values.
Third recommendation is to signal stale configuration information. And this is a two step process which might not always be possible. Which is have the CPE routers recorded prefixes that they are leased so that when, if they crash and remove, they can tell that the information has changed and they can advertise the old prefix to say deprecate them.
And the last one is to recommend CPEs devices not to do the DHCP release when rebooted.
So, we got to the end. I don't know if there are any questions or comments.
RAYMOND JETTEN: There is, of course, the first question the moment you try to think that there isn't.
"Reducing the valid LFD may end up in host W/O, any IPv6 prefix, so even local communication is impossible. In the case that the router disappears is only of concern when you have another one to switch to. Otherwise you are off until then the router becomes back. What is the more needed are routers which are able to do withdrawal prefixes no longer used." Someone's comment.
And I cannot take more questions because we are actually already out of time.
So do you have any comment on that comment?
FERNANDO GONT: For the case where we have the home deployment scenario, I mean, typically the router is the same device that you use as a switch, so typically the device is dead, most likely you won't be able to do much. That's one thing.
Second is that if you want addresses that are stable that don't need the prefixes to be, you know ‑‑ that the prefixes are not embedded on your connection with the ISP, well that's what you need ULAs for, whether you like them or not. But the point in which your addressing is exposed to global addresses, well, unless you have a provider addressing, well you are dependent on timers anyway.
RAYMOND JETTEN: Okay. So, that at this moment I think that we are done. There is no more questions. And it's time to thank you all. There were some 370, a bit more than that, participants, which is quite a lot. I'd like to thank every one of you, the presenters, co‑working chairs and the people from the RIPE NCC, and wish you a nice end of the day and stay healthy, please. Thank you.
(Coffee break)
