idnits 2.17.1 draft-ietf-multi6-l3shim-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1139. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1116. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1129. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'RFC 3484' is mentioned on line 260, but not defined ** Obsolete undefined reference: RFC 3484 (Obsoleted by RFC 6724) == Missing Reference: 'M6REFER' is mentioned on line 272, but not defined == Missing Reference: 'RFC2461' is mentioned on line 606, but not defined ** Obsolete undefined reference: RFC 2461 (Obsoleted by RFC 4861) == Missing Reference: 'RFC2462' is mentioned on line 613, but not defined ** Obsolete undefined reference: RFC 2462 (Obsoleted by RFC 4862) == Unused Reference: 'ADDR-ARCH' is defined on line 982, but no explicit reference was found in the text == Unused Reference: 'IPv6' is defined on line 985, but no explicit reference was found in the text == Unused Reference: 'RFC3041' is defined on line 1016, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-multi6-multihoming-threats-00 ** Downref: Normative reference to an Informational draft: draft-ietf-multi6-multihoming-threats (ref. 'M6THREATS') ** Obsolete normative reference: RFC 3513 (ref. 'ADDR-ARCH') (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 2461 (ref. 'IPv6') (Obsoleted by RFC 4861) -- No information found for draft-dt-multi6-functional-dec - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'M6FUNC' -- Possible downref: Normative reference to a draft: ref. 'HBA' -- No information found for draft-multi6dt-failure-detection - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'M6DET' == Outdated reference: A later version (-10) exists of draft-irtf-nsrg-report-09 == Outdated reference: A later version (-09) exists of draft-ietf-ipv6-unique-local-addr-08 == Outdated reference: A later version (-02) exists of draft-ietf-ipv6-ula-central-00 -- No information found for draft-crocker-mast-protocol - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 3041 (Obsoleted by RFC 4941) Summary: 14 errors (**), 0 flaws (~~), 14 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Erik Nordmark 3 Jan 10, 2005 Sun Microsystems 4 Marcelo Bagnulo 5 UC3M 7 Multihoming L3 Shim Approach 9 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 and any of which I become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet Draft expires July 10, 2005. 36 Abstract 38 This document specifies a particular approach to IPv6 multihoming. 39 The approach is based on using a multi6 shim placed between the IP 40 endpoint sublayer and the IP routing sublayer, and, at least 41 initially, using routable IP locators as the identifiers visible 42 above the shim layer. The approach does not introduce a "stack name" 43 type of identifier, instead it ensures that all upper layer protocols 44 can operate unmodified in a multihomed setting while still seeing a 45 stable IPv6 address. 47 This document does not specify the mechanism for authenticating and 48 authorizing the "rehoming" - this is specified in the HBA document. 50 Nor does it specify the messages used to establish multihoming state. 52 The document does not even specify the packet format used for the 53 data packets. Instead it discusses the issue of receive side 54 demultiplexing and the different tradeoffs. The resolution of this 55 issue will effect the packet format for the data packets. 57 Contents 59 1. Introduction............................................. 4 60 1.1. Non-Goals........................................... 4 61 1.2. Assumptions......................................... 5 63 2. Terminology.............................................. 5 64 2.1. Notational Conventions.............................. 6 66 3. Overview................................................. 6 68 4. Locators as Upper-layer Identifiers...................... 7 69 4.1. IP Multicast........................................ 8 70 4.2. Renumbering Implications............................ 8 72 5. Placement of the multi6 shim............................. 9 73 5.1. Shim Implications on Flow Label Usage............... 11 74 5.2. Shim Implications on ICMP errors.................... 11 75 5.3. Other Shim Protocol Implications.................... 12 76 5.4. MTU Implications.................................... 12 78 6. Deferred Context Establishment........................... 13 80 7. Assumptions about the DNS................................ 13 81 7.1. DNS and Centrally Assigned Unique-local Addresses... 13 83 8. Protocol Walkthrough..................................... 14 84 8.1. Initial Context Establishment....................... 14 85 8.2. Locator Change...................................... 15 86 8.3. Concurrent Context Establishment.................... 15 87 8.4. Handling Initial Locator Failures................... 16 89 9. Demultiplexing of data packets in multi6 communications.. 16 90 9.1. Approaches preventing the existence of ambiguities.. 17 91 9.1.1. Pre-agreed identifiers......................... 18 92 9.1.2. N-square addresses............................. 18 93 9.2. Providing additional information to the receiver.... 19 94 9.2.1. Flow-label..................................... 19 95 9.2.2. Extension Header............................... 21 96 9.3. Host-Pair Context................................... 21 98 10. IPSEC INTERACTIONS...................................... 22 100 11. OPEN ISSUES............................................. 22 102 12. ACKNOWLEDGMENTS......................................... 23 104 13. REFERENCES.............................................. 23 105 13.1. Normative References............................... 23 106 13.2. Informative References............................. 23 108 14. CHANGE LOG.............................................. 24 110 AUTHORS' ADDRESSES........................................... 25 112 1. Introduction 114 The goal of the IPv6 multihoming work is to allow a site to take 115 advantage of multiple attachments to the global Internet without 116 having a specific entry for the site visible in the global routing 117 table. Specifically, a solution should allow users to use multiple 118 attachments in parallel, or to switch between these attachment points 119 dynamically in the case of failures, without an impact on the upper 120 layer protocols. 122 The goals for this approach is to: 124 o Have no impact on upper layer protocols in general and on 125 transport protocols in particular. 127 o Address the security threats in [M6THREATS] through a separate 128 document [HBA] 130 o No extra roundtrip for setup; deferred setup. 132 o Take advantage of multiple locators/addresses for load spreading 133 so that different sets of communication to a host (e.g., different 134 connections) might use different locators of the host. 136 1.1. Non-Goals 138 The assumption is that the problem we are trying to solve is site 139 multihoming, with the ability to have the set of site locator 140 prefixes change over time due to site renumbering. Further, we 141 assume that such changes to the set of locator prefixes can be 142 relatively slow and managed; slow enough to allow updates to the DNS 143 to propagate. This proposal does not attempt to solve, perhaps 144 related, problems such as host multihoming or host mobility. 146 This proposal also does not try to provide an IP identifier. Even 147 though such a concept would be useful to ULPs and applications, 148 especially if the management burden for such a name space was zero 149 and there was an efficient yet secure mechanism to map from 150 identifiers to locators, such a name space isn't necessary (and 151 furthermore doesn't seem to help) to solve the multihoming problem. 153 1.2. Assumptions 155 This approach assumes that packets with arbitrary combinations of 156 source and destination locators will make it from end to end unless 157 there is some form of failure. Due to the interaction between 158 ingress filtering [RFC2827] and source address selection, this 159 assumption might not be true in IPv6 today. As a result there is a 160 need to work out a solution that doesn't make the ingress filtering 161 in ISPs drop more packets than needed. Some solutions to this have 162 been proposed in [INGRESS]. 164 2. Terminology 166 upper layer protocol (ULP) 167 - a protocol layer immediately above IP. Examples are 168 transport protocols such as TCP and UDP, control 169 protocols such as ICMP, routing protocols such as 170 OSPF, and internet or lower-layer protocols being 171 "tunneled" over (i.e., encapsulated in) IP such as 172 IPX, AppleTalk, or IP itself. 174 interface - a node's attachment to a link. 176 address - an IP layer name that contains both topological 177 significance and acts as a unique identifier for an 178 interface. 128 bits. 180 locator - an IP layer topological name for an interface or a 181 set of interfaces. 128 bits. The locators are 182 carried in the IP address fields as the packets 183 traverse the network. 185 identifier - an IP layer identifier for an IP layer endpoint 186 (stack name in [NSRG]). The transport endpoint is a 187 function of the transport protocol and would 188 typically include the IP identifier plus a port 189 number. NOTE: This proposal does not contain any IP 190 layer identifiers. 192 upper-layer identifier (ULID) 193 - an IP locator which has been selected for 194 communication with a peer to be used by the upper 195 layer protocol. 128 bits. This is used for 196 pseudo-header checksum computation and connection 197 identification in the ULP. Different sets of 198 communication to a host (e.g., different 199 connections) might use different ULIDs in order to 200 enable load spreading. 202 address field 203 - the source and destination address fields in the 204 IPv6 header. As IPv6 is currently specified this 205 fields carry "addresses". If identifiers and 206 locators are separated these fields will contain 207 locators. 209 FQDN - Fully Qualified Domain Name 211 Host-pair context 212 - the state that the multi6 shim maintains for a 213 particular peer. The peer is identified by one or 214 more ULIDs. 216 2.1. Notational Conventions 218 A, B, and C are hosts. X is a potentially malicious host. 220 FQDN(A) is the domain name for A. 222 Ls(A) is the locator set for A, which consists of the locators L1(A), 223 L2(A), ... Ln(A). 225 ULID(A) is an upper-layer ID for A. In this proposal, ULID(A) is 226 always one member of A's locator set. 228 3. Overview 230 This document specifies certain aspects of the approach, yet leaves 231 other aspects open. 233 The main points are about using locators as the ULIDs, and the exact 234 placement of the multi6 shim in the protocol stack. 236 The draft also discusses issues about receive side demultiplexing, 237 which affects the packet format for data packets. 239 The approach assumes that there are mechanisms (specified in other 240 drafts) which: 242 - can prevent redirection attacks [HBA] 244 - can prevent 3rd party DoS attacks [HBA, M6FUNC] 246 - can detect whether or not a peer supports the multi6 protocol 247 [M6FUNC, M6DET] 249 - can explore all the locator pairs to find a working pair when the 250 initial pair does not work [M6DET] 252 4. Locators as Upper-layer Identifiers 254 Central to this approach is to not introduce a new identifier name 255 space but instead use one of the locators as the upper-layer ID, 256 while allowing the locators used in the address fields to change over 257 time in response to failures of using the original locator. 259 This implies that the ULID selection is performed as today's default 260 address selection as specified in [RFC 3484]. Underneath, and 261 transparently, the multi6 shim selects working locator pairs with the 262 initial locator pair being the ULID pair. When communication fails 263 the shim can test and select alternate locators. A subsequent 264 section discusses the issues when the selected ULID is not initially 265 working hence there is a need to switch locators up front. 267 Using one of the locators as the ULID has certain benefits for 268 applications which have long-lived session state, or performs 269 callbacks or referrals, because both the FQDN and the 128-bit ULID 270 work as handles for the applications. However, using a single 128- 271 bit ULID doesn't provide seamless communication when that locator is 272 unreachable. See [M6REFER] for further discussion of the application 273 implications. 275 There has been some discussion of using non-routable locators, such 276 as unique-local addresses [ULA], as ULIDs in a multihoming solution. 277 While this document doesn't specify all aspects of this, it is 278 believed that the approach can be extended to handle such a case. 279 For example, the protocol already needs to handle ULIDs that are not 280 initially reachable. Thus the same mechanism can handle ULIDs that 281 are permanently unreachable from outside their site. The issue 282 becomes how to make the protocol perform well when the ULID is not 283 reachable, for instance, avoiding any timeout and retries in this 284 case. In addition one would need to understand how the ULAs would be 285 entered in the DNS to avoid a performance impact on existing, non- 286 multi6 aware, IPv6 hosts potentially trying to communicate to the 287 (unreachable) ULA. 288 4.1. IP Multicast 290 IP Multicast requires that the IP source address field contain a 291 topologically correct locator for interface that is used to send the 292 packet, since IP multicast routing uses both the source address and 293 the destination group to determine where to forward the packet. 294 (This isn't much different than the situation with widely implemented 295 ingress filtering [RFC2827] for unicast.) 297 While in theory it would be possible to apply the shim re-mapping of 298 the IP address fields between ULIDs and locators, the fact that all 299 the multicast receivers would need to know the mapping to perform, 300 makes such an approach difficult in practice. Thus it makes sense to 301 have multicast ULPs operate directly on locators and not use the 302 shim. This is quite a natural fit for protocols which use RTP 303 [RFC3550], since RTP already has an explicit identifier in the form 304 of the SSRC field in the RTP headers. Thus the actual IP address 305 fields are not important to the application. 306 4.2. Renumbering Implications 308 As stated above, this approach does not target to not make 309 communication survive renumbering. However, the fact that a ULID 310 might be used with a different locator over time open up the 311 possibility that communication between two ULIDs might continue to 312 work after one or both of those ULIDs are no longer reachable as 313 locators, for example due to a renumbering event. This opens up the 314 possibility that the ULID (or at least the prefix on which it is 315 based) is reassigned to another site while it is still being used 316 (with another locator) for existing communication. 318 Worst case we could end up with two separate hosts using the same 319 ULID while both of them are communicating with the same host. 321 This potential source for confusion can be avoided if we require that 322 any communication using a ULID must be terminated when the ULID 323 becomes invalid (due to the underlying prefix becoming invalid). 325 5. Placement of the multi6 shim 327 ----------------------- 328 | Transport Protocols | 329 ----------------------- 331 ------ ------- -------------- ------------- IP endpoint 332 | AH | | ESP | | Frag/reass | | Dest opts | sub-layer 333 ------ ------- -------------- ------------- 335 --------------------- 336 | multi6 shim layer | 337 --------------------- 339 ------ IP routing 340 | IP | sub-layer 341 ------ 343 Figure 1: Protocol stack 345 The proposal uses an multi6 shim layer between IP and the ULPs as 346 shown in figure 1, in order to provide ULP independence. 347 Conceptually the multi6 shim layer behaves as if it is associated 348 with an extension header, which would be ordered immediately after 349 any hop-by-hop options in the packet. However, the amount of data 350 that needs to be carried in an actual multi6 extension header is 351 close to zero, thus it might not be necessary to add bytes to each 352 packet. See section 9. 354 We refer to packets that at least conceptually have this extension 355 header, i.e., packets that should be processed by the multi6 shim on 356 the receiver, as "multi6 packets" (analogous to "ESP packets" or "TCP 357 packets"). 359 Layering AH and ESP above the multi6 shim means that IPsec can be 360 made to be unaware of locator changes the same way that transport 361 protocols can be unaware. Thus the IPsec security associations 362 remain stable even though the locators are changing. Layering the 363 fragmentation header above the multi6 shim makes reassembly robust in 364 the case that there is broken multi-path routing which results in 365 using different paths, hence potentially different source locators, 366 for different fragments. Thus, effectively the multi6 shim layer is 367 placed between the IP endpoint sublayer, which handles fragmentation, 368 reassembly, and IPsec, and the IP routing sublayer, which on a host 369 selects which default router to use etc. 371 Applications and upper layer protocols use ULIDs which the multi6 372 layer will map to/from different locators. The multi6 layer 373 maintains state, called host-pair context, per ULID pairs (that is, 374 applies to all ULP connections between the ULID pair) in order to 375 perform this mapping. The mapping is performed consistently at the 376 sender and the receiver, thus from the perspective of the upper layer 377 protocols, packets appear to be sent using ULIDs from end to end, 378 even though the packets travel through the network containing 379 locators in the IP address fields, and even though those locators 380 might be changed by the transmitting multi6 shim layer. 382 The context state in this approach is maintained per remote ULID i.e. 383 approximately per peer host, and not at any finer granularity. In 384 particular, it is independent of the ULPs and any ULP connections. 385 When two hosts are communicating with each other using multiple 386 different ULID pairs, there is an option to "merge" the context state 387 for the two (or more) ULID pairs. Doing so would mean that the 388 protocol to test and select working locators after a failure can be 389 shared across the multiple ULID pairs between the two hosts. 390 However, if it will be uncommon that two hosts communicate using 391 multiple ULID pairs, the added complexity of merging the state might 392 not be worth while. Thus this is for further study. 394 ---------------------------- ---------------------------- 395 | Sender A | | Receiver B | 396 | | | | 397 | ULP | | ULP | 398 | | src ULID(A)=L1(A) | | ^ | 399 | | dst ULID(B)=L1(B) | | | src ULID(A)=L1(A) | 400 | v | | | dst ULID(B)=L1(B) | 401 | multi6 shim | | multi6 shim | 402 | | src L2(A) | | ^ | 403 | | dst L3(B) | | | src L2(A) | 404 | v | | | dst L3(B) | 405 | IP | | IP | 406 ---------------------------- ---------------------------- 407 | ^ 408 ------- cloud with some routers ------- 410 Figure 2: Mapping with changed locators. 412 The result of this consistent mapping is that there is no impact on 413 the ULPs. In particular, there is no impact on pseudo-header 414 checksums and connection identification. 416 Conceptually one could view this approach as if both ULIDs and 417 locators are being present in every packet, but with a header 418 compression mechanism applied that removes the need for the ULIDs 419 once the state has been established. In order for the receiver to 420 recreate a packet with the correct ULIDs there might be a need to 421 include some "compression tag" in the data packets. This would serve 422 to indicate the correct context to use for decompression when the 423 locator pair in the packet is insufficient to uniquely identify the 424 context. 426 5.1. Shim Implications on Flow Label Usage 428 The use of a shim has implications on a class of protocols which have 429 host as well as router functions. This section discusses the 430 implications for the flow label field, which might be used for QoS 431 handling where the hosts set the flow label and initiate some flow 432 signaling protocols, and the routers participate in the flow 433 signaling protocol and as a result perform different action on 434 packets based on the flow (which is identified by the IP address 435 fields and the flow label field). 437 The shim will leave the flow label unmodified. This means that the 438 {Flow Label, Source ULID, Dest ULID} that the upper-layer protocol 439 sends will appear on the wire as the set of {flow label, source 440 location, destination locator) for the different locators. 442 This does have implications for protocols which do explicit signaling 443 to create flow state; such protocols would somehow need to be made 444 multi6 aware so that they can perform the signaling for all the 445 tuples that are used on the wire. Note that this need to modify such 446 signaling protocols would apply even if the flows were identified 447 without the use of the flow label field, due to the different 448 locators which might be used. 450 5.2. Shim Implications on ICMP errors 452 Another protocol which requires consistency between the upper layer 453 protocols on the hosts and the routers are the ICMP errors. The 454 routers (and in some cases the peer host) will generate ICMP errors 455 based on the locators contained in the IP address fields, but when 456 the host implementation delivers a notification to the ULP that an 457 ICMP error was received, the ULP instance needs to be discovered 458 based on the ULIDs. This means that for ICMP error reception the 459 host needs to be able to take the initial part of a multi6 packet 460 (the part returned in an ICMP error) and do the inverse translation 461 of the IP address fields that it did when sending the packet, and 462 then deliver the notification to the ULP. 464 Being able to demultiplex based on the information returned in an 465 ICMP error presumably has some implications on the packet format and 466 mechanism for receive-side demultiplexing. 468 5.3. Other Shim Protocol Implications 470 As stated above, there might be other protocols in addition to flow 471 management and ICMP errors that assume that the ULPs at the hosts and 472 the IP address fields seen by the routers are the same. 474 Any such protocol is potentially impacted by the introduction of the 475 multihoming shim. 477 5.4. MTU Implications 479 Depending on how demultiplexing is handled at the receiver (see 480 subsequent sections) there may or may not be a need for the shim to 481 add an extension header to the packets. In some cases such an 482 extension header would only need to be added to some and not all data 483 packets. 485 This has implications on the MTU that is available to the upper layer 486 protocols hence will require some extra handling in the host 487 implementation. At some level this is similar to the MTU 488 implementations of IPsec, in that the IP layer would add bytes to 489 some ULP packets and not others, but in the case of IPsec one would 490 expect all or no packets in a particular ULP connection to be 491 affected, whereas in multi6 one some packets, such as those sent 492 after a locator failure, would be subject to a reduction in the 493 available MTU. 495 While the effects of these are local to the host implementation they 496 are likely to be a bit complicated. There needs to be a mechanism so 497 that the ULP can be notified when the available MTU changes due to an 498 extension header either being added, or no longer being added. Also, 499 ICMPv6 packet to big errors need to result in a notification to the 500 ULP which takes into account whether or not an extension header is 501 being added. Finally, certain ULPs such as UDP might need to rely on 502 IP fragmentation down to the available MTU, while other ULPs such as 503 TCP will adapt their segment size to the available MTU. 505 6. Deferred Context Establishment 507 The protocol will use some context establishment exchange in order to 508 setup multi6 state at the two endpoints. Similar to MAST [MAST] this 509 initial exchange can be performed asynchronously with data packets 510 flowing between the two hosts; until context state has been 511 established at both ends the packets would flow just as for 512 unmodified IPv6 hosts i.e., without the ability for the hosts to 513 switch locators. This approach allows the hosts to have some local 514 policy on when to attempt to establish multi6 state with a peer; 515 perhaps based on the transport protocols and port numbers, or perhaps 516 based on the number of packets that have flowed to/from the peer. 518 Once the initial exchange has completed there is host-pair context 519 state at both hosts, and both ends know a set of locators for the 520 peer that are acceptable as the source in received packets. This 521 will trigger some verification of the set of locators, which is the 522 subject of the security scheme. 524 7. Assumptions about the DNS 526 This approach assumes that hosts in multihomed sites have multiple 527 AAAA records under a single name, in order to allow initial 528 communication to try all the locators. For multi6 capable hosts, the 529 content of those records are the locators (which also serve as 530 ULIDs). 532 However, the approach does not assume that all the AAAA records for a 533 given name refer to the same host. Instead the context establishment 534 allows each host to pass its locators to the peer. This set could be 535 either smaller or larger (or neither) than the AAAA record set. 537 The approach makes no assumption about the reverse tree since the 538 approach does not use it. However, applications might rely on the 539 reverse tree whether multi6 is used or not. 541 7.1. DNS and Centrally Assigned Unique-local Addresses 543 Earlier we've mentioned that the protocol might provide the basic 544 mechanism to use Unique-local addresses as ULIDs. 546 In the cases where hosts have been assigned centrally assigned ULAs 547 [ULA-CENTRAL], one can potentially take advantage of this to provide 548 better support for applications. With centrally assigned ULAs it is 549 possible to register them in the reverse DNS tree. As a result, one 550 could use the DNS not only for applications which care about reverse 551 and forward tree being consistent, but also to find the full set of 552 locators from the ULID. 554 8. Protocol Walkthrough 555 8.1. Initial Context Establishment 557 Here is the sequence of events when A starts talking to B: 559 1. A looks up FQDN(B) in the DNS which returns a locator set which 560 includes some locators for B. (The set could include locators 561 for other hosts since e.g., www.example.com might include AAAA 562 records for multiple hosts.) The application would typically 563 try to connect using the first locator in the set i.e., ULID(B) 564 = L1(B). The application is prepared to try the other locators 565 should the first one fail. 567 2. The ULP creates "connection" state between ULID(A)=L1(A) and 568 ULID(B) and sends the first packet down to the IP/multi6 shim 569 layer on A. L1(A) was picked using regular source address 570 selection mechanisms. 572 3. The packet passes through the multi6 layer, which has no state 573 for ULID(B). A local policy will be used to determine when, if 574 at all, to attempt to setup multi6 state with the peer. Until 575 this state triggers packets pass back and forth between A and B 576 as they do in unmodified IPv6 today. 578 When the policy is triggered, which could be on either A or B, 579 an initial context establishment takes place. This exchange 580 might fail should the peer not support the multi6 protocol. If 581 it succeeds it results in both ends receiving the locator sets 582 from their respective peer, and the security mechanism provides 583 some way to verify these sets. 585 At this point in time it is possible for the hosts to change to 586 a different locator in the set. But until they have exchanged 587 the locator sets, and probably until they rehome the context to 588 use different locators, they continue sending and receiving IPv6 589 packets as before. 591 As long as both hosts have been informed of the state at the 592 peer i.e., know the locators of the peer and know that the peer 593 has received its locators, each host can make an independent 594 decision when it sees a need to change either the source or 595 destination locator in the packets it is sending. Thus the 596 approach does not require coordinating the actual locator 597 changes between the peers. 599 8.2. Locator Change 601 When a host detects that communication is no longer working it can 602 try to switch to a different locator pair. A host might suspect that 603 communication isn't working due to 605 - lack of positive advise from the ULP (akin to the NUD advise in 606 [RFC2461] 608 - negative advise from the ULP 610 - failure of some explicit multi6 "heartbeat" messages 612 - local indications such as the local locator becoming invalid 613 [RFC2462] or the interface being disabled 615 Given that each host knows the locator set for its peer, the host can 616 just switch to using a different locator pair. It might make sense 617 for the host to test the locator pair before using it for ULP 618 traffic, both to verify that the locator pair is working and to 619 verify that it is indeed the peer that is present at the other end; 620 the latter to prevent 3rd party DoS attacks. Such testing needs to 621 complete before using the locator as a destination in order to 622 prevent 3rd party DoS attacks [M6THREATS]. 624 8.3. Concurrent Context Establishment 626 Should both A and B attempt to contact each other at about the same 627 time using the same ULIDs for each other, the context establishment 628 should create a single host-pair context. The NOID draft [NOID] 629 contains a proof-of-concept that a 4-way context establishment 630 exchange can ensure that a single context is created in this case. 632 However, if different ULIDs are used this would result in two 633 completely independent contexts between the two hosts following the 634 basic content establishment above; the context is per ULID pair. As 635 noted above, in this case it might be desirable to "merge" i.e., 636 share certain information, such as the reachability of different 637 locator pairs, across the different ULID pairs that are between the 638 same pair of hosts. 640 8.4. Handling Initial Locator Failures 642 Should not all locators be working when the communication is 643 initiated some extra complexity arises, because the ULP has already 644 been told which ULIDs to use. If the locators that were selected to 645 be ULIDs are not working and the multi6 shim does not know of 646 alternate locators, it has no other choice than to have the 647 application try a different ULID. 649 Thus the simplest approach is to always punt initial locator failures 650 up the stack to the application. However, this might imply 651 significant delays while transport protocol times out. 653 It is possible to optimize this case when the multi6 shim already has 654 alternate locators for the peer. This might be the case when the two 655 hosts have already communicated, and it might be possible to have the 656 DNS resolver library provide alternate locators to the shim in the 657 speculation that they might be useful. Such an optimization must not 658 assume that the AAAA records refer to the same host, since it isn't 659 uncommon that a FQDN have multiple AAAA records for the same 660 *service* but for different hosts. For instance, the protocol would 661 need to verify with the peer that the ULID in question is in fact 662 assigned to the peer in this case. Potentially the trust level for 663 the different locators retrieved from the DNS in this case, as 664 opposed to retrieving the ULIDs from the DNS and the locators from 665 the peer itself using the multihoming protocol, might be different. 666 Note however, that this is an optimization and is not required for 667 the protocol to work. 669 Should the multi6 shim know alternate locators for the peer, it needs 670 to perform the multi6 protocol before upper layer protocol packets 671 are exchanged. This means that the context establishment can not be 672 deferred, and that there is a rehoming event, with the necessary 673 security checks, before the first ULP packets can be successfully 674 exchanged. 676 9. Demultiplexing of data packets in multi6 communications 678 The mechanisms for preserving established communications through 679 outages that reside in the M6 shim layer manage the multiple 680 addresses available in the multihomed node so that a reachable 681 address is used in the communication. Since reachability may vary 682 during the communication lifetime, different addresses may have to be 683 used in order to keep packets flowing. However, the addresses 684 presented by the M6 shim layer to the upper layer protocols must 685 remain constant through the locator changes, so that received packets 686 are recognized by the upper layer protocols as belonging to the 687 established communication. In other words, in order to preserve 688 established communications through outages, the M6 shim layer will 689 use different locators for exchanging packets while presenting the 690 same identifiers for the upper layer protocols. This means that upon 691 the reception of an incoming packet with a pair of locators, the M6 692 shim layer will need to translate the received locators to the 693 identifiers that are being used by the upper layer protocols in the 694 particular communication. This operation is called demultiplexing. 696 For example, if a host has address A1 and A2 and starts communicating 697 with a peer with addresses B1 and B2, then some communication 698 (connections) might use the pair as upper-layer identifiers 699 and others might use e.g., . Initially there are no failures 700 so these address pairs are used as locators i.e. in the IP address 701 fields in the packets on the wire. But when there is a failure the 702 multi6 shim on A might decide to send packets that used as 703 upper-layer identifiers using as the locators. In this case 704 B needs to be able to rewrite the IP address field for some packets 705 and not others, but the packets all have the same locator pair. 707 Either we must prevent this from happening, or provide some 708 additional information to B so that it can tell which packets need to 709 have the IP address fields rewritten. 711 In this section, we will analyze different approaches to perform the 712 demultiplexing operation. The possible approaches can be classified 713 into two categories: First, the approaches that prevent the existence 714 of ambiguities on the demultiplexing operation i.e. each received 715 locator corresponds to one and only one ULP identifier. Second, the 716 approaches that use a context tag to provide additional information 717 to the receiver that indicates the identifiers that correspond to the 718 locators contained in the packets. 720 Note that the sender also needs to be able to demultiplex ICMP errors 721 as noted in Section 5.2, however the analysis below does not take 722 that added constraint into account. 724 9.1. Approaches preventing the existence of ambiguities 726 One could think this problem can be avoided if the host never used 727 the same locators for different ULIDs when communicating with the 728 same peer host. However, the host can't tell a priori whether two 729 peers share an IP stack. For instance, if A connects to www.foo.com 730 with AAAA=B1 and www.bar.com with AAAA=B2 it can't tell whether B1 or 731 B2 are assigned to the same IP stack or not until it communicates 732 with B1 and B2 and retrieves there complete locator sets. (And even 733 this might not suffice, since the peer might want to preserve the 734 illusion of being two different hosts by returning B3 as an 735 alternative locator for B1 and B4 as an alternate for B2.) 737 9.1.1. Pre-agreed identifiers 739 The simplest approach of this type is to designate one of the 740 available addresses as the identifier to be used for all the 741 communications while the remaining addresses will only be used as 742 locators. This means that the upper layer protocols will only be 743 aware of a single address, the one used as identifier, and all the 744 remaining addresses that are used as locators will remain invisible 745 to them. Consequently, only the address that is being used as 746 identifier can be returned by the resolver to the applications. The 747 addresses used as locators cannot be returned to the applications by 748 the resolver. So, if no additional information about the role of the 749 addresses is placed in the DNS, only the identifier-address can be 750 published in the DNS. This configuration has reduced fault tolerance 751 capabilities during the initial contact, since the initiator will 752 have only one address available to reach the receiver. If the 753 identifier address placed in the DNS is not reachable, the 754 communication will fail. It would be possible to overcome this 755 limitation by defining a new DNS record for storing information about 756 address that can be only used as locators. If such record is 757 defined, the initiator can use an alternative locator, even for 758 initial contact, while still presenting the address designated as 759 identifier to the upper layer protocols. However, this approach 760 requires support from the initiator node, implying that only upgraded 761 nodes will obtain improved fault tolerance while legacy nodes that 762 don't support the new DNS record will still obtain reduced fault 763 tolerance capabilities. 765 9.1.2. N-square addresses 767 In order to overcome the limitations presented by the previous 768 scheme, it is possible to create additional addresses that have a 769 pre-determined role. In this approach, each multihomed node that has 770 n prefixes available, will create n^2 addresses, or in other words, 771 the node will have n sets of n addresses each. Each set will contain 772 one address per prefix. So, in each set, one address will be 773 designated as identifier while the remaining addresses will be 774 designated as locators. The addresses designated as identifiers will 775 have different prefixes in the different sets. The result is that 776 there will be n addresses designated as identifiers, one per 777 available prefix, and each identifier-address will have an associated 778 set of n-1 addresses that can only be used as locators. The 779 addresses designated as identifiers will be published in the DNS 780 while the addresses used as locators must not be AAAA records in the 781 DNS to prevent them from ever being used as ULIDs. The applications 782 will only have knowledge of the first ones, and only the M6 shim 783 layer will deal with locators. The resulting configuration has full 784 fault tolerance capabilities since n addresses (one per prefix) will 785 be published in the DNS, allowing the usage of different addresses to 786 make the initial contact. 788 Even though the destination address field rewrite can be inferred 789 from the destination locator in both of the above approaches, there 790 is still a need to maintain multi6 state at the receiver in order for 791 the receiver to tell how and whether to rewrite the source address 792 field. 794 9.2. Providing additional information to the receiver 796 When two nodes establish a multi6 enabled communication, a context is 797 created at the M6 shim layers of each node. The context stores 798 information about the addresses that are used as identifiers for the 799 upper layer protocols and also about the locator set available for 800 each node. In this approach, data packets carry a context tag that 801 allows the receiver determine which is the context that has to be 802 used to perform the demultiplexing operation. There are several ways 803 to carry the context tag within the data packets. In this section we 804 will explore the following options: the Flow Label, and an Extension 805 Header. 807 9.2.1. Flow-label 809 A possible approach is to carry the context tag in the Flow Label 810 field of the IPv6 header. This means that when a multi6 context is 811 established, a Flow Label value is associated with this context (and 812 perhaps a separate flow label for each direction). 814 The simplest approach that does this is to have the triple identify the context at the 816 receiver. 818 The sender and receiver needs to agree to allocate the flow labels so 819 that each context between a pair of IP stacks receives a different 820 flow label. While this might seem simple at first sight, the 821 possibilities that different ULIDs refer to the same IP stack, and 822 even that different FQDNs refer to the same IP stack, severely 823 constrains how flow labels can be allocated. For instance, when 824 communication is initiated from a host X to both foo.example (with 825 ULIDs A and B) and bar.example (with ULIDs C and D), then host X 826 might think it is communicating to two different IP stacks, when in 827 fact they might be the same IP stack. Later when the locator sets 828 are updated, for instances, after some failure, it might be told that 829 ULID A has locators A, B, C, and D. Hence the two communications 830 would need to have separate flow labels for the packets sent from X. 832 A protocol can handle this either by having X (in this example) 833 allocate the flow label for the packets it is sending, or having the 834 intended receiver allocate them. In the former case, X would need to 835 allocate different flow labels for the different ULID pairs, since it 836 doesn't know which peers are the same IP stack or not. In the latter 837 case, the intended receiver would pick a flow label which is unique 838 i.e., it can disambiguate the two contexts in this case. This 839 implies that the flow label will not be assigned until the 840 multihoming protocol has established the context state. 842 An added limitation imposed by this approach is that all the 843 potential source and destination locators have to be known beforehand 844 by the receiver in order to be recognized. This means that before 845 sending packets with a new locator, the sender has to inform the 846 receiver about the new locator, while for other approaches it is 847 probably possible to start sending packets using a new locator and 848 the same context tag in parallel with carrying information about the 849 new locator to the peer, if the context tag would be sufficient by 850 itself to identify the context i.e., the source locator isn't used to 851 identify the context. 853 Note that we do not yet understand how beneficial it would be to be 854 able to accept packets from unknown source locators (the rules for 855 packet injection can probably be more relaxed than for where packets 856 are sent, for instance if the context tag matches). Requiring a 857 match on would make 858 this impossible. Instead the locator change signaling would need to 859 be acknowledged before the peer can start sending using a new source 860 locator. 862 An attempt to remove the above limitation would be to try to have the 863 receiver only identify the context based on the flow label field, 864 i.e., without taking the locators into account in the lookup. This 865 requires constraining flow label allocation for the hosts that 866 implement multi6 so that for multi6 packets the receiver wouldn't 867 have to compare the locators but only use the flow label. Due to the 868 deferred multi6 capability discovery this would have to apply to all 869 flow label assignments on a host which implements multi6. 871 It also requires carrying some additional information in the packet 872 to identify whether the Flow Label field is actually being used as a 873 context tag or not. In other words, additional information is needed 874 to identify multi6 packets from regular IPv6 packets. This is 875 because, the same Flow Label value that is being used as context tag 876 in multi6 enabled communication can be used for other purposes by a 877 non-multi6 enabled host, resulting in two communications using the 878 same Flow Label value. The result of this situation would be that 879 packets of the non-multi6 enabled communication would be 880 demultiplexed using the context associated to the Flow Label value 881 carried in the packets. A possible approach to solve this issue it 882 to use an additional bit to identify data packets that belong to 883 multi6 capable communications and that have to be demultiplexed using 884 the Flow Label value. However, there are no obvious choices for that 885 bit, since all bits of the IPv6 header are currently in use. A 886 possibility would be to use new Next Header values to indicate that 887 the packet belongs to a multi6 enabled communication and that the 888 Flow Label carries context information as proposed in [NOID]. 890 9.2.2. Extension Header 892 Another approach is to define a new Extension Header to carry the 893 context tag. This context tag is agreed between the involved parties 894 during the multi6 protocol initial negotiation. Following data 895 packets will be demultiplexed using the tag carried in the Extension 896 Header. This seems a clean approach since it does not overload 897 existing fields. However, it introduces additional overhead in the 898 packet due to the additional header. The additional overhead 899 introduced is 8 octets. However, it should be noted that the context 900 tag is only required when an address other than the one used as 901 identifier for upper layer protocols is contained in the packet. 902 Packets carrying the addresses that have to be used as identifier for 903 the upper layer protocols do not require a context tag, since the 904 address contained in the packets is the address presented to the 905 upper layers. This approach would reduce the overhead. On the other 906 hand, this approach would cause changes in the available MTU, since 907 packets that include the Extension Header will have an MTU 8 octets 908 shorter. 910 9.3. Host-Pair Context 912 The host-pair context is established on each end of the communication 913 when one of the endpoints performs the multi6 signaling (the 4-way 914 handshake referred to in [M6FUNC]). 916 This context is accessed differently in the transmit and receive 917 paths. In the transmit path when the ULP passes down a packet the 918 key to the context state is the tuple ; this 919 key must identify at most one state record. In the receive path the 920 context must be found based on what is in the packet, be it just the 921 locators, or the locators plus some additional "context tag" as 922 discussed above, or just a "context tag". 924 10. IPSEC INTERACTIONS 926 As specified, all of ESP, AH, and key management is layered above the 927 multi6 layer. Thus they benefit from the stable ULIDs provided above 928 the multi6 layer. This means the IPsec security associations are 929 unaffected by switching locators. 931 The alternative would be to layer multi6 above IPsec, but that 932 doesn't seem to provide any benefits and it would add the need to 933 create different IPsec SAs when the locators change due to rehoming. 935 A result of layering multi6 above IPsec is that the multi6 protocol 936 can potentially be used to redirect IPsec protected traffic as a 937 selective DoS mechanism. If we somehow could require IPsec for the 938 multi6 protocol packets when the ULP packets between the same hosts 939 use IPsec, then we could prevent such attacks. 941 However, due to the richness in IPsec policy, this would be a bit 942 tricky. If only some protocols or port numbers/selectors are to be 943 protected by IPsec per a host's IPsec policy, then how would one 944 determine whether multi6 traffic needs to be protected? Should one 945 take the conservative approach that if any packets between the 946 hosts/ULIDs need to be protected, then the multi6 traffic should also 947 be protected? 949 For this to be useful both communicating hosts would need to make the 950 same policy decisions, so if we are to take this path there would 951 need to some standardization in this area. 953 11. OPEN ISSUES 955 Receive side demultiplexing issue as described above. 957 Is it possible to facilitate transition to multi6 using some "multi6 958 proxy" at site boundaries until all important hosts in a site have 959 been upgraded to support multi6? Would would be the properties of 960 such a proxy? Would it place any additional requirements on the 961 protocol itself? 963 12. ACKNOWLEDGMENTS 965 This document was originally produced of a MULTI6 design team 966 consisting of (in alphabetical order): Jari Arkko, Iljitsch van 967 Beijnum, Marcelo Bagnulo Braun, Geoff Huston, Erik Nordmark, Margaret 968 Wasserman, and Jukka Ylitalo. 970 The idea to use a set of locators and not inventing a new identifier 971 name space, as well as using the DNS for verification of the 972 locators, was first brought up by Tony Li. 974 13. REFERENCES 976 13.1. Normative References 978 [M6THREATS] Nordmark, E., and T. Li, "Threats relating to IPv6 979 multihoming solutions", draft-ietf-multi6-multihoming- 980 threats-00.txt, July 2004. 982 [ADDR-ARCH] S. Deering, R. Hinden, Editors, "IP Version 6 983 Addressing Architecture", RFC 3513, April 2003. 985 [IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol, Version 986 6 (IPv6) Specification", RFC 2461. 988 [M6FUNC] Functional decomposition of the M6 protocol, draft-dt- 989 multi6-functional-dec-00.txt 991 [HBA] Hash Based Addresses (HBA), draft-bagnulo-multi6dt-hba-00.txt 993 [M6DET] Jari Arkko, Failure Detection and Locator Selection in 994 Multi6, draft-multi6dt-failure-detection-00.txt 996 13.2. Informative References 998 [NSRG] Lear, E., and R. Droms, "What's In A Name: Thoughts from the 999 NSRG", draft-irtf-nsrg-report-09.txt (work in progress), 1000 March 2003. 1002 [ULA] R. Hinden, and B. Haberman, Unique Local IPv6 Unicast 1003 Addresses, draft-ietf-ipv6-unique-local-addr-08.txt 1005 [ULA-CENTRAL] R. Hinden, and B. Haberman, Centrally Assigned Unique 1006 Local IPv6 Unicast Addresses, draft-ietf-ipv6-ula-central- 1007 00.txt 1009 [NOID] Erik Nordmark, "Multihoming without IP Identifiers", Oct 27, 1010 2003, 1012 [MAST] D. Crocker, "MULTIPLE ADDRESS SERVICE FOR TRANSPORT (MAST): 1013 AN EXTENDED PROPOSAL", draft-crocker-mast-protocol-01.txt, 1014 October, 2003. 1016 [RFC3041] T. Narten, R. Draves, "Privacy Extensions for Stateless 1017 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 1019 [RFC2827] Ferguson P., and D. Senie, "Network Ingress Filtering: 1020 Defeating Denial of Service Attacks which employ IP Source 1021 Address Spoofing", RFC 2827, May 2000. 1023 [RFC3550] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, 1024 "RTP: A Transport Protocol for Real-Time Applications", 1025 July 2003, RFC 3550. 1027 [INGRESS] C. Huitema, R. Draves, and M. Bagnulo, "Ingress filtering 1028 compatibility for IPv6 multihomed sites", Oct 2004, 1029 1031 14. CHANGE LOG 1033 Changes since draft-nordmark-multi6dt-shim-00.txt: 1035 o Added assumption that something else handles the interaction between 1036 ingress filtering and source address selection. 1038 o Clarified things with respect to using ULAs in general, and added 1039 separate text about centrally assigned ULAs. 1041 o Added more text about MTU dropping implications and ICMP too big re- 1042 mapping 1044 o Added text specifying how the shim handles the flow label field, and 1045 the impact on flow setup protocols. 1047 o Added text about the need for the sender to handle ICMP errors 1049 o Added text that there might be other protocols than flow setup 1050 protocols and ICMP errors that might be impacted by the shim. 1052 o Added text about IP multicast in a new section. 1054 o Added clarification in section 8.4 about AAAA records being for a 1055 service and not a host needing some care. 1057 o Added a clarification in section 8.4 that learning the different 1058 locators during initial communication from the DNS potentially has 1059 different trust issues than learning them from the peer. 1061 o Clarified the two models of flow label usage for demultiplexing 1063 o In section 5 clarified that state maintenance is not per ULP 1064 connection. 1066 o In section 5 clarified merging option. 1068 o Clarified in section 9.1 why it isn't sufficient to avoid using the 1069 same locators for different ULIDs for the same peer host. 1071 o Clarified in section 9.1.1/9.1.2 that there is multi6 state at the 1072 receiver to tell how/whether to rewrite the source address field. 1074 o Clarified the aspect of section 9.2.1 which talks about not being 1075 able to use a new locator until the peer has been told of the new 1076 locator. 1078 o Added text about the implications of renumbering and reassignment. 1080 o Clarified section on flow labels to first talk about the simple case 1081 of using and its 1082 complexities, and then about the potential to just use the flow label 1083 by itself to identify the context. 1085 AUTHORS' ADDRESSES 1087 Erik Nordmark 1088 Sun Microsystems, Inc. 1089 17 Network Circle 1090 Mountain View, CA 1091 USA 1093 phone: +1 650 786 2921 1094 fax: +1 650 786 5896 1095 email: erik.nordmark@sun.com 1097 Marcelo Bagnulo 1098 Universidad Carlos III de Madrid 1099 Av. Universidad 30 1100 Leganes, Madrid 28911 1101 SPAIN 1103 Phone: 34 91 6249500 1104 EMail: marcelo@it.uc3m.es 1105 URI: http://www.it.uc3m.es 1107 Intellectual Property Statement 1109 The IETF takes no position regarding the validity or scope of any 1110 Intellectual Property Rights or other rights that might be claimed to 1111 pertain to the implementation or use of the technology described in 1112 this document or the extent to which any license under such rights 1113 might or might not be available; nor does it represent that it has 1114 made any independent effort to identify any such rights. Information 1115 on the procedures with respect to rights in RFC documents can be 1116 found in BCP 78 and BCP 79. 1118 Copies of IPR disclosures made to the IETF Secretariat and any 1119 assurances of licenses to be made available, or the result of an 1120 attempt made to obtain a general license or permission for the use of 1121 such proprietary rights by implementors or users of this 1122 specification can be obtained from the IETF on-line IPR repository at 1123 http://www.ietf.org/ipr. 1125 The IETF invites any interested party to bring to its attention any 1126 copyrights, patents or patent applications, or other proprietary 1127 rights that may cover technology that may be required to implement 1128 this standard. Please address the information to the IETF at 1129 ietf-ipr@ietf.org. 1131 Disclaimer of Validity 1133 This document and the information contained herein are provided on an 1134 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1135 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1136 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1137 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1138 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1139 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1141 Copyright Statement 1143 Copyright (C) The Internet Society (2005). This document is subject 1144 to the rights, licenses and restrictions contained in BCP 78, and 1145 except as set forth therein, the authors retain all their rights. 1147 Acknowledgment 1149 Funding for the RFC Editor function is currently provided by the 1150 Internet Society.