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