From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6724.txt | 1795 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1795 insertions(+) create mode 100644 doc/rfc/rfc6724.txt (limited to 'doc/rfc/rfc6724.txt') diff --git a/doc/rfc/rfc6724.txt b/doc/rfc/rfc6724.txt new file mode 100644 index 0000000..4325b3d --- /dev/null +++ b/doc/rfc/rfc6724.txt @@ -0,0 +1,1795 @@ + + + + + + +Internet Engineering Task Force (IETF) D. Thaler, Ed. +Request for Comments: 6724 Microsoft +Obsoletes: 3484 R. Draves +Category: Standards Track Microsoft Research +ISSN: 2070-1721 A. Matsumoto + NTT + T. Chown + University of Southampton + September 2012 + + + Default Address Selection for Internet Protocol Version 6 (IPv6) + +Abstract + + This document describes two algorithms, one for source address + selection and one for destination address selection. The algorithms + specify default behavior for all Internet Protocol version 6 (IPv6) + implementations. They do not override choices made by applications + or upper-layer protocols, nor do they preclude the development of + more advanced mechanisms for address selection. The two algorithms + share a common context, including an optional mechanism for allowing + administrators to provide policy that can override the default + behavior. In dual-stack implementations, the destination address + selection algorithm can consider both IPv4 and IPv6 addresses -- + depending on the available source addresses, the algorithm might + prefer IPv6 addresses over IPv4 addresses, or vice versa. + + Default address selection as defined in this specification applies to + all IPv6 nodes, including both hosts and routers. This document + obsoletes RFC 3484. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6724. + + + + + + +Thaler, et al. Standards Track [Page 1] + +RFC 6724 Default Address Selection for IPv6 September 2012 + + +Copyright Notice + + Copyright (c) 2012 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 + (http://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 Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Conventions Used in This Document ..........................4 + 2. Context in Which the Algorithms Operate .........................4 + 2.1. Policy Table ...............................................6 + 2.2. Common Prefix Length .......................................7 + 3. Address Properties ..............................................7 + 3.1. Scope Comparisons ..........................................8 + 3.2. IPv4 Addresses and IPv4-Mapped Addresses ...................8 + 3.3. Other IPv6 Addresses with Embedded IPv4 Addresses ..........9 + 3.4. IPv6 Loopback Address and Other Format Prefixes ............9 + 3.5. Mobility Addresses .........................................9 + 4. Candidate Source Addresses .....................................10 + 5. Source Address Selection .......................................11 + 6. Destination Address Selection ..................................14 + 7. Interactions with Routing ......................................16 + 8. Implementation Considerations ..................................16 + 9. Security Considerations ........................................17 + 10. Examples ......................................................18 + 10.1. Default Source Address Selection .........................18 + 10.2. Default Destination Address Selection ....................19 + 10.3. Configuring Preference for IPv6 or IPv4 ..................20 + 10.3.1. Handling Broken IPv6 ..............................21 + 10.4. Configuring Preference for Link-Local Addresses ..........21 + 10.5. Configuring a Multi-Homed Site ...........................22 + 10.6. Configuring ULA Preference ...............................24 + 10.7. Configuring 6to4 Preference ..............................25 + 11. References ....................................................26 + 11.1. Normative References .....................................26 + 11.2. Informative References ...................................27 + Appendix A. Acknowledgements .....................................29 + Appendix B. Changes since RFC 3484 ...............................29 + + + +Thaler, et al. Standards Track [Page 2] + +RFC 6724 Default Address Selection for IPv6 September 2012 + + +1. Introduction + + The IPv6 addressing architecture [RFC4291] allows multiple unicast + addresses to be assigned to interfaces. These addresses might have + different reachability scopes (link-local, site-local, or global). + These addresses might also be "preferred" or "deprecated" [RFC4862]. + Privacy considerations have introduced the concepts of "public + addresses" and "temporary addresses" [RFC4941]. The mobility + architecture introduces "home addresses" and "care-of addresses" + [RFC6275]. In addition, multi-homing situations will result in more + addresses per node. For example, a node might have multiple + interfaces, some of them tunnels or virtual interfaces, or a site + might have multiple ISP attachments with a global prefix per ISP. + + The end result is that IPv6 implementations will very often be faced + with multiple possible source and destination addresses when + initiating communication. It is desirable to have default + algorithms, common across all implementations, for selecting source + and destination addresses so that developers and administrators can + reason about and predict the behavior of their systems. + + Furthermore, dual- or hybrid-stack implementations, which support + both IPv6 and IPv4, will very often need to choose between IPv6 and + IPv4 when initiating communication, for example, when DNS name + resolution yields both IPv6 and IPv4 addresses and the network + protocol stack has available both IPv6 and IPv4 source addresses. In + such cases, a simple policy to always prefer IPv6 or always prefer + IPv4 can produce poor behavior. As one example, suppose a DNS name + resolves to a global IPv6 address and a global IPv4 address. If the + node has assigned a global IPv6 address and a 169.254/16 auto- + configured IPv4 address [RFC3927], then IPv6 is the best choice for + communication. But if the node has assigned only a link-local IPv6 + address and a global IPv4 address, then IPv4 is the best choice for + communication. The destination address selection algorithm solves + this with a unified procedure for choosing among both IPv6 and IPv4 + addresses. + + The algorithms in this document are specified as a set of rules that + define a partial ordering on the set of addresses that are available + for use. In the case of source address selection, a node typically + has multiple addresses assigned to its interfaces, and the source + address ordering rules in Section 5 define which address is the + "best" one to use. In the case of destination address selection, the + DNS might return a set of addresses for a given name, and an + application needs to decide which one to use first and in what order + to try others if the first one is not reachable. The destination + address ordering rules in Section 6, when applied to the set of + addresses returned by the DNS, provide such a recommended ordering. + + + +Thaler, et al. Standards Track [Page 3] + +RFC 6724 Default Address Selection for IPv6 September 2012 + + + This document specifies source address selection and destination + address selection separately but uses a common context so that + together the two algorithms yield useful results. The algorithms + attempt to choose source and destination addresses of appropriate + scope and configuration status ("preferred" or "deprecated" in the + RFC 4862 sense). Furthermore, this document suggests a preferred + method, longest matching prefix, for choosing among otherwise + equivalent addresses in the absence of better information. + + This document also specifies policy hooks to allow administrative + override of the default behavior. For example, using these hooks, an + administrator can specify a preferred source prefix for use with a + destination prefix or prefer destination addresses with one prefix + over addresses with another prefix. These hooks give an + administrator flexibility in dealing with some multi-homing and + transition scenarios, but they are certainly not a panacea. + + 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. + +1.1. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 + [RFC2119]. + +2. Context in Which the Algorithms Operate + + Our context for address selection derives from the most common + implementation architecture, which separates the choice of + destination address from the choice of source address. Consequently, + we have two separate algorithms for these tasks. The algorithms are + designed to work well together, and they share a mechanism for + administrative policy override. + + In this implementation architecture, applications use APIs such as + getaddrinfo() [RFC3493] that return a list of addresses to the + application. This list might contain both IPv6 and IPv4 addresses + (sometimes represented as IPv4-mapped addresses). The application + then passes a destination address to the network stack with connect() + or sendto(). The application would then typically try the first + address in the list, looping over the list of addresses until it + finds a working address. In any case, the network layer is never in + a situation where it needs to choose a destination address from + several alternatives. The application might also specify a source + + + + +Thaler, et al. Standards Track [Page 4] + +RFC 6724 Default Address Selection for IPv6 September 2012 + + + address with bind(), but often the source address is left + unspecified. Therefore, the network layer does often choose a source + address from several alternatives. + + As a consequence, we intend that implementations of APIs such as + getaddrinfo() will use the destination address selection algorithm + specified here to sort the list of IPv6 and IPv4 addresses that they + return. Separately, the IPv6 network layer will use the source + address selection algorithm when an application or upper layer has + not specified a source address. Application of this specification to + source address selection in an IPv4 network layer might be possible, + but this is not explored further here. + + Well-behaved applications SHOULD NOT simply use the first address + returned from an API such as getaddrinfo() and then give up if it + fails. For many applications, it is appropriate to iterate through + the list of addresses returned from getaddrinfo() until a working + address is found. For other applications, it might be appropriate to + try multiple addresses in parallel (e.g., with some small delay in + between) and use the first one to succeed. + + Although source and destination address selection is most typically + done when initiating communication, a responder also must deal with + address selection. In many cases, this is trivially dealt with by an + application using the source address of a received packet as the + response destination and the destination address of the received + packet as the response source. Other cases, however, are handled + like an initiator, such as when the request is multicast and hence + source address selection must still occur when generating a response + or when the request includes a list of the initiator's addresses from + which to choose a destination. Finally, a third application scenario + is that of a listening application choosing on what local addresses + to listen. This third scenario is out of the scope of this document. + + The algorithms use several criteria in making their decisions. The + combined effect is to prefer destination/source address pairs for + which the two addresses are of equal scope or type, prefer smaller + scopes over larger scopes for the destination address, prefer non- + deprecated source addresses, avoid the use of transitional addresses + when native addresses are available, and all else being equal, prefer + address pairs having the longest possible common prefix. For source + address selection, temporary addresses [RFC4941] are preferred over + public addresses. In mobile situations [RFC6275], home addresses are + preferred over care-of addresses. If an address is simultaneously a + home address and a care-of address (indicating the mobile node is "at + home" for that address), then the home/care-of address is preferred + over addresses that are solely a home address or solely a care-of + address. + + + +Thaler, et al. Standards Track [Page 5] + +RFC 6724 Default Address Selection for IPv6 September 2012 + + + This specification optionally allows for the possibility of + administrative configuration of policy (e.g., via manual + configuration or a DHCP option such as that proposed in + [ADDR-SEL-OPT]) that can override the default behavior of the + algorithms. The policy override consists of the following set of + state, which SHOULD be configurable: + + o Policy Table (Section 2.1): a table that specifies precedence + values and preferred source prefixes for destination prefixes. + + o Automatic Row Additions flag (Section 2.1): a flag that specifies + whether the implementation is permitted to automatically add site- + specific rows for certain types of addresses. + + o Privacy Preference flag (Section 5): a flag that specifies whether + temporary source addresses or stable source addresses are + preferred by default when both types exist. + +2.1. Policy Table + + The policy table is a longest-matching-prefix lookup table, much like + a routing table. Given an address A, a lookup in the policy table + produces two values: a precedence value denoted Precedence(A) and a + classification or label denoted Label(A). + + The precedence value Precedence(A) is used for sorting destination + addresses. If Precedence(A) > Precedence(B), we say that address A + has higher precedence than address B, meaning that our algorithm will + prefer to sort destination address A before destination address B. + + The label value Label(A) allows for policies that prefer a particular + source address prefix for use with a destination address prefix. The + algorithms prefer to use a source address S with a destination + address D if Label(S) = Label(D). + + IPv6 implementations SHOULD support configurable address selection + via a mechanism at least as powerful as the policy tables defined + here. It is important that implementations provide a way to change + the default policies as more experience is gained. Sections 10.3 + through 10.7 provide examples of the kind of changes that might be + needed. + + If an implementation is not configurable or has not been configured, + then it SHOULD operate according to the algorithms specified here in + conjunction with the following default policy table: + + + + + + +Thaler, et al. Standards Track [Page 6] + +RFC 6724 Default Address Selection for IPv6 September 2012 + + + Prefix Precedence Label + ::1/128 50 0 + ::/0 40 1 + ::ffff:0:0/96 35 4 + 2002::/16 30 2 + 2001::/32 5 5 + fc00::/7 3 13 + ::/96 1 3 + fec0::/10 1 11 + 3ffe::/16 1 12 + + An implementation MAY automatically add additional site-specific rows + to the default table based on its configured addresses, such as for + Unique Local Addresses (ULAs) [RFC4193] and 6to4 [RFC3056] addresses, + for instance (see Sections 10.6 and 10.7 for examples). Any such + rows automatically added by the implementation as a result of address + acquisition MUST NOT override a row for the same prefix configured + via other means. That is, rows can be added but never updated + automatically. An implementation SHOULD provide a means (the + Automatic Row Additions flag) for an administrator to disable + automatic row additions. + + As will become apparent later, one effect of the default policy table + is to prefer using native source addresses with native destination + addresses, 6to4 source addresses with 6to4 destination addresses, + etc. Another effect of the default policy table is to prefer + communication using IPv6 addresses to communication using IPv4 + addresses, if matching source addresses are available. + + Policy table entries for address prefixes that are not of global + scope MAY be qualified with an optional zone index. If so, a prefix + table entry only matches against an address during a lookup if the + zone index also matches the address's zone index. + +2.2. Common Prefix Length + + We define the common prefix length CommonPrefixLen(S, D) of a source + address S and a destination address D as the length of the longest + prefix (looking at the most significant, or leftmost, bits) that the + two addresses have in common, up to the length of S's prefix (i.e., + the portion of the address not including the interface ID). For + example, CommonPrefixLen(fe80::1, fe80::2) is 64. + +3. Address Properties + + In the rules given in later sections, addresses of different types + (e.g., IPv4, IPv6, multicast, and unicast) are compared against each + other. Some of these address types have properties that aren't + + + +Thaler, et al. Standards Track [Page 7] + +RFC 6724 Default Address Selection for IPv6 September 2012 + + + directly comparable to each other. For example, IPv6 unicast + addresses can be "preferred" or "deprecated" [RFC4862], while IPv4 + addresses have no such notion. To compare such addresses using the + ordering rules (e.g., to use "preferred" addresses in preference to + "deprecated" addresses), the following mappings are defined. + +3.1. Scope Comparisons + + Multicast destination addresses have a 4-bit scope field that + controls the propagation of the multicast packet. The IPv6 + addressing architecture defines scope field values for interface- + local (0x1), link-local (0x2), admin-local (0x4), site-local (0x5), + organization-local (0x8), and global (0xE) scopes (Section 2.7 of + [RFC4291]). + + Use of the source address selection algorithm in the presence of + multicast destination addresses requires the comparison of a unicast + address scope with a multicast address scope. We map unicast link- + local to multicast link-local, unicast site-local to multicast site- + local, and unicast global scope to multicast global scope. For + example, unicast site-local is equal to multicast site-local, which + is smaller than multicast organization-local, which is smaller than + unicast global, which is equal to multicast global. (Note that IPv6 + site-local unicast addresses are deprecated [RFC4291]. However, some + existing implementations and deployments may still use these + addresses; they are therefore included in the procedures in this + specification. Also, note that ULAs are considered as global, not + site-local, scope but are handled via the prefix policy table as + discussed in Section 10.6.) + + We write Scope(A) to mean the scope of address A. For example, if A + is a link-local unicast address and B is a site-local multicast + address, then Scope(A) < Scope(B). + + This mapping implicitly conflates unicast site boundaries and + multicast site boundaries [RFC4007]. + +3.2. IPv4 Addresses and IPv4-Mapped Addresses + + The destination address selection algorithm operates on both IPv6 and + IPv4 addresses. For this purpose, IPv4 addresses MUST be represented + as IPv4-mapped addresses [RFC4291]. For example, to look up the + precedence or other attributes of an IPv4 address in the policy + table, look up the corresponding IPv4-mapped IPv6 address. + + IPv4 addresses are assigned scopes as follows. IPv4 auto- + configuration addresses [RFC3927], which have the prefix 169.254/16, + are assigned link-local scope. IPv4 loopback addresses (Section + + + +Thaler, et al. Standards Track [Page 8] + +RFC 6724 Default Address Selection for IPv6 September 2012 + + + 4.2.2.11 of [RFC1812]), which have the prefix 127/8, are assigned + link-local scope (analogously to the treatment of the IPv6 loopback + address (Section 4 of [RFC4007])). Other IPv4 addresses (including + IPv4 private addresses [RFC1918] and Shared Address Space addresses + [RFC6598]) are assigned global scope. + + IPv4 addresses MUST be treated as having "preferred" (in the RFC 4862 + sense) configuration status. + +3.3. Other IPv6 Addresses with Embedded IPv4 Addresses + + IPv4-compatible addresses [RFC4291], IPv4-mapped [RFC4291], IPv4- + converted [RFC6145], IPv4-translatable [RFC6145], and 6to4 addresses + [RFC3056] contain an embedded IPv4 address. For the purposes of this + document, these addresses MUST be treated as having global scope. + + IPv4-compatible, IPv4-mapped, and IPv4-converted addresses MUST be + treated as having "preferred" (in the RFC 4862 sense) configuration + status. + +3.4. IPv6 Loopback Address and Other Format Prefixes + + The loopback address MUST be treated as having link-local scope + (Section 4 of [RFC4007]) and "preferred" (in the RFC 4862 sense) + configuration status. + + NSAP addresses and other addresses with as-yet-undefined format + prefixes MUST be treated as having global scope and "preferred" (in + the RFC 4862) configuration status. Later standards might supersede + this treatment. + +3.5. Mobility Addresses + + Some nodes might support mobility using the concepts of home address + and care-of address (for example, see [RFC6275]). Conceptually, a + home address is an IP address assigned to a mobile node and used as + the permanent address of the mobile node. A care-of address is an IP + address associated with a mobile node while visiting a foreign link. + When a mobile node is on its home link, it might have an address that + is simultaneously a home address and a care-of address. + + For the purposes of this document, it is sufficient to know whether + one's own addresses are designated as home addresses or care-of + addresses. Whether an address ought to be designated a home address + or care-of address is outside the scope of this document. + + + + + + +Thaler, et al. Standards Track [Page 9] + +RFC 6724 Default Address Selection for IPv6 September 2012 + + +4. Candidate Source Addresses + + The source address selection algorithm uses the concept of a + "candidate set" of potential source addresses for a given destination + address. The candidate set is the set of all addresses that could be + used as a source address; the source address selection algorithm will + pick an address out of that set. We write CandidateSource(A) to + denote the candidate set for the address A. + + It is RECOMMENDED that the candidate source addresses be the set of + unicast addresses assigned to the interface that will be used to send + to the destination (the "outgoing" interface). On routers, the + candidate set MAY include unicast addresses assigned to any interface + that forwards packets, subject to the restrictions described below. + Implementations that wish to support the use of global source + addresses assigned to a loopback interface MUST behave as if the + loopback interface originates and forwards the packet. + + Discussion: The Neighbor Discovery Redirect mechanism [RFC4861] + requires that routers verify that the source address of a packet + identifies a neighbor before generating a Redirect, so it is + advantageous for hosts to choose source addresses assigned to the + outgoing interface. + + In some cases, the destination address might be qualified with a zone + index or other information that will constrain the candidate set. + + For all 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. + + Discussion: The restriction for multicast destination addresses is + necessary because currently deployed multicast forwarding + algorithms use Reverse Path Forwarding (RPF) checks. + + For site-local unicast destination addresses, the set of candidate + source addresses MUST only include addresses assigned to interfaces + belonging to the same site as the outgoing interface. + + In any case, multicast addresses and the unspecified address MUST NOT + be included in a candidate set. + + On IPv6-only nodes that support Stateless IP/ICMP Translation (SIIT) + [RFC6145], if the destination address is an IPv4-converted address, + then the candidate set MUST contain only IPv4-translatable addresses. + + + + + + +Thaler, et al. Standards Track [Page 10] + +RFC 6724 Default Address Selection for IPv6 September 2012 + + + If an application or upper layer specifies a source address, it may + affect the choice of outgoing interface. Regardless, if the + application or upper layer specifies a source address that is not in + the candidate set for the destination, then the network layer MUST + treat this as an error. If the application or upper layer specifies + a source address that is in the candidate set for the destination, + then the network layer MUST respect that choice. If the application + or upper layer does not specify a source address, then the network + layer uses the source address selection algorithm specified in the + next section. + +5. Source Address Selection + + The source address selection algorithm produces as output a single + source address for use with a given destination address. This + algorithm only applies to IPv6 destination addresses, not IPv4 + addresses. + + The algorithm is specified here in terms of a list of pair-wise + comparison rules that (for a given destination address D) imposes a + "greater than" ordering on the addresses in the candidate set + CandidateSource(D). The address at the front of the list after the + algorithm completes is the one the algorithm selects. + + Note that conceptually, a sort of the candidate set is being + performed, where a set of rules define the ordering among addresses. + But because the output of the algorithm is a single source address, + an implementation need not actually sort the set; it need only + identify the "maximum" value that ends up at the front of the sorted + list. + + The ordering of the addresses in the candidate set is defined by a + list of eight pair-wise comparison rules, with each rule placing a + "greater than", "less than", or "equal to" ordering on two source + addresses with respect to each other (and that rule). In the case + that a given rule produces a tie, i.e., provides an "equal to" result + for the two addresses, the remaining rules MUST be applied (in order) + to just those addresses that are tied to break the tie. Note that if + a rule produces a single clear "winner" (or set of "winners" in the + case of ties), those addresses not in the winning set can be + discarded from further consideration, with subsequent rules applied + only to the remaining addresses. If the eight rules fail to choose a + single address, the tiebreaker is implementation-specific. + + + + + + + + +Thaler, et al. Standards Track [Page 11] + +RFC 6724 Default Address Selection for IPv6 September 2012 + + + When comparing two addresses SA and SB from the candidate set, we say + "prefer SA" to mean that SA is "greater than" SB, and similarly, we + say "prefer SB" to mean that SA is "less than" SB. If neither is + stated to be preferred, this means that SA is "equal to" SB, and the + remaining rules apply as noted above. + + Rule 1: Prefer same address. + If SA = D, then prefer SA. Similarly, if SB = D, then prefer SB. + + Rule 2: Prefer appropriate scope. + If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB and + otherwise prefer SA. Similarly, if Scope(SB) < Scope(SA): If + Scope(SB) < Scope(D), then prefer SA and otherwise prefer SB. + + Discussion: This rule must be given high priority because it can + affect interoperability. + + Rule 3: Avoid deprecated addresses. + If one of the two source addresses is "preferred" and one of them is + "deprecated" (in the RFC 4862 sense), then prefer the one that is + "preferred". + + Rule 4: Prefer home addresses. + If SA is simultaneously a home address and care-of address and SB is + not, then prefer SA. Similarly, if SB is simultaneously a home + address and care-of address and SA is not, then prefer SB. If SA is + just a home address and SB is just a care-of address, then prefer SA. + Similarly, if SB is just a home address and SA is just a care-of + address, then prefer SB. + + Implementations supporting home addresses MUST provide a mechanism + allowing an application to reverse the sense of this preference and + prefer care-of addresses over home addresses (e.g., via appropriate + API extensions such as [RFC5014]). Use of the mechanism MUST only + affect the selection rules for the invoking application. + + Rule 5: Prefer outgoing interface. + If SA is assigned to the interface that will be used to send to D and + SB is assigned to a different interface, then prefer SA. Similarly, + if SB is assigned to the interface that will be used to send to D and + SA is assigned to a different interface, then prefer SB. + + Rule 5.5: Prefer addresses in a prefix advertised by the next-hop. + If SA or SA's prefix is assigned by the selected next-hop that will + be used to send to D and SB or SB's prefix is assigned by a different + next-hop, then prefer SA. Similarly, if SB or SB's prefix is + assigned by the next-hop that will be used to send to D and SA or + SA's prefix is assigned by a different next-hop, then prefer SB. + + + +Thaler, et al. Standards Track [Page 12] + +RFC 6724 Default Address Selection for IPv6 September 2012 + + + Discussion: An IPv6 implementation is not required to remember + which next-hops advertised which prefixes. The conceptual models + of IPv6 hosts in Section 5 of [RFC4861] and Section 3 of [RFC4191] + have no such requirement. Hence, Rule 5.5 is only applicable to + implementations that track this information. + + Rule 6: Prefer matching label. + If Label(SA) = Label(D) and Label(SB) <> Label(D), then prefer SA. + Similarly, if Label(SB) = Label(D) and Label(SA) <> Label(D), then + prefer SB. + + Rule 7: Prefer temporary addresses. + If SA is a temporary address and SB is a public address, then prefer + SA. Similarly, if SB is a temporary address and SA is a public + address, then prefer SB. + + Implementations MUST provide a mechanism allowing an application to + reverse the sense of this preference and prefer public addresses over + temporary addresses (e.g., via appropriate API extensions such as + [RFC5014]). Use of the mechanism MUST only affect the selection + rules for the invoking application. This default is intended to + address privacy concerns as discussed in [RFC4941] but introduces a + risk of applications potentially failing due to the relatively short + lifetime of temporary addresses or due to the possibility of the + reverse lookup of a temporary address either failing or returning a + randomized name. Implementations for which application compatibility + considerations outweigh these privacy concerns MAY reverse the sense + of this rule and by default prefer public addresses over temporary + addresses. There SHOULD be an administrative option (the Privacy + Preference flag) to change this preference, if the implementation + supports temporary addresses. If there is no such option, there MUST + be an administrative option to disable temporary addresses. + + Rule 8: Use longest matching prefix. + If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then prefer SA. + Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then + prefer SB. + + Rule 8 MAY be superseded if the implementation has other means of + choosing among source addresses. For example, if the implementation + somehow knows which source address will result in the "best" + communications performance. + + + + + + + + + +Thaler, et al. Standards Track [Page 13] + +RFC 6724 Default Address Selection for IPv6 September 2012 + + +6. Destination Address Selection + + The destination address selection algorithm takes a list of + destination addresses and sorts the addresses to produce a new list. + It is specified here in terms of the pair-wise comparison of + addresses DA and DB, where DA appears before DB in the original list. + + The algorithm sorts together both IPv6 and IPv4 addresses. To find + the attributes of an IPv4 address in the policy table, the IPv4 + address MUST be represented as an IPv4-mapped address. + + We write Source(D) to indicate the selected source address for a + destination D. For IPv6 addresses, the previous section specifies + the source address selection algorithm. Source address selection for + IPv4 addresses is not specified in this document. + + We say that Source(D) is undefined if there is no source address + available for destination D. For IPv6 addresses, this is only the + case if CandidateSource(D) is the empty set. + + The pair-wise comparison of destination addresses consists of ten + rules, which MUST be applied in order. If a rule determines a + result, then the remaining rules are not relevant and MUST be + ignored. Subsequent rules act as tiebreakers for earlier rules. See + the previous section for a lengthier description of how pair-wise + comparison tiebreaker rules can be used to sort a list. + + Rule 1: Avoid unusable destinations. + If DB is known to be unreachable or if Source(DB) is undefined, then + prefer DA. Similarly, if DA is known to be unreachable or if + Source(DA) is undefined, then prefer DB. + + Discussion: An implementation might know that a particular + destination is unreachable in several ways. For example, the + destination might be reached through a network interface that is + currently unplugged. For example, the implementation might retain + information from Neighbor Unreachability Detection [RFC4861] for + some period of time. In any case, the determination of + unreachability for the purposes of this rule is implementation- + dependent. + + Rule 2: Prefer matching scope. + If Scope(DA) = Scope(Source(DA)) and Scope(DB) <> Scope(Source(DB)), + then prefer DA. Similarly, if Scope(DA) <> Scope(Source(DA)) and + Scope(DB) = Scope(Source(DB)), then prefer DB. + + + + + + +Thaler, et al. Standards Track [Page 14] + +RFC 6724 Default Address Selection for IPv6 September 2012 + + + Rule 3: Avoid deprecated addresses. + If Source(DA) is deprecated and Source(DB) is not, then prefer DB. + Similarly, if Source(DA) is not deprecated and Source(DB) is + deprecated, then prefer DA. + + Rule 4: Prefer home addresses. + If Source(DA) is simultaneously a home address and care-of address + and Source(DB) is not, then prefer DA. Similarly, if Source(DB) is + simultaneously a home address and care-of address and Source(DA) is + not, then prefer DB. + + If Source(DA) is just a home address and Source(DB) is just a care-of + address, then prefer DA. Similarly, if Source(DA) is just a care-of + address and Source(DB) is just a home address, then prefer DB. + + Rule 5: Prefer matching label. + If Label(Source(DA)) = Label(DA) and Label(Source(DB)) <> Label(DB), + then prefer DA. Similarly, if Label(Source(DA)) <> Label(DA) and + Label(Source(DB)) = Label(DB), then prefer DB. + + Rule 6: Prefer higher precedence. + If Precedence(DA) > Precedence(DB), then prefer DA. Similarly, if + Precedence(DA) < Precedence(DB), then prefer DB. + + Rule 7: Prefer native transport. + If DA is reached via an encapsulating transition mechanism (e.g., + IPv6 in IPv4) and DB is not, then prefer DB. Similarly, if DB is + reached via encapsulation and DA is not, then prefer DA. + + Discussion: The IPv6 Rapid Deployment on IPv4 Infrastructures + (6rd) Protocol [RFC5969], the Intra-Site Automatic Tunnel + Addressing Protocol (ISATAP) [RFC5214], and configured tunnels + [RFC4213] are examples of encapsulating transition mechanisms for + which the destination address does not have a specific prefix and + hence can not be assigned a lower precedence in the policy table. + An implementation MAY generalize this rule by using a concept of + interface preference and giving virtual interfaces (like the IPv6- + in-IPv4 encapsulating interfaces) a lower preference than native + interfaces (like ethernet interfaces). + + Rule 8: Prefer smaller scope. + If Scope(DA) < Scope(DB), then prefer DA. Similarly, if Scope(DA) > + Scope(DB), then prefer DB. + + + + + + + + +Thaler, et al. Standards Track [Page 15] + +RFC 6724 Default Address Selection for IPv6 September 2012 + + + Rule 9: Use longest matching prefix. + When DA and DB belong to the same address family (both are IPv6 or + both are IPv4): If CommonPrefixLen(Source(DA), DA) > + CommonPrefixLen(Source(DB), DB), then prefer DA. Similarly, if + CommonPrefixLen(Source(DA), DA) < CommonPrefixLen(Source(DB), DB), + then prefer DB. + + Rule 10: Otherwise, leave the order unchanged. + If DA preceded DB in the original list, prefer DA. Otherwise, prefer + DB. + + Rules 9 and 10 MAY be superseded if the implementation has other + means of sorting destination addresses. For example, if the + implementation somehow knows which destination addresses will result + in the "best" communications performance. + +7. Interactions with Routing + + This specification of source address selection assumes that routing + (more precisely, selecting an outgoing interface on a node with + multiple interfaces) is done before source address selection. + However, implementations MAY use source address considerations as a + tiebreaker when choosing among otherwise equivalent routes. + + For example, suppose a node has interfaces on two different links, + with both links having a working default router. Both of the + interfaces have preferred (in the RFC 4862 sense) global addresses. + When sending to a global destination address, if there's no routing + reason to prefer one interface over the other, then an implementation + MAY preferentially choose the outgoing interface that will allow it + to use the source address that shares a longer common prefix with the + destination. + + Implementations that support Rule 5.5 of source address selection + (Section 5) also use the choice of router to influence the choice of + source address. For example, suppose a host is on a link with two + routers. One router is advertising a global prefix A and the other + router is advertising global prefix B. Then, when sending via the + first router, the host might prefer source addresses with prefix A + and when sending via the second router, prefer source addresses with + prefix B. + +8. Implementation Considerations + + The destination address selection algorithm needs information about + potential source addresses. One possible implementation strategy is + for getaddrinfo() to call down to the network layer with a list of + destination addresses, sort the list in the network layer with full + + + +Thaler, et al. Standards Track [Page 16] + +RFC 6724 Default Address Selection for IPv6 September 2012 + + + current knowledge of available source addresses, and return the + sorted list to getaddrinfo(). This is simple and gives the best + results, but it introduces the overhead of another system call. One + way to reduce this overhead is to cache the sorted address list in + the resolver, so that subsequent calls for the same name do not need + to re-sort the list. + + Another implementation strategy is to call down to the network layer + to retrieve source address information and then sort the list of + addresses directly in the context of getaddrinfo(). To reduce + overhead in this approach, the source address information can be + cached, amortizing the overhead of retrieving it across multiple + calls to getaddrinfo(). In this approach, the implementation might + not have knowledge of the outgoing interface for each destination, so + it MAY use a looser definition of the candidate set during + destination address ordering. + + In any case, if the implementation uses cached and possibly stale + information in its implementation of destination address selection or + if the ordering of a cached list of destination addresses is possibly + stale, then it MUST ensure that the destination address ordering + returned to the application is no more than one second out of date. + For example, an implementation might make a system call to check if + any routing table entries, source address assignments, or prefix + policy table entries that might affect these algorithms have changed. + Another strategy is to use an invalidation counter that is + incremented whenever any underlying state is changed. By caching the + current invalidation counter value with derived state and then later + comparing against the current value, the implementation could detect + if the derived state is potentially stale. + +9. Security Considerations + + This document has no direct impact on Internet infrastructure + security. + + Note that most source address selection algorithms, including the one + specified in this document, expose a potential privacy concern. An + unfriendly node can infer correlations among a target node's + addresses by probing the target node with request packets that force + the target host to choose its source address for the reply packets + (perhaps because the request packets are sent to an anycast or + multicast address or perhaps because the upper-layer protocol chosen + for the attack does not specify a particular source address for its + reply packets). By using different addresses for itself, the + unfriendly node can cause the target node to expose the target's own + addresses. The source address selection default preference for + temporary addresses helps mitigate this concern. + + + +Thaler, et al. Standards Track [Page 17] + +RFC 6724 Default Address Selection for IPv6 September 2012 + + + Similarly, most source and destination address selection algorithms, + including the one specified in this document, influence the choice of + network path taken (as do routing algorithms that are orthogonal to, + but used together with, such algorithms) and hence whether data might + be sent over a path or network that might be more or less trusted + than other paths or networks. Administrators should consider the + security impact of the rows they configure in the prefix policy + table, just as they should consider the security impact of the + interface metrics used in the routing algorithms. + + In addition, some address selection rules might be administratively + configurable. Care must be taken to make sure that all + administrative options are secured against illicit modification, or + else an attacker could redirect and/or block traffic. + +10. Examples + + This section contains a number of examples, first showing default + behavior and then demonstrating the utility of policy table + configuration. These examples are provided for illustrative + purposes; they are not to be construed as normative. + +10.1. Default Source Address Selection + + The source address selection rules, in conjunction with the default + policy table, produce the following behavior: + + Destination: 2001:db8:1::1 + Candidate Source Addresses: 2001:db8:3::1 or fe80::1 + Result: 2001:db8::1 (prefer appropriate scope) + + Destination: ff05::1 + Candidate Source Addresses: 2001:db8:3::1 or fe80::1 + Result: 2001:db8:3::1 (prefer appropriate scope) + + Destination: 2001:db8:1::1 + Candidate Source Addresses: 2001:db8:1::1 (deprecated) or + 2001:db8:2::1 + Result: 2001:db8:1::1 (prefer same address) + + Destination: fe80::1 + Candidate Source Addresses: fe80::2 (deprecated) or 2001:db8:1::1 + Result: fe80::2 (prefer appropriate scope) + + Destination: 2001:db8:1::1 + Candidate Source Addresses: 2001:db8:1::2 or 2001:db8:3::2 + Result: 2001:db8:1:::2 (longest matching prefix) + + + + +Thaler, et al. Standards Track [Page 18] + +RFC 6724 Default Address Selection for IPv6 September 2012 + + + Destination: 2001:db8:1::1 + Candidate Source Addresses: 2001:db8:1::2 (care-of address) or 2001: + db8:3::2 (home address) + Result: 2001:db8:3::2 (prefer home address) + + Destination: 2002:c633:6401::1 + Candidate Source Addresses: 2002:c633:6401::d5e3:7953:13eb:22e8 + (temporary) or 2001:db8:1::2 + Result: 2002:c633:6401::d5e3:7953:13eb:22e8 (prefer matching label) + + Destination: 2001:db8:1::d5e3:0:0:1 + Candidate Source Addresses: 2001:db8:1::2 (public) or + 2001:db8:1::d5e3:7953:13eb:22e8 (temporary) + Result: 2001:db8:1::d5e3:7953:13eb:22e8 (prefer temporary address) + +10.2. Default Destination Address Selection + + The destination address selection rules, in conjunction with the + default policy table and the source address selection rules, produce + the following behavior: + + Candidate Source Addresses: 2001:db8:1::2 or fe80::1 or 169.254.13.78 + Destination Address List: 2001:db8:1::1 or 198.51.100.121 + Result: 2001:db8:1::1 (src 2001:db8:1::2) then 198.51.100.121 (src + 169.254.13.78) (prefer matching scope) + + Candidate Source Addresses: fe80::1 or 198.51.100.117 + Destination Address List: 2001:db8:1::1 or 198.51.100.121 + Result: 198.51.100.121 (src 198.51.100.117) then 2001:db8:1::1 (src + fe80::1) (prefer matching scope) + + Candidate Source Addresses: 2001:db8:1::2 or fe80::1 or 10.1.2.4 + Destination Address List: 2001:db8:1::1 or 10.1.2.3 + Result: 2001:db8:1::1 (src 2001:db8:1::2) then 10.1.2.3 (src + 10.1.2.4) (prefer higher precedence) + + Candidate Source Addresses: 2001:db8:1::2 or fe80::2 + Destination Address List: 2001:db8:1::1 or fe80::1 + Result: fe80::1 (src fe80::2) then 2001:db8:1::1 (src 2001:db8:1::2) + (prefer smaller scope) + + Candidate Source Addresses: 2001:db8:1::2 (care-of address) or 2001: + db8:3::1 (home address) or fe80::2 (care-of address) + Destination Address List: 2001:db8:1::1 or fe80::1 + Result: 2001:db8:1::1 (src 2001:db8:3::1) then fe80::1 (src fe80::2) + (prefer home address) + + + + + +Thaler, et al. Standards Track [Page 19] + +RFC 6724 Default Address Selection for IPv6 September 2012 + + + Candidate Source Addresses: 2001:db8:1::2 or fe80::2 (deprecated) + Destination Address List: 2001:db8:1::1 or fe80::1 + Result: 2001:db8:1::1 (src 2001:db8:1::2) then fe80::1 (src fe80::2) + (avoid deprecated addresses) + + Candidate Source Addresses: 2001:db8:1::2 or 2001:db8:3f44::2 or + fe80::2 + Destination Address List: 2001:db8:1::1 or 2001:db8:3ffe::1 + Result: 2001:db8:1::1 (src 2001:db8:1::2) then 2001:db8:3ffe::1 (src + 2001:db8:3f44::2) (longest matching prefix) + + Candidate Source Addresses: 2002:c633:6401::2 or fe80::2 + Destination Address List: 2002:c633:6401::1 or 2001:db8:1::1 + Result: 2002:c633:6401::1 (src 2002:c633:6401::2) then 2001:db8:1::1 + (src 2002:c633:6401::2) (prefer matching label) + + Candidate Source Addresses: 2002:c633:6401::2 or 2001:db8:1::2 or + fe80::2 + Destination Address List: 2002:c633:6401::1 or 2001:db8:1::1 + Result: 2001:db8:1::1 (src 2001:db8:1::2) then 2002:c633:6401::1 (src + 2002:c633:6401::2) (prefer higher precedence) + +10.3. Configuring Preference for IPv6 or IPv4 + + The default policy table gives IPv6 addresses higher precedence than + IPv4 addresses. This means that applications will use IPv6 in + preference to IPv4 when the two are equally suitable. An + administrator can change the policy table to prefer IPv4 addresses by + giving the ::ffff:0.0.0.0/96 prefix a higher precedence: + + Prefix Precedence Label + ::1/128 50 0 + ::/0 40 1 + ::ffff:0:0/96 100 4 + 2002::/16 30 2 + 2001::/32 5 5 + fc00::/7 3 13 + ::/96 1 3 + fec0::/10 1 11 + 3ffe::/16 1 12 + + This change to the default policy table produces the following + behavior: + + Candidate Source Addresses: 2001:db8::2 or fe80::1 or 169.254.13.78 + Destination Address List: 2001:db8::1 or 198.51.100.121 + Unchanged Result: 2001:db8::1 (src 2001:db8::2) then 198.51.100.121 + (src 169.254.13.78) (prefer matching scope) + + + +Thaler, et al. Standards Track [Page 20] + +RFC 6724 Default Address Selection for IPv6 September 2012 + + + Candidate Source Addresses: fe80::1 or 198.51.100.117 + Destination Address List: 2001:db8::1 or 198.51.100.121 + Unchanged Result: 198.51.100.121 (src 198.51.100.117) then + 2001:db8::1 (src fe80::1) (prefer matching scope) + + Candidate Source Addresses: 2001:db8::2 or fe80::1 or 10.1.2.4 + Destination Address List: 2001:db8::1 or 10.1.2.3 + New Result: 10.1.2.3 (src 10.1.2.4) then 2001:db8::1 (src + 2001:db8::2) (prefer higher precedence) + +10.3.1. Handling Broken IPv6 + + One problem in practice that has been recently observed occurs when a + host has IPv4 connectivity to the Internet but has "broken" IPv6 + connectivity to the Internet in that it has a global IPv6 address but + is disconnected from the IPv6 Internet. Since the default policy + table prefers IPv6, this can result in unwanted timeouts. + + This can be solved by configuring the table to prefer IPv4 as shown + above. An implementation that has some means to detect that it is + not connected to the IPv6 Internet MAY do this automatically. An + implementation could instead treat it as part of its implementation + of Rule 1 (avoid unusable destinations). + +10.4. Configuring Preference for Link-Local Addresses + + The destination address selection rules give preference to + destinations of smaller scope. For example, a link-local destination + will be sorted before a global scope destination when the two are + otherwise equally suitable. An administrator can change the policy + table to reverse this preference and sort global destinations before + link-local destinations: + + Prefix Precedence Label + ::1/128 50 0 + ::/0 40 1 + ::ffff:0:0/96 35 4 + fe80::/10 33 1 + 2002::/16 30 2 + 2001::/32 5 5 + fc00::/7 3 13 + ::/96 1 3 + fec0::/10 1 11 + 3ffe::/16 1 12 + + + + + + + +Thaler, et al. Standards Track [Page 21] + +RFC 6724 Default Address Selection for IPv6 September 2012 + + + This change to the default policy table produces the following + behavior: + + Candidate Source Addresses: 2001:db8::2 or fe80::2 + Destination Address List: 2001:db8::1 or fe80::1 + New Result: 2001:db8::1 (src 2001:db8::2) then fe80::1 (src fe80::2) + (prefer higher precedence) + + Candidate Source Addresses: 2001:db8::2 (deprecated) or fe80::2 + Destination Address List: 2001:db8::1 or fe80::1 + Unchanged Result: fe80::1 (src fe80::2) then 2001:db8::1 (src 2001: + db8::2) (avoid deprecated addresses) + +10.5. Configuring a Multi-Homed Site + + Consider a site A that has a business-critical relationship with + another site B. To support their business needs, the two sites have + contracted for service with a special high-performance ISP. This is + in addition to the normal Internet connection that both sites have + with different ISPs. The high-performance ISP is expensive, and the + two sites wish to use it only for their business-critical traffic + with each other. + + Each site has two global prefixes, one from the high-performance ISP + and one from their normal ISP. Site A has prefix 2001:db8:1aaa::/48 + from the high-performance ISP and prefix 2001:db8:70aa::/48 from its + normal ISP. Site B has prefix 2001:db8:1bbb::/48 from the high- + performance ISP and prefix 2001:db8:70bb::/48 from its normal ISP. + All hosts in both sites register two addresses in the DNS. + + The routing within both sites directs most traffic to the egress to + the normal ISP, but the routing directs traffic sent to the other + site's 2001 prefix to the egress to the high-performance ISP. To + prevent unintended use of their high-performance ISP connection, the + two sites implement ingress filtering to discard traffic entering + from the high-performance ISP that is not from the other site. + + The default policy table and address selection rules produce the + following behavior: + + Candidate Source Addresses: 2001:db8:1aaa::a or 2001:db8:70aa::a or + fe80::a + Destination Address List: 2001:db8:1bbb::b or 2001:db8:70bb::b + Result: 2001:db8:70bb::b (src 2001:db8:70aa::a) then 2001:db8:1bbb::b + (src 2001:db8:1aaa::a) (longest matching prefix) + + + + + + +Thaler, et al. Standards Track [Page 22] + +RFC 6724 Default Address Selection for IPv6 September 2012 + + + In other words, when a host in site A initiates a connection to a + host in site B, the traffic does not take advantage of their + connections to the high-performance ISP. This is not their desired + behavior. + + Candidate Source Addresses: 2001:db8:1aaa::a or 2001:db8:70aa::a or + fe80::a + Destination Address List: 2001:db8:1ccc::c or 2001:db8:6ccc::c + Result: 2001:db8:1ccc::c (src 2001:db8:1aaa::a) then 2001:db8:6ccc::c + (src 2001:db8:70aa::a) (longest matching prefix) + + In other words, when a host in site A initiates a connection to a + host in some other site C, the reverse traffic might come back + through the high-performance ISP. Again, this is not their desired + behavior. + + This predicament demonstrates the limitations of the longest- + matching-prefix heuristic in multi-homed situations. + + However, the administrators of sites A and B can achieve their + desired behavior via policy table configuration. For example, they + can use the following policy table: + + Prefix Precedence Label + ::1/128 50 0 + 2001:db8:1aaa::/48 43 6 + 2001:db8:1bbb::/48 43 6 + ::/0 40 1 + ::ffff:0:0/96 35 4 + 2002::/16 30 2 + 2001::/32 5 5 + fc00::/7 3 13 + ::/96 1 3 + fec0::/10 1 11 + 3ffe::/16 1 12 + + This policy table produces the following behavior: + + Candidate Source Addresses: 2001:db8:1aaa::a or 2001:db8:70aa::a or + fe80::a + Destination Address List: 2001:db8:1bbb::b or 2001:db8:70bb::b + New Result: 2001:db8:1bbb::b (src 2001:db8:1aaa::a) then 2001:db8: + 70bb::b (src 2001:db8:70aa::a) (prefer higher precedence) + + In other words, when a host in site A initiates a connection to a + host in site B, the traffic uses the high-performance ISP as desired. + + + + + +Thaler, et al. Standards Track [Page 23] + +RFC 6724 Default Address Selection for IPv6 September 2012 + + + Candidate Source Addresses: 2001:db8:1aaa::a or 2001:db8:70aa::a or + fe80::a + Destination Address List: 2001:db8:1ccc::c or 2001:db8:6ccc::c + New Result: 2001:db8:6ccc::c (src 2001:db8:70aa::a) then 2001:db8: + 1ccc::c (src 2001:db8:70aa::a) (longest matching prefix) + + In other words, when a host in site A initiates a connection to a + host in some other site C, the traffic uses the normal ISP as + desired. + +10.6. Configuring ULA Preference + + Sections 2.1.4, 2.2.2, and 2.2.3 of RFC 5220 [RFC5220] describe + address selection problems related to Unique Local Addresses (ULAs) + [RFC4193]. By default, global IPv6 destinations are preferred over + ULA destinations, since an arbitrary ULA is not necessarily + reachable: + + Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1 + Destination Address List: 2001:db8:2::2 or fd22:2222:2222:2::2 + Result: 2001:db8:2::2 (src 2001:db8:1::1) then fd22:2222:2222:2::2 + (src fd11:1111:1111:1::1) (prefer higher precedence) + + However, a site-specific policy entry can be used to cause ULAs + within a site to be preferred over global addresses as follows. + + Prefix Precedence Label + ::1/128 50 0 + fd11:1111:1111::/48 45 14 + ::/0 40 1 + ::ffff:0:0/96 35 4 + 2002::/16 30 2 + 2001::/32 5 5 + fc00::/7 3 13 + ::/96 1 3 + fec0::/10 1 11 + 3ffe::/16 1 12 + + Such a configuration would have the following effect: + + Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1 + Destination Address List: 2001:db8:2::2 or fd22:2222:2222:2::2 + Unchanged Result: 2001:db8:2::2 (src 2001:db8:1::1) then fd22:2222: + 2222:2::2 (src fd11:1111:1111:1::1) (prefer higher precedence) + + + + + + + +Thaler, et al. Standards Track [Page 24] + +RFC 6724 Default Address Selection for IPv6 September 2012 + + + Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1 + Destination Address List: 2001:db8:2::2 or fd11:1111:1111:2::2 + New Result: fd11:1111:1111:2::2 (src fd11:1111:1111:1::1) then 2001: + db8:2::2 (src 2001:db8:1::1) (prefer higher precedence) + + Since ULAs are defined to have a /48 site prefix, an implementation + might choose to add such a row automatically on a machine with a ULA. + + It is also worth noting that ULAs are assigned global scope. As + such, the existence of one or more rows in the prefix policy table is + important so that source address selection does not choose a ULA + purely based on longest match: + + Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1 + Destination Address List: ff00:1 + Result: 2001:db8:1::1 (prefer matching label) + +10.7. Configuring 6to4 Preference + + By default, NATed IPv4 is preferred over 6to4-relayed connectivity: + + Candidate Source Addresses: 2002:c633:6401::2 or 10.1.2.3 + Destination Address List: 2001:db8:1::1 or 203.0.113.1 + Result: 203.0.113.1 (src 10.1.2.3) then 2001:db8:1::1 (src 2002:c633: + 6401::2) (prefer matching label) + + However, NATed IPv4 is now also preferred over 6to4-to-6to4 + connectivity by default. Since a 6to4 prefix might be used natively + within an organization, a site-specific policy entry can be used to + cause native IPv6 communication (using a 6to4 prefix) to be preferred + over NATed IPv4 as follows. + + Prefix Precedence Label + ::1/128 50 0 + 2002:c633:6401::/48 45 14 + ::/0 40 1 + ::ffff:0:0/96 35 4 + 2002::/16 30 2 + 2001::/32 5 5 + fc00::/7 3 13 + ::/96 1 3 + fec0::/10 1 11 + 3ffe::/16 1 12 + + + + + + + + +Thaler, et al. Standards Track [Page 25] + +RFC 6724 Default Address Selection for IPv6 September 2012 + + + Such a configuration would have the following effect: + + Candidate Source Addresses: 2002:c633:6401:1::1 or 10.1.2.3 + Destination Address List: 2002:c633:6401:2::2 or 203.0.113.1 + New Result: 2002:c633:6401:2::2 (src 2002:c633:6401:1::1) then + 203.0.113.1 (sec 10.1.2.3) (prefer higher precedence) + + Since 6to4 addresses are defined to have a /48 site prefix, an + implementation might choose to add such a row automatically on a + machine with a native IPv6 address with a 6to4 prefix. + +11. References + +11.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 + Domains via IPv4 Clouds", RFC 3056, February 2001. + + [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local + Addresses", RFC 3879, September 2004. + + [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 + Unicast Addresses", RFC 4193, October 2005. + + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, February 2006. + + [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through + Network Address Translations (NATs)", RFC 4380, + February 2006. + + [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 + Stateless Address Autoconfiguration", RFC 4862, + September 2007. + + [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy + Extensions for Stateless Address Autoconfiguration in + IPv6", RFC 4941, September 2007. + + [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation + Algorithm", RFC 6145, April 2011. + + + + + + + +Thaler, et al. Standards Track [Page 26] + +RFC 6724 Default Address Selection for IPv6 September 2012 + + +11.2. Informative References + + [ADDR-SEL-OPT] Matsumoto, A., Fujisaki, T., Kato, J., and T. Chown, + "Distributing Address Selection Policy using DHCPv6", + Work in Progress, August 2012. + + [RFC1794] Brisco, T., "DNS Support for Load Balancing", + RFC 1794, April 1995. + + [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", + RFC 1812, June 1995. + + [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, + G., and E. Lear, "Address Allocation for Private + Internets", BCP 5, RFC 1918, February 1996. + + [RFC2827] Ferguson, P. and D. Senie, "Network Ingress + Filtering: Defeating Denial of Service Attacks which + employ IP Source Address Spoofing", BCP 38, RFC 2827, + May 2000. + + [RFC3484] Draves, R., "Default Address Selection for Internet + Protocol version 6 (IPv6)", RFC 3484, February 2003. + + [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and + W. Stevens, "Basic Socket Interface Extensions for + IPv6", RFC 3493, February 2003. + + [RFC3701] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address + Allocation) Phaseout", RFC 3701, March 2004. + + [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic + Configuration of IPv4 Link-Local Addresses", + RFC 3927, May 2005. + + [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., + and B. Zill, "IPv6 Scoped Address Architecture", + RFC 4007, March 2005. + + [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences + and More-Specific Routes", RFC 4191, November 2005. + + [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition + Mechanisms for IPv6 Hosts and Routers", RFC 4213, + October 2005. + + + + + + +Thaler, et al. Standards Track [Page 27] + +RFC 6724 Default Address Selection for IPv6 September 2012 + + + [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. + Soliman, "Neighbor Discovery for IP version 6 + (IPv6)", RFC 4861, September 2007. + + [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 + Socket API for Source Address Selection", RFC 5014, + September 2007. + + [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site + Automatic Tunnel Addressing Protocol (ISATAP)", + RFC 5214, March 2008. + + [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. + Kanayama, "Problem Statement for Default Address + Selection in Multi-Prefix Environments: Operational + Issues of RFC 3484 Default Rules", RFC 5220, + July 2008. + + [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on + IPv4 Infrastructures (6rd) -- Protocol + Specification", RFC 5969, August 2010. + + [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility + Support in IPv6", RFC 6275, July 2011. + + [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, + C., and M. Azinger, "IANA-Reserved IPv4 Prefix for + Shared Address Space", BCP 153, RFC 6598, April 2012. + + + + + + + + + + + + + + + + + + + + + + + +Thaler, et al. Standards Track [Page 28] + +RFC 6724 Default Address Selection for IPv6 September 2012 + + +Appendix A. Acknowledgements + + RFC 3484 [RFC3484] acknowledged the contributions of the IPng Working + Group, particularly Marc Blanchet, Brian Carpenter, Matt Crawford, + Alain Durand, Steve Deering, Robert Elz, Jun-ichiro itojun Hagino, + Tony Hain, M.T. Hollinger, JINMEI Tatuya, Thomas Narten, Erik + Nordmark, Ken Powell, Markku Savela, Pekka Savola, Hesham Soliman, + Dave Thaler, Mauro Tortonesi, Ole Troan, and Stig Venaas. In + addition, the anonymous IESG reviewers had many great comments and + suggestions for clarification. + + This revision was heavily influenced by the work by Arifumi + Matsumoto, Jun-ya Kato, and Tomohiro Fujisaki in a working document + that made proposals for this revision to adopt, with input from Pekka + Savola, Remi Denis-Courmont, Francois-Xavier Le Bail, and the 6man + Working Group. Dmitry Anipko, Mark Andrews, Ray Hunter, and Wes + George also provided valuable feedback on this revision. + +Appendix B. Changes since RFC 3484 + + Some changes were made to the default policy table that were deemed + to be universally useful and cause no harm in every reasonable + network environment. In doing so, care was taken to use the same + preference and label values as in RFC 3484 whenever possible and for + new rows to use label values less likely to collide with values that + might already be in use in additional rows on some hosts. These + changes are: + + 1. Added the Teredo [RFC4380] prefix (2001::/32), with the + preference and label values already widely used in popular + implementations. + + 2. Added a row for ULAs (fc00::/7) below native IPv6 since they are + not globally reachable, as discussed in Section 10.6. + + 3. Added a row for site-local addresses (fec0::/10) in order to + depreference them, for consistency with the example in + Section 10.3, since they are deprecated [RFC3879]. + + 4. Depreferenced 6to4 (2002::/32) below native IPv4 since 6to4 + connectivity is less reliable today (and is expected to be phased + out over time, rather than becoming more reliable). It remains + above Teredo since 6to4 is more efficient in terms of connection + establishment time, bandwidth, and server load. + + 5. Depreferenced IPv4-Compatible addresses (::/96) since they are + now deprecated [RFC4291] and not in common use. + + + + +Thaler, et al. Standards Track [Page 29] + +RFC 6724 Default Address Selection for IPv6 September 2012 + + + 6. Added a row for 6bone testing addresses (3ffe::/16) in order to + depreference them as they have also been phased out [RFC3701]. + + 7. Added optional ability for an implementation to add automatic + rows to the table for site-specific ULA prefixes and site- + specific native 6to4 prefixes. + + Similarly, some changes were made to the rules, as follows: + + 1. Changed the definition of CommonPrefixLen() to only compare bits + up to the source address's prefix length. The previous + definition used the entire source address, rather than only its + prefix. As a result, when a source and destination addresses had + the same prefix, common bits in the interface ID would previously + result in overriding DNS load balancing [RFC1794] by forcing the + destination address with the most bits in common to be always + chosen. The updated definition allows DNS load balancing to + continue to be used as a tie breaker. + + 2. Added Rule 5.5 to allow choosing a source address from a prefix + advertised by the chosen next-hop for a given destination. This + allows better connectivity in the presence of BCP 38 [RFC2827] + ingress filtering and egress filtering. Previously, RFC 3484 had + issues with multiple egress networks reached via the same + interface, as discussed in [RFC5220]. + + 3. Removed restriction against anycast addresses in the candidate + set of source addresses, since the restriction against using IPv6 + anycast addresses as source addresses was removed in Section 2.6 + of RFC 4291 [RFC4291]. + + 4. Changed mapping of RFC 1918 [RFC1918] addresses to global scope + in Section 3.2. Previously, they were mapped to site-local + scope. However, experience has resulted in current + implementations already using global scope instead. When they + were mapped to site-local, Destination Address Selection Rule 2 + (Prefer matching scope) would cause IPv6 to be preferred in + scenarios such as that described in Section 10.7. The change to + global scope allows configurability via the prefix policy table. + + 5. Changed the default recommendation for Source Address Selection + Rule 7 to prefer temporary addresses rather than public + addresses, while providing an administrative override (in + addition to the application-specific override that was already + specified). This change was made because of the increasing + importance of privacy considerations, as well as the fact that + widely deployed implementations have preferred temporary + addresses for many years without major application issues. + + + +Thaler, et al. Standards Track [Page 30] + +RFC 6724 Default Address Selection for IPv6 September 2012 + + + Finally, some editorial changes were made, including: + + 1. Changed global IP addresses in examples to use ranges reserved + for documentation. + + 2. Added additional examples in Sections 10.6 and 10.7. + + 3. Added Section 10.3.1 on "broken" IPv6. + + 4. Updated references. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Thaler, et al. Standards Track [Page 31] + +RFC 6724 Default Address Selection for IPv6 September 2012 + + +Authors' Addresses + + Dave Thaler (editor) + Microsoft + One Microsoft Way + Redmond, WA 98052 + USA + + Phone: +1 425 703 8835 + EMail: dthaler@microsoft.com + + + Richard Draves + Microsoft Research + One Microsoft Way + Redmond, WA 98052 + USA + + Phone: +1 425 706 2268 + EMail: richdr@microsoft.com + + + Arifumi Matsumoto + NTT SI Lab + Midori-Cho 3-9-11 + Musashino-shi, Tokyo 180-8585 + Japan + + Phone: +81 422 59 3334 + EMail: arifumi@nttv6.net + + + Tim Chown + University of Southampt on + Southampton, Hampshire SO17 1BJ + United Kingdom + + EMail: tjc@ecs.soton.ac.uk + + + + + + + + + + + + + +Thaler, et al. Standards Track [Page 32] + -- cgit v1.2.3