| Internet-Draft | gulla | October 2024 |
| Linkova | Expires 24 April 2025 | [Page] |
When an IPv6 prefix assigned to a link changes, hosts may not be explicitly notified about the change. Consequently, they may continue to use addresses which are not valid for that link. This leads to packet loss and service disruption. This document proposes a mechanism to mitigate this issue. Routers are advised to send Router Advertisements containing distinct Prefix Information Options (PIOs) from different link-local addresses. This, in conjunction with RFC6724 (Default Source Address Selection) Rule 5.5 and RFC8028 (first-hop selection requirements), enables hosts to detect prefix changes more rapidly and select the correct source address, thereby improving the robustness of SLAAC.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 24 April 2025.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
IPv6 Stateless Address AutoConfugration (SLAAC, [RFC4862] 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) received from 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 absence of an explicit signal the host would be using the outdated information until its lifetime expires. If the host selects a source IPv6 address from a prefix which is not assigned to the link anymore, packets might be dropped either due to anti-spoofing policies on the routers, or just because the return traffic can not reach the host. This leads to degraded user experience.¶
Multiple documents discuss the SLAAC so-called flash renumbering problem and proposed various improvements to the host and router behaviour (see [RFC9096] and [I-D.ietf-6man-slaac-renum]).¶
The problem of selecting "a correct" source address is not unique for flash renumbering scenarions. In multihomed (more specifically, multi-prefix multi-router) network, where different prefixes are advertized by different routers, a host need to choose both a first-hop router and a source address for a given packet. Rule 5.5 of the default source address selection algorithm [RFC6724] instructs hosts to prefer a source address from a prefix, advertized by the chosen first-hop router. Additionally, [RFC8028] requires hosts to select default routers for each prefix it is assigned an address in.¶
If, when the link is renumebered, the old and new prefixes are seen as advertized by two different routers, the renumbering scenario becomes a specific corner case of a multihoming: the host has addresses in multiple prefixes, advertized by different routers, and needs to select a correct address (one from a prefix which is currently assigned to the link). Therefore, the mechanisms (Rule 5.5 of the source address selection and ones proposed by [RFC8028]) can be used for both multihoming and flash renumering scenarios.¶
To ensure that during the renumbering each prefix is seen as advertized by a different first-hop router, this document suggests that routers sent Router Advertisements with different Prefix Information Options (PIOs) from different link-local addresses. That allows the hosts to select the source address from the prefix advertized by the reachable next-hop and recover from a renumbering or network segment change events much faster.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
DHCPv6-PD: DHCPv6 Prefix Delegation [RFC8415]; a mechanism to delegate IPv6 prefixes to clients.¶
Flash renumbering: a network renumbering event, when an old prefix, used to address hosts, becomes invalid and is replaced by a new prefix (or just removed, without any replacement). Before the flash renumbering only the old prefix provides connectivity, and after the flash renumbering only the new one can be used. In other words, there is no period of time when addresses from both prefixes provide connectivity. Examples of flash renumbering include, but are not limited to a change of prefix delegated via DHCPv6-PD, or removal of one prefix from the router configuration and replacing it with another. See [RFC8978] for more detailed discussion of various flash-renumbering scenarios.¶
LLA: Link-Local Address, Section 2.5.6 of [RFC4291].¶
PIO: Prefix Information Option, [RFC4861].¶
RA: Router Advertisement, [RFC4861].¶
SLAAC: IPv6 Stateless Address AutoConfugration, [RFC4862].¶
SLAAC host: a host which uses SLAAC to configure addresses.¶
SLAAC Router: a router which advertizes at least one prefix in a PIO with the A flag set to 1, so that prefix can be used for SLAAC.¶
There are multiple scenarios when an IPv6 subnet assigned to the link the host is connected to can change without any explicit signals received by hosts. When it happens, the hosts can end up with outdated IPv6 address configuration, which leads to broken connectivity and degraded user experience. In particular there are two common types of scenarios:¶
Flash renumbering of the link the host is connected to. The most common example is a CPE router receiving a new prefix via DHCPv6-PD, while not deprecating the old prefix. The hosts would be using addresses from both old and new prefixes until the prefix lifetime expires. [RFC8978] discusses flash renumbering scenarios in details.¶
While there are no changes in prefixes assigned to links, a host moves from one link to another without detecting the disconnect. For example, a host can be 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). Another example os a host roaming between two SSIDs with the same name but different IPv6 subnets.¶
In all those scenarios a host might move between IPv6 subnets 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 containing pref_a, forms IPv6 addresses from that prefix using SLAAC.¶
The host attachment changes from network A to network B or an IPv6 prefix configured on the network changes from pref_a to pref_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: even if the outgoing packets are not dropped by anti-spoofing filters,the return traffic wouldn’t be able to reach the host. So 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.¶
It should be noted that the Detecting Network Attachment algorithm defined in [RFC6059] relies on the combination of the link-layer address and the link-local IPv6 address of a router to be unique across links. However that assumption doesn't often hold. For example, network administrators prefer to configure the same, easy to remember link-local address (e.g. 'fe80::1') to router interfaces on different links. Some router implementations are known to use the virtual router MAC address to create the Modified Extended Unique Identifier (EUI)-64 identifiers for VRRPV3 virtual link-local addresses (violating Section 7.4 of [RFC5798]). As a result, all links with the same VRRP ID (and hence the same virtual router MAC address) would have the same virtual link-local address as well.¶
Rule 5.5 of the Default Source Address Selection ([RFC6724]) 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 will 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 prefix change also leads to the default router address change, then a host implementing Rule 5.5 could recover from the renumbering quickly, i.e.:¶
The host receives a Router Advertisement (RA, [RFC4861]) from the router (link-local address LLA_A) with a PIO containing pref_a, forms IPv6 addresses from that prefix using SLAAC.¶
An IPv6 prefix configured on the link changes from pref_a to pref_b. The host does not receive any explicit signal about the prefix change and does not clear stale IPv6 configuration from its interface.¶
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 attachment point. Neighbor Unreachability Detection ([RFC4861]) detects that the next-hop is no longer reachable, 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.¶
It should be noted that [RFC6724] does not require all implementations to support Rule 5.5, limiting the support to systems which track which router advertized which prefix. However [I-D.ietf-6man-rfc6724-update] elevates Rule 5.5 support to MUST for all systems.¶
As per [RFC8028], "A host SHOULD select default routers for each prefix it is assigned an address in. Routers that have advertised the prefix in their Router Advertisement message SHOULD be preferred over routers that do not advertise the prefix." If the host complies with [RFC8028], then the proposed mechanism would work even better, and would provide fast recovery from a renumbering event:¶
The host selects a default router with link-local address LLA_A for pref_a.¶
The prefix on the link changes from pref_a to pref_b.¶
When the host receives an RA from LLA_B, containing a PIO for pref_b, the host selects another default gateway, LLA_B.¶
Neighbor Unreachability Detection detects that LLA_A is not reachable, and removes it from the neighbor cache table, so the host can not use it as a default gateway anymore. The host switches to using LLA_B as a default gateway and, in accordance with Rule 5.5, starts using addresses from pref_b.¶
As per [RFC8028], "A host SHOULD select default routers for each prefix it is assigned an address in. Routers that have advertised the prefix in their Router Advertisement message SHOULD be preferred over routers that do not advertise the prefix.". If the host complies with [RFC8028], then the proposed mechanism would work even better, and would provide fast recovery from a renumbering event.¶
The host selects a default router (LLA_A) for pref_a.¶
When the host receives an RA from LLA_B, containing pref_b, the host selects another default gateway, LLA_B.¶
Neighbor Unreachability Detection detects that LLA_A is not reachable, and removes it from the neighbor cache table, so the host can not use it as a default gateway anymore. The host switches to LLA_B and, in accordance with Rule 5.5, starts using addresses from pref_b.¶
When the IPv6 subnet changes (either because the given link has been renumbered, or because the client has moved to another link), there are two factors contributing to the duration of the outage:¶
Without changes proposed in this document, a host might be using the outdated prefix for the duration of the PIO preferred lifetime. As per [RFC4861], the default value for preferred lifetime is 604800 secs (7 days). While [I-D.ietf-6man-slaac-renum] proposes to reduce that value to 14400 seconds (4 hours), it still much longer than any user would accept.¶
The solution proposed in this document allows hosts which implement Rule 5.5 of the source address selection ([RFC6724]) to stop using the outdated prefix much faster. The time required for the host to detect that the old prefix shouldn't be used for initiating new session is the time required for Neighbor Unreachability Detection (NUD, [RFC4861]) to remove an unreachable entry for the old link-local address of the default router. The default value would be (without taking randomisation factors into account): ReachableTime milliseconds (to move from REACHABLE to STALE) + DELAY_FIRST_PROBE_TIME + MAX_UNICAST_SOLICIT*RetransTimer = 30 seconds + 5 second + 3*1 = 38 seconds.¶
It is highly desirable to ensure that renumbering or any changes to the set of prefixes advertized in PIOs detected by hosts in timely manner. Therefore routers which support multiple link-local addresses per interface SHOULD support the following functionality:¶
Generating (using [RFC7217] algorithm but with Prefix set to the prefix in question) or allowing the administrator to configure a dedicated link-local address for each prefix in AdvPrefixList ([RFC4861]);¶
Sending a PIO for each prefix in a separate RA, using that dedicated link-local address as a source. When populating fields in each RA as per Section 6.2.3 of [RFC4861], AdvPrefixList is treated as containing one specific prefix only. The router SHOULD comply with [RFC4861] requirements when sending each of those RAs individually. In other words, it SHOULD behave as a number of independent virtual routers, each having its own link-local address and sending RAs with just one PIO.¶
Removing the prefix-specific link-local address from the interface when the corresponding prefix is no longer advertized in a PIO sent from that interface. The router SHOULD also follow recommendations from Section 6.2.8 of [RFC4861] to inform hosts of this change.¶
Prefix-specific link-local addresses functionality SHOULD be configurable. Routers supporting prefix-specific link-local addresses SHOULD enable it on an interface susceptible to flash renumbering, e.g., if AdvPrefixList contains prefixes obtained dynamically from DHCPv6-PD. In all other cases, prefix-specific link-local addresses SHOULD be disabled by default and MAY be enabled by the administrator.¶
As discussed in Section 6.2.8 of [RFC4861], using multiple link-local address for the same router on the same link may prevent hosts from processing ICMPv6 redirects sent by the router. Therefore, if a router has prefix-specific link-local addresses enabled on its interface, the router MUST select the correct source link-local address when sending ICMPv6 redirects on that interface. In particular, if the source address of the invoking packet belongs to a prefix advertized in a PIO on that interface, the router MUST use the link-local address specific to this prefix as a source address for the ICMPv6 redirects.¶
This document also modifies Section 6.2.8 of [RFC4861]:¶
===¶
OLD TEXT:¶
===¶
Using the link-local address to uniquely identify routers on the link has the benefit that the address a router is known by should not change when a site renumbers.¶
===¶
NEW TEXT:¶
===¶
Using the link-local address to uniquely identify routers on the link has the benefit that the address a router is known by should not change when a site renumbers and the renumbering event is explicitly signalled and properly propagated to all hosts. However, in case of flash renumbering without explicit signalling the router SHOULD be able change the link-local address of an interface following renumbering events, to help hosts detect prefix changes and update their configuration accordingly.¶
===¶
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 fe80::2001:db8:1:1 and fe80::2001:db8:2:2 as the link-local addresses for those interfaces. If the first-hop redundancy is provided by VRRPv3, there is no need to configure the static link-local interface addresses but the virtual link-local address SHOULD be configured instead.¶
In many cases it might be beneficial for a router to have a stable link-local address (e.g. if that address is advertized as a DNS server, or for management purposes. Router MAY generate subnet-specific link-local addresses in addition to a stable link-local address.¶
It should be noted that the proposed mechanism assumes that the router does not use the modified EUI-64 format for generating interface ID. As per Section 3 of [RFC8064], nodes SHOULD NOT use the modified EUI-64 format, and SHOULD use the algorithm defined in [RFC7217] instead.¶
[RFC8028] requires that "a host SHOULD select default routers for each prefix it is assigned an address in" and that "Routers that have advertised the prefix in their Router Advertisement message SHOULD be preferred over routers that do not advertise the prefix, regardless of Default Router Preference. ". However it should be noted that as per Section 6.3.6 of [RFC4861], the host can still select default routers even if the router is not reachable (its Neighbor Cache entry is INCOMPLETE). Selecting such router would be undersirable, as it would prevent eliminating unreachable nexthop and defeating the whole purpose of per-prefix link-local addresses. Therefore this document updates [RFC8028]¶
OLD TEXT:¶
=====¶
Routers that have advertised the prefix in their Router Advertisement message SHOULD be preferred over routers that do not advertise the prefix, regardless of Default Router Preference.¶
=====¶
NEW TEXT¶
=====¶
Routers that that are reachable or probably reachable (i.e., in any state other than INCOMPLETE) and have advertised the prefix in their Router Advertisement message SHOULD be preferred over routers that do not advertise the prefix, regardless of Default Router Preference.¶
=====¶
To be added.¶
This document does not introduce any privacy considerations.¶
This memo does not introduce any requests to IANA.¶
Thanks to Dale W. Carder, Brian Carpenter, Lorenzo Colitti, Fernando Gont, Alexandre Petrescu, Mark Smith, Ole Troan, Eduard Vasilenko, Eric Vyncke for the discussions, the input and all contribution.¶