IDR Working Group Eric C. Rosen Internet Draft Cisco Systems, Inc. Intended Status: Standards Track Updates: 4360,5701 Yakov Rekhter Expires: March 30, 2014 Juniper Networks, Inc. September 30, 2013 IANA Registries for BGP Extended Communities draft-ietf-idr-extcomm-iana-01.txt Abstract This document reorganizes the IANA Registries for the type values and sub-type values of BGP Extended Communities attribute and the BGP IPv6-Address-Specific Extended Communities attribute. This is done in order to remove inter-dependencies among the registries, thus making it easier for IANA to determine which codepoints are available for assignment in which registries. This document also clarifies the information that must be provided to IANA when requesting an allocation from one or more of these registries. These changes are compatible with the existing allocations, and thus do not affect protocol implementations. The changes will however impact the "IANA Considerations" sections of future protocol specifications. This document updates RFCs 4360 and 5701. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. Rosen & Rekhter [Page 1] Internet Draft draft-ietf-idr-extcomm-iana-01.txt September 2013 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright and License Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Rosen & Rekhter [Page 2] Internet Draft draft-ietf-idr-extcomm-iana-01.txt September 2013 Table of Contents 1 Introduction .......................................... 4 2 Types, Sub-Types, and Registries ...................... 4 3 Applicability to IPv6 Address Specific EC Attribute ... 5 4 How to Request EC Type and/or Sub-Type Codepoints ..... 5 5 IANA Considerations ................................... 7 5.1 Registries for the TYPE Field ......................... 7 5.1.1 Transitive Types ...................................... 7 5.1.2 Non-Transitive Types .................................. 9 5.2 Registries for the Sub-Type Field ..................... 10 5.2.1 EVPN Sub-Types ........................................ 10 5.2.2 Transitive Two-Octet AS-Specific Sub-Types ............ 10 5.2.3 Non-Transitive Two-Octet AS-Specific Sub-Types ........ 11 5.2.4 Transitive Four-Octet AS-Specific Sub-Types ........... 12 5.2.5 Non-Transitive Four-Octet AS-Specific Sub-Types ....... 12 5.2.6 Transitive IPv4-Address-Specific Sub-Types ............ 13 5.2.7 Non-Transitive IPv4-Address-Specific Sub-Types ........ 13 5.2.8 Transitive Opaque Extended Community Sub-Types ........ 14 5.2.9 Non-Transitive Opaque Extended Community Sub-Types .... 14 5.2.10 Generic Transitive Experimental Use Sub-Types ......... 15 5.2.11 Registries for the Value Field ........................ 15 5.2.11.1 Traffic Action Field .................................. 15 5.3 Registries for IPv6-Address-Specific ECs .............. 15 5.3.1 Transitive Types ...................................... 15 5.3.2 Non-Transitive Types .................................. 16 6 Security Considerations ............................... 16 7 Acknowledgments ....................................... 17 8 Authors' Addresses .................................... 17 9 Normative References .................................. 17 Rosen & Rekhter [Page 3] Internet Draft draft-ietf-idr-extcomm-iana-01.txt September 2013 1. Introduction RFC 4360 [RFC4360] defines the BGP "Extended Communities" (EC) attribute. This attribute consists of a sequence of eight-octet "extended communities". The high-order octet is defined to be the "Type" field. Each Type has a range of values for "Transitive Extended Community Types" and a range of values for "Non-transitive Extended Community Types". Some of these ranges are further sub- divided into a sub-range of values to be assigned by IANA under the "Standards Action (with Early Allocation)" policy a sub-range of values to be assigned by IANA under the "First Come First Served" policy, and a sub-range for "experimental use". (See [RFC5226], [RFC4020], and [RFC3692] for an explanation of these policies.) For some Extended Community Types, the second octet of the Extended Community is a "Sub-Type" field, and the remaining six octets are the "Value" field. These are referred to as "Extended Types". For other types, there is no Sub-Type field, and the Value field contains seven octets. These are referred to as "Regular Types". RFC 4360 is not very specific about how the IANA registries for Extended Community Types and/or Sub-Types are to be organized, and this has led to some confusion. The purpose of this document is to reorganize the registries to make the IANA codepoint allocation task more straightforward. 2. Types, Sub-Types, and Registries The high-order octet of an Extended Community will be known as the "Type Field". There will be one IANA registry for "Transitive Extended Community Types" (see section 5.1.1), and one for "Non-transitive Extended Community Types" (section 5.1.2). Each registry specifies three ranges, and each range is associated with a particular IANA allocation policy. There will be a set of IANA registries for Extended Community Sub- Types (see section 5.2). Each such registry will have a range of 0x00-0xFF. Values in the range 0x00-0xBF are assignable by IANA according to the "First Come, First Served" allocation policy of [RFC5226]. Values in the range 0xC0-0xFF are assignable by IANA according to the "IETF Review" allocation policy of [RFC5226]. If a particular Type has Sub-Types, that Type's entry in its Type registry identifies its Sub-Type registry. Note that some Types do not have Sub-Types. When the request is made to establish a new Type Rosen & Rekhter [Page 4] Internet Draft draft-ietf-idr-extcomm-iana-01.txt September 2013 registry, the request must specify whether or not there is to be a Sub-Type registry associated with that Type. Whether a given Type has Sub-Types is determined when the Type is initially defined; this cannot be changed later. 3. Applicability to IPv6 Address Specific EC Attribute RFC 5701 [RFC5701] defines the IPv6 Address Specific Extended Community to be a 20-octet quantity whose high order two octets may be considered to be the "Type Field". The high order octet is either 0x00, indicating a transitive Extended Community, or 0x40, indicating a Non-transitive Extended Community. The second octet is said to be a "Sub-Type" and it is suggested that the Sub-Types are the same as the Sub-Types for the IPv4-Address-Specific Extended Community. However, the existing IANA codepoint allocations for this octet do not always match the corresponding allocations for the IPv4-Address- Specific Extended Community Sub-Types. This document modifies RFC 5701 by removing any requirement for the values of the second octet of the IPv6-Address-Specific Extended Community Type codepoints to match the codepoints in the IPv4-Address-Specific Sub-Types registry. This document requests IANA to create two IPv6-Address-Specific Extended Community registries, one for transitive communities and one for non-transitive communities. See section 5.3. 4. How to Request EC Type and/or Sub-Type Codepoints When a codepoint is needed for a new Extended Community, the requester should first determine whether an existing Type can be used. If so, IANA should be asked to allocate a codepoint from the corresponding Sub-Type registry, if there is one. If a new Extended Community Type is needed, the requester should ask IANA to allocate a new type from either the "Transitive Extended Community Types" registry, the "Non-transitive Extended Community Types" registry, or both. It is up to the requester to state whether an allocation is needed from one or both of these registries. When an allocation from both registries is requested, the requester may find it desirable for both allocations to share the same low-order six bits. If so, it is the responsibility of the requester to explicitly request this of IANA. Rosen & Rekhter [Page 5] Internet Draft draft-ietf-idr-extcomm-iana-01.txt September 2013 Of course, any request for a codepoint from a particular registry must follow the defined registration procedures for that registry. If a new Extended Community Type is needed, and the new Type is to have Sub-Types, the requester should specify whether an existing Sub- Type registry can be used for the new Type, or whether a new Sub-Type registry is needed. (At the current time, every Type that has Sub- Types is associated with a unique Sub-Type registry. It is possible that in the future a new Type registry may be created that is associated with a pre-existing Sub-Type registry.) In either case, if a new Sub-Type value needs to be allocated from a particular Sub- Type registry, the request should explicitly identify the registry. If the creation of a new Sub-Type registry is requested, the range of values is always 0x00-0xFF. It is recommended that the allocation policy described in section 2 be used. I.e., 0x00-0xBF to be allocated by IANA under the "First Come, First Served" policy, and 0xC0-0xFF to be allocated by IANA under the "IETF Review" policy. Commonly, a new Extended Community is defined such that it can be of several Types. E.g., one may want to define a new Extended Community so that it can be either transitive or non-transitive, so that it can be either of the Two-octet AS Number Type or the Four-octet AS Number Type, etc. The requester is responsible for explicitly asking IANA to allocate codepoints in all the necessary Type and/or Sub-Type registries. When a new Extended Community is defined, it may be necessary to ask IANA to allocate codepoints in several Sub-Type registries. In this case, it is a common practice to ask IANA to allocate the same codepoint value in each registry. If this is desired, it is the responsibility of the requester to explicitly ask IANA to allocate the same value in each registry. When a new Extended Community Sub-Type codepoint is allocated, it may also be desirable to allocate a corresponding value in one or both of the IPv6-Address-Specific Extended Community registries. The requester is responsible for requesting this allocation explicitly. If the requester would like the same numerical value to be allocated in an IPv6-Address-Specific Extended Community registry that is allocated in some other registry, it is the responsibility of the requester to explicitly ask this of IANA. Rosen & Rekhter [Page 6] Internet Draft draft-ietf-idr-extcomm-iana-01.txt September 2013 5. IANA Considerations IANA is to replace the pre-existing BGP Extended Communities registries with the registries described in this section. Any Extended Community Type or Sub-type codepoints allocated by IANA between the date of this document and the date at which the registries are reorganized must also be incorporated into the new registry organization. The authors will work with IANA to ensure that this is done correctly. The registries reproduced below do not include the "references" or "date" fields of the registries, because it is difficult to incorporate those within the 72-character line limitation of RFCs. The references and associated dates must be copied from the current registries when the new registries are introduced; the authors will work with IANA to ensure that this information is carried over correctly to the new registry organization. 5.1. Registries for the TYPE Field 5.1.1. Transitive Types This registry contains values of the high-order octet (the "Type Field") of a Transitive Extended Community. Rosen & Rekhter [Page 7] Internet Draft draft-ietf-idr-extcomm-iana-01.txt September 2013 Registry Name: BGP TRANSITIVE EXTENDED COMMUNITY TYPES RANGE REGISTRATION PROCEDURES 0x00-0x3F First Come, First Served 0x80-0x8F Experimental Use (see RFC 3692) 0x90-0xBF Standards Action (early allocation per RFC 4020) TYPE VALUE NAME 0x00 Transitive Two-Octet AS-specific Extended Community (Sub-Types are defined in the "Transitive Two-Octet AS-specific Extended Community Sub-Types" Registry) 0x01 Transitive IPv4-Address-specific Extended Community (Sub-Types are defined in the "Transitive IPv4-Address-specific Extended Community Sub-Types" Registry) 0x02 Transitive Four-Octet AS-specific Extended Community (Sub-Types are defined in the "Transitive Four-Octet AS-specific Extended Community Sub-Types" Registry) 0x03 Transitive Opaque Extended Community (Sub-Types are defined in the "Transitive Opaque Extended Community Sub-Types" Registry) 0x04 QoS Marking 0x05 CoS Capability 0x06 EVPN (Sub-Types are defined in the "EVPN Extended Community Sub-types" Registry) 0x08 Flow spec redirect/mirror to IP next-hop 0x80 Generic Transitive Experimental Extended Community (Sub-Types are defined in the "Generic Transitive Experimental Extended Community Sub-Types" Registry) Rosen & Rekhter [Page 8] Internet Draft draft-ietf-idr-extcomm-iana-01.txt September 2013 5.1.2. Non-Transitive Types This registry contains values of the high-order octet (the "Type Field") of a Non-transitive Extended Community. Registry Name: BGP NON-TRANSITIVE EXTENDED COMMUNITY TYPES RANGE REGISTRATION PROCEDURES 0x40-0x7F First Come, First Served 0xC0-0xCF Experimental Use (see RFC 3692) 0xD0-0xFF Standards Action (early allocation per RFC 4020) TYPE VALUE NAME 0x40 Non-Transitive Two-Octet AS-specific Extended Community (Sub-Types are defined in the "Non-Transitive Two-Octet AS-specific Extended Community Sub-Types" Registry) 0x41 Non-Transitive IPv4-Address-specific Extended Community (Sub-Types are defined in the "Non-transitive IPv4-Address-specific Extended Community Sub-Types" Registry) 0x42 Non-Transitive Four-Octet AS-specific Extended (Sub-Types are defined in the "Non-Transitive Four-Octet AS-specific Extended Community Sub-Types" Registry) 0x43 Non-Transitive Opaque Extended Community (Sub-Types are defined in the "Non-Transitive Opaque Extended Community Sub-Types" Registry) 0x44 QoS Marking Rosen & Rekhter [Page 9] Internet Draft draft-ietf-idr-extcomm-iana-01.txt September 2013 5.2. Registries for the Sub-Type Field 5.2.1. EVPN Sub-Types This registry contains values of the second octet (the "Sub-Type field") of an extended community, when the value of the first octet (the "Type field") is 0x06. Registry Name: EVPN EXTENDED COMMUNITY SUB-TYPES RANGE REGISTRATION PROCEDURE 0x00-0xBF First Come, First Served 0xC0-0xFF IETF Review SUB-TYPE VALUE NAME 0x00 MAC Mobility 0x01 ESI MPLS Label 0x02 ES Import 5.2.2. Transitive Two-Octet AS-Specific Sub-Types This registry contains values of the second octet (the "Sub-Type field") of an extended community, when the value of the first octet (the "Type field") is 0x00. Rosen & Rekhter [Page 10] Internet Draft draft-ietf-idr-extcomm-iana-01.txt September 2013 Registry Name: TRANSITIVE TWO-OCTET AS-SPECIFIC EXTENDED COMMUNITY SUB-TYPES RANGE REGISTRATION PROCEDURE 0x00-0xBF First Come, First Served 0xC0-0xFF IETF Review SUB-TYPE VALUE NAME 0x02 Route Target 0x03 Route Origin 0x05 OSPF Domain Identifier 0x08 BGP Data Collection 0x09 Source AS 0x0A L2VPN Identifier 0x10 Cisco VPN-Distinguisher 5.2.3. Non-Transitive Two-Octet AS-Specific Sub-Types This registry contains values of the second octet (the "Sub-Type field") of an extended community, when the value of the first octet (the "Type field") is 0x40. Registry Name: NON-TRANSITIVE TWO-OCTET AS-SPECIFIC EXTENDED COMMUNITY SUB-TYPES RANGE REGISTRATION PROCEDURE 0x00-0xBF First Come, First Served 0xC0-0xFF IETF Review SUB-TYPE VALUE NAME 0x04 Link Bandwidth Extended Community Rosen & Rekhter [Page 11] Internet Draft draft-ietf-idr-extcomm-iana-01.txt September 2013 5.2.4. Transitive Four-Octet AS-Specific Sub-Types This registry contains values of the second octet (the "Sub-Type field") of an extended community, when the value of the first octet (the "Type field") is 0x02. Registry Name: TRANSITIVE FOUR-OCTET AS-SPECIFIC EXTENDED COMMUNITY SUB-TYPES RANGE REGISTRATION PROCEDURE 0x00-0xBF First Come, First Served 0xC0-0xFF IETF Review SUB-TYPE VALUE NAME 0x02 Route Target 0x03 Route Origin 0x04 Generic 0x05 OSPF Domain Identifier 0x08 BGP Data Collection 0x09 Source AS 0x10 Cisco VPN Identifier 5.2.5. Non-Transitive Four-Octet AS-Specific Sub-Types This registry contains values of the second octet (the "Sub-Type field") of an extended community, when the value of the first octet (the "Type field") is 0x42. Registry Name: NON-TRANSITIVE FOUR-OCTET AS-SPECIFIC EXTENDED COMMUNITY SUB-TYPES RANGE REGISTRATION PROCEDURE 0x00-0xBF First Come, First Served 0xC0-0xFF IETF Review SUB-TYPE VALUE NAME 0x04 Generic Rosen & Rekhter [Page 12] Internet Draft draft-ietf-idr-extcomm-iana-01.txt September 2013 5.2.6. Transitive IPv4-Address-Specific Sub-Types This registry contains values of the second octet (the "Sub-Type field") of an extended community, when the value of the first octet (the "Type field") is 0x01. Registry Name: TRANSITIVE IPV4-ADDRESS-SPECIFIC EXTENDED COMMUNITY SUB-TYPES RANGE REGISTRATION PROCEDURE 0x00-0xBF First Come, First Served 0xC0-0xFF IETF Review SUB-TYPE VALUE NAME 0x02 Route Target 0x03 Route Origin 0x05 OSPF Domain Identifier 0x07 OSPF Route ID 0x0A L2VPN Identifier 0x0B VRF Route Import 0x10 Cisco VPN-Distinguisher 5.2.7. Non-Transitive IPv4-Address-Specific Sub-Types This registry contains values of the second octet (the "Sub-Type field") of an extended community, when the value of the first octet (the "Type field") is 0x41. Registry Name: NON-TRANSITIVE IPV4-ADDRESS-SPECIFIC EXTENDED COMMUNITY SUB-TYPES RANGE REGISTRATION PROCEDURE 0x00-0xBF First Come, First Served 0xC0-0xFF IETF Review None Assigned Rosen & Rekhter [Page 13] Internet Draft draft-ietf-idr-extcomm-iana-01.txt September 2013 5.2.8. Transitive Opaque Extended Community Sub-Types This registry contains values of the second octet (the "Sub-Type field") of an extended community, when the value of the first octet (the "Type field") is 0x03. Registry Name: TRANSITIVE OPAQUE EXTENDED COMMUNITY SUB-TYPES RANGE REGISTRATION PROCEDURE 0x00-0xBF First Come, First Served 0xC0-0xFF IETF Review SUB-TYPE VALUE NAME 0x06 OSPF Route Type 0x0B Color Extended Community 0x0C Encapsulation Extended Community 0x0D Default Gateway 5.2.9. Non-Transitive Opaque Extended Community Sub-Types This registry contains values of the second octet (the "Sub-Type field") of an extended community, when the value of the first octet (the "Type field") is 0x43. Registry Name: NON-TRANSITIVE OPAQUE EXTENDED COMMUNITY SUB-TYPES RANGE REGISTRATION PROCEDURE 0x00-0xBF First Come, First Served 0xC0-0xFF IETF Review SUB-TYPE VALUE NAME 0x00 BGP Origin Validation State Rosen & Rekhter [Page 14] Internet Draft draft-ietf-idr-extcomm-iana-01.txt September 2013 5.2.10. Generic Transitive Experimental Use Sub-Types Registry Name: BGP GENERIC TRANSITIVE EXPERIMENTAL USE EXTENDED COMMUNITY SUB-TYPES RANGE REGISTRATION PROCEDURE 0x00-0xBF First Come, First Served 0xC0-0xFF IETF Review SUB-TYPE VALUE NAME 0x06 Flow spec traffic-rate 0x07 Flow spec traffic-action (Use of the Value Field is defined in the "Traffic Action Field" registry) 0x08 Flow spec redirect 0x09 Flow spec traffic-remarking 0x0A Layer2 Info Extended Community Note: RFC 5575 contains narrative text that declares the "Flow spec traffic-rate" to be non-transitive, but then assigns it a codepoint that indicates it to be transitive. Addressing this error in RFC 5575 is not within the scope of the current document. 5.2.11. Registries for the Value Field At the time of writing of this document, there is only one registry containing codepoints for the Value Field of an Extended Community. 5.2.11.1. Traffic Action Field This registry does not need to be modified. 5.3. Registries for IPv6-Address-Specific ECs 5.3.1. Transitive Types This registry contains values of the two high-order octets of an IPv6-Address-Specific Extended Communities attribute. Rosen & Rekhter [Page 15] Internet Draft draft-ietf-idr-extcomm-iana-01.txt September 2013 Registry Name: TRANSITIVE IPV6 ADDRESS SPECIFIC EXTENDED COMMUNITY TYPES RANGE REGISTRATION PROCEDURE 0x0000-0x00FF First Come, First Served TYPE VALUE NAME 0x0002 Route Target 0x0003 Route Origin 0x0004 OSPFv3 Route Attributes (deprecated) 0x000B VRF Route Import 0x0010 Cisco VPN-Distinguisher 0x0011 UUID-based Route Target 5.3.2. Non-Transitive Types This registry contains values of the two high-order octets of an IPv6-Address-Specific Extended Communities attribute. Registry Name: NON-TRANSITIVE IPV6 ADDRESS SPECIFIC EXTENDED COMMUNITY TYPES RANGE REGISTRATION PROCEDURE 0x4000-0x40FF First Come, First Served None assigned 6. Security Considerations No security considerations are raised by this document. Rosen & Rekhter [Page 16] Internet Draft draft-ietf-idr-extcomm-iana-01.txt September 2013 7. Acknowledgments The authors wish to thank Jon Mitchell and Hyojeong Kim for their comments. The authors wish to thank Amanda Baber of IANA for educating us on some of the problems faced by IANA staff when responding to requests for BGP Extended Community Type and Sub-Type codepoint allocations. 8. Authors' Addresses Yakov Rekhter Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 Email: yakov@juniper.net Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA, 01719 Email: erosen@cisco.com 9. Normative References [RFC3692] "Assigning Experimental and Testing Numbers Considered Useful", Narten, RFC 3692, January 2004 [RFC4020] "Early IANA Allocation of Standards Track Code Points", Kompella, Zinin, RFC 4020, February 2005 [RFC4360] "BGP Extended Communities Attribute", Sangli, Tappan, Rekhter, RFC 4360, February 2006 [RFC5226] "Guidelines for Writing an IANA Considerations Section in RFCs", Narten, Alvestrand, RFC 5226, May 2008 [RFC5701] "IPv6 Address Specific BGP Extended Community Attribute", Rekhter, RFC 5701, November 2009 Rosen & Rekhter [Page 17] Internet Draft draft-ietf-idr-extcomm-iana-01.txt September 2013 Rosen & Rekhter [Page 18]