idnits 2.17.00 (12 Aug 2021) /tmp/idnits51793/draft-lindem-ospf-route-attr-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 3979, Section 5, paragraph 1 on line 476. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 483. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 489. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 11) being 68 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 2740 (ref. 'OSPFV3') (Obsoleted by RFC 5340) ** Obsolete normative reference: RFC 2370 (ref. 'OPAQUE') (Obsoleted by RFC 5250) == Outdated reference: A later version (-01) exists of draft-shen-nhop-fastreroute-00 -- Possible downref: Normative reference to a draft: ref. 'NHOPFRR' Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Acee Lindem 2 Internet Draft Naiming Shen 3 Expiration Date: January 2004 Redback Networks 5 Extensions to OSPF for Advertising Optional Route Attributes 6 draft-lindem-ospf-route-attr-00.txt 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or IPR claims of which I am aware have been disclosed, and 12 any of which I become aware will be disclosed, in accordance with 13 RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as ``work in progress.'' 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 There are applications which require additional attributes to 34 be advertised with an OSPF route. The existing OSPF LSA 35 formats do not allow for backward compatible extension to advertise 36 these attributes. This draft proposes an extension to OSPF for 37 advertising additional attributes which will be associated with an 38 OSPF route. 40 Conventions used in this document 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 44 this document are to be interpreted as described in 45 RFC-2119 [BCP-14]. 47 1. Motivation 49 There are applications which require the advertisement of 50 additional attributes associated with an OSPF route. Examples 51 of such applications include: 53 o Association of an administrative tag with an intra-area or 54 inter-area route. 56 o For Nexthop FRR [NHOPFRR], advertising the next hop of an 57 inter-area route. 59 o Indication that the route corresponds to a loopback interface. 61 2. OSPF Route Attributes (RA) Opaque LSA 63 OSPF routers will optionally advertise additional route attributes 64 (RA) in an area-scoped or AS-scoped opaque-LSA [OPAQUE]. The 65 advertising OSPF router will originate an area-scoped (type 10) 66 opaque LSA to associate additional attributes with a route 67 advertised in a router-LSA (type 1), network-LSA (type 2), 68 summary-LSAs (type 3 or type 4) or NSSA-LSA (type 7). An 69 AS-scoped (type 11) Opaque-LSA will be originated to associate 70 additional attributes with a route advertised in an 71 AS-external-LSA (type 5). 72 For certain applications the additional route attributes may only 73 need to be advertised to a adjacent neighbor, in this case 74 a link-scoped (type 9) opaque LSA may be originated in place of 75 an area-scoped (type 10) or AS-scoped (type 11) opaque LSA. 77 The Route Attributes LSA will have an Opaque type of 5 and a 78 unique ID. 80 0 1 2 3 81 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 82 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 83 | LS age | Options | 9, 10, or 11 | 84 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 85 | 5 | Unique ID | 86 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 87 | Advertising Router | 88 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 89 | LS sequence number | 90 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 91 | LS checksum | length | 92 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 93 | Ref LSA Type | Prefix Length | 0 | 94 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 95 | Ref LSA ID | 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 | IPv4 Address | 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 | | 100 +- TLV's -+ 101 | ... | 103 Figure 1. OSPF Route Attributes LSA 105 Reference LSA Type 106 The type for the LSA advertising the IPv4 prefix. The 107 reference LSA type may be 1-5 or 7. 109 Prefix Length 110 The number of significant bits in the IPv4 address. For 111 router routes, a length of 32 MUST be specified. 113 Reference LSA ID 114 The LSA ID for the LSA advertising the IPv4 prefix. The 115 advertising router is not required to be respecified since 116 an OSPF router may not use this LSA to associate additional 117 attributes with LSAs that it does not originate. 119 IPv4 Address 120 The IPv4 address which requires association of additional 121 attributes. For OSPF router routes advertised in 122 Summary-ASBR LSAs, this will be the router ID. 124 The format of the TLV's within the body of a route attributes LSA 125 is the same as the format used by the Traffic Engineering 126 Extensions to OSPF [OSPF-TE]. The LSA payload consists of one or 127 more nested Type/Length/Value (TLV) triplets. The format of 128 each TLV is: 130 0 1 2 3 131 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 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Type | Length | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Value... | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 Figure 2. TLV Format 140 The Length field defines the length of the value portion in octets 141 (thus a TLV with no value portion would have a length of zero). The 142 TLV is padded to four-octet alignment; padding is not included in 143 the length field (so a three octet value would have a length of 144 three, but the total size of the TLV would be eight octets). Nested 145 TLV's are also 32-bit aligned. For example, a one byte value 146 would have the length field set to 1, and three bytes of padding 147 would be added to the end of the value portion of the TLV. 148 Unrecognized types are ignored. 150 2.1 OSPF Route Tag TLV 152 The first defined TLV in the body of an RA opaque LSA is 153 the Route Tag TLV. It allows one or more tags to be associated with 154 a given OSPF routes. Its use is optional. 156 The format of the Route Tag TLV is as follows: 158 0 1 2 3 159 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 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Type | Length | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Tag 1 | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 o o 166 o o 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Tag N | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 Figure 4. OSPF Router Capabilities TLV 173 Type A 16 bit field set to 1. 174 Length A 16 bit field that indicates the length of the value 175 portion in bytes. The value will be N * 4 where N is the 176 number of advertised tags. The maximum number of tags 177 that can be associated with a route is TBD. 178 Value The value is comprised of one or more tags. The use of 179 the tags is beyond the scope of this document but can be 180 used for applications such as marking a particular route 181 for a specific action or preference. 183 2.2 OSPF Inter-Area Route Attribute TLV 185 This Inter-Area Route Attribute TLV in RA opaque LSA is to 186 allow the area border routers (ABRs) to advertise certain 187 route attributes related to topology information in another 188 area. For example, the ABR can advertise the nexthop 189 OSPF node for an inter-area prefix. This can be used for 190 Nexthop FRR of IP traffic in inter-area node protection case. 191 Its use is optional. 193 The format of the Inter-area Route Attribute TLV is as follows: 195 0 1 2 3 196 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 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Type | Length | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Attr Flag 1 | Reserved | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Router-ID 1 | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 o o 205 o o 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Attr Flag N | Reserved | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Router-ID N | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 Type A 16 bit field set to 2. 213 Length A 16 bit field that indicates the length of the value 214 portion in bytes. The value will be N * 8 where N is the 215 number of route attributes. 216 Value The value is comprised of one or more route attributes. 217 It has an Attribute Flag field, a Reserved field and 218 a Router-ID field. 219 Attribute Flag 220 This is an 16-bits field, currently defined: 222 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 |N|O|B| Reserved | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 Bits Description 229 N Nexthop Bit. If set, the router advertising this 230 IP prefix with this TLV uses router specified 231 in the Router-ID field as the nexthop node. 233 O Origination Bit. If set, the router advertising this 234 IP prefix with this TLV had learnt this prefix 235 from the router specified in the Router-ID field. 237 B Non-Best Path Bit. The N bit and B bit are mutually 238 exclusive. If set, the ABR advertising this this TLV 239 does not consider router specified in the Router-ID 240 field to be on the IGP best path to reach the 241 IP prefix. 243 Router-ID This is a 32-bit number representing the router which 244 can be used to forward traffic towards the destination 245 for the prefixes. 247 The list may contain multiple (Attribute Flag, Router-ID) tuples to 248 handle ECMP or non-ECMP cases. 250 If this TLV is being used in support of node protection, the RA 251 opaque LSA containing the Nexthop attributes need only be flooded 252 using a link-scoped (type 9) LSA. 254 3. Operation of OSPF Routers Originating the RA Opaque LSA 256 OSPF routers originating an RA opaque LSA should directly correlate 257 the existence with the reference LSA. In other words, the RA opaque 258 LSA MUST only be originated when the referenced LSA has been 259 originated and should purge (i.e., MaxAged) the RA opaque LSA when 260 the referenced LSA is purged. Reoriganation of either the 261 referenced LSA or the RA opaque LSA do require reorignation of the 262 other (unless of course, the underlying reason for the reorgination 263 affects both). 265 4. Operation of OSPF Routers 267 OSPF routers supporting the RA opaque LSA MUST find the 268 reference LSA and associate the received LSA with the reference 269 LSA. If the reference LSA is chosen as the best path during the 270 SPF computation [OSPF] then the additional attributes in the RA 271 opaque LSA will be associated with the route and handled in an 272 application specific manner. In essence, the RA opaque LSA and the 273 LSA it references are concatentated. 275 In the case of ECMP with more than one of the contributing LSAs 276 having route attributes, the route will have a superset of optional 277 route attributes. In the case of conflicting route attributes, 278 the route will inherit the attributes the LSA with the highest 279 advertising router ID. 281 5. Operation of OSPF Area Border Routers 283 OSPF Area Border Routers (ABRs) supporting RA opaque LSAs will 284 be required to originate an RA opaque LSA whenever they propagate 285 routes with additional attributes from one area to another. This 286 implies that the ABR will: 288 1. Originate an RA area-scoped opaque LSA when it originates 289 a summary LSA (type 3 or 4) for an intra-area or inter-area 290 route with additional attributes. 292 2. Originate an RA AS-scoped opaque LSA when it originates 293 an AS external LSA corresponding to a translated NSSA route 294 with additional attributes. 296 3. Originate an RA area-scoped opaque LSA when it originates 297 a summary LSA for an area range and policy dictates that the 298 ABR should associate additional attributes with the 299 area range. 301 4. Originate an RA AS-scoped opaque LSA when it originates 302 an AS external LSA for an NSSA area range and policy dictates 303 that the ABR should associate additional attributes with the 304 NSSA area range. 306 6. OSPFv3 Route Attribute LSA 308 For OSPFv3 [OSPFV3], the OSPFv3 Route Attributes (RA) LSA will be 309 similiar to the OSPF opaque LSA. It will have it's own OSPFv3 310 LSA function code assigned by IANA. The U bit will always 1 and 311 and S1 and S2 bits will be the same as the referenced LSA type. 312 Optionally, a link-scoped LSA may be orignated when the route 313 attributes need not be propagated beyond immediate neighbors. 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | LS age |1|S|S| TBD | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Link State ID | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Advertising Router | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | LS sequence number | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | LS checksum | length | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Ref LSA Type | Prefix Length | 0 | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Ref LSA ID | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | IPv6 Address | 333 +- -+ 334 : : 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | | 337 +- TLV's -+ 338 | ... | 340 Figure 1. OSPF Route Attributes LSA 342 Reference LSA Type 343 The type for the LSA advertising the IPv6 prefix. The 344 reference LSA type may be 0x2001-0x2005, 0x2007, 0x2009, 345 of 0x0008. 347 Prefix Length 348 The number of significant bits in the IPv6 address. For 349 router routes, a length of 32 MUST be specified. 351 Reference LSA ID 352 The LSA ID for the LSA advertising the IPv6 prefix. The 353 advertising router is not required to be respecified since 354 an OSPFv3 router may not use this LSA to associate additional 355 attributes with LSAs that it does not originate. 357 IPv6 Address 358 The IPv6 address which requires association of additional 359 attributes. IPv6 Address Prefix is an encoding of the prefix 360 itself as an even multiple of 32-bit words, padding with zero 361 bits as necessary; this encoding consumes (Prefix Length 362 + 31) / 32) 32-bit words. For OSPFv3 router routes advertised 363 in Inter-Area-Router-LSAs, this will be the router ID. 365 6.1 Operation of OSPFv3 Area Border Routers 367 OSPFv3 Area Border Routers (ABRs) supporting RA LSAs will 368 be required to originate an RA LSA whenever they propagate 369 routes with additional attributes from one area to another. 370 The rules documented in Section 5 apply to Inter-Area-Prefix-LSAs, 371 Inter-Area-Router-LSAs, and NSSA LSAs. 373 6.2 Operation of OSPFv3 Designated Routers 375 Operation of OSPFv3 Routers acting as a DR is similar to OSPFv3 376 ABRs in that they will propagate route attributes associated with 377 the prefixes advertised in the intra-area-prefix-LSA referencing 378 the DR's network LSA. 380 7. Security Consideration 382 This memo does not create any new security issues for the OSPF 383 protocol. Security considerations for the base OSPF protocol are 384 covered in [OSPF]. Security considerations for OSPFv3 are covered 385 in [OSPFV3]. 387 8. Acknowledgments 389 TBD. 391 9. IANA Considerations 393 A new OSPF opaque LSA type and OSPFv3 LSA function code will need 394 to be assigned by IANA. Additionally, IANA will need to have 395 registries for the Route attributes LSA TLV's. The TLV assignee 396 will be responsible for allocation of any sub-TLV's for the IANA 397 assigned TLV. All TLV's and sub-TLV's will be subject to OSPF 398 WG review. 400 10. References 402 Normative References 404 [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 406 [OSPFV3] Colton, R., J. Moy, and D. Ferguson, "OSPF for IPv6", 407 RFC 2740, December 1999. 409 [OPAQUE] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 410 1998. 412 [NHOPFRR] Shen, N., and P. Pan, "Nexthop Fast ReRoute for IP and 413 MPLS", draft-shen-nhop-fastreroute-00.txt, Work In 414 Progress. 416 [BCP-14] Bradner, S., "Keywords for use in RFCs to Indicate 417 Requirement Level", BCP 14, RFC 2119, March 1997. 419 Informative References 421 [OSPF-TE] Katz, D., D. Yeung and K. Kompella, "Traffic Engineering 422 Extensions to OSPF", RFC 3630, September 2003. 424 11. Author Information 426 Acee Lindem 427 Redback Networks 428 102 Carric Bend Court 429 Cary, NC 27519 430 e-mail: acee@redback.com 432 Naiming Shen 433 Redback Networks 434 350 Holger Way 435 San Jose, CA 95134 436 e-mail: naiming@redback.com 437 12. Full Copyright Statement 439 Copyright (C) The Internet Society (2004). This document is subject 440 to the rights, licenses and restrictions contained in BCP 78 and 441 except as set forth therein, the authors retain all their rights. 443 This document and translations of it may be copied and furnished to 444 others, and derivative works that comment on or otherwise explain it 445 or assist in its implementation may be prepared, copied, published 446 and distributed, in whole or in part, without restriction of any 447 kind, provided that the above copyright notice and this paragraph are 448 included on all such copies and derivative works. However, this 449 document itself may not be modified in any way, such as by removing 450 the copyright notice or references to the Internet Society or other 451 Internet organizations, except as needed for the purpose of 452 developing Internet standards in which case the procedures for 453 copyrights defined in the Internet Standards process must be 454 followed, or as required to translate it into languages other than 455 English. 457 The limited permissions granted above are perpetual and will not be 458 revoked by the Internet Society or its successors or assignees. 460 This document and the information contained herein is provided on an 461 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 462 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 463 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 464 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 465 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 467 13. Intellectual Property 469 The IETF takes no position regarding the validity or scope of any 470 Intellectual Property Rights or other rights that might be claimed to 471 pertain to the implementation or use of the technology described in 472 this document or the extent to which any license under such rights 473 might or might not be available; nor does it represent that it has 474 made any independent effort to identify any such rights. Information 475 on the procedures with respect to rights in RFC documents can be 476 found in BCP 78 and BCP 79. 478 Copies of IPR disclosures made to the IETF Secretariat and any 479 assurances of licenses to be made available, or the result of an 480 attempt made to obtain a general license or permission for the use of 481 such proprietary rights by implementers or users of this 482 specification can be obtained from the IETF on-line IPR repository at 483 http://www.ietf.org/ipr. 485 The IETF invites any interested party to bring to its attention any 486 copyrights, patents or patent applications, or other proprietary 487 rights that may cover technology that may be required to implement 488 this standard. Please address the information to the IETF at ietf- 489 ipr@ietf.org. 491 14. Acknowledgement 493 Funding for the RFC Editor function is currently provided by the 494 Internet Society.