idnits 2.17.1 draft-ietf-ipv6-default-addr-select-07.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 (March 1, 2002) is 8090 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 296 looks like a reference -- Missing reference section? '3' on line 80 looks like a reference -- Missing reference section? '4' on line 182 looks like a reference -- Missing reference section? '5' on line 183 looks like a reference -- Missing reference section? '6' on line 233 looks like a reference -- Missing reference section? '7' on line 138 looks like a reference -- Missing reference section? '8' on line 148 looks like a reference -- Missing reference section? '9' on line 222 looks like a reference -- Missing reference section? '10' on line 234 looks like a reference -- Missing reference section? '12' on line 295 looks like a reference -- Missing reference section? '13' on line 509 looks like a reference -- Missing reference section? '14' on line 545 looks like a reference -- Missing reference section? '15' on line 545 looks like a reference -- Missing reference section? '16' on line 546 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 17 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-07.txt March 1, 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 framework, including an 38 optional mechanism for allowing administrators to provide policy 39 that can override the default behavior. In dual stack 40 implementations, the framework allows the destination address 41 selection algorithm to consider both IPv4 and IPv6 addresses - 42 depending on the available source addresses, the algorithm might 43 prefer IPv6 addresses over 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. Framework...................................................3 53 2.1. Scope Comparisons...........................................4 54 2.2. IPv4 Addresses and IPv4-Mapped Addresses....................5 55 2.3. Other IPv6 Addresses with Embedded IPv4 Addresses...........5 56 2.4. IPv6 Loopback Address and Other Format Prefixes.............5 57 2.5. Policy Table................................................6 58 2.6. Common Prefix Length........................................6 59 3. Candidate Source Addresses..................................7 60 4. Source Address Selection....................................8 61 5. Destination Address Selection..............................10 62 6. Interactions with Routing..................................12 63 7. Implementation Considerations..............................12 64 8. Security Considerations....................................13 65 9. Examples...................................................13 66 9.1. Default Source Address Selection...........................13 67 9.2. Default Destination Address Selection......................14 68 9.3. Configuring Preference for IPv6 or IPv4....................15 69 9.4. Configuring Preference for Scoped Addresses................16 70 9.5. Configuring a Multi-Homed Site.............................16 71 Acknowledgments...................................................19 72 Author's Address..................................................19 73 Revision History..................................................19 75 1. Introduction 77 The IPv6 addressing architecture [2] allows multiple unicast 78 addresses to be assigned to interfaces. These addresses may have 79 different reachability scopes (link-local, site-local, or global). 80 These addresses may also be "preferred" or "deprecated" [3]. Privacy 81 considerations have introduced the concepts of "public addresses" 82 and "temporary addresses" [4]. The mobility architecture introduces 83 "home addresses" and "care-of addresses" [5]. In addition, multi- 84 homing situations will result in more addresses per node. For 85 example, a node may have multiple interfaces, some of them tunnels 86 or virtual interfaces, or a site may have multiple ISP attachments 87 with a global prefix per ISP. 89 The end result is that IPv6 implementations will very often be faced 90 with multiple possible source and destination addresses when 91 initiating communication. It is desirable to have default 92 algorithms, common across all implementations, for selecting source 93 and destination addresses so that developers and administrators can 94 reason about and predict the behavior of their systems. 96 Furthermore, dual or hybrid stack implementations, which support 97 both IPv6 and IPv4, will very often need to choose between IPv6 and 98 IPv4 when initiating communication. For example, when DNS name 99 resolution yields both IPv6 and IPv4 addresses and the network 100 protocol stack has available both IPv6 and IPv4 source addresses. In 101 such cases, a simple policy to always prefer IPv6 or always prefer 102 IPv4 can produce poor behavior. As one example, suppose a DNS name 103 resolves to a global IPv6 address and a global IPv4 address. If the 104 node has assigned a global IPv6 address and a 169.254/16 auto- 105 configured IPv4 address [6], then IPv6 is the best choice for 106 communication. But if the node has assigned only a link-local IPv6 107 address and a global IPv4 address, then IPv4 is the best choice for 108 communication. The destination address selection algorithm solves 109 this with a unified procedure for choosing among both IPv6 and IPv4 110 addresses. 112 This document specifies source address selection and destination 113 address selection separately, but using a common framework so that 114 together the two algorithms yield useful results. The algorithms 115 attempt to choose source and destination addresses of appropriate 116 scope and configuration status (preferred or deprecated). 117 Furthermore, this document suggests a preferred method, longest 118 matching prefix, for choosing among otherwise equivalent addresses 119 in the absence of better information. 121 The framework also has policy hooks to allow administrative override 122 of the default behavior. For example, using these hooks an 123 administrator can specify a preferred source prefix for use with a 124 destination prefix, or prefer destination addresses with one prefix 125 over addresses with another prefix. These hooks give an 126 administrator flexibility in dealing with some multi-homing and 127 transition scenarios, but they are certainly not a panacea. 129 The selection rules specified in this document MUST NOT be construed 130 to override an application or upper-layer's explicit choice of a 131 legal destination or source address. 133 1.1. Conventions used in this document 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 137 this document are to be interpreted as described in RFC 2119 [7]. 139 2. Framework 141 Our framework for address selection derives from the most common 142 implementation architecture, which separates the choice of 143 destination address from the choice of source address. Consequently, 144 the framework specifies two separate algorithms for these tasks. The 145 algorithms are designed to work well together and they share a 146 mechanism for administrative policy override. 148 In this implementation architecture, applications use APIs [8] like 149 getaddrinfo() that return a list of addresses to the application. 150 This list might contain both IPv6 and IPv4 addresses (sometimes 151 represented as IPv4-mapped addresses). The application then passes a 152 destination address to the network stack with connect() or sendto(). 153 The application would then typically try the first address in the 154 list, looping over the list of addresses until it finds a working 155 address. In any case, the network layer is never in a situation 156 where it needs to choose a destination address from several 157 alternatives. The application might also specify a source address 158 with bind(), but often the source address is left unspecified. 159 Therefore the network layer does often choose a source address from 160 several alternatives. 162 As a consequence, we intend that implementations of getaddrinfo() 163 will use the destination address selection algorithm specified here 164 to sort the list of IPv6 and IPv4 addresses that they return. 165 Separately, the IPv6 network layer will use the source address 166 selection algorithm when an application or upper-layer has not 167 specified a source address. Application of this framework to source 168 address selection in an IPv4 network layer may be possible but this 169 is not explored further here. 171 Well-behaved applications SHOULD iterate through the list of 172 addresses returned from getaddrinfo() until they find a working 173 address. 175 The algorithms use several criteria in making their decisions. The 176 combined effect is to prefer destination/source address pairs for 177 which the two addresses are of equal scope or type, prefer smaller 178 scopes over larger scopes for the destination address, prefer non- 179 deprecated source addresses, avoid the use of transitional addresses 180 when native addresses are available, and all else being equal prefer 181 address pairs having the longest possible common prefix. For source 182 address selection, public addresses [4] are preferred over temporary 183 addresses. In mobile situations [5], home addresses are preferred 184 over care-of addresses. If an address is simultaneously a home 185 address and a care-of address (indicating the mobile node is "at 186 home" for that address), then the home/care-of address is preferred 187 over addresses that are solely a home address or solely a care-of 188 address. 190 The framework optionally allows for the possibility of 191 administrative configuration of policy that can override the default 192 behavior of the algorithms. The policy override takes the form of a 193 configurable table that specifies precedence values and preferred 194 source prefixes for destination prefixes. If an implementation is 195 not configurable, or if an implementation has not been configured, 196 then the default policy table specified in this document SHOULD be 197 used. 199 2.1. Scope Comparisons 201 Multicast destination addresses have a 4-bit scope field that 202 controls the propagation of the multicast packet. The IPv6 203 addressing architecture defines scope field values for interface- 204 local (0x1), link-local (0x2), subnet-local (0x3), admin-local 205 (0x4), site-local (0x5), organization-local (0x8), and global (0xE) 206 scopes [9]. 208 Use of the source address selection algorithm in the presence of 209 multicast destination addresses requires the comparison of a unicast 210 address scope with a multicast address scope. We map unicast link- 211 local to multicast link-local, unicast site-local to multicast site- 212 local, and unicast global scope to multicast global scope. For 213 example, unicast site-local is equal to multicast site-local, which 214 is smaller than multicast organization-local, which is smaller than 215 unicast global, which is equal to multicast global. 217 We write Scope(A) to mean the scope of address A. For example, if A 218 is a link-local unicast address and B is a site-local multicast 219 address, then Scope(A) < Scope(B). 221 This mapping implicitly conflates unicast site boundaries and 222 multicast site boundaries [9]. 224 2.2. IPv4 Addresses and IPv4-Mapped Addresses 226 The destination address selection algorithm operates on both IPv6 227 and IPv4 addresses. For this purpose, IPv4 addresses should be 228 represented as IPv4-mapped addresses [2]. For example, to lookup the 229 precedence or other attributes of an IPv4 address in the policy 230 table, lookup the corresponding IPv4-mapped IPv6 address. 232 IPv4 addresses are assigned scopes as follows. IPv4 auto- 233 configuration addresses [6], which have the prefix 169.254/16, are 234 assigned link-local scope. IPv4 private addresses [10], which have 235 the prefixes 10/8, 172.16/12, and 192.168/16, are assigned site- 236 local scope. IPv4 loopback addresses [11, section 4.2.2.11], which 237 have the prefix 127/8, are assigned link-local scope (analogously to 238 the treatment of the IPv6 loopback address [9, section 4]). Other 239 IPv4 addresses are assigned global scope. 241 IPv4 addresses should be treated as having "preferred" configuration 242 status. 244 2.3. Other IPv6 Addresses with Embedded IPv4 Addresses 246 IPv4-compatible addresses [2] and 6to4 addresses [12] contain an 247 embedded IPv4 address. For the purposes of this document, these 248 addresses should be treated as having global scope. 250 IPv4-compatible addresses should be treated as having "preferred" 251 configuration status. 253 2.4. IPv6 Loopback Address and Other Format Prefixes 255 The loopback address should be treated as having link-local 256 scope [9, section 4] and "preferred" configuration status. 258 NSAP addresses and other addresses with as-yet-undefined format 259 prefixes should be treated as having global scope and "preferred" 260 configuration status. Later standards may supersede this treatment. 262 2.5. Policy Table 264 The policy table is a longest-matching-prefix lookup table, much 265 like a routing table. Given an address A, a lookup in the policy 266 table produces two values: a precedence value Precedence(A) and a 267 classification or label Label(A). 269 The precedence value Precedence(A) is used for sorting destination 270 addresses. If Precedence(A) > Precedence(B), we say that address A 271 has higher precedence than address B, meaning that our algorithm 272 will prefer to sort destination address A before destination address 273 B. 275 The label value Label(A) allows for policies that prefer a 276 particular source address prefix for use with a destination address 277 prefix. The algorithms prefer to use a source address S with a 278 destination address D if Label(S) = Label(D). 280 IPv6 implementations SHOULD support configurable address selection 281 via a mechanism at least as powerful as the policy tables defined 282 here. If an implementation is not configurable or has not been 283 configured, then it SHOULD operate according to the algorithms 284 specified here in conjunction with the following default policy 285 table: 287 Prefix Precedence Label 288 ::1/128 50 0 289 ::/0 40 1 290 2002::/16 30 2 291 ::/96 20 3 292 ::ffff:0:0/96 10 4 294 One effect of the default policy table is to prefer using native 295 source addresses with native destination addresses, 6to4 [12] source 296 addresses with 6to4 destination addresses, and v4-compatible [2] 297 source addresses with v4-compatible destination addresses. Another 298 effect of the default policy table is to prefer communication using 299 IPv6 addresses to communication using IPv4 addresses, if matching 300 source addresses are available. 302 Policy table entries for scoped address prefixes MAY be qualified 303 with an optional zone index. If so, a prefix table entry only 304 matches against an address during a lookup if the zone index also 305 matches the address's zone index. 307 2.6. Common Prefix Length 309 We define the common prefix length CommonPrefixLen(A, B) of two 310 addresses A and B as the length of the longest prefix (looking at 311 the most significant, or leftmost, bits) that the two addresses have 312 in common. It ranges from 0 to 128. 314 3. Candidate Source Addresses 316 The source address selection algorithm uses the concept of a 317 "candidate set" of potential source addresses for a given 318 destination address. The candidate set is the set of all addresses 319 that could be used as a source address; the source address selection 320 algorithm will pick an address out of that set. We write 321 CandidateSource(A) to denote the candidate set for the address A. 323 It is RECOMMENDED that the candidate source addresses be the set of 324 unicast addresses assigned to the interface that will be used to 325 send to the destination. (The "outgoing" interface.) On routers, the 326 candidate set MAY include unicast addresses assigned to any 327 interface that forwards packets, subject to the restrictions 328 described below. 330 Discussion: The Neighbor Discovery Redirect mechanism [13] 331 requires that routers verify that the source address of a packet 332 identifies a neighbor before generating a Redirect, so it is 333 advantageous for hosts to choose source addresses assigned to the 334 outgoing interface. Implementations that wish to support the use 335 of global source addresses assigned to a loopback interface should 336 behave as if the loopback interface originates and forwards the 337 packet. 339 In some cases the destination address may be qualified with a zone 340 index or other information that will constrain the candidate set. 342 For multicast and link-local destination addresses, the set of 343 candidate source addresses MUST only include addresses assigned to 344 interfaces belonging to the same link as the outgoing interface. 346 Discussion: The restriction for multicast destination addresses is 347 necessary because currently-deployed multicast forwarding 348 algorithms use Reverse Path Forwarding (RPF) checks. 350 For site-local destination addresses, the set of candidate source 351 addresses MUST only include addresses assigned to interfaces 352 belonging to the same site as the outgoing interface. 354 In any case, anycast addresses, multicast addresses, and the 355 unspecified address MUST NOT be included in a candidate set. 357 If an application or upper-layer specifies a source address that is 358 not in the candidate set for the destination, then the network layer 359 MUST treat this as an error. The specified source address may 360 influence the candidate set, by affecting the choice of outgoing 361 interface. If the application or upper-layer specifies a source 362 address that is in the candidate set for the destination, then the 363 network layer MUST respect that choice. If the application or upper- 364 layer does not specify a source address, then the network layer uses 365 the source address selection algorithm specified in the next 366 section. 368 4. Source Address Selection 370 The source address selection algorithm produces as output a single 371 source address for use with a given destination address. This 372 algorithm only applies to IPv6 destination addresses, not IPv4 373 addresses. 375 The algorithm is specified here in terms of a list of pair-wise 376 comparison rules that (for a given destination address D) imposes a 377 "greater than" ordering on the addresses in the candidate set 378 CandidateSource(D). The address at the front of the list after the 379 algorithm completes is the one the algorithm selects. 381 Note that conceptually, a sort of the candidate set is being 382 performed, where a set of rules define the ordering among addresses. 383 But because the output of the algorithm is a single source address, 384 an implementation need not actually sort the set; it need only 385 identify the "maximum" value that ends up at the front of the sorted 386 list. 388 The ordering of the addresses in the candidate set is defined by a 389 list of eight pair-wise comparison rules, with each rule placing a 390 "greater than," "less than" or "equal to" ordering on two source 391 addresses with respect to each other (and that rule). In the case 392 that a given rule produces a tie, i.e., provides an "equal to" 393 result for the two addresses, the remaining rules are applied (in 394 order) to just those addresses that are tied to break the tie. Note 395 that if a rule produces a single clear "winner" (or set of "winners" 396 in the case of ties), those addresses not in the winning set can be 397 discarded from further consideration, with subsequent rules applied 398 only to the remaining addresses. If the eight rules fail to choose a 399 single address, some unspecified tie-breaker should be used. 401 When comparing two addresses SA and SB from the candidate set, we 402 say "prefer SA" to mean that SA is "greater than" SB, and similarly 403 we say "prefer SB" to mean that SA is "less than" SB. 405 Rule 1: Prefer same address. 406 If SA = D, then prefer SA. Similarly, if SB = D, then prefer SB. 408 Rule 2: Prefer appropriate scope. 409 If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB 410 and otherwise prefer SA. 411 Similarly, if Scope(SB) < Scope(SA): If Scope(SB) < Scope(D), then 412 prefer SA and otherwise prefer SB. 414 Rule 3: Avoid deprecated addresses. 415 The addresses SA and SB have the same scope. If one of the two 416 source addresses is "preferred" and one of them is "deprecated", 417 then prefer the one that is "preferred." 418 Rule 4: Prefer home addresses. 419 If SA is simultaneously a home address and care-of address and SB is 420 not, then prefer SA. Similarly, if SB is simultaneously a home 421 address and care-of address and SA is not, then prefer SB. 422 If SA is just a home address and SB is just a care-of address, then 423 prefer SA. Similarly, if SB is just a home address and SA is just a 424 care-of address, then prefer SB. 425 An implementation may support a per-connection configuration 426 mechanism (for example, a socket option) to reverse the sense of 427 this preference and prefer care-of addresses over home addresses. 429 Rule 5: Prefer outgoing interface. 430 If SA is assigned to the interface that will be used to send to D 431 and SB is assigned to a different interface, then prefer SA. 432 Similarly, if SB is assigned to the interface that will be used to 433 send to D and SA is assigned to a different interface, then prefer 434 SB. 436 Rule 6: Prefer matching label. 437 If Label(SA) = Label(D) and Label(SB) <> Label(D), then prefer SA. 438 Similarly, if Label(SB) = Label(D) and Label(SA) <> Label(D), then 439 prefer SB. 441 Rule 7: Prefer public addresses. 442 If SA is a public address and SB is a temporary address, then prefer 443 SA. Similarly, if SB is a public address and SA is a temporary 444 address, then prefer SB. 445 An implementation may support a per-connection configuration 446 mechanism (for example, a socket option) to reverse the sense of 447 this preference and prefer temporary addresses over public 448 addresses. 450 This rule avoids applications potentially failing due to the 451 relatively short lifetime of temporary addresses or due to the 452 possibility of the reverse lookup of a temporary address either 453 failing or returning a randomized name. Implementations for which 454 privacy considerations outweigh these application compatibility 455 concerns MAY reverse the sense of this rule and by default prefer 456 temporary addresses over public addresses. 458 Rule 8: Use longest matching prefix. 459 If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then prefer SA. 460 Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then 461 prefer SB. 463 Rule 8 may be superseded if the implementation has other means of 464 choosing among source addresses. For example, if the implementation 465 somehow knows which source address will result in the "best" 466 communications performance. 468 Rule 2 (prefer appropriate scope) MUST be implemented and given high 469 priority because it can affect interoperability. 471 5. Destination Address Selection 473 The destination address selection algorithm takes a list of 474 destination addresses and sorts the addresses to produce a new list. 475 It is specified here in terms of the pair-wise comparison of 476 addresses DA and DB, where DA appears before DB in the original 477 list. 479 The algorithm sorts together both IPv6 and IPv4 addresses. To find 480 the attributes of an IPv4 address in the policy table, the IPv4 481 address should be represented as an IPv4-mapped address. 483 We write Source(D) to indicate the selected source address for a 484 destination D. For IPv6 addresses, the previous section specifies 485 the source address selection algorithm. Source address selection for 486 IPv4 addresses is not specified in this document. 488 We say that Source(D) is undefined if there is no source address 489 available for destination D. For IPv6 addresses, this is only the 490 case if CandidateSource(D) is the empty set. 492 The pair-wise comparison of destination addresses consists of ten 493 rules, which should be applied in order. If a rule determines a 494 result, then the remaining rules are not relevant and should be 495 ignored. Subsequent rules act as tie-breakers for earlier rules. See 496 the previous section for a lengthier description of how pair-wise 497 comparison tie-breaker rules can be used to sort a list. 499 Rule 1: Avoid unusable destinations. 500 If DB is known to be unreachable or if Source(DB) is undefined, then 501 prefer DA. Similarly, if DA is known to be unreachable or if 502 Source(DA) is undefined, then prefer DB. 504 Discussion: An implementation may know that a particular 505 destination is unreachable in several ways. For example, the 506 destination may be reached through a network interface that is 507 currently unplugged. For example, the implementation may retain 508 for some period of time information from Neighbor Unreachability 509 Detection [13]. In any case, the determination of unreachability 510 for the purposes of this rule is implementation-dependent. 512 Rule 2: Prefer matching scope. 513 If Scope(DA) = Scope(Source(DA)) and Scope(DB) <> Scope(Source(DB)), 514 then prefer DA. Similarly, if Scope(DA) <> Scope(Source(DA)) and 515 Scope(DB) = Scope(Source(DB)), then prefer DB. 517 Rule 3: Avoid deprecated addresses. 518 If Source(DA) is deprecated and Source(DB) is not, then prefer DB. 519 Similarly, if Source(DA) is not deprecated and Source(DB) is 520 deprecated, then prefer DA. 522 Rule 4: Prefer home addresses. 523 If Source(DA) is simultaneously a home address and care-of address 524 and Source(DB) is not, then prefer DA. Similarly, if Source(DB) is 525 simultaneously a home address and care-of address and Source(DA) is 526 not, then prefer DB. 527 If Source(DA) is just a home address and Source(DB) is just a care- 528 of address, then prefer DA. Similarly, if Source(DA) is just a care- 529 of address and Source(DB) is just a home address, then prefer DB. 531 Rule 5: Prefer matching label. 532 If Label(Source(DA)) = Label(DA) and Label(Source(DB)) <> Label(DB), 533 then prefer DA. Similarly, if Label(Source(DA)) <> Label(DA) and 534 Label(Source(DB)) = Label(DB), then prefer DB. 536 Rule 6: Prefer higher precedence. 537 If Precedence(DA) > Precedence(DB), then prefer DA. Similarly, if 538 Precedence(DA) < Precedence(DB), then prefer DB. 540 Rule 7: Prefer native transport. 541 If DA is reached via an encapsulating transition mechanism (eg, IPv6 542 in IPv4) and DB is not, then prefer DB. Similarly, if DB is reached 543 via encapsulation and DA is not, then prefer DA. 545 Discussion: 6-over-4 [14], ISATAP [15], and configured 546 tunnels [16] are examples of encapsulating transition mechanisms 547 for which the destination address does not have a specific prefix 548 and hence can not be assigned a lower precedence in the policy 549 table. An implementation MAY generalize this rule by using a 550 concept of interface preference, and giving virtual interfaces 551 (like the IPv6-in-IPv4 encapsulating interfaces) a lower 552 preference than native interfaces (like ethernet interfaces). 554 Rule 8: Prefer smaller scope. 555 If Scope(DA) < Scope(DB), then prefer DA. Similarly, if Scope(DA) > 556 Scope(DB), then prefer DB. 558 Rule 9: Use longest matching prefix. 559 When DA and DB belong to the same address family (both are IPv6 or 560 both are IPv4): If CommonPrefixLen(DA, Source(DA)) > 561 CommonPrefixLen(DB, Source(DB)), then prefer DA. Similarly, if 562 CommonPrefixLen(DA, Source(DA)) < CommonPrefixLen(DB, Source(DB)), 563 then prefer DB. 565 Rule 10: Otherwise, leave the order unchanged. 566 If DA preceded DB in the original list, prefer DA. Otherwise prefer 567 DB. 569 Rules 9 and 10 may be superseded if the implementation has other 570 means of sorting destination addresses. For example, if the 571 implementation somehow knows which destination addresses will result 572 in the "best" communications performance. 574 6. Interactions with Routing 576 This specification of source address selection assumes that routing 577 (more precisely, selecting an outgoing interface on a node with 578 multiple interfaces) is done before source address selection. 579 However, implementations may use source address considerations as a 580 tiebreaker when choosing among otherwise equivalent routes. 582 For example, suppose a node has interfaces on two different links, 583 with both links having a working default router. Both of the 584 interfaces have preferred global addresses. When sending to a global 585 destination address, if there's no routing reason to prefer one 586 interface over the other, then an implementation may preferentially 587 choose the outgoing interface that will allow it to use the source 588 address that shares a longer common prefix with the destination. 590 Implementations may also use the choice of router to influence the 591 choice of source address. For example, suppose a host is on a link 592 with two routers. One router is advertising a global prefix A and 593 the other router is advertising global prefix B. Then when sending 594 via the first router, the host may prefer source addresses with 595 prefix A and when sending via the second router, prefer source 596 addresses with prefix B. 598 7. Implementation Considerations 600 The destination address selection algorithm needs information about 601 potential source addresses. One possible implementation strategy is 602 for getaddrinfo() to call down to the network layer with a list of 603 destination addresses, sort the list in the network layer with full 604 current knowledge of available source addresses, and return the 605 sorted list to getaddrinfo(). This is simple and gives the best 606 results but it introduces the overhead of another system call. One 607 way to reduce this overhead is to cache the sorted address list in 608 the resolver, so that subsequent calls for the same name do not need 609 to resort the list. 611 Another implementation strategy is to call down to the network layer 612 to retrieve source address information and then sort the list of 613 addresses directly in the context of getaddrinfo(). To reduce 614 overhead in this approach, the source address information can be 615 cached, amortizing the overhead of retrieving it across multiple 616 calls to getaddrinfo(). In this approach, the implementation may not 617 have knowledge of the outgoing interface for each destination, so it 618 MAY use a looser definition of the candidate set during destination 619 address ordering. 621 In any case, if the implementation uses cached and possibly stale 622 information in its implementation of destination address selection, 623 or if the ordering of a cached list of destination addresses is 624 possibly stale, then it should ensure that the destination address 625 ordering returned to the application is no more than one second out 626 of date. For example, an implementation might make a system call to 627 check if any routing table entries or source address assignments 628 that might affect these algorithms have changed. Another strategy is 629 to use an invalidation counter that is incremented whenever any 630 underlying state is changed. By caching the current invalidation 631 counter value with derived state and then later comparing against 632 the current value, the implementation could detect if the derived 633 state is potentially stale. 635 8. Security Considerations 637 This document has no direct impact on Internet infrastructure 638 security. 640 Note that most source address selection algorithms, including the 641 one specified in this document, expose a potential privacy concern. 642 An unfriendly node can infer correlations among a target node's 643 addresses by probing the target node with request packets that force 644 the target host to choose its source address for the reply packets. 645 (Perhaps because the request packets are sent to an anycast or 646 multicast address, or perhaps the upper-layer protocol chosen for 647 the attack does not specify a particular source address for its 648 reply packets.) By using different addresses for itself, the 649 unfriendly node can cause the target node to expose the target's own 650 addresses. 652 9. Examples 654 This section contains a number of examples, first of default 655 behavior and then demonstrating the utility of policy table 656 configuration. These examples are provided for illustrative 657 purposes; they should not be construed as normative. 659 9.1. Default Source Address Selection 661 The source address selection rules, in conjunction with the default 662 policy table, produce the following behavior: 664 Destination: 2001::1 665 Candidate Set: 3ffe::1 or fe80::1 666 Result: 3ffe::1 (prefer appropriate scope) 668 Destination: 2001::1 669 Candidate Set: fe80::1 or fec0::1 670 Result: fec0::1 (prefer appropriate scope) 672 Destination: fec0::1 673 Candidate Set: fe80::1 or 2001::1 674 Result: 2001::1 (prefer appropriate scope) 676 Destination: ff05::1 677 Candidate Set: fe80::1 or fec0::1 or 2001::1 678 Result: fec0::1 (prefer appropriate scope) 679 Destination: 2001::1 680 Candidate Set: 2001::1 (deprecated) or 2002::1 681 Result: 2001::1 (prefer same address) 683 Destination: fec0::1 684 Candidate Set: fec0::2 (deprecated) or 2001::1 685 Result: fec0::2 (prefer appropriate scope) 687 Destination: 2001::1 688 Candidate Set: 2001::2 or 3ffe::2 689 Result: 2001::2 (longest-matching-prefix) 691 Destination: 2001::1 692 Candidate Set: 2001::2 (care-of address) or 3ffe::2 (home address) 693 Result: 3ffe::2 (prefer home address) 695 Destination: 2002:836b:2179::1 696 Candidate Set: 2002:836b:2179::d5e3:7953:13eb:22e8 (temporary) or 697 2001::2 698 Result: 2002:836b:2179::d5e3:7953:13eb:22e8 (prefer matching label) 700 Destination: 2001::d5e3:0:0:1 701 Candidate Set: 2001::2 or 2001::d5e3:7953:13eb:22e8 (temporary) 702 Result: 2001::2 (prefer public address) 704 9.2. Default Destination Address Selection 706 The destination address selection rules, in conjunction with the 707 default policy table and the source address selection rules, produce 708 the following behavior: 710 Candidate Set: 2001::2 or fe80::1 or 169.254.13.78 711 Destinations: 2001::1 or 131.107.65.121 712 Result: 2001::1 (src 2001::2) then 131.107.65.121 (src 713 169.254.13.78) (prefer matching scope) 715 Candidate Set: fe80::1 or 131.107.65.117 716 Destinations: 2001::1 or 131.107.65.121 717 Result: 131.107.65.121 (src 131.107.65.117) then 2001::1 (src 718 fe80::1) (prefer matching scope) 720 Candidate Set: 2001::2 or fe80::1 or 10.1.2.4 721 Destinations: 2001::1 or 10.1.2.3 722 Result: 2001::1 (src 2001::2) then 10.1.2.3 (src 10.1.2.4) (prefer 723 higher precedence) 725 Candidate Set: 2001::2 or fec0::2 or fe80::2 726 Destinations: 2001::1 or fec0::1 or fe80::1 727 Result: fe80::1 (src fe80::2) then fec0::1 (src fec0::2) then 728 2001::1 (src 2001::2) (prefer smaller scope) 730 Candidate Set: 2001::2 (care-of address) or 3ffe::1 (home address) 731 or fec0::2 (care-of address) or fe80::2 (care-of address) 732 Destinations: 2001::1 or fec0::1 733 Result: 2001:1 (src 3ffe::1) then fec0::1 (src fec0::2) (prefer home 734 address) 736 Candidate Set: 2001::2 or fec0::2 (deprecated) or fe80::2 737 Destinations: 2001::1 or fec0::1 738 Result: 2001::1 (src 2001::2) then fec0::1 (src fec0::2) (avoid 739 deprecated addresses) 741 Candidate Set: 2001::2 or 3f44::2 or fe80::2 742 Destinations: 2001::1 or 3ffe::1 743 Result: 2001::1 (src 2001::2) then 3ffe::1 (src 3f44::2) (longest 744 matching prefix) 746 Candidate Set: 2002:836b:4179::2 or fe80::2 747 Destinations: 2002:836b:4179::1 or 2001::1 748 Result: 2002:836b:4179::1 (src 2002:836b:4179::2) then 2001::1 (src 749 2002:836b:4179::2) (prefer matching label) 751 Candidate Set: 2002:836b:4179::2 or 2001::2 or fe80::2 752 Destinations: 2002:836b:4179::1 or 2001::1 753 Result: 2001::1 (src 2001::2) then 2002:836b:4179::1 (src 754 2002:836b:4179::2) (prefer higher precedence) 756 9.3. Configuring Preference for IPv6 or IPv4 758 The default policy table gives IPv6 addresses higher precedence than 759 IPv4 addresses. This means that applications will use IPv6 in 760 preference to IPv4 when the two are equally suitable. An 761 administrator can change the policy table to prefer IPv4 addresses 762 by giving the ::ffff:0.0.0.0/96 prefix a higher precedence: 764 Prefix Precedence Label 765 ::1/128 50 0 766 ::/0 40 1 767 2002::/16 30 2 768 ::/96 20 3 769 ::ffff:0:0/96 100 4 771 This change to the default policy table produces the following 772 behavior: 774 Candidate Set: 2001::2 or fe80::1 or 169.254.13.78 775 Destinations: 2001::1 or 131.107.65.121 776 Unchanged Result: 2001::1 (src 2001::2) then 131.107.65.121 (src 777 169.254.13.78) (prefer matching scope) 779 Candidate Set: fe80::1 or 131.107.65.117 780 Destinations: 2001::1 or 131.107.65.121 781 Unchanged Result: 131.107.65.121 (src 131.107.65.117) then 2001::1 782 (src fe80::1) (prefer matching scope) 783 Candidate Set: 2001::2 or fe80::1 or 10.1.2.4 784 Destinations: 2001::1 or 10.1.2.3 785 New Result: 10.1.2.3 (src 10.1.2.4) then 2001::1 (src 2001::2) 786 (prefer higher precedence) 788 9.4. Configuring Preference for Scoped Addresses 790 The destination address selection rules give preference to 791 destinations of smaller scope. For example, a site-local destination 792 will be sorted before a global scope destination when the two are 793 otherwise equally suitable. An administrator can change the policy 794 table to reverse this preference and sort global destinations before 795 site-local destinations, and site-local destinations before link- 796 local destinations: 798 Prefix Precedence Label 799 ::1/128 50 0 800 ::/0 40 1 801 fec0::/10 37 1 802 fe80::/10 33 1 803 2002::/16 30 2 804 ::/96 20 3 805 ::ffff:0:0/96 10 4 807 This change to the default policy table produces the following 808 behavior: 810 Candidate Set: 2001::2 or fec0::2 or fe80::2 811 Destinations: 2001::1 or fec0::1 or fe80::1 812 New Result: 2001::1 (src 2001::2) then fec0::1 (src fec0::2) then 813 fe80::1 (src fe80::2) (prefer higher precedence) 815 Candidate Set: 2001::2 (deprecated) or fec0::2 or fe80::2 816 Destinations: 2001::1 or fec0::1 817 Unchanged Result: fec0::1 (src fec0::2) then 2001::1 (src 2001::2) 818 (avoid deprecated addresses) 820 9.5. Configuring a Multi-Homed Site 822 Consider a site A that has a business-critical relationship with 823 another site B. To support their business needs, the two sites have 824 contracted for service with a special high-performance ISP. This is 825 in addition to the normal Internet connection that both sites have 826 with different ISPs. The high-performance ISP is expensive and the 827 two sites wish to use it only for their business-critical traffic 828 with each other. 830 Each site has two global prefixes, one from the high-performance ISP 831 and one from their normal ISP. Site A has prefix 2001:aaaa:aaaa::/48 832 from the high-performance ISP and prefix 2007:0:aaaa::/48 from its 833 normal ISP. Site B has prefix 2001:bbbb:bbbb::/48 from the high- 834 performance ISP and prefix 2007:0:bbbb::/48 from its normal ISP. All 835 hosts in both sites register two addresses in the DNS. 837 The routing within both sites directs most traffic to the egress to 838 the normal ISP, but the routing directs traffic sent to the other 839 site's 2001 prefix to the egress to the high-performance ISP. To 840 prevent unintended use of their high-performance ISP connection, the 841 two sites implement ingress filtering to discard traffic entering 842 from the high-performance ISP that is not from the other site. 844 The default policy table and address selection rules produce the 845 following behavior: 847 Candidate Set: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a 848 Destinations: 2001:bbbb:bbbb::b or 2007:0:bbbb::b 849 Result: 2007:0:bbbb::b (src 2007:0:aaaa::a) then 2001:bbbb:bbbb::b 850 (src 2001:aaaa:aaaa::a) (longest matching prefix) 852 In other words, when a host in site A initiates a connection to a 853 host in site B, the traffic does not take advantage of their 854 connections to the high-performance ISP. This is not their desired 855 behavior. 857 Candidate Set: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a 858 Destinations: 2001:cccc:cccc::c or 2006:cccc:cccc::c 859 Result: 2001:cccc:cccc::c (src 2001:aaaa:aaaa::a) then 860 2006:cccc:cccc::c (src 2007:0:aaaa::a) (longest matching prefix) 862 In other words, when a host in site A initiates a connection to a 863 host in some other site C, the reverse traffic may come back through 864 the high-performance ISP. Again, this is not their desired behavior. 866 This situation demonstrates the limitations of the longest-matching- 867 prefix heuristic in multi-homed situations. 869 However, the administrators of sites A and B can achieve their 870 desired behavior via policy table configuration. For example, they 871 can use the following policy table: 873 Prefix Precedence Label 874 ::1 50 0 875 2001:aaaa:aaaa::/48 45 5 876 2001:bbbb:bbbb::/48 45 5 877 ::/0 40 1 878 2002::/16 30 2 879 ::/96 20 3 880 ::ffff:0:0/96 10 4 882 This policy table produces the following behavior: 884 Candidate Set: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a 885 Destinations: 2001:bbbb:bbbb::b or 2007:0:bbbb::b 886 New Result: 2001:bbbb:bbbb::b (src 2001:aaaa:aaaa::a) then 887 2007:0:bbbb::b (src 2007:0:aaaa::a) (prefer higher precedence) 889 In other words, when a host in site A initiates a connection to a 890 host in site B, the traffic uses the high-performance ISP as 891 desired. 893 Candidate Set: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a 894 Destinations: 2001:cccc:cccc::c or 2006:cccc:cccc::c 895 New Result: 2006:cccc:cccc::c (src 2007:0:aaaa::a) then 896 2001:cccc:cccc::c (src 2007:0:aaaa::a) (longest matching prefix) 898 In other words, when a host in site A initiates a connection to a 899 host in some other site C, the traffic uses the normal ISP as 900 desired. 902 References 904 1 S. Bradner, "The Internet Standards Process -- Revision 3", BCP 905 9, RFC 2026, October 1996. 907 2 R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", 908 RFC 2373, July 1998. 910 3 S. Thompson, T. Narten, "IPv6 Stateless Address Autoconfig- 911 uration", RFC 2462 , December 1998. 913 4 T. Narten, R. Draves, "Privacy Extensions for Stateless Address 914 Autoconfiguration in IPv6", RFC 3041, January 2001. 916 5 D. Johnson, C. Perkins, "Mobility Support in IPv6", draft-ietf- 917 mobileip-ipv6-14.txt, July 2001. 919 6 S. Cheshire, B. Aboba, "Dynamic Configuration of IPv4 Link-local 920 Addresses", draft-ietf-zeroconf-ipv4-linklocal-04.txt, July 2001. 922 7 S. Bradner, "Key words for use in RFCs to Indicate Requirement 923 Levels", BCP 14, RFC 2119, March 1997. 925 8 R. Gilligan, S. Thomson, J. Bound, W. Stevens, "Basic Socket 926 Interface Extensions for IPv6", RFC 2553, March 1999. 928 9 S. Deering et. al, "IP Version 6 Scoped Address Architecture", 929 draft-ietf-ipngwg-scoping-arch-03.txt, November 2001. 931 10 Y. Rekhter et. al, "Address Allocation for Private Internets", 932 RFC 1918, February 1996. 934 11 F. Baker, Editor, "Requirements for IP Version 4 Routers", RFC 935 1812, June 1995. 937 12 B. Carpenter, K. Moore, "Connection of IPv6 Domains via IPv4 938 Clouds", RFC 3056, February 2001. 940 13 T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery for 941 IP Version 6", RFC 2461, December 1998. 943 14 B. Carpenter and C. Jung, "Transmission of IPv6 over IPv4 Domains 944 without Explicit Tunnels", RFC 2529, March 1999. 946 15 F. Templin et. al, "Intra-Site Automatic Tunnel Addressing 947 Protocol (ISATAP)", draft-ietf-ngtrans-isatap-03.txt, January 948 2002. 950 16 R. Gilligan and E. Nordmark, "Transition Mechanisms for IPv6 951 Hosts and Routers", RFC 1933, April 1996. 953 Acknowledgments 955 The author would like to acknowledge the contributions of the IPng 956 Working Group, particularly Marc Blanchet, Brian Carpenter, Matt 957 Crawford, Alain Durand, Steve Deering, Robert Elz, Jun-ichiro itojun 958 Hagino, Tony Hain, M.T. Hollinger, JINMEI Tatuya, Thomas Narten, 959 Erik Nordmark, Ken Powell, Markku Savela, Pekka Savola, Dave Thaler, 960 Mauro Tortonesi, Ole Troan, and Stig Venaas. 962 Author's Address 964 Richard Draves 965 Microsoft Research 966 One Microsoft Way 967 Redmond, WA 98052 968 Phone: +1 425 706 2268 969 Email: richdr@microsoft.com 971 Revision History 973 Changes from draft-ietf-ipngwg-default-addr-select-06 975 Added a table of contents. 977 Modified the longest-matching-prefix destination-address selection 978 rule, so that it only applies if the two destination addresses 979 belong to the same address family. 981 Various great clarifications from Thomas Narten. 983 Changes from draft-ietf-ipngwg-default-addr-select-05 985 Clarified the first destination-address selection rule, avoiding 986 unusable destination addresses. 988 Added a new destination-address selection rule, to prefer native 989 transport over transition mechanisms that use encapsulation. 991 Changes from draft-ietf-ipngwg-default-addr-select-04 993 Clarified candidate set formation for routers. 995 Added some explanatory discussion to the candidate set section. 997 Replaced usages of scope id with zone index. 999 Augmented the first destination-address selection rule, to avoid 1000 destination addresses for which the current next-hop neighbor is 1001 known to be unreachable. 1003 Changes from draft-ietf-ipngwg-default-addr-select-03 1005 Reversed the treatment of temporary addresses, so that unless an 1006 application specifies otherwise public addresses are preferred over 1007 temporary addresses. 1009 Added text clarifying our expectation that applications should 1010 iterate through the list of possible destination addresses until 1011 finding a working address. 1013 Removed references to getipnodebyname(). 1015 Changes from draft-ietf-ipngwg-default-addr-select-02 1017 Changed scope treatment of IPv4-compatible and 6to4 addresses, so 1018 they are always considered to be global. Removed mention of IPX 1019 addresses. 1021 Changed home address rules to favor addresses that are 1022 simultaneously home and care-of addresses, over addresses that are 1023 just home addresses or just care-of addresses. 1025 Combined SrcLabel & DstLabel in the policy table into a single Label 1026 attribute. 1028 Added mention of the invalidation counter technique in the 1029 implementation section. 1031 Changes from draft-ietf-ipngwg-default-addr-select-01 1033 Added Examples section, demonstrating default behavior and some 1034 policy table configuration scenarios. 1036 Removed many uses of MUST. Remaining uses concern the candidate set 1037 of source addresses and the source address selection rule that 1038 prefers source addresses of appropriate scope. 1040 Simplified the default policy table. Reordered the source address 1041 selection rules to reduce the influence of policy labels. Added more 1042 destination address selection rules. 1044 Added scoping of v4-compatible and 6to4 addresses based on the 1045 embedded IPv4 address. 1047 Changed references to anonymous addresses to use the new term, 1048 temporary addresses. 1050 Clarified that a user-level implementation of destination address 1051 ordering, which does not have knowledge of the outgoing interface 1052 for each destination, may use a looser definition of the candidate 1053 set. 1055 Clarified that an implementation should prevent an application or 1056 upper-layer from choosing a source address that is not in the 1057 candidate set and not prevent an application or upper-layer from 1058 choosing a source address that is in the candidate set. 1060 Miscellaneous editorial changes, including adding some missing 1061 references. 1063 Changes from draft-ietf-ipngwg-default-addr-select-00 1065 Changed the candidate set definition so that the strong host model 1066 is recommended but not required. Added a rule to source address 1067 selection to prefer addresses assigned to the outgoing interface. 1069 Simplified the destination address selection algorithm, by having it 1070 use source address selection as a subroutine. 1072 Added a rule to source address selection to handle anonymous/public 1073 addresses. 1075 Added a rule to source address selection to handle home/care-of 1076 addresses. 1078 Changed to allow destination address selection to sort both IPv6 and 1079 IPv4 addresses. Added entries in the default policy table for IPv4- 1080 mapped addresses. 1082 Changed default precedences, so v4-compatible addresses have lower 1083 precedence than 6to4 addresses. 1085 Changes from draft-draves-ipngwg-simple-srcaddr-01 1087 Added framework discussion. 1089 Added algorithm for destination address ordering. 1091 Added mechanism to allow the specification of administrative policy 1092 that can override the default behavior. 1094 Added section on routing interactions and TBD section on mobility 1095 interactions. 1097 Changed the candidate set definition for source address selection, 1098 so that only addresses assigned to the outgoing interface are 1099 allowed. 1101 Changed the loopback address treatment to link-local scope. 1103 Changes from draft-draves-ipngwg-simple-srcaddr-00 1105 Minor wording changes because DHCPv6 also supports "preferred" and 1106 "deprecated" addresses. 1108 Specified treatment of other format prefixes; now they are 1109 considered global scope, "preferred" addresses. 1111 Reiterated that anycast and multicast addresses are not allowed as 1112 source addresses. 1114 Recommended that source addresses be taken from the outgoing 1115 interface. Required this for multicast destinations. Added analogous 1116 requirements for link-local and site-local destinations. 1118 Specified treatment of the loopback address. 1120 Changed the second selection rule so that if both candidate source 1121 addresses have scope greater or equal than the destination address 1122 and only of them is preferred, the preferred address is chosen. 1124 Full Copyright Statement 1126 Copyright (C) The Internet Society (1999). All Rights Reserved. 1128 This document and translations of it may be copied and furnished to 1129 others, and derivative works that comment on or otherwise explain it 1130 or assist in its implementation may be prepared, copied, published 1131 and distributed, in whole or in part, without restriction of any 1132 kind, provided that the above copyright notice and this paragraph 1133 are included on all such copies and derivative works. However, this 1134 document itself may not be modified in any way, such as by removing 1135 the copyright notice or references to the Internet Society or other 1136 Internet organizations, except as needed for the purpose of 1137 developing Internet standards in which case the procedures for 1138 copyrights defined in the Internet Standards process must be 1139 followed, or as required to translate it into languages other than 1140 English. 1142 The limited permissions granted above are perpetual and will not be 1143 revoked by the Internet Society or its successors or assigns. 1145 This document and the information contained herein is provided on an 1146 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1147 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1148 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1149 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1150 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.