idnits 2.17.1 draft-ietf-6man-rfc3484bis-05.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 (May 31, 2012) is 4348 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 2, 2012 A. Matsumoto 7 NTT 8 T. Chown 9 University of Southampton 10 May 31, 2012 12 Default Address Selection for Internet Protocol version 6 (IPv6) 13 draft-ietf-6man-rfc3484bis-05.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 2, 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 . . . . . . . . . . . . . . . . . . . . 8 74 3.2. IPv4 Addresses and IPv4-Mapped Addresses . . . . . . . . . 9 75 3.3. Other IPv6 Addresses with Embedded IPv4 Addresses . . . . 9 76 3.4. IPv6 Loopback Address and Other Format Prefixes . . . . . 10 77 3.5. Mobility Addresses . . . . . . . . . . . . . . . . . . . . 10 78 4. Candidate Source Addresses . . . . . . . . . . . . . . . . . . 10 79 5. Source Address Selection . . . . . . . . . . . . . . . . . . . 11 80 6. Destination Address Selection . . . . . . . . . . . . . . . . 14 81 7. Interactions with Routing . . . . . . . . . . . . . . . . . . 16 82 8. Implementation Considerations . . . . . . . . . . . . . . . . 17 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 84 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 85 10.1. Default Source Address Selection . . . . . . . . . . . . . 18 86 10.2. Default Destination Address Selection . . . . . . . . . . 19 87 10.3. Configuring Preference for IPv6 or IPv4 . . . . . . . . . 20 88 10.3.1. Handling Broken IPv6 . . . . . . . . . . . . . . . . 21 89 10.4. Configuring Preference for Link-Local Addresses . . . . . 21 90 10.5. Configuring a Multi-Homed Site . . . . . . . . . . . . . . 22 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 . . . . . . . . . . . . . . . . . . 26 97 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 28 98 Appendix B. Changes Since RFC 3484 . . . . . . . . . . . . . . . 28 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 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 [RFC3493] 187 like getaddrinfo() 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 getaddrinfo() 201 will use the destination address selection algorithm specified here 202 to sort the list of IPv6 and IPv4 addresses that they return. 203 Separately, the IPv6 network layer will use the source address 204 selection algorithm when an application or upper-layer has not 205 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 getaddrinfo() and then give up if it fails. For many 211 applications, it is appropriate to iterate through the list of 212 addresses returned from getaddrinfo() until a working address is 213 found. For other applications, it might be appropriate to try 214 multiple in parallel (e.g., with some small delay in between) and use 215 the first one to succeed. 217 The algorithms use several criteria in making their decisions. The 218 combined effect is to prefer destination/source address pairs for 219 which the two addresses are of equal scope or type, prefer smaller 220 scopes over larger scopes for the destination address, prefer non- 221 deprecated source addresses, avoid the use of transitional addresses 222 when native addresses are available, and all else being equal prefer 223 address pairs having the longest possible common prefix. For source 224 address selection, temporary addresses [RFC4941] are preferred over 225 public addresses. In mobile situations [RFC6275], home addresses are 226 preferred over care-of addresses. If an address is simultaneously a 227 home address and a care-of address (indicating the mobile node is "at 228 home" for that address), then the home/care-of address is preferred 229 over addresses that are solely a home address or solely a care-of 230 address. 232 This specification optionally allows for the possibility of 233 administrative configuration of policy (e.g., via manual 234 configuration or a DHCP option such as that proposed in 235 [I-D.ietf-6man-addr-select-opt]) that can override the default 236 behavior of the algorithms. The policy override consists of the 237 following set of state, which SHOULD be configurable: 239 o Policy Table (Section 2.1): a table that specifies precedence 240 values and preferred source prefixes for destination prefixes. 241 o Automatic Row Additions flag (Section 2.1): a flag that specifies 242 whether the implementation is permitted to automatically add site- 243 specific rows for certain types of addresses. 245 o Privacy Preference flag (Section 5): a flag that specifies whether 246 temporary source addresses or stable source addresses are 247 preferred by default, when both types exist. 249 2.1. Policy Table 251 The policy table is a longest-matching-prefix lookup table, much like 252 a routing table. Given an address A, a lookup in the policy table 253 produces two values: a precedence value Precedence(A) and a 254 classification or label Label(A). 256 The precedence value Precedence(A) is used for sorting destination 257 addresses. If Precedence(A) > Precedence(B), we say that address A 258 has higher precedence than address B, meaning that our algorithm will 259 prefer to sort destination address A before destination address B. 261 The label value Label(A) allows for policies that prefer a particular 262 source address prefix for use with a destination address prefix. The 263 algorithms prefer to use a source address S with a destination 264 address D if Label(S) = Label(D). 266 IPv6 implementations SHOULD support configurable address selection 267 via a mechanism at least as powerful as the policy tables defined 268 here. It is important that implementations provide a way to change 269 the default policies as more experience is gained. Sections 10.3 270 through 10.7 provide examples of the kind of changes that might be 271 needed. 273 If an implementation is not configurable or has not been configured, 274 then it SHOULD operate according to the algorithms specified here in 275 conjunction with the following default policy table: 277 Prefix Precedence Label 278 ::1/128 50 0 279 ::/0 40 1 280 ::ffff:0:0/96 35 4 281 2002::/16 30 2 282 2001::/32 5 5 283 fc00::/7 3 13 284 ::/96 1 3 285 fec0::/10 1 11 286 3ffe::/16 1 12 288 An implementation MAY automatically add additional site-specific rows 289 to the default table based on its configured addresses, such as for 290 Unique Local Addresses (ULAs) [RFC4193] and 6to4 [RFC3056] addresses 291 for instance (see Section 10.6 and Section 10.7 for examples). Any 292 such rows automatically added by the implementation as a result of 293 address acquisition MUST NOT override a row for the same prefix 294 configured via other means. That is, rows can be added but never 295 updated automatically. An implementation SHOULD provide a means (the 296 Automatic Row Additions flag) for an administrator to disable 297 automatic row additions. 299 One effect of the default policy table is to prefer using native 300 source addresses with native destination addresses, 6to4 source 301 addresses with 6to4 destination addresses, etc. Another effect of 302 the default policy table is to prefer communication using IPv6 303 addresses to communication using IPv4 addresses, if matching source 304 addresses are available. 306 Policy table entries for scoped address prefixes MAY be qualified 307 with an optional zone index. If so, a prefix table entry only 308 matches against an address during a lookup if the zone index also 309 matches the address's zone index. 311 2.2. Common Prefix Length 313 We define the common prefix length CommonPrefixLen(S, D) of a source 314 address S and a destination address D as the length of the longest 315 prefix (looking at the most significant, or leftmost, bits) that the 316 two addresses have in common, up to the length of S's prefix (i.e., 317 the portion of the address not including the interface ID). For 318 example, CommonPrefixLen(fe80::1, fe80::2) is 64. 320 3. Address Properties 322 In the rules given in later sections, addresses of different types 323 (e.g., IPv4, IPv6, multicast and unicast) are compared against each 324 other. Some of these address types have properties that aren't 325 directly comparable to each other. For example, IPv6 unicast 326 addresses can be "preferred" or "deprecated" [RFC4862], while IPv4 327 addresses have no such notion. To compare such addresses using the 328 ordering rules (e.g., to use "preferred" addresses in preference to 329 "deprecated" addresses), the following mappings are defined. 331 3.1. Scope Comparisons 333 Multicast destination addresses have a 4-bit scope field that 334 controls the propagation of the multicast packet. The IPv6 335 addressing architecture defines scope field values for interface- 336 local (0x1), link-local (0x2), subnet-local (0x3), admin-local (0x4), 337 site-local (0x5), organization-local (0x8), and global (0xE) scopes 338 [RFC4007]. 340 Use of the source address selection algorithm in the presence of 341 multicast destination addresses requires the comparison of a unicast 342 address scope with a multicast address scope. We map unicast link- 343 local to multicast link-local, unicast site-local to multicast site- 344 local, and unicast global scope to multicast global scope. For 345 example, unicast site-local is equal to multicast site-local, which 346 is smaller than multicast organization-local, which is smaller than 347 unicast global, which is equal to multicast global. (Note that ULAs 348 are considered as global, not site-local, scope but are handled via 349 the prefix policy table as discussed in Section 10.6.) 351 We write Scope(A) to mean the scope of address A. For example, if A 352 is a link-local unicast address and B is a site-local multicast 353 address, then Scope(A) < Scope(B). 355 This mapping implicitly conflates unicast site boundaries and 356 multicast site boundaries [RFC4007]. 358 3.2. IPv4 Addresses and IPv4-Mapped Addresses 360 The destination address selection algorithm operates on both IPv6 and 361 IPv4 addresses. For this purpose, IPv4 addresses MUST be represented 362 as IPv4-mapped addresses [RFC4291]. For example, to lookup the 363 precedence or other attributes of an IPv4 address in the policy 364 table, lookup the corresponding IPv4-mapped IPv6 address. 366 IPv4 addresses are assigned scopes as follows. IPv4 auto- 367 configuration addresses [RFC3927], which have the prefix 169.254/16, 368 are assigned link-local scope. IPv4 loopback addresses ([RFC1918], 369 section 4.2.2.11), which have the prefix 127/8, are assigned link- 370 local scope (analogously to the treatment of the IPv6 loopback 371 address ([RFC4007], section 4)). Other IPv4 addresses (including 372 IPv4 private addresses [RFC1918] and Shared Address Space addresses 373 [RFC6598]) are assigned global scope. 375 IPv4 addresses MUST be treated as having "preferred" (in the RFC 4862 376 sense) configuration status. 378 3.3. Other IPv6 Addresses with Embedded IPv4 Addresses 380 IPv4-compatible addresses [RFC4291], IPv4-mapped [RFC4291], IPv4- 381 converted [RFC6145], IPv4-translatable [RFC6145], and 6to4 addresses 382 [RFC3056] contain an embedded IPv4 address. For the purposes of this 383 document, these addresses MUST be treated as having global scope. 385 IPv4-compatible, IPv4-mapped, and IPv4-converted addresses MUST be 386 treated as having "preferred" (in the RFC 4862 sense) configuration 387 status. 389 3.4. IPv6 Loopback Address and Other Format Prefixes 391 The loopback address MUST be treated as having link-local scope 392 ([RFC4007], section 4) and "preferred" (in the RFC 4862 sense) 393 configuration status. 395 NSAP addresses and other addresses with as-yet-undefined format 396 prefixes MUST be treated as having global scope and "preferred" (in 397 the RFC 4862) configuration status. Later standards might supersede 398 this treatment. 400 3.5. Mobility Addresses 402 Some nodes might support mobility using the concepts of home address 403 and care-of address (for example see [RFC6275]). Conceptually, a 404 home address is an IP address assigned to a mobile node and used as 405 the permanent address of the mobile node. A care-of address is an IP 406 address associated with a mobile node while visiting a foreign link. 407 When a mobile node is on its home link, it might have an address that 408 is simultaneously a home address and a care-of address. 410 For the purposes of this document, it is sufficient to know whether 411 or not one's own addresses are designated as home addresses or 412 care-of addresses. Whether or not an address is designated a home 413 address or care-of address is outside the scope of this document. 415 4. Candidate Source Addresses 417 The source address selection algorithm uses the concept of a 418 "candidate set" of potential source addresses for a given destination 419 address. The candidate set is the set of all addresses that could be 420 used as a source address; the source address selection algorithm will 421 pick an address out of that set. We write CandidateSource(A) to 422 denote the candidate set for the address A. 424 It is RECOMMENDED that the candidate source addresses be the set of 425 unicast addresses assigned to the interface that will be used to send 426 to the destination. (The "outgoing" interface.) On routers, the 427 candidate set MAY include unicast addresses assigned to any interface 428 that forwards packets, subject to the restrictions described below. 430 Discussion: The Neighbor Discovery Redirect mechanism [RFC4861] 431 requires that routers verify that the source address of a packet 432 identifies a neighbor before generating a Redirect, so it is 433 advantageous for hosts to choose source addresses assigned to the 434 outgoing interface. Implementations that wish to support the use 435 of global source addresses assigned to a loopback interface MUST 436 behave as if the loopback interface originates and forwards the 437 packet. 439 In some cases the destination address might be qualified with a zone 440 index or other information that will constrain the candidate set. 442 For multicast and link-local destination addresses, the set of 443 candidate source addresses MUST only include addresses assigned to 444 interfaces belonging to the same link as the outgoing interface. 446 Discussion: The restriction for multicast destination addresses is 447 necessary because currently-deployed multicast forwarding 448 algorithms use Reverse Path Forwarding (RPF) checks. 450 For site-local destination addresses, the set of candidate source 451 addresses MUST only include addresses assigned to interfaces 452 belonging to the same site as the outgoing interface. 454 In any case, multicast addresses, and the unspecified address MUST 455 NOT be included in a candidate set. 457 If an application or upper layer specifies a source address that is 458 not in the candidate set for the destination, then the network layer 459 MUST treat this as an error. The specified source address may 460 influence the candidate set, by affecting the choice of outgoing 461 interface. If the application or upper layer specifies a source 462 address that is in the candidate set for the destination, then the 463 network layer MUST respect that choice. If the application or upper 464 layer does not specify a source address, then the network layer uses 465 the source address selection algorithm specified in the next section. 467 On IPv6-only nodes that support SIIT [RFC6145], if the destination 468 address is an IPv4-converted address then the candidate set MUST 469 contain only IPv4-translatable addresses. 471 5. Source Address Selection 473 The source address selection algorithm produces as output a single 474 source address for use with a given destination address. This 475 algorithm only applies to IPv6 destination addresses, not IPv4 476 addresses. 478 The algorithm is specified here in terms of a list of pair-wise 479 comparison rules that (for a given destination address D) imposes a 480 "greater than" ordering on the addresses in the candidate set 481 CandidateSource(D). The address at the front of the list after the 482 algorithm completes is the one the algorithm selects. 484 Note that conceptually, a sort of the candidate set is being 485 performed, where a set of rules define the ordering among addresses. 486 But because the output of the algorithm is a single source address, 487 an implementation need not actually sort the set; it need only 488 identify the "maximum" value that ends up at the front of the sorted 489 list. 491 The ordering of the addresses in the candidate set is defined by a 492 list of eight pair-wise comparison rules, with each rule placing a 493 "greater than," "less than" or "equal to" ordering on two source 494 addresses with respect to each other (and that rule). In the case 495 that a given rule produces a tie, i.e., provides an "equal to" result 496 for the two addresses, the remaining rules MUST be applied (in order) 497 to just those addresses that are tied to break the tie. Note that if 498 a rule produces a single clear "winner" (or set of "winners" in the 499 case of ties), those addresses not in the winning set can be 500 discarded from further consideration, with subsequent rules applied 501 only to the remaining addresses. If the eight rules fail to choose a 502 single address, the tie-breaker is implementation-specific. 504 When comparing two addresses SA and SB from the candidate set, we say 505 "prefer SA" to mean that SA is "greater than" SB, and similarly we 506 say "prefer SB" to mean that SA is "less than" SB. 508 Rule 1: Prefer same address. 509 If SA = D, then prefer SA. Similarly, if SB = D, then prefer SB. 511 Rule 2: Prefer appropriate scope. 512 If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB and 513 otherwise prefer SA. Similarly, if Scope(SB) < Scope(SA): If 514 Scope(SB) < Scope(D), then prefer SA and otherwise prefer SB. 516 Rule 3: Avoid deprecated addresses. 517 The addresses SA and SB have the same scope. If one of the two 518 source addresses is "preferred" and one of them is "deprecated" (in 519 the RFC 4862 sense), then prefer the one that is "preferred." 521 Rule 4: Prefer home addresses. 522 If SA is simultaneously a home address and care-of address and SB is 523 not, then prefer SA. Similarly, if SB is simultaneously a home 524 address and care-of address and SA is not, then prefer SB. If SA is 525 just a home address and SB is just a care-of address, then prefer SA. 526 Similarly, if SB is just a home address and SA is just a care-of 527 address, then prefer SB. 529 Implementations supporting home addresses MUST provide a mechanism 530 allowing an application to reverse the sense of this preference and 531 prefer care-of addresses over home addresses (e.g., via appropriate 532 API extensions such as [RFC5014]). Use of the mechanism MUST only 533 affect the selection rules for the invoking application. 535 Rule 5: Prefer outgoing interface. 536 If SA is assigned to the interface that will be used to send to D and 537 SB is assigned to a different interface, then prefer SA. Similarly, 538 if SB is assigned to the interface that will be used to send to D and 539 SA is assigned to a different interface, then prefer SB. 541 Rule 5.5: Prefer addresses in a prefix advertised by the next-hop 542 If SA or SA's prefix is assigned by the selected next-hop that will 543 be used to send to D and SB or SB's prefix is assigned by a different 544 next-hop, then prefer SA. Similarly, if SB or SB's prefix is 545 assigned by the next-hop that will be used to send to D and SA or 546 SA's prefix is assigned by a different next-hop, then prefer SB. 548 Discussion: An IPv6 implementation is not required to remember 549 which next-hops advertised which prefixes. The conceptual models 550 of IPv6 hosts in Section 5 of [RFC4861] and Section 3 of [RFC4191] 551 have no such requirement. Implementations that do not track this 552 information shall omit rule 5.5. 554 Rule 6: Prefer matching label. 555 If Label(SA) = Label(D) and Label(SB) <> Label(D), then prefer SA. 556 Similarly, if Label(SB) = Label(D) and Label(SA) <> Label(D), then 557 prefer SB. 559 Rule 7: Prefer temporary addresses. 560 If SA is a temporary address and SB is a public address, then prefer 561 SA. Similarly, if SB is a temporary address and SA is a public 562 address, then prefer SB. 564 Implementations MUST provide a mechanism allowing an application to 565 reverse the sense of this preference and prefer public addresses over 566 temporary addresses (e.g., via appropriate API extensions such as 567 [RFC5014]). Use of the mechanism MUST only affect the selection 568 rules for the invoking application. This default is intended to 569 address privacy concerns as discussed in [RFC4941], but introduces a 570 risk of applications potentially failing due to the relatively short 571 lifetime of temporary addresses or due to the possibility of the 572 reverse lookup of a temporary address either failing or returning a 573 randomized name. Implementations for which application compatibility 574 considerations outweigh these privacy concerns MAY reverse the sense 575 of this rule and by default prefer public addresses over temporary 576 addresses. There SHOULD be an administrative option (the Privacy 577 Preference flag) to change this preference, if the implementation 578 supports temporary addresses. If there is no such option, there MUST 579 be an administrative option to disable temporary addresses. 581 Rule 8: Use longest matching prefix. 582 If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then prefer SA. 583 Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then 584 prefer SB. 586 Rule 8 MAY be superseded if the implementation has other means of 587 choosing among source addresses. For example, if the implementation 588 somehow knows which source address will result in the "best" 589 communications performance. 591 Rule 2 (prefer appropriate scope) MUST be implemented and given high 592 priority because it can affect interoperability. 594 6. Destination Address Selection 596 The destination address selection algorithm takes a list of 597 destination addresses and sorts the addresses to produce a new list. 598 It is specified here in terms of the pair-wise comparison of 599 addresses DA and DB, where DA appears before DB in the original list. 601 The algorithm sorts together both IPv6 and IPv4 addresses. To find 602 the attributes of an IPv4 address in the policy table, the IPv4 603 address MUST be represented as an IPv4-mapped address. 605 We write Source(D) to indicate the selected source address for a 606 destination D. For IPv6 addresses, the previous section specifies the 607 source address selection algorithm. Source address selection for 608 IPv4 addresses is not specified in this document. 610 We say that Source(D) is undefined if there is no source address 611 available for destination D. For IPv6 addresses, this is only the 612 case if CandidateSource(D) is the empty set. 614 The pair-wise comparison of destination addresses consists of ten 615 rules, which MUST be applied in order. If a rule determines a 616 result, then the remaining rules are not relevant and MUST be 617 ignored. Subsequent rules act as tie-breakers for earlier rules. 618 See the previous section for a lengthier description of how pair-wise 619 comparison tie-breaker rules can be used to sort a list. 621 Rule 1: Avoid unusable destinations. 622 If DB is known to be unreachable or if Source(DB) is undefined, then 623 prefer DA. Similarly, if DA is known to be unreachable or if 624 Source(DA) is undefined, then prefer DB. 626 Discussion: An implementation might know that a particular 627 destination is unreachable in several ways. For example, the 628 destination might be reached through a network interface that is 629 currently unplugged. For example, the implementation might retain 630 for some period of time information from Neighbor Unreachability 631 Detection [RFC4861]. In any case, the determination of 632 unreachability for the purposes of this rule is implementation- 633 dependent. 635 Rule 2: Prefer matching scope. 636 If Scope(DA) = Scope(Source(DA)) and Scope(DB) <> Scope(Source(DB)), 637 then prefer DA. Similarly, if Scope(DA) <> Scope(Source(DA)) and 638 Scope(DB) = Scope(Source(DB)), then prefer DB. 640 Rule 3: Avoid deprecated addresses. 641 If Source(DA) is deprecated and Source(DB) is not, then prefer DB. 642 Similarly, if Source(DA) is not deprecated and Source(DB) is 643 deprecated, then prefer DA. 645 Rule 4: Prefer home addresses. 646 If Source(DA) is simultaneously a home address and care-of address 647 and Source(DB) is not, then prefer DA. Similarly, if Source(DB) is 648 simultaneously a home address and care-of address and Source(DA) is 649 not, then prefer DB. 651 If Source(DA) is just a home address and Source(DB) is just a care-of 652 address, then prefer DA. Similarly, if Source(DA) is just a care-of 653 address and Source(DB) is just a home address, then prefer DB. 655 Rule 5: Prefer matching label. 656 If Label(Source(DA)) = Label(DA) and Label(Source(DB)) <> Label(DB), 657 then prefer DA. Similarly, if Label(Source(DA)) <> Label(DA) and 658 Label(Source(DB)) = Label(DB), then prefer DB. 660 Rule 6: Prefer higher precedence. 661 If Precedence(DA) > Precedence(DB), then prefer DA. Similarly, if 662 Precedence(DA) < Precedence(DB), then prefer DB. 664 Rule 7: Prefer native transport. 665 If DA is reached via an encapsulating transition mechanism (e.g., 666 IPv6 in IPv4) and DB is not, then prefer DB. Similarly, if DB is 667 reached via encapsulation and DA is not, then prefer DA. 669 Discussion: 6RD [RFC5969], ISATAP [RFC5214], and configured 670 tunnels [RFC4213] are examples of encapsulating transition 671 mechanisms for which the destination address does not have a 672 specific prefix and hence can not be assigned a lower precedence 673 in the policy table. An implementation MAY generalize this rule 674 by using a concept of interface preference, and giving virtual 675 interfaces (like the IPv6-in-IPv4 encapsulating interfaces) a 676 lower preference than native interfaces (like ethernet 677 interfaces). 679 Rule 8: Prefer smaller scope. 680 If Scope(DA) < Scope(DB), then prefer DA. Similarly, if Scope(DA) > 681 Scope(DB), then prefer DB. 683 Rule 9: Use longest matching prefix. 684 When DA and DB belong to the same address family (both are IPv6 or 685 both are IPv4): If CommonPrefixLen(Source(DA), DA) > 686 CommonPrefixLen(Source(DB), DB), then prefer DA. Similarly, if 687 CommonPrefixLen(Source(DA), DA) < CommonPrefixLen(Source(DB), DB), 688 then prefer DB. 690 Rule 10: Otherwise, leave the order unchanged. 691 If DA preceded DB in the original list, prefer DA. Otherwise prefer 692 DB. 694 Rules 9 and 10 MAY be superseded if the implementation has other 695 means of sorting destination addresses. For example, if the 696 implementation somehow knows which destination addresses will result 697 in the "best" communications performance. 699 7. Interactions with Routing 701 This specification of source address selection assumes that routing 702 (more precisely, selecting an outgoing interface on a node with 703 multiple interfaces) is done before source address selection. 704 However, implementations MAY use source address considerations as a 705 tiebreaker when choosing among otherwise equivalent routes. 707 For example, suppose a node has interfaces on two different links, 708 with both links having a working default router. Both of the 709 interfaces have preferred (in the RFC 4862 sense) global addresses. 710 When sending to a global destination address, if there's no routing 711 reason to prefer one interface over the other, then an implementation 712 MAY preferentially choose the outgoing interface that will allow it 713 to use the source address that shares a longer common prefix with the 714 destination. 716 Implementations that support source address selection (Section 5) 717 Rule 5.5 also use the choice of router to influence the choice of 718 source address. For example, suppose a host is on a link with two 719 routers. One router is advertising a global prefix A and the other 720 router is advertising global prefix B. Then when sending via the 721 first router, the host might prefer source addresses with prefix A 722 and when sending via the second router, prefer source addresses with 723 prefix B. 725 8. Implementation Considerations 727 The destination address selection algorithm needs information about 728 potential source addresses. One possible implementation strategy is 729 for getaddrinfo() to call down to the network layer with a list of 730 destination addresses, sort the list in the network layer with full 731 current knowledge of available source addresses, and return the 732 sorted list to getaddrinfo(). This is simple and gives the best 733 results but it introduces the overhead of another system call. One 734 way to reduce this overhead is to cache the sorted address list in 735 the resolver, so that subsequent calls for the same name do not need 736 to resort the list. 738 Another implementation strategy is to call down to the network layer 739 to retrieve source address information and then sort the list of 740 addresses directly in the context of getaddrinfo(). To reduce 741 overhead in this approach, the source address information can be 742 cached, amortizing the overhead of retrieving it across multiple 743 calls to getaddrinfo(). In this approach, the implementation might 744 not have knowledge of the outgoing interface for each destination, so 745 it MAY use a looser definition of the candidate set during 746 destination address ordering. 748 In any case, if the implementation uses cached and possibly stale 749 information in its implementation of destination address selection, 750 or if the ordering of a cached list of destination addresses is 751 possibly stale, then it MUST ensure that the destination address 752 ordering returned to the application is no more than one second out 753 of date. For example, an implementation might make a system call to 754 check if any routing table entries or source address assignments or 755 prefix policy table entries that might affect these algorithms have 756 changed. Another strategy is to use an invalidation counter that is 757 incremented whenever any underlying state is changed. By caching the 758 current invalidation counter value with derived state and then later 759 comparing against the current value, the implementation could detect 760 if the derived state is potentially stale. 762 9. Security Considerations 764 This document has no direct impact on Internet infrastructure 765 security. 767 Note that most source address selection algorithms, including the one 768 specified in this document, expose a potential privacy concern. An 769 unfriendly node can infer correlations among a target node's 770 addresses by probing the target node with request packets that force 771 the target host to choose its source address for the reply packets. 772 (Perhaps because the request packets are sent to an anycast or 773 multicast address, or perhaps the upper-layer protocol chosen for the 774 attack does not specify a particular source address for its reply 775 packets.) By using different addresses for itself, the unfriendly 776 node can cause the target node to expose the target's own addresses. 777 The source address selection default preference for temporary 778 addresses helps mitigate this concern. 780 In addition, some address selection rules might be administratively 781 configurable. Care must be taken to make sure that all 782 administrative options are secured against illicit modification, or 783 else an attacker could redirect and/or block traffic. 785 10. Examples 787 This section contains a number of examples, first of default behavior 788 and then demonstrating the utility of policy table configuration. 789 These examples are provided for illustrative purposes; they are not 790 to be construed as normative. 792 10.1. Default Source Address Selection 794 The source address selection rules, in conjunction with the default 795 policy table, produce the following behavior: 797 Destination: 2001:db8:1::1 798 Candidate Source Addresses: 2001:db8:3::1 or fe80::1 799 Result: 2001:db8::1 (prefer appropriate scope) 801 Destination: ff05::1 802 Candidate Source Addresses: 2001:db8:3::1 or fe80::1 803 Result: 2001:db8:3::1 (prefer appropriate scope) 805 Destination: 2001:db8:1::1 806 Candidate Source Addresses: 2001:db8:1::1 (deprecated) or 807 2001:db8:2::1 808 Result: 2001:db8:1::1 (prefer same address) 810 Destination: fe80::1 811 Candidate Source Addresses: fe80::2 (deprecated) or 2001:db8:1::1 812 Result: fe80::2 (prefer appropriate scope) 813 Destination: 2001:db8:1::1 814 Candidate Source Addresses: 2001:db8:1::2 or 2001:db8:3::2 815 Result: 2001:db8:1:::2 (longest-matching-prefix) 817 Destination: 2001:db8:1::1 818 Candidate Source Addresses: 2001:db8:1::2 (care-of address) or 2001: 819 db8:3::2 (home address) 820 Result: 2001:db8:3::2 (prefer home address) 822 Destination: 2002:c633:6401::1 823 Candidate Source Addresses: 2002:c633:6401::d5e3:7953:13eb:22e8 824 (temporary) or 2001:db8:1::2 825 Result: 2002:c633:6401::d5e3:7953:13eb:22e8 (prefer matching label) 827 Destination: 2001:db8:1::d5e3:0:0:1 828 Candidate Source Addresses: 2001:db8:1::2 or 2001:db8:1::d5e3:7953: 829 13eb:22e8 (temporary) 830 Result: 2001:db8:1::2 (prefer public address) 832 10.2. Default Destination Address Selection 834 The destination address selection rules, in conjunction with the 835 default policy table and the source address selection rules, produce 836 the following behavior: 838 Candidate Source Addresses: 2001:db8:1::2 or fe80::1 or 169.254.13.78 839 Destination Address List: 2001:db8:1::1 or 198.51.100.121 840 Result: 2001:db8:1::1 (src 2001:db8:1::2) then 198.51.100.121 (src 841 169.254.13.78) (prefer matching scope) 843 Candidate Source Addresses: fe80::1 or 198.51.100.117 844 Destination Address List: 2001:db8:1::1 or 198.51.100.121 845 Result: 198.51.100.121 (src 198.51.100.117) then 2001:db8:1::1 (src 846 fe80::1) (prefer matching scope) 848 Candidate Source Addresses: 2001:db8:1::2 or fe80::1 or 10.1.2.4 849 Destination Address List: 2001:db8:1::1 or 10.1.2.3 850 Result: 2001:db8:1::1 (src 2001:db8:1::2) then 10.1.2.3 (src 851 10.1.2.4) (prefer higher precedence) 853 Candidate Source Addresses: 2001:db8:1::2 or fe80::2 854 Destination Address List: 2001:db8:1::1 or fe80::1 855 Result: fe80::1 (src fe80::2) then 2001:db8:1::1 (src 2001:db8:1::2) 856 (prefer smaller scope) 858 Candidate Source Addresses: 2001:db8:1::2 (care-of address) or 2001: 859 db8:3::1 (home address) or fe80::2 (care-of address) 860 Destination Address List: 2001:db8:1::1 or fe80::1 861 Result: 2001:db8:1::1 (src 2001:db8:3::1) then fe80::1 (src fe80::2) 862 (prefer home address) 864 Candidate Source Addresses: 2001:db8:1::2 or fe80::2 (deprecated) 865 Destination Address List: 2001:db8:1::1 or fe80::1 866 Result: 2001:db8:1::1 (src 2001:db8:1::2) then fe80::1 (src fe80::2) 867 (avoid deprecated addresses) 869 Candidate Source Addresses: 2001:db8:1::2 or 2001:db8:3f44::2 or 870 fe80::2 871 Destination Address List: 2001:db8:1::1 or 2001:db8:3ffe::1 872 Result: 2001:db8:1::1 (src 2001:db8:1::2) then 2001:db8:3ffe::1 (src 873 2001:db8:3f44::2) (longest matching prefix) 875 Candidate Source Addresses: 2002:c633:6401::2 or fe80::2 876 Destination Address List: 2002:c633:6401::1 or 2001:db8:1::1 877 Result: 2002:c633:6401::1 (src 2002:c633:6401::2) then 2001:db8:1::1 878 (src 2002:c633:6401::2) (prefer matching label) 880 Candidate Source Addresses: 2002:c633:6401::2 or 2001:db8:1::2 or 881 fe80::2 882 Destination Address List: 2002:c633:6401::1 or 2001:db8:1::1 883 Result: 2001:db8:1::1 (src 2001:db8:1::2) then 2002:c633:6401::1 (src 884 2002:c633:6401::2) (prefer higher precedence) 886 10.3. Configuring Preference for IPv6 or IPv4 888 The default policy table gives IPv6 addresses higher precedence than 889 IPv4 addresses. This means that applications will use IPv6 in 890 preference to IPv4 when the two are equally suitable. An 891 administrator can change the policy table to prefer IPv4 addresses by 892 giving the ::ffff:0.0.0.0/96 prefix a higher precedence: 894 Prefix Precedence Label 895 ::1/128 50 0 896 ::/0 40 1 897 ::ffff:0:0/96 100 4 898 2002::/16 30 2 899 2001::/32 5 5 900 fc00::/7 3 13 901 ::/96 1 3 902 fec0::/10 1 11 903 3ffe::/16 1 12 905 This change to the default policy table produces the following 906 behavior: 908 Candidate Source Addresses: 2001:db8::2 or fe80::1 or 169.254.13.78 909 Destination Address List: 2001:db8::1 or 198.51.100.121 910 Unchanged Result: 2001:db8::1 (src 2001:db8::2) then 198.51.100.121 911 (src 169.254.13.78) (prefer matching scope) 913 Candidate Source Addresses: fe80::1 or 198.51.100.117 914 Destination Address List: 2001:db8::1 or 198.51.100.121 915 Unchanged Result: 198.51.100.121 (src 198.51.100.117) then 916 2001:db8::1 (src fe80::1) (prefer matching scope) 918 Candidate Source Addresses: 2001:db8::2 or fe80::1 or 10.1.2.4 919 Destination Address List: 2001:db8::1 or 10.1.2.3 920 New Result: 10.1.2.3 (src 10.1.2.4) then 2001:db8::1 (src 921 2001:db8::2) (prefer higher precedence) 923 10.3.1. Handling Broken IPv6 925 One problem in practice that has been recently observed occurs when a 926 host has IPv4 connectivity to the Internet, but has "broken" IPv6 927 connectivity to the Internet in that it has a global IPv6 address, 928 but is discconnected from the IPv6 Internet. Since the default 929 policy table prefers IPv6, this can result in unwanted timeouts. 931 This can be solved by configuring the table to prefer IPv4 as shown 932 above. An implementation that has some means to detect that it is 933 not connected to the IPv6 Internet MAY do this automatically. An 934 implementation could instead treat it as part of its implementation 935 of Rule 1 (avoid unusable destinations). 937 10.4. Configuring Preference for Link-Local Addresses 939 The destination address selection rules give preference to 940 destinations of smaller scope. For example, a link-local destination 941 will be sorted before a global scope destination when the two are 942 otherwise equally suitable. An administrator can change the policy 943 table to reverse this preference and sort global destinations before 944 link-local destinations: 946 Prefix Precedence Label 947 ::1/128 50 0 948 ::/0 40 1 949 ::ffff:0:0/96 35 4 950 fe80::/10 33 1 951 2002::/16 30 2 952 2001::/32 5 5 953 fc00::/7 3 13 954 ::/96 1 3 955 fec0::/10 1 11 956 3ffe::/16 1 12 958 This change to the default policy table produces the following 959 behavior: 961 Candidate Source Addresses: 2001:db8::2 or fe80::2 962 Destination Address List: 2001:db8::1 or fe80::1 963 New Result: 2001:db8::1 (src 2001:db8::2) then fe80::1 (src fe80::2) 964 (prefer higher precedence) 966 Candidate Source Addresses: 2001:db8::2 (deprecated) or fe80::2 967 Destination Address List: 2001:db8::1 or fe80::1 968 Unchanged Result: fe80::1 (src fe80::2) then 2001:db8::1 (src 2001: 969 db8::2) (avoid deprecated addresses) 971 10.5. Configuring a Multi-Homed Site 973 Consider a site A that has a business-critical relationship with 974 another site B. To support their business needs, the two sites have 975 contracted for service with a special high-performance ISP. This is 976 in addition to the normal Internet connection that both sites have 977 with different ISPs. The high-performance ISP is expensive and the 978 two sites wish to use it only for their business-critical traffic 979 with each other. 981 Each site has two global prefixes, one from the high-performance ISP 982 and one from their normal ISP. Site A has prefix 2001:db8:1aaa::/48 983 from the high-performance ISP and prefix 2001:db8:70aa::/48 from its 984 normal ISP. Site B has prefix 2001:db8:1bbb::/48 from the high- 985 performance ISP and prefix 2001:db8:70bb::/48 from its normal ISP. 986 All hosts in both sites register two addresses in the DNS. 988 The routing within both sites directs most traffic to the egress to 989 the normal ISP, but the routing directs traffic sent to the other 990 site's 2001 prefix to the egress to the high-performance ISP. To 991 prevent unintended use of their high-performance ISP connection, the 992 two sites implement ingress filtering to discard traffic entering 993 from the high-performance ISP that is not from the other site. 995 The default policy table and address selection rules produce the 996 following behavior: 998 Candidate Source Addresses: 2001:db8:1aaa::a or 2001:db8:70aa::a or 999 fe80::a 1000 Destination Address List: 2001:db8:1bbb::b or 2001:db8:70bb::b 1001 Result: 2001:db8:70bb::b (src 2001:db8:70aa::a) then 2001:db8:1bbb::b 1002 (src 2001:db8:1aaa::a) (longest matching prefix) 1004 In other words, when a host in site A initiates a connection to a 1005 host in site B, the traffic does not take advantage of their 1006 connections to the high-performance ISP. This is not their desired 1007 behavior. 1009 Candidate Source Addresses: 2001:db8:1aaa::a or 2001:db8:70aa::a or 1010 fe80::a 1011 Destination Address List: 2001:db8:1ccc::c or 2001:db8:6ccc::c 1012 Result: 2001:db8:1ccc::c (src 2001:db8:1aaa::a) then 2001:db8:6ccc::c 1013 (src 2001:db8:70aa::a) (longest matching prefix) 1015 In other words, when a host in site A initiates a connection to a 1016 host in some other site C, the reverse traffic might come back 1017 through the high-performance ISP. Again, this is not their desired 1018 behavior. 1020 This predicament demonstrates the limitations of the longest- 1021 matching-prefix heuristic in multi-homed situations. 1023 However, the administrators of sites A and B can achieve their 1024 desired behavior via policy table configuration. For example, they 1025 can use the following policy table: 1027 Prefix Precedence Label 1028 ::1/128 50 0 1029 2001:db8:1aaa::/48 43 6 1030 2001:db8:1bbb::/48 43 6 1031 ::/0 40 1 1032 ::ffff:0:0/96 35 4 1033 2002::/16 30 2 1034 2001::/32 5 5 1035 fc00::/7 3 13 1036 ::/96 1 3 1037 fec0::/10 1 11 1038 3ffe::/16 1 12 1040 This policy table produces the following behavior: 1042 Candidate Source Addresses: 2001:db8:1aaa::a or 2001:db8:70aa::a or 1043 fe80::a 1044 Destination Address List: 2001:db8:1bbb::b or 2001:db8:70bb::b 1045 New Result: 2001:db8:1bbb::b (src 2001:db8:1aaa::a) then 2001:db8: 1046 70bb::b (src 2001:db8:70aa::a) (prefer higher precedence) 1048 In other words, when a host in site A initiates a connection to a 1049 host in site B, the traffic uses the high-performance ISP as desired. 1051 Candidate Source Addresses: 2001:db8:1aaa::a or 2001:db8:70aa::a or 1052 fe80::a 1053 Destination Address List: 2001:db8:1ccc::c or 2001:db8:6ccc::c 1054 New Result: 2001:db8:6ccc::c (src 2001:db8:70aa::a) then 2001:db8: 1055 1ccc::c (src 2001:db8:70aa::a) (longest matching prefix) 1057 In other words, when a host in site A initiates a connection to a 1058 host in some other site C, the traffic uses the normal ISP as 1059 desired. 1061 10.6. Configuring ULA Preference 1063 RFC 5220 [RFC5220] sections 2.1.4, 2.2.2, and 2.2.3 describe address 1064 selection problems related to ULAs [RFC4193]. By default, global 1065 IPv6 destinations are preferred over ULA destinations, since an 1066 arbitrary ULA is not necessarily reachable: 1068 Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1 1069 Destination Address List: 2001:db8:2::2 or fd22:2222:2222:2::2 1070 Result: 2001:db8:2::2 (src 2001:db8:1::1) then fd22:2222:2222:2::2 1071 (src fd11:1111:1111:1::1) (prefer higher precedence) 1073 However, a site-specific policy entry can be used to cause ULAs 1074 within a site to be preferred over global addresses as follows. 1076 Prefix Precedence Label 1077 ::1/128 50 0 1078 fd11:1111:1111::/48 45 14 1079 ::/0 40 1 1080 ::ffff:0:0/96 35 4 1081 2002::/16 30 2 1082 2001::/32 5 5 1083 fc00::/7 3 13 1084 ::/96 1 3 1085 fec0::/10 1 11 1086 3ffe::/16 1 12 1088 Such a configuration would have the following effect: 1090 Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1 1091 Destination Address List: 2001:db8:2::2 or fd22:2222:2222:2::2 1092 Unchanged Result: 2001:db8:2::2 (src 2001:db8:1::1) then fd22:2222: 1093 2222:2::2 (src fd11:1111:1111:1::1) (prefer higher precedence) 1095 Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1 1096 Destination Address List: 2001:db8:2::2 or fd11:1111:1111:2::2 1097 New Result: fd11:1111:1111:2::2 (src fd11:1111:1111:1::1) then 2001: 1098 db8:2::2 (src 2001:db8:1::1) (prefer higher precedence) 1100 Since ULAs are defined to have a /48 site prefix, an implementation 1101 might choose to add such a row automatically on a machine with a ULA. 1103 It is also worth noting that ULAs are assigned global scope. As 1104 such, the existence of one or more rows in the prefix policy table is 1105 important so that source address selection does not choose a ULA 1106 purely based on longest match: 1108 Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1 1109 Destination Address List: ff00:1 1110 Result: 2001:db8:1::1 (prefer matching label) 1112 10.7. Configuring 6to4 Preference 1114 By default, NAT'ed IPv4 is preferred over 6to4-relayed connectivity: 1116 Candidate Source Addresses: 2002:c633:6401::2 or 10.1.2.3 1117 Destination Address List: 2001:db8:1::1 or 203.0.113.1 1118 Result: 203.0.113.1 (src 10.1.2.3) then 2001:db8:1::1 (src 2002:c633: 1119 6401::2) (prefer matching label) 1121 However, NAT'ed IPv4 is now also preferred over 6to4-to-6to4 1122 connectivity by default. Since a 6to4 prefix might be used natively 1123 within an organization, a site-specific policy entry can be used to 1124 cause native IPv6 communication (using a 6to4 prefix) to be preferred 1125 over NAT'ed IPv4 as follows. 1127 Prefix Precedence Label 1128 ::1/128 50 0 1129 2002:c633:6401::/48 45 14 1130 ::/0 40 1 1131 ::ffff:0:0/96 35 4 1132 2002::/16 30 2 1133 2001::/32 5 5 1134 fc00::/7 3 13 1135 ::/96 1 3 1136 fec0::/10 1 11 1137 3ffe::/16 1 12 1139 Such a configuration would have the following effect: 1141 Candidate Source Addresses: 2002:c633:6401:1::1 or 10.1.2.3 1142 Destination Address List: 2002:c633:6401:2::2 or 203.0.113.1 1143 New Result: 2002:c633:6401:2::2 (src 2002:c633:6401:1::1) then 1144 203.0.113.1 (sec 10.1.2.3) (prefer higher precedence) 1146 Since 6to4 addresses are defined to have a /48 site prefix, an 1147 implementation might choose to add such a row automatically on a 1148 machine with a native IPv6 address with a 6to4 prefix. 1150 11. IANA Considerations 1152 This document has no IANA actions. 1154 12. References 1156 12.1. Normative References 1158 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1159 Requirement Levels", BCP 14, RFC 2119, March 1997. 1161 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1162 via IPv4 Clouds", RFC 3056, February 2001. 1164 [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local 1165 Addresses", RFC 3879, September 2004. 1167 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1168 Addresses", RFC 4193, October 2005. 1170 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1171 Architecture", RFC 4291, February 2006. 1173 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1174 Network Address Translations (NATs)", RFC 4380, 1175 February 2006. 1177 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1178 Address Autoconfiguration", RFC 4862, September 2007. 1180 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1181 Extensions for Stateless Address Autoconfiguration in 1182 IPv6", RFC 4941, September 2007. 1184 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 1185 Algorithm", RFC 6145, April 2011. 1187 12.2. Informative References 1189 [I-D.ietf-6man-addr-select-opt] 1190 Matsumoto, A., Fujisaki, T., Kato, J., and T. Chown, 1191 "Distributing Address Selection Policy using DHCPv6", 1192 draft-ietf-6man-addr-select-opt-03 (work in progress), 1193 February 2012. 1195 [RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794, 1196 April 1995. 1198 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1199 E. Lear, "Address Allocation for Private Internets", 1200 BCP 5, RFC 1918, February 1996. 1202 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1203 Defeating Denial of Service Attacks which employ IP Source 1204 Address Spoofing", BCP 38, RFC 2827, May 2000. 1206 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 1207 Stevens, "Basic Socket Interface Extensions for IPv6", 1208 RFC 3493, February 2003. 1210 [RFC3701] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address 1211 Allocation) Phaseout", RFC 3701, March 2004. 1213 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 1214 Configuration of IPv4 Link-Local Addresses", RFC 3927, 1215 May 2005. 1217 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 1218 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 1219 March 2005. 1221 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1222 More-Specific Routes", RFC 4191, November 2005. 1224 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1225 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1227 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1228 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1229 September 2007. 1231 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 1232 Socket API for Source Address Selection", RFC 5014, 1233 September 2007. 1235 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1236 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1237 March 2008. 1239 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 1240 "Problem Statement for Default Address Selection in Multi- 1241 Prefix Environments: Operational Issues of RFC 3484 1242 Default Rules", RFC 5220, July 2008. 1244 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 1245 Infrastructures (6rd) -- Protocol Specification", 1246 RFC 5969, August 2010. 1248 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 1249 in IPv6", RFC 6275, July 2011. 1251 [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 1252 M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address 1253 Space", BCP 153, RFC 6598, April 2012. 1255 Appendix A. Acknowledgements 1257 RFC 3484 acknowledged the contributions of the IPng Working Group, 1258 particularly Marc Blanchet, Brian Carpenter, Matt Crawford, Alain 1259 Durand, Steve Deering, Robert Elz, Jun-ichiro itojun Hagino, Tony 1260 Hain, M.T. Hollinger, JINMEI Tatuya, Thomas Narten, Erik Nordmark, 1261 Ken Powell, Markku Savela, Pekka Savola, Hesham Soliman, Dave Thaler, 1262 Mauro Tortonesi, Ole Troan, and Stig Venaas. In addition, the 1263 anonymous IESG reviewers had many great comments and suggestions for 1264 clarification. 1266 This revision was heavily influenced by the work by Arifumi 1267 Matsumoto, Jun-ya Kato, and Tomohiro Fujisaki in a working draft that 1268 made proposals for this revision to adopt, with input from Pekka 1269 Savola, Remi Denis-Courmont, Francois-Xavier Le Bail, and the 6man 1270 Working Group. Dmitry Anipko, Mark Andrews, Ray Hunter, and Wes 1271 George also provided valuable feedback on this revision. 1273 Appendix B. Changes Since RFC 3484 1275 Some changes were made to the default policy table that were deemed 1276 to be universally useful and cause no harm in every reasonable 1277 network environment. In doing so, care was taken to use the same 1278 preference and label values as in RFC 3484 whenever possible, and for 1279 new rows to use label values less likely to collide with values that 1280 might already be in use in additional rows on some hosts. These 1281 changes are: 1283 1. Added the Teredo [RFC4380] prefix (2001::/32), with the 1284 preference and label values already widely used in popular 1285 implementations. 1286 2. Added a row for ULAs (fc00::/7) below native IPv6 since they are 1287 not globally reachable, as discussed in Section 10.6. 1288 3. Added a row for site-local addresses (fec0::/10) in order to 1289 depreference them, for consistency with the example in 1290 Section 10.3, since they are deprecated [RFC3879]. 1292 4. Depreferenced 6to4 (2002::/32) below native IPv4 since 6to4 1293 connectivity is less reliable today (and is expected to be phased 1294 out over time, rather than becoming more reliable). It remains 1295 above Teredo since 6to4 is more efficient in terms of connection 1296 establishment time, bandwidth, and server load. 1297 5. Depreferenced IPv4-Compatible addresses (::/96) since they are 1298 now deprecated [RFC4291] and not in common use. 1299 6. Added a row for 6bone testing addresses (3ffe::/16) in order to 1300 depreference them as they have also been phased out [RFC3701]. 1301 7. Added optional ability for an implementation to add automatic 1302 rows to the table for site-specific ULA prefixes and site- 1303 specific native 6to4 prefixes. 1305 Similarly, some changes were made to the rules, as follows: 1307 1. Changed the definition of CommonPrefixLen() to only compare bits 1308 up to the source address's prefix length. The previous 1309 definition used the entire source address, rather than only its 1310 prefix. As a result, when a source and destination addresses had 1311 the same prefix, common bits in the interface ID would previously 1312 result in overriding DNS load balancing [RFC1794] by forcing the 1313 destination address with the most bits in common to be always 1314 chosen. The updated definition allows DNS load balancing to 1315 continue to be used as a tie breaker. 1316 2. Added Rule 5.5 to allow choosing a source address from a prefix 1317 advertised by the chosen next-hop for a given destination. This 1318 allows better connectivity in the presence of BCP 38 [RFC2827] 1319 ingress filtering and egress filtering. Previously, RFC 3484 had 1320 issues with multiple egress networks reached via the same 1321 interface, as discussed in [RFC5220]. 1322 3. Removed restriction against anycast addresses in the candidate 1323 set of source addresses, since the restriction against using IPv6 1324 anycast addresses as source addresses was removed in Section 2.6 1325 of RFC 4291 [RFC4291]. 1326 4. Changed mapping of RFC 1918 [RFC1918] addresses to global scope 1327 in Section 3.2. Previously they were mapped to site-local scope. 1328 However, experience has resulted in current implementations 1329 already using global scope instead. When they were mapped to 1330 site-local, Destination Address Selection Rule 2 (Prefer matching 1331 scope) would cause IPv6 to be preferred in scenarios such as that 1332 described in Section 10.7. The change to global scope allows 1333 configurability via the prefix policy table. 1334 5. Changed the default recommendation for Source Address Selection 1335 Rule 7 to prefer temporary addresses rather than public 1336 addresses, while providing an administrative override (in 1337 addition to the application-specific override that was already 1338 specified). This change was made because of the increasing 1339 importance of privacy considerations, as well as the fact that 1340 widely deployed implementations have preferred temporary 1341 addresses for many years without major application issues. 1343 Finally, some editorial changes were made, including: 1345 1. Changed global IP addresses in examples to use ranges reserved 1346 for documentation. 1347 2. Added additional examples in Section 10.6 and Section 10.7. 1348 3. Added Section 10.3.1 on "broken" IPv6. 1349 4. Updated references. 1351 Authors' Addresses 1353 Dave Thaler (editor) 1354 Microsoft 1355 One Microsoft Way 1356 Redmond, WA 98052 1358 Phone: +1 425 703 8835 1359 Email: dthaler@microsoft.com 1361 Richard Draves 1362 Microsoft Research 1363 One Microsoft Way 1364 Redmond, WA 98052 1366 Phone: +1 425 706 2268 1367 Email: richdr@microsoft.com 1369 Arifumi Matsumoto 1370 NTT SI Lab 1371 Midori-Cho 3-9-11 1372 Musashino-shi, Tokyo 180-8585 1373 Japan 1375 Phone: +81 422 59 3334 1376 Email: arifumi@nttv6.net 1377 Tim Chown 1378 University of Southampt on 1379 Southampton, Hampshire SO17 1BJ 1380 United Kingdom 1382 Email: tjc@ecs.soton.ac.uk