idnits 2.17.1 draft-ietf-idr-encaps-safi-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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 491. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 502. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 509. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 515. 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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 42 has weird spacing: '...reement betwe...' == Line 99 has weird spacing: '...through a tun...' == Line 127 has weird spacing: '...ulation attri...' == Line 134 has weird spacing: '...uld ask wheth...' == Line 135 has weird spacing: '... simply attac...' == (5 more instances...) -- 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 (August 2007) is 6061 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: 'SOFTWIRE' is defined on line 458, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-AF' == Outdated reference: A later version (-03) exists of draft-ietf-softwire-problem-statement-02 == Outdated reference: A later version (-06) exists of draft-ietf-softwire-mesh-framework-01 Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Pradosh Mohapatra 3 Internet Draft Cisco Systems, Inc. 4 Expiration Date: February 2008 5 Eric Rosen 6 Cisco Systems, Inc. 8 August 2007 10 BGP Encapsulation SAFI and BGP Tunnel Encapsulation Attribute 12 draft-ietf-idr-encaps-safi-00.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 In certain situations, transporting a packet from one BGP speaker to 40 another, the BGP next hop, requires that the packet be encapsulated 41 by the first BGP speaker and decapsulated by the second. To support 42 these situations, there needs to be some agreement between the two 43 BGP speakers with regard to the "encapsulation information", i.e., 44 the format of the encapsulation header as well as the contents of 45 various fields of the header. 47 The encapsulation information need not be signaled for all 48 encapsulation types. In the cases where the signaling is required 49 (such as L2TPv3, GRE with key), This draft specifies a method by 50 which BGP speakers can signal encapsulation information to each 51 other. The signaling is done by sending BGP updates using the 52 "Encapsulation SAFI" and IPv4 or IPv6 AFI. In the cases where no 53 encapsulation information needs to be signaled (such as GRE without 54 key), this draft specifies a BGP extended community that can be 55 attached to UPDATE messages that carry payload prefixes to indicate 56 the encapsulation protocol type to be used. 58 Table of Contents 60 1 Specification of requirements ...................... 2 61 2 Introduction ....................................... 3 62 3 Encapsulation NLRI Format .......................... 4 63 4 Tunnel Encapsulation Attribute ..................... 5 64 4.1 Encapsulation sub-TLV .............................. 7 65 4.2 Protocol Type sub-TLV .............................. 8 66 4.3 Tunnel Type Selection .............................. 9 67 4.4 BGP Encapsulation Extended Community ............... 9 68 5 Capability advertisement ........................... 10 69 6 Security Considerations ............................ 10 70 7 IANA Considerations ................................ 10 71 8 Acknowledgements ................................... 11 72 9 Normative References ............................... 11 73 10 Informative References ............................. 11 74 11 Authors' Addresses ................................. 11 75 12 Full Copyright Statement ........................... 12 76 13 Intellectual Property .............................. 12 78 1. Specification of requirements 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in [RFC2119]. 84 2. Introduction 86 Consider the case of a router R1 forwarding an IP packet P. Let D be 87 P's IP destination address. R1 must look up D in its forwarding 88 table. Suppose that the "best match" route for D is route Q, where Q 89 is a BGP-distributed route whose "BGP next hop" is router R2. And 90 suppose further that the routers along the path from R1 to R2 have 91 entries for R2 in their forwarding tables, but do NOT have entries 92 for D in their forwarding tables. For example, the path from R1 to R2 93 may be part of a "BGP-free core", where there are no BGP-distributed 94 routes at all in the core. Or, as in [Softwires-Mesh-Frame-work], D 95 may be an IPv4 address while the intermediate routers along the path 96 from R1 to R2 may support only IPv6. 98 In cases such as this, in order for R1 to properly forward packet P, 99 it must encapsulate P, and send P "through a tunnel" to R2. For 100 example, R1 may encapsulate P using GRE, L2TPv3, IP-in-IP, etc., 101 where the destination IP address of the encapsulation header is the 102 address of R2. 104 In order for R1 to encapsulate P for transport to R2, R1 must know 105 what encapsulation protocol to use for transporting what sorts of 106 packets to R2. R1 must also know how to fill in the various fields of 107 the encapsulation header. With certain encapsulation types, this 108 knowledge may be acquired by default or through manual configuration. 109 Other encapsulation protocols have fields such as session id, key, or 110 cookie which must be filled in. It would not be desirable to require 111 every BGP speaker to be manually configured with the encapsulation 112 information for every one of its BGP next hops. 114 In this draft, we specify a way in which BGP itself can be used by a 115 given BGP speaker to tell other BGP speakers, "if you need to 116 encapsulate packets to be sent to me, here's the information you need 117 to properly form the encapsulation header". A BGP speaker signals 118 this information to other BGP speakers by using a distinguished SAFI 119 value, the Encapsulation SAFI. The encapsulation SAFI can be used 120 with the AFI for IPv4 or with the AFI for IPv6. The IPv4 AFI is used 121 when the encapsulated packets are to be sent using IPv4; the IPv6 AFI 122 is used when the encapsulated packets are to be sent using IPv6. 124 In a given BGP update, the NLRI of the encapsulation SAFI consists of 125 the IP address (in the family specified by the AFI) of the originator 126 of that update. The encapsulation information is specified in one or 127 more BGP "tunnel encapsulation attributes" (specified herein). These 128 attributes specify the encapsulation protocols that may be used, as 129 well as specifying whatever additional information (if any) is needed 130 in order to properly use those protocols. Other attributes, e.g., 131 communities or extended communities, may also be included. 133 Since the encapsulation information is coded as a set of attributes, 134 one could ask whether a new SAFI is really required. After all, a 135 BGP speaker could simply attach the tunnel encapsulation attributes 136 to each prefix (like Q in our example) that it advertises. But with 137 that technique, any change in the encapsulation information would 138 cause a very large number of updates. Unless one really wants to 139 specify different encapsulation information for each prefix, it is 140 much better to have a mechanism in which a change in the 141 encapsulation information causes a BGP speaker to advertise only a 142 single update. Conversely, when prefixes get modified, the tunnel 143 encapsulation information need not be exchanged. 145 In this specification, a single SAFI is used to carry information for 146 all encapsulation protocols. One could have taken an alternative 147 approach of defining a new SAFI for each encapsulation protocol. 148 However, with the specified approach, encapsulation information can 149 pass transparently and automatically through intermediate BGP 150 speakers (e.g., route reflectors) that do not necessarily understand 151 the encapsulation information. This works because the encapsulation 152 attribute is defined as an optional transitive attribute. New 153 encapsulations can thus be added without the need to reconfigure any 154 intermediate BGP system. If adding a new encapsulation required using 155 a new SAFI, the information for that encapsulation would not pass 156 through intermediate BGP systems unless those systems were 157 reconfigured to support the new SAFI. 159 For encapsulation protocols where no encapsulation information needs 160 to be signaled (such as GRE without key), the egress router MAY still 161 want to specify the protocol to use for transporting packets from the 162 ingress router. This draft specifies a new BGP extended community 163 that can be attached to UPDATE messages that carry payload prefixes 164 for this purpose. 166 3. Encapsulation NLRI Format 168 The NLRI, defined below, is carried in BGP UPDATE messages [RFC4271] 169 using BGP multiprotocol extensions [RFC4760] with an AFI of 1 or 2 170 (IPv4 or IPv6) [IANA-AF] and a SAFI value to be assigned by IANA 171 (called as Encapsulation SAFI). 173 The NLRI is encoded in a format as defined in section 5 of [RFC4760] 174 (a 2-tuple of the form ). The value field is 175 structured as follows: 177 +-----------------------------------------------+ 178 | Endpoint address (Variable) | 179 +-----------------------------------------------+ 181 - Endpoint Address: This field identifies the BGP speaker 182 originating the update. It is typically one of the interface 183 addresses configured at the router. The length of the endpoint 184 address is dependent on the AFI being advertised. If the AFI is 185 set to IPv4 (1), the the endpoint address is a 4-octet IPv4 186 address whereas if the AFI is set to IPv6 (2), the endpoint 187 address is a 16-octet IPv6 address. 189 An update message that carries the MP_REACH_NLRI or MP_UNREACH_NLRI 190 with Encapsulation SAFI MUST also carry the BGP mandatory attributes: 191 ORIGIN, AS_PATH, and LOCAL_PREF (for IBGP neighbors) as defined in 192 [RFC4271]. In addition, such an update message can also contain any 193 of the BGP optional attributes, like Community or Extended Community 194 attribute to influence an action on the receiving speaker. 196 When a BGP speaker advertises the Encapsulation NLRI via BGP, it uses 197 its own address as the BGP nexthop in the MP_REACH_NLRI or 198 MP_UNREACH_NLRI attribute. The nexthop address is set based on the 199 AFI in the attribute. For example, if the AFI is set to IPv4 (1), 200 the nexthop is encoded as a 4-byte IPv4 address. If the AFI is set to 201 IPv6 (2), the nexthop is encoded as a 16-byte IPv6 address of the 202 router. On the receiving router, the BGP nexthop of such an update 203 message is validated by performing a recursive route lookup operation 204 in the routing table. 206 Bestpath selection of Encapsulation NLRIs is governed by the decision 207 process outlined in section 9.1 of [RFC4271]. The encapsulation data 208 carried through other attributes in the message are to be used by the 209 receiving router only if the NLRI has a bestpath. 211 4. Tunnel Encapsulation Attribute 213 Tunnel Encapsulation attribute is an optional transitive attribute 214 that is composed of a set of TLVs. The type code of the attribute is 215 to be assigned by IANA. Each TLV contains information corresponding 216 to a particular tunnel technology. The TLV is structured as follows: 218 0 1 2 3 219 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Tunnel Type (2 Octets) | Length (2 Octets) | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | | 224 | Value | 225 | | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 Tunnel Type (2 octets): It identifies the type of the tunneling 229 technology being signaled. This document defines the following types: 231 - L2TPv3: Tunnel Type = 1 233 - GRE: Tunnel Type = 2 235 Unknown types are to be ignored and skipped upon receipt. 237 Length (2 octets): the total number of octets of the Value field. 239 Value (variable): The value is comprised of multiple sub-TLV's. Each 240 sub-TLV consists of three fields: a one-octet type, one-octet length, 241 and zero or more octets of value. The sub-TLV is structured as 242 follows: 244 +-----------------------------------+ 245 | Sub-TLV Type (1 Octet) | 246 +-----------------------------------+ 247 | Sub-TLV Length (1 Octet) | 248 +-----------------------------------+ 249 | Sub-TLV Value (Variable) | 250 | | 251 +-----------------------------------+ 253 Sub-TLV Type (1 octet): Each sub-TLV type defines a certain property 254 about the tunnel TLV that contains this sub-TLV. The following are 255 the types defined in this document: 257 - Encapsulation: sub-TLV type = 1 259 - Protocol type: sub-TLV type = 2 261 When the TLV is being processed by a BGP speaker that will be 262 performing encapsulation, any unknown sub-TLVs MUST be ignored and 263 skipped. However if the TLV is understood, the entire TLV MUST NOT be 264 ignored just because it contains an unknown sub-TLV. 266 Sub-TLV Length (1 octet): the total number of octets of the sub-TLV 267 value field. 269 Sub-TLV Value (variable): Encodings of the value field depend on the 270 sub-TLV type as enumerated above. The following sub-sections define 271 the encoding in detail. 273 4.1. Encapsulation sub-TLV 275 The syntax and semantics of the encapsulation sub-TLV is determined 276 by the tunnel type of the TLV that contains this sub-TLV. 278 When the tunnel type of the TLV is L2TPv3, the following is the 279 structure of the value field of the encapsulation sub-TLV: 281 0 1 2 3 282 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Session ID (4 octets) | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | | 287 | Cookie (Variable) | 288 | | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 * Session ID: a 4-octet value locally assigned by the advertising 292 router that serves as a lookup key in the incoming packet's 293 context. 295 * Cookie: an optional, variable length (encoded in octets - 0 to 8 296 octets) value used by L2TPv3 to check the association of a 297 received data message with the session identified by the Session 298 ID. The Cookie value is tightly coupled with the Session ID. 300 The length of the cookie is not encoded explicitly, but can be 301 calculated as: (sub-TLV length - 4) 303 When the tunnel type of the TLV is GRE, the following is the 304 structure of the value field of the encapsulation sub-TLV: 306 0 1 2 3 307 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | GRE Key (4 octets) | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 * GRE Key: A 4 Octet field that is generated by the advertising 313 router. The actual method by which the key is obtained is beyond 314 the scope of the document. The key is inserted into the GRE 315 encapsulation header of the payload packets sent by ingress 316 routers to the advertising router. It is intended to be used for 317 identifying extra context information about the received payload. 319 Note that the key is optional. Unless a key value is being 320 advertised, the GRE encapsulation sub-TLV MUST NOT be present. 322 4.2. Protocol Type sub-TLV 324 The protocol type sub-TLV MAY be encoded to indicate the type of the 325 payload packets that will be encapsulated with the tunnel parameters 326 being signaled in the TLV. The value field of the sub-TLV contains a 327 2-octet protocol type that is one of the types defined in [IANA-AF] 328 as ETHER TYPEs. 330 For example, if we want to use three L2TPv3 sessions, one carrying 331 IPv4 packets, one carrying IPv6 packets, and one carrying MPLS 332 packets, the egress router will include three TLVs of L2TPv3 333 encapsulation type, each specifying a different session id and a 334 different payload type. The protocol type sub-TLV for these will be 335 IPv4 (protocol type = 0x0800), IPv6 (protocol type = 0x86dd), and 336 MPLS (protocol type = 0x8847) respectively. This informs the ingress 337 routers of the appropriate encapsulation information to use with each 338 of the given protocol types. Insertion of the specified session id at 339 the ingress routers allows the egress to process the incoming packets 340 correctly, according to their protocol type. 342 Note that the protocol type sub-TLV is optional, e.g. if the 343 tunneling technology is GRE, this sub-TLV is not required. 345 4.3. Tunnel Type Selection 347 A BGP speaker may include multiple tunnel TLVs in the tunnel 348 attribute. The receiving speaker MAY have local policies defined to 349 choose different tunnel types for different sets/types of payload 350 prefixes received from the same BGP speaker. For instance, if a BGP 351 speaker includes both L2TPv3 and GRE tunnel types in the tunnel 352 attribute and it also advertises IPv4 and IPv6 prefixes, the ingress 353 router may have local policy defined to choose L2TPv3 for IPv4 354 prefixes (provided the protocol type received in the tunnel attribute 355 matches) and GRE for IPv6 prefixes. 357 Additionally, the Encapsulation SAFI UPDATE message can contain a 358 community or extended-community as a way to color the corresponding 359 tunnel TLV(s). The same community or extended community can then be 360 attached to the UPDATE messages that contain payload prefixes. This 361 way, the BGP speaker can express the fact that it expects the packets 362 corresponding to these payload prefixes to be received with a 363 particular tunnel encapsulation header. 365 In a multi-vendor deployment that has routers supporting different 366 tunneling technologies, attaching community and/or extended-community 367 to the Encapsulation SAFI UPDATE message can serve as a 368 classification mechanism (for example, set A of routers for GRE and 369 set B of routers for L2TPv3). The ingress router can then choose the 370 encapsulation data appropriately while sending packets to an egress 371 router. 373 These communities/extended communities, if used, will be user defined 374 and configured locally on the routers. 376 4.4. BGP Encapsulation Extended Community 378 We define a BGP opaque extended community that can be attached to BGP 379 UPDATE messages to indicate the encapsulation protocol to be used for 380 sending packets from an ingress router to an egress router. 381 Considering our example from the "Introduction" section, R2 MAY 382 include this extended community specifying a particular tunnel type 383 to be used in the UPDATE message that carries route Q to R1. This is 384 useful if there are no explicit encapsulation information to be 385 signaled using the encap SAFI for a tunneling protocol (such as GRE 386 without key). 388 0 1 2 3 389 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | 0x03 | TBD | Reserved | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Reserved | Tunnel Type | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 The value of the high-order octet of the extended type field is 0x03, 397 which indicates it's transitive. The value of the low-order octet of 398 the extended type field is TBD. 400 The last two octets of the value field encode a tunnel type as 401 defined in this document. 403 5. Capability advertisement 405 A BGP speaker that wishes to exchange tunnel endpoint information 406 must use the Multiprotocol Extensions Capability Code as defined in 407 [RFC4760], to advertise the corresponding (AFI, SAFI) pair. 409 6. Security Considerations 411 If a third party is able to modify any of the information that is 412 used to form encapsulation headers, or to choose a tunnel type, or to 413 choose a particular tunnel for a particular payload type, user data 414 packets may end up getting misrouted, misdelivered, and/or dropped. 416 7. IANA Considerations 418 This document defines a new NLRI format, called Encapsulation NLRI, 419 to be carried in BGP using multiprotocol extensions. It is to be 420 assigned its own SAFI. 422 This document defines a new BGP optional transitive attribute type, 423 called Tunnel attribute and a new opaque extended community sub-type. 424 These values are to be assigned by IANA. 426 This document introduces Tunnel TLVs and sub-TLVs. The type space for 427 both of these should be set up by IANA as a registry of 2-octet 428 tunnel types and 1-octet sub-TLV types. These should be assigned on a 429 first-come- first-serve basis. 431 8. Acknowledgements 433 This specification builds on prior work by Gargi Nalawade, Ruchi 434 Kapoor, Dan Tappan, David Ward, Scott Wainner, Simon Barber, and 435 Chris Metz. The current authors wish to thank all these authors for 436 their contribution. 438 The authors would like to thank John Scudder, Robert Raszuk, Keyur 439 Patel, Chris Metz, and Yakov Rekhter for their valuable comments and 440 suggestions. 442 9. Normative References 444 [RFC4271] Rekhter, Y., Li T., and Hares S.(editors), "A Border 445 Gateway Protocol 4 (BGP-4)," RFC 4271, January 2006. 447 [RFC4760] Bates et al, "Multiprotocol Extensions for BGP-4," RFC 448 4760, January 2007. 450 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 451 Requirement Levels," March 1997. 453 [IANA-AF] "Address Family Numbers," Reachable from 454 http://www.iana.org/numbers.html 456 10. Informative References 458 [SOFTWIRE] Dawkins S. (editor), "Softwire Problem Statement," draft- 459 ietf-softwire-problem-statement-02.txt, May 2006. 461 [Softwires-Mesh-Frame-work] Wu, J. et al, "Softwire Mesh Framework," 462 draft-ietf-softwire-mesh-framework-01.txt, June 2007. 464 11. Authors' Addresses 466 Pradosh Mohapatra 467 Cisco Systems, Inc. 468 170 Tasman Drive 469 San Jose, CA, 95134 470 Email: pmohapat@cisco.com 471 Eric Rosen 472 Cisco Systems, Inc. 473 1414 Massachusetts Avenue 474 Boxborough, MA, 01719 475 E-mail: erosen@cisco.com 477 12. Full Copyright Statement 479 Copyright (C) The IETF Trust (2007). 481 This document is subject to the rights, licenses and restrictions 482 contained in BCP 78, and except as set forth therein, the authors 483 retain all their rights. 485 This document and the information contained herein are provided on an 486 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 487 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 488 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 489 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 490 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 491 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 493 13. Intellectual Property 495 The IETF takes no position regarding the validity or scope of any 496 Intellectual Property Rights or other rights that might be claimed to 497 pertain to the implementation or use of the technology described in 498 this document or the extent to which any license under such rights 499 might or might not be available; nor does it represent that it has 500 made any independent effort to identify any such rights. Information 501 on the procedures with respect to rights in RFC documents can be 502 found in BCP 78 and BCP 79. 504 Copies of IPR disclosures made to the IETF Secretariat and any 505 assurances of licenses to be made available, or the result of an 506 attempt made to obtain a general license or permission for the use of 507 such proprietary rights by implementers or users of this 508 specification can be obtained from the IETF on-line IPR repository at 509 http://www.ietf.org/ipr. 511 The IETF invites any interested party to bring to its attention any 512 copyrights, patents or patent applications, or other proprietary 513 rights that may cover technology that may be required to implement 514 this standard. Please address the information to the IETF at ietf- 515 ipr@ietf.org.