| Internet-Draft | Improving Support for Multi-Router and M | November 2024 |
| Gont | Expires 31 May 2025 | [Page] |
This document specifies IPv6 host behavior to improve their support for general and common multi-router and multi-prefix scenarios. It formally updates RFC 4861, RFC 4862, and RFC 8028 such that such scenarios are properly supported. This document also formally updates RFC 8504, thus requiring support for multi-router and multi-prefix scenarios in all IPv6 nodes.¶
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 31 May 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 Autoconfiguration (SLAAC) is based on the assumption that SLAAC routers will advertise configuration information on a local network, and SLAAC hosts will agregate this information and use it as they see fits. In simple network scenarios where there is a single local router, or where there are multiple routers but all routers advertise the same information (or where all advertised information is equivalent), SLAAC works just fine. However, more complex (yet very common) scenarios are currently not supported.¶
For example, in scenarios where a local network attaches to two different upstream Internet Service Providers (ISP):¶
A host may source packets from the IPv6 prefix of one ISP and incorrectly send them via the second ISP, with the corresponding traffic being dropped as a result of ingress-filtering [RFC2827].¶
A host may resolve DNS names using the recursive DNS server advertised by one ISP, but then use the second ISP for sending traffic to the corresponding IPv6 addresses, thus resulting in suboptimal service or packet drops.¶
These scenarios, along with other common scenarios, are discussed in detail in [draft-gont-v6ops-multi-ipv6-00]. This document pursues the necessary standards-track work to improve the support for such scenarios.¶
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.¶
SLAAC hosts SHOULD record which router (as identified by its IPv6 link-local address and the associated zone index) advertised each piece of SLAAC network configuration information.¶
For each piece of SLAAC network configuration, SLAAC hosts SHOULD maintain separate state for each SLAAC router that advertised each piecen of information.¶
If a piece of configuration information, as associated with a specific SLAAC router, becomes invalid SLAAC hosts SHOULD disassociate the information with the corresponding router. SLAAC hosts SHOULD NOT entirely discard the configuration information from the system unless it has become dissassociated (ie. invalid) for all routers that had advertised it.¶
Routing inforamation conveyed in SLAAC RIOs or Redirect messages SHOULD be associated with the router that advertised it,and SHOULD only be employed for IPv6 packets sourced from addresses in that router's prefix set.¶
Server-type information such as RDNSS SHOULD be associated with the router that advertised it,and SHOULD only be employed for IPv6 packets sourced from addresses in that router's prefix set.¶
This document has no actions for IANA.¶
This document does not introduce any new attack vectors to the ones associated with IPv8 Neighbor Discovery [RFC4861] and IPv6 Stateless Address Autoconfiguration (SLAAC).¶
If attacks based on forged RA packets are a concern, technologies such as RA-Guard [RFC6105] [RFC7113] should be deployed.¶
The authors would like to thank (in alphabetical order) Brian Carpenter for providing valuable comments on earlier versions of this document.¶
Fernando would also like to thank Brian Carpenter who, over the years, has answered many questions and provided valuable comments that has benefited his protocol-related work.¶