idnits 2.17.1 draft-ietf-dna-soln-frame-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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 558. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 535. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 542. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 548. ** 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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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 357: '...delay. A router MUST wait random amou...' RFC 2119 keyword, line 416: '...nt. DNA schemes SHOULD incorporate th...' 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 (April 21, 2005) is 6942 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) == Missing Reference: '0' is mentioned on line 178, but not defined == Unused Reference: '6' is defined on line 450, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 473, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 488, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 500, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 504, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2461 (ref. '1') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. '2') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3513 (ref. '3') (Obsoleted by RFC 4291) ** Downref: Normative reference to an Informational draft: draft-ietf-dna-goals (ref. '4') -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '6') (Obsoleted by RFC 6275) == Outdated reference: A later version (-02) exists of draft-ietf-dna-cpl-00 == Outdated reference: A later version (-01) exists of draft-jinchoi-dna-frd-00 == Outdated reference: A later version (-07) exists of draft-ietf-ipv6-optimistic-dad-05 == Outdated reference: A later version (-02) exists of draft-daley-ipv6-tsllao-01 == Outdated reference: A later version (-06) exists of draft-ietf-dna-link-information-01 == Outdated reference: A later version (-18) exists of draft-ietf-dhc-dna-ipv4-11 Summary: 9 errors (**), 0 flaws (~~), 14 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNA WG JinHyeock. Choi 3 Internet-Draft Samsung AIT 4 Expires: October 23, 2005 Erik. Nordmark 5 Sun 6 April 21, 2005 8 DNA solution framework 9 draft-ietf-dna-soln-frame-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on October 23, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This draft captures the authors' opinions and is intended to serve as 43 input to the discussion for the solution in the DNA WG. It presents 44 a few assumptions for DNA solution. The draft proposes the solution 45 to be based on 1) link identity, 2) RS/RA exchange formed so that a 46 host can determine whether it has moved from a single RA, and 3) 47 Quick delivery of an RA. The draft sketches what rough shape DNA 48 solution could take, including the necessary interaction with 49 Duplicate Address Detection and the Multicast Listener Discovery 50 protocol. It also enumerate a few tasks to be worked on and issues 51 to be resolved for efficient DNA solution. 53 Table of Contents 55 1. DNA Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Basic Assumptions . . . . . . . . . . . . . . . . . . . . . . 4 57 2.1 DNA solution based on link identity detection . . . . . . 4 58 2.2 Using a RS/RA exchange to determine the link identity . . 4 59 2.3 Quick delivery of an RA . . . . . . . . . . . . . . . . . 5 60 3. DNA Solution Sketch . . . . . . . . . . . . . . . . . . . . . 6 61 3.1 Solution components . . . . . . . . . . . . . . . . . . . 6 62 3.2 Solution procedure . . . . . . . . . . . . . . . . . . . . 6 63 3.3 Work items . . . . . . . . . . . . . . . . . . . . . . . . 8 64 4. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 4.1 Checking for link change with Link Identifier . . . . . . 10 66 4.2 RA optimized for DNA . . . . . . . . . . . . . . . . . . . 10 67 4.3 Quick delivery of an RA upon link-layer connection . . . . 11 68 4.4 Links without Link Identification support . . . . . . . . 11 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 71 7. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 15 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 8.1 Normative References . . . . . . . . . . . . . . . . . . . 16 74 8.2 Informative References . . . . . . . . . . . . . . . . . . 16 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 76 Intellectual Property and Copyright Statements . . . . . . . . 19 78 1. DNA Overview 80 Upon establishing a new link-layer connection, a host implementing 81 the DNA solution should detect the identity of the currently attached 82 link to ascertain whether it is attached to the same link as before, 83 or attached to a different link. If the host is attached to a 84 different link, it also needs to acquire the IP configuration for the 85 new link. The DNA solution needs to be fast, precise, secure and 86 have little signaling overhead.[4] 88 2. Basic Assumptions 90 We propose to design DNA solution based upon the following 91 assumptions. 93 2.1 DNA solution based on link identity detection 95 When a host establishes a new link-layer connection, in order to 96 check whether its IP configuration is still valid, the host checks 97 for link change, i.e. determine whether it still remains attached to 98 the same link or not. The term 'link' used in this document is as 99 defined in [1]. NOTE that that definition is completely different 100 than the definition of the term 'link' in IEEE 802 standards. 102 If a link change has occurred, a host assumes that its IP 103 configuration is no longer valid. Thus it needs at least a new 104 default router and a new IP address. If it has remained attached to 105 the same link, the host assumes its IP configuration is still valid, 106 and performs no further DNA operations. 108 2.2 Using a RS/RA exchange to determine the link identity 110 A Router Advertisement message is necessary when the host has 111 attached to a different link, since the RA contains the new 112 configuration information. This means that the number of messages 113 needed for DNA can be minimized if the Router Advertisement message 114 also contains all the information needed to determine whether or not 115 there was a link change. In the general case, the host needs to send 116 a Router Solicitation message so that it can quickly receive a Router 117 Advertisement. Hence we end up with a suggested approach based on 118 using a single RS/RA exchange to both determine the link identity, 119 and to provide the host with the configuration information for a new 120 link. 122 See [5] for the DTs different approaches to handle this. 124 In order for a single RA message to be useful both to detect a link 125 change, and, should the host have attached to a different link, 126 useful to initiate the new IP configuration, the RA message needs to 127 include at least: 129 1) The information to indicate link change 131 2) Router address (to select new default router, in case of a link 132 change) 134 3) Prefix(es) (to form a new IP address, in case of a link change) 136 4) Link-layer address of a router (to immediately send a packet) 138 We need to investigate whether the above is sufficient. 140 2.3 Quick delivery of an RA 142 To quickly check for link change, a host has to receive an RA with 143 minimum latency. This is difficult due to the random delays for RAs 144 in response to RSs and rate limiting of multicast RAs in Neighbor 145 Discovery [1]. For fast DNA solution, we need to find a way to 146 quickly deliver an RA to a host upon a new link-layer connection. 148 3. DNA Solution Sketch 150 3.1 Solution components 152 For efficient DNA solution, we may need the following components. 154 1. RA message optimized for DNA, which 1) properly indicate link 155 change and 2) carries necessary information for a new IP 156 configuration. 158 2. A way to quickly deliver an RA to a host upon a new link-layer 159 connection. 161 3. Optimistic DAD [17] and TSLLAO [18] that is being specified in the 162 IPv6 WG. 164 4. A procedure to apply DAD during the DNA procedure that is both 165 efficient and safe should there be a duplicate. 167 5. A procedure for MLD so that the multicast groups are reported on a 168 new link. 170 6. A procedure that handles DHCPv6 address (and other) configuration 171 for those cases when stateless address autoconfiguration is not 172 used. 174 3.2 Solution procedure 176 With the above, the DNA procedure might be as follows: 178 Step [0] Network attachment 180 A host has established a new link-layer connection. 182 Step [1] Hint 184 The host receives a hint that a link change might have occurred. 185 This triggers the host to initiate DNA procedure. For instance, the 186 hint might consist of the link-layer (device driver) providing a link 187 Up event notification to the IP layer of the host. 189 Since the host doesn't know whether it is still attached to the same 190 link, it needs to take the conservative approach and assumes it might 191 have moved. Thus it switches to operating in optimistic DAD mode 192 [17] at this point in time (but since it might still be on the same 193 link, it would be overkill to immediately send a DAD probe). Since 194 there might be MLD snooping switches in the network, the host must 195 use MLD to join, at least the solicited node multicast addresses that 196 correspond to its IP addresses, at this point in time, so that it can 197 receive Neighbor Solicitation messages that might indicate that an 198 address is a duplicate. 200 Step [2] RA acquisition 202 The host acquires an RA optimized for DNA with minimum latency. This 203 procedure may be initiated either by the host or network. 205 Either an AP (which implements [13]) immediately sends an RA to the 206 host, or the host sends an RS to all-routers and one or more routers 207 on the link responds to the RS with an RA. The first RA from the 208 router(s) should not be delayed. Several approaches to accomplish 209 this have been considered by the design team - see [5]. 211 The RS should have the link-local address of the host as the source 212 address. The RS message needs to contain the TSLLA option [18] to 213 allow for optimal delivery of the RA in the case when the router 214 supports TSLLAO, but should not contain a SLLAO option, since the 215 link-local address might be a duplicate and DAD has not yet been 216 completed. 218 If the router implements TSLLAO, the RA would be unicast to the host; 219 otherwise the RA would either be multicast to all-nodes, or the 220 router would perform an NS/NA exchange with the host before 221 unicasting the RA to the host. 223 Step [3] Link identity detection 225 Using the mechanism which will be selected by the WG (see [5] for 226 ones that are being considered), the host determines whether this is 227 the same link as before. 229 If it is the same, the host assumes that its IP configuration is 230 still valid. No further DNA operation is performed and all the host 231 needs to do is turn off the optimistic DAD mode. (Since the host 232 didn't move to a different link, we can rely on the DAD which was 233 performed when the host was first attached to this link. However, 234 there has been some discussion whether or not DAD should be redone if 235 a host, independently of DNA, has been disconnected from the link for 236 some time.) 238 If the host determines that it is attached to a new link, it 239 immediately initiates a new IP configuration. The RA contains enough 240 information to discard old default routers and prefixes, and 241 configure new ones. (Should there be no "addrconf" prefixes in the 242 RA, the host would presumably use DHCPv6 for address assignment which 243 would take one or two more roundtrips.) 245 At this point in time it also makes sense for the host to perform DAD 246 by sending a DAD probe for each configured IP address. When the DAD 247 probing has completed the host can turn off the optimistic DAD mode. 249 If neither the old link, nor the potentially new link, use the new 250 DNA solution for identifying the link, then the host needs to use 251 prefix based link determination [11] which might require multiple RAs 252 and even multiple RSs being sent before it can determine whether or 253 not it is attached to a new link. 255 Step [4] Multicast group reporting 257 Should the host have moved to a new link, it needs to send MLD 258 reports for all the multicast groups it belongs to, in order to 259 quickly re-establish reception for the multicast groups. (Note that 260 the solicited-node multicast groups must be handled earlier - as part 261 of the DAD procedure.) There might be cases when multicast reception 262 is critical, where it would be beneficial to send the MLD reports 263 earlier (during step 1) so that, in the case the host has moved to a 264 new link, any interruption in multicast reception is minimized, even 265 if this results in unneeded MLD report packets in the case when the 266 host did not move. 268 3.3 Work items 270 It's our opinion that DNA WG (or IPv6 WG in the case of Optimistic 271 DAD and TSLLAO) needs to work on the following subparts of the DNA 272 problem: 274 1. A link identification mechanism from the ones identified in [5] 276 2. Complete Prefix List for the case when the above new mechanism is 277 not available[11] 279 3. Immediate RA responses to RS from the ones identified in [5]. 281 4. Optionally RAs that are sent by APs [13] 283 5. Optimistic DAD [17] and TSLLAO [18]. 285 6. A procedure to apply DAD during the DNA procedure that is both 286 efficient and safe should there be a duplicate. 288 7. A procedure for MLD so that the multicast groups are reported on a 289 new link. 291 8. A procedure that triggers DHCPv6 address (and other) configuration 292 for those cases when stateless address autoconfiguration is not 293 used. 295 4. Issues 297 In this section, we enumerate the issues to be resolved for efficient 298 DNA solution. We don't claim that the list is exhaustive. 300 4.1 Checking for link change with Link Identifier 302 [This discussion on this section pre-dates the design team 303 discussion, thus it might no longer be relevant.] 305 Usually a host receives configuration information in one or more RA 306 (Router Advertisement) messages. But it's difficult for a host to 307 correctly check for link change using a single RA message. No 308 information in RA can properly indicate whether a link change has 309 occurred or not. Neither router address nor prefix can do. 311 It may be better to design a new way to represent a link, 'Link 312 Identifier'. Each link has its unique and explicit Link Identifier 313 and all routers attached to the link advertise the same Link 314 Identifier in their RAs. With an explicit Link Identifier, an RA can 315 represent a link identity and hosts can check for link change 316 immediately without resorting to approximate knowledge. 318 When a host receives an RA with the same Link Identifier, it still 319 remains at the same link. If it receives an RA with a different Link 320 Identifier, a link change has occurred and the host is attached to a 321 different link. 323 We need to investigate an efficient method to design an explicit Link 324 Identifier. We may define a new option for Link Identifier. In [9] 325 Erik Nordmark proposed a new option, Location Indication Option, 326 which can server as Link Identifier. Also Brett Pentland and all 327 submitted a draft on Link Identifier [10]. 329 Other approaches can also be used, and many have been discussed in 330 the Design Team. What is important is that the host can tell whether 331 it remains on the same link, or has moved to a different link, from 332 the first Router Advertisement message it receives. 334 See [5] for different approaches being discussed in the Design Team 335 on how to handle this. 337 4.2 RA optimized for DNA 339 To design RA message optimized for DNA, we need to consider what 340 kinds of information it needs to contain. We already presented 4 341 necessary information in Section 2.2 and also it may be useful for an 342 RA to include the following: 344 1') A global IP address of a router 346 2') All prefixes that the router advertises 348 4.3 Quick delivery of an RA upon link-layer connection 350 Upon a new link-layer connection, it may take too long to receive a 351 RA. A host may passively wait until it receives a periodic RA or, 352 with link-layer hint, actively send an RS message and receive a 353 solicited RA in response. 355 For the first case, the time to receive a RA depends on RA 356 advertisement interval and it may take many minutes. Even in the 357 second case there is a delay. A router MUST wait random amount of 358 time between 0 and 0.5 sec before replying an RA [1]. And if the 359 router multicasts RAs in response to RSs, the MIN_DELAY_BETWEEN_RAS 360 in [1] is also a potential problem which must be looked into. 361 Otherwise this would add the worst-case delay of 3.5 seconds until an 362 RA is received. 364 To remedy this, currently two methods are proposed, FRD [13] and 365 FastRA [14], [15]. In FRD, an AP caches a suitable RA and sends it 366 immediately upon a new link-layer association. FastRA [14] allows a 367 router to send an RA without delay with some safety mechanism. [15] 368 defines a secured mechanism that allows routers to make decisions 369 about which router responds fastest, and additionally allows other 370 routers to avoid random delays. 372 Also see [5] for different approaches to handle this that have been 373 discussed in the Design Team. 375 4.4 Links without Link Identification support 377 A host may visit a link that doesn't support the new DNA solution for 378 link identification. There are a few cases to consider. 380 1 Moving from one link using DNA link identification to another link 381 using DNA link identification (and the link are identified as 382 being different). 384 2 Moving from a link using DNA link identification to a link which 385 is not using it. 387 3 Moving from a link not using DNA link identification to a link 388 which is using it. 390 4 Moving from a link not using DNA link identification to a link 391 which is also not using it. 393 In all those cases, the host needs to be able to perform efficient 394 DNA. 396 If the host can always tell from a single RA whether or not the link 397 is using DNA link identification, then the second and third case 398 above are easy, because the host must have moved to a different link. 400 This approach requires that 1) all the routers on a link are 401 configured uniformly to either use DNA link identification or not, 402 and 2) all the RAs contain at least a bit to indicate when DNA link 403 identification is used. 405 5. IANA Considerations 407 No new message formats or services are defined in this document. 409 6. Security Considerations 411 Because DNA schemes are based on Neighbor Discovery, its trust models 412 and threats are similar to the ones presented in [8]. Nodes 413 connected over wireless interfaces may be particularly susceptible to 414 jamming, monitoring and packet insertion attacks. Use of SEND [7] to 415 secure Neighbor Discovery are important in achieving reliable 416 detection of network attachment. DNA schemes SHOULD incorporate the 417 solutions developed in IETF SEND WG if available, where assessment 418 indicates such procedures are required. 420 7. Acknowledgment 422 The authors wish to express our appreciation to Greg Daley, Thomas 423 Narten, Pekka Nikander and Alper Yegin for their valuable feedback. 424 Also Thanks to Samita Chakrabarti, Youn-Hee Han, Gabriel Montenegro, 425 Nick Moore, Brett Pentland, Ed Remmell and Margaret Wasserman for 426 their contributions to this draft. 428 8. References 430 8.1 Normative References 432 [1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 433 for IP Version 6 (IPv6)", RFC 2461, December 1998. 435 [2] Thomson, S. and T. Narten, "IPv6 Stateless Address 436 Autoconfiguration", RFC 2462, December 1998. 438 [3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 439 Addressing Architecture", RFC 3513, April 2003. 441 [4] Choi, J., "Detecting Network Attachment in IPv6 Goals", 442 draft-ietf-dna-goals-04 (work in progress), December 2004. 444 8.2 Informative References 446 [5] Pentland, B., "An Overview of Approaches to Detecting Network 447 Attachment in IPv6", draft-dnadt-dna-discussion-00 (work in 448 progress), February 2005. 450 [6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 451 IPv6", RFC 3775, June 2004. 453 [7] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. 454 Nikander, "SEcure Neighbor Discovery (SEND)", 455 draft-ietf-send-ndopt-06 (work in progress), July 2004. 457 [8] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 458 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 460 [9] Nordmark, E., "MIPv6: from hindsight to foresight?", 461 draft-nordmark-mobileip-mipv6-hindsight-00 (work in progress), 462 November 2001. 464 [10] Pentland, B., "Router Advertisement Link Identification for 465 Mobile IPv6 Movement Detection", 466 draft-pentland-mobileip-linkid-03 (work in progress), 467 October 2004. 469 [11] Nordmark, E. and J. Choi, "DNA with unmodified routers: Prefix 470 list based approach", draft-ietf-dna-cpl-00 (work in progress), 471 April 2005. 473 [12] Choi, J., "Router Advertisement Issues for Movement Detection/ 474 Detection of Network Attachment", draft-jinchoi-ipv6-cra-00 475 (work in progress), October 2003. 477 [13] Choi, J., "Fast Router Discovery with RA Caching", 478 draft-jinchoi-dna-frd-00 (work in progress), July 2004. 480 [14] Kempf, J., Khalil, M., and B. Pentland, "IPv6 Fast Router 481 Advertisement", draft-mkhalil-ipv6-fastra-05 (work in 482 progress), July 2004. 484 [15] Daley, G., "Deterministic Fast Router Advertisement 485 Configuration", draft-daley-dna-det-fastra-01 (work in 486 progress), October 2004. 488 [16] Narayanan, S., "Recommendations to achieve efficient Router 489 Reachability Detection in IPv6 networks", 490 draft-narayanan-dna-rrd-01 (work in progress), February 2005. 492 [17] Moore, N., "Optimistic Duplicate Address Detection for IPv6", 493 draft-ietf-ipv6-optimistic-dad-05 (work in progress), 494 February 2005. 496 [18] Daley, G., "Tentative Source Link-Layer Address Options for 497 IPv6 Neighbour Discovery", draft-daley-ipv6-tsllao-01 (work in 498 progress), February 2005. 500 [19] Yegin, A., "Link-layer Event Notifications for Detecting 501 Network Attachments", draft-ietf-dna-link-information-01 (work 502 in progress), February 2005. 504 [20] Aboba, B., "Detection of Network Attachment (DNA) in IPv4", 505 draft-ietf-dhc-dna-ipv4-11 (work in progress), April 2005. 507 Authors' Addresses 509 JinHyeock Choi 510 Samsung AIT 511 Communication & N/W Lab 512 P.O.Box 111 Suwon 440-600 513 KOREA 515 Phone: +82 31 280 9233 516 Email: jinchoe@samsung.com 517 Erik Nordmark 518 Sun Microsystems 519 17 Network Circle 520 Menlo Park, CA 94025 521 USA 523 Phone: +1 650 786 2921 524 Email: erik.nordmark@sun.com 526 Intellectual Property Statement 528 The IETF takes no position regarding the validity or scope of any 529 Intellectual Property Rights or other rights that might be claimed to 530 pertain to the implementation or use of the technology described in 531 this document or the extent to which any license under such rights 532 might or might not be available; nor does it represent that it has 533 made any independent effort to identify any such rights. Information 534 on the procedures with respect to rights in RFC documents can be 535 found in BCP 78 and BCP 79. 537 Copies of IPR disclosures made to the IETF Secretariat and any 538 assurances of licenses to be made available, or the result of an 539 attempt made to obtain a general license or permission for the use of 540 such proprietary rights by implementers or users of this 541 specification can be obtained from the IETF on-line IPR repository at 542 http://www.ietf.org/ipr. 544 The IETF invites any interested party to bring to its attention any 545 copyrights, patents or patent applications, or other proprietary 546 rights that may cover technology that may be required to implement 547 this standard. Please address the information to the IETF at 548 ietf-ipr@ietf.org. 550 Disclaimer of Validity 552 This document and the information contained herein are provided on an 553 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 554 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 555 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 556 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 557 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 558 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 560 Copyright Statement 562 Copyright (C) The Internet Society (2005). This document is subject 563 to the rights, licenses and restrictions contained in BCP 78, and 564 except as set forth therein, the authors retain all their rights. 566 Acknowledgment 568 Funding for the RFC Editor function is currently provided by the 569 Internet Society.