idnits 2.17.1 draft-ietf-ipv6-optimistic-dad-02.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 557. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 541. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 523), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 34. ** 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. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 5) being 73 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (09 September 2004) is 7166 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) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) == Outdated reference: A later version (-02) exists of draft-koodli-mobileip-fastv6-00 == Outdated reference: A later version (-06) exists of draft-ietf-send-ndopt-03 Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Working Group Nick 'Sharkey' Moore 3 INTERNET-DRAFT Monash University CTIE 4 09 September 2004 6 Optimistic Duplicate Address Detection for IPv6 7 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 or will be disclosed, and any of which I become aware will be 14 disclosed, in accordance with RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 Optimistic Duplicate Address Detection is an interoperable 39 modification of the existing IPv6 Neighbor Discovery (RFC2461) and 40 Stateless Address Autoconfiguration (RFC2462) process. The intention 41 is to minimize address configuration delays in the successful case, 42 to reduce disruption as far as possible in the failure case and to 43 remain interoperable with unmodified hosts and routers. 45 Table of Contents 47 Status of this Memo ......................................... 1 48 Abstract .................................................... 1 49 Table of Contents ........................................... 2 50 1. Introduction ............................................. 3 51 1.1 Problem Statement ............................... 3 52 1.2 History ......................................... 4 53 1.3 Definitions ..................................... 4 54 1.4 Abbreviations ................................... 5 55 2. Optimistic Behaviours .................................... 6 56 2.1 Probability of Collision ........................ 6 57 2.2 Optimistic Address Flag ......................... 6 58 2.3 Avoiding Disruption ............................. 7 59 2.4 Router Redirection .............................. 7 60 3. Modifications to RFC-compliant behaviour ................. 8 61 3.1 Modifications to RFC 2461 Neighbor Discovery .... 8 62 3.2 Modifications to RFC 2462 SAA ................... 9 63 4. Protocol Operation ....................................... 10 64 4.1 Simple case ..................................... 10 65 4.2 Collision case .................................. 11 66 4.3 Interoperation cases ............................ 11 67 4.4 Pathological cases .............................. 12 68 5. Security Considerations .................................. 12 69 6. IANA Considerations ...................................... 12 70 Normative References ........................................ 13 71 Informative References ...................................... 13 72 Author's Address ............................................ 14 73 Acknowledgments ............................................. 14 74 Full Copyright Statement .................................... 14 75 Intellectual Property Statement ............................. 15 76 Disclaimer of Validity ...................................... 15 78 1. Introduction 80 Optimistic Duplicate Address Detection (DAD) is a modification of the 81 existing IPv6 Neighbor Discovery (ND) [RFC2461] and Stateless Address 82 Autoconfiguration (SAA) [RFC2462] process. The intention is to 83 minimize address configuration delays in the successful case, and to 84 reduce disruption as far as possible in the failure case. 86 Optimistic DAD is a useful optimization because DAD is far more 87 likely to succeed than fail for a well-distributed random address 88 [SOTO]. Disruption is minimized by limiting nodes' participation in 89 Neighbor Discovery while their addresses are still Optimistic. 91 It is not the intention of this memo to improve the security, 92 reliability or robustness of DAD beyond that of existing standards, 93 merely to provide a method to make it faster. 95 1.1 Problem Statement 97 The existing IPv6 address configuration mechanisms provide adequate 98 collision detection mechanisms for the static hosts they were 99 designed for. However, a growing population of nodes need to 100 maintain continuous network access despite frequently changing their 101 network attachment. Optimizations to the DAD process are required to 102 provide these nodes with sufficiently fast address configuration. 104 An optimized DAD method needs to: 106 * provide interoperability with nodes using the current standards. 108 * remove the RetransTimer delay during address configuration. 110 * ensure the probability of address collision is not increased. 112 * improve the resolution mechanisms for address collisions. 114 * minimize disruption in the case of a collision. 116 It is not sufficient to merely reduce RetransTimer in order to reduce 117 the handover delay, as values of RetransTimer long enough to 118 guarantee detection of a collision are too long to avoid disruption 119 of time-critical services. 121 1.2 History 123 There is some precedent for this work in previous Internet Drafts 124 [KOODLI], and in discussions in the MobileIP WG mailing list and at 125 IETF-54. This version of Optimistic DAD differs somewhat from 126 previous versions in that it uses no additional flags or message 127 types beyond those already defined, therefore allowing interoperation 128 between Optimistic and Standard nodes. 130 Earlier versions of this work were presented by the author to the 131 MobileIP WG at IETF-56, and to the IPv6 WG at IETF-59. An issues 132 list was presented at IETF-60. 134 Working implementations of draft versions of this memo have been made 135 by the author as a freely-available patch to Linux 2.4.18, and by Ed 136 Remmel of Elmic Systems. 138 An implementation of this version by the author is in progress, and 139 will be released as a freely-available patch to Linux 2.6.7. 141 1.3 Definitions 143 Definitions of requirements keywords ('MUST NOT', 'SHOULD NOT', 144 'MAY', 'SHOULD', 'MUST') are in accordance with the IETF Best Current 145 Practice - RFC2119 [RFC2119] 147 Address Resolution - Process defined by [RFC2461] section 7.2. 149 Neighbor Unreachability Detection - Process defined by [RFC2461] 150 section 7.3. 152 Tentative Address - an address for which a node has not yet completed 153 DAD is regarded as Tentative: a single Neighbor Solicitation for 154 this address or a single Neighbor Advertisement defending this 155 address will cause the node to deconfigure the address and cease 156 using it. 158 Deprecated Address - an address which should not be used if an 159 alternative is available. 161 Optimistic Address - an address which is available for use despite 162 DAD not being fully complete. This memo places restrictions on 163 the use of Optimistic Addresses. 165 Preferred Address - an address which is neither Tentative, Deprecated 166 or Optimistic. 168 Optimistic Node - An Optimistic Node is one which is compliant with 169 the rules specified in this memo. 171 Standard Node - A Standard Node is one which is compliant with RFCs 172 2461 and 2462. 174 Link - A communication facility or medium over which nodes can 175 communicate at the link layer. 177 Neighbors - Nodes on the same link, which may therefore be competing 178 for the same addresses. 180 1.4 Abbreviations 182 DAD - Duplicate Address Detection. Technique used for SAA. See 183 [RFC2462] section 5.4. 185 ICMP Redirect - See [RFC2461] section 4.5. 187 NA - Neighbor Advertisement. See [RFC2461] sections 4.4 and 7. 189 NC - Neighbor Cache. See [RFC2461] section 5.1 and 7.3. 191 ND - Neighbor Discovery. The process described in [RFC2461] 193 NS - Neighbor Solicitation. See [RFC2461] sections 4.3 and 7. 195 ON - Optimistic Node. A node which is behaving according to the 196 rules of this memo. 198 RA - Router Advertisement. See [RFC2462] sections 4.2 and 6. 200 RS - Router Solicitation. See [RFC2461] sections 4.1 and 6. 202 SAA - Stateless Address Autoconfiguration. The process described in 203 [RFC2462] 205 SLLAO - Source Link Layer Address Option - an option to NS, RA and RS 206 messages, which gives the link layer address of the source of 207 the message. See [RFC2461] section 4.6.1. 209 TLLAO - Target Link Layer Address Option - an option to ICMP redirect 210 messages and Neighbor Advertisements. See [RFC2461] sections 211 4.4, 4.5 and 4.6.1. 213 2. Optimistic DAD Behaviours 215 This section provides some discussion of Optimistic DAD Behaviours. 216 Section 3 provides more specific information on changes to RFC- 217 mandated behaviours. 219 2.1 Probability of Collision 221 Optimistic DAD is only a useful optimization when the probability of 222 collision is very small. As such, the Optimistic algorithm should 223 not be used for manually assigned addresses, where the collision 224 probability is likely to be much higher than that for random 225 addresses due to human error. 227 Modifications are required only to Optimistic nodes -- Optimistic 228 nodes will interoperate with Standard nodes without significant 229 advantage or incompatibility. 231 2.2 Optimistic Addresses 233 [RFC2462] introduces the concept of Tentative (in 5.4) and Deprecated 234 (in 5.5.4) Addresses. Addresses which are neither are said to be 235 Preferred. Tentative addresses may not be used for communication, 236 and Deprecated addresses should not be used for new communications. 237 These address states may also be used by other standards documents, 238 for example Default Address Selection [RFC3484]. 240 This memo introduces a new address state, 'Optimistic', which is used 241 to mark an address which is available for use but which has not 242 completed DAD. Protocols which do not understand this state should 243 treat it equivalently to 'Deprecated', to indicate that the address 244 is available for use but should not be used if another suitable 245 address is available. If address states are recorded as individual 246 flags, this can easily be achieved by setting 'Deprecated' when 247 'Optimistic' is set. In any case, it is important to note that the 248 address lifetime rules of [RFC2462] still apply, and so an address 249 may be Deprecated as well as Optimistic. When DAD completes without 250 incident, the address becomes a Preferred or Deprecated address, as 251 per [RFC2462]. 253 2.3 Avoiding Disruption 255 In order to avoid interference, it is important that an Optimistic 256 node does not send any messages from an Optimistic Address which will 257 override its neighbors' Neighbor Cache (NC) entries for the address 258 it is trying to configure: doing so would disrupt the rightful owner 259 of the address in the case of a collision. 261 This is achieved by: 263 * clearing the 'Override' flag in Neighbor Advertisements for 264 Optimistic addresses, which prevents neighbors from overriding 265 their existing NC entries. The 'Override' flag is already 266 defined [RFC2461] and used for Proxy Neighbor Advertisement. 268 * Never sending Neighbor Solicitations from an Optimistic Address. 269 NSs include a Source Link Layer Address Option (SLLAO), which 270 may cause Neighbor Cache disruption. NSs sent as part of DAD 271 are sent from the unspecified address, without a SLLAO. 273 * Never using a Optimistic Address as the source address of a Router 274 Solicitation with a SLLAO. Another address, or the unspecified 275 address, may be used, or the RS may be sent without a SLLAO. 277 An address collision with a router may cause neighboring 278 router's IsRouter flags for that address to be cleared. 279 However, routers do not appear to use the IsRouter flag for 280 anything, and the NA sent in response to the collision will 281 reassert the IsRouter flag. 283 2.4 Router Redirection 285 When the ON wants to contact another neighbor, but it cannot because 286 the neighbor is not in its NC, it should instead forward the packet 287 to the router, relying on the router to forward the packet. The 288 router should then provide the ON with an ICMP redirect, which may 289 include a Target Link Layer Address Option (TLLAO). If it does, this 290 will update the ON's NC, and direct communication can begin. 291 Implementing this behaviour may be difficult and unnecessary, so it 292 is left as an option to the implementor. 294 3. Modifications to RFC-mandated behaviour 296 3.1 Modifications to RFC 2461 Neighbor Discovery 298 * (modifies 6.3.7) A node MUST NOT send a Router Solicitation with a 299 SLLAO from an Optimistic Address. Router Solicitations SHOULD 300 be sent from a non-Optimistic or the Unspecified Address, 301 however they MAY be sent from an Optimistic Address as long as 302 the SLLAO is not included. 304 * (modifies 7.2.2) A node MUST NOT use an Optimistic Address as the 305 source address of a Neighbor Solicitation. 307 * If the ON isn't told the SLLAO of the router in an RA, and it 308 cannot determine this information without breaching the rules 309 above, it MUST wait until DAD completes despite being unable to 310 send any packets to the router. 312 * (modifies 7.2.2) When a node has a unicast packet to send from an 313 Optimistic Address to a neighbor, but does not know the 314 neighbor's link-layer address, it MUST NOT perform Address 315 Resolution. It SHOULD forward the packet to a default router on 316 the link in the hope that the packet will be redirected. 317 Otherwise it SHOULD buffer the packet until DAD is complete. 319 3.2 Modifications to RFC 2462 Stateless Address Autoconfiguration 321 * (modifies 5.5) A host MAY choose to configure a new address as an 322 Optimistic Address. A host which does not know the SLLAO of its 323 router SHOULD NOT configure a new address as Optimistic. A 324 router MUST NOT configure an Optimistic Address. 326 * (modifies 5.4) As soon as the initial Neighbor Solicitation is 327 sent, the Optimistic Address is configured on the interface and 328 available for use immediately. The address MUST be flagged as 329 'Optimistic'. Protocols which do not understand this state 330 SHOULD treat it equivalently to 'Deprecated'. 332 * When the DAD completes for an Optimistic Address, the address is no 333 longer Optimistic and it becomes Preferred or Deprecated 334 according to the rules of [RFC2462]. 336 * (modifies 5.4.3) The node MUST NOT reply to a Neighbor Solicitation 337 for an Optimistic Address from the unspecified address. This NS 338 indicates that the address is a duplicate, and it MUST be 339 deconfigured as per the behaviour specified in RFC2462 for 340 Tentative addresses. 342 * (modifies 5.4.3) The node MUST reply to a Neighbor Solicitation for 343 an Optimistic Address from a unicast address, but the reply MUST 344 have the Override flag cleared (O=0). 346 4. Protocol Operation 348 The following cases all consider an Optimistic Node (ON) receiving a 349 Router Advertisement containing a new prefix and deciding to 350 autoconfigure a new address on that prefix. 352 The ON will immediately send out a Neighbor Solicitation to determine 353 if its new address is already in use. 355 4.1 Simple case 357 In the non-collision case, the address being configured by the new 358 node is unused and not present in the Neighbor Caches of any of its 359 neighbors. 361 There will be no response to its NS (sent from ::), and this NS will 362 not modify the state of neighbors' Neighbor Caches. 364 The Optimistic Node already has the link-layer address of the router 365 (from the RA), and the router can determine the link-layer address of 366 the ON through standard Address Resolution. Communications can begin 367 as soon as the router and the ON have each others' link-layer 368 addresses. 370 After the appropriate DAD delay has completed, the address is no 371 longer Optimistic, and becomes either Preferred or Deprecated as per 372 RFC2462. 374 4.2 Collision case 376 In the collision case, the address being configured by the new node 377 is already in use by another node, and present in the Neighbor Caches 378 (NCs) of neighbors which are communicating with this node. 380 The NS sent by the ON has the unspecified source address, ::, and no 381 SLLAO. This NS will not cause changes to the NC entries of 382 neighboring hosts. 384 The ON will hopefully already know all it needs to about the router 385 from the initial RA. However, if it needs to it can still send an RS 386 to ask for more information, but it may not include a SLLAO. This 387 forces a broadcast response from the router, but will not disrupt 388 other nodes' NCs. 390 In the course of establishing connections, the ON may send NAs either 391 spontaneously or in response to received NSs. Since these NAs will 392 have O=0, they will not override existing NC entries, although they 393 may result in a colliding entry being changed to state STALE. This 394 change is recoverable through standard NUD. 396 Of course, in the meantime the ON may have sent packets which 397 identify it as the owner of its new Optimistic Address (for example, 398 Binding Updates in [MIPV6]). This may incur some penalty to the ON, 399 in the form of broken connections, and some penalty to the rightful 400 owner of the address, since it will receive (and potentially reply 401 to) the misdirected packets. It is for this reason that Optimistic 402 DAD should only be used where the probability of collision is very 403 low. 405 4.3 Interoperation cases 407 Once the Optimistic Address has completed DAD, it acts exactly like a 408 normal address, and so interoperation cases only arise while the 409 address is Optimistic. 411 If an Optimistic Node attempts to configure an address currently 412 Tentatively assigned to a Standard Node, the Standard Node will see 413 the Neighbor Solicitation and deconfigure the address. 415 If a node attempts to configure an Optimistic Node's Optimistic 416 Address, the Optimistic Node will see the NS and deconfigure the 417 address. 419 4.4 Pathological cases 421 Optimistic DAD suffers from similar problems to Standard DAD, for 422 example duplicates are not guaranteed to be detected if packets are 423 lost. 425 These problems exist, and are not gracefully recoverable, in Standard 426 DAD. Their probability in both Optimistic and Standard DAD can be 427 reduced by increasing the RFC2462 DupAddrDetectTransmits variable to 428 greater than 1. 430 This version of Optimistic DAD is dependant on the details of the 431 router behaviour, eg: that the router includes SLLAOs in RAs, and 432 that the router is willing to redirect traffic for the ON. Where the 433 router does not behave in this way, the behaviour of Optimistic DAD 434 inherently reverts to that of Standard DAD. 436 5. Security Considerations 438 There are existing security concerns with Neighbor Discovery and 439 Stateless Address Autoconfiguration, and this memo does not purport 440 to fix them. However, this memo does not significantly increase 441 security concerns either. 443 Further work will be required to integrate Optimistic DAD with Secure 444 Neighbor Discovery [SEND]. 446 6. IANA Considerations 448 This document has no actions for IANA. 450 Normative References 452 [RFC2119] S. Bradner. "Key words for use in RFCs to Indicate 453 Requirement Levels." Request for Comments (Best Current 454 Practice) 2119 (BCP 14), Internet Engineering Task Force, March 455 1997. 457 [RFC2461] T. Narten, E.Nordmark, W. Simpson. "Neighbor Discovery for 458 IP Version 6 (IPv6)." Request for Comments (Draft Standard) 459 2461, Internet Engineering Task Force, December 1998. 461 [RFC2462] S. Thomson, T. Narten. "IPv6 Stateless Address 462 Autoconfiguration." Request for Comments (Draft Standard) 2462, 463 Internet Engineering Task Force, December 1998. 465 Informative References 467 [RFC3484] R. Draves. "Default Address Selection for Internet Protocol 468 version 6 (IPv6)". Request for Comments (Proposed Standard) 469 3484, Internet Engineering Task Force, February 2003. 471 [MIPV6] D. Johnson, C. Perkins, J. Arkko. Mobility Support in IPv6, 472 revision 24 (draft-ietf-mobileip-ipv6-24). June 2003 ... 473 Expired December 2003. 475 [KOODLI] R. Koodli, C. Perkins. Fast Handovers in Mobile IPv6, 476 revision 00 (draft-koodli-mobileip-fastv6-00). October 2000 ... 477 Expired April 2001. 479 [SOTO] M. Bagnulo, I. Soto, A. Garcia-Martinez, A. Azcorra. Random 480 generation of interface identifiers, revision 00. (draft-soto- 481 mobileip-random-iids-00). January 2002 ... Expired July 2002. 483 [SEND] J. Arkko, J. Kempf, B. Sommerfeld, B.Zill, P. Nikander. 484 SEcure Neighbor Discovery (SEND), revision 03. (draft-ietf- 485 send-ndopt-03). January 2004 ... Expires July 2004. 487 Author's Address: 489 Nick 'Sharkey' Moore 490 or 491 Centre for Telecommunications and Information Engineering 492 Monash University 3800 493 Victoria, Australia 495 Comments should be sent to either of the above email addresses. 497 Acknowledgments 499 Thanks to Greg Daley, Brett Pentland, Richard Nelson and Ahmet 500 Sekercioglu at Monash Uni CTIE for their feedback and encouragement. 501 More information is available at: 502 504 Thanks to all the MobileIP and IPng/IPv6 WG members who have 505 contributed to the debate. Especially and alphabetically: Jari 506 Arkko, JinHyeock Choi, Youn-Hee Han, James Kempf, Thomas Narten, 507 Richard Nelson, Pekka Nikander, Erik Nordmark, Soohong 'Daniel' Park, 508 Ed Remmel, Pekka Savola, Hesham Soliman, Ignatious Souvatzis, Jinmei 509 Tatuya, Dave Thaler, Pascal Thubert, Vladislav Yasevich and Alper 510 Yegin. 512 This work has been supported by the Australian Telecommunications 513 Cooperative Research Centre (ATcrc): 514 516 Funding for the RFC Editor function is currently provided by the 517 Internet Society. 519 Full Copyright Statement 521 Copyright (C) The Internet Society (2004). This document is subject 522 to the rights, licenses and restrictions contained in BCP 78 and 523 except as set forth therein, the authors retain all their rights. 525 Intellectual Property Statement 527 The IETF takes no position regarding the validity or scope of any 528 intellectual property or other rights that might be claimed to 529 pertain to the implementation or use of the technology described in 530 this document or the extent to which any license under such rights 531 might or might not be available; neither does it represent that it 532 has made any effort to identify any such rights. Information on the 533 IETF's procedures with respect to rights in IETF Documents can be 534 found in BCP 78 and 79. 536 Copies of IPR disclosures made to the IETF Secretariat and any 537 assurances of licenses to be made available, or the result of an 538 attempt made to obtain a general license or permission for the use of 539 such proprietary rights by implementers or users of this 540 specification can be obtained from the IETF on-line IPR repository at 541 http://www.ietf.org/ipr. 543 The IETF invites any interested party to bring to its attention any 544 copyrights, patents or patent applications, or other proprietary 545 rights which may cover technology that may be required to implement 546 this standard. Please address the information to the IETF at ietf- 547 ipr@ietf.org. 549 Disclaimer of Validity 551 This document and the information contained herein are provided on an 552 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 553 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 554 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 555 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 556 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 557 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.