IPv6 Maintenance (6man) Working Group F. Gont Internet-Draft SI6 Networks Updates: 4861, 4862, 8028, 8504 (if approved) 27 November 2024 Intended status: Standards Track Expires: 31 May 2025 Support for Multi-Router and Multi-Prefix IPv6 Networks draft-gont-6man-rfc8028-update-00 Abstract 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. Status of This Memo 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 Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. Gont Expires 31 May 2025 [Page 1] Internet-Draft Improving Support for Multi-Router and M November 2024 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Improving Support for Multi-Router and Multi-Prefix Networks . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Host Support for Multi-Router and Multi-Prefix IPv6 Networks . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Node Requirements . . . . . . . . . . . . . . . . . . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 7.2. Informative References . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction 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]. Gont Expires 31 May 2025 [Page 2] Internet-Draft Improving Support for Multi-Router and M November 2024 * 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. 2. Terminology 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. 3. Improving Support for Multi-Router and Multi-Prefix Networks 3.1. Host Support for Multi-Router and Multi-Prefix IPv6 Networks 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. This means that, for example, if two SLAAC routers advertise the same IPv6 prefix via PIOs, a host will maintain a (Prefix, remaining valid lifetime, remaining preferred lifetime) for each router. 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. Gont Expires 31 May 2025 [Page 3] Internet-Draft Improving Support for Multi-Router and M November 2024 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. 3.2. Node Requirements This document formally updates [RFC8504] as follows: Support for Multi-Router and Multi-Prefix Networks Nodes MUST Implement the recommendations specified in [this document]. 4. IANA Considerations This document has no actions for IANA. 5. Security Considerations 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. 6. Acknowledgments 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. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Gont Expires 31 May 2025 [Page 4] Internet-Draft Improving Support for Multi-Router and M November 2024 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, . [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, . [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by Hosts in a Multi-Prefix Network", RFC 8028, DOI 10.17487/RFC8028, November 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, January 2019, . 7.2. Informative References [draft-gont-v6ops-multi-ipv6-00] Gont, F. and G. Gont, "Problem Statement about IPv6 Support for Multiple Routers and Multiple Interfaces", IETF draft, November 2024, . [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, . [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, DOI 10.17487/RFC6105, February 2011, . [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, . Gont Expires 31 May 2025 [Page 5] Internet-Draft Improving Support for Multi-Router and M November 2024 [RFC7113] Gont, F., "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)", RFC 7113, DOI 10.17487/RFC7113, February 2014, . Author's Address Fernando Gont SI6 Networks Segurola y Habana 4310, 7mo Piso Villa Devoto Ciudad Autonoma de Buenos Aires Argentina Email: fgont@si6networks.com URI: https://www.si6networks.com Gont Expires 31 May 2025 [Page 6]