rfc8955xml2.original.xml   rfc8955.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!ENTITY RFC0768 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.0768.xml"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
<!ENTITY RFC0791 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC docName="draft-ietf-idr-rfc5575bis-25" number="8955" ipr="trust200902"
.0791.xml"> obsoletes="5575, 7674" updates="" submissionType="IETF" category="std"
<!ENTITY RFC0792 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC consensus="true" xml:lang="en" tocInclude="true" symRefs="true"
.0792.xml"> sortRefs="true" version="3">
<!ENTITY RFC0793 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.0793.xml"> <!-- xml2rfc v2v3 conversion 2.44.0 -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2119.xml">
<!ENTITY RFC2474 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2474.xml">
<!ENTITY RFC4271 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4271.xml">
<!ENTITY RFC4303 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4303.xml">
<!ENTITY RFC4360 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4360.xml">
<!ENTITY RFC4364 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4364.xml">
<!ENTITY RFC4456 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4456.xml">
<!ENTITY RFC4760 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4760.xml">
<!ENTITY RFC5575 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5575.xml">
<!ENTITY RFC5668 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5668.xml">
<!ENTITY RFC7153 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7153.xml">
<!ENTITY RFC7223 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7223.xml">
<!ENTITY RFC7606 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7606.xml">
<!ENTITY RFC7674 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7674.xml">
<!ENTITY RFC7950 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7950.xml">
<!ENTITY RFC8126 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8126.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8174.xml">
<!ENTITY RFC8294 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8294.xml">
<!ENTITY RFC6811 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6811.xml">
<!ENTITY RFC8205 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8205.xml">
<!ENTITY I-D.ietf-idr-flow-spec-v6 SYSTEM "http://xml.resource.org/public/rfc/bi
bxml3/reference.I-D.ietf-idr-flow-spec-v6.xml">
<!ENTITY I-D.vandevelde-idr-flowspec-path-redirect SYSTEM "http://xml.resource.o
rg/public/rfc/bibxml3/reference.I-D.vandevelde-idr-flowspec-path-redirect.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<rfc category="std" docName="draft-ietf-idr-rfc5575bis-27" ipr="trust200902" obs
oletes="5575,7674">
<front> <front>
<title abbrev="Flow Specification">Dissemination of Flow Specification Rules< <title abbrev="Flow Specification">Dissemination of Flow Specification Rules
/title> </title>
<author fullname="Christoph Loibl" initials="C.L." <seriesInfo name="RFC" value="8955"/>
surname="Loibl"> <author fullname="Christoph Loibl" initials="C." surname="Loibl">
<organization>next layer Telekom GmbH</organization> <organization>next layer Telekom GmbH</organization>
<address> <address>
<postal> <postal>
<street>Mariahilfer Guertel 37/7</street> <street>Mariahilfer Guertel 37/7</street>
<city>Vienna</city> <city>Vienna</city>
<region></region> <region/>
<code>1150</code> <code>1150</code>
<country>AT</country> <country>Austria</country>
</postal> </postal>
<phone>+43 664 1176414</phone> <phone>+43 664 1176414</phone>
<email>cl@tix.at</email> <email>cl@tix.at</email>
</address> </address>
</author> </author>
<author fullname="Susan Hares" initials="S" surname="Hares"> <author fullname="Susan Hares" initials="S." surname="Hares">
<organization>Huawei</organization> <organization>Huawei</organization>
<address> <address>
<postal> <postal>
<street>7453 Hickory Hill</street> <street>7453 Hickory Hill</street>
<city>Saline</city> <city>Saline</city>
<region>MI</region> <region>MI</region>
<code>48176</code> <code>48176</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>shares@ndzh.com</email> <email>shares@ndzh.com</email>
</address> </address>
</author> </author>
<author fullname="Robert Raszuk" initials="R" surname="Raszuk"> <author fullname="Robert Raszuk" initials="R." surname="Raszuk">
<organization>Bloomberg LP</organization> <organization>NTT Network Innovations</organization>
<address> <address>
<postal> <postal>
<street>731 Lexington Ave</street> <street>940 Stewart Dr</street>
<city>New York City</city> <city>Sunnyvale</city>
<region>NY</region> <region>CA</region>
<code>10022</code> <code>94085</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>robert@raszuk.net </email> <email>robert@raszuk.net </email>
</address> </address>
</author> </author>
<author fullname="Danny McPherson" initials="D." surname="McPherson">
<author fullname="Danny McPherson" initials="D" surname="McPherson">
<organization>Verisign</organization> <organization>Verisign</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city></city> <city/>
<code></code> <code/>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>dmcpherson@verisign.com</email> <email>dmcpherson@verisign.com</email>
</address> </address>
</author> </author>
<author fullname="Martin Bacher" initials="M." surname="Bacher">
<author fullname="Martin Bacher" initials="M.B." <organization>T-Mobile Austria</organization>
surname="Bacher"> <address>
<organization>T-Mobile Austria</organization>
<address>
<postal> <postal>
<street>Rennweg 97-99</street> <street>Rennweg 97-99</street>
<city>Vienna</city> <city>Vienna</city>
<region></region> <region/>
<code>1030</code> <code>1030</code>
<country>AT</country> <country>Austria</country>
</postal> </postal>
<email>mb.ietf@gmail.com</email> <email>mb.ietf@gmail.com</email>
</address> </address>
</author> </author>
<date year="2020" /> <date year="2020" month="December"/>
<area>Routing Area</area> <area>Routing</area>
<workgroup>IDR Working Group</workgroup> <workgroup>IDR</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword> <abstract>
<keyword>I-D</keyword> <t>
<keyword>Internet-Draft</keyword> This document defines a Border Gateway Protocol Network Layer
<keyword>Dissemination of Flow Specification Rules</keyword> Reachability Information (BGP NLRI) encoding format that can be used
<abstract> to distribute (intra-domain and inter-domain) traffic Flow Specifications
<t> for IPv4 unicast and IPv4 BGP/MPLS VPN services. This allows the routing
This document defines a Border Gateway Protocol Network Layer system to propagate information regarding more specific components of
Reachability Information (BGP NLRI) encoding format that can be used the traffic aggregate defined by an IP destination prefix.
to distribute traffic Flow Specifications. This allows the routing </t>
system to propagate information regarding more specific components of <t>
the traffic aggregate defined by an IP destination prefix. It also specifies BGP Extended Community encoding formats, which can
</t> be used to propagate Traffic Filtering Actions along with the Flow
<t> Specification NLRI. Those Traffic Filtering Actions encode actions a
It also specifies BGP Extended Community encoding formats, that can be routing system can take if the packet matches the Flow Specification.
used to propagate Traffic Filtering Actions along with the Flow </t>
Specification NLRI. Those Traffic Filtering Actions encode actions a <t>
routing system can take if the packet matches the Flow Specification. This document obsoletes both RFC 5575 and RFC 7674.
</t> </t>
<t>
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.
Other applications (e.g. centralized control of traffic
in a SDN or NFV context) are also possible. Other documents may specify
Flow Specification extensions.
</t>
<t>
The information is carried via BGP, thereby reusing protocol
algorithms, operational experience, and administrative processes such
as inter-provider peering agreements.
</t>
<t>
This document obsoletes both RFC5575 and RFC7674.
</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro" title="Introduction"> <section anchor="intro" numbered="true" toc="default">
<t> <name>Introduction</name>
This document obsoletes "<xref target="RFC5575" format="title" />" <xref tar <t>This document obsoletes <xref target="RFC5575">"Dissemination of Flow S
get="RFC5575" /> pecification Rules"</xref> (see <xref
(see <xref target="rfc5575differences" /> for the differences). This documen target="rfc5575differences" format="default"/> for the
t also obsoletes differences). This document also obsoletes <xref target="RFC7674"
"<xref target="RFC7674" format="title" />" <xref target="RFC7674" /> since format="default">"Clarification of the Flowspec Redirect Extended Communit
it incorporates the encoding of the BGP Flow Specification Redirect Extended y"</xref>, since it
Community incorporates the encoding of the BGP Flow Specification Redirect
in <xref target="rt_redirect_action_subtype" />. Extended Community in <xref target="rt_redirect_action_subtype"
</t> format="default"/>.</t>
<t> <t>
Modern IP routers have the capability to forward traffic Modern IP routers have the capability to forward traffic
and to classify, shape, rate limit, and to classify, shape, rate limit,
filter, or redirect packets based on administratively defined filter, or redirect packets based on administratively defined
policies. policies.
These traffic policy mechanisms allow the operator to define match These traffic policy mechanisms allow the operator to define match
rules that operate on multiple fields of the packet header. Actions rules that operate on multiple fields of the packet header. Actions,
such as the ones described above can be associated with each rule. such as the ones described above, can be associated with each rule.
</t> </t>
<t> <t>
The n-tuple consisting of the matching criteria defines an aggregate The n-tuple consisting of the matching criteria defines an aggregate
traffic Flow Specification. The matching criteria can include traffic Flow Specification. The matching criteria can include
elements such as source and destination address prefixes, IP elements such as source and destination address prefixes, IP
protocol, and transport protocol port numbers. protocol, and transport protocol port numbers.
</t> </t>
<t> <t><xref target="dissemination_ipv4_flowspec" format="default"/> of this
<xref target="dissemination_ipv4_flowspec" /> of this document defines a gene document defines a general procedure to encode Flow Specifications for
ral procedure to encode Flow aggregated traffic flows so that they can be distributed as a BGP <xref
Specifications for aggregated traffic flows so that they can be target="RFC4271" format="default"/> NLRI. Additionally, <xref
distributed as a BGP <xref target="RFC4271" /> NLRI. target="traffic_filtering_actions" format="default"/> of this
Additionally, <xref target="traffic_filtering_actions" /> of this document de document defines the required Traffic Filtering Actions BGP Extended
fines the Communities and mechanisms to use BGP for intra- and inter-provider
required Traffic Filtering Actions BGP Extended Communities distribution of traffic filtering rules in order to mitigate DoS and
and mechanisms to use BGP for intra- and inter-provider DDoS attacks.
distribution of traffic filtering rules to filter (distributed) </t>
denial-of-service (DoS) attacks.
</t> <t>
<t>
By expanding routing information with Flow Specifications, the By expanding routing information with Flow Specifications, the
routing system can take advantage of the ACL (Access Control List) or routing system can take advantage of the ACL (Access Control List) or
firewall capabilities in the router's forwarding path. Flow firewall capabilities in the router's forwarding path. Flow
Specifications can be seen as more specific routing entries to a Specifications can be seen as more specific routing entries to a
unicast prefix and are expected to depend upon the existing unicast unicast prefix and are expected to depend upon the existing unicast
data information. data information.
</t> </t>
<t> <t>A Flow Specification received from an external autonomous system will
A Flow Specification received from an external autonomous system will need to be validated against unicast routing before being accepted
need to be validated against unicast routing before being accepted (<xref target="validation_procedure" format="default"/>). The Flow
(<xref target="validation_procedure" />). The Flow Specification Specification received from an internal BGP peer within the same
received from an internal BGP peer within the same autonomous system autonomous system <xref target="RFC4271" format="default"/> is assumed
<xref target="RFC4271" /> is assumed to have been validated prior to have been validated prior to transmission within the internal BGP
to transmission within the internal BGP (iBGP) mesh of an autonomous system. (iBGP) mesh of an autonomous system. If the aggregate traffic flow
If the aggregate traffic flow defined by the unicast destination defined by the unicast destination prefix is forwarded to a given BGP
prefix is forwarded to a given BGP peer, then the local system can peer, then the local system can install more specific Flow
install more specific Flow Specifications that may result in different Specifications that may result in different forwarding behavior, as
forwarding behavior, as requested by this system. requested by this system.</t>
</t> <t>From an operational perspective, the utilization of BGP as the
<t> carrier for this information allows a network service provider to reuse
From an operational perspective, the utilization of BGP as the both internal route distribution infrastructure (e.g., route reflector
carrier for this information allows a network service provider to or confederation design) and existing external relationships (e.g.,
reuse both internal route distribution infrastructure (e.g., route inter-domain BGP sessions to a customer network).</t>
reflector or confederation design) and existing external <t>
relationships (e.g., inter-domain BGP sessions to a customer
network).
</t>
<t>
While it is certainly possible to address this problem using other While it is certainly possible to address this problem using other
mechanisms, this solution has been utilized in deployments because of the mechanisms, this solution has been utilized in deployments because of the
substantial advantage of being an incremental addition to already substantial advantage of being an incremental addition to already
deployed mechanisms. deployed mechanisms.
</t> </t>
<t>In current deployments, the information distributed by this <t>
Possible applications of that extension are:
Automated inter-domain coordination of traffic filtering, such as what
is required in order to mitigate DoS and DDoS attacks
or traffic filtering in the context of a BGP/MPLS VPN service. Other
applications (e.g., centralized control of traffic in a
Software-Defined Networking (SDN) or Network Function Virtualization
(NFV) context) are also possible.
</t>
<t>In current deployments, the information distributed by this
extension is originated both manually as well as automatically, the extension is originated both manually as well as automatically, the
latter by systems that are able to detect malicious traffic flows. latter by systems that are able to detect malicious traffic flows.
When automated systems are used, care should be taken When automated systems are used, care should be taken
to ensure the correctness of the automated system. The to ensure the correctness of the automated system. The
the limitations of the receiving systems that need to process limitations of the receiving systems that need to process
these automated Flow Specifications need to be taken in consideration these automated Flow Specifications need to be taken in consideration
as well (see also <xref target="security_considerations" />). as well (see also <xref target="security_considerations" format="default"/>).
</t> </t>
<t> <t>
This specification defines required protocol extensions to address This specification defines required protocol extensions to address
most common applications of IPv4 unicast and VPNv4 unicast filtering. most common applications of IPv4 unicast and VPNv4 unicast filtering.
The same mechanism can be reused and new match criteria added to The same mechanism can be reused and new match criteria added to
address similar filtering needs for other BGP address families such as address similar filtering needs for other BGP address families, such as
IPv6 families <xref target="I-D.ietf-idr-flow-spec-v6"></xref>. IPv6 families <xref target="RFC8956" format="default"/>.
</t> </t>
</section> </section>
<section title="Definitions of Terms Used in This Memo"> <section numbered="true" toc="default">
<t> <name>Definitions of Terms Used in This Memo</name>
<list style="hanging"> <dl newline="false" spacing="normal" indent="10">
<t hangText="AFI - ">Address Family Identifier.</t> <dt>AFI:</dt>
<t hangText="AS - ">Autonomous System.</t> <dd>Address Family Identifier</dd>
<t hangText="Loc-RIB - "> <dt>AS:</dt>
The Loc-RIB contains the routes that have been selected by the <dd>Autonomous System</dd>
local BGP speaker's Decision Process <xref target="RFC4271"></xref>. <dt>Loc-RIB:</dt>
</t> <dd>The Loc-RIB contains the routes that have been selected by the
<t hangText="NLRI - ">Network Layer Reachability Information.</t> local BGP speaker's Decision Process <xref target="RFC4271"
<t hangText="PE - ">Provider Edge router.</t> format="default"/>.</dd>
<t hangText="RIB - ">Routing Information Base.</t> <dt>NLRI:</dt>
<t hangText="SAFI - ">Subsequent Address Family Identifier.</t> <dd>Network Layer Reachability Information</dd>
<t hangText="VRF - ">Virtual Routing and Forwarding instance.</t> <dt>PE:</dt>
</list> <dd>Provider Edge router</dd>
</t> <dt>RIB:</dt>
<t> <dd>Routing Information Base</dd>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <dt>SAFI:</dt>
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", <dd>Subsequent Address Family Identifier</dd>
"MAY", and "OPTIONAL" in this document are to be interpreted as <dt>VRF:</dt>
described in BCP 14 <xref target="RFC2119"></xref> <xref target="RFC8174"></ <dd>Virtual Routing and Forwarding</dd>
xref> </dl>
when, and only when, they appear in all capitals, as shown here. <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
</t> "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
</section> NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
<section title="Flow Specifications"> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
<t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
A Flow Specification is an n-tuple consisting of several matching are to be interpreted as described in BCP&nbsp;14 <xref
criteria that can be applied to IP traffic. A given IP packet is target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
said to match the defined Flow Specification if it matches all the specif appear in all capitals, as shown here.</t>
ied </section>
criteria. This n-tuple is encoded into a BGP NLRI defined below. <section numbered="true" toc="default">
</t> <name>Flow Specifications</name>
<t> <t>A Flow Specification is an n-tuple consisting of several matching
criteria that can be applied to IP traffic. A given IP packet is said
</t> to match the defined Flow Specification if it matches all the specified
<t>A given Flow Specification may be associated with a set of attributes, criteria. This n-tuple is encoded into a BGP NLRI defined below.</t>
depending on <t>A given Flow Specification may be associated with a set of
the particular application; such attributes may or may not include attributes, depending on the particular application; such attributes may
reachability information (i.e., NEXT_HOP). Well-known or AS-specific or may not include reachability information (i.e., NEXT_HOP).
community attributes can be used to encode a set of predetermined Well-known or AS-specific community attributes can be used to encode a
actions. set of predetermined actions.</t>
</t> <t>A particular application is identified by a specific (Address Family
<t> Identifier, Subsequent Address Family Identifier (AFI, SAFI)) pair <xref
A particular application is identified by a specific (Address Family target="RFC4760" format="default"/> and corresponds to a distinct set of
Identifier, Subsequent Address Family Identifier (AFI, SAFI)) pair <xref RIBs. Those RIBs should be treated independently from each other in
target="RFC4760"></xref> and corresponds to a distinct set of RIBs. Those order to assure noninterference between distinct applications.</t>
RIBs should be treated independently from each other in order to assure <t>BGP itself treats the NLRI as a key to an entry in its databases.
non-interference between distinct applications. Entries that are placed in the Loc-RIB are then associated with a given
</t> set of semantics, which is application dependent. This is consistent
<t> with existing BGP applications. For instance, IP unicast routing
BGP itself treats the NLRI as a key to an entry in its (AFI=1, SAFI=1) and IP multicast reverse-path information (AFI=1,
databases. Entries that are placed in the Loc-RIB are then SAFI=2) are handled by BGP without any particular semantics being
associated with a given set of semantics, which is application associated with them until installed in the Loc-RIB.</t>
dependent. This is consistent with existing BGP applications. For <t>
instance, IP unicast routing (AFI=1, SAFI=1) and IP multicast
reverse-path information (AFI=1, SAFI=2) are handled by BGP without
any particular semantics being associated with them until installed
in the Loc-RIB.
</t>
<t>
Standard BGP policy mechanisms, such as UPDATE filtering by NLRI Standard BGP policy mechanisms, such as UPDATE filtering by NLRI
prefix as well as community matching and must apply to prefix as well as community matching, must apply to
the Flow specification defined NLRI-type. the Flow specification defined NLRI-type.
Network operators can also control propagation of such Network operators can also control propagation of such
routing updates by enabling or disabling the exchange of a particular routing updates by enabling or disabling the exchange of a particular
(AFI, SAFI) pair on a given BGP peering session. (AFI, SAFI) pair on a given BGP peering session.
</t> </t>
</section> </section>
<section title="Dissemination of IPv4 Flow Specification Information" anc <section anchor="dissemination_ipv4_flowspec" numbered="true" toc="default">
hor="dissemination_ipv4_flowspec"> <name>Dissemination of IPv4 Flow Specification Information</name>
<t> <t>This document defines a Flow Specification NLRI type (<xref
This document defines a Flow Specification NLRI type (<xref target="fs_nl target="fs_nlri" format="default"/>) that may include several components,
ri" />) such as destination prefix, source prefix, protocol, ports, and others
that may include several components such as destination prefix, (see <xref target="nlri_value_encoding" format="default"/> below).</t>
source prefix, protocol, ports, and others (see <t>This NLRI information is encoded using MP_REACH_NLRI and
<xref target="nlri_value_encoding" /> below). MP_UNREACH_NLRI attributes, as defined in <xref target="RFC4760"
</t> format="default"/>. When advertising Flow Specifications, the Length of th
<t> e
This NLRI information is encoded using MP_REACH_NLRI and Next-Hop Network Address <bcp14>MUST</bcp14> be set to 0. The Network
MP_UNREACH_NLRI attributes as defined in <xref target="RFC4760"></xref>. Address of the Next-Hop field <bcp14>MUST</bcp14> be ignored.</t>
When advertising Flow Specifications, <t>The NLRI field of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as
the Length of Next Hop Network Address MUST be set to 0. The Network one or more 2-tuples of the form &lt;length, NLRI value&gt;. It consists
Address of Next Hop field MUST be ignored. of a 1- or 2-octet length field followed by a variable-length NLRI
</t> value. The length is expressed in octets.</t>
<t> <figure anchor="fs_nlri">
The NLRI field of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as <name>Flow Specification NLRI for IPv4</name>
one or more 2-tuples of the form &lt;length, NLRI value&gt;. It consists of <artwork name="" type="" align="left" alt=""><![CDATA[
a 1- or 2-octet length field followed by a variable-length NLRI
value. The length is expressed in octets.
</t>
<t>
<figure title="Flow Specification NLRI for IPv4" anchor="fs_nlri">
<artwork>
+-------------------------------+ +-------------------------------+
| length (0xnn or 0xfnnn) | | length (0xnn or 0xfnnn) |
+-------------------------------+ +-------------------------------+
| NLRI value (variable) | | NLRI value (variable) |
+-------------------------------+ +-------------------------------+
</artwork> ]]></artwork>
</figure> </figure>
</t> <t>Implementations wishing to exchange Flow Specification
<t> <bcp14>MUST</bcp14> use BGP's Capability Advertisement facility to
Implementations wishing to exchange Flow Specification MUST use exchange the Multiprotocol Extension Capability Code (Code 1), as defined
BGP's Capability Advertisement facility to exchange the Multiprotocol in <xref target="RFC4760" format="default"/>. The (AFI, SAFI) pair
Extension Capability Code (Code 1) as defined in <xref target="RFC4760"></xre carried in the Multiprotocol Extension Capability <bcp14>MUST</bcp14> be
f>. (AFI=1, SAFI=133) for IPv4 Flow Specification and (AFI=1, SAFI=134) for
The (AFI, SAFI) pair carried in the Multiprotocol Extension VPNv4 Flow Specification.</t>
Capability MUST be (AFI=1, SAFI=133) for IPv4 Flow Specification, and <section numbered="true" toc="default">
(AFI=1, SAFI=134) for VPNv4 Flow Specification. <name>Length Encoding</name>
</t>
<section title="Length Encoding">
<t>
<list style="symbols">
<t>If the NLRI length is smaller than 240 (0xf0 hex) octets, the length
field can be encoded as a single octet. </t>
<t>Otherwise, it is encoded as
an extended-length 2-octet value in which the most significant nibble
has the hex value 0xf.</t>
</list>
</t>
<t> <t>
In <xref target="fs_nlri" /> above, values less-than 240 are encoded usi The length field indicates the length in octets of the variable NLRI va
ng two hex lue:
digits (0xnn). Values above 239 are encoded using 3 hex digits
(0xfnnn). The highest value that can be represented with this
encoding is 4095. For example the length value of 239 is encoded as 0xef
(single octet)
while 240 is encoded as 0xf0f0 (2-octet).
</t> </t>
</section> <ul spacing="normal">
<section anchor="nlri_value_encoding" title="NLRI Value Encoding"> <li>If the NLRI length is smaller than 240 (0xf0 hex) octets, the
<t> length field can be encoded as a single octet. </li>
<li>Otherwise, it is encoded as an extended-length 2-octet value in
which the most significant nibble has the hex value 0xf.</li>
</ul>
<t>In <xref target="fs_nlri" format="default"/> above, values
less than 240 are encoded using two hex digits (0xnn). Values above
239 are encoded using 3 hex digits (0xfnnn). The highest value that
can be represented with this encoding is 4095. For example, the length
value of 239 is encoded as 0xef (single octet), while 240 is encoded as
0xf0f0 (2 octets).</t>
</section>
<section anchor="nlri_value_encoding" numbered="true" toc="default">
<name>NLRI Value Encoding</name>
<t>
The Flow Specification NLRI value consists of a list of optional The Flow Specification NLRI value consists of a list of optional
components and is encoded as follows: components and is encoded as follows:
</t> </t>
<t>Encoding: &lt;[component]+&gt;</t> <t>Encoding: &lt;[component]+&gt;</t>
<t> <t>A specific packet is considered to match the Flow Specification
A specific packet is considered to match the Flow when it matches the intersection (AND) of all the components present
Specification when it matches the intersection (AND) of all the in the Flow Specification.</t>
components present in the Flow Specification. <t>Components <bcp14>MUST</bcp14> follow strict type ordering by
</t> increasing numerical order. A given component type <bcp14>MAY</bcp14>
<t> (exactly once) be present in the Flow Specification. If present, it
Components MUST follow strict type ordering by increasing <bcp14>MUST</bcp14> precede any component of higher numeric type
numerical order. A given component type MAY (exactly once) be value.</t>
present in the Flow Specification. If present, it MUST precede any component <t>All combinations of components within a single Flow Specification
of are allowed. However, some combinations cannot match any packets
higher numeric type value. (e.g., "ICMP Type AND Port" will never match any packets) and thus
</t> <bcp14>SHOULD NOT</bcp14> be propagated by BGP.</t>
<t> <t>An NLRI value not encoded as specified here, including an NLRI that
All combinations of components within a single Flow Specification are all contains an unknown component type, is considered malformed
owed. However, and error handling according to <xref target="errorhandling"
some combinations cannot match any packets (e.g. "ICMP Type AND Port" wil format="default"/> is performed.</t>
l never <section anchor="operators" numbered="true" toc="default">
match any packets), and thus SHOULD NOT be propagated by BGP. <name>Operators</name>
</t> <t>Most of the components described below make use of comparison
<t> operators. Which of the two operators is used is defined by the
A NLRI value not encoded as specified here, including a NLRI that contai components in <xref target="flowspec_components"
ns an unknown format="default"/>. The operators are encoded as a single octet.</t>
component type, is considered malformed and error handling according to <section anchor="numeric_operator" numbered="true" toc="default">
<xref target="errorhandling" /> is performed. <name>Numeric Operator (numeric_op)</name>
</t> <t>This operator is encoded as shown in <xref
<section anchor="operators" title="Operators"> target="figure_numeric_operator" format="default"/>.</t>
<t> <figure anchor="figure_numeric_operator">
Most of the components described below make use of <name>Numeric Operator (numeric_op)</name>
comparison operators. Which of the two operators is used is defined <artwork name="" type="" align="left" alt=""><![CDATA[
by the components in <xref target="flowspec_components" />. The operators
are
encoded as a single octet.
</t>
<section anchor="numeric_operator" title="Numeric Operator (numeric_op)">
<t>This operator is encoded as shown in <xref target="figure_numeric_operator" /
>.
<figure title="Numeric Operator (numeric_op)" anchor="figure_numeric_operator">
<artwork>
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| e | a | len | 0 |lt |gt |eq | | e | a | len | 0 |lt |gt |eq |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
</artwork> ]]></artwork>
</figure> </figure>
<list style="hanging"> <dl newline="false" spacing="normal" indent="6">
<t hangText="e -">end-of-list bit: Set in the last {op, value} pair in the list. <dt>e (end-of-list bit):</dt>
</t> <dd>Set in the last {op, value} pair in the list</dd>
<t hangText="a -">AND bit: If unset, the result of the previous {op, value} pair <dt>a (AND bit):</dt>
is <dd>If unset, the result of the previous {op, value}
logically ORed with the current pair is logically ORed with the current one. If set, the
one. If set, the operation is a logical AND. In the first operator octet of a s operation is a logical AND. In the first operator octet of a
equence sequence, it <bcp14>MUST</bcp14> be encoded as unset and
it MUST be encoded as unset and MUST be treated as always unset on decoding. <bcp14>MUST</bcp14> be treated as always unset on decoding. The
The AND operator has higher priority than OR for AND operator has higher priority than OR for the purposes of
the purposes of evaluating logical expressions. evaluating logical expressions.</dd>
</t> <dt>len (length):</dt>
<t hangText="len -">length: The length of the value field for this operator give <dd>The length of the value field for this operator
n as (1 &lt;&lt; len). This given as (1 &lt;&lt; len). This encodes 1 (len=00), 2 (len=01),
encodes 1 (len=00), 2 (len=01), 4 (len=10), 8 (len=11) octets. 4 (len=10), and 8 (len=11) octets.</dd>
</t> <dt>0:</dt>
<t hangText="0 -">MUST be set to 0 on NLRI encoding, and MUST be ignored during <dd><bcp14>MUST</bcp14> be set to 0 on NLRI encoding and
decoding <bcp14>MUST</bcp14> be ignored during decoding</dd>
</t> <dt>lt:</dt>
<t hangText="lt -">less than comparison between data and value. <dd>less-than comparison between data and value</dd>
</t> <dt>gt:</dt>
<t hangText="gt -">greater than comparison between data and value. <dd>greater-than comparison between data and value</dd>
</t> <dt>eq:</dt>
<t hangText="eq -">equality between data and value. <dd>equality between data and value</dd>
</t> </dl>
</list> <t>The bits lt, gt, and eq can be combined to produce common
</t> relational operators, such as "less or equal", "greater or equal",
<t> and "not equal to", as shown in <xref
The bits lt, gt, and eq can be combined to produce common target="table_comparison_operator" format="default"/>.</t>
relational operators such as "less or equal", "greater or equal", <table anchor="table_comparison_operator" align="center">
and "not equal to" as shown in <xref target="table_comparison_operator" / <name>Comparison Operation Combinations</name>
>. <thead>
<tr>
<th align="center">lt</th>
<th align="center">gt</th>
<th align="center">eq</th>
<th align="left">Resulting operation</th>
</tr>
</thead>
<tbody>
<tr>
<td align="center">0</td>
<td align="center">0</td>
<td align="center">0</td>
<td align="left"> false (independent of the value)</td>
</tr>
<tr>
<td align="center">0</td>
<td align="center">0</td>
<td align="center">1</td>
<td align="left"> == (equal) </td>
</tr>
<tr>
<td align="center">0</td>
<td align="center">1</td>
<td align="center">0</td>
<td align="left"> &gt; (greater than) </td>
</tr>
<tr>
<td align="center">0</td>
<td align="center">1</td>
<td align="center">1</td>
<td align="left"> &gt;= (greater than or equal)</td>
</tr>
<tr>
<td align="center">1</td>
<td align="center">0</td>
<td align="center">0</td>
<td align="left"> &lt; (less than)</td>
</tr>
<tr>
<td align="center">1</td>
<td align="center">0</td>
<td align="center">1</td>
<td align="left"> &lt;= (less than or equal)</td>
</tr>
<tr>
<td align="center">1</td>
<td align="center">1</td>
<td align="center">0</td>
<td align="left"> != (not equal value)</td>
</tr>
<tr>
<td align="center">1</td>
<td align="center">1</td>
<td align="center">1</td>
<td align="left"> true (independent of the value)</td>
</tr>
</tbody>
</table>
</section>
<section anchor="bitmask_operator" numbered="true" toc="default">
<name>Bitmask Operator (bitmask_op)</name>
<t>This operator is encoded as shown in <xref target="figure_bitmask
_operator" format="default"/>.
</t> </t>
<texttable anchor="table_comparison_operator" title="Comparison operation co <figure anchor="figure_bitmask_operator">
mbinations"> <name>Bitmask Operator (bitmask_op)</name>
<ttcol align="center">lt</ttcol> <artwork name="" type="" align="left" alt=""><![CDATA[
<ttcol align="center">gt</ttcol>
<ttcol align="center">eq</ttcol>
<ttcol align="left">Resulting operation</ttcol>
<c>0</c><c>0</c><c>0</c><c> false (independent of the value)</c>
<c>0</c><c>0</c><c>1</c><c> == (equal) </c>
<c>0</c><c>1</c><c>0</c><c> &gt; (greater than) </c>
<c>0</c><c>1</c><c>1</c><c> &gt;= (greater than or equal)</c>
<c>1</c><c>0</c><c>0</c><c> &lt; (less than)</c>
<c>1</c><c>0</c><c>1</c><c> &lt;= (less than or equal)</c>
<c>1</c><c>1</c><c>0</c><c> != (not equal value)</c>
<c>1</c><c>1</c><c>1</c><c> true (independent of the value)</c>
</texttable>
</section>
<section anchor="bitmask_operator" title="Bitmask Operator (bitmask_op)">
<t>This operator is encoded as shown in <xref target="figure_bitmask_operator" /
>.
<figure title="Bitmask Operator (bitmask_op)" anchor="figure_bitmask_operator">
<artwork>
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| e | a | len | 0 | 0 |not| m | | e | a | len | 0 | 0 |not| m |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
</artwork> ]]></artwork>
</figure> </figure>
</t>
<t>
<list style="hanging">
<t hangText="e, a, len - Most significant nibble:">(end-of-list bit, AND
bit, and length field), as defined in the Numeric Operator format in <xref targ
et="numeric_operator" />.
</t>
<t hangText="not - NOT bit:"> If set, logical negation of operation.
</t>
<t hangText="m - Match bit:"> If set, this is a bitwise match operation
defined as "(data AND value) == value"; if unset, (data AND value) evaluates
to TRUE if any of the bits in the value mask are set in the data
</t>
<t hangText="0 - all 0 bits:"> MUST be set to 0 on NLRI encoding, and MUST be ig
nored during decoding
</t>
</list>
</t>
</section>
</section> <dl newline="false" spacing="normal" indent="6">
<section anchor="flowspec_components" title="Components"> <dt>e, a, len (end-of-list bit, AND bit, and
<t> length field):</dt>
<dd>Most significant nibble; defined in the Numeric Operator forma
t in
<xref target="numeric_operator" format="default"/>.</dd>
<dt>not (NOT bit):</dt>
<dd>If set, logical negation of operation.</dd>
<dt>m (Match bit):</dt>
<dd>If set, this is a bitwise match operation defined as "(data
AND value) == value"; if unset, (data AND value) evaluates to
TRUE if any of the bits in the value mask are set in the
data.</dd>
<dt>0 (all 0 bits):</dt>
<dd><bcp14>MUST</bcp14> be set to 0 on NLRI encoding and
<bcp14>MUST</bcp14> be ignored during decoding</dd>
</dl>
</section>
</section>
<section anchor="flowspec_components" numbered="true" toc="default">
<name>Components</name>
<t>
The encoding of each of the components begins with a type field The encoding of each of the components begins with a type field
(1 octet) followed by a variable length parameter. The following sections (1 octet) followed by a variable length parameter. The following sections
define component types and parameter encodings for the IPv4 IP layer and define component types and parameter encodings for the IPv4 IP layer and
transport layer headers. IPv6 NLRI component types are described transport layer headers. IPv6 NLRI component types are described
in <xref target="I-D.ietf-idr-flow-spec-v6"></xref>. in <xref target="RFC8956" format="default"/>.
</t> </t>
<section anchor="type_1" title="Type 1 - Destination Prefix" toc="include"> <section anchor="type_1" toc="include" numbered="true">
<t>Encoding: &lt;type (1 octet), length (1 octet), prefix (variable)> <name>Type 1 - Destination Prefix</name>
</t> <t>Encoding: &lt;type (1 octet), length (1 octet), prefix
<t>Defines the destination prefix to match. The length and prefix fields are (variable)&gt;</t>
encoded as in BGP UPDATE messages <xref target="RFC4271" /> <t>Defines the destination prefix to match. The length and prefix
</t> fields are encoded as in BGP UPDATE messages <xref
</section> target="RFC4271" format="default"/>.</t>
<section anchor="type_2" title="Type 2 - Source Prefix" toc="include"> </section>
<t>Encoding: &lt;type (1 octet), length (1 octet), prefix (variable)&gt; <section anchor="type_2" toc="include" numbered="true">
</t> <name>Type 2 - Source Prefix</name>
<t>Defines the source prefix to match. The length and prefix fields are <t>Encoding: &lt;type (1 octet), length (1 octet), prefix (variable)
encoded as in BGP UPDATE messages <xref target="RFC4271" /> &gt;</t>
</t> <t>Defines the source prefix to match. The length and prefix
</section> fields are encoded as in BGP UPDATE messages <xref target="RFC4271"
<section anchor="type_3" title="Type 3 - IP Protocol" toc="include"> format="default"/>.</t>
<t>Encoding: &lt;type (1 octet), [numeric_op, value]+&gt; </section>
</t> <section anchor="type_3" toc="include" numbered="true">
<t>Contains a list of {numeric_op, value} pairs that are used to <name>Type 3 - IP Protocol</name>
match the IP protocol value octet in IP packet header (see <xref target="RFC0791 <t>Encoding: &lt;type (1 octet), [numeric_op, value]+&gt;</t>
" /> <t>Contains a list of {numeric_op, value} pairs that are used to
Section 3.1). match the IP protocol value octet in IP packet header (see <xref
</t> target="RFC0791" sectionFormat="of" section="3.1"/>).</t>
<t> <t>This component uses the Numeric Operator (numeric_op) described
This component uses the in <xref target="numeric_operator" format="default"/>. Type 3
Numeric Operator (numeric_op) described in <xref target="numeric_operator" / component values <bcp14>SHOULD</bcp14> be encoded as single octet
>. (numeric_op len=00).</t>
Type 3 component values SHOULD be encoded as single octet (numeric_op len=00 </section>
). <section anchor="type_4" toc="include" numbered="true">
</t> <name>Type 4 - Port</name>
</section> <t>Encoding: &lt;type (1 octet), [numeric_op, value]+&gt;</t>
<section anchor="type_4" title="Type 4 - Port" toc="include"> <t>Defines a list of {numeric_op, value} pairs that match source
<t>Encoding: &lt;type (1 octet), [numeric_op, value]+&gt; OR destination TCP/UDP ports (see <xref target="RFC0793"
</t> sectionFormat="of" section="3.1"/> and the "Format" section of
<t>Defines a list of {numeric_op, value} pairs that matches source <xref target="RFC0768" format="default"/>). This component matches
OR destination TCP/UDP ports (see <xref target="RFC0793" /> Section 3.1 and if
<xref target="RFC0768" /> Section "Format"). either the destination port OR the source port of an IP packet
This component matches if either the destination port OR the source port matches the value.</t>
of a IP packet matches the value. <t>This component uses the Numeric Operator (numeric_op) described
</t> in <xref target="numeric_operator" format="default"/>. Type 4
<t> component values <bcp14>SHOULD</bcp14> be encoded as 1- or 2-octet
This component uses the quantities (numeric_op len=00 or len=01).</t>
Numeric Operator (numeric_op) described in <xref target="numeric_operator" / <t>In case of the presence of the port (destination-port (<xref
>. target="type_5" format="default"/>), source-port (<xref
Type 4 component values SHOULD be encoded as 1- or 2-octet quantities (numer target="type_6" format="default"/>)) component, only TCP or UDP
ic_op len=00 or len=01). packets can match the entire Flow Specification. The port
</t> component, if present, never matches when the packet's IP protocol
<t> value is not 6 (TCP) or 17 (UDP), if the packet is fragmented and
In case of the presence of the port (destination-port <xref target="type_5" this is not the first fragment, or if the system is unable to
/>, locate the transport header. Different implementations may or may
source-port <xref target="type_6"/>) not be able to decode the transport header in the presence of IP
component only TCP or UDP packets can match the entire Flow Specification. options or Encapsulating Security Payload (ESP) NULL <xref
The port component, if present, never matches when the packet's IP target="RFC4303" format="default"/> encryption.</t>
protocol value is not 6 (TCP) or 17 (UDP), if the packet is fragmented </section>
and this is not the first fragment, or if the system is unable to <section anchor="type_5" toc="include" numbered="true">
locate the transport header. Different implementations may or may not be <name>Type 5 - Destination Port</name>
able to decode the transport header in the presence of IP <t>Encoding: &lt;type (1 octet), [numeric_op, value]+&gt;</t>
options or Encapsulating Security Payload (ESP) NULL <t> Defines a list of {numeric_op, value} pairs used to match the
<xref target="RFC4303"></xref> encryption. destination port of a TCP or UDP packet (see also <xref
</t> target="RFC0793" sectionFormat="of" section="3.1"/> and the
</section> "Format" section of <xref target="RFC0768" format="default"/>.</t>
<section anchor="type_5" title="Type 5 - Destination Port" toc="include"> <t>This component uses the Numeric Operator (numeric_op) described
<t>Encoding: &lt;type (1 octet), [numeric_op, value]+&gt; in <xref target="numeric_operator" format="default"/>. Type 5
</t> component values <bcp14>SHOULD</bcp14> be encoded as 1- or 2-octet
<t> Defines a list of {numeric_op, value} pairs used to match the quantities (numeric_op len=00 or len=01).</t>
destination port of a TCP or UDP packet (see also <xref target="RFC0793" /> <t>The last paragraph of <xref target="type_4" format="default"/>
Section 3.1 and also applies to this component.</t>
<xref target="RFC0768" /> Section "Format"). </section>
</t> <section anchor="type_6" toc="include" numbered="true">
<t> <name>Type 6 - Source Port</name>
This component uses the Numeric Operator (numeric_op) described in <xref tar <t>Encoding: &lt;type (1 octet), [numeric_op, value]+&gt;</t>
get="numeric_operator" />. <t>Defines a list of {numeric_op, value} pairs used to match the
Type 5 component values SHOULD be encoded as 1- or 2-octet quantities (numer source port of a TCP or UDP packet (see also <xref
ic_op len=00 or len=01). target="RFC0793" sectionFormat="of" section="3.1"/> and the
</t> "Format" section of <xref target="RFC0768" format="default"/>.</t>
<t>The last paragraph of <xref target="type_4" /> also applies to this component <t>This component uses the Numeric Operator (numeric_op) described
.</t> in <xref target="numeric_operator" format="default"/>. Type 6
</section> component values <bcp14>SHOULD</bcp14> be encoded as 1- or 2-octet
<section anchor="type_6" title="Type 6 - Source Port" toc="include"> quantities (numeric_op len=00 or len=01).</t>
<t>Encoding: &lt;type (1 octet), [numeric_op, value]+&gt; <t>The last paragraph of <xref target="type_4" format="default"/>
</t> also applies to this component.</t>
<t> Defines a list of {numeric_op, value} pairs used to match the </section>
source port of a TCP or UDP packet (see also <xref target="RFC0793" /> Secti <section anchor="type_7" toc="include" numbered="true">
on 3.1 and <name>Type 7 - ICMP Type</name>
<xref target="RFC0768" /> Section "Format"). <t>Encoding: &lt;type (1 octet), [numeric_op, value]+&gt;</t>
</t> <t>Defines a list of {numeric_op, value} pairs used to match the
<t> type field of an ICMP packet (see also the "Message Formats"
This component uses the Numeric Operator (numeric_op) described in <xref tar section of <xref target="RFC0792" format="default"/>).</t>
get="numeric_operator" />. <t>This component uses the Numeric Operator (numeric_op) described
Type 6 component values SHOULD be encoded as 1- or 2-octet quantities (numer in <xref target="numeric_operator" format="default"/>. Type 7
ic_op len=00 or len=01). component values <bcp14>SHOULD</bcp14> be encoded as single octet
</t> (numeric_op len=00).</t>
<t>The last paragraph of <xref target="type_4" /> also applies to this component <t>
.</t>
</section>
<section anchor="type_7" title="Type 7 - ICMP type" toc="include">
<t>Encoding: &lt;type (1 octet), [numeric_op, value]+&gt;
</t>
<t>Defines a list of {numeric_op, value} pairs used to match the
type field of an ICMP packet (see also <xref target="RFC0792" /> Section "Messag
e Formats").
</t>
<t>
This component uses the
Numeric Operator (numeric_op) described in <xref target="numeric_operator" /
>.
Type 7 component values SHOULD be encoded as single octet (numeric_op len=00
).
</t>
<t>
In case of the presence of the ICMP type In case of the presence of the ICMP type
component only ICMP packets can match the entire Flow Specification. component, only ICMP packets can match the entire Flow Specification.
The ICMP type component, if present, never matches when the packet's IP The ICMP type component, if present, never matches when the packet's IP
protocol value is not 1 (ICMP), if the packet is fragmented protocol value is not 1 (ICMP), if the packet is fragmented
and this is not the first fragment, or if the system is unable to and this is not the first fragment, or if the system is unable to
locate the transport header. Different implementations may or may not be locate the transport header. Different implementations may or may not be
able to decode the transport header in the presence of IP able to decode the transport header in the presence of IP
options or Encapsulating Security Payload (ESP) NULL options or Encapsulating Security Payload (ESP) NULL
<xref target="RFC4303"></xref> encryption. <xref target="RFC4303" format="default"/> encryption.
</t>
</section>
<section anchor="type_8" title="Type 8 - ICMP code" toc="include">
<t>Encoding: &lt;type (1 octet), [numeric_op, value]+&gt;
</t>
<t>
Defines a list of {numeric_op, value} pairs used to match the
code field of an ICMP packet (see also <xref target="RFC0792" /> Section "Messag
e Formats").
</t>
<t>
This component uses the
Numeric Operator (numeric_op) described in <xref target="numeric_operator" /
>.
Type 8 component values SHOULD be encoded as single octet (numeric_op len=00
).
</t> </t>
<t> </section>
<section anchor="type_8" toc="include" numbered="true">
<name>Type 8 - ICMP Code</name>
<t>Encoding: &lt;type (1 octet), [numeric_op, value]+&gt;</t>
<t>Defines a list of {numeric_op, value} pairs used to match the
code field of an ICMP packet (see also the "Message Formats"
section of <xref target="RFC0792" format="default"/>).</t>
<t>This component uses the Numeric Operator (numeric_op) described
in <xref target="numeric_operator" format="default"/>. Type 8
component values <bcp14>SHOULD</bcp14> be encoded as single octet
(numeric_op len=00).</t>
<t>
In case of the presence of the ICMP code In case of the presence of the ICMP code
component only ICMP packets can match the entire Flow Specification. component, only ICMP packets can match the entire Flow Specification.
The ICMP code component, if present, never matches when the packet's IP The ICMP code component, if present, never matches when the packet's IP
protocol value is not 1 (ICMP), if the packet is fragmented protocol value is not 1 (ICMP), if the packet is fragmented
and this is not the first fragment, or if the system is unable to and this is not the first fragment, or if the system is unable to
locate the transport header. Different implementations may or may not be locate the transport header. Different implementations may or may not be
able to decode the transport header in the presence of IP able to decode the transport header in the presence of IP
options or Encapsulating Security Payload (ESP) NULL options or Encapsulating Security Payload (ESP) NULL
<xref target="RFC4303"></xref> encryption. <xref target="RFC4303" format="default"/> encryption.
</t>
</section>
<section anchor="type_9" title="Type 9 - TCP flags" toc="include">
<t>Encoding: &lt;type (1 octet), [bitmask_op, bitmask]+&gt;
</t>
<t>
Defines a list of {bitmask_op, bitmask} pairs used to match TCP Control Bits
(see also <xref target="RFC0793"></xref> Section 3.1).
</t>
<t>
This component uses the
Bitmask Operator (bitmask_op) described in <xref target="bitmask_operator" /
>.
Type 9 component bitmasks MUST be encoded as 1- or 2-octet bitmask (bitmask_
op len=00 or len=01).
</t>
<t>When a single octet (bitmask_op len=00) is specified, it matches octet 14
of the TCP
header (see also <xref target="RFC0793"></xref> Section 3.1), which contains
the TCP Control Bits. When a 2-octet (bitmask_op len=01) encoding is used, it ma
tches octets
13 and 14 of the TCP header with the data offset (leftmost 4 bits) always
treated as 0.
</t> </t>
<t> </section>
<section anchor="type_9" toc="include" numbered="true">
<name>Type 9 - TCP Flags</name>
<t>Encoding: &lt;type (1 octet), [bitmask_op, bitmask]+&gt;</t>
<t>Defines a list of {bitmask_op, bitmask} pairs used to match TCP
control bits (see also <xref target="RFC0793" sectionFormat="of"
section="3.1"/>).</t>
<t>This component uses the Bitmask Operator (bitmask_op) described
in <xref target="bitmask_operator" format="default"/>. Type 9
component bitmasks <bcp14>MUST</bcp14> be encoded as 1- or 2-octet
bitmask (bitmask_op len=00 or len=01).</t>
<t>When a single octet (bitmask_op len=00) is specified, it
matches octet 14 of the TCP header (see also <xref
target="RFC0793" sectionFormat="of" section="3.1"/>), which
contains the TCP control bits. When a 2-octet (bitmask_op len=01)
encoding is used, it matches octets 13 and 14 of the TCP header
with the data offset (leftmost 4 bits) always treated as 0.</t>
<t>
In case of the presence of the TCP flags In case of the presence of the TCP flags
component only TCP packets can match the entire Flow Specification. component, only TCP packets can match the entire Flow Specification.
The TCP flags component, if present, never matches when the packet's IP The TCP flags component, if present, never matches when the packet's IP
protocol value is not 6 (TCP), if the packet is fragmented protocol value is not 6 (TCP), if the packet is fragmented
and this is not the first fragment, or if the system is unable to and this is not the first fragment, or if the system is unable to
locate the transport header. Different implementations may or may not be locate the transport header. Different implementations may or may not be
able to decode the transport header in the presence of IP able to decode the transport header in the presence of IP
options or Encapsulating Security Payload (ESP) NULL options or Encapsulating Security Payload (ESP) NULL
<xref target="RFC4303"></xref> encryption. <xref target="RFC4303" format="default"/> encryption.
</t>
</section>
<section anchor="type_10" title="Type 10 - Packet length" toc="include">
<t>Encoding: &lt;type (1 octet), [numeric_op, value]+&gt;
</t>
<t>
Defines a list of {numeric_op, value} pairs used to match on the total
IP packet length (excluding Layer 2 but including IP header).
</t>
<t>
This component uses the Numeric Operator (numeric_op) described in <xref tar
get="numeric_operator" />.
Type 10 component values SHOULD be encoded as 1- or 2-octet quantities (nume
ric_op len=00 or len=01).
</t>
</section>
<section anchor="type_11" title="Type 11 - DSCP (Diffserv Code Point)" toc="incl
ude">
<t>Encoding: &lt;type (1 octet), [numeric_op, value]+&gt;
</t>
<t> Defines a list of {numeric_op, value} pairs used to match the
6-bit DSCP field (see also <xref target="RFC2474"></xref>).
</t>
<t>
This component uses the
Numeric Operator (numeric_op) described in <xref target="numeric_operator" /
>.
Type 11 component values MUST be encoded as single octet (numeric_op len=00)
.
</t>
<t>
The six least significant bits contain the DSCP value. All other bits SHOULD
be
treated as 0.
</t>
</section>
<section anchor="type_12" title="Type 12 - Fragment" toc="include">
<t>Encoding: &lt;type (1 octet), [bitmask_op, bitmask]+&gt;
</t>
<t> Defines a list of {bitmask_op, bitmask} pairs used to match specific IP frag
ments.
</t> </t>
<t> </section>
This component uses the <section anchor="type_10" toc="include" numbered="true">
Bitmask Operator (bitmask_op) described in <xref target="bitmask_operator" / <name>Type 10 - Packet Length</name>
>. <t>Encoding: &lt;type (1 octet), [numeric_op, value]+&gt;</t>
The Type 12 component bitmask MUST be encoded as single octet bitmask (bitma <t>Defines a list of {numeric_op, value} pairs used to match on
sk_op len=00). the total IP packet length (excluding Layer 2 but including IP
</t> header).</t>
<t> <t>This component uses the Numeric Operator (numeric_op) described
<figure title="Fragment Bitmask Operand" anchor="figure_fragment_bitmask_operand in <xref target="numeric_operator" format="default"/>. Type 10
"> component values <bcp14>SHOULD</bcp14> be encoded as 1- or 2-octet
<artwork> quantities (numeric_op len=00 or len=01).</t>
</section>
<section anchor="type_11" toc="include" numbered="true">
<name>Type 11 - DSCP (Diffserv Code Point)</name>
<t>Encoding: &lt;type (1 octet), [numeric_op, value]+&gt;</t>
<t> Defines a list of {numeric_op, value} pairs used to match the
6-bit DSCP field (see also <xref target="RFC2474"
format="default"/>).</t>
<t>This component uses the Numeric Operator (numeric_op) described
in <xref target="numeric_operator" format="default"/>. Type 11
component values <bcp14>MUST</bcp14> be encoded as single octet
(numeric_op len=00).</t>
<t>The six least significant bits contain the DSCP value. All
other bits <bcp14>SHOULD</bcp14> be treated as 0.</t>
</section>
<section anchor="type_12" toc="include" numbered="true">
<name>Type 12 - Fragment</name>
<t>Encoding: &lt;type (1 octet), [bitmask_op, bitmask]+&gt;</t>
<t> Defines a list of {bitmask_op, bitmask} pairs used to match
specific IP fragments.</t>
<t>This component uses the Bitmask Operator (bitmask_op) described
in <xref target="bitmask_operator" format="default"/>. The Type 12
component bitmask <bcp14>MUST</bcp14> be encoded as single octet
bitmask (bitmask_op len=00).</t>
<figure anchor="figure_fragment_bitmask_operand">
<name>Fragment Bitmask Operand</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 0 |LF |FF |IsF|DF | | 0 | 0 | 0 | 0 |LF |FF |IsF|DF |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
</artwork> ]]></artwork>
</figure> </figure>
</t> <t>Bitmask values:</t>
<t>Bitmask values: <dl newline="false" spacing="normal" indent="6">
<list style="hanging"> <dt>DF (Don't Fragment):</dt>
<t hangText="DF -">Don't fragment - match if <xref target="RFC0791" /> IP Header <dd>match if IP Header Flags Bit-1 (DF) <xref target="RFC0791"/> i
Flags Bit-1 (DF) is 1 s 1</dd>
</t> <dt>IsF (Is a fragment other than the first):</dt>
<t hangText="IsF -">Is a fragment other than the first - match if <xref target=" <dd>match if the <xref
RFC0791" /> IP Header Fragment Offset is not 0 target="RFC0791"/> IP Header Fragment Offset is not 0</dd>
</t> <dt>FF (First Fragment):</dt>
<t hangText="FF -">First fragment - match if <xref target="RFC0791" /> IP Header <dd>match if the <xref
Fragment Offset is 0 AND Flags Bit-2 (MF) is 1 target="RFC0791"/> IP Header Fragment
</t> Offset is 0 AND Flags
<t hangText="LF -">Last fragment - match if <xref target="RFC0791" /> IP Header Bit-2 (MF) is 1</dd>
Fragment Offset is not 0 AND Flags Bit-2 (MF) is 0 <dt>LF (Last Fragment):</dt>
</t> <dd>match if the <xref
<t hangText="0 -">MUST be set to 0 on NLRI encoding, and MUST be ignored during target="RFC0791"/> IP Header Fragment Offset
decoding is not 0 AND Flags
</t> Bit-2 (MF) is 0</dd>
</list> <dt>0:</dt>
</t> <dd><bcp14>MUST</bcp14> be set to 0 on NLRI encoding and
</section> <bcp14>MUST</bcp14> be ignored during decoding</dd>
</section> </dl>
</section> </section>
<section title="Examples of Encodings"> </section>
<section title="Example 1" toc="exclude"> </section>
<t> <section numbered="true" toc="default">
An example of a Flow Specification NLRI encoding for: "all packets to <name>Examples of Encodings</name>
192.0.2.0/24 and TCP port 25". <section toc="exclude" numbered="true">
</t> <name>Example 1</name>
<t> <t>An example of a Flow Specification NLRI encoding for: "all
<figure> packets to 192.0.2.0/24 and TCP port 25".</t>
<artwork> <table anchor="ex-1" align="center">
+--------+----------------+----------+----------+ <thead>
| length | destination | protocol | port | <tr>
+--------+----------------+----------+----------+ <th>length</th>
| 0x0b | 01 18 c0 00 02 | 03 81 06 | 04 81 19 | <th>destination</th>
+--------+----------------+----------+----------+ <th>protocol</th>
</artwork> <th>port</th>
</figure> </tr>
</t> </thead>
<t> <tbody>
Decoded: <tr>
<figure> <td>0x0b</td>
<artwork> <td>01 18 c0 00 02</td>
+-------+------------+-------------------------------+ <td>03 81 06</td>
| Value | | | <td>04 81 19</td>
+-------+------------+-------------------------------+ </tr>
| 0x0b | length | 11 octets (len&lt;240 1-octet) | </tbody>
| 0x01 | type | Type 1 - Destination Prefix | </table>
| 0x18 | length | 24 bit | <t>Decoded:</t>
| 0xc0 | prefix | 192 | <table anchor="ex-1-decoded" align="center">
| 0x00 | prefix | 0 | <thead>
| 0x02 | prefix | 2 | <tr>
| 0x03 | type | Type 3 - IP Protocol | <th>Value</th>
| 0x81 | numeric_op | end-of-list, value size=1, == | <th rowspan="1" colspan="2"></th>
| 0x06 | value | 6 (TCP) | </tr>
| 0x04 | type | Type 4 - Port | </thead>
| 0x81 | numeric_op | end-of-list, value size=1, == | <tbody>
| 0x19 | value | 25 | <tr>
+-------+------------+-------------------------------+ <td>0x0b</td>
</artwork> <td>length</td>
</figure> <td> 11 octets (if len&lt;240, 1 octet)</td>
This constitutes a NLRI with a NLRI length of 11 octets. </tr>
</t> <tr>
</section> <td>0x01</td>
<section title="Example 2" toc="exclude"> <td>type</td>
<t> <td>Type 1 - Destination Prefix</td>
An example of a Flow Specification NLRI encoding for: "all packets to </tr>
192.0.2.0/24 from 203.0.113.0/24 and port {range [137, 139] or 8080}". <tr>
<figure> <td>0x18</td>
<artwork> <td>length</td>
+--------+----------------+----------------+-------------------------+ <td>24 bit</td>
| length | destination | source | port | </tr>
+--------+----------------+----------------+-------------------------+ <tr>
| 0x12 | 01 18 c0 00 02 | 02 18 cb 00 71 | 04 03 89 45 8b 91 1f 90 | <td>0xc0</td>
+--------+----------------+----------------+-------------------------+ <td>prefix</td>
</artwork> <td>192</td>
</figure> </tr>
</t> <tr>
<t> <td>0x00</td>
Decoded: <td>prefix</td>
<figure> <td>0</td>
<artwork> </tr>
+--------+------------+-------------------------------+ <tr>
| Value | | | <td>0x02</td>
+--------+------------+-------------------------------+ <td>prefix</td>
| 0x12 | length | 18 octets (len&lt;240 1-octet) | <td>2</td>
| 0x01 | type | Type 1 - Destination Prefix | </tr>
| 0x18 | length | 24 bit | <tr>
| 0xc0 | prefix | 192 | <td>0x03</td>
| 0x00 | prefix | 0 | <td>type</td>
| 0x02 | prefix | 2 | <td>Type 3 - IP Protocol</td>
| 0x02 | type | Type 2 - Source Prefix | </tr>
| 0x18 | length | 24 bit | <tr>
| 0xcb | prefix | 203 | <td>0x81</td>
| 0x00 | prefix | 0 | <td>numeric_op</td>
| 0x71 | prefix | 113 | <td>end-of-list, value size=1, ==</td>
| 0x04 | type | Type 4 - Port | </tr>
| 0x03 | numeric_op | value size=1, &gt;= | <tr>
| 0x89 | value | 137 | <td>0x06</td>
| 0x45 | numeric_op | "AND", value size=1, &lt;= | <td>value</td>
| 0x8b | value | 139 | <td>6 (TCP)</td>
| 0x91 | numeric_op | end-of-list, value size=2, == | </tr>
| 0x1f90 | value | 8080 | <tr>
+--------+------------+-------------------------------+ <td>0x04</td>
</artwork> <td>type</td>
</figure> <td>Type 4 - Port</td>
This constitutes a NLRI with a NLRI length of 18 octets. </tr>
</t> <tr>
</section> <td>0x81</td>
<section title="Example 3" toc="exclude"> <td>numeric_op</td>
<t> <td>end-of-list, value size=1, ==</td>
An example of a Flow Specification NLRI encoding for: "all packets to </tr>
192.0.2.1/32 and fragment { DF or FF } (matching packet with DF bit set or Fi <tr>
rst Fragments) <td>0x19</td>
<figure> <td>value</td>
<artwork> <td>25</td>
+--------+-------------------+----------+ </tr>
| length | destination | fragment | </tbody>
+--------+-------------------+----------+ </table>
| 0x09 | 01 20 c0 00 02 01 | 0c 80 05 | <t>This constitutes an NLRI with an NLRI length of 11 octets.</t>
+--------+-------------------+----------+ </section>
</artwork> <section toc="exclude" numbered="true">
</figure> <name>Example 2</name>
</t> <t>An example of a Flow Specification NLRI encoding for: "all
<t> packets to 192.0.2.0/24 from 203.0.113.0/24 and port {range [137,
Decoded: 139] or 8080}".</t>
<figure> <table anchor="ex-2" align="center">
<artwork> <thead>
+-------+------------+------------------------------+ <tr>
| Value | | | <th>length</th>
+-------+------------+------------------------------+ <th>destination</th>
| 0x09 | length | 9 octets (len&lt;240 1-octet) | <th>source</th>
| 0x01 | type | Type 1 - Destination Prefix | <th>port</th>
| 0x20 | length | 32 bit | </tr>
| 0xc0 | prefix | 192 | </thead>
| 0x00 | prefix | 0 | <tbody>
| 0x02 | prefix | 2 | <tr>
| 0x01 | prefix | 1 | <td>0x12</td>
| 0x0c | type | Type 12 - Fragment | <td>01 18 c0 00 02</td>
| 0x80 | bitmask_op | end-of-list, value size=1 | <td>02 18 cb 00 71</td>
| 0x05 | bitmask | DF=1, FF=1 | <td>04 03 89 45 8b 91 1f 90</td>
+-------+------------+------------------------------+ </tr>
</artwork> </tbody>
</figure> </table>
This constitutes a NLRI with a NLRI length of 9 octets. <t>Decoded:</t>
</t> <table anchor="ex-2-decoded" align="center">
</section> <thead>
</section> <tr>
</section> <th>Value</th>
<section anchor="traffic_filtering" title="Traffic Filtering"> <th rowspan="1" colspan="2"></th>
<t> </tr>
Traffic filtering policies have been traditionally considered to be relativel </thead>
y <tbody>
static. Limitations of these static mechanisms caused this new dynamic mechani <tr>
sm to be <td>0x12</td>
designed for the three new applications of traffic filtering: <td>length</td>
<list style="symbols"> <td>18 octets (if len&lt;240, 1 octet)</td>
<t>Prevention of traffic-based, denial-of-service (DOS) attacks.</t> </tr>
<t>Traffic filtering in the context of BGP/MPLS VPN service.</t> <tr>
<t>Centralized traffic control for SDN/NFV networks.</t> <td>0x01</td>
</list> <td>type</td>
These applications require coordination among service providers and/or coordina <td>Type 1 - Destination Prefix</td>
tion </tr>
among the AS within a service provider. <tr>
</t> <td>0x18</td>
<t> <td>length</td>
The Flow Specification NLRI defined in <xref target="dissemination_ipv4_flowspec <td>24 bit</td>
" /> </tr>
conveys information about traffic <tr>
filtering rules for traffic that should be discarded or handled in a manner <td>0xc0</td>
specified by a set of pre-defined actions (which are defined in BGP Extended <td>prefix</td>
Communities). This mechanism is primarily designed to allow an upstream <td>192</td>
autonomous system to perform inbound filtering in their ingress routers of </tr>
traffic that a given downstream AS wishes to drop. <tr>
</t> <td>0x00</td>
<t> <td>prefix</td>
In order to achieve this goal, this document specifies two application-specif <td>0</td>
ic </tr>
NLRI identifiers that provide traffic filters, and a set of actions encoding <tr>
in BGP Extended Communities. The two application-specific NLRI identifiers <td>0x02</td>
are: <td>prefix</td>
<list style="symbols"> <td>2</td>
<t> </tr>
IPv4 Flow Specification identifier (AFI=1, SAFI=133) along with specific <tr>
semantic rules for IPv4 routes, and <td>0x02</td>
</t> <td>type</td>
<t> <td>Type 2 - Source Prefix</td>
VPNv4 Flow Specification identifier (AFI=1, SAFI=134) </tr>
value, which can be used to propagate traffic filtering information <tr>
in a BGP/MPLS VPN environment. <td>0x18</td>
</t> <td>length</td>
</list> <td> 24 bit</td>
</t> </tr>
<t> <tr>
Encoding of the NLRI is described in <xref target="dissemination_ipv4_flo <td>0xcb</td>
wspec" /> for IPv4 Flow Specification and in <td>prefix</td>
<xref target="traffic_filtering_vpn" /> for VPNv4 Flow Specification. The <td>203</td>
filtering actions are described </tr>
in <xref target="traffic_filtering_actions" />. <tr>
</t> <td>0x00</td>
<section title="Ordering of Flow Specifications" anchor="ordering_of_flow_spec"> <td>prefix</td>
<t> <td>0</td>
More than one Flow Specification may match a </tr>
particular traffic flow. Thus, it is necessary to define the order <tr>
in which Flow Specifications get matched and actions being applied to a <td>0x71</td>
particular traffic flow. <td>prefix</td>
This ordering function is such that it does not depend on the arrival order <td>113</td>
of the Flow Specification via BGP and thus is consistent in the network. </tr>
</t> <tr>
<t> <td>0x04</td>
The relative order of two Flow Specifications is determined by <td>type</td>
comparing their respective components. The algorithm starts by <td>Type 4 - Port</td>
comparing the left-most components (lowest component type value) of the </tr>
Flow Specifications. If the types <tr>
differ, the Flow Specification with lowest numeric type value has higher prec <td>0x03</td>
edence <td>numeric_op</td>
(and thus will match before) than the Flow Specification that doesn't contain <td>value size=1, &gt;=</td>
that </tr>
component type. If the component types are the same, then a type- <tr>
specific comparison is performed (see below). If the types are equal the <td>0x89</td>
algorithm continues with the next component. <td>value</td>
</t> <td>137</td>
<t> </tr>
For IP prefix values (IP destination or source prefix): If one of the <tr>
two prefixes to compare is a more specific prefix of the other, the more <td>0x45</td>
specific prefix has higher precedence. Otherwise the one with the <td>numeric_op</td>
lowest IP value has higher precedence. <td>"AND", value size=1, &lt;=</td>
</t> </tr>
<t> <tr>
For all other component types, unless otherwise specified, the comparison is <td>0x8b</td>
performed by comparing the component data as a binary string using the <td>value</td>
memcmp() function as defined by <xref target="ISO_IEC_9899" />. For strings w <td>139</td>
ith equal </tr>
lengths the lowest string (memcmp) has higher precedence. For strings of <tr>
different lengths, the common prefix is compared. If the common prefix is not <td>0x91</td>
equal the string with the lowest prefix has higher precedence. If the common <td>numeric_op</td>
prefix is equal, the longest string is considered to have higher precedence <td>end-of-list, value size=2, ==</td>
than the shorter one. </tr>
</t> <tr>
<td>0x1f90</td>
<t> <td>value</td>
The code in <xref target="flow_rule_cmp_src" /> shows a Python3 implementation <td>8080</td>
of the comparison algorithm. The full code was tested with Python 3.6.3 and ca </tr>
n be </tbody>
obtained at <eref target="https://github.com/stoffi92/rfc5575bis/tree/master/f </table>
lowspec-cmp">https://github.com/stoffi92/rfc5575bis/tree/master/flowspec-cmp</er <t>This constitutes an NLRI with an NLRI length of 18 octets.</t>
ef>. </section>
</t> <section toc="exclude" numbered="true">
</section> <name>Example 3</name>
</section> <t>An example of a Flow Specification NLRI encoding for: "all
<section title="Validation Procedure" anchor="validation_procedure"> packets to 192.0.2.1/32 and fragment { DF or FF } (matching packet
<t>Flow Specifications received from a BGP peer that are accepted in with DF bit set or First Fragments)</t>
the respective Adj-RIB-In are used as input to the route selection <table anchor="ex-3" align="center">
process. Although the forwarding attributes of two routes for the <thead>
same Flow Specification prefix may be the same, BGP is still required <tr>
to perform its path selection algorithm in order to select the <th>length</th>
correct set of attributes to advertise. <th>destination</th>
</t> <th>fragment</th>
<t> </tr>
The first step of the BGP Route Selection procedure (Section 9.1.2 of </thead>
<xref target="RFC4271"></xref> is to exclude from the <tbody>
selection procedure routes that are <tr>
considered non-feasible. In the context of IP routing information, <td>0x09</td>
this step is used to validate that the NEXT_HOP attribute of a given <td>01 20 c0 00 02 01</td>
route is resolvable. <td>0c 80 05</td>
</t> </tr>
<t> </tbody>
</table>
<t>Decoded:</t>
<table>
<thead>
<tr>
<th>Value</th>
<th rowspan="1" colspan="2"></th>
</tr>
</thead>
<tbody>
<tr>
<td>0x09</td>
<td>length</td>
<td>9 octets (if len&lt;240, 1 octet)</td>
</tr>
<tr>
<td>0x01</td>
<td>type</td>
<td>Type 1 - Destination Prefix</td>
</tr>
<tr>
<td>0x20</td>
<td>length</td>
<td> 32 bit</td>
</tr>
<tr>
<td>0xc0</td>
<td>prefix</td>
<td>192</td>
</tr>
<tr>
<td>0x00</td>
<td>prefix</td>
<td>0</td>
</tr>
<tr>
<td>0x02</td>
<td>prefix</td>
<td>2</td>
</tr>
<tr>
<td>0x01</td>
<td>prefix</td>
<td>1</td>
</tr>
<tr>
<td>0x0c</td>
<td>type</td>
<td>Type 12 - Fragment</td>
</tr>
<tr>
<td>0x80</td>
<td>bitmask_op</td>
<td>end-of-list, value size=1</td>
</tr>
<tr>
<td>0x05</td>
<td>bitmask</td>
<td>DF=1, FF=1</td>
</tr>
</tbody>
</table>
<t>This constitutes an NLRI with an NLRI length of 9 octets.</t>
</section>
</section>
</section>
<section anchor="traffic_filtering" numbered="true" toc="default">
<name>Traffic Filtering</name>
<t>Traffic filtering policies have been traditionally considered to be
relatively static. Limitations of these static mechanisms caused this
new dynamic mechanism to be designed for the three new applications of
traffic filtering:</t>
<ul spacing="normal">
<li>Prevention of traffic-based, denial-of-service (DoS) attacks</li>
<li>Traffic filtering in the context of BGP/MPLS VPN service</li>
<li>Centralized traffic control for SDN/NFV networks</li>
</ul>
<t>These applications require coordination among service providers
and/or coordination among the AS within a service provider.</t>
<t>The Flow Specification NLRI defined in <xref
target="dissemination_ipv4_flowspec" format="default"/> conveys
information about traffic filtering rules for traffic that should be
discarded or handled in a manner specified by a set of predefined
actions (which are defined in BGP Extended Communities). This mechanism
is primarily designed to allow an upstream autonomous system to perform
inbound filtering in their ingress routers of traffic that a given
downstream AS wishes to drop.</t>
<t>In order to achieve this goal, this document specifies two
application-specific NLRI identifiers that provide traffic filters and
a set of actions encoding in BGP Extended Communities. The two
application-specific NLRI identifiers are:</t>
<ul spacing="normal">
<li>IPv4 Flow Specification identifier (AFI=1, SAFI=133) along with
specific semantic rules for IPv4 routes and</li>
<li>VPNv4 Flow Specification identifier (AFI=1, SAFI=134) value, which
can be used to propagate traffic filtering information in a BGP/MPLS
VPN environment.</li>
</ul>
<t>
Encoding of the NLRI is described in <xref target="dissemination_ipv4_flo
wspec" format="default"/> for IPv4 Flow Specification and in
<xref target="traffic_filtering_vpn" format="default"/> for VPNv4 Flow Sp
ecification. The filtering actions are described
in <xref target="traffic_filtering_actions" format="default"/>.
</t>
<section anchor="ordering_of_flow_spec" numbered="true" toc="default">
<name>Ordering of Flow Specifications</name>
<t>More than one Flow Specification may match a particular traffic
flow. Thus, it is necessary to define the order in which Flow
Specifications get matched and actions being applied to a particular
traffic flow. This ordering function is such that it does not depend
on the arrival order of the Flow Specification via BGP and thus is
consistent in the network.</t>
<t>The relative order of two Flow Specifications is determined by
comparing their respective components. The algorithm starts by
comparing the left-most components (lowest component type value) of
the Flow Specifications. If the types differ, the Flow Specification
with lowest numeric type value has higher precedence (and thus will
match before) than the Flow Specification that doesn't contain that
component type. If the component types are the same, then a
type-specific comparison is performed (see below). If the types are
equal, the algorithm continues with the next component.</t>
<t>For IP prefix values (IP destination or source prefix), if one of
the two prefixes to compare is a more specific prefix of the other,
the more specific prefix has higher precedence. Otherwise, the one with
the lowest IP value has higher precedence.</t>
<t>For all other component types, unless otherwise specified, the
comparison is performed by comparing the component data as a binary
string using the memcmp() function as defined by <xref
target="ISO_IEC_9899" format="default"/>. For strings with equal
lengths, the lowest string (memcmp) has higher precedence. For strings
of different lengths, the common prefix is compared. If the common
prefix is not equal, the string with the lowest prefix has higher
precedence. If the common prefix is equal, the longest string is
considered to have higher precedence than the shorter one.</t>
<t>The code in <xref target="flow_rule_cmp_src" format="default"/>
shows a Python3 implementation of the comparison algorithm. The full
code was tested with Python 3.6.3 and can be obtained at <eref brackets="
angle"
target="https://github.com/stoffi92/rfc5575bis/tree/master/flowspec-cmp"/
>.</t>
</section>
</section>
<section anchor="validation_procedure" numbered="true" toc="default">
<name>Validation Procedure</name>
<t>Flow Specifications received from a BGP peer that are accepted in the
respective Adj-RIB-In are used as input to the route selection process.
Although the forwarding attributes of two routes for the same Flow
Specification prefix may be the same, BGP is still required to perform
its path selection algorithm in order to select the correct set of
attributes to advertise.</t>
<t>The first step of the BGP Route Selection procedure (<xref
target="RFC4271" sectionFormat="of" section="9.1.2"/>) is to exclude from
the selection procedure routes that are considered unfeasible.
In the
context of IP routing information, this step is used to validate that
the NEXT_HOP attribute of a given route is resolvable.</t>
<t>
The concept can be extended, in the case of the Flow Specification NLRI, The concept can be extended, in the case of the Flow Specification NLRI,
to allow other validation procedures. to allow other validation procedures.
</t> </t>
<t> <t>
The validation process described below validates Flow Specifications against The validation process described below validates Flow Specifications against
unicast routes received over the same AFI but the associated unicast routing unicast routes received over the same AFI but the associated unicast routing
information SAFI: information SAFI:
<list>
<t>Flow Specification received over SAFI=133 will be validated
against routes received over SAFI=1
</t>
<t>Flow Specification received over SAFI=134 will be validated
against routes received over SAFI=128
</t>
</list>
</t> </t>
<t> <ul spacing="normal">
In the absence of explicit configuration a Flow Specification <li>Flow Specification received over SAFI=133 will be validated
NLRI MUST be validated such that it is considered feasible if against routes received over SAFI=1.</li>
and only if all of the conditions below are true: <li>Flow Specification received over SAFI=134 will be validated
<list> against routes received over SAFI=128.</li>
<t> </ul>
a) A destination prefix component is embedded in the Flow Specification. <t>In the absence of explicit configuration, a Flow Specification NLRI
</t> <bcp14>MUST</bcp14> be validated such that it is considered feasible if
<t> and only if all of the conditions below are true:</t>
b) The originator of the Flow Specification matches the originator of
the best-match unicast route for the destination prefix embedded <ol spacing="normal" type="%c)">
in the Flow Specification (this is the unicast route with the longest <li>A destination prefix component is embedded in the Flow Specification
possible prefix length covering the destination prefix embedded in .</li>
the Flow Specification). <li>The originator of the Flow Specification matches the originator of
</t> the best-match unicast route for the destination prefix embedded in
<t> the Flow Specification (this is the unicast route with the longest
c) There are no "more-specific" unicast routes, when compared with the possible prefix length covering the destination prefix embedded in the
flow destination prefix, that have been received from a different Flow Specification).</li>
neighboring AS than the best-match unicast route, which has been <li>There are no "more-specific" unicast routes, when compared with
determined in rule b). the flow destination prefix, that have been received from a different
</t> neighboring AS than the best-match unicast route, which has been
</list> determined in rule b.</li>
</t> </ol>
<t>
However, rule a) MAY be relaxed by explicit configuration, permitting Flow <t>However, rule a <bcp14>MAY</bcp14> be relaxed by explicit
Specifications that include no destination prefix component. If such configuration, permitting Flow Specifications that include no
is the case, rules b) and c) are moot and MUST be disregarded. destination prefix component. If such is the case, rules b and c are
</t> moot and <bcp14>MUST</bcp14> be disregarded.</t>
<t> <t>By "originator" of a BGP route, we mean either the address of the
By "originator" of a BGP route, we mean either the address of the originator in the ORIGINATOR_ID Attribute <xref target="RFC4456"
originator in the ORIGINATOR_ID Attribute <xref target="RFC4456" />, format="default"/> or the source IP address of the BGP peer, if this
or the source IP address of the BGP peer, if this path attribute is path attribute is not present.</t>
not present. <t>BGP implementations <bcp14>MUST</bcp14> also enforce that the AS_PATH
</t> attribute of a route received via the External Border Gateway Protocol
<t> (eBGP) contains the neighboring AS in the left-most position of the
BGP implementations MUST also enforce that the AS_PATH attribute of a AS_PATH attribute. While this rule is optional in the BGP
route received via the External Border Gateway Protocol (eBGP) specification, it becomes necessary to enforce it here for security
contains the neighboring AS in the left-most position of the AS_PATH reasons.</t>
attribute. While this rule is optional in the BGP specification, it <t>The best-match unicast route may change over the time independently
becomes necessary to enforce it here for security reasons. of the Flow Specification NLRI. Therefore, a revalidation of the Flow
</t> Specification NLRI <bcp14>MUST</bcp14> be performed whenever unicast
<t> routes change. Revalidation is defined as retesting rules a to c as
The best-match unicast route may change over the time independently of the described above.</t>
Flow Specification NLRI. Therefore, a revalidation of the Flow Specification <t>Explanation:</t>
NLRI MUST be performed whenever unicast routes change. Revalidation is <t>The underlying concept is that the neighboring AS that advertises the
defined as retesting rules a) to c) as described above. best unicast route for a destination is allowed to advertise Flow
</t> Specification information that conveys a destination prefix that is more
<t>Explanation: or equally specific. Thus, as long as there are no "more-specific"
</t> unicast routes received from a different neighboring AS, which would be
<t> affected by that Flow Specification, the Flow Specification is validated
The underlying concept is that the neighboring AS that advertises the successfully.</t>
best unicast route for a destination is allowed to advertise Flow <t>The neighboring AS is the immediate destination of the traffic
Specification information that conveys a destination prefix that is described by the Flow Specification. If it requests these flows to be
more or equally specific. dropped, that request can be honored without concern that it represents
Thus, as long as there are no "more-specific" unicast routes, a denial of service in itself. The reasoning is that this is as if the
received from a different neighboring AS, which would be affected by traffic is being dropped by the downstream autonomous system, and there
that Flow Specification, the Flow Specification is validated successfully. is no added value in carrying the traffic to it.</t>
</t> </section>
<t> <section anchor="traffic_filtering_actions" numbered="true" toc="default">
The neighboring AS is the immediate destination of the traffic <name>Traffic Filtering Actions</name>
described by the Flow Specification. If it requests these flows to <t>This document defines a minimum set of Traffic Filtering Actions that
be dropped, that request can be honored without concern that it it standardizes as BGP Extended Communities <xref target="RFC4360"
represents a denial of service in itself. The reasoning is that this is as i format="default"/>. This is not meant to be an inclusive list of all the
f the traffic is possible actions but only a subset that can be interpreted consistently
being dropped by the downstream autonomous system, and there is no across the network. Additional actions can be defined as either
added value in carrying the traffic to it. requiring standards or as vendor specific.</t>
</t> <t>The default action for a matching Flow Specification is to accept the
</section> packet (treat the packet according to the normal forwarding behavior of
<section anchor="traffic_filtering_actions" title="Traffic Filtering Actions"> the system).</t>
<t> <t>This document defines the following Extended Communities values shown
This document defines a minimum set of Traffic Filtering Actions that it in <xref target="traffic_extended_communities" format="default"/> in the
standardizes as BGP extended communities <xref target="RFC4360"></xref>. form 0xttss, where tt indicates the type and ss indicates the sub-type
This is not meant to be an inclusive list of all the possible actions, but on of the Extended Community. Encodings for these Extended Communities are
ly a described below.</t>
subset that can be interpreted consistently across the network. <table anchor="traffic_extended_communities" align="center">
Additional actions can be defined as either requiring standards or <name>Traffic Filtering Action Extended Communities</name>
as vendor specific. <thead>
</t> <tr>
<t> <th align="left">community 0xttss</th>
The default action for a matching Flow Specification is to <th align="left">action</th>
accept the packet (treat the packet according to the normal forwarding <th align="left">encoding</th>
behaviour of the system). </tr>
</t> </thead>
<t>This document defines the following extended communities values <tbody>
shown in <xref target="traffic_extended_communities" /> in the form <tr>
0xttss where tt indicates the type and ss indicates the sub-type of the extende <td align="left">0x8006</td>
d community. <td align="left">traffic-rate-bytes (<xref
Encodings for these extended communities are described below. target="traffic_rate_in_bytes" format="default"/>)</td>
</t> <td align="left">2-octet AS, 4-octet float</td>
<texttable anchor="traffic_extended_communities" title="Traffic Filtering Act </tr>
ion <tr>
Extended Communities"> <td align="left">0x800c</td>
<ttcol align="left">community 0xttss</ttcol> <td align="left">traffic-rate-packets (<xref
<ttcol align="left">action</ttcol> target="traffic_rate_in_packets" format="default"/>)</td>
<ttcol align="left">encoding</ttcol> <td align="left">2-octet AS, 4-octet float</td>
<c>0x8006</c> <c>traffic-rate-bytes (<xref target="traffic_rate_in_bytes" </tr>
/>)</c> <c>2-octet AS, 4-octet float</c> <tr>
<c>TBD</c> <c>traffic-rate-packets (<xref target="traffic_rate_in_byte <td align="left">0x8007</td>
s" />)</c> <c>2-octet AS, 4-octet float</c> <td align="left">traffic-action (<xref
<c>0x8007</c> <c>traffic-action (<xref target="traffic_action_subtype" /> target="traffic_action_subtype" format="default"/>)</td>
)</c> <c>bitmask</c> <td align="left">bitmask</td>
<c>0x8008</c> <c>rt-redirect AS-2octet (<xref target="rt_redirect_action_ </tr>
subtype" />)</c> <c>2-octet AS, 4-octet value</c> <tr>
<c>0x8108</c> <c>rt-redirect IPv4 (<xref target="rt_redirect_action_subty <td align="left">0x8008</td>
pe" />)</c> <c>4-octet IPv4 address, 2-octet value</c> <td align="left">rt-redirect AS-2octet (<xref
<c>0x8208</c> <c>rt-redirect AS-4octet (<xref target="rt_redirect_action_ target="rt_redirect_action_subtype" format="default"/>)</td>
subtype" />)</c> <c>4-octet AS, 2-octet value</c> <td align="left">2-octet AS, 4-octet value</td>
<c>0x8009</c> <c>traffic-marking (<xref target="traffic_marking_subtype" </tr>
/>)</c> <c>DSCP value</c> <tr>
</texttable> <td align="left">0x8108</td>
<t> <td align="left">rt-redirect IPv4 (<xref
Multiple Traffic Filtering Actions defined in this document may be present f target="rt_redirect_action_subtype" format="default"/>)</td>
or a single <td align="left">4-octet IPv4 address, 2-octet value</td>
Flow Specification and SHOULD be applied to the traffic flow (for example tr </tr>
affic-rate-bytes and rt-redirect can be <tr>
applied to packets at the same time). If not all of the Traffic Filtering Ac <td align="left">0x8208</td>
tions can be applied to a traffic flow <td align="left">rt-redirect AS-4octet (<xref
they should be treated as interfering Traffic Filtering Actions (see below). target="rt_redirect_action_subtype" format="default"/>)</td>
</t> <td align="left">4-octet AS, 2-octet value</td>
<t> </tr>
Some Traffic Filtering Actions may interfere with each other or even contradict <tr>
. <td align="left">0x8009</td>
<xref target="rules_action_interference" /> of this document <td align="left">traffic-marking (<xref
provides general considerations on such Traffic Filtering Action interference. target="traffic_marking_subtype" format="default"/>)</td>
Any additional definition of Traffic Filtering Actions SHOULD specify <td align="left">DSCP value</td>
the action to take if those Traffic Filtering Actions interfere (also with exis </tr>
ting </tbody>
Traffic Filtering Actions). </table>
</t> <t>Multiple Traffic Filtering Actions defined in this document may be
<t> present for a single Flow Specification and <bcp14>SHOULD</bcp14> be
All Traffic Filtering Actions are specified as transitive BGP Extended applied to the traffic flow (for example, traffic-rate-bytes and
Communities. rt-redirect can be applied to packets at the same time). If not all of
</t> the Traffic Filtering Actions can be applied to a traffic flow, they
<section anchor="traffic_rate_in_bytes" title="Traffic Rate in Bytes (traffic-r should be treated as interfering Traffic Filtering Actions (see
ate-bytes) sub-type 0x06"> below).</t>
<t>The traffic-rate-bytes extended community uses the following <t>Some Traffic Filtering Actions may interfere with each other or even
extended community encoding: contradict. <xref target="rules_action_interference" format="default"/>
</t> of this document provides general considerations on such Traffic
<t> Filtering Action interference. Any additional definition of Traffic
Filtering Actions <bcp14>SHOULD</bcp14> specify the action to take if
those Traffic Filtering Actions interfere (also with existing Traffic
Filtering Actions).</t>
<t>All Traffic Filtering Actions are specified as transitive BGP
Extended Communities.</t>
<section anchor="traffic_rate_in_bytes" numbered="true" toc="default">
<name>Traffic Rate in Bytes (traffic-rate-bytes) Sub-Type 0x06</name>
<t>The traffic-rate-bytes Extended Community uses the following
Extended Community encoding:</t>
<t>
The first two octets carry the 2-octet id, which can be The first two octets carry the 2-octet id, which can be
assigned from a 2-octet AS number. When a 4-octet AS number is assigned from a 2-octet AS number. When a 4-octet AS number is
locally present, the 2 least significant octets of such an AS locally present, the 2 least significant octets of such an AS
number can be used. This value is purely informational and number can be used. This value is purely informational and
SHOULD NOT be interpreted by the implementation. <bcp14>SHOULD NOT</bcp14> be interpreted by the implementation.
</t>
<t>
The remaining 4 octets carry the maximum rate information in IEEE floating point
<xref target="IEEE.754.1985"></xref> format, units being bytes per second. A
traffic-rate of 0 should result on all traffic for the particular flow to be
discarded. On encoding the traffic-rate MUST NOT be negative. On
decoding negative values MUST be treated as zero (discard all traffic).
</t>
<t>Interferes with: May interfere with the traffic-rate-packets (see <xref targ
et="traffic_rate_in_packets" />).
A policy may allow both filtering by traffic-rate-packets and traffic-rate-byt
es.
If the policy does not allow this, these two actions will conflict.
</t>
</section>
<section anchor="traffic_rate_in_packets" title="Traffic Rate in Packets (traffi
c-rate-packets) sub-type TBD">
<t>
The traffic-rate-packets extended community uses the same encoding as the
traffic-rate-bytes extended community. The floating point value carries the
maximum packet rate in packets per second. A traffic-rate-packets of 0 should
result in all traffic for the particular flow to be discarded. On encoding the
traffic-rate-packets MUST NOT be negative. On decoding negative values MUST
be treated as zero (discard all traffic).
</t> </t>
<t>Interferes with: May interfere with the traffic-rate-bytes (see <xref target <t>The remaining 4 octets carry the maximum rate information in IEEE
="traffic_rate_in_bytes" />). floating point <xref target="IEEE.754.1985" format="default"/> format,
A policy may allow both filtering by traffic-rate-packets and traffic-rate-byt units being bytes per second. A traffic-rate of 0 should result on
es. all traffic for the particular flow to be discarded. On encoding, the
If the policy does not allow this, these two actions will conflict. traffic-rate <bcp14>MUST NOT</bcp14> be negative. On decoding, negative
</t> values <bcp14>MUST</bcp14> be treated as zero (discard all
</section> traffic).</t>
<section anchor="traffic_action_subtype" title="Traffic-action (traffic-action) <t>Interferes with: May interfere with the traffic-rate-packets (see
sub-type 0x07"> <xref target="traffic_rate_in_packets" format="default"/>). A policy
<t>The traffic-action extended community consists of 6 may allow both filtering by traffic-rate-packets and
traffic-rate-bytes. If the policy does not allow this, these two
actions will conflict.</t>
</section>
<section anchor="traffic_rate_in_packets" numbered="true" toc="default">
<name>Traffic Rate in Packets (traffic-rate-packets) Sub-Type 0x0c</name
>
<t>The traffic-rate-packets Extended Community uses the same encoding
as the traffic-rate-bytes Extended Community. The floating point value
carries the maximum packet rate in packets per second. A
traffic-rate-packets of 0 should result in all traffic for the
particular flow to be discarded. On encoding, the traffic-rate-packets
<bcp14>MUST NOT</bcp14> be negative. On decoding, negative values
<bcp14>MUST</bcp14> be treated as zero (discard all traffic).</t>
<t>Interferes with: May interfere with the traffic-rate-bytes (see
<xref target="traffic_rate_in_bytes" format="default"/>). A policy may
allow both filtering by traffic-rate-packets and
traffic-rate-bytes. If the policy does not allow this, these two
actions will conflict.</t>
</section>
<section anchor="traffic_action_subtype" numbered="true" toc="default">
<name>Traffic-Action (traffic-action) Sub-Type 0x07</name>
<t>The traffic-action Extended Community consists of 6
octets of which only the 2 least significant bits of the 6th octet octets of which only the 2 least significant bits of the 6th octet
(from left to right) are defined by this document as shown in (from left to right) are defined by this document, as shown in
<xref target="figure_traffic_action_encoding" />. <xref target="figure_traffic_action_encoding" format="default"/>.
</t> </t>
<t> <figure anchor="figure_traffic_action_encoding">
<figure title="Traffic-action Extended Community Encoding" anchor="figure_traffi <name>Traffic-Action Extended Community Encoding</name>
c_action_encoding"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork>
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Action Field | | Traffic Action Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tr. Action Field (cont.) |S|T| | Tr. Action Field (cont.) |S|T|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork> ]]></artwork>
</figure> </figure>
</t> <t>S and T are defined as:</t>
<t>where S and T are defined as: <dl newline="false" spacing="normal" indent="6">
<list style="symbols"> <dt>T</dt>
<t>T: Terminal Action (bit 47): When this bit is set, the traffic <dd>Terminal Action (bit 47): When this bit is set, the traffic
filtering engine will evaluate any subsequent Flow Specifications (as filtering engine will evaluate any subsequent Flow Specifications
defined by the ordering procedure <xref target="ordering_of_flow_spec" />). I (as defined by the ordering procedure <xref
f not set, the evaluation target="ordering_of_flow_spec" format="default"/>). If not set, the
of the traffic filters stops when this Flow Specification is evaluated. evaluation of the traffic filters stops when this Flow Specification
</t> is evaluated.</dd>
<t>S: Sample (bit 46): Enables traffic sampling and logging for this <dt>S</dt>
Flow Specification (only effective when set). <dd>Sample (bit 46): Enables traffic sampling and logging for this
</t> Flow Specification (only effective when set).</dd>
<t>Traffic Action Field: Other Traffic Action Field (see <dt>Traffic Action Field:</dt>
<xref target="IANA" />) bits unused in this <dd>Other Traffic Action Field (see <xref
specification. These bits MUST be set to 0 on encoding, and MUST be target="IANA" format="default"/>) bits unused in this
ignored during decoding. specification. These bits <bcp14>MUST</bcp14> be set to 0 on
</t> encoding and <bcp14>MUST</bcp14> be ignored during decoding.</dd>
</list> </dl>
</t> <t>The use of the Terminal Action (bit 47) may result in more than one
<t> Flow Specification matching a particular traffic flow. All the Traffic
The use of the Terminal Action (bit 47) may result in more than one Filtering Actions from these Flow Specifications shall be collected
Flow Specification matching a particular traffic flow. All the and applied. In case of interfering Traffic Filtering Actions, it is an
Traffic Filtering Actions from these Flow Specifications implementation decision which Traffic Filtering Actions are
shall be collected and applied. In case of interfering Traffic Filtering Actio selected. See also <xref target="rules_action_interference"
ns format="default"/>.</t>
it is an implementation decision which Traffic Filtering Actions are selected. <t>Interferes with: No other BGP Flow Specification Traffic Filtering
See also <xref Action in this document.</t>
target="rules_action_interference" />. </section>
</t> <section anchor="rt_redirect_action_subtype" numbered="true" toc="default"
<t>Interferes with: No other BGP Flow Specification Traffic Filtering Action in >
this document. <name>RT Redirect (rt-redirect) Sub-Type 0x08</name>
</t> <t>The redirect Extended Community allows the traffic to be redirected
</section> to a VRF routing instance that lists the specified route-target in its
<section anchor="rt_redirect_action_subtype" title="RT Redirect (rt-redirect) s import policy. If several local instances match this criteria, the
ub-type 0x08"> choice between them is a local matter (for example, the instance with
<t>The redirect extended community allows the traffic to be the lowest Route Distinguisher value can be elected).</t>
redirected to a VRF routing instance that lists the specified <t>This Extended Community allows 3 different encodings formats for
route-target in its import policy. If several local instances the route-target (type 0x80, 0x81, 0x82). It uses the same encoding as
match this criteria, the choice between them is a local matter the Route Target Extended Community in Sections <xref target="RFC4360"
(for example, the instance with the lowest Route Distinguisher section="3.1" sectionFormat="bare"/> (type 0x80: 2-octet AS, 4-octet
value can be elected). value), <xref target="RFC4360" section="3.2" sectionFormat="bare"/>
</t> (type 0x81: 4-octet IPv4 address, 2-octet value), and <xref
<t>This Extended Community allows 3 different target="RFC4360" section="4" sectionFormat="bare"/> of <xref
encodings formats for the route-target (type 0x80, 0x81, 0x82). target="RFC4360" format="default"/> and <xref target="RFC5668"
It uses the same encoding as the Route Target Extended Community sectionFormat="of" section="2"/> (type 0x82: 4-octet AS,
in Sections 3.1 (type 0x80: 2-octet AS, 4-octet value), 3.2 2-octet value) with the high-order octet of the Type field 0x80, 0x81,
(type 0x81: 4-octet IPv4 address, 2-octet value) and 4 of 0x82 respectively and the low-order octet of the Type field (Sub-Type)
<xref target="RFC4360" /> and Section 2 (type 0x82: 4-octet AS, 2-octet value) always 0x08.</t>
of <xref target="RFC5668" /> with the high-order octet of the Type <t>Interferes with: No other BGP Flow Specification Traffic Filtering
field 0x80, 0x81, 0x82 respectively and the low-order of the Type Action in this document.</t>
field (Sub-Type) always 0x08. </section>
</t> <section anchor="traffic_marking_subtype" numbered="true" toc="default">
<t>Interferes with: No other BGP Flow Specification Traffic Filtering Action in <name>Traffic Marking (traffic-marking) Sub-Type 0x09</name>
this document. <t> The traffic marking Extended Community instructs a system to
</t> modify the DSCP bits in the IP header (<xref target="RFC2474"
</section> sectionFormat="of" section="3"/>) of a transiting IP packet to the
<section anchor="traffic_marking_subtype" title="Traffic Marking (traffic-markin corresponding value encoded in the 6 least significant bits of the
g) sub-type 0x09"> Extended Community value, as shown in <xref
<t> The traffic marking extended community instructs a target="figure_traffic_marking_encoding" format="default"/>.</t>
system to modify the DSCP bits in the IP header (<xref target="RFC2474" />
Section 3) of a transiting IP packet to the corresponding value encoded <t>The Extended Community is encoded as follows:</t>
in the 6 least significant bits of the extended community value as shown in <xr <figure anchor="figure_traffic_marking_encoding">
ef target="figure_traffic_marking_encoding" />. <name>Traffic Marking Extended Community Encoding</name>
</t> <artwork name="" type="" align="left" alt=""><![CDATA[
<t>The extended is encoded as follows:
<figure title="Traffic Marking Extended Community Encoding" anchor="figure_traff
ic_marking_encoding">
<artwork>
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | reserved | reserved | reserved | | reserved | reserved | reserved | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | r.| DSCP | | reserved | r.| DSCP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork> ]]></artwork>
</figure> </figure>
</t> <dl newline="false" spacing="normal" indent="6">
<t> <dt>DSCP:</dt>
<list style="symbols"> <dd>new DSCP value for the transiting IP packet</dd>
<t>DSCP: new DSCP value for the transiting IP packet. <dt>reserved (r):</dt>
</t> <dd><bcp14>MUST</bcp14> be set to 0 on encoding and
<t>reserved, r.: MUST be set to 0 on encoding, and MUST be <bcp14>MUST</bcp14> be ignored during decoding</dd>
ignored during decoding. </dl>
</t> <t>Interferes with: No other BGP Flow Specification Traffic Filtering
</list> Action in this document.</t>
</t> </section>
<section numbered="true" toc="default">
<t>Interferes with: No other BGP Flow Specification Traffic Filtering Action in <name>Interaction with Other Filtering Mechanisms in Routers</name>
this document.</t> <t>
</section>
<section title="Interaction with other Filtering Mechanisms in Routers">
<t>
Implementations should provide mechanisms that map an arbitrary BGP Implementations should provide mechanisms that map an arbitrary BGP
community value (normal or extended) to Traffic Filtering Actions that community value (normal or extended) to Traffic Filtering Actions that
require different mappings on different systems in the network. For require different mappings on different systems in the network. For
instance, providing packets with a worse-than-best-effort per-hop instance, providing packets with a worse-than-best-effort per-hop
behavior is a functionality that is likely to be implemented behavior is a functionality that is likely to be implemented
differently in different systems and for which no standard behavior differently in different systems and for which no standard behavior
is currently known. Rather than attempting to define it here, this is currently known. Rather than attempting to define it here, this
can be accomplished by mapping a user-defined community value to can be accomplished by mapping a user-defined community value to
platform-/network-specific behavior via user configuration. platform-/network-specific behavior via user configuration.
</t> </t>
</section> </section>
<section anchor="rules_action_interference" title="Considerations on Traffic Fi <section anchor="rules_action_interference" numbered="true" toc="default">
ltering Action Interference"> <name>Considerations on Traffic Filtering Action Interference</name>
<t> <t>Since Traffic Filtering Actions are represented as BGP extended
Since Traffic Filtering Actions are represented as BGP extended community val community values, Traffic Filtering Actions may interfere with each
ues, other (e.g., there may be more than one conflicting traffic-rate-bytes
Traffic Filtering Actions may interfere with each other (e.g. there may be mo Traffic Filtering Action associated with a single Flow
re than Specification). Traffic Filtering Action interference has no impact on
one conflicting traffic-rate-bytes Traffic Filtering Action associated with a BGP propagation of Flow Specifications (all communities are propagated
single according to policies).</t>
Flow Specification). Traffic Filtering Action interference has no impact on B <t>If a Flow Specification associated with interfering Traffic
GP propagation Filtering Actions is selected for packet forwarding, it is an
of Flow Specifications (all communities are propagated according to policies) implementation decision which of the interfering Traffic Filtering
. Actions are selected. Implementors of this specification
</t> <bcp14>SHOULD</bcp14> document the behavior of their implementation in
<t> such cases.</t>
If a Flow Specification associated with interfering Traffic Filtering Actions <t>Operators are encouraged to make use of the BGP policy framework
is selected for supported by their implementation in order to achieve a predictable
packet forwarding, it is an implementation decision which of the interfering behavior. See also <xref target="security_considerations"
Traffic Filtering Actions are selected. Implementors of this specification SH format="default"/>.</t>
OULD </section>
document the behaviour of their implementation in such cases. </section>
</t> <section anchor="traffic_filtering_vpn" numbered="true" toc="default">
<t> <name>Dissemination of Traffic Filtering in BGP/MPLS VPN Networks</name>
Operators are encouraged to make use of the BGP policy framework <t>
supported by their implementation in order to achieve a predictable behaviour
. See also
<xref target="security_considerations" />.
</t>
</section>
</section>
<section anchor="traffic_filtering_vpn" title="Dissemination of Traffic Filterin
g in BGP/MPLS VPN Networks">
<t>
Provider-based Layer 3 VPN networks, such as the ones using a BGP/ MPLS IP Provider-based Layer 3 VPN networks, such as the ones using a BGP/ MPLS IP
VPN <xref target="RFC4364"></xref> control plane, may have different traffic VPN <xref target="RFC4364" format="default"/> control plane, may have differe nt traffic
filtering requirements than Internet service providers. But also Internet filtering requirements than Internet service providers. But also Internet
service providers may use those VPNs for scenarios like having the Internet service providers may use those VPNs for scenarios like having the Internet
routing table in a VRF, resulting in the same traffic filtering requirements routing table in a VRF, resulting in the same traffic filtering requirements
as defined for the global routing table environment within this document. as defined for the global routing table environment within this document.
This document defines an additional BGP NLRI type (AFI=1, SAFI=134) value, This document defines an additional BGP NLRI type (AFI=1, SAFI=134) value,
which can be used to propagate Flow Specification in a BGP/MPLS which can be used to propagate Flow Specification in a BGP/MPLS
VPN environment. VPN environment.
</t> </t>
<t> <t>
The NLRI format for this address family consists of a fixed-length Route The NLRI format for this address family consists of a fixed-length Route
Distinguisher field (8 octets) followed by the Flow Specification NLRI value (<xref target="nlri_value_encoding" />). Distinguisher field (8 octets) followed by the Flow Specification NLRI value (<xref target="nlri_value_encoding" format="default"/>).
The NLRI length field shall include both the 8 octets of the Route The NLRI length field shall include both the 8 octets of the Route
Distinguisher as well as the subsequent Flow Specification NLRI value. Distinguisher as well as the subsequent Flow Specification NLRI value.
The resulting encoding is shown in <xref target="figure_fs_nlri_mpls" />. The resulting encoding is shown in <xref target="figure_fs_nlri_mpls" format= "default"/>.
</t> </t>
<t> <figure anchor="figure_fs_nlri_mpls">
<figure title="Flow Specification NLRI for MPLS" anchor="figure_fs_nlri_mpls"> <name>Flow Specification NLRI for MPLS</name>
<artwork> <artwork name="" type="" align="left" alt=""><![CDATA[
+--------------------------------+ +--------------------------------+
| length (0xnn or 0xfn nn) | | length (0xnn or 0xfn nn) |
+--------------------------------+ +--------------------------------+
| Route Distinguisher (8 octets) | | Route Distinguisher (8 octets) |
+--------------------------------+ +--------------------------------+
| NLRI value (variable) | | NLRI value (variable) |
+--------------------------------+ +--------------------------------+
</artwork> ]]></artwork>
</figure> </figure>
</t> <t>
<t>
Propagation of this NLRI is controlled by matching Route Target Propagation of this NLRI is controlled by matching Route Target
extended communities associated with the BGP path advertisement with extended communities associated with the BGP path advertisement with
the VRF import policy, using the same mechanism as described in BGP/ the VRF import policy, using the same mechanism as described in BGP/
MPLS IP VPNs <xref target="RFC4364"></xref>. MPLS IP VPNs <xref target="RFC4364" format="default"/>.
</t> </t>
<t> <t>
Flow Specifications received via this NLRI apply only to traffic Flow Specifications received via this NLRI apply only to traffic
that belongs to the VRF(s) in which it is imported. By default, that belongs to the VRF(s) in which it is imported. By default,
traffic received from a remote PE is switched via an MPLS forwarding traffic received from a remote PE is switched via an MPLS forwarding
decision and is not subject to filtering. decision and is not subject to filtering.
</t> </t>
<t> <t>Contrary to the behavior specified for the non-VPN NLRI, Flow
Contrary to the behavior specified for the non-VPN NLRI, Flow Specifications Specifications are accepted by default, when received from remote PE
are accepted by default, when received from remote PE routers. routers.</t>
</t> <t>The validation procedure (<xref target="validation_procedure"
<t> format="default"/>) and Traffic Filtering Actions (<xref
The validation procedure (<xref target="validation_procedure" />) and target="traffic_filtering_actions" format="default"/>) are the same as
Traffic Filtering Actions (<xref target="traffic_filtering_actions" />) are for IPv4.</t>
the same as </section>
for IPv4. <section numbered="true" toc="default">
</t> <name>Traffic Monitoring</name>
</section> <t>
<section title="Traffic Monitoring">
<t>
Traffic filtering applications require monitoring and traffic Traffic filtering applications require monitoring and traffic
statistics facilities. While this is an implementation specific statistics facilities. While this is an implementation specific
choice, implementations SHOULD provide: choice, implementations <bcp14>SHOULD</bcp14> provide:
<list style="symbols"> </t>
<t> A mechanism to log the packet header of filtered traffic. <ul spacing="normal">
</t> <li>A mechanism to log the packet header of filtered traffic.</li>
<t>A mechanism to count the number of matches for a given Flow <li>A mechanism to count the number of matches for a given Flow
Specification. Specification rule.</li>
</t> </ul>
</list> </section>
</t> <section anchor="errorhandling" numbered="true" toc="default">
</section> <name>Error Handling</name>
<section anchor="errorhandling" title="Error Handling"> <t>
<t> Error handling according to <xref target="RFC7606" format="default"/> and
Error handling according to <xref target="RFC7606"></xref> and <xref target="RFC4760" format="default"/> applies to this specification.
<xref target="RFC4760"></xref> applies to this specification. </t>
</t> <t>
<t>
This document introduces Traffic Filtering Action Extended Communities. This document introduces Traffic Filtering Action Extended Communities.
Malformed Traffic Filtering Action Extended Communities in the sense of Malformed Traffic Filtering Action Extended Communities in the sense
<xref target="RFC7606"></xref> of <xref target="RFC7606" sectionFormat="of" section="7.14"/>
Section 7.14. are Extended Community values that cannot be decoded accor are Extended Community values that cannot be decoded according
ding to <xref target="traffic_filtering_actions" format="default"/> of this d
to <xref target="traffic_filtering_actions" /> of this document. ocument.
</t> </t>
</section> </section>
<section anchor="IANA" title="IANA Considerations"> <section anchor="IANA" numbered="true" toc="default">
<t> <name>IANA Considerations</name>
This section complies with <xref target="RFC7153"></xref>. <t>
</t> This section complies with <xref target="RFC7153" format="default"/>.
<section title="AFI/SAFI Definitions"> </t>
<t> <section numbered="true" toc="default">
<name>AFI/SAFI Definitions</name>
<t>
IANA maintains a registry entitled "SAFI Values". For the purpose of this IANA maintains a registry entitled "SAFI Values". For the purpose of this
work, IANA is requested to update the following SAFIs to read according to work, IANA has updated the following SAFIs as shown in the table below.
the table below (Note: This document obsoletes both <xref target="RFC7674"
(Note: This document obsoletes both RFC7674 and RFC5575 and all referen format="default"/> and <xref target="RFC5575" format="default"/>, and al
ces l references
to those documents should be deleted from the registry below): to those documents have been deleted from the registry.)
</t> </t>
<texttable anchor="iana_safi" title="Registry: SAFI Values"> <table anchor="iana_safi" align="center">
<ttcol align="left">Value</ttcol> <name>Registry: SAFI Values</name>
<ttcol align="left">Name</ttcol> <thead>
<ttcol align="left">Reference</ttcol> <tr>
<c>133</c> <c>Dissemination of Flow Specification rules</c> <c>[thi <th align="left">Value</th>
s document]</c> <th align="left">Name</th>
<c>134</c> <c>L3VPN Dissemination of Flow Specification rules</c> <th align="left">Reference</th>
<c>[this document]</c> </tr>
</texttable> </thead>
<t> <tbody>
The above textual changes generalise the definition of the SAFIs rather than <tr>
change <td align="left">133</td>
its underlying meaning. Therefore, based on "<xref target="RFC7950" format=" <td align="left">Dissemination of Flow Specification rules</td>
title" />" <xref target="RFC7950" />, <td align="left">RFC 8955</td>
the above text implies that the following YANG enums from "<xref target="RFC </tr>
8294" format="title" />" <tr>
<xref target="RFC8294" /> need to have their names and descriptions at <td align="left">134</td>
<eref target="https://www.iana.org/assignments/iana-routing-types">https://w <td align="left">L3VPN Dissemination of Flow Specification rules</
ww.iana.org/assignments/iana-routing-types</eref> td>
changed to: <td align="left">RFC 8955</td>
<figure> </tr>
<artwork><![CDATA[ </tbody>
<CODE BEGINS> </table>
<t>The above textual changes generalize the definition of the SAFIs
rather than change its underlying meaning. Therefore, based on <xref
target="RFC7950">"The YANG 1.1 Data Modeling Language"</xref>, the above
text means that the following YANG
enums from <xref
target="RFC8294">"Common YANG Data Types for the Routing Area"</xref> hav
e had their names and
descriptions at <eref brackets="angle"
target="https://www.iana.org/assignments/iana-routing-types"/> changed to
:</t>
<sourcecode name="" type="yang" markers="true"><![CDATA[
enum flow-spec-safi { enum flow-spec-safi {
value 133; value 133;
description description
"Dissemination of Flow Specification rules SAFI."; "Dissemination of Flow Specification rules SAFI.";
} }
enum l3vpn-flow-spec-safi { enum l3vpn-flow-spec-safi {
value 134; value 134;
description description
"L3VPN Dissemination of Flow Specification rules SAFI."; "L3VPN Dissemination of Flow Specification rules SAFI.";
} }
<CODE ENDS> ]]></sourcecode>
]]></artwork> <t>A new revision statement has been added to the module as follows:</t>
</figure> <sourcecode name="" type="yang" markers="true"><![CDATA[
A new revision statement should be added to the module as follows:
<figure>
<artwork><![CDATA[
<CODE BEGINS>
revision [revision date] { revision [revision date] {
description "Non-backwards-compatible change of SAFI names description "Non-backwards-compatible change of SAFI names
(SAFI values 133, 134)."; (SAFI values 133, 134).";
reference reference
"[this document]: Dissemination of Flow Specification Rules."; "RFC 8955: Dissemination of Flow Specification Rules.";
} }
<CODE ENDS> ]]></sourcecode>
]]></artwork> </section>
</figure> <section numbered="true" toc="default">
</t> <name>Flow Component Definitions</name>
</section> <t>
<section title="Flow Component Definitions">
<t>
A Flow Specification consists of a sequence of flow components, which A Flow Specification consists of a sequence of flow components, which
are identified by an 8-bit component type. IANA has created and maintains are identified by an 8-bit component type. IANA has created and maintains
a registry entitled "Flow Spec Component Types". IANA is requested to a registry entitled "Flow Spec Component Types". IANA has
update the reference for this registry to [this document]. Furthermore the updated the reference for this registry to RFC 8955. Furthermore, the
references to the values should be updated according to the table below references to the values have been updated according to the table below
(Note: This document obsoletes both RFC7674 and RFC5575 and all references (Note: This document obsoletes both <xref target="RFC7674"
to those documents should be deleted from the registry below). format="default"/> and <xref target="RFC5575" format="default"/>, and all
</t> references
to those documents have been deleted from the registry.)
<texttable anchor="iana_flow_component_types" title="Registry: Flow Spec Com
ponent Types">
<ttcol align="left">Value</ttcol>
<ttcol align="left">Name</ttcol>
<ttcol align="left">Reference</ttcol>
<c>1</c> <c>Destination Prefix</c> <c>[this document]</c>
<c>2</c> <c>Source Prefix</c> <c>[this document]</c>
<c>3</c> <c>IP Protocol</c> <c>[this document]</c>
<c>4</c> <c>Port</c> <c>[this document]</c>
<c>5</c> <c>Destination port</c> <c>[this document]</c>
<c>6</c> <c>Source port</c> <c>[this document]</c>
<c>7</c> <c>ICMP type</c> <c>[this document]</c>
<c>8</c> <c>ICMP code</c> <c>[this document]</c>
<c>9</c> <c>TCP flags</c> <c>[this document]</c>
<c>10</c> <c>Packet length</c> <c>[this document]</c>
<c>11</c> <c>DSCP</c> <c>[this document]</c>
<c>12</c> <c>Fragment</c> <c>[this document]</c>
</texttable>
<t>
In order to manage the limited number space and accommodate several
usages, the following policies defined by <xref target="RFC8126" />
are used:
</t>
<texttable anchor="iana_flow_component_types_policies" title="Flow Spec Comp
onent Types Policies">
<ttcol align="left">Type Values</ttcol>
<ttcol align="left">Policy</ttcol>
<c>0</c> <c>Reserved</c>
<c>[1 .. 127]</c> <c>Specification Required</c>
<c>[128 .. 254]</c> <c>Expert Review</c>
<c>255</c> <c>Reserved</c>
</texttable>
<t>
<list style="hanging" hangIndent="6">
<t hangText="Guidance for Experts:">
<vspace />
128-254 requires
Expert Review as the registration policy. The Experts are expected
to check the clarity of purpose and use of the requested code points.
The Experts must also verify that any
specification produced in the IETF that requests one of these code
points has been made available for review by the IDR working group
and that any specification produced outside the IETF does not
conflict with work that is active or already published within the
IETF. It must be pointed out that introducing new component types may
break interoperability with existing implementations of this protocol.
</t> </t>
</list> <table anchor="iana_flow_component_types" align="center">
</t> <name>Registry: Flow Spec Component Types</name>
</section> <thead>
<section title="Extended Community Flow Specification Actions"> <tr>
<t>The Extended Community Flow Specification Action types defined in this docum <th align="left">Value</th>
ent <th align="left">Name</th>
consist of two parts: <th align="left">Reference</th>
<list> </tr>
<t>Type (BGP Transitive Extended Community Type)</t> </thead>
<t>Sub-Type</t> <tbody>
</list> <tr>
</t> <td align="left">1</td>
<td align="left">Destination Prefix</td>
<td align="left">RFC 8955</td>
</tr>
<tr>
<td align="left">2</td>
<td align="left">Source Prefix</td>
<td align="left">RFC 8955</td>
</tr>
<tr>
<td align="left">3</td>
<td align="left">IP Protocol</td>
<td align="left">RFC 8955</td>
</tr>
<tr>
<td align="left">4</td>
<td align="left">Port</td>
<td align="left">RFC 8955</td>
</tr>
<tr>
<td align="left">5</td>
<td align="left">Destination port</td>
<td align="left">RFC 8955</td>
</tr>
<tr>
<td align="left">6</td>
<td align="left">Source port</td>
<td align="left">RFC 8955</td>
</tr>
<tr>
<td align="left">7</td>
<td align="left">ICMP type</td>
<td align="left">RFC 8955</td>
</tr>
<tr>
<td align="left">8</td>
<td align="left">ICMP code</td>
<td align="left">RFC 8955</td>
</tr>
<tr>
<td align="left">9</td>
<td align="left">TCP flags</td>
<td align="left">RFC 8955</td>
</tr>
<tr>
<td align="left">10</td>
<td align="left">Packet length</td>
<td align="left">RFC 8955</td>
</tr>
<tr>
<td align="left">11</td>
<td align="left">DSCP</td>
<td align="left">RFC 8955</td>
</tr>
<tr>
<td align="left">12</td>
<td align="left">Fragment</td>
<td align="left">RFC 8955</td>
</tr>
</tbody>
</table>
<t>In order to manage the limited number space and accommodate several
usages, the following policies defined by <xref target="RFC8126"
format="default"/> are used:</t>
<table anchor="iana_flow_component_types_policies" align="center">
<name>Flow Spec Component Types Policies</name>
<thead>
<tr>
<th align="left">Type Values</th>
<th align="left">Policy</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">0</td>
<td align="left">Reserved</td>
</tr>
<tr>
<td align="left">[1 .. 127]</td>
<td align="left">Specification Required</td>
</tr>
<tr>
<td align="left">[128 .. 254]</td>
<td align="left">Expert Review</td>
</tr>
<tr>
<td align="left">255</td>
<td align="left">Reserved</td>
</tr>
</tbody>
</table>
<t> <dl newline="true">
For the type-part, IANA maintains a registry entitled "BGP Transitive Exten <dt>Guidance for Experts:</dt>
ded Community <dd>
Types". For the purpose of this work (<xref The registration policy for the range 128-254 is Expert Review. The
target="traffic_filtering_actions" />), IANA is requested to update the experts are expected to check the clarity of purpose and use of
references to the following entries according to the table below (Note: Thi the requested code points. The experts must also verify that
s document obsoletes both any specification produced in the IETF that requests one of
RFC7674 and RFC5575 and all references to those documents should be deleted these code points has been made available for review by the IDR
in the registry below): Working Group and that any specification produced outside the
</t> IETF does not conflict with work that is active or already
<texttable anchor="iana_ext_comm_types" title="Registry: BGP Transitive Exten published within the IETF. It must be pointed out that
ded Community Types"> introducing new component types may break interoperability with
<ttcol align="left">Type Value</ttcol> existing implementations of this protocol.
<ttcol align="left">Name</ttcol> </dd>
<ttcol align="left">Reference</ttcol> </dl>
<c>0x81</c>
<c>
Generic Transitive Experimental Use Extended Community Part 2 (Sub-Ty
pes are
defined in the "Generic Transitive Experimental Use Extended Communit
y Part 2
Sub-Types" Registry)
</c>
<c>[this document]</c>
<c>0x82</c> </section>
<c> <section numbered="true" toc="default">
<name>Extended Community Flow Specification Actions</name>
<t>The Extended Community Flow Specification Action types defined in
this document consist of two parts:</t>
<ul spacing="normal">
<li>Type (BGP Transitive Extended Community Type)</li>
<li>Sub-Type</li>
</ul>
<t>For the type part, IANA maintains a registry entitled "BGP
Transitive Extended Community Types". For the purpose of this work
(<xref target="traffic_filtering_actions" format="default"/>), IANA has
updated the references as shown in the table below. (Note: This document
obsoletes both <xref
target="RFC7674" format="default"/> and
<xref target="RFC5575" format="default"/>, and all references to those
documents have been deleted in the
registry.)</t>
<table anchor="iana_ext_comm_types" align="center">
<name>Registry: BGP Transitive Extended Community Types</name>
<thead>
<tr>
<th align="left">Type Value</th>
<th align="left">Name</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">0x81</td>
<td align="left">
Generic Transitive Experimental Use Extended Community Part 2
(Sub-Types are defined in the "Generic Transitive Experimental Use
Extended Community Part 2 Sub-Types" Registry)
</td>
<td align="left">RFC 8955</td>
</tr>
<tr>
<td align="left">0x82</td>
<td align="left">
Generic Transitive Experimental Use Extended Community Part 3 Generic Transitive Experimental Use Extended Community Part 3
(Sub-Types are defined in the "Generic Transitive Experimental Use (Sub-Types are defined in the "Generic Transitive Experimental Use
Extended Community Part 3 Sub-Types" Registry) Extended Community Part 3 Sub-Types" Registry)
</c> </td>
<c>[this document]</c> <td align="left">RFC 8955</td>
</tr>
</texttable> </tbody>
<t> </table>
For the sub-type part of the extended community Traffic Filtering Actions I <t>For the sub-type part of the Extended Community Traffic Filtering
ANA maintains Actions, IANA maintains the following registries. IANA has
the following registries. IANA is requested to update all names and referen updated all names and references according to the tables below and
ces assign a new value for the "Flow spec traffic-rate-packets" Sub-Type.
according to the tables below and assign a new value for the "Flow spec (Note: This document obsoletes both <xref target="RFC7674"
traffic-rate-packets" Sub-Type (Note: This document obsoletes both format="default"/> and <xref target="RFC5575" format="default"/>, and
RFC7674 and RFC5575 and all references to those documents should be deleted all references to those documents have been deleted from the
from the registries below). registries below.) </t>
</t> <table anchor="iana_ext_comm_subtypes" align="center">
<texttable anchor="iana_ext_comm_subtypes" title="Registry: Generic Transitiv <name>Registry: Generic Transitive Experimental Use Extended
e Experimental Use Extended Community Sub-Types"> Community Sub-Types</name>
<ttcol align="left">Sub-Type Value</ttcol> <thead>
<ttcol align="left">Name</ttcol> <tr>
<ttcol align="left">Reference</ttcol> <th align="left">Sub-Type Value</th>
<c>0x06</c> <th align="left">Name</th>
<c> <th align="left">Reference</th>
Flow spec traffic-rate-bytes </tr>
</c> </thead>
<c>[this document]</c> <tbody>
<tr>
<c>TBD</c> <td align="left">0x06</td>
<c> <td align="left">Flow spec traffic-rate-bytes</td>
Flow spec traffic-rate-packets <td align="left">RFC 8955</td>
</c> </tr>
<c>[this document]</c> <tr>
<td align="left">0x0c</td>
<c>0x07</c> <td align="left">Flow spec traffic-rate-packets</td>
<c> <td align="left">RFC 8955</td>
Flow spec traffic-action (Use of the "Value" field is defined in the </tr>
"Traffic Action Fields" registry) <tr>
</c> <td align="left">0x07</td>
<c>[this document]</c> <td align="left">Flow spec traffic-action (Use of the "Value"
field is defined in the "Traffic Action Fields" registry)</td>
<c>0x08</c> <td align="left">RFC 8955</td>
<c> </tr>
<tr>
<td align="left">0x08</td>
<td align="left">
Flow spec rt-redirect AS-2octet format Flow spec rt-redirect AS-2octet format
</c> </td>
<c>[this document]</c> <td align="left">RFC 8955</td>
</tr>
<c>0x09</c> <tr>
<c> <td align="left">0x09</td>
<td align="left">
Flow spec traffic-remarking Flow spec traffic-remarking
</c> </td>
<c>[this document]</c> <td align="left">RFC 8955</td>
</tr>
</texttable> </tbody>
</table>
<texttable anchor="iana_ext_comm_subtypes2" title="Registry: Generic Transiti <table anchor="iana_ext_comm_subtypes2" align="center">
ve Experimental Use Extended Community Part 2 Sub-Types"> <name>Registry: Generic Transitive Experimental Use Extended
<ttcol align="left">Sub-Type Value</ttcol> Community Part 2 Sub-Types</name>
<ttcol align="left">Name</ttcol> <thead>
<ttcol align="left">Reference</ttcol> <tr>
<c>0x08</c> <th align="left">Sub-Type Value</th>
<c> <th align="left">Name</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">0x08</td>
<td align="left">
Flow spec rt-redirect IPv4 format Flow spec rt-redirect IPv4 format
</c> </td>
<c>[this document]</c> <td align="left">RFC 8955</td>
</texttable> </tr>
<texttable anchor="iana_ext_comm_subtypes3" title="Registry: Generic Transiti </tbody>
ve Experimental Use Extended Community Part 3 Sub-Types"> </table>
<ttcol align="left">Sub-Type Value</ttcol> <table anchor="iana_ext_comm_subtypes3" align="center">
<ttcol align="left">Name</ttcol> <name>Registry: Generic Transitive Experimental Use Extended
<ttcol align="left">Reference</ttcol> Community Part 3 Sub-Types</name>
<c>0x08</c> <thead>
<c> <tr>
<th align="left">Sub-Type Value</th>
<th align="left">Name</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">0x08</td>
<td align="left">
Flow spec rt-redirect AS-4octet format Flow spec rt-redirect AS-4octet format
</c> </td>
<c>[this document]</c> <td align="left">RFC 8955</td>
</texttable> </tr>
<t> </tbody>
Furthermore IANA is requested to update the reference for the registries </table>
<t>
Furthermore, IANA has updated the reference for the registries
"Generic Transitive Experimental Use Extended Community Part 2 Sub-Types" and "Generic Transitive Experimental Use Extended Community Part 2 Sub-Types" and
"Generic Transitive Experimental Use Extended Community Part 3 Sub-Types" "Generic Transitive Experimental Use Extended Community Part 3 Sub-Types"
to [this document]. to RFC 8955.
</t> </t>
<t> <t>The "traffic-action" Extended Community (<xref
The "traffic-action" extended community (<xref target="traffic_action_subtype" format="default"/>) defined in this
target="traffic_action_subtype" />) defined in this document has 46 unused document has 46 unused bits, which can be used to convey additional
bits, meaning. IANA created and maintains a registry entitled "Traffic
which can be used to convey additional meaning. IANA Action Fields". IANA has updated the reference for this
created and maintains a registry entitled: "Traffic Action registry to RFC 8955. Furthermore, IANA has updated
Fields". IANA is requested to update the reference for this registry to the references according to the table below. These values should be
[this document]. Furthermore IANA is requested to update the references acc assigned via IETF Review rules only. (Note: This document obsoletes
ording to the table below. both <xref target="RFC7674" format="default"/> and <xref
These values should be assigned via IETF Review rules only (Note: This docu target="RFC5575" format="default"/>, and all references to those
ment obsoletes both documents have been deleted from the registry.)</t>
RFC7674 and RFC5575 and all references to those documents should be deleted <table anchor="iana_traffic_action_subtype" align="center">
from the registry below). <name>Registry: Traffic Action Fields</name>
</t> <thead>
<texttable anchor="iana_traffic_action_subtype" title="Registry: Traffic Acti <tr>
on Fields"> <th align="left">Bit</th>
<ttcol align="left">Bit</ttcol> <th align="left">Name</th>
<ttcol align="left">Name</ttcol> <th align="left">Reference</th>
<ttcol align="left">Reference</ttcol> </tr>
<c>47</c><c>Terminal Action</c><c>[this document]</c> </thead>
<c>46</c><c>Sample</c><c>[this document]</c> <tbody>
</texttable> <tr>
</section> <td align="left">47</td>
</section> <td align="left">Terminal Action</td>
<section title="Security Considerations" anchor="security_considerations"> <td align="left">RFC 8955</td>
<t> As long as Flow Specifications are restricted to match the </tr>
corresponding unicast routing paths for the relevant prefixes (<xref target=" <tr>
validation_procedure" />), <td align="left">46</td>
the security characteristics of this proposal are equivalent to the existing <td align="left">Sample</td>
security <td align="left">RFC 8955</td>
properties of BGP unicast routing. Any relaxation of the validation </tr>
procedure described in <xref target="validation_procedure" /> may </tbody>
allow unwanted Flow Specifications to be propagated and thus unwanted Traffic </table>
Filtering Actions may be applied to flows. </section>
</t> </section>
<t>Where the above mechanisms are not in place, this could open the door <section anchor="security_considerations" numbered="true" toc="default">
to further denial-of-service attacks such as unwanted traffic filtering, <name>Security Considerations</name>
remarking or redirection. <t> As long as Flow Specifications are restricted to match the
</t> corresponding unicast routing paths for the relevant prefixes (<xref
<t> target="validation_procedure" format="default"/>), the security
characteristics of this proposal are equivalent to the existing security
properties of BGP unicast routing. Any relaxation of the validation
procedure described in <xref target="validation_procedure"
format="default"/> may allow unwanted Flow Specifications to be
propagated, and thus unwanted Traffic Filtering Actions may be applied to
flows.</t>
<t>Where the above mechanisms are not in place, this could open the door
to further denial-of-service attacks, such as unwanted traffic
filtering, remarking, or redirection.</t>
<t>
Deployment of specific relaxations of the validation within an Deployment of specific relaxations of the validation within an
administrative boundary of a network are useful in some networks for quickly administrative boundary of a network are useful in some networks for quickly
distributing filters to prevent denial-of-service attacks. distributing filters to prevent denial-of-service attacks.
For a network to utilize this relaxation, the BGP policies must For a network to utilize this relaxation, the BGP policies must
support additional filtering since the origin AS field is empty. support additional filtering since the origin AS field is empty.
Specifications relaxing the validation restrictions MUST Specifications relaxing the validation restrictions <bcp14>MUST</bcp14>
contain security considerations that provide details on the contain security considerations that provide details on the
required additional filtering. required additional filtering.
For example, the use of Origin validation can provide For example, the use of origin validation can provide
enhanced filtering within an AS confederation. enhanced filtering within an AS confederation.
</t> </t>
<t> <t>
Inter-provider routing is based on a web of trust. Neighboring Inter-provider routing is based on a web of trust. Neighboring
autonomous systems are trusted to advertise valid reachability autonomous systems are trusted to advertise valid reachability
information. If this trust model is violated, a neighboring information. If this trust model is violated, a neighboring
autonomous system may cause a denial-of-service attack by advertising autonomous system may cause a denial-of-service attack by advertising
reachability information for a given prefix for which it does not reachability information for a given prefix for which it does not
provide service (unfiltered address space hijack). Since validation of provide service (unfiltered address space hijack). Since validation of
the Flow Specification is tied to the announcement of the best unicast the Flow Specification is tied to the announcement of the best unicast
route, the failure in the validation of best path route may prevent the route, the failure in the validation of best path route may prevent the
Flow Specificaiton from being used by a local router. Possible Flow Specification from being used by a local router. Possible
mitigations are <xref target="RFC6811" /> and mitigations are <xref target="RFC6811" format="default"/> and
<xref target="RFC8205" />. <xref target="RFC8205" format="default"/>.
</t> </t>
<t> <t>On Internet Exchange Points (IXPs), routes are often exchanged via
On IXPs routes are often exchanged via route servers which do not extend route servers that do not extend the AS_PATH. In such cases, it is not
the AS_PATH. In such cases it is not possible to enforce the left-most possible to enforce the left-most AS in the AS_PATH to be the neighbor
AS in the AS_PATH to be the neighbor AS (the AS of the route server). AS (the AS of the route server). Since the validation of Flow
Since the validation of Flow Specification (<xref target="validation_proc Specification (<xref target="validation_procedure" format="default"/>)
edure" />) depends on this, additional care must be taken. It is advised to use a
depends on this, additional care must be taken. strict inbound route policy in such scenarios.</t>
It is advised to use a strict inbound route policy in such scenarios. <t> Enabling firewall-like capabilities in routers without centralized
</t> management could make certain failures harder to diagnose. For example,
<t> Enabling firewall-like capabilities in routers without centralized it is possible to allow TCP packets to pass between a pair of addresses
management could make certain failures harder to diagnose. For but not ICMP packets. It is also possible to permit packets smaller
example, it is possible to allow TCP packets to pass between a pair than 900 or greater than 1000 octets to pass between a pair of addresses
of addresses but not ICMP packets. It is also possible to permit but not packets whose length is in the range 900-1000. Such behavior
packets smaller than 900 or greater than 1000 octets to pass between a may be confusing, and these capabilities should be used with care whether
pair of addresses, but not packets whose length is in the range 900- manually configured or coordinated through the protocol extensions
1000. Such behavior may be confusing and these capabilities should described in this document.</t>
be used with care whether manually configured or coordinated through <t>Flow Specification BGP speakers (e.g., automated DDoS controllers) not
the protocol extensions described in this document. properly programmed, algorithms that are not performing as expected, or
</t> simply rogue systems may announce unintended Flow Specifications, send
<t> updates at a high rate, or generate a high number of Flow
Flow Specification BGP speakers (e.g. automated DDoS controllers) not prop Specifications. This may stress the receiving systems, exceed their
erly programmed, capacity, or lead to unwanted Traffic Filtering Actions being applied to
algorithms that are not performing as expected, or simply rogue systems flows.</t>
may announce unintended Flow Specifications, send updates at a high rate <t>
or generate a high number of Flow Specifications. Systems may not be able to locate all header values
This may stress the receiving systems, exceed their capacity, or required to identify a packet. This can be especially problematic
lead to unwanted Traffic Filtering Actions being applied to flows. in the case of fragmented packets that are not the first fragment
</t> and thus lack upper-layer protocol headers or Encapsulating Security
<t> While the general verification of the Flow Specification NLRI Payload (ESP) NULL <xref target="RFC4303"/> encryption.
is specified in this document (<xref target="validation_procedure" />) the T </t>
raffic Filtering <t> While the general verification of the Flow Specification NLRI is
Actions received by a third party may need custom verification or filtering. specified in this document (<xref target="validation_procedure"
In particular format="default"/>), the Traffic Filtering Actions received by a third
all non traffic-rate actions may allow a third party to modify packet forwar party may need custom verification or filtering. In particular, all
ding properties and potentially non-traffic-rate actions may allow a third party to modify packet
gain access to other routing-tables/VPNs or undesired queues. This can be av forwarding
oided by proper filtering/screening of the properties and potentially gain access to other routing-tables/VPNs or
Traffic Filtering Action communities undesired queues. This can be avoided by proper filtering/screening of
at network borders and only exposing a predefined subset of Traffic Filterin the Traffic Filtering Action communities at network borders and only
g Actions (see <xref target="traffic_filtering_actions" />) exposing a predefined subset of Traffic Filtering Actions (see <xref
to third parties. One way to achieve this is by mapping user-defined communi target="traffic_filtering_actions" format="default"/>) to third
ties, that can be set by the third party, to parties. One way to achieve this is by mapping user-defined communities,
Traffic Filtering Actions and not accepting Traffic Filtering Action extende which can be set by the third party, to Traffic Filtering Actions and not
d communities from third parties. accepting Traffic Filtering Action extended communities from third
</t> parties.</t>
<t>This extension adds additional information to Internet routers. <t>This extension adds additional information to Internet routers.
These are limited in terms of the maximum number of data elements These are limited in terms of the maximum number of data elements
they can hold as well as the number of events they are able to they can hold as well as the number of events they are able to
process in a given unit of time. Service providers need to consider process in a given unit of time. Service providers need to consider
the maximum capacity of their devices and may need to limit the the maximum capacity of their devices and may need to limit the
number of Flow Specifications accepted and processed. number of Flow Specifications accepted and processed.
</t> </t>
</section> </section>
<section title="Contributors">
<t>Barry Greene, Pedro Marques, Jared Mauch
and Nischal Sheth were authors on <xref target="RFC5575" />, and therefor
e
are contributing authors on this document.
</t>
</section>
<section title="Acknowledgements">
<t>The authors would like to thank Yakov Rekhter, Dennis Ferguson, Chris
Morrow, Charlie Kaufman, and David Smith for their comments for the comments
on
the original <xref target="RFC5575" />. Chaitanya Kodeboyina
helped design the flow validation procedure; and Steven Lin and Jim Washburn
ironed out all the details necessary to
produce a working implementation in the original <xref target="RFC5575" />.
</t>
<t>
A packet rate Traffic Filtering Action was also described in a Flow Specifica
tion extension draft
and the authors like to thank Wesley Eddy, Justin Dailey and Gilbert Clark fo
r
their work.
</t>
<t>Additionally, the authors would like to thank Alexander Mayrhofer, Nicolas
Fevrier,
Job Snijders, Jeffrey Haas and Adam Chappell for their comments and review.
</t>
</section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references>
&RFC0768; <name>References</name>
&RFC0791; <references>
&RFC0792; <name>Normative References</name>
&RFC0793; <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
&RFC2119; ence.RFC.0768.xml"/>
&RFC2474; <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
&RFC4271; ence.RFC.0791.xml"/>
&RFC4360; <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
&RFC4364; ence.RFC.0792.xml"/>
&RFC4456; <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
&RFC4760; ence.RFC.0793.xml"/>
&RFC5668; <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
&RFC7153; ence.RFC.2119.xml"/>
&RFC7606; <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
&RFC8126; ence.RFC.2474.xml"/>
&RFC8174; <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4271.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4360.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4364.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4456.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4760.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5668.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7153.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7606.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8126.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8174.xml"/>
<reference anchor="ISO_IEC_9899"> <reference anchor="ISO_IEC_9899">
<front> <front>
<title>Information technology -- Programming languages -- C</title> <title>Information technology -- Programming languages -- C</title>
<seriesInfo name="ISO/IEC" value="9899:2018"/>
<author> <author>
<organization>ISO</organization> <organization>ISO</organization>
</author> </author>
<date month="June" year="2018" /> <date month="June" year="2018"/>
</front> </front>
<seriesInfo name="ISO/IEC" value="9899:2018"/> </reference>
</reference> <reference anchor="IEEE.754.1985">
<reference anchor="IEEE.754.1985"> <front>
<front>
<title>Standard for Binary Floating-Point Arithmetic</title> <title>Standard for Binary Floating-Point Arithmetic</title>
<author> <author>
<organization>IEEE</organization> <organization>IEEE</organization>
</author> </author>
<date month="August" year="1985" /> <date month="August" year="1985"/>
</front> </front>
<seriesInfo name="IEEE" value="754-1985"/> <seriesInfo name="IEEE" value="754-1985"/>
</reference> <seriesInfo name="DOI" value=" 10.1109/IEEESTD.2019.8766229"/>
</references> </reference>
<references title="Informative References"> </references>
&RFC4303; <references>
&RFC5575; <name>Informative References</name>
&RFC6811; <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
&RFC7674; ence.RFC.4303.xml"/>
&RFC7950; <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
&RFC8205; ence.RFC.5575.xml"/>
&RFC8294; <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
&I-D.ietf-idr-flow-spec-v6; ence.RFC.6811.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7674.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7950.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8205.xml"/>
<xi:include
href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
8294.xml"/>
<!-- draft-ietf-idr-flow-spec-v6-22 in queue 2020-12-14 -->
<reference anchor="RFC8956" target="https://www.rfc-editor.org/info/rfc8956">
<front>
<title>Dissemination of Flow Specification Rules for IPv6</title>
<author initials='C' surname='Loibl' fullname='Christoph Loibl' role='editor'>
<organization />
</author>
<author initials='R' surname='Raszuk' fullname='Robert Raszuk' role='editor'>
<organization />
</author>
<author initials='S' surname='Hares' fullname='Susan Hares' role='editor'>
<organization />
</author>
<date month='December' year='2020' />
</front>
<seriesInfo name="RFC" value="8956"/>
<seriesInfo name="DOI" value="10.17487/RFC8956"/>
</reference>
</references>
</references> </references>
<section title="Example Python code: flow_rule_cmp" anchor="flow_rule_cmp_sr <section anchor="flow_rule_cmp_src" numbered="true" toc="default">
c"> <name>Example Python code: flow_rule_cmp</name>
<t>
<figure> <sourcecode name="" type="python" markers="true"><![CDATA[
<artwork><![CDATA[
<CODE BEGINS>
""" """
Copyright (c) 2020 IETF Trust and the persons identified as authors Copyright (c) 2020 IETF Trust and the persons identified as
of draft-ietf-idr-rfc5575bis. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without Redistribution and use in source and binary forms, with or without
modification, is permitted pursuant to, and subject to the license modification, is permitted pursuant to, and subject to the license
terms contained in, the Simplified BSD License set forth in Section terms contained in, the Simplified BSD License set forth in Section
4.c of the IETF Trust’s Legal Provisions Relating to IETF Documents 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
""" """
import itertools import itertools
import collections import collections
import ipaddress import ipaddress
EQUAL = 0 EQUAL = 0
A_HAS_PRECEDENCE = 1 A_HAS_PRECEDENCE = 1
B_HAS_PRECEDENCE = 2 B_HAS_PRECEDENCE = 2
IP_DESTINATION = 1 IP_DESTINATION = 1
IP_SOURCE = 2 IP_SOURCE = 2
FS_component = collections.namedtuple('FS_component', FS_component = collections.namedtuple('FS_component',
'component_type op_value') 'component_type op_value')
class FS_nlri(object): class FS_nlri(object):
""" """
FS_nlri class implementation that allows sorting. FS_nlri class implementation that allows sorting.
By calling .sort() on a array of FS_nlri objects these will be By calling .sort() on an array of FS_nlri objects these will be
sorted according to the flow_rule_cmp algorithm. sorted according to the flow_rule_cmp algorithm.
Example: Example:
nlri = [ FS_nlri(components=[ nlri = [ FS_nlri(components=[
FS_component(component_type=IP_DESTINATION, FS_component(component_type=IP_DESTINATION,
op_value=ipaddress.ip_network('10.1.0.0/16') ), op_value=ipaddress.ip_network('10.1.0.0/16') ),
FS_component(component_type=4, FS_component(component_type=4,
op_value=bytearray([0,1,2,3,4,5,6])), op_value=bytearray([0,1,2,3,4,5,6])),
]), ]),
FS_nlri(components=[ FS_nlri(components=[
FS_component(component_type=5, FS_component(component_type=5,
op_value=bytearray([0,1,2,3,4,5,6])), op_value=bytearray([0,1,2,3,4,5,6])),
FS_component(component_type=6, FS_component(component_type=6,
op_value=bytearray([0,1,2,3,4,5,6])), op_value=bytearray([0,1,2,3,4,5,6])),
]), ]),
] ]
nlri.sort() # sorts the array accorinding to the algorithm nlri.sort() # sorts the array according to the algorithm
""" """
def __init__(self, components = None): def __init__(self, components = None):
""" """
components: list of type FS_component components: list of type FS_component
""" """
self.components = components self.components = components
def __lt__(self, other): def __lt__(self, other):
# use the below algorithm for sorting # use the below algorithm for sorting
result = flow_rule_cmp(self, other) result = flow_rule_cmp(self, other)
skipping to change at line 1833 skipping to change at line 2162
else: else:
# assuming comp_a.op_value, comp_b.op_value of type # assuming comp_a.op_value, comp_b.op_value of type
# bytearray # bytearray
if len(comp_a.op_value) == len(comp_b.op_value): if len(comp_a.op_value) == len(comp_b.op_value):
if comp_a.op_value > comp_b.op_value: if comp_a.op_value > comp_b.op_value:
return B_HAS_PRECEDENCE return B_HAS_PRECEDENCE
if comp_a.op_value < comp_b.op_value: if comp_a.op_value < comp_b.op_value:
return A_HAS_PRECEDENCE return A_HAS_PRECEDENCE
# components equal -> continue with next component # components equal -> continue with next component
else: else:
common = min(len(comp_a.op_value), len(comp_b.op_value)) common = min(len(comp_a.op_value),
if comp_a.op_value[:common] > comp_b.op_value[:common]: len(comp_b.op_value))
if comp_a.op_value[:common] > \
comp_b.op_value[:common]:
return B_HAS_PRECEDENCE return B_HAS_PRECEDENCE
elif comp_a.op_value[:common] < \ elif comp_a.op_value[:common] < \
comp_b.op_value[:common]: comp_b.op_value[:common]:
return A_HAS_PRECEDENCE return A_HAS_PRECEDENCE
# the first common bytes match # the first common bytes match
elif len(comp_a.op_value) > len(comp_b.op_value): elif len(comp_a.op_value) > len(comp_b.op_value):
return A_HAS_PRECEDENCE return A_HAS_PRECEDENCE
else: else:
return B_HAS_PRECEDENCE return B_HAS_PRECEDENCE
return EQUAL return EQUAL
<CODE ENDS> ]]></sourcecode>
]]></artwork>
</figure>
</t>
</section> </section>
<section title="Comparison with RFC 5575" anchor="rfc5575differences"> <section anchor="rfc5575differences" numbered="true" toc="default">
<t> <name>Comparison with RFC 5575</name>
This document includes numerous editorial changes to <xref target="RFC55 <t>This document includes numerous editorial changes to <xref
75" />. target="RFC5575" format="default"/>. It also completely incorporates the
It also completely incorporates the redirect action clarification docume redirect action clarification document <xref target="RFC7674"
nt <xref target="RFC7674" />. format="default"/>. It is recommended to read the entire document. The
It is recommended to read the entire document. The authors, however, want to point out the following technical changes to
authors, however want to point out the following technical changes to <xref target="RFC5575" format="default"/>:</t>
<xref target="RFC5575" />: <ul spacing="normal">
<list> <li><xref target="intro" format="default"/> introduces the Flow
<t> Specification NLRI. In <xref target="RFC5575" format="default"/>, this
<xref target="intro" /> introduces the Flow Specification NLRI. In NLRI was defined as an opaque key in BGPs database. This specification
<xref target="RFC5575" /> this NLRI was defined as an opaque-key in has removed all references to an opaque key property. BGP
BGPs database. This implementations are able to understand the NLRI encoding.</li>
specification has removed all references to an opaque-key property. <li><xref target="numeric_operator" format="default"/> defines a
BGP implementations are able to understand the NLRI encoding. numeric operator and comparison bit combinations. In <xref
</t> target="RFC5575" format="default"/>, the meaning of those bit
<t> combination was not explicitly defined and left open to the
<xref target="numeric_operator" /> defines a numeric operator and co reader.</li>
mparison <li>Sections <xref target="type_3" format="counter"/> - <xref target="ty
bit combinations. In <xref target="RFC5575" /> the meaning of those pe_8"
bit combination was not explicitly defined and left open to the format="counter"/>, <xref target="type_10" format="counter"/>, and <xref
reader. target="type_11" format="counter"/> make use of the above numeric
</t> operator. The allowed length of the comparison value was not
<t> consistently defined in <xref target="RFC5575"
<xref target="type_3" /> - <xref target="type_8" />, <xref format="default"/>.</li>
target="type_10" />, <xref target="type_11" /> make use of the above <li><xref target="traffic_filtering_actions" format="default"/>
numeric operator. The allowed length of the comparison value was not defines all Traffic Filtering Action Extended Communities as
consistently defined in <xref target="RFC5575" />. transitive Extended Communities. <xref target="RFC5575"
</t> format="default"/> defined the traffic-rate action to be
<t> non-transitive and did not define the transitivity of the other
<xref target="traffic_filtering_actions" /> defines all Traffic Traffic Filtering Action communities at all.</li>
Filtering Action Extended communities as transitive extended communi <li><xref target="traffic_rate_in_packets" format="default"/>
ties. introduces a new Traffic Filtering Action (traffic-rate-packets). This
<xref target="RFC5575" /> defined the traffic-rate action to be action did not exist in <xref target="RFC5575"
non-transitive and did not define the transitivity of the other format="default"/>.</li>
Traffic Filtering Action communities at all. <li><xref target="rt_redirect_action_subtype" format="default"/>
</t> contains the same redirect actions already defined in <xref
<t> target="RFC5575" format="default"/>, however, these actions have been
<xref target="traffic_rate_in_packets" /> introduces a new Traffic renamed to "rt-redirect" to make it clearer that the redirection is
Filtering Action (traffic-rate-packets). This action did not exist based on route-target. This section also completely incorporates the
in <xref target="RFC5575" />. <xref target="RFC7674" format="default"/> clarifications of the
</t> Flowspec Redirect Extended Community.</li>
<t> <li><xref target="rules_action_interference" format="default"/>
<xref target="rt_redirect_action_subtype" /> contains the same contains general considerations on interfering traffic actions. <xref
redirect actions already defined in <xref target="RFC5575" /> target="traffic_action_subtype" format="default"/> also
however, these actions have been renamed to "rt-redirect" to make cross-references <xref target="rules_action_interference"
it clearer that the redirection is based on route-target. format="default"/>. <xref target="RFC5575" format="default"/> did not
This section also completely incorporates the <xref target="RFC7674" mention this.</li>
/> <li><xref target="errorhandling" format="default"/> contains new error
clarifications of the Flowspec Redirect Extended Community. handling.</li>
</t> </ul>
<t> </section>
<xref target="rules_action_interference" /> contains general <section numbered="false" toc="default">
considerations on interfering traffic actions. <name>Acknowledgments</name>
<xref target="traffic_action_subtype" /> also <t>The authors would like to thank <contact fullname="Yakov Rekhter"/>,
cross-references <xref target="rules_action_interference" />. <contact fullname="Dennis Ferguson"/>, <contact fullname="Chris
<xref target="RFC5575" /> did not mention this. Morrow"/>, <contact fullname="Charlie Kaufman"/>, and <contact
</t> fullname="David Smith"/> for their comments on the
<t> original <xref target="RFC5575" format="default"/>. <contact
<xref target="errorhandling" /> contains new error handling. fullname="Chaitanya Kodeboyina"/> helped design the flow validation
</t> procedure, and <contact fullname="Steven Lin"/> and <contact
</list> fullname="Jim Washburn"/> ironed out all the details necessary to
</t> produce a working implementation in the original <xref target="RFC5575"
format="default"/>.</t>
<t>A packet rate Traffic Filtering Action was also described in a Flow
Specification extension draft and the authors would like to thank <contact
fullname="Wesley Eddy"/>, <contact fullname="Justin Dailey"/>, and
<contact fullname="Gilbert Clark"/> for their work.</t>
<t>Additionally, the authors would like to thank <contact
fullname="Alexander Mayrhofer"/>, <contact fullname="Nicolas Fevrier"/>,
<contact fullname="Job Snijders"/>, <contact fullname="Jeffrey Haas"/>,
and <contact fullname="Adam Chappell"/> for their comments and
review.</t>
</section>
<section numbered="false" toc="default">
<name>Contributors</name>
<t><contact fullname="Barry Greene"/>, <contact fullname="Pedro
Marques"/>, <contact fullname="Jared Mauch"/>, and <contact
fullname="Nischal Sheth were"/> authors on <xref target="RFC5575"
format="default"/> and, therefore, are contributing authors on this
document.</t>
</section> </section>
</back> </back>
</rfc>
</rfc>
 End of changes. 96 change blocks. 
1758 lines changed or deleted 1952 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/