One document matched: draft-ietf-idr-flowspec-redirect-rt-bis-05.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC4360 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4360.xml">
<!ENTITY RFC5575 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5575.xml">
<!ENTITY RFC5668 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5668.xml">
<!ENTITY RFC7153 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7153.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-ietf-idr-flowspec-redirect-rt-bis-05" ipr="trust200902" updates="5575">
<front>
<title abbrev="draft-ietf-idr-flowspec-redirect-rt-bis">Clarification of the Flowspec Redirect Extended Community</title>
<author fullname="Jeffrey Haas" initials="J.H."
surname="Haas" role="editor">
<organization>Juniper Networks</organization>
<address>
<email>jhaas@juniper.net</email>
</address>
</author>
<date month="July" year="2015" />
<!-- Meta-data Declarations -->
<area>Routing</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>bgp</keyword>
<keyword>flowspec</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>
This document updates RFC 5575 (Dissemination of Flow Specification
Rules) to clarify the formatting of the the BGP Flowspec
Redirect Extended Community.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
<xref target="RFC5575">Dissemination of Flow Specification Rules</xref>,
commonly known as BGP Flowspec, provided for a
<xref target="RFC4360">BGP Extended Community</xref>
that served to redirect traffic to a VRF routing instance
that matched the flow specification NLRI. In that RFC, the
Redirect Extended Community was documented as follows:
</t>
<figure>
<!--preamble></preamble-->
<artwork><![CDATA[
: +--------+--------------------+--------------------------+
: | type | extended community | encoding |
: +--------+--------------------+--------------------------+
: | 0x8008 | redirect | 6-byte Route Target |
: +--------+--------------------+--------------------------+
:
: [...]
:
: Redirect: The redirect extended community allows the traffic to be
: redirected to a VRF routing instance that lists the specified
: route-target in its import policy. If several local instances
: match this criteria, the choice between them is a local matter
: (for example, the instance with the lowest Route Distinguisher
: value can be elected). This extended community uses the same
: encoding as the Route Target extended community [RFC4360].
: [...]
:
: 11. IANA Considerations
: [...]
:
: The following traffic filtering flow specification rules have been
: allocated by IANA from the "BGP Extended Communities Type -
: Experimental Use" registry as follows:
: [...]
:
: 0x8008 - Flow spec redirect
]]></artwork>
<!--postamble></postamble-->
</figure>
<t>
The IANA registry of BGP Extended Communities clearly identifies
communities of specific formats. For example,
<xref target="RFC4360">"Two-octet AS Specific Extended Community"</xref>,
<xref target="RFC5668">"Four-octet AS Specific Extended Community"</xref> and
<xref target="RFC4360">"IPv4 Address Specific Extended Community"</xref>.
<xref target="RFC4360"> Route Targets</xref> identify this format
in the high-order (Type) octet of the Extended Community and set
the value of the low-order (Sub-Type) octet to 0x02. The Value
field of the Route Target Extended Community is intended to be
interpreted in the context of its format.
</t>
<t>
Since the Redirect Extended Community only registered a single
code-point in the IANA BGP Extended Community registry, a common
interpretation of the redirect extended community's "6-byte route
target" has been to look, at a receiving router, for a route target
value that matches the route target value in the received redirect
extended community, and import the advertised route to the
corresponding VRF instance subject to the rules defined in
<xref target="RFC5575"/>.
However, because the route target format in the
redirect extended community is not clearly defined, the wrong match
may occur.
</t>
<t>
This "value wildcard" matching behavior, which does not take into
account the format of the route target defined for a local VRF and
may result in the wrong matching decision, does not match deployed
implementations of BGP Flowspec. Deployed implementations of BGP
Flowspec solve this problem by defining different redirect
extended communities that are specific to the format of the route
target value. This document defines the following redirect extended
communities:
</t>
<figure>
<!--preamble></preamble-->
<artwork><![CDATA[
+--------+--------------------+-------------------------------------+
| type | extended community | encoding |
+--------+--------------------+-------------------------------------+
| 0x8008 | redirect AS-2byte | 2-octet AS, 4-octet Value |
| 0x8108 | redirect IPv4 | 4-octet IPv4 Address, 2-octet Value |
| 0x8208 | redirect AS-4byte | 4-octet AS, 2-octet Value |
+--------+--------------------+-------------------------------------+
]]></artwork>
<!--postamble></postamble-->
</figure>
<t>
It should be noted that the low-order nibble of the Redirect's Type
field corresponds to the Route Target Extended Community format field
(Type). (See <xref target="RFC4360"/>, Secs. 3.1, 3.2, and 4 plus
<xref target="RFC5668"/>, Sec. 2.) The low order octet (Sub-Type) of the
Redirect Extended Community remains 0x08, contrasted to 0x02 for Route
Targets.
</t>
<t>
The IANA Registries for BGP Extended Communities
<xref target="RFC7153"/> document was written to update the
previously-mentioned IANA registries to better document BGP Extended
Community formats. The IANA Considerations section below further
amends those registry updates in order to properly document the Flowspec
redirect communities.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<section title="BGP Transitive Extended Community Types">
<t>
IANA is requested to update the "BGP Transitive Extended Community Types"
registry as follows:
<figure>
<artwork><![CDATA[
0x81 - Generic Transitive Experimental Use Extended Community
Part 2 (Sub-Types are defined in the "Generic Transitive
Experimental Extended Community Part 2 Sub-Types" Registry)
0x82 - Generic Transitive Experimental Use Extended Community
Part 3 (Sub-Types are defined in the "Generic Transitive
Experimental Extended Community Part 3 Sub-Types" Registry)
]]></artwork>
</figure>
</t>
</section>
<section title="Update to BGP Generic Transitive Experimental Use Extended Community Sub-Types">
<t>
IANA is requested to update the "BGP Generic Transitive Experimental
Use Extended Community Sub-Types" registry as follows:
<figure>
<artwork><![CDATA[
0x08 - Flow spec redirect AS-2byte format. [RFC5575, RFC-to-be]
]]></artwork>
</figure>
</t>
<t>(Note to RFC Editor - replace RFC-to-be with this RFC number.)</t>
</section>
<section title="Generic Transitive Experimental Extended Community Part 2 Sub-Types">
<t>
IANA is requested to create the "Generic Transitive Experimental Use Extended Community Part 2 Sub-Types" registry. This registry should be created under the BGP Extended Communities registry. It will contain the following note:
<list style="hanging">
<t>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 0x81.
</t>
</list>
</t>
<t>
Registry Name: Generic Transitive Experimental Use Extended Community Part 2 Sub-Types
</t>
<figure>
<artwork><![CDATA[
RANGE REGISTRATION PROCEDURE REFERENCE
0x00-0xBF First Come First Served
0xC0-0xFF IETF Review
SUB-TYPE VALUE NAME
0x00-0x07 Unassigned
0x08 Flow spec redirect IPv4 format. [RFC-to-be]
0x09-0xff Unassigned
]]></artwork>
</figure>
<t>(Note to RFC Editor - replace RFC-to-be with this RFC number.)</t>
</section>
<section title="Generic Transitive Experimental Extended Community Part 3 Sub-Types">
<t>
IANA is requested to create the "Generic Transitive Experimental Use Extended Community Part 3 Sub-Types" registry. This registry should be created under the BGP Extended Communities registry. It will contain the following note:
<list style="hanging">
<t>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 0x82.
</t>
</list>
</t>
<t>
Registry Name: Generic Transitive Experimental Use Extended Community Part 2 Sub-Types
</t>
<figure>
<artwork><![CDATA[
RANGE REGISTRATION PROCEDURE REFERENCE
0x00-0xBF First Come First Served
0xC0-0xFF IETF Review
SUB-TYPE VALUE NAME
0x00-0x07 Unassigned
0x08 Flow spec redirect AS-4byte format. [RFC-to-be]
0x09-0xff Unassigned
]]></artwork>
</figure>
<t>(Note to RFC Editor - replace RFC-to-be with this RFC number.)</t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document introduces no additional security considerations than
those already covered in <xref target="RFC5575"/>. It should be noted
that if the wildcard behavior were actually implemented, this ambiguity
may lead to the installation of Flowspec rules in an incorrect VRF and
may lead to traffic to be incorrectly delivered.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
The contents of this document was raised as part of implementation
discussions of BGP Flowspec with the following individuals:
<list style="hanging">
<t>Andrew Karch (Cisco)</t>
<t>Robert Raszuk</t>
<t>Adam Simpson (Alcatel-Lucent)</t>
<t>Matthieu Texier (Arbor Networks)</t>
<t>Kaliraj Vairavakkalai (Juniper)</t>
</list>
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
&RFC4360;
&RFC5575;
&RFC5668;
&RFC7153;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:11:29 |