idnits 2.17.1 draft-ietf-ipv6-default-addr-select-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 14 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 6 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 9 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 17, 2002) is 7984 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) -- Missing reference section? '1' on line 13 looks like a reference -- Missing reference section? '2' on line 330 looks like a reference -- Missing reference section? '3' on line 278 looks like a reference -- Missing reference section? '4' on line 196 looks like a reference -- Missing reference section? '5' on line 197 looks like a reference -- Missing reference section? '6' on line 317 looks like a reference -- Missing reference section? '7' on line 152 looks like a reference -- Missing reference section? '8' on line 162 looks like a reference -- Missing reference section? '9' on line 331 looks like a reference -- Missing reference section? '10' on line 306 looks like a reference -- Missing reference section? '11' on line 318 looks like a reference -- Missing reference section? '13' on line 331 looks like a reference -- Missing reference section? '14' on line 551 looks like a reference -- Missing reference section? '15' on line 587 looks like a reference -- Missing reference section? '16' on line 587 looks like a reference -- Missing reference section? '17' on line 588 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPng Working Group Richard Draves 3 Internet Draft Microsoft Research 4 Document: draft-ietf-ipv6-default-addr-select-08.txt June 17, 2002 5 Category: Standards Track 7 Default Address Selection for IPv6 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026 [1]. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document describes two algorithms, for source address selection 33 and for destination address selection. The algorithms specify 34 default behavior for all IPv6 implementations. They do not override 35 choices made by applications or upper-layer protocols, nor do they 36 preclude the development of more advanced mechanisms for address 37 selection. The two algorithms share a common context, including an 38 optional mechanism for allowing administrators to provide policy 39 that can override the default behavior. In dual stack 40 implementations, the destination address selection algorithm can 41 consider both IPv4 and IPv6 addresses - depending on the available 42 source addresses, the algorithm might prefer IPv6 addresses over 43 IPv4 addresses, or vice-versa. 45 All IPv6 nodes, including both hosts and routers, must implement 46 default address selection as defined in this specification. 48 Table of Contents 50 1. Introduction................................................2 51 1.1. Conventions Used in This Document...........................3 52 2. Context in Which the Algorithms Operate.....................4 53 2.1. Policy Table................................................5 54 2.2. Common Prefix Length........................................6 55 3. Address Properties..........................................6 56 3.1. Scope Comparisons...........................................6 57 3.2. IPv4 Addresses and IPv4-Mapped Addresses....................7 58 3.3. Other IPv6 Addresses with Embedded IPv4 Addresses...........7 59 3.4. IPv6 Loopback Address and Other Format Prefixes.............7 60 4. Candidate Source Addresses..................................7 61 5. Source Address Selection....................................8 62 6. Destination Address Selection..............................11 63 7. Interactions with Routing..................................13 64 8. Implementation Considerations..............................13 65 9. Security Considerations....................................14 66 10. Examples...................................................14 67 10.1. Default Source Address Selection...........................14 68 10.2. Default Destination Address Selection......................15 69 10.3. Configuring Preference for IPv6 or IPv4....................16 70 10.4. Configuring Preference for Scoped Addresses................17 71 10.5. Configuring a Multi-Homed Site.............................17 72 Acknowledgments...................................................20 73 Author's Address..................................................20 74 Revision History..................................................20 76 1. Introduction 78 The IPv6 addressing architecture [2] allows multiple unicast 79 addresses to be assigned to interfaces. These addresses may have 80 different reachability scopes (link-local, site-local, or global). 81 These addresses may also be "preferred" or "deprecated" [3]. Privacy 82 considerations have introduced the concepts of "public addresses" 83 and "temporary addresses" [4]. The mobility architecture introduces 84 "home addresses" and "care-of addresses" [5]. In addition, multi- 85 homing situations will result in more addresses per node. For 86 example, a node may have multiple interfaces, some of them tunnels 87 or virtual interfaces, or a site may have multiple ISP attachments 88 with a global prefix per ISP. 90 The end result is that IPv6 implementations will very often be faced 91 with multiple possible source and destination addresses when 92 initiating communication. It is desirable to have default 93 algorithms, common across all implementations, for selecting source 94 and destination addresses so that developers and administrators can 95 reason about and predict the behavior of their systems. 97 Furthermore, dual or hybrid stack implementations, which support 98 both IPv6 and IPv4, will very often need to choose between IPv6 and 99 IPv4 when initiating communication. For example, when DNS name 100 resolution yields both IPv6 and IPv4 addresses and the network 101 protocol stack has available both IPv6 and IPv4 source addresses. In 102 such cases, a simple policy to always prefer IPv6 or always prefer 103 IPv4 can produce poor behavior. As one example, suppose a DNS name 104 resolves to a global IPv6 address and a global IPv4 address. If the 105 node has assigned a global IPv6 address and a 169.254/16 auto- 106 configured IPv4 address [6], then IPv6 is the best choice for 107 communication. But if the node has assigned only a link-local IPv6 108 address and a global IPv4 address, then IPv4 is the best choice for 109 communication. The destination address selection algorithm solves 110 this with a unified procedure for choosing among both IPv6 and IPv4 111 addresses. 113 The algorithms in this document are specified as a set of rules that 114 define a partial ordering on the set of addresses that are available 115 for use. In the case of source address selection, a node typically 116 has multiple addresses assigned to its interfaces, and the source 117 address ordering rules in section 5 define which address is the 118 "best" one to use. In the case of destination address selection, the 119 DNS may return a set of addresses for a given name, and an 120 application needs to decide which one to use first, and in what 121 order to try others should the first one not be reachable. The 122 destination address ordering rules in section 6, when applied to the 123 set of addresses returned by the DNS, provide such a recommended 124 ordering. 126 This document specifies source address selection and destination 127 address selection separately, but using a common context so that 128 together the two algorithms yield useful results. The algorithms 129 attempt to choose source and destination addresses of appropriate 130 scope and configuration status (preferred or deprecated in the RFC 131 2462 sense). Furthermore, this document suggests a preferred method, 132 longest matching prefix, for choosing among otherwise equivalent 133 addresses in the absence of better information. 135 This document also specifies policy hooks to allow administrative 136 override of the default behavior. For example, using these hooks an 137 administrator can specify a preferred source prefix for use with a 138 destination prefix, or prefer destination addresses with one prefix 139 over addresses with another prefix. These hooks give an 140 administrator flexibility in dealing with some multi-homing and 141 transition scenarios, but they are certainly not a panacea. 143 The selection rules specified in this document MUST NOT be construed 144 to override an application or upper-layer's explicit choice of a 145 legal destination or source address. 147 1.1. Conventions Used in This Document 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 151 this document are to be interpreted as described in RFC 2119 [7]. 153 2. Context in Which the Algorithms Operate 155 Our context for address selection derives from the most common 156 implementation architecture, which separates the choice of 157 destination address from the choice of source address. Consequently, 158 we have two separate algorithms for these tasks. The algorithms are 159 designed to work well together and they share a mechanism for 160 administrative policy override. 162 In this implementation architecture, applications use APIs [8] like 163 getaddrinfo() that return a list of addresses to the application. 164 This list might contain both IPv6 and IPv4 addresses (sometimes 165 represented as IPv4-mapped addresses). The application then passes a 166 destination address to the network stack with connect() or sendto(). 167 The application would then typically try the first address in the 168 list, looping over the list of addresses until it finds a working 169 address. In any case, the network layer is never in a situation 170 where it needs to choose a destination address from several 171 alternatives. The application might also specify a source address 172 with bind(), but often the source address is left unspecified. 173 Therefore the network layer does often choose a source address from 174 several alternatives. 176 As a consequence, we intend that implementations of getaddrinfo() 177 will use the destination address selection algorithm specified here 178 to sort the list of IPv6 and IPv4 addresses that they return. 179 Separately, the IPv6 network layer will use the source address 180 selection algorithm when an application or upper-layer has not 181 specified a source address. Application of this specification to 182 source address selection in an IPv4 network layer may be possible 183 but this is not explored further here. 185 Well-behaved applications SHOULD iterate through the list of 186 addresses returned from getaddrinfo() until they find a working 187 address. 189 The algorithms use several criteria in making their decisions. The 190 combined effect is to prefer destination/source address pairs for 191 which the two addresses are of equal scope or type, prefer smaller 192 scopes over larger scopes for the destination address, prefer non- 193 deprecated source addresses, avoid the use of transitional addresses 194 when native addresses are available, and all else being equal prefer 195 address pairs having the longest possible common prefix. For source 196 address selection, public addresses [4] are preferred over temporary 197 addresses. In mobile situations [5], home addresses are preferred 198 over care-of addresses. If an address is simultaneously a home 199 address and a care-of address (indicating the mobile node is "at 200 home" for that address), then the home/care-of address is preferred 201 over addresses that are solely a home address or solely a care-of 202 address. 204 This specification optionally allows for the possibility of 205 administrative configuration of policy that can override the default 206 behavior of the algorithms. The policy override takes the form of a 207 configurable table that specifies precedence values and preferred 208 source prefixes for destination prefixes. If an implementation is 209 not configurable, or if an implementation has not been configured, 210 then the default policy table specified in this document SHOULD be 211 used. 213 2.1. Policy Table 215 The policy table is a longest-matching-prefix lookup table, much 216 like a routing table. Given an address A, a lookup in the policy 217 table produces two values: a precedence value Precedence(A) and a 218 classification or label Label(A). 220 The precedence value Precedence(A) is used for sorting destination 221 addresses. If Precedence(A) > Precedence(B), we say that address A 222 has higher precedence than address B, meaning that our algorithm 223 will prefer to sort destination address A before destination address 224 B. 226 The label value Label(A) allows for policies that prefer a 227 particular source address prefix for use with a destination address 228 prefix. The algorithms prefer to use a source address S with a 229 destination address D if Label(S) = Label(D). 231 IPv6 implementations SHOULD support configurable address selection 232 via a mechanism at least as powerful as the policy tables defined 233 here. Note that at the time of this writing there is only limited 234 experience with the use of policies that select from a set of 235 possible IPv6 addresses. As more experience is gained, the 236 recommended default policies may change. Consequently it is 237 important that implementations provide a way to change the default 238 policies as more experience is gained. Sections 10.3 and 10.4 239 provide examples of the kind of changes that might be needed. 241 If an implementation is not configurable or has not been configured, 242 then it SHOULD operate according to the algorithms specified here in 243 conjunction with the following default policy table: 245 Prefix Precedence Label 246 ::1/128 50 0 247 ::/0 40 1 248 2002::/16 30 2 249 ::/96 20 3 250 ::ffff:0:0/96 10 4 252 One effect of the default policy table is to prefer using native 253 source addresses with native destination addresses, 6to4 [9] source 254 addresses with 6to4 destination addresses, and v4-compatible [2] 255 source addresses with v4-compatible destination addresses. Another 256 effect of the default policy table is to prefer communication using 257 IPv6 addresses to communication using IPv4 addresses, if matching 258 source addresses are available. 260 Policy table entries for scoped address prefixes MAY be qualified 261 with an optional zone index. If so, a prefix table entry only 262 matches against an address during a lookup if the zone index also 263 matches the address's zone index. 265 2.2. Common Prefix Length 267 We define the common prefix length CommonPrefixLen(A, B) of two 268 addresses A and B as the length of the longest prefix (looking at 269 the most significant, or leftmost, bits) that the two addresses have 270 in common. It ranges from 0 to 128. 272 3. Address Properties 274 In the rules given in later sections, addresses of different types 275 (e.g., IPv4, IPv6, multicast and unicast) are compared against each 276 other. Some of these address types have properties that aren't 277 directly comparable to each other. For example, IPv6 unicast 278 addresses can be "preferred" or "deprecated" [3], while IPv4 279 addresses have no such notion. To compare such addresses using the 280 ordering rules (e.g., to use "preferred" addresses in preference to 281 "deprecated" addresses), the following mappings are defined. 283 3.1. Scope Comparisons 285 Multicast destination addresses have a 4-bit scope field that 286 controls the propagation of the multicast packet. The IPv6 287 addressing architecture defines scope field values for interface- 288 local (0x1), link-local (0x2), subnet-local (0x3), admin-local 289 (0x4), site-local (0x5), organization-local (0x8), and global (0xE) 290 scopes [10]. 292 Use of the source address selection algorithm in the presence of 293 multicast destination addresses requires the comparison of a unicast 294 address scope with a multicast address scope. We map unicast link- 295 local to multicast link-local, unicast site-local to multicast site- 296 local, and unicast global scope to multicast global scope. For 297 example, unicast site-local is equal to multicast site-local, which 298 is smaller than multicast organization-local, which is smaller than 299 unicast global, which is equal to multicast global. 301 We write Scope(A) to mean the scope of address A. For example, if A 302 is a link-local unicast address and B is a site-local multicast 303 address, then Scope(A) < Scope(B). 305 This mapping implicitly conflates unicast site boundaries and 306 multicast site boundaries [10]. 308 3.2. IPv4 Addresses and IPv4-Mapped Addresses 310 The destination address selection algorithm operates on both IPv6 311 and IPv4 addresses. For this purpose, IPv4 addresses should be 312 represented as IPv4-mapped addresses [2]. For example, to lookup the 313 precedence or other attributes of an IPv4 address in the policy 314 table, lookup the corresponding IPv4-mapped IPv6 address. 316 IPv4 addresses are assigned scopes as follows. IPv4 auto- 317 configuration addresses [6], which have the prefix 169.254/16, are 318 assigned link-local scope. IPv4 private addresses [11], which have 319 the prefixes 10/8, 172.16/12, and 192.168/16, are assigned site- 320 local scope. IPv4 loopback addresses [12, section 4.2.2.11], which 321 have the prefix 127/8, are assigned link-local scope (analogously to 322 the treatment of the IPv6 loopback address [10, section 4]). Other 323 IPv4 addresses are assigned global scope. 325 IPv4 addresses should be treated as having "preferred" (in the RFC 326 2462 sense) configuration status. 328 3.3. Other IPv6 Addresses with Embedded IPv4 Addresses 330 IPv4-compatible addresses [2], IPv4-mapped [2], IPv4-translatable 331 [13] and 6to4 addresses [9] contain an embedded IPv4 address. For 332 the purposes of this document, these addresses should be treated as 333 having global scope. 335 IPv4-compatible, IPv4-mapped, and IPv4-translatable addresses should 336 be treated as having "preferred" (in the RFC 2462 sense) 337 configuration status. 339 3.4. IPv6 Loopback Address and Other Format Prefixes 341 The loopback address should be treated as having link-local 342 scope [10, section 4] and "preferred" (in the RFC 2462 sense) 343 configuration status. 345 NSAP addresses and other addresses with as-yet-undefined format 346 prefixes should be treated as having global scope and "preferred" 347 (in the RFC 2462) configuration status. Later standards may 348 supersede this treatment. 350 4. Candidate Source Addresses 352 The source address selection algorithm uses the concept of a 353 "candidate set" of potential source addresses for a given 354 destination address. The candidate set is the set of all addresses 355 that could be used as a source address; the source address selection 356 algorithm will pick an address out of that set. We write 357 CandidateSource(A) to denote the candidate set for the address A. 359 It is RECOMMENDED that the candidate source addresses be the set of 360 unicast addresses assigned to the interface that will be used to 361 send to the destination. (The "outgoing" interface.) On routers, the 362 candidate set MAY include unicast addresses assigned to any 363 interface that forwards packets, subject to the restrictions 364 described below. 366 Discussion: The Neighbor Discovery Redirect mechanism [14] 367 requires that routers verify that the source address of a packet 368 identifies a neighbor before generating a Redirect, so it is 369 advantageous for hosts to choose source addresses assigned to the 370 outgoing interface. Implementations that wish to support the use 371 of global source addresses assigned to a loopback interface should 372 behave as if the loopback interface originates and forwards the 373 packet. 375 In some cases the destination address may be qualified with a zone 376 index or other information that will constrain the candidate set. 378 For multicast and link-local destination addresses, the set of 379 candidate source addresses MUST only include addresses assigned to 380 interfaces belonging to the same link as the outgoing interface. 382 Discussion: The restriction for multicast destination addresses is 383 necessary because currently-deployed multicast forwarding 384 algorithms use Reverse Path Forwarding (RPF) checks. 386 For site-local destination addresses, the set of candidate source 387 addresses MUST only include addresses assigned to interfaces 388 belonging to the same site as the outgoing interface. 390 In any case, anycast addresses, multicast addresses, and the 391 unspecified address MUST NOT be included in a candidate set. 393 If an application or upper-layer specifies a source address that is 394 not in the candidate set for the destination, then the network layer 395 MUST treat this as an error. The specified source address may 396 influence the candidate set, by affecting the choice of outgoing 397 interface. If the application or upper-layer specifies a source 398 address that is in the candidate set for the destination, then the 399 network layer MUST respect that choice. If the application or upper- 400 layer does not specify a source address, then the network layer uses 401 the source address selection algorithm specified in the next 402 section. 404 On IPv6-only nodes that support SIIT [13, especially section 5], if 405 the destination address is an IPv4-mapped address then the candidate 406 set MUST contain only IPv4-translatable addresses. If the 407 destination address is not an IPv4-mapped address, then the 408 candidate set MUST NOT contain IPv4-translatable addresses. 410 5. Source Address Selection 412 The source address selection algorithm produces as output a single 413 source address for use with a given destination address. This 414 algorithm only applies to IPv6 destination addresses, not IPv4 415 addresses. 417 The algorithm is specified here in terms of a list of pair-wise 418 comparison rules that (for a given destination address D) imposes a 419 "greater than" ordering on the addresses in the candidate set 420 CandidateSource(D). The address at the front of the list after the 421 algorithm completes is the one the algorithm selects. 423 Note that conceptually, a sort of the candidate set is being 424 performed, where a set of rules define the ordering among addresses. 425 But because the output of the algorithm is a single source address, 426 an implementation need not actually sort the set; it need only 427 identify the "maximum" value that ends up at the front of the sorted 428 list. 430 The ordering of the addresses in the candidate set is defined by a 431 list of eight pair-wise comparison rules, with each rule placing a 432 "greater than," "less than" or "equal to" ordering on two source 433 addresses with respect to each other (and that rule). In the case 434 that a given rule produces a tie, i.e., provides an "equal to" 435 result for the two addresses, the remaining rules are applied (in 436 order) to just those addresses that are tied to break the tie. Note 437 that if a rule produces a single clear "winner" (or set of "winners" 438 in the case of ties), those addresses not in the winning set can be 439 discarded from further consideration, with subsequent rules applied 440 only to the remaining addresses. If the eight rules fail to choose a 441 single address, some unspecified tie-breaker should be used. 443 When comparing two addresses SA and SB from the candidate set, we 444 say "prefer SA" to mean that SA is "greater than" SB, and similarly 445 we say "prefer SB" to mean that SA is "less than" SB. 447 Rule 1: Prefer same address. 448 If SA = D, then prefer SA. Similarly, if SB = D, then prefer SB. 450 Rule 2: Prefer appropriate scope. 451 If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB 452 and otherwise prefer SA. 453 Similarly, if Scope(SB) < Scope(SA): If Scope(SB) < Scope(D), then 454 prefer SA and otherwise prefer SB. 456 Rule 3: Avoid deprecated addresses. 457 The addresses SA and SB have the same scope. If one of the two 458 source addresses is "preferred" and one of them is "deprecated" (in 459 the RFC 2462 sense), then prefer the one that is "preferred." 460 Rule 4: Prefer home addresses. 461 If SA is simultaneously a home address and care-of address and SB is 462 not, then prefer SA. Similarly, if SB is simultaneously a home 463 address and care-of address and SA is not, then prefer SB. 464 If SA is just a home address and SB is just a care-of address, then 465 prefer SA. Similarly, if SB is just a home address and SA is just a 466 care-of address, then prefer SB. 467 An implementation may support a per-connection configuration 468 mechanism (for example, a socket option) to reverse the sense of 469 this preference and prefer care-of addresses over home addresses. 471 Rule 5: Prefer outgoing interface. 472 If SA is assigned to the interface that will be used to send to D 473 and SB is assigned to a different interface, then prefer SA. 474 Similarly, if SB is assigned to the interface that will be used to 475 send to D and SA is assigned to a different interface, then prefer 476 SB. 478 Rule 6: Prefer matching label. 479 If Label(SA) = Label(D) and Label(SB) <> Label(D), then prefer SA. 480 Similarly, if Label(SB) = Label(D) and Label(SA) <> Label(D), then 481 prefer SB. 483 Rule 7: Prefer public addresses. 484 If SA is a public address and SB is a temporary address, then prefer 485 SA. Similarly, if SB is a public address and SA is a temporary 486 address, then prefer SB. 487 An implementation MUST support a per-connection configuration 488 mechanism (for example, a socket option) to reverse the sense of 489 this preference and prefer temporary addresses over public 490 addresses. 492 This rule avoids applications potentially failing due to the 493 relatively short lifetime of temporary addresses or due to the 494 possibility of the reverse lookup of a temporary address either 495 failing or returning a randomized name. Implementations for which 496 privacy considerations outweigh these application compatibility 497 concerns MAY reverse the sense of this rule and by default prefer 498 temporary addresses over public addresses. 500 Rule 8: Use longest matching prefix. 501 If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then prefer SA. 502 Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then 503 prefer SB. 505 Rule 8 may be superseded if the implementation has other means of 506 choosing among source addresses. For example, if the implementation 507 somehow knows which source address will result in the "best" 508 communications performance. 510 Rule 2 (prefer appropriate scope) MUST be implemented and given high 511 priority because it can affect interoperability. 513 6. Destination Address Selection 515 The destination address selection algorithm takes a list of 516 destination addresses and sorts the addresses to produce a new list. 517 It is specified here in terms of the pair-wise comparison of 518 addresses DA and DB, where DA appears before DB in the original 519 list. 521 The algorithm sorts together both IPv6 and IPv4 addresses. To find 522 the attributes of an IPv4 address in the policy table, the IPv4 523 address should be represented as an IPv4-mapped address. 525 We write Source(D) to indicate the selected source address for a 526 destination D. For IPv6 addresses, the previous section specifies 527 the source address selection algorithm. Source address selection for 528 IPv4 addresses is not specified in this document. 530 We say that Source(D) is undefined if there is no source address 531 available for destination D. For IPv6 addresses, this is only the 532 case if CandidateSource(D) is the empty set. 534 The pair-wise comparison of destination addresses consists of ten 535 rules, which should be applied in order. If a rule determines a 536 result, then the remaining rules are not relevant and should be 537 ignored. Subsequent rules act as tie-breakers for earlier rules. See 538 the previous section for a lengthier description of how pair-wise 539 comparison tie-breaker rules can be used to sort a list. 541 Rule 1: Avoid unusable destinations. 542 If DB is known to be unreachable or if Source(DB) is undefined, then 543 prefer DA. Similarly, if DA is known to be unreachable or if 544 Source(DA) is undefined, then prefer DB. 546 Discussion: An implementation may know that a particular 547 destination is unreachable in several ways. For example, the 548 destination may be reached through a network interface that is 549 currently unplugged. For example, the implementation may retain 550 for some period of time information from Neighbor Unreachability 551 Detection [14]. In any case, the determination of unreachability 552 for the purposes of this rule is implementation-dependent. 554 Rule 2: Prefer matching scope. 555 If Scope(DA) = Scope(Source(DA)) and Scope(DB) <> Scope(Source(DB)), 556 then prefer DA. Similarly, if Scope(DA) <> Scope(Source(DA)) and 557 Scope(DB) = Scope(Source(DB)), then prefer DB. 559 Rule 3: Avoid deprecated addresses. 560 If Source(DA) is deprecated and Source(DB) is not, then prefer DB. 561 Similarly, if Source(DA) is not deprecated and Source(DB) is 562 deprecated, then prefer DA. 564 Rule 4: Prefer home addresses. 565 If Source(DA) is simultaneously a home address and care-of address 566 and Source(DB) is not, then prefer DA. Similarly, if Source(DB) is 567 simultaneously a home address and care-of address and Source(DA) is 568 not, then prefer DB. 569 If Source(DA) is just a home address and Source(DB) is just a care- 570 of address, then prefer DA. Similarly, if Source(DA) is just a care- 571 of address and Source(DB) is just a home address, then prefer DB. 573 Rule 5: Prefer matching label. 574 If Label(Source(DA)) = Label(DA) and Label(Source(DB)) <> Label(DB), 575 then prefer DA. Similarly, if Label(Source(DA)) <> Label(DA) and 576 Label(Source(DB)) = Label(DB), then prefer DB. 578 Rule 6: Prefer higher precedence. 579 If Precedence(DA) > Precedence(DB), then prefer DA. Similarly, if 580 Precedence(DA) < Precedence(DB), then prefer DB. 582 Rule 7: Prefer native transport. 583 If DA is reached via an encapsulating transition mechanism (eg, IPv6 584 in IPv4) and DB is not, then prefer DB. Similarly, if DB is reached 585 via encapsulation and DA is not, then prefer DA. 587 Discussion: 6-over-4 [15], ISATAP [16], and configured 588 tunnels [17] are examples of encapsulating transition mechanisms 589 for which the destination address does not have a specific prefix 590 and hence can not be assigned a lower precedence in the policy 591 table. An implementation MAY generalize this rule by using a 592 concept of interface preference, and giving virtual interfaces 593 (like the IPv6-in-IPv4 encapsulating interfaces) a lower 594 preference than native interfaces (like ethernet interfaces). 596 Rule 8: Prefer smaller scope. 597 If Scope(DA) < Scope(DB), then prefer DA. Similarly, if Scope(DA) > 598 Scope(DB), then prefer DB. 600 Rule 9: Use longest matching prefix. 601 When DA and DB belong to the same address family (both are IPv6 or 602 both are IPv4): If CommonPrefixLen(DA, Source(DA)) > 603 CommonPrefixLen(DB, Source(DB)), then prefer DA. Similarly, if 604 CommonPrefixLen(DA, Source(DA)) < CommonPrefixLen(DB, Source(DB)), 605 then prefer DB. 607 Rule 10: Otherwise, leave the order unchanged. 608 If DA preceded DB in the original list, prefer DA. Otherwise prefer 609 DB. 611 Rules 9 and 10 may be superseded if the implementation has other 612 means of sorting destination addresses. For example, if the 613 implementation somehow knows which destination addresses will result 614 in the "best" communications performance. 616 7. Interactions with Routing 618 This specification of source address selection assumes that routing 619 (more precisely, selecting an outgoing interface on a node with 620 multiple interfaces) is done before source address selection. 621 However, implementations may use source address considerations as a 622 tiebreaker when choosing among otherwise equivalent routes. 624 For example, suppose a node has interfaces on two different links, 625 with both links having a working default router. Both of the 626 interfaces have preferred (in the RFC 2462 sense) global addresses. 627 When sending to a global destination address, if there's no routing 628 reason to prefer one interface over the other, then an 629 implementation may preferentially choose the outgoing interface that 630 will allow it to use the source address that shares a longer common 631 prefix with the destination. 633 Implementations may also use the choice of router to influence the 634 choice of source address. For example, suppose a host is on a link 635 with two routers. One router is advertising a global prefix A and 636 the other router is advertising global prefix B. Then when sending 637 via the first router, the host may prefer source addresses with 638 prefix A and when sending via the second router, prefer source 639 addresses with prefix B. 641 8. Implementation Considerations 643 The destination address selection algorithm needs information about 644 potential source addresses. One possible implementation strategy is 645 for getaddrinfo() to call down to the network layer with a list of 646 destination addresses, sort the list in the network layer with full 647 current knowledge of available source addresses, and return the 648 sorted list to getaddrinfo(). This is simple and gives the best 649 results but it introduces the overhead of another system call. One 650 way to reduce this overhead is to cache the sorted address list in 651 the resolver, so that subsequent calls for the same name do not need 652 to resort the list. 654 Another implementation strategy is to call down to the network layer 655 to retrieve source address information and then sort the list of 656 addresses directly in the context of getaddrinfo(). To reduce 657 overhead in this approach, the source address information can be 658 cached, amortizing the overhead of retrieving it across multiple 659 calls to getaddrinfo(). In this approach, the implementation may not 660 have knowledge of the outgoing interface for each destination, so it 661 MAY use a looser definition of the candidate set during destination 662 address ordering. 664 In any case, if the implementation uses cached and possibly stale 665 information in its implementation of destination address selection, 666 or if the ordering of a cached list of destination addresses is 667 possibly stale, then it should ensure that the destination address 668 ordering returned to the application is no more than one second out 669 of date. For example, an implementation might make a system call to 670 check if any routing table entries or source address assignments 671 that might affect these algorithms have changed. Another strategy is 672 to use an invalidation counter that is incremented whenever any 673 underlying state is changed. By caching the current invalidation 674 counter value with derived state and then later comparing against 675 the current value, the implementation could detect if the derived 676 state is potentially stale. 678 9. Security Considerations 680 This document has no direct impact on Internet infrastructure 681 security. 683 Note that most source address selection algorithms, including the 684 one specified in this document, expose a potential privacy concern. 685 An unfriendly node can infer correlations among a target node's 686 addresses by probing the target node with request packets that force 687 the target host to choose its source address for the reply packets. 688 (Perhaps because the request packets are sent to an anycast or 689 multicast address, or perhaps the upper-layer protocol chosen for 690 the attack does not specify a particular source address for its 691 reply packets.) By using different addresses for itself, the 692 unfriendly node can cause the target node to expose the target's own 693 addresses. 695 10. Examples 697 This section contains a number of examples, first of default 698 behavior and then demonstrating the utility of policy table 699 configuration. These examples are provided for illustrative 700 purposes; they should not be construed as normative. 702 10.1. Default Source Address Selection 704 The source address selection rules, in conjunction with the default 705 policy table, produce the following behavior: 707 Destination: 2001::1 708 Candidate Source Addresses: 3ffe::1 or fe80::1 709 Result: 3ffe::1 (prefer appropriate scope) 711 Destination: 2001::1 712 Candidate Source Addresses: fe80::1 or fec0::1 713 Result: fec0::1 (prefer appropriate scope) 715 Destination: fec0::1 716 Candidate Source Addresses: fe80::1 or 2001::1 717 Result: 2001::1 (prefer appropriate scope) 719 Destination: ff05::1 720 Candidate Source Addresses: fe80::1 or fec0::1 or 2001::1 721 Result: fec0::1 (prefer appropriate scope) 722 Destination: 2001::1 723 Candidate Source Addresses: 2001::1 (deprecated) or 2002::1 724 Result: 2001::1 (prefer same address) 726 Destination: fec0::1 727 Candidate Source Addresses: fec0::2 (deprecated) or 2001::1 728 Result: fec0::2 (prefer appropriate scope) 730 Destination: 2001::1 731 Candidate Source Addresses: 2001::2 or 3ffe::2 732 Result: 2001::2 (longest-matching-prefix) 734 Destination: 2001::1 735 Candidate Source Addresses: 2001::2 (care-of address) or 3ffe::2 736 (home address) 737 Result: 3ffe::2 (prefer home address) 739 Destination: 2002:836b:2179::1 740 Candidate Source Addresses: 2002:836b:2179::d5e3:7953:13eb:22e8 741 (temporary) or 2001::2 742 Result: 2002:836b:2179::d5e3:7953:13eb:22e8 (prefer matching label) 744 Destination: 2001::d5e3:0:0:1 745 Candidate Source Addresses: 2001::2 or 2001::d5e3:7953:13eb:22e8 746 (temporary) 747 Result: 2001::2 (prefer public address) 749 10.2. Default Destination Address Selection 751 The destination address selection rules, in conjunction with the 752 default policy table and the source address selection rules, produce 753 the following behavior: 755 Candidate Source Addresses: 2001::2 or fe80::1 or 169.254.13.78 756 Destination Address List: 2001::1 or 131.107.65.121 757 Result: 2001::1 (src 2001::2) then 131.107.65.121 (src 758 169.254.13.78) (prefer matching scope) 760 Candidate Source Addresses: fe80::1 or 131.107.65.117 761 Destination Address List: 2001::1 or 131.107.65.121 762 Result: 131.107.65.121 (src 131.107.65.117) then 2001::1 (src 763 fe80::1) (prefer matching scope) 765 Candidate Source Addresses: 2001::2 or fe80::1 or 10.1.2.4 766 Destination Address List: 2001::1 or 10.1.2.3 767 Result: 2001::1 (src 2001::2) then 10.1.2.3 (src 10.1.2.4) (prefer 768 higher precedence) 770 Candidate Source Addresses: 2001::2 or fec0::2 or fe80::2 771 Destination Address List: 2001::1 or fec0::1 or fe80::1 772 Result: fe80::1 (src fe80::2) then fec0::1 (src fec0::2) then 773 2001::1 (src 2001::2) (prefer smaller scope) 774 Candidate Source Addresses: 2001::2 (care-of address) or 3ffe::1 775 (home address) or fec0::2 (care-of address) or fe80::2 (care-of 776 address) 777 Destination Address List: 2001::1 or fec0::1 778 Result: 2001:1 (src 3ffe::1) then fec0::1 (src fec0::2) (prefer home 779 address) 781 Candidate Source Addresses: 2001::2 or fec0::2 (deprecated) or 782 fe80::2 783 Destination Address List: 2001::1 or fec0::1 784 Result: 2001::1 (src 2001::2) then fec0::1 (src fec0::2) (avoid 785 deprecated addresses) 787 Candidate Source Addresses: 2001::2 or 3f44::2 or fe80::2 788 Destination Address List: 2001::1 or 3ffe::1 789 Result: 2001::1 (src 2001::2) then 3ffe::1 (src 3f44::2) (longest 790 matching prefix) 792 Candidate Source Addresses: 2002:836b:4179::2 or fe80::2 793 Destination Address List: 2002:836b:4179::1 or 2001::1 794 Result: 2002:836b:4179::1 (src 2002:836b:4179::2) then 2001::1 (src 795 2002:836b:4179::2) (prefer matching label) 797 Candidate Source Addresses: 2002:836b:4179::2 or 2001::2 or fe80::2 798 Destination Address List: 2002:836b:4179::1 or 2001::1 799 Result: 2001::1 (src 2001::2) then 2002:836b:4179::1 (src 800 2002:836b:4179::2) (prefer higher precedence) 802 10.3. Configuring Preference for IPv6 or IPv4 804 The default policy table gives IPv6 addresses higher precedence than 805 IPv4 addresses. This means that applications will use IPv6 in 806 preference to IPv4 when the two are equally suitable. An 807 administrator can change the policy table to prefer IPv4 addresses 808 by giving the ::ffff:0.0.0.0/96 prefix a higher precedence: 810 Prefix Precedence Label 811 ::1/128 50 0 812 ::/0 40 1 813 2002::/16 30 2 814 ::/96 20 3 815 ::ffff:0:0/96 100 4 817 This change to the default policy table produces the following 818 behavior: 820 Candidate Source Addresses: 2001::2 or fe80::1 or 169.254.13.78 821 Destination Address List: 2001::1 or 131.107.65.121 822 Unchanged Result: 2001::1 (src 2001::2) then 131.107.65.121 (src 823 169.254.13.78) (prefer matching scope) 824 Candidate Source Addresses: fe80::1 or 131.107.65.117 825 Destination Address List: 2001::1 or 131.107.65.121 826 Unchanged Result: 131.107.65.121 (src 131.107.65.117) then 2001::1 827 (src fe80::1) (prefer matching scope) 829 Candidate Source Addresses: 2001::2 or fe80::1 or 10.1.2.4 830 Destination Address List: 2001::1 or 10.1.2.3 831 New Result: 10.1.2.3 (src 10.1.2.4) then 2001::1 (src 2001::2) 832 (prefer higher precedence) 834 10.4. Configuring Preference for Scoped Addresses 836 The destination address selection rules give preference to 837 destinations of smaller scope. For example, a site-local destination 838 will be sorted before a global scope destination when the two are 839 otherwise equally suitable. An administrator can change the policy 840 table to reverse this preference and sort global destinations before 841 site-local destinations, and site-local destinations before link- 842 local destinations: 844 Prefix Precedence Label 845 ::1/128 50 0 846 ::/0 40 1 847 fec0::/10 37 1 848 fe80::/10 33 1 849 2002::/16 30 2 850 ::/96 20 3 851 ::ffff:0:0/96 10 4 853 This change to the default policy table produces the following 854 behavior: 856 Candidate Source Addresses: 2001::2 or fec0::2 or fe80::2 857 Destination Address List: 2001::1 or fec0::1 or fe80::1 858 New Result: 2001::1 (src 2001::2) then fec0::1 (src fec0::2) then 859 fe80::1 (src fe80::2) (prefer higher precedence) 861 Candidate Source Addresses: 2001::2 (deprecated) or fec0::2 or 862 fe80::2 863 Destination Address List: 2001::1 or fec0::1 864 Unchanged Result: fec0::1 (src fec0::2) then 2001::1 (src 2001::2) 865 (avoid deprecated addresses) 867 10.5. Configuring a Multi-Homed Site 869 Consider a site A that has a business-critical relationship with 870 another site B. To support their business needs, the two sites have 871 contracted for service with a special high-performance ISP. This is 872 in addition to the normal Internet connection that both sites have 873 with different ISPs. The high-performance ISP is expensive and the 874 two sites wish to use it only for their business-critical traffic 875 with each other. 877 Each site has two global prefixes, one from the high-performance ISP 878 and one from their normal ISP. Site A has prefix 2001:aaaa:aaaa::/48 879 from the high-performance ISP and prefix 2007:0:aaaa::/48 from its 880 normal ISP. Site B has prefix 2001:bbbb:bbbb::/48 from the high- 881 performance ISP and prefix 2007:0:bbbb::/48 from its normal ISP. All 882 hosts in both sites register two addresses in the DNS. 884 The routing within both sites directs most traffic to the egress to 885 the normal ISP, but the routing directs traffic sent to the other 886 site's 2001 prefix to the egress to the high-performance ISP. To 887 prevent unintended use of their high-performance ISP connection, the 888 two sites implement ingress filtering to discard traffic entering 889 from the high-performance ISP that is not from the other site. 891 The default policy table and address selection rules produce the 892 following behavior: 894 Candidate Source Addresses: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or 895 fe80::a 896 Destination Address List: 2001:bbbb:bbbb::b or 2007:0:bbbb::b 897 Result: 2007:0:bbbb::b (src 2007:0:aaaa::a) then 2001:bbbb:bbbb::b 898 (src 2001:aaaa:aaaa::a) (longest matching prefix) 900 In other words, when a host in site A initiates a connection to a 901 host in site B, the traffic does not take advantage of their 902 connections to the high-performance ISP. This is not their desired 903 behavior. 905 Candidate Source Addresses: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or 906 fe80::a 907 Destination Address List: 2001:cccc:cccc::c or 2006:cccc:cccc::c 908 Result: 2001:cccc:cccc::c (src 2001:aaaa:aaaa::a) then 909 2006:cccc:cccc::c (src 2007:0:aaaa::a) (longest matching prefix) 911 In other words, when a host in site A initiates a connection to a 912 host in some other site C, the reverse traffic may come back through 913 the high-performance ISP. Again, this is not their desired behavior. 915 This predicament demonstrates the limitations of the longest- 916 matching-prefix heuristic in multi-homed situations. 918 However, the administrators of sites A and B can achieve their 919 desired behavior via policy table configuration. For example, they 920 can use the following policy table: 922 Prefix Precedence Label 923 ::1 50 0 924 2001:aaaa:aaaa::/48 45 5 925 2001:bbbb:bbbb::/48 45 5 926 ::/0 40 1 927 2002::/16 30 2 928 ::/96 20 3 929 ::ffff:0:0/96 10 4 930 This policy table produces the following behavior: 932 Candidate Source Addresses: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or 933 fe80::a 934 Destination Address List: 2001:bbbb:bbbb::b or 2007:0:bbbb::b 935 New Result: 2001:bbbb:bbbb::b (src 2001:aaaa:aaaa::a) then 936 2007:0:bbbb::b (src 2007:0:aaaa::a) (prefer higher precedence) 938 In other words, when a host in site A initiates a connection to a 939 host in site B, the traffic uses the high-performance ISP as 940 desired. 942 Candidate Source Addresses: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or 943 fe80::a 944 Destination Address List: 2001:cccc:cccc::c or 2006:cccc:cccc::c 945 New Result: 2006:cccc:cccc::c (src 2007:0:aaaa::a) then 946 2001:cccc:cccc::c (src 2007:0:aaaa::a) (longest matching prefix) 948 In other words, when a host in site A initiates a connection to a 949 host in some other site C, the traffic uses the normal ISP as 950 desired. 952 References 954 1 S. Bradner, "The Internet Standards Process -- Revision 3", BCP 955 9, RFC 2026, October 1996. 957 2 R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", 958 RFC 2373, July 1998. 960 3 S. Thompson, T. Narten, "IPv6 Stateless Address Autoconfig- 961 uration", RFC 2462 , December 1998. 963 4 T. Narten, R. Draves, "Privacy Extensions for Stateless Address 964 Autoconfiguration in IPv6", RFC 3041, January 2001. 966 5 D. Johnson, C. Perkins, "Mobility Support in IPv6", draft-ietf- 967 mobileip-ipv6-14.txt, July 2001. 969 6 S. Cheshire, B. Aboba, "Dynamic Configuration of IPv4 Link-local 970 Addresses", draft-ietf-zeroconf-ipv4-linklocal-04.txt, July 2001. 972 7 S. Bradner, "Key words for use in RFCs to Indicate Requirement 973 Levels", BCP 14, RFC 2119, March 1997. 975 8 R. Gilligan, S. Thomson, J. Bound, W. Stevens, "Basic Socket 976 Interface Extensions for IPv6", RFC 2553, March 1999. 978 9 B. Carpenter, K. Moore, "Connection of IPv6 Domains via IPv4 979 Clouds", RFC 3056, February 2001. 981 10 S. Deering et. al, "IP Version 6 Scoped Address Architecture", 982 draft-ietf-ipngwg-scoping-arch-03.txt, November 2001. 984 11 Y. Rekhter et. al, "Address Allocation for Private Internets", 985 RFC 1918, February 1996. 987 12 F. Baker, Editor, "Requirements for IP Version 4 Routers", RFC 988 1812, June 1995. 990 13 E. Nordmark, "Stateless IP/ICMP Translation Algorithm (SIIT)", 991 RFC 2765, February 2000. 993 14 T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery for 994 IP Version 6", RFC 2461, December 1998. 996 15 B. Carpenter and C. Jung, "Transmission of IPv6 over IPv4 Domains 997 without Explicit Tunnels", RFC 2529, March 1999. 999 16 F. Templin et. al, "Intra-Site Automatic Tunnel Addressing 1000 Protocol (ISATAP)", draft-ietf-ngtrans-isatap-03.txt, January 1001 2002. 1003 17 R. Gilligan and E. Nordmark, "Transition Mechanisms for IPv6 1004 Hosts and Routers", RFC 1933, April 1996. 1006 Acknowledgments 1008 The author would like to acknowledge the contributions of the IPng 1009 Working Group, particularly Marc Blanchet, Brian Carpenter, Matt 1010 Crawford, Alain Durand, Steve Deering, Robert Elz, Jun-ichiro itojun 1011 Hagino, Tony Hain, M.T. Hollinger, JINMEI Tatuya, Thomas Narten, 1012 Erik Nordmark, Ken Powell, Markku Savela, Pekka Savola, Hesham 1013 Soliman, Dave Thaler, Mauro Tortonesi, Ole Troan, and Stig Venaas. 1014 In addition, the anonymous IESG reviewers had many great comments 1015 and suggestions for clarification. 1017 Author's Address 1019 Richard Draves 1020 Microsoft Research 1021 One Microsoft Way 1022 Redmond, WA 98052 1023 Phone: +1 425 706 2268 1024 Email: richdr@microsoft.com 1026 Revision History 1028 This section to be removed by the RFC editor upon publication. 1030 Changes from draft-ietf-ipv6-default-addr-select-07 1032 Added definitions and requirements for IPv4-mapped and IPv4- 1033 translatable addresses, in support of SIIT. 1035 Changed the requirement for an API to control temporary vs public 1036 address preference in source address selection, from may to MUST. 1038 Clarifications and editorial changes from the IESG. 1040 Changes from draft-ietf-ipngwg-default-addr-select-06 1042 Added a table of contents. 1044 Modified the longest-matching-prefix destination-address selection 1045 rule, so that it only applies if the two destination addresses 1046 belong to the same address family. 1048 Various great clarifications from Thomas Narten. 1050 Changes from draft-ietf-ipngwg-default-addr-select-05 1052 Clarified the first destination-address selection rule, avoiding 1053 unusable destination addresses. 1055 Added a new destination-address selection rule, to prefer native 1056 transport over transition mechanisms that use encapsulation. 1058 Changes from draft-ietf-ipngwg-default-addr-select-04 1060 Clarified candidate set formation for routers. 1062 Added some explanatory discussion to the candidate set section. 1064 Replaced usages of scope id with zone index. 1066 Augmented the first destination-address selection rule, to avoid 1067 destination addresses for which the current next-hop neighbor is 1068 known to be unreachable. 1070 Changes from draft-ietf-ipngwg-default-addr-select-03 1072 Reversed the treatment of temporary addresses, so that unless an 1073 application specifies otherwise public addresses are preferred over 1074 temporary addresses. 1076 Added text clarifying our expectation that applications should 1077 iterate through the list of possible destination addresses until 1078 finding a working address. 1080 Removed references to getipnodebyname(). 1082 Changes from draft-ietf-ipngwg-default-addr-select-02 1084 Changed scope treatment of IPv4-compatible and 6to4 addresses, so 1085 they are always considered to be global. Removed mention of IPX 1086 addresses. 1088 Changed home address rules to favor addresses that are 1089 simultaneously home and care-of addresses, over addresses that are 1090 just home addresses or just care-of addresses. 1092 Combined SrcLabel & DstLabel in the policy table into a single Label 1093 attribute. 1095 Added mention of the invalidation counter technique in the 1096 implementation section. 1098 Changes from draft-ietf-ipngwg-default-addr-select-01 1100 Added Examples section, demonstrating default behavior and some 1101 policy table configuration scenarios. 1103 Removed many uses of MUST. Remaining uses concern the candidate set 1104 of source addresses and the source address selection rule that 1105 prefers source addresses of appropriate scope. 1107 Simplified the default policy table. Reordered the source address 1108 selection rules to reduce the influence of policy labels. Added more 1109 destination address selection rules. 1111 Added scoping of v4-compatible and 6to4 addresses based on the 1112 embedded IPv4 address. 1114 Changed references to anonymous addresses to use the new term, 1115 temporary addresses. 1117 Clarified that a user-level implementation of destination address 1118 ordering, which does not have knowledge of the outgoing interface 1119 for each destination, may use a looser definition of the candidate 1120 set. 1122 Clarified that an implementation should prevent an application or 1123 upper-layer from choosing a source address that is not in the 1124 candidate set and not prevent an application or upper-layer from 1125 choosing a source address that is in the candidate set. 1127 Miscellaneous editorial changes, including adding some missing 1128 references. 1130 Changes from draft-ietf-ipngwg-default-addr-select-00 1132 Changed the candidate set definition so that the strong host model 1133 is recommended but not required. Added a rule to source address 1134 selection to prefer addresses assigned to the outgoing interface. 1136 Simplified the destination address selection algorithm, by having it 1137 use source address selection as a subroutine. 1139 Added a rule to source address selection to handle anonymous/public 1140 addresses. 1142 Added a rule to source address selection to handle home/care-of 1143 addresses. 1145 Changed to allow destination address selection to sort both IPv6 and 1146 IPv4 addresses. Added entries in the default policy table for IPv4- 1147 mapped addresses. 1149 Changed default precedences, so v4-compatible addresses have lower 1150 precedence than 6to4 addresses. 1152 Changes from draft-draves-ipngwg-simple-srcaddr-01 1154 Added framework discussion. 1156 Added algorithm for destination address ordering. 1158 Added mechanism to allow the specification of administrative policy 1159 that can override the default behavior. 1161 Added section on routing interactions and TBD section on mobility 1162 interactions. 1164 Changed the candidate set definition for source address selection, 1165 so that only addresses assigned to the outgoing interface are 1166 allowed. 1168 Changed the loopback address treatment to link-local scope. 1170 Changes from draft-draves-ipngwg-simple-srcaddr-00 1172 Minor wording changes because DHCPv6 also supports "preferred" and 1173 "deprecated" addresses. 1175 Specified treatment of other format prefixes; now they are 1176 considered global scope, "preferred" addresses. 1178 Reiterated that anycast and multicast addresses are not allowed as 1179 source addresses. 1181 Recommended that source addresses be taken from the outgoing 1182 interface. Required this for multicast destinations. Added analogous 1183 requirements for link-local and site-local destinations. 1185 Specified treatment of the loopback address. 1187 Changed the second selection rule so that if both candidate source 1188 addresses have scope greater or equal than the destination address 1189 and only of them is preferred, the preferred address is chosen. 1191 Full Copyright Statement 1193 Copyright (C) The Internet Society (1999). All Rights Reserved. 1195 This document and translations of it may be copied and furnished to 1196 others, and derivative works that comment on or otherwise explain it 1197 or assist in its implementation may be prepared, copied, published 1198 and distributed, in whole or in part, without restriction of any 1199 kind, provided that the above copyright notice and this paragraph 1200 are included on all such copies and derivative works. However, this 1201 document itself may not be modified in any way, such as by removing 1202 the copyright notice or references to the Internet Society or other 1203 Internet organizations, except as needed for the purpose of 1204 developing Internet standards in which case the procedures for 1205 copyrights defined in the Internet Standards process must be 1206 followed, or as required to translate it into languages other than 1207 English. 1209 The limited permissions granted above are perpetual and will not be 1210 revoked by the Internet Society or its successors or assigns. 1212 This document and the information contained herein is provided on an 1213 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1214 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1215 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1216 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1217 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.