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