idnits 2.17.1 draft-daley-ipv6-tsllao-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 524. -- Found old boilerplate from RFC 3978, Section 5.5 on line 540. ** 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. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 121: '... [RFC-2461], but it MUST NOT override an existing neighbour cache...' RFC 2119 keyword, line 124: '...bour cache entry MUST NOT be affected ...' RFC 2119 keyword, line 130: '... cache, a node MAY send responses di...' RFC 2119 keyword, line 146: '... Option, a host SHOULD NOT send a TSL...' RFC 2119 keyword, line 149: '...ortantly, a node MUST NOT send a TSLLA...' (22 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (9 June 2004) is 7260 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'OPTIDAD' ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) -- Possible downref: Non-RFC (?) normative reference: ref. 'SEND' Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Working Group Greg Daley 3 INTERNET-DRAFT Nick "Sharkey" Moore 4 Expires: December 2004 Monash University CTIE 5 Erik Nordmark 6 Sun Microsystems 7 9 June 2004 9 Tentative Source Link-Layer Address Options 10 for IPv6 Neighbour Discovery 12 14 Status of this Memo 16 By submitting this Internet-Draft, I certify that any applicable 17 patent or other IPR claims of which I am aware have been disclosed 18 and any of which I become aware will be disclosed, in accordance with 19 RFC 3668 (BCP 79). 21 By submitting this Internet-Draft, I accept the provisions of Section 22 3 of RFC 3667 (BCP 78). 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that other 26 groups may also distribute working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or cite them other than as "work in progress". 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/lid-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 This document is an individual submission to the IETF. Comments 40 should be directed to the authors. 42 Definitions of requirements keywords are in accordance with the IETF 43 Best Current Practice - RFC2119 [KEYW-RFC] 45 Abstract 47 The proposed IPv6 Duplicate Address Detection (DAD) Optimization 48 "Optimistic DAD" defines a set of recoverable procedures which allow 49 a node to make use of an address before DAD completes. Essentially, 50 Optimistic DAD forbids usage of certain Neighbour Discovery options 51 which could pollute active neighbour cache entries, while an address 52 is tentative. 54 This document defines a new option and procedures to replace cache 55 polluting options, in a way which is useful to tentative nodes. 56 These procedures are designed to be to backward compatible with 57 existing devices which support IPv6 Neighbour Discovery. 59 1.0 Introduction 61 Source Link-Layer Address Options (SLLAOs) are sent in Neighbour 62 discovery messages in order to notify neighbours of a mapping between 63 a specific IPv6 Network layer address and a link-layer (or MAC) 64 address. Upon reception of a neighbour discovery message containing 65 such an option, nodes update their neighbour cache entries with the 66 IP to link-layer address mapping in accordance with procedures 67 defined in IPv6 Neighbour Discovery [RFC-2461]. 69 Optimistic DAD [OPTIDAD] prevents usage of these options in Router 70 and Neighbour Solicitation messages from a tentative address (while 71 Duplicate Address Detection is occurring). This is because receiving 72 a Neighbour Solicitation (NS) or Router Solicitation (RS) containing 73 an SLLAO would otherwise overwrite an existing cache entry, even if 74 the cache entry contained the legitimate address owner, and the 75 solicitor was a duplicate address. 77 Neighbour Advertisement (NA) messages don't have such an issue, since 78 the Advertisement message contains a flag which explicitly disallows 79 overriding of existing cache entries, by the target link-layer 80 address option carried within. 82 The effect of preventing SLLAOs for tentative addresses is that 83 communications with these addresses are sub-optimal for the tentative 84 period. Sending solicitations without these options causes an 85 additional round-trip for neighbour discovery if the advertiser does 86 not have an existing neighbour cache entry for the solicitor. 88 Tentative Source Link-Layer Address Options are designed to replace 89 the existing Source Link-Layer Address Options available in IPv6 90 Neighbour Discovery, when a device is performing Optimistic DAD, or a 91 device is sending Router Solicitations from an unspecified source 92 address. 94 1.1 Tentative Source Link-Layer Address Option Format 96 0 1 2 3 97 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 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 | Type | Length | Link-Layer Address ... 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 Fields: 103 Type TBD 105 Length The length of the option (including the type and 106 length fields) in units of 8 octets [RFC-2461]. 108 Link-Layer Address 109 The variable length link-layer address. 111 Description 112 The Tentative Source Link-Layer Address option 113 contains the link-layer address of the sender of 114 the packet. It is used in the Neighbour 115 Solicitation and Router Solicitation packets. 117 1.2 Tentative Source Link-Layer Address Option Semantics 119 The Tentative Source Link-Layer Address option (TSLLAO) functions in 120 the same role as the Source Link-Layer Address option defined for 121 [RFC-2461], but it MUST NOT override an existing neighbour cache 122 entry. 124 The differing neighbour cache entry MUST NOT be affected by the 125 reception of the Tentative Source Link-Layer Address option. This 126 ensures that tentative addresses are unable to modify legitimate 127 neighbour cache entries. 129 In the case where an entry is unable to be added to the neighbour 130 cache, a node MAY send responses direct to the link-layer address 131 specified in the TSLLAO. 133 For these messages, no Neighbour Cache entry may be created, although 134 response messages may be directed to a particular unicast address. 136 These procedures are discussed further in section 3.3. 138 2.0 Sending Solicitations containing TSLLAO 140 Solicitations sent containing Tentative Source Link-Layer Address 141 Options need to conform to IPv6 Neighbour Discovery procedures, since 142 they are send without SLLAOs, and legacy nodes will ignore the new 143 option. 145 In a case where it is safe to send a Source Link-Layer Address 146 Option, a host SHOULD NOT send a TSLLAO, since the message may be 147 mis-interpreted by legacy nodes. 149 Importantly, a node MUST NOT send a TSLLAO in the same message where 150 a Source Link-Layer Address Option is sent. 152 A node MUST NOT send TSLLAO options except where [RFC-2461] allows 153 ommision of an SLLAO i.e. in the following cases: 155 2.1 Sending Neighbour Solicitations with TSLLAO 157 Except for packets sent from an unspecified source address, Source 158 Link-Layer Address options are mandatory in Neighbour Solicitation 159 messages destined to multicast addresses. 161 Neighbour Solicitations for the unspecified source address are 162 typically used for Duplicate Address Detection. Any receiver of an 163 unspecified source addressed Neighbour Solicitation with TSLLAO will 164 believe the packet to be a DAD attempt if it is unable to interpret 165 the TSLLAO option. 167 Since many nodes will halt address configuration if they receive a 168 DAD NS while an address is tentative, Tentative Source Link-Layer 169 Address options MUST NOT be sent in Neighbour Solicitation messages 170 from the unspecified source address. 172 On the other hand, Neighbour Solicitation packets with unicast source 173 and destination addresses are not explicitly required to include 174 SLLAOs. Such packets may instead use a Tentative Source Link-Layer 175 Address Option, which is safe when undergoing Duplicate Address 176 Detection[OPTIDAD]. 178 Since delivery of a packet to a unicast destination requires prior 179 knowledge of the destination's hardware address, unicast Neighbour 180 Solicitation packets may only be sent to destinations for which a 181 neighbour cache entry already exists. 183 For example, if checking bidirectional reachability to a router, it 184 may be possible to send a Neighbour Solicitation with TSLLAO to the 185 router's advertised address. 187 As discussed in [RFC-2461], the peer device may not have a cache 188 entry even if the soliciting host does, in which case reception of 189 TSLLAO may create a neighbour cache entry, without the need for 190 neighbour discovering the original solicitor. If the device is a 191 legacy [RFC-2461] device, which doesn't recognize TSLLAO options, it 192 will perform a Neighbour Solicitation back to the tentative node. 194 Hosts MUST NOT send Neighbour Solicitations with specified source 195 addresses and TSLLAO to nodes for which there is no pre-existing 196 neighbour cache entry, or state is INCOMPLETE, unless these nodes are 197 known to support TSLLAOs. 199 This is because such Neighbour Solicitations violate IPv6 Neighbour 200 Discovery specifications since they contain no SLLAO, and may cause 201 confusion or harm to nodes which receive them. 203 2.2 Sending Router Solicitations with TSLLAO 205 Router Solicitations are always able to be sent without Source Link- 206 Layer Address options. 208 Some routers may choose to send a multicast response to devices which 209 send Router Solicitations without SLLAOs when they do not have an 210 existing neighbour cache entry. If a router does not understand 211 Tentative Source Link-Layer Address Options, it MAY send a multicast 212 solicitation in preference to sending Neighbour Solicitation packets 213 to learn unicast address's link-layer address. 215 Any router solicitation, including those from the unspecified 216 address, MAY be sent with a TSLLAO. 218 Responses from routers depend on existing neighbour cache state, and 219 their ability to send packets to identified MAC addresses without 220 using the neighbour cache. 222 Such issues are discussed in sections 3.4 and 3.5. 224 3.0 Receiving Tentative Source Link-Layer Address Options 226 In the case that a node receives a solicitation without a Link-Layer 227 identifier it will determine if a responding Advertisement will be 228 sent to a unicast or multicast address. 230 If the advertisement is to be sent to the solicitor's unicast 231 address, the node will consult its existing neighbour cache for the 232 solicitor's information, and if not present, will undertake neighbour 233 discovery. 235 Receiving a Tentative Source Link-Layer Address Option, avoids this 236 neighbour discovery step, by allowing the host to create or update a 237 matching entry, setting it to STALE state if it didn't previously 238 exist. 240 Additionally, TSLLAO messages may be used to direct advertisements to 241 particular link-layer destinations without updating neighbour cache 242 entries. This is described in section 3.4. 244 3.1 Handling messages with Tentative Source Link-Layer Address Options 246 Use of Tentative Source Link-Layer Address Options is only defined 247 for Neighbour and Router Solicitation messages. 249 In any other received message, a Tentative Source Link-Layer Address 250 Option MUST be treated as if it is an unknown option, and processed 251 appropriately. 253 It is REQUIRED that the same validation algorithms for Neighbour and 254 Router Solicitations received with TSLLAO as in the IPv6 Neighbour 255 Discovery specification [RFC-2461], are used. In the case that a 256 solicitation containing a TSLLAO is received, this does not mean that 257 the solicitor needs to be treated differently, except in the updating 258 of the cache entry and processing of the option. Particularly, there 259 is no reason to believe that the host will remain tentative after 260 receiving a responding advertisement. 262 As defined in Section 1.2, Tentative Source Link-Layer Address 263 Options do not overwrite existing neighbour cache entries where the 264 link-layer addresses differ. 266 If a solicitation from a unicast source address is received where no 267 conflict occurs between the TSLLAO and an existing neighbour cache 268 entry, the option MUST be treated as if it were an SLLAO after 269 message validation, and processed accordingly. 271 In the case that a cache entry is unable to be created or updated, 272 the receiving node MAY send a direct advertisement to the soliciting 273 host by responding with an appropriate advertisement, where the link- 274 layer address contained in the TSLLAO is copied into the destination 275 address of the link-layer frame. 277 This is described further in sections 3.4 and 3.5. 279 3.2 Receiving Neighbour Solicitations containing TSLLAO 281 The TSLLAO option is only allowed in Neighbour Solicitations with 282 specified source addresses for which SLLAO is not required. A 283 Neighbour Solicitation message received with TSLLAO and an 284 unspecified source address MUST be silently discarded. 286 Upon reception of a Tentative Source Link-Layer Address Option in a 287 Neighbour Solicitation for which the receiver has the Target Address 288 configured, a node checks to see if there is a neighbour cache entry 289 with conflicting link-layer address. 291 If no such entry exists, the neighbour cache of the receiver SHOULD 292 be updated, as if the Tentative Source Link-Layer Address Option was 293 a SLLAO. 295 Sending of the solicited Neighbour Advertisement then proceeds 296 normally, as defined in section 7.2.4 of [RFC-2461]. 298 If there is a conflicting neighbour cache entry, a node processes the 299 solicitation in a fashion defined in in sections 3.4 and 3.5. 301 3.3 Receiving a Router Solicitation containing TSLLAO 303 In IPv6 Neighbour Discovery [RFC-2461], responses to router 304 solicitations are either sent to the all-nodes multicast address, or 305 may be sent to the solicitation's source address if it is a unicast 306 address. 308 Including a TSLLAO in the solicitation allows a router to choose to 309 send a packet directly to the link-layer address even in situations 310 where this would not normally be possible. 312 For Router Solicitations with unicast source addresses, neighbour 313 caches SHOULD be updated with the link-layer address from a TSLLAO if 314 there is no conflicting neighbour cache entry. In this case, Router 315 Advertisement continues as in section 6.2.6 of [RFC-2461]. 317 For received solicitations with a conflicting neighbour cache entry 318 or those containing a TSLLAO with an unspecified source address, 319 responses can be generated in accordance with sections 3.4 and 3.5 320 below. 322 3.4 Sending Directed Advertisements without the Neighbour Cache. 324 In the case where a received solicitation has a link-layer address 325 specified in a TSLLAO which conflicts with an existing with a 326 neighbour cache entry, modification of the neighbour cache MUST NOT 327 occur. 329 Router Solicitations with the unspecified source address MUST NOT 330 create neighbour cache entires. 332 In both situations, it may be valuable to send a direct message to 333 the soliciting nodes. 335 In these cases a node MAY generate a responding advertisement 336 according to the rules in [RFC-2461]. 338 The responding packets MAY then have the unicast link-layer address 339 from the TSLLAO inserted into the destination address of the link- 340 layer frame used to transport this advertisement, without consulting 341 the neighbour or destination caches for this entry. 343 Such packets SHOULD scheduled as if they were unicast advertisements 344 as specified in [RFC-2461]. 346 3.5 Alternatives to Sending Directed Advertisements. 348 Some implementations will be unable to generate directed 349 advertisements by copying the tentative source link-layer address 350 into a packet. 352 Also, some nodes will be unable to send unicast packets without 353 consulting their neighbour caches. Alternative mechanisms for such 354 nodes SHOULD perform at least as well as implementations where TSLLAO 355 is not understood. 357 For such implementations as these, it is not possible to send a 358 response for Neighbour Solicitation messages without modifying the 359 neighbour cache. 361 Such nodes MAY send a responding NA message as if it did not 362 understand the TSLLAO message. 364 This will deliver the NA to the soliciting host if it has both the 365 tentative link-layer address and the entry in the neighbour cache 366 configured on the same link. Otherwise, the message will be sent to 367 the originator of the neighbour cache entry, and the solicitor will 368 receive no response. 370 For Router Solicitations where no neighbour cache entry is able to be 371 created, a multicast response SHOULD be sent in accordance with 372 [RFC-2461]. This includes those solicitations sent from unicast 373 sources, for which a conflicting neighbour cache entry was found. 375 4.0 IANA Considerations 377 For standardization, it would be required that the IANA provide 378 allocation of the Tentative Source Link-Layer Address Option (Section 379 1.1) from the IPv6 Neighbour Discovery options for IPv6. 381 Potential details of the allocation process for these options is 382 detailed in the expired draft [IPv6-ALLOC]. 384 5.0 Security Considerations 386 The use of the TSLLAO in Neighbour and Router Solicitation messages 387 acts in a similar manner to SLLAO, updating neighbour cache entries, 388 in a way which causes packet transmission. 390 Particular care should be taken that transmission of messages 391 complies with existing IPv6 Neighbour Discovery Procedures, so that 392 unmodified hosts do not receive invalid messages. 394 An attacker may cause messages may be sent to another node by an 395 advertising node (a reflector), without creating any ongoing state on 396 the reflector. 398 This is attack requires one solicitation for each advertisement and 399 the advertisement has to go to a unicast MAC destination. That said, 400 the size of the advertisement may be significantly larger than the 401 solicitation, or the attacker and reflector may be on a medium with 402 greater available bandwidth than the victim. 404 For link-layers where it isn't possible to spoof the link-layer 405 source address this allows a slightly increased risk of reflection 406 attacks from nodes which are on-link. 408 Additionally, since a SEND host must always advertise using SEND 409 options and signatures, a non-SEND attacker may cause excess 410 computation on both a victim node and a router by causing SEND 411 advertisement messages to be transmitted to a particular MAC address 412 and the all-nodes multicast. [SEND] specifies guidelines to hosts 413 receiving unsolicited advertisements in order to mitigate such 414 attacks. 416 While this is the same effect as experienced when accepting SLLAO 417 from non-SEND nodes, the lack of created neighbour cache entries on 418 the advertiser may make such attacks more difficult to trace. 420 Modification of Neighbour Discovery messages on the network is 421 possible, unless SEND is used. [SEND] provides a protocol 422 specification in which soliciting nodes sign ND messages with a 423 private key and use addresses generated from this key. 425 Even if SEND is used, the lifetime of a neighbour cache entry may be 426 extended by continually replaying a solicitation message to a 427 particular router or hosts. Since this may be achieved for any 428 Neighbour or Router Solicitation message, corresponding 429 advertisements to the original transmitters of these solicitation 430 messages may occur. 432 SEND defines use of Timestamp values to protect a device from attack 433 through replay of previously sent messages. Although this applies to 434 Neighbour and Router Solicitation messages, granularity of the 435 timestamp allows the messages to be used for up to two hours in 436 extreme cases [SEND]. 438 All Router and Neighbour Solicitations using SEND contain a Nonce 439 option, containing a random identifier octet string. Since SEND 440 messages are digitally signed, and may not be easily modified, replay 441 attacks will contain the same Nonce option, as was used in the 442 original solicitation. 444 While the Nonce Option included in a transmission to another node may 445 not vary within one short solicitation period (the host may itself 446 replay solicitations in the case of packet loss), the presence of the 447 timestamp option ensures that for later solicitations, a different 448 Timestamp and Nonce will be used. 450 Therefore, a receiver seeing a solicitation with the same Timestamp 451 and Nonce (and signature) for more than either of 452 MAX_RTR_SOLICITATIONS (for router solicitations), MAX_UNICAST_SOLICIT 453 or MAX_MULTICAST_SOLICIT (for Neighbour Solicitations), SHOULD ignore 454 further solicitations with this (Nonce,Timestamp,Source) triple, 455 ensuring that no modification is made to neighbour cache entries. 456 This applies to any solicitation packet capable of carrying a SEND 457 payload, whether they use TSLLAO or SLLAO. 459 Stations noticing such an attack SHOULD notify their administrator of 460 the attempt at Denial-of-service. 462 Normative References 464 [KEYW-RFC] S. Bradner. Key words for use in RFCs to Indicate 465 Requirement Levels. Request for Comments (Best Current Practice) 466 2119 (BCP 14), Internet Engineering Task Force, March 1997 468 [OPTIDAD] N. Moore. Optimistic Duplicate Address Detection. Internet 469 Draft (work in progress), March 2004. 471 [RFC-2461] T. Narten, E.Nordmark, W. Simpson. Neighbour Discovery 472 for IP Version 6 (IPv6). Request for Comments (Draft Standard) 473 2461, Internet Engineering Task Force, December 1998. 475 [SEND] J. Arkko (Editor) et al. SEcure Neighbour Discovery (SEND). 476 Internet Draft (work in progress), April 2004. 478 Non-Normative References 480 [IPv6-ALLOC] T. Narten. "IANA Allocation Guidelines for Values in 481 IPv6 and Related Headers", Internet Draft (work in progress), 482 October 2002. www.watersprings.org/pub/id/draft-narten- 483 ipv6-iana-considerations-00.txt 485 Acknowledgments 487 Erik Nordmark coined a proposal for TSLLAO during a conversation with 488 JinHyeock Choi and Greg Daley. 490 Authors' Addresses 492 Greg Daley 494 greg.daley@eng.monash.edu.au 496 Nick "Sharkey" Moore 498 nick.moore@eng.monash.edu.au 500 Centre for Telecommunications and Information Engineering 501 Department of Electrical and Computer Systems Engineering 502 Monash University 503 Clayton 3800 504 Victoria 505 Australia 507 Erik Nordmark 509 erik.nordmark@sun.com 511 Sun Microsystems, Inc. 512 17 Network Circle 513 Mountain View, CA 514 USA 516 phone: +1 650 786 2921 517 fax: +1 650 786 5896 519 Intellectual Property Rights 521 By submitting this Internet-Draft, I certify that any applicable 522 patent or other IPR claims of which I am aware have been disclosed, 523 and any of which I become aware will be disclosed, in accordance with 524 RFC 3668. 526 Copyright Statement 528 Copyright (C) The Internet Society (2004). This document is 529 subject to the rights, licenses and restrictions contained in BCP 530 78, and except as set forth therein, the authors retain all their 531 rights. 533 This document and the information contained herein are provided 534 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 535 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 536 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 537 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 538 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 539 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 540 PARTICULAR PURPOSE. 542 This document expires in December 2004.