rfc9301xml2.original.xml   rfc9301.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-rfc6833bis-31" indexInclude="true" ipr="tru
st200902" number="9301" obsoletes="6830, 6833" prepTime="2022-10-18T16:01:20" sc
<rfc category="std" ipr="trust200902" docName="draft-ietf-lisp-rfc6833bis-30" ripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDep
obsoletes="6830, 6833"> th="3" tocInclude="true" xml:lang="en">
<link href="https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis-31" re
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> l="prev"/>
<link href="https://dx.doi.org/10.17487/rfc9301" rel="alternate"/>
<?rfc toc="yes" ?> <link href="urn:issn:2070-1721" rel="alternate"/>
<?rfc symrefs="yes" ?> <front>
<?rfc sortrefs="yes"?> <title abbrev="LISP Control Plane">Locator/ID Separation Protocol (LISP) Con
<?rfc iprnotified="no" ?> trol Plane</title>
<?rfc compact="yes" ?> <seriesInfo name="RFC" value="9301" stream="IETF"/>
<?rfc subcompact="no"?> <author initials="D" surname="Farinacci" fullname="Dino Farinacci">
<?rfc rfcedstyle="yes"?> <organization showOnFrontPage="true">lispers.net</organization>
<address>
<front> <postal>
<title abbrev="LISP Control-Plane">Locator/ID Separation Protocol (LISP) Contr <city>San Jose</city>
ol-Plane</title> <region>CA</region>
<country>United States of America</country>
<author initials='D' surname="Farinacci" fullname='Dino Farinacci'> </postal>
<organization>lispers.net</organization> <email>farinacci@gmail.com</email>
<address> </address>
<email>farinacci@gmail.com</email> </author>
</address> <author initials="F" surname="Maino" fullname="Fabio Maino">
</author> <organization showOnFrontPage="true">Cisco Systems</organization>
<author initials='F' surname="Maino" fullname='Fabio Maino'> <address>
<organization>Cisco Systems</organization> <postal>
<address> <city>San Jose</city>
<email>fmaino@cisco.com</email> <region>CA</region>
</address> <country>United States of America</country>
</author> </postal>
<author initials='V' surname="Fuller" fullname='Vince Fuller'> <email>fmaino@cisco.com</email>
<organization>vaf.net Internet Consulting</organization> </address>
<address> </author>
<email>vaf@vaf.net</email> <author initials="V" surname="Fuller" fullname="Vince Fuller">
</address> <organization showOnFrontPage="true">vaf.net Internet Consulting</organiza
</author> tion>
<author initials='A' surname="Cabellos (Ed.)" fullname='Albert Cabellos'> <address>
<organization>UPC/BarcelonaTech</organization> <email>vince.fuller@gmail.com</email>
<address><postal> </address>
<street>Campus Nord, C. Jordi Girona 1-3</street> </author>
<city>Barcelona</city> <region>Catalunya</region> <author initials="A" surname="Cabellos" fullname="Albert Cabellos" role="edi
<country>Spain</country> tor">
</postal> <organization showOnFrontPage="true">Universitat Politecnica de Catalunya<
<email>acabello@ac.upc.edu</email></address> /organization>
</author> <address>
<postal>
<date /> <street>c/ Jordi Girona s/n</street>
<city>Barcelona</city>
<abstract> <country>Spain</country>
<t> This document describes the Control-Plane and Mapping Service <code>08034</code>
</postal>
<email>acabello@ac.upc.edu</email>
</address>
</author>
<date month="10" year="2022"/>
<abstract pn="section-abstract">
<t indent="0" pn="section-abstract-1"> This document describes the control
plane and Mapping Service
for the Locator/ID Separation Protocol (LISP), implemented by two for the Locator/ID Separation Protocol (LISP), implemented by two
types of LISP-speaking devices -- the LISP Map-Resolver and types of LISP-speaking devices -- the LISP Map-Resolver and
LISP Map-Server -- that provides a simplified "front end" for one LISP Map-Server -- that provide a simplified "front end" for one
or more Endpoint ID to Routing Locator mapping databases.</t> or more Endpoint IDs (EIDs) to Routing Locator mapping databases.</t>
<t indent="0" pn="section-abstract-2">By using this control plane service
<t>By using this Control-Plane service interface and communicating interface and communicating
with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers
(ITRs) and Egress Tunnel Routers (ETRs) are not dependent on the (ITRs) and Egress Tunnel Routers (ETRs) are not dependent on the
details of mapping database systems, which facilitates modularity details of mapping database systems; this behavior facilitates modularity
with different database designs. Since these devices implement the with different database designs. Since these devices implement the "edge" o
"edge" of the LISP Control-Plane infrastructure, connecting EID f the
addressable nodes of a LISP site, it the implementation and LISP control plane infrastructure, connecting EID addressable nodes
operational complexity of the overall cost and effort of of a LISP site, the implementation and operational complexity of the
deploying LISP.</t> overall cost and effort of deploying LISP is reduced.</t>
<t indent="0" pn="section-abstract-3">This document obsoletes RFCs 6830 an
<t>This document obsoletes RFC 6830 and RFC 6833.</t> d 6833.</t>
</abstract>
</abstract> <boilerplate>
</front> <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
"exclude" pn="section-boilerplate.1">
<middle> <name slugifiedName="name-status-of-this-memo">Status of This Memo</name
<section title="Introduction"> >
<t>The Locator/ID Separation Protocol <xref <t indent="0" pn="section-boilerplate.1-1">
target="I-D.ietf-lisp-rfc6830bis"/> (see also <xref This is an Internet Standards Track document.
target="I-D.ietf-lisp-introduction"/>) specifies an architecture </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/rfc9301" 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>
</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-ipv4-and-ipv6-control-">LISP
IPv4 and IPv6 Control Plane Packet Formats</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-control-packet-ty
pe-al">LISP Control Packet Type Allocations</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-map-request-message-fo
rmat">Map-Request Message 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-eid-to-rloc-udp-map-re
quest">EID-to-RLOC UDP Map-Request Message</xref></t>
</li>
<li pn="section-toc.1-1.5.2.4">
<t indent="0" pn="section-toc.1-1.5.2.4.1"><xref derivedContent=
"5.4" format="counter" sectionFormat="of" target="section-5.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-map-reply-message-form
at">Map-Reply Message Format</xref></t>
</li>
<li pn="section-toc.1-1.5.2.5">
<t indent="0" pn="section-toc.1-1.5.2.5.1"><xref derivedContent=
"5.5" format="counter" sectionFormat="of" target="section-5.5"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-eid-to-rloc-udp-map-re
ply-m">EID-to-RLOC UDP Map-Reply Message</xref></t>
</li>
<li pn="section-toc.1-1.5.2.6">
<t indent="0" pn="section-toc.1-1.5.2.6.1"><xref derivedContent=
"5.6" format="counter" sectionFormat="of" target="section-5.6"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-map-register-message-f
ormat">Map-Register Message Format</xref></t>
</li>
<li pn="section-toc.1-1.5.2.7">
<t indent="0" pn="section-toc.1-1.5.2.7.1"><xref derivedContent=
"5.7" format="counter" sectionFormat="of" target="section-5.7"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-map-notify-and-map-not
ify-a">Map-Notify and Map-Notify-Ack Message Formats</xref></t>
</li>
<li pn="section-toc.1-1.5.2.8">
<t indent="0" pn="section-toc.1-1.5.2.8.1"><xref derivedContent=
"5.8" format="counter" sectionFormat="of" target="section-5.8"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-encapsulated-control-m
essag">Encapsulated Control Message Format</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-changing-the-contents-of-ei">Chang
ing the Contents of EID-to-RLOC Mappings</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.6.2">
<li pn="section-toc.1-1.6.2.1">
<t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent=
"6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-solicit-map-request-sm
r">Solicit-Map-Request (SMR)</xref></t>
</li>
</ul>
</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-routing-locator-reachabilit">Routi
ng Locator Reachability</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-rloc-probing-algorithm
">RLOC-Probing Algorithm</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-interactions-with-other-lis">Inter
actions with Other LISP Components</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.8.2">
<li pn="section-toc.1-1.8.2.1">
<t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent=
"8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-itr-eid-to-rloc-mappin
g-res">ITR EID-to-RLOC Mapping Resolution</xref></t>
</li>
<li pn="section-toc.1-1.8.2.2">
<t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent=
"8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-eid-prefix-configurati
on-an">EID-Prefix Configuration and ETR Registration</xref></t>
</li>
<li pn="section-toc.1-1.8.2.3">
<t indent="0" pn="section-toc.1-1.8.2.3.1"><xref derivedContent=
"8.3" format="counter" sectionFormat="of" target="section-8.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-map-server-processing"
>Map-Server Processing</xref></t>
</li>
<li pn="section-toc.1-1.8.2.4">
<t indent="0" pn="section-toc.1-1.8.2.4.1"><xref derivedContent=
"8.4" format="counter" sectionFormat="of" target="section-8.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-map-resolver-processin
g">Map-Resolver Processing</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.8.2.4.2">
<li pn="section-toc.1-1.8.2.4.2.1">
<t indent="0" pn="section-toc.1-1.8.2.4.2.1.1"><xref derived
Content="8.4.1" format="counter" sectionFormat="of" target="section-8.4.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-anycast-op
eration">Anycast Operation</xref></t>
</li>
</ul>
</li>
</ul>
</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-security-considerations">Security
Considerations</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-privacy-considerations">Privacy
Considerations</xref></t>
</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-changes-related-to-rfcs-683">Cha
nges Related to RFCs 6830 and 6833</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-iana-considerations">IANA Consid
erations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.12.2">
<li pn="section-toc.1-1.12.2.1">
<t indent="0" pn="section-toc.1-1.12.2.1.1"><xref derivedContent
="12.1" format="counter" sectionFormat="of" target="section-12.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-lisp-udp-port-numbe
rs">LISP UDP Port Numbers</xref></t>
</li>
<li pn="section-toc.1-1.12.2.2">
<t indent="0" pn="section-toc.1-1.12.2.2.1"><xref derivedContent
="12.2" format="counter" sectionFormat="of" target="section-12.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-lisp-packet-type-co
des">LISP Packet Type Codes</xref></t>
</li>
<li pn="section-toc.1-1.12.2.3">
<t indent="0" pn="section-toc.1-1.12.2.3.1"><xref derivedContent
="12.3" format="counter" sectionFormat="of" target="section-12.3"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-lisp-map-reply-eid-
record-a">LISP Map-Reply EID-Record Action Codes</xref></t>
</li>
<li pn="section-toc.1-1.12.2.4">
<t indent="0" pn="section-toc.1-1.12.2.4.1"><xref derivedContent
="12.4" format="counter" sectionFormat="of" target="section-12.4"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-lisp-address-type-c
odes">LISP Address Type Codes</xref></t>
</li>
<li pn="section-toc.1-1.12.2.5">
<t indent="0" pn="section-toc.1-1.12.2.5.1"><xref derivedContent
="12.5" format="counter" sectionFormat="of" target="section-12.5"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-lisp-algorithm-id-n
umbers">LISP Algorithm ID Numbers</xref></t>
</li>
<li pn="section-toc.1-1.12.2.6">
<t indent="0" pn="section-toc.1-1.12.2.6.1"><xref derivedContent
="12.6" format="counter" sectionFormat="of" target="section-12.6"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-lisp-bit-flags">LIS
P Bit Flags</xref></t>
</li>
</ul>
</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-references">References</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-normative-reference
s">Normative References</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-informative-referen
ces">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.14">
<t indent="0" pn="section-toc.1-1.14.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.15">
<t indent="0" pn="section-toc.1-1.15.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">The Locator/ID Separation Protocol <xref ta
rget="RFC9300" format="default" sectionFormat="of" derivedContent="RFC9300"/> (s
ee also <xref target="RFC9299" format="default" sectionFormat="of" derivedConten
t="RFC9299"/>) specifies an architecture
and mechanism for dynamic tunneling by logically separating the and mechanism for dynamic tunneling by logically separating the
addresses currently used by IP in two separate name spaces: addresses currently used by IP in two separate namespaces:
Endpoint IDs (EIDs), used within sites; and Routing Locators Endpoint IDs (EIDs), used within sites; and Routing Locators
(RLOCs), used on the transit networks that make up the Internet (RLOCs), used on the transit networks that make up the Internet
infrastructure. To achieve this separation, LISP defines protocol infrastructure. To achieve this separation, LISP defines protocol
mechanisms for mapping from EIDs to RLOCs. In addition, LISP mechanisms for mapping from EIDs to RLOCs. In addition, LISP
assumes the existence of a database to store and propagate those assumes the existence of a database to store and propagate those
mappings across mapping system nodes. Several such databases have mappings across Mapping System nodes. Several such databases have
been proposed; among them are the Content distribution Overlay been proposed; among them are the Content distribution Overlay
Network Service for LISP-NERD (a Not-so-novel EID-to-RLOC Network Service for LISP-NERD (a Not-so-novel EID-to-RLOC
Database) <xref target="RFC6837" />, LISP Alternative Logical Database) <xref target="RFC6837" format="default" sectionFormat="of" derived
Topology (LISP-ALT) <xref target="RFC6836" />, and LISP Delegated Content="RFC6837"/>, LISP Alternative Logical
Database Tree (LISP-DDT) <xref target="RFC8111"/>.</t> Topology (LISP-ALT) <xref target="RFC6836" format="default" sectionFormat="o
f" derivedContent="RFC6836"/>, and LISP Delegated
<t> The LISP Mapping Service defines two types of Database Tree (LISP-DDT) <xref target="RFC8111" format="default" sectionForm
at="of" derivedContent="RFC8111"/>.</t>
<t indent="0" pn="section-1-2"> The LISP Mapping Service defines two types
of
LISP-speaking devices: the Map-Resolver, which accepts LISP-speaking devices: the Map-Resolver, which accepts
Map-Requests from an Ingress Tunnel Router (ITR) and "resolves" Map-Requests from an Ingress Tunnel Router (ITR) and "resolves"
the EID-to-RLOC mapping using a mapping database; and the the EID-to-RLOC mapping using a mapping database; and the
Map-Server, which learns authoritative EID-to-RLOC mappings from Map-Server, which learns authoritative EID-to-RLOC mappings from
an Egress Tunnel Router (ETR) and publishes them in a an Egress Tunnel Router (ETR) and publishes them in a
database.</t> database.</t>
<t indent="0" pn="section-1-3"> This LISP control plane and Mapping Servic
<t> This LISP Control-Plane Mapping Service can be used by many e can be used by many
different encapsulation-based or translation-based Data-Planes different encapsulation-based or translation-based data planes, including
which include but are not limited to the ones defined in LISP RFC but not limited to those defined in LISP
6830bis <xref target="I-D.ietf-lisp-rfc6830bis"/>, LISP-GPE <xref <xref target="RFC9300" format="default" sectionFormat="of" derivedContent="R
target="I-D.ietf-lisp-gpe"/>, VXLAN <xref target="RFC7348" />, FC9300"/>, the LISP Generic Protocol Extension (LISP-GPE) <xref target="RFC9305"
VXLAN-GPE <xref target="I-D.ietf-nvo3-vxlan-gpe"/>, format="default" sectionFormat="of" derivedContent="RFC9305"/>, Virtual eXtensi
GRE <xref target="RFC2890"/>, GTP <xref target="GTP-3GPP"/>, ble Local Area Networks (VXLANs) <xref target="RFC7348" format="default" section
ILA <xref target="I-D.herbert-intarea-ila"/>, and Segment Routing (SRv6) Format="of" derivedContent="RFC7348"/>,
<xref target="RFC8402"/>.</t> VXLAN-GPE <xref target="NVO3-VXLAN-GPE" format="default" sectionFormat="of"
derivedContent="NVO3-VXLAN-GPE"/>,
<t> Conceptually, LISP Map-Servers share some of the same basic GRE <xref target="RFC2890" format="default" sectionFormat="of" derivedConten
t="RFC2890"/>, the GPRS Tunneling Protocol (GTP) <xref target="GTP-3GPP" format=
"default" sectionFormat="of" derivedContent="GTP-3GPP"/>,
Identifier-Locator Addressing (ILA) <xref target="I-D.herbert-intarea-ila" f
ormat="default" sectionFormat="of" derivedContent="INTAREA-ILA"/>, and Segment R
outing (SRv6)
<xref target="RFC8402" format="default" sectionFormat="of" derivedContent="R
FC8402"/>.</t>
<t indent="0" pn="section-1-4"> Conceptually, LISP Map-Servers share some
of the same basic
configuration and maintenance properties as Domain Name System configuration and maintenance properties as Domain Name System
(DNS) <xref target="RFC1035" /> servers; likewise, Map-Resolvers (DNS) servers <xref target="RFC1035" format="default" sectionFormat="of" der ivedContent="RFC1035"/>; likewise, Map-Resolvers
are conceptually similar to DNS caching resolvers. With this in are conceptually similar to DNS caching resolvers. With this in
mind, this specification borrows familiar terminology (resolver mind, this specification borrows familiar terminology (resolver
and server) from the DNS specifications.</t> and server) from the DNS specifications.</t>
<t indent="0" pn="section-1-5"> Note that this document doesn't assume any
<t> Note this document doesn't assume any particular database particular database
mapping infrastructure to illustrate certain aspects of Map-Server mapping infrastructure to illustrate certain aspects of Map-Server
and Map-Resolver operation. The Mapping Service interface can (and and Map-Resolver operations. The Mapping Service interface can (and
likely will) be used by ITRs and ETRs to access other mapping likely will) be used by ITRs and ETRs to access other mapping
database systems as the LISP infrastructure evolves.</t> database systems as the LISP infrastructure evolves.</t>
<t indent="0" pn="section-1-6">LISP is not intended to address problems of
<t>LISP is not intended to address problems of connectivity and connectivity and
scaling on behalf of arbitrary communicating parties. Relevant scaling on behalf of arbitrary communicating parties. Relevant
situations are described in the scoping section of the situations are described in
introduction to <xref target="I-D.ietf-lisp-rfc6830bis"/>.</t> <xref target="RFC9300" sectionFormat="of" section="1.1" format="default" derived
Link="https://rfc-editor.org/rfc/rfc9300#section-1.1" derivedContent="RFC9300"/>
<t>This document obsoletes RFC 6830 and 6833.</t> .</t>
<t indent="0" pn="section-1-7">This document obsoletes <xref target="RFC68
<section title="Scope of Applicability" anchor="soa"> 30" format="default" sectionFormat="of" derivedContent="RFC6830"/> and <xref tar
<t>LISP was originally developed to address the Internet-wide get="RFC6833" format="default" sectionFormat="of" derivedContent="RFC6833"/>.</t
route scaling problem <xref target="RFC4984"/>. While there >
<section anchor="soa" numbered="true" toc="include" removeInRFC="false" pn
="section-1.1">
<name slugifiedName="name-scope-of-applicability">Scope of Applicability
</name>
<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" sectionForma
t="of" derivedContent="RFC4984"/>. While there
are a number of approaches of interest for that problem, as LISP are a number of approaches of interest for that problem, as LISP
as been developed and refined, a large number of other LISP uses has been developed and refined, a large number of other uses for LISP have
have been found and are being used. As such, the design and been found and are being implemented. As such, the design and
development of LISP has changed so as to focus on these use development of LISP have changed so as to focus on these use
cases. The common property of these uses is a large set of cases. The common property of these uses is a large set of
cooperating entities seeking to communicate over the public cooperating entities seeking to communicate over the public
Internet or other large underlay IP infrastructures, while Internet or other large underlay IP infrastructures while
keeping the addressing and topology of the cooperating entities keeping the addressing and topology of the cooperating entities
separate from the underlay and Internet topology, routing, and separate from the underlay and Internet topology, routing, and
addressing.</t> addressing.</t>
<t indent="0" pn="section-1.1-2">When communicating over the public Inte
<t>When communicating over the public Internet, deployers MUST consider rnet, deployers <bcp14>MUST</bcp14> consider
the following guidelines:</t> the following guidelines:</t>
<ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-1.
<t><list style="numbers"> 1-3">
<t>LISP-SEC MUST be implemented <xref target="I-D.ietf-lisp-sec"/>. <li pn="section-1.1-3.1" derivedCounter="1.">LISP Security (LISP-SEC) <
This means that the S-bit MUST be set in the Map-Reply (<xref target="MR bcp14>MUST</bcp14> be implemented <xref target="RFC9303" format="default" sectio
-FORMAT"/>), Map-Register (<xref target="MAPREG"/>) and nFormat="of" derivedContent="RFC9303"/>. This means that the S-bit <bcp14>MUST</
Encapsulated Control messages (<xref target="encap-mr"/>).</t> bcp14> be set in the Map-Reply (<xref target="MR-FORMAT" format="default" sectio
<t>Implementations SHOULD use the 'HMAC-SHA256-128+HKDF-SHA256' nFormat="of" derivedContent="Section 5.4"/>), Map-Register (<xref target="MAPREG
as the Algorithm ID (<xref target="KEYS"/>) " format="default" sectionFormat="of" derivedContent="Section 5.6"/>), and Encap
in Map-Register message (<xref target="MAPREG"/>), and MUST NOT sulated Control Messages (ECMs) (<xref target="encap-mr" format="default" sectio
use 'None' or 'HMAC-SHA-1-96-None' as Algorithm ID (<xref target="KEYS nFormat="of" derivedContent="Section 5.8"/>).</li>
"/>) <li pn="section-1.1-3.2" derivedCounter="2.">Implementations <bcp14>SH
in the Map-Register message (<xref target="MAPREG"/>)</t> OULD</bcp14> use 'HMAC-SHA256-128+HKDF-SHA256'
</list></t> as the Algorithm ID (<xref target="KEYS" format="default" sectionForma
t="of" derivedContent="Section 12.5"/>)
in the Map-Register message (<xref target="MAPREG" format="default" se
ctionFormat="of" derivedContent="Section 5.6"/>) and <bcp14>MUST NOT</bcp14> use
'None' or 'HMAC-SHA-1-96-None' as the Algorithm ID (<xref target="KEYS" format=
"default" sectionFormat="of" derivedContent="Section 12.5"/>) in the Map-Registe
r message (<xref target="MAPREG" format="default" sectionFormat="of" derivedCont
ent="Section 5.6"/>).</li>
</ol>
</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 OT RECOMMENDED</bcp14>",
capitals, 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"> f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor
<t><list style="hanging"> mat="of" derivedContent="RFC8174"/>
<t hangText="Map-Server: ">A network infrastructure component when, and only when, they appear in all capitals, as shown here.
</t>
</section>
<section numbered="true" toc="include" removeInRFC="false" 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">Map-Server: </dt>
<dd pn="section-3-1.2">A network infrastructure component
that learns of EID-Prefix mapping entries from an ETR, via the that learns of EID-Prefix mapping entries from an ETR, via the
registration mechanism described below, or some other registration mechanism described below, or some other
authoritative source if one exists. A Map-Server publishes these authoritative source if one exists. A Map-Server publishes these
EID-Prefixes in a mapping database.</t> EID-Prefixes in a mapping database.</dd>
<dt pn="section-3-1.3">Map-Request: </dt>
<t hangText="Map-Request: ">A LISP Map-Request is a <dd pn="section-3-1.4">A control plane message that queries the Mapping
Control-Plane message to query the mapping system to resolve an System to resolve an
EID. A LISP Map-Request can also be sent to an RLOC to test for EID. A LISP Map-Request can also be sent to an RLOC to test for
reachability and to exchange security keys between an reachability and to exchange security keys between an
encapsulator and a decapsulator. This type of Map-Request is encapsulator and a decapsulator. This type of Map-Request is
also known as an RLOC-Probe Request.</t> also known as an RLOC-Probe Request.</dd>
<dt pn="section-3-1.5">Map-Reply: </dt>
<t hangText="Map-Reply: ">A LISP Map-Reply is a Control-Plane <dd pn="section-3-1.6">A control plane
message returned in response to a Map-Request sent to the mapping message returned in response to a Map-Request sent to the Mapping
system when resolving an EID. A LISP Map-Reply can also be returned by System when resolving an EID. A LISP Map-Reply can also be returned by
a decapsulator in response to a Map-Request sent by an encapsulator a decapsulator in response to a Map-Request sent by an encapsulator
to test for reachability. This type of Map-Reply is known as a RLOC-Probe to test for reachability. This type of Map-Reply is known as an RLOC-Probe
Reply.</t> Reply.</dd>
<dt pn="section-3-1.7">Encapsulated Map-Request: </dt>
<t hangText="Encapsulated Map-Request: ">A LISP Map-Request <dd pn="section-3-1.8">A LISP Map-Request
carried within an Encapsulated Control Message (ECM), which has an carried within an ECM. This Map-Request has an
additional LISP header prepended. Sent to UDP destination port additional LISP header prepended. Sent to UDP destination port
4342. The "outer" addresses are routable IP addresses, 4342. The "outer" addresses are routable IP addresses,
also known as RLOCs. Used by an ITR when sending to a also known as RLOCs. Used by an ITR when sending to a
Map-Resolver and by a Map-Server when forwarding a Map-Request Map-Resolver and by a Map-Server when forwarding a Map-Request
to an ETR.</t> to an ETR.</dd>
<dt pn="section-3-1.9">Map-Resolver: </dt>
<t hangText="Map-Resolver: ">A network infrastructure component <dd pn="section-3-1.10">A network infrastructure component
that accepts LISP Encapsulated (ECM) Map-Requests, typically from an that accepts LISP Encapsulated (ECM) Map-Requests, typically from an
ITR, and determines whether or not the destination IP address is ITR, and determines whether or not the destination IP address is
part of the EID namespace; if it is not, a Negative Map-Reply is part of the EID namespace; if it is not, a Negative Map-Reply is
returned. Otherwise, the Map-Resolver finds the appropriate returned. Otherwise, the Map-Resolver finds the appropriate
EID-to-RLOC mapping by consulting a mapping database system.</t> EID-to-RLOC mapping by consulting a mapping database system.</dd>
<dt pn="section-3-1.11">Negative Map-Reply: </dt>
<t hangText="Negative Map-Reply: ">A LISP Map-Reply that <dd pn="section-3-1.12">A LISP Map-Reply that
contains an empty Locator-Set. Returned in response to a contains an empty Locator-Set. Returned in response to a
Map-Request if the destination EID is not registered in the Map-Request if the destination EID is not registered in the
mapping system, is policy denied or fails authentication.</t> Mapping System, is policy-denied, or fails authentication.</dd>
<dt pn="section-3-1.13">Map-Register message: </dt>
<t hangText="Map-Register message: ">A LISP message sent by an <dd pn="section-3-1.14">A LISP message sent by an
ETR to a Map-Server to register its associated EID-Prefixes. In ETR to a Map-Server to register its associated EID-Prefixes. In
addition to the set of EID-Prefixes to register, the message addition to the set of EID-Prefixes to register, the message
includes one or more RLOCs to reach ETR(s). The Map-Server uses includes one or more RLOCs to reach ETR(s). The Map-Server uses
these RLOCs when forwarding Map-Requests (re-formatted as these RLOCs when forwarding Map-Requests (reformatted as
Encapsulated Map-Requests). An ETR MAY request that the Encapsulated Map-Requests). An ETR <bcp14>MAY</bcp14> request that the
Map-Server answer Map-Requests on its behalf by setting the Map-Server answer Map-Requests on its behalf by setting the
"proxy Map-Reply" flag (P-bit) in the message.</t> "proxy Map-Reply" flag (P-bit) in the message.</dd>
<dt pn="section-3-1.15">Map-Notify message: </dt>
<t hangText="Map-Notify message: ">A LISP message sent by a <dd pn="section-3-1.16">A LISP message sent by a
Map-Server to an ETR to confirm that a Map-Register has been Map-Server to an ETR to confirm that a Map-Register has been
received and processed. An ETR requests that a Map-Notify be received and processed. An ETR requests that a Map-Notify be
returned by setting the "want-map-notify" flag (M-bit) in the returned by setting the "want-map-notify" flag (M-bit) in the
Map-Register message. Unlike a Map-Reply, a Map-Notify uses UDP Map-Register message. Unlike a Map-Reply, a Map-Notify uses UDP
port 4342 for both source and destination. Map-Notify messages port 4342 for both source and destination. Map-Notify messages
are also sent to ITRs by Map-Servers when there are RLOC-set are also sent to ITRs by Map-Servers when there are RLOC-Set
changes.</t> changes.</dd>
</list></t> </dl>
<t indent="0" pn="section-3-2">For definitions of other terms, notably Ing
<t>For definitions of other terms, notably Ingress Tunnel ress Tunnel
Router (ITR), Egress Tunnel Router (ETR), and Re-encapsulating Router (ITR), Egress Tunnel Router (ETR), and Re-encapsulating
Tunnel Router (RTR), refer to the LISP Data-Plane specification Tunnel Router (RTR), refer to the LISP data plane specification
<xref target="I-D.ietf-lisp-rfc6830bis" />.</t> <xref target="RFC9300" format="default" sectionFormat="of" derivedContent="R
</section> FC9300"/>.</t>
</section>
<section title="Basic Overview" anchor="OVERVIEW"> <section anchor="OVERVIEW" numbered="true" toc="include" removeInRFC="false"
<t> A Map-Server is a device that publishes EID-Prefixes in a LISP pn="section-4">
<name slugifiedName="name-basic-overview">Basic Overview</name>
<t indent="0" pn="section-4-1"> A Map-Server is a device that publishes EI
D-Prefixes in a LISP
mapping database on behalf of a set of ETRs. When it receives a mapping database on behalf of a set of ETRs. When it receives a
Map Request (typically originating from an ITR), it consults the mapping Map-Request (typically originating from an ITR), it consults the mapping
database to find an ETR that can answer with the set of RLOCs for database to find an ETR that can answer with the set of RLOCs for
an EID-Prefix. To publish its EID-Prefixes, an ETR periodically an EID-Prefix. To publish its EID-Prefixes, an ETR periodically
sends Map-Register messages to the Map-Server. A Map-Register sends Map-Register messages to the Map-Server. A Map-Register
message contains a list of EID-Prefixes plus a set of RLOCs that message contains a list of EID-Prefixes plus a set of RLOCs that
can be used to reach the ETRs.</t> can be used to reach the ETRs.</t>
<t indent="0" pn="section-4-2"> When LISP-ALT <xref target="RFC6836" forma
<t> When LISP-ALT <xref target="RFC6836"/> is used as the mapping t="default" sectionFormat="of" derivedContent="RFC6836"/> is used as the mapping
database, a Map-Server connects to the ALT network and acts as a database, a Map-Server connects to the ALT network and acts as a
"last-hop" ALT-Router. Intermediate ALT-Routers forward "last-hop" ALT-Router. Intermediate ALT-Routers forward
Map-Requests to the Map-Server that advertises a particular Map-Requests to the Map-Server that advertises a particular
EID-Prefix, and the Map-Server forwards them to the owning ETR, EID-Prefix, and the Map-Server forwards them to the owning ETR,
which responds with Map-Reply messages.</t> which responds with Map-Reply messages.</t>
<t indent="0" pn="section-4-3"> When LISP-DDT <xref target="RFC8111" forma
<t> When LISP-DDT <xref target="RFC8111"/> is used as t="default" sectionFormat="of" derivedContent="RFC8111"/> is used as
the mapping database, a Map-Server sends the final Map-Referral the mapping database, a Map-Server sends the final Map-Referral
messages from the Delegated Database Tree.</t> messages from the Delegated Database Tree.</t>
<t indent="0" pn="section-4-4"> A Map-Resolver receives Encapsulated Map-R
<t> A Map-Resolver receives Encapsulated Map-Requests from its equests from its
client ITRs and uses a mapping database system to find the client ITRs and uses a mapping database system to find the
appropriate ETR to answer those requests. On a LISP-ALT network, a appropriate ETR to answer those requests. On a LISP-ALT network, a
Map-Resolver acts as a "first-hop" ALT-Router. It has Generic Map-Resolver acts as a "first-hop" ALT-Router. It has Generic
Routing Encapsulation (GRE) tunnels configured to other Routing Encapsulation (GRE) tunnels configured to other
ALT-Routers and uses BGP to learn paths to ETRs for different ALT-Routers and uses BGP to learn paths to ETRs for different
prefixes in the LISP-ALT database. The Map-Resolver uses this path prefixes in the LISP-ALT database. The Map-Resolver uses this path
information to forward Map-Requests over the ALT to the correct information to forward Map-Requests over the ALT to the correct
ETRs. On a LISP-DDT network <xref target="RFC8111"/>, a ETRs. On a LISP-DDT network <xref target="RFC8111" format="default" section
Map-Resolver maintains a referral-cache and acts as a "first-hop" Format="of" derivedContent="RFC8111"/>, a
DDT-node. The Map-Resolver uses the referral information to Map-Resolver maintains a referral cache and acts as a "first-hop"
DDT node. The Map-Resolver uses the referral information to
forward Map-Requests.</t> forward Map-Requests.</t>
<t indent="0" pn="section-4-5"> Note that while it is conceivable that a M
<t> Note that while it is conceivable that a Map-Resolver could ap-Resolver could
cache responses to improve performance, issues surrounding cache cache responses to improve performance, issues surrounding cache
management would need to be resolved so that doing so will be management would need to be resolved so that doing so would be
reliable and practical. In this specification, Map-Resolvers will reliable and practical. In this specification, Map-Resolvers will
operate only in a non-caching mode, decapsulating and forwarding operate only in a non-caching mode, decapsulating and forwarding
Encapsulated Map Requests received from ITRs. Any specification Encapsulated Map-Requests received from ITRs. Any specification
of caching functionality is out of scope for this document.</t> of caching functionality is out of scope for this document.</t>
<t indent="0" pn="section-4-6"> Note that a single device can implement th
<t> Note that a single device can implement the functions of both e functions of both
a Map-Server and a Map-Resolver, and in many cases the functions a Map-Server and a Map-Resolver, and in many cases, the functions
will be co-located in that way. Also, there can be ALT-only nodes will be co-located in that way. Also, there can be ALT-only nodes
and DDT-only nodes, when LISP-ALT and LISP-DDT are used, and DDT-only nodes, when LISP-ALT and LISP-DDT are used,
respectively, to connecting Map-Resolvers and Map-Servers together to respectively, connecting Map-Resolvers and Map-Servers together to
make up the Mapping System.</t> make up the Mapping System.</t>
</section>
<t><vspace blankLines='50' /></t> <section anchor="lispcp" numbered="true" toc="include" removeInRFC="false" p
</section> n="section-5">
<name slugifiedName="name-lisp-ipv4-and-ipv6-control-">LISP IPv4 and IPv6
<section title="LISP IPv4 and IPv6 Control-Plane Packet Formats" anchor="lispc Control Plane Packet Formats</name>
p"> <t indent="0" pn="section-5-1">The following UDP packet formats are used b
<t>The following UDP packet formats are used by the LISP y the LISP
control plane.</t> control plane.</t>
<figure align="left" suppress-title="false" pn="figure-1">
<figure title="IPv4 UDP LISP Control Message"> <name slugifiedName="name-ipv4-udp-lisp-control-messa">IPv4 UDP LISP Con
<artwork><![CDATA[ trol Message</name>
0 1 2 3 <artwork name="" type="" align="left" alt="" pn="section-5-2.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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length | |Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset | | Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol = 17 | Header Checksum | | Time to Live | Protocol = 17 | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Routing Locator | | Source Routing Locator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Routing Locator | | Destination Routing Locator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port | Dest Port | / | Source Port | Dest Port |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum | \ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| LISP Message | | LISP Message |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> </figure> </artwork>
</figure>
<figure title="IPv6 UDP LISP Control Message"> <figure align="left" suppress-title="false" pn="figure-2">
<artwork><![CDATA[ <name slugifiedName="name-ipv6-udp-lisp-control-messa">IPv6 UDP LISP Con
trol Message</name>
<artwork name="" type="" align="left" alt="" pn="section-5-3.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| Traffic Class | Flow Label | |Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header=17| Hop Limit | | Payload Length | Next Header=17| Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
skipping to change at line 350 skipping to change at line 502
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port | Dest Port | / | Source Port | Dest Port |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum | \ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| LISP Message | | LISP Message |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> </figure> </artwork>
</figure>
<t>When a UDP Map-Request, Map-Register, or Map-Notify (when used <t indent="0" pn="section-5-4">When a UDP Map-Request, Map-Register, or
as a notification message) are sent, the UDP source port is chosen Map-Notify (when used
as a notification message) is sent, the UDP source port is chosen
by the sender and the destination UDP port number is set to by the sender and the destination UDP port number is set to
4342. When a UDP Map-Reply, Map-Notify (when used as an 4342. When a UDP Map-Reply, Map-Notify (when used as an
acknowledgement to a Map-Register), or Map-Notify-Ack are sent, acknowledgment to a Map-Register), or Map-Notify-Ack is sent,
the source UDP port number is set to 4342 and the destination UDP the source UDP port number is set to 4342 and the destination UDP
port number is copied from the source port of either the port number is copied from the source port of either the
Map-Request or the invoking data packet. Implementations MUST be Map-Request or the invoking data packet. Implementations <bcp14>MUST</bcp14> be
prepared to accept packets when either the source port or prepared to accept packets when either the source port or
destination UDP port is set to 4342 due to NATs changing port destination UDP port is set to 4342 due to NATs changing port
number values.</t> number values.</t>
<t indent="0" pn="section-5-5">The 'UDP Length' field will reflect the len
<t>The 'UDP Length' field will reflect the length of the UDP gth of the UDP
header and the LISP Message payload. LISP is expected to be deployed header and the LISP Message payload. LISP is expected to be deployed
by cooperating entities communicating over underlays. Deployers are by cooperating entities communicating over underlays. Deployers are
expected to set the MTU according to the specific deployment guidelines expected to set the MTU according to the specific deployment guidelines
to prevent fragmentation of either the inner packet or the outer to prevent fragmentation of either the inner packet or the outer
encapsulated packet. For deployments not aware of the underlay encapsulated packet. For deployments not aware of the underlay
restrictions on path MTU, the message size MUST be limited to 576 bytes restrictions on the path MTU, the message size <bcp14>MUST</bcp14> be lim
for IPv4 or 1280 bytes for IPv6 -considering the entire IP packet- as out ited to 576 bytes
lined in <xref target="RFC8085"/>.</t> for IPv4 or 1280 bytes for IPv6 -- considering the entire IP packet -- as
outlined in <xref target="RFC8085" format="default" sectionFormat="of" derivedC
<t>The UDP checksum is computed and set to non-zero for all ontent="RFC8085"/>.</t>
messages sent to or from port 4342. It MUST be checked on <t indent="0" pn="section-5-6">The UDP checksum is computed and set to non
receipt, and if the checksum fails, the control message MUST be -zero for all
dropped <xref target="RFC1071"/>.</t> messages sent to or from port 4342. It <bcp14>MUST</bcp14> be checked on
receipt, and if the checksum fails, the control message <bcp14>MUST</bcp14>
<t>The format of control messages includes the UDP header so the be
dropped <xref target="RFC1071" format="default" sectionFormat="of" derivedCo
ntent="RFC1071"/>.</t>
<t indent="0" pn="section-5-7">The format of control messages includes the
UDP header so the
checksum and length fields can be used to protect and delimit checksum and length fields can be used to protect and delimit
message boundaries.</t> message boundaries.</t>
<section numbered="true" toc="include" removeInRFC="false" pn="section-5.1
<t><vspace blankLines='50' /></t> ">
<name slugifiedName="name-lisp-control-packet-type-al">LISP Control Pack
<section title="LISP Control Packet Type Allocations"> et Type Allocations</name>
<t>This section defines the LISP control message formats and <t indent="0" pn="section-5.1-1">This section defines the LISP control m
essage formats and
summarizes for IANA the LISP Type codes assigned by this summarizes for IANA the LISP Type codes assigned by this
document. For completeness, the summary below includes the LISP document. For completeness, the summary below includes the LISP
Shared Extension Message assigned by <xref Shared Extension Message assigned by <xref target="RFC9304" format="defaul
target="I-D.ietf-lisp-rfc8113bis"/>. Message type definitions t" sectionFormat="of" derivedContent="RFC9304"/>. Message type definitions
are:</t> are:</t>
<table align="center" pn="table-1">
<figure> <artwork><![CDATA[ <thead>
Reserved: 0 b'0000' <tr>
LISP Map-Request: 1 b'0001' <th align="left" colspan="1" rowspan="1">Message</th>
LISP Map-Reply: 2 b'0010' <th align="left" colspan="1" rowspan="1">Code</th>
LISP Map-Register: 3 b'0011' <th align="left" colspan="1" rowspan="1">Codepoint</th>
LISP Map-Notify: 4 b'0100' </tr>
LISP Map-Notify-Ack: 5 b'0101' </thead>
LISP Map-Referral: 6 b'0110' <tbody>
Unassigned 7 b'0111' <tr>
LISP Encapsulated Control Message: 8 b'1000' <td align="left" colspan="1" rowspan="1">Reserved</td>
Unassigned 9-14 b'1001'- b'1110' <td align="left" colspan="1" rowspan="1">0</td>
LISP Shared Extension Message: 15 b'1111' <td align="left" colspan="1" rowspan="1">b'0000'</td>
]]></artwork> </figure> </tr>
<tr>
<t>Protocol designers experimenting with new message formats are <td align="left" colspan="1" rowspan="1">LISP Map-Request</td>
<td align="left" colspan="1" rowspan="1">1</td>
<td align="left" colspan="1" rowspan="1">b'0001'</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">LISP Map-Reply</td>
<td align="left" colspan="1" rowspan="1">2</td>
<td align="left" colspan="1" rowspan="1">b'0010'</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">LISP Map-Register</td>
<td align="left" colspan="1" rowspan="1">3</td>
<td align="left" colspan="1" rowspan="1">b'0011'</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">LISP Map-Notify</td>
<td align="left" colspan="1" rowspan="1">4</td>
<td align="left" colspan="1" rowspan="1">b'0100'</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">LISP Map-Notify-Ack</td>
<td align="left" colspan="1" rowspan="1">5</td>
<td align="left" colspan="1" rowspan="1">b'0101'</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">LISP DDT Map-Referral</td
>
<td align="left" colspan="1" rowspan="1">6</td>
<td align="left" colspan="1" rowspan="1">b'0110'</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">Unassigned</td>
<td align="left" colspan="1" rowspan="1">7</td>
<td align="left" colspan="1" rowspan="1">b'0111'</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">LISP Encapsulated Control
Message</td>
<td align="left" colspan="1" rowspan="1">8</td>
<td align="left" colspan="1" rowspan="1">b'1000'</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">Unassigned</td>
<td align="left" colspan="1" rowspan="1">9-14</td>
<td align="left" colspan="1" rowspan="1">b'1001'- b'1110'</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">LISP Shared Extension Mes
sage</td>
<td align="left" colspan="1" rowspan="1">15</td>
<td align="left" colspan="1" rowspan="1">b'1111'</td>
</tr>
</tbody>
</table>
<t indent="0" pn="section-5.1-3">Protocol designers experimenting with n
ew message formats are
recommended to use the LISP Shared Extension Message Type described recommended to use the LISP Shared Extension Message Type described
in <xref target="I-D.ietf-lisp-rfc8113bis"/>.</t> in <xref target="RFC9304" format="default" sectionFormat="of" derivedConte
nt="RFC9304"/>.</t>
<t>All LISP Control-Plane messages use Address Family <t indent="0" pn="section-5.1-4">All LISP control plane messages use Add
Identifiers (AFI) <xref target="AFI"/> or LISP Canonical Address ress Family
Format (LCAF) <xref target="RFC8060"/> formats to encode either Identifiers (AFIs) <xref target="AFN" format="default" sectionFormat="of"
fixed or variable length addresses. This includes explicit derivedContent="AFN"/> or LISP Canonical Address
fields in each control message or part of EID-records or Format (LCAF) entries <xref target="RFC8060" format="default" sectionForma
RLOC-records in commonly formatted messages. LISP control-plane t="of" derivedContent="RFC8060"/> to encode either
messages that include an unrecognized AFI MUST be fixed-length or variable-length addresses. This includes explicit
dropped and the event MUST be logged.</t> fields in each control message or part of EID-Records or
RLOC-Records in commonly formatted messages. LISP control plane
<t>The LISP control-plane describes how other data-planes can messages that include an unrecognized AFI <bcp14>MUST</bcp14> be
encode messages to support the Soliciting of Map-Requests as well as dropped, and the event <bcp14>MUST</bcp14> be logged.</t>
RLOC-probing procedures.</t> <t indent="0" pn="section-5.1-5">The LISP control plane describes how ot
her data planes can
<t><vspace blankLines='50' /></t> encode messages to support the soliciting of Map-Requests as well as
</section> RLOC-Probing procedures.</t>
</section>
<section title="Map-Request Message Format" anchor="NONCE"> <section anchor="NONCE" numbered="true" toc="include" removeInRFC="false"
<figure> <artwork><![CDATA[ pn="section-5.2">
<name slugifiedName="name-map-request-message-format">Map-Request Messag
e 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=1 |A|M|P|S|p|s|R|R| Rsvd |L|D| IRC | Record Count | |Type=1 |A|M|P|S|p|s|R|R| Rsvd |L|D| IRC | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . | | Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce | | . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source-EID-AFI | Source EID Address ... | | Source-EID-AFI | Source EID Address ... |
skipping to change at line 451 skipping to change at line 645
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ITR-RLOC-AFI n | ITR-RLOC Address n ... | | ITR-RLOC-AFI n | ITR-RLOC Address n ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Reserved | EID mask-len | EID-Prefix-AFI | / | Reserved | EID mask-len | EID-Prefix-AFI |
Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | EID-Prefix ... | \ | EID-Prefix ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Map-Reply Record ... | | Map-Reply Record ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> </figure> </artwork>
<t indent="0" pn="section-5.2-2">Packet field descriptions:</t>
<t>Packet field descriptions:</t> <dl newline="false" spacing="normal" indent="3" pn="section-5.2-3">
<t><list style="hanging"> <dt pn="section-5.2-3.1">Type: </dt>
<t hangText="Type: ">1 (Map-Request)</t> <dd pn="section-5.2-3.2">1 (Map-Request)</dd>
<dt pn="section-5.2-3.3">A:</dt>
<t hangText="A:"> This is an authoritative bit, it is set to 1 <dd pn="section-5.2-3.4">This is an authoritative bit. It is set to 1
when an ITR wants the destination site to return the Map-Reply when an ITR wants the destination site to return the Map-Reply
rather than the mapping database system returning a Map-Reply, and rather than the mapping database system returning a Map-Reply and
set to 0 otherwise.</t> is set to 0 otherwise.</dd>
<dt pn="section-5.2-3.5">M:</dt>
<t hangText="M:"> This is the map-data-present bit. When set, <dd pn="section-5.2-3.6">This is the map-data-present bit. When set,
it indicates that a Map-Reply Record segment is included in it indicates that a Map-Reply Record segment is included in
the Map-Request.</t> the Map-Request.</dd>
<dt pn="section-5.2-3.7">P:</dt>
<t hangText="P:"> This is the probe-bit, which indicates that a <dd pn="section-5.2-3.8">This is the probe-bit, which indicates that a
Map-Request MUST be treated as a Locator reachability Map-Request <bcp14>MUST</bcp14> be treated as a Locator reachability
probe. The receiver MUST respond with a Map-Reply with the probe. The receiver <bcp14>MUST</bcp14> respond with a Map-Reply with th
e
probe-bit set, indicating that the Map-Reply is a Locator probe-bit set, indicating that the Map-Reply is a Locator
reachability probe reply, with the nonce copied from the reachability probe reply, with the nonce copied from the
Map-Request. See RLOC-Probing <xref target="rloc-probe"/> for Map-Request. See
more details. This RLOC-probe Map-Request MUST NOT be sent to "<xref target="rloc-probe" format="title" sectionFormat="of" derivedCont
the mapping system. If a Map-Resolver or Map-Server receives a ent="RLOC-Probing Algorithm"/>" (<xref target="rloc-probe" format="default" sect
Map-Request with the probe-bit set, it MUST drop the message.</t> ionFormat="of" derivedContent="Section 7.1"/>) for
more details. This RLOC-Probe Map-Request <bcp14>MUST NOT</bcp14> be sen
<t hangText="S:"> This is the Solicit-Map-Request (SMR) t to
bit. See Solicit-Map-Request (SMRs) <xref target="SMR"/> for the Mapping System. If a Map-Resolver or Map-Server receives a
details.</t> Map-Request with the probe-bit set, it <bcp14>MUST</bcp14> drop the mess
age.</dd>
<t hangText="p:"> This is the PITR bit. This bit is set to 1 <dt pn="section-5.2-3.9">S:</dt>
when a PITR sends a Map-Request. The use of this bit is deployment-speci <dd pn="section-5.2-3.10"> This is the Solicit-Map-Request (SMR)
fic.</t> bit. See "<xref target="SMR" format="title" sectionFormat="of" derivedCo
ntent="Solicit-Map-Request (SMR)"/>" (<xref target="SMR" format="default" sectio
<t hangText="s:"> This is the SMR-invoked bit. This bit is set nFormat="of" derivedContent="Section 6.1"/>) for
details.</dd>
<dt pn="section-5.2-3.11">p:</dt>
<dd pn="section-5.2-3.12"> This is the Proxy Ingress Tunnel Router (PI
TR) bit. This bit is set to 1
when a PITR sends a Map-Request. The use of this bit is deployment speci
fic.</dd>
<dt pn="section-5.2-3.13">s:</dt>
<dd pn="section-5.2-3.14"> This is the SMR-invoked bit. This bit is se
t
to 1 when an xTR is sending a Map-Request in response to a to 1 when an xTR is sending a Map-Request in response to a
received SMR-based Map-Request.</t> received SMR-based Map-Request.</dd>
<dt pn="section-5.2-3.15">R:</dt>
<t hangText="R:">This reserved and unassigned bit MUST be set to 0 on <dd pn="section-5.2-3.16">This reserved and unassigned bit <bcp14>MUST
transmit and MUST be ignored on receipt.</t> </bcp14> be set to 0 on
transmit and <bcp14>MUST</bcp14> be ignored on receipt.</dd>
<t hangText="Rsvd:">This field MUST be set to 0 on transmit <dt pn="section-5.2-3.17">Rsvd:</dt>
and MUST be ignored on receipt.</t> <dd pn="section-5.2-3.18">This field <bcp14>MUST</bcp14> be set to 0 o
n transmit
<t hangText="L:"> This is the local-xtr bit. It is used by an and <bcp14>MUST</bcp14> be ignored on receipt.</dd>
<dt pn="section-5.2-3.19">L:</dt>
<dd pn="section-5.2-3.20"> This is the local-xtr bit. It is used by an
xTR in a LISP site to tell other xTRs in the same site that it xTR in a LISP site to tell other xTRs in the same site that it
is part of the RLOC-set for the LISP site. The L-bit is set to is part of the RLOC-Set for the LISP site. The L-bit is set to
1 when the RLOC is the sender's IP address.</t> 1 when the RLOC is the sender's IP address.</dd>
<dt pn="section-5.2-3.21">D:</dt>
<t hangText="D:"> This is the dont-map-reply bit. It is used <dd pn="section-5.2-3.22"> This is the dont-map-reply bit. It is used
in the SMR procedure described in <xref target="SMR"/>. When in the SMR procedure described in <xref target="SMR" format="default" se
ctionFormat="of" derivedContent="Section 6.1"/>. When
an xTR sends an SMR message, it doesn't need a an xTR sends an SMR message, it doesn't need a
Map-Reply returned. When this bit is set, the receiver of the Map-Reply returned. When this bit is set, the receiver of the
Map-Request does not return a Map-Reply.</t> Map-Request does not return a Map-Reply.</dd>
<dt pn="section-5.2-3.23">IRC:</dt>
<t hangText="IRC:"> This 5-bit field is the ITR-RLOC Count, <dd pn="section-5.2-3.24"> This 5-bit field is the ITR-RLOC Count,
which encodes the additional number of ('ITR-RLOC-AFI', which encodes the additional number of ('ITR-RLOC-AFI',
'ITR-RLOC Address') fields present in this message. At least 'ITR-RLOC Address') fields present in this message. At least
one (ITR-RLOC-AFI, ITR-RLOC-Address) pair MUST be encoded. one (ITR-RLOC-AFI, ITR-RLOC Address) pair <bcp14>MUST</bcp14> be encoded .
Multiple 'ITR-RLOC Address' fields are used, so a Map-Replier Multiple 'ITR-RLOC Address' fields are used, so a Map-Replier
can select which destination address to use for a can select which destination address to use for a
Map-Reply. The IRC value ranges from 0 to 31. For a value of Map-Reply. The IRC value ranges from 0 to 31. For a value of
0, there is 1 ITR-RLOC address encoded; for a value of 1, 0, there is 1 ITR-RLOC address encoded; for a value of 1,
there are 2 ITR-RLOC addresses encoded, and so on up to 31, there are 2 ITR-RLOC addresses encoded, and so on up to 31,
which encodes a total of 32 ITR-RLOC addresses.</t> which encodes a total of 32 ITR-RLOC addresses.</dd>
<dt pn="section-5.2-3.25">Record Count:</dt>
<t hangText="Record Count:"> This is the number of records in <dd pn="section-5.2-3.26"> This is the number of records in
this Map-Request message. A record is comprised of the this Map-Request message. A record is comprised of the
portion of the packet that is labeled 'Rec' above and occurs portion of the packet that is labeled 'Rec' above and occurs
the number of times equal to Record Count. For this version of the number of times equal to Record Count. For this version of
the protocol, a receiver MUST accept and process Map-Requests the protocol, a receiver <bcp14>MUST</bcp14> accept and process Map-Requ
that contain one or more records, but a sender MUST only send ests
Map-Requests containing one record.</t> that contain one or more records, but a sender <bcp14>MUST</bcp14> only
send
<t hangText="Nonce:"> This is an 8-octet random value created Map-Requests containing one record.</dd>
<dt pn="section-5.2-3.27">Nonce:</dt>
<dd pn="section-5.2-3.28"> This is an 8-octet random value created
by the sender of the Map-Request. This nonce will be returned by the sender of the Map-Request. This nonce will be returned
in the Map-Reply. The nonce is used as an index to identify in the Map-Reply. The nonce is used as an index to identify
the corresponding Map-Request when a Map-Reply message is received. the corresponding Map-Request when a Map-Reply message is received.
The nonce MUST be generated by a The nonce <bcp14>MUST</bcp14> be generated by a
properly seeded pseudo-random source, see as an example properly seeded pseudo-random source; for example, see
<xref target="RFC4086" />.</t> <xref target="RFC4086" format="default" sectionFormat="of" derivedConten
t="RFC4086"/>.</dd>
<t hangText="Source-EID-AFI:"> This is the address family of <dt pn="section-5.2-3.29">Source-EID-AFI:</dt>
the 'Source EID Address' field.</t> <dd pn="section-5.2-3.30"> This is the address family of
the 'Source EID Address' field.</dd>
<t hangText="Source EID Address:"> This is the EID of the <dt pn="section-5.2-3.31">Source EID Address:</dt>
<dd pn="section-5.2-3.32"> This is the EID of the
source host that originated the packet that caused the source host that originated the packet that caused the
Map-Request. When Map-Requests are used for refreshing a Map-Request. When Map-Requests are used for refreshing a
Map-Cache entry or for RLOC-Probing, an AFI value 0 is used Map-Cache entry or for RLOC-Probing, an AFI value of 0 is used,
and this field is of zero length.</t> and this field is of zero length.</dd>
<dt pn="section-5.2-3.33">ITR-RLOC-AFI:</dt>
<t hangText="ITR-RLOC-AFI:"> This is the address family of the <dd pn="section-5.2-3.34"> This is the address family of the
'ITR-RLOC Address' field that follows this field.</t> 'ITR-RLOC Address' field that follows this field.</dd>
<dt pn="section-5.2-3.35">ITR-RLOC Address:</dt>
<t hangText="ITR-RLOC Address:"> This is used to give the ETR <dd pn="section-5.2-3.36"> This is used to give the ETR
the option of selecting the destination address from any the option of selecting the destination address from any
address family for the Map-Reply message. This address MUST be address family for the Map-Reply message. This address <bcp14>MUST</bcp1 4> be
a routable RLOC address of the sender of the Map-Request a routable RLOC address of the sender of the Map-Request
message.</t> message.</dd>
<dt pn="section-5.2-3.37">EID mask-len:</dt>
<t hangText="EID mask-len:"> This is the mask length for the <dd pn="section-5.2-3.38"> This is the mask length for the
EID-Prefix.</t> EID-Prefix.</dd>
<dt pn="section-5.2-3.39">EID-Prefix-AFI:</dt>
<t hangText="EID-Prefix-AFI:"> This is the address family of <dd pn="section-5.2-3.40"> This is the address family of
the EID-Prefix according to <xref target="AFI" /> and <xref the EID-Prefix according to <xref target="AFN" format="default" sectionF
target="RFC8060"/>.</t> ormat="of" derivedContent="AFN"/> and <xref target="RFC8060" format="default" se
ctionFormat="of" derivedContent="RFC8060"/>.</dd>
<t hangText="EID-Prefix:"> This prefix address length is 4 <dt pn="section-5.2-3.41">EID-Prefix:</dt>
<dd pn="section-5.2-3.42"> This prefix address length is 4
octets for an IPv4 address family and 16 octets for an IPv6 octets for an IPv4 address family and 16 octets for an IPv6
address family when the EID-Prefix-AFI is 1 or 2, address family when the EID-Prefix-AFI is 1 or 2,
respectively. For other AFIs <xref target="AFI"/>, the address respectively. For other AFIs <xref target="AFN" format="default" section
length varies and for the LCAF AFI the format is defined in Format="of" derivedContent="AFN"/>, the address
<xref target="RFC8060"/>. When a Map-Request is sent by an length varies, and for the LCAF AFI, the format is defined in
<xref target="RFC8060" format="default" sectionFormat="of" derivedConten
t="RFC8060"/>. When a Map-Request is sent by an
ITR because a data packet is received for a destination where ITR because a data packet is received for a destination where
there is no mapping entry, the EID-Prefix is set to the there is no mapping entry, the EID-Prefix is set to the
destination IP address of the data packet, and the 'EID destination IP address of the data packet, and the 'EID
mask-len' is set to 32 or 128 for IPv4 or IPv6, mask-len' field is set to 32 or 128 for IPv4 or IPv6,
respectively. When an xTR wants to query a site about the respectively. When an xTR wants to query a site about the
status of a mapping it already has cached, the EID-Prefix used status of a mapping it already has cached, the EID-Prefix used
in the Map-Request has the same mask-length as the EID-Prefix in the Map-Request has the same mask length as the EID-Prefix
returned from the site when it sent a Map-Reply message.</t> returned from the site when it sent a Map-Reply message.</dd>
<dt pn="section-5.2-3.43">Map-Reply Record:</dt>
<t hangText="Map-Reply Record:"> When the M-bit is set, this <dd pn="section-5.2-3.44"> When the M-bit is set, this
field is the size of a single "Record" in the Map-Reply field is the size of a single "Record" in the Map-Reply
format. This Map-Reply record contains the EID-to-RLOC mapping format. This Map-Reply record contains the EID-to-RLOC mapping
entry associated with the Source EID. This allows the ETR that entry associated with the source EID. This allows the ETR that
will receive this Map-Request to cache the data if it chooses will receive this Map-Request to cache the data if it chooses
to do so. It is important to note that this mapping has not been validat to do so. It is important to note that this mapping has not been validat
ed by the Mapping System.</t> ed by the Mapping System.</dd>
</list></t> </dl>
</section> </section>
<section anchor="MAPREQ" numbered="true" toc="include" removeInRFC="false"
<section title="EID-to-RLOC UDP Map-Request Message" anchor="MAPREQ"> pn="section-5.3">
<t>A Map-Request is sent from an ITR when it needs a mapping for <name slugifiedName="name-eid-to-rloc-udp-map-request">EID-to-RLOC UDP M
ap-Request Message</name>
<t indent="0" pn="section-5.3-1">A Map-Request is sent from an ITR when
it needs a mapping for
an EID, wants to test an RLOC for reachability, or wants to an EID, wants to test an RLOC for reachability, or wants to
refresh a mapping before TTL expiration. For the initial case, refresh a mapping before Time to Live (TTL) expiration. For the initial ca se,
the destination IP address used for the Map-Request is the data the destination IP address used for the Map-Request is the data
packet's destination address (i.e., the destination EID) that packet's destination address (i.e., the destination EID) that
had a mapping cache lookup failure. For the latter two cases, had a mapping cache lookup failure. For the latter two cases,
the destination IP address used for the Map-Request is one of the destination IP address used for the Map-Request is one of
the RLOC addresses from the Locator-Set of the Map-Cache the RLOC addresses from the Locator-Set of the Map-Cache
entry. The source address is either an IPv4 or IPv6 RLOC entry. The source address is either an IPv4 or IPv6 RLOC
address, depending on whether the Map-Request is using an IPv4 address, depending on whether the Map-Request is using an IPv4
or IPv6 header, respectively. In all cases, the UDP source port or IPv6 header, respectively. In all cases, the UDP source port
number for the Map-Request message is a 16-bit value selected by number for the Map-Request message is a 16-bit value selected by
the ITR/PITR, and the UDP destination port number is set to the the ITR/PITR, and the UDP destination port number is set to the
well-known destination port number 4342. A successful well-known destination port number 4342. A successful
Map-Reply, which is one that has a nonce that matches an Map-Reply, which is one that has a nonce that matches an
outstanding Map-Request nonce, will update the cached set of outstanding Map-Request nonce, will update the cached set of
RLOCs associated with the EID-Prefix range.</t> RLOCs associated with the EID-Prefix range.</t>
<t indent="0" pn="section-5.3-2">One or more Map-Request ('ITR-RLOC-AFI'
<t>One or more Map-Request ('ITR-RLOC-AFI', 'ITR-RLOC-Address') , 'ITR-RLOC Address')
fields MUST be filled in by the ITR. The number of fields (minus fields <bcp14>MUST</bcp14> be filled in by the ITR. The number of fields (
1) encoded MUST be placed in the 'IRC' field. The ITR MAY minus
1) encoded <bcp14>MUST</bcp14> be placed in the 'IRC' field. The ITR <bcp1
4>MAY</bcp14>
include all locally configured Locators in this list or just include all locally configured Locators in this list or just
provide one locator address from each address family it provide one Routing Locator Address from each address family it
supports. If the ITR erroneously provides no ITR-RLOC addresses, supports. If the ITR erroneously provides no ITR-RLOC addresses,
the Map-Replier MUST drop the Map-Request.</t> the Map-Replier <bcp14>MUST</bcp14> drop the Map-Request.</t>
<t indent="0" pn="section-5.3-3">Map-Requests can also be LISP encapsula
<t>Map-Requests can also be LISP encapsulated using UDP ted using UDP
destination port&nbsp;4342 with a LISP Type value set to destination port 4342 with a LISP Type value set to
"Encapsulated Control Message", when sent from an ITR to a "Encapsulated Control Message", when sent from an ITR to a
Map-Resolver. Likewise, Map-Requests are LISP encapsulated the Map-Resolver. Likewise, Map-Requests are LISP encapsulated the
same way from a Map-Server to an ETR. Details on Encapsulated same way from a Map-Server to an ETR. Details on Encapsulated
Map-Requests and Map-Resolvers can be found in <xref Map-Requests and Map-Resolvers can be found in <xref target="encap-mr" for
target="encap-mr" />.</t> mat="default" sectionFormat="of" derivedContent="Section 5.8"/>.</t>
<t indent="0" pn="section-5.3-4">Map-Requests <bcp14>MUST</bcp14> be rat
<t>Map-Requests MUST be rate-limited to 1 per second per EID-prefix. e limited to 1 per second per EID-Prefix.
After 10 retransmits without receiving the corresponding Map-Reply the sen After 10 retransmits without receiving the corresponding Map-Reply, the se
der MUST wait 30 seconds.</t> nder <bcp14>MUST</bcp14> wait 30 seconds.</t>
<t indent="0" pn="section-5.3-5">An ITR that is configured with mapping
<t>An ITR that is configured with mapping database information database information
(i.e., it is also an ETR) MAY optionally include those mappings (i.e., it is also an ETR) <bcp14>MAY</bcp14> optionally include those mapp
ings
in a Map-Request. When an ETR configured to accept and verify in a Map-Request. When an ETR configured to accept and verify
such "piggybacked" mapping data receives such a Map-Request and such "piggybacked" mapping data receives such a Map-Request and
it does not have this mapping in the Map-Cache, it MUST originate it does not have this mapping in the Map-Cache, it <bcp14>MUST</bcp14> ori ginate
a "verifying Map-Request" through the mapping database to validate a "verifying Map-Request" through the mapping database to validate
thge "piggybacked" mapping data.</t> the "piggybacked" mapping data.</t>
</section>
<t><vspace blankLines='50' /></t> <section anchor="MR-FORMAT" numbered="true" toc="include" removeInRFC="fal
</section> se" pn="section-5.4">
<name slugifiedName="name-map-reply-message-format">Map-Reply Message Fo
<section title="Map-Reply Message Format" anchor="MR-FORMAT"> rmat</name>
<figure> <artwork><![CDATA[ <artwork name="" type="" align="left" alt="" pn="section-5.4-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=2 |P|E|S| Reserved | Record Count | |Type=2 |P|E|S| Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . | | Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce | | . . . Nonce |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-&gt; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL | | | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R | Locator Count | EID mask-len | ACT |A| Reserved | R | Locator Count | EID mask-len | ACT |A| Reserved |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c | Rsvd | Map-Version Number | EID-Prefix-AFI | c | Rsvd | Map-Version Number | EID-Prefix-AFI |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | EID-Prefix | r | EID-Prefix |
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight | | /| Priority | Weight | M Priority | M Weight |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o | Unused Flags |L|p|R| Loc-AFI | | o | Unused Flags |L|p|R| Loc-AFI |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator | | \| Locator |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-&gt; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> </figure> </artwork>
<t indent="0" pn="section-5.4-2">Packet field descriptions:</t>
<t>Packet field descriptions:</t> <dl newline="false" spacing="normal" indent="3" pn="section-5.4-3">
<t><list style="hanging"> <dt pn="section-5.4-3.1">Type: </dt>
<t hangText="Type: ">2 (Map-Reply)</t> <dd pn="section-5.4-3.2">2 (Map-Reply)</dd>
<dt pn="section-5.4-3.3">P:</dt>
<t hangText="P:"> This is the probe-bit, which indicates that <dd pn="section-5.4-3.4"> This is the probe-bit, which indicates that
the Map-Reply is in response to a Locator reachability probe the Map-Reply is in response to a Locator reachability probe
Map-Request. The 'Nonce' field must contain a copy of the Map-Request. The 'Nonce' field must contain a copy of the
nonce value from the original Map-Request. See RLOC-probing nonce value from the original Map-Request. See
<xref target="rloc-probe"/> for more details. When the "<xref target="rloc-probe" format="title" sectionFormat="of" derivedCont
ent="RLOC-Probing Algorithm"/>" (<xref target="rloc-probe" format="default" sect
ionFormat="of" derivedContent="Section 7.1"/>) for more details. When the
probe-bit is set to 1 in a Map-Reply message, the A-bit in probe-bit is set to 1 in a Map-Reply message, the A-bit in
each EID-record included in the message MUST be set to 1, each EID-Record included in the message <bcp14>MUST</bcp14> be set to 1;
otherwise MUST be silently discarded.</t> otherwise, it <bcp14>MUST</bcp14> be silently discarded.</dd>
<dt pn="section-5.4-3.5">E:</dt>
<t hangText="E:"> This bit indicates that the ETR that sends <dd pn="section-5.4-3.6"> This bit indicates that the ETR that sends
this Map-Reply message is advertising that the site is enabled this Map-Reply message is advertising that the site is enabled
for the Echo-Nonce Locator reachability algorithm. See for the Echo-Nonce Locator reachability algorithm. See
Echo-Nonce <xref target="I-D.ietf-lisp-rfc6830bis" /> for more Section <xref target="RFC9300" section="10.1" sectionFormat="bare" format="defau
details.</t> lt" derivedLink="https://rfc-editor.org/rfc/rfc9300#section-10.1" derivedContent
="RFC9300">"Echo-Nonce Algorithm"</xref> of <xref target="RFC9300" format="defau
<t hangText="S:"> This is the Security bit. When set to 1, the lt" sectionFormat="of" derivedContent="RFC9300"/> for more
details.</dd>
<dt pn="section-5.4-3.7">S:</dt>
<dd pn="section-5.4-3.8"> This is the Security bit. When set to 1, the
following authentication information will be appended to the following authentication information will be appended to the
end of the Map-Reply. The details can be found in <xref end of the Map-Reply. Details can be found in <xref target="RFC9303" for
target="I-D.ietf-lisp-sec"/>.</t> mat="default" sectionFormat="of" derivedContent="RFC9303"/>.</dd>
</list></t> </dl>
<artwork name="" type="" align="left" alt="" pn="section-5.4-4">
<figure> <artwork><![CDATA[ 0 1 2 3
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AD Type | Authentication Data Content . . . |
| AD Type | Authentication Data Content . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </artwork>
]]></artwork> </figure> <dl newline="false" spacing="normal" indent="3" pn="section-5.4-5">
<dt pn="section-5.4-5.1">Reserved:</dt>
<t><list style="hanging"> <dd pn="section-5.4-5.2"> This unassigned field <bcp14>MUST</bcp14> be
<t hangText="Reserved:"> This unassigned field MUST be set to 0 on set to 0 on
transmit and MUST be ignored on receipt.</t> transmit and <bcp14>MUST</bcp14> be ignored on receipt.</dd>
<dt pn="section-5.4-5.3">Record Count:</dt>
<t hangText="Record Count:"> This is the number of records in <dd pn="section-5.4-5.4"> This is the number of records in
this reply message. A record is comprised of that portion of this reply message. A record is comprised of that portion of
the packet labeled 'Record' above and occurs the number of the packet labeled 'Record' above and occurs the number of
times equal to Record Count. Note that the reply count can times equal to Record Count. Note that the reply count can
be larger than the requested count, for instance when more-specifics are be larger than the requested count, for instance, when more-specific pre
present.</t> fixes are present.</dd>
<dt pn="section-5.4-5.5">Nonce:</dt>
<t hangText="Nonce:"> This 64-bit value from the Map-Request <dd pn="section-5.4-5.6"> This 64-bit value from the Map-Request
is echoed in this 'Nonce' field of the Map-Reply.</t> is echoed in this 'Nonce' field of the Map-Reply.</dd>
<dt pn="section-5.4-5.7">Record TTL:</dt>
<t hangText="Record TTL:"> This is the time in minutes the <dd pn="section-5.4-5.8"> This is the time in minutes the
recipient of the Map-Reply can store the mapping. If the TTL recipient of the Map-Reply can store the mapping. If the TTL
is 0, the entry MUST be removed from the cache immediately. is 0, the entry <bcp14>MUST</bcp14> be removed from the cache immediatel y.
If the value is 0xffffffff, the recipient can decide locally If the value is 0xffffffff, the recipient can decide locally
how long to store the mapping.</t> how long to store the mapping.</dd>
<dt pn="section-5.4-5.9">Locator Count:</dt>
<t hangText="Locator Count:"> This is the number of Locator <dd pn="section-5.4-5.10"> This is the number of Locator
entries in the given Record. A Locator entry comprises what is labeled a bove as entries in the given Record. A Locator entry comprises what is labeled a bove as
&apos;Loc&apos;. The Locator count can be 0, indicating that 'Loc'. The Locator count can be 0, indicating that
there are no Locators for the EID-Prefix.</t> there are no Locators for the EID-Prefix.</dd>
<dt pn="section-5.4-5.11">EID mask-len:</dt>
<t hangText="EID mask-len:"> This is the mask length for the <dd pn="section-5.4-5.12"> This is the mask length for the
EID-Prefix.</t> EID-Prefix.</dd>
<dt pn="section-5.4-5.13">ACT:</dt>
<t hangText="ACT:"> This 3-bit field describes Negative <dd pn="section-5.4-5.14">
<t indent="0" pn="section-5.4-5.14.1">This 3-bit field describes Neg
ative
Map-Reply actions. In any other message type, these bits are Map-Reply actions. In any other message type, these bits are
set to 0 and ignored on receipt. These bits are used only when set to 0 and ignored on receipt. These bits are used only when
the 'Locator Count' field is set to 0. The action bits are the 'Locator Count' field is set to 0. The action bits are
encoded only in Map-Reply messages. They are used to tell an encoded only in Map-Reply messages. They are used to tell an
ITR or PITR why a empty locator-set was returned from the ITR or PITR why an empty Locator-Set was returned from the
mapping system and how it stores the map-cache entry. Mapping System and how it stores the Map-Cache entry.
See <xref target="act-iana"/> for additional information.</t> See <xref target="act-iana" format="default" sectionFormat="of" derivedC
ontent="Section 12.3"/> for additional information.</t>
<t><list style="hanging" hangIndent="4"> <dl newline="false" spacing="normal" indent="4" pn="section-5.4-5.14
<t hangText="(0) No-Action:">The Map-Cache is kept alive, .2">
and no packet encapsulation occurs.</t> <dt pn="section-5.4-5.14.2.1">(0) No-Action:</dt>
<dd pn="section-5.4-5.14.2.2">The Map-Cache is kept alive,
<t hangText="(1) Natively-Forward:">The packet is not and no packet encapsulation occurs.</dd>
encapsulated or dropped but natively forwarded.</t> <dt pn="section-5.4-5.14.2.3">(1) Natively-Forward:</dt>
<dd pn="section-5.4-5.14.2.4">The packet is not
<t hangText="(2) Send-Map-Request:">The Map-Cache entry is encapsulated or dropped but natively forwarded.</dd>
created and flagged that any packet matching this entry <dt pn="section-5.4-5.14.2.5">(2) Send-Map-Request:</dt>
invokes sending a Map-Request.</t> <dd pn="section-5.4-5.14.2.6">The Map-Cache entry is
created and flagged so that any packet matching this entry
<t hangText="(3) Drop/No-Reason:">A packet that matches this invokes sending a Map-Request.</dd>
<dt pn="section-5.4-5.14.2.7">(3) Drop/No-Reason:</dt>
<dd pn="section-5.4-5.14.2.8">A packet that matches this
Map-Cache entry is dropped. An ICMP Destination Unreachable Map-Cache entry is dropped. An ICMP Destination Unreachable
message SHOULD be sent.</t> message <bcp14>SHOULD</bcp14> be sent.</dd>
<dt pn="section-5.4-5.14.2.9">(4) Drop/Policy-Denied:</dt>
<t hangText="(4) Drop/Policy-Denied:">A packet that matches <dd pn="section-5.4-5.14.2.10">A packet that matches
this Map-Cache entry is dropped. The reason for the Drop this Map-Cache entry is dropped. The reason for the Drop
action is that a Map-Request for the target-EID is being action is that a Map-Request for the target EID is being
policy denied by either an xTR or the mapping system.</t> policy-denied by either an xTR or the Mapping System.</dd>
<dt pn="section-5.4-5.14.2.11">(5) Drop/Auth-Failure:</dt>
<t hangText="(5) Drop/Authentication-Failure:">A packet that <dd pn="section-5.4-5.14.2.12">A packet that
matches this Map-Cache entry is dropped. The reason for the matches this Map-Cache entry is dropped. The reason for the
Drop action is that a Map-Request for the target-EID fails Drop action is that a Map-Request for the target EID fails
an authentication verification-check by either an xTR or the an authentication verification check by either an xTR or the
mapping system.</t> Mapping System.</dd>
</list></t> </dl>
</dd>
<t hangText="A:"> The Authoritative bit MAY only be set to 1 by an ETR. <dt pn="section-5.4-5.15">A:</dt>
A Map-Server generating Map-Reply messages as a proxy MUST NOT set the A <dd pn="section-5.4-5.16"> The Authoritative bit <bcp14>MAY</bcp14> on
-bit to 1. This bit ly be set to 1 by an ETR.
A Map-Server generating Map-Reply messages as a proxy <bcp14>MUST NOT</b
cp14> set the A-bit to 1. This bit
indicates to the requesting ITRs if the Map-Reply was indicates to the requesting ITRs if the Map-Reply was
originated by a LISP node managed at the site that owns the originated by a LISP node managed at the site that owns the
EID-Prefix.</t> EID-Prefix.</dd>
<dt pn="section-5.4-5.17">Map-Version Number:</dt>
<t hangText="Map-Version Number:"> When this 12-bit value is <dd pn="section-5.4-5.18"> When this 12-bit value in an EID-Record of
non-zero, the Map-Reply sender is informing the ITR what the a
version number is for the EID record contained in the Map-Reply message is non-zero, see <xref target="RFC9302" format="defa
Map-Reply. The ETR can allocate this number internally but ult" sectionFormat="of" derivedContent="RFC9302"/> for details.</dd>
MUST coordinate this value with other ETRs for the site. When <dt pn="section-5.4-5.19">EID-Prefix-AFI:</dt>
this value is 0, there is no versioning information <dd pn="section-5.4-5.20">This is the address family of the
conveyed. The Map-Version Number can be included in EID-Prefix according to <xref target="AFN" format="default" sectionForma
Map-Request and Map-Register messages. See Map-Versioning t="of" derivedContent="AFN"/> and <xref target="RFC8060" format="default" sectio
<xref target="I-D.ietf-lisp-6834bis" /> for more details.</t> nFormat="of" derivedContent="RFC8060"/>.</dd>
<dt pn="section-5.4-5.21">EID-Prefix:</dt>
<t hangText="EID-Prefix-AFI:"> Address family of the <dd pn="section-5.4-5.22"> This prefix is 4 octets for an IPv4
EID-Prefix according to <xref target="AFI" /> and <xref address family and 16 octets for an IPv6 address family.</dd>
target="RFC8060"/>.</t> <dt pn="section-5.4-5.23">Priority:</dt>
<dd pn="section-5.4-5.24"> Each RLOC is assigned a unicast
<t hangText="EID-Prefix:"> This prefix is 4 octets for an IPv4 Priority. Lower values are preferable. When multiple
address family and 16 octets for an IPv6 address family.</t>
<t hangText="Priority:"> Each RLOC is assigned a unicast
Priority. Lower values are more preferable. When multiple
RLOCs have the same Priority, they may be used in a load-split RLOCs have the same Priority, they may be used in a load-split
fashion. A value of 255 means the RLOC MUST NOT be used for fashion. A value of 255 means the RLOC <bcp14>MUST NOT</bcp14> be used
unicast forwarding.</t> for
unicast forwarding.</dd>
<t hangText="Weight:"> When priorities are the same for <dt pn="section-5.4-5.25">Weight:</dt>
<dd pn="section-5.4-5.26"> When priorities are the same for
multiple RLOCs, the Weight indicates how to balance unicast multiple RLOCs, the Weight indicates how to balance unicast
traffic between them. Weight is encoded as a relative weight traffic between them. Weight is encoded as a relative weight
of total unicast packets that match the mapping entry. For of total unicast packets that match the mapping entry. For
example, if there are 4 Locators in a Locator-Set, where the example, if there are 4 Locators in a Locator-Set, where the
Weights assigned are 30, 20, 20, and 10, the first Locator Weights assigned are 30, 20, 20, and 10, the first Locator
will get 37.5% of the traffic, the 2nd and 3rd Locators will will get 37.5% of the traffic, the second and third Locators will
each get 25% of the traffic, and the 4th Locator will get 12.5% of each get 25% of the traffic, and the fourth Locator will get 12.5% of
the traffic. If all Weights for a Locator-Set are equal, the the traffic. If all Weights for a Locator-Set are equal, the
receiver of the Map-Reply will decide how to load-split the receiver of the Map-Reply will decide how to load-split the
traffic. See RLOC-hashing <xref traffic. See Section <xref target="RFC9300" section="12" sectionFormat="
target="I-D.ietf-lisp-rfc6830bis" /> for a suggested hash bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9300#section-1
2" derivedContent="RFC9300">"Routing Locator Hashing"</xref> of <xref target="RF
C9300" format="default" sectionFormat="of" derivedContent="RFC9300"/> for a sugg
ested hash
algorithm to distribute the load across Locators with the same algorithm to distribute the load across Locators with the same
Priority and equal Weight values.</t> Priority and equal Weight values.</dd>
<dt pn="section-5.4-5.27">M Priority:</dt>
<t hangText="M Priority:"> Each RLOC is assigned a multicast <dd pn="section-5.4-5.28"> Each RLOC is assigned a multicast
Priority used by an ETR in a receiver multicast site to select Priority used by an ETR in a receiver multicast site to select
an ITR in a source multicast site for building multicast an ITR in a source multicast site for building multicast
distribution trees. A value of 255 means the RLOC MUST NOT be distribution trees. A value of 255 means the RLOC <bcp14>MUST NOT</bcp14 > be
used for joining a multicast distribution tree. For more used for joining a multicast distribution tree. For more
details, see <xref target="RFC6831" />.</t> details, see <xref target="RFC6831" format="default" sectionFormat="of"
derivedContent="RFC6831"/>.</dd>
<t hangText="M Weight:">When priorities are the same for <dt pn="section-5.4-5.29">M Weight:</dt>
<dd pn="section-5.4-5.30">When priorities are the same for
multiple RLOCs, the Weight indicates how to balance building multiple RLOCs, the Weight indicates how to balance building
multicast distribution trees across multiple ITRs. The Weight multicast distribution trees across multiple ITRs. The Weight
is encoded as a relative weight (similar to the unicast is encoded as a relative weight (similar to the unicast
Weights) of the total number of trees built to the source site Weights) of the total number of trees built to the source site
identified by the EID-Prefix. If all Weights for a Locator-Set identified by the EID-Prefix. If all Weights for a Locator-Set
are equal, the receiver of the Map-Reply will decide how to are equal, the receiver of the Map-Reply will decide how to
distribute multicast state across ITRs. For more details, see distribute multicast state across ITRs. For more details, see
<xref target="RFC6831" />.</t> <xref target="RFC6831" format="default" sectionFormat="of" derivedConten
t="RFC6831"/>.</dd>
<t hangText="Unused Flags:">These are set to 0 when sending <dt pn="section-5.4-5.31">Unused Flags:</dt>
and ignored on receipt.</t> <dd pn="section-5.4-5.32">These are set to 0 when sending
and ignored on receipt.</dd>
<t hangText="L:">When this bit is set, the Locator is flagged <dt pn="section-5.4-5.33">L:</dt>
<dd pn="section-5.4-5.34">When this bit is set, the Locator is flagged
as a local Locator to the ETR that is sending the Map-Reply. as a local Locator to the ETR that is sending the Map-Reply.
When a Map-Server is doing proxy Map-Replying for a LISP site, When a Map-Server is doing proxy Map-Replying for a LISP site,
the L-bit is set to 0 for all Locators in this the L-bit is set to 0 for all Locators in this
Locator-Set.</t> Locator-Set.</dd>
<dt pn="section-5.4-5.35">p:</dt>
<t hangText="p:">When this bit is set, an ETR informs the <dd pn="section-5.4-5.36">When this bit is set, an ETR informs the
RLOC-Probing ITR that the locator address for which this bit RLOC-Probing ITR that the Routing Locator Address for which this bit
is set is the one being RLOC-probed and may be different from is set is the one being RLOC-Probed and may be different from
the source address of the Map-Reply. An ITR that RLOC-probes a the source address of the Map-Reply. An ITR that RLOC-Probes a
particular Locator MUST use this Locator for retrieving the particular Locator <bcp14>MUST</bcp14> use this Locator for retrieving t
he
data structure used to store the fact that the Locator is data structure used to store the fact that the Locator is
reachable. The p-bit is set for a single Locator in the same reachable. The p-bit is set for a single Locator in the same
Locator-Set. If an implementation sets more than one p-bit Locator-Set. If an implementation sets more than one p-bit
erroneously, the receiver of the Map-Reply MUST select the erroneously, the receiver of the Map-Reply <bcp14>MUST</bcp14> select th
first set p-bit Locator. The p-bit MUST NOT be set for Locator-Set e
records sent in Map-Request and Map-Register messages.</t> first set p-bit Locator. The p-bit <bcp14>MUST NOT</bcp14> be set for Lo
cator-Set
<t hangText="R:">This is set when the sender of a Map-Reply records sent in Map-Request and Map-Register messages.</dd>
<dt pn="section-5.4-5.37">R:</dt>
<dd pn="section-5.4-5.38">This is set when the sender of a Map-Reply
has a route to the Locator in the Locator data record. This has a route to the Locator in the Locator data record. This
receiver may find this useful to know if the Locator is up but receiver may find this useful to know if the Locator is up but
not necessarily reachable from the receiver's point of not necessarily reachable from the receiver's point of
view.</t> view.</dd>
<dt pn="section-5.4-5.39">Locator:</dt>
<t hangText="Locator:">This is an IPv4 or IPv6 address (as <dd pn="section-5.4-5.40">This is an IPv4 or IPv6 address (as
encoded by the 'Loc-AFI' field) assigned to an ETR and used by encoded by the 'Loc-AFI' field) assigned to an ETR and used by
an ITR as a destination RLOC address in the outer header of a an ITR as a destination RLOC address in the outer header of a
LISP encapsulated packet. Note that the destination RLOC LISP encapsulated packet. Note that the destination RLOC
address of a LISP encapsulated packet MAY be an anycast address of a LISP encapsulated packet <bcp14>MAY</bcp14> be an anycast
address. A source RLOC of a LISP encapsulated packet can be an address. A source RLOC of a LISP encapsulated packet can be an
anycast address as well. The source or destination RLOC MUST anycast address as well. The source or destination RLOC <bcp14>MUST NOT
NOT be the broadcast address (255.255.255.255 or any subnet </bcp14> be the broadcast address (255.255.255.255 or any subnet
broadcast address known to the router) and MUST NOT be a broadcast address known to the router) and <bcp14>MUST NOT</bcp14> be a
link-local multicast address. The source RLOC MUST NOT be a link-local multicast address. The source RLOC <bcp14>MUST NOT</bcp14> b
multicast address. The destination RLOC SHOULD be a multicast e a
multicast address. The destination RLOC <bcp14>SHOULD</bcp14> be a multi
cast
address if it is being mapped from a multicast destination address if it is being mapped from a multicast destination
EID.</t> EID.</dd>
</list></t> </dl>
<t indent="0" pn="section-5.4-6">Map-Replies <bcp14>MUST</bcp14> be rate
<t>Map-Reply MUST be rate-limited, it is RECOMMENDED that a Map-Reply limited. It is <bcp14>RECOMMENDED</bcp14> that a Map-Reply
for the same destination RLOC be sent no more than one packets per 3 secon for the same destination RLOC be sent to no more than one packet every 3 s
ds.</t> econds.</t>
<t indent="0" pn="section-5.4-7">The Record format, as defined here, is
<t>The Record format, as defined here, is used both in the Map-Reply used both in the Map-Reply
and Map-Register messages, this includes all the field definitions. </t> and Map-Register messages; this includes all the field definitions. </t>
</section>
</section> <section anchor="MR" numbered="true" toc="include" removeInRFC="false" pn=
"section-5.5">
<section title="EID-to-RLOC UDP Map-Reply Message" anchor="MR"> <name slugifiedName="name-eid-to-rloc-udp-map-reply-m">EID-to-RLOC UDP M
<t>A Map-Reply returns an EID-Prefix with a mask-length that ap-Reply Message</name>
<t indent="0" pn="section-5.5-1">A Map-Reply returns an EID-Prefix with
a mask length that
is less than or equal to the EID being requested. The EID being is less than or equal to the EID being requested. The EID being
requested is either from the destination field of an IP header requested is either from the destination field of an IP header
of a Data-Probe or the EID of a record of a Map-Request. The RLOCs of a Data-Probe or the EID of a record of a Map-Request. The RLOCs
in the Map-Reply are routable IP addresses of all ETRs for the in the Map-Reply are routable IP addresses of all ETRs for the
LISP site. Each RLOC conveys status reachability but does not LISP site. Each RLOC conveys status reachability but does not
convey path reachability from a requester's convey path reachability from a requester's
perspective. Separate testing of path reachability is perspective. Separate testing of path reachability is
required. See RLOC-reachability <xref target="rloc-probe" /> for required. See "<xref target="rloc-probe" format="title" sectionFormat="of" derivedContent="RLOC-Probing Algorithm"/>" (<xref target="rloc-probe" format="d efault" sectionFormat="of" derivedContent="Section 7.1"/>) for
details.</t> details.</t>
<t indent="0" pn="section-5.5-2">Note that a Map-Reply <bcp14>MAY</bcp14
<t>Note that a Map-Reply MAY contain different EID-Prefix > contain different EID-Prefix
granularity (prefix + mask-length) than the Map-Request that triggers granularity (prefix + mask length) than the Map-Request that triggers
it. This might occur if a Map-Request were for a prefix that had it. This might occur if a Map-Request were for a prefix that had
been returned by an earlier Map-Reply. In such a case, the been returned by an earlier Map-Reply. In such a case, the
requester updates its cache with the new prefix information and requester updates its cache with the new prefix information and
granularity. For example, a requester with two cached granularity. For example, a requester with two cached
EID-Prefixes that are covered by a Map-Reply containing one EID-Prefixes that are covered by a Map-Reply containing one
less-specific prefix replaces the entry with the less-specific less-specific prefix replaces the entry with the less-specific
EID-Prefix. Note that the reverse, replacement of one EID-Prefix. Note that the reverse, replacement of one
less-specific prefix with multiple more-specific prefixes, can less-specific prefix with multiple more-specific prefixes, can
also occur, not by removing the less-specific prefix but rather also occur, not by removing the less-specific prefix but rather
by adding the more-specific prefixes that, during a lookup, will by adding the more-specific prefixes that, during a lookup, will
override the less-specific prefix.</t> override the less-specific prefix.</t>
<t indent="0" pn="section-5.5-3">When an EID moves out of a LISP site <x
<t>When an EID moves out of a LISP site <xref ref target="EID-MOBILITY" format="default" sectionFormat="of" derivedContent="EI
target="I-D.ietf-lisp-eid-mobility"/>, the database mapping system D-MOBILITY"/>, the database Mapping System
may have overlapping EID-prefixes. Or when a LISP site is may have overlapping EID-Prefixes. Or when a LISP site is
configured with multiple sets of ETRs that support different configured with multiple sets of ETRs that support different
EID-prefix mask-lengths, the database mapping system may have EID-Prefix mask lengths, the database Mapping System may have
overlapping EID-prefixes. When overlapping EID-prefixes exist, a overlapping EID-Prefixes. When overlapping EID-Prefixes exist, a
Map-Request with an EID that best matches any EID-Prefix MUST be Map-Request with an EID that best matches any EID-Prefix <bcp14>MUST</bcp1
4> be
returned in a single Map-Reply message. For instance, if an ETR returned in a single Map-Reply message. For instance, if an ETR
had database mapping entries for EID-Prefixes:</t> had database mapping entries for EID-Prefixes:</t>
<artwork name="" type="" align="left" alt="" pn="section-5.5-4">
<figure> <artwork><![CDATA[
2001:db8::/32 2001:db8::/32
2001:db8:1::/48 2001:db8:1::/48
2001:db8:1:1::/64 2001:db8:1:1::/64
2001:db8:1:2::/64 2001:db8:1:2::/64
]]></artwork></figure> </artwork>
<t indent="0" pn="section-5.5-5">A Map-Request for EID 2001:db8:1:1::1 w
<t>A Map-Request for EID 2001:db8:1:1::1 would cause a Map-Reply ould cause a Map-Reply
with a record count of 1 to be returned with a mapping record with a record count of 1 to be returned with a mapping record
EID-Prefix of 2001:db8:1:1::/64.</t> EID-Prefix of 2001:db8:1:1::/64.</t>
<t indent="0" pn="section-5.5-6">A Map-Request for EID 2001:db8:1:5::5 w
<t>A Map-Request for EID 2001:db8:1:5::5 would cause a Map-Reply ould cause a Map-Reply
with a record count of 3 to be returned with mapping records for with a record count of 3 to be returned with mapping records for
EID-Prefixes 2001:db8:1::/48, 2001:db8:1:1::/64, EID-Prefixes 2001:db8:1::/48, 2001:db8:1:1::/64, and
2001:db8:1:2::/64, filling out the /48 with more-specifics 2001:db8:1:2::/64, filling out the /48 with more-specific prefixes
that exist in the mapping system.</t> that exist in the Mapping System.</t>
<t indent="0" pn="section-5.5-7">Note that not all overlapping EID-Prefi
<t>Note that not all overlapping EID-Prefixes need to be xes need to be
returned but only the more-specific entries (note that in the returned but only the more-specific entries (note in the
second example above 2001:db8::/32 was not returned for requesting second example above that 2001:db8::/32 was not returned for requesting
EID 2001:db8:1:5::5) for the matching EID-Prefix of the requesting EID 2001:db8:1:5::5) for the matching EID-Prefix of the requesting
EID. When more than one EID-Prefix is returned, all SHOULD use EID. When more than one EID-Prefix is returned, all <bcp14>SHOULD</bcp14>
the same Time to Live value so they can all time out at the same use
the same TTL value so they can all time out at the same
time. When a more-specific EID-Prefix is received later, its time. When a more-specific EID-Prefix is received later, its
Time to Live value in the Map-Reply record can be stored even TTL value in the Map-Reply record can be stored even
when other less-specific entries exist. When a less-specific when other less-specific entries exist. When a less-specific
EID-Prefix is received later, its Map-Cache expiration time EID-Prefix is received later, its Map-Cache expiration time
SHOULD be set to the minimum expiration time of any <bcp14>SHOULD</bcp14> be set to the minimum expiration time of any
more-specific EID-Prefix in the Map-Cache. This is done so the more-specific EID-Prefix in the Map-Cache. This is done so the
integrity of the EID-Prefix set is wholly maintained and so no integrity of the EID-Prefix set is wholly maintained and so no
more-specific entries are removed from the Map-Cache while more-specific entries are removed from the Map-Cache while
keeping less-specific entries.</t> keeping less-specific entries.</t>
<t indent="0" pn="section-5.5-8">For scalability, it is expected that ag
<t>For scalability, it is expected that aggregation of EID addresses gregation of EID addresses
into EID-Prefixes will allow one Map-Reply to satisfy a mapping into EID-Prefixes will allow one Map-Reply to satisfy a mapping
for the EID addresses in the prefix range, thereby reducing the for the EID addresses in the prefix range, thereby reducing the
number of Map-Request messages.</t> number of Map-Request messages.</t>
<t indent="0" pn="section-5.5-9">Map-Reply records can have an empty Loc
<t>Map-Reply records can have an empty Locator-Set. A Negative ator-Set. A Negative
Map-Reply is a Map-Reply with an empty Locator-Set. Negative Map-Reply is a Map-Reply with an empty Locator-Set. Negative
Map-Replies convey special actions by the sender to the ITR or Map-Replies convey special actions by the Map-Reply sender to the ITR or
PITR that have solicited the Map-Reply. There are two primary PITR that have solicited the Map-Reply. There are two primary
applications for Negative Map-Replies. The first is for a applications for Negative Map-Replies. The first is for a
Map-Resolver to instruct an ITR or PITR when a destination is Map-Resolver to instruct an ITR or PITR when a destination is
for a LISP site versus a non-LISP site, and the other is to for a LISP site versus a non-LISP site, and the other is to
source quench Map-Requests that are sent for non-allocated source quench Map-Requests that are sent for non-allocated
EIDs.</t> EIDs.</t>
<t indent="0" pn="section-5.5-10">For each Map-Reply record, the list of
<t>For each Map-Reply record, the list of Locators in a Locators in a
Locator-Set MUST be sorted Locator-Set <bcp14>MUST</bcp14> be sorted
in order of ascending IP address where an IPv4 locator address in order of ascending IP address where an IPv4 Routing Locator
is considered numerically 'less than' an IPv6 locator Address is considered numerically "less than" an IPv6 Routing
address.</t> Locator Address.</t>
<t indent="0" pn="section-5.5-11">When sending a Map-Reply message, the
<t>When sending a Map-Reply message, the destination address is destination address is
copied from one of the 'ITR-RLOC' fields from the copied from one of the 'ITR-RLOC' fields from the
Map-Request. The ETR can choose a locator address from one of Map-Request. The ETR can choose a Routing Locator Address from one of
the address families it supports. For Data-Probes, the the address families it supports. For Data-Probes, the
destination address of the Map-Reply is copied from the source destination address of the Map-Reply is copied from the source
address of the Data-Probe message that is invoking the address of the Data-Probe message that is invoking the
reply. The source address of the Map-Reply is one of the local reply. The source address of the Map-Reply is one of the chosen local
IP addresses chosen, to allow Unicast Reverse Path Forwarding IP addresses; this allows Unicast Reverse Path Forwarding
(uRPF) checks to succeed in the upstream service provider. The (uRPF) checks to succeed in the upstream service provider. The
destination port of a Map-Reply message is copied from the destination port of a Map-Reply message is copied from the
source port of the Map-Request or Data-Probe, and the source source port of the Map-Request or Data-Probe, and the source
port of the Map-Reply message is set to the well-known UDP port port of the Map-Reply message is set to the well-known UDP port
4342.</t> 4342.</t>
</section>
<t><vspace blankLines='50' /></t> <section anchor="MAPREG" numbered="true" toc="include" removeInRFC="false"
</section> pn="section-5.6">
<name slugifiedName="name-map-register-message-format">Map-Register Mess
<section title="Map-Register Message Format" anchor="MAPREG"> age Format</name>
<t>This section specifies the encoding format for the <t indent="0" pn="section-5.6-1">This section specifies the encoding for
mat for the
Map-Register message. The message is sent in UDP with a Map-Register message. The message is sent in UDP with a
destination UDP port of 4342 and a randomly selected UDP source destination UDP port of 4342 and a randomly selected UDP source
port number.</t> port number.</t>
<t indent="0" pn="section-5.6-2">The fields below are used in multiple c
<t>The fields below are used in multiple control messages. They ontrol messages. They
are defined for Map-Register, Map-Notify and Map-Notify-Ack message are defined for Map-Register, Map-Notify, and Map-Notify-Ack message
types.</t> types.</t>
<t indent="0" pn="section-5.6-3">The Map-Register message format is:</t>
<t>The Map-Register message format is:</t> <artwork name="" type="" align="left" alt="" pn="section-5.6-4">
<figure> <artwork><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=3 |P|S|I| Reserved |E|T|a|R|M| Record Count | |Type=3 |P|S|I| Reserved |E|T|a|R|M| Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . | | Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce | | . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID | Algorithm ID | Authentication Data Length | | Key ID | Algorithm ID | Authentication Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Authentication Data ~ ~ Authentication Data ~
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-&gt; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL | | | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R | Locator Count | EID mask-len | ACT |A| Reserved | R | Locator Count | EID mask-len | ACT |A| Reserved |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c | Rsvd | Map-Version Number | EID-Prefix-AFI | c | Rsvd | Map-Version Number | EID-Prefix-AFI |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | EID-Prefix | r | EID-Prefix |
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight | | /| Priority | Weight | M Priority | M Weight |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o | Unused Flags |L|p|R| Loc-AFI | | o | Unused Flags |L|p|R| Loc-AFI |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator | | \| Locator |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-&gt; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> </figure> </artwork>
<t indent="0" pn="section-5.6-5">Packet field descriptions:</t>
<t>Packet field descriptions:</t> <dl newline="false" spacing="normal" indent="3" pn="section-5.6-6">
<dt pn="section-5.6-6.1">Type: </dt>
<t><list style="hanging"> <dd pn="section-5.6-6.2">3 (Map-Register)</dd>
<t hangText="Type: ">3 (Map-Register)</t> <dt pn="section-5.6-6.3">P:</dt>
<dd pn="section-5.6-6.4">This is the proxy Map-Reply bit. When set to
<t hangText="P:">This is the proxy Map-Reply bit. When set to
1, the ETR sending the Map-Register message is requesting the 1, the ETR sending the Map-Register message is requesting the
Map-Server to proxy a Map-Reply. The Map-Server will send Map-Server to proxy a Map-Reply. The Map-Server will send
non-authoritative Map-Replies on behalf of the ETR.</t> non-authoritative Map-Replies on behalf of the ETR.</dd>
<dt pn="section-5.6-6.5">S:</dt>
<t hangText="S:">This is the security-capable bit. When set, <dd pn="section-5.6-6.6">This is the security-capable bit. When set,
the procedures from <xref target="I-D.ietf-lisp-sec"/> are the procedures from <xref target="RFC9303" format="default" sectionForma
supported.</t> t="of" derivedContent="RFC9303"/> are
supported.</dd>
<t hangText="I:">This is the ID-present bit. This bit is set to 1 to ind <dt pn="section-5.6-6.7">I:</dt>
icate that a 128 <dd pn="section-5.6-6.8">This is the ID-present bit. This bit is set t
bit xTR-ID and a 64 bit Site-ID fields are present at the end o 1 to indicate that a
128-bit 'xTR-ID' field and a 64-bit 'Site-ID' field are present at the
end
of the Map-Register message. If an xTR is configured with an of the Map-Register message. If an xTR is configured with an
xTR-ID and Site-ID, it MUST set the I bit to 1 and include its xTR-ID and Site-ID, it <bcp14>MUST</bcp14> set the I-bit to 1 and includ e its
xTR-ID and Site-ID in the Map-Register messages it generates. xTR-ID and Site-ID in the Map-Register messages it generates.
The combination of Site-ID plus xTR-ID uniquely identifies an The combination of Site-ID plus xTR-ID uniquely identifies an
xTR in a LISP domain and serves to track its last seen xTR in a LISP domain and serves to track its last seen
nonce.</t> nonce.</dd>
<dt pn="section-5.6-6.9">Reserved:</dt>
<t hangText="Reserved:">This unassigned field MUST be set to 0 on <dd pn="section-5.6-6.10">This unassigned field <bcp14>MUST</bcp14> be
transmit and MUST be ignored on receipt.</t> set to 0 on
transmit and <bcp14>MUST</bcp14> be ignored on receipt.</dd>
<t hangText="E:">This is the Map-Register EID-notify bit. This <dt pn="section-5.6-6.11">E:</dt>
is used by a First-Hop-Router (FHR) which discovers a <dd pn="section-5.6-6.12">This is the Map-Register EID-notify bit. Thi
dynamic-EID. This EID-notify based Map-Register is sent by the s
FHR to a same site xTR that propogates the Map-Register to is used by a First-Hop Router that discovers a
the mapping system. The site xTR keeps state to later dynamic EID. This EID-notify-based Map-Register is sent by the
Map-Notify the FHR after the EID has moves away. See <xref First-Hop Router to a same site xTR that propagates the Map-Register to
target="I-D.ietf-lisp-eid-mobility"/> for a detailed the Mapping System. The site xTR keeps state to later
use-case.</t> Map-Notify the First-Hop Router after the EID has moved away. See <xref
target="EID-MOBILITY" format="default" sectionFormat="of" derivedContent="EID-MO
<t hangText="T:">This is the use-TTL for timeout bit. When set BILITY"/> for a detailed
use case.</dd>
<dt pn="section-5.6-6.13">T:</dt>
<dd pn="section-5.6-6.14">This is the use TTL for timeout bit. When se
t
to 1, the xTR wants the Map-Server to time out registrations to 1, the xTR wants the Map-Server to time out registrations
based on the value in the "Record TTL" field of this based on the value in the 'Record TTL' field of this
message. Otherwise, the default timeout described in <xref message. Otherwise, the default timeout described in <xref target="reg"
target="reg"/> is used.</t> format="default" sectionFormat="of" derivedContent="Section 8.2"/> is used.</dd>
<dt pn="section-5.6-6.15">a:</dt>
<t hangText="a:">This is the merge-request bit. When set to 1, <dd pn="section-5.6-6.16">This is the merge-request bit. When set to 1
the xTR requests to merge RLOC-records from different xTRs ,
registering the same EID-record. See signal-free multicast the xTR requests to merge RLOC-Records from different xTRs
<xref target="RFC8378"/> for one registering the same EID-Record. See Signal-Free Multicast
use case example.</t> <xref target="RFC8378" format="default" sectionFormat="of" derivedConten
t="RFC8378"/> for one
<t hangText="R:">This reserved and unassigned bit MUST be set to 0 on use-case example.</dd>
transmit and MUST be ignored on receipt.</t> <dt pn="section-5.6-6.17">R:</dt>
<dd pn="section-5.6-6.18">This reserved and unassigned bit <bcp14>MUST
<t hangText="M:">This is the want-map-notify bit. When set to </bcp14> be set to 0 on
transmit and <bcp14>MUST</bcp14> be ignored on receipt.</dd>
<dt pn="section-5.6-6.19">M:</dt>
<dd pn="section-5.6-6.20">This is the want-map-notify bit. When set to
1, an ETR is requesting a Map-Notify message to be returned in 1, an ETR is requesting a Map-Notify message to be returned in
response to sending a Map-Register message. The Map-Notify response to sending a Map-Register message. The Map-Notify
message sent by a Map-Server is used to acknowledge receipt of message sent by a Map-Server is used to acknowledge receipt of
a Map-Register message.</t> a Map-Register message.</dd>
<dt pn="section-5.6-6.21">Record Count:</dt>
<t hangText="Record Count:"> This is the number of records in <dd pn="section-5.6-6.22"> This is the number of records in
this Map-Register message. A record is comprised of that this Map-Register message. A record is comprised of that
portion of the packet labeled 'Record' above and occurs the portion of the packet labeled 'Record' above and occurs the
number of times equal to Record Count.</t> number of times equal to Record Count.</dd>
<dt pn="section-5.6-6.23">Nonce:</dt>
<t hangText="Nonce:"> This 8-octet 'Nonce' field is <dd pn="section-5.6-6.24"> This 8-octet 'Nonce' field is
incremented each time a Map-Register message is sent. When a incremented each time a Map-Register message is sent. When a
Map-Register acknowledgement is requested, the nonce is Map-Register acknowledgment is requested, the nonce is
returned by Map-Servers in Map-Notify messages. Since the returned by Map-Servers in Map-Notify messages. Since the
entire Map-Register message is authenticated, the 'Nonce' entire Map-Register message is authenticated, the 'Nonce'
field serves to protect against Map-Register replay field serves to protect against Map-Register replay
attacks. An ETR that registers to the mapping system SHOULD attacks. An ETR that registers to the Mapping System <bcp14>SHOULD</bcp1
store the last nonce sent in persistent storage so when it 4>
restarts it can continue using an incrementing nonce. If store the last nonce sent in persistent storage, so when it
the ETR cannot support saving the nonce, then when it restarts restarts, it can continue using an incrementing nonce. If
it MUST use a new authentication key to register to the the ETR cannot support saving the nonce, then when it restarts,
mapping system. A Map-Server MUST track and save in persistent it <bcp14>MUST</bcp14> use a new authentication key to register to the
Mapping System. A Map-Server <bcp14>MUST</bcp14> track and save in persi
stent
storage the last nonce received for each ETR xTR-ID and key pair. storage the last nonce received for each ETR xTR-ID and key pair.
If a Map-Register is received with a nonce If a Map-Register is received with a nonce
value that is not greater than the saved nonce, it MUST drop the value that is not greater than the saved nonce, it <bcp14>MUST</bcp14> d
Map-Register message and SHOULD log the fact a replay attack could rop the
have occurred.</t> Map-Register message and <bcp14>SHOULD</bcp14> log the fact that a repla
y attack could
<t hangText="Key ID:"> A key-id value that identifies a have occurred.</dd>
<dt pn="section-5.6-6.25">Key ID:</dt>
<dd pn="section-5.6-6.26">This is a key-id value that identifies a
pre-shared secret between an ETR and a Map-Server. Per-message pre-shared secret between an ETR and a Map-Server. Per-message
keys are derived from the pre-shared secret to authenticate keys are derived from the pre-shared secret to authenticate
the origin and protect the integrity of the Map-Register. the origin and protect the integrity of the Map-Register.
The Key ID allows to rotate between multiple pre-shared The Key ID allows rotating between multiple pre-shared
secrets in a non disruptive way. The pre-shared secret MUST secrets in a nondisruptive way. The pre-shared secret <bcp14>MUST
be unique per each LISP "Site-ID" </t> </bcp14>
be unique per each LISP Site-ID.</dd>
<t hangText="Algorithm ID:"> This field identifies the Key <dt pn="section-5.6-6.27">Algorithm ID:</dt>
<dd pn="section-5.6-6.28"> This field identifies the Key
Derivation Function (KDF) and Message Authentication Code (MAC) Derivation Function (KDF) and Message Authentication Code (MAC)
algorithms used to derive the key and to compute the Authenticati on algorithms used to derive the key and to compute the Authenticati on
Data of a Map-Register. This 8-bit field identifies the KDF and Data of a Map-Register. This 8-bit field identifies the KDF and
MAC algorithm pair. See <xref target="KEYS" /> for codepoint ass MAC algorithm pair. See <xref target="KEYS" format="default" sec
ignments.</t> tionFormat="of" derivedContent="Section 12.5"/> for codepoint assignments.</dd>
<dt pn="section-5.6-6.29">Authentication Data Length:</dt>
<t hangText="Authentication Data Length:"> This is the length <dd pn="section-5.6-6.30"> This is the length
in octets of the 'Authentication Data' field that follows this in octets of the 'Authentication Data' field that follows this
field. The length of the 'Authentication Data' field is field. The length of the 'Authentication Data' field is
dependent on the MAC algorithm used. The length field allows a dependent on the MAC algorithm used. The length field allows a
device that doesn't know the MAC algorithm to correctly parse device that doesn't know the MAC algorithm to correctly parse
the packet.</t> the packet.</dd>
<dt pn="section-5.6-6.31">Authentication Data:</dt>
<t hangText="Authentication Data:">This is the output of the <dd pn="section-5.6-6.32">
<t indent="0" pn="section-5.6-6.32.1">This is the output of the
MAC algorithm placed in this field after the MAC computation. MAC algorithm placed in this field after the MAC computation.
The MAC output is computed as follows:</t> The MAC output is computed as follows:</t>
<ol spacing="normal" type="1" indent="adaptive" start="1" pn="sectio
<t><list style="hanging" hangIndent="4"> n-5.6-6.32.2">
<t hangText="1:">The KDF algorithm is identified by the <li pn="section-5.6-6.32.2.1" derivedCounter="1.">The KDF algorith
field 'Algorithm ID' according to the table in <xref target="KE m is identified by the
YS"/>. 'Algorithm ID' field according to the table in <xref target="KE
Implementations of this specification MUST implement HMAC-SHA-2 YS" format="default" sectionFormat="of" derivedContent="Section 12.5"/>. Impleme
56-128 <xref target="RFC4868"/> and SHOULD implement ntations of this specification <bcp14>MUST</bcp14> implement HMAC-SHA-256-128 <x
HMAC-SHA-256-128+HKDF-SHA256 <xref target="RFC5869"/> ref target="RFC4868" format="default" sectionFormat="of" derivedContent="RFC4868
.</t> "/> and <bcp14>SHOULD</bcp14> implement HMAC-SHA-256-128+HKDF-SHA256 <xref targe
<t hangText="2:">The MAC algorithm is identified by the field ' t="RFC5869" format="default" sectionFormat="of" derivedContent="RFC5869"/>.</li>
Algorithm ID' <li pn="section-5.6-6.32.2.2" derivedCounter="2.">The MAC algorith
according to the table in <xref target="KEYS" />.</t> m is identified by the 'Algorithm ID' field
<t hangText="3:">The pre-shared secret used to derive the per-messa according to the table in <xref target="KEYS" format="default"
ge key is represented by PSK[Key ID], sectionFormat="of" derivedContent="Section 12.5"/>.</li>
that is the pre-shared secret identified by the 'Key ID'.</t> <li pn="section-5.6-6.32.2.3" derivedCounter="3.">The pre-shared s
<t hangText="4:">The derived per-message key is computed as: per-ms ecret used to derive the per-message key is represented by PSK[Key ID], that is,
g-key=KDF(nonce+PSK[Key ID],s). the pre-shared secret identified by the Key ID.</li>
Where the nonce is the value in the Nonce field of the Map-Regi <li pn="section-5.6-6.32.2.4" derivedCounter="4.">The derived per-
ster, '+' denotes concatenation and 's' (the salt) message key is computed as: per-msg-key=KDF(nonce+PSK[Key ID],s). Where the nonc
e is the value in the 'Nonce' field of the Map-Register, "+" denotes concatenati
on and "s" (the salt)
is a string that is a string that
corresponds to the message type being authenticated. For corresponds to the message type being authenticated. For
Map-Register messages, it is equal to "Map-Register Map-Register messages, it is equal to "Map-Register
Authentication". Similarly, for Map-Notify and Map-Notify-Ack Authentication". Similarly, for Map-Notify and Map-Notify-Ack
messages, it is "Map-Notify Authentication" and messages, it is "Map-Notify Authentication" and
"Map-Notify-Ack Authentication", respectively. For those Algorithm IDs d "Map-Notify-Ack Authentication", respectively. For those Algorithm IDs d
efined in <xref target="KEYS"/> that specify a 'none' KDF, the per-message key i efined in <xref target="KEYS" format="default" sectionFormat="of" derivedContent
s computed as: per-msg-key = PSK[Key ID]. This means that the same key is used a ="Section 12.5"/> that specify a 'none' KDF, the per-message key is computed as:
cross multiple protocol messages.</t> per-msg-key = PSK[Key ID]. This means that the same key is used across multiple
<t hangText="5:">The MAC output is computed using the MAC algor protocol messages.</li>
ithm and <li pn="section-5.6-6.32.2.5" derivedCounter="5.">The MAC output i
s computed using the MAC algorithm and
the per-msg-key over the entire Map-Register payload the per-msg-key over the entire Map-Register payload
(from and including the LISP message type field through the (from and including the LISP message type field through the
end of the last RLOC record) with the authenticated data field end of the last RLOC-Record) with the authenticated data field
preset to 0.</t> preset to 0.</li>
</list></t> </ol>
</dd>
</list></t> </dl>
<t indent="0" pn="section-5.6-7">The definition of the rest of the Map-R
<t>The definition of the rest of the Map-Register can be found egister can be found
in EID-record description in <xref target="MR-FORMAT"/>. When in the EID-Record description in <xref target="MR-FORMAT" format="default"
sectionFormat="of" derivedContent="Section 5.4"/>. When
the I-bit is set, the following fields are added to the end of the I-bit is set, the following fields are added to the end of
the Map-Register message:</t> the Map-Register message:</t>
<dl newline="false" spacing="normal" indent="3" pn="section-5.6-8">
<t><list style="hanging"> <dt pn="section-5.6-8.1">xTR-ID:</dt>
<t hangText="xTR-ID:">xTR-ID is a 128 bit field at the end of <dd pn="section-5.6-8.2">'xTR-ID' is a 128-bit field at the end of
the Map-Register message, starting after the final Record in the Map-Register message, starting after the final Record in
the message. The xTR-ID is used to uniquely identify a xTR. the message. The xTR-ID is used to uniquely identify an xTR.
The same xTR-ID value MUST NOT be used in two different xTRs in the scop The same xTR-ID value <bcp14>MUST NOT</bcp14> be used in two different x
e of the Site-ID.</t> TRs in the scope of the Site-ID.</dd>
<dt pn="section-5.6-8.3">Site-ID:</dt>
<t hangText="Site-ID:">Site-ID is a 64 bit field at the end of <dd pn="section-5.6-8.4">'Site-ID' is a 64-bit field at the end of
the Map- Register message, following the xTR-ID. Site-ID is the Map-Register message, following the xTR-ID. The Site-ID is
used to uniquely identify to which site the xTR that sent the used to uniquely identify to which site the xTR that sent the
message belongs. This document does not specify a strict meaning for the message belongs. This document does not specify a strict meaning for the
Site-ID field. 'Site-ID' field.
Informally it provides an indication that a group of xTRs have some rela Informally, it provides an indication that a group of xTRs have some rel
tion, either administratively, topologically or otherwise.</t> ationship, either administratively, topologically, or otherwise.</dd>
</list></t> </dl>
</section>
<t><vspace blankLines='50' /></t> <section anchor="MAP-NOTIF-MAP-NOTIF-ACK" numbered="true" toc="include" re
</section> moveInRFC="false" pn="section-5.7">
<name slugifiedName="name-map-notify-and-map-notify-a">Map-Notify and Ma
<section title="Map-Notify/Map-Notify-Ack Message Format"> p-Notify-Ack Message Formats</name>
<t>This section specifies the encoding format for the Map-Notify <t indent="0" pn="section-5.7-1">This section specifies the encoding for
mat for the Map-Notify
and Map-Notify-Ack messages. The messages are sent inside a UDP and Map-Notify-Ack messages. The messages are sent inside a UDP
packet with source and destination UDP ports equal to 4342.</t> packet with source and destination UDP ports equal to 4342.</t>
<t indent="0" pn="section-5.7-2">The Map-Notify and Map-Notify-Ack messa
<t>The Map-Notify and Map-Notify-Ack message formats are:</t> ge formats are:</t>
<artwork name="" type="" align="left" alt="" pn="section-5.7-3">
<figure> <artwork><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=4/5| Reserved | Record Count | |Type=4/5| Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . | | Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce | | . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID | Algorithm ID | Authentication Data Length | | Key ID | Algorithm ID | Authentication Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Authentication Data ~ ~ Authentication Data ~
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-&gt; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL | | | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R | Locator Count | EID mask-len | ACT |A| Reserved | R | Locator Count | EID mask-len | ACT |A| Reserved |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c | Rsvd | Map-Version Number | EID-Prefix-AFI | c | Rsvd | Map-Version Number | EID-Prefix-AFI |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | EID-Prefix | r | EID-Prefix |
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight | | /| Priority | Weight | M Priority | M Weight |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o | Unused Flags |L|p|R| Loc-AFI | | o | Unused Flags |L|p|R| Loc-AFI |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator | | \| Locator |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-&gt; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> </figure> </artwork>
<t indent="0" pn="section-5.7-4">Packet field descriptions:</t>
<t>Packet field descriptions:</t> <dl newline="false" spacing="normal" indent="3" pn="section-5.7-5">
<t><list style="hanging"> <dt pn="section-5.7-5.1">Type: </dt>
<t hangText="Type: ">4/5 (Map-Notify/Map-Notify-Ack)</t> <dd pn="section-5.7-5.2">4/5 (Map-Notify/Map-Notify-Ack)</dd>
</list></t> </dl>
<t indent="0" pn="section-5.7-6">The Map-Notify message has the same con
<t>The Map-Notify message has the same contents as a tents as a
Map-Register message. See the Map-Register section for field Map-Register message. See "<xref target="MAPREG" format="title" sectionFor
descriptions and the Map-Reply section for EID-record and mat="of" derivedContent="Map-Register Message Format"/>" (<xref target="MAPREG"
RLOC-record descriptions.</t> format="default" sectionFormat="of" derivedContent="Section 5.6"/>) for field de
scriptions and
<t>The fields of the Map-Notify are copied from the "<xref target="MR-FORMAT" format="title" sectionFormat="of" derivedContent="Map-
Reply Message Format"/>" (<xref target="MR-FORMAT" format="default" sectionForma
t="of" derivedContent="Section 5.4"/>) for EID-Record and RLOC-Record descriptio
ns.</t>
<t indent="0" pn="section-5.7-7">The fields of the Map-Notify are copied
from the
corresponding Map-Register to acknowledge its correct corresponding Map-Register to acknowledge its correct
processing. In the Map-Notfiy, the 'Authentication Data' processing. In the Map-Notify, the 'Authentication Data'
field is recomputed using the corresponding per-message key and according to the procedure defined field is recomputed using the corresponding per-message key and according to the procedure defined
in the previous section. The Map-Notify message can also used, outside the in the previous section. The Map-Notify message can also be used in an uns
scope of this olicited manner. This topic is out of scope for this document. See <xref target
specification, in an unsolicited manner, such as is specified in <xref target="I ="I-D.ietf-lisp-pubsub" format="default" sectionFormat="of" derivedContent="LISP
-D.ietf-lisp-pubsub"/>.</t> -PUBSUB"/> for details.</t>
<t indent="0" pn="section-5.7-8">After sending a Map-Register, if a Map-
<t>After sending a Map-Register, if a Map-Notify is not Notify is not
received after 1 second the transmitter MUST re-transmit received after 1 second, the transmitter <bcp14>MUST</bcp14> retransmit
the original Map-Register with an exponential backoff (base of 2, that the original Map-Register with an exponential backoff (base of 2, that
is, the next backoff timeout interval is doubled), is, the next backoff timeout interval is doubled);
the maximum backoff is 1 minute. Map-Notify messages are only transmitt the maximum backoff is 1 minute. Map-Notify messages are only transmitt
ed upon the reception of a Map-Register with the M-bit set, Map-Notify messages ed upon the reception of a Map-Register with the M-bit set; Map-Notify messages
are not retransmitted. The only exeption to this is for unsolicited Map-Notify m are not retransmitted. The only exception to this is for unsolicited Map-Notify
essages, see below.</t> messages; see below.</t>
<t indent="0" pn="section-5.7-9">A Map-Server sends an unsolicited Map-N
<t>A Map-Server sends an unsolicited Map-Notify message (one otify message (one
that is not used as an acknowledgment to a Map-Register message) that is not used as an acknowledgment to a Map-Register message)
only in conformance with the Congestion Control And Relability Guideline only in conformance with Section <xref target="RFC8085" section="3.1" sect
sections of <xref target="RFC8085"/>. A Map-Notify is ionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc808
5#section-3.1" derivedContent="RFC8085">"Congestion Control Guidelines"</xref> o
f <xref target="RFC8085" format="default" sectionFormat="of" derivedContent="RFC
8085"/> and Section <xref target="RFC8085" section="3.3" sectionFormat="bare" fo
rmat="default" derivedLink="https://rfc-editor.org/rfc/rfc8085#section-3.3" deri
vedContent="RFC8085">"Reliability Guidelines"</xref> of <xref target="RFC8085" f
ormat="default" sectionFormat="of" derivedContent="RFC8085"/>. A Map-Notify is
retransmitted until a Map-Notify-Ack is received by the retransmitted until a Map-Notify-Ack is received by the
Map-Server with the same nonce used in the Map-Notify message. Map-Server with the same nonce used in the Map-Notify message.
An implementation SHOULD retransmit up to An implementation <bcp14>SHOULD</bcp14> retransmit up to
3 times at 3 second retransmission intervals, after which time 3 times at 3-second retransmission intervals, after which time
the retransmission interval is exponentially backed-off (base of 2, that i the retransmission interval is exponentially backed off (base of 2, that i
s, the next backoff timeout interval is doubled) for s, the next backoff timeout interval is doubled) for
another 3 retransmission attempts. Map-Notify-Ack messages are only transm another 3 retransmission attempts. Map-Notify-Ack messages are only transm
itted upon the reception of an unsolicited Map-Notify, Map-Notify-Ack messages a itted upon the reception of an unsolicited Map-Notify; Map-Notify-Ack messages a
re not retransmitted.</t> re not retransmitted.</t>
<t indent="0" pn="section-5.7-10">The Map-Notify-Ack message has the sam
<t>The Map-Notify-Ack message has the same contents as a e contents as a
Map-Notify message. It is used to acknowledge the receipt of an unsolicit ed Map-Notify message. It is used to acknowledge the receipt of an unsolicit ed
Map-Notify and, once the the authentication data is validated, allows for Map-Notify and, once the Authentication Data is validated, allows
the sender to stop the sender to stop retransmitting a Map-Notify with the same nonce
retransmitting a Map-Notify with the same nonce and the authentication dat and (validated) Authentication Data. The fields of
a validates. The fields of
the Map-Notify-Ack are copied from the corresponding Map-Notify the Map-Notify-Ack are copied from the corresponding Map-Notify
message to acknowledge its correct processing. The 'Authentication Data' message to acknowledge its correct processing. The 'Authentication Data'
field is recomputed using the corresponding per-message key and according to the procedure defined field is recomputed using the corresponding per-message key and according to the procedure defined
in the previous section.</t> in the previous section.</t>
<t indent="0" pn="section-5.7-11">Upon reception of a Map-Register, Map-
<t>Upon reception of Map-Register, Map-Notify or Map-Notifiy-Ack, the rece Notify, or Map-Notify-Ack, the receiver verifies
iver verifies the Authentication Data. If the Authentication Data fails to validate, t
the authentication data. If the authentication data fails to validate, t he
he
message is dropped without further processing.</t> message is dropped without further processing.</t>
</section>
<t><vspace blankLines='50' /></t> <section anchor="encap-mr" numbered="true" toc="include" removeInRFC="fals
</section> e" pn="section-5.8">
<name slugifiedName="name-encapsulated-control-messag">Encapsulated Cont
<section title="Encapsulated Control Message Format" anchor="encap-mr"> rol Message Format</name>
<t>An Encapsulated Control Message (ECM) is used to encapsulate <t indent="0" pn="section-5.8-1">An Encapsulated Control Message (ECM) i
s used to encapsulate
control packets sent between xTRs and the mapping database system or inter nal to the mapping control packets sent between xTRs and the mapping database system or inter nal to the mapping
database system.</t> database system.</t>
<artwork name="" type="" align="left" alt="" pn="section-5.8-2">
<figure> <artwork><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | IPv4 or IPv6 Header | / | IPv4 or IPv6 Header |
OH | (uses RLOC addresses) | OH | (uses RLOC addresses) |
\ | | \ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = 4342 | / | Source Port = xxxx | Dest Port = 4342 |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum | \ | UDP Length | UDP Checksum |
skipping to change at line 1278 skipping to change at line 1412
/ | IPv4 or IPv6 Header | / | IPv4 or IPv6 Header |
IH | (uses RLOC or EID addresses) | IH | (uses RLOC or EID addresses) |
\ | | \ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = yyyy | / | Source Port = xxxx | Dest Port = yyyy |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum | \ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LCM | LISP Control Message | LCM | LISP Control Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> </figure> </artwork>
<t indent="0" pn="section-5.8-3">Packet header descriptions:</t>
<t>Packet header descriptions:</t> <dl newline="false" spacing="normal" indent="6" pn="section-5.8-4">
<dt pn="section-5.8-4.1">OH:</dt>
<t><list style="hanging" hangIndent="6"> <dd pn="section-5.8-4.2">This is the outer IPv4 or IPv6 header, which
<t hangText="OH:">The outer IPv4 or IPv6 header, which uses uses
RLOC addresses in the source and destination header address RLOC addresses in the source and destination header address
fields.</t> fields.</dd>
<dt pn="section-5.8-4.3">UDP:</dt>
<t hangText="UDP:">The outer UDP header with destination port <dd pn="section-5.8-4.4">This is the outer UDP header with destination
port
4342. The source port is randomly allocated. The checksum 4342. The source port is randomly allocated. The checksum
field MUST be non-zero.</t> field <bcp14>MUST</bcp14> be non-zero.</dd>
<dt pn="section-5.8-4.5">LISP:</dt>
<t hangText="LISP:">Type 8 is defined to be a "LISP Encapsulated <dd pn="section-5.8-4.6">Type 8 is defined to be a "LISP Encapsulated
Control Message", and what follows is either an IPv4 or IPv6 Control Message", and what follows is either an IPv4 or IPv6
header as encoded by the first 4 bits after the 'Reserved' header, as encoded by the first 4 bits after the 'Reserved'
field, or the Authentication Data field <xref field, or the 'Authentication Data' field <xref target="RFC9303" format=
target="I-D.ietf-lisp-sec"/> if the S-bit (see below) is set.</t> "default" sectionFormat="of" derivedContent="RFC9303"/> if the S-bit (see below)
is set.</dd>
<t hangText="Type: ">8 (Encapsulated Control Message (ECM))</t> <dt pn="section-5.8-4.7">Type: </dt>
<dd pn="section-5.8-4.8">8 (Encapsulated Control Message (ECM))</dd>
<t hangText="S:">This is the Security bit. When set to 1, the <dt pn="section-5.8-4.9">S:</dt>
<dd pn="section-5.8-4.10">This is the Security bit. When set to 1, th
e
field following the 'Reserved' field will have the following field following the 'Reserved' field will have the following
Authentication Data format and follow the procedures from <xref Authentication Data format and follow the procedures from <xref target="
target="I-D.ietf-lisp-sec"/>.</t> RFC9303" format="default" sectionFormat="of" derivedContent="RFC9303"/>.</dd>
</list></t> </dl>
<artwork name="" type="" align="left" alt="" pn="section-5.8-5">
<figure> <artwork><![CDATA[ 0 1 2 3
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AD Type | Authentication Data Content . . . |
| AD Type | Authentication Data Content . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </artwork>
]]></artwork> </figure> <dl newline="false" spacing="normal" indent="6" pn="section-5.8-6">
<dt pn="section-5.8-6.1">D:</dt>
<t><list style="hanging" hangIndent="6"> <dd pn="section-5.8-6.2">This is the DDT-bit. When set to 1, the
<t hangText="D:">This is the DDT-bit. When set to 1, the
sender is requesting a Map-Referral message to be sender is requesting a Map-Referral message to be
returned. The details of this procedure are described in <xref returned. Details regarding this procedure are described in <xref target
target="RFC8111"/>.</t> ="RFC8111" format="default" sectionFormat="of" derivedContent="RFC8111"/>.</dd>
<t hangText="R:">This reserved and unassigned bit MUST be set to 0 on <dt pn="section-5.8-6.3">R:</dt>
transmit and MUST be ignored on receipt.</t> <dd pn="section-5.8-6.4">This reserved and unassigned bit <bcp14>MUST<
</list></t> /bcp14> be set to 0 on
transmit and <bcp14>MUST</bcp14> be ignored on receipt.</dd>
<t><list style="hanging" hangIndent="6"> </dl>
<t hangText="IH:">The inner IPv4 or IPv6 header, which can use <dl newline="false" spacing="normal" indent="6" pn="section-5.8-7">
<dt pn="section-5.8-7.1">IH:</dt>
<dd pn="section-5.8-7.2">This is the inner IPv4 or IPv6 header, which
can use
either RLOC or EID addresses in the header address either RLOC or EID addresses in the header address
fields. When a Map-Request is encapsulated in this packet fields. When a Map-Request is encapsulated in this packet
format, the destination address in this header is an EID.</t> format, the destination address in this header is an EID.</dd>
<dt pn="section-5.8-7.3">UDP:</dt>
<t hangText="UDP:">The inner UDP header, where the port <dd pn="section-5.8-7.4">This is the inner UDP header, where the port
assignments depend on the control packet being assignments depend on the control packet being
encapsulated. When the control packet is a Map-Request or encapsulated. When the control packet is a Map-Request or
Map-Register, the source port is selected by the ITR/PITR and Map-Register, the source port is selected by the ITR/PITR and
the destination port is 4342. When the control packet is a the destination port is 4342. When the control packet is a
Map-Reply, the source port is 4342 and the destination port is Map-Reply, the source port is 4342 and the destination port is
assigned from the source port of the invoking assigned from the source port of the invoking
Map-Request. Port number 4341 MUST NOT be assigned to either Map-Request. Port number 4341 <bcp14>MUST NOT</bcp14> be assigned to eit
port. The checksum field MUST be non-zero.</t> her
port. The checksum field <bcp14>MUST</bcp14> be non-zero.</dd>
<t hangText="LCM:">The format is one of the control message <dt pn="section-5.8-7.5">LCM:</dt>
formats described in <xref target="lispcp"/>. Map-Request messages are <dd pn="section-5.8-7.6">The format is one of the control message
allowed to be Control-Plane (ECM) encapsulated. When formats described in <xref target="lispcp" format="default" sectionForma
Map-Requests are sent for RLOC-Probing purposes (i.e. the t="of" derivedContent="Section 5"/>. Map-Request messages are
probe-bit is set), they MUST NOT be sent inside Encapsulated allowed to be control plane (ECM) encapsulated. When
Control Messages. PIM Join/Prune messages <xref Map-Requests are sent for RLOC-Probing purposes (i.e., the
target="RFC6831" /> are also allowed to be Control-Plane (ECM) probe-bit is set), they <bcp14>MUST NOT</bcp14> be sent inside Encapsula
encapsulated.</t> ted
</list></t> Control Messages. PIM Join/Prune messages <xref target="RFC6831" format=
"default" sectionFormat="of" derivedContent="RFC6831"/> are also allowed to be c
<t><vspace blankLines='50' /></t> ontrol plane (ECM)
encapsulated.</dd>
</dl>
</section>
</section> </section>
</section> <section numbered="true" toc="include" removeInRFC="false" pn="section-6">
<section title="Changing the Contents of EID-to-RLOC Mappings"> <name slugifiedName="name-changing-the-contents-of-ei">Changing the Conten
<t>In the LISP architecture ITRs/PITRs use a local Map-Cache to ts of EID-to-RLOC Mappings</name>
<t indent="0" pn="section-6-1">In the LISP architecture, ITRs/PITRs use a
local Map-Cache to
store EID-to-RLOC mappings for forwarding. When an ETR updates a store EID-to-RLOC mappings for forwarding. When an ETR updates a
mapping a mechanism is required to inform ITRs/PITRs that are mapping, a mechanism is required to inform ITRs/PITRs that are
using such mappings.</t> using such mappings.</t>
<t indent="0" pn="section-6-2">The LISP data plane defines several mechani
<t>The LISP Data-Plane defines several mechanism to update sms to update
mappings <xref target="I-D.ietf-lisp-rfc6830bis" />. This document mappings <xref target="RFC9300" format="default" sectionFormat="of" derivedC
specifies the Solicit-Map Request (SMR), a Control-Plane ontent="RFC9300"/>. This document
push-based mechanism. An additional Control-Plane mechanism based specifies the Solicit-Map-Request (SMR), a control plane
on the Publish/subscribe paradigm is specified in push-based mechanism. An additional control plane mechanism based
<xref target="I-D.ietf-lisp-pubsub"/>.</t> on the Publish/Subscribe paradigm is specified in
<xref target="I-D.ietf-lisp-pubsub" format="default" sectionFormat="of" deri
<section title="Solicit-Map-Request (SMR)" anchor="SMR"> vedContent="LISP-PUBSUB"/>.</t>
<t>Soliciting a Map-Request is a selective way for ETRs, at <section anchor="SMR" numbered="true" toc="include" removeInRFC="false" pn
="section-6.1">
<name slugifiedName="name-solicit-map-request-smr">Solicit-Map-Request (
SMR)</name>
<t indent="0" pn="section-6.1-1">Soliciting a Map-Request is a selective
way for ETRs, at
the site where mappings change, to control the rate they the site where mappings change, to control the rate they
receive requests for Map-Reply messages. SMRs are also used receive requests for Map-Reply messages. SMRs are also used
to tell remote ITRs to update the mappings they have cached.</t> to tell remote ITRs to update the mappings they have cached.</t>
<t indent="0" pn="section-6.1-2">Since ETRs are not required to keep tra
<t>Since ETRs are not required to keep track of remote ITRs ck of remote ITRs
that have cached their mappings, they do not know which ITRs that have cached their mappings, they do not know which ITRs
need to have their mappings updated. As a result, an ETR need to have their mappings updated. As a result, an ETR will solicit
will solicit Map-Requests to those Map-Requests to
sites to which it has been sending LISP encapsulated data those sites to which it has been sending LISP encapsulated data
packets for the last minute. As a result, when an ETR is also acting a packets for the last minute, and when an ETR is also acting as an
s ITR, ITR, it will send an SMR to an ITR to which it has recently sent
it will send an SMR to an ITR to which it has recently sent encapsulat encapsulated data.</t>
ed <t indent="0" pn="section-6.1-3">An SMR message is simply a bit set in a
data.</t> Map-Request message.
An ITR or PITR will send a Map-Request (SMR-invoked Map-Request) when
<t>An SMR message is simply a bit set in a Map-Request message. it receives an SMR
An ITR or PITR will send a Map-Request (SMR-invoked Map-Request) when message. While the SMR message is sent through the data plane, the SMR
they receive an SMR -invoked Map-Request
message. While the SMR message is sent through the data-plane, the SMR <bcp14>MUST</bcp14> be sent through the Mapping System (not directly).
-invoked Map-Request </t>
MUST be sent through the Mapping System (not directly).</t> <t indent="0" pn="section-6.1-4">Both the SMR sender and the SMR respond
er
<t>Both the SMR sender and the SMR responder <bcp14>MUST</bcp14> rate limit these messages. It is <bcp14>RECOMMEND
MUST rate-limit these messages. It is RECOMMENDED that ED</bcp14> that
the SMR sender rate-limits Map-Request for the same destination the SMR sender rate limit a Map-Request for the same destinatio
RLOC to n RLOC to
no more than one packet per 3 seconds. It is RECOMMENDED that t no more than one packet every 3 seconds. It is <bcp14>RECOMMEND
he ED</bcp14> that the
SMR responder rate-limits Map-Request for the same EID-Prefix to no more t SMR responder rate limit a Map-Request for the same EID-Prefix to no more
han once than once
per 3 seconds.</t> every 3 seconds.</t>
<t indent="0" pn="section-6.1-5">When an ITR receives an SMR message for
<t>When an ITR receives an SMR message for
which it does not have a cached mapping for the EID in which it does not have a cached mapping for the EID in
the SMR message, it SHOULD NOT send an SMR-invoked the SMR message, it <bcp14>SHOULD NOT</bcp14> send an SMR-invoked
Map-Request. This scenario can occur when an ETR sends Map-Request. This scenario can occur when an ETR sends
SMR messages to all Locators in the Locator-Set it has SMR messages to all Locators in the Locator-Set it has
stored in its Map-Cache but the remote ITRs that receive the stored in its Map-Cache but the remote ITRs that receive the
SMR may not be sending packets to the site. There is no SMR may not be sending packets to the site. There is no
point in updating the ITRs until they need to send, in point in updating the ITRs until they need to send, in
which case they will send Map-Requests to obtain a which case they will send Map-Requests to obtain a
Map-Cache entry.</t> Map-Cache entry.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-7">
<section title="Routing Locator Reachability"> <name slugifiedName="name-routing-locator-reachabilit">Routing Locator Rea
chability</name>
<t>This document defines several Control-Plane mechanisms <t indent="0" pn="section-7-1">This document defines several control plane
for determining RLOC reachability. Please note that additional Data-Plane mechanisms
reachability mechanisms are defined in <xref target="I-D.ietf-lisp-rfc6830bis for determining RLOC reachability. Please note that additional data plane
" />.</t> reachability mechanisms are defined in <xref target="RFC9300" format="default
" sectionFormat="of" derivedContent="RFC9300"/>.</t>
<t><list style="numbers"> <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-7-2"
<t>An ITR may receive an ICMP Network Unreachable or Host >
<li pn="section-7-2.1" derivedCounter="1.">An ITR may receive an ICMP Net
work Unreachable or Host
Unreachable message for an RLOC it is using. This Unreachable message for an RLOC it is using. This
indicates that the RLOC is likely down. Note that trusting indicates that the RLOC is likely down. Note that trusting
ICMP messages may not be desirable, but neither is ignoring ICMP messages may not be desirable, but neither is ignoring
them completely. Implementations are encouraged to follow them completely. Implementations are encouraged to follow
current best practices in treating these conditions current best practices in treating these conditions
<xref target="I-D.ietf-opsec-icmp-filtering"/>.</t> <xref target="I-D.ietf-opsec-icmp-filtering" format="default" sectio
nFormat="of" derivedContent="OPSEC-ICMP-FILTER"/>.</li>
<t>When an ITR participates in the routing protocol that <li pn="section-7-2.2" derivedCounter="2.">When an ITR participates in t
he routing protocol that
operates in the underlay routing system, it can determine that operates in the underlay routing system, it can determine that
an RLOC is down when no Routing Information Base (RIB) an RLOC is down when no Routing Information Base (RIB)
entry exists that matches the RLOC IP address.</t> entry exists that matches the RLOC IP address.</li>
<li pn="section-7-2.3" derivedCounter="3.">An ITR may receive an ICMP Po
<t>An ITR may receive an ICMP Port Unreachable message rt Unreachable message
from a destination host. This occurs if an ITR from a destination host. This occurs if an ITR
attempts to use interworking <xref target="RFC6832" /> and attempts to use interworking <xref target="RFC6832" format="default"
LISP-encapsulated data is sent to a non-LISP-capable site.</t> sectionFormat="of" derivedContent="RFC6832"/> and
LISP-encapsulated data is sent to a non-LISP-capable site.</li>
<t>An ITR may receive a Map-Reply from an ETR in <li pn="section-7-2.4" derivedCounter="4.">An ITR may receive a Map-Repl
y from an ETR in
response to a previously sent Map-Request. The RLOC response to a previously sent Map-Request. The RLOC
source of the Map-Reply is likely up, since the source of the Map-Reply is likely up, since the
ETR was able to send the Map-Reply to the ITR. ETR was able to send the Map-Reply to the ITR.
Please note that in some scenarios the RLOC -from the Please note that in some scenarios the RLOC -- from the
outer header- can be an spoofable field.</t> outer header -- can be a spoofable field.</li>
<li pn="section-7-2.5" derivedCounter="5.">An ITR/ETR pair can use the '
<t>An ITR/ETR pair can use the 'RLOC-Probing' mechanism RLOC-Probing' mechanism
described below.</t> described below.</li>
</list></t> </ol>
<t indent="0" pn="section-7-3">When ITRs receive ICMP Network Unreachable
<t>When ITRs receive ICMP Network Unreachable or Host Unreachable or Host Unreachable
messages as a method to determine unreachability, messages as a method to determine unreachability,
they will refrain from they will refrain from
using Locators that are described in Locator lists of Map-Replies. using Locators that are described in Locator lists of Map-Replies.
However, using this approach is unreliable because many network However, using this approach is unreliable because many network
operators turn off generation of ICMP Destination Unreachable operators turn off generation of ICMP Destination Unreachable
messages.</t> messages.</t>
<t indent="0" pn="section-7-4">If an ITR does receive an ICMP Network Unre
<t>If an ITR does receive an ICMP Network Unreachable or Host achable or Host
Unreachable message, it MAY originate its own ICMP Destination Unreachable message, it <bcp14>MAY</bcp14> originate its own ICMP Destin
ation
Unreachable message destined for the host that originated Unreachable message destined for the host that originated
the data packet the ITR encapsulated.</t> the data packet the ITR encapsulated.</t>
<t indent="0" pn="section-7-5">This assumption does create a dependency: L
<t>This assumption does create a dependency: Locator ocator
unreachability is detected by the receipt of ICMP Host unreachability is detected by the receipt of ICMP Host
Unreachable messages. When a Locator has been determined Unreachable messages. When a Locator has been determined
to be unreachable, it is not used for active traffic; this to be unreachable, it is not used for active traffic; this
is the same as if it were listed in a Map-Reply with is the same as if it were listed in a Map-Reply with
Priority 255.</t> Priority 255.</t>
<t indent="0" pn="section-7-6">The ITR can test the reachability of the un
<t>The ITR can test the reachability of the unreachable reachable
Locator by sending periodic Map-Requests. Both Map-Requests and Locator by sending periodic Map-Requests. Both Map-Requests and
Map-Replies MUST be rate-limited, see <xref target="MAPREQ"/> and <xref target="MR-FORMAT"/> for information about rate-limiting. Locator reachability t esting Map-Replies <bcp14>MUST</bcp14> be rate limited; see Sections <xref targ et="MAPREQ" format="counter" sectionFormat="of" derivedContent="5.3"/> and <xref target="MR-FORMAT" format="counter" sectionFormat="of" derivedContent="5.4"/> f or information about rate limiting. Locator reachability testing
is never done with data packets, since that increases the is never done with data packets, since that increases the
risk of packet loss for end-to-end sessions.</t> risk of packet loss for end-to-end sessions.</t>
<section anchor="rloc-probe" numbered="true" toc="include" removeInRFC="fa
<section anchor="rloc-probe" title="RLOC-Probing Algorithm"> lse" pn="section-7.1">
<name slugifiedName="name-rloc-probing-algorithm">RLOC-Probing Algorithm
<t>RLOC-Probing is a method that an ITR or PITR can use to </name>
<t indent="0" pn="section-7.1-1">RLOC-Probing is a method that an ITR or
PITR can use to
determine the reachability status of one or more determine the reachability status of one or more
Locators that it has cached in a Map-Cache entry. The Locators that it has cached in a Map-Cache entry. The
probe-bit of the Map-Request and Map-Reply messages is probe-bit of the Map-Request and Map-Reply messages is
used for RLOC-Probing.</t> used for RLOC-Probing.</t>
<t indent="0" pn="section-7.1-2">RLOC-Probing is done in the control pla
<t>RLOC-Probing is done in the control plane on a ne on a
timer basis, where an ITR or PITR will originate a Map-Request timer basis, where an ITR or PITR will originate a Map-Request
destined to a locator address from one of its destined to a Routing Locator Address from one of its
own locator addresses. A Map-Request used as an RLOC-probe own Routing Locator Addresses. A Map-Request used as an RLOC-Probe
is NOT encapsulated and NOT sent to a Map-Server or to the is NOT encapsulated and NOT sent to a Map-Server or to the
mapping database system as one would when requesting mapping data. mapping database system as one would when requesting mapping data.
The EID record encoded in the Map-Request is the EID-Prefix of The EID-Record encoded in the Map-Request is the EID-Prefix of
the Map-Cache entry cached by the ITR or PITR. The ITR the Map-Cache entry cached by the ITR or PITR. The ITR
MAY include a mapping data record for its own database mapping <bcp14>MAY</bcp14> include a mapping data record for its own database ma pping
information that contains the local EID-Prefixes and RLOCs for information that contains the local EID-Prefixes and RLOCs for
its site. RLOC-probes are sent periodically using a jittered its site. RLOC-Probes are sent periodically using a jittered
timer interval. </t> timer interval. </t>
<t indent="0" pn="section-7.1-3">When an ETR receives a Map-Request mess
<t>When an ETR receives a Map-Request message with the age with the
probe-bit set, it returns a Map-Reply with the probe-bit probe-bit set, it returns a Map-Reply with the probe-bit
set. The source address of the Map-Reply is set to the IP set. The source address of the Map-Reply is set to the IP
address of the outgoing interface the Map-Reply destination address of the outgoing interface the Map-Reply destination
address routes to. The Map-Reply SHOULD contain mapping data address routes to. The Map-Reply <bcp14>SHOULD</bcp14> contain mapping d ata
for the EID-Prefix contained in the Map-Request. This provides for the EID-Prefix contained in the Map-Request. This provides
the opportunity for the ITR or PITR that sent the RLOC-probe the opportunity for the ITR or PITR that sent the RLOC-Probe
to get mapping updates if there were changes to the ETR's to get mapping updates if there were changes to the ETR's
database mapping entries.</t> database mapping entries.</t>
<t indent="0" pn="section-7.1-4">There are advantages and disadvantages
<t>There are advantages and disadvantages of RLOC-Probing. of RLOC-Probing.
The main benefit of RLOC-Probing is that it can handle many The main benefit of RLOC-Probing is that it can handle many
failure scenarios allowing the ITR to determine when the path failure scenarios, allowing the ITR to determine when the path
to a specific Locator is reachable or has become unreachable, to a specific Locator is reachable or has become unreachable,
thus providing a robust mechanism for switching to using thus providing a robust mechanism for switching to using
another Locator from the cached Locator. RLOC-Probing can another Locator from the cached Locator. RLOC-Probing can
also provide rough Round-Trip Time (RTT) estimates between a also provide rough Round-Trip Time (RTT) estimates between a
pair of Locators, which can be useful for network management pair of Locators, which can be useful for network management
purposes as well as for selecting low delay paths. The major purposes as well as for selecting low-delay paths. The major
disadvantage of RLOC-Probing is in the number of control disadvantage of RLOC-Probing is in the number of control
messages required and the amount of bandwidth used to obtain messages required and the amount of bandwidth used to obtain
those benefits, especially if the requirement for failure those benefits, especially if the requirement for failure
detection times is very small.</t> detection times is very small.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-8">
<section title="Interactions with Other LISP Components"> <name slugifiedName="name-interactions-with-other-lis">Interactions with O
ther LISP Components</name>
<section title="ITR EID-to-RLOC Mapping Resolution"> <section numbered="true" toc="include" removeInRFC="false" pn="section-8.1
<t>An ITR is configured with one or more Map-Resolver addresses. ">
These addresses are "Locators" (or RLOCs) and MUST be routable <name slugifiedName="name-itr-eid-to-rloc-mapping-res">ITR EID-to-RLOC M
on the underlying core network; they MUST NOT need to be apping Resolution</name>
<t indent="0" pn="section-8.1-1">An ITR is configured with one or more M
ap-Resolver addresses.
These addresses are "Locators" (or RLOCs) and <bcp14>MUST</bcp14> be routa
ble
on the underlying core network; they <bcp14>MUST NOT</bcp14> need to be
resolved through LISP EID-to-RLOC mapping, as that would resolved through LISP EID-to-RLOC mapping, as that would
introduce a circular dependency. When using a Map-Resolver, an introduce a circular dependency. When using a Map-Resolver, an
ITR does not need to connect to any other database mapping ITR does not need to connect to any other database Mapping
system.</t> System.</t>
<t indent="0" pn="section-8.1-2"> An ITR sends an Encapsulated Map-Reque
<t> An ITR sends an Encapsulated Map-Request to a configured st to a configured
Map-Resolver when it needs an EID-to-RLOC mapping that is not Map-Resolver when it needs an EID-to-RLOC mapping that is not
found in its local Map-Cache. Using the Map-Resolver greatly found in its local Map-Cache. Using the Map-Resolver greatly
reduces both the complexity of the ITR implementation and the reduces both the complexity of the ITR implementation and the
costs associated with its operation.</t> costs associated with its operation.</t>
<t indent="0" pn="section-8.1-3"> In response to an Encapsulated Map-Req
<t> In response to an Encapsulated Map-Request, the ITR can uest, the ITR can
expect one of the following:</t> expect one of the following:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-8
<t><list style="symbols"> .1-4">
<t> An immediate Negative Map-Reply (with action code of <li pn="section-8.1-4.1"> An immediate Negative Map-Reply (with action
"Natively-Forward", 15-minute Time to Live (TTL)) from the code
"Natively-Forward" and a 15-minute TTL) from the
Map-Resolver if the Map-Resolver can determine that the Map-Resolver if the Map-Resolver can determine that the
requested EID does not exist. The ITR saves the EID-Prefix requested EID does not exist. The ITR saves the EID-Prefix
returned in the Map-Reply in its cache, marks it as returned in the Map-Reply in its cache, marks it as
non-LISP-capable, and knows not to attempt LISP encapsulation non-LISP-capable, and knows not to attempt LISP encapsulation
for destinations matching it.</t> for destinations matching it.</li>
<li pn="section-8.1-4.2"> A Negative Map-Reply (with action code
<t> A Negative Map-Reply, with action code of "Natively-Forward") from a Map-Server that is authoritative (within the
"Natively-Forward", from a Map-Server that is authoritative (within the LISP deployment (<xref target="soa" format="default" sectionFormat="of" derivedC
LISP deployment <xref target="soa" />) ontent="Section 1.1"/>))
for an EID-Prefix that matches the requested EID but that does for an EID-Prefix that matches the requested EID but that does
not have an actively registered, more-specific EID-prefix. In not have an actively registered, more-specific EID-Prefix. In
this case, the requested EID is said to match a "hole" in the this case, the requested EID is said to match a "hole" in the
authoritative EID-Prefix. If the requested EID matches a authoritative EID-Prefix. If the requested EID matches a
more-specific EID-Prefix that has been delegated by the more-specific EID-Prefix that has been delegated by the
Map-Server but for which no ETRs are currently registered, a Map-Server but for which no ETRs are currently registered, a
1-minute TTL is returned. If the requested EID matches a 1-minute TTL is returned. If the requested EID matches a
non-delegated part of the authoritative EID-Prefix, then it is non-delegated part of the authoritative EID-Prefix, then it is
not a LISP EID and a 15-minute TTL is returned. See <xref not a LISP EID and a 15-minute TTL is returned. See <xref target="reg"
target="reg"/> for discussion of aggregate EID-Prefixes and format="default" sectionFormat="of" derivedContent="Section 8.2"/> for a discuss
details of Map-Server EID-Prefix matching.</t> ion of aggregate EID-Prefixes and
details regarding Map-Server EID-Prefix matching.</li>
<t> A LISP Map-Reply from the ETR that owns the EID-to-RLOC <li pn="section-8.1-4.3"> A LISP Map-Reply from the ETR that owns the
EID-to-RLOC
mapping or possibly from a Map-Server answering on behalf of mapping or possibly from a Map-Server answering on behalf of
the ETR. See <xref target="mr-processing" /> for more details the ETR. See <xref target="mr-processing" format="default" sectionFormat
on Map-Resolver message processing.</t> ="of" derivedContent="Section 8.4"/> for more details
</list></t> on Map-Resolver message processing.</li>
</ul>
<t> Note that an ITR may be configured to both use a <t indent="0" pn="section-8.1-5"> Note that an ITR may be configured to
Map-Resolver and to participate in a LISP-ALT logical both use a
network. In such a situation, the ITR SHOULD send Map-Requests Map-Resolver and participate in a LISP-ALT logical
network. In such a situation, the ITR <bcp14>SHOULD</bcp14> send Map-Reque
sts
through the ALT network for any EID-Prefix learned via ALT BGP. through the ALT network for any EID-Prefix learned via ALT BGP.
Such a configuration is expected to be very rare, since there is Such a configuration is expected to be very rare, since there is
little benefit to using a Map-Resolver if an ITR is already little benefit to using a Map-Resolver if an ITR is already
using LISP-ALT. There would be, for example, no need for such an using LISP-ALT. There would be, for example, no need for such an
ITR to send a Map-Request to a possibly non-existent EID (and ITR to send a Map-Request to a possibly non-existent EID (and
rely on Negative Map-Replies) if it can consult the ALT database rely on Negative Map-Replies) if it can consult the ALT database
to verify that an EID-Prefix is present before sending that to verify that an EID-Prefix is present before sending that
Map-Request.</t> Map-Request.</t>
</section> </section>
<section anchor="reg" numbered="true" toc="include" removeInRFC="false" pn
<section title="EID-Prefix Configuration and ETR Registration" ="section-8.2">
anchor="reg"> <name slugifiedName="name-eid-prefix-configuration-an">EID-Prefix Config
<t> An ETR publishes its EID-Prefixes on a Map-Server by sending uration and ETR Registration</name>
<t indent="0" pn="section-8.2-1"> An ETR publishes its EID-Prefixes on a
Map-Server by sending
LISP Map-Register messages. A Map-Register message includes LISP Map-Register messages. A Map-Register message includes
authentication data, so prior to sending a Map-Register message, Authentication Data, so prior to sending a Map-Register message,
the ETR and Map-Server MUST be configured with a pre-shared secret the ETR and Map-Server <bcp14>MUST</bcp14> be configured with a pre-shared
secret
used to derive Map-Register authentication keys. A Map-Server's used to derive Map-Register authentication keys. A Map-Server's
configuration SHOULD also include a list of the EID-Prefixes for configuration <bcp14>SHOULD</bcp14> also include a list of the EID-Prefixe s for
which each ETR is authoritative. Upon receipt of a Map-Register which each ETR is authoritative. Upon receipt of a Map-Register
from an ETR, a Map-Server accepts only EID-Prefixes that are from an ETR, a Map-Server accepts only EID-Prefixes that are
configured for that ETR. Failure to implement such a check configured for that ETR. Failure to implement such a check
would leave the mapping system vulnerable to trivial EID-Prefix would leave the Mapping System vulnerable to trivial EID-Prefix
hijacking attacks.</t> hijacking attacks.</t>
<t indent="0" pn="section-8.2-2"> In addition to the set of EID-Prefixes
<t> In addition to the set of EID-Prefixes defined for each ETR defined for each ETR
that may register, a Map-Server is typically also configured that may register, a Map-Server is typically also configured
with one or more aggregate prefixes that define the part of the with one or more aggregate prefixes that define the part of the
EID numbering space assigned to it. When LISP-ALT is the EID numbering space assigned to it. When LISP-ALT is the
database in use, aggregate EID-Prefixes are implemented as database in use, aggregate EID-Prefixes are implemented as
discard routes and advertised into ALT BGP. The existence of discard routes and advertised into ALT BGP. The existence of
aggregate EID-Prefixes in a Map-Server's database means that it aggregate EID-Prefixes in a Map-Server's database means that it
may receive Map Requests for EID-Prefixes that match an may receive Map-Requests for EID-Prefixes that match an
aggregate but do not match a registered prefix; <xref aggregate but do not match a registered prefix; <xref target="ms-processin
target="ms-processing" /> describes how this is handled.</t> g" format="default" sectionFormat="of" derivedContent="Section 8.3"/> describes
how this is handled.</t>
<t> Map-Register messages are sent periodically from an ETR to a <t indent="0" pn="section-8.2-3"> Map-Register messages are sent periodi
cally from an ETR to a
Map-Server with a suggested interval between messages of one Map-Server with a suggested interval between messages of one
minute. A Map-Server SHOULD time out and remove an ETR's minute. A Map-Server <bcp14>SHOULD</bcp14> time out and remove an ETR's
registration if it has not received a valid Map-Register message registration if it has not received a valid Map-Register message
within the past three&nbsp;minutes. When first contacting a within the past three minutes. When first contacting a
Map-Server after restart or changes to its EID-to-RLOC database Map-Server after restart or changes to its EID-to-RLOC database
mappings, an ETR MAY initially send Map-Register messages at an mappings, an ETR <bcp14>MAY</bcp14> initially send Map-Register messages a t an
increased frequency, up to one every 20 seconds. This "quick increased frequency, up to one every 20 seconds. This "quick
registration" period is limited to five&nbsp;minutes in registration" period is limited to five minutes in
duration.</t> duration.</t>
<t indent="0" pn="section-8.2-4"> An ETR <bcp14>MAY</bcp14> request that
<t> An ETR MAY request that a Map-Server explicitly acknowledge a Map-Server explicitly acknowledge
receipt and processing of a Map-Register message by setting the receipt and processing of a Map-Register message by setting the
"want-map-notify" (M-bit) flag. A Map-Server that receives a "want-map-notify" (M-bit) flag. A Map-Server that receives a
Map-Register with this flag set will respond with a Map-Notify Map-Register with this flag set will respond with a Map-Notify
message. Typical use of this flag by an ETR would be to set it message. Typical use of this flag by an ETR would be to set it
for Map-Register messages sent during the initial "quick for Map-Register messages sent during the initial "quick
registration" with a Map-Server but then set it only registration" with a Map-Server but then set it only
occasionally during steady-state maintenance of its association occasionally during steady-state maintenance of its association
with that Map-Server. Note that the Map-Notify message is sent with that Map-Server. Note that the Map-Notify message is sent
to UDP destination port 4342, not to the source port specified to UDP destination port 4342, not to the source port specified
in the original Map-Register message.</t> in the original Map-Register message.</t>
<t indent="0" pn="section-8.2-5"> Note that a one-minute minimum registr
<t> Note that a one-minute minimum registration interval during ation interval during
maintenance of an ETR-Map-Server association places a lower maintenance of an ETR-Map-Server association places a lower
bound on how quickly and how frequently a mapping database entry bound on how quickly and how frequently a mapping database entry
can be updated. This may have implications for what sorts of can be updated. This may have implications for what sorts of
mobility can be supported directly by the mapping system; mobility can be supported directly by the Mapping System;
shorter registration intervals or other mechanisms might be shorter registration intervals or other mechanisms might be
needed to support faster mobility in some cases. For a needed to support faster mobility in some cases. For a
discussion on one way that faster mobility may be implemented discussion on one way that faster mobility may be implemented
for individual devices, please see <xref target="I-D.ietf-lisp-mn"/>.</t> for individual devices, please see <xref target="I-D.ietf-lisp-mn" format=
"default" sectionFormat="of" derivedContent="LISP-MN"/>.</t>
<t> An ETR MAY also request, by setting the "proxy Map-Reply" <t indent="0" pn="section-8.2-6"> An ETR <bcp14>MAY</bcp14> also request
, by setting the "proxy Map-Reply"
flag (P-bit) in the Map-Register message, that a Map-Server flag (P-bit) in the Map-Register message, that a Map-Server
answer Map-Requests instead of forwarding them to the ETR. See answer Map-Requests instead of forwarding them to the ETR. See
<xref target="rloc-probe"/> for details on how <xref target="rloc-probe" format="default" sectionFormat="of" derivedConte nt="Section 7.1"/> for details on how
the Map-Server sets certain flags (such as those indicating the Map-Server sets certain flags (such as those indicating
whether the message is authoritative and how returned Locators whether the message is authoritative and how returned Locators
SHOULD be treated) when sending a Map-Reply on behalf of an ETR. <bcp14>SHOULD</bcp14> be treated) when sending a Map-Reply on behalf of an
When an ETR requests proxy reply service, it SHOULD include all ETR.
When an ETR requests proxy reply service, it <bcp14>SHOULD</bcp14> include
all
RLOCs for all ETRs for the EID-Prefix being registered, along RLOCs for all ETRs for the EID-Prefix being registered, along
with the routable flag ("R-bit") setting for each RLOC. The with the routable flag ("R-bit") setting for each RLOC. The
Map-Server includes all of this information in Map-Reply Map-Server includes all of this information in Map-Reply
messages that it sends on behalf of the ETR. This differs from a messages that it sends on behalf of the ETR. This differs from a
non-proxy registration, since the latter need only provide one non-proxy registration, since the latter need only provide one
or more RLOCs for a Map-Server to use for forwarding or more RLOCs for a Map-Server to use for forwarding
Map-Requests; the registration information is not used in Map-Requests; the registration information is not used in
Map-Replies, so it being incomplete is not incorrect.</t> Map-Replies, so it being incomplete is not incorrect.</t>
<t indent="0" pn="section-8.2-7"> An ETR that uses a Map-Server to publi
<t> An ETR that uses a Map-Server to publish its EID-to-RLOC sh its EID-to-RLOC
mappings does not need to participate further in the mapping mappings does not need to participate further in the mapping
database protocol(s). When using a LISP-ALT mapping database, database protocol(s). When using a LISP-ALT mapping database,
for example, this means that the ETR does not need to implement for example, this means that the ETR does not need to implement
GRE or BGP, which greatly simplifies its configuration and GRE or BGP, which greatly simplifies its configuration and
reduces its cost of operation.</t> reduces its cost of operation.</t>
<t indent="0" pn="section-8.2-8"> Note that use of a Map-Server does not
<t> Note that use of a Map-Server does not preclude an ETR from preclude an ETR from
also connecting to the mapping database (i.e., it could also also connecting to the mapping database (i.e., it could also
connect to the LISP-ALT network), but doing so doesn't seem connect to the LISP-ALT network), but doing so doesn't seem
particularly useful, as the whole purpose of using a Map-Server particularly useful, as the whole purpose of using a Map-Server
is to avoid the complexity of the mapping database is to avoid the complexity of the mapping database
protocols.</t> protocols.</t>
</section> </section>
<section anchor="ms-processing" numbered="true" toc="include" removeInRFC=
<section title="Map-Server Processing" anchor="ms-processing"> "false" pn="section-8.3">
<t> Once a Map-Server has EID-Prefixes registered by its client <name slugifiedName="name-map-server-processing">Map-Server Processing</
name>
<t indent="0" pn="section-8.3-1"> Once a Map-Server has EID-Prefixes reg
istered by its client
ETRs, it can accept and process Map-Requests for them.</t> ETRs, it can accept and process Map-Requests for them.</t>
<t indent="0" pn="section-8.3-2"> In response to a Map-Request, the Map-
<t> In response to a Map-Request, the Map-Server first checks to see if th Server first checks to see if the
e
destination EID matches a configured EID-Prefix. If there is no destination EID matches a configured EID-Prefix. If there is no
match, the Map-Server returns a Negative Map-Reply with action match, the Map-Server returns a Negative Map-Reply with action
code "Natively-Forward" and a 15-minute TTL. This can occur if a code "Natively-Forward" and a 15-minute TTL. This can occur if a
Map Request is received for a configured aggregate EID-Prefix Map-Request is received for a configured aggregate EID-Prefix
for which no more-specific EID-Prefix exists; it indicates the for which no more-specific EID-Prefix exists; it indicates the
presence of a non-LISP "hole" in the aggregate EID-Prefix.</t> presence of a non-LISP "hole" in the aggregate EID-Prefix.</t>
<t indent="0" pn="section-8.3-3">Next, the Map-Server checks to see if a
<t>Next, the Map-Server checks to see if any ETRs have ny ETRs have
registered the matching EID-Prefix. If none are found, then the registered the matching EID-Prefix. If none are found, then the
Map-Server returns a Negative Map-Reply with action code Map-Server returns a Negative Map-Reply with action code
"Natively-Forward" and a 1-minute TTL.</t> "Natively-Forward" and a 1-minute TTL.</t>
<t indent="0" pn="section-8.3-4">If the EID-Prefix is either registered
<t>If the EID-prefix is either registered or not registered to or not registered to
the mapping system and there is a policy in the Map-Server to the Mapping System and there is a policy in the Map-Server to
have the requestor drop packets for the matching EID-prefix, have the requester drop packets for the matching EID-Prefix,
then a Drop/Policy-Denied action is returned. If the EID-prefix then a Drop/Policy-Denied action is returned. If the EID-Prefix
is registered or not registered and there is a authentication is registered or not registered and there is an authentication
failure, then a Drop/Authentication- failure action is failure, then a Drop/Auth-Failure action is
returned. If either of these actions result as a temporary state returned. If either of these actions results as a temporary state
in policy or authentication then a Send-Map-Request action with in policy or authentication, then a Send-Map-Request action with a
1-minute TTL MAY be returned to allow the requestor to retry the 1-minute TTL <bcp14>MAY</bcp14> be returned to allow the requester to retr
y the
Map-Request.</t> Map-Request.</t>
<t indent="0" pn="section-8.3-5"> If any of the registered ETRs for the
<t> If any of the registered ETRs for the EID-Prefix have EID-Prefix have
requested proxy reply service, then the Map-Server answers the requested proxy reply service, then the Map-Server answers the
request instead of forwarding it. It returns a Map-Reply with request instead of forwarding it. It returns a Map-Reply with
the EID-Prefix, RLOCs, and other information learned through the the EID-Prefix, RLOCs, and other information learned through the
registration process.</t> registration process.</t>
<t indent="0" pn="section-8.3-6"> If none of the ETRs have requested pro
<t> If none of the ETRs have requested proxy reply service, then xy reply service, then
the Map-Server re-encapsulates and forwards the resulting the Map-Server re-encapsulates and forwards the resulting
Encapsulated Map-Request to one of the registered ETRs. It does Encapsulated Map-Request to one of the registered ETRs. It does
not otherwise alter the Map-Request, so any Map-Reply sent by not otherwise alter the Map-Request, so any Map-Reply sent by
the ETR is returned to the RLOC in the Map-Request, not to the the ETR is returned to the RLOC in the Map-Request, not to the
Map-Server. Unless also acting as a Map-Resolver, a Map-Server Map-Server. Unless also acting as a Map-Resolver, a Map-Server
should never receive Map-Replies; any such messages SHOULD be should never receive Map-Replies; any such messages <bcp14>SHOULD</bcp14> be
discarded without response, perhaps accompanied by the logging discarded without response, perhaps accompanied by the logging
of a diagnostic message if the rate of Map-Replies is suggestive of a diagnostic message if the rate of Map-Replies is suggestive
of malicious traffic.</t> of malicious traffic.</t>
</section> </section>
<section anchor="mr-processing" numbered="true" toc="include" removeInRFC=
<section title="Map-Resolver Processing" anchor="mr-processing"> "false" pn="section-8.4">
<t> Upon receipt of an Encapsulated Map-Request, a Map-Resolver <name slugifiedName="name-map-resolver-processing">Map-Resolver Processi
ng</name>
<t indent="0" pn="section-8.4-1"> Upon receipt of an Encapsulated Map-Re
quest, a Map-Resolver
decapsulates the enclosed message and then searches for the decapsulates the enclosed message and then searches for the
requested EID in its local database of mapping entries requested EID in its local database of mapping entries
(statically configured or learned from associated ETRs if the (statically configured or learned from associated ETRs if the
Map-Resolver is also a Map-Server offering proxy reply Map-Resolver is also a Map-Server offering proxy reply
service). If it finds a matching entry, it returns a LISP service). If it finds a matching entry, it returns a LISP
Map-Reply with the known mapping.</t> Map-Reply with the known mapping.</t>
<t indent="0" pn="section-8.4-2"> If the Map-Resolver does not have the
<t> If the Map-Resolver does not have the mapping entry and if mapping entry and if
it can determine that the EID is not in the mapping database it can determine that the EID is not in the mapping database
(for example, if LISP-ALT is used, the Map-Resolver will have an (for example, if LISP-ALT is used, the Map-Resolver will have an
ALT forwarding table that covers the full EID space), it ALT forwarding table that covers the full EID space), it
immediately returns a negative LISP Map-Reply, with action code immediately returns a Negative Map-Reply with action code
"Natively-Forward" and a 15&nbhy;minute TTL. To minimize the "Natively-Forward" and a 15‑minute TTL. To minimize the
number of negative cache entries needed by an ITR, the number of negative cache entries needed by an ITR, the
Map-Resolver SHOULD return the least-specific prefix that both Map-Resolver <bcp14>SHOULD</bcp14> return the least-specific prefix that b oth
matches the original query and does not match any EID-Prefix matches the original query and does not match any EID-Prefix
known to exist in the LISP-capable infrastructure.</t> known to exist in the LISP-capable infrastructure.</t>
<t indent="0" pn="section-8.4-3"> If the Map-Resolver does not have suff
<t> If the Map-Resolver does not have sufficient information to icient information to
know whether the EID exists, it needs to forward the Map-Request know whether the EID exists, it needs to forward the Map-Request
to another device that has more information about the EID being to another device that has more information about the EID being
requested. To do this, it forwards the unencapsulated requested. To do this, it forwards the unencapsulated
Map-Request, with the original ITR RLOC as the source, to the Map-Request, with the original ITR RLOC as the source, to the
mapping database system. Using LISP-ALT, the Map-Resolver is mapping database system. Using LISP-ALT, the Map-Resolver is
connected to the ALT network and sends the Map-Request to the connected to the ALT network and sends the Map-Request to the
next ALT hop learned from its ALT BGP neighbors. The next ALT hop learned from its ALT BGP neighbors. The
Map-Resolver does not send any response to the ITR; since the Map-Resolver does not send any response to the ITR; since the
source RLOC is that of the ITR, the ETR or Map-Server that source RLOC is that of the ITR, the ETR or Map-Server that
receives the Map-Request over the ALT and responds will do so receives the Map-Request over the ALT and responds will do so
directly to the ITR.</t> directly to the ITR.</t>
<section numbered="true" toc="include" removeInRFC="false" pn="section-8
<section title="Anycast Operation"> .4.1">
<t> A Map-Resolver can be set up to use "anycast", where the <name slugifiedName="name-anycast-operation">Anycast Operation</name>
<t indent="0" pn="section-8.4.1-1"> A Map-Resolver can be set up to us
e "anycast", where the
same address is assigned to multiple Map-Resolvers and is same address is assigned to multiple Map-Resolvers and is
propagated through IGP routing, to facilitate the use of a propagated through IGP routing, to facilitate the use of a
topologically close Map-Resolver by each ITR.</t> topologically close Map-Resolver by each ITR.</t>
<t indent="0" pn="section-8.4.1-2"> ETRs <bcp14>MAY</bcp14> have anyca
<t> ETRs MAY have anycast RLOC addresses which are registered st RLOC addresses that are registered
as part of their RLOC-set to the mapping system. However, as part of their RLOC-Set to the Mapping System. However,
registrations MUST use their unique RLOC addresses, distinct registrations <bcp14>MUST</bcp14> use their unique RLOC addresses, disti
authentication keys or different XTR-IDs to identify security associatio nct
ns with the authentication keys, or different xTR-IDs to identify security associati
ons with the
Map-Servers.</t> Map-Servers.</t>
</section>
</section> </section>
</section> </section>
</section> <section numbered="true" toc="include" removeInRFC="false" pn="section-9">
<name slugifiedName="name-security-considerations">Security Considerations
<section title="Security Considerations"> </name>
<t>A LISP threat analysis can be found in <xref <t indent="0" pn="section-9-1">A LISP threat analysis can be found in <xre
target="RFC7835"/>. In what follows we highlight security f target="RFC7835" format="default" sectionFormat="of" derivedContent="RFC7835"/
>. Here, we highlight security
considerations that apply when LISP is deployed in environments considerations that apply when LISP is deployed in environments
such as those specified in <xref target="soa"/>, where the such as those specified in <xref target="soa" format="default" sectionFormat ="of" derivedContent="Section 1.1"/>, where the
following assumptions hold:</t> following assumptions hold:</t>
<ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-9-2"
<t><list style="numbers"> >
<t>The Mapping System is secure and trusted, and for the purpose <li pn="section-9-2.1" derivedCounter="1.">The Mapping System is secure a
of this security considerations the Mapping System is considered nd trusted, and for the purpose
as one trusted element.</t> of these security considerations, the Mapping System is considered
as one trusted element.</li>
<t>The ETRs have a pre-configured trust relationship with the <li pn="section-9-2.2" derivedCounter="2.">The ETRs have a preconfigured
Mapping System, which includes some form of shared secret, and the trust relationship with the Mapping
Mapping System is aware of which EIDs an ETR can advertise. How System, including some form of shared secret. The Mapping
those keys and mappings gets established is out of the scope of System is aware of which EIDs an ETR can advertise. How
this document.</t> those keys and mappings are established is out of scope for
this document.</li>
<t>LISP-SEC <xref target="I-D.ietf-lisp-sec"/> MUST be <li pn="section-9-2.3" derivedCounter="3.">LISP-SEC <xref target="RFC930
implemented. Network operators should carefully weight how the 3" format="default" sectionFormat="of" derivedContent="RFC9303"/> <bcp14>MUST</b
cp14> be
implemented. Network operators should carefully weigh how the
LISP-SEC threat model applies to their particular use case or LISP-SEC threat model applies to their particular use case or
deployment. If they decide to ignore a particular deployment. If they decide to ignore a particular
recommendation, they should make sure the risk associated with recommendation, they should make sure the risk associated with
the corresponding threats is well understood.</t> the corresponding threats is well understood.</li>
</list></t> </ol>
<t indent="0" pn="section-9-3">The Map-Request/Map-Reply message exchange
<t>The Map-Request/Map-Reply message exchange can be exploited by can be exploited by
an attacker to mount DoS and/or amplification attacks. Attackers an attacker to mount DoS and/or amplification attacks. Attackers
can send Map-Requests at high rates to overload LISP nodes and can send Map-Requests at high rates to overload LISP nodes and
increase the state maintained by such nodes or consume CPU increase the state maintained by such nodes or consume CPU
cycles. Such threats can be mitigated by systematically applying cycles. Such threats can be mitigated by systematically applying
filters and rate limiters.</t> filters and rate limiters.</t>
<t indent="0" pn="section-9-4">The Map-Request/Map-Reply message exchange
<t>The Map-Request/Map-Reply message exchange can also be exploited to injec can also be exploited to inject
t forged mappings directly into the ITR EID-to-RLOC Map-Cache. This
forged mappings directly in the ITR EID-to-RLOC map-cache. This can lead to traffic being redirected to the attacker; see further
can lead to traffic being redirected to the attacker, see further details in <xref target="RFC7835" format="default" sectionFormat="of" derive
details in <xref target="RFC7835"/>. In addition, valid ETRs in dContent="RFC7835"/>. In addition, valid ETRs in
the system can perform overclaiming attacks. In this case, the system can perform overclaiming attacks. In this case,
attackers can claim to own an EID-prefix that is larger than the attackers can claim to own an EID-Prefix that is larger than the
prefix owned by the ETR. Such attacks can be addressed by using prefix owned by the ETR. Such attacks can be addressed by using
LISP-SEC <xref target="I-D.ietf-lisp-sec"/>. The LISP-SEC protocol LISP-SEC <xref target="RFC9303" format="default" sectionFormat="of" derivedC ontent="RFC9303"/>. The LISP-SEC protocol
defines a mechanism for providing origin authentication, defines a mechanism for providing origin authentication,
integrity protection, and prevention of integrity protection, and prevention of
&apos;man-in-the-middle&apos; and &apos;prefix overclaiming&apos; 'man-in-the-middle' and 'prefix overclaiming'
attacks on the Map-Request/Map-Reply exchange. In addition and attacks on the Map-Request/Map-Reply exchange. In addition, and
while beyond the scope of securing an individual Map-Server or while beyond the scope of securing an individual Map-Server or
Map-Resolver, it should be noted that LISP-SEC can be complemented Map-Resolver, it should be noted that LISP-SEC can be complemented
by additional security mechanisms defined by the Mapping System by additional security mechanisms defined by the Mapping System
Infrastructure. For instance, BGP-based LISP-ALT <xref infrastructure. For instance, BGP-based LISP-ALT <xref target="RFC6836" form
target="RFC6836"/> can take advantage of standards work on adding at="default" sectionFormat="of" derivedContent="RFC6836"/> can take advantage of
security to BGP while LISP-DDT <xref target="RFC8111"/> defines standards work on adding
security to BGP, while LISP-DDT <xref target="RFC8111" format="default" sect
ionFormat="of" derivedContent="RFC8111"/> defines
its own additional security mechanisms.</t> its own additional security mechanisms.</t>
<t indent="0" pn="section-9-5">To publish an authoritative EID-to-RLOC map
<t>To publish an authoritative EID-to-RLOC mapping with a ping with a
Map-Server using the Map-Register message, an ETR includes Map-Server using the Map-Register message, an ETR includes
authentication data that is a MAC of the entire message using a Authentication Data that is a MAC of the entire message using a
key derived from the pre-shared secret. An implementation SHOULD support key derived from the pre-shared secret. An implementation <bcp14>SHOULD</bcp
HMAC-SHA256-128+HKDF-SHA256 <xref target="RFC5869"/>. The Map-Register 14> support
message includes protection for replay HMAC-SHA256-128+HKDF-SHA256 <xref target="RFC5869" format="default" secti
attacks by a man-in-the-middle. However, there is a potential attack where a onFormat="of" derivedContent="RFC5869"/>. The Map-Register
compromised ETR could overclaim message includes protection against replay
attacks by a man in the middle. However, there is a potential attack where a
compromised ETR could overclaim
the prefix it owns and successfully register it on its the prefix it owns and successfully register it on its
corresponding Map-Server. To mitigate this and as noted in <xref corresponding Map-Server. To mitigate this, as noted in <xref target="reg" f
target="reg"/>, a Map-Server MUST verify that all EID-Prefixes ormat="default" sectionFormat="of" derivedContent="Section 8.2"/>, a Map-Server
<bcp14>MUST</bcp14> verify that all EID-Prefixes
registered by an ETR match the configuration stored on the registered by an ETR match the configuration stored on the
Map-Server.</t> Map-Server.</t>
<t indent="0" pn="section-9-6">Deployments concerned about manipulations o
<t>Deployments concerned about manipulations of Map-Request and f Map-Request and
Map-Reply messages, and malicious ETR EID prefix overclaiming MUST Map-Reply messages and malicious ETR EID-Prefix overclaiming <bcp14>MUST</bc
drop LISP Control Plane messages that do not contain LISP-SEC p14>
material (S-bit, EID-AD, OTK-AD, PKT-AD).</t> drop LISP control plane messages that do not contain LISP-SEC
material (S-bit, EID-AD, OTK-AD, PKT-AD). See <xref target="RFC9303" section
<t>Mechanisms to encrypt, support privacy, prevent Format="of" section="3" format="default" derivedLink="https://rfc-editor.org/rfc
/rfc9303#section-3" derivedContent="RFC9303"/> for definitions of "EID-AD", "OTK
-AD", and "PKT-AD".</t>
<t indent="0" pn="section-9-7">Mechanisms to encrypt, support privacy, and
prevent
eavesdropping and packet tampering for messages eavesdropping and packet tampering for messages
exchanged between xTRs, xTRs and the mapping system, and nodes that exchanged between xTRs, between xTRs and the Mapping System, and between n
make up the mapping system, SHOULD be deployed. Examples of this are DTLS odes that
<xref target="RFC6347"/> or make up the Mapping System <bcp14>SHOULD</bcp14> be deployed. Examples of
LISP-crypto <xref target="RFC8061"/>.</t> this are DTLS <xref target="RFC9147" format="default" sectionFormat="of" derived
Content="RFC9147"/> or
</section> "lisp-crypto" <xref target="RFC8061" format="default" sectionFormat="of" der
ivedContent="RFC8061"/>.</t>
<section title="Privacy Considerations"> </section>
<t>As noted by <xref target="RFC6973"/> privacy is a complex issue <section numbered="true" toc="include" removeInRFC="false" pn="section-10">
that greatly depends on the specific protocol use-case and <name slugifiedName="name-privacy-considerations">Privacy Considerations</
deployment. As noted in section 1.1 of <xref name>
target="I-D.ietf-lisp-rfc6830bis"/> LISP focuses on use-cases <t indent="0" pn="section-10-1">As noted by <xref target="RFC6973" format=
"default" sectionFormat="of" derivedContent="RFC6973"/>, privacy is a complex is
sue
that greatly depends on the specific protocol use case and
deployment. As noted in <xref target="RFC9300" sectionFormat="of" section="1
.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9300#section-1.1
" derivedContent="RFC9300"/>, LISP focuses on use cases
where entities communicate over the public Internet while keeping where entities communicate over the public Internet while keeping
separate addressing and topology. In what follows we detail the separate addressing and topology. Here, we detail the
privacy threats introduced by the LISP Control Plane, the analysis privacy threats introduced by the LISP control plane; the analysis
is based on the guidelines detailed in <xref is based on the guidelines detailed in <xref target="RFC6973" format="defaul
target="RFC6973"/>.</t> t" sectionFormat="of" derivedContent="RFC6973"/>.</t>
<t indent="0" pn="section-10-2">LISP can use long-lived identifiers (EIDs)
<t>LISP can use long-lived identifiers (EIDs) that survive that survive
mobility events. Such identifiers bind to the RLOCs of the nodes, mobility events. Such identifiers bind to the RLOCs of the nodes.
which represents the topological location with respect to the The RLOCs represent the topological location with respect to the
specific LISP deployments. In addition, EID-to-RLOC mappings are specific LISP deployments. In addition, EID-to-RLOC mappings are
typically considered public information within the LISP typically considered public information within the LISP
deployment when control-plane messages are not encrypted, and can deployment when control plane messages are not encrypted and can
be eavesdropped while Map-Request messages are sent to the be eavesdropped while Map-Request messages are sent to the
corresponding Map-Resolvers or Map-Register messages to corresponding Map-Resolvers or Map-Register messages to
Map-Servers.</t> Map-Servers.</t>
<t indent="0" pn="section-10-3">In this context, attackers can correlate t
<t>In this context, attackers can correlate the EID with the RLOC he EID with the RLOC
and track the corresponding user topological location and/or and track the corresponding user topological location and/or
mobility. This can be achieved by off-path attackers, if they are mobility. This can be achieved by off-path attackers, if they are
authenticated, by querying the mapping system. Deployments authenticated, by querying the Mapping System. Deployments
concerned about this threat can use access control-lists or stronger concerned about this threat can use access control lists or stronger
authentication mechanisms <xref target="I-D.ietf-lisp-ecdsa-auth"/> in authentication mechanisms <xref target="I-D.ietf-lisp-ecdsa-auth" format="de
the mapping system to make sure that only authorized users can fault" sectionFormat="of" derivedContent="ECDSA-AUTH"/> in
the Mapping System to make sure that only authorized users can
access this information (data minimization). Use of ephemeral EIDs access this information (data minimization). Use of ephemeral EIDs
<xref target="I-D.ietf-lisp-eid-anonymity"/> to achieve anonymity is <xref target="I-D.ietf-lisp-eid-anonymity" format="default" sectionFormat="o f" derivedContent="EID-ANONYMITY"/> to achieve anonymity is
another mechanism to lessen persistency and identity tracking.</t> another mechanism to lessen persistency and identity tracking.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-11">
<section title="Changes since RFC 6833"> <name slugifiedName="name-changes-related-to-rfcs-683">Changes Related to
<t>For implementation considerations, the following major changes have RFCs 6830 and 6833</name>
been made to this document since RFC 6833 was published:</t> <t indent="0" pn="section-11-1">For implementation considerations, the fol
lowing major changes have
<t><list style="symbols"> been made to this document since <xref target="RFC6830" format="default" sec
<t>A Map-Notify-Ack message is added in this document to provide tionFormat="of" derivedContent="RFC6830"/> and <xref target="RFC6833" format="de
fault" sectionFormat="of" derivedContent="RFC6833"/> were published:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-11-
2">
<li pn="section-11-2.1">The 16-bit 'Key ID' field of the Map-Register an
d Map-Notify messages as defined in <xref target="RFC6830" format="default" sect
ionFormat="of" derivedContent="RFC6830"/> has been
split into an 8-bit 'Key ID' field and an 8-bit 'Algorithm ID' field. Not
e that this change also applies to the Map-Notify-Ack message defined by this do
cument. See Sections <xref target="MAPREG" format="counter" sectionFormat="of" d
erivedContent="5.6"/> and <xref target="MAP-NOTIF-MAP-NOTIF-ACK" format="counter
" sectionFormat="of" derivedContent="5.7"/>.</li>
<li pn="section-11-2.2">This document defines a Map-Notify-Ack message t
o provide
reliability for Map-Notify messages. Any receiver of a reliability for Map-Notify messages. Any receiver of a
Map-Notify message must respond with a Map-Notify-Ack Map-Notify message must respond with a Map-Notify-Ack
message. Map-Servers who are senders of Map-Notify messages, message. Map-Servers who are senders of Map-Notify messages
must queue the Map-Notify contents until they receive a must queue the Map-Notify contents until they receive a
Map-Notify-Ack with the nonce used in the Map-Notify Map-Notify-Ack with the nonce used in the Map-Notify
message. Note that implementations for Map-Notify-Ack support message. Note that implementations for Map-Notify-Ack support
already exist and predate this document.</t> already exist and predate this document.</li>
<li pn="section-11-2.3">This document has incorporated the codepoint for
<t>This document is incorporating the codepoint for the the
Map-Referral message from the LISP-DDT specification <xref Map-Referral message from the LISP-DDT specification <xref target="RFC8111
target="RFC8111"/> to indicate that a Map-Server must send the " format="default" sectionFormat="of" derivedContent="RFC8111"/> to indicate tha
t a Map-Server must send the
final Map-Referral message when it participates in the LISP-DDT final Map-Referral message when it participates in the LISP-DDT
mapping system procedures.</t> Mapping System procedures.</li>
<li pn="section-11-2.4">Bits L and D have been added to the
<t>The L" and "D" bits are added to the Map-Request message. See <xref target="MAPREQ" format="default" sectionFor
Map-Request message. See <xref target="MAPREQ"/> for details.</t> mat="of" derivedContent="Section 5.3"/> for details.</li>
<li pn="section-11-2.5">Bits S, I, E, T, a, R, and M have been added to
<t>The "S", "I", "E", "T", "a", "R", and "M" bits are added to the the
Map-Register message. See <xref target="MAPREG"/> for details.</t> Map-Register message. See <xref target="MAPREG" format="default" sectionFo
rmat="of" derivedContent="Section 5.6"/> for details.</li>
<t>The 16-bit Key-ID field of the Map-Register message has been <li pn="section-11-2.6">The nonce and the Authentication Data in the Map
split into a 8-bit Key-ID field and a 8-bit Algorithm-ID field.</t> -Register message
each behave differently; see <xref target="MAPREG" format="default" section
<t>The nonce and the authentication data in the Map-Register message Format="of" derivedContent="Section 5.6"/> for details.</li>
have a different behaviour, see <xref target="MAPREG"/> for details.</t> <li pn="section-11-2.7">This document adds two new action values that ar
e in an
<t>This document adds two new Action values that are in an EID-Record that appears in Map-Reply, Map-Register, Map-Notify,
EID-record that appear in Map-Reply, Map-Register, Map-Notify, and Map-Notify-Ack messages. These new action values are Drop/Policy-Denie
and Map-Notify-Ack messages. The Drop/Policy-Denied and d and
Drop/Auth-Failure are the descriptions for the two new action Drop/Auth-Failure. See <xref target="MR-FORMAT" format="default" sectionFo
values. See <xref target="MR-FORMAT"/> for details.</t> rmat="of" derivedContent="Section 5.4"/> for details.</li>
</list></t> </ul>
</section>
<section title="IANA Considerations">
<t>This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to this
LISP Control-Plane specification, in accordance with BCP 26 <xref
target="RFC8126" />.</t>
<t>There are three namespaces (listed in the sub-sections below) in
LISP that have been registered.</t>
<t><list style="symbols">
<t>LISP IANA registry allocations should not be made for
purposes unrelated to LISP routing or transport protocols.</t>
<t>The following policies are used here with the meanings
defined in BCP 26: "Specification Required", "IETF Review",
"Experimental Use", and "First Come First Served".</t>
</list></t>
<section title="LISP UDP Port Numbers">
<t>The IANA registry has allocated UDP port number 4342 for the
LISP Control-Plane. IANA has updated the description for UDP
port 4342 as follows:</t>
<figure> <artwork><![CDATA[
Keyword Port Transport Layer Description
------- ---- --------------- -----------
lisp-control 4342 udp LISP Control Packets
]]></artwork> </figure>
</section>
<section title="LISP Packet Type Codes">
<t>It is being requested that the IANA be authoritative for LISP
Packet Type definitions and it is requested to replace the <xref
target="RFC6830"/> registry message references with the RFC
number assigned to this document.</t>
<t>Based on deployment experience of <xref target="RFC6830"/>,
the Map-Notify-Ack message, message type 5, was added by this
document. This document requests IANA to add it to the LISP
Packet Type Registry.</t>
<figure> <artwork><![CDATA[
Name Number Defined in
---- ------ -----------
LISP Map-Notify-Ack 5 RFC6833bis
]]></artwork> </figure>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-12">
<section title="LISP Map-Reply EID-Record Action Codes" anchor="act-iana"> <name slugifiedName="name-iana-considerations">IANA Considerations</name>
<t indent="0" pn="section-12-1">This section provides guidance to IANA reg
<t>New ACT values can be allocated through IETF review or IESG arding registration of values related to this
approval. Four values have already been allocated by <xref LISP control plane specification, in accordance with <xref target="RFC8126"
target="RFC6830"/>. IANA is requested to replace the <xref format="default" sectionFormat="of" derivedContent="RFC8126">BCP 26</xref>.</t>
target="RFC6830"/> reference for this registry with the RFC <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-12-
number assigned to this document and <xref 2">
target="RFC6830"/>. This specification changes the name <li pn="section-12-2.1">LISP IANA registry allocations should not be mad
of ACT type 3 value from "Drop" to "Drop/No-Reason" as well as e for
adding two new ACT values, the "Drop/Policy-Denied" (type 4) and purposes unrelated to LISP routing or transport protocols.</li>
"Drop/Authentication-Failure" (type 5).</t> <li pn="section-12-2.2">The following policies are used here with the me
anings
<texttable title="LISP Map-Reply Action Values"> defined in <xref target="RFC8126" format="default" sectionFormat="of" deri
<ttcol align='left'>Value</ttcol> vedContent="RFC8126">BCP 26</xref>: "Specification Required", "IETF Review",
<ttcol align='left'>Action</ttcol> "Experimental Use", and "First Come First Served".</li>
<ttcol align='left'>Description</ttcol> </ul>
<ttcol align='left'>Raeference</ttcol> <t indent="0" pn="section-12-3">There are three namespaces (listed in the
<c>4</c> sub-sections below) in
<c>Drop/Policy-Denied</c> LISP that have been registered (see <xref target="RFC9299" format="default"
<c>A packet matching this Map-Cache entry is dropped because sectionFormat="of" derivedContent="RFC9299"/>.</t>
the target EWID is policy-denied by the xTR or the mapping <section numbered="true" toc="include" removeInRFC="false" pn="section-12.
system.</c> 1">
<c>RFC6833bis</c> <name slugifiedName="name-lisp-udp-port-numbers">LISP UDP Port Numbers</
<c>5</c> name>
<c>Drop/Auth-Failure</c> <t indent="0" pn="section-12.1-1">IANA allocated UDP port number 4342 fo
<c>Packet matching the Map-Cache entry is dropped beacuse the r the
LISP control plane. IANA has updated the description for UDP
port 4342 to reflect the following:</t>
<table align="center" pn="table-2">
<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-control</td>
<td align="left" colspan="1" rowspan="1">4342</td>
<td align="left" colspan="1" rowspan="1">udp</td>
<td align="left" colspan="1" rowspan="1">LISP Control Packets</td>
<td align="left" colspan="1" rowspan="1">RFC 9301</td>
</tr>
</tbody>
</table>
</section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-12.
2">
<name slugifiedName="name-lisp-packet-type-codes">LISP Packet Type Codes
</name>
<t indent="0" pn="section-12.2-1">IANA is now authoritative for LISP
Packet Type definitions, so they have replaced the registry
references to <xref target="RFC6830" format="default" sectionFormat="of" d
erivedContent="RFC6830"/> with references to this document.</t>
<t indent="0" pn="section-12.2-2">Based on deployment experience related
to <xref target="RFC6830" format="default" sectionFormat="of" derivedContent="R
FC6830"/>,
the Map-Notify-Ack message (message type 5) is defined in this
document. IANA has registered it in the "LISP
Packet Types" registry.</t>
<table align="center" pn="table-3">
<thead>
<tr>
<th align="left" colspan="1" rowspan="1">Message</th>
<th align="left" colspan="1" rowspan="1">Code</th>
<th align="left" colspan="1" rowspan="1">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left" colspan="1" rowspan="1">LISP Map-Notify-Ack</td>
<td align="left" colspan="1" rowspan="1">5</td>
<td align="left" colspan="1" rowspan="1">RFC 9301</td>
</tr>
</tbody>
</table>
</section>
<section anchor="act-iana" numbered="true" toc="include" removeInRFC="fals
e" pn="section-12.3">
<name slugifiedName="name-lisp-map-reply-eid-record-a">LISP Map-Reply EI
D-Record Action Codes</name>
<t indent="0" pn="section-12.3-1">New ACT values can be allocated throug
h IETF Review or IESG
Approval. Four values have already been allocated by <xref target="RFC6830
" format="default" sectionFormat="of" derivedContent="RFC6830"/>. IANA has repla
ced the reference pointing to <xref target="RFC6830" format="default" sectionFor
mat="of" derivedContent="RFC6830"/> to point to this document. This specificati
on changes the Action name
of value 3 from "Drop" to "Drop/No-Reason". It also adds the following
new ACT values.</t>
<table align="center" pn="table-4">
<name slugifiedName="name-lisp-map-reply-action-value">LISP Map-Reply
Action Values</name>
<thead>
<tr>
<th align="left" colspan="1" rowspan="1">Value</th>
<th align="left" colspan="1" rowspan="1">Action</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">4</td>
<td align="left" colspan="1" rowspan="1">Drop/Policy-Denied</td>
<td align="left" colspan="1" rowspan="1">A packet matching this Ma
p-Cache entry is dropped because
the target EID is policy-denied by the xTR or the Mapping
System.</td>
<td align="left" colspan="1" rowspan="1">RFC 9301</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">5</td>
<td align="left" colspan="1" rowspan="1">Drop/Auth-Failure</td>
<td align="left" colspan="1" rowspan="1">A packet matching this Ma
p-Cache entry is dropped because the
Map-Request for the target EID fails an authentication check Map-Request for the target EID fails an authentication check
by the xTR or the mapping system.</c> by the xTR or the Mapping System.</td>
<c>RFC6833bis</c> <td align="left" colspan="1" rowspan="1">RFC 9301</td>
</texttable> </tr>
</tbody>
<t>In addition, LISP has a number of flag fields and reserved </table>
fields, such as the LISP header flags field <xref <t indent="0" pn="section-12.3-3">In addition, LISP has a number of flag
target="I-D.ietf-lisp-rfc6830bis" />. New bits for flags in fields and reserved
these fields can be implemented after IETF review or IESG fields, such as the flags of the LISP header fields <xref target="RFC9300"
approval, but these need not be managed by IANA.</t> format="default" sectionFormat="of" derivedContent="RFC9300"/>. New bits for fl
</section> ags in
these fields can be implemented after IETF Review or IESG
<section anchor="IANA" title="LISP Address Type Codes"> Approval, but these need not be managed by IANA.</t>
<t>LISP Canonical Address Format (LCAF) <xref target="RFC8060"/> </section>
is an 8-bit field that defines LISP-specific encodings for AFI <section anchor="IANA" numbered="true" toc="include" removeInRFC="false" p
value 16387. LCAF encodings are used for specific use-cases n="section-12.4">
where different address types for EID-records and RLOC-records <name slugifiedName="name-lisp-address-type-codes">LISP Address Type Cod
es</name>
<t indent="0" pn="section-12.4-1">LISP Canonical Address Format (LCAF) <
xref target="RFC8060" format="default" sectionFormat="of" derivedContent="RFC806
0"/>
has an 8-bit Type field that defines LISP-specific encodings for AFI
value 16387. LCAF encodings are used for specific use cases
where different address types for EID-Records and RLOC-Records
are required.</t> are required.</t>
<t indent="0" pn="section-12.4-2">The "LISP Canonical Address Format (LC
<t>The IANA registry "LISP Canonical Address Format (LCAF) AF)
Types" is used for LCAF types. The registry for LCAF types use Types" registry is used for LCAF types. The registry for LCAF types uses
the Specification Required policy <xref the Specification Required policy <xref target="RFC8126" format="default"
target="RFC8126"/>. Initial values for the registry as well as sectionFormat="of" derivedContent="RFC8126"/>. Initial values for the registry a
further information can be found in <xref s well as
target="RFC8060"/>.</t> further information can be found in <xref target="RFC8060" format="default
" sectionFormat="of" derivedContent="RFC8060"/>.</t>
<t>Therefore, there is no longer a need for the "LISP Address Type <t indent="0" pn="section-12.4-3">Therefore, there is no longer a need f
Codes" registry requested by <xref target="RFC6830"/>. This document or the "LISP Address Type
requests to remove it.</t> Codes" registry requested by <xref target="RFC6830" format="default" secti
</section> onFormat="of" derivedContent="RFC6830"/>. Per this document,
the registry has been closed.</t>
<section title="LISP Algorithm ID Numbers" anchor="KEYS"> </section>
<t>In <xref target="RFC6830"/>, a request for a "LISP Key ID <section anchor="KEYS" numbered="true" toc="include" removeInRFC="false" p
Numbers" registry was submitted. This document renames the n="section-12.5">
registry to "LISP Algorithm ID Numbers" and requests the IANA to <name slugifiedName="name-lisp-algorithm-id-numbers">LISP Algorithm ID N
make the name change.</t> umbers</name>
<t indent="0" pn="section-12.5-1">In <xref target="RFC6830" format="defa
<t>The following Algorithm ID values are defined by this ult" sectionFormat="of" derivedContent="RFC6830"/>, a request for a "LISP Key ID
specification as used in any packet type that references a Numbers" registry was submitted. Per this document, IANA has renamed the
registry to "LISP Algorithm ID Numbers" and listed this document as the re
gistry reference.</t>
<t indent="0" pn="section-12.5-2">The following Algorithm ID values are
defined by this
specification, as used in any packet type that references an
'Algorithm ID' field:</t> 'Algorithm ID' field:</t>
<table align="center" pn="table-5">
<figure> <artwork><![CDATA[ <thead>
Name Number MAC KDF <tr>
------------------------------------------------------- <th align="left" colspan="1" rowspan="1">Name</th>
None 0 None None <th align="left" colspan="1" rowspan="1">Number</th>
HMAC-SHA-1-96-None 1 [RFC2404] None <th align="left" colspan="1" rowspan="1">MAC</th>
HMAC-SHA-256-128-None 2 [RFC4868] None <th align="left" colspan="1" rowspan="1">KDF</th>
HMAC-SHA256-128+HKDF-SHA256 3 [RFC4868] [RFC4868] </tr>
]]></artwork> </figure> </thead>
<tbody>
<t>Number values are in the range of 0 to 255. The allocation of <tr>
values is on a first come first served basis.</t> <td align="left" colspan="1" rowspan="1">None</td>
</section> <td align="left" colspan="1" rowspan="1">0</td>
<td align="left" colspan="1" rowspan="1">None</td>
<section title="LISP Bit Flags" anchor="BITS"> <td align="left" colspan="1" rowspan="1">None</td>
<t>This document asks IANA to create a registry for allocation </tr>
<tr>
<td align="left" colspan="1" rowspan="1">HMAC-SHA-1-96-None</td>
<td align="left" colspan="1" rowspan="1">1</td>
<td align="left" colspan="1" rowspan="1">
<xref target="RFC2404" format="default" sectionFormat="of" deriv
edContent="RFC2404"/></td>
<td align="left" colspan="1" rowspan="1">None</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">HMAC-SHA-256-128-None</td
>
<td align="left" colspan="1" rowspan="1">2</td>
<td align="left" colspan="1" rowspan="1">
<xref target="RFC4868" format="default" sectionFormat="of" deriv
edContent="RFC4868"/></td>
<td align="left" colspan="1" rowspan="1">None</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">HMAC-SHA256-128+HKDF-SHA2
56</td>
<td align="left" colspan="1" rowspan="1">3</td>
<td align="left" colspan="1" rowspan="1">
<xref target="RFC4868" format="default" sectionFormat="of" deriv
edContent="RFC4868"/></td>
<td align="left" colspan="1" rowspan="1">
<xref target="RFC4868" format="default" sectionFormat="of" deriv
edContent="RFC4868"/></td>
</tr>
</tbody>
</table>
<t indent="0" pn="section-12.5-4">Number values are in the range of 0 to
255.
Values are assigned on a First Come First Served basis.</t>
</section>
<section anchor="BITS" numbered="true" toc="include" removeInRFC="false" p
n="section-12.6">
<name slugifiedName="name-lisp-bit-flags">LISP Bit Flags</name>
<t indent="0" pn="section-12.6-1">This document asks IANA to create a re
gistry for allocation
of bits in several headers of the LISP control plane, namely in of bits in several headers of the LISP control plane, namely in
the Map-Request, Map-Reply, Map-Register, Encapsulated Control Map-Request messages, Map-Reply messages, Map-Register messages, and Encap
Message (ECM) messages. Bit allocations are also requested for sulated Control Messages. Bit allocations are also requested for
EID-records and RLOC-records. The registry created should EID-Records and RLOC-Records. The registry created should
be named "LISP Control Plane Header Bits". A sub-registry be named "LISP Control Plane Header Bits". A subregistry
needs to be created per each message and EID-record. The name of each needs to be created per each message and EID-Record. The name of each
sub-registry is indicated below, along with its format subregistry is indicated below, along with its format
and allocation of bits defined in this document. Any additional and allocation of bits defined in this document. Any additional
bits allocation, requires a specification, according with <xref bit allocations require a specification, in accordance with policies defin
target="RFC8126"/> policies.</t> ed in <xref target="RFC8126" format="default" sectionFormat="of" derivedContent=
"RFC8126"/>.</t>
<t>Sub-Registry: Map-Request Header Bits [<xref target="NONCE"/>]:</t> <t indent="0" pn="section-12.6-2">Subregistry: Map-Request Header Bits (
<figure><artwork> <xref target="NONCE" format="default" sectionFormat="of" derivedContent="Section
5.2"/>):</t>
<artwork name="" type="" align="left" alt="" pn="section-12.6-3">
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=1 |A|M|P|S|p|s|R|R| Rsvd |L|D| IRC | Record Count | |Type=1 |A|M|P|S|p|s|R|R| Rsvd |L|D| IRC | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork></figure> </artwork>
<table align="center" pn="table-6">
<texttable title="LISP Map-Request Header Bits"> <name slugifiedName="name-lisp-map-request-header-bit">LISP Map-Reques
<ttcol align='left'>Spec Name</ttcol> t Header Bits</name>
<ttcol align='left'>IANA Name</ttcol> <thead>
<ttcol align='left'>Bit Position</ttcol> <tr>
<ttcol align='left'>Description</ttcol> <th align="left" colspan="1" rowspan="1">Spec Name</th>
<c>A</c><c>map-request-A</c><c>4</c><c>Authoritative Bit</c> <th align="left" colspan="1" rowspan="1">IANA Name</th>
<c>M</c><c>map-request-M</c><c>5</c><c>Map Data Present Bit</c> <th align="left" colspan="1" rowspan="1">Bit Position</th>
<c>P</c><c>map-request-P</c><c>6</c><c>RLOC-Probe Request Bit</c> <th align="left" colspan="1" rowspan="1">Description</th>
<c>S</c><c>map-request-S</c><c>7</c><c>Solicit Map-Request (SMR) </tr>
Bit</c> </thead>
<c>p</c><c>map-request-p</c><c>8</c><c>Proxy-ITR Bit</c> <tbody>
<c>s</c><c>map-request-s</c><c>9</c><c>Solicit Map-Request Invoked <tr>
Bit</c> <td align="left" colspan="1" rowspan="1">A</td>
<c>L</c><c>map-request-L</c><c>17</c><c>Local xTR Bit</c> <td align="left" colspan="1" rowspan="1">Map-Request-A</td>
<c>D</c><c>map-request-D</c><c>18</c><c>Don't Map-Reply Bit</c> <td align="left" colspan="1" rowspan="1">4</td>
</texttable> <td align="left" colspan="1" rowspan="1">Authoritative Bit</td>
</tr>
<t>Sub-Registry: Map-Reply Header Bits [<xref target="MR-FORMAT"/>]:</t> <tr>
<figure><artwork> <td align="left" colspan="1" rowspan="1">M</td>
0 1 2 3 <td align="left" colspan="1" rowspan="1">Map-Request-M</td>
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 <td align="left" colspan="1" rowspan="1">5</td>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <td align="left" colspan="1" rowspan="1">Map Data Present Bit</td>
|Type=2 |P|E|S| Reserved | Record Count | </tr>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <tr>
</artwork></figure> <td align="left" colspan="1" rowspan="1">P</td>
<td align="left" colspan="1" rowspan="1">Map-Request-P</td>
<texttable title="LISP Map-Reply Header Bits"> <td align="left" colspan="1" rowspan="1">6</td>
<ttcol align='left'>Spec Name</ttcol> <td align="left" colspan="1" rowspan="1">RLOC-Probe Request Bit</t
<ttcol align='left'>IANA Name</ttcol> d>
<ttcol align='left'>Bit Position</ttcol> </tr>
<ttcol align='left'>Description</ttcol> <tr>
<c>P</c><c>map-reply-P</c><c>4</c><c>RLOC-Probe Bit</c> <td align="left" colspan="1" rowspan="1">S</td>
<c>E</c><c>map-reply-E</c><c>5</c><c>Echo Nonce Capable Bit</c> <td align="left" colspan="1" rowspan="1">Map-Request-S</td>
<c>S</c><c>map-reply-S</c><c>6</c><c>Security Bit</c> <td align="left" colspan="1" rowspan="1">7</td>
</texttable> <td align="left" colspan="1" rowspan="1">Solicit Map-Request (SMR)
Bit</td>
<t>Sub-Registry: Map-Register Header Bits [<xref target="MAPREG"/>]:</t> </tr>
<figure><artwork> <tr>
<td align="left" colspan="1" rowspan="1">p</td>
<td align="left" colspan="1" rowspan="1">Map-Request-p</td>
<td align="left" colspan="1" rowspan="1">8</td>
<td align="left" colspan="1" rowspan="1">Proxy-ITR Bit</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">s</td>
<td align="left" colspan="1" rowspan="1">Map-Request-s</td>
<td align="left" colspan="1" rowspan="1">9</td>
<td align="left" colspan="1" rowspan="1">Solicit Map-Request Invok
ed
Bit</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">L</td>
<td align="left" colspan="1" rowspan="1">Map-Request-L</td>
<td align="left" colspan="1" rowspan="1">17</td>
<td align="left" colspan="1" rowspan="1">Local xTR Bit</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">D</td>
<td align="left" colspan="1" rowspan="1">Map-Request-D</td>
<td align="left" colspan="1" rowspan="1">18</td>
<td align="left" colspan="1" rowspan="1">Don't Map-Reply Bit</td>
</tr>
</tbody>
</table>
<t indent="0" pn="section-12.6-5">Subregistry: Map-Reply Header Bits (<x
ref target="MR-FORMAT" format="default" sectionFormat="of" derivedContent="Secti
on 5.4"/>):</t>
<artwork name="" type="" align="left" alt="" pn="section-12.6-6">
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=2 |P|E|S| Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
<table align="center" pn="table-7">
<name slugifiedName="name-lisp-map-reply-header-bits">LISP Map-Reply H
eader Bits</name>
<thead>
<tr>
<th align="left" colspan="1" rowspan="1">Spec Name</th>
<th align="left" colspan="1" rowspan="1">IANA Name</th>
<th align="left" colspan="1" rowspan="1">Bit Position</th>
<th align="left" colspan="1" rowspan="1">Description</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left" colspan="1" rowspan="1">P</td>
<td align="left" colspan="1" rowspan="1">Map-Reply-P</td>
<td align="left" colspan="1" rowspan="1">4</td>
<td align="left" colspan="1" rowspan="1">RLOC-Probe Bit</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">E</td>
<td align="left" colspan="1" rowspan="1">Map-Reply-E</td>
<td align="left" colspan="1" rowspan="1">5</td>
<td align="left" colspan="1" rowspan="1">Echo-Nonce Capable Bit</t
d>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">S</td>
<td align="left" colspan="1" rowspan="1">Map-Reply-S</td>
<td align="left" colspan="1" rowspan="1">6</td>
<td align="left" colspan="1" rowspan="1">Security Bit</td>
</tr>
</tbody>
</table>
<t indent="0" pn="section-12.6-8">Subregistry: Map-Register Header Bits
(<xref target="MAPREG" format="default" sectionFormat="of" derivedContent="Secti
on 5.6"/>):</t>
<artwork name="" type="" align="left" alt="" pn="section-12.6-9">
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=3 |P|S|I| Reserved |E|T|a|R|M| Record Count | |Type=3 |P|S|I| Reserved |E|T|a|R|M| Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork></figure> </artwork>
<table align="center" pn="table-8">
<texttable title="LISP Map-Register Header Bits"> <name slugifiedName="name-lisp-map-register-header-bi">LISP Map-Regist
<ttcol align='left'>Spec Name</ttcol> er Header Bits</name>
<ttcol align='left'>IANA Name</ttcol> <thead>
<ttcol align='left'>Bit Position</ttcol> <tr>
<ttcol align='left'>Description</ttcol> <th align="left" colspan="1" rowspan="1">Spec Name</th>
<c>P</c><c>map-register-P</c><c>4</c><c>Proxy Map-Reply Bit</c> <th align="left" colspan="1" rowspan="1">IANA Name</th>
<c>S</c><c>map-register-S</c><c>5</c><c>LISP-SEC Capable Bit</c> <th align="left" colspan="1" rowspan="1">Bit Position</th>
<c>I</c><c>map-register-I</c><c>6</c><c>xTR-ID present flag</c> <th align="left" colspan="1" rowspan="1">Description</th>
</texttable> </tr>
</thead>
<t>Sub-Registry: Encapsulated Control Message (ECM) Header Bits <tbody>
[<xref target="encap-mr"/>]:</t> <tr>
<figure><artwork> <td align="left" colspan="1" rowspan="1">P</td>
<td align="left" colspan="1" rowspan="1">Map-Register-P</td>
<td align="left" colspan="1" rowspan="1">4</td>
<td align="left" colspan="1" rowspan="1">Proxy Map-Reply Bit</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">S</td>
<td align="left" colspan="1" rowspan="1">Map-Register-S</td>
<td align="left" colspan="1" rowspan="1">5</td>
<td align="left" colspan="1" rowspan="1">LISP-SEC Capable Bit</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">I</td>
<td align="left" colspan="1" rowspan="1">Map-Register-I</td>
<td align="left" colspan="1" rowspan="1">6</td>
<td align="left" colspan="1" rowspan="1">xTR-ID Present Bit</td>
</tr>
</tbody>
</table>
<t indent="0" pn="section-12.6-11">Subregistry: Encapsulated Control Mes
sage (ECM) Header Bits
(<xref target="encap-mr" format="default" sectionFormat="of" derivedConten
t="Section 5.8"/>):</t>
<artwork name="" type="" align="left" alt="" pn="section-12.6-12">
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=8 |S|D|E|M| Reserved | |Type=8 |S|D|E|M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork></figure> </artwork>
<table align="center" pn="table-9">
<texttable title="LISP Encapsulated Control Message (ECM) Header Bits"> <name slugifiedName="name-lisp-encapsulated-control-m">LISP Encapsulat
<ttcol align='left'>Spec Name</ttcol> ed Control Message (ECM) Header Bits</name>
<ttcol align='left'>IANA Name</ttcol> <thead>
<ttcol align='left'>Bit Position</ttcol> <tr>
<ttcol align='left'>Description</ttcol> <th align="left" colspan="1" rowspan="1">Spec Name</th>
<c>S</c><c>ecm-S</c><c>4</c><c>Security Bit</c> <th align="left" colspan="1" rowspan="1">IANA Name</th>
<c>D</c><c>ecm-D</c><c>5</c><c>LISP-DDT Bit</c> <th align="left" colspan="1" rowspan="1">Bit Position</th>
<c>E</c><c>ecm-E</c><c>6</c><c>Forward to ETR Bit</c> <th align="left" colspan="1" rowspan="1">Description</th>
<c>M</c><c>ecm-M</c><c>7</c><c>Destined to Map-Server Bit</c> </tr>
</texttable> </thead>
<tbody>
<t>Sub-Registry: EID-Record Header Bits [<xref target="MR-FORMAT"/>]:</t> <tr>
<figure><artwork> <td align="left" colspan="1" rowspan="1">S</td>
0 1 2 3 <td align="left" colspan="1" rowspan="1">ECM-S</td>
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 <td align="left" colspan="1" rowspan="1">4</td>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <td align="left" colspan="1" rowspan="1">Security Bit</td>
| Locator Count | EID mask-len | ACT |A| Reserved | </tr>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <tr>
</artwork></figure> <td align="left" colspan="1" rowspan="1">D</td>
<td align="left" colspan="1" rowspan="1">ECM-D</td>
<texttable title="LISP EID-Record Header Bits"> <td align="left" colspan="1" rowspan="1">5</td>
<ttcol align='left'>Spec Name</ttcol> <td align="left" colspan="1" rowspan="1">LISP-DDT Bit</td>
<ttcol align='left'>IANA Name</ttcol> </tr>
<ttcol align='left'>Bit Position</ttcol> <tr>
<ttcol align='left'>Description</ttcol> <td align="left" colspan="1" rowspan="1">E</td>
<c>A</c><c>eid-record-A</c><c>19</c><c>Authoritative Bit</c> <td align="left" colspan="1" rowspan="1">ECM-E</td>
</texttable> <td align="left" colspan="1" rowspan="1">6</td>
<td align="left" colspan="1" rowspan="1">Forward to ETR Bit</td>
<t>Sub-Registry: RLOC-Record Header Bits [<xref </tr>
target="MR-FORMAT"/>]:</t> <tr>
<figure><artwork> <td align="left" colspan="1" rowspan="1">M</td>
0 1 2 3 <td align="left" colspan="1" rowspan="1">ECM-M</td>
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 <td align="left" colspan="1" rowspan="1">7</td>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <td align="left" colspan="1" rowspan="1">Destined to Map-Server Bi
| Unused Flags |L|p|R| Loc-AFI | t</td>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </tr>
</artwork></figure> </tbody>
</table>
<texttable title="LISP RLOC-Record Header Bits"> <t indent="0" pn="section-12.6-14">Subregistry: EID-Record Header Bits (
<ttcol align='left'>Spec Name</ttcol> <xref target="MR-FORMAT" format="default" sectionFormat="of" derivedContent="Sec
<ttcol align='left'>IANA Name</ttcol> tion 5.4"/>):</t>
<ttcol align='left'>Bit Position</ttcol> <artwork name="" type="" align="left" alt="" pn="section-12.6-15">
<ttcol align='left'>Description</ttcol> 0 1 2 3
<c>L</c><c>rloc-record-L</c><c>13</c><c>Local RLOC Bit</c> 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
<c>p</c><c>rloc-record-p</c><c>19</c><c>RLOC-Probe Reply Bit</c> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<c>R</c><c>rloc-record-R</c><c>19</c><c>RLOC Reachable Bit</c> | Locator Count | EID mask-len | ACT |A| Reserved |
</texttable> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
<table align="center" pn="table-10">
<name slugifiedName="name-lisp-eid-record-header-bits">LISP EID-Record
Header Bits</name>
<thead>
<tr>
<th align="left" colspan="1" rowspan="1">Spec Name</th>
<th align="left" colspan="1" rowspan="1">IANA Name</th>
<th align="left" colspan="1" rowspan="1">Bit Position</th>
<th align="left" colspan="1" rowspan="1">Description</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left" colspan="1" rowspan="1">A</td>
<td align="left" colspan="1" rowspan="1">EID-Record-A</td>
<td align="left" colspan="1" rowspan="1">19</td>
<td align="left" colspan="1" rowspan="1">Authoritative Bit</td>
</tr>
</tbody>
</table>
<t indent="0" pn="section-12.6-17">Subregistry: RLOC-Record Header Bits
(<xref target="MR-FORMAT" format="default" sectionFormat="of" derivedContent="Se
ction 5.4"/>):</t>
<artwork name="" type="" align="left" alt="" pn="section-12.6-18">
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused Flags |L|p|R| Loc-AFI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
<table align="center" pn="table-11">
<name slugifiedName="name-lisp-rloc-record-header-bit">LISP RLOC-Recor
d Header Bits</name>
<thead>
<tr>
<th align="left" colspan="1" rowspan="1">Spec Name</th>
<th align="left" colspan="1" rowspan="1">IANA Name</th>
<th align="left" colspan="1" rowspan="1">Bit Position</th>
<th align="left" colspan="1" rowspan="1">Description</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left" colspan="1" rowspan="1">L</td>
<td align="left" colspan="1" rowspan="1">RLOC-Record-L</td>
<td align="left" colspan="1" rowspan="1">13</td>
<td align="left" colspan="1" rowspan="1">Local RLOC Bit</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">p</td>
<td align="left" colspan="1" rowspan="1">RLOC-Record-p</td>
<td align="left" colspan="1" rowspan="1">14</td>
<td align="left" colspan="1" rowspan="1">RLOC-Probe Reply Bit</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">R</td>
<td align="left" colspan="1" rowspan="1">RLOC-Record-R</td>
<td align="left" colspan="1" rowspan="1">15</td>
<td align="left" colspan="1" rowspan="1">RLOC Reachable Bit</td>
</tr>
</tbody>
</table>
</section>
</section> </section>
</middle>
<back>
<displayreference target="I-D.ietf-lisp-eid-anonymity" to="EID-ANONYMITY"/>
<displayreference target="I-D.ietf-lisp-ecdsa-auth" to="ECDSA-AUTH"/>
<displayreference target="I-D.ietf-lisp-mn" to="LISP-MN"/>
<displayreference target="I-D.ietf-lisp-pubsub" to="LISP-PUBSUB"/>
<displayreference target="I-D.ietf-opsec-icmp-filtering" to="OPSEC-ICMP-FILT
ER"/>
<displayreference target="I-D.herbert-intarea-ila" to="INTAREA-ILA"/>
<references pn="section-13">
<name slugifiedName="name-references">References</name>
<references pn="section-13.1">
<name slugifiedName="name-normative-references">Normative References</na
me>
<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="RFC2404" target="https://www.rfc-editor.org/info/rfc2
404" quoteTitle="true" derivedAnchor="RFC2404">
<front>
<title>The Use of HMAC-SHA-1-96 within ESP and AH</title>
<author fullname="C. Madson" initials="C." surname="Madson"/>
<author fullname="R. Glenn" initials="R." surname="Glenn"/>
<date month="November" year="1998"/>
<abstract>
<t indent="0">This memo describes the use of the HMAC algorithm in
conjunction with the SHA-1 algorithm as an authentication mechanism within the
revised IPSEC Encapsulating Security Payload and the revised IPSEC Authenticatio
n Header. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2404"/>
<seriesInfo name="DOI" value="10.17487/RFC2404"/>
</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="RFC4868" target="https://www.rfc-editor.org/info/rfc4
868" quoteTitle="true" derivedAnchor="RFC4868">
<front>
<title>Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec
</title>
<author fullname="S. Kelly" initials="S." surname="Kelly"/>
<author fullname="S. Frankel" initials="S." surname="Frankel"/>
<date month="May" year="2007"/>
<abstract>
<t indent="0">This specification describes the use of Hashed Messa
ge Authentication Mode (HMAC) in conjunction with the SHA-256, SHA-384, and SHA-
512 algorithms in IPsec. These algorithms may be used as the basis for data ori
gin authentication and integrity verification mechanisms for the Authentication
Header (AH), Encapsulating Security Payload (ESP), Internet Key Exchange Protoco
l (IKE), and IKEv2 protocols, and also as Pseudo-Random Functions (PRFs) for IKE
and IKEv2. Truncated output lengths are specified for the authentication-relat
ed variants, with the corresponding algorithms designated as HMAC-SHA-256-128, H
MAC-SHA-384-192, and HMAC-SHA-512-256. The PRF variants are not truncated, and
are called PRF-HMAC-SHA-256, PRF-HMAC-SHA-384, and PRF-HMAC-SHA-512. [STANDARDS-
TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4868"/>
<seriesInfo name="DOI" value="10.17487/RFC4868"/>
</reference>
<reference anchor="RFC5869" target="https://www.rfc-editor.org/info/rfc5
869" quoteTitle="true" derivedAnchor="RFC5869">
<front>
<title>HMAC-based Extract-and-Expand Key Derivation Function (HKDF)<
/title>
<author fullname="H. Krawczyk" initials="H." surname="Krawczyk"/>
<author fullname="P. Eronen" initials="P." surname="Eronen"/>
<date month="May" year="2010"/>
<abstract>
<t indent="0">This document specifies a simple Hashed Message Auth
entication Code (HMAC)-based key derivation function (HKDF), which can be used a
s a building block in various protocols and applications. The key derivation fu
nction (KDF) is intended to support a wide range of applications and requirement
s, and is conservative in its use of cryptographic hash functions. This documen
t is not an Internet Standards Track specification; it is published for informat
ional purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5869"/>
<seriesInfo name="DOI" value="10.17487/RFC5869"/>
</reference>
<reference anchor="RFC6833" target="https://www.rfc-editor.org/info/rfc6
833" quoteTitle="true" derivedAnchor="RFC6833">
<front>
<title>Locator/ID Separation Protocol (LISP) Map-Server Interface</t
itle>
<author fullname="V. Fuller" initials="V." surname="Fuller"/>
<author fullname="D. Farinacci" initials="D." surname="Farinacci"/>
<date month="January" year="2013"/>
<abstract>
<t indent="0">This document describes the Mapping Service for the
Locator/ID Separation Protocol (LISP), implemented by two new types of LISP- spe
aking devices -- the LISP Map-Resolver and LISP Map-Server -- that provides a si
mplified "front end" for one or more Endpoint ID to Routing Locator mapping data
bases.</t>
<t indent="0">By using this service interface and communicating wi
th Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers and Egress Tunnel
Routers are not dependent on the details of mapping database systems, which faci
litates experimentation with different database designs. Since these devices imp
lement the "edge" of the LISP infrastructure, connect directly to LISP-capable I
nternet end sites, and comprise the bulk of LISP-speaking devices, reducing thei
r implementation and operational complexity should also reduce the overall cost
and effort of deploying LISP. This document defines an Experimental Protocol for
the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6833"/>
<seriesInfo name="DOI" value="10.17487/RFC6833"/>
</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="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="RFC9300" target="https://www.rfc-editor.org/info/rfc9
300" quoteTitle="true" derivedAnchor="RFC9300">
<front>
<title>The Locator/ID Separation Protocol (LISP)</title>
<author initials="D" surname="Farinacci" fullname="Dino Farinacci">
<organization showOnFrontPage="true"/>
</author>
<author initials="V" surname="Fuller" fullname="Vince Fuller">
<organization showOnFrontPage="true"/>
</author>
<author initials="D" surname="Meyer" fullname="David Meyer">
<organization showOnFrontPage="true"/>
</author>
<author initials="D" surname="Lewis" fullname="Darrel Lewis">
<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="9300"/>
<seriesInfo name="DOI" value="10.17487/RFC9300"/>
</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>
<reference anchor="RFC9303" target="https://www.rfc-editor.org/info/rfc9
303" quoteTitle="true" derivedAnchor="RFC9303">
<front>
<title>Locator/ID Separation Protocol Security (LISP-SEC)</title>
<author initials="F" surname="Maino" fullname="Fabio Maino">
<organization showOnFrontPage="true"/>
</author>
<author initials="V" surname="Ermagan" fullname="Vina Ermagan">
<organization showOnFrontPage="true"/>
</author>
<author initials="A" surname="Cabellos" fullname="Albert Cabellos">
<organization showOnFrontPage="true"/>
</author>
<author initials="D" surname="Saucez" fullname="Damien Saucez">
<organization showOnFrontPage="true"/>
</author>
<date month="October" year="2022"/>
</front>
<seriesInfo name="RFC" value="9303"/>
<seriesInfo name="DOI" value="10.17487/RFC9303"/>
</reference>
<reference anchor="RFC9304" target="https://www.rfc-editor.org/info/rfc9
304" quoteTitle="true" derivedAnchor="RFC9304">
<front>
<title>Locator/ID Separation Protocol (LISP): Shared Extension Messa
ge and IANA Registry for Packet Type Allocations</title>
<author initials="M" surname="Boucadair" fullname="Mohamed Boucadair
">
<organization showOnFrontPage="true"/>
</author>
<author initials="C" surname="Jacquenet" fullname="Christian Jacquen
et">
<organization showOnFrontPage="true"/>
</author>
<date month="October" year="2022"/>
</front>
<seriesInfo name="RFC" value="9304"/>
<seriesInfo name="DOI" value="10.17487/RFC9304"/>
</reference>
</references>
<references pn="section-13.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="I-D.ietf-lisp-ecdsa-auth" quoteTitle="true" target="h
ttps://datatracker.ietf.org/doc/html/draft-ietf-lisp-ecdsa-auth-09" derivedAncho
r="ECDSA-AUTH">
<front>
<title>LISP Control-Plane ECDSA Authentication and Authorization</ti
tle>
<author initials="D." surname="Farinacci" fullname="Dino Farinacci">
<organization showOnFrontPage="true">lispers.net</organization>
</author>
<author initials="E." surname="Nordmark" fullname="Erik Nordmark">
<organization showOnFrontPage="true">Zededa</organization>
</author>
<date month="September" day="11" year="2022"/>
<abstract>
<t indent="0"> This draft describes how LISP control-plane messa
ges can be
individually authenticated and authorized without a a priori shared-
key configuration. Public-key cryptography is used with no new PKI
infrastructure required.
</section> </t>
</middle> </abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-lisp-ecdsa-auth-09
"/>
<format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-
lisp-ecdsa-auth-09.txt"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="I-D.ietf-lisp-eid-anonymity" quoteTitle="true" target
="https://datatracker.ietf.org/doc/html/draft-ietf-lisp-eid-anonymity-13" derive
dAnchor="EID-ANONYMITY">
<front>
<title>LISP EID Anonymity</title>
<author initials="D." surname="Farinacci" fullname="Dino Farinacci">
<organization showOnFrontPage="true">lispers.net</organization>
</author>
<author initials="P." surname="Pillay-Esnault" fullname="Padma Pilla
y-Esnault">
<organization showOnFrontPage="true">Independent</organization>
</author>
<author initials="W." surname="Haddad" fullname="Wassim Haddad">
<organization showOnFrontPage="true">Ericsson</organization>
</author>
<date month="September" day="11" year="2022"/>
<abstract>
<t indent="0"> This specification will describe how ephemeral LI
SP EIDs can be used
to create source anonymity. The idea makes use of frequently
changing EIDs much like how a credit-card system uses a different
credit-card numbers for each transaction.
<back> </t>
<references title='Normative References'> </abstract>
<?rfc include="reference.RFC.2119'?> </front>
<?rfc include="reference.RFC.8174'?> <seriesInfo name="Internet-Draft" value="draft-ietf-lisp-eid-anonymity
<?rfc include="reference.RFC.8126'?> -13"/>
<?rfc include="reference.RFC.8085'?> <format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-
<?rfc include="reference.RFC.4086'?> lisp-eid-anonymity-13.txt"/>
<?rfc include="reference.RFC.2404'?> <refcontent>Work in Progress</refcontent>
<?rfc include="reference.RFC.4868'?> </reference>
<?rfc include="reference.RFC.5869'?> <reference anchor="EID-MOBILITY" quoteTitle="true" target="https://datat
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf racker.ietf.org/doc/html/draft-ietf-lisp-eid-mobility-10" derivedAnchor="EID-MOB
-lisp-rfc6830bis.xml'?> ILITY">
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf <front>
-lisp-6834bis.xml'?> <title>LISP L2/L3 EID Mobility Using a Unified Control Plane</title>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf <author initials="M" surname="Portoles" fullname="Marc Portoles Come
-lisp-sec.xml'?> ras">
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf <organization showOnFrontPage="true">Cisco Systems</organization>
-lisp-rfc8113bis.xml'?> </author>
</references> <author initials="V" surname="Ashtaputre" fullname="Vrushali Ashtapu
tre">
<organization showOnFrontPage="true">Cisco Systems</organization>
</author>
<author initials="F" surname="Maino" fullname="Fabio Maino">
<organization showOnFrontPage="true">Cisco Systems</organization>
</author>
<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="July" day="10" year="2022"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-lisp-eid-mobility-
10"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="GTP-3GPP" target="https://portal.3gpp.org/desktopmodu
les/Specifications/SpecificationDetails.aspx?specificationId=1699" quoteTitle="t
rue" derivedAnchor="GTP-3GPP">
<front>
<title>General Packet Radio System (GPRS) Tunnelling Protocol User P
lane (GTPv1-U)</title>
<author>
<organization showOnFrontPage="true">3GPP</organization>
</author>
<date month="June" year="2022"/>
</front>
<refcontent>TS.29.281</refcontent>
</reference>
<reference anchor="I-D.herbert-intarea-ila" quoteTitle="true" target="ht
tps://datatracker.ietf.org/doc/html/draft-herbert-intarea-ila-01" derivedAnchor=
"INTAREA-ILA">
<front>
<title>Identifier-locator addressing for IPv6</title>
<author initials="T." surname="Herbert" fullname="Tom Herbert">
<organization showOnFrontPage="true">Quantonium</organization>
</author>
<author initials="P." surname="Lapukhov" fullname="Petr Lapukhov">
<organization showOnFrontPage="true">Facebook</organization>
</author>
<date month="March" day="5" year="2018"/>
<abstract>
<t indent="0"> This specification describes identifier-locator a
ddressing (ILA) for
IPv6. Identifier-locator addressing differentiates between location
and identity of a network node. Part of an address expresses the
immutable identity of the node, and another part indicates the
location of the node which can be dynamic. Identifier-locator
addressing can be used to efficiently implement overlay networks for
network virtualization as well as solutions for use cases in
mobility.
<references title='Informative References'> </t>
<?rfc include="reference.RFC.4984'?> </abstract>
<?rfc include="reference.RFC.6973'?> </front>
<?rfc include="reference.RFC.8111'?> <seriesInfo name="Internet-Draft" value="draft-herbert-intarea-ila-01"
<?rfc include="reference.RFC.6347'?> />
<?rfc include="reference.RFC.6836'?> <format type="TXT" target="https://www.ietf.org/archive/id/draft-herbe
<?rfc include="reference.RFC.8378'?> rt-intarea-ila-01.txt"/>
<?rfc include="reference.RFC.8060'?> <refcontent>Work in Progress</refcontent>
<?rfc include="reference.RFC.8061'?> </reference>
<?rfc include="reference.RFC.6837'?> <reference anchor="I-D.ietf-lisp-mn" quoteTitle="true" target="https://d
<?rfc include="reference.RFC.6831'?> atatracker.ietf.org/doc/html/draft-ietf-lisp-mn-12" derivedAnchor="LISP-MN">
<?rfc include="reference.RFC.6830'?> <front>
<?rfc include="reference.RFC.1071'?> <title>LISP Mobile Node</title>
<?rfc include="reference.RFC.1035'?> <author initials="D." surname="Farinacci" fullname="Dino Farinacci">
<?rfc include="reference.RFC.2104'?> <organization showOnFrontPage="true">lispers.net</organization>
<?rfc include="reference.RFC.6234'?> </author>
<?rfc include="reference.RFC.6832'?> <author initials="D." surname="Lewis" fullname="Darrel Lewis">
<?rfc include="reference.RFC.7348'?> <organization showOnFrontPage="true">cisco Systems</organization>
<?rfc include="reference.RFC.7835'?> </author>
<?rfc include="reference.RFC.2890'?> <author initials="D." surname="Meyer" fullname="David Meyer">
<?rfc include="reference.RFC.8402'?> <organization showOnFrontPage="true">1-4-5.net</organization>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf </author>
-lisp-eid-anonymity'?> <author initials="C." surname="White" fullname="Chris White">
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf <organization showOnFrontPage="true">Logical Elegance</organizatio
-lisp-ecdsa-auth.xml'?> n>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf </author>
-lisp-mn.xml'?> <date month="July" day="24" year="2022"/>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf <abstract>
-lisp-eid-mobility.xml'?> <t indent="0"> This document describes how a lightweight version
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf of LISP's ITR/ETR
-lisp-gpe.xml'?> functionality can be used to provide seamless mobility to a mobile
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf node. The LISP Mobile Node design described in this document uses
-nvo3-vxlan-gpe.xml'?> standard LISP functionality to provide scalable mobility for LISP
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf mobile nodes.
-lisp-introduction.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf
-lisp-pubsub'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf
-opsec-icmp-filtering.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.herb
ert-intarea-ila.xml'?>
<reference anchor="AFI"> </t>
<front> </abstract>
<title>Address Family Identifier (AFIs)</title> </front>
<author surname="IANA"> <seriesInfo name="Internet-Draft" value="draft-ietf-lisp-mn-12"/>
<organization /> <format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-
</author> lisp-mn-12.txt"/>
<date month="Febuary" year="2007" /> <refcontent>Work in Progress</refcontent>
</front> </reference>
<seriesInfo name="ADDRESS FAMILY NUMBERS" <reference anchor="I-D.ietf-lisp-pubsub" quoteTitle="true" target="https
value="http://www.iana.org/assignments/address-family-numbers/a ://datatracker.ietf.org/doc/html/draft-ietf-lisp-pubsub-09" derivedAnchor="LISP-
ddress-family-numbers.xhtml?"/> PUBSUB">
</reference> <front>
<title>Publish/Subscribe Functionality for LISP</title>
<author initials="A." surname="Rodriguez-Natal" fullname="Alberto Ro
driguez-Natal">
<organization showOnFrontPage="true">Cisco</organization>
</author>
<author initials="V." surname="Ermagan" fullname="Vina Ermagan">
<organization showOnFrontPage="true">Google</organization>
</author>
<author initials="A." surname="Cabellos-Aparicio" fullname="Albert C
abellos-Aparicio">
<organization showOnFrontPage="true">UPC/BarcelonaTech</organizati
on>
</author>
<author initials="S." surname="Barkai" fullname="Sharon Barkai">
<organization showOnFrontPage="true">Nexar</organization>
</author>
<author initials="M." surname="Boucadair" fullname="Mohamed Boucadai
r">
<organization showOnFrontPage="true">Orange</organization>
</author>
<date month="June" day="28" year="2021"/>
<abstract>
<t indent="0"> This document specifies an extension to the Reque
st/Reply based LISP
Control Plane to enable Publish/Subscribe (PubSub) operation.
<reference anchor="GTP-3GPP"> </t>
<front> </abstract>
<title>General Packet Radio System (GPRS) Tunnelling Protocol </front>
User Plane (GTPv1-U)</title> <seriesInfo name="Internet-Draft" value="draft-ietf-lisp-pubsub-09"/>
<author surname="3GPP"> <format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-
<organization /> lisp-pubsub-09.txt"/>
</author> <refcontent>Work in Progress</refcontent>
<date month="January" year="2015"/> </reference>
</front> <reference anchor="NVO3-VXLAN-GPE" quoteTitle="true" target="https://dat
<seriesInfo name="TS.29.281" value="https://portal.3gpp.org/desktopmodules atracker.ietf.org/doc/html/draft-ietf-nvo3-vxlan-gpe-12" derivedAnchor="NVO3-VXL
/Specifications/SpecificationDetails.aspx?specificationId=1699"/> AN-GPE">
</reference> <front>
</references> <title>Generic Protocol Extension for VXLAN (VXLAN-GPE)</title>
<author initials="F" surname="Maino" fullname="Fabio Maino" role="ed
itor">
<organization showOnFrontPage="true"/>
</author>
<author initials="L" surname="Kreeger" fullname="Larry Kreeger" role
="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="U" surname="Elzur" fullname="Uri Elzur" role="edit
or">
<organization showOnFrontPage="true"/>
</author>
<date month="September" day="22" year="2021"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-nvo3-vxlan-gpe-12"
/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="I-D.ietf-opsec-icmp-filtering" quoteTitle="true" targ
et="https://datatracker.ietf.org/doc/html/draft-ietf-opsec-icmp-filtering-04" de
rivedAnchor="OPSEC-ICMP-FILTER">
<front>
<title>Recommendations for filtering ICMP messages</title>
<author initials="F." surname="Gont" fullname="Fernando Gont">
<organization showOnFrontPage="true">UTN/FRH</organization>
</author>
<author initials="G." surname="Gont" fullname="Guillermo Gont">
<organization showOnFrontPage="true">SI6 Networks</organization>
</author>
<author initials="C." surname="Pignataro" fullname="Carlos Pignataro
">
<organization showOnFrontPage="true">Cisco</organization>
</author>
<date month="July" day="3" year="2013"/>
<abstract>
<t indent="0"> This document document provides advice on the fil
tering of ICMPv4 and
ICMPv6 messages. Additionaly, it discusses the operational and
interoperability implications of such filtering.
<section title="Acknowledgments"> </t>
<t>The original authors would like to thank Greg Schudel, Darrel Lewis, </abstract>
John Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper </front>
Skriver, Fabio Maino, and members of the lisp@ietf.org mailing <seriesInfo name="Internet-Draft" value="draft-ietf-opsec-icmp-filteri
ng-04"/>
<format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-
opsec-icmp-filtering-04.txt"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="RFC1035" target="https://www.rfc-editor.org/info/rfc1
035" quoteTitle="true" derivedAnchor="RFC1035">
<front>
<title>Domain names - implementation and specification</title>
<author fullname="P. Mockapetris" initials="P." surname="Mockapetris
"/>
<date month="November" year="1987"/>
<abstract>
<t indent="0">This RFC is the revised specification of the protoco
l and format used in the implementation of the Domain Name System. It obsoletes
RFC-883. This memo documents the details of the domain name client - server co
mmunication.</t>
</abstract>
</front>
<seriesInfo name="STD" value="13"/>
<seriesInfo name="RFC" value="1035"/>
<seriesInfo name="DOI" value="10.17487/RFC1035"/>
</reference>
<reference anchor="RFC1071" target="https://www.rfc-editor.org/info/rfc1
071" quoteTitle="true" derivedAnchor="RFC1071">
<front>
<title>Computing the Internet checksum</title>
<author fullname="R.T. Braden" initials="R.T." surname="Braden"/>
<author fullname="D.A. Borman" initials="D.A." surname="Borman"/>
<author fullname="C. Partridge" initials="C." surname="Partridge"/>
<date month="September" year="1988"/>
<abstract>
<t indent="0">This RFC summarizes techniques and algorithms for ef
ficiently computing the Internet checksum. It is not a standard, but a set of u
seful implementation techniques.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="1071"/>
<seriesInfo name="DOI" value="10.17487/RFC1071"/>
</reference>
<reference anchor="RFC2890" target="https://www.rfc-editor.org/info/rfc2
890" quoteTitle="true" derivedAnchor="RFC2890">
<front>
<title>Key and Sequence Number Extensions to GRE</title>
<author fullname="G. Dommety" initials="G." surname="Dommety"/>
<date month="September" year="2000"/>
<abstract>
<t indent="0">This document describes extensions by which two fiel
ds, Key and Sequence Number, can be optionally carried in the GRE Header. [STAND
ARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2890"/>
<seriesInfo name="DOI" value="10.17487/RFC2890"/>
</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="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="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="RFC6836" target="https://www.rfc-editor.org/info/rfc6
836" quoteTitle="true" derivedAnchor="RFC6836">
<front>
<title>Locator/ID Separation Protocol Alternative Logical Topology (
LISP+ALT)</title>
<author fullname="V. Fuller" initials="V." surname="Fuller"/>
<author fullname="D. Farinacci" initials="D." surname="Farinacci"/>
<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 simple distributed index s
ystem to be used by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Route
r (ITR) or Map-Resolver (MR) to find the Egress Tunnel Router (ETR) that holds t
he mapping information for a particular Endpoint Identifier (EID). The MR can t
hen query that ETR to obtain the actual mapping information, which consists of a
list of Routing Locators (RLOCs) for the EID. Termed the Alternative Logical T
opology (ALT), the index is built as an overlay network on the public Internet u
sing the Border Gateway Protocol (BGP) and Generic Routing Encapsulation (GRE).
This document defines an Experimental Protocol for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6836"/>
<seriesInfo name="DOI" value="10.17487/RFC6836"/>
</reference>
<reference anchor="RFC6837" target="https://www.rfc-editor.org/info/rfc6
837" quoteTitle="true" derivedAnchor="RFC6837">
<front>
<title>NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RL
OC) Database</title>
<author fullname="E. Lear" initials="E." surname="Lear"/>
<date month="January" year="2013"/>
<abstract>
<t indent="0">The Locator/ID Separation Protocol (LISP) is a proto
col to encapsulate IP packets in order to allow end sites to route to one anothe
r without injecting routes from one end of the Internet to another. This memo p
resents an experimental database and a discussion of methods to transport the ma
pping of Endpoint IDs (EIDs) to Routing Locators (RLOCs) to routers in a reliabl
e, scalable, and secure manner. Our analysis concludes that transport of all EI
D-to- RLOC mappings scales well to at least 10^8 entries. This document defines
an Experimental Protocol for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6837"/>
<seriesInfo name="DOI" value="10.17487/RFC6837"/>
</reference>
<reference anchor="RFC6973" target="https://www.rfc-editor.org/info/rfc6
973" quoteTitle="true" derivedAnchor="RFC6973">
<front>
<title>Privacy Considerations for Internet Protocols</title>
<author fullname="A. Cooper" initials="A." surname="Cooper"/>
<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/
>
<author fullname="B. Aboba" initials="B." surname="Aboba"/>
<author fullname="J. Peterson" initials="J." surname="Peterson"/>
<author fullname="J. Morris" initials="J." surname="Morris"/>
<author fullname="M. Hansen" initials="M." surname="Hansen"/>
<author fullname="R. Smith" initials="R." surname="Smith"/>
<date month="July" year="2013"/>
<abstract>
<t indent="0">This document offers guidance for developing privacy
considerations for inclusion in protocol specifications. It aims to make desig
ners, implementers, and users of Internet protocols aware of privacy-related des
ign choices. It suggests that whether any individual RFC warrants a specific pr
ivacy considerations section will depend on the document's content.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6973"/>
<seriesInfo name="DOI" value="10.17487/RFC6973"/>
</reference>
<reference anchor="RFC7348" target="https://www.rfc-editor.org/info/rfc7
348" quoteTitle="true" derivedAnchor="RFC7348">
<front>
<title>Virtual eXtensible Local Area Network (VXLAN): A Framework fo
r Overlaying Virtualized Layer 2 Networks over Layer 3 Networks</title>
<author fullname="M. Mahalingam" initials="M." surname="Mahalingam"/
>
<author fullname="D. Dutt" initials="D." surname="Dutt"/>
<author fullname="K. Duda" initials="K." surname="Duda"/>
<author fullname="P. Agarwal" initials="P." surname="Agarwal"/>
<author fullname="L. Kreeger" initials="L." surname="Kreeger"/>
<author fullname="T. Sridhar" initials="T." surname="Sridhar"/>
<author fullname="M. Bursell" initials="M." surname="Bursell"/>
<author fullname="C. Wright" initials="C." surname="Wright"/>
<date month="August" year="2014"/>
<abstract>
<t indent="0">This document describes Virtual eXtensible Local Are
a Network (VXLAN), which is used to address the need for overlay networks within
virtualized data centers accommodating multiple tenants. The scheme and the re
lated protocols can be used in networks for cloud service providers and enterpri
se data centers. This memo documents the deployed VXLAN protocol for the benefi
t of the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7348"/>
<seriesInfo name="DOI" value="10.17487/RFC7348"/>
</reference>
<reference anchor="RFC7835" target="https://www.rfc-editor.org/info/rfc7
835" quoteTitle="true" derivedAnchor="RFC7835">
<front>
<title>Locator/ID Separation Protocol (LISP) Threat Analysis</title>
<author fullname="D. Saucez" initials="D." surname="Saucez"/>
<author fullname="L. Iannone" initials="L." surname="Iannone"/>
<author fullname="O. Bonaventure" initials="O." surname="Bonaventure
"/>
<date month="April" year="2016"/>
<abstract>
<t indent="0">This document provides a threat analysis of the Loca
tor/ID Separation Protocol (LISP).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7835"/>
<seriesInfo name="DOI" value="10.17487/RFC7835"/>
</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="RFC8111" target="https://www.rfc-editor.org/info/rfc8
111" quoteTitle="true" derivedAnchor="RFC8111">
<front>
<title>Locator/ID Separation Protocol Delegated Database Tree (LISP-
DDT)</title>
<author fullname="V. Fuller" initials="V." surname="Fuller"/>
<author fullname="D. Lewis" initials="D." surname="Lewis"/>
<author fullname="V. Ermagan" initials="V." surname="Ermagan"/>
<author fullname="A. Jain" initials="A." surname="Jain"/>
<author fullname="A. Smirnov" initials="A." surname="Smirnov"/>
<date month="May" year="2017"/>
<abstract>
<t indent="0">This document describes the Locator/ID Separation Pr
otocol Delegated Database Tree (LISP-DDT), a hierarchical distributed database t
hat embodies the delegation of authority to provide mappings from LISP Endpoint
Identifiers (EIDs) to Routing Locators (RLOCs). It is a statically defined dist
ribution of the EID namespace among a set of LISP-speaking servers called "DDT n
odes". Each DDT node is configured as "authoritative" for one or more EID-prefi
xes, along with the set of RLOCs for Map-Servers or "child" DDT nodes to which m
ore-specific EID-prefixes are delegated.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8111"/>
<seriesInfo name="DOI" value="10.17487/RFC8111"/>
</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="RFC8402" target="https://www.rfc-editor.org/info/rfc8
402" quoteTitle="true" derivedAnchor="RFC8402">
<front>
<title>Segment Routing Architecture</title>
<author fullname="C. Filsfils" initials="C." role="editor" surname="
Filsfils"/>
<author fullname="S. Previdi" initials="S." role="editor" surname="P
revidi"/>
<author fullname="L. Ginsberg" initials="L." surname="Ginsberg"/>
<author fullname="B. Decraene" initials="B." surname="Decraene"/>
<author fullname="S. Litkowski" initials="S." surname="Litkowski"/>
<author fullname="R. Shakir" initials="R." surname="Shakir"/>
<date month="July" year="2018"/>
<abstract>
<t indent="0">Segment Routing (SR) leverages the source routing pa
radigm. A node steers a packet through an ordered list of instructions, called "
segments". A segment can represent any instruction, topological or service based
. A segment can have a semantic local to an SR node or global within an SR domai
n. SR provides a mechanism that allows a flow to be restricted to a specific top
ological path, while maintaining per-flow state only at the ingress node(s) to t
he SR domain.</t>
<t indent="0">SR can be directly applied to the MPLS architecture
with no change to the forwarding plane. A segment is encoded as an MPLS label. A
n ordered list of segments is encoded as a stack of labels. The segment to proce
ss is on the top of the stack. Upon completion of a segment, the related label i
s popped from the stack.</t>
<t indent="0">SR can be applied to the IPv6 architecture, with a n
ew type of routing header. A segment is encoded as an IPv6 address. An ordered l
ist of segments is encoded as an ordered list of IPv6 addresses in the routing h
eader. The active segment is indicated by the Destination Address (DA) of the pa
cket. The next active segment is indicated by a pointer in the new routing heade
r.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8402"/>
<seriesInfo name="DOI" value="10.17487/RFC8402"/>
</reference>
<reference anchor="RFC9147" target="https://www.rfc-editor.org/info/rfc9
147" quoteTitle="true" derivedAnchor="RFC9147">
<front>
<title>The Datagram Transport Layer Security (DTLS) Protocol Version
1.3</title>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/
>
<author fullname="N. Modadugu" initials="N." surname="Modadugu"/>
<date month="April" year="2022"/>
<abstract>
<t indent="0">This document specifies version 1.3 of the Datagram
Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applicat
ions to communicate over the Internet in a way that is designed to prevent eaves
dropping, tampering, and message forgery.</t>
<t indent="0">The DTLS 1.3 protocol is based on the Transport Laye
r Security (TLS) 1.3 protocol and provides equivalent security guarantees with t
he exception of order protection / non-replayability. Datagram semantics of the
underlying transport are preserved by the DTLS protocol.</t>
<t indent="0">This document obsoletes RFC 6347.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9147"/>
<seriesInfo name="DOI" value="10.17487/RFC9147"/>
</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>
<reference anchor="RFC9305" target="https://www.rfc-editor.org/info/rfc9
305" quoteTitle="true" derivedAnchor="RFC9305">
<front>
<title>Locator/ID Separation Protocol (LISP) Generic Protocol Extens
ion</title>
<author initials="F" surname="Maino" fullname="Fabio Maino" role="ed
itor">
<organization showOnFrontPage="true"/>
</author>
<author initials="J" surname="Lemon" fullname="Jennifer Lemon">
<organization showOnFrontPage="true"/>
</author>
<author initials="P" surname="Agarwal" fullname="Puneet Agarwal">
<organization showOnFrontPage="true"/>
</author>
<author initials="D" surname="Lewis" fullname="Darrel Lewis">
<organization showOnFrontPage="true"/>
</author>
<author initials="M" surname="Smith" fullname="Michael Smith">
<organization showOnFrontPage="true"/>
</author>
<date month="October" year="2022"/>
</front>
<seriesInfo name="RFC" value="9305"/>
<seriesInfo name="DOI" value="10.17487/RFC9305"/>
</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">The original authors would like to
thank <contact fullname="Greg Schudel"/>, <contact fullname="Darrel Lewis"/>,
<contact fullname="John Zwiebel"/>, <contact fullname="Andrew Partan"/>, <co
ntact fullname="Dave Meyer"/>, <contact fullname="Isidor Kouvelas"/>, <contact f
ullname="Jesper Skriver"/>, and members of the lisp@ietf.org mailing
list for their feedback and helpful suggestions.</t> list for their feedback and helpful suggestions.</t>
<t indent="0" pn="section-appendix.a-2"> Special thanks are due to <contac
<t> Special thanks are due to Noel Chiappa for his extensive work t fullname="Noel Chiappa"/> for his extensive work
and thought about caching in Map-Resolvers.</t> and thought about caching in Map-Resolvers.</t>
<t indent="0" pn="section-appendix.a-3">The current authors would like to
<t>The current authors would like to give a sincere thank you to give a sincere thank you to
the people who help put LISP on standards track in the IETF. They the people who help put LISP on the Standards Track in the IETF. They
include Joel Halpern, Luigi Iannone, Deborah Brungard, Fabio include <contact fullname="Joel Halpern"/>, <contact fullname="Luigi Iannone
Maino, Scott Bradner, Kyle Rose, Takeshi Takahashi, Sarah Banks, "/>, <contact fullname="Deborah Brungard"/>, <contact fullname="Fabio Maino"
Pete Resnick, Colin Perkins, Mirja Kuhlewind, Francis Dupont, />, <contact fullname="Scott Bradner"/>, <contact fullname="Kyle Rose"/>, <conta
Benjamin Kaduk, Eric Rescorla, Alvaro Retana, Alexey Melnikov, ct fullname="Takeshi Takahashi"/>, <contact fullname="Sarah Banks"/>,
Alissa Cooper, Suresh Krishnan, Alberto Rodriguez-Natal, Vina <contact fullname="Pete Resnick"/>, <contact fullname="Colin Perkins"/>, <co
Ermagen, Mohamed Boucadair, Brian Trammell, Sabrina Tanamal, and ntact fullname="Mirja Kühlewind"/>, <contact fullname="Francis Dupont"/>,
John Drake. The contributions they offered greatly added to the <contact fullname="Benjamin Kaduk"/>, <contact fullname="Eric Rescorla"/>, <
contact fullname="Alvaro Retana"/>, <contact fullname="Alexey Melnikov"/>,
<contact fullname="Alissa Cooper"/>, <contact fullname="Suresh Krishnan"/>,
<contact fullname="Alberto Rodriguez-Natal"/>, <contact fullname="Vina Ermag
an"/>, <contact fullname="Mohamed Boucadair"/>, <contact fullname="Brian Trammel
l"/>, <contact fullname="Sabrina Tanamal"/>, and
<contact fullname="John Drake"/>. The contributions they offered greatly add
ed to the
security, scale, and robustness of the LISP architecture and security, scale, and robustness of the LISP architecture and
protocols.</t> protocols.</t>
</section>
<section title="Document Change Log">
<t>[RFC Editor: Please delete this section on publication as RFC.]</t>
<section title="Changes to draft-ietf-lisp-rfc6833bis-26">
<t><list style="symbols">
<t>Posted November 2019.</t>
<t>Fixed the required (MUST implement) authentcation algorithms.</t>
<t>Fixed a large set of minor comments and edits.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6833bis-25">
<t><list style="symbols">
<t>Posted June 2019.</t>
<t>Added change requested by Mirja describing Record Count in
an EID-record.</t>
<t>Fixed Requirements Notation section per Pete.</t>
<t>Added KDF for shared-secret</t>
<t>Specified several rate-limiters for control messages</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6833bis-24">
<t><list style="symbols">
<t>Posted February 2019.</t>
<t>Added suggested text from Albert that Benjamin Kaduk agreed
with.</t>
<t>Added suggested editorial comments from Alvaro's rewview.</t>
<t>Ran document through IDnits. Fixed bugs found.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6833bis-23">
<t><list style="symbols">
<t>Posted December 2018.</t>
<t>Added to Security Considerations section that deployments that
care about prefix over claiming should use LISP-SEC.</t>
<t>Added to Security Considerations section that DTLS or LISP-crypto
be used for control-plane privacy.</t>
<t>Make LISP-SEC a normative reference.</t>
<t>Make it more clear where field descriptions are spec'ed when
referencing to the same fields in other packet types.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6833bis-22">
<t><list style="symbols">
<t>Posted week after IETF November 2018.</t>
<t>No longer need to use IPSEC for replay attacks.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6833bis-21">
<t><list style="symbols">
<t>Posted early November 2018.</t>
<t>Added I-bit back in because its necessary to use for Map-Register
replay attack scenarios. The Map-Server tracks the nonce per xTR-ID
to detect duplicate or replayed Map-Register messages.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6833bis-20">
<t><list style="symbols">
<t>Posted late October 2018.</t>
<t>Changed description about "reserved" bits to state "reserved and
unassigned".</t>
<t>Make it more clear how Map-Register nonce processing is
performed in an ETR and Map-Server.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6833bis-19">
<t><list style="symbols">
<t>Posted mid October 2018.</t>
<t>Added Fabio text to the Security Considerations section.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6833bis-18">
<t><list style="symbols">
<t>Posted mid October 2018.</t>
<t>Fixed comments from Eric after more email clarity.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6833bis-17">
<t><list style="symbols">
<t>Posted early October 2018.</t>
<t>Changes to reflect comments from Sep 27th Telechat.</t>
<t>Added all flag bit definitions as request for allocation in
IANA Considersations section.</t>
<t>Added an applicability statement in section 1 to address
security concerns from Telechat.</t>
<t>Moved m-bit description and IANA request to
draft-ietf-lisp-mn.</t>
<t>Moved I-bit description and IANA request to
draft-ietf-lisp-pubsub.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6833bis-16">
<t><list style="symbols">
<t>Posted Late-September 2018.</t>
<t>Re-wrote Security Considerations section. Thanks Albert.</t>
<t>Added Alvaro text to be more clear about IANA actions.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6833bis-15">
<t><list style="symbols">
<t>Posted mid-September 2018.</t>
<t>Changes to reflect comments from Colin and Mirja.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6833bis-14">
<t><list style="symbols">
<t>Posted September 2018.</t>
<t>Changes to reflect comments from Genart, RTGarea, and
Secdir reviews.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6833bis-13">
<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 6833" so implementators
are informed of any changes since the last RFC publication.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6833bis-12">
<t><list style="symbols">
<t>Posted late July 2018.</t>
<t>Moved RFC6830bis and RFC6834bis to Normative References.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6833bis-11">
<t><list style="symbols">
<t>Posted July 2018.</t>
<t>Fixed Luigi editorial comments to ready draft for RFC status and
ran through IDNITs again.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6833bis-10">
<t><list style="symbols">
<t>Posted after LISP WG at IETF week March.</t>
<t>Move AD field encoding after S-bit in the ECM packet format
description section.</t>
<t>Say more about when the new Drop actions should be sent.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6833bis-09">
<t><list style="symbols">
<t>Posted March IETF week 2018.</t>
<t>Fixed editorial comments submitted by document shepherd Luigi
Iannone.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6833bis-08">
<t><list style="symbols">
<t>Posted March 2018.</t>
<t>Added RLOC-probing algorithm.</t>
<t>Added Solicit-Map Request algorithm.</t>
<t>Added several mechanisms (from 6830bis) regarding Routing
Locator Reachability.</t>
<t>Added port 4342 to IANA Considerations section.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6833bis-07">
<t><list style="symbols">
<t>Posted December 2017.</t>
<t>Make it more clear in a couple of places that RLOCs are
used to locate ETRs more so than for Map-Server Map-Request
forwarding.</t>
<t>Make it clear that "encapsualted" for a control message is
an ECM based message.</t>
<t>Make it more clear what messages use source-port 4342 and
which ones use destinatino-port 4342.</t>
<t>Don't make DDT references when the mapping transport system
can be of any type and the referneced text is general to
it.</t>
<t>Generalize text when referring to the format of an
EID-prefix. Can use othe AFIs then IPv4 and IPv6.</t>
<t>Many editorial changes to clarify text.</t>
<t>Changed some "must", "should", and "may" to capitalized.</t>
<t>Added definitions for Map-Request and Map-Reply messages.</t>
<t>Ran document through IDNITs.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6833bis-06">
<t><list style="symbols">
<t>Posted October 2017.</t>
<t>Spec the I-bit to include the xTR-ID in a Map-Request
message to be consistent with the Map-Register message and to
anticipate the introduction of pubsub functionality to allow
Map-Requests to subscribe to RLOC-set changes.</t>
<t>Updated references for individual submissions that became
working group documents.</t>
<t>Updated references for working group documents that became RFCs.</
t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6833bis-05">
<t><list style="symbols">
<t>Posted May 2017.</t>
<t>Update IANA Considerations section based on new requests
from this document and changes from what was requested in
<xref target="RFC6830"/>.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6833bis-04">
<t><list style="symbols">
<t>Posted May 2017.</t>
<t>Clarify how the Key-ID field is used in Map-Register and
Map-Notify messages. Break the 16-bit field into a 8-bit
Key-ID field and a 8-bit Algorithm-ID field.</t>
<t>Move the Control-Plane codepoints from the IANA
Considerations section of RFC6830bis to the IANA
Considerations section of this document.</t>
<t>In the "LISP Control Packet Type Allocations" section,
indicate how message Types are IANA allocated and how
experimental RFC8113 sub-types should be requested.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6833bis-03">
<t><list style="symbols">
<t>Posted April 2017.</t>
<t>Add types 9-14 and specify they are not assigned.</t>
<t>Add the "LISP Shared Extension Message" type and point to
RFC8113.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6833bis-02">
<t><list style="symbols">
<t>Posted April 2017.</t>
<t>Clarify that the LISP Control-Plane document defines how
the LISP Data-Plane uses Map-Requests with either the SMR-bit
set or the P-bit set supporting mapping updates and
RLOC-probing. Indicating that other Data-Planes can use the
same mechanisms or their own defined mechanisms to achieve the
same functionality.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-rfc6833bis-01">
<t><list style="symbols">
<t>Posted March 2017.</t>
<t>Include references to new RFCs published.</t>
<t>Remove references to self.</t>
<t>Change references from RFC6830 to RFC6830bis.</t>
<t>Add two new action/reasons to a Map-Reply has posted to the
LISP WG mailing list.</t>
<t>In intro section, add refernece to
I-D.ietf-lisp-introduction.</t>
<t>Removed Open Issues section and references to
"experimental".</t>
</list></t>
</section> </section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
<section title="Changes to draft-ietf-lisp-rfc6833bis-00"> ="include" pn="section-appendix.b">
<t><list style="symbols"> <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
<t>Posted December 2016.</t> <author initials="D" surname="Farinacci" fullname="Dino Farinacci">
<t>Created working group document from draft-farinacci-lisp <organization showOnFrontPage="true">lispers.net</organization>
-rfc6833-00 individual submission. No other changes made.</t> <address>
</list></t> <postal>
</section> <city>San Jose</city>
<region>CA</region>
<section title="Changes to draft-farinacci-lisp-rfc6833bis-00"> <country>United States of America</country>
<t><list style="symbols"> </postal>
<t>Posted November 2016.</t> <email>farinacci@gmail.com</email>
<t>This is the initial draft to turn RFC 6833 into RFC </address>
6833bis.</t> </author>
<t>The document name has changed from the "Locator/ID <author initials="F" surname="Maino" fullname="Fabio Maino">
Separation Protocol (LISP) Map-Server Interface" to the <organization showOnFrontPage="true">Cisco Systems</organization>
"Locator/ID Separation Protocol (LISP) Control-Plane".</t> <address>
<t>The fundamental change was to move the Control-Plane <postal>
messages from RFC 6830 to this document in an effort so any <city>San Jose</city>
IETF developed or industry created Data-Plane could use the <region>CA</region>
LISP mapping system and Control-Plane.</t> <country>United States of America</country>
<t>Update Control-Plane messages to incorporate what has been </postal>
implemented in products during the early phase of LISP <email>fmaino@cisco.com</email>
development but wasn't able to make it into RFC6830 and </address>
RFC6833 to make the Experimental RFC deadline.</t> </author>
<t>Indicate there may be nodes in the mapping system that are <author initials="V" surname="Fuller" fullname="Vince Fuller">
not MRs or MSs, that is a ALT-node or a DDT-node.</t> <organization showOnFrontPage="true">vaf.net Internet Consulting</organi
<t>Include LISP-DDT in Map-Resolver section and explain how zation>
they maintain a referral-cache.</t> <address>
<t>Removed open issue about additional state in Map-Servers. <email>vince.fuller@gmail.com</email>
With <xref target="RFC8111"/>, Map-Servers have the same </address>
registration state and can give Map-Resolvers complete </author>
information in ms-ack Map-Referral messages.</t> <author initials="A" surname="Cabellos" fullname="Albert Cabellos" role="e
<t>Make reference to the LISP Threats Analysis RFC ditor">
<xref target="RFC7835"/>.</t> <organization showOnFrontPage="true">Universitat Politecnica de Cataluny
</list></t> a</organization>
<address>
<postal>
<street>c/ Jordi Girona s/n</street>
<city>Barcelona</city>
<country>Spain</country>
<code>08034</code>
</postal>
<email>acabello@ac.upc.edu</email>
</address>
</author>
</section> </section>
</section> </back>
</back>
</rfc> </rfc>
 End of changes. 275 change blocks. 
1865 lines changed or deleted 3424 lines changed or added

This html diff was produced by rfcdiff 1.48.