rfc9300xml2.original.xml   rfc9300.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> nsus="true" docName="draft-ietf-lisp-rfc6830bis-38" indexInclude="true" ipr="tru
st200902" number="9300" obsoletes="6830" prepTime="2022-10-19T13:38:47" scripts=
<rfc category="std" ipr="trust200902" docName="draft-ietf-lisp-rfc6830bis-36" "Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3"
obsoletes="6830"> tocInclude="true" xml:lang="en">
<link href="https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis-38" re
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> l="prev"/>
<link href="https://dx.doi.org/10.17487/rfc9300" rel="alternate"/>
<?rfc toc="yes" ?> <link href="urn:issn:2070-1721" rel="alternate"/>
<?rfc symrefs="yes" ?> <front>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc rfcedstyle="yes"?>
<front>
<title abbrev="LISP">The Locator/ID Separation Protocol (LISP)</title> <title abbrev="LISP">The Locator/ID Separation Protocol (LISP)</title>
<author initials='D' surname="Farinacci" fullname='Dino Farinacci'> <seriesInfo name="RFC" value="9300" stream="IETF"/>
<organization>lispers.net</organization> <author initials="D" surname="Farinacci" fullname="Dino Farinacci">
<address> <organization showOnFrontPage="true">lispers.net</organization>
<email>farinacci@gmail.com</email></address> <address>
<postal>
<city>San Jose</city>
<region>CA</region>
<country>United States of America</country>
</postal>
<email>farinacci@gmail.com</email>
</address>
</author> </author>
<author initials="V" surname="Fuller" fullname="Vince Fuller">
<author initials='V' surname="Fuller" fullname='Vince Fuller'> <organization showOnFrontPage="true">vaf.net Internet Consulting</organiza
<organization>vaf.net Internet Consulting</organization> tion>
<address> <address>
<email>vince.fuller@gmail.com</email></address> <email>vince.fuller@gmail.com</email>
</address>
</author> </author>
<author initials="D" surname="Meyer" fullname="Dave Meyer">
<author initials='D' surname="Meyer" fullname='Dave Meyer'> <organization showOnFrontPage="true">1-4-5.net</organization>
<organization>1-4-5.net</organization> <address>
<address> <email>dmm@1-4-5.net</email>
<email>dmm@1-4-5.net</email></address> </address>
</author> </author>
<author initials="D" surname="Lewis" fullname="Darrel Lewis">
<author initials='D' surname="Lewis" fullname='Darrel Lewis'> <organization showOnFrontPage="true">Cisco Systems</organization>
<organization>Cisco Systems</organization> <address>
<address><postal> <postal>
<street>170 Tasman Drive</street> <city>San Jose</city>
<city>San Jose</city> <region>CA</region> <region>CA</region>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>darlewis@cisco.com</email></address> <email>darlewis@cisco.com</email>
</address>
</author> </author>
<author initials="A" surname="Cabellos" fullname="Albert Cabellos" role="edi
<author initials='A' surname="Cabellos (Ed.)" fullname='Albert Cabellos'> tor">
<organization>UPC/BarcelonaTech</organization> <organization showOnFrontPage="true">Universitat Politecnica de Catalunya<
<address><postal> /organization>
<street>Campus Nord, C. Jordi Girona 1-3</street> <address>
<city>Barcelona</city> <region>Catalunya</region> <postal>
<country>Spain</country> <street>c/ Jordi Girona s/n</street>
</postal> <city>Barcelona</city>
<email>acabello@ac.upc.edu</email></address> <code>08034</code>
</author> <country>Spain</country>
</postal>
<date /> <email>acabello@ac.upc.edu</email>
</address>
<abstract> </author>
<t>This document describes the Data-Plane protocol for the <date month="10" year="2022"/>
<keyword>LISP data plane</keyword>
<abstract pn="section-abstract">
<t indent="0" pn="section-abstract-1">This document describes the data pla
ne protocol for the
Locator/ID Separation Protocol (LISP). LISP defines two Locator/ID Separation Protocol (LISP). LISP defines two
namespaces, End-point Identifiers (EIDs) that identify end-hosts namespaces: Endpoint Identifiers (EIDs), which identify end hosts;
and Routing Locators (RLOCs) that identify network attachment and Routing Locators (RLOCs), which identify network attachment
points. With this, LISP effectively separates control from data, points. With this, LISP effectively separates control from data
and allows routers to create overlay networks. LISP-capable and allows routers to create overlay networks. LISP-capable
routers exchange encapsulated packets according to EID-to-RLOC routers exchange encapsulated packets according to EID-to-RLOC
mappings stored in a local Map-Cache.</t> mappings stored in a local Map-Cache.</t>
<t indent="0" pn="section-abstract-2">LISP requires no change to either ho
<t>LISP requires no change to either host protocol stacks or st protocol stacks or
to underlay routers and offers Traffic Engineering, underlay routers and offers Traffic Engineering (TE),
multihoming and mobility, among other features.</t> multihoming, and mobility, among other features.</t>
<t indent="0" pn="section-abstract-3">This document obsoletes RFC 6830.</t
<t>This document obsoletes RFC 6830.</t> >
</abstract> </abstract>
</front> <boilerplate>
<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
<middle> "exclude" pn="section-boilerplate.1">
<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
<section title="Introduction"> >
<t>This document describes the Locator/Identifier Separation <t indent="0" pn="section-boilerplate.1-1">
This is an Internet Standards Track document.
</t>
<t indent="0" pn="section-boilerplate.1-2">
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
</t>
<t indent="0" pn="section-boilerplate.1-3">
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<eref target="https://www.rfc-editor.org/info/rfc9300" brackets="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t indent="0" pn="section-boilerplate.2-1">
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t indent="0" pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none
"/>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
ivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-introduction">
Introduction</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.1.2">
<li pn="section-toc.1-1.1.2.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><
xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.
1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sc
ope-of-applicability">Scope of Applicability</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.2">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref der
ivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-requirements-n
otation">Requirements Notation</xref></t>
</li>
<li pn="section-toc.1-1.3">
<t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" form
at="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-definitions-of-terms">Definitions
of Terms</xref></t>
</li>
<li pn="section-toc.1-1.4">
<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-basic-overview">Basic Overview</xr
ef></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.4.2">
<li pn="section-toc.1-1.4.2.1">
<t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent=
"4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-deployment-on-the-publ
ic-in">Deployment on the Public Internet</xref></t>
</li>
<li pn="section-toc.1-1.4.2.2">
<t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent=
"4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-packet-flow-sequence">
Packet Flow Sequence</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5">
<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-lisp-encapsulation-details">LISP E
ncapsulation Details</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.5.2">
<li pn="section-toc.1-1.5.2.1">
<t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent=
"5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-lisp-ipv4-in-ipv4-head
er-fo">LISP IPv4-in-IPv4 Header Format</xref></t>
</li>
<li pn="section-toc.1-1.5.2.2">
<t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent=
"5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-lisp-ipv6-in-ipv6-head
er-fo">LISP IPv6-in-IPv6 Header Format</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3">
<t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent=
"5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-tunnel-header-field-de
scrip">Tunnel Header Field Descriptions</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.6">
<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-lisp-eid-to-rloc-map-cache">LISP E
ID-to-RLOC Map-Cache</xref></t>
</li>
<li pn="section-toc.1-1.7">
<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" form
at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-dealing-with-large-encapsul">Deali
ng with Large Encapsulated Packets</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.7.2">
<li pn="section-toc.1-1.7.2.1">
<t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent=
"7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-a-stateless-solution-t
o-mtu">A Stateless Solution to MTU Handling</xref></t>
</li>
<li pn="section-toc.1-1.7.2.2">
<t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent=
"7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-a-stateful-solution-to
-mtu-">A Stateful Solution to MTU Handling</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.8">
<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" form
at="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-using-virtualization-and-se">Using
Virtualization and Segmentation with LISP</xref></t>
</li>
<li pn="section-toc.1-1.9">
<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" form
at="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-routing-locator-selection">Routing
Locator Selection</xref></t>
</li>
<li pn="section-toc.1-1.10">
<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" fo
rmat="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-routing-locator-reachabilit">Rou
ting Locator Reachability</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.10.2">
<li pn="section-toc.1-1.10.2.1">
<t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent
="10.1" format="counter" sectionFormat="of" target="section-10.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-echo-nonce-algorith
m">Echo-Nonce Algorithm</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.11">
<t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" fo
rmat="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-eid-reachability-within-a-l">EID
Reachability within a LISP Site</xref></t>
</li>
<li pn="section-toc.1-1.12">
<t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" fo
rmat="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-routing-locator-hashing">Routing
Locator Hashing</xref></t>
</li>
<li pn="section-toc.1-1.13">
<t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="13" fo
rmat="counter" sectionFormat="of" target="section-13"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-changing-the-contents-of-ei">Cha
nging the Contents of EID-to-RLOC Mappings</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.13.2">
<li pn="section-toc.1-1.13.2.1">
<t indent="0" pn="section-toc.1-1.13.2.1.1"><xref derivedContent
="13.1" format="counter" sectionFormat="of" target="section-13.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-locator-status-bits
">Locator-Status-Bits</xref></t>
</li>
<li pn="section-toc.1-1.13.2.2">
<t indent="0" pn="section-toc.1-1.13.2.2.1"><xref derivedContent
="13.2" format="counter" sectionFormat="of" target="section-13.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-database-map-versio
ning">Database Map-Versioning</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.14">
<t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="14" fo
rmat="counter" sectionFormat="of" target="section-14"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-multicast-considerations">Multic
ast Considerations</xref></t>
</li>
<li pn="section-toc.1-1.15">
<t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="15" fo
rmat="counter" sectionFormat="of" target="section-15"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-router-performance-consider">Rou
ter Performance Considerations</xref></t>
</li>
<li pn="section-toc.1-1.16">
<t indent="0" pn="section-toc.1-1.16.1"><xref derivedContent="16" fo
rmat="counter" sectionFormat="of" target="section-16"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-security-considerations">Securit
y Considerations</xref></t>
</li>
<li pn="section-toc.1-1.17">
<t indent="0" pn="section-toc.1-1.17.1"><xref derivedContent="17" fo
rmat="counter" sectionFormat="of" target="section-17"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-network-management-consider">Net
work Management Considerations</xref></t>
</li>
<li pn="section-toc.1-1.18">
<t indent="0" pn="section-toc.1-1.18.1"><xref derivedContent="18" fo
rmat="counter" sectionFormat="of" target="section-18"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-changes-since-rfc-6830">Changes
since RFC 6830</xref></t>
</li>
<li pn="section-toc.1-1.19">
<t indent="0" pn="section-toc.1-1.19.1"><xref derivedContent="19" fo
rmat="counter" sectionFormat="of" target="section-19"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-iana-considerations">IANA Consid
erations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.19.2">
<li pn="section-toc.1-1.19.2.1">
<t indent="0" pn="section-toc.1-1.19.2.1.1"><xref derivedContent
="19.1" format="counter" sectionFormat="of" target="section-19.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-lisp-udp-port-numbe
rs">LISP UDP Port Numbers</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.20">
<t indent="0" pn="section-toc.1-1.20.1"><xref derivedContent="20" fo
rmat="counter" sectionFormat="of" target="section-20"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-references">References</xref></t
>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.20.2">
<li pn="section-toc.1-1.20.2.1">
<t indent="0" pn="section-toc.1-1.20.2.1.1"><xref derivedContent
="20.1" format="counter" sectionFormat="of" target="section-20.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-normative-reference
s">Normative References</xref></t>
</li>
<li pn="section-toc.1-1.20.2.2">
<t indent="0" pn="section-toc.1-1.20.2.2.1"><xref derivedContent
="20.2" format="counter" sectionFormat="of" target="section-20.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-informative-referen
ces">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.21">
<t indent="0" pn="section-toc.1-1.21.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgment
s</xref></t>
</li>
<li pn="section-toc.1-1.22">
<t indent="0" pn="section-toc.1-1.22.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
resses</xref></t>
</li>
</ul>
</section>
</toc>
</front>
<middle>
<section numbered="true" toc="include" removeInRFC="false" pn="section-1">
<name slugifiedName="name-introduction">Introduction</name>
<t indent="0" pn="section-1-1">This document describes the Locator/ID Sepa
ration
Protocol (LISP). LISP is an encapsulation protocol built around the Protocol (LISP). LISP is an encapsulation protocol built around the
fundamental idea of separating the topological location of a network fundamental idea of separating the topological location of a network
attachment point from the node's identity <xref target="CHIAPPA" attachment point from the node's identity <xref target="CHIAPPA" format="defau
/>. As a result LISP creates two namespaces: Endpoint Identifiers lt" sectionFormat="of" derivedContent="CHIAPPA"/>. As a result, LISP creates two
(EIDs), that are used to identify end-hosts (e.g., nodes or Virtual namespaces: Endpoint Identifiers
Machines) and routable Routing Locators (RLOCs), used to identify (EIDs), which are used to identify end hosts (e.g., nodes or Virtual
Machines); and routable Routing Locators (RLOCs), which are used to identify
network attachment points. LISP then defines functions for mapping network attachment points. LISP then defines functions for mapping
between the two namespaces and for encapsulating traffic between the two namespaces and for encapsulating traffic
originated by devices using non-routable EIDs for transport across a originated by devices using non-routable EIDs for transport across a
network infrastructure that routes and forwards using RLOCs. LISP network infrastructure that routes and forwards using RLOCs. LISP
encapsulation uses a dynamic form of tunneling where no static provisioning encapsulation uses a dynamic form of tunneling where no static provisioning
is required or necessary.</t> is required or necessary.</t>
<t indent="0" pn="section-1-2">LISP is an overlay protocol that separates
<t>LISP is an overlay protocol that separates control from control from data; this
Data-Plane, this document specifies the Data-Plane as well as how LISP-capable document specifies the data plane as well as how LISP-capable
routers (Tunnel Routers) exchange packets by encapsulating them to routers (Tunnel Routers) exchange packets by encapsulating them to
the appropriate location. Tunnel routers are equipped with a cache, the appropriate location. Tunnel Routers are equipped with a cache,
called Map-Cache, that contains EID-to-RLOC mappings. The Map-Cache called the Map-Cache, that contains EID-to-RLOC mappings. The Map-Cache
is populated using the LISP Control-Plane protocol <xref is populated using the LISP control plane protocol <xref target="RFC9301" form
target="I-D.ietf-lisp-rfc6833bis"/>.</t> at="default" sectionFormat="of" derivedContent="RFC9301"/>.</t>
<t indent="0" pn="section-1-3">LISP does not require changes to either the
<t>LISP does not require changes to either the host protocol stack or to host protocol stack or
underlay routers. By separating the EID from the RLOC space, LISP underlay routers. By separating the EID from the RLOC space, LISP
offers native Traffic Engineering, multihoming and mobility, among offers native Traffic Engineering (TE), multihoming, and mobility, among
other features.</t> other features.</t>
<t indent="0" pn="section-1-4">Creation of LISP was initially motivated by
<t>Creation of LISP was initially motivated by discussions during discussions during
the IAB-sponsored Routing and Addressing Workshop held in Amsterdam the IAB-sponsored Routing and Addressing Workshop held in Amsterdam
in October 2006 (see <xref target="RFC4984" />).</t> in October 2006 (see <xref target="RFC4984" format="default" sectionFormat="of
" derivedContent="RFC4984"/>).</t>
<t>This document specifies the LISP Data-Plane encapsulation and <t indent="0" pn="section-1-5">This document specifies the LISP data plane
other LISP forwarding node functionality while <xref encapsulation and
target="I-D.ietf-lisp-rfc6833bis"/> specifies the LISP control other LISP forwarding node functionality while <xref target="RFC9301" format="
plane. LISP deployment guidelines can be found in <xref default" sectionFormat="of" derivedContent="RFC9301"/> specifies the LISP contro
target="RFC7215"/> and <xref target="RFC6835"/> describes l
considerations for network operational management. Finally, <xref plane. LISP deployment guidelines can be found in <xref target="RFC7215" forma
target="I-D.ietf-lisp-introduction"/> describes the LISP architecture.</t> t="default" sectionFormat="of" derivedContent="RFC7215"/>, and <xref target="RFC
6835" format="default" sectionFormat="of" derivedContent="RFC6835"/> describes
<t>This document obsoletes RFC 6830.</t> considerations for network operational management. Finally, <xref target="RFC
9299" format="default" sectionFormat="of" derivedContent="RFC9299"/> describes t
<section title="Scope of Applicability" anchor="soa"> he LISP architecture.</t>
<t>LISP was originally developed to address the Internet-wide <t indent="0" pn="section-1-6">This document obsoletes RFC 6830.</t>
route scaling problem <xref target="RFC4984"/>. While there are a <section anchor="soa" numbered="true" toc="include" removeInRFC="false" pn
number of approaches of interest for that problem, as LISP as been ="section-1.1">
developed and refined, a large number of other LISP uses have been <name slugifiedName="name-scope-of-applicability">Scope of Applicability
found and are being used. As such, the design and development of </name>
LISP has changed so as to focus on these use cases. The common <t indent="0" pn="section-1.1-1">LISP was originally developed to addres
s the Internet-wide
route scaling problem <xref target="RFC4984" format="default" sectionFormat=
"of" derivedContent="RFC4984"/>.
While there are a number of approaches of
interest for that problem, as LISP has been developed and refined, a
large number of other ways to use LISP have been found and are being
implemented. As such, the design and development of
LISP have changed so as to focus on these use cases. The common
property of these uses is a large set of cooperating entities property of these uses is a large set of cooperating entities
seeking to communicate over the public Internet or other large seeking to communicate over the public Internet or other large
underlay IP infrastructures, while keeping the addressing and underlay IP infrastructures while keeping the addressing and
topology of the cooperating entities separate from the underlay topology of the cooperating entities separate from the underlay
and Internet topology, routing, and addressing.</t> and Internet topology, routing, and addressing.</t>
</section>
</section> </section>
</section> <section numbered="true" toc="include" removeInRFC="false" pn="section-2">
<name slugifiedName="name-requirements-notation">Requirements Notation</na
<section title="Requirements Notation"> me>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <t indent="0" pn="section-2-1">
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"MAY", and "OPTIONAL" in this document are to be interpreted as IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOUL
described in BCP 14 <xref target="RFC2119"/> <xref D</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>N
target="RFC8174"/> when, and only when, they appear in all capitals, OT RECOMMENDED</bcp14>",
as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
</section> be interpreted as
described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="o
<section title="Definition of Terms" anchor="DEFINITIONS"> f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor
<t><list style="hanging"> mat="of" derivedContent="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
<t hangText="Address Family Identifier (AFI): ">AFI is a term used </t>
to describe an address encoding in a packet. An address family </section>
that pertains to addresses found in Data-Plane headers. See <xref <section anchor="DEFINITIONS" numbered="true" toc="include" removeInRFC="fal
target="AFN"/> and <xref target="RFC3232"/> for details. An AFI se" pn="section-3">
<name slugifiedName="name-definitions-of-terms">Definitions of Terms</name
>
<dl newline="false" spacing="normal" indent="3" pn="section-3-1">
<dt pn="section-3-1.1">Address Family Identifier (AFI): </dt>
<dd pn="section-3-1.2">"AFI" is a term used
to describe an address encoding in a packet. An address family is an addr
ess
format found in data plane packet headers,
for example, an IPv4 address or an IPv6 address. See <xref target="AFN" f
ormat="default" sectionFormat="of" derivedContent="AFN"/>, <xref target="RFC2453
" format="default" sectionFormat="of" derivedContent="RFC2453"/>, <xref target="
RFC2677" format="default" sectionFormat="of" derivedContent="RFC2677"/>, and <xr
ef target="RFC4760" format="default" sectionFormat="of" derivedContent="RFC4760"
/> for details. An AFI
value of 0 used in this specification indicates an unspecified value of 0 used in this specification indicates an unspecified
encoded address where the length of the address is 0 octets encoded address where the length of the address is 0 octets
following the 16-bit AFI value of 0.</t> following the 16-bit AFI value of 0.</dd>
<dt pn="section-3-1.3">Anycast Address:</dt>
<t hangText="Anycast Address:">Anycast Address refers to the same <dd pn="section-3-1.4">"Anycast address" refers to the same
IPv4 or IPv6 address configured IPv4 or IPv6 address configured
and used on multiple systems at the same time. An EID or RLOC can and used on multiple systems at the same time. An EID or RLOC can
be an anycast address in each of their own address spaces.</t> be an anycast address in each of their own address spaces.</dd>
<dt pn="section-3-1.5">Client-side:</dt>
<t hangText="Client-side:">Client-side is a term used in this <dd pn="section-3-1.6">"Client-side" is a term used in this
document to indicate a connection initiation attempt by an end-system document to indicate a connection initiation attempt by an end-system
represented by an EID.</t> represented by an EID.</dd>
<dt pn="section-3-1.7">Egress Tunnel Router (ETR): </dt>
<t hangText="Egress Tunnel Router (ETR): ">An ETR is a router that <dd pn="section-3-1.8">An ETR is a router that
accepts an IP packet where the destination address in the "outer" accepts an IP packet where the destination address in the "outer"
IP header is one of its own RLOCs. The router strips the "outer" IP header is one of its own RLOCs. The router strips the "outer"
header and forwards the packet based on the next IP header header and forwards the packet based on the next IP header
found. In general, an ETR receives LISP-encapsulated IP packets found. In general, an ETR receives LISP-encapsulated IP packets
from the Internet on one side and sends decapsulated IP packets to from the Internet on one side and sends decapsulated IP packets to
site end-systems on the other side. ETR functionality does not site end-systems on the other side. ETR functionality does not
have to be limited to a router device. A server host can be the have to be limited to a router device. A server host can be the
endpoint of a LISP tunnel as well.</t> endpoint of a LISP tunnel as well.</dd>
<dt pn="section-3-1.9">EID-to-RLOC Database: </dt>
<t hangText="EID-to-RLOC Database: ">The EID-to-RLOC Database is a <dd pn="section-3-1.10">The EID-to-RLOC Database is a
distributed database that contains all known EID-Prefix-to-RLOC distributed database that contains all known EID-Prefix-to-RLOC
mappings. Each potential ETR typically contains a small piece of mappings. Each potential ETR typically contains a small piece of
the database: the EID-to-RLOC mappings for the EID-Prefixes the database: the EID-to-RLOC mappings for the EID-Prefixes
"behind" the router. These map to one of the router's own IP "behind" the router. These map to one of the router's own IP
addresses that are routable on the underlay. addresses that are routable on the underlay.
Note that there MAY be transient conditions when the EID-Prefix Note that there <bcp14>MAY</bcp14> be transient conditions when the EID-Pref ix
for the LISP site and Locator-Set for each EID-Prefix may not be the for the LISP site and Locator-Set for each EID-Prefix may not be the
same on all ETRs. This has no negative implications, since a same on all ETRs. This has no negative implications, since a
partial set of Locators can be used.</t> partial set of Locators can be used.</dd>
<dt pn="section-3-1.11">EID-to-RLOC Map-Cache: </dt>
<t hangText="EID-to-RLOC Map-Cache: ">The EID-to-RLOC Map-Cache is <dd pn="section-3-1.12">The EID-to-RLOC Map-Cache is a
generally short-lived, on-demand table in an ITR that stores, tracks, and generally short-lived, on-demand table in an Ingress Tunnel Router (ITR) tha
t stores, tracks, and
is responsible for timing out and otherwise validating EID-to-RLOC is responsible for timing out and otherwise validating EID-to-RLOC
mappings. This cache is distinct from the full "database" of mappings. This cache is distinct from the full "database" of
EID-to-RLOC mappings; it is dynamic, local to the ITR(s), and EID-to-RLOC mappings; it is dynamic, local to the ITR(s), and
relatively small, while the database is distributed, relatively relatively small, while the database is distributed, relatively
static, and much more widely scoped to LISP nodes.</t> static, and much more widely scoped to LISP nodes.</dd>
<dt pn="section-3-1.13">EID-Prefix: </dt>
<t hangText="EID-Prefix: ">An EID-Prefix is a power-of-two block <dd pn="section-3-1.14">An EID-Prefix is a power-of-two block
of EIDs that are allocated to a site by an address allocation of EIDs that are allocated to a site by an address allocation
authority. EID-Prefixes are associated with a set of RLOC authority. EID-Prefixes are associated with a set of RLOC
addresses. EID-Prefix allocations can be broken up into smaller addresses. EID-Prefix allocations can be broken up into smaller
blocks when an RLOC set is to be associated with the larger blocks when an RLOC-Set is to be associated with the larger
EID-Prefix block.</t> EID-Prefix block.</dd>
<dt pn="section-3-1.15">End-System: </dt>
<t hangText="End-System: ">An end-system is an IPv4 or IPv6 device <dd pn="section-3-1.16">An end-system is an IPv4 or IPv6 device
that originates packets with a single IPv4 or IPv6 header. The that originates packets with a single IPv4 or IPv6 header. The
end-system supplies an EID value for the destination address field end-system supplies an EID value for the destination address field
of the IP header when communicating outside of its routing domain. of the IP header when communicating outside of its routing domain.
An end-system can be a host computer, a switch or router device, An end-system can be a host computer, a switch or router device,
or any network appliance.</t> or any network appliance.</dd>
<dt pn="section-3-1.17">Endpoint ID (EID): </dt>
<t hangText="Endpoint ID (EID): ">An EID is a 32-bit (for IPv4) or <dd pn="section-3-1.18">An EID is a 32-bit (for IPv4) or
128-bit (for IPv6) value that identifies a host. EIDs are generally 128-bit (for IPv6) value that identifies a host. EIDs are generally
only found in the source and destination only found in the source and destination
address fields of the first (most inner) LISP header of a address fields of the first (innermost) LISP header of a
packet. The host obtains a destination EID the same way it obtains packet. The host obtains a destination
a destination address today, for example, through a Domain Name EID through a Domain Name System (DNS) <xref target="RFC1034" format="defau
System (DNS) <xref target="RFC1034" /> lookup or Session lt" sectionFormat="of" derivedContent="RFC1034"/>
Initiation Protocol (SIP) <xref target="RFC3261" /> exchange. The lookup or Session Initiation Protocol (SIP) <xref target="RFC3261" format="d
efault" sectionFormat="of" derivedContent="RFC3261"/> exchange. This
behavior does not change when LISP is in use. The
source EID is obtained via existing mechanisms used to set a source EID is obtained via existing mechanisms used to set a
host's "local" IP address. An EID used on the public Internet MUST host's "local" IP address. An EID used on the public Internet <bcp14>MUST</b cp14>
have the same properties as any other IP address used in that have the same properties as any other IP address used in that
manner; this means, among other things, that it MUST be manner; this means, among other things, that it <bcp14>MUST</bcp14> be
unique. An EID is allocated to a host from an EID-Prefix block unique. An EID is allocated to a host from an EID-Prefix block
associated with the site where the host is located. An EID can be associated with the site where the host is located. An EID can be
used by a host to refer to other hosts. Note that EID blocks MAY used by a host to refer to other hosts. Note that EID blocks <bcp14>MAY</bcp 14>
be assigned in a hierarchical manner, independent of the network be assigned in a hierarchical manner, independent of the network
topology, to facilitate scaling of the mapping database. In topology, to facilitate scaling of the mapping database. In
addition, an EID block assigned to a site MAY have site-local addition, an EID block assigned to a site <bcp14>MAY</bcp14> have site-local
structure (subnetting) for routing within the site; this structure structure (subnetting) for routing within the site; this structure
is not visible to the underlay routing system. In theory, the bit is not visible to the underlay routing system. In theory, the bit
string that represents an EID for one device can represent an RLOC string that represents an EID for one device can represent an RLOC
for a different device. When used in discussions with other for a different device. When discussing other Locator/ID separation proposal
Locator/ID separation proposals, a LISP EID will be called an s, any
"LEID". Throughout this document, any references to "EID" refer to references to an EID in this document will refer to a LISP EID.
an LEID.</t> </dd>
<dt pn="section-3-1.19">Ingress Tunnel Router (ITR): </dt>
<t hangText="Ingress Tunnel Router (ITR): ">An ITR is a router <dd pn="section-3-1.20">An ITR is a router
that resides in a LISP site. Packets sent by sources inside of the that resides in a LISP site. Packets sent by sources inside of the
LISP site to destinations outside of the site are candidates for LISP site to destinations outside of the site are candidates for
encapsulation by the ITR. The ITR treats the IP destination encapsulation by the ITR. The ITR treats the IP destination
address as an EID and performs an EID-to-RLOC mapping lookup. The address as an EID and performs an EID-to-RLOC mapping lookup. The
router then prepends an "outer" IP header with one of its routable router then prepends an "outer" IP header with one of its routable
RLOCs (in the RLOC space) in the source address field and the RLOCs (in the RLOC space) in the source address field and the
result of the mapping lookup in the destination address field. result of the mapping lookup in the destination address field.
Note that this destination RLOC may be an intermediate, proxy Note that this destination RLOC may be an intermediate, proxy
device that has better knowledge of the EID-to-RLOC mapping closer device that has better knowledge of the EID-to-RLOC mapping closer
to the destination EID. In general, an ITR receives IP packets to the destination EID. In general, an ITR receives IP packets
from site end-systems on one side and sends LISP-encapsulated IP from site end-systems on one side and sends LISP-encapsulated IP
packets toward the Internet on the other side.</t> packets toward the Internet on the other side.</dd>
<dt pn="section-3-1.21">LISP Header: </dt>
<t hangText="LISP Header: ">LISP header is a term used in this <dd pn="section-3-1.22">"LISP header" is a term used in this document to
document to refer to the outer IPv4 or IPv6 header, a UDP header, refer
and a LISP-specific 8-octet header that follow the UDP header and to the outer IPv4 or IPv6 header, a UDP header, and a LISP-
that an ITR prepends or an ETR strips.</t> specific 8-octet header, all of which follow the UDP header. An
ITR prepends LISP headers on packets, and an ETR strips them.</dd>
<t hangText="LISP Router: ">A LISP router is a router that <dt pn="section-3-1.23">LISP Router: </dt>
performs the functions of any or all of the following: ITR, ETR, RTR, <dd pn="section-3-1.24">A LISP router is a router that
Proxy-ITR (PITR), or Proxy-ETR (PETR).</t> performs the functions of any or all of the following: ITRs, ETRs, Re-encaps
ulating Tunneling Routers (RTRs),
<t hangText="LISP Site:">LISP site is a set of routers in an edge Proxy-ITRs (PITRs), or Proxy-ETRs (PETRs).</dd>
<dt pn="section-3-1.25">LISP Site:</dt>
<dd pn="section-3-1.26">A LISP site is a set of routers in an edge
network that are under a single technical administration. LISP network that are under a single technical administration. LISP
routers that reside in the edge network are the demarcation points routers that reside in the edge network are the demarcation points
to separate the edge network from the core network.</t> to separate the edge network from the core network.</dd>
<dt pn="section-3-1.27">Locator-Status-Bits (LSBs):</dt>
<t hangText="Locator-Status-Bits (LSBs):"> Locator-Status-Bits are <dd pn="section-3-1.28"> Locator-Status-Bits are
present in the LISP header. They are used by ITRs to inform ETRs present in the LISP header. They are used by ITRs to inform ETRs
about the up/down status of all ETRs at the local site. These bits about the up/down status of all ETRs at the local site. These bits
are used as a hint to convey up/down router status and not path are used as a hint to convey up/down router status and not path
reachability status. The LSBs can be verified by use of one of the reachability status. The LSBs can be verified by use of one of the
Locator reachability algorithms described in <xref Locator reachability algorithms described in <xref target="loc-reach" format
target="loc-reach" />. An ETR MUST rate-limit the action it takes ="default" sectionFormat="of" derivedContent="Section 10"/>. An ETR <bcp14>MUST<
when it detects changes in the Locator-Status-Bits.</t> /bcp14> rate limit the action it takes
when it detects changes in the Locator-Status-Bits.</dd>
<t hangText="Proxy-ETR (PETR): ">A PETR is defined and described <dt pn="section-3-1.29">Proxy-ETR (PETR): </dt>
in <xref target="RFC6832" />. A PETR acts like an ETR but does so <dd pn="section-3-1.30">A PETR is defined and described
in <xref target="RFC6832" format="default" sectionFormat="of" derivedContent
="RFC6832"/>. A PETR acts like an ETR but does so
on behalf of LISP sites that send packets to destinations at on behalf of LISP sites that send packets to destinations at
non-LISP sites.</t> non-LISP sites.</dd>
<dt pn="section-3-1.31">Proxy-ITR (PITR): </dt>
<t hangText="Proxy-ITR (PITR): ">A PITR is defined and described <dd pn="section-3-1.32">A PITR is defined and described
in <xref target="RFC6832" />. A PITR acts like an ITR but does so in <xref target="RFC6832" format="default" sectionFormat="of" derivedContent
="RFC6832"/>. A PITR acts like an ITR but does so
on behalf of non-LISP sites that send packets to destinations at on behalf of non-LISP sites that send packets to destinations at
LISP sites.</t> LISP sites.</dd>
<dt pn="section-3-1.33">Recursive Tunneling: </dt>
<t hangText="Recursive Tunneling: ">Recursive Tunneling occurs <dd pn="section-3-1.34">Recursive Tunneling occurs
when a packet has more than one LISP IP header. Additional layers when a packet has more than one LISP IP header. Additional layers
of tunneling MAY be employed to implement Traffic Engineering or of tunneling <bcp14>MAY</bcp14> be employed to implement Traffic Engineering
other re-routing as needed. When this is done, an additional or
other rerouting as needed. When this is done, an additional
"outer" LISP header is added, and the original RLOCs are preserved "outer" LISP header is added, and the original RLOCs are preserved
in the "inner" header.</t> in the "inner" header.</dd>
<dt pn="section-3-1.35">Re-encapsulating Tunneling Router (RTR): </dt>
<t hangText="Re-Encapsulating Tunneling Router (RTR): "> <dd pn="section-3-1.36">
An RTR acts like an ETR to remove a LISP header, then acts as an An RTR acts like an ETR to remove a LISP header, then acts as an
ITR to prepend a new LISP header. This is known as ITR to prepend a new LISP header. This is known as
Re-encapsulating Tunneling. Doing this allows a packet to be Re-encapsulating Tunneling. Doing this allows a packet to be
re-routed by the RTR without adding the overhead of additional rerouted by the RTR without adding the overhead of additional
tunnel headers. When using multiple mapping database systems, care tunnel headers. When using multiple mapping database systems, care
must be taken to not create re- encapsulation loops through must be taken to not create re-encapsulation loops through
misconfiguration.</t> misconfiguration.</dd>
<dt pn="section-3-1.37">Route-Returnability:</dt>
<t hangText="Route-Returnability:">Route-returnability is an <dd pn="section-3-1.38">Route-returnability is an
assumption that the underlying routing system will deliver packets assumption that the underlying routing system will deliver packets
to the destination. When combined with a nonce that is provided by to the destination. When combined with a nonce that is provided by
a sender and returned by a receiver, this limits off-path data a sender and returned by a receiver, this limits off-path data
insertion. A route-returnability check is verified when a message insertion. A route-returnability check is verified when a message
is sent with a nonce, another message is returned with the same is sent with a nonce, another message is returned with the same
nonce, and the destination of the original message appears as the nonce, and the destination of the original message appears as the
source of the returned message.</t> source of the returned message.</dd>
<dt pn="section-3-1.39">Routing Locator (RLOC): </dt>
<t hangText="Routing Locator (RLOC): ">An RLOC is an IPv4 <xref <dd pn="section-3-1.40">An RLOC is an IPv4 address <xref target="RFC0791
target="RFC0791" /> or IPv6 <xref target="RFC8200" /> address of " format="default" sectionFormat="of" derivedContent="RFC0791"/> or IPv6 address
<xref target="RFC8200" format="default" sectionFormat="of" derivedContent="RFC8
200"/> of
an Egress Tunnel Router (ETR). An RLOC is the output of an an Egress Tunnel Router (ETR). An RLOC is the output of an
EID-to-RLOC mapping lookup. An EID maps to zero or more EID-to-RLOC mapping lookup. An EID maps to zero or more
RLOCs. Typically, RLOCs are numbered from blocks that RLOCs. Typically, RLOCs are numbered from blocks that
are assigned to a site at each point to which it attaches to the are assigned to a site at each point to which it attaches to the
underlay network; where the topology is defined by the connectivity underlay network, where the topology is defined by the connectivity
of provider networks. Multiple RLOCs can be assigned to the same of provider networks. Multiple RLOCs can be assigned to the same
ETR device or to multiple ETR devices at a site.</t> ETR device or to multiple ETR devices at a site.</dd>
<dt pn="section-3-1.41">Server-side:</dt>
<t hangText="Server-side:">Server-side is a term used in this <dd pn="section-3-1.42">"Server-side" is a term used in this
document to indicate that a connection initiation attempt is being document to indicate that a connection initiation attempt is being
accepted for a destination EID.</t> accepted for a destination EID.</dd>
<dt pn="section-3-1.43">xTR: </dt>
<t hangText="xTR: ">An xTR is a reference to an ITR or ETR when <dd pn="section-3-1.44">An xTR is a reference to an ITR or ETR when
direction of data flow is not part of the context description. direction of data flow is not part of the context description.
"xTR" refers to the router that is the tunnel endpoint and is used "xTR" refers to the router that is the tunnel endpoint and is used
synonymously with the term "Tunnel Router". For example, "An xTR synonymously with the term "Tunnel Router". For example, "An xTR
can be located at the Customer Edge (CE) router" indicates both can be located at the Customer Edge (CE) router" indicates both
ITR and ETR functionality at the CE router.</t> ITR and ETR functionality at the CE router.</dd>
</dl>
</list></t> </section>
</section> <section anchor="OVERVIEW" numbered="true" toc="include" removeInRFC="false"
pn="section-4">
<section title="Basic Overview" anchor="OVERVIEW"> <name slugifiedName="name-basic-overview">Basic Overview</name>
<t>One key concept of LISP is that end-systems operate the same way <t indent="0" pn="section-4-1">One key concept of LISP is that end-systems
they do today. The IP addresses that hosts use for tracking sockets operate the same way
when LISP is not in use as well as when LISP is in use. The IP addresses t
hat
hosts use for tracking sockets
and connections, and for sending and receiving packets, do not and connections, and for sending and receiving packets, do not
change. In LISP terminology, these IP addresses are called Endpoint change. In LISP terminology, these IP addresses are called Endpoint
Identifiers (EIDs).</t> Identifiers (EIDs).</t>
<t indent="0" pn="section-4-2">Routers continue to forward packets based o
<t>Routers continue to forward packets based on IP destination n IP destination
addresses. When a packet is LISP encapsulated, these addresses are addresses. When a packet is LISP encapsulated, these addresses are
referred to as Routing Locators (RLOCs). Most routers along a path referred to as RLOCs. Most routers along a path
between two hosts will not change; they continue to perform between two hosts will not change; they continue to perform
routing/forwarding lookups on the destination addresses. For routers routing/forwarding lookups on the destination addresses. For routers
between the source host and the ITR as well as routers from the ETR between the source host and the ITR as well as routers from the ETR
to the destination host, the destination address is an EID. For the to the destination host, the destination address is an EID. For the
routers between the ITR and the ETR, the destination address is an routers between the ITR and the ETR, the destination address is an
RLOC.</t> RLOC.</t>
<t indent="0" pn="section-4-3">Another key LISP concept is the "Tunnel Rou
<t>Another key LISP concept is the "Tunnel Router". A Tunnel Router ter". A Tunnel Router
prepends LISP headers on host-originated packets and strips them prepends LISP headers on host-originated packets and strips them
prior to final delivery to their destination. The IP addresses in prior to final delivery to their destination. The IP addresses in
this &quot;outer header&quot; are RLOCs. During end-to-end packet this "outer header" are RLOCs. During end-to-end packet
exchange between two Internet hosts, an ITR prepends a new LISP exchange between two Internet hosts, an ITR prepends a new LISP
header to each packet, and an ETR strips the new header. The ITR header to each packet, and an ETR strips the new header. The ITR
performs EID-to-RLOC lookups to determine the routing path to the performs EID-to-RLOC lookups to determine the routing path to the
ETR, which has the RLOC as one of its IP addresses. </t> ETR, which has the RLOC as one of its IP addresses. </t>
<t indent="0" pn="section-4-4">Some basic rules governing LISP are:</t>
<t>Some basic rules governing LISP are:</t> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4-5
<t><list style="symbols"> ">
<t>End-systems only send to addresses that are EIDs. EIDs are <li pn="section-4-5.1">End-systems only send to addresses that are EIDs.
typically IP addresses assigned to hosts (other types of EID are EIDs are
supported by LISP, see <xref target="RFC8060"/> for further typically IP addresses assigned to hosts (other types of EIDs are
supported by LISP; see <xref target="RFC8060" format="default" sectionForm
at="of" derivedContent="RFC8060"/> for further
information). End-systems don't know that addresses are EIDs information). End-systems don't know that addresses are EIDs
versus RLOCs but assume that packets get to their intended versus RLOCs but assume that packets get to their intended
destinations. In a system where LISP is deployed, LISP routers destinations. In a system where LISP is deployed, LISP routers
intercept EID-addressed packets and assist in delivering them intercept EID-addressed packets and assist in delivering them
across the network core where EIDs cannot be routed. The across the network core where EIDs cannot be routed. The
procedure a host uses to send IP packets does not change.</t> procedure a host uses to send IP packets does not change.</li>
<li pn="section-4-5.2">LISP routers prepend and strip outer headers with
<t>LISP routers mostly deal with Routing Locator addresses. See RLOC addresses. See <xref target="MOSTLY" format="default" sectionFormat="of"
details in <xref target="MOSTLY" /> to clarify what is meant by derivedContent="Section 4.2"/> for details.</li>
&quot;mostly&quot;.</t> <li pn="section-4-5.3">RLOCs are always IP addresses assigned to routers
, preferably
<t>RLOCs are always IP addresses assigned to routers, preferably topologically oriented addresses from provider Classless
topologically oriented addresses from provider CIDR (Classless Inter-Domain Routing (CIDR) blocks. </li>
Inter-Domain Routing) blocks. </t> <li pn="section-4-5.4">When a router originates packets, it <bcp14>MAY</
bcp14> use as a source
<t>When a router originates packets, it MAY use as a source
address either an EID or RLOC. When acting as a host (e.g., when address either an EID or RLOC. When acting as a host (e.g., when
terminating a transport session such as Secure SHell (SSH), terminating a transport session such as Secure Shell (SSH),
TELNET, or the Simple Network Management Protocol (SNMP)), it TELNET, or the Simple Network Management Protocol (SNMP)), it
MAY use an EID that is explicitly assigned for that purpose. An <bcp14>MAY</bcp14> use an EID that is explicitly assigned for that purpose
EID that identifies the router as a host MUST NOT be used as an . An
EID that identifies the router as a host <bcp14>MUST NOT</bcp14> be used a
s an
RLOC; an EID is only routable within the scope of a site. A RLOC; an EID is only routable within the scope of a site. A
typical BGP configuration might demonstrate this "hybrid" typical BGP configuration might demonstrate this "hybrid"
EID/RLOC usage where a router could use its "host-like" EID to EID/RLOC usage where a router could use its "host-like" EID to
terminate iBGP sessions to other routers in a site while at the terminate internal BGP (iBGP) sessions to other routers in a site while at
same time using RLOCs to terminate eBGP sessions to routers the
outside the site.</t> same time using RLOCs to terminate external BGP (eBGP) sessions to routers
outside the site.</li>
<t>Packets with EIDs in them are not expected to be delivered <li pn="section-4-5.5">Packets with EIDs in them are not expected to be
end-to-end in the absence of an EID-to-RLOC mapping delivered
end to end in the absence of an EID-to-RLOC mapping
operation. They are expected to be used locally for intra-site operation. They are expected to be used locally for intra-site
communication or to be encapsulated for inter-site communication or to be encapsulated for inter-site
communication.</t> communication.</li>
<li pn="section-4-5.6">EIDs <bcp14>MAY</bcp14> also be structured (subne
<t>EIDs MAY also be structured (subnetted) in a manner suitable tted) in a manner suitable
for local routing within an Autonomous System (AS).</t> for local routing within an Autonomous System (AS).</li>
</list></t> </ul>
<t indent="0" pn="section-4-6">An additional LISP header <bcp14>MAY</bcp14
<t>An additional LISP header MAY be prepended to packets by a > be prepended to packets by a
TE-ITR when re-routing of the path for a packet is desired. A TE-ITR when rerouting of the path for a packet is desired. A
potential use-case for this would be an ISP router that needs to potential use case for this would be an ISP router that needs to
perform Traffic Engineering for packets flowing through its perform Traffic Engineering for packets flowing through its
network. In such a situation, termed "Recursive Tunneling", an ISP network. In such a situation, termed "Recursive Tunneling", an ISP
transit acts as an additional ITR, and the destination RLOC it transit acts as an additional ITR, and the destination RLOC it
uses for the new prepended header would be either a TE-ETR within uses for the new prepended header would be either a TE-ETR within
the ISP (along an intra-ISP traffic engineered path) or a TE-ETR the ISP (along an intra-ISP traffic-engineered path) or a TE-ETR
within another ISP (an inter-ISP traffic engineered path, where an within another ISP (an inter-ISP traffic-engineered path, where an
agreement to build such a path exists). </t> agreement to build such a path exists). </t>
<t indent="0" pn="section-4-7">In order to avoid excessive packet overhead
<t>In order to avoid excessive packet overhead as well as possible as well as possible
encapsulation loops, this document RECOMMENDS that a maximum of two encapsulation loops, it is <bcp14>RECOMMENDED</bcp14> that a maximum of two
LISP headers can be prepended to a packet. For initial LISP LISP headers can be prepended to a packet. For initial LISP
deployments, it is assumed that two headers is sufficient, where deployments, it is assumed that two headers is sufficient, where
the first prepended header is used at a site for Location/Identity the first prepended header is used at a site for separation of location and
separation and the second prepended header is used inside a identity and the second prepended header is used inside a
service provider for Traffic Engineering purposes.</t> service provider for Traffic Engineering purposes.</t>
<t indent="0" pn="section-4-8">Tunnel Routers can be placed fairly flexibl
<t>Tunnel Routers can be placed fairly flexibly in a multi-AS y in a multi-AS
topology. For example, the ITR for a particular end-to-end packet topology. For example, the ITR for a particular end-to-end packet
exchange might be the first-hop or default router within a site exchange might be the first-hop or default router within a site
for the source host. Similarly, the ETR might be the last-hop for the source host. Similarly, the ETR might be the last-hop
router directly connected to the destination host. Another router directly connected to the destination host. As another
example, perhaps for a VPN service outsourced to an ISP by a site, example, perhaps for a VPN service outsourced to an ISP by a site,
the ITR could be the site&apos;s border router at the service the ITR could be the site's border router at the service
provider attachment point. Mixing and matching of site-operated, provider attachment point. Mixing and matching of site-operated,
ISP-operated, and other Tunnel Routers is allowed for maximum ISP-operated, and other Tunnel Routers is allowed for maximum
flexibility. </t> flexibility. </t>
<section anchor="DPI" numbered="true" toc="include" removeInRFC="false" pn
<section title="Deployment on the Public Internet" anchor="DPI"> ="section-4.1">
<t>Several of the mechanisms in this document are intended for deployme <name slugifiedName="name-deployment-on-the-public-in">Deployment on the
nt in controlled, Public Internet</name>
trusted environments, and are insecure for use over the public Intern <t indent="0" pn="section-4.1-1">Several of the mechanisms in this docum
et. ent are intended for deployment in controlled,
In particular, on the public internet xTRs:</t> trusted environments and are insecure for use over the public Interne
t.
<t><list style="symbols"> In particular, on the public Internet, xTRs:</t>
<t>MUST set the N, L, E, and V bits in the LISP header (<xref targe <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4
t="header"/>) to zero.</t> .1-2">
<t>MUST NOT use Locator-Status-Bits and echo-nonce, as described in <li pn="section-4.1-2.1">
<xref target="loc-reach"/> for Routing Locator Reachability. <bcp14>MUST</bcp14> set the N-, L-, E-, and V-bits in the LISP heade
Instead MUST rely solely on control-plane methods.</t> r (<xref target="header" format="default" sectionFormat="of" derivedContent="Sec
<t>MUST NOT use Gleaning or Locator-Status-Bits and Map-Versioning, tion 5.1"/>) to zero.</li>
as described in <xref target="update_mapping"/> to update the EID-to-RLOC Mappi <li pn="section-4.1-2.2">
ngs. <bcp14>MUST NOT</bcp14> use Locator-Status-Bits and Echo-Nonce, as d
Instead relying solely on control-plane methods.</t> escribed in <xref target="loc-reach" format="default" sectionFormat="of" derived
</list></t> Content="Section 10"/>, for RLOC reachability.
Instead, they <bcp14>MUST</bcp14> rely solely on control plane meth
</section> ods.</li>
<li pn="section-4.1-2.3">
<section title="Packet Flow Sequence" anchor="MOSTLY"> <bcp14>MUST NOT</bcp14> use gleaning or Locator-Status-Bits and Map-
<t>This section provides an example of the unicast packet flow, Versioning, as described in <xref target="update_mapping" format="default" secti
including also Control-Plane information as specified in <xref onFormat="of" derivedContent="Section 13"/>, to update the EID-to-RLOC mappings.
target="I-D.ietf-lisp-rfc6833bis"/>. The example also assumes Instead, they <bcp14>MUST</bcp14> rely solely on control plane me
thods.</li>
</ul>
</section>
<section anchor="MOSTLY" numbered="true" toc="include" removeInRFC="false"
pn="section-4.2">
<name slugifiedName="name-packet-flow-sequence">Packet Flow Sequence</na
me>
<t indent="0" pn="section-4.2-1">This section provides an example of the
unicast packet flow,
also including control plane information as specified in <xref target="RFC
9301" format="default" sectionFormat="of" derivedContent="RFC9301"/>. The examp
le also assumes
the following conditions:</t> the following conditions:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4
<t><list style="symbols"> .2-2">
<t>Source host &quot;host1.abc.example.com&quot; is sending a <li pn="section-4.2-2.1">Source host "host1.abc.example.com" is sendin
packet to &quot;host2.xyz.example.com&quot;, exactly as it would if the g a
site was not packet to "host2.xyz.example.com", exactly as it would if the site was
not using LISP.</t> not using LISP.</li>
<li pn="section-4.2-2.2">Each site is multihomed, so each Tunnel Route
<t>Each site is multihomed, so each Tunnel Router has an r has an
address (RLOC) assigned from the service provider address address (RLOC) assigned from the service provider address
block for each provider to which that particular Tunnel Router block for each provider to which that particular Tunnel Router
is attached.</t> is attached.</li>
<li pn="section-4.2-2.3">The ITR(s) and ETR(s) are directly connected
<t>The ITR(s) and ETR(s) are directly connected to the source to the source
and destination, respectively, but the source and destination and destination, respectively, but the source and destination
can be located anywhere in the LISP site.</t> can be located anywhere in the LISP site.</li>
<li pn="section-4.2-2.4">A Map-Request is sent for an external destina
<t>A Map-Request is sent for an external destination when the tion when the
destination is not found in the forwarding table or matches a destination is not found in the forwarding table or matches a
default route. Map-Requests are sent to the mapping database default route. Map-Requests are sent to the mapping database
system by using the LISP Control-Plane protocol documented in system by using the LISP control plane protocol documented in
<xref target="I-D.ietf-lisp-rfc6833bis"/>.</t> <xref target="RFC9301" format="default" sectionFormat="of" derivedConten
t="RFC9301"/>.</li>
<t>Map-Replies are sent on the underlying routing system <li pn="section-4.2-2.5">Map-Replies are sent on the underlying routin
topology using the <xref target="I-D.ietf-lisp-rfc6833bis"/> g system
Control-Plane protocol.</t> topology, using the
</list></t> control plane protocol <xref target="RFC9301" format="default" sectionFo
rmat="of" derivedContent="RFC9301"/>.</li>
<t>Client host1.abc.example.com wants to communicate with </ul>
<t indent="0" pn="section-4.2-3">Client host1.abc.example.com wants to c
ommunicate with
server host2.xyz.example.com:</t> server host2.xyz.example.com:</t>
<ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-4.
<t><list style="numbers"> 2-4">
<li pn="section-4.2-4.1" derivedCounter="1.">host1.abc.example.com want
<t>host1.abc.example.com wants to open a TCP connection to s to open a TCP connection to
host2.xyz.example.com. It does a DNS lookup on host2.xyz.example.com. It does a DNS lookup on
host2.xyz.example.com. An A/AAAA record is returned. This host2.xyz.example.com. An A/AAAA record is returned. This
address is the destination EID. The locally assigned address address is the destination EID. The locally assigned address
of host1.abc.example.com is used as the source EID. An IPv4 of host1.abc.example.com is used as the source EID. An IPv4
or IPv6 packet is built and forwarded through the LISP site or IPv6 packet is built and forwarded through the LISP site
as a normal IP packet until it reaches a LISP ITR.</t> as a normal IP packet until it reaches a LISP ITR.</li>
<li pn="section-4.2-4.2" derivedCounter="2.">The LISP ITR must be able
<t>The LISP ITR must be able to map the destination EID to an to map the destination EID to an
RLOC of one of the ETRs at the destination site. A method RLOC of one of the ETRs at the destination site. A method
to do this is to send a LISP Map-Request, as specified in for doing this is to send a LISP Map-Request, as specified in
<xref target="I-D.ietf-lisp-rfc6833bis"/>.</t> <xref target="RFC9301" format="default" sectionFormat="of" derivedConte
nt="RFC9301"/>.</li>
<t>The mapping system helps forwarding the Map-Request to the <li pn="section-4.2-4.3" derivedCounter="3.">The Mapping System helps
forward the Map-Request to the
corresponding ETR. When the Map-Request arrives at one of the corresponding ETR. When the Map-Request arrives at one of the
ETRs at the destination site, it will process the packet as a ETRs at the destination site, it will process the packet as a
control message.</t> control message.</li>
<li pn="section-4.2-4.4" derivedCounter="4.">The ETR looks at the dest
<t>The ETR looks at the destination EID of the Map-Request ination EID of the Map-Request
and matches it against the prefixes in the ETR's configured and matches it against the prefixes in the ETR's configured
EID-to-RLOC mapping database. This is the list of EID-to-RLOC mapping database. This is the list of
EID-Prefixes the ETR is supporting for the site it resides EID-Prefixes the ETR is supporting for the site it resides
in. If there is no match, the Map-Request is in. If there is no match, the Map-Request is
dropped. Otherwise, a LISP Map-Reply is returned to the dropped. Otherwise, a LISP Map-Reply is returned to the
ITR.</t> ITR.</li>
<li pn="section-4.2-4.5" derivedCounter="5.">The ITR receives the Map-
<t>The ITR receives the Map-Reply message, parses the message, Reply message, parses the message,
and stores the mapping information from the packet. This informa tion and stores the mapping information from the packet. This informa tion
is stored in the ITR&apos;s EID-to-RLOC Map-Cache. Note that th e is stored in the ITR's EID-to-RLOC Map-Cache. Note that the
Map-Cache is an on-demand cache. An ITR will manage its Map-Cache is an on-demand cache. An ITR will manage its
Map-Cache in such a way that optimizes for its resource Map-Cache in such a way that optimizes for its resource
constraints.</t> constraints.</li>
<li pn="section-4.2-4.6" derivedCounter="6.">Subsequent packets from h
<t>Subsequent packets from host1.abc.example.com to ost1.abc.example.com to
host2.xyz.example.com will have a LISP header prepended by host2.xyz.example.com will have a LISP header prepended by
the ITR using the appropriate RLOC as the LISP header the ITR using the appropriate RLOC as the LISP header
destination address learned from the ETR. Note that the destination address learned from the ETR. Note that the
packet MAY be sent to a different ETR than the one that packet <bcp14>MAY</bcp14> be sent to a different ETR than the one that
returned the Map-Reply due to the source site's hashing returned the Map-Reply due to the source site's hashing
policy or the destination site's Locator-Set policy.</t> policy or the destination site's Locator-Set policy.</li>
<li pn="section-4.2-4.7" derivedCounter="7.">The ETR receives these pa
<t>The ETR receives these packets directly (since the ckets directly (since the
destination address is one of its assigned IP addresses), destination address is one of its assigned IP addresses),
checks the validity of the addresses, strips the LISP header, checks the validity of the addresses, strips the LISP header,
and forwards packets to the attached destination host.</t> and forwards packets to the attached destination host.</li>
<li pn="section-4.2-4.8" derivedCounter="8.">In order to defer the nee
<t>In order to defer the need for a mapping lookup in the d for a mapping lookup in the
reverse direction, an ETR can OPTIONALLY create a cache entry reverse direction, it is <bcp14>OPTIONAL</bcp14> for an ETR to
create a cache entry
that maps the source EID (inner-header source IP address) to that maps the source EID (inner-header source IP address) to
the source RLOC (outer-header source IP address) in a the source RLOC (outer-header source IP address) in a
received LISP packet. Such a cache entry is termed a received LISP packet. Such a cache entry is termed a
"glean mapping" and only contains a single RLOC for the EID "glean mapping" and only contains a single RLOC for the EID
in question. More complete information about additional in question. More complete information about additional
RLOCs SHOULD be verified by sending a LISP Map-Request for RLOCs <bcp14>SHOULD</bcp14> be verified by sending a LISP Map-Request f
that EID. Both the ITR and the ETR MAY also influence the or
decision the other makes in selecting an RLOC.</t> that EID. Both the ITR and the ETR <bcp14>MAY</bcp14> also influence th
</list></t> e
</section> decision the other makes in selecting an RLOC.</li>
</section> </ol>
</section>
<section title="LISP Encapsulation Details"> </section>
<t>Since additional tunnel headers are prepended, the packet <section numbered="true" toc="include" removeInRFC="false" pn="section-5">
<name slugifiedName="name-lisp-encapsulation-details">LISP Encapsulation D
etails</name>
<t indent="0" pn="section-5-1">Since additional tunnel headers are prepend
ed, the packet
becomes larger and can exceed the MTU of any link traversed from becomes larger and can exceed the MTU of any link traversed from
the ITR to the ETR. It is RECOMMENDED in IPv4 that packets do not the ITR to the ETR. It is <bcp14>RECOMMENDED</bcp14> in IPv4 that packets d o not
get fragmented as they are encapsulated by the ITR. Instead, the get fragmented as they are encapsulated by the ITR. Instead, the
packet is dropped and an ICMP Unreachable/Fragmentation-Needed packet is dropped and an ICMPv4 Unreachable / Fragmentation Needed
message is returned to the source.</t> message is returned to the source.</t>
<t indent="0" pn="section-5-2">In the case when fragmentation is needed, i
<t>In the case when fragmentation is needed, this specification t is
RECOMMENDS that implementations provide support for one of the <bcp14>RECOMMENDED</bcp14> that implementations provide support for one of t
he
proposed fragmentation and reassembly schemes. Two existing proposed fragmentation and reassembly schemes. Two existing
schemes are detailed in <xref target="fragment" />.</t> schemes are detailed in <xref target="fragment" format="default" sectionForm
at="of" derivedContent="Section 7"/>.</t>
<t>Since IPv4 or IPv6 addresses can be either EIDs or RLOCs, the <t indent="0" pn="section-5-3">Since IPv4 or IPv6 addresses can be either
EIDs or RLOCs, the
LISP architecture supports IPv4 EIDs with IPv6 RLOCs (where the LISP architecture supports IPv4 EIDs with IPv6 RLOCs (where the
inner header is in IPv4 packet format and the outer header is in inner header is in IPv4 packet format and the outer header is in
IPv6 packet format) or IPv6 EIDs with IPv4 RLOCs (where the inner IPv6 packet format) or IPv6 EIDs with IPv4 RLOCs (where the inner
header is in IPv6 packet format and the outer header is in IPv4 header is in IPv6 packet format and the outer header is in IPv4
packet format). The next sub-sections illustrate packet formats packet format). The next sub-sections illustrate packet formats
for the homogeneous case (IPv4-in-IPv4 and IPv6-in-IPv6), but all for the homogeneous case (IPv4-in-IPv4 and IPv6-in-IPv6), but all
4 combinations MUST be supported. Additional types of EIDs are 4 combinations <bcp14>MUST</bcp14> be supported. Additional types of EIDs ar
defined in <xref target="RFC8060" />.</t> e
defined in <xref target="RFC8060" format="default" sectionFormat="of" derive
<t>As LISP uses UDP encapsulation to carry traffic between xTRs dContent="RFC8060"/>.</t>
<t indent="0" pn="section-5-4">As LISP uses UDP encapsulation to carry tra
ffic between xTRs
across the Internet, implementors should be aware of the across the Internet, implementors should be aware of the
provisions of <xref target="RFC8085"/>, especially those given in provisions of <xref target="RFC8085" format="default" sectionFormat="of" der
section 3.1.11 on congestion control for UDP tunneling.</t> ivedContent="RFC8085"/>, especially those given in its
Section <xref target="RFC8085" section="3.1.11" sectionFormat="bare" format=
<t>Implementors are encouraged to consider UDP checksum usage "default" derivedLink="https://rfc-editor.org/rfc/rfc8085#section-3.1.11" derive
guidelines in section 3.4 of <xref target="RFC8085"/> when it is dContent="RFC8085"/> on congestion control for UDP tunneling.</t>
<t indent="0" pn="section-5-5">Implementors are encouraged to consider UDP
checksum usage
guidelines in <xref target="RFC8085" sectionFormat="of" section="3.4" format
="default" derivedLink="https://rfc-editor.org/rfc/rfc8085#section-3.4" derivedC
ontent="RFC8085"/> when it is
desirable to protect UDP and LISP headers against corruption.</t> desirable to protect UDP and LISP headers against corruption.</t>
<section anchor="header" numbered="true" toc="include" removeInRFC="false"
<section title="LISP IPv4-in-IPv4 Header Format" anchor="header"> pn="section-5.1">
<figure> <artwork><![CDATA[ <name slugifiedName="name-lisp-ipv4-in-ipv4-header-fo">LISP IPv4-in-IPv4
Header Format</name>
<artwork name="" type="" align="left" alt="" pn="section-5.1-1">
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |Version| IHL | DSCP |ECN| Total Length | / |Version| IHL | DSCP |ECN| Total Length |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Identification |Flags| Fragment Offset | | | Identification |Flags| Fragment Offset |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OH | Time to Live | Protocol = 17 | Header Checksum | OH | Time to Live | Protocol = 17 | Header Checksum |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Source Routing Locator | | | Source Routing Locator |
skipping to change at line 610 skipping to change at line 729
| | Identification |Flags| Fragment Offset | | | Identification |Flags| Fragment Offset |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IH | Time to Live | Protocol | Header Checksum | IH | Time to Live | Protocol | Header Checksum |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Source EID | | | Source EID |
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | Destination EID | \ | Destination EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IHL = IP-Header-Length IHL = IP-Header-Length
]]></artwork> </figure> </artwork>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-5.2
<section title="LISP IPv6-in-IPv6 Header Format"> ">
<figure> <artwork><![CDATA[ <name slugifiedName="name-lisp-ipv6-in-ipv6-header-fo">LISP IPv6-in-IPv6
Header Format</name>
<artwork name="" type="" align="left" alt="" pn="section-5.2-1">
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |Version| DSCP |ECN| Flow Label | / |Version| DSCP |ECN| Flow Label |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Payload Length | Next Header=17| Hop Limit | | | Payload Length | Next Header=17| Hop Limit |
v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
O + + O + +
u | | u | |
skipping to change at line 666 skipping to change at line 785
| | | |
H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
d | | d | |
r + + r + +
| | | |
^ + Destination EID + ^ + Destination EID +
\ | | \ | |
\ + + \ + +
\ | | \ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> </figure> </artwork>
</section> </section>
<section anchor="LRB" numbered="true" toc="include" removeInRFC="false" pn
<section title="Tunnel Header Field Descriptions" anchor="LRB" > ="section-5.3">
<t><list style="hanging"> <t hangText="Inner Header <name slugifiedName="name-tunnel-header-field-descrip">Tunnel Header Fie
(IH):">The inner header is the header on the datagram ld Descriptions</name>
received from the originating host <xref target="RFC0791" /> <dl newline="false" spacing="normal" indent="3" pn="section-5.3-1">
<xref target="RFC8200" /> <xref target="RFC2474"/>. The <dt pn="section-5.3-1.1">Inner Header (IH):</dt>
source and destination IP addresses are EIDs.</t> <dd pn="section-5.3-1.2">The inner header is the header on the datagra
m
<t hangText="Outer Header: (OH)">The outer header is a new received from the originating host <xref target="RFC0791" format="defa
ult" sectionFormat="of" derivedContent="RFC0791"/>
<xref target="RFC8200" format="default" sectionFormat="of" derivedCo
ntent="RFC8200"/> <xref target="RFC2474" format="default" sectionFormat="of" der
ivedContent="RFC2474"/>. The
source and destination IP addresses are EIDs.</dd>
<dt pn="section-5.3-1.3">Outer Header (OH):</dt>
<dd pn="section-5.3-1.4">The outer header is a new
header prepended by an ITR. The address fields contain RLOCs header prepended by an ITR. The address fields contain RLOCs
obtained from the ingress router's EID-to-RLOC Cache. The IP obtained from the ingress router's EID-to-RLOC Map-Cache. The IP
protocol number is &quot;UDP (17)&quot; from <xref protocol number is "UDP (17)" from <xref target="RFC0768" format="defa
target="RFC0768" />. The setting of the Don't Fragment (DF) ult" sectionFormat="of" derivedContent="RFC0768"/>. The setting of the Don't Fr
agment (DF)
bit 'Flags' field is according to rules listed in Sections bit 'Flags' field is according to rules listed in Sections
<xref target="MTU-STATELESS" format="counter"/> and <xref <xref target="MTU-STATELESS" format="counter" sectionFormat="of" deriv
target="MTU-STATEFUL" format="counter"/>.</t> edContent="7.1"/> and <xref target="MTU-STATEFUL" format="counter" sectionFormat
="of" derivedContent="7.2"/>.</dd>
<t hangText="UDP Header:">The UDP header contains an ITR <dt pn="section-5.3-1.5">UDP Header:</dt>
selected source port when encapsulating a packet. See <xref <dd pn="section-5.3-1.6">The UDP header contains an ITR-selected sourc
target="loc-hash" /> for details on the hash algorithm used e port when encapsulating a packet. See <xref target="loc-hash" format="default"
sectionFormat="of" derivedContent="Section 12"/> for details on the hash algori
thm used
to select a source port based on the 5-tuple of the inner to select a source port based on the 5-tuple of the inner
header. The destination port MUST be set to the well-known header. The destination port <bcp14>MUST</bcp14> be set to the well-kn
IANA-assigned port value 4341.</t> own
IANA-assigned port value 4341.</dd>
<t hangText="UDP Checksum:">The 'UDP Checksum' field SHOULD <dt pn="section-5.3-1.7">UDP Checksum:</dt>
be transmitted as zero by an ITR for either IPv4 <xref <dd pn="section-5.3-1.8">The 'UDP Checksum' field <bcp14>SHOULD</bcp14
target="RFC0768" /> and IPv6 encapsulation <xref >
target="RFC6935" /> <xref target="RFC6936" />. When a be transmitted as zero by an ITR for either IPv4 <xref target="RFC0768
" format="default" sectionFormat="of" derivedContent="RFC0768"/> or IPv6 encapsu
lation <xref target="RFC6935" format="default" sectionFormat="of" derivedContent
="RFC6935"/> <xref target="RFC6936" format="default" sectionFormat="of" derivedC
ontent="RFC6936"/>. When a
packet with a zero UDP checksum is received by an ETR, the packet with a zero UDP checksum is received by an ETR, the
ETR MUST accept the packet for decapsulation. When an ITR ETR <bcp14>MUST</bcp14> accept the packet for decapsulation. When an
transmits a non-zero value for the UDP checksum, it MUST ITR
transmits a non-zero value for the UDP checksum, it <bcp14>MUST</bcp14
>
send a correctly computed value in this field. When an ETR send a correctly computed value in this field. When an ETR
receives a packet with a non-zero UDP checksum, it MAY receives a packet with a non-zero UDP checksum, it <bcp14>MAY</bcp14>
choose to verify the checksum value. If it chooses to choose to verify the checksum value. If it chooses to
perform such verification, and the verification fails, the perform such verification and the verification fails, the
packet MUST be silently dropped. If the ETR chooses not to packet <bcp14>MUST</bcp14> be silently dropped. If the ETR either cho
perform the verification, or performs the verification oses not to
successfully, the packet MUST be accepted for perform the verification or performs the verification
successfully, the packet <bcp14>MUST</bcp14> be accepted for
decapsulation. The handling of UDP zero checksums over IPv6 decapsulation. The handling of UDP zero checksums over IPv6
for all tunneling protocols, including LISP, is subject to for all tunneling protocols, including LISP, is subject to
the applicability statement in <xref target="RFC6936"/>.</t> the applicability statement in <xref target="RFC6936" format="default"
sectionFormat="of" derivedContent="RFC6936"/>.</dd>
<t hangText="UDP Length:">The 'UDP Length' field is set for <dt pn="section-5.3-1.9">UDP Length:</dt>
<dd pn="section-5.3-1.10">The 'UDP Length' field is set for
an IPv4-encapsulated packet to be the sum of the an IPv4-encapsulated packet to be the sum of the
inner-header IPv4 Total Length plus the UDP and LISP header inner-header IPv4 Total Length plus the UDP and LISP header
lengths. For an IPv6-encapsulated packet, the 'UDP Length' lengths. For an IPv6-encapsulated packet, the 'UDP Length'
field is the sum of the inner-header IPv6 Payload Length, field is the sum of the inner-header IPv6 Payload Length,
the size of the IPv6 header (40 octets), and the size of the the size of the IPv6 header (40 octets), and the size of the
UDP and LISP headers.</t> UDP and LISP headers.</dd>
<dt pn="section-5.3-1.11">N:</dt>
<t hangText="N:">The N-bit is the nonce-present bit. When <dd pn="section-5.3-1.12">The N-bit is the nonce-present bit. When
this bit is set to 1, the low-order 24 bits of the first 32 this bit is set to 1, the low-order 24 bits of the first 32
bits of the LISP header contain a Nonce. See <xref bits of the LISP header contain a nonce. See <xref target="echo-nonce"
target="echo-nonce"/> for details. Both N- and V-bits MUST format="default" sectionFormat="of" derivedContent="Section 10.1"/> for details
NOT be set in the same packet. If they are, a decapsulating . Both N- and V-bits <bcp14>MUST NOT</bcp14> be set in the same packet. If they
ETR MUST treat the 'Nonce/Map-Version' field as having a are, a decapsulating
Nonce value present.</t> ETR <bcp14>MUST</bcp14> treat the 'Nonce/Map-Version' field as having
a
<t hangText="L:">The L-bit is the 'Locator-Status-Bits' nonce value present.</dd>
<dt pn="section-5.3-1.13">L:</dt>
<dd pn="section-5.3-1.14">The L-bit is the 'Locator-Status-Bits'
field enabled bit. When this bit is set to 1, the field enabled bit. When this bit is set to 1, the
Locator-Status-Bits in the second 32&nbsp;bits of the LISP Locator-Status-Bits in the second 32 bits of the LISP
header are in use.</t> header are in use.</dd>
</list></t> </dl>
<artwork name="" type="" align="left" alt="" pn="section-5.3-2">
<figure> <artwork><![CDATA[ x 1 x x 0 x x x
x 1 x x 0 x x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|R|K|K| Nonce/Map-Version |
|N|L|E|V|I|R|K|K| Nonce/Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator-Status-Bits |
| Locator-Status-Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </artwork>
]]></artwork> </figure> <dl newline="false" spacing="normal" indent="3" pn="section-5.3-3">
<dt pn="section-5.3-3.1">E:</dt>
<t><list style="hanging"> <dd pn="section-5.3-3.2">The E-bit is the Echo-Nonce-request bit.
<t hangText="E:">The E-bit is the echo-nonce-request bit. This bit <bcp14>MUST</bcp14> be ignored and has no meaning when the N-
This bit MUST be ignored and has no meaning when the N-bit bit
is set to 0. When the N-bit is set to 1 and this bit is set is set to 0. When the N-bit is set to 1 and this bit is set
to 1, an ITR is requesting that the nonce value in the to 1, an ITR is requesting that the nonce value in the
'Nonce' field be echoed back in LISP-encapsulated packets 'Nonce' field be echoed back in LISP-encapsulated packets
when the ITR is also an ETR. See <xref target="echo-nonce"/> when the ITR is also an ETR. See <xref target="echo-nonce" format="def
for details.</t> ault" sectionFormat="of" derivedContent="Section 10.1"/>
for details.</dd>
<t hangText="V:">The V-bit is the Map-Version present <dt pn="section-5.3-3.3">V:</dt>
bit. When this bit is set to 1, the N-bit MUST be 0. Refer <dd pn="section-5.3-3.4">The V-bit is the Map-Version present
to <xref target="map-versioning" /> for more details. This bit. When this bit is set to 1, the N-bit <bcp14>MUST</bcp14> be 0. Re
fer
to <xref target="RFC9302" format="default" sectionFormat="of" derivedC
ontent="RFC9302"/> for more details on Database Map-Versioning. This
bit indicates that the LISP header is encoded in this bit indicates that the LISP header is encoded in this
case&nbsp;as:</t> case as:</dd>
</list></t> </dl>
<artwork name="" type="" align="left" alt="" pn="section-5.3-4">
<figure> <artwork><![CDATA[ 0 x 0 1 x x x x
0 x 0 1 x x x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|R|K|K| Source Map-Version | Dest Map-Version |
|N|L|E|V|I|R|K|K| Source Map-Version | Dest Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID/Locator-Status-Bits |
| Instance ID/Locator-Status-Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </artwork>
]]></artwork> </figure> <dl newline="false" spacing="normal" indent="3" pn="section-5.3-5">
<dt pn="section-5.3-5.1">I:</dt>
<t><list style="hanging"> <dd pn="section-5.3-5.2">The I-bit is the Instance ID bit. See <xref t
<t hangText="I:">The I-bit is the Instance ID bit. See <xref arget="instance" format="default" sectionFormat="of" derivedContent="Section 8"/
target="instance" /> for more details. When this bit is set > for more details. When this bit is set
to 1, the 'Locator-Status-Bits' field is reduced to 8 bits to 1, the 'Locator-Status-Bits' field is reduced to 8 bits
and the high-order 24 bits are used as an Instance ID. If and the high-order 24 bits are used as an Instance ID. If
the L-bit is set to 0, then the low-order 8&nbsp;bits are the L-bit is set to 0, then the low-order 8 bits are
transmitted as zero and ignored on receipt. The format of transmitted as zero and ignored on receipt. The format of
the LISP header would look like this:</t> the LISP header would look like this:</dd>
</list></t> </dl>
<artwork name="" type="" align="left" alt="" pn="section-5.3-6">
<figure> <artwork><![CDATA[ x x x x 1 x x x
x x x x 1 x x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|R|K|K| Nonce/Map-Version |
|N|L|E|V|I|R|K|K| Nonce/Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID | LSBs |
| Instance ID | LSBs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </artwork>
]]></artwork> </figure> <dl newline="false" spacing="normal" indent="3" pn="section-5.3-7">
<dt pn="section-5.3-7.1">R:</dt>
<t><list style="hanging"> <dd pn="section-5.3-7.2">The R-bit is a reserved and unassigned bit
<t hangText="R:">The R-bit is a Reserved and unassigned bit for future use. It <bcp14>MUST</bcp14> be set to 0 on transmit and <bc
for future use. It MUST be set to 0 on transmit and MUST be p14>MUST</bcp14> be
ignored on receipt.</t> ignored on receipt.</dd>
<dt pn="section-5.3-7.3">KK:</dt>
<t hangText="KK:">The KK-bits are a 2-bit field used when <dd pn="section-5.3-7.4">The KK-bits are a 2-bit field used when
encapsulated packets are encrypted. The field is set to 00 encapsulated packets are encrypted. The field is set to 00
when the packet is not encrypted. See <xref when the packet is not encrypted. See <xref target="RFC8061" format="
target="RFC8061" /> for further information.</t> default" sectionFormat="of" derivedContent="RFC8061"/> for further information.<
/dd>
<t hangText="LISP Nonce:">The LISP 'Nonce' field is a 24-bit <dt pn="section-5.3-7.5">LISP Nonce:</dt>
<dd pn="section-5.3-7.6">The LISP 'Nonce' field is a 24-bit
value that is randomly generated by an ITR when the N-bit is value that is randomly generated by an ITR when the N-bit is
set to 1. Nonce generation algorithms are an implementation set to 1. Nonce generation algorithms are an implementation
matter but are required to generate different nonces when matter but are required to generate different nonces when
sending to different RLOCs. The nonce is also used when the E-bit is set to sending to different RLOCs. The nonce is also used when the E-bit is set to
request the nonce value to be echoed by the other side when request the nonce value to be echoed by the other side when
packets are returned. When the E-bit is clear but the N-bit packets are returned. When the E-bit is clear but the N-bit
is set, a remote ITR is either echoing a previously is set, a remote ITR is either echoing a previously
requested echo-nonce or providing a random nonce. See <xref requested Echo-Nonce or providing a random nonce. See <xref target="ec
target="echo-nonce" /> for more details. Finally, when ho-nonce" format="default" sectionFormat="of" derivedContent="Section 10.1"/> fo
both the N and V-bit are not set (N=0, V=0), then both the Nonce r more details. Finally, when
and Map-Version fields are set to 0 and ignored on receipt.</t> both the N- and V-bits are not set (N=0, V=0), then both the 'Nonce'
and 'Map-Version' fields are set to 0 and ignored on receipt.</dd>
<t hangText="LISP Locator-Status-Bits (LSBs):">When the <dt pn="section-5.3-7.7">LISP Locator-Status-Bits (LSBs):</dt>
<dd pn="section-5.3-7.8">When the
L-bit is also set, the 'Locator-Status-Bits' field in the L-bit is also set, the 'Locator-Status-Bits' field in the
LISP header is set by an ITR to indicate to an ETR the LISP header is set by an ITR to indicate to an ETR the
up/down status of the Locators in the source site. Each RLOC up/down status of the Locators in the source site. Each RLOC
in a Map-Reply is assigned an ordinal value from 0 to n-1 in a Map-Reply is assigned an ordinal value from 0 to n-1
(when there are n RLOCs in a mapping entry). The (when there are n RLOCs in a mapping entry). The
Locator-Status-Bits are numbered from 0 to n-1 from the Locator-Status-Bits are numbered from 0 to n-1 from the
least significant bit of the field. The field is 32 bits least significant bit of the field. The field is 32 bits
when the I-bit is set to 0 and is 8 bits when the I-bit is when the I-bit is set to 0 and is 8 bits when the I-bit is
set to 1. When a Locator-Status-Bit is set to 1, the ITR is set to 1. When a Locator-Status-Bit is set to 1, the ITR is
indicating to the ETR that the RLOC associated with the bit indicating to the ETR that the RLOC associated with the bit
ordinal has up status. See <xref target="loc-reach" /> for ordinal has up status. See <xref target="loc-reach" format="default" s ectionFormat="of" derivedContent="Section 10"/> for
details on how an ITR can determine the status of the ETRs details on how an ITR can determine the status of the ETRs
at the same site. When a site has multiple EID-Prefixes at the same site. When a site has multiple EID-Prefixes
that result in multiple mappings (where each could have a that result in multiple mappings (where each could have a
different Locator-Set), the Locator-Status-Bits setting in different Locator-Set), the Locator-Status-Bits setting in
an encapsulated packet MUST reflect the mapping for the an encapsulated packet <bcp14>MUST</bcp14> reflect the mapping for the
EID-Prefix that the inner-header source EID address EID-Prefix that the inner-header source EID address
matches (longest-match). If the LSB for an anycast Locator is set to 1 , then matches (longest-match). If the LSB for an anycast Locator is set to 1 , then
there is at least one RLOC with that address, and the ETR is there is at least one RLOC with that address, and the ETR is
considered 'up'.</t> considered 'up'.</dd>
</list></t> </dl>
<t indent="0" pn="section-5.3-8">When doing ITR/PITR encapsulation:</t>
<t>When doing ITR/PITR encapsulation:</t> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5
.3-9">
<t><list style="symbols"> <li pn="section-5.3-9.1">The outer-header 'Time to Live' field (or 'Ho
<t>The outer-header 'Time to Live' field (or 'Hop Limit' p Limit'
field, in the case of IPv6) SHOULD be copied from the field, in the case of IPv6) <bcp14>SHOULD</bcp14> be copied from the
inner-header 'Time to Live' field. </t> inner-header 'Time to Live' field. </li>
<li pn="section-5.3-9.2">The outer-header IPv4 'Differentiated Service
<t>The outer-header IPv4 'Differentiated Services Code Point' s Code Point
(DSCP) field or the 'Traffic Class' field, in the case of (DSCP)' field (or 'Traffic Class' field, in the case of
IPv6, SHOULD be copied from the inner-header IPv4 DSCP field or IPv6) <bcp14>SHOULD</bcp14> be copied from the inner-header IPv4 '
'Traffic Class' field in the case of IPv6, to the DSCP' field (or
outer-header. Guidelines for this can be found at <xref target="RF 'Traffic Class' field, in the case of IPv6) to the
C2983"/>.</t> outer header. Guidelines for this can be found in <xref target="RF
C2983" format="default" sectionFormat="of" derivedContent="RFC2983"/>.</li>
<t>The IPv4 'Explicit Congestion Notification' (ECN) field and bits <li pn="section-5.3-9.3">The IPv4 'Explicit Congestion Notification (E
6 and 7 of the IPv6 'Traffic Class' field requires special CN)' field and bits
6 and 7 of the IPv6 'Traffic Class' field require special
treatment in order to avoid discarding indications of treatment in order to avoid discarding indications of
congestion as specified in <xref target="RFC6040"/>.</t> congestion as specified in <xref target="RFC6040" format="default" se
</list></t> ctionFormat="of" derivedContent="RFC6040"/>.</li>
</ul>
<t>When doing ETR/PETR decapsulation:</t> <t indent="0" pn="section-5.3-10">When doing ETR/PETR decapsulation:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5
<t><list style="symbols"> .3-11">
<t>The inner-header IPv4 'Time to Live' field or 'Hop Limit' <li pn="section-5.3-11.1">The inner-header IPv4 'Time to Live' field (
field in the case of IPv6, MUST be copied from the or 'Hop Limit'
outer-header 'Time to Live'/'Hop Limit' field, when the 'Time to Li field, in the case of IPv6) <bcp14>MUST</bcp14> be copied from the
ve'/'Hop Limit' outer-header 'Time to Live'/'Hop Limit' field when the Time to Live
value of the outer header is less than the 'Time to Live'/'Hop Limi / Hop Limit
t' value of the outer header is less than the Time to Live / Hop Limit
value of the inner header. Failing to perform this check value of the inner header. Failing to perform this check
can cause the 'Time to Live'/'Hop Limit' of the inner header to inc rement can cause the Time to Live / Hop Limit of the inner header to incre ment
across encapsulation/decapsulation cycles. This check is across encapsulation/decapsulation cycles. This check is
also performed when doing initial encapsulation, when a also performed when doing initial encapsulation, when a
packet comes to an ITR or PITR destined for a LISP site.</t> packet comes to an ITR or PITR destined for a LISP site.</li>
<li pn="section-5.3-11.2">The outer-header IPv4 'Differentiated Servic
<t>The outer-header IPv4 'Differentiated Services Code Point' es Code Point
(DSCP) field or the 'Traffic Class' field in the case of (DSCP)' field (or 'Traffic Class' field, in the case of
IPv6, SHOULD be copied from the outer-header IPv4 DSCP field or IPv6) <bcp14>SHOULD</bcp14> be copied from the outer-header 'IPv4 D
'Traffic Class' field in the case of IPv6, to the SCP' field (or
inner-header. Guidelines for this can be found at <xref target="RFC 'Traffic Class' field, in the case of IPv6) to the
2983"/>.</t> inner header. Guidelines for this can be found in <xref target="RFC
2983" format="default" sectionFormat="of" derivedContent="RFC2983"/>.</li>
<t>The IPv4 'Explicit Congestion Notification' (ECN) field and bits <li pn="section-5.3-11.3">The IPv4 'Explicit Congestion Notification (
6 and 7 of the IPv6 'Traffic Class' field, requires special ECN)' field and bits
6 and 7 of the IPv6 'Traffic Class' field require special
treatment in order to avoid discarding indications of treatment in order to avoid discarding indications of
congestion as specified in <xref target="RFC6040"/>. Note congestion as specified in <xref target="RFC6040" format="default" sec tionFormat="of" derivedContent="RFC6040"/>. Note
that implementations exist that copy the 'ECN' field from that implementations exist that copy the 'ECN' field from
the outer header to the inner header even though <xref the outer header to the inner header, even though <xref target="RFC604
target="RFC6040"/> does not recommend this behavior. It is 0" format="default" sectionFormat="of" derivedContent="RFC6040"/> does not recom
RECOMMENDED that implementations change to support the mend this behavior. It is
behavior in <xref target="RFC6040"/>.</t> <bcp14>RECOMMENDED</bcp14> that implementations change to support the
</list></t> behavior discussed in <xref target="RFC6040" format="default" sectionF
ormat="of" derivedContent="RFC6040"/>.</li>
<t>Note that if an ETR/PETR is also an ITR/PITR and chooses to </ul>
<t indent="0" pn="section-5.3-12">Note that if an ETR/PETR is also an IT
R/PITR and chooses to
re-encapsulate after decapsulating, the net effect of this re-encapsulate after decapsulating, the net effect of this
is that the new outer header will carry the same Time to is that the new outer header will carry the same Time to
Live as the old outer header minus 1.</t> Live as the old outer header minus 1.</t>
<t indent="0" pn="section-5.3-13">Copying the Time to Live serves two pu
<t>Copying the Time to Live (TTL) serves two purposes: rposes:
first, it preserves the distance the host intended the packet to first, it preserves the distance the host intended the packet to
travel; second, and more importantly, it provides for travel; second, and more importantly, it provides for
suppression of looping packets in the event there is a loop of suppression of looping packets in the event there is a loop of
concatenated tunnels due to misconfiguration.</t> concatenated tunnels due to misconfiguration.</t>
<t indent="0" pn="section-5.3-14"> Some xTRs, PETRs, and PITRs perform r
<t>Some xTRs and PxTRs performs re-encapsulation operations e-encapsulation operations and
and need to treat the 'Explicit Congestion Notification' (ECN) need to treat ECN functions in a special way. Because the re-encapsulatio
in a special way. Because the re-encapsulation operation is a n
operation is a
sequence of two operations, namely a decapsulation followed by sequence of two operations, namely a decapsulation followed by
an encapsulation, the ECN bits MUST be treated as described an encapsulation, the ECN bits <bcp14>MUST</bcp14> be treated as describ ed
above for these two operations.</t> above for these two operations.</t>
<t indent="0" pn="section-5.3-15">
<t> The LISP data plane protocol is not backwards compatible with
The LISP dataplane protocol is not backwards compatible with <xref target="RFC6830" format="default" sectionFormat="of" derive
<xref target="RFC6830"/> and does not have explicit support for i dContent="RFC6830"/> and does not have explicit support for introducing
ntroducing future protocol changes (e.g., an explicit version field). Howeve
future protocol changes (e.g. an explicit version field). However r,
, the LISP control plane <xref target="RFC9301" format="default" se
the LISP control plane <xref ctionFormat="of" derivedContent="RFC9301"/> allows an ETR to register
target="I-D.ietf-lisp-rfc6833bis"/> allows an ETR to register data plane capabilities by means of new LISP Canonical Address Fo
dataplane capabilities by means of new LCAF types <xref target="R rmat (LCAF) types <xref target="RFC8060" format="default" sectionFormat="of" der
FC8060"/>. ivedContent="RFC8060"/>.
In this way an ITR can be made aware of the dataplane capabilitie In this way, an ITR can be made aware of the data plane capabilit
s ies
of an ETR, and encapsulate accordingly. The specification of the of an ETR and encapsulate accordingly. The specification of the n
new ew
LCAF types, new LCAF mechanisms, and their use, is out of the LCAF types, the new LCAF mechanisms, and their use are out of the
scope of this document. scope of this document.
</t> </t>
</section>
</section> </section>
</section> <section anchor="Map-Cache" numbered="true" toc="include" removeInRFC="false
" pn="section-6">
<section title="LISP EID-to-RLOC Map-Cache" anchor="Map-Cache"> <name slugifiedName="name-lisp-eid-to-rloc-map-cache">LISP EID-to-RLOC Map
-Cache</name>
<t>ITRs and PITRs maintain an on-demand cache, referred as LISP <t indent="0" pn="section-6-1">ITRs and PITRs maintain an on-demand cache,
EID-to-RLOC Map-Cache, that contains mappings from EID-prefixes referred to as the LISP
to locator sets. The cache is used to encapsulate packets from EID-to-RLOC Map-Cache, that contains mappings from EID-Prefixes
to Locator-Sets. The cache is used to encapsulate packets from
the EID space to the corresponding RLOC network attachment point.</t> the EID space to the corresponding RLOC network attachment point.</t>
<t indent="0" pn="section-6-2">When an ITR/PITR receives a packet from ins
<t>When an ITR/PITR receives a packet from inside of the LISP ide of the LISP
site to destinations outside of the site a longest-prefix match site to destinations outside of the site, a longest-prefix match
lookup of the EID is done to the Map-Cache.</t> lookup of the EID is done to the Map-Cache.</t>
<t indent="0" pn="section-6-3">When the lookup succeeds, the Locator-Set r
<t>When the lookup succeeds, the Locator-Set retrieved from the etrieved from the
Map-Cache is used to send the packet to the EID's topological Map-Cache is used to send the packet to the EID's topological
location.</t> location.</t>
<t indent="0" pn="section-6-4">If the lookup fails, the ITR/PITR needs to
<t>If the lookup fails, the ITR/PITR needs to retrieve the retrieve the
mapping using the LISP Control-Plane protocol <xref mapping using the LISP control plane protocol <xref target="RFC9301" format
target="I-D.ietf-lisp-rfc6833bis"/>. While the mapping is being retrieved, ="default" sectionFormat="of" derivedContent="RFC9301"/>. While the mapping is b
eing retrieved,
the ITR/PITR can either drop or buffer the packets. This document does n ot have specific the ITR/PITR can either drop or buffer the packets. This document does n ot have specific
recommendations about the action to be taken. recommendations about the action to be taken.
It is up to the deployer to consider whether or not it is desirable to b uffer packets It is up to the deployer to consider whether or not it is desirable to b uffer packets
and deploy a LISP implementation that offers the desired behaviour. Once the mapping is resolved and deploy a LISP implementation that offers the desired behavior. Once the mapping is resolved,
it is then stored in the local Map-Cache to forward subsequent packets a ddressed to it is then stored in the local Map-Cache to forward subsequent packets a ddressed to
the same EID-prefix.</t> the same EID-Prefix.</t>
<t indent="0" pn="section-6-5">The Map-Cache is a local cache of mappings;
<t>The Map-Cache is a local cache of mappings, entries are entries are
expired based on the associated Time to live. In addition, expired based on the associated Time to Live. In addition,
entries can be updated with more current information, see <xref entries can be updated with more current information; see <xref target="upd
target="update_mapping" /> for further information on ate_mapping" format="default" sectionFormat="of" derivedContent="Section 13"/> f
or further information on
this. Finally, the Map-Cache also contains reachability this. Finally, the Map-Cache also contains reachability
information about EIDs and RLOCs, and uses LISP reachability information about EIDs and RLOCs and uses LISP reachability
information mechanisms to determine the reachability of RLOCs, information mechanisms to determine the reachability of RLOCs;
see <xref target="loc-reach" /> for the specific mechanisms.</t> see <xref target="loc-reach" format="default" sectionFormat="of" derivedCon
tent="Section 10"/> for the specific mechanisms.</t>
</section> </section>
<section anchor="fragment" numbered="true" toc="include" removeInRFC="false"
<section title="Dealing with Large Encapsulated Packets" anchor="fragment"> pn="section-7">
<name slugifiedName="name-dealing-with-large-encapsul">Dealing with Large
<t>This section proposes two mechanisms to deal with Encapsulated Packets</name>
packets that exceed the path MTU between the ITR and ETR.</t> <t indent="0" pn="section-7-1">This section proposes two mechanisms to dea
l with
<t>It is left to the implementor to decide if the stateless or packets that exceed the Path MTU (PMTU) between the ITR and ETR.</t>
stateful mechanism SHOULD be implemented. Both or neither can be <t indent="0" pn="section-7-2">It is left to the implementor to decide if
the stateless or
stateful mechanism <bcp14>SHOULD</bcp14> be implemented. Both or neither can
be
used, since it is a local decision in the ITR regarding how used, since it is a local decision in the ITR regarding how
to deal with MTU issues, and sites can interoperate with differing to deal with MTU issues, and sites can interoperate with differing
mechanisms.</t> mechanisms.</t>
<t indent="0" pn="section-7-3">Both stateless and stateful mechanisms also
<t>Both stateless and stateful mechanisms also apply to apply to
Re-encapsulating and Recursive Tunneling, so any actions Re-encapsulating and Recursive Tunneling, so any actions
below referring to an ITR also apply to a TE-ITR.</t> below referring to an ITR also apply to a TE-ITR.</t>
<section anchor="MTU-STATELESS" numbered="true" toc="include" removeInRFC=
<section anchor="MTU-STATELESS" title="A Stateless Solution to MTU Handling" "false" pn="section-7.1">
> <name slugifiedName="name-a-stateless-solution-to-mtu">A Stateless Solut
<t>An ITR stateless solution to handle MTU issues is described as ion to MTU Handling</name>
<t indent="0" pn="section-7.1-1">An ITR stateless solution to handle MTU
issues is described as
follows:</t> follows:</t>
<ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-7.
<t><list style="numbers"> 1-2">
<t>Define H to be the size, in octets, of the outer header an ITR <li pn="section-7.1-2.1" derivedCounter="1.">Define H to be the size, i
prepends to a packet. This includes the UDP and LISP header lengths.</t> n octets, of the outer header an ITR
prepends to a packet. This includes the UDP and LISP header lengths.</li>
<t>Define L to be the size, in octets, of the maximum-sized packet <li pn="section-7.1-2.2" derivedCounter="2.">Define L to be the size,
in octets, of the maximum-sized packet
an ITR can send to an ETR without the need for the ITR or any an ITR can send to an ETR without the need for the ITR or any
intermediate routers to fragment the packet. intermediate routers to fragment the packet.
The network administrator of the LISP deployment has to determine The network administrator of the LISP deployment has to determine
what is the suitable value of L so to make sure that no MTU issues arise. what the suitable value of L is, so as to make sure that no MTU issues ar
</t> ise.</li>
<li pn="section-7.1-2.3" derivedCounter="3.">Define an architectural c
<t>Define an architectural constant S for the maximum size of a onstant S for the maximum size of a
packet, in octets, an ITR MUST receive from the source so the packet, in octets, an ITR <bcp14>MUST</bcp14> receive from the source so the
effective MTU can be met. That is, L = S + H.</t> effective MTU can be met. That is, L = S + H.</li>
</list></t> </ol>
<t indent="0" pn="section-7.1-3">When an ITR receives a packet from a si
<t>When an ITR receives a packet from a site-facing interface and te-facing interface and
adds H octets worth of encapsulation to yield a packet size adds H octets worth of encapsulation to yield a packet size
greater than L octets (meaning the received packet size was greater than L octets (meaning the received packet size was
greater than S octets from the source), it resolves the MTU issue greater than S octets from the source), it resolves the MTU issue
by first splitting the original packet into 2 equal-sized by first splitting the original packet into 2 equal-sized
fragments. A LISP header is then prepended to each fragment. The fragments. A LISP header is then prepended to each fragment. The
size of the encapsulated fragments is then (S/2 + H), which is size of the encapsulated fragments is then (S/2 + H), which is
less than the ITR's estimate of the path MTU between the ITR and less than the ITR's estimate of the PMTU between the ITR and
its correspondent ETR.</t> its correspondent ETR.</t>
<t indent="0" pn="section-7.1-4">When an ETR receives encapsulated fragm
<t>When an ETR receives encapsulated fragments, it treats them ents, it treats them
as two individually encapsulated packets. It strips the LISP as two individually encapsulated packets. It strips the LISP
headers and then forwards each fragment to the destination host of headers and then forwards each fragment to the destination host of
the destination site. The two fragments are reassembled at the destination site. The two fragments are reassembled at
the destination host into the single IP datagram that was the destination host into the single IP datagram that was
originated by the source host. Note that reassembly can happen originated by the source host. Note that reassembly can happen
at the ETR if the encapsulated packet was fragmented at or after the at the ETR if the encapsulated packet was fragmented at or after the
ITR.</t> ITR.</t>
<t indent="0" pn="section-7.1-5">This behavior <bcp14>MUST</bcp14> be im
<t>This behavior MUST be performed by the ITR only when the source plemented by the ITR only when the source
host originates a packet with the 'DF' field of the IP header set host originates a packet with the 'DF' field of the IP header set
to 0. When the 'DF' field of the IP header is set to 1, or the to 0. When the 'DF' field of the IP header is set to 1 or the
packet is an IPv6 packet originated by the source host, the ITR packet is an IPv6 packet originated by the source host, the ITR
will drop the packet when the size (adding in the size of the will drop the packet when the size (adding in the size of the
encapsulation header) is greater than L and send an ICMPv4 ICMP encapsulation header) is greater than L and send an ICMPv4
Unreachable/Fragmentation-Needed or ICMPv6 "Packet Too Big" Unreachable / Fragmentation Needed or ICMPv6 Packet Too Big (PTB)
message to the source with a value of S, where S is (L - H).</t> message to the source with a value of S, where S is (L - H).</t>
<t indent="0" pn="section-7.1-6">When the outer-header encapsulation use
<t>When the outer-header encapsulation uses an IPv4 header, an s an IPv4 header, an
implementation SHOULD set the DF bit to 1 so ETR fragment implementation <bcp14>SHOULD</bcp14> set the DF bit to 1 so ETR fragment
reassembly can be avoided. An implementation MAY set the DF reassembly can be avoided. An implementation <bcp14>MAY</bcp14> set the DF
bit in such headers to 0 if it has good reason to believe bit in such headers to 0 if it has good reason to believe
there are unresolvable path MTU issues between the sending ITR there are unresolvable PMTU issues between the sending ITR
and the receiving ETR.</t> and the receiving ETR.</t>
<t indent="0" pn="section-7.1-7">It is <bcp14>RECOMMENDED</bcp14> that L
<t>This specification RECOMMENDS that L be defined as 1500. be defined as 1500.
Additional information about in-network MTU and fragmentation issues can be Additional information about in-network MTU and fragmentation issues can be
found at <xref target="RFC4459"/>.</t> found in <xref target="RFC4459" format="default" sectionFormat="of" derivedConte
</section> nt="RFC4459"/>.</t>
</section>
<section anchor="MTU-STATEFUL" title="A Stateful Solution to MTU Handling"> <section anchor="MTU-STATEFUL" numbered="true" toc="include" removeInRFC="
<t>An ITR stateful solution to handle MTU issues is described as false" pn="section-7.2">
<name slugifiedName="name-a-stateful-solution-to-mtu-">A Stateful Soluti
on to MTU Handling</name>
<t indent="0" pn="section-7.2-1">An ITR stateful solution to handle MTU
issues is described as
follows:</t> follows:</t>
<ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-7.
<t><list style="numbers"> 2-2">
<t>The ITR will keep state of the effective MTU for each Locator <li pn="section-7.2-2.1" derivedCounter="1.">The ITR will keep state of
the effective MTU for each Locator
per Map-Cache entry. The effective MTU is what the core network per Map-Cache entry. The effective MTU is what the core network
can deliver along the path between the ITR and ETR.</t> can deliver along the path between the ITR and ETR.</li>
<li pn="section-7.2-2.2" derivedCounter="2.">When an IPv4-encapsulated
<t>When an IPv4-encapsulated packet with the DF bit set to 1, exceeds wh packet with the DF bit set to 1 exceeds what the core network
at the core network
can deliver, one of the intermediate routers on the path will can deliver, one of the intermediate routers on the path will
send an an ICMPv4 send an ICMPv4
Unreachable/Fragmentation-Needed to the ITR, respectively. The Unreachable / Fragmentation Needed message to the ITR. The
ITR will parse the ICMP message to determine which Locator is ITR will parse the ICMP message to determine which Locator is
affected by the effective MTU change and then record the new affected by the effective MTU change and then record the new
effective MTU value in the Map-Cache entry.</t> effective MTU value in the Map-Cache entry.</li>
<li pn="section-7.2-2.3" derivedCounter="3.">When a packet is received
<t>When a packet is received by the ITR from a source inside by the ITR from a source inside
of the site and the size of the packet is greater than the of the site and the size of the packet is greater than the
effective MTU stored with the Map-Cache entry associated with effective MTU stored with the Map-Cache entry associated with
the destination EID the packet is for, the ITR will send an the destination EID the packet is for, the ITR will send an
ICMPv4 ICMP Unreachable/Fragmentation-Needed message back to the source. The packet size ICMPv4 Unreachable / Fragmentation Needed message back to the source. Th e packet size
advertised by the ITR in the ICMP message is the effective advertised by the ITR in the ICMP message is the effective
MTU minus the LISP encapsulation length.</t> MTU minus the LISP encapsulation length.</li>
</list></t> </ol>
<t indent="0" pn="section-7.2-3">Even though this mechanism is stateful,
<t>Even though this mechanism is stateful, it has advantages over it has advantages over
the stateless IP fragmentation mechanism, by not involving the the stateless IP fragmentation mechanism, by not involving the
destination host with reassembly of ITR fragmented packets.</t> destination host with reassembly of ITR fragmented packets.</t>
<t indent="0" pn="section-7.2-4">Please note that using ICMP packets for
<t>Please note that <xref target="RFC1191"/> and <xref target="RFC1981"/>, w PMTU discovery, as described
hich describe the use in <xref target="RFC1191" format="default" sectionFormat="of" derivedContent="RF
of ICMP packets for PMTU discovery, can behave suboptimally in the C1191"/> and <xref target="RFC8201" format="default" sectionFormat="of" derivedC
presence of ICMP black holes or off-path attackers that spoof ICMP. ontent="RFC8201"/>, can result in suboptimal behavior in the
presence of ICMP packet losses or off-path attackers that spoof ICMP.
Possible mitigations include ITRs and ETRs cooperating on MTU probe Possible mitigations include ITRs and ETRs cooperating on MTU probe
packets (<xref target="RFC4821"/>, <xref target="I-D.ietf-tsvwg-datagram-p lpmtud"/>), or ITRs packets <xref target="RFC4821" format="default" sectionFormat="of" derived Content="RFC4821"/> <xref target="RFC8899" format="default" sectionFormat="of" d erivedContent="RFC8899"/> or ITRs
storing the beginning of large packets to verify that they match storing the beginning of large packets to verify that they match
the echoed packet in ICMP Frag Needed/PTB.</t> the echoed packet in an ICMP Fragmentation Needed / PTB message.</t>
</section></section> </section>
</section>
<section anchor="instance" title="Using Virtualization and Segmentation with <section anchor="instance" numbered="true" toc="include" removeInRFC="false"
LISP"> pn="section-8">
<t>There are several cases where segregation is needed at the <name slugifiedName="name-using-virtualization-and-se">Using Virtualizatio
n and Segmentation with LISP</name>
<t indent="0" pn="section-8-1">There are several cases where segregation i
s needed at the
EID level. For instance, this is the case for deployments EID level. For instance, this is the case for deployments
containing overlapping addresses, traffic isolation policies containing overlapping addresses, traffic isolation policies,
or multi-tenant virtualization. For these and other scenarios or multi-tenant virtualization. For these and other scenarios
where segregation is needed, Instance IDs are used.</t> where segregation is needed, Instance IDs are used.</t>
<t indent="0" pn="section-8-2">An Instance ID can be carried in a LISP-enc
<t>An Instance ID can be carried in a LISP-encapsulated apsulated
packet. An ITR that prepends a LISP header will copy a packet. An ITR that prepends a LISP header will copy a
24-bit value used by the LISP router to uniquely identify 24-bit value used by the LISP router to uniquely identify
the address space. The value is copied to the 'Instance ID' the address space. The value is copied to the 'Instance ID'
field of the LISP header, and the I-bit is set to&nbsp;1.</t> field of the LISP header, and the I-bit is set to 1.</t>
<t indent="0" pn="section-8-3">When an ETR decapsulates a packet, the Inst
<t>When an ETR decapsulates a packet, the Instance ID from the ance ID from the
LISP header is used as a table identifier to locate the LISP header is used as a table identifier to locate the
forwarding table to use for the inner destination EID forwarding table to use for the inner destination EID
lookup.</t> lookup.</t>
<t indent="0" pn="section-8-4">For example, an 802.1Q VLAN tag or VPN iden
<t>For example, an 802.1Q VLAN tag or VPN identifier could be tifier could be
used as a 24-bit Instance ID. See <xref target="I-D.ietf-lisp-vpn"/> used as a 24-bit Instance ID. See <xref target="I-D.ietf-lisp-vpn" forma
for LISP VPN use-case details. Please note that the Instance ID t="default" sectionFormat="of" derivedContent="LISP-VPN"/>
is not protected, an on-path attacker can modify the tags and for instan for details regarding LISP VPN use cases. Please note that the Instance
ce, ID
allow communicatons between logically isolated VLANs.</t> is not protected; an on-path attacker can modify the tags and, for insta
nce,
<t>Participants within a LISP deployment must agree allow communications between logically isolated VLANs.</t>
<t indent="0" pn="section-8-5">Participants within a LISP deployment must
agree
on the meaning of Instance ID values. The source and destination EIDs on the meaning of Instance ID values. The source and destination EIDs
MUST belong to the same Instance ID. <bcp14>MUST</bcp14> belong to the same Instance ID.
</t> </t>
<t indent="0" pn="section-8-6">The Instance ID <bcp14>SHOULD NOT</bcp14> b
<t>Instance ID SHOULD NOT be used with overlapping IPv6 EID addresses.</ e used with overlapping IPv6 EID addresses.</t>
t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-9">
<section title="Routing Locator Selection"> <name slugifiedName="name-routing-locator-selection">Routing Locator Selec
tion</name>
<t>The Map-Cache contains the state used by ITRs and PITRs to <t indent="0" pn="section-9-1">The Map-Cache contains the state used by IT
Rs and PITRs to
encapsulate packets. When an ITR/PITR receives a packet from encapsulate packets. When an ITR/PITR receives a packet from
inside the LISP site to a destination outside of the site a inside the LISP site to a destination outside of the site, a
longest-prefix match lookup of the EID is done to the longest-prefix match lookup of the EID is done to the
Map-Cache (see <xref target="Map-Cache" />). The lookup Map-Cache (see <xref target="Map-Cache" format="default" sectionF ormat="of" derivedContent="Section 6"/>). The lookup
returns a single Locator-Set containing a list of RLOCs returns a single Locator-Set containing a list of RLOCs
corresponding to the EID's topological location. Each RLOC in corresponding to the EID's topological location. Each RLOC in
the Locator-Set is associated with a 'Priority' and 'Weight', the Locator-Set is associated with a Priority and Weight;
this information is used to select the RLOC to this information is used to select the RLOC to
encapsulate.</t> encapsulate.</t>
<t indent="0" pn="section-9-2">The RLOC with the lowest Priority is select
<t>The RLOC with the lowest 'Priority' is selected. An RLOC ed. An RLOC
with 'Priority' 255 means that MUST NOT be used for with Priority 255 means that it <bcp14>MUST NOT</bcp14> be used f
forwarding. When multiple RLOCs have the same 'Priority' then or
the 'Weight' states how to load balance traffic among them. forwarding. When multiple RLOCs have the same Priority, then
The value of the 'Weight' represents the relative weight of the Weight states how to load-balance traffic among them.
The value of the Weight represents the relative weight of
the total packets that match the mapping entry.</t> the total packets that match the mapping entry.</t>
<t indent="0" pn="section-9-3">The following are different scenarios for c
<t>The following are different scenarios for choosing hoosing
RLOCs and the controls that are available:</t> RLOCs and the controls that are available:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-9-4
<t><list style="symbols"> ">
<li pn="section-9-4.1">The server-side returns one RLOC. The client-side
<t>The server-side returns one RLOC. The client-side can only can only
use one RLOC. The server-side has complete control of the use one RLOC. The server-side has complete control of the
selection.</t> selection.</li>
<li pn="section-9-4.2">The server-side returns a list of RLOCs where a s
<t>The server-side returns a list of RLOCs where a subset ubset
of the list has the same best Priority. The client can only use of the list has the same best Priority. The client can only use
the subset list according to the the subset list according to the
weighting assigned by the server-side. In this case, the weighting assigned by the server-side. In this case, the
server-side controls both the subset list and load-splitting server-side controls both the subset list and load splitting
across its members. The client-side can use RLOCs outside across its members. The client-side can use RLOCs outside
of the subset list if it determines that the subset of the subset list if it determines that the subset
list is unreachable (unless RLOCs are set to a Priority of 255). list is unreachable (unless RLOCs are set to a Priority of 255).
Some sharing of control exists: the server-side determines Some sharing of control exists: the server-side determines
the destination RLOC list and load distribution while the the destination RLOC list and load distribution while the
client-side has the option of using alternatives to this list if client-side has the option of using alternatives to this list if
RLOCs in the list are unreachable.</t> RLOCs in the list are unreachable.</li>
<li pn="section-9-4.3">The server-side sets a Weight of zero for the RLO
<t>The server-side sets a Weight of zero for the RLOC subset C subset
list. In this case, the client-side can choose how the traffic list. In this case, the client-side can choose how the traffic
load is spread across the subset list. See <xref load is spread across the subset list. See <xref target="loc-hash" forma
target="loc-hash"/> for details on load-sharing mechanisms. t="default" sectionFormat="of" derivedContent="Section 12"/> for details on load
-sharing mechanisms.
Control is shared by the server-side determining the list and Control is shared by the server-side determining the list and
the client-side determining load distribution. Again, the the client-side determining load distribution. Again, the
client can use alternative RLOCs if the server-provided list client can use alternative RLOCs if the server-provided list
of RLOCs is unreachable.</t> of RLOCs is unreachable.</li>
<li pn="section-9-4.4">Either side (more likely the server-side ETR) dec
<t>Either side (more likely the server-side ETR) decides to "glean" ides to "glean"
the RLOCs. For example, if the server-side ETR gleans RLOCs, the RLOCs. For example, if the server-side ETR gleans RLOCs, then
then the client-side ITR gives the client-side ITR responsibility the client-side ITR gives the server-side ETR responsibility for
for bidirectional RLOC reachability and preferability. Server-side bidirectional RLOC reachability and preferability. Server-side
ETR gleaning of the client-side ITR RLOC is done by caching the ETR gleaning of the client-side ITR RLOC is done by caching the
inner-header source EID and the outer-header source RLOC of inner-header source EID and the outer-header source RLOC of
received packets. The client-side ITR controls how traffic is received packets. The client-side ITR controls how traffic is
returned and can alternate using an outer-header source RLOC, returned and can, as an alternative, use an outer-header source
which then can be added to the list the server-side ETR uses RLOC, which then can be added to the list the server-side ETR uses
to return traffic. Since no Priority or Weights are provided to return traffic. Since no Priority or Weights are provided
using this method, the server-side ETR MUST assume that each using this method, the server-side ETR <bcp14>MUST</bcp14> assume that
each
client-side ITR RLOC uses the same best Priority with a Weight client-side ITR RLOC uses the same best Priority with a Weight
of zero. In addition, since EID-Prefix encoding cannot be conveyed of zero. In addition, since EID-Prefix encoding cannot be conveyed
in data packets, the EID-to-RLOC Cache on Tunnel Routers can grow in data packets, the EID-to-RLOC Map-Cache on Tunnel Routers can grow
to be very large. Gleaning has several important considerations. very large. Gleaning has several important considerations.
A "gleaned" Map-Cache entry is only stored and used for a RECOMMENDED A "gleaned" Map-Cache entry is only stored and used for a <bcp14>RECOM
period of 3 seconds, MENDED</bcp14> period of 3 seconds,
pending verification. Verification MUST be performed by pending verification. Verification <bcp14>MUST</bcp14> be performed b
y
sending a Map-Request to the source EID (the inner-header IP source sending a Map-Request to the source EID (the inner-header IP source
address) of the received encapsulated packet. A reply to this address) of the received encapsulated packet. A reply to this
"verifying Map-Request" is used to fully populate the Map-Cache entry "verifying Map-Request" is used to fully populate the Map-Cache entry
for the "gleaned" EID and is stored and used for the time indicated for the "gleaned" EID and is stored and used for the time indicated
from the 'TTL' field of a received Map-Reply. When a verified Map- in the 'Time to Live' field of a received Map-Reply. When a verified
Cache entry is stored, data gleaning no longer occurs for subsequent Map-Cache entry is stored, data gleaning no longer occurs for subsequent
packets that have a source EID that matches the EID-Prefix of the packets that have a source EID that matches the EID-Prefix of the
verified entry. This "gleaning" mechanism MUST NOT be used over verified entry. This "gleaning" mechanism <bcp14>MUST NOT</bcp14> be
the public Internet and SHOULD only be used in trusted and closed used over
deployments. Refer to <xref target="SECURITY"/> for security issues r the public Internet and <bcp14>SHOULD</bcp14> only be used in trusted
egarding this and closed
mechanism.</t> deployments. Refer to <xref target="SECURITY" format="default" sectio
nFormat="of" derivedContent="Section 16"/> for security issues regarding this
</list></t> mechanism.</li>
</ul>
<t>RLOCs that appear in EID-to-RLOC Map-Reply messages are <t indent="0" pn="section-9-5">RLOCs that appear in EID-to-RLOC Map-Reply
assumed to be reachable when the R-bit <xref messages are
target="I-D.ietf-lisp-rfc6833bis"/> for the Locator record is set assumed to be reachable when the R-bit <xref target="RFC9301" format="de
to 1. When the R-bit is set to 0, an ITR or PITR MUST NOT fault" sectionFormat="of" derivedContent="RFC9301"/> for the Locator record is s
et
to 1. When the R-bit is set to 0, an ITR or PITR <bcp14>MUST NOT</bcp14
>
encapsulate to the RLOC. Neither the information contained in encapsulate to the RLOC. Neither the information contained in
a Map-Reply nor that stored in the mapping database system a Map-Reply nor that stored in the mapping database system
provides reachability information for RLOCs. Note that provides reachability information for RLOCs. Note that
reachability is not part of the mapping system and is reachability is not part of the Mapping System and is
determined using one or more of the Routing Locator determined using one or more of the RLOC
reachability algorithms described in the next section.</t> reachability algorithms described in the next section.</t>
</section> </section>
<section anchor="loc-reach" numbered="true" toc="include" removeInRFC="false
<section anchor="loc-reach" title="Routing Locator Reachability"> " pn="section-10">
<name slugifiedName="name-routing-locator-reachabilit">Routing Locator Rea
<t>Several Data-Plane mechanisms for determining RLOC chability</name>
<t indent="0" pn="section-10-1">Several data plane mechanisms for determin
ing RLOC
reachability are currently defined. Please note that reachability are currently defined. Please note that
additional Control-Plane based reachability mechanisms are additional reachability mechanisms based on the control plane are
defined in <xref target="I-D.ietf-lisp-rfc6833bis"/>.</t> defined in <xref target="RFC9301" format="default" sectionFormat="of" de
rivedContent="RFC9301"/>.</t>
<t><list style="numbers"> <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-10-2
">
<t>An ETR MAY examine the Locator-Status-Bits in the LISP <li pn="section-10-2.1" derivedCounter="1.">An ETR <bcp14>MAY</bcp14> exa
mine the Locator-Status-Bits in the LISP
header of an encapsulated data packet received from an header of an encapsulated data packet received from an
ITR. If the ETR is also acting as an ITR and has ITR. If the ETR is also acting as an ITR and has
traffic to return to the original ITR site, it can use traffic to return to the original ITR site, it can use
this status information to help select an RLOC.</t> this status information to help select an RLOC.</li>
<li pn="section-10-2.2" derivedCounter="2.">When an ETR receives an enca
<t>When an ETR receives an encapsulated packet from an ITR, psulated packet from an ITR,
the source RLOC from the outer header of the packet is likely the source RLOC from the outer header of the packet is likely
to be reachable. Please note that in some scenarios the to be reachable. Please note that in some scenarios the
RLOC from the outer header can be an spoofable field.</t> RLOC from the outer header can be a spoofable field.</li>
<li pn="section-10-2.3" derivedCounter="3.">An ITR/ETR pair can use the
<t>An ITR/ETR pair can use the 'Echo-Noncing' Locator Echo-Noncing Locator
reachability algorithms described in this section.</t> reachability algorithms described in this section.</li>
</ol>
</list></t> <t indent="0" pn="section-10-3">When determining Locator up/down reachabil
ity by
<t>When determining Locator up/down reachability by
examining the Locator-Status-Bits from the LISP-encapsulated examining the Locator-Status-Bits from the LISP-encapsulated
data packet, an ETR will receive up-to-date status from an data packet, an ETR will receive an up-to-date status from an
encapsulating ITR about reachability for all ETRs at the encapsulating ITR about reachability for all ETRs at the
site. CE-based ITRs at the source site can determine site. CE-based ITRs at the source site can determine
reachability relative to each other using the site IGP as reachability relative to each other using the site IGP as
follows:</t> follows:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-10-
<t><list style="symbols"> 4">
<li pn="section-10-4.1">Under normal circumstances, each ITR will advert
<t>Under normal circumstances, each ITR will advertise ise
a default route into the site IGP.</t> a default route into the site IGP.</li>
<li pn="section-10-4.2">If an ITR fails or if the upstream link to its P
<t>If an ITR fails or if the upstream link to its PE rovider Edge
fails, its default route will either time out or be fails, its default route will either time out or be
withdrawn.</t> withdrawn.</li>
</ul>
</list></t> <t indent="0" pn="section-10-5">Each ITR can thus observe the presence or
lack of a
<t>Each ITR can thus observe the presence or lack of a
default route originated by the others to determine the default route originated by the others to determine the
Locator-Status-Bits it sets for them.</t> Locator-Status-Bits it sets for them.</t>
<t indent="0" pn="section-10-6">When ITRs at the site are not deployed in
<t>When ITRs at the site are not deployed in CE routers, the IGP CE routers, the IGP
can still be used to determine the reachability of Locators, can still be used to determine the reachability of Locators,
provided they are injected into the IGP. This is provided they are injected into the IGP. This is
typically done when a /32 address is configured on a loopback typically done when a /32 address is configured on a loopback
interface.</t> interface.</t>
<t indent="0" pn="section-10-7"> RLOCs listed in a Map-Reply are numbered
<t> RLOCs listed in a Map-Reply are numbered with ordinals with ordinals
0 to n-1. The Locator-Status-Bits in a LISP-encapsulated 0 to n-1. The Locator-Status-Bits in a LISP-encapsulated
packet are numbered from 0 to n-1 starting with the least packet are numbered from 0 to n-1 starting with the least
significant bit. For example, if an RLOC listed in the 3rd significant bit. For example, if an RLOC listed in the 3rd
position of the Map-Reply goes down (ordinal value 2), position of the Map-Reply goes down (ordinal value 2),
then all ITRs at the site will clear the 3rd least then all ITRs at the site will clear the 3rd least
significant bit (xxxx x0xx) of the 'Locator-Status-Bits' significant bit (xxxx x0xx) of the 'Locator-Status-Bits'
field for the packets they encapsulate.</t> field for the packets they encapsulate.</t>
<t indent="0" pn="section-10-8">When an xTR decides to use Locator-Status-
<t>When an xTR decides to use 'Locator-Status-Bits' Bits
to affect reachability information, it acts as follows: to affect reachability information, it acts as follows:
ETRs decapsulating a packet will check for any change in ETRs decapsulating a packet will check for any change in
the 'Locator-Status-Bits' field. When a bit goes from 1 to 0, the the 'Locator-Status-Bits' field. When a bit goes from 1 to 0, the
ETR, if acting also as an ITR, will refrain from encapsulating ETR, if also acting as an ITR, will refrain from encapsulating
packets to an RLOC that is indicated as down. It will only resume packets to an RLOC that is indicated as down. It will only resume
using that RLOC if the corresponding Locator-Status-Bit using that RLOC if the corresponding Locator-Status-Bit
returns to a value of 1. Locator-Status-Bits are associated with a Loc ator-Set returns to a value of 1. Locator-Status-Bits are associated with a Loc ator-Set
per EID-Prefix. Therefore, when a Locator becomes unreachable, the per EID-Prefix. Therefore, when a Locator becomes unreachable, the
Locator-Status-Bit that corresponds to that Locator's position in the Locator-Status-Bit that corresponds to that Locator's position in the
list returned by the last Map-Reply will be set to zero for that list returned by the last Map-Reply will be set to zero for that
particular EID-Prefix. particular EID-Prefix.
</t> </t>
<t indent="0" pn="section-10-9">Locator-Status-Bits <bcp14>MUST NOT</bcp14
<t>Locator-Status-Bits MUST NOT be used > be used
over the public Internet and SHOULD only be used in trusted over the public Internet and <bcp14>SHOULD</bcp14> only be used
and closed deployments. In addition Locator-Status-Bits in trusted
SHOULD be coupled with Map-Versioning (<xref target="map-versioni and closed deployments. In addition, Locator-Status-Bits
ng"/>) <bcp14>SHOULD</bcp14> be coupled with Map-Versioning <xref target
="RFC9302" format="default" sectionFormat="of" derivedContent="RFC9302"/>
to prevent race conditions where Locator-Status-Bits are interpreted as to prevent race conditions where Locator-Status-Bits are interpreted as
referring to different RLOCs than intended. Refer to <xref target="SECURITY" /> referring to different RLOCs than intended. Refer to <xref target="SECURITY" format="default" sectionFormat="of" derivedContent="Section 16"/>
for security issues regarding this mechanism.</t> for security issues regarding this mechanism.</t>
<t indent="0" pn="section-10-10">If an ITR encapsulates a packet to an ETR
<t>If an ITR encapsulates a packet to an ETR and the packet is and the packet is
received and decapsulated by the ETR, it is implied but not received and decapsulated by the ETR, it is implied, but not
confirmed by the ITR that the ETR's RLOC is reachable. In confirmed by the ITR, that the ETR's RLOC is reachable. In
most cases, the ETR can also reach the ITR but cannot assume most cases, the ETR can also reach the ITR but cannot assume
this to be true, due to the possibility of path asymmetry. In this to be true, due to the possibility of path asymmetry. In
the presence of unidirectional traffic flow from an ITR to an the presence of unidirectional traffic flow from an ITR to an
ETR, the ITR SHOULD NOT use the lack of return traffic as an ETR, the ITR <bcp14>SHOULD NOT</bcp14> use the lack of return traffic as
indication that the ETR is unreachable. Instead, it MUST use an
indication that the ETR is unreachable. Instead, it <bcp14>MUST</bcp14>
use
an alternate mechanism to determine reachability.</t> an alternate mechanism to determine reachability.</t>
<t indent="0" pn="section-10-11">The security considerations of <xref targ
<t>The security considerations of <xref target="SECURITY"/> et="SECURITY" format="default" sectionFormat="of" derivedContent="Section 16"/>
related to data-plane reachability applies to the data-plane related to data plane reachability apply to the data plane
RLOC reachability mechanisms described in this section.</t> RLOC reachability mechanisms described in this section.</t>
<section anchor="echo-nonce" numbered="true" toc="include" removeInRFC="fa
<section anchor="echo-nonce" title="Echo Nonce Algorithm"> lse" pn="section-10.1">
<t>When data flows bidirectionally between Locators from <name slugifiedName="name-echo-nonce-algorithm">Echo-Nonce Algorithm</na
different sites, a Data-Plane mechanism called "nonce me>
<t indent="0" pn="section-10.1-1">When data flows bidirectionally betwee
n Locators from
different sites, a data plane mechanism called "nonce
echoing" can be used to determine reachability between an ITR echoing" can be used to determine reachability between an ITR
and ETR. When an ITR wants to solicit a nonce echo, it sets and ETR. When an ITR wants to solicit a nonce echo, it sets
the N- and E-bits and places a 24-bit nonce <xref the N- and E-bits and places a 24-bit nonce <xref target="RFC4086" form
target="RFC4086" /> in the LISP header of the next at="default" sectionFormat="of" derivedContent="RFC4086"/> in the LISP header of
the next
encapsulated data packet.</t> encapsulated data packet.</t>
<t indent="0" pn="section-10.1-2">When this packet is received by the ET
<t>When this packet is received by the ETR, the encapsulated R, the encapsulated
packet is forwarded as normal. When the ETR is an xTR packet is forwarded as normal. When the ETR is an xTR
(co-located as an ITR), it then sends a data packet to the (co-located as an ITR), it then sends a data packet to the
ITR (when it is an xTR co-located as an ETR), it includes the ITR (when it is an xTR co-located as an ETR) and includes the
nonce received earlier with the N-bit set and E-bit nonce received earlier with the N-bit set and E-bit
cleared. The ITR sees this "echoed nonce" and knows that the cleared. The ITR sees this "echoed nonce" and knows that the
path to and from the ETR is up.</t> path to and from the ETR is up.</t>
<t indent="0" pn="section-10.1-3">The ITR will set the E-bit and N-bit f
<t>The ITR will set the E-bit and N-bit for every packet it or every packet it
sends while in the echo-nonce-request state. The time the sends while in the Echo-Nonce-request state. The time the
ITR waits to process the echoed nonce before it determines ITR waits to process the echoed nonce before it determines that
the path is unreachable is variable and is a choice left for the path is unreachable is variable and is a choice left for
the implementation.</t> the implementation.</t>
<t indent="0" pn="section-10.1-4">If the ITR is receiving packets from t
<t>If the ITR is receiving packets from the ETR but does not he ETR but does not
see the nonce echoed while being in the echo-nonce-request see the nonce echoed while being in the Echo-Nonce-request
state, then the path to the ETR is unreachable. This decision state, then the path to the ETR is unreachable. This decision
MAY be overridden by other Locator reachability <bcp14>MAY</bcp14> be overridden by other Locator reachability
algorithms. Once the ITR determines that the path to the ETR algorithms. Once the ITR determines that the path to the ETR
is down, it can switch to another Locator for that is down, it can switch to another Locator for that
EID-Prefix.</t> EID-Prefix.</t>
<t indent="0" pn="section-10.1-5">Note that "ITR" and "ETR" are relative
<t>Note that "ITR" and "ETR" are relative terms here. Both terms here. Both
devices MUST be implementing both ITR and ETR functionality devices <bcp14>MUST</bcp14> be implementing both ITR and ETR functional
for the echo nonce mechanism to operate.</t> ity
for the Echo-Nonce mechanism to operate.</t>
<t>The ITR and ETR MAY both go into the echo-nonce-request <t indent="0" pn="section-10.1-6">The ITR and ETR <bcp14>MAY</bcp14> bot
h go into the Echo-Nonce-request
state at the same time. The number of packets sent or the state at the same time. The number of packets sent or the
time during which echo nonce requests are sent is an time during which Echo-Nonce request packets are sent is an
implementation-specific setting. In this case, an xTR implementation-specific setting. In this case, an xTR
receiving the echo-nonce-request packets will suspend receiving the Echo-Nonce request packets will suspend
the echo-nonce-request state and setup a 'echo-nonce-request-state' tim the Echo-Nonce state and set up an 'Echo-Nonce-request-state' timer.
er. After the 'Echo-Nonce-request-state' timer expires, it will resume
After the 'echo-nonce-request-state' timer expires it will resume the Echo-Nonce state.</t>
the echo-nonce-request state.</t> <t indent="0" pn="section-10.1-7">This mechanism does not completely sol
ve the forward path
<t>This mechanism does not completely solve the forward path
reachability problem, as traffic may be unidirectional. That reachability problem, as traffic may be unidirectional. That
is, the ETR receiving traffic at a site MAY not be the same is, the ETR receiving traffic at a site <bcp14>MAY</bcp14> not be the s ame
device as an ITR that transmits traffic from that site, or device as an ITR that transmits traffic from that site, or
the site-to-site traffic is unidirectional so there is no ITR the site-to-site traffic is unidirectional so there is no ITR
returning traffic.</t> returning traffic.</t>
<t indent="0" pn="section-10.1-8">The Echo-Nonce algorithm is bilateral.
<t>The echo-nonce algorithm is bilateral. That is, if one That is, if one
side sets the E-bit and the other side is not enabled for side sets the E-bit and the other side is not enabled for
echo-noncing, then the echoing of the nonce does not occur Echo-Noncing, then the echoing of the nonce does not occur
and the requesting side may erroneously consider the Locator and the requesting side may erroneously consider the Locator
unreachable. An ITR SHOULD set the E-bit in an unreachable. An ITR <bcp14>SHOULD</bcp14> set the E-bit in an
encapsulated data packet when it knows the ETR is enabled for encapsulated data packet when it knows the ETR is enabled for
echo-noncing. This is conveyed by the E-bit in the Echo-Noncing. This is conveyed by the E-bit in the
Map-Reply message.</t> Map-Reply message.</t>
<t indent="0" pn="section-10.1-9">Many implementations default to not ad
<t>Many implementations default to not advertising they are vertising that they are
echo-nonce capable in Map-Reply messages and so RLOC-probing tends Echo-Nonce capable in Map-Reply messages, and so RLOC-Probing tends
to be used for RLOC reachability.</t> to be used for RLOC reachability.</t>
<t indent="0" pn="section-10.1-10">The Echo-Nonce mechanism <bcp14>MUST
<t>The echo-nonce mechanism MUST NOT be used NOT</bcp14> be used
over the public Internet and MUST only be used in trusted over the public Internet and <bcp14>MUST</bcp14> only be used in
and closed deployments. Refer to <xref target="SECURITY"/> for trusted
and closed deployments. Refer to <xref target="SECURITY" format="
default" sectionFormat="of" derivedContent="Section 16"/> for
security issues regarding this mechanism.</t> security issues regarding this mechanism.</t>
</section> </section>
</section> </section>
<section anchor="eid-reach" numbered="true" toc="include" removeInRFC="false
<section anchor="eid-reach" title="EID Reachability within a LISP Site"> " pn="section-11">
<t>A site MAY be multihomed using two or more ETRs. The hosts <name slugifiedName="name-eid-reachability-within-a-l">EID Reachability wi
thin a LISP Site</name>
<t indent="0" pn="section-11-1">A site <bcp14>MAY</bcp14> be multihomed us
ing two or more ETRs. The hosts
and infrastructure within a site will be addressed using one and infrastructure within a site will be addressed using one
or more EID-Prefixes that are mapped to the RLOCs of the or more EID-Prefixes that are mapped to the RLOCs of the
relevant ETRs in the mapping system. One possible failure relevant ETRs in the Mapping System. One possible failure
mode is for an ETR to lose reachability to one or more of the mode is for an ETR to lose reachability to one or more of the
EID-Prefixes within its own site. When this occurs when the EID-Prefixes within its own site. When this occurs when the
ETR sends Map-Replies, it can clear the R-bit associated with ETR sends Map-Replies, it can clear the R-bit associated with
its own Locator. And when the ETR is also an ITR, it can clear its own Locator. And when the ETR is also an ITR, it can clear
its Locator-Status-Bit in the encapsulation data header.</t> its Locator-Status-Bit in the encapsulation data header.</t>
<t indent="0" pn="section-11-2">It is recognized that there are no simple
<t>It is recognized that there are no simple solutions to the solutions to the
site partitioning problem because it is hard to know which site partitioning problem because it is hard to know which
part of the EID-Prefix range is partitioned and which Locators part of the EID-Prefix range is partitioned and which Locators
can reach any sub-ranges of the EID-Prefixes. Note that this can reach any sub-ranges of the EID-Prefixes. Note that this
is not a new problem introduced by the LISP architecture. The is not a new problem introduced by the LISP architecture. At the time of
problem exists today when a multihomed site uses BGP to this writing, this problem exists when a multihomed site uses BGP to
advertise its reachability upstream.</t> advertise its reachability upstream.</t>
</section> </section>
<section anchor="loc-hash" numbered="true" toc="include" removeInRFC="false"
<section anchor="loc-hash" title="Routing Locator Hashing"> pn="section-12">
<t>When an ETR provides an EID-to-RLOC mapping in a <name slugifiedName="name-routing-locator-hashing">Routing Locator Hashing
</name>
<t indent="0" pn="section-12-1">When an ETR provides an EID-to-RLOC mappin
g in a
Map-Reply message that is stored in the Map-Cache of a Map-Reply message that is stored in the Map-Cache of a
requesting ITR, the Locator-Set for the EID-Prefix MAY requesting ITR, the Locator-Set for the EID-Prefix <bcp14>MAY</bcp14>
contain different Priority and Weight values for each contain different Priority and Weight values for each
locator address. When more than one best Priority Locator Routing Locator Address. When more than one best Priority Locator
exists, the ITR can decide how to load-share traffic against exists, the ITR can decide how to load-share traffic against
the corresponding Locators.</t> the corresponding Locators.</t>
<t indent="0" pn="section-12-2">The following hash algorithm <bcp14>MAY</b
<t>The following hash algorithm MAY be used by an ITR to cp14> be used by an ITR to
select a Locator for a packet destined to an EID for the select a Locator for a packet destined to an EID for the
EID-to-RLOC mapping:</t> EID-to-RLOC mapping:</t>
<ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-12-3
<t><list style="numbers"> ">
<t>Either a source and destination address hash or the <li pn="section-12-3.1" derivedCounter="1.">Either a source and destinati
traditional 5-tuple hash can be used. The traditional on address hash or the
commonly used 5-tuple hash can be used. The commonly used
5-tuple hash includes the source and destination 5-tuple hash includes the source and destination
addresses; source and destination TCP, UDP, or Stream addresses; source and destination TCP, UDP, or Stream
Control Transmission Protocol (SCTP) port numbers; and the Control Transmission Protocol (SCTP) port numbers; and the
IP protocol number field or IPv6 next-protocol fields of a IP protocol number field or IPv6 next-protocol fields of a
packet that a host originates from within a LISP packet that a host originates from within a LISP
site. When a packet is not a TCP, UDP, or SCTP packet, the site. When a packet is not a TCP, UDP, or SCTP packet, the
source and destination addresses only from the header are source and destination addresses only from the header are
used to compute the hash.</t> used to compute the hash.</li>
<li pn="section-12-3.2" derivedCounter="2.">Take the hash value and divi
<t>Take the hash value and divide it by the number of de it by the number of
Locators stored in the Locator-Set for the EID-to-RLOC Locators stored in the Locator-Set for the EID-to-RLOC
mapping.</t> mapping.</li>
<li pn="section-12-3.3" derivedCounter="3.">The remainder will yield a v
<t>The remainder will yield a value of 0 to "number of alue of 0 to "number of
Locators minus 1". Use the remainder to select the Locator Locators minus 1". Use the remainder to select the Locator
in the Locator-Set.</t> in the Locator-Set.</li>
</list></t> </ol>
<t indent="0" pn="section-12-4">The specific hash algorithm the ITR uses f
<t>The specific hash algorithm the ITR uses for load-sharing or load-sharing
is out of scope for this document and does not prevent is out of scope for this document and does not prevent
interoperability.</t> interoperability.</t>
<t indent="0" pn="section-12-5">The source port <bcp14>SHOULD</bcp14> be t
<t>The Source port SHOULD be the same for all packets belonging to the he same for all packets belonging to the
same flow. Also note that when a packet is LISP encapsulated, the source same flow. Also note that when a packet is LISP encapsulated, the source
port number in the outer UDP header needs to be set. Selecting port number in the outer UDP header needs to be set. Selecting
a hashed value allows core routers that are attached to Link a hashed value allows core routers that are attached to Link
Aggregation Groups (LAGs) to load-split the encapsulated Aggregation Groups (LAGs) to load-split the encapsulated
packets across member links of such LAGs. Otherwise, core packets across member links of such LAGs. Otherwise, core
routers would see a single flow, since packets have a source routers would see a single flow, since packets have a source
address of the ITR, for packets that are originated by address of the ITR, for packets that are originated by
different EIDs at the source site. A suggested setting for the different EIDs at the source site. A suggested setting for the
source port number computed by an ITR is a 5-tuple hash source port number computed by an ITR is a 5-tuple hash
function on the inner header, as described above. The source function on the inner header, as described above. The source
port SHOULD be the same for all packets belonging to the same port <bcp14>SHOULD</bcp14> be the same for all packets belonging to the same
flow.</t> flow.</t>
<t indent="0" pn="section-12-6">Many core router implementations use a 5-t
<t>Many core router implementations use a 5-tuple hash to decide uple hash to decide
how to balance packet load across members of a LAG. The 5-tuple how to balance packet load across members of a LAG. The 5-tuple
hash includes the source and destination addresses of the packet hash includes the source and destination addresses of the packet
and the source and destination ports when the protocol number in and the source and destination ports when the protocol number in
the packet is TCP or UDP. For this reason, UDP encoding is the packet is TCP or UDP. For this reason, UDP encoding is
used for LISP encapsulation. In this scenario, when the outer header is used for LISP encapsulation. In this scenario, when the outer header is
IPv6, the flow label MAY also be IPv6, the flow label <bcp14>MAY</bcp14> also be
set following the procedures specified in <xref target="RFC6438"/>. Wh set following the procedures specified in <xref target="RFC6438" forma
en the inner header t="default" sectionFormat="of" derivedContent="RFC6438"/>. When the inner header
is IPv6 then the flow label is not zero, it MAY be used to compute the is IPv6 and the flow label is not zero, it <bcp14>MAY</bcp14> be used
hash.</t> to compute the hash.</t>
</section>
</section> <section anchor="update_mapping" numbered="true" toc="include" removeInRFC="
false" pn="section-13">
<section anchor="update_mapping" title="Changing the Contents of EID-to-RLOC <name slugifiedName="name-changing-the-contents-of-ei">Changing the Conten
Mappings"> ts of EID-to-RLOC Mappings</name>
<t indent="0" pn="section-13-1">Since the LISP architecture uses a caching
<t>Since the LISP architecture uses a caching scheme to scheme to
retrieve and store EID-to-RLOC mappings, the only way an ITR retrieve and store EID-to-RLOC mappings, the only way an ITR
can get a more up-to-date mapping is to re-request the can get a more up-to-date mapping is to re-request the
mapping. However, the ITRs do not know when the mappings mapping. However, the ITRs do not know when the mappings
change, and the ETRs do not keep track of which ITRs change, and the ETRs do not keep track of which ITRs
requested its mappings. For scalability reasons, it is requested their mappings. For scalability reasons, it is
desirable to maintain this approach but need to provide a desirable to maintain this approach, but implementors need to provide a
way for ETRs to change their mappings and inform the sites way for ETRs to change their mappings and inform the sites
that are currently communicating with the ETR site using that are currently communicating with the ETR site using
such mappings.</t> such mappings.</t>
<t indent="0" pn="section-13-2">This section defines two data plane mechan
<t>This section defines two Data-Plane mechanism for updating ism for updating
EID-to-RLOC mappings. Additionally, the Solicit-Map Request EID-to-RLOC mappings. Additionally, the Solicit-Map-Request
(SMR) Control-Plane updating mechanism is specified in <xref (SMR) control plane updating mechanism is specified in <xref target="RFC9301"
target="I-D.ietf-lisp-rfc6833bis" />.</t> format="default" sectionFormat="of" derivedContent="RFC9301"/>.</t>
<section anchor="lsb-changing" numbered="true" toc="include" removeInRFC="
<section anchor="lsb-changing" title="Locator-Status-Bits"> false" pn="section-13.1">
<name slugifiedName="name-locator-status-bits">Locator-Status-Bits</name
<t>Locator-Status-Bits (LSB) can also be used to keep track of the >
Locator status (up or down) when EID-to-RLOC mappings are changing. When LSB a <t indent="0" pn="section-13.1-1">Locator-Status-Bits (LSBs) can also be
re used in a LISP deployment, all LISP tunnel routers MUST implement both ITR an used to keep track of the
d ETR capabilities (therefore all tunnel routers are effectively xTRs). In this Locator status (up or down) when EID-to-RLOC mappings are changing. When LSBs
section the term "source xTR" is used to refer to the xTR setting the LSB and "d are used in a LISP deployment, all LISP Tunnel Routers <bcp14>MUST</bcp14> imple
estination xTR" is used to refer to the xTR receiving the LSB. The procedure is ment both ITR and ETR capabilities (therefore, all Tunnel Routers are effectivel
as follows: y xTRs). In this section, the term "source xTR" is used to refer to the xTR sett
</t> ing the LSB and "destination xTR" is used to refer to the xTR receiving the LSB.
The procedure is as follows:
<t>First, when a Locator record is added or removed from the Locator-Set, the </t>
source xTR <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-13
will signal this by sending a Solicit-Map Request (SMR) Control-Plane message .1-2">
<xref <li pn="section-13.1-2.1" derivedCounter="1.">When a Locator record is a
target="I-D.ietf-lisp-rfc6833bis" /> to the destination xTR. At this point the s dded or removed from the Locator-Set, the source xTR
ource xTR MUST NOT use LSB (L-bit = 0) since the will signal this by sending an SMR control plane message <xref target="RFC9301
destination xTR site has outdated information. The source xTR will setup a 'use- " format="default" sectionFormat="of" derivedContent="RFC9301"/> to the destinat
LSB' timer.</t> ion xTR. At this point, the source xTR <bcp14>MUST NOT</bcp14> use the LSB field
, when the L-bit is 0,
<t>Second and as defined in <xref target="I-D.ietf-lisp-rfc6833bis" />, since the destination xTR site has outdated information.
upon reception of the SMR message the destination xTR will retrieve the updated The source xTR will set up a 'use-LSB' timer.</li>
EID-to-RLOC mappings by sending a Map-Request.</t> <li pn="section-13.1-2.2" derivedCounter="2.">As defined in <xref targ
et="RFC9301" format="default" sectionFormat="of" derivedContent="RFC9301"/>,
<t>And third, when the 'use-LSB' timer expires, the source xTR can use again L upon reception of the SMR message, the destination xTR will retrieve the updated
SB with the destination xTR to signal the Locator status (up or down). EID-to-RLOC mappings by sending a Map-Request.</li>
The specific value for the 'use-LSB' timer depends on the LISP deployment, the <li pn="section-13.1-2.3" derivedCounter="3.">When the 'use-LSB' timer
'use-LSB' timer needs to be large enough expires, the source xTR can use the LSB again with the destination xTR to signa
for the destination xTR to retreive the updated EID-to-RLOC mappings. A RECOMME l the Locator status (up or down).
NDED value for the 'use-LSB' timer is 5 minutes.</t> The specific value for the 'use-LSB' timer depends on the LISP deployment; the
</section> 'use-LSB' timer needs to be large enough
for the destination xTR to retrieve the updated EID-to-RLOC mappings. A <bcp14>R
<section anchor="map-versioning" title="Database Map-Versioning"> ECOMMENDED</bcp14> value for the 'use-LSB' timer is 5 minutes.</li>
<t>When there is unidirectional packet flow between an ITR and </ol>
</section>
<section anchor="map-versioning" numbered="true" toc="include" removeInRFC
="false" pn="section-13.2">
<name slugifiedName="name-database-map-versioning">Database Map-Versioni
ng</name>
<t indent="0" pn="section-13.2-1">When there is unidirectional packet fl
ow between an ITR and
ETR, and the EID-to-RLOC mappings change on the ETR, it needs to ETR, and the EID-to-RLOC mappings change on the ETR, it needs to
inform the ITR so encapsulation to a removed Locator can stop inform the ITR so encapsulation to a removed Locator can stop
and can instead be started to a new Locator in the and can instead be started to a new Locator in the
Locator-Set.</t> Locator-Set.</t>
<t indent="0" pn="section-13.2-2">An ETR can send Map-Reply messages car
<t>An ETR, when it sends Map-Reply messages, conveys its rying a Map-Version Number <xref target="RFC9302" format="default" sectionFormat
own Map-Version Number. This is known as the Destination ="of" derivedContent="RFC9302"/> in
Map-Version Number. ITRs include the Destination an EID-Record. This is known as the Destination Map-Version Number.
Map-Version Number in packets they encapsulate to the ITRs include the Destination Map-Version Number in packets they
site. When an ETR decapsulates a packet and detects that the encapsulate to the site.</t>
Destination Map-Version Number is less than the current <t indent="0" pn="section-13.2-3">An ITR, when it encapsulates packets t
version for its mapping, the SMR procedure described in o ETRs, can convey its own Map-
<xref target="I-D.ietf-lisp-rfc6833bis" /> occurs.</t> Version Number. This is known as the Source Map-Version Number.</t>
<t indent="0" pn="section-13.2-4">When presented in EID-Records of Map-R
<t>An ITR, when it encapsulates packets to ETRs, can convey egister messages <xref target="RFC9301" format="default" sectionFormat="of" deri
its own Map-Version Number. This is known as the Source vedContent="RFC9301"/>, a Map-Version
Map-Version Number. When an ETR decapsulates a packet and Number is a good way for the Map-Server <xref target="RFC9301" format="defaul
detects that the Source Map-Version Number is greater than the t" sectionFormat="of" derivedContent="RFC9301"/> to assure that all ETRs for a
last Map-Version Number sent in a Map-Reply from the ITR's site, site registering to it are synchronized according to the Map-Version
the ETR will send a Map-Request to one of the ETRs for the source Number.</t>
site.</t> <t indent="0" pn="section-13.2-5">See <xref target="RFC9302" format="def
ault" sectionFormat="of" derivedContent="RFC9302"/> for a more
<t>A Map-Version Number is used as a sequence number per
EID-Prefix, so values that are greater are considered to be
more recent. A value
of 0 for the Source Map-Version Number or the Destination
Map-Version Number conveys no versioning information, and an
ITR does no comparison with previously received Map-Version
Numbers.</t>
<t>A Map-Version Number can be included in Map-Register messages
as well. This is a good way for the Map-Server to assure that
all ETRs for a site registering to it will be synchronized
according to Map-Version Number.</t>
<t>Map-Version requires that ETRs within the LISP site are synchronized
with respect to the Map-Version Number, EID-prefix and the set and status
(up/down)
of the RLOCs. The use of Map-Versioning without proper synchronization may
cause
traffic disruption. The synchronization protocol is out-of-the-scope of th
is document, but MUST
keep ETRs synchronized within a 1 minute window.</t>
<t>Map-Versioning MUST NOT be used over the public Internet and
SHOULD only be used in trusted and closed deployments. Refer to
<xref target="SECURITY"/> for security issues regarding this mechanism.</t>
<t>See <xref target="I-D.ietf-lisp-6834bis" /> for a more
detailed analysis and description of Database detailed analysis and description of Database
Map-Versioning.</t> Map-Versioning.</t>
</section> </section>
</section>
</section> <section anchor="multicast" numbered="true" toc="include" removeInRFC="false
" pn="section-14">
<section title="Multicast Considerations" anchor="multicast"> <name slugifiedName="name-multicast-considerations">Multicast Consideratio
<t>A multicast group address, as defined in the original Internet ns</name>
<t indent="0" pn="section-14-1">A multicast group address, as defined in t
he original Internet
architecture, is an identifier of a grouping of topologically architecture, is an identifier of a grouping of topologically
independent receiver host locations. The address encoding itself independent receiver host locations. The address encoding itself
does not determine the location of the receiver(s). The multicast does not determine the location of the receiver(s). The multicast
routing protocol, and the network-based state the protocol creates, routing protocol and the network-based state the protocol creates
determine where the receivers are located.</t> determine where the receivers are located.</t>
<t indent="0" pn="section-14-2">In the context of LISP, a multicast group
<t>In the context of LISP, a multicast group address is both an address is both an
EID and a Routing Locator. Therefore, no specific semantic or EID and an RLOC. Therefore, no specific semantic or
action needs to be taken for a destination address, as it would action needs to be taken for a destination address, as it would
appear in an IP header. Therefore, a group address that appear in an IP header. Therefore, a group address that
appears in an inner IP header built by a source host will be appears in an inner IP header built by a source host will be
used as the destination EID. The outer IP header (the used as the destination EID. The outer IP header (the
destination Routing Locator address), prepended by a LISP destination RLOC address), prepended by a LISP
router, can use the same group address as the destination router, can use the same group address as the destination
Routing Locator, use a multicast or unicast Routing Locator RLOC, use a multicast or unicast RLOC
obtained from a Mapping System lookup, or use other means to obtained from a Mapping System lookup, or use other means to
determine the group address mapping.</t> determine the group address mapping.</t>
<t indent="0" pn="section-14-3">With respect to the source RLOC address, t
<t>With respect to the source Routing Locator address, the ITR he ITR
prepends its own IP address as the source address of the outer prepends its own IP address as the source address of the outer
IP header, just like it would if the destination EID was a IP header, just like it would if the destination EID was a
unicast address. This source Routing Locator address, like any unicast address. This source RLOC address, like any
other Routing Locator address, MUST be routable on the underlay.</t> other RLOC address, <bcp14>MUST</bcp14> be routable on the underlay.</t>
<t indent="0" pn="section-14-4">There are two approaches for LISP-Multicas
<t>There are two approaches for LISP-Multicast, one that uses t <xref target="RFC6831" format="default" sectionFormat="of" derivedContent="RFC
6831"/>: one that uses
native multicast routing in the underlay with no support from native multicast routing in the underlay with no support from
the Mapping System and the other that uses only unicast routing the Mapping System and another that uses only unicast routing
in the underlay with support from the Mapping System. See <xref in the underlay with support from the Mapping System. See <xref target="R
target="RFC6831"/> and <xref target="RFC8378"/>, respectively, FC6831" format="default" sectionFormat="of" derivedContent="RFC6831"/> and <xref
target="RFC8378" format="default" sectionFormat="of" derivedContent="RFC8378"/>
, respectively,
for details. Details for LISP-Multicast and interworking with for details. Details for LISP-Multicast and interworking with
non-LISP sites are described in <xref target="RFC6831"/> and non-LISP sites are described in <xref target="RFC6831" format="default" s
<xref target="RFC6832"/>.</t> ectionFormat="of" derivedContent="RFC6831"/> and
<xref target="RFC6832" format="default" sectionFormat="of" derivedContent
="RFC6832"/>, respectively.</t>
</section> </section>
<section anchor="PUNT" numbered="true" toc="include" removeInRFC="false" pn=
<section title="Router Performance Considerations" "section-15">
anchor="PUNT"> <name slugifiedName="name-router-performance-consider">Router Performance
<t>LISP is designed to be very "hardware-based forwarding Considerations</name>
<t indent="0" pn="section-15-1">LISP is designed to be very "hardware base
d and forwarding
friendly". A few implementation techniques can be used to friendly". A few implementation techniques can be used to
incrementally implement LISP:</t> incrementally implement LISP:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-15-
<t><list style="symbols"> 2">
<t>When a tunnel-encapsulated packet is received by an <li pn="section-15-2.1">When a tunnel-encapsulated packet is received by
an
ETR, the outer destination address may not be the address ETR, the outer destination address may not be the address
of the router. This makes it challenging for the control of the router. This makes it challenging for the control
plane to get packets from the hardware. This may be plane to get packets from the hardware. This may be
mitigated by creating special Forwarding Information Base mitigated by creating special Forwarding Information Base
(FIB) entries for the EID-Prefixes of EIDs served by the (FIB) entries for the EID-Prefixes of EIDs served by the
ETR (those for which the router provides an RLOC ETR (those for which the router provides an RLOC
translation). These FIB entries are marked with a flag translation). These FIB entries are marked with a flag
indicating that Control-Plane processing SHOULD be indicating that control plane processing <bcp14>SHOULD</bcp14> be
performed. The forwarding logic of testing for particular performed. The forwarding logic of testing for particular
IP protocol number values is not necessary. There are a IP protocol number values is not necessary. There are a
few proven cases where no changes to existing deployed few proven cases where no changes to existing deployed
hardware were needed to support the LISP Data-Plane.</t> hardware were needed to support the LISP data plane.</li>
<li pn="section-15-2.2">On an ITR, prepending a new IP header consists o
<t>On an ITR, prepending a new IP header consists of adding f adding
more octets to a MAC rewrite string and prepending the more octets to a Message Authentication Code (MAC) rewrite string an
d prepending the
string as part of the outgoing encapsulation string as part of the outgoing encapsulation
procedure. Routers that support Generic Routing Encapsulation procedure. Routers that support Generic Routing Encapsulation
(GRE) tunneling <xref target="RFC2784"/> or 6to4 tunneling (GRE) tunneling <xref target="RFC2784" format="default" sectionForma
<xref target="RFC3056"/> may already support this t="of" derivedContent="RFC2784"/> or 6to4 tunneling
action.</t> <xref target="RFC3056" format="default" sectionFormat="of" derivedCo
ntent="RFC3056"/> may already support this
<t>A packet's source address or interface the action.</li>
packet was received on can be used to select VRF <li pn="section-15-2.3">A packet's source address or the interface on wh
(Virtual Routing/Forwarding). The VRF's routing table ich the
can be used to find EID-to-RLOC mappings.</t> packet was received can be used to select
</list></t> Virtual Routing and Forwarding (VRF). The VRF system's routing table
can be used to find EID-to-RLOC mappings.</li>
<t>For performance issues related to Map-Cache management, see </ul>
<xref target="SECURITY" />.</t> <t indent="0" pn="section-15-3">For performance issues related to Map-Cach
e management, see
<xref target="SECURITY" format="default" sectionFormat="of" derivedConte
nt="Section 16"/>.</t>
</section> </section>
<section anchor="SECURITY" numbered="true" toc="include" removeInRFC="false"
<section title="Security Considerations" anchor="SECURITY"> pn="section-16">
<t>In what follows we highlight security <name slugifiedName="name-security-considerations">Security Considerations
</name>
<t indent="0" pn="section-16-1">In what follows, we highlight security
considerations that apply when LISP is deployed in environments such considerations that apply when LISP is deployed in environments such
as those specified in <xref target="soa"/>.</t> as those specified in <xref target="soa" format="default" sectionFormat="of" d
erivedContent="Section 1.1"/>.</t>
<t>The optional mechanisms of gleaning is offered to directly obtain <t indent="0" pn="section-16-2">The optional gleaning mechanism is offered
a mapping from the LISP encapsulated packets. Specifically, an xTR to directly obtain
a mapping from the LISP-encapsulated packets. Specifically, an xTR
can learn the EID-to-RLOC mapping by inspecting the source RLOC and can learn the EID-to-RLOC mapping by inspecting the source RLOC and
source EID of an encapsulated packet, and insert this new mapping source EID of an encapsulated packet and insert this new mapping
into its Map-Cache. An off-path attacker can spoof the source EID into its Map-Cache. An off-path attacker can spoof the source EID
address to divert the traffic sent to the victim's spoofed EID. If address to divert the traffic sent to the victim's spoofed EID. If
the attacker spoofs the source RLOC, it can mount a DoS attack by the attacker spoofs the source RLOC, it can mount a DoS attack by
redirecting traffic to the spoofed victim's RLOC, potentially redirecting traffic to the spoofed victim's RLOC, potentially
overloading it.</t> overloading it.</t>
<t indent="0" pn="section-16-3">The LISP data plane defines several mechan
<t>The LISP Data-Plane defines several mechanisms to monitor RLOC isms to monitor RLOC
Data-Plane reachability, in this context Locator-Status Bits, data plane reachability; in this context, Locator-Status-Bits,
Nonce-Present and Echo-Nonce bits of the LISP encapsulation header nonce-present bits, and Echo-Nonce bits of the LISP encapsulation header
can be manipulated by an attacker to mount a DoS attack. An off-path can be manipulated by an attacker to mount a DoS attack. An off-path
attacker able to spoof the RLOC and/or nonce of a victim's xTR can attacker able to spoof the RLOC and/or nonce of a victim's xTR can
manipulate such mechanisms to declare false information about the manipulate such mechanisms to declare false information about the
RLOC's reachability status.</t> RLOC's reachability status.</t>
<t indent="0" pn="section-16-4">An example of such attacks is when an off-
<t>For example of such attacks, an off-path attacker can exploit the path attacker can exploit the
echo-nonce mechanism by sending data packets to an ITR with a random Echo-Nonce mechanism by sending data packets to an ITR with a random
nonce from an ETR's spoofed RLOC. Note the attacker must guess a nonce from an ETR's spoofed RLOC. Note that the attacker only has a small wind
valid nonce the ITR is requesting to be echoed within a small window ow
of time. The goal is to convince the ITR that the ETR's RLOC is of time within which to guess a valid nonce that the ITR is requesting to be e
choed. The goal is to convince the ITR that the ETR's RLOC is
reachable even when it may not be reachable. If the attack is reachable even when it may not be reachable. If the attack is
successful, the ITR believes the wrong reachability status of the successful, the ITR believes the wrong reachability status of the
ETR's RLOC until RLOC-probing detects the correct status. This time ETR's RLOC until RLOC-Probing detects the correct status. This time
frame is on the order of 10s of seconds. This specific attack can frame is on the order of tens of seconds. This specific attack can
be mitigated by preventing RLOC spoofing in the network by deploying be mitigated by preventing RLOC spoofing in the network by deploying
uRPF BCP 38 <xref target="RFC2827"/>. In addition and in order to exploit Unicast Reverse Path Forwarding (uRPF) per <xref target="RFC8704" format="defa
this vulnerability, the off-path attacker must send echo-nonce ult" sectionFormat="of" derivedContent="RFC8704">BCP 84</xref>. In order to expl
packets at high rate. If the nonces have never been requested by the oit
this vulnerability, the off-path attacker must also send Echo-Nonce
packets at a high rate. If the nonces have never been requested by the
ITR, it can protect itself from erroneous reachability attacks.</t> ITR, it can protect itself from erroneous reachability attacks.</t>
<t indent="0" pn="section-16-5">A LISP-specific uRPF check is also possibl
<t>A LISP-specific uRPF check is also possible. When decapsulating, e. When decapsulating,
an ETR can check that the source EID and RLOC are valid EID-to-RLOC an ETR can check that the source EID and RLOC are valid EID-to-RLOC
mappings by checking the Mapping System.</t> mappings by checking the Mapping System.</t>
<t indent="0" pn="section-16-6">Map-Versioning is a data plane mechanism u
<t>Map-Versioning is a Data-Plane mechanism used to signal a peering sed to signal to a peering
xTR that a local EID-to-RLOC mapping has been updated, so that the xTR that a local EID-to-RLOC mapping has been updated so that the
peering xTR uses LISP Control-Plane signaling message to retrieve a peering xTR uses a LISP control plane signaling message to retrieve a
fresh mapping. This can be used by an attacker to forge the fresh mapping. This can be used by an attacker to forge the
map-versioning field of a LISP encapsulated header and force an 'Map-Version' field of a LISP-encapsulated header and force an
excessive amount of signaling between xTRs that may overload them.</t> excessive amount of signaling between xTRs that may overload them.
Further security considerations on Map-Versioning can be found in
<t>Locator-Status-Bits, echo-nonce and map-versioning MUST NOT be used <xref target="RFC9302" format="default" sectionFormat="of" derivedContent=
over the public Internet and SHOULD only be used in trusted "RFC9302"/>.</t>
and closed deployments. In addition Locator-Status-Bits <t indent="0" pn="section-16-7">Locator-Status-Bits, the Echo-Nonce mechan
SHOULD be coupled with map-versioning to prevent race conditions ism, and Map-Versioning <bcp14>MUST NOT</bcp14> be used
over the public Internet and <bcp14>SHOULD</bcp14> only be used in trusted
and closed deployments. In addition, Locator-Status-Bits
<bcp14>SHOULD</bcp14> be coupled with Map-Versioning to prevent race condition
s
where Locator-Status-Bits are interpreted as referring to different RLOCs than intended.</t> where Locator-Status-Bits are interpreted as referring to different RLOCs than intended.</t>
<t indent="0" pn="section-16-8">LISP implementations and deployments that
<t>LISP implementations and deployments which permit outer header fragments permit outer header fragments
of IPv6 LISP encapsulated packets as a means of dealing with MTU issues of IPv6 LISP-encapsulated packets as a means of dealing with MTU issues
should also use implementation techniques in ETRs to prevent this should also use implementation techniques in ETRs to prevent this
from being a DoS attack vector. Limits on the number of fragments from being a DoS attack vector. Limits on the number of fragments
awaiting reassembly at an ETR, RTR, or PETR, and the rate of admitting awaiting reassembly at an ETR, RTR, or PETR, and the rate of admitting
such fragments may be used.</t> such fragments, may be used.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-17">
<section title="Network Management Considerations"> <name slugifiedName="name-network-management-consider">Network Management
<t>Considerations for network management tools exist so the LISP Considerations</name>
<t indent="0" pn="section-17-1">Considerations for network management tool
s exist so the LISP
protocol suite can be operationally managed. These mechanisms can protocol suite can be operationally managed. These mechanisms can
be found in <xref target="RFC7052" /> and <xref target="RFC6835" be found in <xref target="RFC7052" format="default" sectionFormat="of" derived
/>.</t> Content="RFC7052"/> and <xref target="RFC6835" format="default" sectionFormat="o
</section> f" derivedContent="RFC6835"/>.</t>
</section>
<section title="Changes since RFC 6830"> <section numbered="true" toc="include" removeInRFC="false" pn="section-18">
<t>For implementation considerations, the following changes have been made <name slugifiedName="name-changes-since-rfc-6830">Changes since RFC 6830</
to this document since RFC 6830 was published:</t> name>
<t indent="0" pn="section-18-1">For implementation considerations, the fol
<t><list style="symbols"> lowing changes have been made
<t>It is no longer mandated that a maximum number of 2 LISP to this document since <xref target="RFC6830" format="default" sectionFormat="
headers be prepended to a packet. If there is a application need of" derivedContent="RFC6830"/> was published:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-18-
2">
<li pn="section-18-2.1">It is no longer mandated that a maximum number o
f 2 LISP
headers be prepended to a packet. If there is an application need
for more than 2 LISP headers, an implementation can support for more than 2 LISP headers, an implementation can support
more. However, it is RECOMMENDED that a maximum of two LISP more. However, it is <bcp14>RECOMMENDED</bcp14> that a maximum of 2 LISP
headers can be prepended to a packet.</t> headers can be prepended to a packet.</li>
<li pn="section-18-2.2">The 3 reserved flag bits in the LISP header have
<t>The 3 reserved flag bits in the LISP header have been allocated been allocated
for <xref target="RFC8061"/>. The low-order 2 bits of the 3-bit for <xref target="RFC8061" format="default" sectionFormat="of" derivedConten
field (now named the KK bits) are used as a key identifier. The 1 t="RFC8061"/>. The low-order 2 bits of the 3-bit
remaining bit is still documented as reserved and unassigned.</t> field (now named the KK-bits) are used as a key identifier. The 1
remaining bit is still documented as reserved and unassigned.</li>
<t>Data-Plane gleaning for creating map-cache entries has been <li pn="section-18-2.3">Data plane gleaning for creating Map-Cache entri
made optional. Any ITR implementations that depend on or assume the es has been
made optional. Any ITR implementations that depend on or assume that the
remote ETR is gleaning should not do so. This does not create any remote ETR is gleaning should not do so. This does not create any
interoperability problems since the control-plane map-cache interoperability problems, since the control plane Map-Cache
population procedures are unilateral and are the typical method population procedures are unilateral and are the typical method
for map-cache population.</t> for populating the Map-Cache.</li>
<li pn="section-18-2.4">Most of the changes to this document, which redu
<t>The bulk of the changes to this document which reduces its ce its
length are due to moving the LISP control-plane messaging and length, are due to moving the LISP control plane messaging and
procedures to <xref target="I-D.ietf-lisp-rfc6833bis" />.</t> procedures to <xref target="RFC9301" format="default" sectionFormat="of" der
</list></t> ivedContent="RFC9301"/>.</li>
</section> </ul>
</section>
<section title="IANA Considerations" anchor="IANA"> <section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn=
<t>This section provides guidance to the Internet Assigned Numbers "section-19">
<name slugifiedName="name-iana-considerations">IANA Considerations</name>
<t indent="0" pn="section-19-1">This section provides guidance to the Inte
rnet Assigned Numbers
Authority (IANA) regarding registration of values related to this Authority (IANA) regarding registration of values related to this
Data-Plane LISP specification, in accordance with BCP 26 <xref data plane LISP specification, in accordance with <xref target="RFC8126" forma
target="RFC8126" />.</t> t="default" sectionFormat="of" derivedContent="RFC8126">BCP 26</xref>.</t>
<section numbered="true" toc="include" removeInRFC="false" pn="section-19.
<section title="LISP UDP Port Numbers"> 1">
<t>The IANA registry has allocated UDP port number 4341 for the <name slugifiedName="name-lisp-udp-port-numbers">LISP UDP Port Numbers</
LISP Data-Plane. IANA has updated the description for UDP port name>
<t indent="0" pn="section-19.1-1">IANA has allocated UDP port number 434
1 for the
LISP data plane. IANA has updated the description for UDP port
4341 as follows:</t> 4341 as follows:</t>
<table anchor="iana-port-number" align="center" pn="table-1">
<name/>
<thead>
<tr>
<th align="left" colspan="1" rowspan="1">Service Name</th>
<th align="left" colspan="1" rowspan="1">Port Number</th>
<th align="left" colspan="1" rowspan="1">Transport Protocol</th>
<th align="left" colspan="1" rowspan="1">Description</th>
<th align="left" colspan="1" rowspan="1">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left" colspan="1" rowspan="1">lisp-data</td>
<td align="left" colspan="1" rowspan="1">4341</td>
<td align="left" colspan="1" rowspan="1">udp</td>
<td align="left" colspan="1" rowspan="1">LISP Data Packets</td>
<td align="left" colspan="1" rowspan="1">RFC 9300</td>
</tr>
</tbody>
</table>
</section>
</section>
</middle>
<back>
<displayreference target="I-D.ietf-lisp-vpn" to="LISP-VPN"/>
<references pn="section-20">
<name slugifiedName="name-references">References</name>
<references pn="section-20.1">
<name slugifiedName="name-normative-references">Normative References</na
me>
<reference anchor="RFC0768" target="https://www.rfc-editor.org/info/rfc7
68" quoteTitle="true" derivedAnchor="RFC0768">
<front>
<title>User Datagram Protocol</title>
<author fullname="J. Postel" initials="J." surname="Postel"/>
<date month="August" year="1980"/>
</front>
<seriesInfo name="STD" value="6"/>
<seriesInfo name="RFC" value="768"/>
<seriesInfo name="DOI" value="10.17487/RFC0768"/>
</reference>
<reference anchor="RFC0791" target="https://www.rfc-editor.org/info/rfc7
91" quoteTitle="true" derivedAnchor="RFC0791">
<front>
<title>Internet Protocol</title>
<author fullname="J. Postel" initials="J." surname="Postel"/>
<date month="September" year="1981"/>
</front>
<seriesInfo name="STD" value="5"/>
<seriesInfo name="RFC" value="791"/>
<seriesInfo name="DOI" value="10.17487/RFC0791"/>
</reference>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119" quoteTitle="true" derivedAnchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t indent="0">In many standards track documents several words are
used to signify the requirements in the specification. These words are often ca
pitalized. This document defines these words as they should be interpreted in I
ETF documents. This document specifies an Internet Best Current Practices for t
he Internet Community, and requests discussion and suggestions for improvements.
</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC2474" target="https://www.rfc-editor.org/info/rfc2
474" quoteTitle="true" derivedAnchor="RFC2474">
<front>
<title>Definition of the Differentiated Services Field (DS Field) in
the IPv4 and IPv6 Headers</title>
<author fullname="K. Nichols" initials="K." surname="Nichols"/>
<author fullname="S. Blake" initials="S." surname="Blake"/>
<author fullname="F. Baker" initials="F." surname="Baker"/>
<author fullname="D. Black" initials="D." surname="Black"/>
<date month="December" year="1998"/>
<abstract>
<t indent="0">This document defines the IP header field, called th
e DS (for differentiated services) field. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2474"/>
<seriesInfo name="DOI" value="10.17487/RFC2474"/>
</reference>
<reference anchor="RFC2983" target="https://www.rfc-editor.org/info/rfc2
983" quoteTitle="true" derivedAnchor="RFC2983">
<front>
<title>Differentiated Services and Tunnels</title>
<author fullname="D. Black" initials="D." surname="Black"/>
<date month="October" year="2000"/>
<abstract>
<t indent="0">This document considers the interaction of Different
iated Services (diffserv) with IP tunnels of various forms. This memo provides
information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2983"/>
<seriesInfo name="DOI" value="10.17487/RFC2983"/>
</reference>
<reference anchor="RFC6040" target="https://www.rfc-editor.org/info/rfc6
040" quoteTitle="true" derivedAnchor="RFC6040">
<front>
<title>Tunnelling of Explicit Congestion Notification</title>
<author fullname="B. Briscoe" initials="B." surname="Briscoe"/>
<date month="November" year="2010"/>
<abstract>
<t indent="0">This document redefines how the explicit congestion
notification (ECN) field of the IP header should be constructed on entry to and
exit from any IP-in-IP tunnel. On encapsulation, it updates RFC 3168 to bring a
ll IP-in-IP tunnels (v4 or v6) into line with RFC 4301 IPsec ECN processing. On
decapsulation, it updates both RFC 3168 and RFC 4301 to add new behaviours for
previously unused combinations of inner and outer headers. The new rules ensure
the ECN field is correctly propagated across a tunnel whether it is used to sig
nal one or two severity levels of congestion; whereas before, only one severity
level was supported. Tunnel endpoints can be updated in any order without affec
ting pre-existing uses of the ECN field, thus ensuring backward compatibility.
Nonetheless, operators wanting to support two severity levels (e.g., for pre-con
gestion notification -- PCN) can require compliance with this new specification.
A thorough analysis of the reasoning for these changes and the implications is
included. In the unlikely event that the new rules do not meet a specific need
, RFC 4774 gives guidance on designing alternate ECN semantics, and this documen
t extends that to include tunnelling issues. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6040"/>
<seriesInfo name="DOI" value="10.17487/RFC6040"/>
</reference>
<reference anchor="RFC6438" target="https://www.rfc-editor.org/info/rfc6
438" quoteTitle="true" derivedAnchor="RFC6438">
<front>
<title>Using the IPv6 Flow Label for Equal Cost Multipath Routing an
d Link Aggregation in Tunnels</title>
<author fullname="B. Carpenter" initials="B." surname="Carpenter"/>
<author fullname="S. Amante" initials="S." surname="Amante"/>
<date month="November" year="2011"/>
<abstract>
<t indent="0">The IPv6 flow label has certain restrictions on its
use. This document describes how those restrictions apply when using the flow l
abel for load balancing by equal cost multipath routing and for link aggregation
, particularly for IP-in-IPv6 tunneled traffic. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6438"/>
<seriesInfo name="DOI" value="10.17487/RFC6438"/>
</reference>
<reference anchor="RFC6830" target="https://www.rfc-editor.org/info/rfc6
830" quoteTitle="true" derivedAnchor="RFC6830">
<front>
<title>The Locator/ID Separation Protocol (LISP)</title>
<author fullname="D. Farinacci" initials="D." surname="Farinacci"/>
<author fullname="V. Fuller" initials="V." surname="Fuller"/>
<author fullname="D. Meyer" initials="D." surname="Meyer"/>
<author fullname="D. Lewis" initials="D." surname="Lewis"/>
<date month="January" year="2013"/>
<abstract>
<t indent="0">This document describes a network-layer-based protoc
ol that enables separation of IP addresses into two new numbering spaces: Endpoi
nt Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to e
ither host protocol stacks or to the "core" of the Internet infrastructure. The
Locator/ID Separation Protocol (LISP) can be incrementally deployed, without a "
flag day", and offers Traffic Engineering, multihoming, and mobility benefits to
early adopters, even when there are relatively few LISP-capable sites.</t>
<t indent="0">Design and development of LISP was largely motivated
by the problem statement produced by the October 2006 IAB Routing and Addressin
g Workshop. This document defines an Experimental Protocol for the Internet comm
unity.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6830"/>
<seriesInfo name="DOI" value="10.17487/RFC6830"/>
</reference>
<reference anchor="RFC6831" target="https://www.rfc-editor.org/info/rfc6
831" quoteTitle="true" derivedAnchor="RFC6831">
<front>
<title>The Locator/ID Separation Protocol (LISP) for Multicast Envir
onments</title>
<author fullname="D. Farinacci" initials="D." surname="Farinacci"/>
<author fullname="D. Meyer" initials="D." surname="Meyer"/>
<author fullname="J. Zwiebel" initials="J." surname="Zwiebel"/>
<author fullname="S. Venaas" initials="S." surname="Venaas"/>
<date month="January" year="2013"/>
<abstract>
<t indent="0">This document describes how inter-domain multicast r
outing will function in an environment where Locator/ID Separation is deployed u
sing the Locator/ID Separation Protocol (LISP) architecture. This document defi
nes an Experimental Protocol for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6831"/>
<seriesInfo name="DOI" value="10.17487/RFC6831"/>
</reference>
<reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8
126" quoteTitle="true" derivedAnchor="RFC8126">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs
</title>
<author fullname="M. Cotton" initials="M." surname="Cotton"/>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<date month="June" year="2017"/>
<abstract>
<t indent="0">Many protocols make use of points of extensibility t
hat use constants to identify various protocol parameters. To ensure that the va
lues in these fields do not have conflicting uses and to promote interoperabilit
y, their allocations are often coordinated by a central record keeper. For IETF
protocols, that role is filled by the Internet Assigned Numbers Authority (IANA)
.</t>
<t indent="0">To make assignments in a given registry prudently, g
uidance describing the conditions under which new values should be assigned, as
well as when and how modifications to existing values can be made, is needed. Th
is document defines a framework for the documentation of these guidelines by spe
cification authors, in order to assure that the provided guidance for the IANA C
onsiderations is clear and addresses the various issues that are likely in the o
peration of a registry.</t>
<t indent="0">This is the third edition of this document; it obsol
etes RFC 5226.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" quoteTitle="true" derivedAnchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t indent="0">RFC 2119 specifies common key words that may be used
in protocol specifications. This document aims to reduce the ambiguity by clar
ifying that only UPPERCASE usage of the key words have the defined special meani
ngs.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8200" target="https://www.rfc-editor.org/info/rfc8
200" quoteTitle="true" derivedAnchor="RFC8200">
<front>
<title>Internet Protocol, Version 6 (IPv6) Specification</title>
<author fullname="S. Deering" initials="S." surname="Deering"/>
<author fullname="R. Hinden" initials="R." surname="Hinden"/>
<date month="July" year="2017"/>
<abstract>
<t indent="0">This document specifies version 6 of the Internet Pr
otocol (IPv6). It obsoletes RFC 2460.</t>
</abstract>
</front>
<seriesInfo name="STD" value="86"/>
<seriesInfo name="RFC" value="8200"/>
<seriesInfo name="DOI" value="10.17487/RFC8200"/>
</reference>
<reference anchor="RFC8378" target="https://www.rfc-editor.org/info/rfc8
378" quoteTitle="true" derivedAnchor="RFC8378">
<front>
<title>Signal-Free Locator/ID Separation Protocol (LISP) Multicast</
title>
<author fullname="V. Moreno" initials="V." surname="Moreno"/>
<author fullname="D. Farinacci" initials="D." surname="Farinacci"/>
<date month="May" year="2018"/>
<abstract>
<t indent="0">When multicast sources and receivers are active at L
ocator/ID Separation Protocol (LISP) sites, the core network is required to use
native multicast so packets can be delivered from sources to group members. Whe
n multicast is not available to connect the multicast sites together, a signal-f
ree mechanism can be used to allow traffic to flow between sites. The mechanism
described in this document uses unicast replication and encapsulation over the
core network for the data plane and uses the LISP mapping database system so enc
apsulators at the source LISP multicast site can find decapsulators at the recei
ver LISP multicast sites.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8378"/>
<seriesInfo name="DOI" value="10.17487/RFC8378"/>
</reference>
<reference anchor="RFC8704" target="https://www.rfc-editor.org/info/rfc8
704" quoteTitle="true" derivedAnchor="RFC8704">
<front>
<title>Enhanced Feasible-Path Unicast Reverse Path Forwarding</title
>
<author fullname="K. Sriram" initials="K." surname="Sriram"/>
<author fullname="D. Montgomery" initials="D." surname="Montgomery"/
>
<author fullname="J. Haas" initials="J." surname="Haas"/>
<date month="February" year="2020"/>
<abstract>
<t indent="0">This document identifies a need for and proposes imp
rovement of the unicast Reverse Path Forwarding (uRPF) techniques (see RFC 3704)
for detection and mitigation of source address spoofing (see BCP 38). Strict u
RPF is inflexible about directionality, the loose uRPF is oblivious to direction
ality, and the current feasible-path uRPF attempts to strike a balance between t
he two (see RFC 3704). However, as shown in this document, the existing feasibl
e-path uRPF still has shortcomings. This document describes enhanced feasible-p
ath uRPF (EFP-uRPF) techniques that are more flexible (in a meaningful way) abou
t directionality than the feasible-path uRPF (RFC 3704). The proposed EFP-uRPF
methods aim to significantly reduce false positives regarding invalid detection
in source address validation (SAV). Hence, they can potentially alleviate ISPs'
concerns about the possibility of disrupting service for their customers and en
courage greater deployment of uRPF techniques. This document updates RFC 3704.<
/t>
</abstract>
</front>
<seriesInfo name="BCP" value="84"/>
<seriesInfo name="RFC" value="8704"/>
<seriesInfo name="DOI" value="10.17487/RFC8704"/>
</reference>
<reference anchor="RFC9301" target="https://www.rfc-editor.org/info/rfc9
301" quoteTitle="true" derivedAnchor="RFC9301">
<front>
<title>Locator/ID Separation Protocol (LISP) Control Plane</title>
<author initials="D" surname="Farinacci" fullname="Dino Farinacci">
<organization showOnFrontPage="true"/>
</author>
<author initials="F" surname="Maino" fullname="Fabio Maino">
<organization showOnFrontPage="true"/>
</author>
<author initials="V" surname="Fuller" fullname="Vince Fuller">
<organization showOnFrontPage="true"/>
</author>
<author initials="A" surname="Cabellos" fullname="Albert Cabellos" r
ole="editor">
<organization showOnFrontPage="true"/>
</author>
<date month="October" year="2022"/>
</front>
<seriesInfo name="RFC" value="9301"/>
<seriesInfo name="DOI" value="10.17487/RFC9301"/>
</reference>
<reference anchor="RFC9302" target="https://www.rfc-editor.org/info/rfc9
302" quoteTitle="true" derivedAnchor="RFC9302">
<front>
<title>Locator/ID Separation Protocol (LISP) Map-Versioning</title>
<author initials="L" surname="Iannone" fullname="Luigi Iannone">
<organization showOnFrontPage="true"/>
</author>
<author initials="D" surname="Saucez" fullname="Damien Saucez">
<organization showOnFrontPage="true"/>
</author>
<author initials="O" surname="Bonaventure" fullname="Olivier Bonaven
ture">
<organization showOnFrontPage="true"/>
</author>
<date month="October" year="2022"/>
</front>
<seriesInfo name="RFC" value="9302"/>
<seriesInfo name="DOI" value="10.17487/RFC9302"/>
</reference>
</references>
<references pn="section-20.2">
<name slugifiedName="name-informative-references">Informative References
</name>
<reference anchor="AFN" target="http://www.iana.org/assignments/address-
family-numbers" quoteTitle="true" derivedAnchor="AFN">
<front>
<title>Address Family Numbers</title>
<author>
<organization showOnFrontPage="true">IANA</organization>
</author>
</front>
</reference>
<reference anchor="CHIAPPA" target="http://mercury.lcs.mit.edu/~jnc/tech
/endpoints.txt" quoteTitle="true" derivedAnchor="CHIAPPA">
<front>
<title>Endpoints and Endpoint Names: A Proposed Enhancement to the I
nternet Architecture</title>
<author initials="J." surname="Chiappa" fullname="J. Noel Chiappa">
<organization showOnFrontPage="true"/>
</author>
<date year="1999"/>
</front>
</reference>
<reference anchor="I-D.ietf-lisp-vpn" quoteTitle="true" target="https://
datatracker.ietf.org/doc/html/draft-ietf-lisp-vpn-10" derivedAnchor="LISP-VPN">
<front>
<title>LISP Virtual Private Networks (VPNs)</title>
<author initials="V." surname="Moreno" fullname="Victor Moreno">
<organization showOnFrontPage="true">Google LLC</organization>
</author>
<author initials="D." surname="Farinacci" fullname="Dino Farinacci">
<organization showOnFrontPage="true">lispers.net</organization>
</author>
<date month="October" day="3" year="2022"/>
<abstract>
<t indent="0"> This document describes the use of the Locator/ID
Separation Protocol
(LISP) to create Virtual Private Networks (VPNs). LISP is used to
provide segmentation in both the LISP data plane and control plane.
These VPNs can be created over the top of the Internet or over
private transport networks, and can be implemented by Enterprises or
Service Providers. The goal of these VPNs is to leverage the
characteristics of LISP - routing scalability, simply expressed
Ingress site TE Policy, IP Address Family traversal, and mobility, in
ways that provide value to network operators.
<figure> <artwork><![CDATA[ </t>
lisp-data 4341 udp LISP Data Packets </abstract>
]]></artwork> </figure> </front>
</section> <seriesInfo name="Internet-Draft" value="draft-ietf-lisp-vpn-10"/>
</section> <format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-
lisp-vpn-10.txt"/>
</middle> <refcontent>Work in Progress</refcontent>
</reference>
<back> <reference anchor="RFC1034" target="https://www.rfc-editor.org/info/rfc1
034" quoteTitle="true" derivedAnchor="RFC1034">
<references title='Normative References'> <front>
<?rfc include="reference.RFC.2827'?> <title>Domain names - concepts and facilities</title>
<?rfc include="reference.RFC.2119'?> <author fullname="P. Mockapetris" initials="P." surname="Mockapetris
<?rfc include="reference.RFC.6040'?> "/>
<?rfc include="reference.RFC.2474'?> <date month="November" year="1987"/>
<?rfc include="reference.RFC.8200'?> <abstract>
<?rfc include="reference.RFC.0768'?> <t indent="0">This RFC is the revised basic definition of The Doma
<?rfc include="reference.RFC.6438'?> in Name System. It obsoletes RFC-882. This memo describes the domain style nam
<?rfc include="reference.RFC.0791'?> es and their used for host address look up and electronic mail forwarding. It d
<?rfc include="reference.RFC.2983'?> iscusses the clients and servers in the domain name system and the protocol used
<?rfc include="reference.RFC.6830'?> between them.</t>
<?rfc include="reference.RFC.6831'?> </abstract>
<?rfc include="reference.RFC.8378'?> </front>
<?rfc include="reference.RFC.8174'?> <seriesInfo name="STD" value="13"/>
<?rfc include="reference.RFC.8126'?> <seriesInfo name="RFC" value="1034"/>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-l <seriesInfo name="DOI" value="10.17487/RFC1034"/>
isp-rfc6833bis.xml'?> </reference>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-l <reference anchor="RFC1191" target="https://www.rfc-editor.org/info/rfc1
isp-6834bis.xml'?> 191" quoteTitle="true" derivedAnchor="RFC1191">
</references> <front>
<title>Path MTU discovery</title>
<references title="Informative References"> <author fullname="J. Mogul" initials="J." surname="Mogul"/>
<?rfc include="reference.RFC.1191'?> <author fullname="S. Deering" initials="S." surname="Deering"/>
<?rfc include="reference.RFC.1981'?> <date month="November" year="1990"/>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D <abstract>
.ietf-tsvwg-datagram-plpmtud.xml'?> <t indent="0">This memo describes a technique for dynamically disc
<?rfc include="reference.RFC.4821'?> overing the maximum transmission unit (MTU) of an arbitrary internet path. It s
<?rfc include="reference.RFC.3232'?> pecifies a small change to the way routers generate one type of ICMP message. F
<?rfc include="reference.RFC.4086'?> or a path that passes through a router that has not been so changed, this techni
<?rfc include="reference.RFC.4459'?> que might not discover the correct Path MTU, but it will always choose a Path MT
<?rfc include="reference.RFC.1918'?> U as accurate as, and in many cases more accurate than, the Path MTU that would
<?rfc include="reference.RFC.8061'?> be chosen by current practice. [STANDARDS-TRACK]</t>
<?rfc include="reference.RFC.7215'?> </abstract>
<?rfc include="reference.RFC.7052'?> </front>
<?rfc include="reference.RFC.1034'?> <seriesInfo name="RFC" value="1191"/>
<?rfc include="reference.RFC.3261'?> <seriesInfo name="DOI" value="10.17487/RFC1191"/>
<?rfc include="reference.RFC.2784'?> </reference>
<?rfc include="reference.RFC.3056'?> <reference anchor="RFC2453" target="https://www.rfc-editor.org/info/rfc2
<?rfc include="reference.RFC.4984'?> 453" quoteTitle="true" derivedAnchor="RFC2453">
<?rfc include="reference.RFC.6832'?> <front>
<?rfc include="reference.RFC.6835'?> <title>RIP Version 2</title>
<?rfc include="reference.RFC.8060'?> <author fullname="G. Malkin" initials="G." surname="Malkin"/>
<?rfc include="reference.RFC.6935'?> <date month="November" year="1998"/>
<?rfc include="reference.RFC.6936'?> <abstract>
<?rfc include="reference.RFC.8085'?> <t indent="0">This document specifies an extension of the Routing
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-l Information Protocol (RIP) to expand the amount of useful information carried in
isp-introduction.xml'?> RIP messages and to add a measure of security. [STANDARDS-TRACK]</t>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-l </abstract>
isp-vpn.xml'?> </front>
<seriesInfo name="STD" value="56"/>
<reference anchor="CHIAPPA" target="http://mercury.lcs.mit.edu/~jnc/tech/endpo <seriesInfo name="RFC" value="2453"/>
ints.txt"> <seriesInfo name="DOI" value="10.17487/RFC2453"/>
<front> </reference>
<title>Endpoints and Endpoint names: A Proposed <reference anchor="RFC2677" target="https://www.rfc-editor.org/info/rfc2
</title> 677" quoteTitle="true" derivedAnchor="RFC2677">
<author initials="J." surname="Chiappa"> <front>
<organization /> </author> <title>Definitions of Managed Objects for the NBMA Next Hop Resoluti
<date year="1999"/> on Protocol (NHRP)</title>
</front> <author fullname="M. Greene" initials="M." surname="Greene"/>
</reference> <author fullname="J. Cucchiara" initials="J." surname="Cucchiara"/>
<author fullname="J. Luciani" initials="J." surname="Luciani"/>
<reference anchor="AFN" target="http://www.iana.org/assignments/address-family <date month="August" year="1999"/>
-numbers"> <abstract>
<front> <t indent="0">This memo defines a portion of the Management Inform
<title>Address Family Numbers</title> ation Base (MIB) for use with network management protocols in the Internet commu
<author> nity. [STANDARDS-TRACK]</t>
<organization>IANA</organization> </author> </abstract>
<date month="August" year="2016"/> </front>
</front> <seriesInfo name="RFC" value="2677"/>
</reference> <seriesInfo name="DOI" value="10.17487/RFC2677"/>
</reference>
</references> <reference anchor="RFC2784" target="https://www.rfc-editor.org/info/rfc2
784" quoteTitle="true" derivedAnchor="RFC2784">
<section title="Acknowledgments"> <front>
<t>An initial thank you goes to Dave Oran for planting the seeds for <title>Generic Routing Encapsulation (GRE)</title>
<author fullname="D. Farinacci" initials="D." surname="Farinacci"/>
<author fullname="T. Li" initials="T." surname="Li"/>
<author fullname="S. Hanks" initials="S." surname="Hanks"/>
<author fullname="D. Meyer" initials="D." surname="Meyer"/>
<author fullname="P. Traina" initials="P." surname="Traina"/>
<date month="March" year="2000"/>
<abstract>
<t indent="0">This document specifies a protocol for encapsulation
of an arbitrary network layer protocol over another arbitrary network layer pro
tocol. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2784"/>
<seriesInfo name="DOI" value="10.17487/RFC2784"/>
</reference>
<reference anchor="RFC3056" target="https://www.rfc-editor.org/info/rfc3
056" quoteTitle="true" derivedAnchor="RFC3056">
<front>
<title>Connection of IPv6 Domains via IPv4 Clouds</title>
<author fullname="B. Carpenter" initials="B." surname="Carpenter"/>
<author fullname="K. Moore" initials="K." surname="Moore"/>
<date month="February" year="2001"/>
<abstract>
<t indent="0">This memo specifies an optional interim mechanism fo
r IPv6 sites to communicate with each other over the IPv4 network without explic
it tunnel setup, and for them to communicate with native IPv6 domains via relay
routers. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3056"/>
<seriesInfo name="DOI" value="10.17487/RFC3056"/>
</reference>
<reference anchor="RFC3261" target="https://www.rfc-editor.org/info/rfc3
261" quoteTitle="true" derivedAnchor="RFC3261">
<front>
<title>SIP: Session Initiation Protocol</title>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg"/>
<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne
"/>
<author fullname="G. Camarillo" initials="G." surname="Camarillo"/>
<author fullname="A. Johnston" initials="A." surname="Johnston"/>
<author fullname="J. Peterson" initials="J." surname="Peterson"/>
<author fullname="R. Sparks" initials="R." surname="Sparks"/>
<author fullname="M. Handley" initials="M." surname="Handley"/>
<author fullname="E. Schooler" initials="E." surname="Schooler"/>
<date month="June" year="2002"/>
<abstract>
<t indent="0">This document describes Session Initiation Protocol
(SIP), an application-layer control (signaling) protocol for creating, modifying
, and terminating sessions with one or more participants. These sessions includ
e Internet telephone calls, multimedia distribution, and multimedia conferences.
[STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3261"/>
<seriesInfo name="DOI" value="10.17487/RFC3261"/>
</reference>
<reference anchor="RFC4086" target="https://www.rfc-editor.org/info/rfc4
086" quoteTitle="true" derivedAnchor="RFC4086">
<front>
<title>Randomness Requirements for Security</title>
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3
rd"/>
<author fullname="J. Schiller" initials="J." surname="Schiller"/>
<author fullname="S. Crocker" initials="S." surname="Crocker"/>
<date month="June" year="2005"/>
<abstract>
<t indent="0">Security systems are built on strong cryptographic a
lgorithms that foil pattern analysis attempts. However, the security of these sy
stems is dependent on generating secret quantities for passwords, cryptographic
keys, and similar quantities. The use of pseudo-random processes to generate sec
ret quantities can result in pseudo-security. A sophisticated attacker may find
it easier to reproduce the environment that produced the secret quantities and t
o search the resulting small set of possibilities than to locate the quantities
in the whole of the potential number space.</t>
<t indent="0">Choosing random quantities to foil a resourceful and
motivated adversary is surprisingly difficult. This document points out many pi
tfalls in using poor entropy sources or traditional pseudo-random number generat
ion techniques for generating such quantities. It recommends the use of truly ra
ndom hardware techniques and shows that the existing hardware on many systems ca
n be used for this purpose. It provides suggestions to ameliorate the problem wh
en a hardware solution is not available, and it gives examples of how large such
quantities need to be for some applications. This document specifies an Interne
t Best Current Practices for the Internet Community, and requests discussion and
suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="106"/>
<seriesInfo name="RFC" value="4086"/>
<seriesInfo name="DOI" value="10.17487/RFC4086"/>
</reference>
<reference anchor="RFC4459" target="https://www.rfc-editor.org/info/rfc4
459" quoteTitle="true" derivedAnchor="RFC4459">
<front>
<title>MTU and Fragmentation Issues with In-the-Network Tunneling</t
itle>
<author fullname="P. Savola" initials="P." surname="Savola"/>
<date month="April" year="2006"/>
<abstract>
<t indent="0">Tunneling techniques such as IP-in-IP when deployed
in the middle of the network, typically between routers, have certain issues reg
arding how large packets can be handled: whether such packets would be fragmente
d and reassembled (and how), whether Path MTU Discovery would be used, or how th
is scenario could be operationally avoided. This memo justifies why this is a c
ommon, non-trivial problem, and goes on to describe the different solutions and
their characteristics at some length. This memo provides information for the In
ternet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4459"/>
<seriesInfo name="DOI" value="10.17487/RFC4459"/>
</reference>
<reference anchor="RFC4760" target="https://www.rfc-editor.org/info/rfc4
760" quoteTitle="true" derivedAnchor="RFC4760">
<front>
<title>Multiprotocol Extensions for BGP-4</title>
<author fullname="T. Bates" initials="T." surname="Bates"/>
<author fullname="R. Chandra" initials="R." surname="Chandra"/>
<author fullname="D. Katz" initials="D." surname="Katz"/>
<author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
<date month="January" year="2007"/>
<abstract>
<t indent="0">This document defines extensions to BGP-4 to enable
it to carry routing information for multiple Network Layer protocols (e.g., IPv6
, IPX, L3VPN, etc.). The extensions are backward compatible - a router that sup
ports the extensions can interoperate with a router that doesn't support the ext
ensions. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4760"/>
<seriesInfo name="DOI" value="10.17487/RFC4760"/>
</reference>
<reference anchor="RFC4821" target="https://www.rfc-editor.org/info/rfc4
821" quoteTitle="true" derivedAnchor="RFC4821">
<front>
<title>Packetization Layer Path MTU Discovery</title>
<author fullname="M. Mathis" initials="M." surname="Mathis"/>
<author fullname="J. Heffner" initials="J." surname="Heffner"/>
<date month="March" year="2007"/>
<abstract>
<t indent="0">This document describes a robust method for Path MTU
Discovery (PMTUD) that relies on TCP or some other Packetization Layer to probe
an Internet path with progressively larger packets. This method is described a
s an extension to RFC 1191 and RFC 1981, which specify ICMP-based Path MTU Disco
very for IP versions 4 and 6, respectively. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4821"/>
<seriesInfo name="DOI" value="10.17487/RFC4821"/>
</reference>
<reference anchor="RFC4984" target="https://www.rfc-editor.org/info/rfc4
984" quoteTitle="true" derivedAnchor="RFC4984">
<front>
<title>Report from the IAB Workshop on Routing and Addressing</title
>
<author fullname="D. Meyer" initials="D." role="editor" surname="Mey
er"/>
<author fullname="L. Zhang" initials="L." role="editor" surname="Zha
ng"/>
<author fullname="K. Fall" initials="K." role="editor" surname="Fall
"/>
<date month="September" year="2007"/>
<abstract>
<t indent="0">This document reports the outcome of the Routing and
Addressing Workshop that was held by the Internet Architecture Board (IAB) on O
ctober 18-19, 2006, in Amsterdam, Netherlands. The primary goal of the workshop
was to develop a shared understanding of the problems that the large backbone op
erators are facing regarding the scalability of today's Internet routing system.
The key workshop findings include an analysis of the major factors that are dri
ving routing table growth, constraints in router technology, and the limitations
of today's Internet addressing architecture. It is hoped that these findings wi
ll serve as input to the IETF community and help identify next steps towards eff
ective solutions.</t>
<t indent="0">Note that this document is a report on the proceedin
gs of the workshop. The views and positions documented in this report are those
of the workshop participants and not of the IAB. Furthermore, note that work on
issues related to this workshop report is continuing, and this document does not
intend to reflect the increased understanding of issues nor to discuss the rang
e of potential solutions that may be the outcome of this ongoing work. This memo
provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4984"/>
<seriesInfo name="DOI" value="10.17487/RFC4984"/>
</reference>
<reference anchor="RFC6832" target="https://www.rfc-editor.org/info/rfc6
832" quoteTitle="true" derivedAnchor="RFC6832">
<front>
<title>Interworking between Locator/ID Separation Protocol (LISP) an
d Non-LISP Sites</title>
<author fullname="D. Lewis" initials="D." surname="Lewis"/>
<author fullname="D. Meyer" initials="D." surname="Meyer"/>
<author fullname="D. Farinacci" initials="D." surname="Farinacci"/>
<author fullname="V. Fuller" initials="V." surname="Fuller"/>
<date month="January" year="2013"/>
<abstract>
<t indent="0">This document describes techniques for allowing site
s running the Locator/ID Separation Protocol (LISP) to interoperate with Interne
t sites that may be using either IPv4, IPv6, or both but that are not running LI
SP. A fundamental property of LISP-speaking sites is that they use Endpoint Ide
ntifiers (EIDs), rather than traditional IP addresses, in the source and destina
tion fields of all traffic they emit or receive. While EIDs are syntactically i
dentical to IPv4 or IPv6 addresses, normally routes to them are not carried in t
he global routing system, so an interoperability mechanism is needed for non- LI
SP-speaking sites to exchange traffic with LISP-speaking sites. This document i
ntroduces three such mechanisms. The first uses a new network element, the LISP
Proxy Ingress Tunnel Router (Proxy-ITR), to act as an intermediate LISP Ingress
Tunnel Router (ITR) for non-LISP- speaking hosts. Second, this document adds N
etwork Address Translation (NAT) functionality to LISP ITRs and LISP Egress Tunn
el Routers (ETRs) to substitute routable IP addresses for non-routable EIDs. Fi
nally, this document introduces the Proxy Egress Tunnel Router (Proxy-ETR) to ha
ndle cases where a LISP ITR cannot send packets to non-LISP sites without encaps
ulation. This document defines an Experimental Protocol for the Internet commun
ity.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6832"/>
<seriesInfo name="DOI" value="10.17487/RFC6832"/>
</reference>
<reference anchor="RFC6835" target="https://www.rfc-editor.org/info/rfc6
835" quoteTitle="true" derivedAnchor="RFC6835">
<front>
<title>The Locator/ID Separation Protocol Internet Groper (LIG)</tit
le>
<author fullname="D. Farinacci" initials="D." surname="Farinacci"/>
<author fullname="D. Meyer" initials="D." surname="Meyer"/>
<date month="January" year="2013"/>
<abstract>
<t indent="0">A simple tool called the Locator/ID Separation Proto
col (LISP) Internet Groper or 'lig' can be used to query the LISP mapping databa
se. This document describes how it works. This document is not an Internet Sta
ndards Track specification; it is published for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6835"/>
<seriesInfo name="DOI" value="10.17487/RFC6835"/>
</reference>
<reference anchor="RFC6935" target="https://www.rfc-editor.org/info/rfc6
935" quoteTitle="true" derivedAnchor="RFC6935">
<front>
<title>IPv6 and UDP Checksums for Tunneled Packets</title>
<author fullname="M. Eubanks" initials="M." surname="Eubanks"/>
<author fullname="P. Chimento" initials="P." surname="Chimento"/>
<author fullname="M. Westerlund" initials="M." surname="Westerlund"/
>
<date month="April" year="2013"/>
<abstract>
<t indent="0">This document updates the IPv6 specification (RFC 24
60) to improve performance when a tunnel protocol uses UDP with IPv6 to tunnel p
ackets. The performance improvement is obtained by relaxing the IPv6 UDP checks
um requirement for tunnel protocols whose header information is protected on the
"inner" packet being carried. Relaxing this requirement removes the overhead a
ssociated with the computation of UDP checksums on IPv6 packets that carry the t
unnel protocol packets. This specification describes how the IPv6 UDP checksum
requirement can be relaxed when the encapsulated packet itself contains a checks
um. It also describes the limitations and risks of this approach and discusses
the restrictions on the use of this method.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6935"/>
<seriesInfo name="DOI" value="10.17487/RFC6935"/>
</reference>
<reference anchor="RFC6936" target="https://www.rfc-editor.org/info/rfc6
936" quoteTitle="true" derivedAnchor="RFC6936">
<front>
<title>Applicability Statement for the Use of IPv6 UDP Datagrams wit
h Zero Checksums</title>
<author fullname="G. Fairhurst" initials="G." surname="Fairhurst"/>
<author fullname="M. Westerlund" initials="M." surname="Westerlund"/
>
<date month="April" year="2013"/>
<abstract>
<t indent="0">This document provides an applicability statement fo
r the use of UDP transport checksums with IPv6. It defines recommendations and
requirements for the use of IPv6 UDP datagrams with a zero UDP checksum. It des
cribes the issues and design principles that need to be considered when UDP is u
sed with IPv6 to support tunnel encapsulations, and it examines the role of the
IPv6 UDP transport checksum. The document also identifies issues and constraint
s for deployment on network paths that include middleboxes. An appendix present
s a summary of the trade-offs that were considered in evaluating the safety of t
he update to RFC 2460 that changes the use of the UDP checksum with IPv6.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6936"/>
<seriesInfo name="DOI" value="10.17487/RFC6936"/>
</reference>
<reference anchor="RFC7052" target="https://www.rfc-editor.org/info/rfc7
052" quoteTitle="true" derivedAnchor="RFC7052">
<front>
<title>Locator/ID Separation Protocol (LISP) MIB</title>
<author fullname="G. Schudel" initials="G." surname="Schudel"/>
<author fullname="A. Jain" initials="A." surname="Jain"/>
<author fullname="V. Moreno" initials="V." surname="Moreno"/>
<date month="October" year="2013"/>
<abstract>
<t indent="0">This document defines the MIB module that contains m
anaged objects to support the monitoring devices of the Locator/ID Separation Pr
otocol (LISP). These objects provide information useful for monitoring LISP dev
ices, including determining basic LISP configuration information, LISP functiona
l status, and operational counters and other statistics.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7052"/>
<seriesInfo name="DOI" value="10.17487/RFC7052"/>
</reference>
<reference anchor="RFC7215" target="https://www.rfc-editor.org/info/rfc7
215" quoteTitle="true" derivedAnchor="RFC7215">
<front>
<title>Locator/Identifier Separation Protocol (LISP) Network Element
Deployment Considerations</title>
<author fullname="L. Jakab" initials="L." surname="Jakab"/>
<author fullname="A. Cabellos-Aparicio" initials="A." surname="Cabel
los-Aparicio"/>
<author fullname="F. Coras" initials="F." surname="Coras"/>
<author fullname="J. Domingo-Pascual" initials="J." surname="Domingo
-Pascual"/>
<author fullname="D. Lewis" initials="D." surname="Lewis"/>
<date month="April" year="2014"/>
<abstract>
<t indent="0">This document is a snapshot of different Locator/Ide
ntifier Separation Protocol (LISP) deployment scenarios. It discusses the place
ment of new network elements introduced by the protocol, representing the thinki
ng of the LISP working group as of Summer 2013. LISP deployment scenarios may h
ave evolved since then. This memo represents one stable point in that evolution
of understanding.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7215"/>
<seriesInfo name="DOI" value="10.17487/RFC7215"/>
</reference>
<reference anchor="RFC8060" target="https://www.rfc-editor.org/info/rfc8
060" quoteTitle="true" derivedAnchor="RFC8060">
<front>
<title>LISP Canonical Address Format (LCAF)</title>
<author fullname="D. Farinacci" initials="D." surname="Farinacci"/>
<author fullname="D. Meyer" initials="D." surname="Meyer"/>
<author fullname="J. Snijders" initials="J." surname="Snijders"/>
<date month="February" year="2017"/>
<abstract>
<t indent="0">This document defines a canonical address format enc
oding used in Locator/ID Separation Protocol (LISP) control messages and in the
encoding of lookup keys for the LISP Mapping Database System.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8060"/>
<seriesInfo name="DOI" value="10.17487/RFC8060"/>
</reference>
<reference anchor="RFC8061" target="https://www.rfc-editor.org/info/rfc8
061" quoteTitle="true" derivedAnchor="RFC8061">
<front>
<title>Locator/ID Separation Protocol (LISP) Data-Plane Confidential
ity</title>
<author fullname="D. Farinacci" initials="D." surname="Farinacci"/>
<author fullname="B. Weis" initials="B." surname="Weis"/>
<date month="February" year="2017"/>
<abstract>
<t indent="0">This document describes a mechanism for encrypting t
raffic encapsulated using the Locator/ID Separation Protocol (LISP). The design
describes how key exchange is achieved using existing LISP control-plane mechan
isms as well as how to secure the LISP data plane from third-party surveillance
attacks.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8061"/>
<seriesInfo name="DOI" value="10.17487/RFC8061"/>
</reference>
<reference anchor="RFC8085" target="https://www.rfc-editor.org/info/rfc8
085" quoteTitle="true" derivedAnchor="RFC8085">
<front>
<title>UDP Usage Guidelines</title>
<author fullname="L. Eggert" initials="L." surname="Eggert"/>
<author fullname="G. Fairhurst" initials="G." surname="Fairhurst"/>
<author fullname="G. Shepherd" initials="G." surname="Shepherd"/>
<date month="March" year="2017"/>
<abstract>
<t indent="0">The User Datagram Protocol (UDP) provides a minimal
message-passing transport that has no inherent congestion control mechanisms. Th
is document provides guidelines on the use of UDP for the designers of applicati
ons, tunnels, and other protocols that use UDP. Congestion control guidelines ar
e a primary focus, but the document also provides guidance on other topics, incl
uding message sizes, reliability, checksums, middlebox traversal, the use of Exp
licit Congestion Notification (ECN), Differentiated Services Code Points (DSCPs)
, and ports.</t>
<t indent="0">Because congestion control is critical to the stable
operation of the Internet, applications and other protocols that choose to use
UDP as an Internet transport must employ mechanisms to prevent congestion collap
se and to establish some degree of fairness with concurrent traffic. They may al
so need to implement additional mechanisms, depending on how they use UDP.</t>
<t indent="0">Some guidance is also applicable to the design of ot
her protocols (e.g., protocols layered directly on IP or via IP-based tunnels),
especially when these protocols do not themselves provide congestion control.</t
>
<t indent="0">This document obsoletes RFC 5405 and adds guidelines
for multicast UDP usage.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="145"/>
<seriesInfo name="RFC" value="8085"/>
<seriesInfo name="DOI" value="10.17487/RFC8085"/>
</reference>
<reference anchor="RFC8201" target="https://www.rfc-editor.org/info/rfc8
201" quoteTitle="true" derivedAnchor="RFC8201">
<front>
<title>Path MTU Discovery for IP version 6</title>
<author fullname="J. McCann" initials="J." surname="McCann"/>
<author fullname="S. Deering" initials="S." surname="Deering"/>
<author fullname="J. Mogul" initials="J." surname="Mogul"/>
<author fullname="R. Hinden" initials="R." role="editor" surname="Hi
nden"/>
<date month="July" year="2017"/>
<abstract>
<t indent="0">This document describes Path MTU Discovery (PMTUD) f
or IP version 6. It is largely derived from RFC 1191, which describes Path MTU
Discovery for IP version 4. It obsoletes RFC 1981.</t>
</abstract>
</front>
<seriesInfo name="STD" value="87"/>
<seriesInfo name="RFC" value="8201"/>
<seriesInfo name="DOI" value="10.17487/RFC8201"/>
</reference>
<reference anchor="RFC8899" target="https://www.rfc-editor.org/info/rfc8
899" quoteTitle="true" derivedAnchor="RFC8899">
<front>
<title>Packetization Layer Path MTU Discovery for Datagram Transport
s</title>
<author fullname="G. Fairhurst" initials="G." surname="Fairhurst"/>
<author fullname="T. Jones" initials="T." surname="Jones"/>
<author fullname="M. Tüxen" initials="M." surname="Tüxen"/>
<author fullname="I. Rüngeler" initials="I." surname="Rüngeler"/>
<author fullname="T. Völker" initials="T." surname="Völker"/>
<date month="September" year="2020"/>
<abstract>
<t indent="0">This document specifies Datagram Packetization Layer
Path MTU Discovery (DPLPMTUD). This is a robust method for Path MTU Discovery (
PMTUD) for datagram Packetization Layers (PLs). It allows a PL, or a datagram ap
plication that uses a PL, to discover whether a network path can support the cur
rent size of datagram. This can be used to detect and reduce the message size wh
en a sender encounters a packet black hole. It can also probe a network path to
discover whether the maximum packet size can be increased. This provides functio
nality for datagram transports that is equivalent to the PLPMTUD specification f
or TCP, specified in RFC 4821, which it updates. It also updates the UDP Usage G
uidelines to refer to this method for use with UDP datagrams and updates SCTP.</
t>
<t indent="0">The document provides implementation notes for incor
porating Datagram PMTUD into IETF datagram transports or applications that use d
atagram transports.</t>
<t indent="0">This specification updates RFC 4960, RFC 4821, RFC 6
951, RFC 8085, and RFC 8261.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8899"/>
<seriesInfo name="DOI" value="10.17487/RFC8899"/>
</reference>
<reference anchor="RFC9299" target="https://www.rfc-editor.org/info/rfc9
299" quoteTitle="true" derivedAnchor="RFC9299">
<front>
<title>An Architectural Introduction to the Locator/ID Separation Pr
otocol (LISP)</title>
<author initials="A" surname="Cabellos" fullname="Albert Cabellos">
<organization showOnFrontPage="true"/>
</author>
<author initials="D" surname="Saucez" fullname="Damien Saucez" role=
"editor">
<organization showOnFrontPage="true"/>
</author>
<date month="October" year="2022"/>
</front>
<seriesInfo name="RFC" value="9299"/>
<seriesInfo name="DOI" value="10.17487/RFC9299"/>
</reference>
</references>
</references>
<section numbered="false" toc="include" removeInRFC="false" pn="section-appe
ndix.a">
<name slugifiedName="name-acknowledgments">Acknowledgments</name>
<t indent="0" pn="section-appendix.a-1">An initial thank you goes to <cont
act fullname="Dave Oran"/> for planting the seeds for
the initial ideas for LISP. His consultation continues to provide the initial ideas for LISP. His consultation continues to provide
value to the LISP authors.</t> value to the LISP authors.</t>
<t indent="0" pn="section-appendix.a-2">A special and appreciative thank y
<t>A special and appreciative thank you goes to Noel Chiappa for ou goes to <contact fullname="Noel Chiappa"/> for
providing architectural impetus over the past decades on separation providing architectural impetus over the past decades on separation
of location and identity, as well as detailed reviews of the LISP of location and identity, as well as detailed reviews of the LISP
architecture and documents, coupled with enthusiasm for making LISP architecture and documents, coupled with enthusiasm for making LISP
a practical and incremental transition for the Internet.</t> a practical and incremental transition for the Internet.</t>
<t indent="0" pn="section-appendix.a-3">The original authors would like to
<t>The original authors would like to gratefully acknowledge many people who gratefully acknowledge many people who
have contributed discussions and ideas to the making of this have contributed discussions and ideas to the making of this
proposal. They include Scott Brim, Andrew Partan, John Zwiebel, proposal. They include <contact fullname="Scott Brim"/>, <contact fullname="A
Jason Schiller, Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay ndrew Partan"/>, <contact fullname="John Zwiebel"/>,
Gill, Geoff Huston, David Conrad, Mark Handley, Ron Bonica, Ted <contact fullname="Jason Schiller"/>, <contact fullname="Lixia Zhang"/>, <cont
Seely, Mark Townsley, Chris Morrow, Brian Weis, Dave McGrew, Peter act fullname="Dorian Kim"/>, <contact fullname="Peter Schoenmaker"/>, <contact f
Lothberg, Dave Thaler, Eliot Lear, Shane Amante, Ved Kafle, Olivier ullname="Vijay Gill"/>, <contact fullname="Geoff Huston"/>, <contact fullname=
Bonaventure, Luigi Iannone, Robin Whittle, Brian Carpenter, Joel "David Conrad"/>, <contact fullname="Mark Handley"/>, <contact fullname="Ron Bon
Halpern, Terry Manderson, Roger Jorgensen, Ran Atkinson, Stig ica"/>, <contact fullname="Ted Seely"/>, <contact fullname="Mark Townsley"/>,
Venaas, Iljitsch van Beijnum, Roland Bless, Dana Blair, Bill Lynch, <contact fullname="Chris Morrow"/>, <contact fullname="Brian Weis"/>, <contact f
Marc Woolward, Damien Saucez, Damian Lezama, Attilla De Groot, ullname="Dave McGrew"/>, <contact fullname="Peter Lothberg"/>, <contact fullna
Parantap Lahiri, David Black, Roque Gagliano, Isidor Kouvelas, me="Dave Thaler"/>, <contact fullname="Eliot Lear"/>, <contact fullname="Shane A
Jesper Skriver, Fred Templin, Margaret Wasserman, Sam Hartman, mante"/>, <contact fullname="Ved Kafle"/>, <contact fullname="Olivier Bonavent
Michael Hofling, Pedro Marques, Jari Arkko, Gregg Schudel, Srinivas ure"/>, <contact fullname="Luigi Iannone"/>, <contact fullname="Robin Whittle"/>
Subramanian, Amit Jain, Xu Xiaohu, Dhirendra Trivedi, Yakov Rekhter, , <contact fullname="Brian Carpenter"/>, <contact fullname="Joel Halpern"/>, <
John Scudder, John Drake, Dimitri Papadimitriou, Ross Callon, Selina contact fullname="Terry Manderson"/>, <contact fullname="Roger Jorgensen"/>, <co
Heimlich, Job Snijders, Vina Ermagan, Fabio Maino, Victor Moreno, ntact fullname="Ran Atkinson"/>, <contact fullname="Stig Venaas"/>, <contact f
Chris White, Clarence Filsfils, Alia Atlas, Florin Coras and Alberto ullname="Iljitsch van Beijnum"/>, <contact fullname="Roland Bless"/>, <contact f
Rodriguez.</t> ullname="Dana Blair"/>, <contact fullname="Bill Lynch"/>,
<contact fullname="Marc Woolward"/>, <contact fullname="Damien Saucez"/>, <con
<t>This work originated in the Routing Research Group (RRG) of the tact fullname="Damian Lezama"/>, <contact fullname="Attilla De Groot"/>,
<contact fullname="Parantap Lahiri"/>, <contact fullname="David Black"/>, <con
tact fullname="Roque Gagliano"/>, <contact fullname="Isidor Kouvelas"/>,
<contact fullname="Jesper Skriver"/>, <contact fullname="Fred Templin"/>, <con
tact fullname="Margaret Wasserman"/>, <contact fullname="Sam Hartman"/>,
<contact fullname="Michael Hofling"/>, <contact fullname="Pedro Marques"/>, <c
ontact fullname="Jari Arkko"/>, <contact fullname="Gregg Schudel"/>, <contact fu
llname="Srinivas Subramanian"/>, <contact fullname="Amit Jain"/>, <contact ful
lname="Xu Xiaohu"/>, <contact fullname="Dhirendra Trivedi"/>, <contact fullname=
"Yakov Rekhter"/>,
<contact fullname="John Scudder"/>, <contact fullname="John Drake"/>, <contact
fullname="Dimitri Papadimitriou"/>, <contact fullname="Ross Callon"/>, <contact
fullname="Selina Heimlich"/>, <contact fullname="Job Snijders"/>, <contact fu
llname="Vina Ermagan"/>, <contact fullname="Fabio Maino"/>, <contact fullname="V
ictor Moreno"/>,
<contact fullname="Chris White"/>, <contact fullname="Clarence Filsfils"/>, <c
ontact fullname="Alia Atlas"/>, <contact fullname="Florin Coras"/>, and <contact
fullname="Alberto Rodriguez"/>.</t>
<t indent="0" pn="section-appendix.a-4">This work originated in the Routin
g Research Group (RRG) of the
IRTF. An individual submission was converted into the IETF LISP IRTF. An individual submission was converted into the IETF LISP
working group document that became this RFC.</t> Working Group document that became this RFC.</t>
<t indent="0" pn="section-appendix.a-5">The LISP Working Group would like
<t>The LISP working group would like to give a special thanks to to give a special thanks to
Jari Arkko, the Internet Area AD at the time that the set of LISP <contact fullname="Jari Arkko"/>, the Internet Area AD at the time that the se
documents were being prepared for IESG last call, and for his t of LISP
meticulous reviews and detailed commentaries on the 7 working group documents was being prepared for IESG Last Call, for his
last call documents progressing toward standards-track RFCs.</t> meticulous reviews and detailed commentaries on the 7 Working Group
Last Call documents progressing toward Standards Track RFCs.</t>
<t>The current authors would like to give a sincere thank you to the <t indent="0" pn="section-appendix.a-6">The current authors would like to
people who help put LISP on standards track in the IETF. They give a sincere thank you to the
include Joel Halpern, Luigi Iannone, Deborah Brungard, Fabio Maino, people who helped put LISP on the Standards Track in the IETF. They
Scott Bradner, Kyle Rose, Takeshi Takahashi, Sarah Banks, Pete Resnick, include <contact fullname="Joel Halpern"/>, <contact fullname="Luigi Iannone"/
Colin Perkins, Mirja Kuhlewind, Francis Dupont, Benjamin Kaduk, Eric >, <contact fullname="Deborah Brungard"/>, <contact fullname="Fabio Maino"/>,
Rescorla, Alvaro Retana, Alexey Melnikov, Alissa Cooper, Suresh <contact fullname="Scott Bradner"/>, <contact fullname="Kyle Rose"/>, <contact
Krishnan, Alberto Rodriguez-Natal, Vina Ermagen, Mohamed Boucadair, fullname="Takeshi Takahashi"/>, <contact fullname="Sarah Banks"/>, <contact ful
Brian Trammell, Sabrina Tanamal, and John Drake. The contributions lname="Pete Resnick"/>,
<contact fullname="Colin Perkins"/>, <contact fullname="Mirja Kühlewind"/>, <c
ontact fullname="Francis Dupont"/>, <contact fullname="Benjamin Kaduk"/>, <conta
ct fullname="Eric Rescorla"/>, <contact fullname="Alvaro Retana"/>, <contact f
ullname="Alexey Melnikov"/>, <contact fullname="Alissa Cooper"/>, <contact fulln
ame="Suresh Krishnan"/>, <contact fullname="Alberto Rodriguez-Natal"/>, <conta
ct fullname="Vina Ermagan"/>, <contact fullname="Mohamed Boucadair"/>,
<contact fullname="Brian Trammell"/>, <contact fullname="Sabrina Tanamal"/>, a
nd <contact fullname="John Drake"/>. The contributions
they offered greatly added to the security, scale, and robustness of they offered greatly added to the security, scale, and robustness of
the LISP architecture and protocols.</t> the LISP architecture and protocols.</t>
</section> </section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
<section title="Document Change Log"> ="include" pn="section-appendix.b">
<t>[RFC Editor: Please delete this section on publication as RFC.]</t> <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
<author initials="D" surname="Farinacci" fullname="Dino Farinacci">
<section title="Changes to draft-ietf-lisp-rfc6830bis-27"> <organization showOnFrontPage="true">lispers.net</organization>
<t><list style="symbols"> <address>
<t>Posted November 2019.</t> <postal>
<t>Fixed how LSB behave in the presence of new/removed locators.</t> <city>San Jose</city>
<t>Added ETR synchronization requirements when using Map-Versioning.</t> <region>CA</region>
<t>Fixed a large set of minor comments and edits.</t> <country>United States of America</country>
</list></t> </postal>
</section> <email>farinacci@gmail.com</email>
</address>
<section title="Changes to draft-ietf-lisp-rfc6830bis-27"> </author>
<t><list style="symbols"> <author initials="V" surname="Fuller" fullname="Vince Fuller">
<t>Posted April 2019 post telechat.</t> <organization showOnFrontPage="true">vaf.net Internet Consulting</organi
<t>Made editorial corrections per Warren's suggestions.</t> zation>
<t>Put in suggested text from Luigi that Mirja agreed with.</t> <address>
<t>LSB, Echo-Nonce and Map-Versioning SHOULD be only used in closed env <email>vince.fuller@gmail.com</email>
ironments.</t> </address>
<t>Removed paragraph stating that Instance-ID can be 32-bit in the cont </author>
rol-plane.</t> <author initials="D" surname="Meyer" fullname="Dave Meyer">
<t>6831/8378 are now normative.</t> <organization showOnFrontPage="true">1-4-5.net</organization>
<t>Rewritten Security Considerations according to the changes.</t> <address>
<t>Stated that LSB SHOULD be coupled with Map-Versioning.</t> <email>dmm@1-4-5.net</email>
</list></t> </address>
</section> </author>
<author initials="D" surname="Lewis" fullname="Darrel Lewis">
<section title="Changes to draft-ietf-lisp-rfc6830bis-26"> <organization showOnFrontPage="true">Cisco Systems</organization>
<t><list style="symbols"> <address>
<t>Posted late October 2018.</t> <postal>
<t>Changed description about "reserved" bits to state "reserved <city>San Jose</city>
and unassigned".</t> <region>CA</region>
</list></t> <country>United States of America</country>
</section> </postal>
<email>darlewis@cisco.com</email>
<section title="Changes to draft-ietf-lisp-rfc6830bis-25"> </address>
<t><list style="symbols"> </author>
<t>Posted mid October 2018.</t> <author initials="A" surname="Cabellos" fullname="Albert Cabellos" role="e
<t>Added more to the Security Considerations section with discussion ditor">
about echo-nonce attacks.</t> <organization showOnFrontPage="true">Universitat Politecnica de Cataluny
</list></t> a</organization>
</section> <address>
<postal>
<section title="Changes to draft-ietf-lisp-rfc6830bis-24"> <street>c/ Jordi Girona s/n</street>
<t><list style="symbols"> <city>Barcelona</city>
<t>Posted mid October 2018.</t> <code>08034</code>
<t>Final editorial changes for Eric and Ben.</t> <country>Spain</country>
</list></t> </postal>
</section> <email>acabello@ac.upc.edu</email>
</address>
<section title="Changes to draft-ietf-lisp-rfc6830bis-23"> </author>
<t><list style="symbols"> </section>
<t>Posted early October 2018.</t> </back>
<t>Added an applicability statement in section 1 to address security
concerns from Telechat.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6830bis-22">
<t><list style="symbols">
<t>Posted early October 2018.</t>
<t>Changes to reflect comments post Telechat.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6830bis-21">
<t><list style="symbols">
<t>Posted late-September 2018.</t>
<t>Changes to reflect comments from Sep 27th Telechat.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6830bis-20">
<t><list style="symbols">
<t>Posted late-September 2018.</t>
<t>Fix old reference to RFC3168, changed to RFC6040.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6830bis-19">
<t><list style="symbols">
<t>Posted late-September 2018.</t>
<t>More editorial changes.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6830bis-18">
<t><list style="symbols">
<t>Posted mid-September 2018.</t>
<t>Changes to reflect comments from Secdir review (Mirja).</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6830bis-17">
<t><list style="symbols">
<t>Posted September 2018.</t>
<t>Indicate in the "Changes since RFC 6830" section why the document
has been shortened in length.</t>
<t>Make reference to RFC 8085 about UDP congestion control.</t>
<t>More editorial changes from multiple IESG reviews.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6830bis-16">
<t><list style="symbols">
<t>Posted late August 2018.</t>
<t>Distinguish the message type names between ICMP for IPv4 and
ICMP for IPv6 for handling MTU issues.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6830bis-15">
<t><list style="symbols">
<t>Posted August 2018.</t>
<t>Final editorial changes before RFC submission for Proposed
Standard.</t>
<t>Added section "Changes since RFC 6830" so implementers are informed
of any changes since the last RFC publication.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6830bis-14">
<t><list style="symbols">
<t>Posted July 2018 IETF week.</t>
<t>Put obsolete of RFC 6830 in Intro section in addition to abstract.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6830bis-13">
<t><list style="symbols">
<t>Posted March IETF Week 2018.</t>
<t>Clarified that a new nonce is required per RLOC.</t>
<t>Removed 'Clock Sweep' section. This text must be placed in a
new OAM document.</t>
<t>Some references changed from normative to informative</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6830bis-12">
<t><list style="symbols">
<t>Posted July 2018.</t>
<t>Fixed Luigi editorial comments to ready draft for RFC status.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6830bis-11">
<t><list style="symbols">
<t>Posted March 2018.</t>
<t>Removed sections 16, 17 and 18 (Mobility, Deployment and
Traceroute considerations). This text must be placed in a new
OAM document.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6830bis-10">
<t><list style="symbols">
<t>Posted March 2018.</t>
<t>Updated section 'Router Locator Selection' stating that the
Data-Plane MUST follow what's stored in the Map-Cache
(priorities and weights).</t>
<t>Section 'Routing Locator Reachability': Removed bullet point
2 (ICMP Network/Host Unreachable),3 (hints from BGP),4 (ICMP
Port Unreachable),5 (receive a Map-Reply as a response) and RLOC
probing </t>
<t>Removed 'Solicit-Map Request'.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6830bis-09">
<t><list style="symbols">
<t>Posted January 2018.</t>
<t>Add more details in section 5.3 about DSCP processing during
encapsulation and decapsulation.</t>
<t>Added clarity to definitions in the Definition of Terms section
from various commenters.</t>
<t>Removed PA and PI definitions from Definition of Terms section.</t>
<t>More editorial changes.</t>
<t>Removed 4342 from IANA section and move to RFC6833 IANA section.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6830bis-08">
<t><list style="symbols">
<t>Posted January 2018.</t>
<t>Remove references to research work for any protocol mechanisms.</t>
<t>Document scanned to make sure it is RFC 2119 compliant.</t>
<t>Made changes to reflect comments from document WG shepherd Luigi
Iannone.</t>
<t>Ran IDNITs on the document.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6830bis-07">
<t><list style="symbols">
<t>Posted November 2017.</t>
<t>Rephrase how Instance-IDs are used and don't refer to <xref
target="RFC1918"/> addresses.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6830bis-06">
<t><list style="symbols">
<t>Posted October 2017.</t>
<t>Put RTR definition before it is used.</t>
<t>Rename references that are now working group drafts.</t>
<t>Remove "EIDs MUST NOT be used as used by a host to refer to
other hosts. Note that EID blocks MAY LISP RLOCs".</t>
<t>Indicate what address-family can appear in data packets.</t>
<t>ETRs may, rather than will, be the ones to send Map-Replies.</t>
<t>Recommend, rather than mandate, max encapsulation headers to 2.</t>
<t>Reference VPN draft when introducing Instance-ID.</t>
<t>Indicate that SMRs can be sent when ITR/ETR are in the same node.</t>
<t>Clarify when private addresses can be used.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6830bis-05">
<t><list style="symbols">
<t>Posted August 2017.</t>
<t>Make it clear that a Re-encapsulating Tunnel Router is an RTR.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6830bis-04">
<t><list style="symbols">
<t>Posted July 2017.</t>
<t>Changed reference of IPv6 RFC2460 to RFC8200.</t>
<t>Indicate that the applicability statement for UDP zero checksums
over IPv6 adheres to RFC6936.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6830bis-03">
<t><list style="symbols">
<t>Posted May 2017.</t>
<t>Move the control-plane related codepoints in the IANA Considerations
section to RFC6833bis.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6830bis-02">
<t><list style="symbols">
<t>Posted April 2017.</t>
<t>Reflect some editorial comments from Damien Sausez.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6830bis-01">
<t><list style="symbols">
<t>Posted March 2017.</t>
<t>Include references to new RFCs published.</t>
<t>Change references from RFC6833 to RFC6833bis.</t>
<t>Clarified LCAF text in the IANA section.</t>
<t>Remove references to "experimental".</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6830bis-00">
<t><list style="symbols">
<t>Posted December 2016.</t>
<t>Created working group document from draft-farinacci-lisp
-rfc6830-00 individual submission. No other changes made.</t>
</list></t>
</section>
</section>
</back>
</rfc> </rfc>
 End of changes. 259 change blocks. 
1530 lines changed or deleted 2684 lines changed or added

This html diff was produced by rfcdiff 1.48.