Default Address Selection for Internet Protocol version 6 (IPv6)
obsoleted by
- rfc-6724 — Default Address Selection for Internet Protocol Version 6 (IPv6)
Extracted elements (27)
Public addresses are preferred over temporary addresses by default (Rule 7) to avoid application failures caused by the short lifetime of temporary addresses or reverse-lookup failures. Implementations where privacy outweighs compatibility MAY reverse this default.
The candidate source address set for multicast destinations is restricted to the outgoing interface's link because currently-deployed multicast forwarding uses Reverse Path Forwarding (RPF) checks, which require source and destination to be on the same link.
The default policy table assigns 6to4 (2002::/16) addresses label 2 and v4-compatible (::/96) label 3, distinct from native IPv6 (label 1), so that the label-matching rules naturally pair 6to4 sources with 6to4 destinations and native sources with native destinations.
The specification assumes routing (outgoing interface selection) is done before source address selection. This separation allows implementations to use source address considerations only as a tiebreaker among otherwise equivalent routes, keeping routing and address selection loosely coupled.
Two separate algorithms (source and destination selection) share a common policy table context so that together they yield useful results, while still permitting implementations to use either algorithm independently via existing APIs like getaddrinfo() and connect().
IPv4-compatible, IPv4-mapped, IPv4-translatable, and 6to4 addresses containing embedded IPv4 addresses are all treated as having global scope for address selection purposes.
The destination address selection algorithm operates on both IPv6 and IPv4 addresses uniformly; IPv4 addresses should be represented as IPv4-mapped addresses when looking them up in the policy table.
All IPv6 nodes, including both hosts and routers, must implement default address selection as defined in this specification.
Anycast addresses, multicast addresses, and the unspecified address MUST NOT be included in a candidate source address set.
For multicast and link-local destination addresses, the set of candidate source addresses MUST only include addresses assigned to interfaces belonging to the same link as the outgoing interface.
For site-local destination addresses, the candidate source address set MUST only include addresses assigned to interfaces belonging to the same site as the outgoing interface.
If an application specifies a source address not in the candidate set, the network layer MUST treat this as an error; if the specified source address is in the candidate set, the network layer MUST respect that choice.
If an implementation is not configurable or has not been configured, it SHOULD operate according to the default policy table: ::1/128 precedence 50 label 0; ::/0 precedence 40 label 1; 2002::/16 precedence 30 label 2; ::/96 precedence 20 label 3; ::ffff:0:0/96 precedence 10 label 4.
Implementations MUST provide a mechanism allowing an application to reverse the default preference and prefer temporary addresses over public addresses (Rule 7), affecting only the invoking application.
IPv6 implementations SHOULD support configurable address selection via a mechanism at least as powerful as the policy tables defined here, allowing administrators to change default policies as experience is gained.
On IPv6-only nodes supporting SIIT, if the destination is an IPv4-mapped address the candidate set MUST contain only IPv4-translatable addresses; if the destination is not IPv4-mapped, the candidate set MUST NOT contain IPv4-translatable addresses.
Source address selection Rule 2 (prefer appropriate scope) MUST be implemented and given high priority because it can affect interoperability.
The selection rules specified in this document MUST NOT be construed to override an application or upper-layer's explicit choice of a legal destination or source address.
Well-behaved applications SHOULD iterate through the list of addresses returned from getaddrinfo() until they find a working address.
CommonPrefixLen(A, B) is defined as the length (0–128) of the longest common prefix of two addresses A and B, measured from the most significant (leftmost) bits.
IPv4 addresses are mapped to scopes as follows: 169.254/16 auto-configuration addresses get link-local scope; 10/8, 172.16/12, and 192.168/16 private addresses get site-local scope; 127/8 loopback addresses get link-local scope; all other IPv4 addresses get global scope.
The candidate source address set CandidateSource(D) for a destination D is the set of unicast addresses that could be used as a source; it is recommended to be the unicast addresses assigned to the outgoing interface, with routers optionally including addresses on forwarding interfaces.
The destination address selection algorithm sorts a mixed IPv4/IPv6 address list using ten ordered pair-wise rules: (1) avoid unusable, (2) prefer matching scope, (3) avoid deprecated source, (4) prefer home address source, (5) prefer matching label, (6) prefer higher precedence, (7) prefer native transport, (8) prefer smaller scope, (9) use longest matching prefix, (10) preserve original order.
The policy table is a longest-matching-prefix lookup structure that maps address prefixes to two values: Precedence(A), used to sort destination addresses, and Label(A), used to pair compatible source and destination prefixes. Entries may optionally include a zone index qualifier.
The source address selection algorithm applies eight ordered pair-wise comparison rules to the candidate set: (1) prefer same address, (2) prefer appropriate scope, (3) avoid deprecated, (4) prefer home addresses, (5) prefer outgoing interface, (6) prefer matching label, (7) prefer public over temporary, (8) use longest matching prefix.
Unicast scope is mapped to multicast scope for comparison purposes: unicast link-local maps to multicast link-local (0x2), unicast site-local maps to multicast site-local (0x5), and unicast global maps to multicast global (0xE).
Source address selection exposes a privacy risk: an unfriendly node can probe a target by sending requests to anycast or multicast addresses (or via upper-layer protocols that do not fix the reply source), causing the target to reveal its own addresses through its choice of source address for reply packets, enabling correlation of multiple addresses.