Support for Multi-Router and Multi-Prefix IPv6 Networks

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 . 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 . 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 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. 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. 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 formally updates as follows: Support for Multi-Router and Multi-Prefix Networks Nodes MUST Implement the recommendations specified in [this document].

This document has no actions for IANA.

This document does not introduce any new attack vectors to the ones associated with IPv8 Neighbor Discovery and IPv6 Stateless Address Autoconfiguration (SLAAC). If attacks based on forged RA packets are a concern, technologies such as RA-Guard 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.