Improving Support for Multi-Router, Multi-Interface, and Multi-Prefix Scenarios

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 4 September 2025.¶

Copyright Notice

Copyright (c) 2025 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.¶

Table of Contents

1. Introduction

IPv6 Stateless Address Autoconfiguration (SLAAC) is based on the premise that SLAAC routers advertise network configuration information on a local network, and SLAAC hosts aggregate this information and use it as they see fits. In the case of simple network scenarios such as a local network with a single SLAAC router, or a network with multiple SLAAC routers where all routers advertise the same network configuration information, SLAAC works just fine. However, other more complex (yet very common) scenarios are very badly supported (if at all supported). THese scenarios include, but are not limited to, the following:¶

• Two Customer Premises Equipment (CPE) routers are attached to a local network, whether to perform basic load-sharing across two upstream connctions, or for improved resiliency (i.e. provide a fall-back upstream Internet connection).¶

• An IPv6 host attaches to two different local networks via different network interfaces. For example, an IPv6 host employs a wired Ethernet connection and a Wi-Fi wireless connection, or a mobile node employs a 4G mobile connection, and also leverages WiFi connectivity where available.¶

As discussed in [I-D.gont-v6ops-multi-ipv6], these scenarios are not only common, but support for these scenarios may actually represent a pre-requisite for deploying IPv6 in an Enterprise or home office environemnt. Therefore, they warrant native and proper support by IPv6 hosts.¶

[RFC8028] discusses the challenge of selecting an appropriate default router in Multi-IPv6 scenarios, and specifies some recommendations for the selection of a next-hop router in multi-ipv6 scenarios. However, as noted in [I-D.gont-v6ops-multi-ipv6], there still exists specification gaps that prevent full support of multi-ipv6 scenarios. This document builds upon [RFC8028] to provide a more comprehensive solution to the problem at hand.¶

2. Terminology

Multi-prefix scenario:

A network scenario where a host employs two or more IPv6 prefixes for address configuration with SLAAC. This may be the result of attaching to two or more networks via two or more network interfaces, or simply the result of attaching to a single local network where multiple prefixes are advertised via one or more SLAAC routers.¶

Multi-router scenario:

A network scenario where a SLAAC hosts employs two or more SLAAC routers. This may be the result of attaching to two o more networks via two or more network interfaces, or simply the result of attaching to a single local network where multiple prefixes are advertised via one or more SLAAC routers.¶

Multi-interface scenario:

A network scenario where a host employs two or more network interfaces (without considering the "loopback" interface). Some bibliography refer to these hosts as being "multihomed". In the vast majority of cases, hosts employing multiple interfaces will result in "multi-prefix" and "multi-router" scenarios. In the specific corner case where a host attaches to the same network via two (or more) network interfaces, this will typically result in a multi-router scenario, where the same router that is available via multiple is interfaces is considered, fo all practical purposes, as a different router -- .e.g., the same router will result in different default routes, one via each of the network interfaces.¶

Multi-IPv6:

The term "Multi-IPv6" (case insensitive) is employed throughout this document as a short-hand for network scenarios where multiple IPv6 routers, multiple interfaces, and/or multiple IPv6 prefixes are employed. We note that "multi-prefix", "multi-interface", and "multi-router" scenarios are not mutually-exclusive: for instance, a host that employs multiple interfaces will usually also employ multiple prefixes and multiple routers.¶

SLAAC prefix set:

The SLAAC prefix set for an SLAAC router is composed of all prefixes that are being advertised by the router via SLAAC PIOs (irrespective of how e.g. the "A" and "L" flags of the PIO were set).¶

3. Conceptual model

In order to properly properly support multi-ipv6 scenarios, IPv6 hosts should adhere to the following principles:¶

• Network configuration information advertised by each SLAAC router is an atomic set of information that must be associated with the router that advertised it. This means that:¶

  • Hosts should maintain state for SLAAC information on a per-slaac-router basis (as opposed to a "per-host" or "per-interface" basis. If the same piece of information is advertised by multiple SLAAC routers, a SLAAC host must maintain state information for the advertised information on a per-router basis -- i.e., one record (with an associated timer, where applicable) for each advertising router.¶

  • As a result of this consideration, in scenarios where the same network configuration information is advertised by multiple local SLAAC routers, such information may eventually expire or be considered invalid for one of the SLAAC routers that advertised it, but may still be valid for some of the other routers that have advertised it (since state is maintained on a per-router basis as opposed to a per-host or per-interface basis).¶

  • IPv6 addresses configured from a given SLAAC prefix should only be employed with the SLAAC routers that have advertised such prefix on the local network. RDNSS should only be queried from SLAAC prefixes advertised by the same router that advertised the RDNSS, via the router that advertised such prefixes.¶

  • Hosts must not employ information advertised by one SLAAC in conjunction with information advertised by other SLAAC routers. For example, in a network scenario where SLAAC router ROUTER_A advertises {RDNSS_A, autoconfiguration prefix PREFIX_A} and SLAAC router ROUTER_B advertises {RDNSS_B, autoconfiguration prefix PREFIX_B}, SLAACs hosts should NOT do any of the following:¶

    • Send packets from PREFIX_A via ROUTER_B (or packets from PREFIX_B via ROUTER_A)¶

    • Send DNS queries from PREFIX_A to RDNSS_B (or queries from PREFIX_B to RDNSS_A)¶

    • Send packets from PREFIX_A to an IPv6 address obtained via RDNSS_B (or packets from PREFIX_B to an IPv6 address obtained via RDNSS_A)¶

• IPv6 addresses configured from a given SLAAC prefix should only be employed with the SLAAC routers that have advertised such prefix on the local network: it is quite common for IPv6 routers to enforce ingress/egress filtering, and thus in a scenario where SLAAC router ROUTER_A advertises {RDNSS_A, autoconfiguration prefix PREFIX_A} and SLAAC router ROUTER_B advertises {RDNSS_B, autoconfiguration prefix PREFIX_B}, ROUTER_A might drop outgoing packets (from the local network) that are not sourced from PREFIX_A, while ROUTER_B might drop outgoing packets that are not sourced from PREFIX_B.¶

• It is not uncommon for servers to enforce Access Control Lists (ACLs) based on the IPv6 address of incoming requests. Thus, as noted above, this means that:¶

  • In a scenario where SLAAC router ROUTER_A advertises {RDNSS_A, autoconfiguration prefix PREFIX_A} and SLAAC router ROUTER_B advertises {RDNSS_B, autoconfiguration prefix PREFIX_B}, RDNSS_A might drop DNS queries that do not originate from PREFIX_A, while RDNSS_B might drop DNS queries that do not originate from PREFIX_B.¶

  • Communications with addresses obtained via a RDNSS should be carried out using source addresses from the prefix-set of the router that advertised the RDNSS that was employed for DNS resoltion: In a scenario where SLAAC router ROUTER_A advertises {RDNSS_A, autoconfiguration prefix PREFIX_A} and SLAAC router ROUTER_B advertises {RDNSS_B, autoconfiguration prefix PREFIX_B}, RNDSS_A might resolve e.g. "www.example.com" to an IPv6 address that will drop incoming requests unless they originate from PREFIX_A, while RDNSS_B might resolve the same domain name ("www.example.com") to a different IPv6 address that will drop incoming requests unless they originate from PREFIX_B. In other scenarios, RDNSS_A might resolve a domain name to an IPv6 address that is topologically close to RDNSS_A. Thus, and address from PREFIX_B is employed to communicate with the corresponding address, this might result in suboptimal service (when compared to communicating with that address from PREFIX_A).¶

4. Protocol Specification

Appendix A. Sample scenarios

Author's Address