idnits 2.17.1 draft-ietf-6man-rfc3484bis-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == 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 12 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document obsoletes RFC3484, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 23, 2012) is 4446 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) == Unused Reference: 'RFC6052' is defined on line 1224, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3701 ** 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: 4 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). 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: August 26, 2012 T. Chown 7 University of Southampton 8 February 23, 2012 10 Default Address Selection for Internet Protocol version 6 (IPv6) 11 draft-ietf-6man-rfc3484bis-00.txt 13 Abstract 15 This document describes two algorithms, for source address selection 16 and for destination address selection. The algorithms specify 17 default behavior for all Internet Protocol version 6 (IPv6) 18 implementations. They do not override choices made by applications 19 or upper-layer protocols, nor do they preclude the development of 20 more advanced mechanisms for address selection. The two algorithms 21 share a common context, including an optional mechanism for allowing 22 administrators to provide policy that can override the default 23 behavior. In dual stack implementations, the destination address 24 selection algorithm can consider both IPv4 and IPv6 addresses - 25 depending on the available source addresses, the algorithm might 26 prefer IPv6 addresses over IPv4 addresses, or vice-versa. 28 All IPv6 nodes, including both hosts and routers, must implement 29 default address selection as defined in this specification. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on August 26, 2012. 48 Copyright Notice 49 Copyright (c) 2012 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 This document may contain material from IETF Documents or IETF 63 Contributions published or made publicly available before November 64 10, 2008. The person(s) controlling the copyright in some of this 65 material may not have granted the IETF Trust the right to allow 66 modifications of such material outside the IETF Standards Process. 67 Without obtaining an adequate license from the person(s) controlling 68 the copyright in such materials, this document may not be modified 69 outside the IETF Standards Process, and derivative works of it may 70 not be created outside the IETF Standards Process, except to format 71 it for publication as an RFC or to translate it into languages other 72 than English. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 1.1. Conventions Used in This Document . . . . . . . . . . . . 5 78 2. Context in Which the Algorithms Operate . . . . . . . . . . . 5 79 2.1. Policy Table . . . . . . . . . . . . . . . . . . . . . . . 6 80 2.2. Common Prefix Length . . . . . . . . . . . . . . . . . . . 8 81 3. Address Properties . . . . . . . . . . . . . . . . . . . . . . 8 82 3.1. Scope Comparisons . . . . . . . . . . . . . . . . . . . . 8 83 3.2. IPv4 Addresses and IPv4-Mapped Addresses . . . . . . . . . 9 84 3.3. Other IPv6 Addresses with Embedded IPv4 Addresses . . . . 9 85 3.4. IPv6 Loopback Address and Other Format Prefixes . . . . . 9 86 3.5. Mobility Addresses . . . . . . . . . . . . . . . . . . . . 9 87 4. Candidate Source Addresses . . . . . . . . . . . . . . . . . . 10 88 5. Source Address Selection . . . . . . . . . . . . . . . . . . . 11 89 6. Destination Address Selection . . . . . . . . . . . . . . . . 13 90 7. Interactions with Routing . . . . . . . . . . . . . . . . . . 16 91 8. Implementation Considerations . . . . . . . . . . . . . . . . 16 92 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 93 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 94 10.1. Default Source Address Selection . . . . . . . . . . . . . 18 95 10.2. Default Destination Address Selection . . . . . . . . . . 18 96 10.3. Configuring Preference for IPv6 or IPv4 . . . . . . . . . 20 97 10.3.1. Handling Broken IPv6 . . . . . . . . . . . . . . . . 20 98 10.4. Configuring Preference for Link-Local Addresses . . . . . 21 99 10.5. Configuring a Multi-Homed Site . . . . . . . . . . . . . . 21 100 10.6. Configuring ULA Preference . . . . . . . . . . . . . . . . 23 101 10.7. Configuring 6to4 Preference . . . . . . . . . . . . . . . 24 102 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 103 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 104 11.2. Informative References . . . . . . . . . . . . . . . . . . 26 105 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 27 106 Appendix B. Changes Since RFC 3484 . . . . . . . . . . . . . . . 28 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 109 1. Introduction 111 The IPv6 addressing architecture [RFC4291] allows multiple unicast 112 addresses to be assigned to interfaces. These addresses may have 113 different reachability scopes (link-local, site-local, or global). 114 These addresses may also be "preferred" or "deprecated" [RFC4862]. 115 Privacy considerations have introduced the concepts of "public 116 addresses" and "temporary addresses" [RFC4941]. The mobility 117 architecture introduces "home addresses" and "care-of addresses" 118 [RFC6275]. In addition, multi-homing situations will result in more 119 addresses per node. For example, a node may have multiple 120 interfaces, some of them tunnels or virtual interfaces, or a site may 121 have multiple ISP attachments with a global prefix per ISP. 123 The end result is that IPv6 implementations will very often be faced 124 with multiple possible source and destination addresses when 125 initiating communication. It is desirable to have default 126 algorithms, common across all implementations, for selecting source 127 and destination addresses so that developers and administrators can 128 reason about and predict the behavior of their systems. 130 Furthermore, dual or hybrid stack implementations, which support both 131 IPv6 and IPv4, will very often need to choose between IPv6 and IPv4 132 when initiating communication. For example, when DNS name resolution 133 yields both IPv6 and IPv4 addresses and the network protocol stack 134 has available both IPv6 and IPv4 source addresses. In such cases, a 135 simple policy to always prefer IPv6 or always prefer IPv4 can produce 136 poor behavior. As one example, suppose a DNS name resolves to a 137 global IPv6 address and a global IPv4 address. If the node has 138 assigned a global IPv6 address and a 169.254/16 auto-configured IPv4 139 address [RFC3927], then IPv6 is the best choice for communication. 140 But if the node has assigned only a link-local IPv6 address and a 141 global IPv4 address, then IPv4 is the best choice for communication. 142 The destination address selection algorithm solves this with a 143 unified procedure for choosing among both IPv6 and IPv4 addresses. 145 The algorithms in this document are specified as a set of rules that 146 define a partial ordering on the set of addresses that are available 147 for use. In the case of source address selection, a node typically 148 has multiple addresses assigned to its interfaces, and the source 149 address ordering rules in section 5 define which address is the 150 "best" one to use. In the case of destination address selection, the 151 DNS may return a set of addresses for a given name, and an 152 application needs to decide which one to use first, and in what order 153 to try others should the first one not be reachable. The destination 154 address ordering rules in section 6, when applied to the set of 155 addresses returned by the DNS, provide such a recommended ordering. 157 This document specifies source address selection and destination 158 address selection separately, but using a common context so that 159 together the two algorithms yield useful results. The algorithms 160 attempt to choose source and destination addresses of appropriate 161 scope and configuration status (preferred or deprecated in the RFC 162 4862 sense). Furthermore, this document suggests a preferred method, 163 longest matching prefix, for choosing among otherwise equivalent 164 addresses in the absence of better information. 166 This document also specifies policy hooks to allow administrative 167 override of the default behavior. For example, using these hooks an 168 administrator can specify a preferred source prefix for use with a 169 destination prefix, or prefer destination addresses with one prefix 170 over addresses with another prefix. These hooks give an 171 administrator flexibility in dealing with some multi-homing and 172 transition scenarios, but they are certainly not a panacea. 174 The selection rules specified in this document MUST NOT be construed 175 to override an application or upper-layer's explicit choice of a 176 legal destination or source address. 178 1.1. Conventions Used in This Document 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in BCP 14, RFC 2119 183 [RFC2119]. 185 2. Context in Which the Algorithms Operate 187 Our context for address selection derives from the most common 188 implementation architecture, which separates the choice of 189 destination address from the choice of source address. Consequently, 190 we have two separate algorithms for these tasks. The algorithms are 191 designed to work well together and they share a mechanism for 192 administrative policy override. 194 In this implementation architecture, applications use APIs [RFC3493] 195 like getaddrinfo() that return a list of addresses to the 196 application. This list might contain both IPv6 and IPv4 addresses 197 (sometimes represented as IPv4-mapped addresses). The application 198 then passes a destination address to the network stack with connect() 199 or sendto(). The application would then typically try the first 200 address in the list, looping over the list of addresses until it 201 finds a working address. In any case, the network layer is never in 202 a situation where it needs to choose a destination address from 203 several alternatives. The application might also specify a source 204 address with bind(), but often the source address is left 205 unspecified. Therefore the network layer does often choose a source 206 address from several alternatives. 208 As a consequence, we intend that implementations of getaddrinfo() 209 will use the destination address selection algorithm specified here 210 to sort the list of IPv6 and IPv4 addresses that they return. 211 Separately, the IPv6 network layer will use the source address 212 selection algorithm when an application or upper-layer has not 213 specified a source address. Application of this specification to 214 source address selection in an IPv4 network layer may be possible but 215 this is not explored further here. 217 Well-behaved applications SHOULD iterate through the list of 218 addresses returned from getaddrinfo() until they find a working 219 address. 221 The algorithms use several criteria in making their decisions. The 222 combined effect is to prefer destination/source address pairs for 223 which the two addresses are of equal scope or type, prefer smaller 224 scopes over larger scopes for the destination address, prefer non- 225 deprecated source addresses, avoid the use of transitional addresses 226 when native addresses are available, and all else being equal prefer 227 address pairs having the longest possible common prefix. For source 228 address selection, public addresses [RFC4941] are preferred over 229 temporary addresses. In mobile situations [RFC6275], home addresses 230 are preferred over care-of addresses. If an address is 231 simultaneously a home address and a care-of address (indicating the 232 mobile node is "at home" for that address), then the home/care-of 233 address is preferred over addresses that are solely a home address or 234 solely a care-of address. 236 This specification optionally allows for the possibility of 237 administrative configuration of policy (e.g., via manual 238 configuration or a DHCP option such as that proposed in 239 [I-D.ietf-6man-addr-select-opt]) that can override the default 240 behavior of the algorithms. The policy override takes the form of a 241 configurable table that specifies precedence values and preferred 242 source prefixes for destination prefixes. If an implementation is 243 not configurable, or if an implementation has not been configured, 244 then the default policy table specified in this document SHOULD be 245 used. 247 2.1. Policy Table 249 The policy table is a longest-matching-prefix lookup table, much like 250 a routing table. Given an address A, a lookup in the policy table 251 produces two values: a precedence value Precedence(A) and a 252 classification or label Label(A). 254 The precedence value Precedence(A) is used for sorting destination 255 addresses. If Precedence(A) > Precedence(B), we say that address A 256 has higher precedence than address B, meaning that our algorithm will 257 prefer to sort destination address A before destination address B. 259 The label value Label(A) allows for policies that prefer a particular 260 source address prefix for use with a destination address prefix. The 261 algorithms prefer to use a source address S with a destination 262 address D if Label(S) = Label(D). 264 IPv6 implementations SHOULD support configurable address selection 265 via a mechanism at least as powerful as the policy tables defined 266 here. It is important that implementations provide a way to change 267 the default policies as more experience is gained. Sections 10.3 and 268 10.4 provide examples of the kind of changes that might be needed. 270 If an implementation is not configurable or has not been configured, 271 then it SHOULD operate according to the algorithms specified here in 272 conjunction with the following default policy table: 274 Prefix Precedence Label 275 ::1/128 50 0 276 ::/0 40 1 277 ::ffff:0:0/96 35 4 278 2002::/16 30 2 279 2001::/32 5 5 280 fc00::/7 3 13 281 ::/96 1 3 282 fec0::/10 1 11 283 3ffe::/16 1 12 285 An implementation MAY automatically add additional site-specific rows 286 to the default table based on its configured addresses, such as for 287 ULAs and 6to4 addresses for instance (see Section 10.6 and 288 Section 10.7 for examples). 290 One effect of the default policy table is to prefer using native 291 source addresses with native destination addresses, 6to4 [RFC3056] 292 source addresses with 6to4 destination addresses, etc. Another 293 effect of the default policy table is to prefer communication using 294 IPv6 addresses to communication using IPv4 addresses, if matching 295 source addresses are available. 297 Policy table entries for scoped address prefixes MAY be qualified 298 with an optional zone index. If so, a prefix table entry only 299 matches against an address during a lookup if the zone index also 300 matches the address's zone index. 302 2.2. Common Prefix Length 304 We define the common prefix length CommonPrefixLen(S, D) of a source 305 address S and a destination address D as the length of the longest 306 prefix (looking at the most significant, or leftmost, bits) that the 307 two addresses have in common, up to the length of S's prefix (i.e., 308 the portion of the address not including the interface ID). For 309 example, CommonPrefixLen(fe80::1, fe80::2) is 64. 311 3. Address Properties 313 In the rules given in later sections, addresses of different types 314 (e.g., IPv4, IPv6, multicast and unicast) are compared against each 315 other. Some of these address types have properties that aren't 316 directly comparable to each other. For example, IPv6 unicast 317 addresses can be "preferred" or "deprecated" [RFC4862], while IPv4 318 addresses have no such notion. To compare such addresses using the 319 ordering rules (e.g., to use "preferred" addresses in preference to 320 "deprecated" addresses), the following mappings are defined. 322 3.1. Scope Comparisons 324 Multicast destination addresses have a 4-bit scope field that 325 controls the propagation of the multicast packet. The IPv6 326 addressing architecture defines scope field values for interface- 327 local (0x1), link-local (0x2), subnet-local (0x3), admin-local (0x4), 328 site-local (0x5), organization-local (0x8), and global (0xE) scopes 329 [RFC4007]. 331 Use of the source address selection algorithm in the presence of 332 multicast destination addresses requires the comparison of a unicast 333 address scope with a multicast address scope. We map unicast link- 334 local to multicast link-local, unicast site-local to multicast site- 335 local, and unicast global scope to multicast global scope. For 336 example, unicast site-local is equal to multicast site-local, which 337 is smaller than multicast organization-local, which is smaller than 338 unicast global, which is equal to multicast global. 340 We write Scope(A) to mean the scope of address A. For example, if A 341 is a link-local unicast address and B is a site-local multicast 342 address, then Scope(A) < Scope(B). 344 This mapping implicitly conflates unicast site boundaries and 345 multicast site boundaries [RFC4007]. 347 3.2. IPv4 Addresses and IPv4-Mapped Addresses 349 The destination address selection algorithm operates on both IPv6 and 350 IPv4 addresses. For this purpose, IPv4 addresses should be 351 represented as IPv4-mapped addresses [RFC4291]. For example, to 352 lookup the precedence or other attributes of an IPv4 address in the 353 policy table, lookup the corresponding IPv4-mapped IPv6 address. 355 IPv4 addresses are assigned scopes as follows. IPv4 auto- 356 configuration addresses [RFC3927], which have the prefix 169.254/16, 357 are assigned link-local scope. IPv4 private addresses [RFC1918], 358 which have the prefixes 10/8, 172.16/12, and 192.168/16, are assigned 359 global scope. IPv4 loopback addresses ([RFC1918], section 4.2.2.11), 360 which have the prefix 127/8, are assigned link-local scope 361 (analogously to the treatment of the IPv6 loopback address 362 ([RFC4007], section 4)). Other IPv4 addresses are assigned global 363 scope. 365 IPv4 addresses should be treated as having "preferred" (in the RFC 366 4862 sense) configuration status. 368 3.3. Other IPv6 Addresses with Embedded IPv4 Addresses 370 IPv4-compatible addresses [RFC4291], IPv4-mapped [RFC4291], IPv4- 371 converted [RFC6145], IPv4-translatable [RFC6145], and 6to4 addresses 372 [RFC3056] contain an embedded IPv4 address. For the purposes of this 373 document, these addresses should be treated as having global scope. 375 IPv4-compatible, IPv4-mapped, and IPv4-converted addresses should be 376 treated as having "preferred" (in the RFC 4862 sense) configuration 377 status. 379 3.4. IPv6 Loopback Address and Other Format Prefixes 381 The loopback address should be treated as having link-local scope 382 ([RFC4007], section 4) and "preferred" (in the RFC 4862 sense) 383 configuration status. 385 NSAP addresses and other addresses with as-yet-undefined format 386 prefixes should be treated as having global scope and "preferred" (in 387 the RFC 4862) configuration status. Later standards may supersede 388 this treatment. 390 3.5. Mobility Addresses 392 Some nodes may support mobility using the concepts of home address 393 and care-of address (for example see [RFC6275]). Conceptually, a 394 home address is an IP address assigned to a mobile node and used as 395 the permanent address of the mobile node. A care-of address is an IP 396 address associated with a mobile node while visiting a foreign link. 397 When a mobile node is on its home link, it may have an address that 398 is simultaneously a home address and a care-of address. 400 For the purposes of this document, it is sufficient to know whether 401 or not one's own addresses are designated as home addresses or 402 care-of addresses. Whether or not an address should be designated a 403 home address or care-of address is outside the scope of this 404 document. 406 4. Candidate Source Addresses 408 The source address selection algorithm uses the concept of a 409 "candidate set" of potential source addresses for a given destination 410 address. The candidate set is the set of all addresses that could be 411 used as a source address; the source address selection algorithm will 412 pick an address out of that set. We write CandidateSource(A) to 413 denote the candidate set for the address A. 415 It is RECOMMENDED that the candidate source addresses be the set of 416 unicast addresses assigned to the interface that will be used to send 417 to the destination. (The "outgoing" interface.) On routers, the 418 candidate set MAY include unicast addresses assigned to any interface 419 that forwards packets, subject to the restrictions described below. 421 Discussion: The Neighbor Discovery Redirect mechanism [RFC4861] 422 requires that routers verify that the source address of a packet 423 identifies a neighbor before generating a Redirect, so it is 424 advantageous for hosts to choose source addresses assigned to the 425 outgoing interface. Implementations that wish to support the use 426 of global source addresses assigned to a loopback interface should 427 behave as if the loopback interface originates and forwards the 428 packet. 430 In some cases the destination address may be qualified with a zone 431 index or other information that will constrain the candidate set. 433 For multicast and link-local destination addresses, the set of 434 candidate source addresses MUST only include addresses assigned to 435 interfaces belonging to the same link as the outgoing interface. 437 Discussion: The restriction for multicast destination addresses is 438 necessary because currently-deployed multicast forwarding 439 algorithms use Reverse Path Forwarding (RPF) checks. 441 For site-local destination addresses, the set of candidate source 442 addresses MUST only include addresses assigned to interfaces 443 belonging to the same site as the outgoing interface. 445 In any case, multicast addresses, and the unspecified address MUST 446 NOT be included in a candidate set. 448 If an application or upper layer specifies a source address that is 449 not in the candidate set for the destination, then the network layer 450 MUST treat this as an error. The specified source address may 451 influence the candidate set, by affecting the choice of outgoing 452 interface. If the application or upper layer specifies a source 453 address that is in the candidate set for the destination, then the 454 network layer MUST respect that choice. If the application or upper 455 layer does not specify a source address, then the network layer uses 456 the source address selection algorithm specified in the next section. 458 On IPv6-only nodes that support SIIT [RFC6145], if the destination 459 address is an IPv4-converted address then the candidate set MUST 460 contain only IPv4-translatable addresses. 462 5. Source Address Selection 464 The source address selection algorithm produces as output a single 465 source address for use with a given destination address. This 466 algorithm only applies to IPv6 destination addresses, not IPv4 467 addresses. 469 The algorithm is specified here in terms of a list of pair-wise 470 comparison rules that (for a given destination address D) imposes a 471 "greater than" ordering on the addresses in the candidate set 472 CandidateSource(D). The address at the front of the list after the 473 algorithm completes is the one the algorithm selects. 475 Note that conceptually, a sort of the candidate set is being 476 performed, where a set of rules define the ordering among addresses. 477 But because the output of the algorithm is a single source address, 478 an implementation need not actually sort the set; it need only 479 identify the "maximum" value that ends up at the front of the sorted 480 list. 482 The ordering of the addresses in the candidate set is defined by a 483 list of eight pair-wise comparison rules, with each rule placing a 484 "greater than," "less than" or "equal to" ordering on two source 485 addresses with respect to each other (and that rule). In the case 486 that a given rule produces a tie, i.e., provides an "equal to" result 487 for the two addresses, the remaining rules are applied (in order) to 488 just those addresses that are tied to break the tie. Note that if a 489 rule produces a single clear "winner" (or set of "winners" in the 490 case of ties), those addresses not in the winning set can be 491 discarded from further consideration, with subsequent rules applied 492 only to the remaining addresses. If the eight rules fail to choose a 493 single address, some unspecified tie-breaker should be used. 495 When comparing two addresses SA and SB from the candidate set, we say 496 "prefer SA" to mean that SA is "greater than" SB, and similarly we 497 say "prefer SB" to mean that SA is "less than" SB. 499 Rule 1: Prefer same address. 500 If SA = D, then prefer SA. Similarly, if SB = D, then prefer SB. 502 Rule 2: Prefer appropriate scope. 503 If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB and 504 otherwise prefer SA. Similarly, if Scope(SB) < Scope(SA): If 505 Scope(SB) < Scope(D), then prefer SA and otherwise prefer SB. 507 Rule 3: Avoid deprecated addresses. 508 The addresses SA and SB have the same scope. If one of the two 509 source addresses is "preferred" and one of them is "deprecated" (in 510 the RFC 4862 sense), then prefer the one that is "preferred." 512 Rule 4: Prefer home addresses. 513 If SA is simultaneously a home address and care-of address and SB is 514 not, then prefer SA. Similarly, if SB is simultaneously a home 515 address and care-of address and SA is not, then prefer SB. If SA is 516 just a home address and SB is just a care-of address, then prefer SA. 517 Similarly, if SB is just a home address and SA is just a care-of 518 address, then prefer SB. 520 Implementations should provide a mechanism allowing an application to 521 reverse the sense of this preference and prefer care-of addresses 522 over home addresses (e.g., via appropriate API extensions such as 523 [RFC5014]). Use of the mechanism should only affect the selection 524 rules for the invoking application. 526 Rule 5: Prefer outgoing interface. 527 If SA is assigned to the interface that will be used to send to D and 528 SB is assigned to a different interface, then prefer SA. Similarly, 529 if SB is assigned to the interface that will be used to send to D and 530 SA is assigned to a different interface, then prefer SB. 532 Rule 5.5: Prefer addresses in a prefix advertised by the next-hop 533 If SA or SA's prefix is assigned by the selected next-hop that will 534 be used to send to D and SB or SB's prefix is assigned by a different 535 next-hop, then prefer SA. Similarly, if SB or SB's prefix is 536 assigned by the next-hop that will be used to send to D and SA or 537 SA's prefix is assigned by a different next-hop, then prefer SB. 539 Discussion: An IPv6 implementation is not required to remember 540 which next-hops advertised which prefixes. The conceptual models 541 of IPv6 hosts in Section 5 of [RFC4861] and Section 3 of [RFC4191] 542 have no such requirement. Implementations that do not track this 543 information shall omit rule 5.5. 545 Rule 6: Prefer matching label. 546 If Label(SA) = Label(D) and Label(SB) <> Label(D), then prefer SA. 547 Similarly, if Label(SB) = Label(D) and Label(SA) <> Label(D), then 548 prefer SB. 550 Rule 7: Prefer public addresses. 551 If SA is a public address and SB is a temporary address, then prefer 552 SA. Similarly, if SB is a public address and SA is a temporary 553 address, then prefer SB. 555 Implementations MUST provide a mechanism allowing an application to 556 reverse the sense of this preference and prefer temporary addresses 557 over public addresses (e.g., via appropriate API extensions such as 558 [RFC5014]). Use of the mechanism should only affect the selection 559 rules for the invoking application. This rule avoids applications 560 potentially failing due to the relatively short lifetime of temporary 561 addresses or due to the possibility of the reverse lookup of a 562 temporary address either failing or returning a randomized name. 563 Implementations for which privacy considerations outweigh these 564 application compatibility concerns MAY reverse the sense of this rule 565 and by default prefer temporary addresses over public addresses. 567 Rule 8: Use longest matching prefix. 568 If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then prefer SA. 569 Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then 570 prefer SB. 572 Rule 8 may be superseded if the implementation has other means of 573 choosing among source addresses. For example, if the implementation 574 somehow knows which source address will result in the "best" 575 communications performance. 577 Rule 2 (prefer appropriate scope) MUST be implemented and given high 578 priority because it can affect interoperability. 580 6. Destination Address Selection 582 The destination address selection algorithm takes a list of 583 destination addresses and sorts the addresses to produce a new list. 585 It is specified here in terms of the pair-wise comparison of 586 addresses DA and DB, where DA appears before DB in the original list. 588 The algorithm sorts together both IPv6 and IPv4 addresses. To find 589 the attributes of an IPv4 address in the policy table, the IPv4 590 address should be represented as an IPv4-mapped address. 592 We write Source(D) to indicate the selected source address for a 593 destination D. For IPv6 addresses, the previous section specifies the 594 source address selection algorithm. Source address selection for 595 IPv4 addresses is not specified in this document. 597 We say that Source(D) is undefined if there is no source address 598 available for destination D. For IPv6 addresses, this is only the 599 case if CandidateSource(D) is the empty set. 601 The pair-wise comparison of destination addresses consists of ten 602 rules, which should be applied in order. If a rule determines a 603 result, then the remaining rules are not relevant and should be 604 ignored. Subsequent rules act as tie-breakers for earlier rules. 605 See the previous section for a lengthier description of how pair-wise 606 comparison tie-breaker rules can be used to sort a list. 608 Rule 1: Avoid unusable destinations. 609 If DB is known to be unreachable or if Source(DB) is undefined, then 610 prefer DA. Similarly, if DA is known to be unreachable or if 611 Source(DA) is undefined, then prefer DB. 613 Discussion: An implementation may know that a particular 614 destination is unreachable in several ways. For example, the 615 destination may be reached through a network interface that is 616 currently unplugged. For example, the implementation may retain 617 for some period of time information from Neighbor Unreachability 618 Detection [RFC4861]. In any case, the determination of 619 unreachability for the purposes of this rule is implementation- 620 dependent. 622 Rule 2: Prefer matching scope. 623 If Scope(DA) = Scope(Source(DA)) and Scope(DB) <> Scope(Source(DB)), 624 then prefer DA. Similarly, if Scope(DA) <> Scope(Source(DA)) and 625 Scope(DB) = Scope(Source(DB)), then prefer DB. 627 Rule 3: Avoid deprecated addresses. 628 If Source(DA) is deprecated and Source(DB) is not, then prefer DB. 629 Similarly, if Source(DA) is not deprecated and Source(DB) is 630 deprecated, then prefer DA. 632 Rule 4: Prefer home addresses. 634 If Source(DA) is simultaneously a home address and care-of address 635 and Source(DB) is not, then prefer DA. Similarly, if Source(DB) is 636 simultaneously a home address and care-of address and Source(DA) is 637 not, then prefer DB. 639 If Source(DA) is just a home address and Source(DB) is just a care-of 640 address, then prefer DA. Similarly, if Source(DA) is just a care-of 641 address and Source(DB) is just a home address, then prefer DB. 643 Rule 5: Prefer matching label. 644 If Label(Source(DA)) = Label(DA) and Label(Source(DB)) <> Label(DB), 645 then prefer DA. Similarly, if Label(Source(DA)) <> Label(DA) and 646 Label(Source(DB)) = Label(DB), then prefer DB. 648 Rule 6: Prefer higher precedence. 649 If Precedence(DA) > Precedence(DB), then prefer DA. Similarly, if 650 Precedence(DA) < Precedence(DB), then prefer DB. 652 Rule 7: Prefer native transport. 653 If DA is reached via an encapsulating transition mechanism (e.g., 654 IPv6 in IPv4) and DB is not, then prefer DB. Similarly, if DB is 655 reached via encapsulation and DA is not, then prefer DA. 657 Discussion: 6RD [RFC5969], ISATAP [RFC5214], and configured 658 tunnels [RFC4213] are examples of encapsulating transition 659 mechanisms for which the destination address does not have a 660 specific prefix and hence can not be assigned a lower precedence 661 in the policy table. An implementation MAY generalize this rule 662 by using a concept of interface preference, and giving virtual 663 interfaces (like the IPv6-in-IPv4 encapsulating interfaces) a 664 lower preference than native interfaces (like ethernet 665 interfaces). 667 Rule 8: Prefer smaller scope. 668 If Scope(DA) < Scope(DB), then prefer DA. Similarly, if Scope(DA) > 669 Scope(DB), then prefer DB. 671 Rule 9: Use longest matching prefix. 672 When DA and DB belong to the same address family (both are IPv6 or 673 both are IPv4): If CommonPrefixLen(Source(DA), DA) > 674 CommonPrefixLen(Source(DB), DB), then prefer DA. Similarly, if 675 CommonPrefixLen(Source(DA), DA) < CommonPrefixLen(Source(DB), DB), 676 then prefer DB. 678 Rule 10: Otherwise, leave the order unchanged. 679 If DA preceded DB in the original list, prefer DA. Otherwise prefer 680 DB. 682 Rules 9 and 10 may be superseded if the implementation has other 683 means of sorting destination addresses. For example, if the 684 implementation somehow knows which destination addresses will result 685 in the "best" communications performance. 687 7. Interactions with Routing 689 This specification of source address selection assumes that routing 690 (more precisely, selecting an outgoing interface on a node with 691 multiple interfaces) is done before source address selection. 692 However, implementations may use source address considerations as a 693 tiebreaker when choosing among otherwise equivalent routes. 695 For example, suppose a node has interfaces on two different links, 696 with both links having a working default router. Both of the 697 interfaces have preferred (in the RFC 4862 sense) global addresses. 698 When sending to a global destination address, if there's no routing 699 reason to prefer one interface over the other, then an implementation 700 may preferentially choose the outgoing interface that will allow it 701 to use the source address that shares a longer common prefix with the 702 destination. 704 Implementations that support Rule 5.5 also use the choice of router 705 to influence the choice of source address. For example, suppose a 706 host is on a link with two routers. One router is advertising a 707 global prefix A and the other router is advertising global prefix B. 708 Then when sending via the first router, the host may prefer source 709 addresses with prefix A and when sending via the second router, 710 prefer source addresses with prefix B. 712 8. Implementation Considerations 714 The destination address selection algorithm needs information about 715 potential source addresses. One possible implementation strategy is 716 for getaddrinfo() to call down to the network layer with a list of 717 destination addresses, sort the list in the network layer with full 718 current knowledge of available source addresses, and return the 719 sorted list to getaddrinfo(). This is simple and gives the best 720 results but it introduces the overhead of another system call. One 721 way to reduce this overhead is to cache the sorted address list in 722 the resolver, so that subsequent calls for the same name do not need 723 to resort the list. 725 Another implementation strategy is to call down to the network layer 726 to retrieve source address information and then sort the list of 727 addresses directly in the context of getaddrinfo(). To reduce 728 overhead in this approach, the source address information can be 729 cached, amortizing the overhead of retrieving it across multiple 730 calls to getaddrinfo(). In this approach, the implementation may not 731 have knowledge of the outgoing interface for each destination, so it 732 MAY use a looser definition of the candidate set during destination 733 address ordering. 735 In any case, if the implementation uses cached and possibly stale 736 information in its implementation of destination address selection, 737 or if the ordering of a cached list of destination addresses is 738 possibly stale, then it should ensure that the destination address 739 ordering returned to the application is no more than one second out 740 of date. For example, an implementation might make a system call to 741 check if any routing table entries or source address assignments or 742 prefix policy table entries that might affect these algorithms have 743 changed. Another strategy is to use an invalidation counter that is 744 incremented whenever any underlying state is changed. By caching the 745 current invalidation counter value with derived state and then later 746 comparing against the current value, the implementation could detect 747 if the derived state is potentially stale. 749 9. Security Considerations 751 This document has no direct impact on Internet infrastructure 752 security. 754 Note that most source address selection algorithms, including the one 755 specified in this document, expose a potential privacy concern. An 756 unfriendly node can infer correlations among a target node's 757 addresses by probing the target node with request packets that force 758 the target host to choose its source address for the reply packets. 759 (Perhaps because the request packets are sent to an anycast or 760 multicast address, or perhaps the upper-layer protocol chosen for the 761 attack does not specify a particular source address for its reply 762 packets.) By using different addresses for itself, the unfriendly 763 node can cause the target node to expose the target's own addresses. 765 10. Examples 767 This section contains a number of examples, first of default behavior 768 and then demonstrating the utility of policy table configuration. 769 These examples are provided for illustrative purposes; they should 770 not be construed as normative. 772 10.1. Default Source Address Selection 774 The source address selection rules, in conjunction with the default 775 policy table, produce the following behavior: 777 Destination: 2001:db8:1::1 778 Candidate Source Addresses: 2001:db8:3::1 or fe80::1 779 Result: 2001:db8::1 (prefer appropriate scope) 781 Destination: ff05::1 782 Candidate Source Addresses: 2001:db8:3::1 or fe80::1 783 Result: 2001:db8:3::1 (prefer appropriate scope) 785 Destination: 2001:db8:1::1 786 Candidate Source Addresses: 2001:db8:1::1 (deprecated) or 787 2001:db8:2::1 788 Result: 2001:db8:1::1 (prefer same address) 790 Destination: fe80::1 791 Candidate Source Addresses: fe80::2 (deprecated) or 2001:db8:1::1 792 Result: fe80::2 (prefer appropriate scope) 794 Destination: 2001:db8:1::1 795 Candidate Source Addresses: 2001:db8:1::2 or 2001:db8:3::2 796 Result: 2001:db8:1:::2 (longest-matching-prefix) 798 Destination: 2001:db8:1::1 799 Candidate Source Addresses: 2001:db8:1::2 (care-of address) or 2001: 800 db8:3::2 (home address) 801 Result: 2001:db8:3::2 (prefer home address) 803 Destination: 2002:c633:6401::1 804 Candidate Source Addresses: 2002:c633:6401::d5e3:7953:13eb:22e8 805 (temporary) or 2001:db8:1::2 806 Result: 2002:c633:6401::d5e3:7953:13eb:22e8 (prefer matching label) 808 Destination: 2001:db8:1::d5e3:0:0:1 809 Candidate Source Addresses: 2001:db8:1::2 or 2001:db8:1::d5e3:7953: 810 13eb:22e8 (temporary) 811 Result: 2001:db8:1::2 (prefer public address) 813 10.2. Default Destination Address Selection 815 The destination address selection rules, in conjunction with the 816 default policy table and the source address selection rules, produce 817 the following behavior: 819 Candidate Source Addresses: 2001:db8:1::2 or fe80::1 or 169.254.13.78 820 Destination Address List: 2001:db8:1::1 or 198.51.100.121 821 Result: 2001:db8:1::1 (src 2001:db8:1::2) then 198.51.100.121 (src 822 169.254.13.78) (prefer matching scope) 824 Candidate Source Addresses: fe80::1 or 198.51.100.117 825 Destination Address List: 2001:db8:1::1 or 198.51.100.121 826 Result: 198.51.100.121 (src 198.51.100.117) then 2001:db8:1::1 (src 827 fe80::1) (prefer matching scope) 829 Candidate Source Addresses: 2001:db8:1::2 or fe80::1 or 10.1.2.4 830 Destination Address List: 2001:db8:1::1 or 10.1.2.3 831 Result: 2001:db8:1::1 (src 2001:db8:1::2) then 10.1.2.3 (src 832 10.1.2.4) (prefer higher precedence) 834 Candidate Source Addresses: 2001:db8:1::2 or fe80::2 835 Destination Address List: 2001:db8:1::1 or fe80::1 836 Result: fe80::1 (src fe80::2) then 2001:db8:1::1 (src 2001:db8:1::2) 837 (prefer smaller scope) 839 Candidate Source Addresses: 2001:db8:1::2 (care-of address) or 2001: 840 db8:3::1 (home address) or fe80::2 (care-of address) 841 Destination Address List: 2001:db8:1::1 or fe80::1 842 Result: 2001:db8:1::1 (src 2001:db8:3::1) then fe80::1 (src fe80::2) 843 (prefer home address) 845 Candidate Source Addresses: 2001:db8:1::2 or fe80::2 (deprecated) 846 Destination Address List: 2001:db8:1::1 or fe80::1 847 Result: 2001:db8:1::1 (src 2001:db8:1::2) then fe80::1 (src fe80::2) 848 (avoid deprecated addresses) 850 Candidate Source Addresses: 2001:db8:1::2 or 2001:db8:3f44::2 or 851 fe80::2 852 Destination Address List: 2001:db8:1::1 or 2001:db8:3ffe::1 853 Result: 2001:db8:1::1 (src 2001:db8:1::2) then 2001:db8:3ffe::1 (src 854 2001:db8:3f44::2) (longest matching prefix) 856 Candidate Source Addresses: 2002:c633:6401::2 or fe80::2 857 Destination Address List: 2002:c633:6401::1 or 2001:db8:1::1 858 Result: 2002:c633:6401::1 (src 2002:c633:6401::2) then 2001:db8:1::1 859 (src 2002:c633:6401::2) (prefer matching label) 861 Candidate Source Addresses: 2002:c633:6401::2 or 2001:db8:1::2 or 862 fe80::2 863 Destination Address List: 2002:c633:6401::1 or 2001:db8:1::1 864 Result: 2001:db8:1::1 (src 2001:db8:1::2) then 2002:c633:6401::1 (src 865 2002:c633:6401::2) (prefer higher precedence) 867 10.3. Configuring Preference for IPv6 or IPv4 869 The default policy table gives IPv6 addresses higher precedence than 870 IPv4 addresses. This means that applications will use IPv6 in 871 preference to IPv4 when the two are equally suitable. An 872 administrator can change the policy table to prefer IPv4 addresses by 873 giving the ::ffff:0.0.0.0/96 prefix a higher precedence: 875 Prefix Precedence Label 876 ::1/128 50 0 877 ::/0 40 1 878 fc00::/7 35 13 879 ::ffff:0:0/96 100 4 880 2002::/16 7 2 881 2001::/32 5 5 882 ::/96 1 3 883 fec0::/10 1 11 884 3ffe::/16 1 12 886 This change to the default policy table produces the following 887 behavior: 889 Candidate Source Addresses: 2001::2 or fe80::1 or 169.254.13.78 890 Destination Address List: 2001::1 or 198.51.100.121 891 Unchanged Result: 2001::1 (src 2001::2) then 198.51.100.121 (src 892 169.254.13.78) (prefer matching scope) 894 Candidate Source Addresses: fe80::1 or 198.51.100.117 895 Destination Address List: 2001::1 or 198.51.100.121 896 Unchanged Result: 198.51.100.121 (src 198.51.100.117) then 2001::1 897 (src fe80::1) (prefer matching scope) 899 Candidate Source Addresses: 2001::2 or fe80::1 or 10.1.2.4 900 Destination Address List: 2001::1 or 10.1.2.3 901 New Result: 10.1.2.3 (src 10.1.2.4) then 2001::1 (src 2001::2) 902 (prefer higher precedence) 904 10.3.1. Handling Broken IPv6 906 One problem in practice that has been recently observed occurs when a 907 host has IPv4 connectivity to the Internet, but has "broken" IPv6 908 connectivity to the Internet in that it has a global IPv6 address, 909 but is discconnected from the IPv6 Internet. Since the default 910 policy table prefers IPv6, this can result in unwanted timeouts. 912 This can be solved by configuring the table to prefer IPv4 as shown 913 above. An implementation that has some means to detect that it is 914 not connected to the IPv6 Internet MAY do this automatically. An 915 implementation could instead treat it as part of its implementation 916 of Rule 1 (avoid unusable destinations). 918 10.4. Configuring Preference for Link-Local Addresses 920 The destination address selection rules give preference to 921 destinations of smaller scope. For example, a link-local destination 922 will be sorted before a global scope destination when the two are 923 otherwise equally suitable. An administrator can change the policy 924 table to reverse this preference and sort global destinations before 925 link-local destinations: 927 Prefix Precedence Label 928 ::1/128 50 0 929 ::/0 40 1 930 fc00::/7 35 13 931 fe80::/10 33 1 932 ::ffff:0:0/96 10 4 933 2002::/16 7 2 934 2001::/32 5 5 935 ::/96 1 3 936 fec0::/10 1 11 937 3ffe::/16 1 12 939 This change to the default policy table produces the following 940 behavior: 942 Candidate Source Addresses: 2001::2 or fe80::2 943 Destination Address List: 2001::1 or fe80::1 944 New Result: 2001::1 (src 2001::2) then fe80::1 (src fe80::2) (prefer 945 higher precedence) 947 Candidate Source Addresses: 2001::2 (deprecated) or fe80::2 948 Destination Address List: 2001::1 or fe80::1 949 Unchanged Result: fe80::1 (src fe80::2) then 2001::1 (src 2001::2) 950 (avoid deprecated addresses) 952 10.5. Configuring a Multi-Homed Site 954 Consider a site A that has a business-critical relationship with 955 another site B. To support their business needs, the two sites have 956 contracted for service with a special high-performance ISP. This is 957 in addition to the normal Internet connection that both sites have 958 with different ISPs. The high-performance ISP is expensive and the 959 two sites wish to use it only for their business-critical traffic 960 with each other. 962 Each site has two global prefixes, one from the high-performance ISP 963 and one from their normal ISP. Site A has prefix 2001:aaaa:aaaa::/48 964 from the high-performance ISP and prefix 2007:0:aaaa::/48 from its 965 normal ISP. Site B has prefix 2001:bbbb:bbbb::/48 from the high- 966 performance ISP and prefix 2007:0:bbbb::/48 from its normal ISP. All 967 hosts in both sites register two addresses in the DNS. 969 The routing within both sites directs most traffic to the egress to 970 the normal ISP, but the routing directs traffic sent to the other 971 site's 2001 prefix to the egress to the high-performance ISP. To 972 prevent unintended use of their high-performance ISP connection, the 973 two sites implement ingress filtering to discard traffic entering 974 from the high-performance ISP that is not from the other site. 976 The default policy table and address selection rules produce the 977 following behavior: 979 Candidate Source Addresses: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or 980 fe80::a 981 Destination Address List: 2001:bbbb:bbbb::b or 2007:0:bbbb::b 982 Result: 2007:0:bbbb::b (src 2007:0:aaaa::a) then 2001:bbbb:bbbb::b 983 (src 2001:aaaa:aaaa::a) (longest matching prefix) 985 In other words, when a host in site A initiates a connection to a 986 host in site B, the traffic does not take advantage of their 987 connections to the high-performance ISP. This is not their desired 988 behavior. 990 Candidate Source Addresses: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or 991 fe80::a 992 Destination Address List: 2001:cccc:cccc::c or 2006:cccc:cccc::c 993 Result: 2001:cccc:cccc::c (src 2001:aaaa:aaaa::a) then 2006:cccc: 994 cccc::c (src 2007:0:aaaa::a) (longest matching prefix) 996 In other words, when a host in site A initiates a connection to a 997 host in some other site C, the reverse traffic may come back through 998 the high-performance ISP. Again, this is not their desired behavior. 1000 This predicament demonstrates the limitations of the longest- 1001 matching-prefix heuristic in multi-homed situations. 1003 However, the administrators of sites A and B can achieve their 1004 desired behavior via policy table configuration. For example, they 1005 can use the following policy table: 1007 Prefix Precedence Label 1008 ::1/128 50 0 1009 2001:aaaa:aaaa::/48 43 6 1010 2001:bbbb:bbbb::/48 43 6 1011 ::/0 40 1 1012 fc00::/7 35 13 1013 ::ffff:0:0/96 10 4 1014 2002::/16 7 2 1015 2001::/32 5 5 1016 ::/96 1 3 1017 fec0::/10 1 11 1018 3ffe::/16 1 12 1020 This policy table produces the following behavior: 1022 Candidate Source Addresses: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or 1023 fe80::a 1024 Destination Address List: 2001:bbbb:bbbb::b or 2007:0:bbbb::b 1025 New Result: 2001:bbbb:bbbb::b (src 2001:aaaa:aaaa::a) then 2007:0: 1026 bbbb::b (src 2007:0:aaaa::a) (prefer higher precedence) 1028 In other words, when a host in site A initiates a connection to a 1029 host in site B, the traffic uses the high-performance ISP as desired. 1031 Candidate Source Addresses: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or 1032 fe80::a 1033 Destination Address List: 2001:cccc:cccc::c or 2006:cccc:cccc::c 1034 New Result: 2006:cccc:cccc::c (src 2007:0:aaaa::a) then 2001:cccc: 1035 cccc::c (src 2007:0:aaaa::a) (longest matching prefix) 1037 In other words, when a host in site A initiates a connection to a 1038 host in some other site C, the traffic uses the normal ISP as 1039 desired. 1041 10.6. Configuring ULA Preference 1043 RFC 5220 [RFC5220] sections 2.1.4, 2.2.2, and 2.2.3 describe address 1044 selection problems related to ULAs [RFC4193]. By default, global 1045 IPv6 destinations are preferred over ULA destinations, since an 1046 arbitrary ULA is not necessarily reachable: 1048 Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1 1049 Destination Address List: 2001:db8:2::2 or fd22:2222:2222:2::2 1050 Result: 2001:db8:2::2 (src 2001:db8:1::1) then fd22:2222:2222:2::2 1051 (src fd11:1111:1111:1::1) (prefer higher precedence) 1053 However, a site-specific policy entry can be used to cause ULAs 1054 within a site to be preferred over global addresses as follows. 1056 Prefix Precedence Label 1057 ::1/128 50 0 1058 fd11:1111:1111::/48 45 14 1059 ::/0 40 1 1060 fc00::/7 35 13 1061 ::ffff:0:0/96 10 4 1062 2002::/16 7 2 1063 2001::/32 5 5 1064 ::/96 1 3 1065 fec0::/10 1 11 1066 3ffe::/16 1 12 1068 Such a configuration would have the following effect: 1070 Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1 1071 Destination Address List: 2001:db8:2::2 or fd22:2222:2222:2::2 1072 Unchanged Result: 2001:db8:2::2 (src 2001:db8:1::1) then fd22:2222: 1073 2222:2::2 (src fd11:1111:1111:1::1) (prefer higher precedence) 1075 Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1 1076 Destination Address List: 2001:db8:2::2 or fd11:1111:1111:2::2 1077 New Result: fd11:1111:1111:2::2 (src fd11:1111:1111:1::1) then 2001: 1078 db8:2::2 (src 2001:db8:1::1) (prefer higher precedence) 1080 Since ULAs are defined to have a /48 site prefix, an implementation 1081 might choose to add such a row automatically on a machine with a ULA. 1083 It is also worth noting that ULAs are assigned global scope. As 1084 such, the existence of one or more rows in the prefix policy table is 1085 important so that source address selection does not choose a ULA 1086 purely based on longest match: 1088 Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1 1089 Destination Address List: ff00:1 1090 Result: 2001:db8:1::1 (prefer matching label) 1092 10.7. Configuring 6to4 Preference 1094 By default, NAT'ed IPv4 is preferred over 6to4-relayed connectivity: 1096 Candidate Source Addresses: 2002:836b:4179::2 or 10.1.2.3 1097 Destination Address List: 2001:db8:1::1 or 203.0.113.1 1098 Result: 203.0.113.1 (src 10.1.2.3) then 2001:db8:1::1 (src 2002:836b: 1099 4179::2) (prefer matching label) 1101 However, NAT'ed IPv4 is now also preferred over 6to4-to-6to4 1102 connectivity by default. Since a 6to4 prefix might be used natively 1103 within an organization, a site-specific policy entry can be used to 1104 cause native IPv6 communication (using a 6to4 prefix) to be preferred 1105 over NAT'ed IPv4 as follows. 1107 Prefix Precedence Label 1108 ::1/128 50 0 1109 2002:836b:4179::/48 45 14 1110 ::/0 40 1 1111 fc00::/7 35 13 1112 ::ffff:0:0/96 10 4 1113 2002::/16 7 2 1114 2001::/32 5 5 1115 ::/96 1 3 1116 fec0::/10 1 11 1117 3ffe::/16 1 12 1119 Such a configuration would have the following effect: 1121 Candidate Source Addresses: 2002:836b:4179:1::1 or 10.1.2.3 1122 Destination Address List: 2002:836b:4179:2::2 or 203.0.113.1 1123 New Result: 2002:836b:4179:2::2 (src 2002:836b:4179:1::1) then 1124 203.0.113.1 (sec 10.1.2.3) (prefer higher precedence) 1126 Since 6to4 addresses are defined to have a /48 site prefix, an 1127 implementation might choose to add such a row automatically on a 1128 machine with a native IPv6 address with a 6to4 prefix. 1130 11. References 1132 11.1. Normative References 1134 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1135 Requirement Levels", BCP 14, RFC 2119, March 1997. 1137 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1138 via IPv4 Clouds", RFC 3056, February 2001. 1140 [RFC3701] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address 1141 Allocation) Phaseout", RFC 3701, March 2004. 1143 [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local 1144 Addresses", RFC 3879, September 2004. 1146 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1147 Addresses", RFC 4193, October 2005. 1149 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1150 Architecture", RFC 4291, February 2006. 1152 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1153 Network Address Translations (NATs)", RFC 4380, 1154 February 2006. 1156 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1157 Address Autoconfiguration", RFC 4862, September 2007. 1159 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1160 Extensions for Stateless Address Autoconfiguration in 1161 IPv6", RFC 4941, September 2007. 1163 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 1164 Algorithm", RFC 6145, April 2011. 1166 11.2. Informative References 1168 [I-D.ietf-6man-addr-select-opt] 1169 Matsumoto, A., Fujisaki, T., Kato, J., and T. Chown, 1170 "Distributing Address Selection Policy using DHCPv6", 1171 draft-ietf-6man-addr-select-opt-03 (work in progress), 1172 February 2012. 1174 [RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794, 1175 April 1995. 1177 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1178 E. Lear, "Address Allocation for Private Internets", 1179 BCP 5, RFC 1918, February 1996. 1181 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1182 Defeating Denial of Service Attacks which employ IP Source 1183 Address Spoofing", BCP 38, RFC 2827, May 2000. 1185 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 1186 Stevens, "Basic Socket Interface Extensions for IPv6", 1187 RFC 3493, February 2003. 1189 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 1190 Configuration of IPv4 Link-Local Addresses", RFC 3927, 1191 May 2005. 1193 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 1194 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 1195 March 2005. 1197 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1198 More-Specific Routes", RFC 4191, November 2005. 1200 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1201 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1203 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1204 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1205 September 2007. 1207 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 1208 Socket API for Source Address Selection", RFC 5014, 1209 September 2007. 1211 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1212 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1213 March 2008. 1215 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 1216 "Problem Statement for Default Address Selection in Multi- 1217 Prefix Environments: Operational Issues of RFC 3484 1218 Default Rules", RFC 5220, July 2008. 1220 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 1221 Infrastructures (6rd) -- Protocol Specification", 1222 RFC 5969, August 2010. 1224 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 1225 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 1226 October 2010. 1228 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 1229 in IPv6", RFC 6275, July 2011. 1231 Appendix A. Acknowledgements 1233 RFC 3484 acknowledged the contributions of the IPng Working Group, 1234 particularly Marc Blanchet, Brian Carpenter, Matt Crawford, Alain 1235 Durand, Steve Deering, Robert Elz, Jun-ichiro itojun Hagino, Tony 1236 Hain, M.T. Hollinger, JINMEI Tatuya, Thomas Narten, Erik Nordmark, 1237 Ken Powell, Markku Savela, Pekka Savola, Hesham Soliman, Dave Thaler, 1238 Mauro Tortonesi, Ole Troan, and Stig Venaas. In addition, the 1239 anonymous IESG reviewers had many great comments and suggestions for 1240 clarification. 1242 This revision was heavily influenced by the work by Arifumi 1243 Matsumoto, Jun-ya Kato, and Tomohiro Fujisaki in a working draft that 1244 made proposals for this revision to adopt, with input from Pekka 1245 Savola, Remi Denis-Courmont, Francois-Xavier Le Bail, and the 6man 1246 Working Group. Dmitry Anipko, Mark Andrews, and Ray Hunter also 1247 provided valuable feedback on this revision. 1249 Appendix B. Changes Since RFC 3484 1251 Some changes were made to the default policy table that were deemed 1252 to be universally useful and cause no harm in every reasonable 1253 network environment. In doing so, care was taken to use the same 1254 preference and label values as in RFC 3484 whenever possible, and for 1255 new rows to use label values less likely to collide with values that 1256 might already be in use in additional rows on some hosts. These 1257 changes are: 1259 1. Added the Teredo [RFC4380] prefix (2001::/32), with the 1260 preference and label values already widely used in popular 1261 implementations. 1262 2. Added a row for ULAs (fc00::/7) below native IPv6 since they are 1263 not globally reachable, as discussed in Section 10.6. 1264 3. Added a row for site-local addresses (fec0::/10) in order to 1265 depreference them, for consistency with the example in 1266 Section 10.3, since they are deprecated [RFC3879]. 1267 4. Depreferenced 6to4 (2002::/32) below native IPv4 since 6to4 1268 connectivity is less reliable today (and is expected to be phased 1269 out over time, rather than becoming more reliable). It remains 1270 above Teredo since 6to4 is more efficient in terms of connection 1271 establishment time, bandwidth, and server load. 1272 5. Depreferenced IPv4-Compatible addresses (::/96) since they are 1273 now deprecated [RFC4291] and not in common use. 1274 6. Added a row for 6bone testing addresses (3ffe::/16) in order to 1275 depreference them as they have also been phased out [RFC3701]. 1277 Similarly, some changes were made to the rules, as follows: 1279 1. Changed the definition of CommonPrefixLen() to only compare bits 1280 up to the source address's prefix length. The previous 1281 definition used the entire source address, rather than only its 1282 prefix. As a result, when a source and destination addresses had 1283 the same prefix, common bits in the interface ID would previously 1284 result in overriding DNS load balancing [RFC1794] by forcing the 1285 destination address with the most bits in common to be always 1286 chosen. The updated definition allows DNS load balancing to 1287 continue to be used as a tie breaker. 1288 2. Added Rule 5.5 to allow choosing a source address from a prefix 1289 advertised by the chosen next-hop for a given destination. This 1290 allows better connectivity in the presence of BCP 38 [RFC2827] 1291 ingress filtering and egress filtering. Previously, RFC 3484 had 1292 issues with multiple egress networks reached via the same 1293 interface, as discussed in [RFC5220]. 1295 3. Removed restriction against anycast addresses in the candidate 1296 set of source addresses, since the restriction against using IPv6 1297 anycast addresses as source addresses was removed in Section 2.6 1298 of RFC 4291 [RFC4291]. 1299 4. Changed mapping of RFC 1918 [RFC1918] addresses to global scope 1300 in Section Section 3.2. Previously they were mapped to site- 1301 local scope. However, experience has resulted in current 1302 implementations already using global scope instead. When they 1303 were mapped to site-local, Destination Address Selection Rule 2 1304 (Prefer matching scope) would cause IPv6 to be preferred in 1305 scenarios such as that described in Section 10.7. The change to 1306 global scope allows configurability via the prefix policy table. 1308 Finally, some editorial changes were made, including: 1310 1. Changed global IP addresses in examples to use ranges reserved 1311 for documentation. 1312 2. Added additional examples in Section 10.6 and Section 10.7. 1313 3. Added Section 10.3.1 on "broken" IPv6. 1314 4. Updated references. 1316 Authors' Addresses 1318 Dave Thaler (editor) 1319 Microsoft 1320 One Microsoft Way 1321 Redmond, WA 98052 1323 Phone: +1 425 703 8835 1324 Email: dthaler@microsoft.com 1326 Richard Draves 1327 Microsoft Research 1328 One Microsoft Way 1329 Redmond, WA 98052 1331 Phone: +1 425 706 2268 1332 Email: richdr@microsoft.com 1333 Tim Chown 1334 University of Southampt on 1335 Southampton, Hampshire SO17 1BJ 1336 United Kingdom 1338 Email: tjc@ecs.soton.ac.uk