idnits 2.17.1 draft-ietf-idr-extcomm-iana-02.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 (December 4, 2013) is 3789 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: June 4, 2014 Juniper Networks, Inc. 8 December 4, 2013 10 IANA Registries for BGP Extended Communities 12 draft-ietf-idr-extcomm-iana-02.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 RFC 4360 and RFC 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 ........ 14 83 5.2.8 Transitive Opaque Extended Community Sub-Types ........ 14 84 5.2.9 Non-Transitive Opaque Extended Community Sub-Types .... 15 85 5.2.10 Generic Transitive Experimental Use Sub-Types ......... 15 86 5.2.11 Registries for the Value Field ........................ 16 87 5.2.11.1 Traffic Action Field .................................. 16 88 5.3 Registries for IPv6-Address-Specific ECs .............. 16 89 5.3.1 Transitive Types ...................................... 16 90 5.3.2 Non-Transitive Types .................................. 17 91 6 Security Considerations ............................... 17 92 7 Acknowledgments ....................................... 17 93 8 Authors' Addresses .................................... 17 94 9 Normative References .................................. 18 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 and 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 for the individual codepoints in the registries, 244 because it is difficult to incorporate those within the 72-character 245 line limitation of RFCs. The references and associated dates must be 246 copied from the current registries when the new registries are 247 introduced; the authors will work with IANA to ensure that this 248 information is carried over correctly to the new registry 249 organization. As this document does not change the usage or 250 semantics of any of the codepoints, the references associated with 251 the individual codepoints do not change. 253 On the other hand, the reference for each of the registries defined 254 in this section should be changed to this document. 256 5.1. Registries for the TYPE Field 258 5.1.1. Transitive Types 260 This registry shall contain the following note: 262 This registry contains values of the high-order octet (the "Type 263 Field") of a Transitive Extended Community. 265 Registry Name: BGP TRANSITIVE EXTENDED COMMUNITY TYPES 267 RANGE REGISTRATION PROCEDURES 269 0x00-0x3F First Come, First Served 270 0x80-0x8F Experimental Use (see RFC 3692) 271 0x90-0xBF Standards Action (early allocation per RFC 4020) 273 TYPE VALUE NAME 275 0x00 Transitive Two-Octet AS-specific Extended 276 Community (Sub-Types are defined in the 277 "Transitive Two-Octet AS-specific Extended 278 Community Sub-Types" Registry) 280 0x01 Transitive IPv4-Address-specific Extended 281 Community (Sub-Types are defined in the 282 "Transitive IPv4-Address-specific Extended 283 Community Sub-Types" Registry) 285 0x02 Transitive Four-Octet AS-specific Extended 286 Community (Sub-Types are defined in the 287 "Transitive Four-Octet AS-specific Extended 288 Community Sub-Types" Registry) 290 0x03 Transitive Opaque Extended Community 291 (Sub-Types are defined in the "Transitive 292 Opaque Extended Community Sub-Types" 293 Registry) 295 0x04 QoS Marking 297 0x05 CoS Capability 299 0x06 EVPN (Sub-Types are defined in the "EVPN 300 Extended Community Sub-types" Registry) 302 0x08 Flow spec redirect/mirror to IP next-hop 304 0x80 Generic Transitive Experimental Extended 305 Community (Sub-Types are defined in the 306 "Generic Transitive Experimental Extended 307 Community Sub-Types" Registry) 309 5.1.2. Non-Transitive Types 311 This registry shall contain the following note: 313 This registry contains values of the high-order octet (the "Type 314 Field") of a Non-transitive Extended Community. 316 Registry Name: BGP NON-TRANSITIVE EXTENDED COMMUNITY TYPES 318 RANGE REGISTRATION PROCEDURES 320 0x40-0x7F First Come, First Served 321 0xC0-0xCF Experimental Use (see RFC 3692) 322 0xD0-0xFF Standards Action (early allocation per RFC 4020) 324 TYPE VALUE NAME 326 0x40 Non-Transitive Two-Octet AS-specific Extended 327 Community (Sub-Types are defined in the 328 "Non-Transitive Two-Octet AS-specific Extended 329 Community Sub-Types" Registry) 331 0x41 Non-Transitive IPv4-Address-specific Extended 332 Community (Sub-Types are defined in the 333 "Non-transitive IPv4-Address-specific Extended 334 Community Sub-Types" Registry) 336 0x42 Non-Transitive Four-Octet AS-specific Extended 337 (Sub-Types are defined in the "Non-Transitive 338 Four-Octet AS-specific Extended Community 339 Sub-Types" Registry) 341 0x43 Non-Transitive Opaque Extended Community 342 (Sub-Types are defined in the "Non-Transitive 343 Opaque Extended Community Sub-Types" Registry) 345 0x44 QoS Marking 347 5.2. Registries for the Sub-Type Field 349 5.2.1. EVPN Sub-Types 351 This registry shall contain the following note: 353 This registry contains values of the second octet (the "Sub-Type 354 field") of an extended community, when the value of the first 355 octet (the "Type field") is 0x06. 357 Registry Name: EVPN EXTENDED COMMUNITY SUB-TYPES 359 RANGE REGISTRATION PROCEDURE 361 0x00-0xBF First Come, First Served 362 0xC0-0xFF IETF Review 364 SUB-TYPE VALUE NAME 366 0x00 MAC Mobility 367 0x01 ESI MPLS Label 368 0x02 ES Import 370 5.2.2. Transitive Two-Octet AS-Specific Sub-Types 372 This registry shall contain the following note: 374 This registry contains values of the second octet (the "Sub-Type 375 field") of an extended community, when the value of the first 376 octet (the "Type field") is 0x00. 378 Registry Name: TRANSITIVE TWO-OCTET AS-SPECIFIC 379 EXTENDED COMMUNITY SUB-TYPES 381 RANGE REGISTRATION PROCEDURE 383 0x00-0xBF First Come, First Served 384 0xC0-0xFF IETF Review 386 SUB-TYPE VALUE NAME 388 0x02 Route Target 389 0x03 Route Origin 390 0x05 OSPF Domain Identifier 391 0x08 BGP Data Collection 392 0x09 Source AS 393 0x0A L2VPN Identifier 394 0x10 Cisco VPN-Distinguisher 396 5.2.3. Non-Transitive Two-Octet AS-Specific Sub-Types 398 This registry shall contain the following note: 400 This registry contains values of the second octet (the "Sub-Type 401 field") of an extended community, when the value of the first 402 octet (the "Type field") is 0x40. 404 Registry Name: NON-TRANSITIVE TWO-OCTET AS-SPECIFIC 405 EXTENDED COMMUNITY SUB-TYPES 407 RANGE REGISTRATION PROCEDURE 409 0x00-0xBF First Come, First Served 410 0xC0-0xFF IETF Review 412 SUB-TYPE VALUE NAME 414 0x04 Link Bandwidth Extended Community 416 5.2.4. Transitive Four-Octet AS-Specific Sub-Types 418 This registry shall contain the following note: 420 This registry contains values of the second octet (the "Sub-Type 421 field") of an extended community, when the value of the first 422 octet (the "Type field") is 0x02. 424 Registry Name: TRANSITIVE FOUR-OCTET AS-SPECIFIC EXTENDED 425 COMMUNITY SUB-TYPES 427 RANGE REGISTRATION PROCEDURE 429 0x00-0xBF First Come, First Served 430 0xC0-0xFF IETF Review 432 SUB-TYPE VALUE NAME 434 0x02 Route Target 435 0x03 Route Origin 436 0x04 Generic 437 0x05 OSPF Domain Identifier 438 0x08 BGP Data Collection 439 0x09 Source AS 440 0x10 Cisco VPN Identifier 442 5.2.5. Non-Transitive Four-Octet AS-Specific Sub-Types 444 This registry shall contain the following note: 446 This registry contains values of the second octet (the "Sub-Type 447 field") of an extended community, when the value of the first 448 octet (the "Type field") is 0x42. 450 Registry Name: NON-TRANSITIVE FOUR-OCTET AS-SPECIFIC 451 EXTENDED COMMUNITY SUB-TYPES 453 RANGE REGISTRATION PROCEDURE 455 0x00-0xBF First Come, First Served 456 0xC0-0xFF IETF Review 458 SUB-TYPE VALUE NAME 460 0x04 Generic 462 5.2.6. Transitive IPv4-Address-Specific Sub-Types 464 This registry shall contain the following note: 466 This registry contains values of the second octet (the "Sub-Type 467 field") of an extended community, when the value of the first 468 octet (the "Type field") is 0x01. 470 Registry Name: TRANSITIVE IPV4-ADDRESS-SPECIFIC 471 EXTENDED COMMUNITY SUB-TYPES 473 RANGE REGISTRATION PROCEDURE 475 0x00-0xBF First Come, First Served 476 0xC0-0xFF IETF Review 478 SUB-TYPE VALUE NAME 480 0x02 Route Target 481 0x03 Route Origin 482 0x05 OSPF Domain Identifier 483 0x07 OSPF Route ID 484 0x0A L2VPN Identifier 485 0x0B VRF Route Import 486 0x10 Cisco VPN-Distinguisher 488 5.2.7. Non-Transitive IPv4-Address-Specific Sub-Types 490 This registry shall contain the following note: 492 This registry contains values of the second octet (the "Sub-Type 493 field") of an extended community, when the value of the first 494 octet (the "Type field") is 0x41. 496 Registry Name: NON-TRANSITIVE IPV4-ADDRESS-SPECIFIC 497 EXTENDED COMMUNITY SUB-TYPES 499 RANGE REGISTRATION PROCEDURE 501 0x00-0xBF First Come, First Served 502 0xC0-0xFF IETF Review 504 None Assigned 506 5.2.8. Transitive Opaque Extended Community Sub-Types 508 This registry shall contain the following note: 510 This registry contains values of the second octet (the "Sub-Type 511 field") of an extended community, when the value of the first 512 octet (the "Type field") is 0x03. 514 Registry Name: TRANSITIVE OPAQUE 515 EXTENDED COMMUNITY SUB-TYPES 517 RANGE REGISTRATION PROCEDURE 519 0x00-0xBF First Come, First Served 520 0xC0-0xFF IETF Review 522 SUB-TYPE VALUE NAME 524 0x06 OSPF Route Type 525 0x0B Color Extended Community 526 0x0C Encapsulation Extended Community 527 0x0D Default Gateway 529 5.2.9. Non-Transitive Opaque Extended Community Sub-Types 531 This registry shall contain the following note: 533 This registry contains values of the second octet (the "Sub-Type 534 field") of an extended community, when the value of the first 535 octet (the "Type field") is 0x43. 537 Registry Name: NON-TRANSITIVE OPAQUE 538 EXTENDED COMMUNITY SUB-TYPES 540 RANGE REGISTRATION PROCEDURE 542 0x00-0xBF First Come, First Served 543 0xC0-0xFF IETF Review 545 SUB-TYPE VALUE NAME 547 0x00 BGP Origin Validation State 549 5.2.10. Generic Transitive Experimental Use Sub-Types 551 Registry Name: BGP GENERIC TRANSITIVE EXPERIMENTAL USE 552 EXTENDED COMMUNITY SUB-TYPES 554 RANGE REGISTRATION PROCEDURE 556 0x00-0xBF First Come, First Served 557 0xC0-0xFF IETF Review 559 SUB-TYPE VALUE NAME 561 0x06 Flow spec traffic-rate 562 0x07 Flow spec traffic-action (Use of the Value Field 563 is defined in the "Traffic Action Field" 564 registry) 565 0x08 Flow spec redirect 566 0x09 Flow spec traffic-remarking 567 0x0A Layer2 Info Extended Community 569 Note: RFC 5575 contains narrative text that declares the "Flow spec 570 traffic-rate" to be non-transitive, but then assigns it a codepoint that 571 indicates it to be transitive. Addressing this error in RFC 5575 is not 572 within the scope of the current document. 574 5.2.11. Registries for the Value Field 576 At the time of writing of this document, there is only one registry 577 containing codepoints for the Value Field of an Extended Community. 579 5.2.11.1. Traffic Action Field 581 This registry does not need to be modified. 583 5.3. Registries for IPv6-Address-Specific ECs 585 5.3.1. Transitive Types 587 This registry shall contain the following note: 589 This registry contains values of the two high-order octets of an 590 IPv6-Address-Specific Extended Communities attribute. 592 Registry Name: TRANSITIVE IPV6 ADDRESS SPECIFIC 593 EXTENDED COMMUNITY TYPES 595 RANGE REGISTRATION PROCEDURE 597 0x0000-0x00FF First Come, First Served 599 TYPE VALUE NAME 601 0x0002 Route Target 602 0x0003 Route Origin 603 0x0004 OSPFv3 Route Attributes (deprecated) 604 0x000B VRF Route Import 605 0x0010 Cisco VPN-Distinguisher 606 0x0011 UUID-based Route Target 608 5.3.2. Non-Transitive Types 610 This registry shall contain the following note: 612 This registry contains values of the two high-order octets of an 613 IPv6-Address-Specific Extended Communities attribute. 615 Registry Name: NON-TRANSITIVE IPV6 ADDRESS SPECIFIC 616 EXTENDED COMMUNITY TYPES 618 RANGE REGISTRATION PROCEDURE 620 0x4000-0x40FF First Come, First Served 622 None assigned 624 6. Security Considerations 626 No security considerations are raised by this document. 628 7. Acknowledgments 630 The authors wish to thank Jon Mitchell, Hyojeong Kim, and Pearl Liang 631 for their review and comments. 633 The authors wish to thank Amanda Baber of IANA for educating us on 634 some of the problems faced by IANA staff when responding to requests 635 for BGP Extended Community Type and Sub-Type codepoint allocations. 637 8. Authors' Addresses 639 Yakov Rekhter 640 Juniper Networks 641 1194 North Mathilda Ave. 642 Sunnyvale, CA 94089 643 Email: yakov@juniper.net 644 Eric C. Rosen 645 Cisco Systems, Inc. 646 1414 Massachusetts Avenue 647 Boxborough, MA, 01719 648 Email: erosen@cisco.com 650 9. Normative References 652 [RFC3692] "Assigning Experimental and Testing Numbers Considered 653 Useful", Narten, RFC 3692, January 2004 655 [RFC4020] "Early IANA Allocation of Standards Track Code Points", 656 Kompella, Zinin, RFC 4020, February 2005 658 [RFC4360] "BGP Extended Communities Attribute", Sangli, Tappan, 659 Rekhter, RFC 4360, February 2006 661 [RFC5226] "Guidelines for Writing an IANA Considerations Section in 662 RFCs", Narten, Alvestrand, RFC 5226, May 2008 664 [RFC5701] "IPv6 Address Specific BGP Extended Community Attribute", 665 Rekhter, RFC 5701, November 2009