Using Subnet-Specific Link-Local Addresses to Improve SLAAC Robustness

Introduction IPv6 Stateless Address AutoConfugration (SLAAC, provides IPv6 hosts with a mechanism to configure their IPv6 stack based on the information (such as an IPv6 prefix and the default router address) provided by the on-link routers. If that information changes (e.g. a prefix assigned to the link is changed), the routers need to explicitly invalidate the outdated information (e.g. by sending a Router Advertisement packet which deprecates the old prefix). In the absense of an explicit signal the host would be using the outdated information until its lifetime expires. Multiple documents discusses the SLAAC renumbering problem and proposed various improvements to the host and router behaviour (see and draft-ietf-6man-slaac-renum). This document recommends that the link-local address the router sends the router advertisement from should depend on the network prefix(es) assigned to the router interface. As a result, Router Advertisements containing different sets of PIOs are sent from different link-local addresses. That allows the hosts to select the source address from the prefix advertized by the reachable router. As a result the host would be able to recover from the renyumbering events much faster.

Subnet Change Scenarios There are multiple scenarions when an IPv6 subnet assigned to the link can change unexpectedly, leading to outdates and invalid IPv6 configuration on the host interface. For example:

A prefix delegated to a CPE router changes, and the router does not send RAs to the connected hosts, deprecating the old prefix. The hosts would be using addresses from both old and new prefixes until the prefix lifetime expires.
A host is connected to a wired port, and a VLAN (and the corresponding IPv6 subnet) changed. This often happens if the VLAN is configured as a result of 802.1x or MAC-based authentication, so the VLAN is provided by RADIUS. Some OSes do not correctly reset IPv6 stack when the wired interface 802.1x state changes from ‘unauthenticated’ to ‘authenticated’ (or vice versa).

In all those scenarions a host might move between networks without complete disconnection and without detecting the network change. As a result the following sequence of events may occur, leading to broken connectivity:

The host is connected to a network A, receives an RA from the router with a PIO containg pref_a, forms IPv6 addresses from that prefix using SLAAC.
The host attachment changes from network A to network B. The host doesn’t detect the network change and doesn’t clear the IPv6 stack.
The host receives an RA from the router with a new PIO for pref_b and forms new addresses from that prefix.
Now the host has two sets of IPv6 addresses - one from pref_a and one from pref_b. Addresses from pref_a are unusable - the return traffic wouldn’t be able to reach the host and outgoing traffic might be dropped by anti-spoofing filters. If the host selects an address from pref_a as a source address for outgoing communication (as per RFC6724 or by using any other custom algorithms), the traffic would be dropped, causing user-visible outages.

Default Address Selection Rule 5.5 and Renumbering Rule 5.5 of the Default Source Address Selection () requires the host to prefer addresses in a prefix advertised by the next-hop. It allows the multihomed host to select the source address correctly: when two routers advertize different prefixes, the host wull be sending packets with source address from a given prefix to the router the prefix was received from. In case of renumbering if both old and new prefixes are advertized by the same router (received from a router with the same link-local address), then Rule 5.5 doesn't help selecting the correct (working) source address. However if the subnet change also leads to the default router address change, then a host implementing Rule 5.5 could recover from the renumbering quickly:

The host is connected to a network A, receives an RA from the router (link-local address LLA_A) with a PIO containg pref_a, forms IPv6 addresses from that prefix using SLAAC.
The host attachment changes from network A to network B. The host doesn’t detect the network change and doesn’t clear the IPv6 stack.
The host receives an RA from the router (link-local address LLA_B) with a new PIO for pref_b and forms new addresses from that prefix.
Link-local address LLA_A is not reachable anymore, as the host changes the network attachement point. Neighbor Unreachability Detection () detects it and removes LLA_A from the list of default routers.
The host is using LLA_B as a next-hop for outgoing traffic, so addresses from the pref_b are selected, and addresses from pref_a are not used.

Generating Subnet-Specific Link-Local Addresses for Router Interfaces

The router SHOULD send router advertisement packets from a dedicated link-local address.
That dedicated link-local address SHOULD change if the set of prefixes advertized in the Router Advertisement changes. In other words, when the set of prefixes advertized on a given interface changes, the router SHOULD generate a new link-local address and use that address as a source address for Router Advertisements. The router SHOULD also send at least one router advertisement as soon as it generates a new link-local address.

Routers which act as DHCPv6-PD clients need to implement some algorith to generate the interface ID based on the set of prefixes advertised on a given interface. The exact algorithm is outside of scope of this document - it could be some form of hashing function which consumes a list of network prefixes and generates a 64-bits interface ID. At the same time if the interface subnets are configured statically, the network administrator can configure link-local addresses statically as well. In some cases it might be possible to just utilize the global subnet prefix as an interface ID. For example, if the router has two interfaces configured with 2001:db8:1:1::/64 and 2001:db8:2:2::/64 subnets respectively, it is sufficient to configure f80::2001:db8:1:1 and fe80::2001:db8:2:2 as the link-local addresses for those interfaces (if VRRPv3 is used to provide the first-hop router redundancy, the virtual link-local address shall be configured instead).