One document matched: draft-ietf-idr-reserved-extended-communities-06.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="no"?>
<?rfc tocompact="no"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-idr-reserved-extended-communities-06"
ipr="trust200902">
<front>
<title abbrev="Assigned extended communities">Assigned BGP extended
communities</title>
<author fullname="Bruno Decraene" initials="B." surname="Decraene">
<organization>Orange</organization>
<address>
<postal>
<street>38 rue du General Leclerc</street>
<city>Issy Moulineaux cedex 9</city>
<code>92794</code>
<country>France</country>
</postal>
<email>bruno.decraene@orange.com</email>
</address>
</author>
<author fullname="Pierre Francois" initials="P." surname="Francois">
<organization>IMDEA Networks</organization>
<address>
<postal>
<street>Avda. del Mar Mediterraneo, 22</street>
<city>Leganese</city>
<code>28918</code>
<country>ES</country>
</postal>
<email>pierre.francois@imdea.org</email>
</address>
</author>
<date year="2013" />
<abstract>
<t>This document defines an IANA registry in order to assign
non-transitive extended communities from. These are similar to the
existing well-known BGP communities defined in RFC 1997 but provide a
control over inter-AS community advertisement as, per RFC RFC 4360, they
are not transitive across Autonomous System boundaries.</t>
<t>For that purpose, this document defines the use of the reserved
Autonomous System number 0.65535 in the non-transitive generic
four-octet AS specific extended community type.</t>
</abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t><xref target="RFC1997"></xref> defines the BGP community attribute
and some BGP well-known communities whose meaning SHALL be understood by
all compliant implementations. New communities can be registered in the
IANA "BGP Well-known Communities" registry but it can't be assumed
anymore that they will be known by all BGP implementations.
Implementations or BGP policies which recognize them will behave as
specified in the IANA registry. Implementations which do not recognize
those new IANA assigned communities will propagate them from BGP
neighbor to BGP neighbor and from AS to AS with an unlimited scope.</t>
<t>There is currently no agreed way to register a non-transitive
well-known community.</t>
<t>On one hand, <xref target="RFC1997"></xref> defines BGP Well-known
communities with no structure to set their transitiveness across ASes.
Without structure, communities can only be filtered by explicitly
enumerating all community values that will be denied or allowed to BGP
speakers in neighboring ASes. This is not satisfactory as this would
require upgrading all border routers to understand this community before
its first usage.</t>
<t>On the other hand, <xref target="RFC4360"></xref> defines the BGP
extended community attribute with a structure including a type and a
transitive bit "T". This transitive bit, when set, allows to restrict
the scope of the community within an AS. But there is no IANA registry
to allocate one well-known extended community. <xref
target="RFC4360"></xref> defines IANA registries to allocate BGP
Extended Communities types. Each type is able to encode 2^48 or 2^56
values depending on the type being extended or regular. Therefore, one
needing to reserve a single non-transitive extended community would need
to reserve an extended subtype which represents 2^48 communities, while
a single value is used. This would both waste the resources and disable
the ability to define global policies on reserved communities, such as
to accept them or to filter them out. In addition, using a new community
type typically requires a software upgrade on both the router setting
the community and the router using it in a BGP policy. So this would not
allow the networking community to quickly define and use a new
community.</t>
<t><vspace blankLines="1" />To address this limitation, this document
defines an IANA registry in order to allow the registration of
non-transitive extended communities. These are similar to the existing
Well-known BGP communities defined in <xref target="RFC1997"></xref> but
provides a control on inter-AS community advertisement. Indeed, as per
<xref target="RFC4360"></xref> non-transitive communities are removed
from routes propagated to another AS.</t>
</section>
<section title="Assigned non-transitive extended communities">
<t><xref target="I-D.ietf-idr-as4octet-extcomm-generic-subtype"></xref>
defines a generic sub-type for the four-octet AS specific extended
community. The value of the four-octets Global Administrator sub-field
contains a four-octet Autonomous System number. The value of their
two-octet Local Administrator sub-field has semantics defined by the
Autonomous System set in the Global Administrator sub-field.</t>
<t>This document updates <xref
target="I-D.ietf-idr-as4octet-extcomm-generic-subtype"></xref> and
defines the use of the Local Administrator sub-field of the
"non-transitive generic four-octet AS specific" extended community type
when the AS number has the reserved value 0.65535 (0x0000FFFF).</t>
<t>When the AS number, encoded in the Global Administrator sub-field,
has the reserved value 0.65535, the communities have global
significance. The lists of those communities are maintained by the IANA
in the registry "Assigned non-transitive extended communities".</t>
<t>Note that this use of the reserved AS number 0.65535 in the AS field
of the communities is similar to the one defined by <xref
target="RFC1997"></xref> for the BGP Well-Known communities. In
particular, <xref target="RFC1997"></xref> also uses the reserved AS
number 65535.</t>
</section>
<section title="Assigned transitive extended communities">
<t>As per <xref target="RFC6793"></xref>, a 2-octet Autonomous System
number can be converted into a 4-octet Autonomous System number by
setting the two high-order octets of the 4-octet field to zero. This
applies to the reserved 2-octet Autonous System number 65535 which could
use either a standard community or the 4-octet AS specific generic
extended community. As noted in <xref
target="I-D.ietf-idr-as4octet-extcomm-generic-subtype"></xref>, this is
undesirable as they would be treated as different communities, even if
they had the same values.</t>
<t>Therefore, this document does not define a transitive extended
community registry. Transitive communities are to be assigned
as per <xref target="RFC1997"></xref>.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>The IANA is requested to create and maintain a registry entitled
"Assigned non-transitive extended communities" with the following
registration procedure:</t>
<t><vspace blankLines="1" /></t>
<figure>
<artwork><![CDATA[ Registry Name: Assigned non-transitive extended communities
with Global Significance
Range Registration Procedures
----------- -------------------------
0x0000-8000 First Come First Served
0x8001-FFFF Standards Action/Early IANA Allocation]]></artwork>
</figure>
<t><vspace blankLines="2" />An application may need both a transitive
and a non-transitive community and it may be beneficial to have the same
value for both communities. Therefore, the IANA SHOULD try to
accommodate such request to get both a non-transitive community from the
above "Assigned non transitive extended communities" and a transitive
community from <xref target="RFC1997"></xref> BGP Well-known Communities
with the same (lower two-octets) value for both.</t>
</section>
<section anchor="Security" title="Security Considerations" toc="default">
<t>This document defines IANA actions. In itself, it has no impact on
the security of the BGP protocol.</t>
<t>It allows the allocation of non-transitive global communities which
are not propagated across Autonomous System boundaries. Compared to a
transitive well-known community, a non-transitive community can provide
some security benefit both for the sender and the receiver of the
community.</t>
</section>
<section anchor="acknowledgements" title="Acknowledgements">
<t>We would like to acknowledge John Scudder, Jeffrey Haas and Yakov Rekhter for their
contribution to this document.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.1997"?>
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.4360"?>
<?rfc include="reference.RFC.6793"?>
<?rfc include="reference.RFC.5226"?>
<?rfc include="reference.I-D.ietf-idr-as4octet-extcomm-generic-subtype"?>
<?rfc ?>
</references>
<section anchor="authors-notes" title="Appendix A. Changes / Author Notes">
<t>[RFC Editor: Please remove this section before publication ]</t>
<t>Changes -01: <list style="symbols">
<t>Name changed from 'Reserved BGP extended communities' to
'Assigned BGP extended communities'</t>
<t>Addition of section 'Assigned extended communities'</t>
</list></t>
<t>Changes -02: no change, refresh only.</t>
<t>Changes -03: <list style="symbols">
<t>Use of AS number 0.65535 (0x0000FFFF) instead of AS 0. This is
better aligned with RFC 1997 which also uses AS 65535.</t>
<t>Remove the transitive flavor of assigned extended communities.
RFC 1997 well-known standard communities to be used instead.</t>
</list></t>
<t>Changes -04: no change, refresh only.</t>
<t>Changes -05: minor editorial change (RFC 4893 obsoleted by 6793).</t>
<t>Changes -06: typo fixed, minor editorial change.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:31:54 |