rfc9013xml2.original.xml   rfc9013.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-ospf-encapsulation-cap-09" ipr="trust20
0902">
<front>
<title abbrev="Tunnel Encapsulations RI">The Tunnel Encapsulations OSPF Rout
er Information</title>
<author fullname="Xiaohu Xu" initials="X.X." role="editor" surname="Xu"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
<organization>Huawei</organization> docName="draft-ietf-ospf-encapsulation-cap-09" ipr="trust200902"
obsoletes="" updates="" submissionType="IETF" xml:lang="en"
tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true"
version="3" number="9013" consensus="true">
<!-- xml2rfc v2v3 conversion 2.46.0 -->
<front>
<title abbrev="Tunnel Encapsulations RI">OSPF Advertisement of Tunnel Encaps
ulations</title>
<seriesInfo name="RFC" value="9013"/>
<author fullname="Xiaohu Xu" initials="X" role="editor" surname="Xu">
<organization>Capitalonline</organization>
<address> <address>
<email>xuxiaohu@huawei.com</email> <email>xiaohu.xu@capitalonline.net</email>
</address> </address>
</author> </author>
<author fullname="Bruno Decraene" initials="B" role="editor" surname="Decrae
<author fullname="Bruno Decraene " initials="B.D." role="editor" surname="De ne">
craene">
<organization>Orange</organization> <organization>Orange</organization>
<address> <address>
<email>bruno.decraene@orange.com</email> <email>bruno.decraene@orange.com</email>
</address> </address>
</author> </author>
<author fullname="Robert Raszuk" initials="R" surname="Raszuk">
<author fullname="Robert Raszuk" initials="R.R." surname="Raszuk"> <organization>NTT Network Innovations</organization>
<organization>Bloomberg LP</organization>
<address> <address>
<!-- <postal>
<postal> <street>940 Stewart Dr</street>
<street></street> <city>Sunnyvale</city>
<region>CA</region>
<!-- Reorder these if your country does things differently --> <code>94085</code>
<country>United States of America</country>
<!-- </postal>
<city>Soham</city>
<region></region>
<code></code>
<country>UK</country>
</postal>
<phone>+44 7889 488 335</phone>
<email>robert@raszuk.net</email> <email>robert@raszuk.net</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Luis M. Contreras" initials="L" surname="Contreras">
<author fullname="Luis M. Contreras" initials="L.C." surname="Contreras">
<organization>Telefonica I+D</organization> <organization>Telefonica I+D</organization>
<address> <address>
<email>luismiguel.contrerasmurillo@telefonica.com</email> <email>luismiguel.contrerasmurillo@telefonica.com</email>
</address> </address>
</author> </author>
<author fullname="Luay Jalil" initials="L" surname="Jalil">
<author fullname="Luay Jalil" initials="L.J." surname="Jalil">
<organization>Verizon</organization> <organization>Verizon</organization>
<address> <address>
<email>luay.jalil@verizon.com</email> <email>luay.jalil@verizon.com</email>
</address> </address>
</author> </author>
<date year="2021" month="April"/>
<date year='2017'/> <keyword>BGP</keyword>
<area>Routing Area</area>
<workgroup>OSPF Working Group</workgroup>
<abstract> <abstract>
<t>Networks use tunnels for a variety of reasons. A large variety of <t>Networks use tunnels for a variety of reasons. A large variety of
tunnel types are defined and the tunnel encapsulator router needs to selec tunnel types are defined, and the tunnel encapsulator router needs to sele
t a ct a
type of tunnel which is supported by the tunnel decapsulator router. This type of tunnel that is supported by the tunnel decapsulator router. This d
document ocument
defines how to advertise, in OSPF Router Information Link State Advertisem defines how to advertise, in OSPF Router Information Link State Advertisem
ent (LSAs), ents (LSAs),
the list of tunnel encapsulations supported by the tunnel decapsulator.</t > the list of tunnel encapsulations supported by the tunnel decapsulator.</t >
</abstract> </abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front> </front>
<middle> <middle>
<section anchor="Introduction" title="Introduction"> <section anchor="Introduction" numbered="true" toc="default">
<name>Introduction</name>
<t>Networks use tunnels for a variety of reasons, such as:</t> <t>Networks use tunnels for a variety of reasons, such as:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Partial deployment of IPv6 in IPv4 networks or IPv4 in IPv6
<t>Partial deployment of IPv6 in IPv4 networks or IPv4 in IPv6 networks, as described in <xref target="RFC5565" format="default"/>, w
networks as described in <xref target="RFC5565"/>, where IPvx here IPvx
tunnels are used between IPvx-enabled routers so as to traverse tunnels are used between IPvx-enabled routers so as to traverse
non-IPvx routers.</t> non-IPvx routers.</li>
<li>Remote Loop-Free Alternate (RLFA) repair tunnels as described in
<t>Remote Loop-Free Alternate (RLFA) repair tunnels as described in
<xref target="RFC7490"/>, where tunnels are used between the Point
of Local Repair and the selected PQ node.</t>
</list></t>
<t>The tunnel encapsulator router needs to select a type of tunnel which i <xref target="RFC7490" format="default"/>, where tunnels are used betwe
s en the Point
of Local Repair and the selected PQ node.</li>
</ul>
<t>The tunnel encapsulator router needs to select a type of tunnel that is
supported by the tunnel decapsulator router. This document supported by the tunnel decapsulator router. This document
defines how to advertise, in OSPF Router Information Link State Advertisem ent (LSAs), defines how to advertise, in OSPF Router Information Link State Advertisem ents (LSAs),
the list of tunnel encapsulations supported by the tunnel decapsulator. the list of tunnel encapsulations supported by the tunnel decapsulator.
In this document, OSPF refers to both OSPFv2 In this document, OSPF refers to both OSPFv2
<xref target="RFC2328"/> and OSPFv3 <xref target="RFC5340"/>.</t> <xref target="RFC2328" format="default"/> and OSPFv3 <xref target="RFC5340
</section> " format="default"/>.</t>
<section anchor="Terminology" title="Terminology">
<t>This memo makes use of the terms defined in <xref
target="RFC7770"/>.</t>
</section> </section>
<section anchor="Terminology" numbered="true" toc="default">
<section anchor="RI" title="Tunnel Encapsulations TLV"> <name>Terminology</name>
<t>This memo makes use of the terms defined in <xref target="RFC7770"
format="default"/>.</t>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
<section anchor="RI" numbered="true" toc="default">
<name>Tunnel Encapsulations TLV</name>
<t>Routers advertise their supported tunnel encapsulation type(s) by <t>Routers advertise their supported tunnel encapsulation type(s) by
advertising a new TLV of the OSPF Router Information (RI) Opaque LSA advertising a new TLV of the OSPF Router Information (RI) Opaque LSA
<xref target="RFC7770"/>, referred to as the Tunnel Encapsulations TLV. <xref target="RFC7770" format="default"/>, referred to as the "Tunnel Enca psulations TLV".
This TLV is applicable to both OSPFv2 and OSPFv3.</t> This TLV is applicable to both OSPFv2 and OSPFv3.</t>
<t>The Type code of the Tunnel Encapsulations is TBD1, the
<t>The Type code of the Tunnel Encapsulations TLV is 13, the
Length value is variable, and the Value field contains one or more Length value is variable, and the Value field contains one or more
Tunnel Sub-TLVs as defined in <xref target="TunnelType"/>. Tunnel Sub-TLVs, as defined in <xref target="TunnelType" format="default"/ >.
Each Tunnel Sub-TLV indicates a particular encapsulation Each Tunnel Sub-TLV indicates a particular encapsulation
format that the advertising router supports along with the parameters format that the advertising router supports, along with the parameters
corresponding to the tunnel type.</t> corresponding to the tunnel type.</t>
<t>The Tunnel Encapsulations TLV MAY appear more than once <t>The Tunnel Encapsulations TLV <bcp14>MAY</bcp14> appear more than once
within a given OSPF Router Information (RI) Opaque LSA. If the Tunnel within a given OSPF Router Information (RI) Opaque LSA. If the Tunnel
Encapsulations TLV appears more than once in an OSPF Router Encapsulations TLV appears more than once in an OSPF Router
Information LSA, the set of all Tunnel Sub-TLVs from all Tunnel Encapsulat Information LSA, the set of all Tunnel Sub-TLVs from all Tunnel
ions TLV SHOULD be considered. The scope of the advertisement depends on the Encapsulations TLVs <bcp14>SHOULD</bcp14> be considered. The scope of
application but it is recommended that it SHOULD be domain-wide.</t> the advertisement depends on the
application, but it is recommended that it <bcp14>SHOULD</bcp14> be
domain wide.</t>
</section> </section>
<section anchor="TunnelType" numbered="true" toc="default">
<name>Tunnel Sub-TLV</name>
<t>The Tunnel Sub-TLV is structured as shown in <xref
target="Tunnel_Sub-TLV"/>.</t>
<figure anchor="Tunnel_Sub-TLV">
<name>Tunnel Sub-TLV</name>
<section anchor="TunnelType" title="Tunnel Sub-TLV"> <artwork name="" type="" align="left" alt=""><![CDATA[
<t>The Tunnel Sub-TLV is structured as follows:</t>
<t><figure anchor="Tunnel_Sub-TLV" title="Tunnel 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Type (2 Octets) | Length (2 Octets) | | Tunnel Type (2 octets) | Length (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Tunnel Parameter Sub-TLVs | | Tunnel Parameter Sub-TLVs |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork></figure>
</figure></t> <dl newline="false">
<dt>Tunnel Type (2 octets):</dt><dd>Identifies the type of tunneling
<t><list>
<t>Tunnel Type (2 octets): Identifies the type of tunneling
technology signaled. Tunnel types are shared with the BGP technology signaled. Tunnel types are shared with the BGP
extension <xref target="I-D.ietf-idr-tunnel-encaps"/> and hence are extension <xref target="RFC9012" format="default"/> and hence are
defined in the IANA registry "BGP Tunnel Encapsulation Attribute defined in the IANA registry "BGP Tunnel Encapsulation Attribute
Tunnel Types". Unknown Tunnel types are to be ignored upon Tunnel Types". Unknown tunnel types are to be ignored upon
receipt.</t> receipt.</dd>
<dt>Length (2 octets):</dt><dd>Unsigned 16-bit integer indicating the to
<t>Length (2 octets): Unsigned 16-bit integer indicating the total tal
number of octets of the value field.</t> number of octets of the Tunnel Parameter Sub-TLVs field.</dd>
<dt>Tunnel Parameter Sub-TLVs (variable):</dt><dd>Zero or more Tunnel Pa
<t>Value (variable): Zero or more Tunnel Parameter rameter
Sub-TLVs as defined in <xref target="ParameterTLVs"/>.</t> Sub-TLVs, as defined in <xref target="ParameterTLVs" format="default"/
</list></t> >.</dd>
</dl>
<t>If a Tunnel Sub-TLV is invalid, it MUST be ignored and skipped <t>If a Tunnel Sub-TLV is invalid, it <bcp14>MUST</bcp14> be ignored and s
. However, kipped. However,
other Tunnel Sub-TLVs MUST be considered</t> other Tunnel Sub-TLVs <bcp14>MUST</bcp14> be considered.</t>
</section> </section>
<section anchor="ParameterTLVs" numbered="true" toc="default">
<section anchor="ParameterTLVs" title="Tunnel Parameter Sub-TLVs"> <name>Tunnel Parameter Sub-TLVs</name>
<t>A Tunnel Parameter Sub-TLV is structured as follows:</t> <t>A Tunnel Parameter Sub-TLV is structured as shown in <xref target="Tunn
el_Parameter_Sub-TLV"/>.</t>
<t><figure anchor="Tunnel_Parameter_Sub-TLV" title="Tunnel Parameter Sub-T <figure anchor="Tunnel_Parameter_Sub-TLV">
LV"> <name>Tunnel Parameter Sub-TLV</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+---------------------------------------------+ +---------------------------------------------+
| Tunnel Parameter Sub-Type (2 Octets) | | Tunnel Parameter Sub-Type (2 octets) |
+---------------------------------------------+ +---------------------------------------------+
| Tunnel Parameter Length (2 Octets) | | Tunnel Parameter Length (2 octets) |
+---------------------------------------------+ +---------------------------------------------+
| Tunnel Parameter Value (Variable) | | Tunnel Parameter Value (variable) |
| | | |
+---------------------------------------------+ +---------------------------------------------+
]]></artwork> ]]></artwork></figure>
</figure><list>
<t>Tunnel Parameter Sub-Type (2 octets): Each sub-type defines a
parameter of the Tunnel Sub-TLV. Sub-Types are
registered in the IANA registry "OSPF Tunnel Parameter Sub-TLVs" <xref
target="ParameterRegistry"/>.</t>
<t>Tunnel Parameter Length (2 octets): Unsigned 16-bit integer indicat
ing the
total number of octets of the Tunnel Parameter Value field.</t>
<t>Tunnel Parameter Value (variable): Encodings of the value field dep
end on
the Sub-TLV type as enumerated above. The following sub-sections
define the encoding in detail.</t>
</list>Any unknown Tunnel Parameter Sub-Type MUST be ignored and skipped
upon receipt. When a reserved
value (See <xref target="ParameterRegistry"/>) is seen in an LSA, it
MUST be treated as an invalid Tunnel Parameter Sub-TLV. When a Tunnel Para
meter Value has an incorrect syntax or semantic, it MUST be treated as an invali
d Tunnel Parameter Sub-TLV. If a Tunnel Parameter Sub-TLV is invalid, its
Tunnel Sub-TLV MUST be ignored. However,
other Tunnel Sub-TLVs MUST be considered.</t>
<section anchor="EncapsulationTLV" title="Encapsulation Sub-TLV"> <dl newline="false">
<t>This Sub-TLV type is 1. The syntax, semantic, and usage of its value <dt>Tunnel Parameter Sub-Type (2 octets):</dt><dd>Each sub-type defines
field are defined in Section 3.2 "Encapsulation a
Sub-TLVs for Particular Tunnel Types" of <xref target="I-D.ietf-idr-tunn parameter of the Tunnel Sub-TLV. Sub-types are
el-encaps"/>.</t> registered in the IANA registry "OSPF Tunnel Parameter Sub-TLVs"
(see <xref target="ParameterRegistry" format="default"/>).</dd>
<dt>Tunnel Parameter Length (2 octets):</dt><dd>Unsigned 16-bit integer
indicating the
total number of octets of the Tunnel Parameter Value field.</dd>
<dt>Tunnel Parameter Value (variable):</dt><dd>Encodings of the Value fi
eld depend on
the sub-TLV type. The following subsections
define the encoding in detail.</dd>
</dl>
<t>Any unknown Tunnel Parameter sub-type <bcp14>MUST</bcp14> be ignored
and skipped upon receipt. When a reserved
value (see <xref target="ParameterRegistry" format="default"/>) is seen in
an LSA, it
<bcp14>MUST</bcp14> be treated as an invalid Tunnel Parameter Sub-TLV. Whe
n a Tunnel Parameter Value has an incorrect syntax or semantics, it <bcp14>MUST<
/bcp14> be treated as an invalid Tunnel Parameter Sub-TLV. If a Tunnel Parameter
Sub-TLV is invalid, its
Tunnel Sub-TLV <bcp14>MUST</bcp14> be ignored. However,
other Tunnel Sub-TLVs <bcp14>MUST</bcp14> be considered.</t>
<section anchor="EncapsulationTLV" numbered="true" toc="default">
<name>Encapsulation Sub-TLV</name>
<t>This sub-TLV type is 1. The syntax, semantics, and usage of its
Value field are defined in Section <xref target="RFC9012"
sectionFormat="bare" section="3.2">"Encapsulation Sub-TLVs for
Particular Tunnel Types"</xref> of <xref target="RFC9012"
format="default"/>.</t>
</section> </section>
<section anchor="ProtocolTLV" numbered="true" toc="default">
<section anchor="ProtocolTLV" title="Protocol Type Sub-TLV"> <name>Protocol Type Sub-TLV</name>
<t>This Sub-TLV type is 2. The syntax, semantic, and usage of its value <t>This sub-TLV type is 2. The syntax, semantics, and usage of its
field are defined in Section 3.4.1 "Protocol Type Value field are defined in Section <xref target="RFC9012"
sub-TLV" of <xref target="I-D.ietf-idr-tunnel-encaps"/>.</t> sectionFormat="bare" section="3.4.1">"Protocol Type Sub-TLV"</xref> of
<xref target="RFC9012" format="default"/>.</t>
</section> </section>
<section anchor="EndpointTLV" numbered="true" toc="default">
<section anchor="EndpointTLV" title="Endpoint Sub-TLV"> <name>Tunnel Egress Endpoint Sub-TLV</name>
<t>This Sub-TLV type is 3. It MUST be present once and only once in a gi <t>The Tunnel Egress Endpoint Sub-TLV specifies the address of the egres
ven Tunnel Sub-TLV. The value field contain two sub-fields: s endpoint of the tunnel -- that is, the address of the router that will decapsu
<list> late the payload.</t>
<t>a two-octet Address Family sub-field</t> <t>This sub-TLV type is 3. It <bcp14>MUST</bcp14> be present once and on
<t>an Address sub-field, whose length depends upon the Ad ly once in a given Tunnel Sub-TLV. The Value field contains two subfields:
dress Family.</t> </t>
</list></t> <ul spacing="normal">
<li>a two-octet Address Family subfield</li>
<t><figure anchor="Endpoint_Sub-TLV" title="Endpoint Sub-TLV"> <li>an Address subfield, whose length depends upon the Address Family<
<artwork><![CDATA[ /li>
0 1 2 3 </ul>
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 <figure anchor="Endpoint_Sub-TLV">
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <name>Tunnel Egress Endpoint Sub-TLV</name>
| Address Family | Address ~ <artwork name="" type="" align="left" alt=""><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 0 1 2 3
~ (Variable length) ~ 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
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family | Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ (variable length) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>The Address Family subfield contains a value from IANA's "Address <t>The Address Family subfield contains a value from IANA's "Address
Family Numbers" registry. In this document, we assume that the Family Numbers" registry. In this document, we assume 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>If the Address Family subfield contains the value for IPv4, the <t>If the Address Family subfield contains the value for IPv4, the
address subfield MUST contain an IPv4 address (a /32 IPv4 prefix). Address subfield <bcp14>MUST</bcp14> contain an IPv4 address (a /32 IPv4 pref
In this case, the length field of Remote Endpoint sub-TLV MUST contain the va ix).
lue 6.</t> In this case, the Length field of the Tunnel Egress Endpoint Sub-TLV <bcp14>M
UST</bcp14> contain the value 6.</t>
<t>If the Address Family subfield contains the value for IPv6, th <t>If the Address Family subfield contains the value for IPv6, the
e address subfield <bcp14>MUST</bcp14> contain an IPv6 address (a /128 IPv6 pre
address sub-field MUST contain an IPv6 address (a /128 IPv6 prefix). fix).
In this case, the length field of Remote Endpoint sub-TLV MUST In this case, the Length field of the Tunnel Egress Endpoint Sub-TLV <bcp14>M
contain the value 18 (0x12). IPv6 link local addresses are not valid UST</bcp14>
contain the value 18 (0x12). IPv6 link-local addresses are not valid
values of the IP address field.</t> values of the IP address field.</t>
</section> </section>
<section anchor="ColorTLV" numbered="true" toc="default">
<section anchor="ColorTLV" title="Color Sub-TLV"> <name>Color Sub-TLV</name>
<t>This Sub-TLV type is 4. It may appear zero or more time in a given Tu <t>This sub-TLV type is 4. It may appear zero or more times in a given
nnel Sub-TLV. The value field is a 4-octet opaque unsigned Tunnel Sub-TLV. The Value field is a 4-octet opaque unsigned
integer.</t> integer.</t>
<t>The color value is user-defined and configured locally on the <t>The color value is user-defined and configured locally on the
advertising routers. It may be used by service providers to define advertising routers. It may be used by service providers to define
policies on the tunnel encapsulator routers, for example, to control the policies on the tunnel encapsulator routers, for example, to control the
selection of the tunnel to use.</t> selection of the tunnel to use.</t>
<t>This color value can be referenced by BGP routes carrying the Color
<t>This color value can be referenced by BGP routes carrying Color Extended Community <xref target="RFC9012" format="default"/>. If the
Extended Community <xref target="I-D.ietf-idr-tunnel-encaps"/>. If the tunnel is used to reach the BGP next hop of BGP routes, then attaching
tunnel is used to reach the BGP Next-Hop of BGP routes, then attaching a Color Extended Community to those routes expresses the
a Color Extended Community to those routes express the
willingness of the BGP speaker to use a tunnel of the same color.</t> willingness of the BGP speaker to use a tunnel of the same color.</t>
</section> </section>
<section anchor="Load-Balancing" numbered="true" toc="default">
<section anchor="Load-Balancing" title="Load-Balancing Block Sub-TLV"> <name>Load-Balancing Block Sub-TLV</name>
<t>This Sub-TLV type is 5. The syntax, semantic, and usage of its value <t>This sub-TLV type is 5. The syntax, semantics, and usage of its
field are defined in <xref target="RFC5640"/>.</t> Value field are defined in <xref target="RFC5640"
format="default"/>.</t>
</section> </section>
<section anchor="IP.QoS" numbered="true" toc="default">
<section anchor="IP.QoS" title="IP QoS Field"> <name>DS Field Sub-TLV</name>
<t>This Sub-TLV type is 6. The syntax, semantic, and usage of its value <t>This sub-TLV type is 6. The syntax, semantics, and usage of its
field are defined in Section 3.3.1 "IPv4 DS Field" Value field are defined in Section <xref
of <xref target="I-D.ietf-idr-tunnel-encaps"/>.</t> target="RFC9012" sectionFormat="bare"
section="3.3.1">"DS Field"</xref>
of <xref target="RFC9012" format="default"/>.</t>
</section> </section>
<section anchor="UDP" numbered="true" toc="default">
<section anchor="UDP" title="UDP Destination Port"> <name>UDP Destination Port Sub-TLV</name>
<t>This Sub-TLV type is 7. The syntax, semantic, and usage of its value <t>This sub-TLV type is 7. The syntax, semantics, and usage of its
field are defined in Section 3.3.2 "UDP Destination Value field are defined in Section <xref
Port" of <xref target="I-D.ietf-idr-tunnel-encaps"/>.</t> target="RFC9012" sectionFormat="bare"
section="3.3.2">"UDP Destination Port"</xref> of <xref
target="RFC9012" format="default"/>.</t>
</section> </section>
</section> </section>
<section anchor="Operation" numbered="true" toc="default">
<section anchor="Operation" title="Operation"> <name>Operation</name>
<t>The advertisement of a Tunnel Encapsulations Sub-TLV indicates that the <t>The advertisement of a Tunnel Encapsulations Sub-TLV indicates that the
advertising router advertising router
supports a particular tunnel decapsulation along with the parameters to supports a particular tunnel decapsulation along with the parameters to
be used for the tunnel. The decision to use that tunnel is driven by the be used for the tunnel. The decision to use that tunnel is driven by the
capability of the tunnel encapsulator router to support the encapsulation type and capability of the tunnel encapsulator router to support the encapsulation type and
the policy on the tunnel encapsulator router. The Color Sub-TLV (See <xref the policy on the tunnel encapsulator router. The Color Sub-TLV (see <xref
target="ColorTLV"/>) may be used as an input to this policy. Note that target="ColorTLV" format="default"/>) may be used as an input to this policy. N
ote that
some tunnel types may require the execution of an explicit tunnel setup some tunnel types may require the execution of an explicit tunnel setup
protocol before they can be used to transit data.</t> protocol before they can be used to transit data.</t>
<t> A tunnel MUST NOT be <t> A tunnel <bcp14>MUST NOT</bcp14> be
used if there is no route toward the IP address specified in the used if there is no route toward the IP address specified in the
Endpoint Sub-TLV (See <xref target="EndpointTLV"/>) or if the route is Tunnel Egress Endpoint Sub-TLV (see <xref target="EndpointTLV" format="def ault"/>) or if the route is
not advertised in the same OSPF domain.</t> not advertised in the same OSPF domain.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<section anchor="IANA.RI" numbered="true" toc="default">
<name>OSPF Router Information (RI) TLVs Registry</name>
<t>IANA has allocated the following new code point in the
"OSPF Router Information (RI) TLVs" registry.
<section anchor="IANA" title="IANA Considerations"> </t>
<section anchor="IANA.RI" title="OSPF Router Information">
<t>This document requests IANA to allocate a new code point from the
OSPF Router Information (RI) registry.
<figure anchor="Tunnel_Encapsulation_RI" title="Tunnel Encapsulation Rou <table anchor="encaps-router">
ter Information"> <name>Addition to OSPF Router Information (RI) TLVs Registry</name>
<artwork><![CDATA[ <thead>
Value TLV Name Reference <tr>
----- ---------------------- ------------- <th>Value</th>
TBD1 Tunnel Encapsulations This document]]></artwork> <th>TLV Name</th>
</figure> <th>Reference</th>
</t> </tr>
</thead>
<tbody>
<tr>
<td>13</td>
<td>Tunnel Encapsulations</td>
<td>RFC 9013</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="ParameterRegistry" numbered="true" toc="default">
<name>OSPF Tunnel Parameter Sub-TLVs Registry</name>
<t>IANA has created a new subregistry called the "OSPF Tunnel
Parameter Sub-TLVs" registry under the "Open Shortest Path
First (OSPF) Parameters" registry. The registration procedures are as fol
lows:</t>
<section anchor="ParameterRegistry" title="Tunnel Parameter Sub-TLVs Regis <ul spacing="normal">
try"> <li>The values in the range 1-34999 are to be allocated using the
"Standards Action" registration procedure defined in <xref target="R
<t>This document requests IANA to create, under "Open Shortest Path Firs FC8126" format="default"/>.</li>
t (OSPF) Parameters", a new registry "OSPF Tunnel <li>The values in the range 35000-65499 are to be allocated using the
Parameter Sub-TLVs" with the following registration procedure:<list> "First Come First Served" registration procedure.</li>
<t>The values in the range 1-34999 are to be allocated using the </ul>
"Standards Action" registration procedure as defined in <xref
target="RFC8126"/>.</t>
<t>The values in the range 35000-65499 are to be allocated using the <t>The initial contents of the registry are as follows:</t>
"First Come, First Served" registration procedure.</t> <table anchor="sub-TLV-reg">
</list></t> <name>Initial Contents of OSPF Tunnel Parameter Sub-TLVs Registry</name>
<thead>
<tr>
<th>Value</th>
<th>TLV Name</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>Reserved</td>
<td>RFC 9013</td>
</tr>
<tr>
<td>1</td>
<td>Encapsulation</td>
<td>RFC 9013 &amp; RFC 9012</td>
</tr>
<tr>
<td>2</td>
<td>Protocol Type</td>
<td>RFC 9013 &amp; RFC 9012</td>
</tr>
<tr>
<td>3</td>
<td>Endpoint</td>
<td>RFC 9013</td>
</tr>
<tr>
<td>4</td>
<td>Color</td>
<td>RFC 9013</td>
</tr>
<tr>
<td>5</td>
<td>Load-Balancing Block</td>
<td>RFC 9013 &amp; RFC 5640</td>
</tr>
<tr>
<td>6</td>
<td>DS Field</td>
<td>RFC 9013 &amp; RFC 9012</td>
</tr>
<tr>
<td>7</td>
<td>UDP Destination Port</td>
<td>RFC 9013 &amp; RFC 9012</td>
</tr>
<tr>
<td>8-65499</td>
<td>Unassigned</td>
<td></td>
</tr>
<tr>
<td>65500-65534</td>
<td>Experimental</td>
<td>RFC 9013</td>
</tr>
<tr>
<td>65535</td>
<td>Reserved</td>
<td>RFC 9013</td>
</tr>
<figure anchor="OSPF_Tunnel_Parameter_Registry" title="OSPF Tunnel Param </tbody>
eter Sub-TLVs Registry"> </table>
<artwork><![CDATA[ Registry Name: OSPF Tunnel Parameter Sub-TLVs
Value Name Reference
0 Reserved This document
1 Encapsulation This document
& [I-D.ietf-idr-tunnel-encaps]
2 Protocol Type This document
& [I-D.ietf-idr-tunnel-encaps]
3 Endpoint This document
4 Color This document
5 Load-Balancing Block This document & [RFC5640]
6 IP QoS This document
& [I-D.ietf-idr-tunnel-encaps]
7 UDP Destination Port This document
& [I-D.ietf-idr-tunnel-encaps]
8-65499 Unassigned
65500-65534 Experimental This document
65535 Reserved This document]]></artwork>
</figure>
</section> </section>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>Security considerations applicable to softwires can be found in the <t>Security considerations applicable to softwires can be found in the
mesh framework <xref target="RFC5565"/>. In general, security issues of mesh framework <xref target="RFC5565" format="default"/>. In general, secu rity issues of
the tunnel protocols signaled through this OSPF capability extension are the tunnel protocols signaled through this OSPF capability extension are
inherited.</t> inherited.</t>
<t>If a third party is able to modify any of the information that is
<t>If a third-party is able to modify any of the information that is used to form encapsulation headers, choose a tunnel type, or
used to form encapsulation headers, to choose a tunnel type, or to
choose a particular tunnel for a particular payload type, user data choose a particular tunnel for a particular payload type, user data
packets may end up getting misrouted, mis-delivered, and/or dropped. packets may end up getting misrouted, misdelivered, and/or dropped.
However, since an OSPF routing domain is usually a well-controlled network However, since an OSPF routing domain is usually a well-controlled network
under a single administrative domain, the possibility of the above attack is very low.</t> under a single administrative domain, the possibility of the above attack is very low.</t>
<t>We note that the last paragraph of <xref target="Operation"
<t>We note that the last paragraph of <xref target="Operation"/> forbid th format="default"/> forbids the establishment of a tunnel toward
e establishment of a tunnel toward arbitrary destinations. It prohibits a destin arbitrary destinations. It prohibits a destination outside of the OSPF
ation outside of the OSPF domain. This avoid that a third-party gaining access t domain. This prevents a third
o an OSPF router be able to send the traffic to other destinations, e.g., for in party that has gained access to an OSPF router from being able to send
spection purposes.</t> the traffic to other destinations, e.g., for inspection purposes.</t>
<t>Security considerations for the base OSPF protocol are covered in <t>Security considerations for the base OSPF protocol are covered in
<xref target="RFC2328"/> and <xref target="RFC5340"/>.</t> <xref target="RFC2328" format="default"/> and <xref target="RFC5340" forma
</section> t="default"/>.</t>
<section title="Contributors">
<t><figure>
<artwork><![CDATA[Uma Chunduri
Huawei
Email: uma.chunduri@gmail.com
]]></artwork>
</figure></t>
</section> </section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>This document is partially inspired by <xref target="RFC5512"/>.</t>
<t>The authors would like to thank Greg Mirsky, John E Drake, Carlos
Pignataro and Karsten Thomann for their valuable comments on this
document. Special thanks should be given to Acee Lindem for his multiple
detailed reviews of this document and help. The authors would like to
thank Pete Resnick, Joe Touch, David Mandelberg, Sabrina Tanamal, Tim
Wicinski, Amanda Baber for their Last Call reviews and thank Spencer
Dawkins, Mirja Kuehlewind, Ben Campbell, Benoit Claise, Alvaro
Retana, Adam Roach and Suresh Krishnan for their AD reviews.</t>
<!---->
</section>
</middle> </middle>
<back> <back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.7770"?> <references>
<name>References</name>
<?rfc include="reference.RFC.8126"?> <references>
<name>Normative References</name>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.x
ml"/>
<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.7770.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8126.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5640.xml"/>
<?rfc include="reference.RFC.5640"?> <!-- draft-ietf-idr-tunnel-encaps-15 (RFC 9012) -->
<reference anchor="RFC9012" target="https://www.rfc-editor.org/info/rfc9012">
<front>
<title>The BGP Tunnel Encapsulation Attribute</title>
<author initials='K' surname='Patel' >
<organization/>
</author>
<author initials='G' surname='Van de Velde' >
<organization/>
</author>
<author initials='S' surname='Sangli' >
<organization/>
</author>
<author initials='J' surname='Scudder' >
<organization/>
</author>
<date month='April' year='2021'/>
</front>
<seriesInfo name="RFC" value="9012"/>
<seriesInfo name="DOI" value="10.17487/RFC9012"/>
</reference>
<?rfc include="reference.I-D.ietf-idr-tunnel-encaps"?> </references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2328.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5340.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.5565.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7490.xml"/>
</references>
</references> </references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>This document is partially inspired by <xref target="RFC5512"
format="default"/>.</t>
<t>The authors would like to thank <contact fullname="Greg Mirsky"/>,
<contact fullname="John E. Drake"/>, <contact fullname="Carlos
Pignataro"/>, and <contact fullname="Karsten Thomann"/> for their
valuable comments on this
document. Special thanks should be given to <contact fullname="Acee
Lindem"/> for his multiple
detailed reviews of this document and help. The authors would like to
thank <contact fullname="Pete Resnick"/>, <contact fullname="Joe
Touch"/>, <contact fullname="David Mandelberg"/>, <contact
fullname="Sabrina Tanamal"/>, <contact fullname="Tim Wicinski"/>, and
<contact fullname="Amanda Baber"/> for their Last Call reviews. The author
s also thank
<contact fullname="Spencer Dawkins"/>, <contact fullname="Mirja
Kühlewind"/>, <contact fullname="Ben Campbell"/>, <contact
fullname="Benoit Claise"/>, <contact fullname="Alvaro Retana"/>,
<contact fullname="Adam Roach"/>, and <contact fullname="Suresh
Krishnan"/> for their AD reviews.</t>
<references title="Informative References"> </section>
<?rfc include="reference.RFC.2328"?>
<?rfc include="reference.RFC.5340"?> <section numbered="false" toc="default">
<name>Contributors</name>
<?rfc include="reference.RFC.5512"?> <contact fullname="Uma Chunduri">
<organization>Huawei</organization>
<address>
<email>uma.chunduri@gmail.com</email>
</address>
</contact>
<?rfc include="reference.RFC.5565"?> </section>
<?rfc include="reference.RFC.7490"?>
</references>
</back> </back>
</rfc> </rfc>
 End of changes. 87 change blocks. 
333 lines changed or deleted 427 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/