idnits 2.17.1 draft-ietf-idr-extcomm-iana-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year (Using the creation date from RFC4360, updated by this document, for RFC5378 checks: 2001-07-10) -- 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 22, 2013) is 3893 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 4020 (Obsoleted by RFC 7120) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group Eric C. Rosen 3 Internet Draft Cisco Systems, Inc. 4 Intended Status: Standards Track 5 Updates: 4360,5701 Yakov Rekhter 6 Expires: February 22, 2014 Juniper Networks, Inc. 8 August 22, 2013 10 IANA Registries for BGP Extended Communities 12 draft-ietf-idr-extcomm-iana-00.txt 14 Abstract 16 This document reorganizes the IANA Registries for the type values and 17 sub-type values of BGP Extended Communities attribute and the BGP 18 IPv6-Address-Specific Extended Communities attribute. This is done 19 in order to remove inter-dependencies among the registries, thus 20 making it easier for IANA to determine which codepoints are available 21 for assignment in which registries. This document also clarifies the 22 information that must be provided to IANA when requesting an 23 allocation from one or more of these registries. These changes are 24 compatible with the existing allocations, and thus do not affect 25 protocol implementations. The changes will however impact the "IANA 26 Considerations" sections of future protocol specifications. This 27 document updates RFCs 4360 and 5701. 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt. 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 Copyright and License Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1 Introduction .......................................... 4 68 2 Types, Sub-Types, and Registries ...................... 4 69 3 Applicability to IPv6 Address Specific EC Attribute ... 5 70 4 How to Request EC Type and/or Sub-Type Codepoints ..... 5 71 5 IANA Considerations ................................... 7 72 5.1 Registries for the TYPE Field ......................... 7 73 5.1.1 Transitive Types ...................................... 7 74 5.1.2 Non-Transitive Types .................................. 9 75 5.2 Registries for the Sub-Type Field ..................... 10 76 5.2.1 EVPN Sub-Types ........................................ 10 77 5.2.2 Transitive Two-Octet AS-Specific Sub-Types ............ 10 78 5.2.3 Non-Transitive Two-Octet AS-Specific Sub-Types ........ 11 79 5.2.4 Transitive Four-Octet AS-Specific Sub-Types ........... 12 80 5.2.5 Non-Transitive Four-Octet AS-Specific Sub-Types ....... 12 81 5.2.6 Transitive IPv4-Address-Specific Sub-Types ............ 13 82 5.2.7 Non-Transitive IPv4-Address-Specific Sub-Types ........ 13 83 5.2.8 Transitive Opaque Extended Community Sub-Types ........ 14 84 5.2.9 Non-Transitive Opaque Extended Community Sub-Types .... 14 85 5.2.10 Generic Transitive Experimental Use Sub-Types ......... 15 86 5.2.11 Registries for the Value Field ........................ 15 87 5.2.11.1 Traffic Action Field .................................. 15 88 5.3 Registries for IPv6-Address-Specific ECs .............. 15 89 5.3.1 Transitive Types ...................................... 15 90 5.3.2 Non-Transitive Types .................................. 16 91 6 Security Considerations ............................... 16 92 7 Acknowledgments ....................................... 17 93 8 Authors' Addresses .................................... 17 94 9 Normative References .................................. 17 96 1. Introduction 98 RFC 4360 [RFC4360] defines the BGP "Extended Communities" (EC) 99 attribute. This attribute consists of a sequence of eight-octet 100 "extended communities". The high-order octet is defined to be the 101 "Type" field. Each Type has a range of values for "Transitive 102 Extended Community Types" and a range of values for "Non-transitive 103 Extended Community Types". Some of these ranges are further sub- 104 divided into a sub-range of values to be assigned by IANA under the 105 "Standards Action (with Early Allocation)" policy a sub-range of 106 values to be assigned by IANA under the "First Come First Served" 107 policy, and a sub-range for "experimental use". (See [RFC5226], 108 [RFC4020], and [RFC3692] for an explanation of these policies.) 110 For some Extended Community Types, the second octet of the Extended 111 Community is a "Sub-Type" field, and the remaining six octets are the 112 "Value" field. These are referred to as "Extended Types". For other 113 types, there is no Sub-Type field, and the Value field contains seven 114 octets. These are referred to as "Regular Types". 116 RFC 4360 is not very specific about how the IANA registries for 117 Extended Community Types and/or Sub-Types are to be organized, and 118 this has led to some confusion. The purpose of this document is to 119 reorganize the registries to make the IANA codepoint allocation task 120 more straightforward. 122 2. Types, Sub-Types, and Registries 124 The high-order octet of an Extended Community will be known as the 125 "Type Field". 127 There will be one IANA registry for "Transitive Extended Community 128 Types" (see section 5.1.1), and one for "Non-transitive Extended 129 Community Types" (section 5.1.2). Each registry specifies three 130 ranges, and each range is associated with a particular IANA 131 allocation policy. 133 There will be a set of IANA registries for Extended Community Sub- 134 Types (see section 5.2). Each such registry will have a range of 135 0x00-0xFF. Values in the range 0x00-0xBF are assignable by IANA 136 according to the "First Come, First Served" allocation policy of 137 [RFC5226]. Values in the range 0xC0-0xFF are assignable by IANA 138 according to the "IETF Review" allocation policy of [RFC5226]. 140 If a particular Type has Sub-Types, that Type's entry in its Type 141 registry identifies its Sub-Type registry. Note that some Types do 142 not have Sub-Types. When the request is made to establish a new Type 143 registry, the request must specify whether or not there is to be a 144 Sub-Type registry associated with that Type. 146 Whether a given Type has Sub-Types is determined when the Type is 147 initially defined; this cannot be changed later. 149 3. Applicability to IPv6 Address Specific EC Attribute 151 RFC 5701 [RFC5701] defines the IPv6 Address Specific Extended 152 Community to be a 20-octet quantity whose high order two octets may 153 be considered to be the "Type Field". The high order octet is either 154 0x00, indicating a transitive Extended Community, or 0x40, indicating 155 a Non-transitive Extended Community. The second octet is said to be 156 a "Sub-Type" and it is suggested that the Sub-Types are the same as 157 the Sub-Types for the IPv4-Address-Specific Extended Community. 158 However, the existing IANA codepoint allocations for this octet do 159 not always match the corresponding allocations for the IPv4-Address- 160 Specific Extended Community Sub-Types. 162 This document modifies RFC 5701 by removing any requirement for the 163 values of the second octet of the IPv6-Address-Specific Extended 164 Community Type codepoints to match the codepoints in the 165 IPv4-Address-Specific Sub-Types registry. 167 This document requests IANA to create two IPv6-Address-Specific 168 Extended Community registries, one for transitive communities and one 169 for non-transitive communities. See section 5.3. 171 4. How to Request EC Type and/or Sub-Type Codepoints 173 When a codepoint is needed for a new Extended Community, the 174 requester should first determine whether an existing Type can be 175 used. If so, IANA should be asked to allocate a codepoint from the 176 corresponding Sub-Type registry, if there is one. 178 If a new Extended Community Type is needed, the requester should ask 179 IANA to allocate a new type from either the "Transitive Extended 180 Community Types" registry, the "Non-transitive Extended Community 181 Types" registry, or both. It is up to the requester to state whether 182 an allocation is needed from one or both of these registries. When 183 an allocation from both registries is requested, the requester may 184 find it desirable for both allocations to share the same low-order 185 six bits. If so, it is the responsibility of the requester to 186 explicitly request this of IANA. 188 Of course, any request for a codepoint from a particular registry 189 must follow the defined registration procedures for that registry. 191 If a new Extended Community Type is needed, and the new Type is to 192 have Sub-Types, the requester should specify whether an existing Sub- 193 Type registry can be used for the new Type, or whether a new Sub-Type 194 registry is needed. (At the current time, every Type that has Sub- 195 Types is associated with a unique Sub-Type registry. It is possible 196 that in the future a new Type registry may be created that is 197 associated with a pre-existing Sub-Type registry.) In either case, 198 if a new Sub-Type value needs to be allocated from a particular Sub- 199 Type registry, the request should explicitly identify the registry. 201 If the creation of a new Sub-Type registry is requested, the range of 202 values is always 0x00-0xFF. It is recommended that the allocation 203 policy described in section 2 be used. I.e., 0x00-0xBF to be 204 allocated by IANA under the "First Come, First Served" policy, and 205 0xC0-0xFF to be allocated by IANA under the "IETF Review" policy. 207 Commonly, a new Extended Community is defined such that it can be of 208 several Types. E.g., one may want to define a new Extended Community 209 so that it can be either transitive or non-transitive, so that it can 210 be either of the Two-octet AS Number Type or the Four-octet AS Number 211 Type, etc. The requester is responsible for explicitly asking IANA 212 to allocate codepoints in all the necessary Type and/or Sub-Type 213 registries. 215 When a new Extended Community is defined, it may be necessary to ask 216 IANA to allocate codepoints in several Sub-Type registries. In this 217 case, it is a common practice to ask IANA to allocate the same 218 codepoint value in each registry. If this is desired, it is the 219 responsibility of the requester to explicitly ask IANA to allocate 220 the same value in each registry. 222 When a new Extended Community Sub-Type codepoint is allocated, it may 223 also be desirable to allocate a corresponding value in one or both of 224 the IPv6-Address-Specific Extended Community registries. The 225 requester is responsible for requesting this allocation explicitly. 226 If the requester would like the same numerical value to be allocated 227 in an IPv6-Address-Specific Extended Community registry that is 228 allocated in some other registry, it is the responsibility of the 229 requester to explicitly ask this of IANA. 231 5. IANA Considerations 233 IANA is to replace the pre-existing BGP Extended Communities 234 registries with the registries described in this section. 236 Any Extended Community Type or Sub-type codepoints allocated by IANA 237 between the date of this document that the date at which the 238 registries are reorganized must also be incorporated into the new 239 registry organization. The authors will work with IANA to ensure 240 that this is done correctly. 242 The registries reproduced below do not include the "references" or 243 "date" fields of the registries, because it is difficult to 244 incorporate those within the 72-character line limitation of RFCs. 245 The references and associated dates must be copied from the current 246 registries when the new registries are introduced; the authors will 247 work with IANA to ensure this this information is carried over 248 correctly to the new registry organization. 250 5.1. Registries for the TYPE Field 252 5.1.1. Transitive Types 254 This registry contains values of the high-order octet (the "Type 255 Field") of a Transitive Extended Community. 257 Registry Name: BGP TRANSITIVE EXTENDED COMMUNITY TYPES 259 RANGE REGISTRATION PROCEDURES 261 0x00-0x3F First Come, First Served 262 0x80-0x8F Experimental Use (see RFC 3692) 263 0x90-0xBF Standards Action (early allocation per RFC 4020) 265 TYPE VALUE NAME 267 0x00 Transitive Two-Octet AS-specific Extended 268 Community (Sub-Types are defined in the 269 "Transitive Two-Octet AS-specific Extended 270 Community Sub-Types" Registry) 272 0x01 Transitive IPv4-Address-specific Extended 273 Community (Sub-Types are defined in the 274 "Transitive IPv4-Address-specific Extended 275 Community Sub-Types" Registry) 277 0x02 Transitive Four-Octet AS-specific Extended 278 Community (Sub-Types are defined in the 279 "Transitive Four-Octet AS-specific Extended 280 Community Sub-Types" Registry) 282 0x03 Transitive Opaque Extended Community 283 (Sub-Types are defined in the "Transitive 284 Opaque Extended Community Sub-Types" 285 Registry) 287 0x04 QoS Marking 289 0x05 CoS Capability 291 0x06 EVPN (Sub-Types are defined in the "EVPN 292 Extended Community Sub-types" Registry) 294 0x08 Flow spec redirect/mirror to IP next-hop 296 0x80 Generic Transitive Experimental Extended 297 Community (Sub-Types are defined in the 298 "Generic Transitive Experimental Extended 299 Community Sub-Types" Registry) 301 5.1.2. Non-Transitive Types 303 This registry contains values of the high-order octet (the "Type 304 Field") of a Non-transitive Extended Community. 306 Registry Name: BGP NON-TRANSITIVE EXTENDED COMMUNITY TYPES 308 RANGE REGISTRATION PROCEDURES 310 0x40-0x7F First Come, First Served 311 0xC0-0xCF Experimental Use (see RFC 3692) 312 0xD0-0xFF Standards Action (early allocation per RFC 4020) 314 TYPE VALUE NAME 316 0x40 Non-Transitive Two-Octet AS-specific Extended 317 Community (Sub-Types are defined in the 318 "Non-Transitive Two-Octet AS-specific Extended 319 Community Sub-Types" Registry) 321 0x41 Non-Transitive IPv4-Address-specific Extended 322 Community (Sub-Types are defined in the 323 "Non-transitive IPv4-Address-specific Extended 324 Community Sub-Types" Registry) 326 0x42 Non-Transitive Four-Octet AS-specific Extended 327 (Sub-Types are defined in the "Non-Transitive 328 Four-Octet AS-specific Extended Community 329 Sub-Types" Registry) 331 0x43 Non-Transitive Opaque Extended Community 332 (Sub-Types are defined in the "Non-Transitive 333 Opaque Extended Community Sub-Types" Registry) 335 0x44 QoS Marking 337 5.2. Registries for the Sub-Type Field 339 5.2.1. EVPN Sub-Types 341 This registry contains values of the second octet (the "Sub-Type 342 field") of an extended community, when the value of the first octet 343 (the "Type field") is 0x06. 345 Registry Name: EVPN EXTENDED COMMUNITY SUB-TYPES 347 RANGE REGISTRATION PROCEDURE 349 0x00-0xBF First Come, First Served 350 0xC0-0xFF IETF Review 352 SUB-TYPE VALUE NAME 354 0x00 MAC Mobility 355 0x01 ESI MPLS Label 356 0x02 ES Import 358 5.2.2. Transitive Two-Octet AS-Specific Sub-Types 360 This registry contains values of the second octet (the "Sub-Type 361 field") of an extended community, when the value of the first octet 362 (the "Type field") is 0x00. 364 Registry Name: TRANSITIVE TWO-OCTET AS-SPECIFIC 365 EXTENDED COMMUNITY SUB-TYPES 367 RANGE REGISTRATION PROCEDURE 369 0x00-0xBF First Come, First Served 370 0xC0-0xFF IETF Review 372 SUB-TYPE VALUE NAME 374 0x02 Route Target 375 0x03 Route Origin 376 0x05 OSPF Domain Identifier 377 0x08 BGP Data Collection 378 0x09 Source AS 379 0x0A L2VPN Identifier 380 0x10 Cisco VPN-Distinguisher 382 5.2.3. Non-Transitive Two-Octet AS-Specific Sub-Types 384 This registry contains values of the second octet (the "Sub-Type 385 field") of an extended community, when the value of the first octet 386 (the "Type field") is 0x40. 388 Registry Name: NON-TRANSITIVE TWO-OCTET AS-SPECIFIC 389 EXTENDED COMMUNITY SUB-TYPES 391 RANGE REGISTRATION PROCEDURE 393 0x00-0xBF First Come, First Served 394 0xC0-0xFF IETF Review 396 SUB-TYPE VALUE NAME 398 0x04 Link Bandwidth Extended Community 400 5.2.4. Transitive Four-Octet AS-Specific Sub-Types 402 This registry contains values of the second octet (the "Sub-Type 403 field") of an extended community, when the value of the first octet 404 (the "Type field") is 0x02. 406 Registry Name: TRANSITIVE FOUR-OCTET AS-SPECIFIC EXTENDED 407 COMMUNITY SUB-TYPES 409 RANGE REGISTRATION PROCEDURE 411 0x00-0xBF First Come, First Served 412 0xC0-0xFF IETF Review 414 SUB-TYPE VALUE NAME 416 0x02 Route Target 417 0x03 Route Origin 418 0x04 Generic 419 0x05 OSPF Domain Identifier 420 0x08 BGP Data Collection 421 0x09 Source AS 422 0x10 Cisco VPN Identifier 424 5.2.5. Non-Transitive Four-Octet AS-Specific Sub-Types 426 This registry contains values of the second octet (the "Sub-Type 427 field") of an extended community, when the value of the first octet 428 (the "Type field") is 0x42. 430 Registry Name: NON-TRANSITIVE FOUR-OCTET AS-SPECIFIC 431 EXTENDED COMMUNITY SUB-TYPES 433 RANGE REGISTRATION PROCEDURE 435 0x00-0xBF First Come, First Served 436 0xC0-0xFF IETF Review 438 SUB-TYPE VALUE NAME 440 0x04 Generic 442 5.2.6. Transitive IPv4-Address-Specific Sub-Types 444 This registry contains values of the second octet (the "Sub-Type 445 field") of an extended community, when the value of the first octet 446 (the "Type field") is 0x01. 448 Registry Name: TRANSITIVE IPV4-ADDRESS-SPECIFIC 449 EXTENDED COMMUNITY SUB-TYPES 451 RANGE REGISTRATION PROCEDURE 453 0x00-0xBF First Come, First Served 454 0xC0-0xFF IETF Review 456 SUB-TYPE VALUE NAME 458 0x02 Route Target 459 0x03 Route Origin 460 0x05 OSPF Domain Identifier 461 0x07 OSPF Route ID 462 0x0A L2VPN Identifier 463 0x0B VRF Route Import 464 0x10 Cisco VPN-Distinguisher 466 5.2.7. Non-Transitive IPv4-Address-Specific Sub-Types 468 This registry contains values of the second octet (the "Sub-Type 469 field") of an extended community, when the value of the first octet 470 (the "Type field") is 0x41. 472 Registry Name: NON-TRANSITIVE IPV4-ADDRESS-SPECIFIC 473 EXTENDED COMMUNITY SUB-TYPES 475 RANGE REGISTRATION PROCEDURE 477 0x00-0xBF First Come, First Served 478 0xC0-0xFF IETF Review 480 None Assigned 482 5.2.8. Transitive Opaque Extended Community Sub-Types 484 This registry contains values of the second octet (the "Sub-Type 485 field") of an extended community, when the value of the first octet 486 (the "Type field") is 0x03. 488 Registry Name: TRANSITIVE OPAQUE 489 EXTENDED COMMUNITY SUB-TYPES 491 RANGE REGISTRATION PROCEDURE 493 0x00-0xBF First Come, First Served 494 0xC0-0xFF IETF Review 496 SUB-TYPE VALUE NAME 498 0x06 OSPF Route Type 499 0x0B Color Extended Community 500 0x0C Encapsulation Extended Community 501 0x0D Default Gateway 503 5.2.9. Non-Transitive Opaque Extended Community Sub-Types 505 This registry contains values of the second octet (the "Sub-Type 506 field") of an extended community, when the value of the first octet 507 (the "Type field") is 0x43. 509 Registry Name: NON-TRANSITIVE OPAQUE 510 EXTENDED COMMUNITY SUB-TYPES 512 RANGE REGISTRATION PROCEDURE 514 0x00-0xBF First Come, First Served 515 0xC0-0xFF IETF Review 517 SUB-TYPE VALUE NAME 519 0x00 BGP Origin Validation State 521 5.2.10. Generic Transitive Experimental Use Sub-Types 523 Registry Name: BGP GENERIC TRANSITIVE EXPERIMENTAL USE 524 EXTENDED COMMUNITY SUB-TYPES 526 RANGE REGISTRATION PROCEDURE 528 0x00-0xBF First Come, First Served 529 0xC0-0xFF IETF Review 531 SUB-TYPE VALUE NAME 533 0x06 Flow spec traffic-rate 534 0x07 Flow spec traffic-action (Use of the Value Field 535 is defined in the "Traffic Actions Field" 536 registry) 537 0x08 Flow spec redirect 538 0x09 Flow spec traffic-remarking 539 0x0A Layer2 Info Extended Community 541 Note: RFC 5575 contains narrative text that declares the "Flow spec 542 traffic-rate" to be non-transitive, but then assigns it a codepoint that 543 indicates it to be transitive. Addressing this error in RFC 5575 is not 544 within the scope of the current document. 546 5.2.11. Registries for the Value Field 548 At the time of writing of this document, there is only one registry 549 containing codepoints for the Value Field of an Extended Community. 551 5.2.11.1. Traffic Action Field 553 This registry does not need to be modified. 555 5.3. Registries for IPv6-Address-Specific ECs 557 5.3.1. Transitive Types 559 This registry contains values of the two high-order octets of an 560 IPv6-Address-Specific Extended Communities attribute. 562 Registry Name: TRANSITIVE IPV6 ADDRESS SPECIFIC 563 EXTENDED COMMUNITY TYPES 565 RANGE REGISTRATION PROCEDURE 567 0x0000-0x00FF First Come, First Served 569 TYPE VALUE NAME 571 0x0002 Route Target 572 0x0003 Route Origin 573 0x0004 OSPFv3 Route Attributes (deprecated) 574 0x000B VRF Route Import 575 0x0010 Cisco VPN-Distinguisher 576 0x0011 UUID-based Route Target 578 5.3.2. Non-Transitive Types 580 This registry contains values of the two high-order octets of an 581 IPv6-Address-Specific Extended Communities attribute. 583 Registry Name: NON-TRANSITIVE IPV6 ADDRESS SPECIFIC 584 EXTENDED COMMUNITY TYPES 586 RANGE REGISTRATION PROCEDURE 588 0x4000-0x40FF First Come, First Served 590 None assigned 592 6. Security Considerations 594 No security considerations are raised by this document. 596 7. Acknowledgments 598 The authors wish to thank Jon Mitchell and Hyojeong Kim for their 599 comments. 601 The authors wish to thank Amanda Baber of IANA for educating us on 602 some of the problems faced by IANA staff when responding to requests 603 for BGP Extended Community Type and Sub-Type codepoint allocations. 605 8. Authors' Addresses 607 Yakov Rekhter 608 Juniper Networks 609 1194 North Mathilda Ave. 610 Sunnyvale, CA 94089 611 Email: yakov@juniper.net 613 Eric C. Rosen 614 Cisco Systems, Inc. 615 1414 Massachusetts Avenue 616 Boxborough, MA, 01719 617 Email: erosen@cisco.com 619 9. Normative References 621 [RFC3692] "Assigning Experimental and Testing Numbers Considered 622 Useful", Narten, RFC 3692, January 2004 624 [RFC4020] "Early IANA Allocation of Standards Track Code Points", 625 Kompella, Zinin, RFC 4020, February 2005 627 [RFC4360] "BGP Extended Communities Attribute", Sangli, Tappan, 628 Rekhter, RFC 4360, February 2006 630 [RFC5226] "Guidelines for Writing an IANA Considerations Section in 631 RFCs", Narten, Alvestrand, RFC 5226, May 2008 633 [RFC5701] "IPv6 Address Specific BGP Extended Community Attribute", 634 Rekhter, RFC 5701, November 2009