idnits 2.17.1 draft-ietf-mboned-ipv6-multicast-issues-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 3978, Section 5.1.a on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 510. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 487. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 494. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 500. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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 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: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 (February 15, 2005) is 7009 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: 'I-D.ietf-pim-sm-bsr' is defined on line 414, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-pim-anycast-rp-02 == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-v2-new-11 ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Downref: Normative reference to an Informational RFC: RFC 3446 ** Downref: Normative reference to an Informational RFC: RFC 3569 ** Downref: Normative reference to an Experimental RFC: RFC 3618 ** Downref: Normative reference to an Historic RFC: RFC 3913 -- No information found for draft-bhattach-diot-pimso - is the name correct? == Outdated reference: A later version (-12) exists of draft-ietf-magma-snoop-11 == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-bsr-04 Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MBONE Deployment WG P. Savola 2 Internet-Draft CSC/FUNET 3 Expires: August 19, 2005 February 15, 2005 5 IPv6 Multicast Deployment Issues 6 draft-ietf-mboned-ipv6-multicast-issues-02.txt 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 12 author represents that any applicable patent or other IPR claims of 13 which he or she is aware have been or will be disclosed, and any of 14 which he or she become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 19, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This memo describes known issues with IPv6 multicast, and provides 42 historical reference of how some earlier problems have been resolved. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 1.1 Multicast-related Abbreviations . . . . . . . . . . . . . 3 48 2. Justification for IPv6 Inter-domain ASM . . . . . . . . . . . 3 49 2.1 Groups of Different Non-global Scopes . . . . . . . . . . 3 50 3. Different Solutions to Inter-domain Multicast . . . . . . . . 4 51 3.1 Changing the Multicast Usage Model . . . . . . . . . . . . 4 52 3.2 Implementing MSDP for IPv6 . . . . . . . . . . . . . . . . 5 53 3.3 Implementing Another Multicast Routing Protocol . . . . . 5 54 3.4 Embedding the RP Address in an IPv6 Multicast Address . . 6 55 4. Issues with IPv6 Multicast . . . . . . . . . . . . . . . . . . 6 56 4.1 Issues with Embedded RP . . . . . . . . . . . . . . . . . 6 57 4.1.1 RP Failover with Embedded RP . . . . . . . . . . . . . 6 58 4.1.2 Embedded RP and Control Mechanisms . . . . . . . . . . 7 59 4.2 Neighbor Discovery Using Multicast . . . . . . . . . . . . 7 60 4.3 Functionality Like MLD Snooping . . . . . . . . . . . . . 8 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 7.1 Normative References . . . . . . . . . . . . . . . . . . . 8 65 7.2 Informative References . . . . . . . . . . . . . . . . . . 9 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10 67 A. SSM Deployment Issues . . . . . . . . . . . . . . . . . . . . 10 68 Intellectual Property and Copyright Statements . . . . . . . . 12 70 1. Introduction 72 There are many issues concerning the deployment and implementation, 73 and to a lesser degree, specification of IPv6 multicast. This memo 74 describes known problems to raise awareness, and documents how 75 previous problems have been resolved. 77 Section 2 describes the justifications for providing an inter-domain 78 multicast solution using Any Source Multicast (ASM) with IPv6. 79 Section 3 in turn describes which options were considered for filling 80 the requirements for the IPv6 inter-domain multicast solutions. 81 These sections are provided for historical reference of the 82 discussion and consensus in the IETF MBONED working group. 84 Section 4 lists issues that have come up with IPv6 multicast but have 85 not yet been at least fully resolved, and may require raised 86 awareness. 88 1.1 Multicast-related Abbreviations 90 ASM Any Source Multicast 91 BSR Bootstrap Router 92 CGMP Cisco Group Management Protocol 93 DR Designated Router 94 IGMP Internet Group Management Protocol 95 MLD Multicast Listener Discovery 96 MSDP Multicast Source Discovery Protocol 97 PIM Protocol Independent Multicast 98 PIM-SM Protocol Independent Multicast - Sparse Mode 99 RP Rendezvous Point 100 SSM Source-specific Multicast 102 2. Justification for IPv6 Inter-domain ASM 104 This section documents the reasons and the discussion which led to 105 the agreement that solution to IPv6 inter-domain ASM was necessary. 107 The main reason was that SSM [RFC3569] was not considered to solve 108 all the relevant problems (e.g., many-to-many applications, source 109 discovery), and that SSM was not sufficiently widely deployed and 110 used. As these issues are more generic than just IPv6, they are 111 described in Appendix A. 113 2.1 Groups of Different Non-global Scopes 115 Many ASM applications are used with a smaller scope than global; some 116 of these have a wider scope than others. However, groups of smaller 117 scope typically need to be in their own PIM-SM domains to prevent 118 inappropriate data leakage. 120 Therefore if a site has groups of different scopes, it is important 121 to have multiple PIM domain borders. However, this need can be 122 obviated by using globally-scoped multicast addresses instead. It is 123 easier to set scoping using globally scoped addresses, rather than 124 having to configure (nesting) local multicast scopes. 126 In consequence there will be a need for inter-domain multicast 127 solutions, as a means to simplify and obviate the need for 128 operational hassles with local scoping. As many applications are 129 relying on ASM characteristics, this further increases the need for 130 an inter-domain ASM solution. 132 3. Different Solutions to Inter-domain Multicast 134 When ASM is used, the Internet must be divided into multiple PIM-SM 135 domains for both administrative and technical reasons, which means 136 there will be multiple PIM-SM RPs which need to share the source IP 137 addresses between themselves. 139 On the other hand, SSM does not require RPs and also works in the 140 inter-domain without such communication. Section 2 describes the 141 justification why Inter-domain ASM was still considered to be 142 required. This section describes different solutions which were 143 discussed to providing inter-domain multicast for IPv6. 145 For inter-domain multicast, MBONED WG came to consensus to continue 146 using SSM, and also use Embedded-RP for ASM as appropriate. 148 This section provides historical reference of the discussion and 149 decisions. 151 3.1 Changing the Multicast Usage Model 153 As ASM model has been found to be complex and a bit problematic, some 154 felt that this is a good incentive to move to SSM for good (at least 155 for most cases). Below two paragraphs are adapted from 156 [I-D.bhattach-diot-pimso]: 158 The most serious criticism of the SSM architecture is that it does 159 not support shared trees which may be useful for supporting 160 many-to-many applications. In the short-term this is not a 161 serious concern since the multicast application space is likely to 162 be dominated by one-to-many applications. Some other classes of 163 multicast applications that are likely to emerge in the future are 164 few-to-few (e.g. private chat rooms, whiteboards), few-to-many 165 (e.g., video conferencing, distance learning) and many-to-many 166 (e.g., large chat rooms, multi-user games). The first two classes 167 can be easily handled using a few one-to-many source-based trees. 169 The issue of many-to-many multicasting service on top of a SSM 170 architecture is an open issue at this point. However, some feel 171 that even many-to-many applications should be handled with 172 multiple one- to-many instead of shared trees. 174 In any case, even though SSM would be preferable in many cases, SSM 175 was not sufficiently widely available to completely replace ASM (see 176 Appendix A), and that the IETF should not try to force the 177 application writers to change their multicast usage models. 179 3.2 Implementing MSDP for IPv6 181 In IPv4, notification of multicast sources between these PIM-SM RPs 182 is done with Multicast Source Discovery Protocol (MSDP) [RFC3618]. 183 The protocol is widely considered a sub-optimal solution and even 184 dangerous to deploy; when it was specified, it was only meant as a 185 "stop-gap" measure. 187 The easiest stop-gap solution (to a stop-gap solution) would have 188 been to specify IPv6 TLV's for MSDP. This would be fairly 189 straightforward, and existing implementations would probably be 190 relatively easy to modify. 192 There is and has been resistance to this, as MSDP was not supposed to 193 last this long in the first place; there is clear consensus that 194 there should be no further work on it [I-D.ietf-mboned-msdp-deploy]. 196 3.3 Implementing Another Multicast Routing Protocol 198 One possibility might have been to specify and/or implement a 199 different multicast routing protocol. 201 In fact, Border Gateway Multicast Protocol (BGMP) [RFC3913] has been 202 specified; however, it is quite complex and there have been no 203 implementations nor desire to write any. Lacking deployment 204 experience and specification analysis, it is difficult to say which 205 problems BGMP might solve (and possibly, which new ones BGMP might 206 introduce). One probable reason why BGMP failed to attract 207 continuing interest was it's dependance on similarly heavy-weight 208 multicast address allocation/assignment protocols. 210 As of this writing, no other inter-domain protocols have been 211 specified, and BGMP is not considered a realistic option. 213 3.4 Embedding the RP Address in an IPv6 Multicast Address 215 One way to work around these problems was to allocate and assign 216 multicast addresses in such a fashion that the address of the RP 217 could be automatically calculated from the IPv6 multicast address. 219 Making some assumptions about how the RPs would configure Interface 220 Identifiers, this is can achieved as described in [RFC3956]; PIM-SM 221 implementations need to implement the Embedded RP group-to-RP mapping 222 mechanism which processes this encoding. 224 To completely replace the need for MSDP for IPv6, a different way to 225 implement "Anycast RP" [RFC3446] is also needed. One such approach 226 is described in [I-D.ietf-pim-anycast-rp]. 228 4. Issues with IPv6 Multicast 230 This section describes issues that have come up with IPv6 multicast 231 but have not yet been at least fully resolved. 233 4.1 Issues with Embedded RP 235 4.1.1 RP Failover with Embedded RP 237 Embedded RP provides a means for ASM multicast without inter-domain 238 MSDP. However, to continue providing failover mechanisms for RPs, a 239 form of state sharing, Anycast-RP, should still be supported. 240 Instead of MSDP, this can be achieved using a PIM-SM extension 241 [I-D.ietf-pim-anycast-rp]. 243 One should note that as Embedded RP does not require MSDP peerings 244 between the RPs, it's possible to deploy more RPs in a PIM domain. 245 For example, the scalability and redundancy could be achieved by 246 co-locating RP functionality in the DRs: each major source, which 247 "owns" a group, could have its own DR act as the RP. This has about 248 the same redundancy characteristics as using SSM -- so there may not 249 be an actually very urgent need for Anycast-RP if operational methods 250 to include fate-sharing of the groups is followed. 252 In any case, "cold failover" redundancy without state sharing is 253 still an option. This does not offer any load-balancing of RPs or 254 shared trees, but provides only long-term redundancy. In this 255 mechanism, multiple routers would be configured with the RP address 256 (with appropriate unicast metrics), but only one of them would be 257 active at any time: if the main RP goes down, another takes its 258 place. However, the multicast state stored in the RP would be lost, 259 unless it is synchronized by some out-of-band mechanism. 261 4.1.2 Embedded RP and Control Mechanisms 263 With ASM and MSDP deployment, the ISPs can better control who is 264 using their RPs. 266 With Embedded RP, anyone could use a third-party RP to host their 267 groups unless some mechanisms, for example access-lists, are in place 268 to control the use of the RP [RFC3956]. 270 Such abuse is of questionable benefit, though, as anyone with a /64 271 could form an RP of its own. 273 Whether this is a sufficiently serious problem worth designing a 274 (potentially complex) solution for is still under debate, as of this 275 writing. 277 4.2 Neighbor Discovery Using Multicast 279 Neighbor Discovery [RFC2461] uses link-local multicast in Ethernet 280 media, not broadcast as ARP does with IPv4. This has been seen to 281 cause operational problems with some equipment. This section 282 documents these as "lessons (hopefully) learned" so that other 283 vendors could better avoid them. 285 There are equipment which do not forward (IPv6) multicast frames 286 appropriately; these could be considered "bugs", but are sufficiently 287 commonplace so that the behaviour is worth mentioning. 289 In particular, many WLAN IEEE 802.11b access points, working in the 290 bridged mode, do not forward IPv6 Ethernet multicast frames across 291 the bridge. When procuring WLAN equipment, it is probably a good 292 idea to check out this functionality explicitly. 294 In some Ethernet switches, IPv6 frames are likewise not forwarded. 295 The problem has likely been with building multicast forwarding state 296 based on Layer 3 information (which the vendor does support with 297 IPv6); state using Layer 2 information would work just fine 298 [I-D.ietf-magma-snoop]. Therefore the snooping swich developers 299 should be aware of the tradeoff of using Layer 2 vs Layer 3 300 information on multicast data forwarding, especially if IPv6 snooping 301 is not supported. 303 There are no good workarounds for these problems, except 304 disseminating information about them (e.g., at http://www.v6fix.net) 305 and complaining to the vendor. 307 4.3 Functionality Like MLD Snooping 309 On Ethernet, multicast frames are forwarded to every port, even 310 without subscribers (or IPv6 support). 312 Especially if multicast traffic is relatively heavy (e.g., video 313 streaming), it becomes particularly important to have some feature 314 like Multicast Listener Discovery (MLD) snooping implemented, to 315 reduce the amount of flooding [I-D.ietf-magma-snoop]. 317 Looking at the actual problem from a higher view, it is not clear 318 that MLD snooping is the right long-term solution. It makes the 319 switches complex, requires the processing of datagrams above the 320 link-layer, and should be discouraged 321 [I-D.ietf-mboned-iesg-gap-analysis]: the whole idea of L2-only 322 devices having to peek into L3 datagrams seems like a severe layering 323 violation -- and often the devices aren't upgradeable (if there are 324 bugs or missing features, which could be fixed later) in any way. 325 Better mechanisms could be having routers tell switches which 326 multicasts to forward where (e.g., [CGMP]) or by using some other 327 mechanisms [GARP]. 329 5. Security Considerations 331 Only deployment and implementation issues are considered, and these 332 do not have any particular security considerations; security 333 considerations for each technology are covered in the respective 334 specifications. 336 6. Acknowledgements 338 Early discussions with Stig Venaas, Jerome Durand, Tim Chown et al. 339 led to the writing of this draft. Brian Haberman offered extensive 340 comments along the way. "Itojun" Hagino brought up the need for MLD 341 snooping in a presentation. Bill Nickless pointed out issues in the 342 gap analysis and provided a pointer to GARP/GMRP; Havard Eidnes made 343 a case for a protocol like CGMP. Leonard Giuliano pointed out a more 344 complete analysis of SSM with different kind of applications. 346 7. References 348 7.1 Normative References 350 [I-D.ietf-mboned-msdp-deploy] 351 McBride, M., "Multicast Source Discovery Protocol (MSDP) 352 Deployment Scenarios", 353 Internet-Draft draft-ietf-mboned-msdp-deploy-06, March 354 2004. 356 [I-D.ietf-pim-anycast-rp] 357 Farinacci, D., "Anycast-RP using PIM", 358 Internet-Draft draft-ietf-pim-anycast-rp-02, June 2004. 360 [I-D.ietf-pim-sm-v2-new] 361 Fenner, B., Handley, M., Holbrook, H. and I. Kouvelas, 362 "Protocol Independent Multicast - Sparse Mode PIM-SM): 363 Protocol Specification (Revised)", 364 Internet-Draft draft-ietf-pim-sm-v2-new-11, October 2004. 366 [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor 367 Discovery for IP Version 6 (IPv6)", RFC 2461, December 368 1998. 370 [RFC3446] Kim, D., Meyer, D., Kilmer, H. and D. Farinacci, "Anycast 371 Rendevous Point (RP) mechanism using Protocol Independent 372 Multicast (PIM) and Multicast Source Discovery Protocol 373 (MSDP)", RFC 3446, January 2003. 375 [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific 376 Multicast (SSM)", RFC 3569, July 2003. 378 [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery 379 Protocol (MSDP)", RFC 3618, October 2003. 381 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 382 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 384 [RFC3913] Thaler, D., "Border Gateway Multicast Protocol (BGMP): 385 Protocol Specification", RFC 3913, September 2004. 387 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 388 Point (RP) Address in an IPv6 Multicast Address", 389 RFC 3956, November 2004. 391 7.2 Informative References 393 [CGMP] "Cisco Group Management Protocol", 394 . 396 [GARP] Tobagi, F., Molinero-Fernandez, P. and M. Karam, "Study of 397 IEEE 802.1p GARP/GMRP Timer Values", 1997. 399 [I-D.bhattach-diot-pimso] 400 Bhattacharyya, S., Diot, C., Giuliano, L. and R. Rockell, 401 "Deployment of PIM-SO at Sprint (PIM-SO)", March 2000. 403 [I-D.ietf-magma-snoop] 404 Christensen, M., Kimball, K. and F. Solensky, 405 "Considerations for IGMP and MLD Snooping Switches", 406 Internet-Draft draft-ietf-magma-snoop-11, May 2004. 408 [I-D.ietf-mboned-iesg-gap-analysis] 409 Meyer, D. and B. Nickless, "Internet Multicast Gap 410 Analysis from the MBONED Working Group for the IESG", 411 Internet-Draft draft-ietf-mboned-iesg-gap-analysis-00, 412 July 2002. 414 [I-D.ietf-pim-sm-bsr] 415 Fenner, B., "Bootstrap Router (BSR) Mechanism for PIM", 416 Internet-Draft draft-ietf-pim-sm-bsr-04, July 2004. 418 [RFC3678] Thaler, D., Fenner, B. and B. Quinn, "Socket Interface 419 Extensions for Multicast Source Filters", RFC 3678, 420 January 2004. 422 [SSMSNOOP] 423 "Operational Problems with IGMP snooping switches", March 424 2003, . 426 Author's Address 428 Pekka Savola 429 CSC/FUNET 430 Espoo 431 Finland 433 Email: psavola@funet.fi 435 Appendix A. SSM Deployment Issues 437 To be deployed, SSM requires changes to: 439 1. routers 441 2. IGMP/MLD-snooping Ethernet switches 443 3. hosts 445 4. application programming interfaces (APIs) 447 5. multicast usage models 449 Introducing SSM support in the routers has been straightforward as 450 PIM-SSM is a subset of PIM-SM [I-D.ietf-pim-sm-v2-new]. 452 IGMP-snooping Ethernet switches have been a more difficult issue 453 [SSMSNOOP]; some which perform IGMPv2 snooping discard IGMPv3 reports 454 or queries, or multicast transmissions associated to them. If MLDv1 455 snooping had been implemented (or is implemented in a similar 456 manner), this would likely have affected that as well. 458 Host systems require MLDv2 [RFC3810] support. The situation has 459 improved with respect to MLDv2 support for end systems, and 460 interoperability has increased after the publication of the RFC due 461 to the stabilization of the ICMP types used. 463 The multicast source filtering API specification has also been 464 completed [RFC3678]; its deployment is likely roughly equal (or 465 slightly worse) than MLDv2. The API is required for creating 466 (cross-platform) SSM applications. 468 The most difficult issue, multicast usage models, remains a problem 469 as of this writing as described below. SSM is an excellent fit for 470 one-to-many distribution topologies, and porting such applications to 471 use SSM would likely be rather simple. However, a significant number 472 of current applications are many-to-many (e.g., conferencing 473 applications) which cannot be converted to SSM without significant 474 effort, including, for example, out-of-band source discovery. For 475 such applications to be usable for IPv6 at least in a short to medium 476 term, ASM -like techniques seem to be required. 478 Intellectual Property Statement 480 The IETF takes no position regarding the validity or scope of any 481 Intellectual Property Rights or other rights that might be claimed to 482 pertain to the implementation or use of the technology described in 483 this document or the extent to which any license under such rights 484 might or might not be available; nor does it represent that it has 485 made any independent effort to identify any such rights. Information 486 on the procedures with respect to rights in RFC documents can be 487 found in BCP 78 and BCP 79. 489 Copies of IPR disclosures made to the IETF Secretariat and any 490 assurances of licenses to be made available, or the result of an 491 attempt made to obtain a general license or permission for the use of 492 such proprietary rights by implementers or users of this 493 specification can be obtained from the IETF on-line IPR repository at 494 http://www.ietf.org/ipr. 496 The IETF invites any interested party to bring to its attention any 497 copyrights, patents or patent applications, or other proprietary 498 rights that may cover technology that may be required to implement 499 this standard. Please address the information to the IETF at 500 ietf-ipr@ietf.org. 502 Disclaimer of Validity 504 This document and the information contained herein are provided on an 505 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 506 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 507 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 508 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 509 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 510 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 512 Copyright Statement 514 Copyright (C) The Internet Society (2005). This document is subject 515 to the rights, licenses and restrictions contained in BCP 78, and 516 except as set forth therein, the authors retain all their rights. 518 Acknowledgment 520 Funding for the RFC Editor function is currently provided by the 521 Internet Society.