idnits 2.17.1 draft-ietf-6man-rfc3484bis-03.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 11 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 date (May 5, 2012) is 4374 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 (~~), 6 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: November 6, 2012 A. Matsumoto 7 NTT 8 T. Chown 9 University of Southampton 10 May 5, 2012 12 Default Address Selection for Internet Protocol version 6 (IPv6) 13 draft-ietf-6man-rfc3484bis-03.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 November 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 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Conventions Used in This Document . . . . . . . . . . . . 5 69 2. Context in Which the Algorithms Operate . . . . . . . . . . . 5 70 2.1. Policy Table . . . . . . . . . . . . . . . . . . . . . . . 7 71 2.2. Common Prefix Length . . . . . . . . . . . . . . . . . . . 8 72 3. Address Properties . . . . . . . . . . . . . . . . . . . . . . 8 73 3.1. Scope Comparisons . . . . . . . . . . . . . . . . . . . . 8 74 3.2. IPv4 Addresses and IPv4-Mapped Addresses . . . . . . . . . 9 75 3.3. Other IPv6 Addresses with Embedded IPv4 Addresses . . . . 9 76 3.4. IPv6 Loopback Address and Other Format Prefixes . . . . . 9 77 3.5. Mobility Addresses . . . . . . . . . . . . . . . . . . . . 10 78 4. Candidate Source Addresses . . . . . . . . . . . . . . . . . . 10 79 5. Source Address Selection . . . . . . . . . . . . . . . . . . . 11 80 6. Destination Address Selection . . . . . . . . . . . . . . . . 14 81 7. Interactions with Routing . . . . . . . . . . . . . . . . . . 16 82 8. Implementation Considerations . . . . . . . . . . . . . . . . 16 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 84 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 85 10.1. Default Source Address Selection . . . . . . . . . . . . . 18 86 10.2. Default Destination Address Selection . . . . . . . . . . 19 87 10.3. Configuring Preference for IPv6 or IPv4 . . . . . . . . . 20 88 10.3.1. Handling Broken IPv6 . . . . . . . . . . . . . . . . 21 89 10.4. Configuring Preference for Link-Local Addresses . . . . . 21 90 10.5. Configuring a Multi-Homed Site . . . . . . . . . . . . . . 22 91 10.6. Configuring ULA Preference . . . . . . . . . . . . . . . . 24 92 10.7. Configuring 6to4 Preference . . . . . . . . . . . . . . . 25 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 94 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 95 11.2. Informative References . . . . . . . . . . . . . . . . . . 26 96 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 28 97 Appendix B. Changes Since RFC 3484 . . . . . . . . . . . . . . . 28 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 100 1. Introduction 102 The IPv6 addressing architecture [RFC4291] allows multiple unicast 103 addresses to be assigned to interfaces. These addresses may have 104 different reachability scopes (link-local, site-local, or global). 105 These addresses may also be "preferred" or "deprecated" [RFC4862]. 106 Privacy considerations have introduced the concepts of "public 107 addresses" and "temporary addresses" [RFC4941]. The mobility 108 architecture introduces "home addresses" and "care-of addresses" 109 [RFC6275]. In addition, multi-homing situations will result in more 110 addresses per node. For example, a node may have multiple 111 interfaces, some of them tunnels or virtual interfaces, or a site may 112 have multiple ISP attachments with a global prefix per ISP. 114 The end result is that IPv6 implementations will very often be faced 115 with multiple possible source and destination addresses when 116 initiating communication. It is desirable to have default 117 algorithms, common across all implementations, for selecting source 118 and destination addresses so that developers and administrators can 119 reason about and predict the behavior of their systems. 121 Furthermore, dual or hybrid stack implementations, which support both 122 IPv6 and IPv4, will very often need to choose between IPv6 and IPv4 123 when initiating communication. For example, when DNS name resolution 124 yields both IPv6 and IPv4 addresses and the network protocol stack 125 has available both IPv6 and IPv4 source addresses. In such cases, a 126 simple policy to always prefer IPv6 or always prefer IPv4 can produce 127 poor behavior. As one example, suppose a DNS name resolves to a 128 global IPv6 address and a global IPv4 address. If the node has 129 assigned a global IPv6 address and a 169.254/16 auto-configured IPv4 130 address [RFC3927], then IPv6 is the best choice for communication. 131 But if the node has assigned only a link-local IPv6 address and a 132 global IPv4 address, then IPv4 is the best choice for communication. 133 The destination address selection algorithm solves this with a 134 unified procedure for choosing among both IPv6 and IPv4 addresses. 136 The algorithms in this document are specified as a set of rules that 137 define a partial ordering on the set of addresses that are available 138 for use. In the case of source address selection, a node typically 139 has multiple addresses assigned to its interfaces, and the source 140 address ordering rules in section 5 define which address is the 141 "best" one to use. In the case of destination address selection, the 142 DNS may return a set of addresses for a given name, and an 143 application needs to decide which one to use first, and in what order 144 to try others should the first one not be reachable. The destination 145 address ordering rules in section 6, when applied to the set of 146 addresses returned by the DNS, provide such a recommended ordering. 148 This document specifies source address selection and destination 149 address selection separately, but using a common context so that 150 together the two algorithms yield useful results. The algorithms 151 attempt to choose source and destination addresses of appropriate 152 scope and configuration status (preferred or deprecated in the RFC 153 4862 sense). Furthermore, this document suggests a preferred method, 154 longest matching prefix, for choosing among otherwise equivalent 155 addresses in the absence of better information. 157 This document also specifies policy hooks to allow administrative 158 override of the default behavior. For example, using these hooks an 159 administrator can specify a preferred source prefix for use with a 160 destination prefix, or prefer destination addresses with one prefix 161 over addresses with another prefix. These hooks give an 162 administrator flexibility in dealing with some multi-homing and 163 transition scenarios, but they are certainly not a panacea. 165 The selection rules specified in this document MUST NOT be construed 166 to override an application or upper-layer's explicit choice of a 167 legal destination or source address. 169 1.1. Conventions Used in This Document 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in BCP 14, RFC 2119 174 [RFC2119]. 176 2. Context in Which the Algorithms Operate 178 Our context for address selection derives from the most common 179 implementation architecture, which separates the choice of 180 destination address from the choice of source address. Consequently, 181 we have two separate algorithms for these tasks. The algorithms are 182 designed to work well together and they share a mechanism for 183 administrative policy override. 185 In this implementation architecture, applications use APIs [RFC3493] 186 like getaddrinfo() that return a list of addresses to the 187 application. This list might contain both IPv6 and IPv4 addresses 188 (sometimes represented as IPv4-mapped addresses). The application 189 then passes a destination address to the network stack with connect() 190 or sendto(). The application would then typically try the first 191 address in the list, looping over the list of addresses until it 192 finds a working address. In any case, the network layer is never in 193 a situation where it needs to choose a destination address from 194 several alternatives. The application might also specify a source 195 address with bind(), but often the source address is left 196 unspecified. Therefore the network layer does often choose a source 197 address from several alternatives. 199 As a consequence, we intend that implementations of getaddrinfo() 200 will use the destination address selection algorithm specified here 201 to sort the list of IPv6 and IPv4 addresses that they return. 202 Separately, the IPv6 network layer will use the source address 203 selection algorithm when an application or upper-layer has not 204 specified a source address. Application of this specification to 205 source address selection in an IPv4 network layer may be possible but 206 this is not explored further here. 208 Well-behaved applications SHOULD iterate through the list of 209 addresses returned from getaddrinfo() until they find a working 210 address. 212 The algorithms use several criteria in making their decisions. The 213 combined effect is to prefer destination/source address pairs for 214 which the two addresses are of equal scope or type, prefer smaller 215 scopes over larger scopes for the destination address, prefer non- 216 deprecated source addresses, avoid the use of transitional addresses 217 when native addresses are available, and all else being equal prefer 218 address pairs having the longest possible common prefix. For source 219 address selection, temporary addresses [RFC4941] are preferred over 220 public addresses. In mobile situations [RFC6275], home addresses are 221 preferred over care-of addresses. If an address is simultaneously a 222 home address and a care-of address (indicating the mobile node is "at 223 home" for that address), then the home/care-of address is preferred 224 over addresses that are solely a home address or solely a care-of 225 address. 227 This specification optionally allows for the possibility of 228 administrative configuration of policy (e.g., via manual 229 configuration or a DHCP option such as that proposed in 230 [I-D.ietf-6man-addr-select-opt]) that can override the default 231 behavior of the algorithms. The policy override consists of the 232 following set of state, which SHOULD be configurable: 234 o Policy Table (Section 2.1): a table that specifies precedence 235 values and preferred source prefixes for destination prefixes. 236 o Automatic Row Additions flag (Section 2.1): a flag that specifies 237 whether the implementation may automatically add site-specific 238 rows for certain types of addresses. 239 o Privacy Preference flag (Section 5): a flag that specifies whether 240 temporary source addresses or stable source addresses are 241 preferred by default, when both types exist. 243 2.1. Policy Table 245 The policy table is a longest-matching-prefix lookup table, much like 246 a routing table. Given an address A, a lookup in the policy table 247 produces two values: a precedence value Precedence(A) and a 248 classification or label Label(A). 250 The precedence value Precedence(A) is used for sorting destination 251 addresses. If Precedence(A) > Precedence(B), we say that address A 252 has higher precedence than address B, meaning that our algorithm will 253 prefer to sort destination address A before destination address B. 255 The label value Label(A) allows for policies that prefer a particular 256 source address prefix for use with a destination address prefix. The 257 algorithms prefer to use a source address S with a destination 258 address D if Label(S) = Label(D). 260 IPv6 implementations SHOULD support configurable address selection 261 via a mechanism at least as powerful as the policy tables defined 262 here. It is important that implementations provide a way to change 263 the default policies as more experience is gained. Sections 10.3 264 through 10.7 provide examples of the kind of changes that might be 265 needed. 267 If an implementation is not configurable or has not been configured, 268 then it SHOULD operate according to the algorithms specified here in 269 conjunction with the following default policy table: 271 Prefix Precedence Label 272 ::1/128 50 0 273 ::/0 40 1 274 ::ffff:0:0/96 35 4 275 2002::/16 30 2 276 2001::/32 5 5 277 fc00::/7 3 13 278 ::/96 1 3 279 fec0::/10 1 11 280 3ffe::/16 1 12 282 An implementation MAY automatically add additional site-specific rows 283 to the default table based on its configured addresses, such as for 284 ULAs and 6to4 addresses for instance (see Section 10.6 and 285 Section 10.7 for examples). Any such rows automatically added by the 286 implementation as a result of address acquisition MUST NOT override a 287 row for the same prefix configured via other means. That is, rows 288 can be added but never updated automatically. An implementation 289 SHOULD provide a means (the Automatic Row Additions flag) for an 290 administrator to disable automatic row additions. 292 One effect of the default policy table is to prefer using native 293 source addresses with native destination addresses, 6to4 [RFC3056] 294 source addresses with 6to4 destination addresses, etc. Another 295 effect of the default policy table is to prefer communication using 296 IPv6 addresses to communication using IPv4 addresses, if matching 297 source addresses are available. 299 Policy table entries for scoped address prefixes MAY be qualified 300 with an optional zone index. If so, a prefix table entry only 301 matches against an address during a lookup if the zone index also 302 matches the address's zone index. 304 2.2. Common Prefix Length 306 We define the common prefix length CommonPrefixLen(S, D) of a source 307 address S and a destination address D as the length of the longest 308 prefix (looking at the most significant, or leftmost, bits) that the 309 two addresses have in common, up to the length of S's prefix (i.e., 310 the portion of the address not including the interface ID). For 311 example, CommonPrefixLen(fe80::1, fe80::2) is 64. 313 3. Address Properties 315 In the rules given in later sections, addresses of different types 316 (e.g., IPv4, IPv6, multicast and unicast) are compared against each 317 other. Some of these address types have properties that aren't 318 directly comparable to each other. For example, IPv6 unicast 319 addresses can be "preferred" or "deprecated" [RFC4862], while IPv4 320 addresses have no such notion. To compare such addresses using the 321 ordering rules (e.g., to use "preferred" addresses in preference to 322 "deprecated" addresses), the following mappings are defined. 324 3.1. Scope Comparisons 326 Multicast destination addresses have a 4-bit scope field that 327 controls the propagation of the multicast packet. The IPv6 328 addressing architecture defines scope field values for interface- 329 local (0x1), link-local (0x2), subnet-local (0x3), admin-local (0x4), 330 site-local (0x5), organization-local (0x8), and global (0xE) scopes 331 [RFC4007]. 333 Use of the source address selection algorithm in the presence of 334 multicast destination addresses requires the comparison of a unicast 335 address scope with a multicast address scope. We map unicast link- 336 local to multicast link-local, unicast site-local to multicast site- 337 local, and unicast global scope to multicast global scope. For 338 example, unicast site-local is equal to multicast site-local, which 339 is smaller than multicast organization-local, which is smaller than 340 unicast global, which is equal to multicast global. 342 We write Scope(A) to mean the scope of address A. For example, if A 343 is a link-local unicast address and B is a site-local multicast 344 address, then Scope(A) < Scope(B). 346 This mapping implicitly conflates unicast site boundaries and 347 multicast site boundaries [RFC4007]. 349 3.2. IPv4 Addresses and IPv4-Mapped Addresses 351 The destination address selection algorithm operates on both IPv6 and 352 IPv4 addresses. For this purpose, IPv4 addresses should be 353 represented as IPv4-mapped addresses [RFC4291]. For example, to 354 lookup the precedence or other attributes of an IPv4 address in the 355 policy table, lookup the corresponding IPv4-mapped IPv6 address. 357 IPv4 addresses are assigned scopes as follows. IPv4 auto- 358 configuration addresses [RFC3927], which have the prefix 169.254/16, 359 are assigned link-local scope. IPv4 loopback addresses ([RFC1918], 360 section 4.2.2.11), which have the prefix 127/8, are assigned link- 361 local scope (analogously to the treatment of the IPv6 loopback 362 address ([RFC4007], section 4)). Other IPv4 addresses (including 363 IPv4 private addresses [RFC1918] and Shared Address Space addresses 364 [RFC6598]) are assigned global scope. 366 IPv4 addresses should be treated as having "preferred" (in the RFC 367 4862 sense) configuration status. 369 3.3. Other IPv6 Addresses with Embedded IPv4 Addresses 371 IPv4-compatible addresses [RFC4291], IPv4-mapped [RFC4291], IPv4- 372 converted [RFC6145], IPv4-translatable [RFC6145], and 6to4 addresses 373 [RFC3056] contain an embedded IPv4 address. For the purposes of this 374 document, these addresses should be treated as having global scope. 376 IPv4-compatible, IPv4-mapped, and IPv4-converted addresses should be 377 treated as having "preferred" (in the RFC 4862 sense) configuration 378 status. 380 3.4. IPv6 Loopback Address and Other Format Prefixes 382 The loopback address should be treated as having link-local scope 383 ([RFC4007], section 4) and "preferred" (in the RFC 4862 sense) 384 configuration status. 386 NSAP addresses and other addresses with as-yet-undefined format 387 prefixes should be treated as having global scope and "preferred" (in 388 the RFC 4862) configuration status. Later standards may supersede 389 this treatment. 391 3.5. Mobility Addresses 393 Some nodes may support mobility using the concepts of home address 394 and care-of address (for example see [RFC6275]). Conceptually, a 395 home address is an IP address assigned to a mobile node and used as 396 the permanent address of the mobile node. A care-of address is an IP 397 address associated with a mobile node while visiting a foreign link. 398 When a mobile node is on its home link, it may have an address that 399 is simultaneously a home address and a care-of address. 401 For the purposes of this document, it is sufficient to know whether 402 or not one's own addresses are designated as home addresses or 403 care-of addresses. Whether or not an address should be designated a 404 home address or care-of address is outside the scope of this 405 document. 407 4. Candidate Source Addresses 409 The source address selection algorithm uses the concept of a 410 "candidate set" of potential source addresses for a given destination 411 address. The candidate set is the set of all addresses that could be 412 used as a source address; the source address selection algorithm will 413 pick an address out of that set. We write CandidateSource(A) to 414 denote the candidate set for the address A. 416 It is RECOMMENDED that the candidate source addresses be the set of 417 unicast addresses assigned to the interface that will be used to send 418 to the destination. (The "outgoing" interface.) On routers, the 419 candidate set MAY include unicast addresses assigned to any interface 420 that forwards packets, subject to the restrictions described below. 422 Discussion: The Neighbor Discovery Redirect mechanism [RFC4861] 423 requires that routers verify that the source address of a packet 424 identifies a neighbor before generating a Redirect, so it is 425 advantageous for hosts to choose source addresses assigned to the 426 outgoing interface. Implementations that wish to support the use 427 of global source addresses assigned to a loopback interface should 428 behave as if the loopback interface originates and forwards the 429 packet. 431 In some cases the destination address may be qualified with a zone 432 index or other information that will constrain the candidate set. 434 For multicast and link-local destination addresses, the set of 435 candidate source addresses MUST only include addresses assigned to 436 interfaces belonging to the same link as the outgoing interface. 438 Discussion: The restriction for multicast destination addresses is 439 necessary because currently-deployed multicast forwarding 440 algorithms use Reverse Path Forwarding (RPF) checks. 442 For site-local destination addresses, the set of candidate source 443 addresses MUST only include addresses assigned to interfaces 444 belonging to the same site as the outgoing interface. 446 In any case, multicast addresses, and the unspecified address MUST 447 NOT be included in a candidate set. 449 If an application or upper layer specifies a source address that is 450 not in the candidate set for the destination, then the network layer 451 MUST treat this as an error. The specified source address may 452 influence the candidate set, by affecting the choice of outgoing 453 interface. If the application or upper layer specifies a source 454 address that is in the candidate set for the destination, then the 455 network layer MUST respect that choice. If the application or upper 456 layer does not specify a source address, then the network layer uses 457 the source address selection algorithm specified in the next section. 459 On IPv6-only nodes that support SIIT [RFC6145], if the destination 460 address is an IPv4-converted address then the candidate set MUST 461 contain only IPv4-translatable addresses. 463 5. Source Address Selection 465 The source address selection algorithm produces as output a single 466 source address for use with a given destination address. This 467 algorithm only applies to IPv6 destination addresses, not IPv4 468 addresses. 470 The algorithm is specified here in terms of a list of pair-wise 471 comparison rules that (for a given destination address D) imposes a 472 "greater than" ordering on the addresses in the candidate set 473 CandidateSource(D). The address at the front of the list after the 474 algorithm completes is the one the algorithm selects. 476 Note that conceptually, a sort of the candidate set is being 477 performed, where a set of rules define the ordering among addresses. 478 But because the output of the algorithm is a single source address, 479 an implementation need not actually sort the set; it need only 480 identify the "maximum" value that ends up at the front of the sorted 481 list. 483 The ordering of the addresses in the candidate set is defined by a 484 list of eight pair-wise comparison rules, with each rule placing a 485 "greater than," "less than" or "equal to" ordering on two source 486 addresses with respect to each other (and that rule). In the case 487 that a given rule produces a tie, i.e., provides an "equal to" result 488 for the two addresses, the remaining rules are applied (in order) to 489 just those addresses that are tied to break the tie. Note that if a 490 rule produces a single clear "winner" (or set of "winners" in the 491 case of ties), those addresses not in the winning set can be 492 discarded from further consideration, with subsequent rules applied 493 only to the remaining addresses. If the eight rules fail to choose a 494 single address, some unspecified tie-breaker should be used. 496 When comparing two addresses SA and SB from the candidate set, we say 497 "prefer SA" to mean that SA is "greater than" SB, and similarly we 498 say "prefer SB" to mean that SA is "less than" SB. 500 Rule 1: Prefer same address. 501 If SA = D, then prefer SA. Similarly, if SB = D, then prefer SB. 503 Rule 2: Prefer appropriate scope. 504 If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB and 505 otherwise prefer SA. Similarly, if Scope(SB) < Scope(SA): If 506 Scope(SB) < Scope(D), then prefer SA and otherwise prefer SB. 508 Rule 3: Avoid deprecated addresses. 509 The addresses SA and SB have the same scope. If one of the two 510 source addresses is "preferred" and one of them is "deprecated" (in 511 the RFC 4862 sense), then prefer the one that is "preferred." 513 Rule 4: Prefer home addresses. 514 If SA is simultaneously a home address and care-of address and SB is 515 not, then prefer SA. Similarly, if SB is simultaneously a home 516 address and care-of address and SA is not, then prefer SB. If SA is 517 just a home address and SB is just a care-of address, then prefer SA. 518 Similarly, if SB is just a home address and SA is just a care-of 519 address, then prefer SB. 521 Implementations should provide a mechanism allowing an application to 522 reverse the sense of this preference and prefer care-of addresses 523 over home addresses (e.g., via appropriate API extensions such as 524 [RFC5014]). Use of the mechanism should only affect the selection 525 rules for the invoking application. 527 Rule 5: Prefer outgoing interface. 528 If SA is assigned to the interface that will be used to send to D and 529 SB is assigned to a different interface, then prefer SA. Similarly, 530 if SB is assigned to the interface that will be used to send to D and 531 SA is assigned to a different interface, then prefer SB. 533 Rule 5.5: Prefer addresses in a prefix advertised by the next-hop 534 If SA or SA's prefix is assigned by the selected next-hop that will 535 be used to send to D and SB or SB's prefix is assigned by a different 536 next-hop, then prefer SA. Similarly, if SB or SB's prefix is 537 assigned by the next-hop that will be used to send to D and SA or 538 SA's prefix is assigned by a different next-hop, then prefer SB. 540 Discussion: An IPv6 implementation is not required to remember 541 which next-hops advertised which prefixes. The conceptual models 542 of IPv6 hosts in Section 5 of [RFC4861] and Section 3 of [RFC4191] 543 have no such requirement. Implementations that do not track this 544 information shall omit rule 5.5. 546 Rule 6: Prefer matching label. 547 If Label(SA) = Label(D) and Label(SB) <> Label(D), then prefer SA. 548 Similarly, if Label(SB) = Label(D) and Label(SA) <> Label(D), then 549 prefer SB. 551 Rule 7: Prefer temporary addresses. 552 If SA is a temporary address and SB is a public address, then prefer 553 SA. Similarly, if SB is a temporary address and SA is a public 554 address, then prefer SB. 556 Implementations MUST provide a mechanism allowing an application to 557 reverse the sense of this preference and prefer public addresses over 558 temporary addresses (e.g., via appropriate API extensions such as 559 [RFC5014]). Use of the mechanism should only affect the selection 560 rules for the invoking application. This default is intended to 561 address privacy concerns as discussed in [RFC4941], but introduces a 562 risk of applications potentially failing due to the relatively short 563 lifetime of temporary addresses or due to the possibility of the 564 reverse lookup of a temporary address either failing or returning a 565 randomized name. Implementations for which application compatibility 566 considerations outweigh these privacy concerns MAY reverse the sense 567 of this rule and by default prefer public addresses over temporary 568 addresses. There SHOULD be an administrative option (the Privacy 569 Preference flag) to change this preference, if the implementation 570 supports temporary addresses. If there is no such option, there MUST 571 be an administrative option to disable temporary addresses. 573 Rule 8: Use longest matching prefix. 574 If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then prefer SA. 575 Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then 576 prefer SB. 578 Rule 8 may be superseded if the implementation has other means of 579 choosing among source addresses. For example, if the implementation 580 somehow knows which source address will result in the "best" 581 communications performance. 583 Rule 2 (prefer appropriate scope) MUST be implemented and given high 584 priority because it can affect interoperability. 586 6. Destination Address Selection 588 The destination address selection algorithm takes a list of 589 destination addresses and sorts the addresses to produce a new list. 590 It is specified here in terms of the pair-wise comparison of 591 addresses DA and DB, where DA appears before DB in the original list. 593 The algorithm sorts together both IPv6 and IPv4 addresses. To find 594 the attributes of an IPv4 address in the policy table, the IPv4 595 address should be represented as an IPv4-mapped address. 597 We write Source(D) to indicate the selected source address for a 598 destination D. For IPv6 addresses, the previous section specifies the 599 source address selection algorithm. Source address selection for 600 IPv4 addresses is not specified in this document. 602 We say that Source(D) is undefined if there is no source address 603 available for destination D. For IPv6 addresses, this is only the 604 case if CandidateSource(D) is the empty set. 606 The pair-wise comparison of destination addresses consists of ten 607 rules, which should be applied in order. If a rule determines a 608 result, then the remaining rules are not relevant and should be 609 ignored. Subsequent rules act as tie-breakers for earlier rules. 610 See the previous section for a lengthier description of how pair-wise 611 comparison tie-breaker rules can be used to sort a list. 613 Rule 1: Avoid unusable destinations. 614 If DB is known to be unreachable or if Source(DB) is undefined, then 615 prefer DA. Similarly, if DA is known to be unreachable or if 616 Source(DA) is undefined, then prefer DB. 618 Discussion: An implementation may know that a particular 619 destination is unreachable in several ways. For example, the 620 destination may be reached through a network interface that is 621 currently unplugged. For example, the implementation may retain 622 for some period of time information from Neighbor Unreachability 623 Detection [RFC4861]. In any case, the determination of 624 unreachability for the purposes of this rule is implementation- 625 dependent. 627 Rule 2: Prefer matching scope. 628 If Scope(DA) = Scope(Source(DA)) and Scope(DB) <> Scope(Source(DB)), 629 then prefer DA. Similarly, if Scope(DA) <> Scope(Source(DA)) and 630 Scope(DB) = Scope(Source(DB)), then prefer DB. 632 Rule 3: Avoid deprecated addresses. 633 If Source(DA) is deprecated and Source(DB) is not, then prefer DB. 634 Similarly, if Source(DA) is not deprecated and Source(DB) is 635 deprecated, then prefer DA. 637 Rule 4: Prefer home addresses. 638 If Source(DA) is simultaneously a home address and care-of address 639 and Source(DB) is not, then prefer DA. Similarly, if Source(DB) is 640 simultaneously a home address and care-of address and Source(DA) is 641 not, then prefer DB. 643 If Source(DA) is just a home address and Source(DB) is just a care-of 644 address, then prefer DA. Similarly, if Source(DA) is just a care-of 645 address and Source(DB) is just a home address, then prefer DB. 647 Rule 5: Prefer matching label. 648 If Label(Source(DA)) = Label(DA) and Label(Source(DB)) <> Label(DB), 649 then prefer DA. Similarly, if Label(Source(DA)) <> Label(DA) and 650 Label(Source(DB)) = Label(DB), then prefer DB. 652 Rule 6: Prefer higher precedence. 653 If Precedence(DA) > Precedence(DB), then prefer DA. Similarly, if 654 Precedence(DA) < Precedence(DB), then prefer DB. 656 Rule 7: Prefer native transport. 657 If DA is reached via an encapsulating transition mechanism (e.g., 658 IPv6 in IPv4) and DB is not, then prefer DB. Similarly, if DB is 659 reached via encapsulation and DA is not, then prefer DA. 661 Discussion: 6RD [RFC5969], ISATAP [RFC5214], and configured 662 tunnels [RFC4213] are examples of encapsulating transition 663 mechanisms for which the destination address does not have a 664 specific prefix and hence can not be assigned a lower precedence 665 in the policy table. An implementation MAY generalize this rule 666 by using a concept of interface preference, and giving virtual 667 interfaces (like the IPv6-in-IPv4 encapsulating interfaces) a 668 lower preference than native interfaces (like ethernet 669 interfaces). 671 Rule 8: Prefer smaller scope. 672 If Scope(DA) < Scope(DB), then prefer DA. Similarly, if Scope(DA) > 673 Scope(DB), then prefer DB. 675 Rule 9: Use longest matching prefix. 676 When DA and DB belong to the same address family (both are IPv6 or 677 both are IPv4): If CommonPrefixLen(Source(DA), DA) > 678 CommonPrefixLen(Source(DB), DB), then prefer DA. Similarly, if 679 CommonPrefixLen(Source(DA), DA) < CommonPrefixLen(Source(DB), DB), 680 then prefer DB. 682 Rule 10: Otherwise, leave the order unchanged. 683 If DA preceded DB in the original list, prefer DA. Otherwise prefer 684 DB. 686 Rules 9 and 10 may be superseded if the implementation has other 687 means of sorting destination addresses. For example, if the 688 implementation somehow knows which destination addresses will result 689 in the "best" communications performance. 691 7. Interactions with Routing 693 This specification of source address selection assumes that routing 694 (more precisely, selecting an outgoing interface on a node with 695 multiple interfaces) is done before source address selection. 696 However, implementations may use source address considerations as a 697 tiebreaker when choosing among otherwise equivalent routes. 699 For example, suppose a node has interfaces on two different links, 700 with both links having a working default router. Both of the 701 interfaces have preferred (in the RFC 4862 sense) global addresses. 702 When sending to a global destination address, if there's no routing 703 reason to prefer one interface over the other, then an implementation 704 may preferentially choose the outgoing interface that will allow it 705 to use the source address that shares a longer common prefix with the 706 destination. 708 Implementations that support Rule 5.5 also use the choice of router 709 to influence the choice of source address. For example, suppose a 710 host is on a link with two routers. One router is advertising a 711 global prefix A and the other router is advertising global prefix B. 712 Then when sending via the first router, the host may prefer source 713 addresses with prefix A and when sending via the second router, 714 prefer source addresses with prefix B. 716 8. Implementation Considerations 718 The destination address selection algorithm needs information about 719 potential source addresses. One possible implementation strategy is 720 for getaddrinfo() to call down to the network layer with a list of 721 destination addresses, sort the list in the network layer with full 722 current knowledge of available source addresses, and return the 723 sorted list to getaddrinfo(). This is simple and gives the best 724 results but it introduces the overhead of another system call. One 725 way to reduce this overhead is to cache the sorted address list in 726 the resolver, so that subsequent calls for the same name do not need 727 to resort the list. 729 Another implementation strategy is to call down to the network layer 730 to retrieve source address information and then sort the list of 731 addresses directly in the context of getaddrinfo(). To reduce 732 overhead in this approach, the source address information can be 733 cached, amortizing the overhead of retrieving it across multiple 734 calls to getaddrinfo(). In this approach, the implementation may not 735 have knowledge of the outgoing interface for each destination, so it 736 MAY use a looser definition of the candidate set during destination 737 address ordering. 739 In any case, if the implementation uses cached and possibly stale 740 information in its implementation of destination address selection, 741 or if the ordering of a cached list of destination addresses is 742 possibly stale, then it should ensure that the destination address 743 ordering returned to the application is no more than one second out 744 of date. For example, an implementation might make a system call to 745 check if any routing table entries or source address assignments or 746 prefix policy table entries that might affect these algorithms have 747 changed. Another strategy is to use an invalidation counter that is 748 incremented whenever any underlying state is changed. By caching the 749 current invalidation counter value with derived state and then later 750 comparing against the current value, the implementation could detect 751 if the derived state is potentially stale. 753 9. Security Considerations 755 This document has no direct impact on Internet infrastructure 756 security. 758 Note that most source address selection algorithms, including the one 759 specified in this document, expose a potential privacy concern. An 760 unfriendly node can infer correlations among a target node's 761 addresses by probing the target node with request packets that force 762 the target host to choose its source address for the reply packets. 763 (Perhaps because the request packets are sent to an anycast or 764 multicast address, or perhaps the upper-layer protocol chosen for the 765 attack does not specify a particular source address for its reply 766 packets.) By using different addresses for itself, the unfriendly 767 node can cause the target node to expose the target's own addresses. 768 The source address selection default preference for temporary 769 addresses helps mitigate this concern. 771 In addition, some address selection rules may be administratively 772 configurable. Care must be taken to make sure that all 773 administrative options are secured against illicit modification, or 774 else an attacker could redirect and/or block traffic. 776 10. Examples 778 This section contains a number of examples, first of default behavior 779 and then demonstrating the utility of policy table configuration. 780 These examples are provided for illustrative purposes; they should 781 not be construed as normative. 783 10.1. Default Source Address Selection 785 The source address selection rules, in conjunction with the default 786 policy table, produce the following behavior: 788 Destination: 2001:db8:1::1 789 Candidate Source Addresses: 2001:db8:3::1 or fe80::1 790 Result: 2001:db8::1 (prefer appropriate scope) 792 Destination: ff05::1 793 Candidate Source Addresses: 2001:db8:3::1 or fe80::1 794 Result: 2001:db8:3::1 (prefer appropriate scope) 796 Destination: 2001:db8:1::1 797 Candidate Source Addresses: 2001:db8:1::1 (deprecated) or 798 2001:db8:2::1 799 Result: 2001:db8:1::1 (prefer same address) 801 Destination: fe80::1 802 Candidate Source Addresses: fe80::2 (deprecated) or 2001:db8:1::1 803 Result: fe80::2 (prefer appropriate scope) 805 Destination: 2001:db8:1::1 806 Candidate Source Addresses: 2001:db8:1::2 or 2001:db8:3::2 807 Result: 2001:db8:1:::2 (longest-matching-prefix) 809 Destination: 2001:db8:1::1 810 Candidate Source Addresses: 2001:db8:1::2 (care-of address) or 2001: 811 db8:3::2 (home address) 812 Result: 2001:db8:3::2 (prefer home address) 813 Destination: 2002:c633:6401::1 814 Candidate Source Addresses: 2002:c633:6401::d5e3:7953:13eb:22e8 815 (temporary) or 2001:db8:1::2 816 Result: 2002:c633:6401::d5e3:7953:13eb:22e8 (prefer matching label) 818 Destination: 2001:db8:1::d5e3:0:0:1 819 Candidate Source Addresses: 2001:db8:1::2 or 2001:db8:1::d5e3:7953: 820 13eb:22e8 (temporary) 821 Result: 2001:db8:1::2 (prefer public address) 823 10.2. Default Destination Address Selection 825 The destination address selection rules, in conjunction with the 826 default policy table and the source address selection rules, produce 827 the following behavior: 829 Candidate Source Addresses: 2001:db8:1::2 or fe80::1 or 169.254.13.78 830 Destination Address List: 2001:db8:1::1 or 198.51.100.121 831 Result: 2001:db8:1::1 (src 2001:db8:1::2) then 198.51.100.121 (src 832 169.254.13.78) (prefer matching scope) 834 Candidate Source Addresses: fe80::1 or 198.51.100.117 835 Destination Address List: 2001:db8:1::1 or 198.51.100.121 836 Result: 198.51.100.121 (src 198.51.100.117) then 2001:db8:1::1 (src 837 fe80::1) (prefer matching scope) 839 Candidate Source Addresses: 2001:db8:1::2 or fe80::1 or 10.1.2.4 840 Destination Address List: 2001:db8:1::1 or 10.1.2.3 841 Result: 2001:db8:1::1 (src 2001:db8:1::2) then 10.1.2.3 (src 842 10.1.2.4) (prefer higher precedence) 844 Candidate Source Addresses: 2001:db8:1::2 or fe80::2 845 Destination Address List: 2001:db8:1::1 or fe80::1 846 Result: fe80::1 (src fe80::2) then 2001:db8:1::1 (src 2001:db8:1::2) 847 (prefer smaller scope) 849 Candidate Source Addresses: 2001:db8:1::2 (care-of address) or 2001: 850 db8:3::1 (home address) or fe80::2 (care-of address) 851 Destination Address List: 2001:db8:1::1 or fe80::1 852 Result: 2001:db8:1::1 (src 2001:db8:3::1) then fe80::1 (src fe80::2) 853 (prefer home address) 855 Candidate Source Addresses: 2001:db8:1::2 or fe80::2 (deprecated) 856 Destination Address List: 2001:db8:1::1 or fe80::1 857 Result: 2001:db8:1::1 (src 2001:db8:1::2) then fe80::1 (src fe80::2) 858 (avoid deprecated addresses) 860 Candidate Source Addresses: 2001:db8:1::2 or 2001:db8:3f44::2 or 861 fe80::2 862 Destination Address List: 2001:db8:1::1 or 2001:db8:3ffe::1 863 Result: 2001:db8:1::1 (src 2001:db8:1::2) then 2001:db8:3ffe::1 (src 864 2001:db8:3f44::2) (longest matching prefix) 866 Candidate Source Addresses: 2002:c633:6401::2 or fe80::2 867 Destination Address List: 2002:c633:6401::1 or 2001:db8:1::1 868 Result: 2002:c633:6401::1 (src 2002:c633:6401::2) then 2001:db8:1::1 869 (src 2002:c633:6401::2) (prefer matching label) 871 Candidate Source Addresses: 2002:c633:6401::2 or 2001:db8:1::2 or 872 fe80::2 873 Destination Address List: 2002:c633:6401::1 or 2001:db8:1::1 874 Result: 2001:db8:1::1 (src 2001:db8:1::2) then 2002:c633:6401::1 (src 875 2002:c633:6401::2) (prefer higher precedence) 877 10.3. Configuring Preference for IPv6 or IPv4 879 The default policy table gives IPv6 addresses higher precedence than 880 IPv4 addresses. This means that applications will use IPv6 in 881 preference to IPv4 when the two are equally suitable. An 882 administrator can change the policy table to prefer IPv4 addresses by 883 giving the ::ffff:0.0.0.0/96 prefix a higher precedence: 885 Prefix Precedence Label 886 ::1/128 50 0 887 ::/0 40 1 888 ::ffff:0:0/96 100 4 889 2002::/16 30 2 890 2001::/32 5 5 891 fc00::/7 3 13 892 ::/96 1 3 893 fec0::/10 1 11 894 3ffe::/16 1 12 896 This change to the default policy table produces the following 897 behavior: 899 Candidate Source Addresses: 2001::2 or fe80::1 or 169.254.13.78 900 Destination Address List: 2001::1 or 198.51.100.121 901 Unchanged Result: 2001::1 (src 2001::2) then 198.51.100.121 (src 902 169.254.13.78) (prefer matching scope) 904 Candidate Source Addresses: fe80::1 or 198.51.100.117 905 Destination Address List: 2001::1 or 198.51.100.121 906 Unchanged Result: 198.51.100.121 (src 198.51.100.117) then 2001::1 907 (src fe80::1) (prefer matching scope) 908 Candidate Source Addresses: 2001::2 or fe80::1 or 10.1.2.4 909 Destination Address List: 2001::1 or 10.1.2.3 910 New Result: 10.1.2.3 (src 10.1.2.4) then 2001::1 (src 2001::2) 911 (prefer higher precedence) 913 10.3.1. Handling Broken IPv6 915 One problem in practice that has been recently observed occurs when a 916 host has IPv4 connectivity to the Internet, but has "broken" IPv6 917 connectivity to the Internet in that it has a global IPv6 address, 918 but is discconnected from the IPv6 Internet. Since the default 919 policy table prefers IPv6, this can result in unwanted timeouts. 921 This can be solved by configuring the table to prefer IPv4 as shown 922 above. An implementation that has some means to detect that it is 923 not connected to the IPv6 Internet MAY do this automatically. An 924 implementation could instead treat it as part of its implementation 925 of Rule 1 (avoid unusable destinations). 927 10.4. Configuring Preference for Link-Local Addresses 929 The destination address selection rules give preference to 930 destinations of smaller scope. For example, a link-local destination 931 will be sorted before a global scope destination when the two are 932 otherwise equally suitable. An administrator can change the policy 933 table to reverse this preference and sort global destinations before 934 link-local destinations: 936 Prefix Precedence Label 937 ::1/128 50 0 938 ::/0 40 1 939 ::ffff:0:0/96 35 4 940 fe80::/10 33 1 941 2002::/16 30 2 942 2001::/32 5 5 943 fc00::/7 3 13 944 ::/96 1 3 945 fec0::/10 1 11 946 3ffe::/16 1 12 948 This change to the default policy table produces the following 949 behavior: 951 Candidate Source Addresses: 2001::2 or fe80::2 952 Destination Address List: 2001::1 or fe80::1 953 New Result: 2001::1 (src 2001::2) then fe80::1 (src fe80::2) (prefer 954 higher precedence) 955 Candidate Source Addresses: 2001::2 (deprecated) or fe80::2 956 Destination Address List: 2001::1 or fe80::1 957 Unchanged Result: fe80::1 (src fe80::2) then 2001::1 (src 2001::2) 958 (avoid deprecated addresses) 960 10.5. Configuring a Multi-Homed Site 962 Consider a site A that has a business-critical relationship with 963 another site B. To support their business needs, the two sites have 964 contracted for service with a special high-performance ISP. This is 965 in addition to the normal Internet connection that both sites have 966 with different ISPs. The high-performance ISP is expensive and the 967 two sites wish to use it only for their business-critical traffic 968 with each other. 970 Each site has two global prefixes, one from the high-performance ISP 971 and one from their normal ISP. Site A has prefix 2001:aaaa:aaaa::/48 972 from the high-performance ISP and prefix 2007:0:aaaa::/48 from its 973 normal ISP. Site B has prefix 2001:bbbb:bbbb::/48 from the high- 974 performance ISP and prefix 2007:0:bbbb::/48 from its normal ISP. All 975 hosts in both sites register two addresses in the DNS. 977 The routing within both sites directs most traffic to the egress to 978 the normal ISP, but the routing directs traffic sent to the other 979 site's 2001 prefix to the egress to the high-performance ISP. To 980 prevent unintended use of their high-performance ISP connection, the 981 two sites implement ingress filtering to discard traffic entering 982 from the high-performance ISP that is not from the other site. 984 The default policy table and address selection rules produce the 985 following behavior: 987 Candidate Source Addresses: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or 988 fe80::a 989 Destination Address List: 2001:bbbb:bbbb::b or 2007:0:bbbb::b 990 Result: 2007:0:bbbb::b (src 2007:0:aaaa::a) then 2001:bbbb:bbbb::b 991 (src 2001:aaaa:aaaa::a) (longest matching prefix) 993 In other words, when a host in site A initiates a connection to a 994 host in site B, the traffic does not take advantage of their 995 connections to the high-performance ISP. This is not their desired 996 behavior. 998 Candidate Source Addresses: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or 999 fe80::a 1000 Destination Address List: 2001:cccc:cccc::c or 2006:cccc:cccc::c 1001 Result: 2001:cccc:cccc::c (src 2001:aaaa:aaaa::a) then 2006:cccc: 1002 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 [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 1239 M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address 1240 Space", BCP 153, RFC 6598, April 2012. 1242 Appendix A. Acknowledgements 1244 RFC 3484 acknowledged the contributions of the IPng Working Group, 1245 particularly Marc Blanchet, Brian Carpenter, Matt Crawford, Alain 1246 Durand, Steve Deering, Robert Elz, Jun-ichiro itojun Hagino, Tony 1247 Hain, M.T. Hollinger, JINMEI Tatuya, Thomas Narten, Erik Nordmark, 1248 Ken Powell, Markku Savela, Pekka Savola, Hesham Soliman, Dave Thaler, 1249 Mauro Tortonesi, Ole Troan, and Stig Venaas. In addition, the 1250 anonymous IESG reviewers had many great comments and suggestions for 1251 clarification. 1253 This revision was heavily influenced by the work by Arifumi 1254 Matsumoto, Jun-ya Kato, and Tomohiro Fujisaki in a working draft that 1255 made proposals for this revision to adopt, with input from Pekka 1256 Savola, Remi Denis-Courmont, Francois-Xavier Le Bail, and the 6man 1257 Working Group. Dmitry Anipko, Mark Andrews, Ray Hunter, and Wes 1258 George also provided valuable feedback on this revision. 1260 Appendix B. Changes Since RFC 3484 1262 Some changes were made to the default policy table that were deemed 1263 to be universally useful and cause no harm in every reasonable 1264 network environment. In doing so, care was taken to use the same 1265 preference and label values as in RFC 3484 whenever possible, and for 1266 new rows to use label values less likely to collide with values that 1267 might already be in use in additional rows on some hosts. These 1268 changes are: 1270 1. Added the Teredo [RFC4380] prefix (2001::/32), with the 1271 preference and label values already widely used in popular 1272 implementations. 1273 2. Added a row for ULAs (fc00::/7) below native IPv6 since they are 1274 not globally reachable, as discussed in Section 10.6. 1275 3. Added a row for site-local addresses (fec0::/10) in order to 1276 depreference them, for consistency with the example in 1277 Section 10.3, since they are deprecated [RFC3879]. 1278 4. Depreferenced 6to4 (2002::/32) below native IPv4 since 6to4 1279 connectivity is less reliable today (and is expected to be phased 1280 out over time, rather than becoming more reliable). It remains 1281 above Teredo since 6to4 is more efficient in terms of connection 1282 establishment time, bandwidth, and server load. 1283 5. Depreferenced IPv4-Compatible addresses (::/96) since they are 1284 now deprecated [RFC4291] and not in common use. 1286 6. Added a row for 6bone testing addresses (3ffe::/16) in order to 1287 depreference them as they have also been phased out [RFC3701]. 1288 7. Added optional ability for an implementation to add automatic 1289 rows to the table for site-specific ULA prefixes and site- 1290 specific native 6to4 prefixes. 1292 Similarly, some changes were made to the rules, as follows: 1294 1. Changed the definition of CommonPrefixLen() to only compare bits 1295 up to the source address's prefix length. The previous 1296 definition used the entire source address, rather than only its 1297 prefix. As a result, when a source and destination addresses had 1298 the same prefix, common bits in the interface ID would previously 1299 result in overriding DNS load balancing [RFC1794] by forcing the 1300 destination address with the most bits in common to be always 1301 chosen. The updated definition allows DNS load balancing to 1302 continue to be used as a tie breaker. 1303 2. Added Rule 5.5 to allow choosing a source address from a prefix 1304 advertised by the chosen next-hop for a given destination. This 1305 allows better connectivity in the presence of BCP 38 [RFC2827] 1306 ingress filtering and egress filtering. Previously, RFC 3484 had 1307 issues with multiple egress networks reached via the same 1308 interface, as discussed in [RFC5220]. 1309 3. Removed restriction against anycast addresses in the candidate 1310 set of source addresses, since the restriction against using IPv6 1311 anycast addresses as source addresses was removed in Section 2.6 1312 of RFC 4291 [RFC4291]. 1313 4. Changed mapping of RFC 1918 [RFC1918] addresses to global scope 1314 in Section 3.2. Previously they were mapped to site-local scope. 1315 However, experience has resulted in current implementations 1316 already using global scope instead. When they were mapped to 1317 site-local, Destination Address Selection Rule 2 (Prefer matching 1318 scope) would cause IPv6 to be preferred in scenarios such as that 1319 described in Section 10.7. The change to global scope allows 1320 configurability via the prefix policy table. 1321 5. Changed the default recommendation for Source Address Selection 1322 Rule 7 to prefer temporary addresses rather than public 1323 addresses, while providing an administrative override (in 1324 addition to the application-specific override that was already 1325 specified). This change was made because of the increasing 1326 importance of privacy considerations, as well as the fact that 1327 widely deployed implementations have preferred temporary 1328 addresses for many years without major application issues. 1330 Finally, some editorial changes were made, including: 1332 1. Changed global IP addresses in examples to use ranges reserved 1333 for documentation. 1334 2. Added additional examples in Section 10.6 and Section 10.7. 1335 3. Added Section 10.3.1 on "broken" IPv6. 1336 4. Updated references. 1338 Authors' Addresses 1340 Dave Thaler (editor) 1341 Microsoft 1342 One Microsoft Way 1343 Redmond, WA 98052 1345 Phone: +1 425 703 8835 1346 Email: dthaler@microsoft.com 1348 Richard Draves 1349 Microsoft Research 1350 One Microsoft Way 1351 Redmond, WA 98052 1353 Phone: +1 425 706 2268 1354 Email: richdr@microsoft.com 1356 Arifumi Matsumoto 1357 NTT SI Lab 1358 Midori-Cho 3-9-11 1359 Musashino-shi, Tokyo 180-8585 1360 Japan 1362 Phone: +81 422 59 3334 1363 Email: arifumi@nttv6.net 1365 Tim Chown 1366 University of Southampt on 1367 Southampton, Hampshire SO17 1BJ 1368 United Kingdom 1370 Email: tjc@ecs.soton.ac.uk