next layer Telekom GmbH

Mariahilfer Guertel 37/7 Vienna 1150 Austria +43 664 1176414 cl@tix.at

Routing Area IDR Working Group IANA This document updates several BGP Extended Community registries in order to replace the "Experimental Use" registration procedure in some entries, since their use is clearly not experimental and is thus misleading. This document updates RFCs 7153 and 8955.

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 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2022 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 () 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Table of Contents

• .  Introduction
• .  IANA Considerations
  • .  Registry: BGP Transitive Extended Community Types
  • .  Registry: Generic Transitive Experimental Use Extended Community Sub-Types
  • .  Registry: Generic Transitive Experimental Use Extended Community Part 2 Sub-Types
  • .  Registry: Generic Transitive Experimental Use Extended Community Part 3 Sub-Types
• .  Security Considerations
• .  References
  • .  Normative References
  • .  Informative References
• Acknowledgements
• Author's Address

Introduction The IANA registries for the type values and sub-type values of the BGP Extended Communities attribute were reorganized by . As a result, IANA maintains a registry entitled "BGP Transitive Extended Community Types", which includes a range of type values (0x80-0x8F) reserved for Experimental Use . Out of this experimental range, types 0x80, 0x81, and 0x82 have been used in and (both documents were rendered obsolete by ). The primary use for those types and the sub-type registries is non-experimental. describes updates to the registry to reflect the actual use of those code points by changing the registration procedure from "Experimental Use" to "First Come First Served" for the types 0x80-0x82 (and removing "Experimental Use" from the sub-type registry names), thereby updating and .

IANA Considerations

Registry: BGP Transitive Extended Community Types IANA maintains a registry entitled "BGP Transitive Extended Community Types". IANA has added RFC 9184 to the reference of this registry. They have also updated the name of the type values according to and added RFC 9184 as a reference for the existing entries. Registry: BGP Transitive Extended Community Types

Type Value	Name	Reference
0x80	Generic Transitive Extended Community (Sub-Types are defined in the "Generic Transitive Extended Community Sub-Types" registry)	RFC 9184
0x81	Generic Transitive Extended Community Part 2 (Sub-Types are defined in the "Generic Transitive Extended Community Part 2 Sub-Types" registry)	RFC 9184
0x82	Generic Transitive Extended Community Part 3 (Sub-Types are defined in the "Generic Transitive Extended Community Part 3 Sub-Types" registry)	RFC 9184

Furthermore, IANA has changed the registration procedures of this registry for type values 0x80 through 0x82 to First Come First Served . The resulting registration procedures should read as in . Registration Procedures: BGP Transitive Extended Community Types

Range	Registration Procedures
0x00-0x3f	First Come First Served
0x80-0x82	First Come First Served (see RFC 9184)
0x83-0x8f	Reserved for Experimental Use (see )
0x90-0xbf	Standards Action

Registry: Generic Transitive Experimental Use Extended Community Sub-Types IANA maintains a registry entitled "Generic Transitive Experimental Use Extended Community Sub-Types". IANA has added RFC 9184 to the reference of this registry and updated the registry title to:

• "Generic Transitive Extended Community Sub-Types"

Registry: Generic Transitive Experimental Use Extended Community Part 2 Sub-Types IANA maintains a registry entitled "Generic Transitive Experimental Use Extended Community Part 2 Sub-Types". IANA has added RFC 9184 to the reference of this registry and updated the registry title to:

• "Generic Transitive Extended Community Part 2 Sub-Types"

Registry: Generic Transitive Experimental Use Extended Community Part 3 Sub-Types IANA maintains a registry entitled "Generic Transitive Experimental Use Extended Community Part 3 Sub-Types". IANA has added RFC 9184 to the reference of this registry and updated the registry title to:

• "Generic Transitive Extended Community Part 3 Sub-Types"

Security Considerations There are no direct security considerations arising from this document.

References Normative References 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. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Informative References When experimenting with or extending protocols, it is often necessary to use some sort of protocol number or constant in order to actually test or experiment with the new function, even when testing in a closed environment. For example, to test a new DHCP option, one needs an option number to identify the new function. This document recommends that when writing IANA Considerations sections, authors should consider assigning a small range of numbers for experimentation purposes that implementers can use when testing protocol extensions or other new features. This document reserves some ranges of numbers for experimentation purposes in specific protocols where the need to support experimentation has been identified. This document defines a new Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute traffic flow specifications. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix. Additionally, it defines two applications of that encoding format: one that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial-of-service attacks, and a second application to provide traffic filtering in the context of a BGP/MPLS VPN service. The information is carried via the BGP, thereby reusing protocol algorithms, operational experience, and administrative processes such as inter-provider peering agreements. [STANDARDS-TRACK] This document updates RFC 5575 ("Dissemination of Flow Specification Rules") to clarify the formatting of the BGP Flowspec Redirect Extended Community. This document defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute (intra-domain and inter-domain) traffic Flow Specifications for IPv4 unicast and IPv4 BGP/MPLS VPN services. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix. It also specifies BGP Extended Community encoding formats, which can be used to propagate Traffic Filtering Actions along with the Flow Specification NLRI. Those Traffic Filtering Actions encode actions a routing system can take if the packet matches the Flow Specification. This document obsoletes both RFC 5575 and RFC 7674.

Acknowledgements The author wants to thank , who pointed out that the IANA registry contains misleading entries in this context.

Author's Address next layer Telekom GmbH

Mariahilfer Guertel 37/7 Vienna 1150 Austria +43 664 1176414 cl@tix.at