rfc9012xml2.original.xml   rfc9012.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2119.xml">
<!ENTITY RFC5512 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5512.xml">
<!ENTITY RFC7606 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7606.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8174.xml">
<!ENTITY I-D.ietf-bess-evpn-inter-subnet-forwarding SYSTEM "https://xml2rfc.ietf
.org/public/rfc/bibxml3/reference.I-D.ietf-bess-evpn-inter-subnet-forwarding.xml
">
<!--><!ENTITY I-D.ietf-intarea-tunnels SYSTEM "https://xml2rfc.ietf.org/public/r
fc/bibxml3/reference.I-D.ietf-intarea-tunnels.xml">-->
<!ENTITY RFC2474 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2474.xml">
<!ENTITY RFC2784 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2784.xml">
<!ENTITY RFC2890 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2890.xml">
<!ENTITY RFC3032 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3032.xml">
<!ENTITY RFC3270 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3270.xml">
<!ENTITY RFC3931 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3931.xml">
<!ENTITY RFC4023 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4023.xml">
<!ENTITY RFC4364 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4364.xml">
<!ENTITY RFC5129 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5129.xml">
<!ENTITY RFC5462 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5462.xml">
<!ENTITY RFC5565 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5565.xml">
<!ENTITY RFC5566 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5566.xml">
<!ENTITY RFC5640 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5640.xml">
<!ENTITY RFC6514 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6514.xml">
<!ENTITY RFC6811 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6811.xml">
<!ENTITY RFC6890 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6890.xml">
<!ENTITY RFC7348 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7348.xml">
<!ENTITY RFC7510 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7510.xml">
<!ENTITY RFC7637 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7637.xml">
<!ENTITY RFC8205 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8205.xml">
<!ENTITY RFC8277 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8277.xml">
<!ENTITY RFC8669 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8669.xml">
<!ENTITY RFC4271 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4271.xml">
<!ENTITY RFC4272 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4272.xml">
<!ENTITY RFC4760 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4760.xml">
<!ENTITY RFC8126 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8126.xml">
<!ENTITY RFC8365 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8365.xml">
<!ENTITY RFC8402 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8402.xml">
]>
<rfc submissionType="IETF" docName="draft-ietf-idr-tunnel-encaps-22" category="s
td" obsoletes="5512, 5566"
updates="5640">
<!-- Generated by id2xml 1.4.4 on 2019-02-22T16:45:17Z -->
<?rfc compact="yes"?>
<?rfc text-list-symbols="o*+-"?>
<?rfc subcompact="no"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<front>
<title abbrev="Tunnel Encapsulation Attribute">The BGP Tunnel Encapsulati
on Attribute</title>
<author fullname="Keyur Patel" initials="K." surname="Patel"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<organization>Arrcus, Inc</organization>
<address>
<postal><street>2077 Gateway Pl</street>
<street>San Jose, CA 95110</street>
<street>United States</street>
</postal>
<email>keyur@arrcus.com</email>
</address>
</author>
<author fullname="Gunter Van de Velde" initials="G." surname="Van de Veld <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
e"> -ietf-idr-tunnel-encaps-22" number="9012" submissionType="IETF" category="std" c
<organization>Nokia</organization> onsensus="true" obsoletes="5512, 5566" updates="5640" xml:lang="en" sortRefs="tr
<address><postal><street>Copernicuslaan 50</street> ue" symRefs="true" tocInclude="true" version="3">
<street>Antwerpen 2018</street>
<street>Belgium</street>
</postal>
<email>gunter.van_de_velde@nokia.com</email>
</address>
</author>
<author fullname="Srihari R. Sangli" initials="S." surname="Sangli"> <!-- xml2rfc v2v3 conversion 3.5.0 -->
<organization>Juniper Networks</organization> <!-- Generated by id2xml 1.4.4 on 2019-02-22T16:45:17Z -->
<address>
<email>ssangli@juniper.net</email>
</address>
</author>
<author fullname="John Scudder" initials="J." surname="Scudder"> <front>
<organization>Juniper Networks</organization> <title abbrev="Tunnel Encapsulation Attribute">The BGP Tunnel Encapsulation
<address> Attribute</title>
<email>jgs@juniper.net</email> <seriesInfo name="RFC" value="9012"/>
</address> <author fullname="Keyur Patel" initials="K." surname="Patel">
</author> <organization>Arrcus, Inc</organization>
<address>
<postal>
<street>2077 Gateway Pl</street>
<city>San Jose</city>
<region>CA</region>
<code>95110</code>
<country>United States of America</country>
</postal>
<email>keyur@arrcus.com</email>
</address>
</author>
<author fullname="Gunter Van de Velde" initials="G." surname="Van de Velde">
<organization>Nokia</organization>
<address>
<postal>
<street>Copernicuslaan 50</street>
<city>Antwerpen</city>
<code>2018</code>
<country>Belgium</country>
</postal>
<email>gunter.van_de_velde@nokia.com</email>
</address>
</author>
<author fullname="Srihari R. Sangli" initials="S." surname="Sangli">
<organization>Juniper Networks</organization>
<address>
<email>ssangli@juniper.net</email>
</address>
</author>
<author fullname="John Scudder" initials="J." surname="Scudder">
<organization>Juniper Networks</organization>
<address>
<email>jgs@juniper.net</email>
</address>
</author>
<date year="2021" month="April" />
<date/> <keyword>BGP</keyword>
<workgroup>IDR Working Group</workgroup>
<abstract><t> <abstract>
This document defines a BGP Path Attribute known as the <t>
"Tunnel Encapsulation Attribute", which can be used with This document defines a BGP path attribute known as the
BGP UPDATEs of various SAFIs to provide information needed "Tunnel Encapsulation attribute", which can be used with
BGP UPDATEs of various Subsequent Address Family Identifiers (SAFIs) to p
rovide information needed
to create tunnels and their corresponding encapsulation to create tunnels and their corresponding encapsulation
headers. It provides encodings for a number of Tunnel Types headers. It provides encodings for a number of tunnel types,
along with procedures for choosing between alternate tunnels along with procedures for choosing between alternate tunnels
and routing packets into tunnels.</t> and routing packets into tunnels.</t>
<t>This document obsoletes RFC 5512, which provided an earlier
<t>This document obsoletes RFC 5512, which provided an earlier definition of the Tunnel Encapsulation attribute. RFC 5512 was never
definition of the Tunnel Encapsulation Attribute. RFC 5512 was never
deployed in production. Since RFC 5566 relies on RFC 5512, it is deployed in production. Since RFC 5566 relies on RFC 5512, it is
likewise obsoleted. This document updates RFC 5640 by indicating likewise obsoleted. This document updates RFC 5640 by indicating
that the Load-Balancing Block sub-TLV may be included in any Tunnel that the Load-Balancing Block sub-TLV may be included in any Tunnel
Encapsulation Attribute where load balancing is desired.</t> Encapsulation attribute where load balancing is desired.</t>
</abstract>
</abstract> </front>
</front> <middle>
<section numbered="true" toc="default">
<middle> <name>Introduction</name>
<section title="Introduction"><t> <t>
This document obsoletes RFC 5512. The deficiencies of RFC 5512, and This document obsoletes <xref target="RFC5512"/>. The deficiencies of <xref
a summary of the changes made, are discussed in Sections 1.1-1.3. target="RFC5512"/>, and
The material from RFC 5512 that is retained has been incorporated a summary of the changes made, are discussed in Sections <xref target="summar
y" format="counter"/>-<xref target="use-case" format="counter"/>.
The material from <xref target="RFC5512"/> that is retained has been incorpor
ated
into this document. Since <xref target="RFC5566"/> into this document. Since <xref target="RFC5566"/>
relies on RFC 5512, it is likewise obsoleted.</t> relies on <xref target="RFC5512"/>, it is likewise obsoleted.</t>
<t>
<t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
"OPTIONAL" in this document are to be interpreted as described in BCP RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, the "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
y appear in all be interpreted as
capitals, as shown here.</t> described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<section title="Brief Summary of RFC 5512"><t> <section numbered="true" toc="default" anchor="summary">
<xref target="RFC5512"/> defines a BGP Path Attribute known as the Tunnel <name>Brief Summary of RFC 5512</name>
<t>
<xref target="RFC5512" format="default"/> defines a BGP path attribute known
as the Tunnel
Encapsulation attribute. This attribute consists of one or more Encapsulation attribute. This attribute consists of one or more
TLVs. Each TLV identifies a particular type of tunnel. Each TLV TLVs. Each TLV identifies a particular type of tunnel. Each TLV
also contains one or more sub-TLVs. Some of the sub-TLVs, for example, the also contains one or more sub-TLVs. Some of the sub-TLVs, for example, the
"Encapsulation sub-TLV", contain information that may be used to form Encapsulation sub-TLV, contain information that may be used to form
the encapsulation header for the specified Tunnel Type. Other sub- the encapsulation header for the specified tunnel type. Other sub-TLVs, for
TLVs, for example, the "color sub-TLV" and the "protocol sub-TLV", contain example, the "color sub-TLV" and the "protocol sub-TLV", contain
information that aids in determining whether particular packets information that aids in determining whether particular packets
should be sent through the tunnel that the TLV identifies.</t> should be sent through the tunnel that the TLV identifies.</t>
<t>
<t> <xref target="RFC5512" format="default"/> only allows the Tunnel Encapsulatio
<xref target="RFC5512"/> only allows the Tunnel Encapsulation attribute to be n attribute to be
attached to BGP UPDATE messages of the Encapsulation Address Family. attached to BGP UPDATE messages of the Encapsulation Address Family.
These UPDATE messages have an AFI (Address Family Identifier) of 1 or These UPDATE messages have an Address Family Identifier (AFI) of 1 or
2, and a SAFI of 7. In an UPDATE of the Encapsulation SAFI, the NLRI 2, and a SAFI of 7. In an UPDATE of the Encapsulation SAFI, the
(Network Layer Reachability Information) is an address of the BGP Network Layer Reachability Information (NLRI) is an address of the BGP
speaker originating the UPDATE. Consider the following scenario:</t> speaker originating the UPDATE. Consider the following scenario:</t>
<ul spacing="normal">
<t><list style="symbols"><t>BGP speaker R1 has received and selected UPDA <li>BGP speaker R1 has received and selected UPDATE U for local use;</
TE U for local use;</t> li>
<li>UPDATE U's SAFI is the Encapsulation SAFI;</li>
<t>UPDATE U's SAFI is the Encapsulation SAFI;</t> <li>UPDATE U has the address R2 as its NLRI;</li>
<li>UPDATE U has a Tunnel Encapsulation attribute.</li>
<t>UPDATE U has the address R2 as its NLRI;</t> <li>R1 has a packet, P, to transmit to destination D; and</li>
<li>R1's best route to D is a BGP route that has R2 as its next hop.</
<t>UPDATE U has a Tunnel Encapsulation attribute.</t> li>
</ul>
<t>R1 has a packet, P, to transmit to destination D;</t> <t>
<t>R1's best route to D is a BGP route that has R2 as its next hop;</t>
</list>
</t>
<t>
In this scenario, when R1 transmits packet P, it should transmit it In this scenario, when R1 transmits packet P, it should transmit it
to R2 through one of the tunnels specified in U's Tunnel to R2 through one of the tunnels specified in U's Tunnel
Encapsulation attribute. The IP address of the tunnel egress endpoint of Encapsulation attribute. The IP address of the tunnel egress endpoint of
each such tunnel is R2. Packet P is known as the tunnel's "payload".</t> each such tunnel is R2. Packet P is known as the tunnel's "payload".</t>
</section>
</section> <section anchor="deficiencies" numbered="true" toc="default">
<name>Deficiencies in RFC 5512</name>
<section title="Deficiencies in RFC 5512" anchor="deficiencies"><t> <t>
While the ability to specify tunnel information in a BGP UPDATE is While the ability to specify tunnel information in a BGP UPDATE is
useful, the procedures of <xref target="RFC5512"/> have certain limitations:< useful, the procedures of <xref target="RFC5512" format="default"/> have cert
/t> ain limitations:</t>
<ul spacing="normal">
<t><list style="symbols"><t>The requirement to use the "Encapsulation SAF <li>The requirement to use the Encapsulation SAFI presents an
I" presents an
unfortunate operational cost, as each BGP session that may need to unfortunate operational cost, as each BGP session that may need to
carry tunnel encapsulation information needs to be reconfigured to carry tunnel encapsulation information needs to be reconfigured to
support the Encapsulation SAFI. The Encapsulation SAFI has never support the Encapsulation SAFI. The Encapsulation SAFI has never
been used, and this requirement has served only to discourage the been used, and this requirement has served only to discourage the
use of the Tunnel Encapsulation attribute.</t> use of the Tunnel Encapsulation attribute.</li>
<li>There is no way to use the Tunnel Encapsulation attribute to
<t>There is no way to use the Tunnel Encapsulation attribute to specify the tunnel egress endpoint address of a given tunnel; <xref target
specify the tunnel egress endpoint address of a given tunnel; <xref target ="RFC5512" format="default"/>
="RFC5512"/>
assumes that the tunnel egress endpoint of each tunnel is specified as assumes that the tunnel egress endpoint of each tunnel is specified as
the NLRI of an UPDATE of the Encapsulation SAFI.</t> the NLRI of an UPDATE of the Encapsulation SAFI.</li>
<li>If the respective best routes to two different address prefixes
<t>If the respective best routes to two different address prefixes have the same next hop, <xref target="RFC5512" format="default"/> does not
have the same next hop, <xref target="RFC5512"/> does not provide a provide a
straightforward method to associate each prefix with a different straightforward method to associate each prefix with a different
tunnel.</t> tunnel.</li>
<li>If a particular tunnel type requires an outer IP or UDP
<t>If a particular Tunnel Type requires an outer IP or UDP
encapsulation, there is no way to signal the values of any of the encapsulation, there is no way to signal the values of any of the
fields of the outer encapsulation.</t> fields of the outer encapsulation.</li>
<li>In the specification of the sub-TLVs in <xref target="RFC5512" for
<t>In <xref target="RFC5512"/>'s specification of the sub-TLVs, each sub- mat="default"/>, each sub-TLV has a
TLV has one-octet Length field. In some cases, where a sub-TLV may require more t
one-octet length field. In some cases, where a sub-TLV may require more t han
han 255 octets for its encoding, a two-octet Length field
255 octets for its encoding, a two-octet length field may be needed.</li>
may be needed.</t> </ul>
</section>
</list> <section numbered="true" toc="default" anchor="use-case">
</t> <name>Use Case for the Tunnel Encapsulation Attribute</name>
<t>
</section>
<section title="Use Case for The Tunnel Encapsulation Attribute"><t>
Consider the case of a router R1 forwarding an IP packet P. Let D be Consider the case of a router R1 forwarding an IP packet P. Let D be
P's IP destination address. R1 must look up D in its forwarding P's IP destination address. R1 must look up D in its forwarding
table. Suppose that the "best match" route for D is route Q, where Q table. Suppose that the "best match" route for D is route Q, where Q
is a BGP-distributed route whose "BGP next hop" is router R2. And is a BGP-distributed route whose "BGP next hop" is router R2. And
suppose further that the routers along the path from R1 to R2 have suppose further that the routers along the path from R1 to R2 have
entries for R2 in their forwarding tables, but do NOT have entries entries for R2 in their forwarding tables but do NOT have entries
for D in their forwarding tables. For example, the path from R1 to for D in their forwarding tables. For example, the path from R1 to
R2 may be part of a "BGP-free core", where there are no BGP- R2 may be part of a "BGP-free core", where there are no BGP-distribut
distributed routes at all in the core. Or, as in <xref target="RFC55 ed routes at all in the core. Or, as in <xref target="RFC5565" format="default"
65"/>, D may be an />, D may be an
IPv4 address while the intermediate routers along the path from R1 to IPv4 address while the intermediate routers along the path from R1 to
R2 may support only IPv6. R2 may support only IPv6.
</t> </t>
<t> <t>
In cases such as this, in order for R1 to properly forward packet P, In cases such as this, in order for R1 to properly forward packet P,
it must encapsulate P and send P "through a tunnel" to R2. For it must encapsulate P and send P "through a tunnel" to R2. For
example, R1 may encapsulate P using GRE, L2TPv3, IP in IP, etc., example, R1 may encapsulate P using GRE, Layer 2 Tunneling
Protocol version 3 (L2TPv3), IP in IP, etc.,
where the destination IP address of the encapsulation header is the where the destination IP address of the encapsulation header is the
address of R2. address of R2.
</t> </t>
<t> <t>
In order for R1 to encapsulate P for transport to R2, R1 must know In order for R1 to encapsulate P for transport to R2, R1 must know
what encapsulation protocol to use for transporting different sorts what encapsulation protocol to use for transporting different sorts
of packets to R2. R1 must also know how to fill in the various of packets to R2. R1 must also know how to fill in the various
fields of the encapsulation header. With certain encapsulation fields of the encapsulation header. With certain encapsulation
types, this knowledge may be acquired by default or through manual types, this knowledge may be acquired by default or through manual
configuration. Other encapsulation protocols have fields such as configuration. Other encapsulation protocols have fields such as
session id, key, or cookie that must be filled in. It would not be session id, key, or cookie that must be filled in. It would not be
desirable to require every BGP speaker to be manually configured with desirable to require every BGP speaker to be manually configured with
the encapsulation information for every one of its BGP next hops. the encapsulation information for every one of its BGP next hops.
</t> </t>
<t> <t>
This document specifies a way in which BGP itself can be used by This document specifies a way in which BGP itself can be used by
a given BGP speaker to tell other BGP speakers, "if you need to a given BGP speaker to tell other BGP speakers, "If you need to
encapsulate packets to be sent to me, here's the information you need encapsulate packets to be sent to me, here's the information you need
to properly form the encapsulation header". A BGP speaker signals to properly form the encapsulation header". A BGP speaker signals
this information to other BGP speakers by using a new BGP attribute t ype this information to other BGP speakers by using a new BGP attribute t ype
value, the BGP Tunnel Encapsulation Attribute. This attribute value -- the BGP Tunnel Encapsulation attribute. This attribute
specifies the encapsulation protocols that may be used as well as specifies the encapsulation protocols that may be used, as well as
whatever additional information (if any) is needed in order to whatever additional information (if any) is needed in order to
properly use those protocols. Other attributes, for example, communiti es or properly use those protocols. Other attributes, for example, communiti es or
extended communities, may also be included. extended communities, may also be included.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Brief Summary of Changes from RFC 5512"><t> <name>Brief Summary of Changes from RFC 5512</name>
This document addresses the deficiencies identified in <xref <t>
target="deficiencies"/> by:</t> This document addresses the deficiencies identified in <xref target="deficien
cies" format="default"/> by:</t>
<t><list style="symbols"><t>Deprecating the Encapsulation SAFI.</t> <ul spacing="normal">
<li>Deprecating the Encapsulation SAFI.</li>
<t>Defining a new "Tunnel Egress Endpoint sub-TLV" (<xref <li>Defining a new "Tunnel Egress Endpoint sub-TLV" (<xref target="tun
target="tunnel-egress-endpoint"/>) that can be nel-egress-endpoint" format="default"/>) that can be
included in any of the TLVs contained in the Tunnel Encapsulation included in any of the TLVs contained in the Tunnel Encapsulation
attribute. This sub-TLV can be used to specify the remote attribute. This sub-TLV can be used to specify the remote
endpoint address of a particular tunnel.</t> endpoint address of a particular tunnel.</li>
<li>Allowing the Tunnel Encapsulation attribute to be carried by BGP
<t>Allowing the Tunnel Encapsulation attribute to be carried by BGP
UPDATEs of additional AFI/SAFIs. Appropriate semantics are UPDATEs of additional AFI/SAFIs. Appropriate semantics are
provided for this way of using the attribute.</t> provided for this way of using the attribute.</li>
<li>Defining a number of new sub-TLVs that provide additional
<t>Defining a number of new sub-TLVs that provide additional
information that is useful when forming the encapsulation header information that is useful when forming the encapsulation header
used to send a packet through a particular tunnel.</t> used to send a packet through a particular tunnel.</li>
<li>Defining the Sub-TLV Type field so that a sub-TLV whose type is in
<t>Defining the sub-TLV type field so that a sub-TLV whose type is in the range from 0 to 127 (inclusive) has a one-octet Length field,
the range from 0 to 127 inclusive has a one-octet length field, but a sub-TLV whose type is in the range from 128 to 255 (inclusive)
but a sub-TLV whose type is in the range from 128 to 255 inclusive has a two-octet Length field.</li>
has a two-octet length field.</t> </ul>
<t>
</list> One of the sub-TLVs defined in <xref target="RFC5512" format="default"/> is t
</t> he "Encapsulation sub-TLV". For a given tunnel, the Encapsulation sub-TLV speci
fies some
<t>
One of the sub-TLVs defined in <xref target="RFC5512"/> is the "Encapsulation
sub-TLV". For a given tunnel, the Encapsulation sub-TLV specifies some
of the information needed to construct the encapsulation header used of the information needed to construct the encapsulation header used
when sending packets through that tunnel. This document defines when sending packets through that tunnel. This document defines
Encapsulation sub-TLVs for a number of tunnel types not discussed in Encapsulation sub-TLVs for a number of tunnel types not discussed in
<xref target="RFC5512"/>: VXLAN (Virtual Extensible Local Area Network, <xref <xref target="RFC5512" format="default"/>: Virtual eXtensible Local Area Netw
target="RFC7348"/>), ork (VXLAN) <xref target="RFC7348" format="default"/>, Network Virtualization Us
NVGRE ing Generic Routing Encapsulation (NVGRE)
(Network Virtualization Using Generic Routing Encapsulation <xref target="RFC7637" format="default"/>, and MPLS in Generic Routing Encaps
<xref target="RFC7637"/>), and MPLS-in-GRE (MPLS in Generic Routing Encapsula ulation (MPLS-in-GRE) <xref target="RFC4023" format="default"/>. MPLS-in-UDP <x
tion ref target="RFC7510" format="default"/> is also
<xref target="RFC4023"/>). MPLS-in-UDP <xref target="RFC7510"/> is also
supported, but an Encapsulation sub-TLV for it is not needed since there are supported, but an Encapsulation sub-TLV for it is not needed since there are
no additional parameters to be signaled.</t> no additional parameters to be signaled.</t>
<t>
<t>
Some of the encapsulations mentioned in the previous paragraph need Some of the encapsulations mentioned in the previous paragraph need
to be further encapsulated inside UDP and/or IP. <xref target="RFC5512"/> pr ovides to be further encapsulated inside UDP and/or IP. <xref target="RFC5512" form at="default"/> provides
no way to specify that certain information is to appear in these no way to specify that certain information is to appear in these
outer IP and/or UDP encapsulations. This document provides a outer IP and/or UDP encapsulations. This document provides a
framework for including such information in the TLVs of the Tunnel framework for including such information in the TLVs of the Tunnel
Encapsulation attribute.</t> Encapsulation attribute.</t>
<t>
<t>
When the Tunnel Encapsulation attribute is attached to a BGP UPDATE When the Tunnel Encapsulation attribute is attached to a BGP UPDATE
whose AFI/SAFI identifies one of the labeled address families, it is whose AFI/SAFI identifies one of the labeled address families, it is
not always obvious whether the label embedded in the NLRI is to not always obvious whether the label embedded in the NLRI is to
appear somewhere in the tunnel encapsulation header (and if so, appear somewhere in the tunnel encapsulation header (and if so,
where), or whether it is to appear in the payload, or whether it can where), whether it is to appear in the payload, or whether it can
be omitted altogether. This is especially true if the tunnel be omitted altogether. This is especially true if the tunnel
encapsulation header itself contains a "virtual network identifier". encapsulation header itself contains a "virtual network identifier".
This document provides a mechanism that allows one to signal (by This document provides a mechanism that allows one to signal (by
using sub-TLVs of the Tunnel Encapsulation attribute) how one wants using sub-TLVs of the Tunnel Encapsulation attribute) how one wants
to use the embedded label when the tunnel encapsulation has its own to use the embedded label when the tunnel encapsulation has its own
virtual network identifier field.</t> Virtual Network Identifier field.</t>
<t>
<t> <xref target="RFC5512" format="default"/> defines an Encapsulation Extended
<xref target="RFC5512"/> defines a Tunnel Encapsulation Extended
Community that can be used instead of the Tunnel Encapsulation Community that can be used instead of the Tunnel Encapsulation
attribute under certain circumstances. This document describes attribute under certain circumstances. This document describes
(<xref target="encapsulation-extcomm"/>) how the Tunnel Encapsulation Extend how the Encapsulation Extended
ed Community can be used in a backwards-compatible fashion (see <xref target="e
Community can be used in a backwards-compatible fashion. It is ncapsulation-extcomm" format="default"/>). It is
possible to combine Tunnel Encapsulation Extended Communities and possible to combine Encapsulation Extended Communities and
Tunnel Encapsulation attributes in the same BGP UPDATE in this Tunnel Encapsulation attributes in the same BGP UPDATE in this
manner.</t> manner.</t>
</section>
</section> <section numbered="true" toc="default">
<name>Update to RFC 5640</name>
<section title="Update to RFC 5640"> <t>
<t> This document updates <xref target="RFC5640" format="default"/> by indica
This document updates <xref target="RFC5640"/> by indicating that the Loa ting that the Load-Balancing Block
d-Balancing Block sub-TLV <bcp14>MAY</bcp14> be included in any Tunnel Encapsulation attrib
sub-TLV MAY be included in any Tunnel Encapsulation Attribute where ute where
loadbalancing is desired. load balancing is desired.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Effects of Obsoleting RFC 5566"> <name>Effects of Obsoleting RFC 5566</name>
<t> <t>
This specification obsoletes RFC 5566. This has the effect of, This specification obsoletes RFC 5566. This has the effect of,
in turn, obsoleting a number of code points defined in that document. in turn, deprecating a number of code points defined in that document.
From the "BGP Tunnel Encapsulation Attribute Tunnel Types" registry, In the "BGP Tunnel Encapsulation Attribute Tunnel Types" registry <xref t
arget="IANA-BGP-TUNNEL-ENCAP"/>, the following code points have been marked as d
eprecated:
"Transmit tunnel endpoint" (type code 3), "IPsec in Tunnel-mode" (type "Transmit tunnel endpoint" (type code 3), "IPsec in Tunnel-mode" (type
code 4), "IP in IP tunnel with IPsec Transport Mode" (type code 5), and code 4), "IP in IP tunnel with IPsec Transport Mode" (type code 5), and
"MPLS-in-IP tunnel with IPsec Transport Mode" (type code 6) are obsoleted "MPLS-in-IP tunnel with IPsec Transport Mode" (type code 6).
. In the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry <xref targe
From the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry, t="IANA-BGP-TUNNEL-ENCAP"/>,
"IPsec Tunnel Authenticator" (type code 3) is obsoleted. "IPsec Tunnel Authenticator" (type code 3) has been marked as deprecated.
See <xref target="obsoleting-5566-and-5640"/>. See <xref target="obsoleting-5566-and-5640" format="default"/>.
</t> </t>
</section>
</section> </section>
<section anchor="encaps-attr" numbered="true" toc="default">
</section> <name>The Tunnel Encapsulation Attribute</name>
<t>
The Tunnel Encapsulation attribute is an optional transitive BGP path
<section title="The Tunnel Encapsulation Attribute" anchor="encaps-attr">
<t>
The Tunnel Encapsulation attribute is an optional transitive BGP Path
attribute. IANA has assigned the value 23 as the type code of the attribute. IANA has assigned the value 23 as the type code of the
attribute. The attribute is composed of a set of Type-Length-Value attribute in the "BGP Path Attributes" registry <xref target="IANA-BGP-PARAMS " />. The attribute is composed of a set of Type-Length-Value
(TLV) encodings. Each TLV contains information corresponding to a (TLV) encodings. Each TLV contains information corresponding to a
particular Tunnel Type. A Tunnel Encapsulation TLV, also known as Tunnel TLV particular tunnel type. A Tunnel Encapsulation TLV, also known as Tunnel TLV
, ,
is structured as shown in Figure 1:</t> is structured as shown in <xref target="ref-tunnel-tlv-value-field"/>.
</t>
<figure title="Tunnel Encapsulation TLV Value Field" anchor="ref-tunnel-t <figure anchor="ref-tunnel-tlv-value-field">
lv-value-field"><artwork><![CDATA[ <name>Tunnel Encapsulation TLV</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Type (2 Octets) | Length (2 Octets) | | Tunnel Type (2 octets) | Length (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Value (Variable) | | Value (variable) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t><list style="symbols"><t>Tunnel Type (2 octets): identifies a type of
tunnel. The field
contains values from the IANA Registry "BGP Tunnel Encapsulation Attribute
Tunnel Types".
See <xref target="protocol-type"/> for discussion of special treatment of
tunnel types
with names of the form "X-in-Y".
</t>
<t>Length (2 octets): the total number of octets of the Value field.</t>
<t>Value (variable): comprised of multiple sub-TLVs.</t>
</list>
</t>
<t> <dl>
Each sub-TLV consists of three fields: a 1-octet type, a 1-octet or <dt>Tunnel Type (2 octets):</dt><dd>Identifies a type of tunnel. The fi
2-octet length field (depending on the type), and zero or more octets eld
of value. A sub-TLV is structured as shown in Figure 2: contains values from the IANA registry
<figure title="Encapsulation Sub-TLV Value Field" anchor="ref-tunnel-enca "BGP Tunnel Encapsulation Attribute Tunnel Types" <xref target="IANA-BGP-TUNNEL-
psulation-sub-tlv-value-field"><artwork><![CDATA[ ENCAP" />.
See <xref target="protocol-type" format="default"/> for discussion of spec
ial treatment of tunnel types with names of the form "X-in-Y".</dd>
<dt>Length (2 octets):</dt><dd>The total number of octets of the Value f
ield.</dd>
<dt>Value (variable):</dt><dd>Comprised of multiple sub-TLVs.</dd>
</dl>
<t>
Each sub-TLV consists of three fields: A 1-octet type, a 1-octet or
2-octet length (depending on the type), and zero or more octets
of value. A sub-TLV is structured as shown in <xref target="ref-tunnel-encap
sulation-sub-tlv-value-field"/>.
</t>
<figure anchor="ref-tunnel-encapsulation-sub-tlv-value-field">
<name>Encapsulation Sub-TLV</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+--------------------------------+ +--------------------------------+
| Sub-TLV Type (1 Octet) | | Sub-TLV Type (1 octet) |
+--------------------------------+ +--------------------------------+
| Sub-TLV Length (1 or 2 Octets) | | Sub-TLV Length (1 or 2 octets) |
+--------------------------------+ +--------------------------------+
| Sub-TLV Value (Variable) | | Sub-TLV Value (variable) |
+--------------------------------+ +--------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<dl>
</t> <dt>Sub-TLV Type (1 octet):</dt><dd>Each sub-TLV type defines a certain
<t><list style="symbols"><t>Sub-TLV Type (1 octet): each sub-TLV type def
ines a certain
property about the Tunnel TLV that contains this sub-TLV. property about the Tunnel TLV that contains this sub-TLV.
The field contains values from the IANA Registry "BGP Tunnel Encapsulation The field contains values from the IANA registry
Attribute Sub-TLVs".</t> "BGP Tunnel Encapsulation Attribute Sub-TLVs" <xref target="IANA-BGP-TUNNEL-ENCA
P" />.</dd>
<t>Sub-TLV Length (1 or 2 octets): the total number of octets of the <dt>Sub-TLV Length (1 or 2 octets):</dt><dd>The total number of octets of
sub-TLV Value field. The Sub-TLV Length field contains 1 octet if the
Sub-TLV Value field. The Sub-TLV Length field contains 1 octet if
the Sub-TLV Type field contains a value in the range from 0-127. the Sub-TLV Type field contains a value in the range from 0-127.
The Sub-TLV Length field contains two octets if the Sub-TLV Type The Sub-TLV Length field contains two octets if the Sub-TLV Type
field contains a value in the range from 128-255.</t> field contains a value in the range from 128-255.</dd>
<dt>Sub-TLV Value (variable):</dt><dd>Encodings of the Value field depend
<t>Sub-TLV Value (variable): encodings of the Value field depend on on
the sub-TLV type as enumerated above. The following sub-sections the sub-TLV type. The following subsections
define the encoding in detail.</t> define the encoding in detail.</dd>
</dl>
</list> </section>
</t> <section numbered="true" toc="default">
<name>Tunnel Encapsulation Attribute Sub-TLVs</name>
</section> <t>
This section specifies a number of sub-TLVs. These sub-TLVs can
<section title="Tunnel Encapsulation Attribute Sub-TLVs"><t> be included in a TLV of the Tunnel Encapsulation attribute.</t>
This section specifies a number of sub-TLVs. These sub-TLVs can <section anchor="tunnel-egress-endpoint" numbered="true" toc="default">
be included in a TLV of the Tunnel Encapsulation attribute.</t> <name>The Tunnel Egress Endpoint Sub-TLV (Type Code 6)</name>
<t>
<section title="The Tunnel Egress Endpoint Sub-TLV (type code 6)"
anchor="tunnel-egress-endpoint"><t>
The Tunnel Egress Endpoint The Tunnel Egress Endpoint
sub-TLV specifies the address of the egress endpoint of the tunnel, that sub-TLV specifies the address of the egress endpoint of the tunnel, that
is, the address of the router that will decapsulate the payload. Its is, the address of the router that will decapsulate the payload. Its
Value field contains three subfields:</t> Value field contains three subfields:</t>
<ol spacing="normal" type="1"><li>a Reserved subfield</li>
<t><list style="numbers"><t>a reserved subfield</t> <li>a two-octet Address Family subfield</li>
<li>an Address subfield, whose length depends upon the Address
<t>a two-octet Address Family subfield</t> Family.</li>
</ol>
<t>an Address subfield, whose length depends upon the Address <figure anchor="ref-tunnel-endpoint-sub-tlv-value-field">
Family.</t> <name>Tunnel Egress Endpoint Sub-TLV Value Field</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
</list>
</t>
<figure title="Tunnel Egress Endpoint Sub-TLV Value Field" anchor="ref-tu
nnel-endpoint-sub-tlv-value-field"><artwork><![CDATA[
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 (4 octets) | | Reserved (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family (2 octets) | Address | | Address Family (2 octets) | Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Variable) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (variable) +
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
The Reserved subfield SHOULD be originated as zero. It MUST be The Reserved subfield <bcp14>SHOULD</bcp14> be originated as zero. It <bcp14>
disregarded on receipt, and it MUST be propagated unchanged. MUST</bcp14> be
</t> disregarded on receipt, and it <bcp14>MUST</bcp14> be propagated unchanged.
</t>
<t> <t>
The Address Family subfield contains a value from IANA's "Address Family Numb The Address Family subfield contains a value from IANA's
ers" registry. "Address Family Numbers" registry <xref target="IANA-ADDRESS-FAM" />.
This document assumes that the This document assumes that the
Address Family is either IPv4 or IPv6; use of other address families Address Family is either IPv4 or IPv6; use of other address families
is outside the scope of this document.</t> is outside the scope of this document.</t>
<t>
<t>
If the Address Family subfield contains the value for IPv4, the If the Address Family subfield contains the value for IPv4, the
Address subfield MUST contain an IPv4 address (a /32 IPv4 prefix).</t> Address subfield <bcp14>MUST</bcp14> contain an IPv4 address (a /32 IPv4 pref
ix).</t>
<t> <t>
If the Address Family subfield contains the value for IPv6, the If the Address Family subfield contains the value for IPv6, the
Address subfield MUST contain an IPv6 address (a /128 IPv6 prefix).</t> Address subfield <bcp14>MUST</bcp14> contain an IPv6 address (a /128 IPv6 pre
fix).</t>
<t> <t>
In a given BGP UPDATE, the address family (IPv4 or IPv6) of a Tunnel In a given BGP UPDATE, the address family (IPv4 or IPv6) of a Tunnel
Egress Endpoint sub-TLV is independent of the address family of the UPDATE Egress Endpoint sub-TLV is independent of the address family of the UPDATE
itself. For example, an UPDATE whose NLRI is an IPv4 address may itself. For example, an UPDATE whose NLRI is an IPv4 address may
have a Tunnel Encapsulation attribute containing Tunnel Egress Endpoint have a Tunnel Encapsulation attribute containing Tunnel Egress Endpoint
sub-TLVs that contain IPv6 addresses. Also, different tunnels sub-TLVs that contain IPv6 addresses. Also, different tunnels
represented in the Tunnel Encapsulation attribute may have tunnel egress represented in the Tunnel Encapsulation attribute may have tunnel egress
endpoints of different address families.</t> endpoints of different address families.</t>
<t>
<t> There is one special case: the Tunnel Egress Endpoint sub-TLV <bcp14>MA
There is one special case: the Tunnel Egress Endpoint sub-TLV MAY have Y</bcp14> have a
a
Value field whose Address Family subfield contains 0. This means Value field whose Address Family subfield contains 0. This means
that the tunnel's egress endpoint is the address of the next hop. If that the tunnel's egress endpoint is the address of the next hop. If
the Address Family subfield contains 0, the Address subfield is the Address Family subfield contains 0, the Address subfield is
omitted. In this case, omitted. In this case,
the Length field of Tunnel Egress Endpoint sub-TLV MUST contain the the Length field of Tunnel Egress Endpoint sub-TLV <bcp14>MUST</bcp14> contain the
value 6 (0x06). </t> value 6 (0x06). </t>
<t> <t>
When the Tunnel Encapsulation attribute is carried in an UPDATE messag e When the Tunnel Encapsulation attribute is carried in an UPDATE messag e
of one of the AFI/SAFIs specified in this document (see the second of one of the AFI/SAFIs specified in this document (see the first
paragraph of <xref target="usage"/>), each TLV MUST have one, and one paragraph of <xref target="usage" format="default"/>), each TLV <bcp14
only, Tunnel >MUST</bcp14> have one, and only one, Tunnel Egress Endpoint sub-TLV. If a TLV d
Egress Endpoint sub-TLV. If a TLV does not have a Tunnel Egress Endpoi oes not have a Tunnel Egress Endpoint sub-TLV, that TLV should be treated as if
nt it had a malformed Tunnel
sub-TLV, that TLV should be treated as if it had a malformed Tunnel
Egress Endpoint sub-TLV (see below).</t> Egress Endpoint sub-TLV (see below).</t>
<t> <t>
In the context of this specification, if the Address Family subfield In the context of this specification, if the Address Family subfield
has any value other than IPv4, IPv6, or the special value 0, the has any value other than IPv4, IPv6, or the special value 0, the
Tunnel Egress Endpoint sub-TLV is considered "unrecognized" (see Tunnel Egress Endpoint sub-TLV is considered "unrecognized" (see
<xref target="validation-and-error"/>). <xref target="validation-and-error" format="default"/>).
If any of the following conditions hold, the Tunnel Egress Endpoint sub-TLV If any of the following conditions hold, the Tunnel Egress Endpoint sub-TLV
is considered to be "malformed":</t> is considered to be "malformed":</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>The length of the sub-TLV's Value field is other than 6 added to <t>The length of the sub-TLV's Value field is other than 6 added to
the defined length for the address family given in its Address the defined length for the address family given in its Address
Family subfield. Therefore, for address family behaviors defined Family subfield. Therefore, for address family behaviors defined
in this document, the permitted values are: in this document, the permitted values are:
<list style="symbols"> </t>
<t>10, if the Address Family subfield contains the value for IPv4.</t> <ul spacing="normal">
<t>22, if the Address Family subfield contains the value for IPv6.</t> <li>10, if the Address Family subfield contains the value for IPv4
<t>6, if the Address Family subfield contains the value zero.</t> .</li>
</list></t> <li>22, if the Address Family subfield contains the value for IPv6
.</li>
<t>The IP address in the sub-TLV's Address subfield lies within a <li>6, if the Address Family subfield contains the value zero.</li
block listed in the relevant Special-Purpose IP Address Registry >
<xref target="RFC6890"/> with either a “destination” attribute </ul>
value or a “forwardable” attribute value of “false”. (Such routes </li>
<li>The IP address in the sub-TLV's Address subfield lies within a
block listed in the relevant Special-Purpose IP Address registry
<xref target="RFC6890" format="default"/> with either a "destination" a
ttribute
value or a "forwardable" attribute value of "false". (Such routes
are sometimes colloquially known as "Martians".) This restriction are sometimes colloquially known as "Martians".) This restriction
MAY be relaxed by explicit configuration.</t> <bcp14>MAY</bcp14> be relaxed by explicit configuration.</li>
<li>It can be determined that the IP address in the sub-TLV's Address
<t>It can be determined that the IP address in the sub-TLV's Address
subfield does not belong to the Autonomous System (AS) that originated subfield does not belong to the Autonomous System (AS) that originated
the route that contains the attribute. <xref target="address-validation"/ the route that contains the attribute. <xref target="address-validation"
> format="default"/>
describes an optional procedure to make this determination.</t> describes an optional procedure to make this determination.</li>
</list> </ul>
</t> <t>
Error handling is specified in <xref target="validation-and-error" format="de
<t> fault"/>.
Error Handling is specified in <xref target="validation-and-error"/>. </t>
</t> <t>
<t>
If the Tunnel Egress Endpoint sub-TLV contains an IPv4 or IPv6 address that If the Tunnel Egress Endpoint sub-TLV contains an IPv4 or IPv6 address that
is valid but not reachable, the sub-TLV is not considered to be is valid but not reachable, the sub-TLV is not considered to be
malformed.</t> malformed.</t>
<section anchor="address-validation" numbered="true" toc="default">
<section title="Validating the Address Subfield" anchor="address-validation" <name>Validating the Address Subfield</name>
> <t>
<t> This section provides a procedure that <bcp14>MAY</bcp14> be applied to
This section provides a procedure that MAY be applied to
validate that the IP address in the sub-TLV's Address subfield validate that the IP address in the sub-TLV's Address subfield
belongs to the AS that originated the route that contains the belongs to the AS that originated the route that contains the
attribute. (The notion of "belonging to" an AS is expanded on below.) attribute. (The notion of "belonging to" an AS is expanded on below.)
Doing this is thought to increase confidence that when Doing this is thought to increase confidence that when
traffic is sent to the IP address depicted in the traffic is sent to the IP address depicted in the
Address subfield, it will go to the same AS as it would go to if the Address subfield, it will go to the same AS as it would go to if the
Tunnel Encapsulation Attribute were not present, although of course Tunnel Encapsulation attribute were not present, although of course
it cannot guarantee it. See <xref it cannot guarantee it. See <xref target="security" format="default"/> for di
target="security"/> for discussion of the limitations of this scussion of the limitations of this
procedure. The principal applicability of this procedure is in deployments procedure. The principal applicability of this procedure is in deployments
that are not strictly scoped. In deployments with strict scope, and especiall y that are not strictly scoped. In deployments with strict scope, and especiall y
those scoped to a single AS, these procedures may not add substantial those scoped to a single AS, these procedures may not add substantial
benefit beyond those discussed in <xref target="scoping"/>. benefit beyond those discussed in <xref target="scoping" format="default"/>.
</t> </t>
<t>
<t> The Route Origin Autonomous System Number (ASN) of a BGP route that
The Route Origin ASN (Autonomous System Number) of a BGP route that includes a Tunnel Encapsulation attribute can be determined by
includes a Tunnel Encapsulation Attribute can be determined by
inspection of the AS_PATH attribute, according to the procedure inspection of the AS_PATH attribute, according to the procedure
specified in <xref target="RFC6811"/> Section 2. Call this value specified in <xref target="RFC6811" sectionFormat="comma" section="2"/>. Call this value
Route_AS. Route_AS.
</t> </t>
<t>
<t>
In order to determine the Route Origin ASN of the address depicted in In order to determine the Route Origin ASN of the address depicted in
the Address subfield of the Tunnel Egress Endpoint sub-TLV, it is the Address subfield of the Tunnel Egress Endpoint sub-TLV, it is
necessary to consider the forwarding route, that is, the route that necessary to consider the forwarding route -- that is, the route that
will be used to forward traffic toward that address. This route is will be used to forward traffic toward that address. This route is
determined by a recursive route lookup operation for that address, as determined by a recursive route-lookup operation for that address, as
discussed in <xref target="RFC4271"/> Section 5.1.3. The relevant AS discussed in <xref target="RFC4271" sectionFormat="comma" section="5.1.3"/>.
Path to consider is the last one encountered while performing the The relevant AS
recursive lookup; the procedures of RFC6811 Section 2 are applied to path to consider is the last one encountered while performing the
that AS Path to determine the Route Origin ASN. If no AS Path is recursive lookup; the procedures of <xref target="RFC6811" sectionFormat="com
encountered at all, for example if that route's source is a protocol ma" section="2"/> are applied to
that AS path to determine the Route Origin ASN. If no AS path is
encountered at all, for example, if that route's source is a protocol
other than BGP, the Route Origin ASN is the BGP speaker's own AS other than BGP, the Route Origin ASN is the BGP speaker's own AS
number. Call this value Egress_AS. number. Call this value Egress_AS.
</t> </t>
<t>
<t>
If Route_AS does not equal Egress_AS, then the Tunnel Egress Endpoint If Route_AS does not equal Egress_AS, then the Tunnel Egress Endpoint
sub-TLV is considered not to be valid. In some cases a network operator sub-TLV is considered not to be valid. In some cases, a network operator
who controls a set of Autonomous Systems might wish to allow a Tunnel who controls a set of ASes might wish to allow a tunnel
Egress Endpoint to reside in an AS other than Route_AS; configuration egress endpoint to reside in an AS other than Route_AS; configuration
MAY allow for such a case, in which case the check becomes, if <bcp14>MAY</bcp14> allow for such a case, in which case the check becomes: if
Egress_AS is not within the configured set of permitted AS numbers, then the Egress_AS is not within the configured set of permitted AS numbers, then the
Tunnel Egress Endpoint sub-TLV is considered to be "malformed". Tunnel Egress Endpoint sub-TLV is considered to be "malformed".
</t> </t>
<t>
<t> Note that if the forwarding route changes, this procedure <bcp14>MUST</bcp14>
Note that if the forwarding route changes, this procedure MUST be be
reapplied. As a result, a sub-TLV that was formerly considered valid reapplied. As a result, a sub-TLV that was formerly considered valid
might become not valid, or vice-versa. might become not valid, or vice versa.
</t> </t>
</section> </section>
</section>
</section> <section numbered="true" toc="default">
<name>Encapsulation Sub-TLVs for Particular Tunnel Types (Type Code 1)</
<section title="Encapsulation Sub-TLVs for Particular Tunnel Types (type name>
code 1)"><t> <t>
This section defines Encapsulation sub-TLVs for the following This section defines Encapsulation sub-TLVs for the following
tunnel types: VXLAN (<xref target="RFC7348"/>), NVGRE tunnel types: VXLAN <xref target="RFC7348" format="default"/>, NVGRE
(<xref target="RFC7637"/>), MPLS-in-GRE (<xref target="RFC4023"/>), L2TPv3 <xref target="RFC7637" format="default"/>, MPLS-in-GRE <xref target="RFC4023"
(<xref target="RFC3931"/>), and GRE (<xref target="RFC2784"/>).</t> format="default"/>, L2TPv3
<xref target="RFC3931" format="default"/>, and GRE <xref target="RFC2784" for
<t> mat="default"/>.</t>
<t>
Rules for forming the encapsulation based on the information in a Rules for forming the encapsulation based on the information in a
given TLV are given in <xref target="usage"/> and <xref target="use-of-vni"/> given TLV are given in Sections <xref target="usage" format="counter"/> and <
.</t> xref target="use-of-vni" format="counter"/>.</t>
<t>
<t>
Recall that the tunnel type itself is identified by the Tunnel Type Recall that the tunnel type itself is identified by the Tunnel Type
field in the attribute header (<xref target="encaps-attr"/>); the field in the attribute header (<xref target="encaps-attr" format="default"/>) ; the
Encapsulation sub-TLV's structure is inferred from this. Regardless Encapsulation sub-TLV's structure is inferred from this. Regardless
of the Tunnel Type, the sub-TLV type of the Encapsulation sub-TLV is of the tunnel type, the sub-TLV type of the Encapsulation sub-TLV is
1. There are also tunnel types for which it is not necessary to 1. There are also tunnel types for which it is not necessary to
define an Encapsulation sub-TLV, because there are no fields in the define an Encapsulation sub-TLV, because there are no fields in the
encapsulation header whose values need to be signaled from the tunnel encapsulation header whose values need to be signaled from the tunnel
egress endpoint.</t> egress endpoint.</t>
<section numbered="true" toc="default">
<section title="VXLAN (tunnel type 8)"><t> <name>VXLAN (Tunnel Type 8)</name>
This document defines an Encapsulation sub-TLV for <xref target="RFC7348">VXL <t>
AN</xref> tunnels. This document defines an Encapsulation sub-TLV for <xref target="RFC7348" for
When the Tunnel Type is VXLAN, the length of the sub-TLV is 12 octets. The mat="default">VXLAN</xref> tunnels.
following is the structure of the Value field in the Encapsulation sub-TLV:</ When the tunnel type is VXLAN, the length of the sub-TLV is 12 octets. The st
t> ructure of the Value field in the Encapsulation sub-TLV is shown in <xref target
="ref-vxlan-encapsulation-sub-tlv" />.</t>
<figure title="VXLAN Encapsulation Sub-TLV Value Field" anchor="ref-vxlan <figure anchor="ref-vxlan-encapsulation-sub-tlv">
-encapsulation-sub-tlv"><artwork><![CDATA[ <name>VXLAN Encapsulation Sub-TLV Value Field</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V|M|R|R|R|R|R|R| VN-ID (3 Octets) | |V|M|R|R|R|R|R|R| VN-ID (3 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address (4 Octets) | | MAC Address (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address (2 Octets) | Reserved (2 Octets) | | MAC Address (2 octets) | Reserved (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t><list hangIndent="3" style="hanging"><t> <dl newline="false" spacing="normal" indent="3">
V: This bit is set to 1 to indicate that a VN-ID (Virtual <dt>V:</dt>
Network Identifier) is present in the Encapsulation sub-TLV. <dd>
This bit is set to 1 to indicate that a Virtual
Network Identifier (VN-ID) is present in the Encapsulation sub-TLV.
If set to 0, the VN-ID field is disregarded. If set to 0, the VN-ID field is disregarded.
Please see <xref target="use-of-vni"/>.</t> Please see <xref target="use-of-vni" format="default"/>.</dd>
<dt>M:</dt>
</list> <dd>
</t> This bit is set to 1 to indicate that a Media Access Control (MAC) Address
is
<t><list hangIndent="3" style="hanging"><t>
M: This bit is set to 1 to indicate that a MAC Address is
present in the Encapsulation sub-TLV. If set to 0, the MAC present in the Encapsulation sub-TLV. If set to 0, the MAC
Address field is disregarded.</t> Address field is disregarded.</dd>
<dt>R:</dt>
</list> <dd>
</t> The remaining bits in the 8-bit Flags field are reserved for
further use. They <bcp14>MUST</bcp14> always be set to 0 by the originato
<t><list hangIndent="3" style="hanging"><t> r of
R: The remaining bits in the 8-bit flags field are reserved for the sub-TLV. Intermediate routers <bcp14>MUST</bcp14> propagate them witho
further use. They MUST always be set to 0 by the originator of ut
the sub-TLV. Intermediate routers MUST propagate them without modification. Any receiving routers <bcp14>MUST</bcp14> ignore
modification. Any receiving routers MUST ignore these bits upon receipt.</dd>
these bits upon receipt.</t>
</list>
</t>
<t><list hangIndent="3" style="hanging"><t>
VN-ID: If the V bit is set, the VN-ID field contains a 3 octet VN-
ID value. If the V bit is not set, the VN-ID field MUST be set
to zero on transmission and disregarded on receipt.</t>
</list>
</t>
<t><list hangIndent="3" style="hanging"><t>
MAC Address: If the M bit is set, this field contains a 6 octet
Ethernet MAC address. If the M bit is not set, this field MUST
be set to all zeroes on transmission and disregarded on receipt.</t>
</list>
</t>
<t><list hangIndent="3" style="hanging"><t>
Reserved: MUST be set to zero on transmission and disregarded
on receipt.</t>
</list>
</t>
<t> <dt>VN-ID:</dt>
<dd>
If the V bit is set to 1, the VN-ID field contains a 3-octet VN-ID value.
If the V bit is set to 0, the VN-ID field <bcp14>MUST</bcp14> be set
to zero on transmission and disregarded on receipt.</dd>
<dt>MAC Address:</dt>
<dd>
If the M bit is set to 1, this field contains a 6-octet
Ethernet MAC address. If the M bit is set to 0, this field <bcp14>MUST</b
cp14>
be set to all zeroes on transmission and disregarded on receipt.</dd>
<dt>Reserved:</dt>
<dd>
<bcp14>MUST</bcp14> be set to zero on transmission and disregarded
on receipt.</dd>
</dl>
<t>
When forming the VXLAN encapsulation header:</t> When forming the VXLAN encapsulation header:</t>
<ul spacing="normal">
<t><list style="symbols"><t>The values of the V, M, and R bits are NOT co <li>The values of the V, M, and R bits are NOT copied into the Flags
pied into the flags field of the VXLAN header. The Flags field of the VXLAN header is
field of the VXLAN header. The flags field of the VXLAN header is set as per <xref target="RFC7348" format="default"/>.</li>
set as per <xref target="RFC7348"/>.</t> <li>
<t>If the M bit is set to 1, the MAC Address is copied into the In
<t>If the M bit is set, the MAC Address is copied into the Inner ner
Destination MAC Address field of the Inner Ethernet Header (see Destination MAC Address field of the Inner Ethernet Header (see
section 5 of <xref target="RFC7348"/>).<vspace blankLines="1"/> <xref target="RFC7348" sectionFormat="of" section="5"/>).</t>
If the M bit is not set, and the payload being sent through the <t>
If the M bit is set to 0, and the payload being sent through the
VXLAN tunnel is an Ethernet frame, the Destination MAC Address VXLAN tunnel is an Ethernet frame, the Destination MAC Address
field of the Inner Ethernet Header is just the Destination MAC field of the Inner Ethernet Header is just the Destination MAC
Address field of the payload's Ethernet header. Address field of the payload's Ethernet header.
<vspace blankLines="1"/> </t>
If the M bit is not set, and the payload being sent through the <t>
If the M bit is set to 0, and the payload being sent through the
VXLAN tunnel is an IP or MPLS packet, the Inner Destination MAC VXLAN tunnel is an IP or MPLS packet, the Inner Destination MAC
Address field is set to a configured value; if there is no Address field is set to a configured value; if there is no
configured value, the VXLAN tunnel cannot be used. configured value, the VXLAN tunnel cannot be used.
</t> </t>
<t> If the V bit is not set, and the BGP UPDATE message has </li>
AFI/SAFI other than Ethernet VPNs (SAFI 70, "BGP EVPNs") then the <li> If the V bit is set to 0, and the BGP UPDATE message has an
AFI/SAFI other than Ethernet VPNs (SAFI 70, "BGP EVPNs"), then the
VXLAN tunnel cannot be used. VXLAN tunnel cannot be used.
</t> </li>
<li>
<t><xref target="use-of-vni"/> describes how the VNI field of the <xref target="use-of-vni" format="default"/> describes how the VNI
VXLAN encapsulation header is set. (VXLAN Network Identifier) field of the VXLAN encapsulation header is set.
</t> </li>
</ul>
</list> <t>
</t>
<t>
Note that in order to send an IP packet or an MPLS packet through a Note that in order to send an IP packet or an MPLS packet through a
VXLAN tunnel, the packet must first be encapsulated in an Ethernet VXLAN tunnel, the packet must first be encapsulated in an Ethernet
header, which becomes the "inner Ethernet header" described in header, which becomes the "Inner Ethernet Header" described in
<xref target="RFC7348"/>. The VXLAN Encapsulation sub-TLV may contain inform <xref target="RFC7348" format="default"/>. The VXLAN Encapsulation sub-TLV m
ation ay contain information
(for example,the MAC address) that is used to form this Ethernet header.</t> (for example, the MAC address) that is used to form this Ethernet header.</t>
</section>
</section> <section numbered="true" toc="default">
<name>NVGRE (Tunnel Type 9)</name>
<section title="NVGRE (tunnel type 9)"><t> <t>
This document defines an Encapsulation sub-TLV for <xref target="RFC7637">NVG This document defines an Encapsulation sub-TLV for <xref target="RFC7637" for
RE</xref> tunnels. mat="default">NVGRE</xref> tunnels.
When the Tunnel Type is NVGRE, the length of the sub-TLV is 12 octets. The When the tunnel type is NVGRE, the length of the sub-TLV is 12 octets. The st
following is the structure of the Value field in the Encapsulation sub-TLV:</ ructure of the Value field in the Encapsulation sub-TLV is shown in <xref target
t> ="ref-nvgre-encapsulation-sub-tlv"/>.</t>
<figure anchor="ref-nvgre-encapsulation-sub-tlv">
<figure title="NVGRE Encapsulation Sub-TLV Value Field" anchor="ref-nvgre <name>NVGRE Encapsulation Sub-TLV Value Field</name>
-encapsulation-sub-tlv"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V|M|R|R|R|R|R|R| VN-ID (3 Octets) | |V|M|R|R|R|R|R|R| VN-ID (3 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address (4 Octets) | | MAC Address (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address (2 Octets) | Reserved (2 Octets) | | MAC Address (2 octets) | Reserved (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t><list hangIndent="3" style="hanging"><t> <dl newline="false" spacing="normal" indent="3">
V: This bit is set to 1 to indicate that a VN-ID is <dt>V:</dt>
<dd>
This bit is set to 1 to indicate that a VN-ID is
present in the Encapsulation sub-TLV. If set to 0, present in the Encapsulation sub-TLV. If set to 0,
the VN-ID field is disregarded. Please see <xref target="use-of-vni"/>.</t the VN-ID field is disregarded. Please see <xref target="use-of-vni" forma
> t="default"/>.</dd>
<dt>M:</dt>
</list> <dd>
</t> This bit is set to 1 to indicate that a MAC Address is
<t><list hangIndent="3" style="hanging"><t>
M: This bit is set to 1 to indicate that a MAC Address is
present in the Encapsulation sub-TLV. If set to 0, present in the Encapsulation sub-TLV. If set to 0,
the MAC Address field is disregarded. </t> the MAC Address field is disregarded. </dd>
<dt>R:</dt>
</list> <dd>
</t> The remaining bits in the 8-bit Flags field are reserved for
further use. They <bcp14>MUST</bcp14> always be set to 0 by the originator
<t><list hangIndent="3" style="hanging"><t> of
R: The remaining bits in the 8-bit flags field are reserved for the sub-TLV. Intermediate routers <bcp14>MUST</bcp14> propagate them witho
further use. They MUST always be set to 0 by the originator of ut
the sub-TLV. Intermediate routers MUST propagate them without modification. Any receiving routers <bcp14>MUST</bcp14> ignore
modification. Any receiving routers MUST ignore these bits upon receipt.</dd>
these bits upon receipt.</t> <dt>VN-ID:</dt>
<dd>
</list> If the V bit is set to 1, the VN-ID field contains a 3-octet VN-ID value,
</t> used to set the NVGRE Virtual Subnet Identifier (VSID; see <xref target="use-of-
vni" format="default"/>). If the V bit is set to 0, the VN-ID field <bcp14>MUST
<t><list hangIndent="3" style="hanging"><t> </bcp14> be set
VN-ID: If the V bit is set, the VN-ID field contains a 3 octet VN- to zero on transmission and disregarded on receipt.</dd>
ID value, used to set the NVGRE VSID (see <xref target="use-of-vni"/>). I <dt>MAC Address:</dt>
f the V bit is not set, the VN-ID field MUST be set <dd>
to zero on transmission and disregarded on receipt.</t> If the M bit is set to 1, this field contains a 6-octet
Ethernet MAC address. If the M bit is set to 0, this field <bcp14>MUST</b
</list> cp14>
</t> be set to all zeroes on transmission and disregarded on receipt.</dd>
<dt>Reserved:</dt>
<t><list hangIndent="3" style="hanging"><t> <dd>
MAC Address: If the M bit is set, this field contains a 6 octet <bcp14>MUST</bcp14> be set to zero on transmission and disregarded
Ethernet MAC address. If the M bit is not set, this field MUST on receipt.</dd>
be set to all zeroes on transmission and disregarded on receipt.</t> </dl>
<t>
</list>
</t>
<t><list hangIndent="3" style="hanging"><t>
Reserved: MUST be set to zero on transmission and disregarded
on receipt.</t>
</list>
</t>
<t>
When forming the NVGRE encapsulation header:</t> When forming the NVGRE encapsulation header:</t>
<ul spacing="normal">
<t><list style="symbols"><t>The values of the V, M, and R bits are NOT co <li>The values of the V, M, and R bits are NOT copied into the Flags
pied into the flags field of the NVGRE header. The Flags field of the NVGRE header is
field of the NVGRE header. The flags field of the NVGRE header is set as per <xref target="RFC7637" format="default"/>.</li>
set as per <xref target="RFC7637"/>.</t> <li>
<t>If the M bit is set to 1, the MAC Address is copied into the In
<t>If the M bit is set, the MAC Address is copied into the Inner ner
Destination MAC Address field of the Inner Ethernet Header (see Destination MAC Address field of the Inner Ethernet Header (see
section 3.2 of <xref target="RFC7637"/>).<vspace blankLines="1"/> <xref target="RFC7637" sectionFormat="of" section="3.2"/>).</t>
If the M bit is not set, and the payload being sent through the <t>
If the M bit is set to 0, and the payload being sent through the
NVGRE tunnel is an Ethernet frame, the Destination MAC Address NVGRE tunnel is an Ethernet frame, the Destination MAC Address
field of the Inner Ethernet Header is just the Destination MAC field of the Inner Ethernet Header is just the Destination MAC
Address field of the payload's Ethernet header. Address field of the payload's Ethernet header.
<vspace blankLines="1"/> </t>
If the M bit is not set, and the payload being sent through the <t>
If the M bit is set to 0, and the payload being sent through the
NVGRE tunnel is an IP or MPLS packet, the Inner Destination MAC NVGRE tunnel is an IP or MPLS packet, the Inner Destination MAC
Address field is set to a configured value; if there is no Address field is set to a configured value; if there is no
configured value, the NVGRE tunnel cannot be used. configured value, the NVGRE tunnel cannot be used.
</t> </t>
<t> If the V bit is not set, and the BGP UPDATE message has </li>
AFI/SAFI other than Ethernet VPNs (EVPN) then the <li> If the V bit is set to 0, and the BGP UPDATE message has an
AFI/SAFI other than Ethernet VPNs (EVPNs), then the
NVGRE tunnel cannot be used. NVGRE tunnel cannot be used.
</t> </li>
<li>
<t><xref target="use-of-vni"/> describes how the VSID (Virtual Subnet Ide <xref target="use-of-vni" format="default"/> describes how the VSI
ntifier) field of the D field of the
NVGRE encapsulation header is set.</t> NVGRE encapsulation header is set.</li>
</ul>
</list> </section>
</t> <section numbered="true" toc="default">
<name>L2TPv3 (Tunnel Type 1)</name>
</section> <t>
When the tunnel type of the TLV is <xref target="RFC3931" format="default">L2
<section title="L2TPv3 (tunnel type 1)"><t> TPv3 over IP</xref>, the length of the sub-TLV is
When the Tunnel Type of the TLV is <xref target="RFC3931">L2TPv3 over IP</xre
f>, the length of the sub-TLV is
between 4 and 12 between 4 and 12
octets, depending on the length of the cookie. octets, depending on the length of the cookie.
The following is the structure of the Value field of the Encapsulation sub-TL The structure of the Value field of the Encapsulation sub-TLV is shown in <xr
V:</t> ef target="ref-l2tpv3-encapsulation-sub-tlv"/>.</t>
<figure anchor="ref-l2tpv3-encapsulation-sub-tlv">
<figure title="L2TPv3 Encapsulation Sub-TLV Value Field" anchor="ref-l2tp <name>L2TPv3 Encapsulation Sub-TLV Value Field</name>
v3-encapsulation-sub-tlv"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID (4 octets) | | Session ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Cookie (Variable) | | Cookie (variable) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t><list hangIndent="3" style="hanging"><t> <dl newline="false" spacing="normal" indent="3">
Session ID: a non-zero 4-octet value locally assigned by the <dt>Session ID:</dt>
<dd>
A non-zero 4-octet value locally assigned by the
advertising router that serves as a lookup key for the incoming advertising router that serves as a lookup key for the incoming
packet's context.</t> packet's context.</dd>
<dt>Cookie:</dt>
</list> <dd>
</t> <t>
An optional, variable-length (encoded in 0 to 8
<t><list hangIndent="3" style="hanging"><t>
Cookie: an optional, variable length (encoded in octets -- 0 to 8
octets) value used by L2TPv3 to check the association of a octets) value used by L2TPv3 to check the association of a
received data message with the session identified by the Session received data message with the session identified by the Session
ID. Generation and usage of the cookie value is as specified in ID. Generation and usage of the cookie value is as specified in
<xref target="RFC3931"/>.</t> <xref target="RFC3931" format="default"/>. </t>
<t>
</list> The length of the cookie is not encoded explicitly but can be
</t> calculated as (sub-TLV length - 4).</t></dd>
</dl>
<t><list hangIndent="3" style="hanging"><t> </section>
The length of the cookie is not encoded explicitly, but can be <section anchor="gre" numbered="true" toc="default">
calculated as (sub-TLV length - 4).</t> <name>GRE (Tunnel Type 2)</name>
<t>
</list> When the tunnel type of the TLV is <xref target="RFC2784" format="default">GR
</t> E</xref>, the length of the sub-TLV is 4 octets. The structure of the Value fiel
d of the Encapsulation sub-TLV is shown in <xref target="ref-gre-encapsulation-s
</section> ub-tlv"/>.</t>
<section title="GRE (tunnel type 2)" anchor="gre"><t>
When the Tunnel Type of the TLV is <xref target="RFC2784">GRE</xref>, the len
gth of the sub-TLV is 4 octets. The
following is the structure of the Value field of the Encapsulation sub-TLV:</
t>
<figure title="GRE Encapsulation Sub-TLV" anchor="ref-gre-encapsulation-s <figure anchor="ref-gre-encapsulation-sub-tlv">
ub-tlv"><artwork><![CDATA[ <name>GRE Encapsulation Sub-TLV Value Field</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GRE Key (4 octets) | | GRE Key (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t><list hangIndent="3" style="hanging"><t> <dl newline="false" spacing="normal" indent="3">
GRE Key: 4-octet field <xref target="RFC2890"/> that is generated by the <dt>GRE Key:</dt>
<dd>
4-octet field <xref target="RFC2890" format="default"/> that is generated
by the
advertising router. Note that the key is optional. Unless a key value is being advertising router. Note that the key is optional. Unless a key value is being
advertised, the GRE Encapsulation sub-TLV MUST NOT be present.</t> advertised, the GRE Encapsulation sub-TLV <bcp14>MUST NOT</bcp14> be prese
nt.</dd>
</list> </dl>
</t> </section>
<section numbered="true" toc="default">
</section> <name>MPLS-in-GRE (Tunnel Type 11)</name>
<t>
<section title="MPLS-in-GRE (tunnel type 11)"><t> When the tunnel type is <xref target="RFC4023" format="default">MPLS-in-GRE</
When the Tunnel Type is <xref target="RFC4023">MPLS-in-GRE</xref>, the length xref>, the length of the sub-TLV is 4 octets. The structure of the Value field o
of the sub-TLV is 4 octets. The f the Encapsulation sub-TLV is shown in <xref target="ref-mpls-in-gre-encapsulat
following is the structure of the Value field of the Encapsulation sub-TLV:</ ion-sub-tlv"/>.</t>
t> <figure anchor="ref-mpls-in-gre-encapsulation-sub-tlv">
<name>MPLS-in-GRE Encapsulation Sub-TLV Value Field</name>
<figure title="MPLS-in-GRE Encapsulation Sub-TLV Value Field" anchor="ref <artwork name="" type="" align="left" alt=""><![CDATA[
-mpls-in-gre-encapsulation-sub-tlv"><artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GRE-Key (4 Octets) | | GRE Key (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t><list hangIndent="3" style="hanging"><t>
GRE-Key: 4-octet field <xref target="RFC2890"/> that is generated by the <dl newline="false" spacing="normal" indent="3">
<dt>GRE Key:</dt>
<dd>
4-octet field <xref target="RFC2890" format="default"/> that is generated
by the
advertising router. Note that the key is optional. Unless a key advertising router. Note that the key is optional. Unless a key
value is being advertised, the MPLS-in-GRE Encapsulation sub-TLV value is being advertised, the MPLS-in-GRE Encapsulation sub-TLV
MUST NOT be present.</t> <bcp14>MUST NOT</bcp14> be present.</dd>
</dl>
</list> <t>
</t> Note that the GRE tunnel type defined in <xref target="gre" format="default"/
> can be used
<t> instead of the MPLS-in-GRE tunnel type when it is necessary to
Note that the GRE Tunnel Type defined in <xref target="gre"/> can be used
instead of the MPLS-in-GRE Tunnel Type when it is necessary to
encapsulate MPLS in GRE. Including a TLV of the MPLS-in-GRE tunnel encapsulate MPLS in GRE. Including a TLV of the MPLS-in-GRE tunnel
type is equivalent to including a TLV of the GRE Tunnel Type that type is equivalent to including a TLV of the GRE tunnel type that
also includes a Protocol Type sub-TLV (<xref target="protocol-type"/>) specif also includes a Protocol Type sub-TLV (<xref target="protocol-type" format="d
ying MPLS efault"/>) specifying MPLS
as the protocol to be encapsulated.</t> as the protocol to be encapsulated.</t>
<t>
<t>
Although the MPLS-in-GRE tunnel type is just a special case of the GRE Although the MPLS-in-GRE tunnel type is just a special case of the GRE
tunnel type and thus is not strictly necessary, it is included for reasons tunnel type and thus is not strictly necessary, it is included for reasons
of backwards compatibility with, for example, implementations of <xref target ="RFC8365"/>. of backwards compatibility with, for example, implementations of <xref target ="RFC8365" format="default"/>.
</t> </t>
</section>
</section> </section>
<section numbered="true" toc="default">
</section> <name>Outer Encapsulation Sub-TLVs</name>
<t>
<section title="Outer Encapsulation Sub-TLVs"><t> The Encapsulation sub-TLV for a particular tunnel type allows one to
The Encapsulation sub-TLV for a particular Tunnel Type allows one to
specify the values that are to be placed in certain fields of the specify the values that are to be placed in certain fields of the
encapsulation header for that Tunnel Type. However, some tunnel encapsulation header for that tunnel type. However, some tunnel
types require an outer IP encapsulation, and some also require an types require an outer IP encapsulation, and some also require an
outer UDP encapsulation. The Encapsulation sub-TLV for a given outer UDP encapsulation. The Encapsulation sub-TLV for a given
Tunnel Type does not usually provide a way to specify values for tunnel type does not usually provide a way to specify values for
fields of the outer IP and/or UDP encapsulations. If it is necessary fields of the outer IP and/or UDP encapsulations. If it is necessary
to specify values for fields of the outer encapsulation, additional to specify values for fields of the outer encapsulation, additional
sub-TLVs must be used. This document defines two such sub-TLVs.</t> sub-TLVs must be used. This document defines two such sub-TLVs.</t>
<t>
<t> If an outer Encapsulation sub-TLV occurs in a TLV for a tunnel type
If an outer Encapsulation sub-TLV occurs in a TLV for a Tunnel Type
that does not use the corresponding outer encapsulation, the sub-TLV that does not use the corresponding outer encapsulation, the sub-TLV
MUST be treated as if it were an unrecognized type of sub-TLV.</t> <bcp14>MUST</bcp14> be treated as if it were an unrecognized type of sub-TLV.
</t>
<section title="DS Field (type code 7)"><t> <section numbered="true" toc="default">
<name>DS Field (Type Code 7)</name>
<t>
Most of the tunnel types that can be specified in the Tunnel Most of the tunnel types that can be specified in the Tunnel
Encapsulation attribute require an outer IP encapsulation. The Encapsulation attribute require an outer IP encapsulation. The
Differentiated Services (DS) Field sub-TLV can be carried in the TLV Differentiated Services (DS) Field sub-TLV can be carried in the TLV
of any such Tunnel Type. It specifies the setting of the one-octet of any such tunnel type. It specifies the setting of the one-octet
Differentiated Services field in the outer IPv4 or IPv6 encapsulation (see Differentiated Services field in the outer IPv4 or IPv6 encapsulation (see
<xref target="RFC2474"/>). Any one-octet value can be transported; the seman <xref target="RFC2474" format="default"/>). Any one-octet value can be trans
tics ported; the semantics
of the DSCP field is beyond the scope of this document. The Value field is a of the DSCP (Differentiated Services Code Point) field is beyond the scope of
lways a single octet.</t> this document. The Value field is always a single octet.</t>
<figure anchor="ref-ds-field">
<figure title="DS Field Sub-TLV Value Field" anchor="ref-ds-field"><artwo <name>DS Field Sub-TLV Value Field</name>
rk><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| DS value | | DS value |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>
<t>
Because the interpretation of the DSCP field at the recipient may be Because the interpretation of the DSCP field at the recipient may be
different from its interpretation at the originator, an implementation different from its interpretation at the originator, an implementation
MAY provide a facility to use policy to filter or modify the DS Field. <bcp14>MAY</bcp14> provide a facility to use policy to filter or modify the D
</t> S field.
</t>
</section> </section>
<section numbered="true" toc="default">
<section title="UDP Destination Port (type code 8)"><t> <name>UDP Destination Port (Type Code 8)</name>
<t>
Some of the tunnel types that can be specified in the Tunnel Some of the tunnel types that can be specified in the Tunnel
Encapsulation attribute require an outer UDP encapsulation. Encapsulation attribute require an outer UDP encapsulation.
Generally there is a standard UDP Destination Port value for a Generally, there is a standard UDP destination port value for a
particular Tunnel Type. However, sometimes it is useful to be able particular tunnel type. However, sometimes it is useful to be able
to use a non-standard UDP destination port. If a particular tunnel to use a nonstandard UDP destination port. If a particular tunnel
type requires an outer UDP encapsulation, and it is desired to use a type requires an outer UDP encapsulation, and it is desired to use a
UDP destination port other than the standard one, the port to be used UDP destination port other than the standard one, the port to be used
can be specified by including a UDP Destination Port sub-TLV. The can be specified by including a UDP Destination Port sub-TLV. The
Value field of this sub-TLV is always a two-octet field, containing Value field of this sub-TLV is always a two-octet field, containing
the port value. Any two-octet value other than zero can be transported. the port value. Any two-octet value other than zero can be transported.
If the reserved value zero is received, the sub-TLV MUST be treated If the reserved value zero is received, the sub-TLV <bcp14>MUST</bcp14> be tr
as malformed according to the rules of <xref target="validation-and-error"/>. eated
</t> as malformed, according to the rules of <xref target="validation-and-error" f
ormat="default"/>.</t>
<figure title="UDP Destination Port Sub-TLV Value Field" anchor="ref-udp- <figure anchor="ref-udp-dest-port">
dest-port"><artwork><![CDATA[ <name>UDP Destination Port Sub-TLV Value Field</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Port (2 Octets) | | UDP Port (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
</section>
</section> </section>
<section numbered="true" toc="default">
</section> <name>Sub-TLVs for Aiding Tunnel Selection</name>
<section anchor="protocol-type" numbered="true" toc="default">
<section title="Sub-TLVs for Aiding Tunnel Selection"> <name>Protocol Type Sub-TLV (Type Code 2)</name>
<section title="Protocol Type Sub-TLV (type code 2)" anchor="protocol-typ <t>
e"><t> The Protocol Type sub-TLV <bcp14>MAY</bcp14> be included in a given TLV to in
The Protocol Type sub-TLV MAY be included in a given TLV to indicate dicate
the type of the payload packets that are allowed to be encapsulated with the the type of the payload packets that are allowed to be encapsulated with the
tunnel parameters that are being signaled in the TLV. Packets with other tunnel parameters that are being signaled in the TLV. Packets with other
payload types MUST NOT be encapsulated in the relevant tunnel. The Value payload types <bcp14>MUST NOT</bcp14> be encapsulated in the relevant tunnel.
field of the sub-TLV contains a 2-octet value from IANA's "ETHER TYPES" The Value
registry <xref target="Ethertypes"/>. If the reserved value 0xFFFF is field of the sub-TLV contains a 2-octet value from IANA's
received, the sub-TLV MUST be treated "ETHER TYPES"
as malformed according to the rules of <xref target="validation-and-error"/>. registry <xref target="IANA-ETHERTYPES" />. If the reserved value 0xFFFF is
</t> received, the sub-TLV <bcp14>MUST</bcp14> be treated
as malformed according to the rules of <xref target="validation-and-error" fo
<figure title="Protocol Type Sub-TLV Value Field" anchor="ref-proto-type"><a rmat="default"/>.</t>
rtwork><![CDATA[ <figure anchor="ref-proto-type">
<name>Protocol Type Sub-TLV Value Field</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype (2 Octets) | | Ethertype (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>
<t>
For example, if there are three L2TPv3 sessions, one carrying For example, if there are three L2TPv3 sessions, one carrying
IPv4 packets, one carrying IPv6 packets, and one carrying MPLS IPv4 packets, one carrying IPv6 packets, and one carrying MPLS
packets, the egress router will include three TLVs of L2TPv3 packets, the egress router will include three TLVs of L2TPv3
encapsulation type, each specifying a different Session ID and a encapsulation type, each specifying a different Session ID and a
different payload type. The Protocol Type sub-TLV for these will be different payload type. The Protocol Type sub-TLV for these will be
IPv4 (protocol type = 0x0800), IPv6 (protocol type = 0x86dd), and IPv4 (protocol type = 0x0800), IPv6 (protocol type = 0x86dd), and
MPLS (protocol type = 0x8847), respectively. This informs the MPLS (protocol type = 0x8847), respectively. This informs the
ingress routers of the appropriate encapsulation information to use ingress routers of the appropriate encapsulation information to use
with each of the given protocol types. Insertion of the specified with each of the given protocol types. Insertion of the specified
Session ID at the ingress routers allows the egress to process the Session ID at the ingress routers allows the egress to process the
incoming packets correctly, according to their protocol type.</t> incoming packets correctly, according to their protocol type.</t>
<t>
<t> Note that for tunnel types whose names are of the form "X-in-Y"
Note that for tunnel types whose names are of the form "X-in-Y", (for example, MPLS-in-GRE), only packets of the specified payload type "X"
for example, "MPLS-in-GRE", only packets of the specified payload type "X"
are to be carried through the tunnel of type "Y". This is the are to be carried through the tunnel of type "Y". This is the
equivalent of specifying a Tunnel Type "Y" and including in its TLV a equivalent of specifying a tunnel type "Y" and including in its TLV a
Protocol Type sub-TLV (see <xref target="protocol-type"/>) specifying Protocol Type sub-TLV (see <xref target="protocol-type" format="default"/>) s
protocol "X". If the Tunnel Type is "X-in-Y", it is unnecessary, pecifying
protocol "X". If the tunnel type is "X-in-Y", it is unnecessary,
though harmless, to explicitly include a Protocol Type sub-TLV though harmless, to explicitly include a Protocol Type sub-TLV
specifying "X". Also, for "X-in-Y" type tunnels, a Protocol Type specifying "X". Also, for "X-in-Y" type tunnels, a Protocol Type
sub-TLV specifying anything other than "X" MUST be ignored; this is sub-TLV specifying anything other than "X" <bcp14>MUST</bcp14> be ignored; th
discussed further in <xref target="validation-and-error"/>. is is
</t> discussed further in <xref target="validation-and-error" format="default"/>.
</t>
</section> </section>
<section anchor="color" numbered="true" toc="default">
<section title="Color Sub-TLV (type code 4)" anchor="color"><t> <name>Color Sub-TLV (Type Code 4)</name>
The Color sub-TLV MAY be used as a way to "color" the <t>
The Color sub-TLV <bcp14>MAY</bcp14> be used as a way to "color" the
corresponding Tunnel TLV. The Value field of the sub-TLV is eight corresponding Tunnel TLV. The Value field of the sub-TLV is eight
octets long, and consists of a Color Extended Community, as defined octets long and consists of a Color Extended Community, as defined
in <xref target="color-extcomm"/>. For the use of this sub-TLV and Extended in <xref target="color-extcomm" format="default"/>. For the use of this sub-
Community, TLV and extended community,
please see <xref target="recursive-nh-resolution"/>.</t> please see <xref target="recursive-nh-resolution" format="default"/>.</t>
<t>The format of the Value field is depicted in
<t>The format of the Value field is depicted in <xref target="ref-color-extended-community" format="default"/>.</t>
<xref target="ref-color-extended-community"/>.</t> <t>
<t>
If the Length field of a Color sub-TLV has a value other than 8, or the first two If the Length field of a Color sub-TLV has a value other than 8, or the first two
octets of its Value field are not 0x030b, the sub-TLV MUST be octets of its Value field are not 0x030b, the sub-TLV <bcp14>MUST</bcp14> be
treated as if it were an unrecognized sub-TLV (see <xref target="validation-a treated as if it were an unrecognized sub-TLV (see <xref target="validation-a
nd-error"/>).</t> nd-error" format="default"/>).</t>
</section>
</section> </section>
<section numbered="true" toc="default">
</section> <name>Embedded Label Handling Sub-TLV (Type Code 9)</name>
<t>
<section title="Embedded Label Handling Sub-TLV (type code 9)"><t>
Certain BGP address families (corresponding to particular AFI/SAFI Certain BGP address families (corresponding to particular AFI/SAFI
pairs, for example, 1/4, 2/4, 1/128, 2/128) have MPLS labels embedded in pairs, for example, 1/4, 2/4, 1/128, 2/128) have MPLS labels embedded in
their NLRIs. The term "embedded label" is used to refer to the their NLRIs. The term "embedded label" is used to refer to the
MPLS label that is embedded in an NLRI, and the term "labeled address family" MPLS label that is embedded in an NLRI, and the term "labeled address family"
to refer to any AFI/SAFI that has embedded labels.</t> to refer to any AFI/SAFI that has embedded labels.</t>
<t>
<t>
Some of the tunnel types (for example, VXLAN and NVGRE) that can Some of the tunnel types (for example, VXLAN and NVGRE) that can
be specified in the Tunnel Encapsulation attribute have an be specified in the Tunnel Encapsulation attribute have an
encapsulation header containing a "Virtual Network" identifier of some encapsulation header containing a virtual network identifier of some
sort. The Encapsulation sub-TLVs for these tunnel types may sort. The Encapsulation sub-TLVs for these tunnel types may
optionally specify a value for the virtual network identifier.</t> optionally specify a value for the virtual network identifier.</t>
<t>
<t>
Suppose a Tunnel Encapsulation attribute is attached to an UPDATE of Suppose a Tunnel Encapsulation attribute is attached to an UPDATE of
a labeled address family, and it is decided to use a particular a labeled address family, and it is decided to use a particular
tunnel (specified in one of the attribute's TLVs) for transmitting a tunnel (specified in one of the attribute's TLVs) for transmitting a
packet that is being forwarded according to that UPDATE. When packet that is being forwarded according to that UPDATE. When
forming the encapsulation header for that packet, different forming the encapsulation header for that packet, different
deployment scenarios require different handling of the embedded label deployment scenarios require different handling of the embedded label
and/or the virtual network identifier. The Embedded Label Handling and/or the virtual network identifier. The Embedded Label Handling
sub-TLV can be used to control the placement of the embedded label sub-TLV can be used to control the placement of the embedded label
and/or the virtual network identifier in the encapsulation.</t> and/or the virtual network identifier in the encapsulation.</t>
<t>
<t>
The Embedded Label Handling sub-TLV may be included in any TLV of the The Embedded Label Handling sub-TLV may be included in any TLV of the
Tunnel Encapsulation attribute. If the Tunnel Encapsulation Tunnel Encapsulation attribute. If the Tunnel Encapsulation
attribute is attached to an UPDATE of a non-labeled address family, attribute is attached to an UPDATE of a non-labeled address family,
then the sub-TLV MUST be disregarded. If the sub-TLV is contained in a then the sub-TLV <bcp14>MUST</bcp14> be disregarded. If the sub-TLV is conta
TLV whose Tunnel Type does not have a virtual network identifier in ined in a
its encapsulation header, the sub-TLV MUST be disregarded. In TLV whose tunnel type does not have a virtual network identifier in
those cases where the sub-TLV is ignored, it MUST NOT be its encapsulation header, the sub-TLV <bcp14>MUST</bcp14> be disregarded. In
those cases where the sub-TLV is ignored, it <bcp14>MUST NOT</bcp14> be
stripped from the TLV before the route is propagated.</t> stripped from the TLV before the route is propagated.</t>
<t>
<t>
The sub-TLV's Length field always contains the value 1, and its Value The sub-TLV's Length field always contains the value 1, and its Value
field consists of a single octet. The following values are defined:</t> field consists of a single octet. The following values are defined:</t>
<dl spacing="normal" indent="4">
<dt>1:</dt><dd>The payload will be an MPLS packet with the embedded la
bel at the top of its label stack.</dd>
<dt>2:</dt>
<dd><t>The embedded label is not carried in the payload but is either c
arried
in the Virtual Network Identifier field of the
encapsulation header or else ignored entirely.</t>
</dd>
</dl>
<t>If any value other than 1 or 2 is carried, the sub-TLV <bcp14>MUST</bc
p14> be
considered malformed, according to the procedures of <xref target="valida
tion-and-error" format="default"/>.</t>
<t><list style="hanging" hangIndent="3"><t hangText="1: The payload will <t>
be an MPLS packet with the embedded label at"> Please see <xref target="use-of-vni" format="default"/> for the details of ho
<vspace blankLines="0"/> w this sub-TLV is used when
the top of its label stack.
</t>
<t hangText="2: The embedded label is not carried in the payload, but is
carried">
<vspace blankLines="0"/>
either in the virtual network identifier field of the
encapsulation header, or else is ignored entirely.
</t>
<t>If any value other than 1 or 2 is carried, the sub-TLV MUST be
considered malformed, according to the procedures of <xref target="valida
tion-and-error"/>.
</t>
</list>
</t>
<t>
Please see <xref target="use-of-vni"/> for the details of how this sub-TLV is
used when
it is carried by an UPDATE of a labeled address family.</t> it is carried by an UPDATE of a labeled address family.</t>
<figure anchor="ref-embedded-label">
<figure title="Embedded Label Handling Sub-TLV Value Field" anchor="ref-e <name>Embedded Label Handling Sub-TLV Value Field</name>
mbedded-label"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| 1 or 2 | | 1 or 2 |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
</section>
</section> <section anchor="label-stack" numbered="true" toc="default">
<name>MPLS Label Stack Sub-TLV (Type Code 10)</name>
<section title="MPLS Label Stack Sub-TLV (type code 10)" anchor="label-st <t>
ack"><t> This sub-TLV allows an MPLS label stack <xref target="RFC3032" format="defaul
This sub-TLV allows an MPLS label stack (<xref target="RFC3032"/>) to be asso t"/> to be associated
ciated
with a particular tunnel.</t> with a particular tunnel.</t>
<t> <t>
The length of the sub-TLV is a multiple of 4 octets and the Value field of th The length of the sub-TLV is a multiple of 4 octets, and the Value field of t
is sub-TLV his sub-TLV
is a sequence of MPLS label stack entries. The first entry in the sequence i s the is a sequence of MPLS label stack entries. The first entry in the sequence i s the
"topmost" label, the final entry in the sequence is the "bottommost" label. "topmost" label, and the final entry in the sequence is the "bottommost" labe
When this l. When this
label stack is pushed onto a packet, this ordering MUST be preserved.</t> label stack is pushed onto a packet, this ordering <bcp14>MUST</bcp14> be pre
served.</t>
<t><list style="hanging" hangIndent="-1"><t hangText="Each label stack en <dl newline="true" spacing="normal">
try has the following format:"> <dt>Each label stack entry has the format shown in <xref target="ref-m
<vspace blankLines="0"/> pls-label-stack-sub-tlv"/>.</dt>
</t> <dd/>
</dl>
</list> <figure anchor="ref-mpls-label-stack-sub-tlv">
</t> <name>MPLS Label Stack Sub-TLV Value Field</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure title="MPLS Label Stack Sub-TLV Value Field" anchor="ref-mpls-lab
el-stack-sub-tlv"><artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |S| TTL | | Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
The fields are as defined in <xref target="RFC3032"/>, <xref target="RFC5462" The fields are as defined in <xref target="RFC3032" format="default"/> and <x
/>. ref target="RFC5462" format="default"/>.
</t> </t>
<t> <t>
If a packet is to be sent through the tunnel identified in a If a packet is to be sent through the tunnel identified in a
particular TLV, and if that TLV contains an MPLS Label Stack sub-TLV, particular TLV, and if that TLV contains an MPLS Label Stack sub-TLV,
then the label stack appearing in the sub-TLV MUST be pushed onto the then the label stack appearing in the sub-TLV <bcp14>MUST</bcp14> be pushed o nto the
packet before any packet before any
other labels are pushed onto the packet. (See <xref target="usage"/> other labels are pushed onto the packet. (See <xref target="usage" format="de fault"/>
for further discussion.)</t> for further discussion.)</t>
<t>
<t>
In particular, if the Tunnel Encapsulation attribute is attached to a In particular, if the Tunnel Encapsulation attribute is attached to a
BGP UPDATE of a labeled address family, the contents of the MPLS BGP UPDATE of a labeled address family, the contents of the MPLS
Label Stack sub-TLV MUST be pushed onto the packet before the label Label Stack sub-TLV <bcp14>MUST</bcp14> be pushed onto the packet before the label
embedded in the NLRI is pushed onto the packet.</t> embedded in the NLRI is pushed onto the packet.</t>
<t>
<t>
If the MPLS Label Stack sub-TLV is included in a TLV identifying a If the MPLS Label Stack sub-TLV is included in a TLV identifying a
Tunnel Type that uses virtual network identifiers (see <xref target="use-of-v tunnel type that uses virtual network identifiers (see <xref target="use-of-v
ni"/>), ni" format="default"/>),
the contents of the MPLS Label Stack sub-TLV MUST be pushed onto the the contents of the MPLS Label Stack sub-TLV <bcp14>MUST</bcp14> be pushed on
packet before the procedures of <xref target="use-of-vni"/> are applied.</t> to the
packet before the procedures of <xref target="use-of-vni" format="default"/>
<t> are applied.</t>
The number of label stack entries in the sub-TLV MUST be determined <t>
from the sub-TLV length field. Thus it is not necessary to set the S The number of label stack entries in the sub-TLV <bcp14>MUST</bcp14> be deter
mined
from the Sub-TLV Length field. Thus, it is not necessary to set the S
bit in any of the label stack entries of the sub-TLV, and the setting bit in any of the label stack entries of the sub-TLV, and the setting
of the S bit is ignored when parsing the sub-TLV. When the label of the S bit is ignored when parsing the sub-TLV. When the label stack entri
stack entries are pushed onto a packet that already has a label es are pushed onto a packet that already has a label
stack, the S bits of all the entries being pushed MUST be cleared. When the stack, the S bits of all the entries being pushed <bcp14>MUST</bcp14> be clea
label red. When the label stack entries are pushed onto a packet that does not alread
stack entries are pushed onto a packet that does not already have a y have a
label stack, the S bit of the bottommost label stack entry MUST be label stack, the S bit of the bottommost label stack entry <bcp14>MUST</bcp14
set, and the S bit of all the other label stack entries MUST be > be
set, and the S bit of all the other label stack entries <bcp14>MUST</bcp14> b
e
cleared.</t> cleared.</t>
<t>
<t> The Traffic Class (TC) field <xref target="RFC3270" format="default"/><xref t
The TC (Traffic Class) field (<xref target="RFC3270"/>, <xref arget="RFC5129" format="default"/> of each label stack entry <bcp14>SHOULD</bcp1
target="RFC5129"/>) of each label stack entry SHOULD be set to 0, 4> be set to 0,
unless changed by policy at the originator of the sub-TLV. When unless changed by policy at the originator of the sub-TLV. When
pushing the label stack onto a packet, the TC of each label stack pushing the label stack onto a packet, the TC of each label stack
SHOULD be preserved, unless local policy results in a modification. <bcp14>SHOULD</bcp14> be preserved, unless local policy results in a modifica
</t> tion.
</t>
<t> <t>
The TTL (Time to Live) field of each label stack entry SHOULD be set The TTL (Time to Live) field of each label stack entry <bcp14>SHOULD</bcp14>
be set
to 255, unless changed to some other non-zero value by policy at the to 255, unless changed to some other non-zero value by policy at the
originator of the sub-TLV. When pushing the label stack onto a originator of the sub-TLV. When pushing the label stack onto a
packet, the TTL of each label stack entry SHOULD be preserved, unless packet, the TTL of each label stack entry <bcp14>SHOULD</bcp14> be preserved, unless
local policy results in a modification to some other non-zero value. local policy results in a modification to some other non-zero value.
If any label stack entry in the sub-TLV has a TTL value of zero, the If any label stack entry in the sub-TLV has a TTL value of zero, the
router that is pushing the stack on a packet MUST change the value to router that is pushing the stack onto a packet <bcp14>MUST</bcp14> change the value to
a non-zero value, either 255 or some other value as determined by a non-zero value, either 255 or some other value as determined by
policy as discussed above.</t> policy as discussed above.</t>
<t>
<t>
Note that this sub-TLV can appear within a TLV identifying any Note that this sub-TLV can appear within a TLV identifying any
type of tunnel, not just within a TLV identifying an MPLS tunnel. type of tunnel, not just within a TLV identifying an MPLS tunnel.
However, if this sub-TLV appears within a TLV identifying an MPLS However, if this sub-TLV appears within a TLV identifying an MPLS
tunnel (or an MPLS-in-X tunnel), this sub-TLV plays the same role tunnel (or an MPLS-in-X tunnel), this sub-TLV plays the same role
that would be played by an MPLS Encapsulation sub-TLV. Therefore, an that would be played by an MPLS Encapsulation sub-TLV. Therefore, an
MPLS Encapsulation sub-TLV is not defined.</t> MPLS Encapsulation sub-TLV is not defined.</t>
<t>
<t>
Although this specification does not supply detailed instructions Although this specification does not supply detailed instructions
for validating the received label stack, implementations might for validating the received label stack, implementations might
impose restrictions on the label stack they can support. If an impose restrictions on the label stack they can support. If an
invalid or unsupported label stack is received, <!-- the sub-TLV MAY invalid or unsupported label stack is received, the tunnel <bcp14>MAY</bcp14>
be treated as malformed according to the procedures of be treated as not feasible, according to the
<xref target="validation-and-error"/>, procedures of <xref target="usage" format="default"/>.
or --> the tunnel MAY be treated as not feasible according to the </t>
procedures of <xref target="usage"/>. </section>
</t> <section anchor="prefix-sid" numbered="true" toc="default">
<name>Prefix-SID Sub-TLV (Type Code 11)</name>
</section> <t>
<xref target="RFC8669" format="default"/> defines a BGP path
<section title="Prefix-SID Sub-TLV (type code 11)" anchor="prefix-sid"><t attribute known as the "BGP Prefix-SID attribute". This attribute is
>
<xref target="RFC8669"/> defines a BGP Path
attribute known as the "Prefix-SID Attribute". This attribute is
defined to contain a sequence of one or more TLVs, where each TLV is defined to contain a sequence of one or more TLVs, where each TLV is
either a "Label-Index" TLV, or an "Originator SRGB (Source Routing either a Label-Index TLV or an Originator SRGB (Source Routing
Global Block)" TLV.</t> Global Block) TLV.</t>
<t>
<t> This document defines a Prefix-SID (Prefix Segment Identifier) sub-TLV.
This document defines a Prefix-SID sub-TLV.
The Value field of the Prefix-SID sub-TLV can be set to any permitted The Value field of the Prefix-SID sub-TLV can be set to any permitted
value of the Value field of a BGP Prefix-SID attribute <xref value of the Value field of a BGP Prefix-SID attribute <xref target="RFC8669"
target="RFC8669"/>. format="default"/>.
</t> </t>
<t>
<t> <xref target="RFC8669" format="default"/> only defines behavior when the BGP
<xref target="RFC8669"/> only defines behavior when the Prefix-SID Prefix-SID
Attribute is attached to routes of type IPv4/IPv6 Labeled Unicast attribute is attached to routes of type IPv4/IPv6 Labeled Unicast
(<xref target="RFC4760"/>, <xref target="RFC8277"/>), and it only <xref target="RFC4760" format="default"/><xref target="RFC8277" format="defau
defines values of the Prefix-SID Attribute for those cases. Therefore, lt"/>, and it only
similar limitations exist for the Prefix-SID sub-TLV: it SHOULD only defines values of the BGP Prefix-SID attribute for those cases. Therefore,
similar limitations exist for the Prefix-SID sub-TLV: it <bcp14>SHOULD</bcp14
> only
be included in a BGP UPDATE message for one of the address families be included in a BGP UPDATE message for one of the address families
defined in <xref target="RFC8669"/>. If included in a BGP UPDATE for for which <xref target="RFC8669" format="default"/> has a defined behavior, n
any other address family then it MUST be ignored. amely BGP IPv4/IPv6 Labeled Unicast <xref target="RFC4760" format="default"/> <x
</t> ref target="RFC8277" format="default"/>. If included in a BGP UPDATE for
any other address family, it <bcp14>MUST</bcp14> be ignored.
<t> </t>
<t>
The Prefix-SID sub-TLV can occur in a TLV identifying any type of The Prefix-SID sub-TLV can occur in a TLV identifying any type of
tunnel. If an Originator SRGB is specified in the sub-TLV, that SRGB tunnel. If an Originator SRGB is specified in the sub-TLV, that SRGB
MUST be interpreted to be the SRGB used by the tunnel's <bcp14>MUST</bcp14> be interpreted to be the SRGB used by the tunnel's
egress endpoint. The Label-Index, if present, is the Segment Routing SID egress endpoint. The Label-Index, if present, is the Segment Routing SID
that the tunnel's egress endpoint uses to represent the prefix that the tunnel's egress endpoint uses to represent the prefix
appearing in the NLRI field of the BGP UPDATE to which the Tunnel appearing in the NLRI field of the BGP UPDATE to which the Tunnel
Encapsulation attribute is attached.</t> Encapsulation attribute is attached.</t>
<t>
<t>
If a Label-Index is present in the Prefix-SID sub-TLV, then when a If a Label-Index is present in the Prefix-SID sub-TLV, then when a
packet is sent through the tunnel identified by the TLV, if that tunnel packet is sent through the tunnel identified by the TLV, if that tunnel
is from a labeled address family, the is from a labeled address family, the
corresponding MPLS label MUST be pushed on the packet's label stack. corresponding MPLS label <bcp14>MUST</bcp14> be pushed on the packet's label stack.
The corresponding MPLS label is computed from the Label-Index value The corresponding MPLS label is computed from the Label-Index value
and the SRGB of the route's originator, as specified in section 4.1 and the SRGB of the route's originator, as specified in
of <xref target="RFC8669"/>.</t> <xref target="RFC8669" sectionFormat="of" section="4.1"/>.</t>
<t>
<t>
The corresponding MPLS label is pushed on after the processing of the The corresponding MPLS label is pushed on after the processing of the
MPLS Label Stack sub-TLV, if present, as specified in <xref target="label-sta MPLS Label Stack sub-TLV, if present, as specified in <xref target="label-sta
ck"/>. ck" format="default"/>.
It is pushed on before any other labels (for example, a label embedded in It is pushed on before any other labels (for example, a label embedded in an
UPDATE's NLRI, or a label determined by the procedures of <xref target="use-o UPDATE's NLRI or a label determined by the procedures of <xref target="use-of
f-vni"/>), -vni" format="default"/>) are pushed on the stack.</t>
are pushed on the stack.</t> <t>
<t>
The Prefix-SID sub-TLV has slightly different semantics than the The Prefix-SID sub-TLV has slightly different semantics than the
Prefix-SID attribute. When the Prefix-SID attribute is attached to a BGP Prefix-SID attribute. When the BGP Prefix-SID attribute is attached to a
given route, the BGP speaker that originally attached the attribute given route, the BGP speaker that originally attached the attribute
is expected to be in the same Segment Routing domain as the BGP is expected to be in the same Segment Routing domain as the BGP
speakers who receive the route with the attached attribute. The speakers who receive the route with the attached attribute. The
Label-Index tells the receiving BGP speakers what the prefix-SID is Label-Index tells the receiving BGP speakers what the Prefix-SID is
for the advertised prefix in that Segment Routing domain. When the for the advertised prefix in that Segment Routing domain. When the
Prefix-SID sub-TLV is used, there is no implication that the Prefix-SID sub-TLV is used, there is no implication that the
prefix-SID for the advertised prefix is the same in the Segment Prefix-SID for the advertised prefix is the same in the Segment
Routing domains of the BGP speaker that originated the sub-TLV and Routing domains of the BGP speaker that originated the sub-TLV and
the BGP speaker that received it.</t> the BGP speaker that received it.</t>
</section>
</section> </section>
<section numbered="true" toc="default">
</section> <name>Extended Communities Related to the Tunnel Encapsulation Attribute</
name>
<section title="Extended Communities Related to the Tunnel Encapsulation <section anchor="encapsulation-extcomm" numbered="true" toc="default">
Attribute"> <name>Encapsulation Extended Community</name>
<t>
<section title="Encapsulation Extended Community" anchor="encapsulation-e
xtcomm">
<t>
The Encapsulation Extended Community is a Transitive Opaque Extended The Encapsulation Extended Community is a Transitive Opaque Extended
Community. </t> Community. </t>
<t> The Encapsulation Extended Community encoding is as shown in <xref t
<t> The Encapsulation Extended Community encoding is as shown below </t> arget="ref-Encapsulation-extended-community"/>.</t>
<figure anchor="ref-Encapsulation-extended-community">
<figure title="Encapsulation Extended Community" anchor="ref-Encapsula <name>Encapsulation Extended Community</name>
tion-extended-community"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x03 (1 Octet)| 0x0c (1 Octet)| Reserved (2 Octets) | | 0x03 (1 octet)| 0x0c (1 octet)| Reserved (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (2 Octets) | Tunnel Type (2 Octets) | | Reserved (2 octets) | Tunnel Type (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The value of the high-order octet of the extended type field is 0x03, <t>The value of the high-order octet of the extended Type field is 0x03,
which indicates it's transitive. The value of the low-order octet of which indicates it's transitive. The value of the low-order octet of
the extended type field is 0x0c.</t> the extended Type field is 0x0c.</t>
<t>The last two octets of the Value field encode a tunnel type.</t>
<t>The last two octets of the Value field encode a tunnel type.</t>
<t>This Extended Community may be attached to a route of any <t>This extended community may be attached to a route of any
AFI/SAFI to which the Tunnel Encapsulation attribute may be attached. AFI/SAFI to which the Tunnel Encapsulation attribute may be attached.
Each such Extended Community identifies a particular Tunnel Type, its Each such extended community identifies a particular tunnel type; its
semantics are the same as semantics of a Tunnel Encapsulation attribute semantics are the same as semantics of a Tunnel TLV in a Tunnel Encapsulation
Tunnel TLV for which the following three conditions all hold:</t> attribute,
for which the following three conditions all hold:</t>
<t><list style="numbers"><t>it identifies the same Tunnel Type,</t> <ol spacing="normal" type="1">
<li>It identifies the same tunnel type.</li>
<t>it has a Tunnel Egress Endpoint sub-TLV for which one of the following <li>
two conditions holds:<list style="letters"><t>its "Address Family" subfie <t>It has a Tunnel Egress Endpoint sub-TLV for which one of the foll
ld contains zero, or</t> owing
two conditions holds:</t>
<t>its "Address" subfield contains the address of the next hop field of <ol spacing="normal" type="a">
the route to which the Tunnel Encapsulation attribute is attached</t> <li>Its Address Family subfield contains zero, or</li>
<li>Its Address subfield contains the address of the Next Hop fiel
</list> d of
</t> the route to which the Tunnel Encapsulation attribute is attached.</l
i>
<t>it has no other sub-TLVs.</t> </ol>
</li>
</list> <li>It has no other sub-TLVs.</li>
</t> </ol>
<t>
<t>
Such a Tunnel TLV is called a "barebones" Tunnel TLV.</t> Such a Tunnel TLV is called a "barebones" Tunnel TLV.</t>
<t>
<t> The Encapsulation Extended Community was first defined in <xref target="RFC55
The Encapsulation Extended Community was first defined in <xref target="RFC55 12" format="default"/>.
12"/>.
While it provides only a small subset of the functionality of the While it provides only a small subset of the functionality of the
Tunnel Encapsulation attribute, it is used in a number of deployed Tunnel Encapsulation attribute, it is used in a number of deployed
applications, and is still needed for backwards compatibility. applications and is still needed for backwards compatibility.
In situations where a tunnel could be encoded using In situations where a tunnel could be encoded using
a barebones TLV, it MUST be encoded using the corresponding a barebones TLV, it <bcp14>MUST</bcp14> be encoded using the corresponding
Encapsulation Extended Community. Notwithstanding, an implementation Encapsulation Extended Community. Notwithstanding, an implementation
MUST be prepared to process a tunnel received encoded as a barebones <bcp14>MUST</bcp14> be prepared to process a tunnel received encoded as a bar ebones
TLV.</t> TLV.</t>
<t>
<t> Note that for tunnel types of the form "X-in-Y" (for example, MPLS-in-GRE),
Note that for tunnel types of the form "X-in-Y", for example, MPLS-in-GRE,
the Encapsulation Extended Community implies that only packets of the the Encapsulation Extended Community implies that only packets of the
specified payload type "X" are to be carried through the tunnel of specified payload type "X" are to be carried through the tunnel of
type "Y". Packets with other payload types MUST NOT be carried through type "Y". Packets with other payload types <bcp14>MUST NOT</bcp14> be carried
such tunnels. See also <xref target="encaps-attr"/>.</t> through
such tunnels. See also <xref target="encaps-attr" format="default"/>.</t>
<t> <t>
In the remainder of this specification, when a route is referred to as In the remainder of this specification, when a route is referred to as
containing a Tunnel Encapsulation attribute with a TLV identifying a containing a Tunnel Encapsulation attribute with a TLV identifying a
particular Tunnel Type, it implicitly includes the case where particular tunnel type, it implicitly includes the case where
the route contains a Tunnel Encapsulation Extended Community the route contains an Encapsulation Extended Community
identifying that Tunnel Type.</t> identifying that tunnel type.</t>
</section>
</section> <section numbered="true" toc="default">
<name>Router's MAC Extended Community</name>
<section title="Router's MAC Extended Community"><t> <t>
<xref target="I-D.ietf-bess-evpn-inter-subnet-forwarding"/> defines a Router' <xref target="I-D.ietf-bess-evpn-inter-subnet-forwarding" format="default"/>
s MAC defines a router's MAC
Extended Community. This Extended Community, as its name implies, Extended Community. This extended community, as its name implies,
carries the MAC address of the advertising router. Since the VXLAN carries the MAC address of the advertising router. Since the VXLAN
and NVGRE Encapsulation Sub-TLVs can also optionally carry a router's and NVGRE Encapsulation sub-TLVs can also optionally carry a router's
MAC, a conflict can arise if both the Router's MAC Extended Community MAC, a conflict can arise if both the Router's MAC Extended Community
and such an Encapsulation Sub-TLV are present at the same time but and such an Encapsulation sub-TLV are present at the same time but
have different values. In have different values. In
case of such a conflict, the information in the Router's MAC Extended Communi ty case of such a conflict, the information in the Router's MAC Extended Communi ty
MUST be used.</t> <bcp14>MUST</bcp14> be used.</t>
</section>
</section> <section anchor="color-extcomm" numbered="true" toc="default">
<name>Color Extended Community</name>
<section title="Color Extended Community" anchor="color-extcomm"><t> <t>
The Color Extended Community is a Transitive Opaque Extended The Color Extended Community is a Transitive Opaque Extended
Community with the following encoding:</t> Community with the encoding shown in <xref target="ref-color-extended-communi
ty"/>.</t>
<figure title="Color Extended Community" anchor="ref-color-extended-commu <figure anchor="ref-color-extended-community">
nity"><artwork><![CDATA[ <name>Color Extended Community</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x03 (1 Octet)| 0x0b (1 Octet)| Flags (2 Octets) | | 0x03 (1 octet)| 0x0b (1 octet)| Flags (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Color Value (4 Octets) | | Color Value (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
The value of the high-order octet of the extended type field is 0x03, which The value of the high-order octet of the extended Type field is 0x03, which
indicates it is transitive. The value of the low-order octet of the extended indicates it is transitive. The value of the low-order octet of the extended
type field for this community is 0x0b. The color value is user defined and Type field for this community is 0x0b. The color value is user defined and
configured locally. No flags are defined in this document; this field MUST be configured locally. No flags are defined in this document; this field <bcp14>
set to MUST</bcp14> be set to
zero by the originator and ignored by the receiver; the value MUST NOT be zero by the originator and ignored by the receiver; the value <bcp14>MUST NOT
changed when propagating this Extended Community. The Color Value field is </bcp14> be
encoded as 4 octet value by the administrator and is outside the scope changed when propagating this extended community. The Color Value field is
of this document. For the use of this Extended Community please see encoded as a 4-octet value by the administrator and is outside the scope
<xref target="recursive-nh-resolution"/>.</t> of this document. For the use of this extended community, please see
<xref target="recursive-nh-resolution" format="default"/>.</t>
</section> </section>
</section>
</section> <section anchor="ipip-considerations" numbered="true" toc="default">
<name>Special Considerations for IP-in-IP Tunnels</name>
<section title="Special Considerations for IP-in-IP Tunnels" anchor="ipip <t>
-considerations"><t>
In certain situations with an IP fabric underlay, one could have a tunnel ove rlay In certain situations with an IP fabric underlay, one could have a tunnel ove rlay
with the tunnel type IP-in-IP. The egress BGP speaker can advertise the with the tunnel type IP-in-IP. The egress BGP speaker can advertise the
IP-in-IP tunnel endpoint address in the Tunnel Egress Endpoint sub-TLV. When IP-in-IP tunnel endpoint address in the Tunnel Egress Endpoint sub-TLV. When
the Tunnel type of the TLV is IP-in-IP, it will not have a Virtual Network the tunnel type of the TLV is IP-in-IP, it will not have a virtual network
Identifier. However, the tunnel egress endpoint address can be used in identi identifier. However, the tunnel egress endpoint address can be used in identi
fying fying
the forwarding table to use for making the forwarding decisions to forward the forwarding table to use for making the forwarding decisions to forward
the payload.</t> the payload.</t>
</section>
</section> <section anchor="usage" numbered="true" toc="default">
<name>Semantics and Usage of the Tunnel Encapsulation Attribute</name>
<section title="Semantics and Usage of the Tunnel Encapsulation attribute <t>
" anchor="usage"> The BGP Tunnel Encapsulation attribute <bcp14>MAY</bcp14> be carried in any B
<t> GP
The BGP Tunnel Encapsulation attribute MAY be carried in any BGP
UPDATE message whose AFI/SAFI is 1/1 (IPv4 Unicast), 2/1 (IPv6 UPDATE message whose AFI/SAFI is 1/1 (IPv4 Unicast), 2/1 (IPv6
Unicast), 1/4 (IPv4 Labeled Unicast), 2/4 (IPv6 Labeled Unicast), Unicast), 1/4 (IPv4 Labeled Unicast), 2/4 (IPv6 Labeled Unicast),
1/128 (VPN-IPv4 Labeled Unicast), 2/128 (VPN-IPv6 Labeled Unicast), 1/128 (VPN-IPv4 Labeled Unicast), 2/128 (VPN-IPv6 Labeled Unicast),
or 25/70 (Ethernet VPN, usually known as EVPN)). Use of the Tunnel or 25/70 (Ethernet VPN, usually known as EVPN). Use of the Tunnel
Encapsulation attribute in BGP UPDATE messages of other AFI/SAFIs is Encapsulation attribute in BGP UPDATE messages of other AFI/SAFIs is
outside the scope of this document.</t> outside the scope of this document.</t>
<t>
<t>
There is no significance to the order in which the TLVs occur within There is no significance to the order in which the TLVs occur within
the Tunnel Encapsulation attribute. Multiple TLVs may occur for a the Tunnel Encapsulation attribute. Multiple TLVs may occur for a
given Tunnel Type; each such TLV is regarded as describing a given tunnel type; each such TLV is regarded as describing a
different tunnel. (This also applies if the Tunnel Encapsulation different tunnel. (This also applies if the Encapsulation
Extended Community encoding is used.)</t> Extended Community encoding is used.)</t>
<t>
<t>
The decision to attach a Tunnel Encapsulation attribute to a given The decision to attach a Tunnel Encapsulation attribute to a given
BGP UPDATE is determined by policy. The set of TLVs and sub-TLVs BGP UPDATE is determined by policy. The set of TLVs and sub-TLVs
contained in the attribute is also determined by policy.</t> contained in the attribute is also determined by policy.</t>
<t>
<t>
Suppose that:</t> Suppose that:</t>
<ul spacing="normal">
<t><list style="symbols"><t>a given packet P must be forwarded by router <li>a given packet P must be forwarded by router R;</li>
R;</t> <li>the path along which P is to be forwarded is determined by BGP
UPDATE U;</li>
<t>the path along which P is to be forwarded is determined by BGP <li>
UPDATE U;</t> <t>UPDATE U has a Tunnel Encapsulation attribute, containing at least
<t>UPDATE U has a Tunnel Encapsulation attribute, containing at least
one TLV that identifies a "feasible tunnel" for packet P. A one TLV that identifies a "feasible tunnel" for packet P. A
tunnel is considered feasible if it has the following four tunnel is considered feasible if it has the following four
properties:<list style="symbols"><t>The Tunnel Type is supported (that properties:</t>
is, router R knows how to set <ol spacing="normal">
up tunnels of that type, how to create the encapsulation header <li>The tunnel type is supported (that is, router R knows how to set
for tunnels of that type, etc.)</t> up tunnels of that type, how to create the encapsulation header for tunnels of
that type, etc.).</li>
<t>The tunnel is of a type that can be used to carry packet P <li>The tunnel is of a type that can be used to carry packet P (for
(for example, an MPLS-in-UDP tunnel would not be a feasible tunnel for example, an MPLS-in-UDP tunnel would not be a feasible tunnel for
carrying an IP packet, unless the IP packet can first be carrying an IP packet, unless the IP packet can first be
encapsulated in a MPLS packet).</t> encapsulated in a MPLS packet).</li>
<li>The tunnel is specified in a TLV whose Tunnel Egress Endpoint su
<t>The tunnel is specified in a TLV whose Tunnel Egress Endpoint sub-TLV b-TLV
identifies an IP address that is reachable. The reachability con dition identifies an IP address that is reachable. The reachability con dition
is evaluated as per <xref target="RFC4271"/>. If the IP address is is evaluated as per <xref target="RFC4271" format="default"/>. If the IP address is
reachable via more than one forwarding table, local policy is us ed reachable via more than one forwarding table, local policy is us ed
to determine which table to use.</t> to determine which table to use.</li>
<li>There is no local policy that prevents the use of the tunnel.</l
<t>There is no local policy that prevents the use of the tunnel.</t> i>
</ol>
</list> </li>
</t> </ul>
<t>
</list> Then router R <bcp14>MUST</bcp14> send packet P through one of the feasible
</t>
<t>
Then router R MUST send packet P through one of the feasible
tunnels identified in the Tunnel Encapsulation attribute of UPDATE U.</t> tunnels identified in the Tunnel Encapsulation attribute of UPDATE U.</t>
<t>
<t>
If the Tunnel Encapsulation attribute contains several TLVs (that is, if If the Tunnel Encapsulation attribute contains several TLVs (that is, if
it specifies several feasible tunnels), router R may choose any one of those it specifies several feasible tunnels), router R may choose any one of those
tunnels, based upon local policy. If any Tunnel TLV contains tunnels, based upon local policy. If any Tunnel TLV contains
one or more Color sub-TLVs (<xref target="color"/>) and/or the Protocol Type one or more Color sub-TLVs (<xref target="color" format="default"/>) and/or t
sub-TLV he Protocol Type sub-TLV (<xref target="protocol-type" format="default"/>), the
(<xref target="protocol-type"/>), the choice of tunnel may be influenced by t choice of tunnel may be influenced by these
hese sub-TLVs. Many other factors, for example, minimization of encapsulation-head
sub-TLVs. Many other factors, for example minimization of encapsulation heade er
r
overhead, could also be used to influence selection.</t> overhead, could also be used to influence selection.</t>
<t>
<t>
The reachability to the address of the egress endpoint of the tunnel may chan ge over The reachability to the address of the egress endpoint of the tunnel may chan ge over
time, directly impacting the feasibility of the tunnel. A tunnel that is not time, directly impacting the feasibility of the tunnel. A tunnel that is not
feasible at some moment, may become feasible at a later time when its egress endpoint feasible at some moment may become feasible at a later time when its egress e ndpoint
address is reachable. The router may start using the newly feasible tunnel address is reachable. The router may start using the newly feasible tunnel
instead of an existing one. How this decision is made is outside the scope instead of an existing one. How this decision is made is outside the scope
of this document.</t> of this document.</t>
<t>
<t>
Once it is determined to send a packet through the tunnel specified Once it is determined to send a packet through the tunnel specified
in a particular Tunnel TLV of a particular Tunnel Encapsulation attribute, in a particular Tunnel TLV of a particular Tunnel Encapsulation attribute,
then the tunnel's egress endpoint address is the IP address contained then the tunnel's egress endpoint address is the IP address contained
in the Tunnel Egress Endpoint sub-TLV. If the Tunnel TLV contains a Tunnel E gress Endpoint sub-TLV in the Tunnel Egress Endpoint sub-TLV. If the Tunnel TLV contains a Tunnel E gress Endpoint sub-TLV
whose Value field is all zeroes, then the tunnel's egress endpoint is the whose Value field is all zeroes, then the tunnel's egress endpoint is the
address of the Next Hop of the BGP Update containing the Tunnel Encapsulation address of the next hop of the BGP UPDATE containing the Tunnel Encapsulation
attribute. The address of the tunnel egress endpoint generally appears in a attribute (that is, the Network Address of Next Hop field of the
"destination address" field of the encapsulation.</t> MP_REACH_NLRI attribute if the encoding of [RFC4760] is in use or
the NEXT_HOP attribute otherwise). The address of the tunnel egress endpoint
<t> generally appears in a
Destination Address field of the encapsulation.</t>
<t>
The full set of procedures for sending a packet through a particular The full set of procedures for sending a packet through a particular
Tunnel Type to a particular tunnel egress endpoint depends upon the tunnel tunnel type to a particular tunnel egress endpoint depends upon the tunnel
type, and is outside the scope of this document. Note that some type and is outside the scope of this document. Note that some
tunnel types may require the execution of an explicit tunnel setup tunnel types may require the execution of an explicit tunnel setup
protocol before they can be used for carrying data. Other tunnel protocol before they can be used for carrying data. Other tunnel
types may not require any tunnel setup protocol.</t> types may not require any tunnel setup protocol.</t>
<t>
<t>
Sending a packet through a tunnel always requires that the packet be Sending a packet through a tunnel always requires that the packet be
encapsulated, with an encapsulation header that is appropriate for encapsulated, with an encapsulation header that is appropriate for
the Tunnel Type. The contents of the tunnel encapsulation header may the tunnel type. The contents of the tunnel encapsulation header may
be influenced by the Encapsulation sub-TLV. If there is no be influenced by the Encapsulation sub-TLV. If there is no
Encapsulation sub-TLV present, the router transmitting the packet Encapsulation sub-TLV present, the router transmitting the packet
through the tunnel must have a priori knowledge (for example, by through the tunnel must have a priori knowledge (for example, by
provisioning) of how to fill in the various fields in the provisioning) of how to fill in the various fields in the
encapsulation header.</t> encapsulation header.</t>
<t>
<t>
A Tunnel Encapsulation attribute may contain several TLVs that all A Tunnel Encapsulation attribute may contain several TLVs that all
specify the same Tunnel Type. Each TLV should be considered as specify the same tunnel type. Each TLV should be considered as
specifying a different tunnel. Two tunnels of the same type may have specifying a different tunnel. Two tunnels of the same type may have
different Tunnel Egress Endpoint sub-TLVs, different Encapsulation sub-TLVs, different Tunnel Egress Endpoint sub-TLVs, different Encapsulation sub-TLVs,
etc. Choosing between two such tunnels is a matter of local policy.</t> etc. Choosing between two such tunnels is a matter of local policy.</t>
<t>
<t>
Once router R has decided to send packet P through a particular Once router R has decided to send packet P through a particular
tunnel, it encapsulates packet P appropriately and then forwards it tunnel, it encapsulates packet P appropriately and then forwards it
according to the route that leads to the tunnel's egress endpoint. according to the route that leads to the tunnel's egress endpoint.
This route may itself be a BGP route with a Tunnel Encapsulation This route may itself be a BGP route with a Tunnel Encapsulation
attribute. If so, the encapsulated packet is treated as the payload attribute. If so, the encapsulated packet is treated as the payload
and is encapsulated according to the Tunnel Encapsulation attribute and encapsulated according to the Tunnel Encapsulation attribute
of that route. That is, tunnels may be "stacked".</t> of that route. That is, tunnels may be "stacked".</t>
<t>
<t> Notwithstanding anything said in this document, a BGP speaker <bcp14>MAY</bcp
Notwithstanding anything said in this document, a BGP speaker MAY 14>
have local policy that influences the choice of tunnel, and the way have local policy that influences the choice of tunnel and the way
the encapsulation is formed. A BGP speaker MAY also have a local the encapsulation is formed. A BGP speaker <bcp14>MAY</bcp14> also have a lo
cal
policy that tells it to ignore the Tunnel Encapsulation attribute policy that tells it to ignore the Tunnel Encapsulation attribute
entirely or in part. Of course, interoperability issues must be entirely or in part. Of course, interoperability issues must be
considered when such policies are put into place.</t> considered when such policies are put into place.</t>
<t>
<t> See also <xref target="validation-and-error" format="default"/>, which provi
See also <xref target="validation-and-error"/>, which provides further des further
specification regarding validation and exception cases.</t> specification regarding validation and exception cases.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Routing Considerations"> <name>Routing Considerations</name>
<section title="Impact on the BGP Decision Process"><t> <section numbered="true" toc="default">
<name>Impact on the BGP Decision Process</name>
<t>
The presence of the Tunnel Encapsulation attribute affects The presence of the Tunnel Encapsulation attribute affects
the BGP best route selection algorithm. If a route includes the BGP best route-selection algorithm. If a route includes
the Tunnel Encapsulation attribute, and if that attribute the Tunnel Encapsulation attribute, and if that attribute
includes no tunnel which is feasible, then that route MUST includes no tunnel that is feasible, then that route <bcp14>MUST
NOT be considered resolvable for the purposes of Route Resolvabilit NOT</bcp14> be considered resolvable for the purposes of the route
y resolvability
Condition <xref target="RFC4271"/> Section 9.1.2.1. condition (<xref target="RFC4271" sectionFormat="comma" section="9.
</t> 1.2.1"/>).
</section> </t>
</section>
<section title="Looping, Mutual Recursion, Etc."><t> <section numbered="true" toc="default">
<name>Looping, Mutual Recursion, Etc.</name>
<t>
Consider a packet destined for address X. Suppose a BGP UPDATE for Consider a packet destined for address X. Suppose a BGP UPDATE for
address prefix X carries a Tunnel Encapsulation attribute that address prefix X carries a Tunnel Encapsulation attribute that
specifies a tunnel egress endpoint of Y, and suppose that a BGP specifies a tunnel egress endpoint of Y, and suppose that a BGP
UPDATE for address prefix Y carries a Tunnel Encapsulation attribute UPDATE for address prefix Y carries a Tunnel Encapsulation attribute
that specifies a tunnel egress endpoint of X. It is easy to see that this that specifies a tunnel egress endpoint of X. It is easy to see that this
can have no good outcome. <xref target="RFC4271"/> describes an analogous cas e can have no good outcome. <xref target="RFC4271" format="default"/> describes an analogous case
as mutually recursive routes.</t> as mutually recursive routes.</t>
<t>
<t>
This could happen as a result of misconfiguration, either accidental This could happen as a result of misconfiguration, either accidental
or intentional. It could also happen if the Tunnel Encapsulation or intentional. It could also happen if the Tunnel Encapsulation
attribute were altered by a malicious agent. Implementations should attribute were altered by a malicious agent. Implementations should
be aware that such an attack will result in unresolvable BGP routes due to th e be aware that such an attack will result in unresolvable BGP routes due to th e
mutually recursive relationship. This document does not specify a maximum num ber of mutually recursive relationship. This document does not specify a maximum num ber of
recursions; that is an implementation-specific matter.</t> recursions; that is an implementation-specific matter.</t>
<t>
<t>
Improper setting (or malicious altering) of the Tunnel Encapsulation Improper setting (or malicious altering) of the Tunnel Encapsulation
attribute could also cause data packets to loop. Suppose a BGP attribute could also cause data packets to loop. Suppose a BGP
UPDATE for address prefix X carries a Tunnel Encapsulation attribute UPDATE for address prefix X carries a Tunnel Encapsulation attribute
that specifies a tunnel egress endpoint of Y. Suppose router R that specifies a tunnel egress endpoint of Y. Suppose router R
receives and processes the advertisement. When router R receives a packet receives and processes the advertisement. When router R receives a packet
destined for X, it will apply the encapsulation and send the destined for X, it will apply the encapsulation and send the
encapsulated packet to Y. Y will decapsulate the packet and forward encapsulated packet to Y. Y will decapsulate the packet and forward
it further. If Y is further away from X than is router R, it is it further. If Y is further away from X than is router R, it is
possible that the path from Y to X will traverse R. This would cause possible that the path from Y to X will traverse R. This would cause
a long-lasting routing loop. The control plane itself cannot detect a long-lasting routing loop. The control plane itself cannot detect
this situation, though a TTL field in the payload packets would this situation, though a TTL field in the payload packets would
prevent any given packet from looping infinitely.</t> prevent any given packet from looping infinitely.</t>
<t>
<t> During the deployment of techniques described
During the deployment of techniques as described
in this document, operators are encouraged to avoid mutually in this document, operators are encouraged to avoid mutually
recursive route and/or tunnel dependencies. There is greater recursive route and/or tunnel dependencies. There is greater
potential for such scenarios to arise when the tunnel egress endpoint for a potential for such scenarios to arise when the tunnel egress endpoint for a
given prefix differs from the address of the next hop for that given prefix differs from the address of the next hop for that
prefix.</t> prefix.</t>
</section>
</section> </section>
<section anchor="recursive-nh-resolution" numbered="true" toc="default">
</section> <name>Recursive Next-Hop Resolution</name>
<t>
<section title="Recursive Next Hop Resolution" anchor="recursive-nh-resol
ution"><t>
Suppose that:</t> Suppose that:</t>
<ul spacing="normal">
<t><list style="symbols"><t>a given packet P must be forwarded by router <li>a given packet P must be forwarded by router R1;</li>
R1;</t> <li>the path along which P is to be forwarded is determined by BGP
UPDATE U1;</li>
<t>the path along which P is to be forwarded is determined by BGP <li>UPDATE U1 does not have a Tunnel Encapsulation attribute;</li>
UPDATE U1;</t> <li>the address of the next hop of UPDATE U1 is router R2;</li>
<li>the best route to router R2 is a BGP route that was advertised in
<t>UPDATE U1 does not have a Tunnel Encapsulation attribute;</t> UPDATE U2; and</li>
<li>UPDATE U2 has a Tunnel Encapsulation attribute.</li>
<t>the address of the next hop of UPDATE U1 is router R2;</t> </ul>
<t>
<t>the best route to router R2 is a BGP route that was advertised in Then packet P <bcp14>MUST</bcp14> be sent through one of the tunnels identifi
UPDATE U2;</t> ed in
the Tunnel Encapsulation attribute of UPDATE U2. See <xref target="usage" fo
<t>UPDATE U2 has a Tunnel Encapsulation attribute.</t> rmat="default"/> for
</list>
</t>
<t>
Then packet P MUST be sent through one of the tunnels identified in
the Tunnel Encapsulation attribute of UPDATE U2. See <xref target="usage"/>
for
further details.</t> further details.</t>
<t>
<t>
However, suppose that one of the TLVs in U2's Tunnel Encapsulation However, suppose that one of the TLVs in U2's Tunnel Encapsulation
attribute contains one or more Color Sub-TLVs. In that case, packet P MUST attribute contains one or more Color sub-TLVs. In that case, packet P <bcp14
NOT be sent through the tunnel contained in that TLV, unless U1 is >MUST
NOT</bcp14> be sent through the tunnel contained in that TLV, unless U1 is
carrying a Color Extended Community that is identified in one of U2's carrying a Color Extended Community that is identified in one of U2's
Color Sub-TLVs.</t> Color sub-TLVs.</t>
<t>
<t>
The procedures in this section presuppose that U1's address of the next hop The procedures in this section presuppose that U1's address of the next hop
resolves to a BGP route, and that U2's next hop resolves (perhaps after resolves to a BGP route, and that U2's next hop resolves (perhaps after
further recursion) to a non-BGP route.</t> further recursion) to a non-BGP route.</t>
</section>
</section> <section anchor="use-of-vni" numbered="true" toc="default">
<name>Use of Virtual Network Identifiers and Embedded Labels When Imposing
<section title="Use of Virtual Network Identifiers and Embedded Labels wh a Tunnel Encapsulation</name>
en Imposing a Tunnel Encapsulation" anchor="use-of-vni"><t> <t>
If the TLV specifying a tunnel contains an MPLS Label Stack sub-TLV, If the TLV specifying a tunnel contains an MPLS Label Stack sub-TLV,
then when sending a packet through that tunnel, the procedures of then when sending a packet through that tunnel, the procedures of
<xref target="label-stack"/> are applied before the procedures of this sectio <xref target="label-stack" format="default"/> are applied before the procedur
n.</t> es of this section.</t>
<t>
<t>
If the TLV specifying a tunnel contains a Prefix-SID sub-TLV, the If the TLV specifying a tunnel contains a Prefix-SID sub-TLV, the
procedures of <xref target="prefix-sid"/> are applied before the procedures o f this procedures of <xref target="prefix-sid" format="default"/> are applied before the procedures of this
section. If the TLV also contains an MPLS Label Stack sub-TLV, the section. If the TLV also contains an MPLS Label Stack sub-TLV, the
procedures of <xref target="label-stack"/> are applied before the procedures procedures of <xref target="label-stack" format="default"/> are applied befor
of e the procedures of
<xref target="prefix-sid"/>.</t> <xref target="prefix-sid" format="default"/>.</t>
<section numbered="true" toc="default">
<section title="Tunnel Types without a Virtual Network Identifier Field"> <name>Tunnel Types without a Virtual Network Identifier Field</name>
<t> <t>
If a Tunnel Encapsulation attribute is attached to an UPDATE of a If a Tunnel Encapsulation attribute is attached to an UPDATE of a
labeled address family, there will be one or more labels specifie d in labeled address family, there will be one or more labels specifie d in
the UPDATE's NLRI. When a packet is sent through a tunnel specif ied the UPDATE's NLRI. When a packet is sent through a tunnel specif ied
in one of the attribute's TLVs, and that tunnel type does not con tain in one of the attribute's TLVs, and that tunnel type does not con tain
a virtual network identifier field, the label or labels from the NLRI a Virtual Network Identifier field, the label or labels from the NLRI
are pushed on the packet's label stack. The resulting MPLS packe t is are pushed on the packet's label stack. The resulting MPLS packe t is
then further encapsulated, as specified by the TLV. then further encapsulated, as specified by the TLV.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Tunnel Types with a Virtual Network Identifier Field"><t> <name>Tunnel Types with a Virtual Network Identifier Field</name>
<t>
Two of the tunnel types that can be specified in a Tunnel Two of the tunnel types that can be specified in a Tunnel
Encapsulation TLV have virtual network identifier fields in their Encapsulation TLV have Virtual Network Identifier fields in their
encapsulation headers. In the VXLAN encapsulation, encapsulation headers. In the VXLAN encapsulation,
this field is called the VNI (VXLAN Network Identifier) field; in this field is called the VNI (VXLAN Network Identifier) field; in
the NVGRE encapsulation, this field is called the VSID (Virtual the NVGRE encapsulation, this field is called the VSID (Virtual
Subnet Identifier) field.</t> Subnet Identifier) field.</t>
<t>
<t>
When one of these tunnel encapsulations is imposed on a packet, the When one of these tunnel encapsulations is imposed on a packet, the
setting of the virtual network identifier field in the encapsulation setting of the Virtual Network Identifier field in the encapsulation
header depends upon the contents of the Encapsulation sub-TLV (if one header depends upon the contents of the Encapsulation sub-TLV (if one
is present). When the Tunnel Encapsulation attribute is being is present). When the Tunnel Encapsulation attribute is being
carried in a BGP UPDATE of a labeled address family, the setting of carried in a BGP UPDATE of a labeled address family, the setting of
the virtual network identifier field also depends upon the contents the Virtual Network Identifier field also depends upon the contents
of the Embedded Label Handling sub-TLV (if present).</t> of the Embedded Label Handling sub-TLV (if present).</t>
<t>
<t>
This section specifies the procedures for choosing the value to set This section specifies the procedures for choosing the value to set
in the virtual network identifier field of the encapsulation header. in the Virtual Network Identifier field of the encapsulation header.
These procedures apply only when the Tunnel Type is VXLAN These procedures apply only when the tunnel type is VXLAN
or NVGRE.</t> or NVGRE.</t>
<section numbered="true" toc="default">
<section title="Unlabeled Address Families"><t> <name>Unlabeled Address Families</name>
This sub-section applies when:</t> <t>
This subsection applies when:</t>
<t><list style="symbols"><t>the Tunnel Encapsulation attribute is carried <ul spacing="normal">
in a BGP UPDATE of <li>the Tunnel Encapsulation attribute is carried in a BGP UPDATE of
an unlabeled address family, and</t> an unlabeled address family, </li>
<li>at least one of the attribute's TLVs identifies a tunnel type th
<t>at least one of the attribute's TLVs identifies a Tunnel Type that at
uses a virtual network identifier, and</t> uses a virtual network identifier, and</li>
<li>it has been determined to send a packet through one of those
<t>it has been determined to send a packet through one of those tunnels.</li>
tunnels.</t> </ul>
<t>
</list>
</t>
<t>
If the TLV identifying the tunnel contains an Encapsulation sub-TLV If the TLV identifying the tunnel contains an Encapsulation sub-TLV
whose V bit is set, the virtual network identifier field of the whose V bit is set to 1, the Virtual Network Identifier field of the
encapsulation header is set to the value of the virtual network encapsulation header is set to the value of the Virtual Network
identifier field of the Encapsulation sub-TLV.</t> Identifier field of the Encapsulation sub-TLV.</t>
<t>
<t> Otherwise, the Virtual Network Identifier field of the encapsulation
Otherwise, the virtual network identifier field of the encapsulation
header is set to a configured value; if there is no configured value, header is set to a configured value; if there is no configured value,
the tunnel cannot be used.</t> the tunnel cannot be used.</t>
</section>
</section> <section numbered="true" toc="default">
<name>Labeled Address Families</name>
<section title="Labeled Address Families"><t> <t>
This sub-section applies when:</t> This subsection applies when:</t>
<ul spacing="normal">
<t><list style="symbols"><t>the Tunnel Encapsulation attribute is carried <li>the Tunnel Encapsulation attribute is carried in a BGP UPDATE of
in a BGP UPDATE of a a
labeled address family, and</t> labeled address family,</li>
<li>at least one of the attribute's TLVs identifies a tunnel type th
<t>at least one of the attribute's TLVs identifies a Tunnel Type that at
uses a virtual network identifier, and</t> uses a virtual network identifier, and</li>
<li>it has been determined to send a packet through one of those
<t>it has been determined to send a packet through one of those tunnels.</li>
tunnels.</t> </ul>
<section anchor="valid-vni" numbered="true" toc="default">
</list> <name>When a Valid VNI Has Been Signaled</name>
</t> <t>
<section title="When a Valid VNI has been Signaled" anchor="valid-vni"><t
>
If the TLV identifying the tunnel contains an Encapsulation sub-TLV If the TLV identifying the tunnel contains an Encapsulation sub-TLV
whose V bit is set, the virtual network identifier field of the whose V bit is set to 1, the Virtual Network Identifier field of the
encapsulation header is set to the value of the virtual network identifier encapsulation header is set to the value of the Virtual Network Identifier
field of the Encapsulation sub-TLV. However, the Embedded Label Handling field of the Encapsulation sub-TLV. However, the Embedded Label Handling
sub-TLV will determine label processing as described below.</t> sub-TLV will determine label processing as described below.</t>
<ul spacing="normal">
<t><list style="symbols"><t>If the TLV contains an Embedded Label <li>If the TLV contains an Embedded Label
Handling sub-TLV whose value is 1, the embedded label (from the NLRI Handling sub-TLV whose value is 1, the embedded label (from the NLRI
of the route that is carrying the Tunnel Encapsulation attribute) of the route that is carrying the Tunnel Encapsulation attribute)
appears at the top of the MPLS label stack in the encapsulation payload. appears at the top of the MPLS label stack in the encapsulation payload.
</t> </li>
<li>If the TLV does not contain an Embedded Label Handling sub-TLV
<t>If the TLV does not contain an Embedded Label Handling sub-TLV, or , or
it contains an Embedded Label Handling sub-TLV whose value is 2, it contains an Embedded Label Handling sub-TLV whose value is 2,
the embedded label is ignored entirely.</t> the embedded label is ignored entirely.</li>
</ul>
</list> </section>
</t> <section anchor="no-valid-vni" numbered="true" toc="default">
<name>When a Valid VNI Has Not Been Signaled</name>
</section> <t>
<section title="When a Valid VNI has not been Signaled" anchor="no-valid-
vni"><t>
If the TLV identifying the tunnel does not contain an Encapsulation If the TLV identifying the tunnel does not contain an Encapsulation
sub-TLV whose V bit is set, the virtual network identifier field of sub-TLV whose V bit is set to 1, the Virtual Network Identifier field of
the encapsulation header is set as follows:</t> the encapsulation header is set as follows:</t>
<ul spacing="normal">
<t><list style="symbols"><t>If the TLV contains an Embedded Label Handlin <li>
g sub-TLV whose value <t>If the TLV contains an Embedded Label Handling sub-TLV whose
is 1, then the virtual network identifier field of the value
encapsulation header is set to a configured value.<vspace blankLines="1"/> is 1, then the Virtual Network Identifier field of the
encapsulation header is set to a configured value.</t>
<t>
If there is no configured value, the tunnel cannot be used. If there is no configured value, the tunnel cannot be used.
<vspace blankLines="1"/> </t>
<t>
The embedded label (from the NLRI of the route that is carrying The embedded label (from the NLRI of the route that is carrying
the Tunnel Encapsulation attribute) appears at the top of the MPLS the Tunnel Encapsulation attribute) appears at the top of the MPLS
label stack in the encapsulation payload. label stack in the encapsulation payload.
</t> </t>
</li>
<t>If the TLV does not contain an Embedded Label Handling sub-TLV, or <li>
<t>If the TLV does not contain an Embedded Label Handling sub-TL
V, or
if it contains an Embedded Label Handling sub-TLV whose value is if it contains an Embedded Label Handling sub-TLV whose value is
2, the embedded label is copied into the lower 3 octets of the virtual 2, the embedded label is copied into the lower 3 octets of the Virtual
network identifier field of the encapsulation header.<vspace blankLines="1 Network Identifier field of the encapsulation header.</t>
"/> <t>
In this case, the payload may or may not contain an MPLS label In this case, the payload may or may not contain an MPLS label
stack, depending upon other factors. If the payload does contain stack, depending upon other factors. If the payload does contain
an MPLS label stack, the embedded label does not appear in that an MPLS label stack, the embedded label does not appear in that
stack. stack.
</t> </t>
</li>
</list> </ul>
</t> </section>
</section>
</section> </section>
</section>
</section> <section anchor="applicability" numbered="true" toc="default">
<name>Applicability Restrictions</name>
</section> <t>
</section>
<section title="Applicability Restrictions" anchor="applicability"><t>
In a given UPDATE of a labeled address family, the label embedded in In a given UPDATE of a labeled address family, the label embedded in
the NLRI is generally a label that is meaningful only to the router the NLRI is generally a label that is meaningful only to the router
represented by the address of the next hop. Certain of the procedures of represented by the address of the next hop. Certain of the procedures of Sec
<xref target="valid-vni"/> or <xref target="no-valid-vni"/> cause the embedde tions
d label to be <xref target="valid-vni" format="counter"/> or <xref target="no-valid-vni" fo
rmat="counter"/> cause the embedded label to be
carried by a data packet to the router whose address appears in the carried by a data packet to the router whose address appears in the
Tunnel Egress Endpoint sub-TLV. If the Tunnel Egress Endpoint sub-TLV does n ot Tunnel Egress Endpoint sub-TLV. If the Tunnel Egress Endpoint sub-TLV does n ot
identify the same router represented by the address of the next hop, sending the identify the same router represented by the address of the next hop, sending the
packet through the tunnel may cause the label to be misinterpreted at the packet through the tunnel may cause the label to be misinterpreted at the
tunnel's egress endpoint. This may cause misdelivery of the packet. tunnel's egress endpoint. This may cause misdelivery of the packet.
Avoidance of this unfortunate outcome is a matter of network planning Avoidance of this unfortunate outcome is a matter of network planning
and design, and is outside the scope of this document.</t> and design and is outside the scope of this document.</t>
<t>
<t>
Note that if the Tunnel Encapsulation attribute is attached to a VPN- Note that if the Tunnel Encapsulation attribute is attached to a VPN-
IP route <xref target="RFC4364"/>, and if Inter-AS "option b" (see section 10 IP route <xref target="RFC4364" format="default"/>, if Inter-AS "option b" (s
of ee
<xref target="RFC4364"/>) is being used, and if the Tunnel Egress Endpoint su <xref target="RFC4364" sectionFormat="of" section="10"/>) is being used, and
b-TLV contains if the Tunnel Egress Endpoint sub-TLV contains
an IP address that is not in same AS as the router receiving the an IP address that is not in the same AS as the router receiving the
route, it is very likely that the embedded label has been changed. route, it is very likely that the embedded label has been changed.
Therefore use of the Tunnel Encapsulation attribute in an "Inter-AS option b" scenario is Therefore, use of the Tunnel Encapsulation attribute in an "Inter-AS option b " scenario is
not recommended.</t> not recommended.</t>
<t>
<t>
Other documents may define other ways to signal tunnel information in Other documents may define other ways to signal tunnel information in
BGP. For example, <xref target="RFC6514"/> defines the "P-Multicast BGP. For example, <xref target="RFC6514" format="default"/> defines the "P-Mu lticast
Service Interface Tunnel" (PMSI Tunnel) attribute. In this Service Interface Tunnel" (PMSI Tunnel) attribute. In this
specification, we do not consider the effects of advertising the specification, we do not consider the effects of advertising the
Tunnel Encapsulation Attribute in conjunction with other forms of Tunnel Encapsulation attribute in conjunction with other forms of
signaling tunnels. Any document specifying such joint use MUST signaling tunnels. Any document specifying such joint use <bcp14>MUST</bcp14>
provide details as to how interactions should be handled. provide details as to how interactions should be handled.
</t> </t>
</section>
</section> <section anchor="scoping" numbered="true" toc="default">
<name>Scoping</name>
<section title="Scoping" anchor="scoping"><t> <t>
The Tunnel Encapsulation attribute is defined as a transitive The Tunnel Encapsulation attribute is defined as a transitive
attribute, so that it may be passed along by BGP speakers that do not attribute, so that it may be passed along by BGP speakers that do not
recognize it. However the Tunnel Encapsulation recognize it. However, the Tunnel Encapsulation
attribute MUST be used only within a well-defined scope, for example, within attribute <bcp14>MUST</bcp14> be used only within a well-defined scope, for e
a xample, within a
set of Autonomous Systems that belong to a single administrative set of ASes that belong to a single administrative
entity. If the attribute is distributed beyond its intended scope, entity. If the attribute is distributed beyond its intended scope,
packets may be sent through tunnels in a manner that is not intended.</t> packets may be sent through tunnels in a manner that is not intended.</t>
<t>
<t>
To prevent the Tunnel Encapsulation attribute from being distributed To prevent the Tunnel Encapsulation attribute from being distributed
beyond its intended scope, any BGP speaker that understands the beyond its intended scope, any BGP speaker that understands the
attribute MUST be able to filter the attribute from incoming BGP attribute <bcp14>MUST</bcp14> be able to filter the attribute from incoming B GP
UPDATE messages. When the attribute is filtered from an incoming UPDATE messages. When the attribute is filtered from an incoming
UPDATE, the attribute is neither processed nor distributed. This UPDATE, the attribute is neither processed nor distributed. This
filtering SHOULD be possible on a per-BGP-session basis; finer filtering <bcp14>SHOULD</bcp14> be possible on a per-BGP-session basis; finer
granularities (for example, per route and/or per attribute TLV) MAY be granularities (for example, per route and/or per attribute TLV) <bcp14>MAY</b
cp14> be
supported. For each external BGP (EBGP) session, filtering of the attribute on supported. For each external BGP (EBGP) session, filtering of the attribute on
incoming UPDATEs MUST be enabled by default.</t> incoming UPDATEs <bcp14>MUST</bcp14> be enabled by default.</t>
<t>
<t> In addition, any BGP speaker that understands the attribute <bcp14>MUST</bcp1
In addition, any BGP speaker that understands the attribute MUST be 4> be
able to filter the attribute from outgoing BGP UPDATE messages. This able to filter the attribute from outgoing BGP UPDATE messages. This
filtering SHOULD be possible on a per-BGP-session basis. For each EBGP filtering <bcp14>SHOULD</bcp14> be possible on a per-BGP-session basis. For
session, filtering of the attribute on outgoing UPDATEs MUST be each EBGP
session, filtering of the attribute on outgoing UPDATEs <bcp14>MUST</bcp14> b
e
enabled by default.</t> enabled by default.</t>
<t>
<t> Since the Encapsulation Extended Community provides a subset
Since the Tunnel Encapsulation Extended Community provides a subset
of the functionality of the Tunnel Encapsulation attribute, these of the functionality of the Tunnel Encapsulation attribute, these
considerations apply equally in its case: any BGP speaker that considerations apply equally in its case: </t>
understands it MUST be able to filter it from incoming BGP UPDATE <ul>
messages, it MUST be possible to filter the Tunnel Encapsulation <li>Any BGP speaker that
Extended Community from outgoing messages, and in both cases this understands it <bcp14>MUST</bcp14> be able to filter it from incoming BGP UPD
filtering MUST be enabled by default for EBGP sessions. ATE
</t> messages.</li>
<li>It <bcp14>MUST</bcp14> be possible to filter the Encapsulation
</section> Extended Community from outgoing messages.</li>
<li>In both cases, this
filtering <bcp14>MUST</bcp14> be enabled by default for EBGP sessions.</li>
</ul>
<section title="Operational Considerations"> </section>
<t> <section numbered="true" toc="default">
<name>Operational Considerations</name>
<t>
A potential operational difficulty arises when tunnels are used, if the A potential operational difficulty arises when tunnels are used, if the
size of packets entering the tunnel exceeds the size of packets entering the tunnel exceeds the
maximum transmission unit (MTU) the tunnel is capable of supporting. This maximum transmission unit (MTU) the tunnel is capable of supporting. This
difficulty can be exacerbated by stacking multiple tunnels, since each difficulty can be exacerbated by stacking multiple tunnels, since each
stacked tunnel header further reduces the supportable MTU. This issue is stacked tunnel header further reduces the supportable MTU. This issue is
long-standing and well-known. The tunnel long-standing and well-known. The tunnel
signaling provided in this specification does nothing to address this signaling provided in this specification does nothing to address this
issue, nor to aggravate it (except insofar as it may further increase the issue, nor to aggravate it (except insofar as it may further increase the
popularity of tunneling). <!-- A detailed discussion of this issue can be popularity of tunneling).
found in <xref target="I-D.ietf-intarea-tunnels"/>. --> </t>
</t> </section>
</section> <section anchor="validation-and-error" numbered="true" toc="default">
<name>Validation and Error Handling</name>
<section title="Validation and Error Handling" anchor="validation-and-err <t>
or"><t>
The Tunnel Encapsulation attribute is a sequence of TLVs, each of The Tunnel Encapsulation attribute is a sequence of TLVs, each of
which is a sequence of sub-TLVs. The final octet of a TLV is which is a sequence of sub-TLVs. The final octet of a TLV is
determined by its length field. Similarly, the final octet of a sub- determined by its Length field. Similarly, the final octet of a sub-
TLV is determined by its length field. The final octet of a TLV MUST TLV is determined by its Length field. The final octet of a TLV <bcp14>MUST<
/bcp14>
also be the final octet of its final sub-TLV. If this is not the also be the final octet of its final sub-TLV. If this is not the
case, the TLV MUST be considered to be malformed, case, the TLV <bcp14>MUST</bcp14> be considered to be malformed,
and the "Treat-as-withdraw" procedure of and the "Treat-as-withdraw" procedure of
<xref target="RFC7606"/> is applied. </t> <xref target="RFC7606" format="default"/> is applied. </t>
<t>
<t>
If a Tunnel Encapsulation attribute does not have any valid TLVs, or If a Tunnel Encapsulation attribute does not have any valid TLVs, or
it does not have the transitive bit set, the "Treat-as-withdraw" it does not have the transitive bit set, the "Treat-as-withdraw"
procedure of <xref target="RFC7606"/> is applied.</t> procedure of <xref target="RFC7606" format="default"/> is applied.</t>
<t>
<t> If a Tunnel Encapsulation attribute can be parsed correctly but
If a Tunnel Encapsulation attribute can be parsed correctly, but contains a TLV whose tunnel type is not recognized by a particular
contains a TLV whose Tunnel Type is not recognized by a particular BGP speaker, that BGP speaker <bcp14>MUST NOT</bcp14> consider the attribute
BGP speaker, that BGP speaker MUST NOT consider the attribute to be to be
malformed. Rather, it MUST malformed. Rather, it <bcp14>MUST</bcp14>
interpret the attribute as if that interpret the attribute as if that
TLV had not been present. If the route carrying the Tunnel TLV had not been present. If the route carrying the Tunnel
Encapsulation attribute is propagated with the attribute, the Encapsulation attribute is propagated with the attribute, the
unrecognized TLV MUST remain in the attribute.</t> unrecognized TLV <bcp14>MUST</bcp14> remain in the attribute.</t>
<t>
<t> The following sub-TLVs defined in this document <bcp14>MUST NOT</bcp14> occur
The following sub-TLVs defined in this document MUST NOT occur more more
than once in a given Tunnel TLV: Tunnel Egress Endpoint (discussed below), than once in a given Tunnel TLV: Tunnel Egress Endpoint (discussed below),
Encapsulation, DS, UDP Destination Port, Embedded Label Encapsulation, DS, UDP Destination Port, Embedded Label
Handling, MPLS Label Stack, Prefix-SID. If a Tunnel TLV has more Handling, MPLS Label Stack, and Prefix-SID. If a Tunnel TLV has more
than one of any of these sub-TLVs, all but the first occurrence of than one of any of these sub-TLVs, all but the first occurrence of
each such sub-TLV type MUST be disregarded. However, the each such sub-TLV type <bcp14>MUST</bcp14> be disregarded. However, the
Tunnel TLV containing them MUST NOT be considered to be malformed, Tunnel TLV containing them <bcp14>MUST NOT</bcp14> be considered to be malfor
and all the sub-TLVs MUST be propagated if the route carrying the med,
and all the sub-TLVs <bcp14>MUST</bcp14> be propagated if the route carrying
the
Tunnel Encapsulation attribute is propagated.</t> Tunnel Encapsulation attribute is propagated.</t>
<t>
<t>
The following sub-TLVs defined in this document may appear zero or The following sub-TLVs defined in this document may appear zero or
more times in a given Tunnel TLV: Protocol Type, Color. Each more times in a given Tunnel TLV: Protocol Type and Color. Each
occurrence of such sub-TLVs is meaningful. For example, the Color occurrence of such sub-TLVs is meaningful. For example, the Color
sub-TLV may appear multiple times to assign multiple colors to a sub-TLV may appear multiple times to assign multiple colors to a
tunnel. </t> tunnel. </t>
<t>
<t>
If a TLV of a Tunnel Encapsulation attribute contains a sub-TLV that If a TLV of a Tunnel Encapsulation attribute contains a sub-TLV that
is not recognized by a particular BGP speaker, the BGP speaker MUST is not recognized by a particular BGP speaker, the BGP speaker <bcp14>MUST</b cp14>
process that TLV as if the unrecognized sub-TLV had not been present. process that TLV as if the unrecognized sub-TLV had not been present.
If the route carrying the Tunnel Encapsulation attribute is If the route carrying the Tunnel Encapsulation attribute is
propagated with the attribute, the unrecognized sub-TLV MUST remain in propagated with the attribute, the unrecognized sub-TLV <bcp14>MUST</bcp14> r emain in
the attribute.</t> the attribute.</t>
<t>
<t>
In general, if a TLV contains a sub-TLV that is malformed, In general, if a TLV contains a sub-TLV that is malformed,
the sub-TLV MUST be treated as if it were an unrecognized sub-TLV. the sub-TLV <bcp14>MUST</bcp14> be treated as if it were an unrecognized sub-
There is one exception to this rule -- if a TLV TLV.
There is one exception to this rule: if a TLV
contains a malformed Tunnel Egress Endpoint sub-TLV (as defined in contains a malformed Tunnel Egress Endpoint sub-TLV (as defined in
<xref target="tunnel-egress-endpoint"/>), the entire TLV MUST be ignored, and <xref target="tunnel-egress-endpoint" format="default"/>), the entire TLV <bc
MUST be removed from the Tunnel Encapsulation attribute before the p14>MUST</bcp14> be ignored and <bcp14>MUST</bcp14> be removed from the Tunnel E
ncapsulation attribute before the
route carrying that attribute is distributed.</t> route carrying that attribute is distributed.</t>
<t>
<t>
Within a Tunnel Encapsulation attribute that is carried by a BGP Within a Tunnel Encapsulation attribute that is carried by a BGP
UPDATE whose AFI/SAFI is one of those explicitly listed in the second UPDATE whose AFI/SAFI is one of those explicitly listed in the first
paragraph of <xref target="usage"/>, a TLV that does not contain exactly one paragraph of <xref target="usage" format="default"/>, a TLV that does not con
Tunnel Egress Endpoint sub-TLV MUST be treated as if it contained a tain exactly one
Tunnel Egress Endpoint sub-TLV <bcp14>MUST</bcp14> be treated as if it contai
ned a
malformed Tunnel Egress Endpoint sub-TLV.</t> malformed Tunnel Egress Endpoint sub-TLV.</t>
<t>
<t> A TLV identifying a particular tunnel type may contain a sub-TLV that
A TLV identifying a particular Tunnel Type may contain a sub-TLV that is meaningless for that tunnel type. For example, perhaps the TLV
is meaningless for that Tunnel Type. For example, perhaps the TLV
contains a UDP Destination Port sub-TLV, but the identified tunnel contains a UDP Destination Port sub-TLV, but the identified tunnel
type does not use UDP encapsulation at all, or a tunnel of the form type does not use UDP encapsulation at all, or a tunnel of the form
"X-in-Y" contains a Protocol Type sub-TLV that specifies something "X-in-Y" contains a Protocol Type sub-TLV that specifies something
other than "X". Sub-TLVs of this sort MUST be disregarded. That is, other than "X". Sub-TLVs of this sort <bcp14>MUST</bcp14> be disregarded. Th
they MUST NOT affect the creation of the encapsulation header. at is,
However, the sub-TLV MUST NOT be considered to be malformed, and MUST they <bcp14>MUST NOT</bcp14> affect the creation of the encapsulation header.
NOT be removed from the TLV before the route carrying the Tunnel However, the sub-TLV <bcp14>MUST NOT</bcp14> be considered to be malformed an
Encapsulation attribute is distributed. An implementation MAY log a d <bcp14>MUST&nbsp;NOT</bcp14> be removed from the TLV before the route carrying
the Tunnel
Encapsulation attribute is distributed. An implementation <bcp14>MAY</bcp14>
log a
message when it encounters such a sub-TLV.</t> message when it encounters such a sub-TLV.</t>
</section>
<section numbered="true" toc="default">
<name>IANA Considerations</name>
<t>
IANA has made the updates described in the following subsections.
All registration
procedures listed are per their definitions in
<xref target="RFC8126" format="default"/>.</t>
<section numbered="true" toc="default">
<name>Obsoleting RFC 5512</name>
<t>
Because this document obsoletes RFC 5512, IANA has updated
references to RFC 5512 to point to this document in the following registries:
</t>
<ul>
<li>"Border Gateway Protocol (BGP) Extended Communities" registry <xref target="
IANA-BGP-EXT-COMM" /></li>
<li>"Border Gateway Protocol (BGP) Parameters" registry <xref target="IANA-BGP-P
ARAMS" /></li>
<li>"Border Gateway Protocol (BGP) Tunnel Encapsulation" registry <xref target="
IANA-BGP-TUNNEL-ENCAP" /></li>
<li>"Subsequent Address Family Identifiers (SAFI) Parameters" registry <xref tar
get="IANA-SAFI" /></li>
</ul>
</section> </section>
<section anchor="obsoleting-5566-and-5640" numbered="true" toc="default">
<section title="IANA Considerations"> <name>Obsoleting Code Points Assigned by RFC 5566</name>
<t> <t>
This document makes the following requests of IANA. (All registration
procedures listed below are per their definitions in
<xref target="RFC8126"/>.)</t>
<section title="Obsoleting RFC 5512">
<t>
Because this document obsoletes RFC 5512, change all registration
information that references <xref target="RFC5512"/> to instead reference thi
s document.</t>
</section>
<section title="Obsoleting Code Points Assigned by RFCs 5566"
anchor="obsoleting-5566-and-5640">
<t>
Since this document obsoletes RFC 5566, the code points Since this document obsoletes RFC 5566, the code points
assigned by that RFC are similarly obsoleted. Specifically, the assigned by that RFC are similarly obsoleted. Specifically, the
following code points should be marked as deprecated.</t> following code points have been marked as deprecated.</t>
<t>
<t> In the
In the "BGP Tunnel Encapsulation Attribute Tunnel Types" registry:</t> "BGP Tunnel Encapsulation Attribute Tunnel Types" registry <xref target="IANA-BG
P-TUNNEL-ENCAP" />:</t>
<texttable> <table align="center">
<ttcol>Value</ttcol> <thead>
<ttcol>Name</ttcol> <tr>
<c>3</c> <th align="left">Value</th>
<c>Transmit tunnel endpoint</c> <th align="left">Name</th>
<c>4</c> </tr>
<c>IPsec in Tunnel-mode</c> </thead>
<c>5</c> <tbody>
<c>IP in IP tunnel with IPsec Transport Mode</c> <tr>
<c>6</c> <td align="left">3</td>
<c>MPLS-in-IP tunnel with IPsec Transport Mode</c> <td align="left">Transmit tunnel endpoint (DEPRECATED)</td>
</texttable> </tr>
<tr>
<t> <td align="left">4</td>
And in the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry:</t> <td align="left">IPsec in Tunnel-mode (DEPRECATED)</td>
</tr>
<texttable> <tr>
<ttcol>Value</ttcol> <td align="left">5</td>
<ttcol>Name</ttcol> <td align="left">IP in IP tunnel with IPsec Transport Mode (DEPREC
<c>3</c> ATED)</td>
<c>IPsec Tunnel Authenticator</c> </tr>
</texttable> <tr>
<td align="left">6</td>
</section> <td align="left">MPLS-in-IP tunnel with IPsec Transport Mode (DEPR
ECATED)</td>
<section title="BGP Tunnel Encapsulation Parameters Grouping"> </tr>
<t> </tbody>
Create a new registry grouping, to be named </table>
"BGP Tunnel Encapsulation Parameters". <t>
</t> And in the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry <xref t
</section> arget="IANA-BGP-TUNNEL-ENCAP" />:</t>
<table align="center">
<section title="BGP Tunnel Encapsulation Attribute Tunnel Types"> <thead>
<t> <tr>
Relocate the "BGP Tunnel Encapsulation Attribute Tunnel Types" registry to be <th align="left">Value</th>
under the "BGP Tunnel Encapsulation Parameters" grouping. <th align="left">Name</th>
</t> </tr>
</section> </thead>
<tbody>
<section title="Subsequent Address Family Identifiers"><t> <tr>
Modify the "Subsequent Address Family Identifiers" registry to <td align="left">3</td>
indicate that the Encapsulation SAFI (value 7) is <td align="left">IPsec Tunnel Authenticator (DEPRECATED)</td>
obsoleted. This document should be the reference.</t> </tr>
</tbody>
</section> </table>
</section>
<section title="BGP Tunnel Encapsulation Attribute Sub-TLVs"> <section numbered="true" toc="default">
<t> <name>Border Gateway Protocol (BGP) Tunnel Encapsulation Grouping</name>
Relocate the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry to be und <t>
er IANA has created a new registry grouping named
the "BGP Tunnel Encapsulation Parameters" grouping.</t> "Border Gateway Protocol (BGP) Tunnel Encapsulation" <xref target="IANA-BGP-T
UNNEL-ENCAP"/>.
<t> </t>
Add the following note to the registry:</t> </section>
<section numbered="true" toc="default">
<t><list hangIndent="3" style="hanging"><t> <name>BGP Tunnel Encapsulation Attribute Tunnel Types</name>
If the Sub-TLV Type is in the range from 0 to 127 inclusive, the <t>
IANA has relocated the "BGP Tunnel Encapsulation Attribute Tunnel Types" regi
stry to be
under the "Border Gateway Protocol (BGP) Tunnel Encapsulation" grouping <xref
target="IANA-BGP-TUNNEL-ENCAP"/>.
</t>
</section>
<section numbered="true" toc="default">
<name>Subsequent Address Family Identifiers</name>
<t>
IANA has modified the "SAFI Values" registry <xref target="IANA-SAFI"/> to
indicate that the Encapsulation SAFI (value 7) has been
obsoleted. This document is listed as the reference for this change.</t>
</section>
<section numbered="true" toc="default">
<name>BGP Tunnel Encapsulation Attribute Sub-TLVs</name>
<t>
IANA has relocated the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry
to be under
the "Border Gateway Protocol (BGP) Tunnel Encapsulation" grouping <xref targe
t="IANA-BGP-TUNNEL-ENCAP"/>.</t>
<t>
IANA has included the following note to the registry:</t>
<blockquote>
If the Sub-TLV Type is in the range from 0 to 127 (inclusive), the
Sub-TLV Length field contains one octet. If the Sub-TLV Type is Sub-TLV Length field contains one octet. If the Sub-TLV Type is
in the range from 128-255 inclusive, the Sub-TLV Length field in the range from 128 to 255 (inclusive), the Sub-TLV Length field
contains two octets.</t> contains two octets.
</blockquote>
</list> <t>
</t> IANA has updated the registration procedures of the
<t>
Change the registration policy of the
registry to the following:</t> registry to the following:</t>
<table align="center">
<thead>
<tr>
<th align="left">Range</th>
<th align="left">Registration Procedures</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">1-63</td>
<td align="left">Standards Action</td>
</tr>
<tr>
<td align="left">64-125</td>
<td align="left">First Come First Served</td>
</tr>
<tr>
<td align="left">126-127</td>
<td align="left">Experimental Use</td>
</tr>
<tr>
<td align="left">128-191</td>
<td align="left">Standards Action</td>
</tr>
<tr>
<td align="left">192-252</td>
<td align="left">First Come First Served</td>
</tr>
<tr>
<td align="left">253-254</td>
<td align="left">Experimental Use</td>
</tr>
</tbody>
</table>
<texttable> <t>IANA has added the following entries to this registry:</t>
<ttcol>Value(s)</ttcol> <table align="center">
<ttcol>Registration Procedure</ttcol> <thead>
<c>0</c> <tr>
<c>Reserved</c> <th align="left">Value</th>
<c>1-63</c> <th align="left">Description</th>
<c>Standards Action</c> <th align="left">Reference</th>
<c>64-125</c> </tr>
<c>First Come First Served</c> </thead>
<c>126-127</c> <tbody>
<c>Experimental Use</c> <tr>
<c>128-191</c> <td align="left">0</td>
<c>Standards Action</c> <td align="left">Reserved</td>
<c>192-252</c> <td align="left">RFC 9012</td>
<c>First Come First Served</c> </tr>
<c>253-254</c> <tr>
<c>Experimental Use</c> <td align="left">6</td>
<c>255</c> <td align="left">Tunnel Egress Endpoint</td>
<c>Reserved</c> <td align="left">RFC 9012</td>
</texttable> </tr>
<tr>
<t>Rename the following entries within the registry:</t> <td align="left">7</td>
<td align="left">DS Field</td>
<texttable> <td align="left">RFC 9012</td>
<ttcol>Value</ttcol> </tr>
<ttcol>Old Name</ttcol>
<ttcol>New Name</ttcol>
<c>6</c>
<c>Remote Endpoint</c>
<c>Tunnel Egress Endpoint</c>
<c>7</c>
<c>IPv4 DS Field</c>
<c>DS Field</c>
</texttable>
</section>
<section title="Flags Field of VXLAN Encapsulation sub-TLV">
<t>Create a registry named "Flags Field of VXLAN Encapsulation sub-TLV" u <tr>
nder <td align="left">8</td>
the "BGP Tunnel Encapsulation Parameters" grouping. The registration policy f <td align="left">UDP Destination Port</td>
or <td align="left">RFC 9012</td>
this registry is "Standards Action". The minimum possible value is 0, the </tr>
<tr>
<td align="left">9</td>
<td align="left">Embedded Label Handling</td>
<td align="left">RFC 9012</td>
</tr>
<tr>
<td align="left">10</td>
<td align="left">MPLS Label Stack</td>
<td align="left">RFC 9012</td>
</tr>
<tr>
<td align="left">11</td>
<td align="left">Prefix-SID</td>
<td align="left">RFC 9012</td>
</tr>
<tr>
<td align="left">255</td>
<td align="left">Reserved</td>
<td align="left">RFC 9012</td>
</tr>
</tbody>
</table>
</section>
<section numbered="true" toc="default">
<name>Flags Field of VXLAN Encapsulation Sub-TLV</name>
<t>IANA has created a registry named "Flags Field of VXLAN Encapsulation
Sub-TLVs" under
the "Border Gateway Protocol (BGP) Tunnel Encapsulation" grouping <xref targe
t="IANA-BGP-TUNNEL-ENCAP"/>. The registration policy for
this registry is "Standards Action". The minimum possible value is 0, and the
maximum is 7.</t> maximum is 7.</t>
<t>The initial values for this new registry are indicated in <xref targe
<t>The initial values for this new registry are indicated below.</t> t="flags-vxlan"/>.</t>
<table align="center" anchor="flags-vxlan">
<texttable> <thead>
<ttcol align='center'>Bit Position</ttcol> <tr>
<ttcol align='left'>Description</ttcol> <th align="center">Bit Position</th>
<ttcol align='left'>Reference</ttcol> <th align="left">Description</th>
<c>0</c> <th align="left">Reference</th>
<c>V (VN-ID)</c> </tr>
<c>(this document)</c> </thead>
<c>1</c> <tbody>
<c>M (MAC Address)</c> <tr>
<c>(this document)</c> <td align="center">0</td>
</texttable> <td align="left">V (VN-ID)</td>
<td align="left">RFC 9012</td>
</section> </tr>
<tr>
<section title="Flags Field of NVGRE Encapsulation sub-TLV"> <td align="center">1</td>
<t>Create a registry named "Flags Field of NVGRE Encapsulation sub-TLV" u <td align="left">M (MAC Address)</td>
nder <td align="left">RFC 9012</td>
the "BGP Tunnel Encapsulation Parameters" grouping. The registration policy f </tr>
or </tbody>
this registry is "Standards Action". The minimum possible value is 0, the </table>
</section>
<section numbered="true" toc="default">
<name>Flags Field of NVGRE Encapsulation Sub-TLV</name>
<t>IANA has created a registry named "Flags Field of NVGRE Encapsulation
Sub-TLVs" under
the "Border Gateway Protocol (BGP) Tunnel Encapsulation" grouping <xref targe
t="IANA-BGP-TUNNEL-ENCAP"/>. The registration policy for
this registry is "Standards Action". The minimum possible value is 0, and the
maximum is 7.</t> maximum is 7.</t>
<t>The initial values for this new registry are indicated in <xref targe
<t>The initial values for this new registry are indicated below.</t> t="flags-nvgre"/>.</t>
<table align="center" anchor="flags-nvgre">
<texttable> <thead>
<ttcol align='center'>Bit Position</ttcol> <tr>
<ttcol align='left'>Description</ttcol> <th align="center">Bit Position</th>
<ttcol align='left'>Reference</ttcol> <th align="left">Description</th>
<c>0</c> <th align="left">Reference</th>
<c>V (VN-ID)</c> </tr>
<c>(this document)</c> </thead>
<c>1</c> <tbody>
<c>M (MAC Address)</c> <tr>
<c>(this document)</c> <td align="center">0</td>
</texttable> <td align="left">V (VN-ID)</td>
<td align="left">RFC 9012</td>
</section> </tr>
<tr>
<section title="Embedded Label Handling sub-TLV"> <td align="center">1</td>
<t>Create a registry named "Embedded Label Handling sub-TLV" under <td align="left">M (MAC Address)</td>
the "BGP Tunnel Encapsulation Parameters" grouping. The registration policy f <td align="left">RFC 9012</td>
or </tr>
this registry is "Standards Action". The minimum possible value is 0, the </tbody>
</table>
</section>
<section numbered="true" toc="default">
<name>Embedded Label Handling Sub-TLV</name>
<t>IANA has created a registry named "Embedded Label Handling Sub-TLVs"
under
the "Border Gateway Protocol (BGP) Tunnel Encapsulation" grouping <xref targe
t="IANA-BGP-TUNNEL-ENCAP"/>. The registration policy for
this registry is "Standards Action". The minimum possible value is 0, and the
maximum is 255.</t> maximum is 255.</t>
<t>The initial values for this new registry are indicated in <xref targe
<t>The initial values for this new registry are indicated below.</t> t="embedded-label"/>.</t>
<table align="center" anchor="embedded-label">
<texttable> <thead>
<ttcol align='center'>Value</ttcol> <tr>
<ttcol align='left'>Description</ttcol> <th align="center">Value</th>
<ttcol align='left'>Reference</ttcol> <th align="left">Description</th>
<c>0</c> <th align="left">Reference</th>
<c>Reserved</c> </tr>
<c>(this document)</c> </thead>
<c>1</c> <tbody>
<c>Payload of MPLS with embedded label</c> <tr>
<c>(this document)</c> <td align="center">0</td>
<c>2</c> <td align="left">Reserved</td>
<c>no embedded label in payload</c> <td align="left">RFC 9012</td>
<c>(this document)</c> </tr>
</texttable> <tr>
<td align="center">1</td>
</section> <td align="left">Payload of MPLS with embedded label</td>
<td align="left">RFC 9012</td>
<section title="Color Extended Community Flags" anchor="color-extcomm-fla </tr>
gs"> <tr>
<t>Create a registry named "Color Extended Community Flags" under <td align="center">2</td>
the "BGP Tunnel Encapsulation Parameters" grouping. The registration policy f <td align="left">No embedded label in payload</td>
or <td align="left">RFC 9012</td>
this registry is "Standards Action". The minimum possible value is 0, the </tr>
</tbody>
</table>
</section>
<section anchor="color-extcomm-flags" numbered="true" toc="default">
<name>Color Extended Community Flags</name>
<t>IANA has created a registry named "Color Extended Community Flags" un
der
the "Border Gateway Protocol (BGP) Tunnel Encapsulation" grouping <xref targe
t="IANA-BGP-TUNNEL-ENCAP"/>. The registration policy for
this registry is "Standards Action". The minimum possible value is 0, and the
maximum is 15.</t> maximum is 15.</t>
<t> This new registry contains columns for "Bit Position", "Descriptio
<t>No initial values are to be registered. The format of the registry n", and
is shown below.</t> "Reference". No values have currently been registered.
</t>
<texttable> </section>
<ttcol align='center'>Bit Position</ttcol> </section>
<ttcol align='left'>Description</ttcol> <section anchor="security" numbered="true" toc="default">
<ttcol align='left'>Reference</ttcol> <name>Security Considerations</name>
</texttable> <t>
As <xref target="scoping" format="default"/> discusses, it is intended that t
</section> he
</section>
<section title="Security Considerations" anchor="security">
<t>
As <xref target="scoping"/> discusses, it is intended that the
Tunnel Encapsulation attribute be used only within a well-defined Tunnel Encapsulation attribute be used only within a well-defined
scope, for example, within a set of Autonomous Systems that belong to a scope, for example, within a set of ASes that belong to a
single administrative entity. As long as the filtering mechanisms single administrative entity. As long as the filtering mechanisms
discussed in that section are applied diligently, an attacker outside discussed in that section are applied diligently, an attacker outside
the scope would not be able to use the Tunnel Encapsulation attribute the scope would not be able to use the Tunnel Encapsulation attribute
in an attack. This leaves open the questions of attackers within the in an attack. This leaves open the questions of attackers within the
scope (for example, a compromised router) and failures in filtering scope (for example, a compromised router) and failures in filtering
that allow an external attack to succeed. that allow an external attack to succeed.
</t> </t>
<t>
<t> As <xref target="RFC4272" format="default"/> discusses, BGP is vulnerable to
As <xref target="RFC4272"/> discusses, BGP is vulnerable to traffic traffic-diversion attacks. The Tunnel Encapsulation attribute adds a new
diversion attacks. The Tunnel Encapsulation attribute adds a new
means by which an attacker could cause traffic to be diverted from means by which an attacker could cause traffic to be diverted from
its normal path, especially when the Tunnel Egress Endpoint sub-TLV its normal path, especially when the Tunnel Egress Endpoint sub-TLV
is used. Such an attack would differ from pre-existing is used. Such an attack would differ from pre-existing
vulnerabilities in that traffic could be tunneled to a distant target vulnerabilities in that traffic could be tunneled to a distant target
across intervening network infrastructure, allowing an attack to across intervening network infrastructure, allowing an attack to
potentially succeed more easily, since less infrastructure would have potentially succeed more easily, since less infrastructure would have
to be subverted. Potential consequences include "hijacking" of to be subverted. Potential consequences include "hijacking" of
traffic (insertion of an undesired node in the path allowing for traffic (insertion of an undesired node in the path, which allows for
inspection or modification of traffic, or avoidance of security inspection or modification of traffic, or avoidance of security
controls) or denial of service (directing traffic to a node that controls) or denial of service (directing traffic to a node that
doesn't desire to receive it). doesn't desire to receive it).
</t> </t>
<t>
<t>
In order to further mitigate the risk of diversion of traffic from In order to further mitigate the risk of diversion of traffic from
its intended destination, <xref target="address-validation"/> its intended destination, <xref target="address-validation" format="default"/ >
provides an optional procedure to check that the destination given in provides an optional procedure to check that the destination given in
a Tunnel Egress Endpoint sub-TLV is within the AS that was the source a Tunnel Egress Endpoint sub-TLV is within the AS that was the source
of the route. One then has some level of assurance that the tunneled of the route. One then has some level of assurance that the tunneled
traffic is going to the same destination AS that it would have gone traffic is going to the same destination AS that it would have gone
to had the Tunnel Encapsulation attribute not been present. As RFC to had the Tunnel Encapsulation attribute not been present. As RFC
4272 discusses, it's possible for an attacker to announce an 4272 discusses, it's possible for an attacker to announce an
inaccurate AS_PATH, therefore an attacker with the ability to inject inaccurate AS_PATH; therefore, an attacker with the ability to inject
a Tunnel Egress Endpoint sub-TLV could equally craft an AS_PATH that would a Tunnel Egress Endpoint sub-TLV could equally craft an AS_PATH that would
pass the validation procedures of <xref pass the validation procedures of <xref target="address-validation" format="d
target="address-validation"/>. BGP Origin Validation <xref efault"/>. BGP origin validation <xref target="RFC6811" format="default"/> and B
target="RFC6811"/> and BGPsec <xref target="RFC8205"/> provide means GPsec <xref target="RFC8205" format="default"/> provide means to increase assura
to increase assurance that the origins being validated have not been nce that the origins being validated have not been
falsified. falsified.
</t> </t>
<t>
<t>
Many tunnels carry traffic that embeds a destination address that comes Many tunnels carry traffic that embeds a destination address that comes
from a non-global namespace. One example is MPLS VPNs. If a tunnel from a non-global namespace. One example is MPLS VPNs. If a tunnel
crosses from one namespace to another, without the necessary translation crosses from one namespace to another, without the necessary translation
being performed for the embedded address(es), there exists a risk of being performed for the embedded address(es), there exists a risk of
misdelivery of traffic. If the traffic contains confidential data that's misdelivery of traffic. If the traffic contains confidential data that's
not otherwise protected (for example, by end-to-end encryption) then not otherwise protected (for example, by end-to-end encryption), then
confidential information could be revealed. The restriction of applicability confidential information could be revealed. The restriction of applicability
of the Tunnel Encapsulation attribute to a well-defined scope limits the of the Tunnel Encapsulation attribute to a well-defined scope limits the
likelihood of this occurring. See the discussion of "option b" in likelihood of this occurring. See the discussion of "option b" in
<xref target="applicability"/> for further discussion of one such <xref target="applicability" format="default"/> for further discussion of one such
scenario. scenario.
</t> </t>
<t>
<t> RFC 8402 specifies that "SR domain boundary routers <bcp14>MUST</bcp14> filte
RFC 8402 specifies that "SR domain boundary routers MUST filter any r any
external traffic" (<xref target="RFC8402"/> Section 8.1). For these external traffic" (<xref target="RFC8402" sectionFormat="comma" section="8.1"
purposes, traffic introduced into a SR domain using the Prefix-SID />). For these
sub-TLV lies within the SR domain, even though the prefix-SIDs used purposes, traffic introduced into an SR domain using the Prefix-SID
sub-TLV lies within the SR domain, even though the Prefix-SIDs used
by the routers at the two ends of the tunnel may be different, as by the routers at the two ends of the tunnel may be different, as
discussed in <xref target="prefix-sid"/>. This implies that the duty discussed in <xref target="prefix-sid" format="default"/>. This implies that the duty
to filter external traffic extends to all routers participating in to filter external traffic extends to all routers participating in
such tunnels. such tunnels.
</t> </t>
</section>
</section> </middle>
<back>
<section title="Acknowledgments"><t>
This document contains text from RFC 5512, authored by Pradosh
Mohapatra and Eric Rosen. The authors of the current document wish to thank
them for their contribution. RFC 5512 itself built upon prior work by Gargi
Nalawade, Ruchi Kapoor, Dan Tappan, David Ward, Scott Wainner, Simon
Barber, Lili Wang, and Chris Metz, whom the authors also thank for their
contributions. Eric Rosen was the principal author of earlier versions
of this document.</t>
<t>
The authors wish to thank Lou Berger, Ron Bonica, Martin Djernaes,
John Drake, Susan Hares, Satoru Matsushima, Thomas Morin, Dhananjaya Rao, Rav
i
Singh, Harish Sitaraman, Brian Trammell, Xiaohu Xu, and Zhaohui Zhang for the
ir review,
comments, and/or helpful discussions. Alvaro Retana provided an
especially comprehensive review.</t>
</section>
<section title="Contributor Addresses"><t> <displayreference target="I-D.ietf-bess-evpn-inter-subnet-forwarding" to="EVPN-I
Below is a list of other contributing authors in alphabetical order:</t> NTER-SUBNET"/>
<figure><artwork><![CDATA[ <references>
Randy Bush <name>References</name>
Internet Initiative Japan <references>
5147 Crystal Springs <name>Normative References</name>
Bainbridge Island, Washington 98110 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
United States FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7606.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2784.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2890.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3032.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3270.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3931.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4023.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5129.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5462.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6811.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7348.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7637.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4271.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6890.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8669.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2474.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4760.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8126.xml"/>
</references>
<references>
<name>Informative References</name>
Email: randy@psg.com <!-- [I-D.ietf-bess-evpn-inter-subnet-forwarding] IESG state IESG Evaluation::AD Followup -->
Robert Raszuk <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
Bloomberg LP .ietf-bess-evpn-inter-subnet-forwarding.xml"/>
731 Lexington Ave
New York City, NY 10022
United States
Email: robert@raszuk.net <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4272.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4364.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5565.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5640.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8205.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8277.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5566.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7510.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5512.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6514.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8365.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8402.xml"/>
Eric C. Rosen <reference anchor="IANA-BGP-TUNNEL-ENCAP"
target="https://www.iana.org/assignments/bgp-tunnel-encapsulation/">
<front>
<title>Border Gateway Protocol (BGP) Tunnel Encapsulation</title>
<author><organization>IANA</organization></author>
</front>
</reference>
]]></artwork> <reference anchor="IANA-BGP-PARAMS"
</figure> target="https://www.iana.org/assignments/bgp-parameters/">
</section> <front>
<title>Border Gateway Protocol (BGP) Parameters</title>
<author><organization>IANA</organization></author>
</front>
</reference>
</middle> <reference anchor="IANA-ADDRESS-FAM"
target="https://www.iana.org/assignments/address-family-numbers/">
<front>
<title>Address Family Numbers</title>
<author><organization>IANA</organization></author>
</front>
</reference>
<back> <reference anchor="IANA-ETHERTYPES"
<references title="Normative References"> target="https://www.iana.org/assignments/ieee-802-numbers/">
&RFC2119; <front>
&RFC7606; <title>IEEE 802 Numbers: ETHER TYPES</title>
&RFC8174; <author><organization>IANA</organization></author>
&RFC2784; </front>
&RFC2890; </reference>
&RFC3032;
&RFC3270;
&RFC3931;
&RFC4023;
&RFC5129;
&RFC5462;
&RFC6811;
&RFC7348;
&RFC7637;
&RFC4271;
&RFC6890;
&RFC8669;
&RFC2474;
&RFC4760;
&RFC8126;
</references> <reference anchor="IANA-BGP-EXT-COMM"
<references title="Informative References"> target="https://www.iana.org/assignments/bgp-extended-communities/">
<reference anchor="Ethertypes" target="http://www.iana.org/assignments/ie <front>
ee-802-numbers/ieee-802-numbers.xhtml"><front> <title>Border Gateway Protocol (BGP) Extended Communities</title>
<title>IANA Ethertype Registry</title> <author><organization>IANA</organization></author>
<author> </front>
</author> </reference>
<date/> <reference anchor="IANA-SAFI"
</front> target="https://www.iana.org/assignments/safi-namespace/">
<front>
<title>Subsequent Address Family Identifiers (SAFI) Parameters</title>
<author><organization>IANA</organization></author>
</front>
</reference>
</reference>
&I-D.ietf-bess-evpn-inter-subnet-forwarding;
&RFC4272;
&RFC4364;
&RFC5565;
&RFC5640;
&RFC8205;
&RFC8277;
&RFC5566;
&RFC7510;
&RFC5512;
&RFC6514;
&RFC8365;
&RFC8402;
<!--> &I-D.ietf-intarea-tunnels;-->
</references> </references>
</references>
<section title="Impact on RFC 8365" anchor="impact-on-8365"> <section anchor="impact-on-8365" numbered="true" toc="default">
<t> <name>Impact on RFC 8365</name>
<xref target="RFC8365"/> references RFC 5512 for its definition of <t>
<xref target="RFC8365" format="default"/> references RFC 5512 for its def
inition of
the BGP Encapsulation Extended Community. That extended community is the BGP Encapsulation Extended Community. That extended community is
now defined in this document, in a way consistent with its previous now defined in this document, in a way consistent with its previous
definition. definition.
</t> </t>
<t>
<t> <xref target="RFC8365" section="6"/> talks about the use of the Encapsula
RFC 8365 talks in Section 6 about the use of the Encapsulation Extended tion Extended
Community to allow Network Virtualization Edge devices (NVEs) to Community to allow Network Virtualization Edge (NVE) devices to
signal their supported encapsulations. We signal their supported encapsulations. We
note that with the introduction of this specification, the Tunnel note that with the introduction of this specification, the Tunnel
Encapsulation Attribute can also be used for this purpose. For purposes Encapsulation attribute can also be used for this purpose. For purposes
where RFC 8365 talks about "advertising supported encapsulations" (for where RFC 8365 talks about "advertising supported encapsulations" (for
example, in the second paragraph of Section 6), encapsulations advertised example, in the second paragraph of Section <xref target="RFC8365" sectio
using the Tunnel Encapsulation Attribute should be considered equally wit n="6" sectionFormat="bare"/>), encapsulations advertised
h using the Tunnel Encapsulation attribute should be considered equally wit
h
those advertised using the Encapsulation Extended Community. those advertised using the Encapsulation Extended Community.
</t> </t>
<t>
In particular, a review of <xref target="RFC8365" section="8.3.1" /> is c
alled for, to
consider whether the introduction of the Tunnel Encapsulation attribute
creates a need for any revisions to the split-horizon procedures.
</t>
<t>
<xref target="RFC8365" format="default"/> also refers to a draft version
of this specification in
the final paragraph of Section <xref target="RFC8365" section="5.1.3" sec
tionFormat="bare" />. That paragraph references
Section 8.2.2.2 of the draft. In this document, the correct reference
would be <xref target="no-valid-vni" format="default"/>. There are no sub
stantive
differences between the section in the referenced draft version and that
in
this document.
</t>
</section>
<section numbered="false" toc="default">
<name>Acknowledgments</name>
<t>
This document contains text from RFC 5512, authored by <contact fullname="Pra
dosh Mohapatra"/> and <contact fullname="Eric Rosen"/>. The authors of the curr
ent document wish to thank
them for their contribution. RFC 5512 itself built upon prior work by <conta
ct fullname="Gargi Nalawade"/>, <contact fullname="Ruchi Kapoor"/>, <contact ful
lname="Dan Tappan"/>, <contact fullname="David Ward"/>, <contact fullname="Scott
Wainner"/>, <contact fullname="Simon Barber"/>, <contact fullname="Lili Wang"/>
, and <contact fullname="Chris Metz"/>, whom the authors also thank for their
contributions. <contact fullname="Eric Rosen"/> was the principal author of e
arlier versions
of this document.</t>
<t>
The authors wish to thank <contact fullname="Lou Berger"/>, <contact fullname
="Ron Bonica"/>, <contact fullname="Martin Djernaes"/>,
<contact fullname="John Drake"/>, <contact fullname="Susan Hares"/>, <contact
fullname="Satoru Matsushima"/>, <contact fullname="Thomas Morin"/>, <contact fu
llname="Dhananjaya Rao"/>, <contact fullname="Ravi Singh"/>, <contact fullname="
Harish Sitaraman"/>, <contact fullname="Brian Trammell"/>, <contact fullname="Xi
aohu Xu"/>, and <contact fullname="Zhaohui Zhang"/> for their review, comments,
and/or helpful discussions. <contact fullname="Alvaro Retana"/> provided an
especially comprehensive review.</t>
</section>
<section numbered="false" toc="default">
<name>Contributors</name>
<t>
Below is a list of other contributing authors in alphabetical order:</t>
<contact fullname="Randy Bush">
<organization>Internet Initiative Japan</organization>
<address>
<postal>
<street>5147 Crystal Springs</street>
<city>Bainbridge Island</city>
<region>WA</region>
<code>98110</code>
<country>United States of America</country>
</postal>
<email>randy@psg.com </email>
</address>
</contact>
<t> <contact fullname="Robert Raszuk">
In particular, a review of Section 8.3.1 of RFC 8365 is called for, to <organization>Bloomberg LP</organization>
consider whether the introduction of the Tunnel Encapsulation Attribute <address>
creates a need for any revisions to the split horizon procedures. <postal>
</t> <street>731 Lexington Ave</street>
<city>New York City</city>
<region>NY</region>
<code>10022</code>
<country>USA</country>
</postal>
<email>robert@raszuk.net</email>
</address>
</contact>
<t> <contact fullname="Eric C. Rosen"/>
RFC 8365 also refers to a draft version of this specification in
the final paragraph of section 5.1.3. That paragraph references
Section 8.2.2.2 of the draft. In this version of the document the correct
reference
would be <xref target="no-valid-vni"/>. There are no substantive
differences between the section in the referenced draft, and that in
this document.
</t>
</section>
</back> </section>
</rfc> </back>
</rfc>
 End of changes. 356 change blocks. 
1845 lines changed or deleted 1876 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/