idnits 2.17.1 draft-ietf-softwire-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 501. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 512. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 519. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 525. 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 (January 18, 2008) is 5933 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 == Outdated reference: A later version (-06) exists of draft-ietf-softwire-mesh-framework-03 -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Softwire F. Le Faucheur 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track E. Rosen 5 Expires: July 21, 2008 Cisco Systems, Inc. 6 January 18, 2008 8 Advertising an IPv4 NLRI with an IPv6 Next Hop 9 draft-ietf-softwire-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 July 21, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 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 [RFC4925] and in 113 [I-D.ietf-softwire-mesh-framework] where carriers (or large 114 enterprise networks acting as carrier for their internal resources) 115 may be required to establish connectivity between 'islands' of 116 networks of one address family type across a transit core of a 117 differing address family type. This includes both the case of IPv6 118 islands across an IPv4 core and the case of IPv4 islands across an 119 IPv6 core. Where Multi-Protocol BGP (MP-BGP) is used to advertise 120 the corresponding reachability information, this translates into the 121 requirement for a BGP speaker to advertise Network Layer Reachability 122 Information (NLRI) of a given address family via a Next Hop of a 123 different address family (i.e. IPv6 NLRI with IPv4 Next Hop and IPv4 124 NLRI with IPv6 Next Hop). 126 The current AFI/SAFI definitions for the IPv6 address family assume 127 that the Next Hop address belongs to the IPv6 address family type. 128 Specifically, as per [RFC2545] and [RFC3107], when the is 129 <2/1>, <2/2>, or <2/4>, the Next Hop address is assumed to be of IPv6 130 type. As per [RFC4659], when the is <2/128>, the Next Hop 131 address is assumed to be of IPv6-VPN type. 133 However, [RFC4798] and [RFC4659] specify how an IPv4 address can be 134 encoded inside the Next Hop IPv6 address field when an IPv6 NLRI 135 needs to be advertised with an IPv4 Next Hop. [RFC4798] defines how 136 the IPv4-mapped IPv6 address format specified in the IPv6 addressing 137 architecture ([RFC4291]) can be used for that purpose when the is <2/1>, <2/2>, or <2/4>. [RFC4659] defines how the IPv4- 139 mapped IPv6 address format as well as a null Route Distinguisher can 140 be used for that purpose when the is <2/128>. Thus, there 141 are existing solutions for the advertisement of IPv6 NLRI with an 142 IPv4 next hop. 144 Similarly, the current AFI/SAFI definitions for advertisement of IPv4 145 NLRI or VPN-IPv4 NLRI assume that the Next Hop address belongs to the 146 IPv4 address family type. Specifically, as per [RFC4760] and 147 [RFC3107], when the is <1/1>, <1/2>, or <1/4>, the Next 148 Hop address is assumed to be of IPv4 type. As per [RFC4364], when 149 the is <1/128>, the Next Hop address is assumed to be of 150 VPN-IPv4 type. There is clearly no generally applicable method for 151 encoding an IPv6 address inside the IPv4 address field of the Next 152 Hop. Hence, there is currently no specified solution for advertising 153 IPv4 or VPN-IPv4 NLRI with an IPv6 Next Hop. 155 This document specifies the extensions necessary to do so. This 156 comprises an extension of the AFI/SAFI definitions to allow the 157 address of the Next Hop for an IPv4 NLRI or VPN-IPv4 NLRI to belong 158 to either the IPv4 or the IPv6 protocol, the encoding of the Next Hop 159 information in order to determine which of the protocols the address 160 actually belongs to, and a new BGP Capability allowing MP-BGP Peers 161 to dynamically discover whether they can exchange IPv4 NLRI and VPV- 162 IPv4 NLRI with an IPv6 Next Hop. The new BGP capability allows 163 gradual deployment of the new functionality of advertising IPv4 164 reachability via an IPv6 next hop, without any flag day nor any risk 165 of traffic black-holing. 167 2. Extension of AFI/SAFI Definitions for IPv4 Address Family 169 As mentioned earlier, MP-BGP specifies that the set of Network Layer 170 protocols to which the address carried in the Next Hop field may 171 belong is determined by the Address Family Identifier (AFI) and the 172 Subsequent Address Family Identifier (SAFI). The following current 173 AFI/SAFI definitions for the IPv4 NLRI or VPN-IPv4 NLRI (<1/1>, 174 <1/2>, <1/4> and <1/128>) only have provisions for advertising a Next 175 Hop address that belongs to the IPv4 protocol. This document extends 176 the definition of the AFI/SAFI for advertisement of IPv4 NLRI and 177 VPN-IPv4 NLRI to extend the set of network layer protocols to which 178 the Next Hop address can belong, to include IPv6 in addition to IPv4. 180 Specifically, this document allows advertising with [RFC4760] of an 181 MP_REACH_NLRI with: 183 o AFI=1 185 o SAFI = 1, 2, 4 or 128 187 o Length of Next Hop Address = 16 or 32 189 o Next Hop Address = IPv6 address of next hop (potentially followed 190 by the link-local IPv6 address of the next hop). This field is to 191 be constructed as per section 3 of [RFC2545]. 193 o NLRI= NLRI as per current AFI/SAFI definition 195 This is in addition to the current mode of operation allowing 196 advertisement of an NLRI for of <1,1>, <1,2> and <1,4> 197 with a next hop address of IPv4 type and advertisement of an NLRI for 198 of <1,128> with a next hop address of VPN-IPv4 type. 200 The BGP speaker receiving the advertisement MUST use the Length of 201 Next Hop Address field to determine which network layer protocol the 202 next hop address belongs to. When the Length of Next Hop Address 203 field is equal to 16 or 32, the next hop address is of type IPv6. 204 Note that this method of using the Length of the Next Hop Address 205 field to determine which network layer protocol the next hop address 206 belongs to (out of the set of protocols allowed by the AFI/SAFI 207 definition) is the same as used in [RFC4684] and 208 [I-D.ietf-l2vpn-signaling]. 210 3. Use of BGP Capability Advertisement 212 [RFC3392] defines a mechanism to allow two BGP speakers to discover 213 if a particular capability is supported by their BGP peer and thus 214 whether it can be used with that peer. This document defines a new 215 capability which can be advertised using [RFC3392] and which is 216 referred to as the Extended Next Hop Encoding capability. This 217 capability allows BGP speakers to discover whether, for a given NLRI 218 , a peer supports advertisement with a next hop whose 219 network protocol is determined by the value of the Length of Next Hop 220 Address field, as specified in section 2. 222 A BGP speaker that wishes to advertise to a BGP peer an IPv6 next hop 223 for an IPv4 NLRI or for a VPN-IPv4 NLRI as per this specification 224 MUST use the Capability Advertisement procedures defined in [RFC3392] 225 with the Extended Next Hop Encoding Capability to establish whether 226 its peer supports this for the NLRI AFI/SAFI pair(s) of interest. 227 The fields in the Capabilities Optional Parameter MUST be set as 228 follows: 230 o The Capability Code field MUST be set to [To be allocated by IANA] 231 (which indicates the Extended Next Hop Encoding capability). 233 o The Capability Length field is set to a variable value which is 234 the length of the Capability Value field (which follows). 236 o The Capability Value field has the following format: 238 +-----------------------------------------------------+ 239 | NLRI AFI - 1 (2 octets) | 240 +-----------------------------------------------------+ 241 | NLRI SAFI - 1 (2 octets) | 242 +-----------------------------------------------------+ 243 | Nexthop AFI - 1 (2 octets) | 244 +-----------------------------------------------------+ 245 | ..... | 246 +-----------------------------------------------------+ 247 | NLRI AFI - N (2 octets) | 248 +-----------------------------------------------------+ 249 | NLRI SAFI - N (2 octet) | 250 +-----------------------------------------------------+ 251 | Nexthop AFI - N (2 octets) | 252 +-----------------------------------------------------+ 254 where: 256 * each triple indicates that 257 an NLRI of NLRI AFI, NLRI SAFI may be advertised with a Next 258 Hop address belonging to the Network Layer protocol of Nexthop 259 AFI. 261 * the AFI and SAFI values are defined in the Address Family 262 Identifier and Subsequent Address Family Identifier registries 263 maintained by IANA. 265 Since this document only concerns itself with the advertisement of 266 IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop, this specification 267 only allows the following values in the Capability Value field of the 268 Extended Next Hop Encoding capability: 270 o NLRI AFI=1 (IPv4) 272 o NLRI SAFI = 1, 2, 4 or 128 274 o Nexthop AFI=2 (IPv6) 276 This specification does not propose that the Extended Next Hop 277 Encoding capability be used with any other combinations of NLRI AFI, 278 NLRI SAFI, Nexthop AFI. In particular, this specification does not 279 propose that the Extended Next Hop Encoding capability be used for 280 NLRI AFI/SAFIs whose definition already allows use of both IPv4 and 281 IPv6 next hops (e.g. AFI/SAFI=1/132 as defined in [RFC4684]). 282 Similarly, it does not propose that the Extended Next Hop Encoding 283 capability be used for NLRI AFI/SAFIs for which there is already a 284 solution for advertising a next hop of a different address family 285 (e.g AFI/SAFI=2/1, 2/2 or 2/4 with IPv4 next hop as per [RFC4798] and 286 AFI/SAFI=2/128 with IPv4 next hop as per [RFC4659]). 288 It is expected that if new AFI/SAFIs are defined in the future, their 289 definition will (where appropriate) have provisions for both IPv4 and 290 IPv6 next hops from the onset, with determination based on Length of 291 Next Hop Address field. Thus, new AFI/SAFIs are not expected to make 292 use of the Extended Next Hop Encoding capability. 294 A BGP speaker MUST only advertise to a BGP peer an IPv4 or VPN-IPv4 295 NLRI with an IPv6 Next Hop if the BGP speaker has first ascertained 296 via BGP Capability Advertisement that the BGP peer supports the 297 Extended Next Hop Encoding capability for the relevant AFI/SAFI pair. 299 The Extended Next Hop Encoding capability provides information about 300 next hop encoding for a given AFI/SAFI, assuming that AFI/SAFI is 301 allowed. It does not influence whether that AFI/SAFI is indeed 302 allowed. Whether a AFI/SAFI can be used between the BGP peers is 303 purely determined through the Multiprotocol Extensions capability 304 defined in [RFC4760]. 306 The Extended Next Hop Encoding capability MAY be dynamically updated 307 through the use of the Dynamic Capability capability and associated 308 mechanisms defined in [I-D.ietf-idr-dynamic-cap]. 310 4. Operations 312 By default, if a particular BGP session is running over IPvx (where 313 IPvx is IPv4 or IPv6), and if the BGP speaker sending an update is 314 putting its own address in as the next hop, then the next hop address 315 SHOULD be specified as an IPvx address, using the encoding rules 316 specified in the AFI/SAFI definition of the NLRI being updated. This 317 default behavior may be overridden by policy. 319 When a next hop address needs to be passed along unchanged (as, e.g., 320 a Route Reflector (RR) would do), its encoding MUST NOT be changed. 321 If a particular RR client cannot handle that encoding (as determined 322 by the BGP capability advertisement), then the NLRI in question 323 cannot be distributed to that client. For sound routing in certain 324 scenarios, this will require that all the RR clients be able to 325 handle whatever encodings any of them may generate. 327 5. Usage Examples 329 5.1. IPv4 over IPv6 Core 331 The extensions defined in this document may be used as discussed in 332 [I-D.ietf-softwire-mesh-framework] for the interconnection of IPV4 333 islands over an IPv6 backbone. In this application, Address Family 334 Border Routers (AFBR) (as defined in [RFC4925]) advertise IPv4 NLRI 335 information in the MP_REACH_NLRI along with an IPv6 next hop. 337 The MP_REACH_NLRI is encoded with: 339 o AFI=1 341 o SAFI=1 343 o Length of Next Hop Network Address = 16 (or 32) 345 o Network Address of Next Hop= IPv6 address of Next Hop 347 o NLRI= IPv4 routes 349 During BGP Capability Advertisement, the PE routers would include the 350 following fields in the Capabilities Optional Parameter: 352 o Capability Code set to "Extended Next Hop Encoding" 354 o Capability Value containing 357 5.2. IPv4 VPN over IPv6 Core 359 The extensions defined in this document may be used for support of 360 IPV4 VPNs over an IPv6 backbone. In this application, PE Routers 361 would advertise VPN-IPv4 NLRI information in the MP_REACH_NLRI along 362 with an IPv6 next hop. 364 The MP_REACH_NLRI is encoded with: 366 o AFI=1 368 o SAFI=128 370 o Length of Next Hop Network Address = 16 (or 32) 372 o Network Address of Next Hop= IPv6 address of Next Hop 374 o NLRI= IPv4-VPN routes 376 During BGP Capability Advertisement, the PE routers would include the 377 following fields in the Capabilities Optional Parameter : 379 o Capability Code set to "Extended Next Hop Encoding" 381 o Capability Value containing 384 6. IANA Considerations 386 This document defines, in section 3, a new Capability Code to 387 indicate the Extended Next Hop Encoding capability in the [RFC3392] 388 Capabilities Optional Parameter. The value for this new Capability 389 Code is to be allocated from the range 1 through 63 set aside for 390 allocation using the "IETF consensus" policy defined in [RFC2434]. 392 7. Security Considerations 394 This document does not raise any additional security issues beyond 395 those of BGP-4 and the MultiProtocol extensions for BGP-4. The same 396 security mechanisms are applicable. 398 8. Acknowledgments 400 The authors would like to thank Yakov Rekhter, Pranav Metha and John 401 Scudder for their contributions in the approach defined in this 402 document. 404 9. References 405 9.1. Normative References 407 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 408 Requirement Levels", BCP 14, RFC 2119, March 1997. 410 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 411 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 412 March 1999. 414 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 415 BGP-4", RFC 3107, May 2001. 417 [RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement 418 with BGP-4", RFC 3392, November 2002. 420 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 421 Architecture", RFC 4291, February 2006. 423 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 424 Networks (VPNs)", RFC 4364, February 2006. 426 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 427 "Multiprotocol Extensions for BGP-4", RFC 4760, 428 January 2007. 430 9.2. Informative References 432 [I-D.ietf-idr-dynamic-cap] 433 Chen, E. and S. Sangli, "Dynamic Capability for BGP-4", 434 draft-ietf-idr-dynamic-cap-09 (work in progress), 435 November 2006. 437 [I-D.ietf-l2vpn-signaling] 438 Rosen, E., "Provisioning, Autodiscovery, and Signaling in 439 L2VPNs", draft-ietf-l2vpn-signaling-08 (work in progress), 440 May 2006. 442 [I-D.ietf-softwire-mesh-framework] 443 Wu, J., Cui, Y., Li, X., Metz, C., Rosen, E., Barber, S., 444 Mohapatra, P., Scudder, J., and I. Property, "Softwire 445 Mesh Framework", draft-ietf-softwire-mesh-framework-03 446 (work in progress), January 2008. 448 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 449 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 450 October 1998. 452 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 453 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 454 IPv6 VPN", RFC 4659, September 2006. 456 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 457 R., Patel, K., and J. Guichard, "Constrained Route 458 Distribution for Border Gateway Protocol/MultiProtocol 459 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 460 Private Networks (VPNs)", RFC 4684, November 2006. 462 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 463 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 464 Provider Edge Routers (6PE)", RFC 4798, February 2007. 466 [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire 467 Problem Statement", RFC 4925, July 2007. 469 Authors' Addresses 471 Francois Le Faucheur 472 Cisco Systems 473 Greenside, 400 Avenue de Roumanille 474 Sophia Antipolis 06410 475 France 477 Email: flefauch@cisco.com 479 Eric Rosen 480 Cisco Systems, Inc. 481 1414 Massachusetts Avenue 482 Boxborough, MA 01719 483 USA 485 Email: erosen@cisco.com 487 Full Copyright Statement 489 Copyright (C) The IETF Trust (2008). 491 This document is subject to the rights, licenses and restrictions 492 contained in BCP 78, and except as set forth therein, the authors 493 retain all their rights. 495 This document and the information contained herein are provided on an 496 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 497 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 498 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 499 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 500 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 501 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 503 Intellectual Property 505 The IETF takes no position regarding the validity or scope of any 506 Intellectual Property Rights or other rights that might be claimed to 507 pertain to the implementation or use of the technology described in 508 this document or the extent to which any license under such rights 509 might or might not be available; nor does it represent that it has 510 made any independent effort to identify any such rights. Information 511 on the procedures with respect to rights in RFC documents can be 512 found in BCP 78 and BCP 79. 514 Copies of IPR disclosures made to the IETF Secretariat and any 515 assurances of licenses to be made available, or the result of an 516 attempt made to obtain a general license or permission for the use of 517 such proprietary rights by implementers or users of this 518 specification can be obtained from the IETF on-line IPR repository at 519 http://www.ietf.org/ipr. 521 The IETF invites any interested party to bring to its attention any 522 copyrights, patents or patent applications, or other proprietary 523 rights that may cover technology that may be required to implement 524 this standard. Please address the information to the IETF at 525 ietf-ipr@ietf.org. 527 Acknowledgment 529 Funding for the RFC Editor function is provided by the IETF 530 Administrative Support Activity (IASA).