(…and why this is a really bad idea these days 🙂 )
Imagine this scenario: you are sitting on the couch with your laptop open and all of a sudden there is a brief power outage. No big deal, a couple of your electronics will have to reboot and all is well.
However, if your CPE (modem/router) that connects your home to the Internet also reboots – you may have another problem. If you are connected to an ISP that implements IPv6 and is offering dual-stack connectivity to your home, interesting things might happen if your ISP did not configure IPv6 provisioning properly and decided to delegate IPv6 prefixes to your home in a dynamic way. So what are these interesting things?
If you are unlucky – your CPE reboots and your ISP delegates you a different IPv6 prefix than before, but because the CPE “hard reboot” it could not signal to your laptop/devices that the previous IPv6 prefix (and IPv6 address on your laptop that is from that prefix) is now gone and you can’t use it anymore.
To further add to the adventure, the majority of CPEs do not have persistent memory dedicated to storing your current IPv6 prefix in the case of a reboot. This means that there is no intelligence inside the CPE to inspect the new IPv6 prefix it has been assigned and deprecate the old prefix on your network. The CPE will instead just announce the new IPv6 prefix and your device is then free to choose an IPv6 address from the newly assigned prefix.
So what is the problem? The old IPv6 address is technically still valid and also a preferred address, so there is no reason why it should not still be used. This means that even though the old prefix is no longer routed to your home, you can still send packets with your old IPv6 address as a source all day long.
The result? Your IPv6 connectivity will break and connectivity will not be resolved until something on the device gets refreshed
How does an RFC affect this? The RFC 4861 suggests in Section 6.2.1 a very high value for the period of validity of advertised prefixes – one week for the preferred lifetime and one month(!) for the valid lifetime. In the event of abrupt renumbering, this is too long (see also section 2.2), because your computer could remain disconnected for a week – and this is not the agility that we are hoping for when internet connectivity is in question.
The end result is that in this realistic scenario: Your CPE reboots and can result in IPv6 not working anymore. The user in our scenario would initially see this as a service interruption if they were only running IPv6. If IPv4 ai also enabled on the CPE, the issue would probably mask the IPv6 connectivity interruption. For example – I am hosting many internet services on “IPv6 only” and would definitely notice when my IMAP email service stopped working, or that I can’t connect to hosts via ssh, and so on. So let’s see how we can actually resolve or prevent this issue from happening.
Of course – the oldie but goodie – rebooting your device or even restarting the network interface should clear the issue. The challenge here is determining that it is reasonable to tell the average user that is a normal use case and to deal with it? In an IPv6 only world, this is an outage from the eyes of the user, and in a dual-stack world, there will be things that “don’t work as they did” but in theory the connection should work. Either way – the likelihood of an ISP having to field a support call goes up.
What other ramifications are there other than support calls? Let’s share a few other examples from the ISP perspective that have much broader implications in this situation…
Content Providers: Many big content providers (with Google being one of them…) are measuring “IPv6 brokenness” and are reacting to those measurements in serving content. In short – if a user sends an IPv6 SYN packet to Google’s service (and that packet will arrive at Google due to default routes) and Google sends back an ACK packet that never reaches originating client (due to that fact Google never receives back an SYN ACK from a client) – Google will mark that ISP’s ASN as “broken IPv6” and will stop serving IPv6 traffic to that network and even stop serving AAAA records to their clients – for the entire ASN. That is a significant consequence and has significant implications for the quality of the user experience.
This problem was thoroughly described in our Best Current Operational Practice document RIPE-690 and the operational community agreed that this in fact is a problem and with the current state of IPv6 SLAAC specification and deployment: the best way to avoid this issue is to deploy IPv6 with the delegation of prefixes to end users that are as stable and static as possible.
However, due to many reasons and situations that can (and will) happen on the network – emergency situations where network topology needs to change and end-users might be renumbered – we decided that it was time to address this issue in a more direct fashion – with the IETF.
Our goal is to make SLAAC more robust and reactive to network topology changes, so Fernando Gont (SI6 Networks), Richard Patterson (SKY UK), and myself started a series of IETF internet-drafts that document the problem in a language that IETF understands. We also took the opportunity to propose some solutions to make this issue less evident while making the internet a happier place.
The first change is to lower the Valid Lifetime from 30 days to 90 minutes and Preferred Lifetime from 7 days to 45 minutes.
In this case, if flash renumbering happens – your laptop will be reconnected to the IPv6 world in less than (or equal to) 45 minutes, which is much better than a week as it is today.
We made this suggestion in a document that was published as IETF RFC (RFC8978) and we are very proud that we managed to navigate through all of the different interests and managed to get a consensus with the v6ops Working Group and later on with IESG – so this first document was published.
We are also working on a document with some CPE modification suggestions to mitigate the above issue and in a v6ops Working Group we have drafted “Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events” that is actually aimed to update the RFC4861 and RFC4862, known as “Neighbor Discovery for IP version 6 (IPv6)” and “IPv6 Stateless Address Autoconfiguration”.
So – if your ISP is changing the delegated IPv6 prefix to your CPE/router – please point them to RIPE-690 and RFC8978 and ask them to stop doing that. We are working on making SLAAC more robust, but as you may understand – it may be years before the proposed fix gets implemented on our computers in the real world. Until then – static IPv6 prefixes are the way to go!
Jan Žorž
6connect
P.S: There are a couple of ISPs that already made their CPE more robust and can afford to change prefixes for their end-users – but they know what they are doing and implemented all of the needed measures to mitigate the problem. For everyone else – the above suggestion applies 🙂
