--- 1/draft-ietf-6man-rfc3484bis-04.txt 2012-06-01 00:14:09.701344025 +0200 +++ 2/draft-ietf-6man-rfc3484bis-05.txt 2012-06-01 00:14:09.757344117 +0200 @@ -1,58 +1,58 @@ Network Working Group D. Thaler, Ed. Internet-Draft Microsoft Obsoletes: 3484 (if approved) R. Draves Intended status: Standards Track Microsoft Research -Expires: November 16, 2012 A. Matsumoto +Expires: December 2, 2012 A. Matsumoto NTT T. Chown University of Southampton - May 15, 2012 + May 31, 2012 Default Address Selection for Internet Protocol version 6 (IPv6) - draft-ietf-6man-rfc3484bis-04.txt + draft-ietf-6man-rfc3484bis-05.txt Abstract - This document describes two algorithms, for source address selection - and for destination address selection. The algorithms specify - default behavior for all Internet Protocol version 6 (IPv6) + 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. - All IPv6 nodes, including both hosts and routers, must implement - default address selection as defined in this specification. This - document obsoletes RFC 3484. + 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 Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at 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 November 16, 2012. + This Internet-Draft will expire on December 2, 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 @@ -66,58 +66,58 @@ 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.2. IPv4 Addresses and IPv4-Mapped Addresses . . . . . . . . . 9 3.3. Other IPv6 Addresses with Embedded IPv4 Addresses . . . . 9 - 3.4. IPv6 Loopback Address and Other Format Prefixes . . . . . 9 + 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 6. Destination Address Selection . . . . . . . . . . . . . . . . 14 7. Interactions with Routing . . . . . . . . . . . . . . . . . . 16 - 8. Implementation Considerations . . . . . . . . . . . . . . . . 16 + 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 10.6. Configuring ULA Preference . . . . . . . . . . . . . . . . 24 10.7. Configuring 6to4 Preference . . . . . . . . . . . . . . . 25 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 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 1. Introduction The IPv6 addressing architecture [RFC4291] allows multiple unicast - addresses to be assigned to interfaces. These addresses may have + addresses to be assigned to interfaces. These addresses might have different reachability scopes (link-local, site-local, or global). - These addresses may also be "preferred" or "deprecated" [RFC4862]. + 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 may have multiple - interfaces, some of them tunnels or virtual interfaces, or a site may - have multiple ISP attachments with a global prefix per ISP. + 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 @@ -133,23 +133,23 @@ 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 may return a set of addresses for a given name, and an + 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 should the first one not be reachable. The destination + 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. This document specifies source address selection and destination address selection separately, but using 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 @@ -196,26 +196,30 @@ 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 - source address selection in an IPv4 network layer may be possible but - this is not explored further here. + source address selection in an IPv4 network layer might be possible + but this is not explored further here. - Well-behaved applications SHOULD iterate through the list of - addresses returned from getaddrinfo() until they find a working - address. + 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. 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 @@ -228,22 +232,23 @@ 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 [I-D.ietf-6man-addr-select-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 may automatically add site-specific - rows for certain types of addresses. + 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 Precedence(A) and a classification or label Label(A). @@ -275,34 +280,35 @@ ::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 - ULAs and 6to4 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. + 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 [RFC3056] - 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. + 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. 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 @@ -331,86 +337,87 @@ site-local (0x5), organization-local (0x8), and global (0xE) scopes [RFC4007]. 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. + 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.) 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 should be - represented as IPv4-mapped addresses [RFC4291]. For example, to - lookup the precedence or other attributes of an IPv4 address in the - policy table, lookup the corresponding IPv4-mapped IPv6 address. + IPv4 addresses. For this purpose, IPv4 addresses MUST be represented + as IPv4-mapped addresses [RFC4291]. For example, to lookup the + precedence or other attributes of an IPv4 address in the policy + table, lookup 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 ([RFC1918], section 4.2.2.11), which have the prefix 127/8, are assigned link- local scope (analogously to the treatment of the IPv6 loopback address ([RFC4007], section 4)). Other IPv4 addresses (including IPv4 private addresses [RFC1918] and Shared Address Space addresses [RFC6598]) are assigned global scope. - IPv4 addresses should be treated as having "preferred" (in the RFC - 4862 sense) configuration status. + 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 should be treated as having global scope. + document, these addresses MUST be treated as having global scope. - IPv4-compatible, IPv4-mapped, and IPv4-converted addresses should be + 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 should be treated as having link-local scope + The loopback address MUST be treated as having link-local scope ([RFC4007], section 4) and "preferred" (in the RFC 4862 sense) configuration status. NSAP addresses and other addresses with as-yet-undefined format - prefixes should be treated as having global scope and "preferred" (in - the RFC 4862) configuration status. Later standards may supersede + 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 may support mobility using the concepts of home address + 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 may have an address that + 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 should be designated a - home address or care-of address is outside the scope of this - document. + care-of addresses. Whether or not an address is 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. @@ -418,25 +425,25 @@ 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. 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 should + of global source addresses assigned to a loopback interface MUST behave as if the loopback interface originates and forwards the packet. - In some cases the destination address may be qualified with a zone + 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 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. @@ -479,27 +486,27 @@ 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 are 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 + 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, some unspecified tie-breaker should be used. + 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. 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 @@ -512,25 +519,25 @@ 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 should 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 should only affect the selection - rules for the invoking application. + 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 @@ -550,83 +557,83 @@ 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 should only affect the selection + [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 + 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 should be represented as an IPv4-mapped address. + 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 should be applied in order. If a rule determines a - result, then the remaining rules are not relevant and should be + 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 tie-breakers for earlier rules. See the previous section for a lengthier description of how pair-wise comparison tie-breaker 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 may know that a particular + Discussion: An implementation might know that a particular destination is unreachable in several ways. For example, the - destination may be reached through a network interface that is - currently unplugged. For example, the implementation may retain + destination might be reached through a network interface that is + currently unplugged. For example, the implementation might retain for some period of time information from Neighbor Unreachability Detection [RFC4861]. 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. @@ -677,77 +684,78 @@ 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 + 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 + 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 + 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 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 may prefer source - addresses with prefix A and when sending via the second router, - prefer source addresses with prefix B. + Implementations that support source address selection (Section 5) + Rule 5.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 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 resort 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 may 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. + 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 should ensure that the destination address + 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 or 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. @@ -762,31 +770,31 @@ 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. - In addition, some address selection rules may be administratively + 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 should - not be construed as normative. + 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) @@ -994,23 +1004,25 @@ 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 may come back through - the high-performance ISP. Again, this is not their desired behavior. + 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