doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc7153.txt b/doc/rfc/rfc7153.txt
new file mode 100644
index 0000000..cad5847
--- /dev/null
+++ b/doc/rfc/rfc7153.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          E. Rosen
+Request for Comments: 7153                           Cisco Systems, Inc.
+Updates: 4360, 5701                                           Y. Rekhter
+Category: Standards Track                         Juniper Networks, Inc.
+ISSN: 2070-1721                                               March 2014
+
+
+              IANA Registries for BGP Extended Communities
+
+Abstract
+
+   This document reorganizes the IANA registries for the type values and
+   sub-type values of the BGP Extended Communities attribute and the BGP
+   IPv6-Address-Specific Extended Communities attribute.  This is done
+   in order to remove interdependencies 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 RFC 4360 and RFC 5701.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7153.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosen & Rekhter              Standards Track                    [Page 1]
+
+RFC 7153               IANA Registries for BGP ECs            March 2014
+
+
+Copyright Notice
+
+   Copyright (c) 2014 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              Standards Track                    [Page 2]
+
+RFC 7153               IANA Registries for BGP ECs            March 2014
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Types, Sub-Types, and Registries ................................4
+   3. Applicability to IPv6-Address-Specific EC Attribute .............4
+   4. How to Request EC Type and/or Sub-Type Codepoints ...............5
+   5. IANA Considerations .............................................6
+      5.1. Registries for the "Type" Field ............................7
+           5.1.1. Transitive Types ....................................7
+           5.1.2. Non-Transitive Types ................................8
+      5.2. Registries for the "Sub-Type" Field ........................9
+           5.2.1. EVPN Extended Community Sub-Types ...................9
+           5.2.2. Transitive Two-Octet AS-Specific Extended Community
+                  Sub-Types ..........................................10
+           5.2.3. Non-Transitive Two-Octet AS-Specific Extended
+                  Community Sub-Types ................................10
+           5.2.4. Transitive Four-Octet AS-Specific Extended
+                  Community Sub-Types ................................11
+           5.2.5. Non-Transitive Four-Octet AS-Specific Extended
+                  Community Sub-Types ................................11
+           5.2.6. Transitive IPv4-Address-Specific Extended Community
+                  Sub-Types ..........................................12
+           5.2.7. Non-Transitive IPv4-Address-Specific Extended
+                  Community Sub-Types ................................12
+           5.2.8. Transitive Opaque Extended Community Sub-Types .....13
+           5.2.9. Non-Transitive Opaque Extended Community
+                  Sub-Types ..........................................13
+           5.2.10. Generic Transitive Experimental Use Extended
+                   Community Sub-Types ...............................14
+           5.2.11. Registries for the "Value" Field ..................14
+                  5.2.11.1. Traffic Action Fields ....................14
+      5.3. Registries for IPv6-Address-Specific ECs ..................15
+           5.3.1. Transitive Types ...................................15
+           5.3.2. Non-Transitive Types ...............................15
+   6. Security Considerations ........................................15
+   7. Acknowledgments ................................................16
+   8. Normative References ...........................................16
+
+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
+   subdivided into a sub-range of values to be assigned by IANA under
+   the "Standards Action" policy, a sub-range of values to be assigned
+
+
+
+Rosen & Rekhter              Standards Track                    [Page 3]
+
+RFC 7153               IANA Registries for BGP ECs            March 2014
+
+
+   by IANA under the "First Come First Served" policy, and a sub-range
+   for "experimental use".  (See [RFC5226], [RFC7120], 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
+   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
+
+
+
+Rosen & Rekhter              Standards Track                    [Page 4]
+
+RFC 7153               IANA Registries for BGP ECs            March 2014
+
+
+   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 either of the
+   IPv4-Address-Specific Sub-Types registries.
+
+   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 the "BGP Transitive Extended
+   Community Types" registry, the "BGP 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.
+
+   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 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.
+
+
+
+
+Rosen & Rekhter              Standards Track                    [Page 5]
+
+RFC 7153               IANA Registries for BGP ECs            March 2014
+
+
+   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.  For example, one may want to define a new Extended
+   Community so that it can be either transitive or non-transitive,
+   either 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.
+
+5.  IANA Considerations
+
+   IANA has replaced the pre-existing BGP Extended Communities
+   registries with the registries described in this section.
+
+   The registries reproduced below do not include the "references" or
+   "date" fields for the individual codepoints in the registries,
+   because it is difficult to incorporate those within the 72-character
+   line limitation of RFCs.  The references and associated dates have
+   been copied from the existing registries when creating the new
+   registries; the authors have worked with IANA to ensure that this
+   information has been carried over correctly to the reorganized
+   registry.  As this document does not change the usage or semantics of
+   any of the codepoints, the references associated with the individual
+   codepoints do not change.
+
+   On the other hand, the references for each of the registries defined
+   in this section have been changed to refer to this document.
+
+
+
+Rosen & Rekhter              Standards Track                    [Page 6]
+
+RFC 7153               IANA Registries for BGP ECs            March 2014
+
+
+5.1.  Registries for the "Type" Field
+
+5.1.1.  Transitive Types
+
+   The following note has been added to the "BGP Transitive Extended
+   Community Types" registry.
+
+      This registry contains values of the high-order octet (the "Type"
+      field) of a Transitive Extended Community.
+
+   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
+
+      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
+
+
+
+Rosen & Rekhter              Standards Track                    [Page 7]
+
+RFC 7153               IANA Registries for BGP ECs            March 2014
+
+
+      0x80             Generic Transitive Experimental Use Extended
+                       Community (Sub-Types are defined in the
+                       "Generic Transitive Experimental Use Extended
+                       Community Sub-Types" registry)
+
+5.1.2.  Non-Transitive Types
+
+   The following note has been added to the "BGP Non-Transitive Extended
+   Community Types" registry.
+
+      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
+
+      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
+                       Community (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              Standards Track                    [Page 8]
+
+RFC 7153               IANA Registries for BGP ECs            March 2014
+
+
+5.2.  Registries for the "Sub-Type" Field
+
+5.2.1.  EVPN Extended Community Sub-Types
+
+   The following note has been added to the "EVPN Extended Community
+   Sub-Types" registry:
+
+      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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosen & Rekhter              Standards Track                    [Page 9]
+
+RFC 7153               IANA Registries for BGP ECs            March 2014
+
+
+5.2.2.  Transitive Two-Octet AS-Specific Extended Community Sub-Types
+
+   The following note has been added to the "Transitive Two-Octet
+   AS-Specific Extended Community Sub-Types" registry:
+
+      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.
+
+   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 Extended Community
+        Sub-Types
+
+   The following note has been added to the "Non-Transitive Two-Octet
+   AS-Specific Extended Community Sub-Types" registry:
+
+      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              Standards Track                   [Page 10]
+
+RFC 7153               IANA Registries for BGP ECs            March 2014
+
+
+5.2.4.  Transitive Four-Octet AS-Specific Extended Community Sub-Types
+
+   The following note has been added to the "Transitive Four-Octet
+   AS-Specific Extended Community Sub-Types" registry:
+
+      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 Extended Community
+        Sub-Types
+
+   The following note has been added to the "Non-Transitive Four-Octet
+   AS-Specific Extended Community Sub-Types" registry:
+
+      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              Standards Track                   [Page 11]
+
+RFC 7153               IANA Registries for BGP ECs            March 2014
+
+
+5.2.6.  Transitive IPv4-Address-Specific Extended Community Sub-Types
+
+   The following note has been added to the "Transitive
+   IPv4-Address-Specific Extended Community Sub-Types" registry:
+
+      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 Extended Community
+        Sub-Types
+
+   The following note has been added to the "Non-Transitive
+   IPv4-Address-Specific Extended Community Sub-Types" registry:
+
+      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              Standards Track                   [Page 12]
+
+RFC 7153               IANA Registries for BGP ECs            March 2014
+
+
+5.2.8.  Transitive Opaque Extended Community Sub-Types
+
+   The following note has been added to the "Transitive Opaque Extended
+   Community Sub-Types" registry:
+
+      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
+
+   The following note has been added to the "Non-Transitive Opaque
+   Extended Community Sub-Types" registry:
+
+      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              Standards Track                   [Page 13]
+
+RFC 7153               IANA Registries for BGP ECs            March 2014
+
+
+5.2.10.  Generic Transitive Experimental Use Extended Community
+         Sub-Types
+
+   The following note has been added to the "Generic Transitive
+   Experimental Use Extended Community Sub-Types" registry:
+
+      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 0x80.
+
+   Registry Name: 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 Fields" 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 that it is transitive.  Addressing this error in
+   RFC 5575 is not within the scope of this document.
+
+5.2.11.  Registries for the "Value" Field
+
+   At the time of the 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 Fields
+
+   This registry has not been modified.
+
+
+
+
+
+
+
+
+
+Rosen & Rekhter              Standards Track                   [Page 14]
+
+RFC 7153               IANA Registries for BGP ECs            March 2014
+
+
+5.3.  Registries for IPv6-Address-Specific ECs
+
+5.3.1.  Transitive Types
+
+   The following note has been added to the "Transitive
+   IPv6-Address-Specific Extended Community Types" registry:
+
+      This registry contains values of the two high-order octets of an
+      IPv6-Address-Specific Extended Community.
+
+   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
+
+   The following note has been added to the "Non-Transitive
+   IPv6-Address-Specific Extended Community Types" registry:
+
+      This registry contains values of the two high-order octets of an
+      IPv6-Address-Specific Extended Community.
+
+   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              Standards Track                   [Page 15]
+
+RFC 7153               IANA Registries for BGP ECs            March 2014
+
+
+7.  Acknowledgments
+
+   The authors wish to thank Jon Mitchell, Hyojeong Kim, and Pearl Liang
+   for their review and 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.  Normative References
+
+   [RFC3692]  Narten, T., "Assigning Experimental and Testing Numbers
+              Considered Useful", BCP 82, RFC 3692, January 2004.
+
+   [RFC4360]  Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
+              Communities Attribute", RFC 4360, February 2006.
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              May 2008.
+
+   [RFC5701]  Rekhter, Y., "IPv6 Address Specific BGP Extended Community
+              Attribute", RFC 5701, November 2009.
+
+   [RFC7120]  Cotton, M., "Early IANA Allocation of Standards Track Code
+              Points", BCP 100, RFC 7120, January 2014.
+
+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
+
+
+
+
+
+
+
+
+Rosen & Rekhter              Standards Track                   [Page 16]
+