rfc8956xml2.original.xml   rfc8956.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-idr-flow-spe
.2119.xml"> c-v6-22"
<!ENTITY RFC4271 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC number="8956" ipr="trust200902" updates="8955" obsoletes=""
.4271.xml"> submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="
<!ENTITY RFC4443 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC true" tocDepth="2"
.4443.xml"> symRefs="true" sortRefs="true" version="3">
<!ENTITY RFC4760 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4760.xml"> <!-- xml2rfc v2v3 conversion 3.5.0 -->
<!ENTITY RFC5701 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5701.xml">
<!ENTITY RFC7112 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7112.xml">
<!ENTITY RFC7153 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7153.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8174.xml">
<!ENTITY RFC8200 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8200.xml">
<!ENTITY RFC8883 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8883.xml">
<!ENTITY I-D.ietf-idr-rfc5575bis SYSTEM "http://xml.resource.org/public/rfc/bibx
ml3/reference.I-D.ietf-idr-rfc5575bis.xml">
]>
<?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-flow-spec-v6-22" ipr="trust200902"
updates="I-D.ietf-idr-rfc5575bis">
<front> <front>
<title abbrev="IPv6 Flow Specification">Dissemination of Flow Specification Ru <title abbrev="IPv6 Flow Specification">Dissemination of Flow Specification
les for IPv6</title> Rules for IPv6</title>
<author role="editor" fullname="Christoph Loibl" initials="C.L." <seriesInfo name="RFC" value="8956"/>
surname="Loibl"> <author role="editor" fullname="Christoph Loibl" initials="C" surname="Loibl
<organization>next layer Telekom GmbH</organization> ">
<address> <organization>next layer Telekom GmbH</organization>
<postal> <address>
<street>Mariahilfer Guertel 37/7</street>
<city>Vienna</city>
<region></region>
<code>1150</code>
<country>AT</country>
</postal>
<phone>+43 664 1176414</phone>
<email>cl@tix.at</email>
</address>
</author>
<author fullname='Robert Raszuk' initials='R' surname='Raszuk' role="edito
r">
<organization>Bloomberg LP</organization>
<address>
<postal> <postal>
<street>731 Lexington Ave </street> <street>Mariahilfer Guertel 37/7</street>
<city>New York City</city> <city>Vienna</city>
<region>NY</region> <region/>
<code>10022</code> <code>1150</code>
<country>USA</country> <country>Austria</country>
</postal>
<phone>+43 664 1176414</phone>
<email>cl@tix.at</email>
</address>
</author>
<author fullname="Robert Raszuk" initials="R" surname="Raszuk" role="editor"
>
<organization>NTT Network Innovations</organization>
<address>
<postal>
<street>940 Stewart Dr</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94085</code>
<country>United States of America</country>
</postal> </postal>
<email>robert@raszuk.net</email> <email>robert@raszuk.net</email>
</address> </address>
</author> </author>
<author role="editor" fullname="Susan Hares" initials="S" surname ="Hares"> <author role="editor" 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>
<date year="2020" month="December" />
<date year="2020" /> <area>Routing</area>
<area>Routing Area</area> <workgroup>IDR</workgroup>
<workgroup>IDR Working Group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>BGP Flow Specification</keyword> <keyword>BGP Flow Specification</keyword>
<keyword>V6</keyword> <keyword>V6</keyword>
<abstract> <abstract>
<t> <t>
Dissemination of Flow Specification Rules I-D.ietf-idr-rfc5575bis "Dissemination of Flow Specification Rules" (RFC 8955)
provides a Border Gateway Protocol provides a Border Gateway Protocol (BGP)
extension for the propagation of traffic flow information for extension for the propagation of traffic flow information for
the purpose of rate limiting or filtering IPv4 protocol data packets. the purpose of rate limiting or filtering IPv4 protocol data packets.
</t> </t>
<t> <t>
This document extends I-D.ietf-idr-rfc5575bis with IPv6 functionality. This document extends RFC 8955 with IPv6 functionality.
It also updates I-D.ietf-idr-rfc5575bis by changing the IANA Flow Spec It also updates RFC 8955 by changing the IANA Flow Spec
Component Types registry. Component Types registry.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro" title="Introduction"> <section anchor="intro" numbered="true" toc="default">
<t>The growing amount of IPv6 traffic in private and public networks <name>Introduction</name>
<t>The growing amount of IPv6 traffic in private and public networks
requires the extension of tools used in IPv4-only networks to also support requires the extension of tools used in IPv4-only networks to also support
IPv6 data packets. IPv6 data packets.
</t> </t>
<t> <t>
This document analyzes the differences between describing IPv6 This document analyzes the differences between describing IPv6
<xref target="RFC8200"></xref> flows and those of IPv4 packets. It specifies <xref target="RFC8200" format="default"/> flows and those of IPv4 packets. It
new Border Gateway Protocol <xref target="RFC4271"></xref> encoding formats t specifies
o enable new Border Gateway Protocol <xref target="RFC4271" format="default"/> encodin
Dissemination of Flow Specification Rules <xref target="I-D.ietf-idr-rfc5575b g formats to enable
is" /> "Dissemination of Flow Specification Rules" <xref target="RFC8955" format="de
fault"/>
for IPv6. for IPv6.
</t> </t>
<t> <t>
This specification is an extension of the base <xref target="I-D.ietf-idr-rf This specification is an extension of the base established in <xref target="
c5575bis" />. RFC8955" format="default"/>.
It only defines the delta changes required to support IPv6 while all other It only defines the delta changes required to support IPv6, while all other
definitions and operation mechanisms of Dissemination of Flow Specification definitions and operation mechanisms of "Dissemination of Flow Specification
Rules will remain in the main specification and will not be repeated here. Rules" will remain in the main specification and will not be repeated here.
</t> </t>
<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="NLRI - ">Network Layer Reachability Information.</t> <dt>AS: </dt>
<t hangText="SAFI - ">Subsequent Address Family Identifier.</t> <dd>Autonomous System</dd>
<t hangText="VRF - ">Virtual Routing and Forwarding instance.</t> <dt>NLRI: </dt>
</list> <dd>Network Layer Reachability Information</dd>
</t> <dt>SAFI: </dt>
<t> <dd>Subsequent Address Family Identifier</dd>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <dt>VRF: </dt>
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", <dd>Virtual Routing and Forwarding</dd>
"MAY", and "OPTIONAL" in this document are to be interpreted as </dl>
described in BCP 14 <xref target="RFC2119"></xref> <xref target="RFC8174"></ <t>
xref> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here. when, and only when, they appear in all capitals, as shown here.
</t> </t>
</section> </section>
</section> </section>
<section title="IPv6 Flow Specification encoding in BGP"> <section numbered="true" toc="default">
<t> <name>IPv6 Flow Specification Encoding in BGP</name>
<xref target="I-D.ietf-idr-rfc5575bis" /> defines SAFIs <t>
133 (Dissemination of Flow Specification) and 134 (L3VPN <xref target="RFC8955" format="default"/> defines SAFIs
Dissemination of Flow Specification) in order to carry 133 (Dissemination of Flow Specification rules) and 134 (L3VPN
Dissemination of Flow Specification rules) in order to carry
the corresponding Flow Specification. the corresponding Flow Specification.
</t> </t>
<t> <t>
Implementations wishing to exchange IPv6 Flow Specifications MUST use Implementations wishing to exchange IPv6 Flow Specifications <bcp14>MUST</bcp
14> use
BGP's Capability Advertisement facility to exchange the Multiprotocol BGP's Capability Advertisement facility to exchange the Multiprotocol
Extension Capability Code (Code 1) as defined in <xref target="RFC4760"></xre Extension Capability Code (Code 1), as defined in <xref target="RFC4760" form
f>. at="default"/>.
The (AFI, SAFI) pair carried in the Multiprotocol Extension Capability MUST b The (AFI, SAFI) pair carried in the Multiprotocol Extension Capability <bcp14
e: >MUST</bcp14> be
(AFI=2, SAFI=133) for IPv6 Flow Specification, and (AFI=2, SAFI=134) for (AFI=2, SAFI=133) for IPv6 Flow Specification rules and (AFI=2, SAFI=134) for
VPNv6 Flow Specification. L3VPN Dissemination of Flow Specification rules.
</t> </t>
</section> </section>
<section title="IPv6 Flow Specification components"> <section numbered="true" toc="default">
<t> <name>IPv6 Flow Specification Components</name>
The encoding of each of the components begins with a type field (1 octet) <t>
The encoding of each of the components begins with a Type field (1 octet)
followed by a variable length parameter. The following sections define followed by a variable length parameter. The following sections define
component types and parameter encodings for IPv6. component types and parameter encodings for IPv6.
</t> </t>
<t> <t>
Types 4 (Port), 5 (Destination Port), 6 (Source Port), 9 (TCP flags), 10 (Pac Types 4 (Port), 5 (Destination Port), 6 (Source Port), 9 (TCP Flags), 10 (Pac
ket length) and 11 (DSCP), ket Length),
as defined in <xref target="I-D.ietf-idr-rfc5575bis" />, and 11 (DSCP),
also apply to IPv6. Note that IANA is requested to update the "Flow Spec Comp as defined in <xref target="RFC8955" format="default"/>,
onent Types" registry in order also apply to IPv6. Note that IANA has updated the "Flow Spec Component Types
" registry in order
to contain both IPv4 and IPv6 Flow Specification component type numbers in a single registry to contain both IPv4 and IPv6 Flow Specification component type numbers in a single registry
(<xref target="IANA" />). (<xref target="IANA" format="default"/>).
</t> </t>
<section anchor="type_1" title="Type 1 - Destination IPv6 Prefix" toc="include"> <section anchor="type_1" toc="include" numbered="true">
<t>Encoding: &lt;type (1 octet), length (1 octet), offset (1 octet), p <name>Type 1 - Destination IPv6 Prefix</name>
attern (variable), padding(variable) &gt;</t> <dl newline="false" spacing="normal">
<t>Defines the destination prefix to match. <dt>Encoding:</dt>
<dd>&lt;type (1 octet), length (1 octet), offset (1 octet), pattern (vari
able),
padding (variable) &gt;</dd>
</dl>
<t>This defines the destination prefix to match.
The offset has been defined to allow for flexible matching to portions of an The offset has been defined to allow for flexible matching to portions of an
IPv6 address where one is required to skip over the first N bits of the ad IPv6 address where one is required to skip over the first N bits of the ad
dress dress.
(these bits skipped are often indicated as "don’t care" bits). (These bits skipped are often indicated as "don't care" bits.)
This can be especially useful where part of the IPv6 address This can be especially useful where part of the IPv6 address
consists of an embedded IPv4 address and matching needs to happen consists of an embedded IPv4 address, and matching needs to happen
only on the embedded IPv4 address. The encoded pattern contains only on the embedded IPv4 address. The encoded pattern contains
enough octets for the bits used in matching (length minus offset enough octets for the bits used in matching (length minus offset
bits). bits).
</t>
<t>
<list style="hanging">
<t hangText="length -">The length field indicates the N-th most signific
ant bit in the address where
bitwise pattern matching stops.
</t> </t>
<t hangText="offset -">The offset field indicates the number of most sig <dl newline="false" spacing="normal" indent="11">
nificant address bits to <dt>length:</dt>
<dd>This indicates the N-th most significant bit in the address where
bitwise pattern matching stops.
</dd>
<dt>offset:</dt>
<dd>This indicates the number of most significant address bits to
skip before bitwise pattern matching starts. skip before bitwise pattern matching starts.
</t> </dd>
<t hangText="pattern -">Contains the matching pattern. The length of the <dt>pattern:</dt>
pattern is defined by the <dd>This contains the matching pattern. The length of the pattern is d
efined by the
number of bits needed for pattern matching (length minus offset). number of bits needed for pattern matching (length minus offset).
</dd>
<dt>padding:</dt>
<dd>This contains the minimum number of bits required to pad the compo
nent to an octet boundary.
Padding bits <bcp14>MUST</bcp14> be 0 on encoding and <bcp14>MUST</bc
p14> be ignored on decoding.
</dd>
</dl>
<t>
If length = 0 and offset = 0, this component matches every address; oth
erwise, length <bcp14>MUST</bcp14> be in the
range offset &lt; length &lt; 129 or the component is malformed.</t>
<t>
Note: This Flow Specification component can be represented by the notati
on ipv6address/length
if offset is 0 or
ipv6address/offset-length. The ipv6address in this notation is the textu
al IPv6 representation
of the pattern
shifted to the right by the number of offset bits. See also <xref target
="examples" format="default"/>.
</t> </t>
<t hangText="padding -">The minimum number of bits required to pad the c </section>
omponent to an octet boundary. <section anchor="type_2" toc="include" numbered="true">
Padding bits MUST be 0 on encoding and MUST be ignored on decoding. <name>Type 2 - Source IPv6 Prefix</name>
</t> <dl newline="false" spacing="normal">
</list> <dt>Encoding:</dt>
<dd>&lt;type (1 octet), length (1 octet), offset (1 octet), pattern (vari
able),
padding (variable) &gt;</dd>
</dl>
<t>This defines the source prefix to match. The length, offset, pattern,
and padding
are the same as in <xref target="type_1" format="default"/>.
</t> </t>
<t> </section>
length = offset = 0 matches every address, otherwise length MUST be in t <section anchor="type_3" numbered="true" toc="default">
he range offset &lt; length &lt; 129 <name>Type 3 - Upper-Layer Protocol</name>
or the component is malformed. <dl newline="false" spacing="normal">
</t> <dt>Encoding:</dt>
<t> <dd>&lt;type (1 octet), [numeric_op, value]+&gt;</dd>
Note: This Flow Specification component can be represented by the notati </dl>
on ipv6address/length if offset is 0, or <t>This contains a list of {numeric_op, value} pairs that
ipv6address/offset-length. The ipv6address in this notation is the textu
al IPv6 representation of the pattern
shifted to the right by the number of offset bits. See also <xref target
="examples" />.
</t>
</section>
<section anchor="type_2" title="Type 2 - Source IPv6 Prefix" toc="include">
<t>Encoding: &lt;type (1 octet), length (1 octet), offset (1 octet), p
attern (variable), padding(variable) &gt;</t>
<t>Defines the source prefix to match. The length, offset, pattern and
padding
are the same as in <xref target="type_1" />.
</t>
</section>
<section anchor="type_3" title="Type 3 - Upper-Layer Protocol">
<t>Encoding: &lt;type (1 octet), [numeric_op, value]+&gt;
</t>
<t>Contains a list of {numeric_op, value} pairs that
are used to match the first Next Header value octet in IPv6 packets are used to match the first Next Header value octet in IPv6 packets
that is not an extension header and thus indicates that the next item that is not an extension header and thus indicates that the next item
in the packet is the corresponding upper-layer header (see in the packet is the corresponding upper-layer header (see
<xref target="RFC8200" /> Section 4). <xref target="RFC8200" sectionFormat="of" section="4"/>).
</t> </t>
<t>This component uses the Numeric Operator (numeric_op) described in <t>This component uses the Numeric Operator (numeric_op) described in
<xref target="I-D.ietf-idr-rfc5575bis" /> Section 4.2.1.1. <xref target="RFC8955" sectionFormat="of" section="4.2.1.1"/>.
Type 3 component values SHOULD be encoded as single octet Type 3 component values <bcp14>SHOULD</bcp14> be encoded as a single octet
(numeric_op len=00). (numeric_op len=00).
</t> </t>
<t>Note: While IPv6 allows for more than one Next Header field in the <t>Note: While IPv6 allows for more than one Next Header field in the
packet, the main goal of the Type 3 Flow Specification component is to packet, the main goal of the Type 3 Flow Specification component is to
match on the first upper-layer IP protocol value. Therefore the match on the first upper-layer IP protocol value. Therefore, the
definition is limited to match only on this specific Next Header field in definition is limited to match only on this specific Next Header field in
the packet. the packet.
</t> </t>
</section> </section>
<section anchor="type_7" title="Type 7 - ICMPv6 Type" toc="include"> <section anchor="type_7" toc="include" numbered="true">
<t>Encoding: &lt;type (1 octet), [numeric_op, value]+&gt; <name>Type 7 - ICMPv6 Type</name>
</t> <dl newline="false" spacing="normal">
<t>Defines a list of {numeric_op, value} pairs used to match the <dt>Encoding:</dt>
type field of an ICMPv6 packet (see also <xref target="RFC4443" /> Section 2 <dd>&lt;type (1 octet), [numeric_op, value]+&gt;</dd>
.1). </dl>
</t> <t>This defines a list of {numeric_op, value} pairs used to match the
<t> Type field of an ICMPv6 packet (see also <xref target="RFC4443" sectionForma
t="of" section="2.1"/>).
</t>
<t>
This component uses the Numeric Operator (numeric_op) described This component uses the Numeric Operator (numeric_op) described
in <xref target="I-D.ietf-idr-rfc5575bis" /> Section 4.2.1.1. in <xref target="RFC8955" sectionFormat="of" section="4.2.1.1"/>.
Type 7 component values SHOULD be encoded as single octet Type 7 component values <bcp14>SHOULD</bcp14> be encoded as a single oct
et
(numeric_op len=00). (numeric_op len=00).
</t> </t>
<t> <t>
In case of the presence of the ICMPv6 Type In case of the presence of the ICMPv6 type
component only ICMPv6 packets can match the entire Flow Specification. component, only ICMPv6 packets can match the entire Flow Specification.
The ICMPv6 Type component, if present, never matches when the packet's The ICMPv6 type component, if present, never matches when the packet's
upper-layer IP protocol value is not 58 (ICMPv6), if the packet is fragm ented upper-layer IP protocol value is not 58 (ICMPv6), if the packet is fragm ented
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. able to decode the transport header.
</t> </t>
</section> </section>
<section anchor="type_8" title="Type 8 - ICMPv6 Code" toc="include"> <section anchor="type_8" toc="include" numbered="true">
<t>Encoding: &lt;type (1 octet), [numeric_op, value]+&gt; <name>Type 8 - ICMPv6 Code</name>
</t> <dl newline="false" spacing="normal">
<t> <dt>Encoding:</dt>
Defines a list of {numeric_op, value} pairs used to match the <dd>&lt;type (1 octet), [numeric_op, value]+&gt;</dd>
code field of an ICMPv6 packet (see also <xref target="RFC4443" /> Section 2 </dl>
.1). <t>
</t> This defines a list of {numeric_op, value} pairs used to match the
<t> code field of an ICMPv6 packet (see also <xref target="RFC4443" sectionForma
t="of" section="2.1"/>).
</t>
<t>
This component uses the Numeric Operator (numeric_op) described This component uses the Numeric Operator (numeric_op) described
in <xref target="I-D.ietf-idr-rfc5575bis" /> Section 4.2.1.1. in <xref target="RFC8955" sectionFormat="of" section="4.2.1.1"/>.
Type 8 component values SHOULD be encoded as single octet Type 8 component values <bcp14>SHOULD</bcp14> be encoded as a single oct
et
(numeric_op len=00). (numeric_op len=00).
</t> </t>
<t> <t>
In case of the presence of the ICMPv6 Code In case of the presence of the ICMPv6 code
component only ICMPv6 packets can match the entire Flow Specification. component, only ICMPv6 packets can match the entire Flow Specification.
The ICMPv6 code component, if present, never matches when the packet's The ICMPv6 code component, if present, never matches when the packet's
upper-layer IP protocol value is not 58 (ICMPv6), if the packet is fragm ented upper-layer IP protocol value is not 58 (ICMPv6), if the packet is fragm ented
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. able to decode the transport header.
</t> </t>
</section> </section>
<section anchor="type_12 " title="Type 12 - Fragment"> <section anchor="type_12" numbered="true" toc="default">
<t>Encoding: &lt;type (1 octet), [bitmask_op, bitmask]+&gt; <name>Type 12 - Fragment</name>
</t> <dl newline="false" spacing="normal">
<t> Defines a list of {bitmask_op, bitmask} pairs used to match specific I <dt>Encoding:</dt>
P fragments. <dd>&lt;type (1 octet), [bitmask_op, bitmask]+&gt;</dd>
</t> </dl>
<t>This component uses the Bitmask Operator (bitmask_op) described <t>This defines a list of {bitmask_op, bitmask} pairs used to match spec
in <xref target="I-D.ietf-idr-rfc5575bis" /> Section 4.2.1.2. The ific IP fragments.</t>
Type 12 component bitmask MUST be encoded as single octet bitmask <t>This component uses the Bitmask Operator (bitmask_op) described
in <xref target="RFC8955" sectionFormat="of" section="4.2.1.2"/>. The
Type 12 component bitmask <bcp14>MUST</bcp14> be encoded as a single octet
bitmask
(bitmask_op len=00). (bitmask_op len=00).
</t> </t>
<t> <figure anchor="figure_fragment_bitmask_operand">
<figure title="Fragment Bitmask Operand" anchor="figure_fragment_bitmask <name>Fragment Bitmask Operand</name>
_operand"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork>
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 0 |LF |FF |IsF| 0 | | 0 | 0 | 0 | 0 |LF |FF |IsF| 0 |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
</artwork> ]]></artwork>
</figure> </figure>
</t>
<t>Bitmask values: <t>Bitmask values:
<list style="hanging">
<t hangText="IsF -">Is a fragment other than the first - match if IPv6 F
ragment Header (<xref target="RFC8200" /> Section 4.5)
Fragment Offset is not 0
</t>
<t hangText="FF -">First fragment - match if IPv6 Fragment Header (<xref
target="RFC8200" /> Section 4.5)
Fragment Offset is 0 AND M flag is 1
</t>
<t hangText="LF -">Last fragment - match if IPv6 Fragment Header (<xref
target="RFC8200" /> Section 4.5)
Fragment Offset is not 0 AND M flag is 0
</t> </t>
<t hangText="0 -">MUST be set to 0 on NLRI encoding, and MUST be ignored <dl newline="false" spacing="normal" indent="6">
during decoding <dt>IsF:</dt>
</t> <dd>Is a fragment other than the first -- match if IPv6 Fragment Heade
</list> r
(<xref target="RFC8200" sectionFormat="of" section="4.5"/>) Fragment Of
fset is not 0</dd>
<dt>FF:</dt>
<dd>First fragment -- match if IPv6 Fragment Header (<xref target="RFC
8200" sectionFormat="of"
section="4.5"/>) Fragment Offset is 0 AND M flag is 1</dd>
<dt>LF:</dt>
<dd>Last fragment -- match if IPv6 Fragment Header (<xref target="RFC8
200" sectionFormat="of"
section="4.5"/>) Fragment Offset is not 0 AND M flag is 0</dd>
<dt>0:</dt>
<dd><bcp14>MUST</bcp14> be set to 0 on NLRI encoding and <bcp14>MUST</
bcp14> be ignored
during decoding</dd>
</dl>
</section>
<section anchor="type_13" numbered="true" toc="default">
<name>Type 13 - Flow Label (new)</name>
<dl newline="false" spacing="normal">
<dt>Encoding:</dt>
<dd>&lt;type (1 octet), [numeric_op, value]+&gt;</dd>
</dl>
<t>This contains a list of {numeric_op, value} pairs that are used to ma
tch
the 20-bit Flow Label IPv6 header field (<xref target="RFC8200" sectionFor
mat="of" section="3"/>).
</t> </t>
</section> <t>This component uses the Numeric Operator (numeric_op) described in
<section anchor="type_13" title="Type 13 - Flow Label (new)"> <xref target="RFC8955" sectionFormat="of" section="4.2.1.1"/>. Type 13
<t>Encoding: &lt;type (1 octet), [numeric_op, value]+&gt; component values <bcp14>SHOULD</bcp14> be encoded as 4-octet quantities
</t>
<t>Contains a list of {numeric_op, value} pairs that are used to match
the 20-bit Flow Label IPv6 header field (<xref target="RFC8200"></xref>
Section 3).
</t>
<t>This component uses the Numeric Operator (numeric_op) described in
<xref target="I-D.ietf-idr-rfc5575bis" /> Section 4.2.1.1. Type 13
component values SHOULD be encoded as 4-octet quantities
(numeric_op len=10). (numeric_op len=10).
</t> </t>
</section> </section>
<section title="Encoding Example" anchor="examples"> <section anchor="examples" numbered="true" toc="default">
<section title="Example 1" toc="exclude"> <name>Encoding Examples</name>
<t> <section numbered="true">
The following example demonstrates the prefix encoding for: <name>Example 1</name>
"packets from ::1234:5678:9a00:0/64-104 to 2001:db8::/32 and upper-layer-prot <t>
ocol tcp". The following example demonstrates the prefix encoding for
</t> packets from ::1234:5678:9a00:0/64-104 to 2001:db8::/32 and upper-layer proto
<t> col tcp.
<figure> </t>
<artwork>
+--------+----------------------+-------------------------+----------+ <table anchor="example-1" align="left">
| length | destination | source | ul-proto | <thead>
+--------+----------------------+-------------------------+----------+ <tr>
| 0x12 | 01 20 00 20 01 0D B8 | 02 68 40 12 34 56 78 9A | 03 81 06 | <th>len</th>
+--------+----------------------+-------------------------+----------+ <th>destination</th>
</artwork> <th>source</th>
</figure> <th>ul-proto</th>
</t> </tr>
<t> </thead>
Decoded: <tbody>
<figure> <tr>
<artwork> <td>0x12</td>
+-------+------------+-------------------------------+ <td>01 20 00 20 01 0D B8</td>
| Value | | | <td>02 68 40 12 34 56 78 9A</td>
+-------+------------+-------------------------------+ <td>03 81 06</td>
| 0x12 | length | 18 octets (len&lt;240 1-octet) | </tr>
| 0x01 | type | Type 1 - Dest. IPv6 Prefix | </tbody>
| 0x20 | length | 32 bit | </table>
| 0x00 | offset | 0 bit | <t>Decoded:</t>
| 0x20 | pattern | | <table anchor="example-1-decoded" align="left">
| 0x01 | pattern | | <thead>
| 0x0D | pattern | | <tr>
| 0xB8 | pattern | (no padding needed) | <th>Value</th>
| 0x02 | type | Type 2 - Source IPv6 Prefix | <th></th>
| 0x68 | length | 104 bit | <th></th>
| 0x40 | offset | 64 bit | </tr>
| 0x12 | pattern | | </thead>
| 0x34 | pattern | | <tbody>
| 0x56 | pattern | | <tr>
| 0x78 | pattern | | <td>0x12</td>
| 0x9A | pattern | (no padding needed) | <td>length</td>
| 0x03 | type | Type 3 - upper-layer-proto | <td>18 octets (if len&lt;240, 1 octet)</td>
| 0x81 | numeric_op | end-of-list, value size=1, == | </tr>
| 0x06 | value | 06 | <tr>
+-------+------------+-------------------------------+ <td>0x01</td>
</artwork> <td>type</td>
</figure> <td>Type 1 - Dest.&nbsp;IPv6 Prefix</td>
This constitutes a NLRI with a NLRI length of 18 octets. </tr>
</t> <tr>
<t> <td>0x20</td>
<td>length</td>
<td>32 bits</td>
</tr>
<tr>
<td>0x00</td>
<td>offset</td>
<td>0 bits</td>
</tr>
<tr>
<td>0x20</td>
<td>pattern</td>
<td></td>
</tr>
<tr>
<td>0x01</td>
<td>pattern</td>
<td></td>
</tr>
<tr>
<td>0x0D</td>
<td>pattern</td>
<td></td>
</tr>
<tr>
<td>0xB8</td>
<td>pattern</td>
<td>(no padding needed)</td>
</tr>
<tr>
<td>0x02</td>
<td>type</td>
<td>Type 2 - Source IPv6 Prefix</td>
</tr>
<tr>
<td>0x68</td>
<td>length</td>
<td>104 bits</td>
</tr>
<tr>
<td>0x40</td>
<td>offset</td>
<td>64 bits</td>
</tr>
<tr>
<td>0x12</td>
<td>pattern</td>
<td></td>
</tr>
<tr>
<td>0x34</td>
<td>pattern</td>
<td></td>
</tr>
<tr>
<td>0x56</td>
<td>pattern</td>
<td></td>
</tr>
<tr>
<td>0x78</td>
<td>pattern</td>
<td></td>
</tr>
<tr>
<td>0x9A</td>
<td>pattern</td>
<td>(no padding needed)</td>
</tr>
<tr>
<td>0x03</td>
<td>type</td>
<td>Type 3 - Upper-Layer Protocol</td>
</tr>
<tr>
<td>0x81</td>
<td>numeric_op</td>
<td>end-of-list, value size=1, ==</td>
</tr>
<tr>
<td>0x06</td>
<td>value</td>
<td>06</td>
</tr>
</tbody>
</table>
<t>This constitutes an NLRI with an NLRI length of 18 octets.</t>
<t>
Padding is not needed either for the destination prefix pattern Padding is not needed either for the destination prefix pattern
(length - offset = 32 bit) or for the source prefix pattern (length - offset = 32 bits) or for the source prefix pattern
(length - offset = 40 bit), as both patterns end on an octet (length - offset = 40 bits), as both patterns end on an octet
boundary. boundary.
</t> </t>
</section> </section>
<section title="Example 2" toc="exclude"> <section numbered="true">
<t> <name>Example 2</name>
The following example demonstrates the prefix encoding for: "all <t>
packets from ::1234:5678:9a00:0/65-104 to 2001:db8::/32". The following example demonstrates the prefix encoding for all
</t> packets from ::1234:5678:9a00:0/65-104 to 2001:db8::/32.
<t>
<figure>
<artwork>
+--------+----------------------+-------------------------+
| length | destination | source |
+--------+----------------------+-------------------------+
| 0x0f | 01 20 00 20 01 0D B8 | 02 68 41 24 68 ac f1 34 |
+--------+----------------------+-------------------------+
</artwork>
</figure>
</t>
<t>
Decoded:
<figure>
<artwork>
+-------+-------------+-------------------------------+
| Value | | |
+-------+-------------+-------------------------------+
| 0x0f | length | 15 octets (len&lt;240 1-octet) |
| 0x01 | type | Type 1 - Dest. IPv6 Prefix |
| 0x20 | length | 32 bit |
| 0x00 | offset | 0 bit |
| 0x20 | pattern | |
| 0x01 | pattern | |
| 0x0D | pattern | |
| 0xB8 | pattern | (no padding needed) |
| 0x02 | type | Type 2 - Source IPv6 Prefix |
| 0x68 | length | 104 bit |
| 0x41 | offset | 65 bit |
| 0x24 | pattern | |
| 0x68 | pattern | |
| 0xac | pattern | |
| 0xf1 | pattern | |
| 0x34 | pattern/pad | (contains 1 bit padding) |
+-------+-------------+-------------------------------+
</artwork>
</figure>
This constitutes a NLRI with a NLRI length of 15 octets.
</t> </t>
<t> <table anchor="example-2" align="left">
<thead>
<tr>
<th>length</th>
<th>destination</th>
<th>source</th>
</tr>
</thead>
<tbody>
<tr>
<td>0x0f</td>
<td>01 20 00 20 01 0D B8</td>
<td>02 68 41 24 68 ac f1 34</td>
</tr>
</tbody>
</table>
<t>Decoded:</t>
<table anchor="example-2-decoded" align="left">
<thead>
<tr>
<th>Value</th>
<th></th>
<th></th>
</tr>
</thead>
<tbody>
<tr>
<td>0x0f</td>
<td>length</td>
<td>15 octets (if len&lt;240, 1 octet)</td>
</tr>
<tr>
<td>0x01</td>
<td>type</td>
<td>Type 1 - Dest.&nbsp;IPv6 Prefix</td>
</tr>
<tr>
<td>0x20</td>
<td>length</td>
<td>32 bits</td>
</tr>
<tr>
<td>0x00</td>
<td>offset</td>
<td>0 bits</td>
</tr>
<tr>
<td>0x20</td>
<td>pattern</td>
<td></td>
</tr>
<tr>
<td>0x01</td>
<td>pattern</td>
<td></td>
</tr>
<tr>
<td>0x0D</td>
<td>pattern</td>
<td></td>
</tr>
<tr>
<td>0xB8</td>
<td>pattern</td>
<td>(no padding needed)</td>
</tr>
<tr>
<td>0x02</td>
<td>type</td>
<td>Type 2 - Source IPv6 Prefix</td>
</tr>
<tr>
<td>0x68</td>
<td>length</td>
<td>104 bits</td>
</tr>
<tr>
<td>0x41</td>
<td>offset</td>
<td>65 bits</td>
</tr>
<tr>
<td>0x24</td>
<td>pattern</td>
<td></td>
</tr>
<tr>
<td>0x68</td>
<td>pattern</td>
<td></td>
</tr>
<tr>
<td>0xac</td>
<td>pattern</td>
<td></td>
</tr>
<tr>
<td>0xf1</td>
<td>pattern</td>
<td></td>
</tr>
<tr>
<td>0x34</td>
<td>pattern/pad</td>
<td>(contains 1 bit of padding)</td>
</tr>
</tbody>
</table>
<t>This constitutes an NLRI with an NLRI length of 15 octets.</t>
<t>
The source prefix pattern is 104 - 65 = 39 bits in length. The source prefix pattern is 104 - 65 = 39 bits in length.
After the pattern one bit of padding needs to be added so that the After the pattern, one bit of padding needs to be added so that the
component ends on a octet boundary. However, only the first 39 bits component ends on an octet boundary. However, only the first 39 bits
are actually used for bitwise pattern matching starting with a 65 bit are actually used for bitwise pattern matching, starting with a 65-bit
offset from the topmost bit of the address. offset from the topmost bit of the address.
</t> </t>
</section> </section>
</section>
</section> </section>
</section> <section numbered="true" toc="default">
<section title="Ordering of Flow Specifications"> <name>Ordering of Flow Specifications</name>
<t> <t>
The definition for the order of traffic filtering rules from The definition for the order of traffic filtering rules from
<xref target="I-D.ietf-idr-rfc5575bis" /> Section 5.1 is <xref target="RFC8955" sectionFormat="of" section="5.1"/> is
reused with new consideration for the IPv6 prefix offset. As long reused with new consideration for the IPv6 prefix offset. As long
as the offsets are equal, the comparison is the same, retaining as the offsets are equal, the comparison is the same, retaining
longest-prefix-match semantics. If the offsets are not equal, the longest-prefix-match semantics. If the offsets are not equal, the
lowest offset has precedence, as this Flow Specification matches the most lowest offset has precedence, as this Flow Specification matches the most si
significant bit. gnificant bit.
</t> </t>
<t> <t>
The code in <xref target="flow_rule_cmp_src" /> shows a Python3 implementa The code in <xref target="flow_rule_cmp_src" format="default"/> shows a Py
tion thon3 implementation
of the resulting comparison algorithm. The full code was tested with Pytho n 3.7.2 and can be of the resulting comparison algorithm. The full code was tested with Pytho n 3.7.2 and can be
obtained at <eref target="https://github.com/stoffi92/draft-ietf-idr-flow- obtained at <eref target="https://github.com/stoffi92/draft-ietf-idr-flow-
spec-v6/tree/master/flowspec-cmp">https://github.com/stoffi92/draft-ietf-idr-flo spec-v6/tree/master/flowspec-cmp" brackets="angle"/>.
w-spec-v6/tree/master/flowspec-cmp</eref>. </t>
</t> </section>
</section> <section numbered="true" toc="default">
<section title="Validation Procedure"> <name>Validation Procedure</name>
<t> <t>
The validation procedure is the same as specified in The validation procedure is the same as specified in
<xref target="I-D.ietf-idr-rfc5575bis" /> Section 6 with the exception <xref target="RFC8955" sectionFormat="of" section="6"/> with the exception
that item a) of the validation procedure should now read as follows: that item a) of the validation procedure should now read as follows:
<list> </t>
<t> <blockquote>
a) A destination prefix component with offset=0 is embedded in the <ol type="%c)">
Flow Specification <li>A destination prefix component with offset=0 is embedded in the
</t> Flow Specification</li>
</list> </ol>
</t> </blockquote>
</section> </section>
<section title="IPv6 Traffic Filtering Action changes"> <section numbered="true" toc="default">
<t>Traffic Filtering Actions from <xref target="I-D.ietf-idr-rfc5575bis" <name>IPv6 Traffic Filtering Action Changes</name>
/> <t>Traffic Filtering Actions from <xref target="RFC8955" sectionFormat="of
Section 7 can also be applied to IPv6 Flow Specifications. To allow " section="7"/>
can also be applied to IPv6 Flow Specifications. To allow
an IPv6-Address-Specific Route-Target, a new Traffic Filtering an IPv6-Address-Specific Route-Target, a new Traffic Filtering
Action IPv6-Address-Specific Extended Community <xref target="RFC5701">< Action IPv6-Address-Specific Extended Community is specified in
/xref> is specified in <xref target="redirect_ipv6" format="default"/> below.
<xref target="redirect_ipv6" /> below. </t>
</t> <section anchor="redirect_ipv6" numbered="true" toc="default">
<section anchor="redirect_ipv6" title="Redirect IPv6 (rt-redirect-ipv6) Type <name>Redirect IPv6 (rt-redirect-ipv6) Type 0x000d</name>
TBD"> <t>The redirect IPv6-Address-Specific Extended Community
<t>The redirect IPv6-Address-Specific Extended Community
allows the traffic to be redirected to a VRF routing instance that allows the traffic to be redirected to a VRF routing instance that
lists the specified IPv6-Address-Specific Route-Target in its import lists the specified IPv6-Address-Specific Route-Target in its import
policy. If several local instances match this criteria, the choice policy. If several local instances match this criteria, the choice
between them is a local matter (for example, the instance with the between them is a local matter (for example, the instance with the
lowest Route Distinguisher value can be elected). lowest Route Distinguisher value can be elected).
</t>
<t>This IPv6-Address-Specific Extended Community uses the same encoding a
s the
IPv6-Address-Specific Route-Target Extended Community
<xref target="RFC5701"></xref> Section 2 with the
Type value always TBD.
</t>
<t>The Local Administrator sub-field contains a number from a numbering
space that is administered by the organization to which the IP
address carried in the Global Administrator sub-field has been
assigned by an appropriate authority.
</t>
<t>Interferes with: All BGP Flow Specification redirect Traffic Filtering
Actions (with itself and those specified in
<xref target="I-D.ietf-idr-rfc5575bis" /> Section 7.4).
</t>
</section>
</section>
<section title="Security Considerations">
<t>
This document extends the functionality in <xref target="I-D.ietf-idr-rfc5575
bis" /> to be applicable to
IPv6 data packets. The same Security Considerations from <xref target="I-D.ie
tf-idr-rfc5575bis" />
now also apply to IPv6 networks.
</t>
<t>
<xref target="RFC7112" /> describes the impact of oversized IPv6 header chain
s when trying to match on the transport
header; <xref target="RFC8200" /> Section 4.5 also requires that the first fr
agment must include the upper-layer
header but there could be wrongly formatted packets not respecting <xref targ
et="RFC8200" />. IPv6 Flow Specification
component type 3 (<xref target="type_3"/>) will not be enforced for those ill
egal packets. Moreover,
there are hardware limitations in several routers (<xref target="RFC8883" />
Section 1) that may make it impossible to
enforce a policy signaled by a type 3 Flow Specification component or Flow Sp
ecification components
that match on upper-layer properties of the packet.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This section complies with <xref target="RFC7153"></xref>.
</t>
<section title="Flow Spec IPv6 Component Types">
<t>
IANA has created and maintains a registry entitled "Flow Spec Component Type
s".
IANA is requested to add [this document] to the reference for this registry.
Furthermore the registry should be rewritten to also contain the IPv6 Flow S
pecification
Component Types as described below. The registration procedure should remain
unchanged.
</t>
<section title="Registry Template">
<t>
<list style="hanging" hangIndent="6">
<t hangText="Type Value:">
<vspace />
Contains the assigned Flow Specification component type value.
</t>
<t hangText="IPv4 Name:">
<vspace />
Contains the associated IPv4 Flow Specification component name as specif
ied in
<xref target="I-D.ietf-idr-rfc5575bis" />.
</t>
<t hangText="IPv6 Name:">
<vspace />
Contains the associated IPv6 Flow Specification component name as specif
ied in
this document.
</t>
<t hangText="Reference:">
<vspace />
Contains referenced to the specifications.
</t>
</list>
</t>
</section>
<section title="Registry Contents">
<t>
<list>
<t>
+ Type Value: 0<vspace/>
+ IPv4 Name: Reserved<vspace/>
+ IPv6 Name: Reserved<vspace/>
+ Reference: <xref target="I-D.ietf-idr-rfc5575bis" /> [this document]<v
space/>
</t>
<t>
+ Type Value: 1<vspace/>
+ IPv4 Name: Destination Prefix<vspace/>
+ IPv6 Name: Destination IPv6 Prefix<vspace/>
+ Reference: <xref target="I-D.ietf-idr-rfc5575bis" /> [this document]<v
space/>
</t>
<t>
+ Type Value: 2<vspace/>
+ IPv4 Name: Source Prefix<vspace/>
+ IPv6 Name: Source IPv6 Prefix<vspace/>
+ Reference: <xref target="I-D.ietf-idr-rfc5575bis" /> [this document]<v
space/>
</t>
<t>
+ Type Value: 3<vspace/>
+ IPv4 Name: IP Protocol<vspace/>
+ IPv6 Name: Upper-Layer Protocol<vspace/>
+ Reference: <xref target="I-D.ietf-idr-rfc5575bis" /> [this document]<v
space/>
</t>
<t>
+ Type Value: 4<vspace/>
+ IPv4 Name: Port<vspace/>
+ IPv6 Name: Port<vspace/>
+ Reference: <xref target="I-D.ietf-idr-rfc5575bis" /> [this document]<v
space/>
</t>
<t>
+ Type Value: 5<vspace/>
+ IPv4 Name: Destination Port<vspace/>
+ IPv6 Name: Destination Port<vspace/>
+ Reference: <xref target="I-D.ietf-idr-rfc5575bis" /> [this document]<v
space/>
</t>
<t>
+ Type Value: 6<vspace/>
+ IPv4 Name: Source Port<vspace/>
+ IPv6 Name: Source Port<vspace/>
+ Reference: <xref target="I-D.ietf-idr-rfc5575bis" /> [this document]<v
space/>
</t>
<t>
+ Type Value: 7<vspace/>
+ IPv4 Name: ICMP Type<vspace/>
+ IPv6 Name: ICMPv6 Type<vspace/>
+ Reference: <xref target="I-D.ietf-idr-rfc5575bis" /> [this document]<v
space/>
</t>
<t>
+ Type Value: 8<vspace/>
+ IPv4 Name: ICMP Code<vspace/>
+ IPv6 Name: ICMPv6 Code<vspace/>
+ Reference: <xref target="I-D.ietf-idr-rfc5575bis" /> [this document]<v
space/>
</t> </t>
<t> <t>This IPv6-Address-Specific Extended Community uses the same encoding
+ Type Value: 9<vspace/> as the IPv6-Address-Specific
+ IPv4 Name: TCP Flags<vspace/> Route-Target Extended Community
+ IPv6 Name: TCP Flags<vspace/> (<xref target="RFC5701" sectionFormat="of" section="2"/>) with the
+ Reference: <xref target="I-D.ietf-idr-rfc5575bis" /> [this document]<v Type value always 0x000d.
space/>
</t>
<t>
+ Type Value: 10<vspace/>
+ IPv4 Name: Packet Length<vspace/>
+ IPv6 Name: Packet Length<vspace/>
+ Reference: <xref target="I-D.ietf-idr-rfc5575bis" /> [this document]<v
space/>
</t>
<t>
+ Type Value: 11<vspace/>
+ IPv4 Name: DSCP<vspace/>
+ IPv6 Name: DSCP<vspace/>
+ Reference: <xref target="I-D.ietf-idr-rfc5575bis" /> [this document]<v
space/>
</t>
<t>
+ Type Value: 12<vspace/>
+ IPv4 Name: Fragment<vspace/>
+ IPv6 Name: Fragment<vspace/>
+ Reference: <xref target="I-D.ietf-idr-rfc5575bis" /> [this document]<v
space/>
</t> </t>
<t> <t>The Local Administrator subfield contains a number from a numbering
+ Type Value: 13<vspace/> space that is administered by the organization to which the IP
+ IPv4 Name: Unassigned<vspace/> address carried in the Global Administrator subfield has been
+ IPv6 Name: Flow Label<vspace/> assigned by an appropriate authority.
+ Reference: [this document]<vspace/>
</t> </t>
<t> <t>Interferes with: All BGP Flow Specification redirect Traffic Filterin
+ Type Value: 14-254<vspace/> g
+ IPv4 Name: Unassigned<vspace/> Actions (with itself and those specified in
+ IPv6 Name: Unassigned<vspace/> <xref target="RFC8955" sectionFormat="of" section="7.4"/>).
+ Reference: <vspace/>
</t> </t>
</section>
</section>
<section numbered="true" toc="default">
<name>Security Considerations</name>
<t>This document extends the functionality in <xref target="RFC8955" forma
t="default"/>
to be applicable to IPv6 data packets. The same security considerations fr
om <xref
target="RFC8955" format="default"/> now also apply to IPv6 networks.</t>
<t><xref target="RFC7112" format="default"/> describes the impact of overs
ized
IPv6 header chains when trying to match on the transport header; <xref tar
get="RFC8200"
sectionFormat="of" section="4.5"/> also requires that the first fragment m
ust include
the upper-layer header, but there could be wrongly formatted packets not r
especting <xref
target="RFC8200" format="default"/>. IPv6 Flow Specification component Typ
e 3 (<xref
target="type_3" format="default"/>) will not be enforced for those illegal
packets.
Moreover, there are hardware limitations in several routers (<xref target=
"RFC8883"
sectionFormat="of" section="1"/>) that may make it impossible to enforce a
policy signaled
by a Type 3 Flow Specification component or Flow Specification components
that match on
upper-layer properties of the packet.</t>
</section>
<section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This section complies with <xref target="RFC7153" format="default"/>.
</t>
<section numbered="true" toc="default">
<name>Flow Spec IPv6 Component Types</name>
<t> <t>
+ Type Value: 255<vspace/> IANA has created and maintains a registry entitled "Flow Spec Component Type
+ IPv4 Name: Reserved<vspace/> s".
+ IPv6 Name: Reserved<vspace/> IANA has added this document as a reference for that registry.
+ Reference: <xref target="I-D.ietf-idr-rfc5575bis" /> [this document]<v Furthermore, the registry has been updated to also contain the IPv6 Flow Spe
space/> cification
Component Types as described below. The registration procedure remains uncha
nged.
</t> </t>
</list> <section numbered="true" toc="default">
</t> <name>Registry Template</name>
</section> <dl newline="false" spacing="normal" indent="13">
<dt>Type Value:</dt>
<dd>contains the assigned Flow Specification component type value</d
d>
<dt>IPv4 Name:</dt>
<dd>contains the associated IPv4 Flow Specification component name a
s specified in
<xref target="RFC8955" format="default"/></dd>
<dt>IPv6 Name:</dt>
<dd>contains the associated IPv6 Flow Specification component name a
s specified in
this document</dd>
<dt>Reference:</dt>
<dd>contains references to the specifications</dd>
</dl>
</section>
<section numbered="true" toc="default">
<name>Registry Contents</name>
<dl newline="false" spacing="compact" indent="13">
<dt>Type Value:</dt>
<dd>0</dd>
<dt>IPv4 Name:</dt>
<dd>Reserved</dd>
<dt>IPv6 Name:</dt>
<dd>Reserved</dd>
<dt>Reference:</dt>
<dd><xref target="RFC8955" format="default"/>, RFC 8956</dd>
</dl>
<dl newline="false" spacing="compact" indent="13">
<dt>Type Value:</dt>
<dd>1</dd>
<dt>IPv4 Name:</dt>
<dd>Destination Prefix</dd>
<dt>IPv6 Name:</dt>
<dd>Destination IPv6 Prefix</dd>
<dt>Reference:</dt>
<dd><xref target="RFC8955" format="default"/>, RFC 8956</dd>
</dl>
<dl newline="false" spacing="compact" indent="13">
<dt>Type Value:</dt>
<dd>2</dd>
<dt>IPv4 Name:</dt>
<dd>Source Prefix</dd>
<dt>IPv6 Name:</dt>
<dd>Source IPv6 Prefix</dd>
<dt>Reference:</dt>
<dd><xref target="RFC8955" format="default"/>, RFC 8956</dd>
</dl>
<dl newline="false" spacing="compact" indent="13">
<dt>Type Value:</dt>
<dd>3</dd>
<dt>IPv4 Name:</dt>
<dd>IP Protocol</dd>
<dt>IPv6 Name:</dt>
<dd>Upper-Layer Protocol</dd>
<dt>Reference:</dt>
<dd><xref target="RFC8955" format="default"/>, RFC 8956</dd>
</dl>
<dl newline="false" spacing="compact" indent="13">
<dt>Type Value:</dt>
<dd>4</dd>
<dt>IPv4 Name:</dt>
<dd>Port</dd>
<dt>IPv6 Name:</dt>
<dd>Port</dd>
<dt>Reference:</dt>
<dd><xref target="RFC8955" format="default"/>, RFC 8956</dd>
</dl>
<dl newline="false" spacing="compact" indent="13">
<dt>Type Value:</dt>
<dd>5</dd>
<dt>IPv4 Name:</dt>
<dd>Destination Port</dd>
<dt>IPv6 Name:</dt>
<dd>Destination Port</dd>
<dt>Reference:</dt>
<dd><xref target="RFC8955" format="default"/>, RFC 8956</dd>
</dl>
<dl newline="false" spacing="compact" indent="13">
<dt>Type Value:</dt>
<dd>6</dd>
<dt>IPv4 Name:</dt>
<dd>Source Port</dd>
<dt>IPv6 Name:</dt>
<dd>Source Port</dd>
<dt>Reference:</dt>
<dd><xref target="RFC8955" format="default"/>, RFC 8956</dd>
</dl>
<dl newline="false" spacing="compact" indent="13">
<dt>Type Value:</dt>
<dd>7</dd>
<dt>IPv4 Name:</dt>
<dd>ICMP Type</dd>
<dt>IPv6 Name:</dt>
<dd>ICMPv6 Type</dd>
<dt>Reference:</dt>
<dd><xref target="RFC8955" format="default"/>, RFC 8956</dd>
</dl>
<dl newline="false" spacing="compact" indent="13">
<dt>Type Value:</dt>
<dd>8</dd>
<dt>IPv4 Name:</dt>
<dd>ICMP Code</dd>
<dt>IPv6 Name:</dt>
<dd>ICMPv6 Code</dd>
<dt>Reference:</dt>
<dd><xref target="RFC8955" format="default"/>, RFC 8956</dd>
</dl>
<dl newline="false" spacing="compact" indent="13">
<dt>Type Value:</dt>
<dd>9</dd>
<dt>IPv4 Name:</dt>
<dd>TCP Flags</dd>
<dt>IPv6 Name:</dt>
<dd>TCP Flags</dd>
<dt>Reference:</dt>
<dd><xref target="RFC8955" format="default"/>, RFC 8956</dd>
</dl>
<dl newline="false" spacing="compact" indent="13">
<dt>Type Value:</dt>
<dd>10</dd>
<dt>IPv4 Name:</dt>
<dd>Packet Length</dd>
<dt>IPv6 Name:</dt>
<dd>Packet Length</dd>
<dt>Reference:</dt>
<dd><xref target="RFC8955" format="default"/>, RFC 8956</dd>
</dl>
<dl newline="false" spacing="compact" indent="13">
<dt>Type Value:</dt>
<dd>11</dd>
<dt>IPv4 Name:</dt>
<dd>DSCP</dd>
<dt>IPv6 Name:</dt>
<dd>DSCP</dd>
<dt>Reference:</dt>
<dd><xref target="RFC8955" format="default"/>, RFC 8956</dd>
</dl>
<dl newline="false" spacing="compact" indent="13">
<dt>Type Value:</dt>
<dd>12</dd>
<dt>IPv4 Name:</dt>
<dd>Fragment</dd>
<dt>IPv6 Name:</dt>
<dd>Fragment</dd>
<dt>Reference:</dt>
<dd><xref target="RFC8955" format="default"/>, RFC 8956</dd>
</dl>
<dl newline="false" spacing="compact" indent="13">
<dt>Type Value:</dt>
<dd>13</dd>
<dt>IPv4 Name:</dt>
<dd>Unassigned</dd>
<dt>IPv6 Name:</dt>
<dd>Flow Label</dd>
<dt>Reference:</dt>
<dd>RFC 8956</dd>
</dl>
</section> <dl newline="false" spacing="compact" indent="13">
<section title="IPv6-Address-Specific Extended Community Flow Spec IPv6 Acti <dt>Type Value:</dt>
ons"> <dd>14-254</dd>
<t> <dt>IPv4 Name:</dt>
<dd>Unassigned</dd>
<dt>IPv6 Name:</dt>
<dd>Unassigned</dd>
</dl>
<dl newline="false" spacing="compact" indent="13">
<dt>Type Value:</dt>
<dd>255</dd>
<dt>IPv4 Name:</dt>
<dd>Reserved</dd>
<dt>IPv6 Name:</dt>
<dd>Reserved</dd>
<dt>Reference:</dt>
<dd><xref target="RFC8955" format="default"/>, RFC 8956</dd>
</dl>
</section>
</section>
<section numbered="true" toc="default">
<name>IPv6-Address-Specific Extended Community Flow Spec IPv6 Actions</n
ame>
<t>
IANA maintains a registry entitled "Transitive IPv6-Address-Specific IANA maintains a registry entitled "Transitive IPv6-Address-Specific
Extended Community Types". For the purpose of Extended Community Types". For the purpose of
this work, IANA is requested to assign a new value: this work, IANA has assigned a new value:
</t> </t>
<texttable anchor="iana_ext_comm_types" title="Registry: Transitive IPv6-Addr <table anchor="iana_ext_comm_subtypes" align="center">
ess-Specific Extended Community Types"> <name>Transitive IPv6-Address-Specific Extended Community Types Regist
<ttcol align="left">Type Value</ttcol> ry</name>
<ttcol align="left">Name</ttcol> <thead>
<ttcol align="left">Reference</ttcol> <tr>
<c>TBD</c> <th align="left">Type Value</th>
<c>Flow spec rt-redirect-ipv6 format</c> <th align="left">Name</th>
<c>[this document]</c> <th align="left">Reference</th>
</texttable> </tr>
</section> </thead>
</section> <tbody>
<section title="Acknowledgements"> <tr>
<t>Authors would like to thank Pedro Marques, Hannes Gredler, Bruno <td align="left">0x000d</td>
Rijsman, Brian Carpenter, and Thomas Mangin for their valuable input. <td align="left">Flow spec rt-redirect-ipv6 format</td>
</t> <td align="left">RFC 8956</td>
</section> </tr>
<section title="Contributors"> </tbody>
<t> </table>
<figure> </section>
<artwork> </section>
Danny McPherson </middle>
Verisign, Inc. <back>
<references>
Email: dmcpherson@verisign.com <name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
</artwork> .2119.xml"/>
</figure> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
</t><t> .4271.xml"/>
<figure> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
<artwork> .4443.xml"/>
Burjiz Pithawala <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
Individual .4760.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
Email: burjizp@gmail.com .5701.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.7112.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.7153.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8200.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8883.xml"/>
</artwork> <!-- draft-ietf-idr-rfc5575bis - RFC-to-be 8955 companion document -->
</figure>
</t><t>
<figure>
<artwork>
Andy Karch
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
USA
Email: akarch@cisco.com <reference anchor='RFC8955' target="https://www.rfc-editor.org/info/rfc8955">
<front>
<title>Dissemination of Flow Specification Rules</title>
<author initials='C' surname='Loibl' fullname='Christoph Loibl'>
<organization />
</author>
<author initials='S' surname='Hares' fullname='Susan Hares'>
<organization />
</author>
<author initials='R' surname='Raszuk' fullname='Robert Raszuk'>
<organization />
</author>
<author initials='D' surname='McPherson' fullname='Danny McPherson'>
<organization />
</author>
<author initials='M' surname='Bacher' fullname='Martin Bacher'>
<organization />
</author>
<date month='December' year='2020' />
</front>
<seriesInfo name="RFC" value="8955"/>
<seriesInfo name="DOI" value="10.17487/RFC8955"/>
</reference>
</artwork> </references>
</figure> <section anchor="flow_rule_cmp_src" numbered="true" toc="default">
</t> <name>Example Python Code: flow_rule_cmp_v6</name>
</section> <sourcecode name="" type="python" markers="true"><![CDATA[
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC4271;
&RFC4443;
&RFC4760;
&RFC5701;
&RFC7112;
&RFC7153;
&RFC8174;
&RFC8200;
&RFC8883;
&I-D.ietf-idr-rfc5575bis;
</references>
<section title="Example python code: flow_rule_cmp_v6" anchor="flow_rule_cmp
_src">
<t>
<figure>
<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 authors
of the code. All rights reserved. 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
(https://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
skipping to change at line 795 skipping to change at line 1017
# use the below algorithm for sorting # use the below algorithm for sorting
result = flow_rule_cmp_v6(self, other) result = flow_rule_cmp_v6(self, other)
if result == B_HAS_PRECEDENCE: if result == B_HAS_PRECEDENCE:
return True return True
else: else:
return False return False
def flow_rule_cmp_v6(a, b): def flow_rule_cmp_v6(a, b):
""" """
Implementation of the flowspec sorting algorithm in Implementation of the flowspec sorting algorithm in
draft-ietf-idr-flow-spec-v6. RFC 8956.
""" """
for comp_a, comp_b in itertools.zip_longest(a.components, for comp_a, comp_b in itertools.zip_longest(a.components,
b.components): b.components):
# If a component type does not exist in one rule # If a component type does not exist in one rule
# this rule has lower precedence # this rule has lower precedence
if not comp_a: if not comp_a:
return B_HAS_PRECEDENCE return B_HAS_PRECEDENCE
if not comp_b: if not comp_b:
return A_HAS_PRECEDENCE return A_HAS_PRECEDENCE
# Higher precedence for lower component type # Higher precedence for lower component type
if comp_a.component_type < comp_b.component_type: if comp_a.component_type < comp_b.component_type:
return A_HAS_PRECEDENCE return A_HAS_PRECEDENCE
if comp_a.component_type > comp_b.component_type: if comp_a.component_type > comp_b.component_type:
return B_HAS_PRECEDENCE return B_HAS_PRECEDENCE
# component types are equal -> type specific comparison # component types are equal -> type-specific comparison
if comp_a.component_type in (IP_DESTINATION, IP_SOURCE): if comp_a.component_type in (IP_DESTINATION, IP_SOURCE):
if comp_a.offset < comp_b.offset: if comp_a.offset < comp_b.offset:
return A_HAS_PRECEDENCE return A_HAS_PRECEDENCE
if comp_a.offset > comp_b.offset: if comp_a.offset > comp_b.offset:
return B_HAS_PRECEDENCE return B_HAS_PRECEDENCE
# both components have the same offset # both components have the same offset
# assuming comp_a.value, comp_b.value of type # assuming comp_a.value, comp_b.value of type
# ipaddress.IPv6Network # ipaddress.IPv6Network
# and the offset bits are reset to 0 (since they are # and the offset bits are reset to 0 (since they are
# not represented in the NLRI) # not represented in the NLRI)
skipping to change at line 860 skipping to change at line 1082
return B_HAS_PRECEDENCE return B_HAS_PRECEDENCE
elif comp_a.value[:common] < \ elif comp_a.value[:common] < \
comp_b.value[:common]: comp_b.value[:common]:
return A_HAS_PRECEDENCE return A_HAS_PRECEDENCE
# the first common bytes match # the first common bytes match
elif len(comp_a.value) > len(comp_b.value): elif len(comp_a.value) > len(comp_b.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> </section>
</figure> <section numbered="false" toc="default">
</t> <name>Acknowledgments</name>
<t>The authors would like to thank <contact fullname="Pedro Marques"/>, <c
ontact
fullname="Hannes Gredler"/>, <contact fullname="Bruno Rijsman"/>, <contact
fullname="Brian Carpenter"/>, and <contact fullname="Thomas Mangin"/> for
their valuable input.
</t>
</section>
<section numbered="false" toc="default">
<name>Contributors</name>
<contact fullname="Danny McPherson">
<organization>Verisign, Inc.</organization>
<address>
<postal/>
<email>dmcpherson@verisign.com</email>
</address>
</contact>
<contact fullname="Burjiz Pithawala">
<organization>Individual</organization>
<address>
<postal/>
<email>burjizp@gmail.com</email>
</address>
</contact>
<contact fullname="Andy Karch">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>United States of America</country>
</postal>
<email>akarch@cisco.com</email>
</address>
</contact>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 72 change blocks. 
698 lines changed or deleted 954 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/