| Internet-Draft | gulla | November 2023 |
| Linkova | Expires 9 May 2024 | [Page] |
This document suggests that a link-local address used by a router as a source address for Router Advertisement packets is calculated as a function of prefixes listed in the Prefix Information Option of the Router Advertisement. The proposed approach, combined with the Rule 5.5 of the Default Source Address Selection algorithm (RFC6724) improves the robustness of the SLAAC by allowing the hosts to detect the IPv6 subnet changes much faster and select the correct source address.¶
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 9 May 2024.¶
Copyright (c) 2023 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) 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 [RFC9096] 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.¶
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.¶
To be added¶
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.¶
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 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 ([RFC4861]) 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.¶
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).¶
This document does not introduce any privacy considerations.¶
This memo does not introduce any requests to IANA.¶
Thanks to Lorenzo Colitti, Fernando Gont, Ole Troan, eric Vyncke for the discussions, the input and all contribution.¶