idnits 2.17.1 draft-ietf-idr-v4nlri-v6nh-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, updated by RFC 4748 on line 504. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 515. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 522. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 528. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (March 23, 2007) is 6215 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3107 (Obsoleted by RFC 8277) ** Obsolete normative reference: RFC 3392 (Obsoleted by RFC 5492) == Outdated reference: A later version (-16) exists of draft-ietf-idr-dynamic-cap-09 -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Inter-Domain Routing F. Le Faucheur 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track E. Rosen 5 Expires: September 24, 2007 Cisco Systems, Inc. 6 March 23, 2007 8 Advertising an IPv4 NLRI with an IPv6 Next Hop 9 draft-ietf-idr-v4nlri-v6nh-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 September 24, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 MultiProtocol-BGP (MP-BGP) specifies that the set of Network Layer 43 protocols to which the address carried in the Next Hop field may 44 belong is determined by the Address Family Identifier (AFI) and the 45 Subsequent Address Family Identifier (SAFI). The current AFI/SAFI 46 definitions for the IPv4 address family only have provisions for 47 advertising a Next Hop address that belongs to the IPv4 protocol when 48 advertising an IPv4 Network Layer Reachability Information (NLRI) or 49 a VPN-IPv4 NLRI. This document specifies the extensions necessary to 50 allow advertising an IPv4 NLRI or a VPN-IPv4 NLRI with a Next Hop 51 address that belongs to the IPv6 protocol. This comprises an 52 extension of the AFI/SAFI definitions to allow the address of the 53 Next Hop for an IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 54 protocol, the encoding of the Next Hop in order to determine which of 55 the protocols the address actually belongs to, and a new BGP 56 Capability allowing MP-BGP Peers to dynamically discover whether they 57 can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop. 59 Requirements Language 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in RFC 2119 [RFC2119]. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Extension of AFI/SAFI Definitions for IPv4 Address Family . . 4 69 3. Use of BGP Capability Advertisement . . . . . . . . . . . . . 5 70 4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 5. Usage Examples . . . . . . . . . . . . . . . . . . . . . . . . 8 72 5.1. IPv4 over IPv6 Core . . . . . . . . . . . . . . . . . . . 8 73 5.2. IPv4 VPN over IPv6 Core . . . . . . . . . . . . . . . . . 8 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 76 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 79 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 81 Intellectual Property and Copyright Statements . . . . . . . . . . 12 83 1. Introduction 85 Multi Protocol-BGP (MP-BGP) ([RFC4760]) specifies that the set of 86 Network Layer protocols to which the address carried in the Next Hop 87 field may belong is determined by the Address Family Identifier (AFI) 88 and the Subsequent Address Family Identifier (SAFI). A number of 89 existing AFI/SAFIs allow the Next Hop address to belong to a 90 different address family than the Network Layer Reachability 91 Information (NLRI). For example, the AFI/SAFI <25/65> used as per 92 [I-D.ietf-l2vpn-signaling] in order to perform L2VPN Autodiscovery 93 allows advertising an NLRI containing the identifier of a VPLS 94 instance, or identifying a particular pool of attachment circuits at 95 a given Provider Edge (PE), while the Next Hop field contains the 96 loopback address of a PE. Similarly, the AFI/SAFI <1/132> defined in 97 [RFC4684] in order to advertise Route Target (RT) membership 98 information, allows advertising an NLRI containing such RT membership 99 information while the Next Hop field contains the address of the 100 advertising router. 102 Furthermore, a number of these existing AFI/SAFIs allow the Next Hop 103 to belong to either the IPv4 Network Layer Protocol or the IPv6 104 Network Layer Protocol, and specify the encoding of the Next Hop 105 information in order to determine which of the protocols the address 106 actually belongs to. For example, [RFC4684] allows the Next Hop 107 address to be either IPv4 or IPv6 and states that the Next Hop field 108 address shall be interpreted as an IPv4 address, whenever the length 109 of Next Hop address is 4 octets, and as a IPv6 address, whenever the 110 length of the Next Hop address is 16 octets. 112 There are situations such as those described in 113 [I-D.ietf-softwire-problem-statement] and in 114 [I-D.wu-softwire-mesh-framework] where carriers (or large enterprise 115 networks acting as carrier for their internal resources) may be 116 required to establish connectivity between 'islands' of networks of 117 one address family type across a transit core of a differing address 118 family type. This includes both the case of IPv6 islands across an 119 IPv4 core and the case of IPv4 islands across an IPv6 core. Where 120 Multi-Protocol BGP (MP-BGP) is used to advertise the corresponding 121 reachability information, this translates into the requirement for a 122 BGP speaker to advertise Network Layer Reachability Information 123 (NLRI) of a given address family via a Next Hop of a different 124 address family (i.e. IPv6 NLRI with IPv4 Next Hop and IPv4 NLRI with 125 IPv6 Next Hop). 127 The current AFI/SAFI definitions for the IPv6 address family assume 128 that the Next Hop address belongs to the IPv6 address family type. 129 Specifically, as per [RFC2545] and [RFC3107], when the is 130 <2/1>, <2/2>, or <2/4>, the Next Hop address is assumed to be of IPv6 131 type. As per [RFC4659], when the is <2/128>, the Next Hop 132 address is assumed to be of IPv6-VPN type. 134 However, [RFC4798] and [RFC4659] specify how an IPv4 address can be 135 encoded inside the Next Hop IPv6 address field when an IPv6 NLRI 136 needs to be advertised with an IPv4 Next Hop. [RFC4798] defines how 137 the IPv4-mapped IPv6 address format specified in the IPv6 addressing 138 architecture ([RFC4291]) can be used for that purpose when the is <2/1>, <2/2>, or <2/4>. [RFC4659] defines how the IPv4- 140 mapped IPv6 address format as well as a null Route Distinguisher can 141 be used for that purpose when the is <2/128>. Thus, there 142 are existing solutions for the advertisement of IPv6 NLRI with an 143 IPv4 next hop. 145 Similarly, the current AFI/SAFI definitions for advertisement of IPv4 146 NLRI or VPN-IPv4 NLRI assume that the Next Hop address belongs to the 147 IPv4 address family type. Specifically, as per [RFC4760] and 148 [RFC3107], when the is <1/1>, <1/2>, or <1/4>, the Next 149 Hop address is assumed to be of IPv4 type. As per [RFC4364], when 150 the is <1/128>, the Next Hop address is assumed to be of 151 VPN-IPv4 type. There is clearly no generally applicable method for 152 encoding an IPv6 address inside the IPv4 address field of the Next 153 Hop. Hence, there is currently no specified solution for advertising 154 IPv4 or VPN-IPv4 NLRI with an IPv6 Next Hop. 156 This document specifies the extensions necessary to do so. This 157 comprises an extension of the AFI/SAFI definitions to allow the 158 address of the Next Hop for an IPv4 NLRI or VPN-IPv4 NLRI to belong 159 to either the IPv4 or the IPv6 protocol, the encoding of the Next Hop 160 information in order to determine which of the protocols the address 161 actually belongs to, and a new BGP Capability allowing MP-BGP Peers 162 to dynamically discover whether they can exchange IPv4 NLRI and VPV- 163 IPv4 NLRI with an IPv6 Next Hop. The new BGP capability allows 164 gradual deployment of the new functionality of advertising IPv4 165 reachability via an IPv6 next hop, without any flag day nor any risk 166 of traffic black-holing. 168 2. Extension of AFI/SAFI Definitions for IPv4 Address Family 170 As mentioned earlier, MP-BGP specifies that the set of Network Layer 171 protocols to which the address carried in the Next Hop field may 172 belong is determined by the Address Family Identifier (AFI) and the 173 Subsequent Address Family Identifier (SAFI). The following current 174 AFI/SAFI definitions for the IPv4 NLRI or VPN-IPv4 NLRI (<1/1>, 175 <1/2>, <1/4> and <1/128>) only have provisions for advertising a Next 176 Hop address that belongs to the IPv4 protocol. This document extends 177 the definition of the AFI/SAFI for advertisement of IPv4 NLRI and 178 VPN-IPv4 NLRI to extend the set of network layer protocols to which 179 the Next Hop address can belong, to include IPv6 in addition to IPv4. 181 Specifically, this document allows advertising with [RFC4760] of an 182 MP_REACH_NLRI with: 184 o AFI=1 186 o SAFI = 1, 2, 4 or 128 188 o Length of Next Hop Address = 16 or 32 190 o Next Hop Address = IPv6 address of next hop (potentially followed 191 by the link-local IPv6 address of the next hop). This field is to 192 be constructed as per section 3 of [RFC2545]. 194 o NLRI= NLRI as per current AFI/SAFI definition 196 This is in addition to the current mode of operation allowing 197 advertisement of an NLRI for of <1,1>, <1,2> and <1,4> 198 with a next hop address of IPv4 type and advertisement of an NLRI for 199 of <1,128> with a next hop address of VPN-IPv4 type. 201 The BGP speaker receiving the advertisement MUST use the Length of 202 Next Hop Address field to determine which network layer protocol the 203 next hop address belongs to. When the Length of Next Hop Address 204 field is equal to 16 or 32, the next hop address is of type IPv6. 205 Note that this method of using the Length of the Next Hop Address 206 field to determine which network layer protocol the next hop address 207 belongs to (out of the set of protocols allowed by the AFI/SAFI 208 definition) is the same as used in[RFC4684] and 209 [I-D.ietf-l2vpn-signaling]. 211 3. Use of BGP Capability Advertisement 213 [RFC3392] defines a mechanism to allow two BGP speakers to discover 214 if a particular capability is supported by their BGP peer and thus 215 whether it can be used with that peer. This document defines a new 216 capability which can be advertised using [RFC3392] and which is 217 referred to as the Extended Next Hop Encoding capability. This 218 capability allows BGP speakers to discover whether, for a given NLRI 219 , a peer supports advertisement with a next hop whose 220 network protocol is determined by the value of the Length of Next Hop 221 Address field, as specified in section 2. 223 A BGP speaker that wishes to advertise to a BGP peer an IPv6 next hop 224 for an IPv4 NLRI or for a VPN-IPv4 NLRI as per this specification 225 MUST use the Capability Advertisement procedures defined in [RFC3392] 226 with the Extended Next Hop Encoding Capability to establish whether 227 its peer supports this for the NLRI AFI/SAFI pair(s) of interest. 228 The fields in the Capabilities Optional Parameter MUST be set as 229 follows: 231 o The Capability Code field MUST be set to [To be allocated by IANA] 232 (which indicates the Extended Next Hop Encoding capability). 234 o The Capability Length field is set to a variable value which is 235 the length of the Capability Value field (which follows). 237 o The Capability Value field has the following format: 239 +-----------------------------------------------------+ 240 | NLRI AFI - 1 (2 octets) | 241 +-----------------------------------------------------+ 242 | NLRI SAFI - 1 (2 octets) | 243 +-----------------------------------------------------+ 244 | Nexthop AFI - 1 (2 octets) | 245 +-----------------------------------------------------+ 246 | ..... | 247 +-----------------------------------------------------+ 248 | NLRI AFI - N (2 octets) | 249 +-----------------------------------------------------+ 250 | NLRI SAFI - N (2 octet) | 251 +-----------------------------------------------------+ 252 | Nexthop AFI - N (2 octets) | 253 +-----------------------------------------------------+ 255 where: 257 * each triple indicates that 258 an NLRI of NLRI AFI, NLRI SAFI may be advertised with a Next 259 Hop address belonging to the Network Layer protocol of Nexthop 260 AFI. 262 * the AFI and SAFI values are defined in the Address Family 263 Identifier and Subsequent Address Family Identifier registries 264 maintained by IANA. 266 Since this document only concerns itself with the advertisement of 267 IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop, this specification 268 only allows the following values in the Capability Value field of the 269 Extended Next Hop Encoding capability: 271 o NLRI AFI=1 (IPv4) 273 o NLRI SAFI = 1, 2, 4 or 128 275 o Nexthop AFI=2 (IPv6) 277 This specification does not propose that the Extended Next Hop 278 Encoding capability be used with any other combinations of NLRI AFI, 279 NLRI SAFI, Nexthop AFI. In particular, this specification does not 280 propose that the Extended Next Hop Encoding capability be used for 281 NLRI AFI/SAFIs whose definition already allows use of both IPv4 and 282 IPv6 next hops (e.g. AFI/SAFI=1/132 as defined in [RFC4684]). 283 Similarly, it does not propose that the Extended Next Hop Encoding 284 capability be used for NLRI AFI/SAFIs for which there is already a 285 solution for advertising a next hop of a different address family 286 (e.g AFI/SAFI=2/1, 2/2 or 2/4 with IPv4 next hop as per [RFC4798] and 287 AFI/SAFI=2/128 with IPv4 next hop as per [RFC4659]). 289 It is expected that if new AFI/SAFIs are defined in the future, their 290 definition will (where appropriate) have provisions for both IPv4 and 291 IPv6 next hops from the onset, with determination based on Length of 292 Next Hop Address field. Thus, new AFI/SAFIs are not expected to make 293 use of the Extended Next Hop Encoding capability. 295 A BGP speaker MUST only advertise to a BGP peer an IPv4 or VPN-IPv4 296 NLRI with an IPv6 Next Hop if the BGP speaker has first ascertained 297 via BGP Capability Advertisement that the BGP peer supports the 298 Extended Next Hop Encoding capability for the relevant AFI/SAFI pair. 300 The Extended Next Hop Encoding capability provides information about 301 next hop encoding for a given AFI/SAFI, assuming that AFI/SAFI is 302 allowed. It does not influence whether that AFI/SAFI is indeed 303 allowed. Whether a AFI/SAFI can be used between the BGP peers is 304 purely determined through the Multiprotocol Extensions capability 305 defined in [RFC4760]. 307 The Extended Next Hop Encoding capability MAY be dynamically updated 308 through the use of the Dynamic Capability capability and associated 309 mechanisms defined in [I-D.ietf-idr-dynamic-cap]. 311 4. Operations 313 By default, if a particular BGP session is running over IPvx (where 314 IPvx is IPv4 or IPv6), and if the BGP speaker sending an update is 315 putting its own address in as the next hop, then the next hop address 316 SHOULD be specified as an IPvx address, using the encoding rules 317 specified in the AFI/SAFI definition of the NLRI being updated. This 318 default behavior may be overridden by policy. 320 When a next hop address needs to be passed along unchanged (as, e.g., 321 a Route Reflector (RR) would do), its encoding MUST NOT be changed. 322 If a particular RR client cannot handle that encoding (as determined 323 by the BGP capability advertisement), then the NLRI in question 324 cannot be distributed to that client. For sound routing in certain 325 scenarios, this will require that all the RR clients be able to 326 handle whatever encodings any of them may generate. 328 5. Usage Examples 330 5.1. IPv4 over IPv6 Core 332 The extensions defined in this document may be used as discussed in 333 [I-D.wu-softwire-mesh-framework] for the interconnection of IPV4 334 islands over an IPv6 backbone. In this application, Address Family 335 Border Routers (AFBR) (as defined in 336 [I-D.ietf-softwire-problem-statement]) advertise IPv4 NLRI 337 information in the MP_REACH_NLRI along with an IPv6 next hop. 339 The MP_REACH_NLRI is encoded with: 341 o AFI=1 343 o SAFI=1 345 o Length of Next Hop Network Address = 16 (or 32) 347 o Network Address of Next Hop= IPv6 address of Next Hop 349 o NLRI= IPv4 routes 351 During BGP Capability Advertisement, the PE routers would include the 352 following fields in the Capabilities Optional Parameter: 354 o Capability Code set to "Extended Next Hop Encoding" 356 o Capability Value containing 359 5.2. IPv4 VPN over IPv6 Core 361 The extensions defined in this document may be used for support of 362 IPV4 VPNs over an IPv6 backbone. In this application, PE Routers 363 would advertise VPN-IPv4 NLRI information in the MP_REACH_NLRI along 364 with an IPv6 next hop. 366 The MP_REACH_NLRI is encoded with: 368 o AFI=1 370 o SAFI=128 372 o Length of Next Hop Network Address = 16 (or 32) 374 o Network Address of Next Hop= IPv6 address of Next Hop 376 o NLRI= IPv4-VPN routes 378 During BGP Capability Advertisement, the PE routers would include the 379 following fields in the Capabilities Optional Parameter : 381 o Capability Code set to "Extended Next Hop Encoding" 383 o Capability Value containing 386 6. IANA Considerations 388 This document defines, in section 3, a new Capability Code to 389 indicate the Extended Next Hop Encoding capability in the [RFC3392] 390 Capabilities Optional Parameter. The value for this new Capability 391 Code is to be allocated from the range 1 through 63 set aside for 392 allocation using the "IETF consensus" policy defined in [RFC2434]. 394 7. Security Considerations 396 This document does not raise any additional security issues beyond 397 those of BGP-4 and the MultiProtocol extensions for BGP-4. The same 398 security mechanisms are applicable. 400 8. Acknowledgments 402 The authors would like to thank Yakov Rekhter, Pranav Metha and John 403 Scudder for their contributions in the approach defined in this 404 document. 406 9. References 407 9.1. Normative References 409 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 410 Requirement Levels", BCP 14, RFC 2119, March 1997. 412 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 413 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 414 March 1999. 416 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 417 BGP-4", RFC 3107, May 2001. 419 [RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement 420 with BGP-4", RFC 3392, November 2002. 422 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 423 Architecture", RFC 4291, February 2006. 425 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 426 Networks (VPNs)", RFC 4364, February 2006. 428 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 429 "Multiprotocol Extensions for BGP-4", RFC 4760, 430 January 2007. 432 9.2. Informative References 434 [I-D.ietf-idr-dynamic-cap] 435 Chen, E. and S. Sangli, "Dynamic Capability for BGP-4", 436 draft-ietf-idr-dynamic-cap-09 (work in progress), 437 November 2006. 439 [I-D.ietf-l2vpn-signaling] 440 Rosen, E., "Provisioning, Autodiscovery, and Signaling in 441 L2VPNs", draft-ietf-l2vpn-signaling-08 (work in progress), 442 May 2006. 444 [I-D.ietf-softwire-problem-statement] 445 Dawkins, S., "Softwire Problem Statement", 446 draft-ietf-softwire-problem-statement-03 (work in 447 progress), March 2007. 449 [I-D.wu-softwire-mesh-framework] 450 Wu, J., "Softwire Mesh Framework", 451 draft-wu-softwire-mesh-framework-02 (work in progress), 452 March 2007. 454 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 455 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 456 October 1998. 458 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 459 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 460 IPv6 VPN", RFC 4659, September 2006. 462 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 463 R., Patel, K., and J. Guichard, "Constrained Route 464 Distribution for Border Gateway Protocol/MultiProtocol 465 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 466 Private Networks (VPNs)", RFC 4684, November 2006. 468 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 469 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 470 Provider Edge Routers (6PE)", RFC 4798, February 2007. 472 Authors' Addresses 474 Francois Le Faucheur 475 Cisco Systems 476 Greenside, 400 Avenue de Roumanille 477 Sophia Antipolis 06410 478 France 480 Email: flefauch@cisco.com 482 Eric Rosen 483 Cisco Systems, Inc. 484 1414 Massachusetts Avenue 485 Boxborough, MA 01719 486 USA 488 Email: erosen@cisco.com 490 Full Copyright Statement 492 Copyright (C) The IETF Trust (2007). 494 This document is subject to the rights, licenses and restrictions 495 contained in BCP 78, and except as set forth therein, the authors 496 retain all their rights. 498 This document and the information contained herein are provided on an 499 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 500 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 501 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 502 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 503 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 504 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 506 Intellectual Property 508 The IETF takes no position regarding the validity or scope of any 509 Intellectual Property Rights or other rights that might be claimed to 510 pertain to the implementation or use of the technology described in 511 this document or the extent to which any license under such rights 512 might or might not be available; nor does it represent that it has 513 made any independent effort to identify any such rights. Information 514 on the procedures with respect to rights in RFC documents can be 515 found in BCP 78 and BCP 79. 517 Copies of IPR disclosures made to the IETF Secretariat and any 518 assurances of licenses to be made available, or the result of an 519 attempt made to obtain a general license or permission for the use of 520 such proprietary rights by implementers or users of this 521 specification can be obtained from the IETF on-line IPR repository at 522 http://www.ietf.org/ipr. 524 The IETF invites any interested party to bring to its attention any 525 copyrights, patents or patent applications, or other proprietary 526 rights that may cover technology that may be required to implement 527 this standard. Please address the information to the IETF at 528 ietf-ipr@ietf.org. 530 Acknowledgment 532 Funding for the RFC Editor function is provided by the IETF 533 Administrative Support Activity (IASA).