--- 1/draft-ietf-6man-rfc3484bis-05.txt 2012-06-27 03:14:12.777342132 +0200 +++ 2/draft-ietf-6man-rfc3484bis-06.txt 2012-06-27 03:14:12.837342613 +0200 @@ -1,23 +1,23 @@ Network Working Group D. Thaler, Ed. Internet-Draft Microsoft Obsoletes: 3484 (if approved) R. Draves Intended status: Standards Track Microsoft Research -Expires: December 2, 2012 A. Matsumoto +Expires: December 29, 2012 A. Matsumoto NTT T. Chown University of Southampton - May 31, 2012 + June 27, 2012 Default Address Selection for Internet Protocol version 6 (IPv6) - draft-ietf-6man-rfc3484bis-05.txt + draft-ietf-6man-rfc3484bis-06.txt 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 @@ -38,21 +38,21 @@ 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 http://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 December 2, 2012. + This Internet-Draft will expire on December 29, 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 @@ -63,47 +63,47 @@ described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Conventions Used in This Document . . . . . . . . . . . . 5 2. Context in Which the Algorithms Operate . . . . . . . . . . . 5 2.1. Policy Table . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Common Prefix Length . . . . . . . . . . . . . . . . . . . 8 3. Address Properties . . . . . . . . . . . . . . . . . . . . . . 8 - 3.1. Scope Comparisons . . . . . . . . . . . . . . . . . . . . 8 + 3.1. Scope Comparisons . . . . . . . . . . . . . . . . . . . . 9 3.2. IPv4 Addresses and IPv4-Mapped Addresses . . . . . . . . . 9 - 3.3. Other IPv6 Addresses with Embedded IPv4 Addresses . . . . 9 + 3.3. Other IPv6 Addresses with Embedded IPv4 Addresses . . . . 10 3.4. IPv6 Loopback Address and Other Format Prefixes . . . . . 10 3.5. Mobility Addresses . . . . . . . . . . . . . . . . . . . . 10 - 4. Candidate Source Addresses . . . . . . . . . . . . . . . . . . 10 - 5. Source Address Selection . . . . . . . . . . . . . . . . . . . 11 + 4. Candidate Source Addresses . . . . . . . . . . . . . . . . . . 11 + 5. Source Address Selection . . . . . . . . . . . . . . . . . . . 12 6. Destination Address Selection . . . . . . . . . . . . . . . . 14 - 7. Interactions with Routing . . . . . . . . . . . . . . . . . . 16 + 7. Interactions with Routing . . . . . . . . . . . . . . . . . . 17 8. Implementation Considerations . . . . . . . . . . . . . . . . 17 - 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 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 + 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 10.1. Default Source Address Selection . . . . . . . . . . . . . 19 + 10.2. Default Destination Address Selection . . . . . . . . . . 20 + 10.3. Configuring Preference for IPv6 or IPv4 . . . . . . . . . 21 + 10.3.1. Handling Broken IPv6 . . . . . . . . . . . . . . . . 22 + 10.4. Configuring Preference for Link-Local Addresses . . . . . 22 + 10.5. Configuring a Multi-Homed Site . . . . . . . . . . . . . . 23 10.6. Configuring ULA Preference . . . . . . . . . . . . . . . . 24 10.7. Configuring 6to4 Preference . . . . . . . . . . . . . . . 25 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 12.1. Normative References . . . . . . . . . . . . . . . . . . . 26 - 12.2. Informative References . . . . . . . . . . . . . . . . . . 26 - Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 28 - Appendix B. Changes Since RFC 3484 . . . . . . . . . . . . . . . 28 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 + 12.2. Informative References . . . . . . . . . . . . . . . . . . 27 + Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 29 + Appendix B. Changes Since RFC 3484 . . . . . . . . . . . . . . . 29 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 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" @@ -176,50 +176,63 @@ 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 [RFC3493] - like getaddrinfo() that return a list of addresses to the + 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 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 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 + 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 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 in parallel (e.g., with some small delay in between) and use - the first one to succeed. + 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 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 was 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 scope for 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 @@ -289,31 +301,31 @@ to the default table based on its configured addresses, such as for Unique Local Addresses (ULAs) [RFC4193] and 6to4 [RFC3056] addresses for instance (see Section 10.6 and Section 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. - 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. + 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 scoped address prefixes 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. + 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. @@ -326,34 +338,38 @@ 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), subnet-local (0x3), admin-local (0x4), - site-local (0x5), organization-local (0x8), and global (0xE) scopes - [RFC4007]. + local (0x1), link-local (0x2), admin-local (0x4), site-local (0x5), + organization-local (0x8), and global (0xE) scopes ([RFC4291] Section + 2.7). 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 ULAs - are considered as global, not site-local, scope but are handled via - the prefix policy table as discussed in Section 10.6.) + 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 and, therefore, they are 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 @@ -401,79 +417,80 @@ 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 - or not one's own addresses are designated as home addresses or - care-of addresses. Whether or not an address is designated a home - address or care-of address is outside the scope of this document. + 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. 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 + 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. 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. + 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 multicast and link-local destination addresses, the set of + 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 destination addresses, the set of candidate source - addresses MUST only include addresses assigned to interfaces + 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. - If an 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. The specified source address may - influence the candidate set, by affecting the choice of outgoing - interface. 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. + 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. - On IPv6-only nodes that support SIIT [RFC6145], if the destination - address is an IPv4-converted address then the candidate set MUST - contain only IPv4-translatable addresses. + 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 @@ -496,34 +513,39 @@ 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 tie-breaker is implementation-specific. 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. + 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. - The addresses SA and SB have the same scope. 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." + 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 @@ -541,22 +563,22 @@ 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. 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. Implementations that do not track this - information shall omit rule 5.5. + 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. @@ -581,23 +603,20 @@ 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. - Rule 2 (prefer appropriate scope) MUST be implemented and given high - priority because it can affect interoperability. - 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. @@ -659,29 +678,30 @@ 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: 6RD [RFC5969], 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). + Discussion: "IPv6 Rapid Deployment on IPv4 Infrastructures" (6rd) + [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. 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), @@ -770,20 +790,30 @@ 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 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. + 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 of default behavior and then demonstrating the utility of policy table configuration. These examples are provided for illustrative purposes; they are not @@ -1054,23 +1086,24 @@ 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 RFC 5220 [RFC5220] sections 2.1.4, 2.2.2, and 2.2.3 describe address - selection problems related to ULAs [RFC4193]. By default, global - IPv6 destinations are preferred over ULA destinations, since an - arbitrary ULA is not necessarily reachable: + 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