idnits 2.17.1 draft-ietf-dna-tentative-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 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 591. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 568. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 575. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 581. ** 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. 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 : ---------------------------------------------------------------------------- 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 (February 25, 2006) is 6633 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) == Unused Reference: '1' is defined on line 389, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 408, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2461 (ref. '2') (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 2462 (ref. '6') (Obsoleted by RFC 4862) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Daley 3 Internet-Draft Panasonic 4 Expires: August 29, 2006 E. Nordmark 5 Sun Microsystems 6 N. Moore 7 February 25, 2006 9 Tentative Options for Link-Layer Addresses in IPv6 Neighbour Discovery 10 draft-ietf-dna-tentative-00.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 August 29, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 The proposed IPv6 Duplicate Address Detection (DAD) Optimization 44 "Optimistic DAD" defines a set of recoverable procedures which allow 45 a node to make use of an address before DAD completes. Essentially, 46 Optimistic DAD forbids usage of certain Neighbour Discovery options 47 which could pollute active neighbour cache entries, while an address 48 is tentative. 50 This document defines a new option and procedures to replace cache 51 polluting options, in a way which is useful to tentative nodes. 52 These procedures are designed to be to backward compatible with 53 existing devices which support IPv6 Neighbour Discovery. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1 Tentative Option format . . . . . . . . . . . . . . . . . 3 59 1.2 Tentative Option semantics . . . . . . . . . . . . . . . . 4 60 2. Sending solicitations containing Tentative Options . . . . . . 4 61 2.1 Sending Neighbour Solicitations with Tentative Options . . 5 62 2.2 Sending Router Solicitations with Tentative Options . . . 5 63 3. Receiving Tentative Options . . . . . . . . . . . . . . . . . 5 64 3.1 Handling Tentative Options . . . . . . . . . . . . . . . . 5 65 3.2 Receiving Neighbour Solicitations containing Tentative 66 Options . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.3 Receiving Router Solicitations containing Tentative 68 Options . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 7.1 Normative References . . . . . . . . . . . . . . . . . . . 9 74 7.2 Informative References . . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 76 A. Constraints imposed by IPv6 Neighbour Discovery . . . . . . . 10 77 A.1 Constraints on Neighbour Solicitations . . . . . . . . . . 10 78 A.2 Constraints on Router Solicitations . . . . . . . . . . . 11 79 B. Interactions with legacy nodes . . . . . . . . . . . . . . . . 11 80 B.1 Legacy Neighbour Solicitation processing . . . . . . . . . 11 81 B.2 Legacy Router Solicitation processing . . . . . . . . . . 12 82 C. Sending directed advertisements without the neighbour cache . 12 83 Intellectual Property and Copyright Statements . . . . . . . . 14 85 1. Introduction 87 Source Link-Layer Address Options (SLLAOs) are sent in Neighbour 88 discovery messages in order to notify neighbours of a mapping between 89 a specific IPv6 Network layer address and a link-layer (or MAC) 90 address. Upon reception of a neighbour discovery message containing 91 such an option, nodes update their neighbour cache entries with the 92 IP to link-layer address mapping in accordance with procedures 93 defined in IPv6 Neighbour Discovery [2]. 95 Optimistic DAD [4] prevents usage of these options in Router and 96 Neighbour Solicitation messages from a tentative address (while 97 Duplicate Address Detection is occurring). This is because receiving 98 a Neighbour Solicitation (NS) or Router Solicitation (RS) containing 99 an SLLAO would otherwise overwrite an existing cache entry, even if 100 the cache entry contained the legitimate address owner, and the 101 solicitor was a duplicate address. 103 Neighbour Advertisement (NA) messages don't have such an issue, since 104 the Advertisement message contains a flag which explicitly disallows 105 overriding of existing cache entries, by the target link-layer 106 address option carried within. 108 The effect of preventing SLLAOs for tentative addresses is that 109 communications with these addresses are sub-optimal for the tentative 110 period. Sending solicitations without these options causes an 111 additional round-trip for neighbour discovery if the advertiser does 112 not have an existing neighbour cache entry for the solicitor. In 113 some cases, multicast advertisements will be scheduled, where 114 neighbour discovery is not possible on the advertiser. 116 This document proposes Tentative Options which designed to replace 117 the existing Source Link-Layer Address Options available in IPv6 118 Neighbour Discovery, when a device is performing Optimistic DAD. 120 1.1 Tentative Option format 121 0 1 2 3 122 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 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Type | Length | Link-Layer Address ... 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 Fields: 128 Type TBD (Requires IANA Allocation) suggest 17 (0x11) 130 Length The length of the option (including the type and 131 length fields) in units of 8 octets. 133 Link-Layer Address 134 The variable length link-layer address. 136 Description 137 The Tentative option contains the link-layer 138 address of the sender of the packet. It is used 139 in the Neighbour Solicitation and Router 140 Solicitation packets. 142 1.2 Tentative Option semantics 144 The Tentative Option (TO) functions in the same role as the Source 145 Link-Layer Address option defined for [2], but it MUST NOT override 146 an existing neighbour cache entry. 148 The differing neighbour cache entry MUST NOT be affected by the 149 reception of the Tentative Option. This ensures that tentative 150 addresses are unable to modify legitimate neighbour cache entries. 152 In the case where an entry is unable to be added to the neighbour 153 cache, a node MAY send responses direct to the link-layer address 154 specified in the TO. 156 For these messages, no Neighbour Cache entry may be created, although 157 response messages may be directed to a particular unicast address. 159 These procedures are discussed further in Section 3.3. 161 2. Sending solicitations containing Tentative Options 163 Tentative Options may be sent in Router and Neighbour Solicitations, 164 as described below. 166 In a case where it is safe to send a Source Link-Layer Address 167 Option, a host SHOULD NOT send a TO, since the message may be 168 misinterpreted by legacy nodes. 170 Importantly, a node MUST NOT send a Tentative Option in the same 171 message where a Source Link-Layer Address Option is sent. 173 2.1 Sending Neighbour Solicitations with Tentative Options 175 Neighbour Solicitations sent to unicast addresses MAY contain a 176 Tentative Option. 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 Tentative 185 Option to the router's advertised address. 187 As discussed in [2], the peer device may not have a cache entry even 188 if the soliciting host does, in which case reception of the Tentative 189 Option may create a neighbour cache entry, without the need for 190 neighbour discovering the original solicitor. 192 2.2 Sending Router Solicitations with Tentative Options 194 Any Router Solicitation from a Preferred, Deprecated or Optimistic 195 address MAY be sent with a Tentative Option [4]. 197 An extension which allows Router Solicitations to be sent with a TO 198 from the unspecified address is described in Appendix C. 200 3. Receiving Tentative Options 202 Receiving a Tentative Option allows nodes to unicast responses to 203 solicitations without performing neighbour discovery. 205 It does this by allowing the solicitation to create STALE neighbour 206 cache entries if one doesn't exist, but only update an entry if the 207 link-layer address in the option matches the entry. 209 Additionally, messages containing TO may be used to direct 210 advertisements to particular link-layer destinations without updating 211 neighbour cache entries. This is described in Appendix C. 213 3.1 Handling Tentative Options 215 Use of Tentative Options is only defined for Neighbour and Router 216 Solicitation messages. 218 In any other received message, the presence of the option is silently 219 ignored, that is, the packet is processed as if the option was not 220 present. 222 It is REQUIRED that the same validation algorithms for Neighbour and 223 Router Solicitations received with TO as in the IPv6 Neighbour 224 Discovery specification [2], are used. 226 In the case that a solicitation containing a Tentative Option is 227 received, The only processing differences occur in checking and 228 updating the neighbour cache entry. Particularly, there is no reason 229 to believe that the host will remain tentative after receiving a 230 responding advertisement. 232 As defined in Section 1.1, Tentative Options do not overwrite 233 existing neighbour cache entries where the link-layer addresses of 234 the option and entry differ. 236 If a solicitation from a unicast source address is received where no 237 difference exists between the TO and an existing neighbour cache 238 entry, the option MUST be treated as if it were an SLLAO after 239 message validation, and processed accordingly. 241 In the case that a cache entry is unable to be created or updated due 242 to existence of a conflicting neighbour cache entry, it MUST NOT 243 update the neighbour cache entry. 245 An extension which allows a direct advertisement to the soliciting 246 host without modifying the neighbour cache entry is described in 247 Appendix C. 249 3.2 Receiving Neighbour Solicitations containing Tentative Options 251 The Tentative Option is only allowed in Neighbour Solicitations with 252 specified source addresses for which SLLAO is not required. 254 A Neighbour Solicitation message received with a TO and an 255 unspecified source address MUST be silently discarded. 257 Upon reception of a Tentative Option in a Neighbour Solicitation for 258 which the receiver has the Target Address configured, a node checks 259 to see if there is a neighbour cache entry with conflicting link- 260 layer address. 262 If no such entry exists, the neighbour cache of the receiver SHOULD 263 be updated, as if the Tentative Option was a SLLAO. 265 Sending of the solicited Neighbour Advertisement then proceeds 266 normally, as defined in section 7.2.4 of [2]. 268 If there is a conflicting neighbour cache entry, the node processes 269 the solicitation as defined in Section 7.2.4 of [2], except that the 270 Neighbour Cache entry MUST NOT be modified. 272 3.3 Receiving Router Solicitations containing Tentative Options 274 In IPv6 Neighbour Discovery [2], responses to Router Solicitations 275 are either sent to the all-nodes multicast address, or may be sent to 276 the solicitation's source address if it is a unicast address. 278 Including a Tentative Option in the solicitation allows a router to 279 choose to send a packet directly to the link-layer address even in 280 situations where this would not normally be possible. 282 For Router Solicitations with unicast source addresses, neighbour 283 caches SHOULD be updated with the link-layer address from a Tentative 284 Option if there is no differing neighbour cache entry. In this case, 285 Router Advertisement continues as in Section 6.2.6 of [2]. 287 For received solicitations with a differing link-layer address to 288 that stored in the neighbour cache, the node processes the 289 solicitation as defined in Section 6.2.6 of [2], except that the 290 Neighbour Cache entry MUST NOT be modified. 292 4. IANA Considerations 294 For standardization, it would be required that the IANA provide 295 allocation of the Tentative Option for link-layer addressing (Section 296 1.1) from the IPv6 Neighbour Discovery options for IPv6. 298 Current experimental implementations have used the value 0x11 (17) 299 for the Tentative Option. 301 IANA action requires either IESG Approval or Standards Action [5]. 303 5. Security Considerations 305 The use of the Tentative Option in Neighbour and Router Solicitation 306 messages acts in a similar manner to SLLAO, updating neighbour cache 307 entries, in a way which causes packet transmission. 309 Particular care should be taken that transmission of messages 310 complies with existing IPv6 Neighbour Discovery Procedures, so that 311 unmodified hosts do not receive invalid messages. 313 An attacker may cause messages may be sent to another node by an 314 advertising node (a reflector), without creating any ongoing state on 315 the reflector. 317 This is attack requires one solicitation for each advertisement and 318 the advertisement has to go to a unicast MAC destination. That said, 319 the size of the advertisement may be significantly larger than the 320 solicitation, or the attacker and reflector may be on a medium with 321 greater available bandwidth than the victim. 323 For link-layers where it isn't possible to spoof the link-layer 324 source address this allows a slightly increased risk of reflection 325 attacks from nodes which are on-link. 327 Additionally, since a SEND host must always advertise using SEND 328 options and signatures, a non-SEND attacker may cause excess 329 computation on both a victim node and a router by causing SEND 330 advertisement messages to be transmitted to a particular MAC address 331 and the lall-nodes multicast. SEND specifies guidelines to hosts 332 receiving unsolicited advertisements in order to mitigate such 333 attacks [3]. 335 While this is the same effect as experienced when accepting SLLAO 336 from non-SEND nodes, the lack of created neighbour cache entries on 337 the advertiser may make such attacks more difficult to trace. 339 Modification of Neighbour Discovery messages on the network is 340 possible, unless SEND is used. [3] provides a protocol specification 341 in which soliciting nodes sign ND messages with a private key and use 342 addresses generated from this key. 344 Even if SEND is used, the lifetime of a neighbour cache entry may be 345 extended by continually replaying a solicitation message to a 346 particular router or hosts. Since this may be achieved for any 347 Neighbour or Router Solicitation message, corresponding 348 advertisements to the original transmitters of these solicitation 349 messages may occur. 351 SEND defines use of Timestamp values to protect a device from attack 352 through replay of previously sent messages. Although this applies to 353 Neighbour and Router Solicitation messages, granularity of the 354 timestamp allows the messages to be used for up to five minutes [3]. 356 All Router and Neighbour Solicitations using SEND contain a Nonce 357 option, containing a random identifier octet string. Since SEND 358 messages are digitally signed, and may not be easily modified, replay 359 attacks will contain the same Nonce option, as was used in the 360 original solicitation. 362 While the Nonce Option included in a transmission to another node may 363 not vary within one short solicitation period (the host may itself 364 replay solicitations in the case of packet loss), the presence of the 365 timestamp option ensures that for later solicitations, a different 366 Timestamp and Nonce will be used. 368 Therefore, a receiver seeing a solicitation with the same Timestamp 369 and Nonce (and signature) for more than either of 370 MAX_RTR_SOLICITATIONS (for Router Solicitations), MAX_UNICAST_SOLICIT 371 or MAX_MULTICAST_SOLICIT (for Neighbour Solicitations), SHOULD ignore 372 further solicitations with this (Nonce,Timestamp,Source) triple, 373 ensuring that no modification is made to neighbour cache entries. 374 This applies to any solicitation packet capable of carrying a SEND 375 payload, whether they use a Tentative Option or SLLAO. 377 Stations noticing such an attack SHOULD notify their administrator of 378 the attempt at Denial-of-service. 380 6. Acknowledgments 382 Erik Nordmark coined a proposal for Tentative version of the SLLAO 383 during a conversation with JinHyeock Choi and Greg Daley. 385 7. References 387 7.1 Normative References 389 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 390 Levels", BCP 14, RFC 2119, March 1997. 392 [2] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 393 for IP Version 6 (IPv6)", RFC 2461, December 1998. 395 [3] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 396 Neighbor Discovery (SEND)", RFC 3971, March 2005. 398 [4] Moore, N., "Optimistic Duplicate Address Detection for IPv6", 399 draft-ietf-ipv6-optimistic-dad-07 (work in progress), 400 December 2005. 402 7.2 Informative References 404 [5] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 405 Values In the Internet Protocol and Related Headers", BCP 37, 406 RFC 2780, March 2000. 408 [6] Thomson, S. and T. Narten, "IPv6 Stateless Address 409 Autoconfiguration", RFC 2462, December 1998. 411 Authors' Addresses 413 Greg Daley 414 Panasonic Digital Networking Laboratory 415 2 Research Way 416 Princeton, New Jersey 08540 417 USA 419 Phone: +1 609 734 7334 420 Email: gregd@research.panasonic.com 422 Erik Nordmark 423 Sun Microsystems, Inc. 424 17 Network Circle 425 Mountain View, CA 426 USA 428 Phone: +1 650 786 2921 429 Email: erik.nordmark@sun.com 431 Nick "Sharkey" Moore 433 Email: sharkey@zoic.org 435 Appendix A. Constraints imposed by IPv6 Neighbour Discovery 437 Hosts which send and receive Tentative Options may be interacting 438 with legacy nodes which support IPv6 Neighbour Discovery procedures, 439 but do not understand the new option. 441 For these nodes, the presence of the option is silently ignored, that 442 is, the packet is processed as if the option was not present. 443 Therefore all messages sent with Tentative Options MUST be compliant 444 with the existing requirements for options and addressing specified 445 in the IPv6 Neighbour Discovery RFC [2]. 447 A.1 Constraints on Neighbour Solicitations 449 As described in Section 7.2.2 of [2], packets sent to solicited 450 nodes' multicast addresses MUST contain Source Link-Layer Address 451 options. 453 Neighbour solicitations to multicast addresses MUST NOT contain 454 Tentative Options 456 Neighbour Solicitations to unicast addresses SHOULD include a link- 457 layer address (if the sender has one has one) as a Source Link-Layer 458 Address option. 460 Unicast neighbour solicitations without Source Link-Layer Address 461 Options MAY contain Tentative Options, if the solicitor has a 462 Link-Layer address. 464 A.2 Constraints on Router Solicitations 466 As described in Section 6.3.7 of [2], Router Solicitations SHOULD 467 contain Source Link-Layer Address Options. 469 Router Solicitations without Source Link-Layer Address options MAY 470 contain a Tentative Option. 472 Appendix B. Interactions with legacy nodes 474 Devices which do not implement Tentative Options will act as if no 475 option was placed within the Neighbour Discovery message. The 476 following sections summarize how legacy hosts will interact with 477 messages containing Tentative Options. 479 Appendix B.1 Legacy Neighbour Solicitation processing 481 A node can include the Tentative Option in a unicast NS (and no SLLAO 482 option) when the transmitter's address is either preferred, tentative 483 or optimistic. 485 An RFC 2461 host receiving such a packet will "see" a packet 486 without an SLLAO option, which is allowed in RFC2461. 488 If the recipient host has an existing neighbour cache entry for 489 the transmitter, it can then send a Neighbour Advertisement. 491 Where no neighbour cache entry exists, the recipient will send a 492 multicast NS (containing its own SLLAO) in order for the original 493 transmitter to respond with an NA. Upon reception of the original 494 transmitter's NA, an NA is sent back to the origin. 496 The Tentative Option MUST NOT be included in an NS message which has 497 no source address. 499 An RFC 2461 host sees an NS without a source address as a 500 Duplicate Address Detection message. 502 Reception of duplicate address detection messages may cause side- 503 effects on other hosts, which may cause them to treat addresses as 504 invalid. 506 Appendix B.2 Legacy Router Solicitation processing 508 A node can include the Tentative Option in an RS with a unicast 509 source address (and no SLLAO option) when the transmitter's address 510 is either tentative or optimistic. 512 An RFC 2461 router receiving such a packet will "see" a packet 513 without an SLLAO option, which is allowed in RFC2461. 515 If the router has an existing neighbour cache entry for this host, 516 it may send a Unicast RA in response, but may send a multicast in 517 preference. 519 If no neighbour cache entry exists, some routers will not be able 520 to provide a unicast response. These routers will schedule a 521 multicast response. 523 Other routers may attempt to perform neighbour discovery (by 524 sending a multicast NS), and unicast a response when a neighbour 525 cache entry has been created. 527 A node can include the Tentative Option in an RS with an unspecified 528 source address (and no SLLAO option) when the transmitter's address 529 is tentative. This is described in Appendix C. 531 RFC 2461 routers receiving this solicitation will "see" a message 532 without a SLLAO ( SLLAOs are not allowed in RFC2461 for messages 533 with unspecified source). 535 These routers will schedule a multicast RA response. 537 Appendix C. Sending directed advertisements without the neighbour cache 539 In the case where an entry is unable to be added to the neighbour 540 cache, a node MAY send responses direct to the link-layer address 541 specified in the Tentative Option. Also, RS packets sent without a 542 specificed source address may potentially contain a Tentative Option. 544 In this case the unicast link-layer address from the solicitation MAY 545 be extracted from the Tentative Option and used as the destination of 546 the link-layer frame for a responding Router Advertisment. 548 Sending such a packet MUST NOT consult the neighbour or destination 549 caches for address. 551 Such packets SHOULD scheduled as if they were unicast advertisements 552 as specified in [2]. 554 If an implementation can not send a Router Advertisement using 555 information from the Tentative Option i.e, without consulting the 556 neighbour cache, then it SHOULD behave as if the Tentative Option was 557 not present in the solicitation message. 559 Intellectual Property Statement 561 The IETF takes no position regarding the validity or scope of any 562 Intellectual Property Rights or other rights that might be claimed to 563 pertain to the implementation or use of the technology described in 564 this document or the extent to which any license under such rights 565 might or might not be available; nor does it represent that it has 566 made any independent effort to identify any such rights. Information 567 on the procedures with respect to rights in RFC documents can be 568 found in BCP 78 and BCP 79. 570 Copies of IPR disclosures made to the IETF Secretariat and any 571 assurances of licenses to be made available, or the result of an 572 attempt made to obtain a general license or permission for the use of 573 such proprietary rights by implementers or users of this 574 specification can be obtained from the IETF on-line IPR repository at 575 http://www.ietf.org/ipr. 577 The IETF invites any interested party to bring to its attention any 578 copyrights, patents or patent applications, or other proprietary 579 rights that may cover technology that may be required to implement 580 this standard. Please address the information to the IETF at 581 ietf-ipr@ietf.org. 583 Disclaimer of Validity 585 This document and the information contained herein are provided on an 586 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 587 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 588 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 589 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 590 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 591 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 593 Copyright Statement 595 Copyright (C) The Internet Society (2006). This document is subject 596 to the rights, licenses and restrictions contained in BCP 78, and 597 except as set forth therein, the authors retain all their rights. 599 Acknowledgment 601 Funding for the RFC Editor function is currently provided by the 602 Internet Society.