idnits 2.17.1 draft-ietf-dna-tentative-01.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 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 581. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 592. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 599. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 605. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (July 14, 2008) is 5763 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Daley 3 Internet-Draft 4 Intended status: Standards Track E. Nordmark 5 Expires: January 15, 2009 Sun Microsystems 6 N. Moore 7 July 14, 2008 9 Tentative Options for Link-Layer Addresses in IPv6 Neighbour Discovery 10 draft-ietf-dna-tentative-01.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 15, 2009. 37 Abstract 39 The proposed IPv6 Duplicate Address Detection (DAD) Optimization 40 "Optimistic DAD" defines a set of recoverable procedures which allow 41 a node to make use of an address before DAD completes. Essentially, 42 Optimistic DAD forbids usage of certain Neighbour Discovery options 43 which could pollute active neighbour cache entries, while an address 44 is tentative. 46 This document defines a new option and procedures to replace cache 47 polluting options, in a way which is useful to tentative nodes. 48 These procedures are designed to be to backward compatible with 49 existing devices which support IPv6 Neighbour Discovery. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Tentative Option format . . . . . . . . . . . . . . . . . 3 56 2.2. Tentative Option semantics . . . . . . . . . . . . . . . . 4 57 3. Sending solicitations containing Tentative Options . . . . . . 4 58 3.1. Sending Neighbour Solicitations with Tentative Options . . 5 59 3.2. Sending Router Solicitations with Tentative Options . . . 5 60 4. Receiving Tentative Options . . . . . . . . . . . . . . . . . 5 61 4.1. Handling Tentative Options . . . . . . . . . . . . . . . . 6 62 4.2. Receiving Neighbour Solicitations containing Tentative 63 Options . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 4.3. Receiving a Router Solicitation containing a Tentative 65 Option . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 71 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 72 Appendix A. Constraints imposed by IPv6 Neighbour Discovery . . . 10 73 A.1. Constraints on Neighbour Solicitations . . . . . . . . . . 10 74 A.2. Constraints on Router Solicitations . . . . . . . . . . . 10 75 Appendix B. Interactions with legacy nodes . . . . . . . . . . . 11 76 B.1. Legacy Neighbour Solicitation processing . . . . . . . . . 11 77 B.2. Legacy Router Solicitation processing . . . . . . . . . . 11 78 Appendix C. Sending directed advertisements without the 79 neighbour cache . . . . . . . . . . . . . . . . . . . 12 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 81 Intellectual Property and Copyright Statements . . . . . . . . . . 14 83 1. Introduction 85 1. Requirements notation The key words "MUST", "MUST NOT", 86 "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 87 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 88 interpreted as described in [RFC2119]. 90 2. Introduction 92 Source Link-Layer Address Options (SLLAOs) are sent in Neighbour 93 discovery messages in order to notify neighbours of a mapping between 94 a specific IPv6 Network layer address and a link-layer (or MAC) 95 address. Upon reception of a neighbour discovery message containing 96 such an option, nodes update their neighbour cache entries with the 97 IP to link-layer address mapping in accordance with procedures 98 defined in IPv6 Neighbour Discovery [RFC4861]. 100 Optimistic DAD [RFC4429] prevents usage of these options in Router 101 and Neighbour Solicitation messages from a tentative address (while 102 Duplicate Address Detection is occurring) [RFC4862]. This is because 103 receiving a Neighbour Solicitation (NS) or Router Solicitation (RS) 104 containing an SLLAO would otherwise overwrite an existing cache 105 entry, even if the cache entry contained the legitimate address 106 owner, and the solicitor was a duplicate address. 108 Neighbour Advertisement (NA) messages don't have such an issue, since 109 the Advertisement message contains a flag which explicitly disallows 110 overriding of existing cache entries, by the target link-layer 111 address option carried within. 113 The effect of preventing SLLAOs for tentative addresses is that 114 communications with these addresses are sub-optimal for the tentative 115 period. Sending solicitations without these options causes an 116 additional round-trip for neighbour discovery if the advertiser does 117 not have an existing neighbour cache entry for the solicitor. In 118 some cases, multicast advertisements will be scheduled, where 119 neighbour discovery is not possible on the advertiser. 121 This document proposes Tentative Options which designed to replace 122 the existing Source Link-Layer Address Options available in IPv6 123 Neighbour Discovery, when a device is performing Optimistic DAD. 125 2.1. Tentative Option format 126 0 1 2 3 127 0 1 2 3 4 5 6 7 8 9 0 1 2 5 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | Type | Length | Link-Layer Address ... 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 Fields: 133 Type TBD (Requires IANA Allocation) suggest 17 (0x11) 135 Length The length of the option (including the type and 136 length fields) in units of 8 octets. 138 Link-Layer Address 139 The variable length link-layer address. 141 Description 142 The Tentative option contains the link-layer 143 address of the sender of the packet. It is used 144 in the Neighbour Solicitation and Router 145 Solicitation packets. 147 2.2. Tentative Option semantics 149 The Tentative Option (TO) functions in the same role as the Source 150 Link-Layer Address option defined for [RFC4861], but it MUST NOT 151 override an existing neighbour cache entry. 153 The differing neighbour cache entry MUST NOT be affected by the 154 reception of the Tentative Option. This ensures that tentative 155 addresses are unable to modify legitimate neighbour cache entries. 157 In the case where an entry is unable to be added to the neighbour 158 cache, a node MAY send responses direct to the link-layer address 159 specified in the TO. 161 For these messages, no Neighbour Cache entry may be created, although 162 response messages may be directed to a particular unicast address. 164 These procedures are discussed further in Section 4.3. 166 3. Sending solicitations containing Tentative Options 168 Tentative Options may be sent in Router and Neighbour Solicitations, 169 as described below. 171 In a case where it is safe to send a Source Link-Layer Address 172 Option, a host SHOULD NOT send a TO, since the message may be 173 misinterpreted by legacy nodes. 175 Importantly, a node MUST NOT send a Tentative Option in the same 176 message where a Source Link-Layer Address Option is sent. 178 3.1. Sending Neighbour Solicitations with Tentative Options 180 Neighbour Solicitations sent to unicast addresses MAY contain a 181 Tentative Option. 183 Since delivery of a packet to a unicast destination requires prior 184 knowledge of the destination's hardware address, unicast Neighbour 185 Solicitation packets may only be sent to destinations for which a 186 neighbour cache entry already exists. 188 For example, if checking bidirectional reachability to a router, it 189 may be possible to send a Neighbour Solicitation with Tentative 190 Option to the router's advertised address. 192 As discussed in [RFC4861], the peer device may not have a cache entry 193 even if the soliciting host does, in which case reception of the 194 Tentative Option may create a neighbour cache entry, without the need 195 for neighbour discovering the original solicitor. 197 3.2. Sending Router Solicitations with Tentative Options 199 Any Router Solicitation from a Preferred, Deprecated or Optimistic 200 address MAY be sent with a Tentative Option [RFC4429]. 202 An extension which allows Router Solicitations to be sent with a TO 203 from the unspecified address is described in Appendix C. 205 4. Receiving Tentative Options 207 Receiving a Tentative Option allows nodes to unicast responses to 208 solicitations without performing neighbour discovery. 210 It does this by allowing the solicitation to create STALE neighbour 211 cache entries if one doesn't exist, but only update an entry if the 212 link-layer address in the option matches the entry. 214 Additionally, messages containing TO may be used to direct 215 advertisements to particular link-layer destinations without updating 216 neighbour cache entries. This is described in Appendix C. 218 4.1. Handling Tentative Options 220 Use of Tentative Options is only defined for Neighbour and Router 221 Solicitation messages. 223 In any other received message, the presence of the option is silently 224 ignored, that is, the packet is processed as if the option was not 225 present. 227 It is REQUIRED that the same validation algorithms for Neighbour and 228 Router Solicitations received with TO as in the IPv6 Neighbour 229 Discovery specification [RFC4861], are used. 231 In the case that a solicitation containing a Tentative Option is 232 received, The only processing differences occur in checking and 233 updating the neighbour cache entry. Particularly, there is no reason 234 to believe that the host will remain tentative after receiving a 235 responding advertisement. 237 As defined in Section 2.1, Tentative Options do not overwrite 238 existing neighbour cache entries where the link-layer addresses of 239 the option and entry differ. 241 If a solicitation from a unicast source address is received where no 242 difference exists between the TO and an existing neighbour cache 243 entry, the option MUST be treated as if it were an SLLAO after 244 message validation, and processed accordingly. 246 In the case that a cache entry is unable to be created or updated due 247 to existence of a conflicting neighbour cache entry, it MUST NOT 248 update the neighbour cache entry. 250 An extension which allows a direct advertisement to the soliciting 251 host without modifying the neighbour cache entry is described in 252 Appendix C. 254 4.2. Receiving Neighbour Solicitations containing Tentative Options 256 The Tentative Option is only allowed in Neighbour Solicitations with 257 specified source addresses for which SLLAO is not required. 259 A Neighbour Solicitation message received with a TO and an 260 unspecified source address MUST be silently discarded. 262 Upon reception of a Tentative Option in a Neighbour Solicitation for 263 which the receiver has the Target Address configured, a node checks 264 to see if there is a neighbour cache entry with conflicting link- 265 layer address. 267 If no such entry exists, the neighbour cache of the receiver SHOULD 268 be updated, as if the Tentative Option was a SLLAO. 270 Sending of the solicited Neighbour Advertisement then proceeds 271 normally, as defined in section 7.2.4 of [RFC4861]. 273 If there is a conflicting neighbour cache entry, the node processes 274 the solicitation as defined in Section 7.2.4 of [RFC4861], except 275 that the Neighbour Cache entry MUST NOT be modified. 277 4.3. Receiving a Router Solicitation containing a Tentative Option 279 In IPv6 Neighbour Discovery [RFC4861], responses to Router 280 Solicitations are either sent to the all-nodes multicast address, or 281 may be sent to the solicitation's source address if it is a unicast 282 address. 284 Including a Tentative Option in the solicitation allows a router to 285 choose to send a packet directly to the link-layer address even in 286 situations where this would not normally be possible. 288 For Router Solicitations with unicast source addresses, neighbour 289 caches SHOULD be updated with the link-layer address from a Tentative 290 Option if there is no differing neighbour cache entry. In this case, 291 Router Advertisement continues as in Section 6.2.6 of [RFC4861]. 293 For received solicitations with a differing link-layer address to 294 that stored in the neighbour cache, the node processes the 295 solicitation as defined in Section 6.2.6 of [RFC4861], except that 296 the Neighbour Cache entry MUST NOT be modified. 298 5. IANA Considerations 300 For standardization, it would be required that the IANA provide 301 allocation of the Tentative Option for link-layer addressing (Section 302 1.1) from the IPv6 Neighbour Discovery options for IPv6. 304 Current experimental implementations have used the value 0x11 (17) 305 for the Tentative Option. 307 IANA action requires either IESG Approval or Standards Action 308 [RFC2780]. 310 6. Security Considerations 312 The use of the Tentative Option in Neighbour and Router Solicitation 313 messages acts in a similar manner to SLLAO, updating neighbour cache 314 entries, in a way which causes packet transmission. 316 Particular care should be taken that transmission of messages 317 complies with existing IPv6 Neighbour Discovery Procedures, so that 318 unmodified hosts do not receive invalid messages. 320 An attacker may cause messages may be sent to another node by an 321 advertising node (a reflector), without creating any ongoing state on 322 the reflector. 324 This is attack requires one solicitation for each advertisement and 325 the advertisement has to go to a unicast MAC destination. That said, 326 the size of the advertisement may be significantly larger than the 327 solicitation, or the attacker and reflector may be on a medium with 328 greater available bandwidth than the victim. 330 For link-layers where it isn't possible to spoof the link-layer 331 source address this allows a slightly increased risk of reflection 332 attacks from nodes which are on-link. 334 Additionally, since a SEND host must always advertise using SEND 335 options and signatures, a non-SEND attacker may cause excess 336 computation on both a victim node and a router by causing SEND 337 advertisement messages to be transmitted to a particular MAC address 338 and the lall-nodes multicast. SEND specifies guidelines to hosts 339 receiving unsolicited advertisements in order to mitigate such 340 attacks [RFC3971]. 342 While this is the same effect as experienced when accepting SLLAO 343 from non-SEND nodes, the lack of created neighbour cache entries on 344 the advertiser may make such attacks more difficult to trace. 346 Modification of Neighbour Discovery messages on the network is 347 possible, unless SEND is used. [RFC3971] provides a protocol 348 specification in which soliciting nodes sign ND messages with a 349 private key and use addresses generated from this key. 351 Even if SEND is used, the lifetime of a neighbour cache entry may be 352 extended by continually replaying a solicitation message to a 353 particular router or hosts. Since this may be achieved for any 354 Neighbour or Router Solicitation message, corresponding 355 advertisements to the original transmitters of these solicitation 356 messages may occur. 358 SEND defines use of Timestamp values to protect a device from attack 359 through replay of previously sent messages. Although this applies to 360 Neighbour and Router Solicitation messages, granularity of the 361 timestamp allows the messages to be used for up to five minutes 362 [RFC3971]. 364 All Router and Neighbour Solicitations using SEND contain a Nonce 365 option, containing a random identifier octet string. Since SEND 366 messages are digitally signed, and may not be easily modified, replay 367 attacks will contain the same Nonce option, as was used in the 368 original solicitation. 370 While the Nonce Option included in a transmission to another node may 371 not vary within one short solicitation period (the host may itself 372 replay solicitations in the case of packet loss), the presence of the 373 timestamp option ensures that for later solicitations, a different 374 Timestamp and Nonce will be used. 376 Therefore, a receiver seeing a solicitation with the same Timestamp 377 and Nonce (and signature) for more than either of 378 MAX_RTR_SOLICITATIONS (for Router Solicitations), MAX_UNICAST_SOLICIT 379 or MAX_MULTICAST_SOLICIT (for Neighbour Solicitations), SHOULD ignore 380 further solicitations with this (Nonce,Timestamp,Source) triple, 381 ensuring that no modification is made to neighbour cache entries. 382 This applies to any solicitation packet capable of carrying a SEND 383 payload, whether they use a Tentative Option or SLLAO. 385 Stations noticing such an attack SHOULD notify their administrator of 386 the attempt at Denial-of-service. 388 7. Acknowledgments 390 Erik Nordmark coined a proposal for Tentative version of the SLLAO 391 during a conversation with JinHyeock Choi and Greg Daley. 393 8. References 395 8.1. Normative References 397 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 398 Requirement Levels", BCP 14, RFC 2119, March 1997. 400 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 401 Neighbor Discovery (SEND)", RFC 3971, March 2005. 403 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection for 404 IPv6", RFC RFC4429, April 2006. 406 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 407 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 408 September 2007. 410 8.2. Informative References 412 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 413 Values In the Internet Protocol and Related Headers", 414 BCP 37, RFC 2780, March 2000. 416 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 417 Address Autoconfiguration", RFC 4862, September 2007. 419 Appendix A. Constraints imposed by IPv6 Neighbour Discovery 421 Hosts which send and receive Tentative Options may be interacting 422 with legacy nodes which support IPv6 Neighbour Discovery procedures, 423 but do not understand the new option. 425 For these nodes, the presence of the option is silently ignored, that 426 is, the packet is processed as if the option was not present. 427 Therefore all messages sent with Tentative Options MUST be compliant 428 with the existing requirements for options and addressing specified 429 in the IPv6 Neighbour Discovery RFC [RFC4861]. 431 A.1. Constraints on Neighbour Solicitations 433 As described in Section 7.2.2 of [RFC4861], packets sent to solicited 434 nodes' multicast addresses MUST contain Source Link-Layer Address 435 options. 437 o Neighbour solicitations to multicast addresses MUST NOT contain 438 Tentative Options 440 Neighbour Solicitations to unicast addresses SHOULD include a link- 441 layer address (if the sender has one has one) as a Source Link-Layer 442 Address option. 444 o Unicast neighbour solicitations without Source Link-Layer Address 445 Options MAY contain Tentative Options, if the solicitor has a 446 Link-Layer address. 448 A.2. Constraints on Router Solicitations 450 As described in Section 6.3.7 of [RFC4861], Router Solicitations 451 SHOULD contain Source Link-Layer Address Options. 453 o Router Solicitations without Source Link-Layer Address options MAY 454 contain a Tentative Option. 456 Appendix B. Interactions with legacy nodes 458 Devices which do not implement Tentative Options will act as if no 459 option was placed within the Neighbour Discovery message. The 460 following sections summarize how legacy hosts will interact with 461 messages containing Tentative Options. 463 B.1. Legacy Neighbour Solicitation processing 465 A node can include the Tentative Option in a unicast NS (and no SLLAO 466 option) when the transmitter's address is either preferred, tentative 467 or optimistic. 469 o An RFC 4861 host receiving such a packet will "see" a packet 470 without an SLLAO option, which is allowed in RFC4861. 472 o If the recipient host has an existing neighbour cache entry for 473 the transmitter, it can then send a Neighbour Advertisement. 475 o Where no neighbour cache entry exists, the recipient will send a 476 multicast NS (containing its own SLLAO) in order for the original 477 transmitter to respond with an NA. Upon reception of the original 478 transmitter's NA, an NA is sent back to the origin. 480 The Tentative Option MUST NOT be included in an NS message which has 481 no source address. 483 o An RFC 4861 host sees an NS without a source address as a 484 Duplicate Address Detection message. 486 o Reception of duplicate address detection messages may cause side- 487 effects on other hosts, which may cause them to treat addresses as 488 invalid. 490 B.2. Legacy Router Solicitation processing 492 A node can include the Tentative Option in an RS with a unicast 493 source address (and no SLLAO option) when the transmitter's address 494 is either tentative or optimistic. 496 o An RFC 4861 router receiving such a packet will "see" a packet 497 without an SLLAO option, which is allowed in RFC4861. 499 o If the router has an existing neighbour cache entry for this host, 500 it may send a Unicast RA in response, but may send a multicast in 501 preference. 503 o If no neighbour cache entry exists, some routers will not be able 504 to provide a unicast response. These routers will schedule a 505 multicast response. 507 o Other routers may attempt to perform neighbour discovery (by 508 sending a multicast NS), and unicast a response when a neighbour 509 cache entry has been created. 511 A node can include the Tentative Option in an RS with an unspecified 512 source address (and no SLLAO option) when the transmitter's address 513 is tentative. This is described in Appendix C. 515 o RFC 4861 routers receiving this solicitation will "see" a message 516 without a SLLAO (such options are not allowed in RFC4861 for 517 messages with unspecified source). 519 o These routers will schedule a multicast RA response. 521 Appendix C. Sending directed advertisements without the neighbour cache 523 In the case where an entry is unable to be added to the neighbour 524 cache, a node MAY send responses direct to the link-layer address 525 specified in the Tentative Option. Also, RS packets sent without a 526 specificed source address may potentially contain a Tentative Option. 528 In this case the unicast link-layer address from the solicitation MAY 529 be extracted from the Tentative Option and used as the destination of 530 the link-layer frame for a responding Router Advertisment. 532 Sending such a packet MUST NOT consult the neighbour or destination 533 caches for address. 535 Such packets SHOULD scheduled as if they were unicast advertisements 536 as specified in [RFC4861]. 538 If an implementation can not send a Router Advertisement using 539 information from the Tentative Option i.e, without consulting the 540 neighbour cache, then it SHOULD behave as if the Tentative Option was 541 not present in the solicitation message. 543 Authors' Addresses 545 Greg Daley 546 55 Pakington Street 547 Kew, Victoria 3101 548 Australia 550 Phone: +61 405 494849 551 Email: hoskuld@hotmail.com 553 Erik Nordmark 554 Sun Microsystems, Inc. 555 17 Network Circle 556 Mountain View, CA 557 USA 559 Phone: +1 650 786 2921 560 Fax: +1 650 786 5896 561 Email: erik.nordmark@sun.com 563 Nick "Sharkey" Moore 565 Email: sharkey@zoic.org 567 Full Copyright Statement 569 Copyright (C) The IETF Trust (2008). 571 This document is subject to the rights, licenses and restrictions 572 contained in BCP 78, and except as set forth therein, the authors 573 retain all their rights. 575 This document and the information contained herein are provided on an 576 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 577 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 578 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 579 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 580 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 581 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 583 Intellectual Property 585 The IETF takes no position regarding the validity or scope of any 586 Intellectual Property Rights or other rights that might be claimed to 587 pertain to the implementation or use of the technology described in 588 this document or the extent to which any license under such rights 589 might or might not be available; nor does it represent that it has 590 made any independent effort to identify any such rights. Information 591 on the procedures with respect to rights in RFC documents can be 592 found in BCP 78 and BCP 79. 594 Copies of IPR disclosures made to the IETF Secretariat and any 595 assurances of licenses to be made available, or the result of an 596 attempt made to obtain a general license or permission for the use of 597 such proprietary rights by implementers or users of this 598 specification can be obtained from the IETF on-line IPR repository at 599 http://www.ietf.org/ipr. 601 The IETF invites any interested party to bring to its attention any 602 copyrights, patents or patent applications, or other proprietary 603 rights that may cover technology that may be required to implement 604 this standard. Please address the information to the IETF at 605 ietf-ipr@ietf.org.