rfc9305xml2.original.xml   rfc9305.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc, <!DOCTYPE rfc [
which is available here: http://xml.resource.org. --> <!ENTITY nbsp "&#160;">
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!ENTITY zwsp "&#8203;">
<!ENTITY ieee_802_1Q SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml6/r <!ENTITY nbhy "&#8209;">
eference.IEEE.802.1Q_2014.xml"> <!ENTITY wj "&#8288;">
]> ]>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-lisp-gpe-19" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902
,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-lisp-gpe-19" number="9305" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" tocDepth="4" sym Refs="true" sortRefs="true" version="3">
<front> <front>
<!-- The abbreviated title is used in the page header - it is only necessary <title abbrev="LISP-GPE">Locator/ID Separation Protocol (LISP) Generic Proto
if the col Extension</title>
full title is longer than 39 characters --> <seriesInfo name="RFC" value="9305"/>
<title>LISP Generic Protocol Extension</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Fabio Maino" initials="F." role="editor" surname="Maino"> <author fullname="Fabio Maino" initials="F." role="editor" surname="Maino">
<organization abbrev="Cisco">Cisco Systems</organization> <organization abbrev="Cisco">Cisco Systems</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<!-- Reorder these if your country does things differently -->
<city>San Jose</city> <city>San Jose</city>
<region>CA</region> <region>CA</region>
<code></code>
<code>95134</code> <country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>fmaino@cisco.com</email> <email>fmaino@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Jennifer Lemon" initials="J." surname="Lemon"> <author fullname="Jennifer Lemon" initials="J." surname="Lemon">
<organization>Broadcom</organization> <organization/>
<address> <address>
<postal> <email>jalemon@meus.us</email>
<street>270 Innovation Drive</street>
<!-- Reorder these if your country does things differently -->
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>jennifer.lemon@broadcom.com</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Puneet Agarwal" initials="P." surname="Agarwal"> <author fullname="Puneet Agarwal" initials="P." surname="Agarwal">
<organization>Innovium</organization> <organization>Innovium</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<!-- Reorder these if your country does things differently -->
<city/> <city/>
<region/> <region/>
<code/> <code/>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>puneet@acm.org</email> <email>puneet@acm.org</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Darrel Lewis" initials="D." surname="Lewis"> <author fullname="Darrel Lewis" initials="D." surname="Lewis">
<organization abbrev="Cisco">Cisco Systems</organization> <organization abbrev="Cisco">Cisco Systems</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<!-- Reorder these if your country does things differently -->
<city>San Jose</city> <city>San Jose</city>
<region>CA</region> <region>CA</region>
<country>United States of America</country>
<code>95134</code>
<country>USA</country>
</postal> </postal>
<email>darlewis@cisco.com</email> <email>darlewis@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Michael Smith" initials="M." surname="Smith"> <author fullname="Michael Smith" initials="M." surname="Smith">
<organization abbrev="Cisco">Cisco Systems</organization> <organization abbrev="Cisco">Cisco Systems</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<!-- Reorder these if your country does things differently -->
<city>San Jose</city> <city>San Jose</city>
<region>CA</region> <region>CA</region>
<code>95134</code> <code>95134</code>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>michsmit@cisco.com</email> <email>michsmit@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<date month="October" year="2022"/>
<date day="26" month="July" year="2020"/> <area>Routing</area>
<workgroup>lisp</workgroup>
<!-- If the month and year are both specified and are the current ones, xml2
rfc will fill
in the current day for you. If only the current year is specified, xml2r
fc will fill
in the current day and month for you. If the year is not the current one
, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not sp
ecified for the
purpose of calculating the expiry date). With drafts it is normally suf
ficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>security</keyword> <keyword>security</keyword>
<keyword>policy</keyword> <keyword>policy</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract> <abstract>
<t>This document describes extensions to the Locator/ID Separation <t>This document describes extensions to the Locator/ID Separation
Protocol (LISP) Data-Plane, via changes to the LISP header, to support Protocol (LISP) data plane, via changes to the LISP header, to support
multi-protocol encapsulation and allow to introduce new protocol multiprotocol encapsulation and allow the introduction of new protocol
capabilities.</t> capabilities.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="Introduction" title="Introduction"> <section anchor="Introduction" numbered="true" toc="default">
<t>The LISP Data-Plane is defined in <xref <name>Introduction</name>
target="I-D.ietf-lisp-rfc6830bis"/>. It specifies an encapsulation <t>The LISP data plane is defined in <xref target="RFC9300" format="defaul
t"/>.
It specifies an encapsulation
format that carries IPv4 or IPv6 packets (henceforth jointly referred to format that carries IPv4 or IPv6 packets (henceforth jointly referred to
as IP) in a LISP header and outer UDP/IP transport.</t> as IP) in a LISP header and outer UDP/IP transport.</t>
<t>The LISP data plane header does not specify the protocol being
<t>The LISP Data-Plane header does not specify the protocol being encapsulated and, therefore, is currently limited to encapsulating only IP
encapsulated and therefore is currently limited to encapsulating only IP packet payloads. Other protocols, most notably the Virtual eXtensible Loca
packet payloads. Other protocols, most notably Virtual eXtensible Local l
Area Network (VXLAN) <xref target="RFC7348"/> (which defines a similar Area Network (VXLAN) protocol <xref target="RFC7348" format="default"/> (w
header format to LISP), are used to encapsulate Layer-2 (L2) protocols hich defines a header format similar to LISP), are used to encapsulate Layer 2 (
L2) protocols,
such as Ethernet.</t> such as Ethernet.</t>
<t>This document defines an extension for the LISP header, as defined in <t>This document defines an extension for the LISP header, as defined in
<xref target="I-D.ietf-lisp-rfc6830bis"/>, to indicate the inner <xref target="RFC9300" format="default"/>, to indicate the inner
protocol, enabling the encapsulation of Ethernet, IP or any other protocol, enabling the encapsulation of Ethernet, IP, or any other
desired protocol all the while ensuring compatibility with existing LISP desired protocol, all the while ensuring compatibility with existing LISP
deployments.</t> deployments.</t>
<t>A flag in the LISP header -- the P-bit -- is used to signal the
<t>A flag in the LISP header, called the P-bit, is used to signal the presence of the 8-bit 'Next Protocol' field. The 'Next Protocol' field, wh
presence of the 8-bit Next Protocol field. The Next Protocol field, when en
present, uses 8 bits of the field that was allocated to the echo-noncing present, uses 8 bits of the field that was allocated to the Echo-Noncing
and map-versioning features in <xref and Map-Versioning features in <xref target="RFC9300" format="default"/>.
target="I-D.ietf-lisp-rfc6830bis"/>. Those two features are no longer Those two features are no longer
available when the P-bit is used. However, appropriate LISP-GPE (LISP available when the P-bit is used. However, appropriate LISP
Generic Protocol Extension) shim headers can be defined to specify Generic Protocol Extension (LISP-GPE) shim headers can be defined to speci
capabilities that are equivalent to echo-noncing and/or fy
map-versioning.</t> capabilities that are equivalent to Echo-Noncing and/or
Map-Versioning.</t>
<t>Since all of the reserved bits of the LISP Data-Plane header have <t>Since all of the reserved bits of the LISP data plane header have
been allocated, LISP-GPE can also be used to extend the LISP Data-Plane been allocated, LISP-GPE can also be used to extend the LISP data plane
header by defining Next Protocol "shim" headers that implements new data header by defining Next Protocol shim headers that implement new
plane functions not supported in the LISP header. For example, the use data plane functions not supported in the LISP header. For example, the us
of the Group-Based Policy (GBP) header <xref e
target="I-D.lemon-vxlan-lisp-gpe-gbp"/> or of the In-situ Operations, of the Group-Based Policy (GBP) header <xref target="VXLAN-LISP" format="d
Administration, and Maintenance (IOAM) header <xref efault"/> or of the In situ Operations,
target="I-D.brockners-ippm-ioam-vxlan-gpe"/> with LISP-GPE, can be Administration, and Maintenance (IOAM) header <xref target="VXLAN-GPE" for
considered an extension to add support in the Data-Plane for Group-Based mat="default"/> with LISP-GPE can be
Policy functionalities or IOAM metadata.</t> considered an extension to add support in the data plane for GBP functiona
lities or IOAM metadata.</t>
<section anchor="Conventions" title="Conventions"> <section anchor="Conventions" numbered="true" toc="default">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <name>Conventions</name>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp
"OPTIONAL" in this document are to be interpreted as described in BCP 14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDE
D</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and
"<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as desc
ribed in BCP
14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" form
at="default"/> when, and only
when, they appear in all capitals, as shown here.</t> when, they appear in all capitals, as shown here.</t>
</section> </section>
<section anchor="Abbreviations" numbered="true" toc="default">
<section anchor="Abbreviations" title="Definition of Terms"> <name>Definitions of Terms</name>
<t>This document uses terms already defined in <xref <t>This document uses terms already defined in <xref target="RFC9300" fo
target="I-D.ietf-lisp-rfc6830bis"/>.</t> rmat="default"/>.</t>
</section> </section>
</section> </section>
<section anchor="LISP_header" numbered="true" toc="default">
<section anchor="LISP_header" <name>LISP Header without Protocol Extensions</name>
title="LISP Header Without Protocol Extensions"> <t>As described in <xref target="Introduction" format="default"/>, the LIS
<t>As described in <xref target="Introduction"/>, the LISP header has no P header has no
protocol identifier that indicates the type of payload being carried. protocol identifier that indicates the type of payload being carried.
Because of this, LISP is limited to carrying IP payloads.</t> Because of this, LISP is limited to carrying IP payloads.</t>
<t>The LISP header <xref target="RFC9300" format="default"/> contains a
<t>The LISP header <xref target="I-D.ietf-lisp-rfc6830bis"/> contains a series of flags (some defined, some reserved), a 'Nonce/Map-Version' field
series of flags (some defined, some reserved), a Nonce/Map-version field ,
and an instance ID/Locator-status-bit field. The flags provide and an 'Instance ID/Locator-Status-Bits' field. The flags provide
flexibility to define how the various fields are encoded. Notably, Flag flexibility to define how the various fields are encoded. Notably, Flag
bit 5 is the last reserved bit in the LISP header.</t> bit 5 is the last reserved bit in the LISP header.</t>
<figure anchor="LISP_Header">
<figure align="left" anchor="LISP_Header" title="LISP Header"> <name>LISP Header</name>
<artwork align="left"><![CDATA[ <artwork align="left" name="" type="" 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|R|K|K| Nonce/Map-Version |
|N|L|E|V|I|R|K|K| Nonce/Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID/Locator-Status-Bits |
| Instance ID/Locator-Status-Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>
]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="LISP_GPE" numbered="true" toc="default">
<section anchor="LISP_GPE" <name>LISP Generic Protocol Extension (LISP-GPE)</name>
title="Generic Protocol Extension for LISP (LISP-GPE)">
<t>This document defines two changes to the LISP header in order to <t>This document defines two changes to the LISP header in order to
support multi-protocol encapsulation: the introduction of the P-bit and support multiprotocol encapsulation: the introduction of the P-bit and
the definition of a Next Protocol field. This document specifies the the definition of a 'Next Protocol' field. This document specifies the
protocol behavior when the P-bit is set to 1, no changes are introduced protocol behavior when the P-bit is set to 1; no changes are introduced
when the P-bit is set to 0. The LISP-GPE header is shown in <xref when the P-bit is set to 0. The LISP-GPE header is shown in <xref target="
target="GPE_Header"> </xref> and described below.</t> GPE_Header" format="default"> </xref> and described below.</t>
<figure anchor="GPE_Header">
<figure align="left" anchor="GPE_Header" title="LISP-GPE Header"> <name>LISP-GPE Header</name>
<artwork align="left"><![CDATA[ <artwork align="left" name="" type="" 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|P|K|K| Nonce/Map-Version/Next Protocol |
|N|L|E|V|I|P|K|K| Nonce/Map-Version/Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID/Locator-Status-Bits |
| Instance ID/Locator-Status-Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>
]]></artwork>
</figure> </figure>
<t/> <dl newline="false" spacing="normal">
<dt>P-Bit:</dt>
<t><list style="hanging"> <dd>Flag bit 5 is defined as the Next Protocol bit.
<t hangText="P-Bit:">Flag bit 5 is defined as the Next Protocol bit. The P-bit is set to 1 to indicate the presence of the 8-bit 'Next
The P-bit is set to 1 to indicate the presence of the 8 bit Next Protocol' field.</dd>
Protocol field.</t> </dl>
<t>If the P-bit is clear (0), the LISP header is
<t hangText="">If the P-bit is clear (0) the LISP header is bit-by-bit equivalent to the definition in <xref target="RFC9300" form
bit-by-bit equivalent to the definition in <xref at="default"/>.</t>
target="I-D.ietf-lisp-rfc6830bis"/>.</t> <t>When the P-bit is set to 1, bits N, E, and V, and bits 8-23 of the
'Nonce/Map-Version/Next Protocol' field <bcp14>MUST</bcp14> be set to
<t>When the P-bit is set to 1, bits N, E, V, and bits 8-23 of the zero on
'Nonce/Map-Version/Next Protocol' field MUST be set to zero on transmission and <bcp14>MUST</bcp14> be ignored on receipt. Features e
transmission and MUST be ignored on receipt. Features equivalent to quivalent to
those that were implemented with bits N,E and V in <xref those that were implemented with bits N, E, and V in <xref
target="I-D.ietf-lisp-rfc6830bis"/>, such as echo-noncing and target="RFC9300" format="default"/>, such as Echo-Noncing and
map-versioning, can be implemented by defining appropriate LISP-GPE Map-Versioning, can be implemented by defining appropriate LISP-GPE
shim headers.</t> shim headers.</t>
<t>When the P-bit is set to 1, the LISP-GPE header is encoded
<t>When the P-bit is set to 1, the LISP-GPE header is encoded
as:</t> as:</t>
<t><figure align="left" anchor="GPE_Header_Next_Protocol" <figure anchor="GPE_Header_Next_Protocol">
title="LISP-GPE with P-bit set to 1"> <name>LISP-GPE with P-bit Set to 1</name>
<artwork align="left"><![CDATA[ <artwork align="left" name="" type="" alt=""><![CDATA[
0 x 0 0 x 1 x x
0 x 0 0 x 1 x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|P|K|K| 0x0000 | Next Protocol |
|N|L|E|V|I|P|K|K| 0x0000 | Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID/Locator-Status-Bits |
| Instance ID/Locator-Status-Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>
</figure>
]]></artwork>
</figure></t>
<t hangText="Next Protocol:">When the P-bit is set to 1, the lower 8 <dl newline="false" spacing="normal">
<dt>Next Protocol:</dt>
<dd>When the P-bit is set to 1, the lower 8
bits of the first 32-bit word are used to carry a Next Protocol. bits of the first 32-bit word are used to carry a Next Protocol.
This Next Protocol field contains the protocol of the encapsulated This 'Next Protocol' field contains the protocol of the encapsulated
payload packet.</t> payload packet.</dd>
</dl>
<t>This document defines the following Next Protocol values:</t>
<t><list style="hanging">
<t hangText="0x00 :">Reserved</t>
<t hangText="0x01 :">IPv4</t>
<t hangText="0x02 :">IPv6</t>
<t hangText="0x03 :">Ethernet</t>
<t hangText="0x04 :">Network Service Header (NSH) <xref
target="RFC8300"/></t>
<t hangText="0x05 to 0x7D:">Unassigned</t>
<t hangText="0x7E, 0x7F:">Experimentation and testing</t>
<t hangText="0x80 to 0xFD:">Unassigned (shim headers)</t>
<t hangText="0xFE, 0xFF:">Experimentation and testing (shim
headers)</t>
</list></t>
<t hangText="">The values are tracked in the IANA LISP-GPE Next
Protocol Registry as described in <xref
target="Next_protocol"/>.</t>
</list></t>
<t>Next protocol values 0x7E, 0x7F and 0xFE, 0xFF are assigned for <t>This document defines the following Next Protocol values:</t>
experimentation and testing as per <xref target="RFC3692"/>.</t> <dl newline="false" spacing="normal">
<dt>0x00:</dt>
<dd>Reserved</dd>
<dt>0x01:</dt>
<dd>IPv4</dd>
<dt>0x02:</dt>
<dd>IPv6</dd>
<dt>0x03:</dt>
<dd>Ethernet</dd>
<dt>0x04:</dt>
<dd>Network Service Header (NSH) <xref target="RFC8300" format="defa
ult"/></dd>
<dt>0x05 to 0x7D:</dt>
<dd>Unassigned</dd>
<dt>0x7E and 0x7F:</dt>
<dd>Experimentation and testing</dd>
<dt>0x80 to 0xFD:</dt>
<dd>Unassigned (shim headers)</dd>
<dt>0xFE, 0xFF:</dt>
<dd>Experimentation and testing (shim
headers)</dd>
</dl>
<t>Next protocol values from Ox80 to 0xFD are assigned to protocols <t>The values are tracked in the IANA "LISP-GPE Next
encoded as generic "shim" headers. All shim protocols MUST use the Protocol" registry, as described in <xref target="Next_protocol" format=
header structure in <xref target="shim"/>, which includes a Next "default"/>.</t>
Protocol field. When shim headers are used with other protocols
identified by next protocol values from 0x00 to 0x7F, all the shim
headers MUST come first.</t>
<t>Next Protocol values 0x7E, 0x7F, 0xFE, and 0xFF are assigned for
experimentation and testing, as per <xref target="RFC3692" format="default
"/>.</t>
<t>Next Protocol values from 0x80 to 0xFD are assigned to protocols
encoded as generic shim headers. All shim protocols <bcp14>MUST</bcp14> us
e the
header structure in <xref target="shim" format="default"/>, which includes
a 'Next
Protocol' field. When shim headers are used with other protocols
identified by Next Protocol values from 0x00 to 0x7F, all the shim
headers <bcp14>MUST</bcp14> come first.</t>
<t>Shim headers can be used to incrementally deploy new GPE features, <t>Shim headers can be used to incrementally deploy new GPE features,
keeping the processing of shim headers known to a given xTR keeping the processing of shim headers known to a given Tunnel Router (xTR
implementation in the 'fast' path (typically an ASIC), while punting the )
implementation in the 'fast' path (typically an Application-Specific Integ
rated
Circuit (ASIC)) while punting the
processing of the remaining new GPE features to the 'slow' path.</t> processing of the remaining new GPE features to the 'slow' path.</t>
<t>Shim protocols <bcp14>MUST</bcp14> have the first 32 bits defined as:</
<t>Shim protocols MUST have the first 32 bits defined as:</t> t>
<t keepWithNext="true"/>
<t><figure anchor="shim" title="Shim Header"> <figure anchor="shim">
<preamble/> <name>Shim Header</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[ 0 1 2 0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Next Protocol | | Type | Length | Reserved | Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Protocol Specific Fields ~ ~ Protocol-Specific Fields ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure>
<postamble/> <t keepWithPrevious="true"/>
</figure></t>
<t>Where:</t> <t>Where:</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>Type:</dt>
<t hangText="Type:">This field identifies the different messages of <dd>This field identifies the different messages of
this protocol.</t> this protocol.</dd>
<dt>Length:</dt>
<t hangText="Length:">The length, in 4-octet units, of this protocol <dd>This field indicates the length, in 4-octet units, of this protocol
message not including the first 4 octets.</t> message, not including the first 4 octets.</dd>
<dt>Reserved:</dt>
<t hangText="Reserved:">The use of this field is reserved to the <dd>The use of this field is reserved to the
protocol defined in this message.</t> protocol defined in this message.</dd>
<dt>Next Protocol:</dt>
<t hangText="Next Protocol Field:">The next protocol field contains <dd>This field contains
the protocol of the encapsulated payload. The values are tracked in the protocol of the encapsulated payload. The values are tracked in
the IANA LISP-GPE Next Protocol Registry as described in <xref the IANA "LISP-GPE Next Protocol" registry, as described in <xref
target="Next_protocol"/>.</t> target="Next_protocol" format="default"/>.</dd>
</list></t> </dl>
</section> </section>
<section anchor="Deployments" numbered="true" toc="default">
<section anchor="Deployments" <name>Implementation and Deployment Considerations</name>
title="Implementation and Deployment Considerations"> <section anchor="Applicability" numbered="true" toc="default">
<section anchor="Applicability" title="Applicability Statement"> <name>Applicability Statement</name>
<t>LISP-GPE conforms, as an UDP-based encapsulation protocol, to the <t>LISP-GPE conforms, as a UDP-based encapsulation protocol, to the
UDP usage guidelines as specified in <xref target="RFC8085"/>. The UDP usage guidelines specified in <xref target="RFC8085" format="default
applicability of these guidelines are dependent on the underlay IP "/>. The
applicability of these guidelines is dependent on the underlay IP
network and the nature of the encapsulated payload.</t> network and the nature of the encapsulated payload.</t>
<t><xref target="RFC8085" format="default"/> outlines two applicability
<t><xref target="RFC8085"/> outlines two applicability scenarios for scenarios for
UDP applications, 1) general Internet and 2) controlled environment. UDP applications: 1) the general Internet and 2) a controlled environmen
The controlled environment means a single administrative domain or t.
A controlled environment means a single administrative domain or
adjacent set of cooperating domains. A network in a controlled adjacent set of cooperating domains. A network in a controlled
environment can be managed to operate under certain conditions whereas environment can be managed to operate under certain conditions, whereas,
in general Internet this cannot be done. Hence requirements for a in the general Internet, this cannot be done. Hence, requirements for a
tunnel protocol operating under a controlled environment can be less tunnel protocol operating under a controlled environment can be less
restrictive than the requirements of general internet.</t> restrictive than the requirements of the general Internet.</t>
<t>The LISP-GPE scope of applicability is the same set of use cases
<t>LISP-GPE scope of applicability is the same set of use cases covered by <xref target="RFC9300" format="default"/> for the LISP
covered by<xref target="I-D.ietf-lisp-rfc6830bis"/> for the LISP data plane protocol. The common property of these use cases is a large
dataplane protocol. The common property of these use cases is a large
set of cooperating entities seeking to communicate over the public set of cooperating entities seeking to communicate over the public
Internet or other large underlay IP infrastructures, while keeping the Internet or other large underlay IP infrastructures while keeping the
addressing and topology of the cooperating entities separate from the addressing and topology of the cooperating entities separate from the
underlay and Internet topology, routing, and addressing.</t> underlay and Internet topology, routing, and addressing.</t>
<t>LISP-GPE is meant to be deployed in network environments operated <t>LISP-GPE is meant to be deployed in network environments operated
by a single operator or adjacent set of cooperating network operators by a single operator or adjacent set of cooperating network operators
that fits with the definition of controlled environments in <xref that fit with the definition of controlled environments in <xref target=
target="RFC8085"/>.</t> "RFC8085" format="default"/>.</t>
<t>For the purpose of this document, a Traffic-Managed Controlled
<t>For the purpose of this document, a traffic-managed controlled Environment (TMCE), outlined in <xref target="RFC8086" format="default"/
environment (TMCE), outlined in <xref target="RFC8086"/>, is defined >, is defined
as an IP network that is traffic-engineered and/or otherwise managed as an IP network that is traffic-engineered and/or otherwise managed
(e.g., via use of traffic rate limiters) to avoid congestion. (e.g., via the use of traffic rate limiters) to avoid congestion.
Significant portions of text in this Section are based on <xref Significant portions of the text in this section are based on <xref targ
target="RFC8086"/>.</t> et="RFC8086" format="default"/>.</t>
<t>It is the responsibility of the network operators to ensure that <t>It is the responsibility of the network operators to ensure that
the guidelines/requirements in this section are followed as applicable the guidelines/requirements in this section are followed as applicable
to their LISP-GPE deployments</t> to their LISP-GPE deployments.</t>
</section> </section>
<section anchor="CongestionControl" numbered="true" toc="default">
<section anchor="CongestionControl" <name>Congestion-Control Functionality</name>
title="Congestion Control Functionality"> <t>LISP-GPE does not provide congestion-control functionality
<t>LISP-GPE does not natively provide congestion control functionality
and relies on the payload protocol traffic for congestion control. As and relies on the payload protocol traffic for congestion control. As
such LISP-GPE MUST be used with congestion controlled traffic or such, LISP-GPE <bcp14>MUST</bcp14> be used with congestion-controlled tr affic or
within a network that is traffic managed to avoid congestion (TMCE). within a network that is traffic managed to avoid congestion (TMCE).
An operator of a traffic managed network (TMCE) may avoid congestion An operator of a traffic-managed network (TMCE) may avoid congestion
by careful provisioning of their networks, rate-limiting of user data by careful provisioning of their networks, rate limiting of user data
traffic and traffic engineering according to path capacity.</t> traffic, and traffic engineering according to path capacity.</t>
<t>Keeping in mind the recommendation above, new encapsulated
<t>Keeping in mind the reccomendation above, new encapsulated payloads, when registered with LISP-GPE, <bcp14>MUST</bcp14> be accompan
payloads, when registered with LISP-GPE, MUST be accompained by a set ied by a set
of guidelines derived from <xref target="I-D.ietf-lisp-rfc6830bis"/>. of guidelines derived from <xref target="RFC9300" format="default" secti
onFormat="of" section="5"/>.
Such new protocols should be designed for explicit congestion signals Such new protocols should be designed for explicit congestion signals
to propagate consistently from lower layer protocols into IP. Then the to propagate consistently from lower-layer protocols into IP. Then, the
IP internetwork layer can act as a portability layer to carry IP internetwork layer can act as a portability layer to carry
congestion notification from non-IP-aware congested nodes up to the congestion notifications from non-IP-aware congested nodes up to the
transport layer (L4). By following the guidelines in <xref transport layer (L4). By following the guidelines in <xref target="I-D.i
target="I-D.ietf-tsvwg-ecn-encap-guidelines"/>, subnetwork designers etf-tsvwg-ecn-encap-guidelines" format="default"/>, subnetwork designers
can enable a layer-2 protocol to participate in congestion control can enable a Layer 2 protocol to participate in congestion control
without dropping packets via propagation of explicit congestion without dropping packets, via propagation of Explicit Congestion
notification (ECN <xref target="RFC3168"/> ) to receivers.</t> Notification (ECN) data <xref target="RFC3168" format="default"/> to rec
eivers.</t>
</section> </section>
<section anchor="UDPChecksum" numbered="true" toc="default">
<section anchor="UDPChecksum" title="UDP Checksum"> <name>UDP Checksum</name>
<t>For IP payloads, section 5.3 of <xref <t>For IP payloads, <xref target="RFC9300" section="5.3" sectionFormat="
target="I-D.ietf-lisp-rfc6830bis"/> specifies how to handle UDP of"/>
Checksums encouraging implementors to consider UDP checksum usage specifies how to handle UDP
guidelines in section 3.4 of <xref target="RFC8085"/> when it is checksums, encouraging implementors to consider UDP checksum usage
guidelines in <xref target="RFC8085" section="3.4" sectionFormat="of"/>
when it is
desirable to protect UDP and LISP headers against corruption.</t> desirable to protect UDP and LISP headers against corruption.</t>
<t>In order to protect the integrity of LISP-GPE headers, options, and
<t>In order to provide integrity of LISP-GPE headers, options and payloads (for example, to avoid misdelivery of payloads to different
payload, for example to avoid mis-delivery of payload to different tenant systems in the case of data corruption), the outer UDP checksum <
tenant systems in case of data corruption, outer UDP checksum SHOULD bcp14>SHOULD</bcp14>
be used with LISP-GPE when transported over IPv4. The UDP checksum be used with LISP-GPE when transported over IPv4. The UDP checksum
provides a statistical guarantee that a payload was not corrupted in provides a statistical guarantee that a payload was not corrupted in
transit. These integrity checks are not strong from a coding or transit. These integrity checks are not strong from a coding or
cryptographic perspective and are not designed to detect cryptographic perspective and are not designed to detect
physical-layer errors or malicious modification of the datagram (see physical-layer errors or malicious modifications of the datagram (see
Section 3.4 of <xref target="RFC8085"/>). In deployments where such a <xref target="RFC8085" section="3.4" sectionFormat="of"/>). In deploymen
risk exists, an operator SHOULD use additional data integrity ts where such a
mechanisms such as offered by IPSec.</t> risk exists, an operator <bcp14>SHOULD</bcp14> use additional data integ
rity
<t>An operator MAY choose to disable UDP checksum and use zero mechanisms, such as those offered by IPsec.</t>
<t>An operator <bcp14>MAY</bcp14> choose to disable a UDP checksum and u
se a zero
checksum if LISP-GPE packet integrity is provided by other data checksum if LISP-GPE packet integrity is provided by other data
integrity mechanisms such as IPsec or additional checksums or if one integrity mechanisms, such as IPsec or additional checksums, or if one
of the conditions in <xref target="IPv6Checksum"/> a, b, c are of the conditions in <xref target="IPv6Checksum" format="default"/> (a,
b, or c) is
met.</t> met.</t>
<section anchor="IPv6Checksum" numbered="true" toc="default">
<section anchor="IPv6Checksum" <name>UDP Zero Checksum Handling with IPv6</name>
title="UDP Zero Checksum Handling with IPv6"> <t>By default, a UDP checksum <bcp14>MUST</bcp14> be used when LISP-GP
<t>By default, UDP checksum MUST be used when LISP-GPE is E is
transported over IPv6. A tunnel endpoint MAY be configured for use transported over IPv6. A tunnel endpoint <bcp14>MAY</bcp14> be configu
with zero UDP checksum if additional requirements described in this red for use
with a zero UDP checksum if additional requirements described in this
section are met.</t> section are met.</t>
<t>When LISP-GPE is used over IPv6, a UDP checksum is used to protect
<t>When LISP-GPE is used over IPv6, UDP checksum is used to protect IPv6 headers, UDP headers, and LISP-GPE headers and payloads from
IPv6 headers, UDP headers and LISP-GPE headers and payload from potential data corruption. As such, by default, LISP-GPE <bcp14>MUST</
potential data corruption. As such by default LISP-GPE MUST use UDP bcp14> use a UDP
checksum when transported over IPv6. An operator MAY choose to checksum when transported over IPv6. An operator <bcp14>MAY</bcp14> ch
configure to operate with zero UDP checksum if operating in a oose to
traffic managed controlled environment as stated in <xref configure to operate with a zero UDP checksum if operating in a
target="Applicability"/> if one of the following conditions are traffic-managed controlled environment, as stated in <xref target="App
met:</t> licability"
format="default"/>, if one of the following conditions is met:</t>
<t><list style="letters"> <ol spacing="normal" type="a">
<t>It is known that the packet corruption is exceptionally <li>It is known that packet corruption is exceptionally
unlikely (perhaps based on knowledge of equipment types in their unlikely (perhaps based on an operator's knowledge of equipment ty
underlay network) and the operator is willing to take a risk of pes in their
undetected packet corruption</t> underlay network), and the operator is willing to take the risk of
undetected packet corruption.</li>
<t>It is judged through observational measurements (perhaps <li>It is determined through observational measurements
through historic or current traffic flows that use non zero (perhaps
checksum) that the level of packet corruption is tolerably low through historic or current traffic flows that use a non-zero
and where the operator is willing to take the risk of undetected checksum) that the level of packet corruption is tolerably low,
corruption</t> and the operator is willing to take the risk of undetected
corruption.</li>
<t>LISP-GPE payload is carrying applications that are tolerant <li>LISP-GPE payloads are carrying applications that are tolerant
of misdelivered or corrupted packets (perhaps through higher of misdelivered or corrupted packets (perhaps through higher-layer
layer checksum validation and/or reliability through checksum validation and/or reliability through retransmission).</li
retransmission)</t> >
</list>In addition LISP-GPE tunnel implementations using Zero UDP </ol>
checksum MUST meet the following requirements:</t> <t>In addition, LISP-GPE tunnel implementations using a zero UDP
checksum <bcp14>MUST</bcp14> meet the following requirements:</t>
<t><list style="numbers"> <ol spacing="normal" type="1">
<t>Use of UDP checksum over IPv6 MUST be the default <li>Use of a UDP checksum over IPv6 <bcp14>MUST</bcp14> be the defaul
configuration for all LISP-GPE tunnels</t> t
configuration for all LISP-GPE tunnels.</li>
<t>If LISP-GPE is used with zero UDP checksum over IPv6 then <li>If LISP-GPE is used with a zero UDP checksum over IPv6, then
such xTR implementation MUST meet all the requirements specified such xTR implementations <bcp14>MUST</bcp14> meet all the requirem
in section 4 of <xref target="RFC6936"/> and requirements 1 as ents specified
specified in section 5 of <xref target="RFC6936"/></t> in <xref target="RFC6936" section="4" sectionFormat="of"/> and req
uirement 1
<t>The ETR that decapsulates the packet SHOULD check the source specified in <xref target="RFC6936" section="5" sectionFormat="of"
/>.</li>
<li>The Egress Tunnel Router (ETR) that decapsulates the packet <bcp
14>SHOULD</bcp14>
check that the source
and destination IPv6 addresses are valid for the LISP-GPE tunnel and destination IPv6 addresses are valid for the LISP-GPE tunnel
that is configured to receive Zero UDP checksum and discard that is configured to receive a zero UDP checksum and discard
other packets for which such check fails</t> other packets that fail such checks.</li>
<li>The Ingress Tunnel Router (ITR) that encapsulates the packet <bc
<t>The ITR that encapsulates the packet MAY use different IPv6 p14>MAY</bcp14>
source addresses for each LISP-GPE tunnel that uses Zero UDP use different IPv6
source addresses for each LISP-GPE tunnel that uses zero UDP
checksum mode in order to strengthen the decapsulator's check of checksum mode in order to strengthen the decapsulator's check of
the IPv6 source address (i.e the same IPv6 source address is not the IPv6 source address (i.e., the same IPv6 source address is not
to be used with more than one IPv6 destination address, to be used with more than one IPv6 destination address,
irrespective of whether that destination address is a unicast or irrespective of whether that destination address is a unicast or
multicast address). When this is not possible, it is RECOMMENDED multicast address). When this is not possible, it is <bcp14>RECOMM
to use each source address for as few LISP-GPE tunnels that use ENDED</bcp14>
zero UDP checksum as is feasible</t> to use each source address for as few LISP-GPE tunnels that use a
zero UDP checksum as is feasible.</li>
<t>Measures SHOULD be taken to prevent LISP-GPE traffic over <li>Measures <bcp14>SHOULD</bcp14> be taken to prevent LISP-GPE traf
IPv6 with zero UDP checksum from escaping into the general fic over
IPv6 with a zero UDP checksum from escaping into the general
Internet. Examples of such measures include employing packet Internet. Examples of such measures include employing packet
filters at the PETR and/or keeping logical or physical filters at the Proxy Egress Tunnel Router (PETR) and/or keeping lo
separation of LISP network from networks carrying General gical or physical
Internet</t> separation of the LISP network from networks in the general
</list>The above requirements do not change either the Internet.</li>
requirements specified in <xref target="RFC2460"/> as modified by </ol>
<xref target="RFC6935"/> or the requirements specified in <xref <t>The above requirements do not change the
target="RFC6936"/>.</t> requirements specified in <xref target="RFC6935"/>,
<xref target="RFC6936" format="default"/>, or <xref target="RFC8200" fo
rmat="default"/>.</t>
<t>The requirement to check the source IPv6 address in addition to <t>The requirement to check the source IPv6 address in addition to
the destination IPv6 address, plus the recommendation against reuse the destination IPv6 address, plus the recommendation against the reus
of source IPv6 addresses among LISP-GPE tunnels collectively provide e
of source IPv6 addresses among LISP-GPE tunnels, collectively provide
some mitigation for the absence of UDP checksum coverage of the IPv6 some mitigation for the absence of UDP checksum coverage of the IPv6
header. A traffic-managed controlled environment that satisfies at header. A traffic-managed controlled environment that satisfies at
least one of three conditions listed at the beginning of this least one of the three conditions listed at the beginning of this
section provides additional assurance.</t> section provides additional assurance.</t>
</section> </section>
</section> </section>
<section anchor="DSCP" numbered="true" toc="default">
<section anchor="DSCP" title="DSCP, ECN, TTL, and 802.1Q"> <name>DSCP, ECN, TTL, and 802.1Q</name>
<t>When encapsulating IP (including over Ethernet) packets <xref <t>When encapsulating IP (including over Ethernet) packets, <xref target
target="RFC2983"/> provides guidance for mapping DSCP between inner ="RFC2983"
and outer IP headers. The Pipe model typically fits better Network format="default"/> provides guidance for mapping packets that contain Dif
ferentiated Services Code Point
(DSCP) information between inner
and outer IP headers. The Pipe model typically fits better with network
virtualization. The DSCP value on the tunnel header is set based on a virtualization. The DSCP value on the tunnel header is set based on a
policy (which may be a fixed value, one based on the inner traffic policy (which may be a fixed value, one based on the inner traffic
class, or some other mechanism for grouping traffic). Some aspects of class, or some other mechanism for grouping traffic). Some aspects of
the Uniform model (which treats the inner and outer DSCP value as a the Uniform model (which treats the inner and outer DSCP value as a
single field by copying on ingress and egress) may also apply, such as single field by copying on ingress and egress) may also apply, such as
the ability to remark the inner header on tunnel egress based on the ability to remark the inner header on tunnel egress based on
transit marking. However, the Uniform model is not conceptually transit marking. However, the Uniform model is not conceptually
consistent with network virtualization, which seeks to provide strong consistent with network virtualization, which seeks to provide strong
isolation between encapsulated traffic and the physical network.</t> isolation between encapsulated traffic and the physical network.</t>
<t><xref target="RFC6040" format="default"/> describes the mechanism for
<t><xref target="RFC6040"/> describes the mechanism for exposing ECN exposing ECN
capabilities on IP tunnels and propagating congestion markers to the capabilities on IP tunnels and propagating congestion markers to the
inner packets. This behavior MUST be followed for IP packets inner packets. This behavior <bcp14>MUST</bcp14> be followed for IP pack ets
encapsulated in LISP-GPE.</t> encapsulated in LISP-GPE.</t>
<t>Though the Uniform model or the Pipe model could be used for TTL (or
<t>Though Uniform or Pipe models could be used for TTL (or Hop Limit Hop Limit
in case of IPv6) handling when tunneling IP packets, Pipe model is in the case of IPv6) handling when tunneling IP packets, the Pipe model
more aligned with network virtualization. <xref target="RFC2003"/> is
provides guidance on handling TTL between inner IP header and outer IP more aligned with network virtualization. <xref target="RFC2003" format=
"default"/>
provides guidance on handling TTL between inner IP headers and outer IP
tunnels; this model is more aligned with the Pipe model and is tunnels; this model is more aligned with the Pipe model and is
recommended for use with LISP-GPE for network virtualization recommended for use with LISP-GPE for network-virtualization
applications.</t> applications.</t>
<t>When a LISP-GPE router performs Ethernet encapsulation, the inner
802.1Q <xref target="IEEE.802.1Q_2014"/> 3-bit priority code point
(PCP) field MAY be mapped from the encapsulated frame to the DSCP
codepoint of the DS field defined in <xref target="RFC2474"/>.</t>
<t>When a LISP-GPE router performs Ethernet encapsulation, the inner <t>When a LISP-GPE router performs Ethernet encapsulation, the inner
header 802.1Q <xref target="IEEE.802.1Q_2014"/> VLAN Identifier (VID) 802.1Q 3-bit Priority Code Point
MAY be mapped to, or used to determine the LISP Instance IDentifier ('PCP') field <xref target="IEEE.802.1Q_2014" format="default"/> <bcp14>
MAY</bcp14> be mapped from the encapsulated frame to the DSCP
codepoint of the Differentiated Services ('DS') field defined in <xref
target="RFC2474" format="default"/>.</t>
<t>When a LISP-GPE router performs Ethernet encapsulation, the
inner-header 802.1Q VLAN Identifier (VID) <xref target="IEEE.802.1Q_2014
" format="default"/>
<bcp14>MAY</bcp14> be mapped to, or used to determine, the LISP 'Instanc
e ID'
(IID) field.</t> (IID) field.</t>
<t>Refer to <xref target="Security" format="default"/> for consideration
<t>Refer to <xref target="Security"/> for consideration about the use s about the use
of integrity protection for deployments, such as the public Internet, of integrity protection for deployments, such as the public Internet,
concerned with on-path attackers.</t> concerned with on-path attackers.</t>
</section> </section>
</section> </section>
<section anchor="Compatibility" numbered="true" toc="default">
<section anchor="Compatibility" title="Backward Compatibility"> <name>Backward Compatibility</name>
<t>LISP-GPE uses the same UDP destination port (4341) allocated to <t>LISP-GPE uses the same UDP destination port (4341) allocated to
LISP.</t> LISP.</t>
<t>When encapsulating IP packets to a non-LISP-GPE-capable router, the
<t>When encapsulating IP packets to a non LISP-GPE capable router the P-bit <bcp14>MUST</bcp14> be set to 0. That is, the encapsulation format d
P-bit MUST be set to 0. That is, the encapsulation format defined in efined in
this document MUST NOT be sent to a router that has not indicated that this document <bcp14>MUST NOT</bcp14> be sent to a router that has not ind
it supports this specification because such a router would ignore the icated that
P-bit (as described in <xref target="I-D.ietf-lisp-rfc6830bis"/>) and so it supports this specification, because such a router would ignore the
would misinterpret the other LISP header fields possibly causing P-bit (as described in <xref target="RFC9300" format="default"/>) and so
would misinterpret the other LISP header fields, possibly causing
significant errors.</t> significant errors.</t>
<section anchor="ETR_CAPABILITIES" numbered="true" toc="default">
<section anchor="ETR_CAPABILITIES" title="Detection of ETR Capabilities"> <name>Detection of ETR Capabilities</name>
<t>The discovery of xTR capabilities to support LISP-GPE is out of the <t>The discovery of xTR capabilities to support LISP-GPE is out of the
scope of this document. Given that the applicability domain of scope of this document. Given that the applicability domain of
LISP-GPE is a traffic-managed controlled environment, ITR/ETR (xTR) LISP-GPE is a traffic-managed controlled environment, ITR/ETR (xTR)
configuration mechanisms may be used for this purpose.</t> configuration mechanisms may be used for this purpose.</t>
</section> </section>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t/> <t/>
<section anchor="Next_protocol" numbered="true" toc="default">
<section anchor="Next_protocol" title="LISP-GPE Next Protocol Registry"> <name>LISP-GPE Next Protocol Registry</name>
<t>IANA is requested to set up a registry of LISP-GPE "Next Protocol". <t>IANA has created a registry called "LISP-GPE Next Protocol".
These are 8-bit values. Next Protocol values in the table below are These are 8-bit values. Next Protocol values in the table below are
defined in this document. New values are assigned under the defined in this document. New values are assigned under the
Specification Required policy <xref target="RFC8126"/>. The protocols Specification Required policy <xref target="RFC8126" format="default"/>. The protocols
that are being assigned values do not themselves need to be IETF that are being assigned values do not themselves need to be IETF
standards track protocols.</t> Standards Track protocols.</t>
<table align="center">
<texttable> <thead>
<ttcol>Next Protocol</ttcol> <tr>
<th align="left">Next Protocol</th>
<ttcol>Description</ttcol> <th align="left">Description</th>
<th align="left">Reference</th>
<ttcol>Reference</ttcol> </tr>
</thead>
<c>0x0</c> <tbody>
<tr>
<c>Reserved</c> <td align="left">0x00</td> <!-- 0 -->
<td align="left">Reserved</td>
<c>This Document</c> <td align="left">RFC 9305</td>
</tr>
<c>0x1</c> <tr>
<td align="left">0x01</td> <!-- 1 -->
<c>IPv4</c> <td align="left">IPv4</td>
<td align="left">RFC 9305</td>
<c>This Document</c> </tr>
<tr>
<c>0x2</c> <td align="left">0x02</td><!-- 2 -->
<td align="left">IPv6</td>
<c>IPv6</c> <td align="left">RFC 9305</td>
</tr>
<c>This Document</c> <tr>
<td align="left">0x03</td><!-- 3 -->
<c>0x3</c> <td align="left">Ethernet</td>
<td align="left">RFC 9305</td>
<c>Ethernet</c> </tr>
<tr>
<c>This Document</c> <td align="left">0x04</td> <!-- 4 -->
<td align="left">NSH</td>
<c>0x4</c> <td align="left">RFC 9305</td>
</tr>
<c>NSH</c> <tr>
<td align="left">0x05-0x7D</td><!-- 5-125 -->
<c>This Document</c> <td align="left">Unassigned</td>
<td align="left"/>
<c>0x05..0x7D</c> </tr>
<tr>
<c>Unassigned</c> <td align="left">0x7E-0x7F</td><!-- 126-127 -->
<td align="left">Experimentation and testing</td>
<c/> <td align="left">RFC 9305</td>
</tr>
<c>0x7E..0x7F</c> <tr>
<td align="left">0x80-0xFD</td><!-- 128-253 -->
<c>Experimentation and testing</c> <td align="left">Unassigned (shim headers)</td>
<td align="left"/>
<c>This Document</c> </tr>
<tr>
<c>0x80..0xFD</c> <td align="left">0xFE-0xFF</td><!-- 254-255 -->
<td align="left">Experimentation and testing (shim headers)</td>
<c>Unassigned (shim headers)</c> <td align="left">RFC 9305</td>
</tr>
<c/> </tbody>
</table>
<c>0x8E..0x8F</c>
<c>Experimentation and testing (shim headers)</c>
<c>This Document</c>
</texttable>
</section> </section>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>LISP-GPE security considerations are similar to the LISP security <t>LISP-GPE security considerations are similar to the LISP security
considerations and mitigation techniques documented in <xref considerations and mitigation techniques documented in <xref target="RFC78
target="RFC7835"/>.</t> 35" format="default"/>.</t>
<t>As is the case for many encapsulations that use optional extensions, LI
<t>LISP-GPE, as many encapsulations that use optional extensions, is SP-GPE is
subject to on-path adversaries that can make arbitrary modifications to subject to on-path adversaries that can make arbitrary modifications to
the packet (including the P-Bit) to change or remove any part of the the packet (including the P-bit) to change or remove any part of the
payload, or claim to encapsulate any protocol payload type. Typical payload, or claim to encapsulate any protocol payload type. Typical
integrity protection mechanisms (such as IPsec) SHOULD be used in integrity protection mechanisms (such as IPsec) <bcp14>SHOULD</bcp14> be u sed in
combination with LISP-GPE by those protocol extensions that want to combination with LISP-GPE by those protocol extensions that want to
protect from on-path attackers.</t> protect against on-path attackers.</t>
<t>With LISP-GPE, issues such as data plane spoofing, flooding, and
<t>With LISP-GPE, issues such as data-plane spoofing, flooding, and
traffic redirection may depend on the particular protocol payload traffic redirection may depend on the particular protocol payload
encapsulated.</t> encapsulated.</t>
</section> </section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="Acknowledgements"
title="Acknowledgements and Contributors">
<t>A special thank you goes to Dino Farinacci for his guidance and
detailed review. Thanks to Tom Herbert for the suggestion to assign
codepoints for experimentations and testing.</t>
<t>This Working Group (WG) document originated as draft-lewis-lisp-gpe;
the following are its coauthors and contributors along with their
respective affiliations at the time of WG adoption. The editor of this
document would like to thank and recognize them and their contributions.
These coauthors and contributors provided invaluable concepts and
content for this document's creation.</t>
<t><list style="symbols">
<t>Darrel Lewis, Cisco Systems, Inc.</t>
<t>Fabio Maino, Cisco Systems, Inc.</t>
<t>Paul Quinn, Cisco Systems, Inc.</t>
<t>Michael Smith, Cisco Systems, Inc.</t>
<t>Navindra Yadav, Cisco Systems, Inc.</t>
<t>Larry Kreeger</t>
<t>Jennifer Lemon, Broadcom</t>
<t>Puneet Agarwal, Innovium</t>
</list></t>
</section>
</middle> </middle>
<!-- *****BACK MATTER ***** v-->
<back> <back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation librarie
s:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (
as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml
"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.x
ml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included fil
es in the same
directory as the including file. You can also define the XML_LIBRARY environ
ment variable
with a value containing a set of directories to search. These can be either
in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
&ieee_802_1Q;
<?rfc include="reference.I-D.ietf-lisp-rfc6830bis"
?>
<?rfc include="reference.RFC.6040"?>
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
<?rfc include="reference.I-D.ietf-tsvwg-ecn-encap-guidelines"
?>
<?rfc include="reference.I-D.lemon-vxlan-lisp-gpe-gbp"?>
<?rfc include="reference.I-D.brockners-ippm-ioam-vxlan-gpe"?>
<?rfc include="reference.RFC.2460"?>
<?rfc include="reference.RFC.2003"?>
<?rfc include="reference.RFC.2474"?>
<?rfc include="reference.RFC.2983"?>
<?rfc include="reference.RFC.3168"?>
<?rfc include="reference.RFC.3692"?> <displayreference target="I-D.ietf-tsvwg-ecn-encap-guidelines" to="ENCAP-GUIDE"/
>
<?rfc include="reference.RFC.6935"?>
<?rfc include="reference.RFC.6936"?>
<?rfc include="reference.RFC.7348"?> <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6040.xml"/>
<?rfc include="reference.RFC.7835" <reference anchor="IEEE.802.1Q_2014" target="http://ieeexplore.ieee.org/
?> servlet/opac?punumber=6991460">
<front>
<title>IEEE Standard for Local and metropolitan area networks--Bridg
es and Bridged Networks</title>
<author>
<organization>IEEE</organization>
</author>
<date month="December" year="2014"/>
</front>
<refcontent>IEEE Std 802.1Q-2014</refcontent>
</reference>
<?rfc include="reference.RFC.8085"?> <reference anchor='RFC9300' target="https://www.rfc-editor.org/info/rfc9300">
<front>
<title>The Locator/ID Separation Protocol (LISP)</title>
<author initials='D' surname='Farinacci' fullname='Dino Farinacci'>
<organization />
</author>
<author initials='V' surname='Fuller' fullname='Vince Fuller'>
<organization />
</author>
<author initials='D' surname='Meyer' fullname='David Meyer'>
<organization />
</author>
<author initials='D' surname='Lewis' fullname='Darrel Lewis'>
<organization />
</author>
<author initials='A' surname='Cabellos' fullname='Albert Cabellos' role='editor'
>
<organization />
</author>
<date month='October' year='2022' />
</front>
<seriesInfo name="RFC" value="9300"/>
<seriesInfo name="DOI" value="10.17487/RFC9300"/>
</reference>
</references>
<references>
<name>Informative References</name>
<?rfc include="reference.RFC.8086"?> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.i etf-tsvwg-ecn-encap-guidelines.xml"/>
<?rfc include="reference.RFC.8126"?> <reference anchor='VXLAN-LISP'>
<front>
<title>Group Policy Encoding with VXLAN-GPE and LISP-GPE</title>
<author initials='J' surname='Lemon' fullname='John Lemon' role='editor'>
<organization />
</author>
<author initials='F' surname='Maino' fullname='Fabio Maino'>
<organization />
</author>
<author initials='M' surname='Smith' fullname='Michael Smith'>
<organization />
</author>
<author initials='A' surname='Isaac' fullname='Aldrin Isaac'>
<organization />
</author>
<date month='April' day='30' year='2019' />
</front>
<seriesInfo name='Internet-Draft' value='draft-lemon-vxlan-lisp-gpe-gbp-02' />
</reference>
<?rfc include="reference.RFC.8174"?> <reference anchor="VXLAN-GPE">
<front>
<title>VXLAN-GPE Encapsulation for In-situ OAM Data</title>
<author initials="F." surname="Brockners" fullname="Frank Brockners">
<organization>Cisco Systems, Inc.</organization>
</author>
<author initials="S." surname="Bhandari" fullname="Shwetha Bhandari">
<organization>Cisco Systems, Inc.</organization>
</author>
<author initials="V." surname="Govindan" fullname="Vengada Prasad Govindan
">
<organization>Cisco Systems, Inc.</organization>
</author>
<author initials="C." surname="Pignataro" fullname="Carlos Pignataro">
<organization>Cisco Systems, Inc.</organization>
</author>
<author initials="H." surname="Gredler" fullname="Hannes Gredler">
<organization>RtBrick Inc.</organization>
</author>
<author initials="J." surname="Leddy" fullname="John Leddy">
</author>
<author initials="S." surname="Youell" fullname="Stephen Youell">
<organization>JP Morgan Chase</organization>
</author>
<author initials="T." surname="Mizrahi" fullname="Tal Mizrahi">
<organization>Huawei Network.IO Innovation Lab</organization>
</author>
<author initials="A." surname="Kfir" fullname="Aviv Kfir">
<organization>Mellanox Technologies, Inc.</organization>
</author>
<author initials="B." surname="Gafni" fullname="Barak Gafni">
<organization>Mellanox Technologies, Inc.</organization>
</author>
<author initials="P." surname="Lapukhov" fullname="Petr Lapukhov">
<organization>Facebook</organization>
</author>
<author initials="M." surname="Spiegel" fullname="Mickey Spiegel">
<organization>Barefoot Networks</organization>
</author>
<date month="November" day="4" year="2019" />
</front>
<seriesInfo name="Internet-Draft" value="draft-brockners-ippm-ioam-vxlan-gpe-
03" />
</reference>
<?rfc include="reference.RFC.8300"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8200.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2003.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.2983.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3168.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3692.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6935.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6936.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.7835.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8085.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8086.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.8300.xml"/>
</references>
</references> </references>
<section anchor="Acknowledgments" numbered="false" toc="default">
<name>Acknowledgments</name>
<t>A special thank you goes to <contact fullname="Dino Farinacci"/> for hi
s guidance and
detailed review. Thanks to <contact fullname="Tom Herbert"/> for the sugge
stion to assign
codepoints for experimentations and testing.</t>
</section>
<section anchor="Contributors" numbered="false" toc="default">
<name>Contributors</name>
<t>The editor of this document would like to thank and recognize the
following coauthors and contributors for their contributions. These
coauthors and contributors provided invaluable concepts and content
for this document's creation.</t>
<!-- Change Log <contact fullname="Darrel Lewis">
<organization>Cisco Systems, Inc.</organization>
v00.01 2017-01-24 FM Renamed as draft-ietf-lisp-gpe to reflect WG adoption <address/>
v00.02 2017-12-12 FM Changed to reflect RFC6830bis header format </contact>
<contact fullname="Fabio Maino">
<!--v00.03 2017-12-14 FM Changed Intended Status to Standard Track <organization>Cisco Systems, Inc.</organization>
v01.00 2018-03-05 FM Removed reference to GBP draft (informational) and fixe <address/>
d paulq email address--> </contact>
<contact fullname="Paul Quinn">
<!--v02.00 2018-03-22 FM Updated Section 4. Backward Compatibilty to be <organization>Cisco Systems, Inc.</organization>
consistent with RFC8061 and addressed WG chair comments--> <address/>
</contact>
<!--v04.00 2018-07-19 FM Addressed WG chair editorial comments--> <contact fullname="Michael Smith">
<organization>Cisco Systems, Inc.</organization>
<!--v05.00 2018-08-15 FM Addressed rtgdir comments --> <address/>
</contact>
<!--v06.00 2018-09-20 FM Addressed secdir, tsvart + Mirja comments. Some <contact fullname="Navindra Yadav">
tsvart comments are still to be resolved <organization>Cisco Systems, Inc.</organization>
v07.00 2018-10- FM Fixed a few nits, added support for shim protoocls GBP <address/>
and iOAM. </contact>
Introduced concept of LISP-GPE shim headers, new sectio <contact fullname="Larry Kreeger">
n 4 dealing with deployment considerations: <organization/>
Applicability, Congestion Control, UDP checksum, Ethern <address/>
et Payoads </contact>
<contact fullname="Jennifer Lemon">
<organization>Broadcom</organization>
<address/>
</contact>
<contact fullname="Puneet Agarwal">
<organization>Innovium</organization>
<address/>
</contact>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 125 change blocks. 
717 lines changed or deleted 669 lines changed or added

This html diff was produced by rfcdiff 1.48.