idnits 2.17.1 draft-ietf-6man-rfc3484bis-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 9 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. == There are 6 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 27, 2012) is 4313 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) == Outdated reference: A later version (-13) exists of draft-ietf-6man-addr-select-opt-03 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Thaler, Ed. 3 Internet-Draft Microsoft 4 Obsoletes: 3484 (if approved) R. Draves 5 Intended status: Standards Track Microsoft Research 6 Expires: December 29, 2012 A. Matsumoto 7 NTT 8 T. Chown 9 University of Southampton 10 June 27, 2012 12 Default Address Selection for Internet Protocol version 6 (IPv6) 13 draft-ietf-6man-rfc3484bis-06.txt 15 Abstract 17 This document describes two algorithms, one for source address 18 selection and one for destination address selection. The algorithms 19 specify default behavior for all Internet Protocol version 6 (IPv6) 20 implementations. They do not override choices made by applications 21 or upper-layer protocols, nor do they preclude the development of 22 more advanced mechanisms for address selection. The two algorithms 23 share a common context, including an optional mechanism for allowing 24 administrators to provide policy that can override the default 25 behavior. In dual stack implementations, the destination address 26 selection algorithm can consider both IPv4 and IPv6 addresses - 27 depending on the available source addresses, the algorithm might 28 prefer IPv6 addresses over IPv4 addresses, or vice-versa. 30 Default address selection as defined in this specification applies to 31 all IPv6 nodes, including both hosts and routers. This document 32 obsoletes RFC 3484. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on December 29, 2012. 50 Copyright Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Conventions Used in This Document . . . . . . . . . . . . 5 69 2. Context in Which the Algorithms Operate . . . . . . . . . . . 5 70 2.1. Policy Table . . . . . . . . . . . . . . . . . . . . . . . 7 71 2.2. Common Prefix Length . . . . . . . . . . . . . . . . . . . 8 72 3. Address Properties . . . . . . . . . . . . . . . . . . . . . . 8 73 3.1. Scope Comparisons . . . . . . . . . . . . . . . . . . . . 9 74 3.2. IPv4 Addresses and IPv4-Mapped Addresses . . . . . . . . . 9 75 3.3. Other IPv6 Addresses with Embedded IPv4 Addresses . . . . 10 76 3.4. IPv6 Loopback Address and Other Format Prefixes . . . . . 10 77 3.5. Mobility Addresses . . . . . . . . . . . . . . . . . . . . 10 78 4. Candidate Source Addresses . . . . . . . . . . . . . . . . . . 11 79 5. Source Address Selection . . . . . . . . . . . . . . . . . . . 12 80 6. Destination Address Selection . . . . . . . . . . . . . . . . 14 81 7. Interactions with Routing . . . . . . . . . . . . . . . . . . 17 82 8. Implementation Considerations . . . . . . . . . . . . . . . . 17 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 84 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 85 10.1. Default Source Address Selection . . . . . . . . . . . . . 19 86 10.2. Default Destination Address Selection . . . . . . . . . . 20 87 10.3. Configuring Preference for IPv6 or IPv4 . . . . . . . . . 21 88 10.3.1. Handling Broken IPv6 . . . . . . . . . . . . . . . . 22 89 10.4. Configuring Preference for Link-Local Addresses . . . . . 22 90 10.5. Configuring a Multi-Homed Site . . . . . . . . . . . . . . 23 91 10.6. Configuring ULA Preference . . . . . . . . . . . . . . . . 24 92 10.7. Configuring 6to4 Preference . . . . . . . . . . . . . . . 25 93 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 94 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 95 12.1. Normative References . . . . . . . . . . . . . . . . . . . 26 96 12.2. Informative References . . . . . . . . . . . . . . . . . . 27 97 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 29 98 Appendix B. Changes Since RFC 3484 . . . . . . . . . . . . . . . 29 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 101 1. Introduction 103 The IPv6 addressing architecture [RFC4291] allows multiple unicast 104 addresses to be assigned to interfaces. These addresses might have 105 different reachability scopes (link-local, site-local, or global). 106 These addresses might also be "preferred" or "deprecated" [RFC4862]. 107 Privacy considerations have introduced the concepts of "public 108 addresses" and "temporary addresses" [RFC4941]. The mobility 109 architecture introduces "home addresses" and "care-of addresses" 110 [RFC6275]. In addition, multi-homing situations will result in more 111 addresses per node. For example, a node might have multiple 112 interfaces, some of them tunnels or virtual interfaces, or a site 113 might have multiple ISP attachments with a global prefix per ISP. 115 The end result is that IPv6 implementations will very often be faced 116 with multiple possible source and destination addresses when 117 initiating communication. It is desirable to have default 118 algorithms, common across all implementations, for selecting source 119 and destination addresses so that developers and administrators can 120 reason about and predict the behavior of their systems. 122 Furthermore, dual or hybrid stack implementations, which support both 123 IPv6 and IPv4, will very often need to choose between IPv6 and IPv4 124 when initiating communication. For example, when DNS name resolution 125 yields both IPv6 and IPv4 addresses and the network protocol stack 126 has available both IPv6 and IPv4 source addresses. In such cases, a 127 simple policy to always prefer IPv6 or always prefer IPv4 can produce 128 poor behavior. As one example, suppose a DNS name resolves to a 129 global IPv6 address and a global IPv4 address. If the node has 130 assigned a global IPv6 address and a 169.254/16 auto-configured IPv4 131 address [RFC3927], then IPv6 is the best choice for communication. 132 But if the node has assigned only a link-local IPv6 address and a 133 global IPv4 address, then IPv4 is the best choice for communication. 134 The destination address selection algorithm solves this with a 135 unified procedure for choosing among both IPv6 and IPv4 addresses. 137 The algorithms in this document are specified as a set of rules that 138 define a partial ordering on the set of addresses that are available 139 for use. In the case of source address selection, a node typically 140 has multiple addresses assigned to its interfaces, and the source 141 address ordering rules in section 5 define which address is the 142 "best" one to use. In the case of destination address selection, the 143 DNS might return a set of addresses for a given name, and an 144 application needs to decide which one to use first, and in what order 145 to try others if the first one is not reachable. The destination 146 address ordering rules in section 6, when applied to the set of 147 addresses returned by the DNS, provide such a recommended ordering. 149 This document specifies source address selection and destination 150 address selection separately, but using a common context so that 151 together the two algorithms yield useful results. The algorithms 152 attempt to choose source and destination addresses of appropriate 153 scope and configuration status (preferred or deprecated in the RFC 154 4862 sense). Furthermore, this document suggests a preferred method, 155 longest matching prefix, for choosing among otherwise equivalent 156 addresses in the absence of better information. 158 This document also specifies policy hooks to allow administrative 159 override of the default behavior. For example, using these hooks an 160 administrator can specify a preferred source prefix for use with a 161 destination prefix, or prefer destination addresses with one prefix 162 over addresses with another prefix. These hooks give an 163 administrator flexibility in dealing with some multi-homing and 164 transition scenarios, but they are certainly not a panacea. 166 The selection rules specified in this document MUST NOT be construed 167 to override an application or upper-layer's explicit choice of a 168 legal destination or source address. 170 1.1. Conventions Used in This Document 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in BCP 14, RFC 2119 175 [RFC2119]. 177 2. Context in Which the Algorithms Operate 179 Our context for address selection derives from the most common 180 implementation architecture, which separates the choice of 181 destination address from the choice of source address. Consequently, 182 we have two separate algorithms for these tasks. The algorithms are 183 designed to work well together and they share a mechanism for 184 administrative policy override. 186 In this implementation architecture, applications use APIs such as 187 getaddrinfo() [RFC3493] that return a list of addresses to the 188 application. This list might contain both IPv6 and IPv4 addresses 189 (sometimes represented as IPv4-mapped addresses). The application 190 then passes a destination address to the network stack with connect() 191 or sendto(). The application would then typically try the first 192 address in the list, looping over the list of addresses until it 193 finds a working address. In any case, the network layer is never in 194 a situation where it needs to choose a destination address from 195 several alternatives. The application might also specify a source 196 address with bind(), but often the source address is left 197 unspecified. Therefore the network layer does often choose a source 198 address from several alternatives. 200 As a consequence, we intend that implementations of APIs such as 201 getaddrinfo() will use the destination address selection algorithm 202 specified here to sort the list of IPv6 and IPv4 addresses that they 203 return. Separately, the IPv6 network layer will use the source 204 address selection algorithm when an application or upper-layer has 205 not specified a source address. Application of this specification to 206 source address selection in an IPv4 network layer might be possible 207 but this is not explored further here. 209 Well-behaved applications SHOULD NOT simply use the first address 210 returned from an API such as getaddrinfo() and then give up if it 211 fails. For many applications, it is appropriate to iterate through 212 the list of addresses returned from getaddrinfo() until a working 213 address is found. For other applications, it might be appropriate to 214 try multiple in parallel (e.g., with some small delay in between) and 215 use the first one to succeed. 217 Although source and destination address selection is most typically 218 done when initiating communication, a responder also must deal with 219 address selection. In many cases this is trivially dealt with by an 220 application using the source address of a received packet as the 221 response destination, and the destination address of the received 222 packet as the response source. Other cases, however, are handled 223 like an initiator, such as when the request was multicast and hence 224 source address selection must still occur when generating a response, 225 or when the request includes a list of the initiator's addresses from 226 which to choose a destination. Finally, a third application scenario 227 is that of a listening application choosing on what local addresses 228 to listen. This third scenario is out of scope for this document. 230 The algorithms use several criteria in making their decisions. The 231 combined effect is to prefer destination/source address pairs for 232 which the two addresses are of equal scope or type, prefer smaller 233 scopes over larger scopes for the destination address, prefer non- 234 deprecated source addresses, avoid the use of transitional addresses 235 when native addresses are available, and all else being equal prefer 236 address pairs having the longest possible common prefix. For source 237 address selection, temporary addresses [RFC4941] are preferred over 238 public addresses. In mobile situations [RFC6275], home addresses are 239 preferred over care-of addresses. If an address is simultaneously a 240 home address and a care-of address (indicating the mobile node is "at 241 home" for that address), then the home/care-of address is preferred 242 over addresses that are solely a home address or solely a care-of 243 address. 245 This specification optionally allows for the possibility of 246 administrative configuration of policy (e.g., via manual 247 configuration or a DHCP option such as that proposed in 248 [I-D.ietf-6man-addr-select-opt]) that can override the default 249 behavior of the algorithms. The policy override consists of the 250 following set of state, which SHOULD be configurable: 252 o Policy Table (Section 2.1): a table that specifies precedence 253 values and preferred source prefixes for destination prefixes. 254 o Automatic Row Additions flag (Section 2.1): a flag that specifies 255 whether the implementation is permitted to automatically add site- 256 specific rows for certain types of addresses. 257 o Privacy Preference flag (Section 5): a flag that specifies whether 258 temporary source addresses or stable source addresses are 259 preferred by default, when both types exist. 261 2.1. Policy Table 263 The policy table is a longest-matching-prefix lookup table, much like 264 a routing table. Given an address A, a lookup in the policy table 265 produces two values: a precedence value Precedence(A) and a 266 classification or label Label(A). 268 The precedence value Precedence(A) is used for sorting destination 269 addresses. If Precedence(A) > Precedence(B), we say that address A 270 has higher precedence than address B, meaning that our algorithm will 271 prefer to sort destination address A before destination address B. 273 The label value Label(A) allows for policies that prefer a particular 274 source address prefix for use with a destination address prefix. The 275 algorithms prefer to use a source address S with a destination 276 address D if Label(S) = Label(D). 278 IPv6 implementations SHOULD support configurable address selection 279 via a mechanism at least as powerful as the policy tables defined 280 here. It is important that implementations provide a way to change 281 the default policies as more experience is gained. Sections 10.3 282 through 10.7 provide examples of the kind of changes that might be 283 needed. 285 If an implementation is not configurable or has not been configured, 286 then it SHOULD operate according to the algorithms specified here in 287 conjunction with the following default policy table: 289 Prefix Precedence Label 290 ::1/128 50 0 291 ::/0 40 1 292 ::ffff:0:0/96 35 4 293 2002::/16 30 2 294 2001::/32 5 5 295 fc00::/7 3 13 296 ::/96 1 3 297 fec0::/10 1 11 298 3ffe::/16 1 12 300 An implementation MAY automatically add additional site-specific rows 301 to the default table based on its configured addresses, such as for 302 Unique Local Addresses (ULAs) [RFC4193] and 6to4 [RFC3056] addresses 303 for instance (see Section 10.6 and Section 10.7 for examples). Any 304 such rows automatically added by the implementation as a result of 305 address acquisition MUST NOT override a row for the same prefix 306 configured via other means. That is, rows can be added but never 307 updated automatically. An implementation SHOULD provide a means (the 308 Automatic Row Additions flag) for an administrator to disable 309 automatic row additions. 311 As will become apparent later, one effect of the default policy table 312 is to prefer using native source addresses with native destination 313 addresses, 6to4 source addresses with 6to4 destination addresses, 314 etc. Another effect of the default policy table is to prefer 315 communication using IPv6 addresses to communication using IPv4 316 addresses, if matching source addresses are available. 318 Policy table entries for address prefixes that are not of global 319 scope MAY be qualified with an optional zone index. If so, a prefix 320 table entry only matches against an address during a lookup if the 321 zone index also matches the address's zone index. 323 2.2. Common Prefix Length 325 We define the common prefix length CommonPrefixLen(S, D) of a source 326 address S and a destination address D as the length of the longest 327 prefix (looking at the most significant, or leftmost, bits) that the 328 two addresses have in common, up to the length of S's prefix (i.e., 329 the portion of the address not including the interface ID). For 330 example, CommonPrefixLen(fe80::1, fe80::2) is 64. 332 3. Address Properties 334 In the rules given in later sections, addresses of different types 335 (e.g., IPv4, IPv6, multicast and unicast) are compared against each 336 other. Some of these address types have properties that aren't 337 directly comparable to each other. For example, IPv6 unicast 338 addresses can be "preferred" or "deprecated" [RFC4862], while IPv4 339 addresses have no such notion. To compare such addresses using the 340 ordering rules (e.g., to use "preferred" addresses in preference to 341 "deprecated" addresses), the following mappings are defined. 343 3.1. Scope Comparisons 345 Multicast destination addresses have a 4-bit scope field that 346 controls the propagation of the multicast packet. The IPv6 347 addressing architecture defines scope field values for interface- 348 local (0x1), link-local (0x2), admin-local (0x4), site-local (0x5), 349 organization-local (0x8), and global (0xE) scopes ([RFC4291] Section 350 2.7). 352 Use of the source address selection algorithm in the presence of 353 multicast destination addresses requires the comparison of a unicast 354 address scope with a multicast address scope. We map unicast link- 355 local to multicast link-local, unicast site-local to multicast site- 356 local, and unicast global scope to multicast global scope. For 357 example, unicast site-local is equal to multicast site-local, which 358 is smaller than multicast organization-local, which is smaller than 359 unicast global, which is equal to multicast global. (Note that IPv6 360 site-local unicast addresses are deprecated [RFC4291]. However, some 361 existing implementations and deployments may still use these 362 addresses and, therefore, they are included in the procedures in this 363 specification. Also note that ULAs are considered as global, not 364 site-local, scope but are handled via the prefix policy table as 365 discussed in Section 10.6.) 367 We write Scope(A) to mean the scope of address A. For example, if A 368 is a link-local unicast address and B is a site-local multicast 369 address, then Scope(A) < Scope(B). 371 This mapping implicitly conflates unicast site boundaries and 372 multicast site boundaries [RFC4007]. 374 3.2. IPv4 Addresses and IPv4-Mapped Addresses 376 The destination address selection algorithm operates on both IPv6 and 377 IPv4 addresses. For this purpose, IPv4 addresses MUST be represented 378 as IPv4-mapped addresses [RFC4291]. For example, to lookup the 379 precedence or other attributes of an IPv4 address in the policy 380 table, lookup the corresponding IPv4-mapped IPv6 address. 382 IPv4 addresses are assigned scopes as follows. IPv4 auto- 383 configuration addresses [RFC3927], which have the prefix 169.254/16, 384 are assigned link-local scope. IPv4 loopback addresses ([RFC1918], 385 section 4.2.2.11), which have the prefix 127/8, are assigned link- 386 local scope (analogously to the treatment of the IPv6 loopback 387 address ([RFC4007], section 4)). Other IPv4 addresses (including 388 IPv4 private addresses [RFC1918] and Shared Address Space addresses 389 [RFC6598]) are assigned global scope. 391 IPv4 addresses MUST be treated as having "preferred" (in the RFC 4862 392 sense) configuration status. 394 3.3. Other IPv6 Addresses with Embedded IPv4 Addresses 396 IPv4-compatible addresses [RFC4291], IPv4-mapped [RFC4291], IPv4- 397 converted [RFC6145], IPv4-translatable [RFC6145], and 6to4 addresses 398 [RFC3056] contain an embedded IPv4 address. For the purposes of this 399 document, these addresses MUST be treated as having global scope. 401 IPv4-compatible, IPv4-mapped, and IPv4-converted addresses MUST be 402 treated as having "preferred" (in the RFC 4862 sense) configuration 403 status. 405 3.4. IPv6 Loopback Address and Other Format Prefixes 407 The loopback address MUST be treated as having link-local scope 408 ([RFC4007], section 4) and "preferred" (in the RFC 4862 sense) 409 configuration status. 411 NSAP addresses and other addresses with as-yet-undefined format 412 prefixes MUST be treated as having global scope and "preferred" (in 413 the RFC 4862) configuration status. Later standards might supersede 414 this treatment. 416 3.5. Mobility Addresses 418 Some nodes might support mobility using the concepts of home address 419 and care-of address (for example see [RFC6275]). Conceptually, a 420 home address is an IP address assigned to a mobile node and used as 421 the permanent address of the mobile node. A care-of address is an IP 422 address associated with a mobile node while visiting a foreign link. 423 When a mobile node is on its home link, it might have an address that 424 is simultaneously a home address and a care-of address. 426 For the purposes of this document, it is sufficient to know whether 427 one's own addresses are designated as home addresses or care-of 428 addresses. Whether an address ought to be designated a home address 429 or care-of address is outside the scope of this document. 431 4. Candidate Source Addresses 433 The source address selection algorithm uses the concept of a 434 "candidate set" of potential source addresses for a given destination 435 address. The candidate set is the set of all addresses that could be 436 used as a source address; the source address selection algorithm will 437 pick an address out of that set. We write CandidateSource(A) to 438 denote the candidate set for the address A. 440 It is RECOMMENDED that the candidate source addresses be the set of 441 unicast addresses assigned to the interface that will be used to send 442 to the destination (the "outgoing" interface). On routers, the 443 candidate set MAY include unicast addresses assigned to any interface 444 that forwards packets, subject to the restrictions described below. 445 Implementations that wish to support the use of global source 446 addresses assigned to a loopback interface MUST behave as if the 447 loopback interface originates and forwards the packet. 449 Discussion: The Neighbor Discovery Redirect mechanism [RFC4861] 450 requires that routers verify that the source address of a packet 451 identifies a neighbor before generating a Redirect, so it is 452 advantageous for hosts to choose source addresses assigned to the 453 outgoing interface. 455 In some cases the destination address might be qualified with a zone 456 index or other information that will constrain the candidate set. 458 For all multicast and link-local destination addresses, the set of 459 candidate source addresses MUST only include addresses assigned to 460 interfaces belonging to the same link as the outgoing interface. 462 Discussion: The restriction for multicast destination addresses is 463 necessary because currently-deployed multicast forwarding 464 algorithms use Reverse Path Forwarding (RPF) checks. 466 For site-local unicast destination addresses, the set of candidate 467 source addresses MUST only include addresses assigned to interfaces 468 belonging to the same site as the outgoing interface. 470 In any case, multicast addresses, and the unspecified address MUST 471 NOT be included in a candidate set. 473 On IPv6-only nodes that support Stateless IP/ICMP Translation (SIIT) 474 [RFC6145], if the destination address is an IPv4-converted address 475 then the candidate set MUST contain only IPv4-translatable addresses. 477 If an application or upper layer specifies a source address, it may 478 affect the choice of outgoing interface. Regardless, if the 479 application or upper layer specifies a source address that is not in 480 the candidate set for the destination, then the network layer MUST 481 treat this as an error. If the application or upper layer specifies 482 a source address that is in the candidate set for the destination, 483 then the network layer MUST respect that choice. If the application 484 or upper layer does not specify a source address, then the network 485 layer uses the source address selection algorithm specified in the 486 next section. 488 5. Source Address Selection 490 The source address selection algorithm produces as output a single 491 source address for use with a given destination address. This 492 algorithm only applies to IPv6 destination addresses, not IPv4 493 addresses. 495 The algorithm is specified here in terms of a list of pair-wise 496 comparison rules that (for a given destination address D) imposes a 497 "greater than" ordering on the addresses in the candidate set 498 CandidateSource(D). The address at the front of the list after the 499 algorithm completes is the one the algorithm selects. 501 Note that conceptually, a sort of the candidate set is being 502 performed, where a set of rules define the ordering among addresses. 503 But because the output of the algorithm is a single source address, 504 an implementation need not actually sort the set; it need only 505 identify the "maximum" value that ends up at the front of the sorted 506 list. 508 The ordering of the addresses in the candidate set is defined by a 509 list of eight pair-wise comparison rules, with each rule placing a 510 "greater than," "less than" or "equal to" ordering on two source 511 addresses with respect to each other (and that rule). In the case 512 that a given rule produces a tie, i.e., provides an "equal to" result 513 for the two addresses, the remaining rules MUST be applied (in order) 514 to just those addresses that are tied to break the tie. Note that if 515 a rule produces a single clear "winner" (or set of "winners" in the 516 case of ties), those addresses not in the winning set can be 517 discarded from further consideration, with subsequent rules applied 518 only to the remaining addresses. If the eight rules fail to choose a 519 single address, the tie-breaker is implementation-specific. 521 When comparing two addresses SA and SB from the candidate set, we say 522 "prefer SA" to mean that SA is "greater than" SB, and similarly we 523 say "prefer SB" to mean that SA is "less than" SB. If neither is 524 stated to be preferred, this means that SA is "equal to" SB and the 525 remaining rules apply as noted above. 527 Rule 1: Prefer same address. 528 If SA = D, then prefer SA. Similarly, if SB = D, then prefer SB. 530 Rule 2: Prefer appropriate scope. 531 If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB and 532 otherwise prefer SA. Similarly, if Scope(SB) < Scope(SA): If 533 Scope(SB) < Scope(D), then prefer SA and otherwise prefer SB. 535 Discussion: This rule must be given high priority because it can 536 affect interoperability. 538 Rule 3: Avoid deprecated addresses. 539 If one of the two source addresses is "preferred" and one of them is 540 "deprecated" (in the RFC 4862 sense), then prefer the one that is 541 "preferred." 543 Rule 4: Prefer home addresses. 544 If SA is simultaneously a home address and care-of address and SB is 545 not, then prefer SA. Similarly, if SB is simultaneously a home 546 address and care-of address and SA is not, then prefer SB. If SA is 547 just a home address and SB is just a care-of address, then prefer SA. 548 Similarly, if SB is just a home address and SA is just a care-of 549 address, then prefer SB. 551 Implementations supporting home addresses MUST provide a mechanism 552 allowing an application to reverse the sense of this preference and 553 prefer care-of addresses over home addresses (e.g., via appropriate 554 API extensions such as [RFC5014]). Use of the mechanism MUST only 555 affect the selection rules for the invoking application. 557 Rule 5: Prefer outgoing interface. 558 If SA is assigned to the interface that will be used to send to D and 559 SB is assigned to a different interface, then prefer SA. Similarly, 560 if SB is assigned to the interface that will be used to send to D and 561 SA is assigned to a different interface, then prefer SB. 563 Rule 5.5: Prefer addresses in a prefix advertised by the next-hop 564 If SA or SA's prefix is assigned by the selected next-hop that will 565 be used to send to D and SB or SB's prefix is assigned by a different 566 next-hop, then prefer SA. Similarly, if SB or SB's prefix is 567 assigned by the next-hop that will be used to send to D and SA or 568 SA's prefix is assigned by a different next-hop, then prefer SB. 570 Discussion: An IPv6 implementation is not required to remember 571 which next-hops advertised which prefixes. The conceptual models 572 of IPv6 hosts in Section 5 of [RFC4861] and Section 3 of [RFC4191] 573 have no such requirement. Hence rule 5.5 is only applicable to 574 implementations that track this information. 576 Rule 6: Prefer matching label. 577 If Label(SA) = Label(D) and Label(SB) <> Label(D), then prefer SA. 578 Similarly, if Label(SB) = Label(D) and Label(SA) <> Label(D), then 579 prefer SB. 581 Rule 7: Prefer temporary addresses. 582 If SA is a temporary address and SB is a public address, then prefer 583 SA. Similarly, if SB is a temporary address and SA is a public 584 address, then prefer SB. 586 Implementations MUST provide a mechanism allowing an application to 587 reverse the sense of this preference and prefer public addresses over 588 temporary addresses (e.g., via appropriate API extensions such as 589 [RFC5014]). Use of the mechanism MUST only affect the selection 590 rules for the invoking application. This default is intended to 591 address privacy concerns as discussed in [RFC4941], but introduces a 592 risk of applications potentially failing due to the relatively short 593 lifetime of temporary addresses or due to the possibility of the 594 reverse lookup of a temporary address either failing or returning a 595 randomized name. Implementations for which application compatibility 596 considerations outweigh these privacy concerns MAY reverse the sense 597 of this rule and by default prefer public addresses over temporary 598 addresses. There SHOULD be an administrative option (the Privacy 599 Preference flag) to change this preference, if the implementation 600 supports temporary addresses. If there is no such option, there MUST 601 be an administrative option to disable temporary addresses. 603 Rule 8: Use longest matching prefix. 604 If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then prefer SA. 605 Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then 606 prefer SB. 608 Rule 8 MAY be superseded if the implementation has other means of 609 choosing among source addresses. For example, if the implementation 610 somehow knows which source address will result in the "best" 611 communications performance. 613 6. Destination Address Selection 615 The destination address selection algorithm takes a list of 616 destination addresses and sorts the addresses to produce a new list. 617 It is specified here in terms of the pair-wise comparison of 618 addresses DA and DB, where DA appears before DB in the original list. 620 The algorithm sorts together both IPv6 and IPv4 addresses. To find 621 the attributes of an IPv4 address in the policy table, the IPv4 622 address MUST be represented as an IPv4-mapped address. 624 We write Source(D) to indicate the selected source address for a 625 destination D. For IPv6 addresses, the previous section specifies the 626 source address selection algorithm. Source address selection for 627 IPv4 addresses is not specified in this document. 629 We say that Source(D) is undefined if there is no source address 630 available for destination D. For IPv6 addresses, this is only the 631 case if CandidateSource(D) is the empty set. 633 The pair-wise comparison of destination addresses consists of ten 634 rules, which MUST be applied in order. If a rule determines a 635 result, then the remaining rules are not relevant and MUST be 636 ignored. Subsequent rules act as tie-breakers for earlier rules. 637 See the previous section for a lengthier description of how pair-wise 638 comparison tie-breaker rules can be used to sort a list. 640 Rule 1: Avoid unusable destinations. 641 If DB is known to be unreachable or if Source(DB) is undefined, then 642 prefer DA. Similarly, if DA is known to be unreachable or if 643 Source(DA) is undefined, then prefer DB. 645 Discussion: An implementation might know that a particular 646 destination is unreachable in several ways. For example, the 647 destination might be reached through a network interface that is 648 currently unplugged. For example, the implementation might retain 649 for some period of time information from Neighbor Unreachability 650 Detection [RFC4861]. In any case, the determination of 651 unreachability for the purposes of this rule is implementation- 652 dependent. 654 Rule 2: Prefer matching scope. 655 If Scope(DA) = Scope(Source(DA)) and Scope(DB) <> Scope(Source(DB)), 656 then prefer DA. Similarly, if Scope(DA) <> Scope(Source(DA)) and 657 Scope(DB) = Scope(Source(DB)), then prefer DB. 659 Rule 3: Avoid deprecated addresses. 660 If Source(DA) is deprecated and Source(DB) is not, then prefer DB. 661 Similarly, if Source(DA) is not deprecated and Source(DB) is 662 deprecated, then prefer DA. 664 Rule 4: Prefer home addresses. 665 If Source(DA) is simultaneously a home address and care-of address 666 and Source(DB) is not, then prefer DA. Similarly, if Source(DB) is 667 simultaneously a home address and care-of address and Source(DA) is 668 not, then prefer DB. 670 If Source(DA) is just a home address and Source(DB) is just a care-of 671 address, then prefer DA. Similarly, if Source(DA) is just a care-of 672 address and Source(DB) is just a home address, then prefer DB. 674 Rule 5: Prefer matching label. 675 If Label(Source(DA)) = Label(DA) and Label(Source(DB)) <> Label(DB), 676 then prefer DA. Similarly, if Label(Source(DA)) <> Label(DA) and 677 Label(Source(DB)) = Label(DB), then prefer DB. 679 Rule 6: Prefer higher precedence. 680 If Precedence(DA) > Precedence(DB), then prefer DA. Similarly, if 681 Precedence(DA) < Precedence(DB), then prefer DB. 683 Rule 7: Prefer native transport. 684 If DA is reached via an encapsulating transition mechanism (e.g., 685 IPv6 in IPv4) and DB is not, then prefer DB. Similarly, if DB is 686 reached via encapsulation and DA is not, then prefer DA. 688 Discussion: "IPv6 Rapid Deployment on IPv4 Infrastructures" (6rd) 689 [RFC5969], the Intra-Site Automatic Tunnel Addressing Protocol 690 (ISATAP) [RFC5214], and configured tunnels [RFC4213] are examples 691 of encapsulating transition mechanisms for which the destination 692 address does not have a specific prefix and hence can not be 693 assigned a lower precedence in the policy table. An 694 implementation MAY generalize this rule by using a concept of 695 interface preference, and giving virtual interfaces (like the 696 IPv6-in-IPv4 encapsulating interfaces) a lower preference than 697 native interfaces (like ethernet interfaces). 699 Rule 8: Prefer smaller scope. 700 If Scope(DA) < Scope(DB), then prefer DA. Similarly, if Scope(DA) > 701 Scope(DB), then prefer DB. 703 Rule 9: Use longest matching prefix. 704 When DA and DB belong to the same address family (both are IPv6 or 705 both are IPv4): If CommonPrefixLen(Source(DA), DA) > 706 CommonPrefixLen(Source(DB), DB), then prefer DA. Similarly, if 707 CommonPrefixLen(Source(DA), DA) < CommonPrefixLen(Source(DB), DB), 708 then prefer DB. 710 Rule 10: Otherwise, leave the order unchanged. 711 If DA preceded DB in the original list, prefer DA. Otherwise prefer 712 DB. 714 Rules 9 and 10 MAY be superseded if the implementation has other 715 means of sorting destination addresses. For example, if the 716 implementation somehow knows which destination addresses will result 717 in the "best" communications performance. 719 7. Interactions with Routing 721 This specification of source address selection assumes that routing 722 (more precisely, selecting an outgoing interface on a node with 723 multiple interfaces) is done before source address selection. 724 However, implementations MAY use source address considerations as a 725 tiebreaker when choosing among otherwise equivalent routes. 727 For example, suppose a node has interfaces on two different links, 728 with both links having a working default router. Both of the 729 interfaces have preferred (in the RFC 4862 sense) global addresses. 730 When sending to a global destination address, if there's no routing 731 reason to prefer one interface over the other, then an implementation 732 MAY preferentially choose the outgoing interface that will allow it 733 to use the source address that shares a longer common prefix with the 734 destination. 736 Implementations that support source address selection (Section 5) 737 Rule 5.5 also use the choice of router to influence the choice of 738 source address. For example, suppose a host is on a link with two 739 routers. One router is advertising a global prefix A and the other 740 router is advertising global prefix B. Then when sending via the 741 first router, the host might prefer source addresses with prefix A 742 and when sending via the second router, prefer source addresses with 743 prefix B. 745 8. Implementation Considerations 747 The destination address selection algorithm needs information about 748 potential source addresses. One possible implementation strategy is 749 for getaddrinfo() to call down to the network layer with a list of 750 destination addresses, sort the list in the network layer with full 751 current knowledge of available source addresses, and return the 752 sorted list to getaddrinfo(). This is simple and gives the best 753 results but it introduces the overhead of another system call. One 754 way to reduce this overhead is to cache the sorted address list in 755 the resolver, so that subsequent calls for the same name do not need 756 to resort the list. 758 Another implementation strategy is to call down to the network layer 759 to retrieve source address information and then sort the list of 760 addresses directly in the context of getaddrinfo(). To reduce 761 overhead in this approach, the source address information can be 762 cached, amortizing the overhead of retrieving it across multiple 763 calls to getaddrinfo(). In this approach, the implementation might 764 not have knowledge of the outgoing interface for each destination, so 765 it MAY use a looser definition of the candidate set during 766 destination address ordering. 768 In any case, if the implementation uses cached and possibly stale 769 information in its implementation of destination address selection, 770 or if the ordering of a cached list of destination addresses is 771 possibly stale, then it MUST ensure that the destination address 772 ordering returned to the application is no more than one second out 773 of date. For example, an implementation might make a system call to 774 check if any routing table entries or source address assignments or 775 prefix policy table entries that might affect these algorithms have 776 changed. Another strategy is to use an invalidation counter that is 777 incremented whenever any underlying state is changed. By caching the 778 current invalidation counter value with derived state and then later 779 comparing against the current value, the implementation could detect 780 if the derived state is potentially stale. 782 9. Security Considerations 784 This document has no direct impact on Internet infrastructure 785 security. 787 Note that most source address selection algorithms, including the one 788 specified in this document, expose a potential privacy concern. An 789 unfriendly node can infer correlations among a target node's 790 addresses by probing the target node with request packets that force 791 the target host to choose its source address for the reply packets. 792 (Perhaps because the request packets are sent to an anycast or 793 multicast address, or perhaps the upper-layer protocol chosen for the 794 attack does not specify a particular source address for its reply 795 packets.) By using different addresses for itself, the unfriendly 796 node can cause the target node to expose the target's own addresses. 797 The source address selection default preference for temporary 798 addresses helps mitigate this concern. 800 Similarly, most source and destination address selection algorithms, 801 including the one specified in this document, influence the choice of 802 network path taken (as do routing algorithms that are orthogonal to, 803 but used together with such algorithms) and hence whether data might 804 be sent over a path or network that might be more or less trusted 805 than other paths or networks. Administrators should consider the 806 security impact of the rows they configure in the prefix policy 807 table, just as they should consider the security impact of the 808 interface metrics used in the routing algorithms. 810 In addition, some address selection rules might be administratively 811 configurable. Care must be taken to make sure that all 812 administrative options are secured against illicit modification, or 813 else an attacker could redirect and/or block traffic. 815 10. Examples 817 This section contains a number of examples, first of default behavior 818 and then demonstrating the utility of policy table configuration. 819 These examples are provided for illustrative purposes; they are not 820 to be construed as normative. 822 10.1. Default Source Address Selection 824 The source address selection rules, in conjunction with the default 825 policy table, produce the following behavior: 827 Destination: 2001:db8:1::1 828 Candidate Source Addresses: 2001:db8:3::1 or fe80::1 829 Result: 2001:db8::1 (prefer appropriate scope) 831 Destination: ff05::1 832 Candidate Source Addresses: 2001:db8:3::1 or fe80::1 833 Result: 2001:db8:3::1 (prefer appropriate scope) 835 Destination: 2001:db8:1::1 836 Candidate Source Addresses: 2001:db8:1::1 (deprecated) or 837 2001:db8:2::1 838 Result: 2001:db8:1::1 (prefer same address) 840 Destination: fe80::1 841 Candidate Source Addresses: fe80::2 (deprecated) or 2001:db8:1::1 842 Result: fe80::2 (prefer appropriate scope) 844 Destination: 2001:db8:1::1 845 Candidate Source Addresses: 2001:db8:1::2 or 2001:db8:3::2 846 Result: 2001:db8:1:::2 (longest-matching-prefix) 848 Destination: 2001:db8:1::1 849 Candidate Source Addresses: 2001:db8:1::2 (care-of address) or 2001: 850 db8:3::2 (home address) 851 Result: 2001:db8:3::2 (prefer home address) 853 Destination: 2002:c633:6401::1 854 Candidate Source Addresses: 2002:c633:6401::d5e3:7953:13eb:22e8 855 (temporary) or 2001:db8:1::2 856 Result: 2002:c633:6401::d5e3:7953:13eb:22e8 (prefer matching label) 858 Destination: 2001:db8:1::d5e3:0:0:1 859 Candidate Source Addresses: 2001:db8:1::2 or 2001:db8:1::d5e3:7953: 861 13eb:22e8 (temporary) 862 Result: 2001:db8:1::2 (prefer public address) 864 10.2. Default Destination Address Selection 866 The destination address selection rules, in conjunction with the 867 default policy table and the source address selection rules, produce 868 the following behavior: 870 Candidate Source Addresses: 2001:db8:1::2 or fe80::1 or 169.254.13.78 871 Destination Address List: 2001:db8:1::1 or 198.51.100.121 872 Result: 2001:db8:1::1 (src 2001:db8:1::2) then 198.51.100.121 (src 873 169.254.13.78) (prefer matching scope) 875 Candidate Source Addresses: fe80::1 or 198.51.100.117 876 Destination Address List: 2001:db8:1::1 or 198.51.100.121 877 Result: 198.51.100.121 (src 198.51.100.117) then 2001:db8:1::1 (src 878 fe80::1) (prefer matching scope) 880 Candidate Source Addresses: 2001:db8:1::2 or fe80::1 or 10.1.2.4 881 Destination Address List: 2001:db8:1::1 or 10.1.2.3 882 Result: 2001:db8:1::1 (src 2001:db8:1::2) then 10.1.2.3 (src 883 10.1.2.4) (prefer higher precedence) 885 Candidate Source Addresses: 2001:db8:1::2 or fe80::2 886 Destination Address List: 2001:db8:1::1 or fe80::1 887 Result: fe80::1 (src fe80::2) then 2001:db8:1::1 (src 2001:db8:1::2) 888 (prefer smaller scope) 890 Candidate Source Addresses: 2001:db8:1::2 (care-of address) or 2001: 891 db8:3::1 (home address) or fe80::2 (care-of address) 892 Destination Address List: 2001:db8:1::1 or fe80::1 893 Result: 2001:db8:1::1 (src 2001:db8:3::1) then fe80::1 (src fe80::2) 894 (prefer home address) 896 Candidate Source Addresses: 2001:db8:1::2 or fe80::2 (deprecated) 897 Destination Address List: 2001:db8:1::1 or fe80::1 898 Result: 2001:db8:1::1 (src 2001:db8:1::2) then fe80::1 (src fe80::2) 899 (avoid deprecated addresses) 901 Candidate Source Addresses: 2001:db8:1::2 or 2001:db8:3f44::2 or 902 fe80::2 903 Destination Address List: 2001:db8:1::1 or 2001:db8:3ffe::1 904 Result: 2001:db8:1::1 (src 2001:db8:1::2) then 2001:db8:3ffe::1 (src 905 2001:db8:3f44::2) (longest matching prefix) 907 Candidate Source Addresses: 2002:c633:6401::2 or fe80::2 908 Destination Address List: 2002:c633:6401::1 or 2001:db8:1::1 909 Result: 2002:c633:6401::1 (src 2002:c633:6401::2) then 2001:db8:1::1 910 (src 2002:c633:6401::2) (prefer matching label) 912 Candidate Source Addresses: 2002:c633:6401::2 or 2001:db8:1::2 or 913 fe80::2 914 Destination Address List: 2002:c633:6401::1 or 2001:db8:1::1 915 Result: 2001:db8:1::1 (src 2001:db8:1::2) then 2002:c633:6401::1 (src 916 2002:c633:6401::2) (prefer higher precedence) 918 10.3. Configuring Preference for IPv6 or IPv4 920 The default policy table gives IPv6 addresses higher precedence than 921 IPv4 addresses. This means that applications will use IPv6 in 922 preference to IPv4 when the two are equally suitable. An 923 administrator can change the policy table to prefer IPv4 addresses by 924 giving the ::ffff:0.0.0.0/96 prefix a higher precedence: 926 Prefix Precedence Label 927 ::1/128 50 0 928 ::/0 40 1 929 ::ffff:0:0/96 100 4 930 2002::/16 30 2 931 2001::/32 5 5 932 fc00::/7 3 13 933 ::/96 1 3 934 fec0::/10 1 11 935 3ffe::/16 1 12 937 This change to the default policy table produces the following 938 behavior: 940 Candidate Source Addresses: 2001:db8::2 or fe80::1 or 169.254.13.78 941 Destination Address List: 2001:db8::1 or 198.51.100.121 942 Unchanged Result: 2001:db8::1 (src 2001:db8::2) then 198.51.100.121 943 (src 169.254.13.78) (prefer matching scope) 945 Candidate Source Addresses: fe80::1 or 198.51.100.117 946 Destination Address List: 2001:db8::1 or 198.51.100.121 947 Unchanged Result: 198.51.100.121 (src 198.51.100.117) then 948 2001:db8::1 (src fe80::1) (prefer matching scope) 950 Candidate Source Addresses: 2001:db8::2 or fe80::1 or 10.1.2.4 951 Destination Address List: 2001:db8::1 or 10.1.2.3 952 New Result: 10.1.2.3 (src 10.1.2.4) then 2001:db8::1 (src 953 2001:db8::2) (prefer higher precedence) 955 10.3.1. Handling Broken IPv6 957 One problem in practice that has been recently observed occurs when a 958 host has IPv4 connectivity to the Internet, but has "broken" IPv6 959 connectivity to the Internet in that it has a global IPv6 address, 960 but is discconnected from the IPv6 Internet. Since the default 961 policy table prefers IPv6, this can result in unwanted timeouts. 963 This can be solved by configuring the table to prefer IPv4 as shown 964 above. An implementation that has some means to detect that it is 965 not connected to the IPv6 Internet MAY do this automatically. An 966 implementation could instead treat it as part of its implementation 967 of Rule 1 (avoid unusable destinations). 969 10.4. Configuring Preference for Link-Local Addresses 971 The destination address selection rules give preference to 972 destinations of smaller scope. For example, a link-local destination 973 will be sorted before a global scope destination when the two are 974 otherwise equally suitable. An administrator can change the policy 975 table to reverse this preference and sort global destinations before 976 link-local destinations: 978 Prefix Precedence Label 979 ::1/128 50 0 980 ::/0 40 1 981 ::ffff:0:0/96 35 4 982 fe80::/10 33 1 983 2002::/16 30 2 984 2001::/32 5 5 985 fc00::/7 3 13 986 ::/96 1 3 987 fec0::/10 1 11 988 3ffe::/16 1 12 990 This change to the default policy table produces the following 991 behavior: 993 Candidate Source Addresses: 2001:db8::2 or fe80::2 994 Destination Address List: 2001:db8::1 or fe80::1 995 New Result: 2001:db8::1 (src 2001:db8::2) then fe80::1 (src fe80::2) 996 (prefer higher precedence) 998 Candidate Source Addresses: 2001:db8::2 (deprecated) or fe80::2 999 Destination Address List: 2001:db8::1 or fe80::1 1000 Unchanged Result: fe80::1 (src fe80::2) then 2001:db8::1 (src 2001: 1001 db8::2) (avoid deprecated addresses) 1003 10.5. Configuring a Multi-Homed Site 1005 Consider a site A that has a business-critical relationship with 1006 another site B. To support their business needs, the two sites have 1007 contracted for service with a special high-performance ISP. This is 1008 in addition to the normal Internet connection that both sites have 1009 with different ISPs. The high-performance ISP is expensive and the 1010 two sites wish to use it only for their business-critical traffic 1011 with each other. 1013 Each site has two global prefixes, one from the high-performance ISP 1014 and one from their normal ISP. Site A has prefix 2001:db8:1aaa::/48 1015 from the high-performance ISP and prefix 2001:db8:70aa::/48 from its 1016 normal ISP. Site B has prefix 2001:db8:1bbb::/48 from the high- 1017 performance ISP and prefix 2001:db8:70bb::/48 from its normal ISP. 1018 All hosts in both sites register two addresses in the DNS. 1020 The routing within both sites directs most traffic to the egress to 1021 the normal ISP, but the routing directs traffic sent to the other 1022 site's 2001 prefix to the egress to the high-performance ISP. To 1023 prevent unintended use of their high-performance ISP connection, the 1024 two sites implement ingress filtering to discard traffic entering 1025 from the high-performance ISP that is not from the other site. 1027 The default policy table and address selection rules produce the 1028 following behavior: 1030 Candidate Source Addresses: 2001:db8:1aaa::a or 2001:db8:70aa::a or 1031 fe80::a 1032 Destination Address List: 2001:db8:1bbb::b or 2001:db8:70bb::b 1033 Result: 2001:db8:70bb::b (src 2001:db8:70aa::a) then 2001:db8:1bbb::b 1034 (src 2001:db8:1aaa::a) (longest matching prefix) 1036 In other words, when a host in site A initiates a connection to a 1037 host in site B, the traffic does not take advantage of their 1038 connections to the high-performance ISP. This is not their desired 1039 behavior. 1041 Candidate Source Addresses: 2001:db8:1aaa::a or 2001:db8:70aa::a or 1042 fe80::a 1043 Destination Address List: 2001:db8:1ccc::c or 2001:db8:6ccc::c 1044 Result: 2001:db8:1ccc::c (src 2001:db8:1aaa::a) then 2001:db8:6ccc::c 1045 (src 2001:db8:70aa::a) (longest matching prefix) 1047 In other words, when a host in site A initiates a connection to a 1048 host in some other site C, the reverse traffic might come back 1049 through the high-performance ISP. Again, this is not their desired 1050 behavior. 1052 This predicament demonstrates the limitations of the longest- 1053 matching-prefix heuristic in multi-homed situations. 1055 However, the administrators of sites A and B can achieve their 1056 desired behavior via policy table configuration. For example, they 1057 can use the following policy table: 1059 Prefix Precedence Label 1060 ::1/128 50 0 1061 2001:db8:1aaa::/48 43 6 1062 2001:db8:1bbb::/48 43 6 1063 ::/0 40 1 1064 ::ffff:0:0/96 35 4 1065 2002::/16 30 2 1066 2001::/32 5 5 1067 fc00::/7 3 13 1068 ::/96 1 3 1069 fec0::/10 1 11 1070 3ffe::/16 1 12 1072 This policy table produces the following behavior: 1074 Candidate Source Addresses: 2001:db8:1aaa::a or 2001:db8:70aa::a or 1075 fe80::a 1076 Destination Address List: 2001:db8:1bbb::b or 2001:db8:70bb::b 1077 New Result: 2001:db8:1bbb::b (src 2001:db8:1aaa::a) then 2001:db8: 1078 70bb::b (src 2001:db8:70aa::a) (prefer higher precedence) 1080 In other words, when a host in site A initiates a connection to a 1081 host in site B, the traffic uses the high-performance ISP as desired. 1083 Candidate Source Addresses: 2001:db8:1aaa::a or 2001:db8:70aa::a or 1084 fe80::a 1085 Destination Address List: 2001:db8:1ccc::c or 2001:db8:6ccc::c 1086 New Result: 2001:db8:6ccc::c (src 2001:db8:70aa::a) then 2001:db8: 1087 1ccc::c (src 2001:db8:70aa::a) (longest matching prefix) 1089 In other words, when a host in site A initiates a connection to a 1090 host in some other site C, the traffic uses the normal ISP as 1091 desired. 1093 10.6. Configuring ULA Preference 1095 RFC 5220 [RFC5220] sections 2.1.4, 2.2.2, and 2.2.3 describe address 1096 selection problems related to Unique Local Addresses (ULAs) 1097 [RFC4193]. By default, global IPv6 destinations are preferred over 1098 ULA destinations, since an arbitrary ULA is not necessarily 1099 reachable: 1101 Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1 1102 Destination Address List: 2001:db8:2::2 or fd22:2222:2222:2::2 1103 Result: 2001:db8:2::2 (src 2001:db8:1::1) then fd22:2222:2222:2::2 1104 (src fd11:1111:1111:1::1) (prefer higher precedence) 1106 However, a site-specific policy entry can be used to cause ULAs 1107 within a site to be preferred over global addresses as follows. 1109 Prefix Precedence Label 1110 ::1/128 50 0 1111 fd11:1111:1111::/48 45 14 1112 ::/0 40 1 1113 ::ffff:0:0/96 35 4 1114 2002::/16 30 2 1115 2001::/32 5 5 1116 fc00::/7 3 13 1117 ::/96 1 3 1118 fec0::/10 1 11 1119 3ffe::/16 1 12 1121 Such a configuration would have the following effect: 1123 Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1 1124 Destination Address List: 2001:db8:2::2 or fd22:2222:2222:2::2 1125 Unchanged Result: 2001:db8:2::2 (src 2001:db8:1::1) then fd22:2222: 1126 2222:2::2 (src fd11:1111:1111:1::1) (prefer higher precedence) 1128 Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1 1129 Destination Address List: 2001:db8:2::2 or fd11:1111:1111:2::2 1130 New Result: fd11:1111:1111:2::2 (src fd11:1111:1111:1::1) then 2001: 1131 db8:2::2 (src 2001:db8:1::1) (prefer higher precedence) 1133 Since ULAs are defined to have a /48 site prefix, an implementation 1134 might choose to add such a row automatically on a machine with a ULA. 1136 It is also worth noting that ULAs are assigned global scope. As 1137 such, the existence of one or more rows in the prefix policy table is 1138 important so that source address selection does not choose a ULA 1139 purely based on longest match: 1141 Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1 1142 Destination Address List: ff00:1 1143 Result: 2001:db8:1::1 (prefer matching label) 1145 10.7. Configuring 6to4 Preference 1147 By default, NAT'ed IPv4 is preferred over 6to4-relayed connectivity: 1149 Candidate Source Addresses: 2002:c633:6401::2 or 10.1.2.3 1150 Destination Address List: 2001:db8:1::1 or 203.0.113.1 1151 Result: 203.0.113.1 (src 10.1.2.3) then 2001:db8:1::1 (src 2002:c633: 1152 6401::2) (prefer matching label) 1154 However, NAT'ed IPv4 is now also preferred over 6to4-to-6to4 1155 connectivity by default. Since a 6to4 prefix might be used natively 1156 within an organization, a site-specific policy entry can be used to 1157 cause native IPv6 communication (using a 6to4 prefix) to be preferred 1158 over NAT'ed IPv4 as follows. 1160 Prefix Precedence Label 1161 ::1/128 50 0 1162 2002:c633:6401::/48 45 14 1163 ::/0 40 1 1164 ::ffff:0:0/96 35 4 1165 2002::/16 30 2 1166 2001::/32 5 5 1167 fc00::/7 3 13 1168 ::/96 1 3 1169 fec0::/10 1 11 1170 3ffe::/16 1 12 1172 Such a configuration would have the following effect: 1174 Candidate Source Addresses: 2002:c633:6401:1::1 or 10.1.2.3 1175 Destination Address List: 2002:c633:6401:2::2 or 203.0.113.1 1176 New Result: 2002:c633:6401:2::2 (src 2002:c633:6401:1::1) then 1177 203.0.113.1 (sec 10.1.2.3) (prefer higher precedence) 1179 Since 6to4 addresses are defined to have a /48 site prefix, an 1180 implementation might choose to add such a row automatically on a 1181 machine with a native IPv6 address with a 6to4 prefix. 1183 11. IANA Considerations 1185 This document has no IANA actions. 1187 12. References 1189 12.1. Normative References 1191 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1192 Requirement Levels", BCP 14, RFC 2119, March 1997. 1194 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1195 via IPv4 Clouds", RFC 3056, February 2001. 1197 [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local 1198 Addresses", RFC 3879, September 2004. 1200 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1201 Addresses", RFC 4193, October 2005. 1203 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1204 Architecture", RFC 4291, February 2006. 1206 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1207 Network Address Translations (NATs)", RFC 4380, 1208 February 2006. 1210 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1211 Address Autoconfiguration", RFC 4862, September 2007. 1213 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1214 Extensions for Stateless Address Autoconfiguration in 1215 IPv6", RFC 4941, September 2007. 1217 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 1218 Algorithm", RFC 6145, April 2011. 1220 12.2. Informative References 1222 [I-D.ietf-6man-addr-select-opt] 1223 Matsumoto, A., Fujisaki, T., Kato, J., and T. Chown, 1224 "Distributing Address Selection Policy using DHCPv6", 1225 draft-ietf-6man-addr-select-opt-03 (work in progress), 1226 February 2012. 1228 [RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794, 1229 April 1995. 1231 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1232 E. Lear, "Address Allocation for Private Internets", 1233 BCP 5, RFC 1918, February 1996. 1235 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1236 Defeating Denial of Service Attacks which employ IP Source 1237 Address Spoofing", BCP 38, RFC 2827, May 2000. 1239 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 1240 Stevens, "Basic Socket Interface Extensions for IPv6", 1241 RFC 3493, February 2003. 1243 [RFC3701] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address 1244 Allocation) Phaseout", RFC 3701, March 2004. 1246 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 1247 Configuration of IPv4 Link-Local Addresses", RFC 3927, 1248 May 2005. 1250 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 1251 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 1252 March 2005. 1254 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1255 More-Specific Routes", RFC 4191, November 2005. 1257 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1258 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1260 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1261 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1262 September 2007. 1264 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 1265 Socket API for Source Address Selection", RFC 5014, 1266 September 2007. 1268 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1269 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1270 March 2008. 1272 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 1273 "Problem Statement for Default Address Selection in Multi- 1274 Prefix Environments: Operational Issues of RFC 3484 1275 Default Rules", RFC 5220, July 2008. 1277 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 1278 Infrastructures (6rd) -- Protocol Specification", 1279 RFC 5969, August 2010. 1281 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 1282 in IPv6", RFC 6275, July 2011. 1284 [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 1285 M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address 1286 Space", BCP 153, RFC 6598, April 2012. 1288 Appendix A. Acknowledgements 1290 RFC 3484 acknowledged the contributions of the IPng Working Group, 1291 particularly Marc Blanchet, Brian Carpenter, Matt Crawford, Alain 1292 Durand, Steve Deering, Robert Elz, Jun-ichiro itojun Hagino, Tony 1293 Hain, M.T. Hollinger, JINMEI Tatuya, Thomas Narten, Erik Nordmark, 1294 Ken Powell, Markku Savela, Pekka Savola, Hesham Soliman, Dave Thaler, 1295 Mauro Tortonesi, Ole Troan, and Stig Venaas. In addition, the 1296 anonymous IESG reviewers had many great comments and suggestions for 1297 clarification. 1299 This revision was heavily influenced by the work by Arifumi 1300 Matsumoto, Jun-ya Kato, and Tomohiro Fujisaki in a working draft that 1301 made proposals for this revision to adopt, with input from Pekka 1302 Savola, Remi Denis-Courmont, Francois-Xavier Le Bail, and the 6man 1303 Working Group. Dmitry Anipko, Mark Andrews, Ray Hunter, and Wes 1304 George also provided valuable feedback on this revision. 1306 Appendix B. Changes Since RFC 3484 1308 Some changes were made to the default policy table that were deemed 1309 to be universally useful and cause no harm in every reasonable 1310 network environment. In doing so, care was taken to use the same 1311 preference and label values as in RFC 3484 whenever possible, and for 1312 new rows to use label values less likely to collide with values that 1313 might already be in use in additional rows on some hosts. These 1314 changes are: 1316 1. Added the Teredo [RFC4380] prefix (2001::/32), with the 1317 preference and label values already widely used in popular 1318 implementations. 1319 2. Added a row for ULAs (fc00::/7) below native IPv6 since they are 1320 not globally reachable, as discussed in Section 10.6. 1321 3. Added a row for site-local addresses (fec0::/10) in order to 1322 depreference them, for consistency with the example in 1323 Section 10.3, since they are deprecated [RFC3879]. 1324 4. Depreferenced 6to4 (2002::/32) below native IPv4 since 6to4 1325 connectivity is less reliable today (and is expected to be phased 1326 out over time, rather than becoming more reliable). It remains 1327 above Teredo since 6to4 is more efficient in terms of connection 1328 establishment time, bandwidth, and server load. 1329 5. Depreferenced IPv4-Compatible addresses (::/96) since they are 1330 now deprecated [RFC4291] and not in common use. 1331 6. Added a row for 6bone testing addresses (3ffe::/16) in order to 1332 depreference them as they have also been phased out [RFC3701]. 1334 7. Added optional ability for an implementation to add automatic 1335 rows to the table for site-specific ULA prefixes and site- 1336 specific native 6to4 prefixes. 1338 Similarly, some changes were made to the rules, as follows: 1340 1. Changed the definition of CommonPrefixLen() to only compare bits 1341 up to the source address's prefix length. The previous 1342 definition used the entire source address, rather than only its 1343 prefix. As a result, when a source and destination addresses had 1344 the same prefix, common bits in the interface ID would previously 1345 result in overriding DNS load balancing [RFC1794] by forcing the 1346 destination address with the most bits in common to be always 1347 chosen. The updated definition allows DNS load balancing to 1348 continue to be used as a tie breaker. 1349 2. Added Rule 5.5 to allow choosing a source address from a prefix 1350 advertised by the chosen next-hop for a given destination. This 1351 allows better connectivity in the presence of BCP 38 [RFC2827] 1352 ingress filtering and egress filtering. Previously, RFC 3484 had 1353 issues with multiple egress networks reached via the same 1354 interface, as discussed in [RFC5220]. 1355 3. Removed restriction against anycast addresses in the candidate 1356 set of source addresses, since the restriction against using IPv6 1357 anycast addresses as source addresses was removed in Section 2.6 1358 of RFC 4291 [RFC4291]. 1359 4. Changed mapping of RFC 1918 [RFC1918] addresses to global scope 1360 in Section 3.2. Previously they were mapped to site-local scope. 1361 However, experience has resulted in current implementations 1362 already using global scope instead. When they were mapped to 1363 site-local, Destination Address Selection Rule 2 (Prefer matching 1364 scope) would cause IPv6 to be preferred in scenarios such as that 1365 described in Section 10.7. The change to global scope allows 1366 configurability via the prefix policy table. 1367 5. Changed the default recommendation for Source Address Selection 1368 Rule 7 to prefer temporary addresses rather than public 1369 addresses, while providing an administrative override (in 1370 addition to the application-specific override that was already 1371 specified). This change was made because of the increasing 1372 importance of privacy considerations, as well as the fact that 1373 widely deployed implementations have preferred temporary 1374 addresses for many years without major application issues. 1376 Finally, some editorial changes were made, including: 1378 1. Changed global IP addresses in examples to use ranges reserved 1379 for documentation. 1381 2. Added additional examples in Section 10.6 and Section 10.7. 1382 3. Added Section 10.3.1 on "broken" IPv6. 1383 4. Updated references. 1385 Authors' Addresses 1387 Dave Thaler (editor) 1388 Microsoft 1389 One Microsoft Way 1390 Redmond, WA 98052 1392 Phone: +1 425 703 8835 1393 Email: dthaler@microsoft.com 1395 Richard Draves 1396 Microsoft Research 1397 One Microsoft Way 1398 Redmond, WA 98052 1400 Phone: +1 425 706 2268 1401 Email: richdr@microsoft.com 1403 Arifumi Matsumoto 1404 NTT SI Lab 1405 Midori-Cho 3-9-11 1406 Musashino-shi, Tokyo 180-8585 1407 Japan 1409 Phone: +81 422 59 3334 1410 Email: arifumi@nttv6.net 1412 Tim Chown 1413 University of Southampt on 1414 Southampton, Hampshire SO17 1BJ 1415 United Kingdom 1417 Email: tjc@ecs.soton.ac.uk