Deprecation of BGP Path Attribute Values 30, 31, 129, 241, 242, and 243
NTT Communications
Theodorus Majofskistraat 100
1065 SZ
Amsterdam
The Netherlands
job@ntt.net
Routing
IDR
BGP
This document requests IANA to mark BGP path attribute
values 30, 31, 129, 241, 242, and 243 as "Deprecated".
It has been discovered that certain BGP Path Attribute values
have been used in BGP implementations that have been deployed
in the wild while not being assigned by IANA for such
usage. Unregistered usage of BGP Path Attribute values can lead to
deployment problems for new technologies.
The use of these unregistered values was noticed when the BGP Large
Communities attribute
was initially assigned value 30 by IANA. It was subsequently
discovered that a widely deployed BGP-4
implementation had released code that used path attribute 30
and that applied a "Treat-as-withdraw"
strategy to routes containing a valid Large Community
attribute, since it was expecting a different data structure.
Because these routes were dropped, early adopters of Large
Communities were unreachable from parts of the Internet. As a
workaround, a new Early IANA Allocation was requested.
The squatting of values 30, 31, 129, 241, 242, and 243 has been
confirmed by the involved vendors or through source code
review.
IANA has marked values 30, 31,
129, 241, 242, and 243 as "Deprecated" in the "BGP Path
Attributes" subregistry under the "Border Gateway Protocol (BGP)
Parameters" registry. The marking "Deprecated" means "use is not
recommended" ().
There are no meaningful security consequences arising from this
registry update.
BGP Large Communities Attribute
This document describes the BGP Large Communities attribute, an extension to BGP-4. This attribute provides a mechanism to signal opaque information within separate namespaces to aid in routing management. The attribute is suitable for use with four-octet Autonomous System Numbers.
Guidelines for Writing an IANA Considerations Section in RFCs
Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values used in these fields do not have conflicting uses, and to promote interoperability, their allocation is 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, IANA needs guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the guidance given to IANA 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.
The author would like to gratefully acknowledge Marlien
Vijfhuizen who helped discover the squatting of value 30, and
Nick Hilliard for editorial feedback.