<?xml version="1.0" encoding="US-ASCII"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-lisp-rfc6833bis-31" indexInclude="true" ipr="trust200902" docName="draft-ietf-lisp-rfc6833bis-30" number="9301" obsoletes="6830, 6833">

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no"?>
<?rfc rfcedstyle="yes"?> 6833" prepTime="2022-10-18T16:01:20" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis-31" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9301" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="LISP Control-Plane">Locator/ID Control Plane">Locator/ID Separation Protocol (LISP) Control-Plane</title> Control Plane</title>
    <seriesInfo name="RFC" value="9301" stream="IETF"/>
    <author initials='D' initials="D" surname="Farinacci" fullname='Dino Farinacci'>
    <organization>lispers.net</organization> fullname="Dino Farinacci">
      <organization showOnFrontPage="true">lispers.net</organization>
      <address>
        <postal>
          <city>San Jose</city>
          <region>CA</region>
          <country>United States of America</country>
        </postal>
        <email>farinacci@gmail.com</email>
      </address>
    </author>
    <author initials='F' initials="F" surname="Maino" fullname='Fabio Maino'>
    <organization>Cisco fullname="Fabio Maino">
      <organization showOnFrontPage="true">Cisco Systems</organization>
      <address>
        <postal>
          <city>San Jose</city>
          <region>CA</region>
          <country>United States of America</country>
        </postal>
        <email>fmaino@cisco.com</email>
      </address>
    </author>
    <author initials='V' initials="V" surname="Fuller" fullname='Vince Fuller'>
    <organization>vaf.net fullname="Vince Fuller">
      <organization showOnFrontPage="true">vaf.net Internet Consulting</organization>
      <address>
      <email>vaf@vaf.net</email>
        <email>vince.fuller@gmail.com</email>
      </address>
    </author>
    <author initials='A' surname="Cabellos (Ed.)" fullname='Albert Cabellos'>
    <organization>UPC/BarcelonaTech</organization>
    <address><postal>
      <street>Campus Nord, C. initials="A" surname="Cabellos" fullname="Albert Cabellos" role="editor">
      <organization showOnFrontPage="true">Universitat Politecnica de Catalunya</organization>
      <address>
        <postal>
          <street>c/ Jordi Girona 1-3</street> s/n</street>
          <city>Barcelona</city> <region>Catalunya</region>
          <country>Spain</country>
          <code>08034</code>
        </postal>
    <email>acabello@ac.upc.edu</email></address>
        <email>acabello@ac.upc.edu</email>
      </address>
    </author>
    <date />

  <abstract>
    <t> month="10" year="2022"/>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1"> This document describes the Control-Plane control plane and Mapping Service
    for the Locator/ID Separation Protocol (LISP), implemented by two
    types of LISP-speaking devices -- the LISP Map-Resolver and
    LISP Map-Server -- that provides provide a simplified "front end" for one
    or more Endpoint ID IDs (EIDs) to Routing Locator mapping databases.</t>

    <t>By
      <t indent="0" pn="section-abstract-2">By using this Control-Plane control plane service interface and communicating
    with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers
    (ITRs) and Egress Tunnel Routers (ETRs) are not dependent on the
    details of mapping database systems, which systems; this behavior facilitates modularity
    with different database designs.  Since these devices implement the "edge" of the
    LISP Control-Plane control plane infrastructure, connecting EID addressable nodes
    of a LISP site, it the implementation and operational complexity of the
      overall cost and effort of deploying LISP.</t>

    <t>This LISP is reduced.</t>
      <t indent="0" pn="section-abstract-3">This document obsoletes RFC RFCs 6830 and RFC 6833.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9301" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" 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" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="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="section-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-scope-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 derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-notation">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" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="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" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-basic-overview">Basic Overview</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="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="section-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 derivedContent="" format="title" sectionFormat="of" target="name-lisp-control-packet-type-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 derivedContent="" format="title" sectionFormat="of" target="name-map-request-message-format">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 derivedContent="" format="title" sectionFormat="of" target="name-eid-to-rloc-udp-map-request">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 derivedContent="" format="title" sectionFormat="of" target="name-map-reply-message-format">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 derivedContent="" format="title" sectionFormat="of" target="name-eid-to-rloc-udp-map-reply-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 derivedContent="" format="title" sectionFormat="of" target="name-map-register-message-format">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 derivedContent="" format="title" sectionFormat="of" target="name-map-notify-and-map-notify-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 derivedContent="" format="title" sectionFormat="of" target="name-encapsulated-control-messag">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" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-changing-the-contents-of-ei">Changing the Contents of EID-to-RLOC Mappings</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="" format="title" sectionFormat="of" target="name-solicit-map-request-smr">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" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-routing-locator-reachabilit">Routing Locator Reachability</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="" 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" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-interactions-with-other-lis">Interactions with Other LISP Components</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="" format="title" sectionFormat="of" target="name-itr-eid-to-rloc-mapping-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 derivedContent="" format="title" sectionFormat="of" target="name-eid-prefix-configuration-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 derivedContent="" 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 derivedContent="" format="title" sectionFormat="of" target="name-map-resolver-processing">Map-Resolver Processing</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="8.4.1" format="counter" sectionFormat="of" target="section-8.4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-anycast-operation">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" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="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" format="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" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-changes-related-to-rfcs-683">Changes 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" format="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="" format="title" sectionFormat="of" target="name-lisp-udp-port-numbers">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 derivedContent="" format="title" sectionFormat="of" target="name-lisp-packet-type-codes">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 derivedContent="" 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 derivedContent="" format="title" sectionFormat="of" target="name-lisp-address-type-codes">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 derivedContent="" format="title" sectionFormat="of" target="name-lisp-algorithm-id-numbers">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 derivedContent="" format="title" sectionFormat="of" target="name-lisp-bit-flags">LISP 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" format="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="section-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 derivedContent="" format="title" sectionFormat="of" target="name-normative-references">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 derivedContent="" format="title" sectionFormat="of" target="name-informative-references">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="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.15">
            <t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section title="Introduction">
    <t>The 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
    target="I-D.ietf-lisp-rfc6830bis"/> target="RFC9300" format="default" sectionFormat="of" derivedContent="RFC9300"/> (see also <xref
    target="I-D.ietf-lisp-introduction"/>) target="RFC9299" format="default" sectionFormat="of" derivedContent="RFC9299"/>) specifies an architecture
    and mechanism for dynamic tunneling by logically separating the
    addresses currently used by IP in two separate name spaces: namespaces:
    Endpoint IDs (EIDs), used within sites; and Routing Locators
    (RLOCs), used on the transit networks that make up the Internet
    infrastructure. To achieve this separation, LISP defines protocol
    mechanisms for mapping from EIDs to RLOCs. In addition, LISP
    assumes the existence of a database to store and propagate those
    mappings across mapping system Mapping System nodes. Several such databases have
    been proposed; among them are the Content distribution Overlay
    Network Service for LISP-NERD (a Not-so-novel EID-to-RLOC
    Database) <xref target="RFC6837" />, format="default" sectionFormat="of" derivedContent="RFC6837"/>, LISP Alternative Logical
    Topology (LISP-ALT) <xref target="RFC6836" />, format="default" sectionFormat="of" derivedContent="RFC6836"/>, and LISP Delegated
    Database Tree (LISP-DDT) <xref target="RFC8111"/>.</t>

    <t> target="RFC8111" format="default" sectionFormat="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
    Map-Requests from an Ingress Tunnel Router (ITR) and "resolves"
    the EID-to-RLOC mapping using a mapping database; and the
    Map-Server, which learns authoritative EID-to-RLOC mappings from
    an Egress Tunnel Router (ETR) and publishes them in a
    database.</t>

    <t>
      <t indent="0" pn="section-1-3"> This LISP Control-Plane control plane and Mapping Service can be used by many
    different encapsulation-based or translation-based Data-Planes
    which include data planes, including
    but are not limited to the ones those defined in LISP RFC
    6830bis
    <xref target="I-D.ietf-lisp-rfc6830bis"/>, LISP-GPE target="RFC9300" format="default" sectionFormat="of" derivedContent="RFC9300"/>, the LISP Generic Protocol Extension (LISP-GPE) <xref
    target="I-D.ietf-lisp-gpe"/>, VXLAN target="RFC9305" format="default" sectionFormat="of" derivedContent="RFC9305"/>, Virtual eXtensible Local Area Networks (VXLANs) <xref target="RFC7348" />, format="default" sectionFormat="of" derivedContent="RFC7348"/>,
    VXLAN-GPE <xref target="I-D.ietf-nvo3-vxlan-gpe"/>, target="NVO3-VXLAN-GPE" format="default" sectionFormat="of" derivedContent="NVO3-VXLAN-GPE"/>,
    GRE <xref target="RFC2890"/>, GTP <xref target="GTP-3GPP"/>,
    ILA target="RFC2890" format="default" sectionFormat="of" derivedContent="RFC2890"/>, the GPRS Tunneling Protocol (GTP) <xref target="I-D.herbert-intarea-ila"/>, target="GTP-3GPP" format="default" sectionFormat="of" derivedContent="GTP-3GPP"/>,
    Identifier-Locator Addressing (ILA) <xref target="I-D.herbert-intarea-ila" format="default" sectionFormat="of" derivedContent="INTAREA-ILA"/>, and Segment Routing (SRv6)
    <xref target="RFC8402"/>.</t>

    <t> target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/>.</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
    (DNS) servers <xref target="RFC1035" /> servers; format="default" sectionFormat="of" derivedContent="RFC1035"/>; likewise, Map-Resolvers
    are conceptually similar to DNS caching resolvers. With this in
    mind, this specification borrows familiar terminology (resolver
    and server) from the DNS specifications.</t>

    <t>
      <t indent="0" pn="section-1-5"> Note that this document doesn't assume any particular database
    mapping infrastructure to illustrate certain aspects of Map-Server
    and Map-Resolver operation. operations. The Mapping Service interface can (and
    likely will) be used by ITRs and ETRs to access other mapping
    database systems as the LISP infrastructure evolves.</t>

    <t>LISP
      <t indent="0" pn="section-1-6">LISP is not intended to address problems of connectivity and
    scaling on behalf of arbitrary communicating parties.  Relevant
    situations are described in the scoping section of the
    introduction to
<xref target="I-D.ietf-lisp-rfc6830bis"/>.</t>

    <t>This target="RFC9300" sectionFormat="of" section="1.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9300#section-1.1" derivedContent="RFC9300"/>.</t>
      <t indent="0" pn="section-1-7">This document obsoletes RFC 6830 <xref target="RFC6830" format="default" sectionFormat="of" derivedContent="RFC6830"/> and 6833.</t> <xref target="RFC6833" format="default" sectionFormat="of" derivedContent="RFC6833"/>.</t>
      <section title="Scope anchor="soa" numbered="true" toc="include" removeInRFC="false" pn="section-1.1">
        <name slugifiedName="name-scope-of-applicability">Scope of Applicability" anchor="soa">
      <t>LISP Applicability</name>
        <t indent="0" pn="section-1.1-1">LISP was originally developed to address the Internet-wide
      route scaling problem <xref target="RFC4984"/>. target="RFC4984" format="default" sectionFormat="of" derivedContent="RFC4984"/>.  While there
      are a number of approaches of interest for that problem, as LISP
      as
      has been developed and refined, a large number of other LISP uses for LISP have
      been found and are being used. implemented.  As such, the design and
      development of LISP has have changed so as to focus on these use
      cases.  The common property of these uses is a large set of
      cooperating entities seeking to communicate over the public
      Internet or other large underlay IP infrastructures, infrastructures while
      keeping the addressing and topology of the cooperating entities
      separate from the underlay and Internet topology, routing, and
      addressing.</t>

      <t>When
        <t indent="0" pn="section-1.1-2">When communicating over the public Internet, deployers MUST <bcp14>MUST</bcp14> consider
        the following guidelines:</t>

        <t><list style="numbers">
        <t>LISP-SEC MUST
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-1.1-3">
	  <li pn="section-1.1-3.1" derivedCounter="1.">LISP Security (LISP-SEC) <bcp14>MUST</bcp14> be implemented <xref target="I-D.ietf-lisp-sec"/>. target="RFC9303" format="default" sectionFormat="of" derivedContent="RFC9303"/>. This means that the S-bit MUST <bcp14>MUST</bcp14> be set in the Map-Reply (<xref target="MR-FORMAT"/>), target="MR-FORMAT" format="default" sectionFormat="of" derivedContent="Section 5.4"/>), Map-Register (<xref target="MAPREG"/>) target="MAPREG" format="default" sectionFormat="of" derivedContent="Section 5.6"/>), and Encapsulated Control messages Messages (ECMs) (<xref target="encap-mr"/>).</t>
        <t>Implementations SHOULD target="encap-mr" format="default" sectionFormat="of" derivedContent="Section 5.8"/>).</li>
          <li pn="section-1.1-3.2" derivedCounter="2.">Implementations <bcp14>SHOULD</bcp14> use the 'HMAC-SHA256-128+HKDF-SHA256'
          as the Algorithm ID (<xref target="KEYS"/>) target="KEYS" format="default" sectionFormat="of" derivedContent="Section 12.5"/>)
          in the Map-Register message (<xref target="MAPREG"/>), target="MAPREG" format="default" sectionFormat="of" derivedContent="Section 5.6"/>) and MUST NOT <bcp14>MUST NOT</bcp14> use 'None' or 'HMAC-SHA-1-96-None' as the Algorithm ID (<xref target="KEYS"/>) target="KEYS" format="default" sectionFormat="of" derivedContent="Section 12.5"/>) in the Map-Register message (<xref target="MAPREG"/>)</t>
        </list></t> target="MAPREG" format="default" sectionFormat="of" derivedContent="Section 5.6"/>).</li>
        </ol>
      </section>
    </section>
    <section title="Requirements Notation">
    <t>The numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-requirements-notation">Requirements Notation</name>
      <t indent="0" pn="section-2-1">
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
    NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
    "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 <xref target="RFC2119"/> BCP 14 <xref
    target="RFC8174"/> target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
      </t>
    </section>
    <section title="Definition of Terms">
    <t><list style="hanging">
      <t hangText="Map-Server: ">A 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
      registration mechanism described below, or some other
      authoritative source if one exists. A Map-Server publishes these
      EID-Prefixes in a mapping database.</t>

      <t hangText="Map-Request: ">A LISP Map-Request is a
      Control-Plane database.</dd>
        <dt pn="section-3-1.3">Map-Request: </dt>
        <dd pn="section-3-1.4">A control plane message to query that queries the mapping system Mapping System to resolve an
      EID.  A LISP Map-Request can also be sent to an RLOC to test for
      reachability and to exchange security keys between an
      encapsulator and a decapsulator. This type of Map-Request is
      also known as an RLOC-Probe Request.</t>

      <t hangText="Map-Reply: ">A LISP Map-Reply is a Control-Plane Request.</dd>
        <dt pn="section-3-1.5">Map-Reply: </dt>
        <dd pn="section-3-1.6">A control plane
      message returned in response to a Map-Request sent to the mapping
      system Mapping
      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
      to test for reachability. This type of Map-Reply is known as a an RLOC-Probe
      Reply.</t>

      <t hangText="Encapsulated
      Reply.</dd>
        <dt pn="section-3-1.7">Encapsulated Map-Request: ">A </dt>
        <dd pn="section-3-1.8">A LISP Map-Request
      carried within an Encapsulated Control Message (ECM), which ECM. This Map-Request has an
      additional LISP header prepended. Sent to UDP destination port
      4342. The "outer" addresses are routable IP addresses,
      also known as RLOCs.  Used by an ITR when sending to a
      Map-Resolver and by a Map-Server when forwarding a Map-Request
      to an ETR.</t>

      <t hangText="Map-Resolver: ">A ETR.</dd>
        <dt pn="section-3-1.9">Map-Resolver: </dt>
        <dd pn="section-3-1.10">A network infrastructure component
      that accepts LISP Encapsulated (ECM) Map-Requests, typically from an
      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
      returned.  Otherwise, the Map-Resolver finds the appropriate
      EID-to-RLOC mapping by consulting a mapping database system.</t>

      <t hangText="Negative system.</dd>
        <dt pn="section-3-1.11">Negative Map-Reply: ">A </dt>
        <dd pn="section-3-1.12">A LISP Map-Reply that
      contains an empty Locator-Set.  Returned in response to a
      Map-Request if the destination EID is not registered in the
      mapping system,
      Mapping System, is policy denied policy-denied, or fails authentication.</t>

      <t hangText="Map-Register authentication.</dd>
        <dt pn="section-3-1.13">Map-Register message: ">A </dt>
        <dd pn="section-3-1.14">A LISP message sent by an
      ETR to a Map-Server to register its associated EID-Prefixes. In
      addition to the set of EID-Prefixes to register, the message
      includes one or more RLOCs to reach ETR(s). The Map-Server uses
      these RLOCs when forwarding Map-Requests (re-formatted (reformatted as
      Encapsulated Map-Requests).  An ETR MAY <bcp14>MAY</bcp14> request that the
      Map-Server answer Map-Requests on its behalf by setting the
      "proxy Map-Reply" flag (P-bit) in the message.</t>

      <t hangText="Map-Notify message.</dd>
        <dt pn="section-3-1.15">Map-Notify message: ">A </dt>
        <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
      received and processed. An ETR requests that a Map-Notify be
      returned by setting the "want-map-notify" flag (M-bit) in the
      Map-Register message. Unlike a Map-Reply, a Map-Notify uses UDP
      port 4342 for both source and destination. Map-Notify messages
      are also sent to ITRs by Map-Servers when there are RLOC-set
      changes.</t>
    </list></t>

    <t>For RLOC-Set
      changes.</dd>
      </dl>
      <t indent="0" pn="section-3-2">For definitions of other terms, notably Ingress Tunnel
    Router (ITR), Egress Tunnel Router (ETR), and Re-encapsulating
    Tunnel Router (RTR), refer to the LISP Data-Plane data plane specification
    <xref target="I-D.ietf-lisp-rfc6830bis" />.</t> target="RFC9300" format="default" sectionFormat="of" derivedContent="RFC9300"/>.</t>
    </section>
    <section title="Basic Overview" anchor="OVERVIEW">
    <t> anchor="OVERVIEW" numbered="true" toc="include" removeInRFC="false" 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 EID-Prefixes in a LISP
    mapping database on behalf of a set of ETRs. When it receives a
    Map Request
    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
    an EID-Prefix. To publish its EID-Prefixes, an ETR periodically
    sends Map-Register messages to the Map-Server. A Map-Register
    message contains a list of EID-Prefixes plus a set of RLOCs that
    can be used to reach the ETRs.</t>

    <t>
      <t indent="0" pn="section-4-2"> When LISP-ALT <xref target="RFC6836"/> target="RFC6836" format="default" sectionFormat="of" derivedContent="RFC6836"/> is used as the mapping
    database, a Map-Server connects to the ALT network and acts as a
    "last-hop" ALT-Router.  Intermediate ALT-Routers forward
    Map-Requests to the Map-Server that advertises a particular
    EID-Prefix, and the Map-Server forwards them to the owning ETR,
    which responds with Map-Reply messages.</t>

    <t>
      <t indent="0" pn="section-4-3"> When LISP-DDT <xref target="RFC8111"/> target="RFC8111" format="default" sectionFormat="of" derivedContent="RFC8111"/> is used as
    the mapping database, a Map-Server sends the final Map-Referral
    messages from the Delegated Database Tree.</t>

    <t>
      <t indent="0" pn="section-4-4"> A Map-Resolver receives Encapsulated Map-Requests from its
    client ITRs and uses a mapping database system to find the
    appropriate ETR to answer those requests. On a LISP-ALT network, a
    Map-Resolver acts as a "first-hop" ALT-Router.  It has Generic
    Routing Encapsulation (GRE) tunnels configured to other
    ALT-Routers and uses BGP to learn paths to ETRs for different
    prefixes in the LISP-ALT database. The Map-Resolver uses this path
    information to forward Map-Requests over the ALT to the correct
    ETRs.  On a LISP-DDT network <xref target="RFC8111"/>, target="RFC8111" format="default" sectionFormat="of" derivedContent="RFC8111"/>, a
    Map-Resolver maintains a referral-cache referral cache and acts as a "first-hop"
    DDT-node.
    DDT node. The Map-Resolver uses the referral information to
    forward Map-Requests.</t>

    <t>
      <t indent="0" pn="section-4-5"> Note that while it is conceivable that a Map-Resolver could
    cache responses to improve performance, issues surrounding cache
    management would need to be resolved so that doing so will would be
    reliable and practical. In this specification, Map-Resolvers will
    operate only in a non-caching mode, decapsulating and forwarding
    Encapsulated Map Requests Map-Requests received from ITRs.  Any specification
    of caching functionality is out of scope for this document.</t>

    <t>
      <t indent="0" pn="section-4-6"> Note that a single device can implement the functions of both
    a Map-Server and a Map-Resolver, and in many cases cases, the functions
    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,
    respectively, to connecting Map-Resolvers and Map-Servers together to
    make up the Mapping System.</t>

    <t><vspace blankLines='50' /></t>
    </section>
    <section title="LISP anchor="lispcp" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-lisp-ipv4-and-ipv6-control-">LISP IPv4 and IPv6 Control-Plane Control Plane Packet Formats" anchor="lispcp">
      <t>The Formats</name>
      <t indent="0" pn="section-5-1">The following UDP packet formats are used by the LISP
      control plane.</t>
      <figure title="IPv4 align="left" suppress-title="false" pn="figure-1">
        <name slugifiedName="name-ipv4-udp-lisp-control-messa">IPv4 UDP LISP Control Message">
        <artwork><![CDATA[ Message</name>
        <artwork name="" type="" align="left" alt="" pn="section-5-2.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         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Identification        |Flags|      Fragment Offset    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Time to Live | Protocol = 17 |         Header Checksum       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Source Routing Locator                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Destination Routing Locator                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  / |           Source Port         |         Dest Port             |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  \ |           UDP Length          |        UDP Checksum           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                         LISP Message                          |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ]]></artwork>
</artwork>
      </figure>
      <figure title="IPv6 align="left" suppress-title="false" pn="figure-2">
        <name slugifiedName="name-ipv6-udp-lisp-control-messa">IPv6 UDP LISP Control Message">
        <artwork><![CDATA[ Message</name>
        <artwork name="" type="" align="left" alt="" pn="section-5-3.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| Traffic Class |           Flow Label                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Payload Length        | Next Header=17|   Hop Limit   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                     Source Routing Locator                    +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                  Destination Routing Locator                  +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  / |           Source Port         |         Dest Port             |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  \ |           UDP Length          |        UDP Checksum           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                         LISP Message                          |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ]]></artwork>
</artwork>
      </figure>

    <t>When
      <t indent="0" pn="section-5-4">When a UDP Map-Request, Map-Register, or
      Map-Notify (when used
    as a notification message) are is sent, the UDP source port is chosen
    by the sender and the destination UDP port number is set to
    4342. When a UDP Map-Reply, Map-Notify (when used as an
    acknowledgement
    acknowledgment to a Map-Register), or Map-Notify-Ack are is sent,
    the source UDP port number is set to 4342 and the destination UDP
    port number is copied from the source port of either the
    Map-Request or the invoking data packet. Implementations MUST <bcp14>MUST</bcp14> be
    prepared to accept packets when either the source port or
    destination UDP port is set to 4342 due to NATs changing port
    number values.</t>

	<t>The
      <t indent="0" pn="section-5-5">The 'UDP Length' field will reflect the length of the UDP
	header and the LISP Message payload. LISP is expected to be deployed
	by cooperating entities communicating over underlays. Deployers are
	expected to set the MTU according to the specific deployment guidelines
	to prevent fragmentation of either the inner packet or the outer
  encapsulated packet. For deployments not aware of the underlay
	restrictions on the path MTU, the message size MUST <bcp14>MUST</bcp14> be limited to 576 bytes
	for IPv4 or 1280 bytes for IPv6 -considering -- considering the entire IP packet- packet -- as outlined in <xref target="RFC8085"/>.</t>

    <t>The target="RFC8085" format="default" sectionFormat="of" derivedContent="RFC8085"/>.</t>
      <t indent="0" pn="section-5-6">The UDP checksum is computed and set to non-zero for all
    messages sent to or from port 4342.  It MUST <bcp14>MUST</bcp14> be checked on
    receipt, and if the checksum fails, the control message MUST <bcp14>MUST</bcp14> be
    dropped <xref target="RFC1071"/>.</t>

    <t>The target="RFC1071" format="default" sectionFormat="of" derivedContent="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
    message boundaries.</t>

    <t><vspace blankLines='50' /></t>
      <section title="LISP numbered="true" toc="include" removeInRFC="false" pn="section-5.1">
        <name slugifiedName="name-lisp-control-packet-type-al">LISP Control Packet Type Allocations">
      <t>This Allocations</name>
        <t indent="0" pn="section-5.1-1">This section defines the LISP control message formats and
      summarizes for IANA the LISP Type codes assigned by this
      document. For completeness, the summary below includes the LISP
      Shared Extension Message assigned by <xref
      target="I-D.ietf-lisp-rfc8113bis"/>. target="RFC9304" format="default" sectionFormat="of" derivedContent="RFC9304"/>.  Message type definitions
      are:</t>

      <figure> <artwork><![CDATA[
    Reserved:                          0     b'0000'
    LISP Map-Request:                  1     b'0001'
    LISP Map-Reply:                    2     b'0010'
    LISP Map-Register:                 3     b'0011'
    LISP Map-Notify:                   4     b'0100'
    LISP Map-Notify-Ack:               5     b'0101'
    LISP Map-Referral:                 6     b'0110'
    Unassigned                         7     b'0111'
    LISP
        <table align="center" pn="table-1">
          <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">Codepoint</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">Reserved</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">b'0000'</td>
            </tr>
            <tr>
              <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: 8     b'1000'
    Unassigned                         9-14  b'1001'- b'1110'
    LISP 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 Message:     15    b'1111'
      ]]></artwork> </figure>

      <t>Protocol Message</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 new message formats are
      recommended to use the LISP Shared Extension Message Type described
      in <xref target="I-D.ietf-lisp-rfc8113bis"/>.</t>

      <t>All target="RFC9304" format="default" sectionFormat="of" derivedContent="RFC9304"/>.</t>
        <t indent="0" pn="section-5.1-4">All LISP Control-Plane control plane messages use Address Family
      Identifiers (AFI) (AFIs) <xref target="AFI"/> target="AFN" format="default" sectionFormat="of" derivedContent="AFN"/> or LISP Canonical Address
      Format (LCAF) entries <xref target="RFC8060"/> formats target="RFC8060" format="default" sectionFormat="of" derivedContent="RFC8060"/> to encode either
      fixed
      fixed-length or variable length variable-length addresses. This includes explicit
      fields in each control message or part of EID-records EID-Records or
      RLOC-records
      RLOC-Records in commonly formatted messages. LISP control-plane control plane
      messages that include an unrecognized AFI MUST <bcp14>MUST</bcp14> be
      dropped
      dropped, and the event MUST <bcp14>MUST</bcp14> be logged.</t>

      <t>The
        <t indent="0" pn="section-5.1-5">The LISP control-plane control plane describes how other data-planes data planes can
      encode messages to support the Soliciting soliciting of Map-Requests as well as
      RLOC-probing
      RLOC-Probing procedures.</t>

      <t><vspace blankLines='50' /></t>
      </section>
      <section title="Map-Request anchor="NONCE" numbered="true" toc="include" removeInRFC="false" pn="section-5.2">
        <name slugifiedName="name-map-request-message-format">Map-Request Message Format" anchor="NONCE">
      <figure> <artwork><![CDATA[ Format</name>
        <artwork name="" type="" align="left" alt="" pn="section-5.2-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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Type=1 |A|M|P|S|p|s|R|R|  Rsvd   |L|D|   IRC   | Record Count  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Nonce . . .                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         . . . Nonce                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Source-EID-AFI        |   Source EID Address  ...     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         ITR-RLOC-AFI 1        |    ITR-RLOC Address 1  ...    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                              ...                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         ITR-RLOC-AFI n        |    ITR-RLOC Address n  ...    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  / |   Reserved    | EID mask-len  |        EID-Prefix-AFI         |
Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  \ |                       EID-Prefix  ...                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Map-Reply Record  ...                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ]]></artwork> </figure>

      <t>Packet
</artwork>
        <t indent="0" pn="section-5.2-2">Packet field descriptions:</t>
      <t><list style="hanging">
        <t hangText="Type: ">1 (Map-Request)</t>

        <t hangText="A:"> This
        <dl newline="false" spacing="normal" indent="3" pn="section-5.2-3">
          <dt pn="section-5.2-3.1">Type: </dt>
          <dd pn="section-5.2-3.2">1 (Map-Request)</dd>
          <dt pn="section-5.2-3.3">A:</dt>
          <dd pn="section-5.2-3.4">This is an authoritative bit, it bit. It is set to 1
        when an ITR wants the destination site to return the Map-Reply
        rather than the mapping database system returning a Map-Reply, Map-Reply and
        is set to 0 otherwise.</t>

       <t hangText="M:"> This otherwise.</dd>
          <dt pn="section-5.2-3.5">M:</dt>
          <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
        the Map-Request.</t>

        <t hangText="P:"> This Map-Request.</dd>
          <dt pn="section-5.2-3.7">P:</dt>
          <dd pn="section-5.2-3.8">This is the probe-bit, which indicates that a
        Map-Request MUST <bcp14>MUST</bcp14> be treated as a Locator reachability
        probe. The receiver MUST <bcp14>MUST</bcp14> respond with a Map-Reply with the
        probe-bit set, indicating that the Map-Reply is a Locator
        reachability probe reply, with the nonce copied from the
        Map-Request. See RLOC-Probing <xref target="rloc-probe"/>
        "<xref target="rloc-probe" format="title" sectionFormat="of" derivedContent="RLOC-Probing Algorithm"/>" (<xref target="rloc-probe" format="default" sectionFormat="of" derivedContent="Section 7.1"/>) for
        more details. This RLOC-probe RLOC-Probe Map-Request MUST NOT <bcp14>MUST NOT</bcp14> be sent to
        the mapping system. Mapping System. If a Map-Resolver or Map-Server receives a
        Map-Request with the probe-bit set, it MUST <bcp14>MUST</bcp14> drop the message.</t>

        <t hangText="S:"> message.</dd>
          <dt pn="section-5.2-3.9">S:</dt>
          <dd pn="section-5.2-3.10"> This is the Solicit-Map-Request (SMR)
        bit. See Solicit-Map-Request (SMRs) <xref target="SMR"/> for
        details.</t>

        <t hangText="p:"> "<xref target="SMR" format="title" sectionFormat="of" derivedContent="Solicit-Map-Request (SMR)"/>" (<xref target="SMR" format="default" sectionFormat="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 PITR Proxy Ingress Tunnel Router (PITR) bit. This bit is set to 1
        when a PITR sends a Map-Request. The use of this bit is deployment-specific.</t>

        <t hangText="s:"> deployment specific.</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 set
        to 1 when an xTR is sending a Map-Request in response to a
        received SMR-based Map-Request.</t>

        <t hangText="R:">This Map-Request.</dd>
          <dt pn="section-5.2-3.15">R:</dt>
          <dd pn="section-5.2-3.16">This reserved and unassigned bit MUST <bcp14>MUST</bcp14> be set to 0 on
        transmit and MUST <bcp14>MUST</bcp14> be ignored on receipt.</t>

        <t hangText="Rsvd:">This receipt.</dd>
          <dt pn="section-5.2-3.17">Rsvd:</dt>
          <dd pn="section-5.2-3.18">This field MUST <bcp14>MUST</bcp14> be set to 0 on transmit
        and MUST <bcp14>MUST</bcp14> be ignored on receipt.</t>

        <t hangText="L:"> 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
        is part of the RLOC-set RLOC-Set for the LISP site. The L-bit is set to
        1 when the RLOC is the sender's IP address.</t>

        <t hangText="D:"> address.</dd>
          <dt pn="section-5.2-3.21">D:</dt>
          <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"/>. target="SMR" format="default" sectionFormat="of" derivedContent="Section 6.1"/>. When
        an xTR sends an SMR message, it doesn't need a
        Map-Reply returned. When this bit is set, the receiver of the
        Map-Request does not return a Map-Reply.</t>

        <t hangText="IRC:"> Map-Reply.</dd>
          <dt pn="section-5.2-3.23">IRC:</dt>
          <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',
        'ITR-RLOC Address') fields present in this message.  At least
        one (ITR-RLOC-AFI, ITR-RLOC-Address) ITR-RLOC Address) pair MUST <bcp14>MUST</bcp14> be encoded.
        Multiple 'ITR-RLOC Address' fields are used, so a Map-Replier
        can select which destination address to use for a
        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,
        there are 2 ITR-RLOC addresses encoded, and so on up to 31,
        which encodes a total of 32 ITR-RLOC addresses.</t>

        <t hangText="Record Count:"> addresses.</dd>
          <dt pn="section-5.2-3.25">Record Count:</dt>
          <dd pn="section-5.2-3.26"> This is the number of records in
        this Map-Request message.  A record is comprised of the
        portion of the packet that is labeled 'Rec' above and occurs
        the number of times equal to Record Count. For this version of
        the protocol, a receiver MUST <bcp14>MUST</bcp14> accept and process Map-Requests
        that contain one or more records, but a sender MUST <bcp14>MUST</bcp14> only send
        Map-Requests containing one record.</t>

        <t hangText="Nonce:"> 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
        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 nonce MUST <bcp14>MUST</bcp14> be generated by a
        properly seeded pseudo-random source, source; for example, see as an example
        <xref target="RFC4086" />.</t>

        <t hangText="Source-EID-AFI:"> format="default" sectionFormat="of" derivedContent="RFC4086"/>.</dd>
          <dt pn="section-5.2-3.29">Source-EID-AFI:</dt>
          <dd pn="section-5.2-3.30"> This is the address family of
        the 'Source EID Address' field.</t>

        <t hangText="Source field.</dd>
          <dt pn="section-5.2-3.31">Source EID Address:"> Address:</dt>
          <dd pn="section-5.2-3.32"> This is the EID of the
        source host that originated the packet that caused the
        Map-Request. When Map-Requests are used for refreshing a
        Map-Cache entry or for RLOC-Probing, an AFI value of 0 is used used,
        and this field is of zero length.</t>

        <t hangText="ITR-RLOC-AFI:"> length.</dd>
          <dt pn="section-5.2-3.33">ITR-RLOC-AFI:</dt>
          <dd pn="section-5.2-3.34"> This is the address family of the
        'ITR-RLOC Address' field that follows this field.</t>

        <t hangText="ITR-RLOC Address:"> field.</dd>
          <dt pn="section-5.2-3.35">ITR-RLOC Address:</dt>
          <dd pn="section-5.2-3.36"> This is used to give the ETR
        the option of selecting the destination address from any
        address family for the Map-Reply message. This address MUST <bcp14>MUST</bcp14> be
        a routable RLOC address of the sender of the Map-Request
        message.</t>

        <t hangText="EID mask-len:">
        message.</dd>
          <dt pn="section-5.2-3.37">EID mask-len:</dt>
          <dd pn="section-5.2-3.38"> This is the mask length for the
        EID-Prefix.</t>

        <t hangText="EID-Prefix-AFI:">
        EID-Prefix.</dd>
          <dt pn="section-5.2-3.39">EID-Prefix-AFI:</dt>
          <dd pn="section-5.2-3.40"> This is the address family of
        the EID-Prefix according to <xref target="AFI" /> target="AFN" format="default" sectionFormat="of" derivedContent="AFN"/> and <xref
        target="RFC8060"/>.</t>

        <t hangText="EID-Prefix:"> target="RFC8060" format="default" sectionFormat="of" derivedContent="RFC8060"/>.</dd>
          <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
        address family when the EID-Prefix-AFI is 1 or 2,
        respectively. For other AFIs <xref target="AFI"/>, target="AFN" format="default" sectionFormat="of" derivedContent="AFN"/>, the address
        length varies varies, and for the LCAF AFI AFI, the format is defined in
        <xref target="RFC8060"/>. target="RFC8060" format="default" sectionFormat="of" derivedContent="RFC8060"/>.  When a Map-Request is sent by an
        ITR because a data packet is received for a destination where
        there is no mapping entry, the EID-Prefix is set to the
        destination IP address of the data packet, and the 'EID
        mask-len' field is set to 32 or 128 for IPv4 or IPv6,
        respectively. When an xTR wants to query a site about the
        status of a mapping it already has cached, the EID-Prefix used
        in the Map-Request has the same mask-length mask length as the EID-Prefix
        returned from the site when it sent a Map-Reply message.</t>

        <t hangText="Map-Reply Record:"> message.</dd>
          <dt pn="section-5.2-3.43">Map-Reply Record:</dt>
          <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
        format. This Map-Reply record contains the EID-to-RLOC mapping
        entry associated with the Source source EID. This allows the ETR that
        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 validated by the Mapping System.</t>
      </list></t> System.</dd>
        </dl>
      </section>
      <section title="EID-to-RLOC anchor="MAPREQ" numbered="true" toc="include" removeInRFC="false" pn="section-5.3">
        <name slugifiedName="name-eid-to-rloc-udp-map-request">EID-to-RLOC UDP Map-Request Message" anchor="MAPREQ">
      <t>A 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
      refresh a mapping before TTL Time to Live (TTL) expiration. For the initial case,
      the destination IP address used for the Map-Request is the data
      packet's destination address (i.e., the destination EID) that
      had a mapping cache lookup failure. For the latter two cases,
      the destination IP address used for the Map-Request is one of
      the RLOC addresses from the Locator-Set of the Map-Cache
      entry. The source address is either an IPv4 or IPv6 RLOC
      address, depending on whether the Map-Request is using an IPv4
      or IPv6 header, respectively. In all cases, the UDP source port
      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
      well-known destination port number 4342.  A successful
      Map-Reply, which is one that has a nonce that matches an
      outstanding Map-Request nonce, will update the cached set of
      RLOCs associated with the EID-Prefix range.</t>

      <t>One
        <t indent="0" pn="section-5.3-2">One or more Map-Request ('ITR-RLOC-AFI', 'ITR-RLOC-Address') 'ITR-RLOC Address')
      fields MUST <bcp14>MUST</bcp14> be filled in by the ITR. The number of fields (minus
      1) encoded MUST <bcp14>MUST</bcp14> be placed in the 'IRC' field. The ITR MAY <bcp14>MAY</bcp14>
      include all locally configured Locators in this list or just
      provide one locator address Routing Locator Address from each address family it
      supports. If the ITR erroneously provides no ITR-RLOC addresses,
      the Map-Replier MUST <bcp14>MUST</bcp14> drop the Map-Request.</t>

      <t>Map-Requests
        <t indent="0" pn="section-5.3-3">Map-Requests can also be LISP encapsulated using UDP
      destination port&nbsp;4342 port 4342 with a LISP Type value set to
      "Encapsulated Control Message", when sent from an ITR to a
      Map-Resolver.  Likewise, Map-Requests are LISP encapsulated the
      same way from a Map-Server to an ETR.  Details on Encapsulated
      Map-Requests and Map-Resolvers can be found in <xref target="encap-mr" />.</t>

      <t>Map-Requests MUST format="default" sectionFormat="of" derivedContent="Section 5.8"/>.</t>
        <t indent="0" pn="section-5.3-4">Map-Requests <bcp14>MUST</bcp14> be rate-limited rate limited to 1 per second per EID-prefix. EID-Prefix.
      After 10 retransmits without receiving the corresponding Map-Reply Map-Reply, the sender MUST <bcp14>MUST</bcp14> wait 30 seconds.</t>

      <t>An
        <t indent="0" pn="section-5.3-5">An ITR that is configured with mapping database information
      (i.e., it is also an ETR) MAY <bcp14>MAY</bcp14> optionally include those mappings
      in a Map-Request.  When an ETR configured to accept and verify
      such "piggybacked" mapping data receives such a Map-Request and
      it does not have this mapping in the Map-Cache, it MUST <bcp14>MUST</bcp14> originate
      a "verifying Map-Request" through the mapping database to validate
      thge
      the "piggybacked" mapping data.</t>

      <t><vspace blankLines='50' /></t>
      </section>
      <section title="Map-Reply anchor="MR-FORMAT" numbered="true" toc="include" removeInRFC="false" pn="section-5.4">
        <name slugifiedName="name-map-reply-message-format">Map-Reply Message Format" anchor="MR-FORMAT">
      <figure> <artwork><![CDATA[ Format</name>
        <artwork name="" type="" align="left" alt="" pn="section-5.4-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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Type=2 |P|E|S|          Reserved               | Record Count  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Nonce . . .                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         . . . Nonce                           |
+->
+-&gt; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   |                          Record TTL                           |
|   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R   | Locator Count | EID mask-len  | ACT |A|      Reserved         |
e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c   | Rsvd  |  Map-Version Number   |       EID-Prefix-AFI          |
o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r   |                          EID-Prefix                           |
d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o |        Unused Flags     |L|p|R|           Loc-AFI             |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  \|                             Locator                           |
+->
+-&gt; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ]]></artwork> </figure>

      <t>Packet
</artwork>
        <t indent="0" pn="section-5.4-2">Packet field descriptions:</t>
      <t><list style="hanging">
        <t hangText="Type: ">2 (Map-Reply)</t>

        <t hangText="P:">
        <dl newline="false" spacing="normal" indent="3" pn="section-5.4-3">
          <dt pn="section-5.4-3.1">Type: </dt>
          <dd pn="section-5.4-3.2">2 (Map-Reply)</dd>
          <dt pn="section-5.4-3.3">P:</dt>
          <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
        Map-Request. The 'Nonce' field must contain a copy of the
        nonce value from the original Map-Request. See RLOC-probing
        <xref target="rloc-probe"/>
        "<xref target="rloc-probe" format="title" sectionFormat="of" derivedContent="RLOC-Probing Algorithm"/>" (<xref target="rloc-probe" format="default" sectionFormat="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
        each EID-record EID-Record included in the message MUST <bcp14>MUST</bcp14> be set to 1,
        otherwise MUST 1;
        otherwise, it <bcp14>MUST</bcp14> be silently discarded.</t>

        <t hangText="E:"> discarded.</dd>
          <dt pn="section-5.4-3.5">E:</dt>
          <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
        for the Echo-Nonce Locator reachability algorithm. See
        Echo-Nonce
Section <xref target="RFC9300" section="10.1" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9300#section-10.1" derivedContent="RFC9300">"Echo-Nonce Algorithm"</xref> of <xref target="I-D.ietf-lisp-rfc6830bis" /> target="RFC9300" format="default" sectionFormat="of" derivedContent="RFC9300"/> for more
        details.</t>

        <t hangText="S:">
        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
        end of the Map-Reply. The details Details can be found in <xref
        target="I-D.ietf-lisp-sec"/>.</t>
      </list></t>

      <figure> <artwork><![CDATA[ target="RFC9303" format="default" sectionFormat="of" derivedContent="RFC9303"/>.</dd>
        </dl>
        <artwork name="" type="" align="left" alt="" pn="section-5.4-4">
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    AD Type    |       Authentication Data Content . . .       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ]]></artwork> </figure>

      <t><list style="hanging">
        <t hangText="Reserved:">
</artwork>
        <dl newline="false" spacing="normal" indent="3" pn="section-5.4-5">
          <dt pn="section-5.4-5.1">Reserved:</dt>
          <dd pn="section-5.4-5.2"> This unassigned field MUST <bcp14>MUST</bcp14> be set to 0 on
        transmit and MUST <bcp14>MUST</bcp14> be ignored on receipt.</t>

        <t hangText="Record Count:"> receipt.</dd>
          <dt pn="section-5.4-5.3">Record Count:</dt>
          <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
        the packet labeled 'Record' above and occurs the number of
        times equal to Record Count. Note that the reply count can
        be larger than the requested count, for instance instance, when more-specifics more-specific prefixes are present.</t>

        <t hangText="Nonce:"> present.</dd>
          <dt pn="section-5.4-5.5">Nonce:</dt>
          <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>

        <t hangText="Record TTL:"> Map-Reply.</dd>
          <dt pn="section-5.4-5.7">Record TTL:</dt>
          <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
        is 0, the entry MUST <bcp14>MUST</bcp14> be removed from the cache immediately.
        If the value is 0xffffffff, the recipient can decide locally
        how long to store the mapping.</t>

        <t hangText="Locator Count:"> mapping.</dd>
          <dt pn="section-5.4-5.9">Locator Count:</dt>
          <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 above as
        &apos;Loc&apos;.
        'Loc'. The Locator count can be 0, indicating that
        there are no Locators for the EID-Prefix.</t>

        <t hangText="EID mask-len:"> EID-Prefix.</dd>
          <dt pn="section-5.4-5.11">EID mask-len:</dt>
          <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>
          <dd pn="section-5.4-5.14">
            <t hangText="ACT:"> This indent="0" pn="section-5.4-5.14.1">This 3-bit field describes Negative
        Map-Reply actions. In any other message type, these bits are
        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
        encoded only in Map-Reply messages. They are used to tell an
        ITR or PITR why a an empty locator-set Locator-Set was returned from the
        mapping system
        Mapping System and how it stores the map-cache Map-Cache entry.
        See <xref target="act-iana"/> target="act-iana" format="default" sectionFormat="of" derivedContent="Section 12.3"/> for additional information.</t>

        <t><list style="hanging" hangIndent="4">
          <t hangText="(0) No-Action:">The
            <dl newline="false" spacing="normal" indent="4" pn="section-5.4-5.14.2">
              <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,
          and no packet encapsulation occurs.</t>

          <t hangText="(1) Natively-Forward:">The occurs.</dd>
              <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
          encapsulated or dropped but natively forwarded.</t>

          <t hangText="(2) Send-Map-Request:">The forwarded.</dd>
              <dt pn="section-5.4-5.14.2.5">(2) Send-Map-Request:</dt>
              <dd pn="section-5.4-5.14.2.6">The Map-Cache entry is
          created and flagged so that any packet matching this entry
          invokes sending a Map-Request.</t>

          <t hangText="(3) Drop/No-Reason:">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
          message SHOULD <bcp14>SHOULD</bcp14> be sent.</t>

	      <t hangText="(4) Drop/Policy-Denied:">A sent.</dd>
              <dt pn="section-5.4-5.14.2.9">(4) Drop/Policy-Denied:</dt>
              <dd pn="section-5.4-5.14.2.10">A packet that matches
	      this Map-Cache entry is dropped. The reason for the Drop
	      action is that a Map-Request for the target-EID target EID is being
	      policy denied
	      policy-denied by either an xTR or the mapping system.</t>

	      <t hangText="(5) Drop/Authentication-Failure:">A Mapping System.</dd>
              <dt pn="section-5.4-5.14.2.11">(5) Drop/Auth-Failure:</dt>
              <dd pn="section-5.4-5.14.2.12">A packet that
	      matches this Map-Cache entry is dropped.  The reason for the
	      Drop action is that a Map-Request for the target-EID target EID fails
	      an authentication verification-check verification check by either an xTR or the
	      mapping system.</t>
        </list></t>

        <t hangText="A:">
	      Mapping System.</dd>
            </dl>
          </dd>
          <dt pn="section-5.4-5.15">A:</dt>
          <dd pn="section-5.4-5.16"> The Authoritative bit MAY <bcp14>MAY</bcp14> only be set to 1 by an ETR.
        A Map-Server generating Map-Reply messages as a proxy MUST NOT <bcp14>MUST NOT</bcp14> set the A-bit to 1. This bit
        indicates to the requesting ITRs if the Map-Reply was
        originated by a LISP node managed at the site that owns the
        EID-Prefix.</t>

        <t hangText="Map-Version Number:">
        EID-Prefix.</dd>
          <dt pn="section-5.4-5.17">Map-Version Number:</dt>
          <dd pn="section-5.4-5.18"> When this 12-bit value is
        non-zero, the in an EID-Record of a
          Map-Reply sender message is informing the ITR what the
        version number non-zero, see <xref target="RFC9302" format="default" sectionFormat="of" derivedContent="RFC9302"/> for details.</dd>
          <dt pn="section-5.4-5.19">EID-Prefix-AFI:</dt>
          <dd pn="section-5.4-5.20">This is for the EID record contained in the
        Map-Reply. The ETR can allocate this number internally but
        MUST coordinate this value with other ETRs for the site. When
        this value is 0, there is no versioning information
        conveyed. The Map-Version Number can be included in
        Map-Request and Map-Register messages. See Map-Versioning
        <xref target="I-D.ietf-lisp-6834bis" /> for more details.</t>

        <t hangText="EID-Prefix-AFI:"> Address address family of the
        EID-Prefix according to <xref target="AFI" /> target="AFN" format="default" sectionFormat="of" derivedContent="AFN"/> and <xref
        target="RFC8060"/>.</t>

        <t hangText="EID-Prefix:"> target="RFC8060" format="default" sectionFormat="of" derivedContent="RFC8060"/>.</dd>
          <dt pn="section-5.4-5.21">EID-Prefix:</dt>
          <dd pn="section-5.4-5.22"> This prefix is 4 octets for an IPv4
        address family and 16 octets for an IPv6 address family.</t>

        <t hangText="Priority:"> family.</dd>
          <dt pn="section-5.4-5.23">Priority:</dt>
          <dd pn="section-5.4-5.24"> 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
        fashion.  A value of 255 means the RLOC MUST NOT <bcp14>MUST NOT</bcp14> be used for
        unicast forwarding.</t>

        <t hangText="Weight:"> forwarding.</dd>
          <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
        traffic between them. Weight is encoded as a relative weight
        of total unicast packets that match the mapping entry. For
        example, if there are 4 Locators in a Locator-Set, where the
        Weights assigned are 30, 20, 20, and 10, the first Locator
        will get 37.5% of the traffic, the 2nd second and 3rd third Locators will
        each get 25% of the traffic, and the 4th fourth Locator will get 12.5% of
        the traffic. If all Weights for a Locator-Set are equal, the
        receiver of the Map-Reply will decide how to load-split the
        traffic. See RLOC-hashing Section <xref target="RFC9300" section="12" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9300#section-12" derivedContent="RFC9300">"Routing Locator Hashing"</xref> of <xref
        target="I-D.ietf-lisp-rfc6830bis" /> target="RFC9300" format="default" sectionFormat="of" derivedContent="RFC9300"/> for a suggested hash
        algorithm to distribute the load across Locators with the same
        Priority and equal Weight values.</t>

        <t hangText="M Priority:"> values.</dd>
          <dt pn="section-5.4-5.27">M Priority:</dt>
          <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
        an ITR in a source multicast site for building multicast
        distribution trees. A value of 255 means the RLOC MUST NOT <bcp14>MUST NOT</bcp14> be
        used for joining a multicast distribution tree.  For more
        details, see <xref target="RFC6831" />.</t>

        <t hangText="M Weight:">When format="default" sectionFormat="of" derivedContent="RFC6831"/>.</dd>
          <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
        multicast distribution trees across multiple ITRs. The Weight
        is encoded as a relative weight (similar to the unicast
        Weights) of the total number of trees built to the source site
        identified by the EID-Prefix. If all Weights for a Locator-Set
        are equal, the receiver of the Map-Reply will decide how to
        distribute multicast state across ITRs. For more details, see
        <xref target="RFC6831" />.</t>

        <t hangText="Unused Flags:">These format="default" sectionFormat="of" derivedContent="RFC6831"/>.</dd>
          <dt pn="section-5.4-5.31">Unused Flags:</dt>
          <dd pn="section-5.4-5.32">These are set to 0 when sending
        and ignored on receipt.</t>

        <t hangText="L:">When receipt.</dd>
          <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.
        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
        Locator-Set.</t>

        <t hangText="p:">When
        Locator-Set.</dd>
          <dt pn="section-5.4-5.35">p:</dt>
          <dd pn="section-5.4-5.36">When this bit is set, an ETR informs the
        RLOC-Probing ITR that the locator address Routing Locator Address for which this bit
        is set is the one being RLOC-probed RLOC-Probed and may be different from
        the source address of the Map-Reply. An ITR that RLOC-probes RLOC-Probes a
        particular Locator MUST <bcp14>MUST</bcp14> use this Locator for retrieving the
        data structure used to store the fact that the Locator is
        reachable. The p-bit is set for a single Locator in the same
        Locator-Set.  If an implementation sets more than one p-bit
        erroneously, the receiver of the Map-Reply MUST <bcp14>MUST</bcp14> select the
        first set p-bit Locator. The p-bit MUST NOT <bcp14>MUST NOT</bcp14> be set for Locator-Set
        records sent in Map-Request and Map-Register messages.</t>

        <t hangText="R:">This 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
        receiver may find this useful to know if the Locator is up but
        not necessarily reachable from the receiver's point of
        view.</t>

        <t hangText="Locator:">This
        view.</dd>
          <dt pn="section-5.4-5.39">Locator:</dt>
          <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
        an ITR as a destination RLOC address in the outer header of a
        LISP encapsulated packet. Note that the destination RLOC
        address of a LISP encapsulated packet MAY <bcp14>MAY</bcp14> be an anycast
        address. A source RLOC of a LISP encapsulated packet can be an
        anycast address as well.  The source or destination RLOC MUST
        NOT <bcp14>MUST NOT</bcp14> be the broadcast address (255.255.255.255 or any subnet
        broadcast address known to the router) and MUST NOT <bcp14>MUST NOT</bcp14> be a
        link-local multicast address.  The source RLOC MUST NOT <bcp14>MUST NOT</bcp14> be a
        multicast address. The destination RLOC SHOULD <bcp14>SHOULD</bcp14> be a multicast
        address if it is being mapped from a multicast destination
        EID.</t>
      </list></t>

    <t>Map-Reply MUST
        EID.</dd>
        </dl>
        <t indent="0" pn="section-5.4-6">Map-Replies <bcp14>MUST</bcp14> be rate-limited, it rate limited. It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that a Map-Reply
      for the same destination RLOC be sent to no more than one packets per packet every 3 seconds.</t>

	  <t>The
        <t indent="0" pn="section-5.4-7">The Record format, as defined here, is used both in the Map-Reply
    and Map-Register messages, messages; this includes all the field definitions. </t>
      </section>
      <section title="EID-to-RLOC anchor="MR" numbered="true" toc="include" removeInRFC="false" pn="section-5.5">
        <name slugifiedName="name-eid-to-rloc-udp-map-reply-m">EID-to-RLOC UDP Map-Reply Message" anchor="MR">
      <t>A Message</name>
        <t indent="0" pn="section-5.5-1">A Map-Reply returns an EID-Prefix with a mask-length mask length that
      is less than or equal to the EID being requested. The EID being
      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
      in the Map-Reply are routable IP addresses of all ETRs for the
      LISP site. Each RLOC conveys status reachability but does not
      convey path reachability from a requester's
      perspective. Separate testing of path reachability is
      required. See RLOC-reachability <xref "<xref target="rloc-probe" /> format="title" sectionFormat="of" derivedContent="RLOC-Probing Algorithm"/>" (<xref target="rloc-probe" format="default" sectionFormat="of" derivedContent="Section 7.1"/>) for
      details.</t>

      <t>Note
        <t indent="0" pn="section-5.5-2">Note that a Map-Reply MAY <bcp14>MAY</bcp14> contain different EID-Prefix
      granularity (prefix + mask-length) mask length) than the Map-Request that triggers
      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
      requester updates its cache with the new prefix information and
      granularity. For example, a requester with two cached
      EID-Prefixes that are covered by a Map-Reply containing one
      less-specific prefix replaces the entry with the less-specific
      EID-Prefix. Note that the reverse, replacement of one
      less-specific prefix with multiple more-specific prefixes, can
      also occur, not by removing the less-specific prefix but rather
      by adding the more-specific prefixes that, during a lookup, will
      override the less-specific prefix.</t>

      <t>When
        <t indent="0" pn="section-5.5-3">When an EID moves out of a LISP site <xref
      target="I-D.ietf-lisp-eid-mobility"/>, target="EID-MOBILITY" format="default" sectionFormat="of" derivedContent="EID-MOBILITY"/>, the database mapping system Mapping System
      may have overlapping EID-prefixes. EID-Prefixes. Or when a LISP site is
      configured with multiple sets of ETRs that support different
      EID-prefix mask-lengths,
      EID-Prefix mask lengths, the database mapping system Mapping System may have
      overlapping EID-prefixes. EID-Prefixes. When overlapping EID-prefixes EID-Prefixes exist, a
      Map-Request with an EID that best matches any EID-Prefix MUST <bcp14>MUST</bcp14> be
      returned in a single Map-Reply message. For instance, if an ETR
      had database mapping entries for EID-Prefixes:</t>

      <figure> <artwork><![CDATA[
        <artwork name="" type="" align="left" alt="" pn="section-5.5-4">
  2001:db8::/32
  2001:db8:1::/48
  2001:db8:1:1::/64
  2001:db8:1:2::/64
      ]]></artwork></figure>

      <t>A
</artwork>
        <t indent="0" pn="section-5.5-5">A Map-Request for EID 2001:db8:1:1::1 would cause a Map-Reply
      with a record count of 1 to be returned with a mapping record
      EID-Prefix of 2001:db8:1:1::/64.</t>

      <t>A
        <t indent="0" pn="section-5.5-6">A Map-Request for EID 2001:db8:1:5::5 would cause a Map-Reply
      with a record count of 3 to be returned with mapping records for
      EID-Prefixes 2001:db8:1::/48, 2001:db8:1:1::/64, and
      2001:db8:1:2::/64, filling out the /48 with more-specifics more-specific prefixes
      that exist in the mapping system.</t>

      <t>Note Mapping System.</t>
        <t indent="0" pn="section-5.5-7">Note that not all overlapping EID-Prefixes need to be
      returned but only the more-specific entries (note that in the
      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. When more than one EID-Prefix is returned, all SHOULD <bcp14>SHOULD</bcp14> use
      the same Time to Live TTL value so they can all time out at the same
      time. When a more-specific EID-Prefix is received later, its
      Time to Live
      TTL value in the Map-Reply record can be stored even
      when other less-specific entries exist. When a less-specific
      EID-Prefix is received later, its Map-Cache expiration time
      SHOULD
      <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
      integrity of the EID-Prefix set is wholly maintained and so no
      more-specific entries are removed from the Map-Cache while
      keeping less-specific entries.</t>

      <t>For
        <t indent="0" pn="section-5.5-8">For scalability, it is expected that aggregation of EID addresses
      into EID-Prefixes will allow one Map-Reply to satisfy a mapping
      for the EID addresses in the prefix range, thereby reducing the
      number of Map-Request messages.</t>

      <t>Map-Reply
        <t indent="0" pn="section-5.5-9">Map-Reply records can have an empty Locator-Set.  A Negative
      Map-Reply is a Map-Reply with an empty Locator-Set.  Negative
      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
      applications for Negative Map-Replies. The first is for a
      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
      source quench Map-Requests that are sent for non-allocated
      EIDs.</t>

      <t>For
        <t indent="0" pn="section-5.5-10">For each Map-Reply record, the list of Locators in a
      Locator-Set MUST <bcp14>MUST</bcp14> be sorted
      in order of ascending IP address where an IPv4 locator address Routing Locator
      Address is considered numerically 'less than' "less than" an IPv6 locator
      address.</t>

      <t>When Routing
	Locator Address.</t>
        <t indent="0" pn="section-5.5-11">When sending a Map-Reply message, the destination address is
      copied from one of the 'ITR-RLOC' fields from the
      Map-Request. The ETR can choose a locator address Routing Locator Address from one of
      the address families it supports. For Data-Probes, the
      destination address of the Map-Reply is copied from the source
      address of the Data-Probe message that is invoking the
      reply. The source address of the Map-Reply is one of the chosen local
      IP addresses chosen, to allow addresses; this allows Unicast Reverse Path Forwarding
      (uRPF) checks to succeed in the upstream service provider. The
      destination port of a Map-Reply message is copied from the
      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
      4342.</t>

      <t><vspace blankLines='50' /></t>
      </section>
      <section title="Map-Register anchor="MAPREG" numbered="true" toc="include" removeInRFC="false" pn="section-5.6">
        <name slugifiedName="name-map-register-message-format">Map-Register Message Format" anchor="MAPREG">
      <t>This Format</name>
        <t indent="0" pn="section-5.6-1">This section specifies the encoding format for the
      Map-Register message. The message is sent in UDP with a
      destination UDP port of 4342 and a randomly selected UDP source
      port number.</t>

      <t>The
        <t indent="0" pn="section-5.6-2">The fields below are used in multiple control messages. They
      are defined for Map-Register, Map-Notify Map-Notify, and Map-Notify-Ack message
      types.</t>

      <t>The
        <t indent="0" pn="section-5.6-3">The Map-Register message format is:</t>

      <figure> <artwork><![CDATA[
        <artwork name="" type="" align="left" alt="" pn="section-5.6-4">
     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=3 |P|S|I|        Reserved       |E|T|a|R|M| Record Count  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Nonce . . .                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         . . . Nonce                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Key ID     | Algorithm ID  |  Authentication Data Length   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                     Authentication Data                       ~
+->
+-&gt; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   |                          Record TTL                           |
|   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R   | Locator Count | EID mask-len  | ACT |A|      Reserved         |
e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c   | Rsvd  |  Map-Version Number   |        EID-Prefix-AFI         |
o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r   |                          EID-Prefix                           |
d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o |        Unused Flags     |L|p|R|           Loc-AFI             |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  \|                             Locator                           |
+->
+-&gt; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ]]></artwork> </figure>

      <t>Packet
</artwork>
        <t indent="0" pn="section-5.6-5">Packet field descriptions:</t>

      <t><list style="hanging">
        <t hangText="Type: ">3 (Map-Register)</t>

        <t hangText="P:">This
        <dl newline="false" spacing="normal" indent="3" pn="section-5.6-6">
          <dt pn="section-5.6-6.1">Type: </dt>
          <dd pn="section-5.6-6.2">3 (Map-Register)</dd>
          <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
        1, the ETR sending the Map-Register message is requesting the
        Map-Server to proxy a Map-Reply. The Map-Server will send
        non-authoritative Map-Replies on behalf of the ETR.</t>

        <t hangText="S:">This ETR.</dd>
          <dt pn="section-5.6-6.5">S:</dt>
          <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
        supported.</t>

        <t hangText="I:">This target="RFC9303" format="default" sectionFormat="of" derivedContent="RFC9303"/> are
        supported.</dd>
          <dt pn="section-5.6-6.7">I:</dt>
          <dd pn="section-5.6-6.8">This is the ID-present bit. This bit is set to 1 to indicate that a 128
        bit xTR-ID
	  128-bit 'xTR-ID' field and a 64 bit Site-ID fields 64-bit 'Site-ID' field are present at the end
        of the Map-Register message.  If an xTR is configured with an
        xTR-ID and Site-ID, it MUST <bcp14>MUST</bcp14> set the I bit I-bit to 1 and include its
        xTR-ID and Site-ID in the Map-Register messages it generates.
        The combination of Site-ID plus xTR-ID uniquely identifies an
        xTR in a LISP domain and serves to track its last seen
        nonce.</t>

        <t hangText="Reserved:">This
        nonce.</dd>
          <dt pn="section-5.6-6.9">Reserved:</dt>
          <dd pn="section-5.6-6.10">This unassigned field MUST <bcp14>MUST</bcp14> be set to 0 on
        transmit and MUST <bcp14>MUST</bcp14> be ignored on receipt.</t>

        <t hangText="E:">This receipt.</dd>
          <dt pn="section-5.6-6.11">E:</dt>
          <dd pn="section-5.6-6.12">This is the Map-Register EID-notify bit. This
        is used by a First-Hop-Router (FHR) which First-Hop Router  that discovers a
        dynamic-EID.
        dynamic EID. This EID-notify based EID-notify-based Map-Register is sent by the
        FHR
        First-Hop Router to a same site xTR that propogates propagates the Map-Register to
        the mapping system. Mapping System. The site xTR keeps state to later
        Map-Notify the FHR First-Hop Router after the EID has moves moved away. See <xref
        target="I-D.ietf-lisp-eid-mobility"/> target="EID-MOBILITY" format="default" sectionFormat="of" derivedContent="EID-MOBILITY"/> for a detailed
        use-case.</t>

        <t hangText="T:">This
        use case.</dd>
          <dt pn="section-5.6-6.13">T:</dt>
          <dd pn="section-5.6-6.14">This is the use-TTL use TTL for timeout bit. When set
        to 1, the xTR wants the Map-Server to time out registrations
        based on the value in the "Record TTL" 'Record TTL' field of this
        message. Otherwise, the default timeout described in <xref
        target="reg"/> is used.</t>

        <t hangText="a:">This target="reg" format="default" sectionFormat="of" derivedContent="Section 8.2"/> is used.</dd>
          <dt pn="section-5.6-6.15">a:</dt>
          <dd pn="section-5.6-6.16">This is the merge-request bit. When set to 1,
        the xTR requests to merge RLOC-records RLOC-Records from different xTRs
        registering the same EID-record. EID-Record. See signal-free multicast Signal-Free Multicast
        <xref target="RFC8378"/> target="RFC8378" format="default" sectionFormat="of" derivedContent="RFC8378"/> for one
        use case example.</t>

        <t hangText="R:">This
        use-case example.</dd>
          <dt pn="section-5.6-6.17">R:</dt>
          <dd pn="section-5.6-6.18">This reserved and unassigned bit MUST <bcp14>MUST</bcp14> be set to 0 on
        transmit and MUST <bcp14>MUST</bcp14> be ignored on receipt.</t>

        <t hangText="M:">This 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
        response to sending a Map-Register message. The Map-Notify
        message sent by a Map-Server is used to acknowledge receipt of
        a Map-Register message.</t>

        <t hangText="Record Count:"> message.</dd>
          <dt pn="section-5.6-6.21">Record Count:</dt>
          <dd pn="section-5.6-6.22"> This is the number of records in
        this Map-Register message.  A record is comprised of that
        portion of the packet labeled 'Record' above and occurs the
        number of times equal to Record Count.</t>

        <t hangText="Nonce:"> Count.</dd>
          <dt pn="section-5.6-6.23">Nonce:</dt>
          <dd pn="section-5.6-6.24"> This 8-octet 'Nonce' field is
        incremented each time a Map-Register message is sent. When a
        Map-Register acknowledgement acknowledgment is requested, the nonce is
        returned by Map-Servers in Map-Notify messages.  Since the
        entire Map-Register message is authenticated, the 'Nonce'
        field serves to protect against Map-Register replay
        attacks. An ETR that registers to the mapping system SHOULD Mapping System <bcp14>SHOULD</bcp14>
        store the last nonce sent in persistent storage storage, so when it
        restarts
        restarts, it can continue using an incrementing nonce. If
        the ETR cannot support saving the nonce, then when it restarts restarts,
        it MUST <bcp14>MUST</bcp14> use a new authentication key to register to the
        mapping system.
        Mapping System. A Map-Server MUST <bcp14>MUST</bcp14> track and save in persistent
        storage the last nonce received for each ETR xTR-ID and key pair.
		If a Map-Register is received with a nonce
        value that is not greater than the saved nonce, it MUST <bcp14>MUST</bcp14> drop the
        Map-Register message and SHOULD <bcp14>SHOULD</bcp14> log the fact that a replay attack could
        have occurred.</t>

        <t hangText="Key ID:"> A 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
		keys are derived from the pre-shared secret to authenticate
		the origin and protect the integrity of the Map-Register.
		The Key ID allows to rotate rotating between multiple pre-shared
		secrets in a non disruptive nondisruptive way. The pre-shared secret MUST <bcp14>MUST</bcp14>
		be unique per each LISP "Site-ID" </t>

        <t hangText="Algorithm ID:"> Site-ID.</dd>
          <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)
		algorithms used to derive the key and to compute the Authentication
		Data of a Map-Register.  This 8-bit field identifies the KDF and
		MAC algorithm pair.  See <xref target="KEYS" /> format="default" sectionFormat="of" derivedContent="Section 12.5"/> for codepoint assignments.</t>

        <t hangText="Authentication assignments.</dd>
          <dt pn="section-5.6-6.29">Authentication Data Length:"> Length:</dt>
          <dd pn="section-5.6-6.30"> This is the length
        in octets of the 'Authentication Data' field that follows this
        field.  The length of the 'Authentication Data' field is
        dependent on the MAC algorithm used. The length field allows a
        device that doesn't know the MAC algorithm to correctly parse
        the packet.</t> packet.</dd>
          <dt pn="section-5.6-6.31">Authentication Data:</dt>
          <dd pn="section-5.6-6.32">
            <t hangText="Authentication Data:">This 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.
		The MAC output is computed as follows:</t>

		<t><list style="hanging" hangIndent="4">
	      <t hangText="1:">The
            <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-5.6-6.32.2">
              <li pn="section-5.6-6.32.2.1" derivedCounter="1.">The KDF algorithm is identified by the
		  field
		  'Algorithm ID' field according to the table in <xref target="KEYS"/>. target="KEYS" format="default" sectionFormat="of" derivedContent="Section 12.5"/>. Implementations of this specification MUST <bcp14>MUST</bcp14> implement HMAC-SHA-256-128 <xref target="RFC4868"/> target="RFC4868" format="default" sectionFormat="of" derivedContent="RFC4868"/> and SHOULD <bcp14>SHOULD</bcp14> implement HMAC-SHA-256-128+HKDF-SHA256 <xref target="RFC5869"/>
      .</t>
		  <t hangText="2:">The target="RFC5869" format="default" sectionFormat="of" derivedContent="RFC5869"/>.</li>
              <li pn="section-5.6-6.32.2.2" derivedCounter="2.">The MAC algorithm is identified by the field 'Algorithm ID' field
		  according to the table in <xref target="KEYS" />.</t>
	      <t hangText="3:">The format="default" sectionFormat="of" derivedContent="Section 12.5"/>.</li>
              <li pn="section-5.6-6.32.2.3" derivedCounter="3.">The pre-shared secret used to derive the per-message key is represented by PSK[Key ID], that is is, the pre-shared secret identified by the 'Key ID'.</t>
	      <t hangText="4:">The Key ID.</li>
              <li pn="section-5.6-6.32.2.4" derivedCounter="4.">The derived per-message key is computed as: per-msg-key=KDF(nonce+PSK[Key ID],s). Where the nonce is the value in the Nonce 'Nonce' field of the Map-Register, '+' "+" denotes concatenation and 's' "s" (the salt)
      is a string that
      corresponds to the message type being authenticated.  For
      Map-Register messages, it is equal to "Map-Register
      Authentication".  Similarly, for Map-Notify and Map-Notify-Ack
      messages, it is "Map-Notify Authentication" and
        "Map-Notify-Ack Authentication", respectively. For those Algorithm IDs defined in <xref target="KEYS"/> target="KEYS" format="default" sectionFormat="of" derivedContent="Section 12.5"/> that specify a 'none' KDF, the per-message key is computed as: per-msg-key = PSK[Key ID]. This means that the same key is used across multiple protocol messages.</t>
		  <t hangText="5:">The messages.</li>
              <li pn="section-5.6-6.32.2.5" derivedCounter="5.">The MAC output is computed using the MAC algorithm and
		  the per-msg-key over the entire Map-Register payload
		  (from and including the LISP message type field through the
		  end of the last RLOC record) RLOC-Record) with the authenticated data field preset to 0.</t>
		</list></t>

      </list></t>

      <t>The 0.</li>
            </ol>
          </dd>
        </dl>
        <t indent="0" pn="section-5.6-7">The definition of the rest of the Map-Register can be found
      in EID-record the EID-Record description in <xref target="MR-FORMAT"/>. 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 Map-Register message:</t>

      <t><list style="hanging">
        <t hangText="xTR-ID:">xTR-ID
        <dl newline="false" spacing="normal" indent="3" pn="section-5.6-8">
          <dt pn="section-5.6-8.1">xTR-ID:</dt>
          <dd pn="section-5.6-8.2">'xTR-ID' is a 128 bit 128-bit field at the end of
        the Map-Register message, starting after the final Record in
        the message. The xTR-ID is used to uniquely identify a an xTR.
        The same xTR-ID value MUST NOT <bcp14>MUST NOT</bcp14> be used in two different xTRs in the scope of the Site-ID.</t>

        <t hangText="Site-ID:">Site-ID Site-ID.</dd>
          <dt pn="section-5.6-8.3">Site-ID:</dt>
          <dd pn="section-5.6-8.4">'Site-ID' is a 64 bit 64-bit field at the end of
        the Map- Register Map-Register message, following the xTR-ID.  The Site-ID is
        used to uniquely identify to which site the xTR that sent the
        message belongs. This document does not specify a strict meaning for the Site-ID 'Site-ID' field.
        Informally
        Informally, it provides an indication that a group of xTRs have some relation, relationship, either administratively, topologically topologically, or otherwise.</t>
      </list></t>

      <t><vspace blankLines='50' /></t> otherwise.</dd>
        </dl>
      </section>
      <section title="Map-Notify/Map-Notify-Ack anchor="MAP-NOTIF-MAP-NOTIF-ACK" numbered="true" toc="include" removeInRFC="false" pn="section-5.7">
        <name slugifiedName="name-map-notify-and-map-notify-a">Map-Notify and Map-Notify-Ack Message Format">
      <t>This Formats</name>
        <t indent="0" pn="section-5.7-1">This section specifies the encoding format for the Map-Notify
      and Map-Notify-Ack messages. The messages are sent inside a UDP
      packet with source and destination UDP ports equal to 4342.</t>

      <t>The
        <t indent="0" pn="section-5.7-2">The Map-Notify and Map-Notify-Ack message formats are:</t>

      <figure> <artwork><![CDATA[
        <artwork name="" type="" align="left" alt="" pn="section-5.7-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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Type=4/5|             Reserved                 | Record Count  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Nonce . . .                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         . . . Nonce                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Key ID     | Algorithm ID  |  Authentication Data Length   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                     Authentication Data                       ~
+->
+-&gt; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   |                          Record TTL                           |
|   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R   | Locator Count | EID mask-len  | ACT |A|      Reserved         |
e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c   | Rsvd  |  Map-Version Number   |         EID-Prefix-AFI        |
o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r   |                          EID-Prefix                           |
d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o |        Unused Flags     |L|p|R|           Loc-AFI             |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  \|                             Locator                           |
+->
+-&gt; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ]]></artwork> </figure>

      <t>Packet
</artwork>
        <t indent="0" pn="section-5.7-4">Packet field descriptions:</t>
      <t><list style="hanging">
        <dl newline="false" spacing="normal" indent="3" pn="section-5.7-5">
          <dt pn="section-5.7-5.1">Type: </dt>
          <dd pn="section-5.7-5.2">4/5 (Map-Notify/Map-Notify-Ack)</dd>
        </dl>
        <t hangText="Type: ">4/5 (Map-Notify/Map-Notify-Ack)</t>
      </list></t>

      <t>The indent="0" pn="section-5.7-6">The Map-Notify message has the same contents as a
      Map-Register message. See the Map-Register section "<xref target="MAPREG" format="title" sectionFormat="of" derivedContent="Map-Register Message Format"/>" (<xref target="MAPREG" format="default" sectionFormat="of" derivedContent="Section 5.6"/>) for field descriptions and the Map-Reply section
"<xref target="MR-FORMAT" format="title" sectionFormat="of" derivedContent="Map-Reply Message Format"/>" (<xref target="MR-FORMAT" format="default" sectionFormat="of" derivedContent="Section 5.4"/>) for EID-record EID-Record and
      RLOC-record RLOC-Record descriptions.</t>

      <t>The
        <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
      processing. In the Map-Notfiy, Map-Notify, the 'Authentication Data'
      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 scope of this
specification, be used in an unsolicited manner, such as manner.  This topic is specified in out of scope for this document. See <xref target="I-D.ietf-lisp-pubsub"/>.</t>

	  <t>After target="I-D.ietf-lisp-pubsub" format="default" sectionFormat="of" derivedContent="LISP-PUBSUB"/> for details.</t>
        <t indent="0" pn="section-5.7-8">After sending a Map-Register, if a Map-Notify is not
	  received after 1 second second, the transmitter MUST re-transmit <bcp14>MUST</bcp14> retransmit
	  the original Map-Register with an exponential backoff (base of 2, that is, the next backoff timeout interval is doubled), doubled);
	  the maximum backoff is 1 minute. Map-Notify messages are only transmitted upon the reception of a Map-Register with the M-bit set, set; Map-Notify messages are not retransmitted. The only exeption exception to this is for unsolicited Map-Notify messages, messages; see below.</t>

      <t>A
        <t indent="0" pn="section-5.7-9">A Map-Server sends an unsolicited Map-Notify message (one
      that is not used as an acknowledgment to a Map-Register message)
      only in conformance with the Congestion Section <xref target="RFC8085" section="3.1" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8085#section-3.1" derivedContent="RFC8085">"Congestion Control And Relability Guideline
      sections Guidelines"</xref> of <xref target="RFC8085"/>. target="RFC8085" format="default" sectionFormat="of" derivedContent="RFC8085"/> and Section <xref target="RFC8085" section="3.3" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8085#section-3.3" derivedContent="RFC8085">"Reliability Guidelines"</xref> of <xref target="RFC8085" format="default" sectionFormat="of" derivedContent="RFC8085"/>. A Map-Notify is
      retransmitted until a Map-Notify-Ack is received by the
      Map-Server with the same nonce used in the Map-Notify message.
      An implementation SHOULD <bcp14>SHOULD</bcp14> retransmit up to
      3 times at 3 second 3-second retransmission intervals, after which time
      the retransmission interval is exponentially backed-off backed off (base of 2, that is, the next backoff timeout interval is doubled) for
      another 3 retransmission attempts. Map-Notify-Ack messages are only transmitted upon the reception of an unsolicited Map-Notify, Map-Notify; Map-Notify-Ack messages are not retransmitted.</t>

      <t>The
        <t indent="0" pn="section-5.7-10">The Map-Notify-Ack message has the same contents as a
      Map-Notify message.  It is used to acknowledge the receipt of an unsolicited
 Map-Notify and, once the the authentication data Authentication Data is validated, allows for
 the sender to stop retransmitting a Map-Notify with the same nonce
 and the authentication data validates. (validated) Authentication Data. The fields of
      the Map-Notify-Ack are copied from the corresponding Map-Notify
      message to acknowledge its correct processing. The 'Authentication Data'
      field is recomputed using the corresponding per-message key and according to the procedure defined
      in the previous section.</t>

      <t>Upon
        <t indent="0" pn="section-5.7-11">Upon reception of a Map-Register, Map-Notify Map-Notify, or Map-Notifiy-Ack, Map-Notify-Ack, the receiver verifies
        the authentication data. Authentication Data. If the authentication data Authentication Data fails to validate, the
message is dropped without further processing.</t>

      <t><vspace blankLines='50' /></t>
      </section>
      <section title="Encapsulated anchor="encap-mr" numbered="true" toc="include" removeInRFC="false" pn="section-5.8">
        <name slugifiedName="name-encapsulated-control-messag">Encapsulated Control Message Format" anchor="encap-mr">
      <t>An Format</name>
        <t indent="0" pn="section-5.8-1">An Encapsulated Control Message (ECM) is used to encapsulate
      control packets sent between xTRs and the mapping database system or internal to the mapping
      database system.</t>

      <figure> <artwork><![CDATA[
        <artwork name="" type="" align="left" alt="" pn="section-5.8-2">
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   / |                       IPv4 or IPv6 Header                     |
 OH  |                      (uses RLOC addresses)                    |
   \ |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   / |       Source Port = xxxx      |       Dest Port = 4342        |
 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \ |           UDP Length          |        UDP Checksum           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LISP |Type=8 |S|D|R|R|            Reserved                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   / |                       IPv4 or IPv6 Header                     |
 IH  |                  (uses RLOC or EID addresses)                 |
   \ |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   / |       Source Port = xxxx      |       Dest Port = yyyy        |
 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \ |           UDP Length          |        UDP Checksum           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 LCM |                      LISP Control Message                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          ]]></artwork> </figure>

      <t>Packet
</artwork>
        <t indent="0" pn="section-5.8-3">Packet header descriptions:</t>

      <t><list style="hanging" hangIndent="6">
        <t hangText="OH:">The
        <dl newline="false" spacing="normal" indent="6" pn="section-5.8-4">
          <dt pn="section-5.8-4.1">OH:</dt>
          <dd pn="section-5.8-4.2">This is the outer IPv4 or IPv6 header, which uses
        RLOC addresses in the source and destination header address
        fields.</t>

        <t hangText="UDP:">The
        fields.</dd>
          <dt pn="section-5.8-4.3">UDP:</dt>
          <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
        field MUST <bcp14>MUST</bcp14> be non-zero.</t>

        <t hangText="LISP:">Type non-zero.</dd>
          <dt pn="section-5.8-4.5">LISP:</dt>
          <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
        header
        header, as encoded by the first 4 bits after the 'Reserved'
        field, or the Authentication Data 'Authentication Data' field <xref
        target="I-D.ietf-lisp-sec"/> target="RFC9303" format="default" sectionFormat="of" derivedContent="RFC9303"/> if the S-bit (see below) is set.</t>

        <t hangText="Type: ">8 set.</dd>
          <dt pn="section-5.8-4.7">Type: </dt>
          <dd pn="section-5.8-4.8">8 (Encapsulated Control Message (ECM))</t>

        <t hangText="S:">This (ECM))</dd>
          <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, the
        field following the 'Reserved' field will have the following
        Authentication Data format and follow the procedures from <xref
        target="I-D.ietf-lisp-sec"/>.</t>
      </list></t>

      <figure> <artwork><![CDATA[ target="RFC9303" format="default" sectionFormat="of" derivedContent="RFC9303"/>.</dd>
        </dl>
        <artwork name="" type="" align="left" alt="" pn="section-5.8-5">
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    AD Type    |       Authentication Data Content . . .       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ]]></artwork> </figure>

      <t><list style="hanging" hangIndent="6">
        <t hangText="D:">This
</artwork>
        <dl newline="false" spacing="normal" indent="6" pn="section-5.8-6">
          <dt pn="section-5.8-6.1">D:</dt>
          <dd pn="section-5.8-6.2">This is the DDT-bit. When set to 1, the
        sender is requesting a Map-Referral message to be
        returned. The details of Details regarding this procedure are described in <xref
        target="RFC8111"/>.</t>
        <t hangText="R:">This target="RFC8111" format="default" sectionFormat="of" derivedContent="RFC8111"/>.</dd>
          <dt pn="section-5.8-6.3">R:</dt>
          <dd pn="section-5.8-6.4">This reserved and unassigned bit MUST <bcp14>MUST</bcp14> be set to 0 on
        transmit and MUST <bcp14>MUST</bcp14> be ignored on receipt.</t>
      </list></t>

      <t><list style="hanging" hangIndent="6">
        <t hangText="IH:">The receipt.</dd>
        </dl>
        <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
        fields. When a Map-Request is encapsulated in this packet
        format, the destination address in this header is an EID.</t>

        <t hangText="UDP:">The EID.</dd>
          <dt pn="section-5.8-7.3">UDP:</dt>
          <dd pn="section-5.8-7.4">This is the inner UDP header, where the port
        assignments depend on the control packet being
        encapsulated. When the control packet is a Map-Request or
        Map-Register, the source port is selected by the ITR/PITR and
        the destination port is 4342.  When the control packet is a
        Map-Reply, the source port is 4342 and the destination port is
        assigned from the source port of the invoking
        Map-Request. Port number 4341 MUST NOT <bcp14>MUST NOT</bcp14> be assigned to either
        port. The checksum field MUST <bcp14>MUST</bcp14> be non-zero.</t>

        <t hangText="LCM:">The non-zero.</dd>
          <dt pn="section-5.8-7.5">LCM:</dt>
          <dd pn="section-5.8-7.6">The format is one of the control message
        formats described in <xref target="lispcp"/>. target="lispcp" format="default" sectionFormat="of" derivedContent="Section 5"/>. Map-Request messages are
        allowed to be Control-Plane control plane (ECM) encapsulated. When
        Map-Requests are sent for RLOC-Probing purposes (i.e. (i.e., the
        probe-bit is set), they MUST NOT <bcp14>MUST NOT</bcp14> be sent inside Encapsulated
        Control Messages. PIM Join/Prune messages <xref target="RFC6831" /> format="default" sectionFormat="of" derivedContent="RFC6831"/> are also allowed to be Control-Plane control plane (ECM)
        encapsulated.</t>
      </list></t>

      <t><vspace blankLines='50' /></t>
        encapsulated.</dd>
        </dl>
      </section>
    </section>
    <section title="Changing numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-changing-the-contents-of-ei">Changing the Contents of EID-to-RLOC Mappings">
    <t>In Mappings</name>
      <t indent="0" pn="section-6-1">In the LISP architecture architecture, ITRs/PITRs use a local Map-Cache to
    store EID-to-RLOC mappings for forwarding. When an ETR updates a
    mapping
    mapping, a mechanism is required to inform ITRs/PITRs that are
    using such mappings.</t>

    <t>The
      <t indent="0" pn="section-6-2">The LISP Data-Plane data plane defines several mechanism mechanisms to update
    mappings <xref target="I-D.ietf-lisp-rfc6830bis" />. target="RFC9300" format="default" sectionFormat="of" derivedContent="RFC9300"/>. This document
    specifies the Solicit-Map Request Solicit-Map-Request (SMR), a Control-Plane control plane
    push-based mechanism.  An additional Control-Plane control plane mechanism based
    on the Publish/subscribe Publish/Subscribe paradigm is specified in
    <xref target="I-D.ietf-lisp-pubsub"/>.</t> target="I-D.ietf-lisp-pubsub" format="default" sectionFormat="of" derivedContent="LISP-PUBSUB"/>.</t>
      <section title="Solicit-Map-Request (SMR)" anchor="SMR">
          <t>Soliciting 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
          receive requests for Map-Reply messages. SMRs are also used
          to tell remote ITRs to update the mappings they have cached.</t>

          <t>Since
        <t indent="0" pn="section-6.1-2">Since ETRs are not required to keep track of remote ITRs
          that have cached their mappings, they do not know which ITRs
          need to have their mappings updated. As a result, an ETR will solicit
	  Map-Requests to
	  those sites to which it has been sending LISP encapsulated data
	  packets for the last minute. As a result, minute, and when an ETR is also acting as an
	  ITR, it will send an SMR to an ITR to which it has recently sent
	encapsulated data.</t>

          <t>An
        <t indent="0" pn="section-6.1-3">An SMR message is simply a bit set in a Map-Request message.
          An ITR or PITR will send a Map-Request (SMR-invoked Map-Request) when they receive it receives an SMR
          message. While the SMR message is sent through the data-plane, data plane, the SMR-invoked Map-Request
          MUST
          <bcp14>MUST</bcp14> be sent through the Mapping System (not directly).</t>

          <t>Both
        <t indent="0" pn="section-6.1-4">Both the SMR sender and the SMR responder
           MUST rate-limit
           <bcp14>MUST</bcp14> rate limit these messages. It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that
		  the SMR sender rate-limits rate limit a Map-Request for the same destination RLOC to
		  no more than one packet per every 3 seconds. It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the
      SMR responder rate-limits rate limit a Map-Request for the same EID-Prefix to no more than once
      per
      every 3 seconds.</t>

         <t>When
        <t indent="0" pn="section-6.1-5">When an ITR receives an SMR message for
         which it does not have a cached mapping for the EID in
         the SMR message, it SHOULD NOT <bcp14>SHOULD NOT</bcp14> send an SMR-invoked
         Map-Request. This scenario can occur when an ETR sends
         SMR messages to all Locators in the Locator-Set it has
         stored in its Map-Cache but the remote ITRs that receive the
         SMR may not be sending packets to the site. There is no
         point in updating the ITRs until they need to send, in
         which case they will send Map-Requests to obtain a
         Map-Cache entry.</t>
      </section>
    </section>
    <section title="Routing numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-routing-locator-reachabilit">Routing Locator Reachability">

   <t>This Reachability</name>
      <t indent="0" pn="section-7-1">This document defines several Control-Plane control plane mechanisms
   for determining RLOC reachability. Please note that additional Data-Plane data plane
   reachability mechanisms are defined in <xref target="I-D.ietf-lisp-rfc6830bis" />.</t>

   <t><list style="numbers">
            <t>An target="RFC9300" format="default" sectionFormat="of" derivedContent="RFC9300"/>.</t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-7-2">
	<li pn="section-7-2.1" derivedCounter="1.">An ITR may receive an ICMP Network Unreachable or Host
            Unreachable message for an RLOC it is using. This
            indicates that the RLOC is likely down. Note that trusting
            ICMP messages may not be desirable, but neither is ignoring
            them completely. Implementations are encouraged to follow
            current best practices in treating these conditions
            <xref target="I-D.ietf-opsec-icmp-filtering"/>.</t>

			<t>When target="I-D.ietf-opsec-icmp-filtering" format="default" sectionFormat="of" derivedContent="OPSEC-ICMP-FILTER"/>.</li>
        <li pn="section-7-2.2" derivedCounter="2.">When an ITR participates in the routing protocol that
            operates in the underlay routing system, it can determine that
            an RLOC is down when no Routing Information Base (RIB)
            entry exists that matches the RLOC IP address.</t>

			<t>An address.</li>
        <li pn="section-7-2.3" derivedCounter="3.">An ITR may receive an ICMP Port Unreachable message
            from a destination host. This occurs if an ITR
            attempts to use interworking <xref target="RFC6832" /> format="default" sectionFormat="of" derivedContent="RFC6832"/> and
            LISP-encapsulated data is sent to a non-LISP-capable site.</t>

			<t>An site.</li>
        <li pn="section-7-2.4" derivedCounter="4.">An ITR may receive a Map-Reply from an ETR in
            response to a previously sent Map-Request. The RLOC
            source of the Map-Reply is likely up, since the
            ETR was able to send the Map-Reply to the ITR.
            Please note that in some scenarios the RLOC -from -- from the
            outer header- header -- can be an a spoofable field.</t>

			<t>An field.</li>
        <li pn="section-7-2.5" derivedCounter="5.">An ITR/ETR pair can use the 'RLOC-Probing' mechanism
            described below.</t>
   </list></t>

           <t>When below.</li>
      </ol>
      <t indent="0" pn="section-7-3">When ITRs receive ICMP Network Unreachable or Host Unreachable
        messages as a method to determine unreachability,
        they will refrain from
        using Locators that are described in Locator lists of Map-Replies.
        However, using this approach is unreliable because many network
        operators turn off generation of ICMP Destination Unreachable
        messages.</t>

        <t>If
      <t indent="0" pn="section-7-4">If an ITR does receive an ICMP Network Unreachable or Host
        Unreachable message, it MAY <bcp14>MAY</bcp14> originate its own ICMP Destination
        Unreachable message destined for the host that originated
        the data packet the ITR encapsulated.</t>

        <t>This
      <t indent="0" pn="section-7-5">This assumption does create a dependency: Locator
        unreachability is detected by the receipt of ICMP Host
        Unreachable messages.  When a Locator has been determined
        to be unreachable, it is not used for active traffic; this
        is the same as if it were listed in a Map-Reply with
        Priority 255.</t>

        <t>The
      <t indent="0" pn="section-7-6">The ITR can test the reachability of the unreachable
        Locator by sending periodic Map-Requests. Both Map-Requests and
        Map-Replies MUST <bcp14>MUST</bcp14> be rate-limited, rate limited; see <xref target="MAPREQ"/> Sections <xref target="MAPREQ" format="counter" sectionFormat="of" derivedContent="5.3"/> and <xref target="MR-FORMAT"/> target="MR-FORMAT" format="counter" sectionFormat="of" derivedContent="5.4"/> for information about rate-limiting. rate limiting. Locator reachability testing
        is never done with data packets, since that increases the
        risk of packet loss for end-to-end sessions.</t>
      <section anchor="rloc-probe" title="RLOC-Probing Algorithm">

        <t>RLOC-Probing numbered="true" toc="include" removeInRFC="false" pn="section-7.1">
        <name slugifiedName="name-rloc-probing-algorithm">RLOC-Probing Algorithm</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
        Locators that it has cached in a Map-Cache entry. The
        probe-bit of the Map-Request and Map-Reply messages is
        used for RLOC-Probing.</t>

        <t>RLOC-Probing
        <t indent="0" pn="section-7.1-2">RLOC-Probing is done in the control plane on a
        timer basis, where an ITR or PITR will originate a Map-Request
        destined to a locator address Routing Locator Address from one of its
        own locator addresses. Routing Locator Addresses. A Map-Request used as an RLOC-probe RLOC-Probe
        is NOT encapsulated and NOT sent to a Map-Server or to the
        mapping database system as one would when requesting mapping data.
        The EID record EID-Record encoded in the Map-Request is the EID-Prefix of
        the Map-Cache entry cached by the ITR or PITR. The ITR
        MAY
        <bcp14>MAY</bcp14> include a mapping data record for its own database mapping
        information that contains the local EID-Prefixes and RLOCs for
        its site. RLOC-probes RLOC-Probes are sent periodically using a jittered
        timer interval. </t>

        <t>When
        <t indent="0" pn="section-7.1-3">When an ETR receives a Map-Request message with the
        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
        address of the outgoing interface the Map-Reply destination
        address routes to. The Map-Reply SHOULD <bcp14>SHOULD</bcp14> contain mapping data
        for the EID-Prefix contained in the Map-Request. This provides
        the opportunity for the ITR or PITR that sent the RLOC-probe RLOC-Probe
        to get mapping updates if there were changes to the ETR's
        database mapping entries.</t>

        <t>There
        <t indent="0" pn="section-7.1-4">There are advantages and disadvantages of RLOC-Probing.
        The main benefit of RLOC-Probing is that it can handle many
        failure scenarios scenarios, allowing the ITR to determine when the path
        to a specific Locator is reachable or has become unreachable,
        thus providing a robust mechanism for switching to using
        another Locator from the cached Locator.  RLOC-Probing can
        also provide rough Round-Trip Time (RTT) estimates between a
        pair of Locators, which can be useful for network management
        purposes as well as for selecting low delay low-delay paths. The major
        disadvantage of RLOC-Probing is in the number of control
        messages required and the amount of bandwidth used to obtain
        those benefits, especially if the requirement for failure
        detection times is very small.</t>
      </section>
    </section>
    <section title="Interactions numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-interactions-with-other-lis">Interactions with Other LISP Components"> Components</name>
      <section title="ITR numbered="true" toc="include" removeInRFC="false" pn="section-8.1">
        <name slugifiedName="name-itr-eid-to-rloc-mapping-res">ITR EID-to-RLOC Mapping Resolution">
      <t>An Resolution</name>
        <t indent="0" pn="section-8.1-1">An ITR is configured with one or more Map-Resolver addresses.
      These addresses are "Locators" (or RLOCs) and MUST <bcp14>MUST</bcp14> be routable
      on the underlying core network; they MUST NOT <bcp14>MUST NOT</bcp14> need to be
      resolved through LISP EID-to-RLOC mapping, as that would
      introduce a circular dependency. When using a Map-Resolver, an
      ITR does not need to connect to any other database mapping
      system.</t>

      <t> Mapping
      System.</t>
        <t indent="0" pn="section-8.1-2"> An ITR sends an Encapsulated Map-Request to a configured
      Map-Resolver when it needs an EID-to-RLOC mapping that is not
      found in its local Map-Cache. Using the Map-Resolver greatly
      reduces both the complexity of the ITR implementation and the
      costs associated with its operation.</t>

      <t>
        <t indent="0" pn="section-8.1-3"> In response to an Encapsulated Map-Request, the ITR can
      expect one of the following:</t>

      <t><list style="symbols">
        <t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-8.1-4">
          <li pn="section-8.1-4.1"> An immediate Negative Map-Reply (with action code of
        "Natively-Forward",
        "Natively-Forward" and a 15-minute Time to Live (TTL)) TTL) from the
        Map-Resolver if the Map-Resolver can determine that the
        requested EID does not exist. The ITR saves the EID-Prefix
        returned in the Map-Reply in its cache, marks it as
        non-LISP-capable, and knows not to attempt LISP encapsulation
        for destinations matching it.</t>

        <t> it.</li>
          <li pn="section-8.1-4.2"> A Negative Map-Reply, with Map-Reply (with action code of
        "Natively-Forward",
        "Natively-Forward") from a Map-Server that is authoritative (within the LISP deployment <xref (<xref target="soa" />) format="default" sectionFormat="of" derivedContent="Section 1.1"/>))
        for an EID-Prefix that matches the requested EID but that does
        not have an actively registered, more-specific EID-prefix. EID-Prefix. In
        this case, the requested EID is said to match a "hole" in the
        authoritative EID-Prefix. If the requested EID matches a
        more-specific EID-Prefix that has been delegated by the
        Map-Server but for which no ETRs are currently registered, a
        1-minute TTL is returned. If the requested EID matches a
        non-delegated part of the authoritative EID-Prefix, then it is
        not a LISP EID and a 15-minute TTL is returned.  See <xref
        target="reg"/> target="reg" format="default" sectionFormat="of" derivedContent="Section 8.2"/> for a discussion of aggregate EID-Prefixes and
        details of regarding Map-Server EID-Prefix matching.</t>

        <t> matching.</li>
          <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
        the ETR. See <xref target="mr-processing" /> format="default" sectionFormat="of" derivedContent="Section 8.4"/> for more details
        on Map-Resolver message processing.</t>
      </list></t>

      <t> processing.</li>
        </ul>
        <t indent="0" pn="section-8.1-5"> Note that an ITR may be configured to both use a
      Map-Resolver and to participate in a LISP-ALT logical
      network. In such a situation, the ITR SHOULD <bcp14>SHOULD</bcp14> send Map-Requests
      through the ALT network for any EID-Prefix learned via ALT BGP.
      Such a configuration is expected to be very rare, since there is
      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
      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
      to verify that an EID-Prefix is present before sending that
      Map-Request.</t>
      </section>
      <section title="EID-Prefix anchor="reg" numbered="true" toc="include" removeInRFC="false" pn="section-8.2">
        <name slugifiedName="name-eid-prefix-configuration-an">EID-Prefix Configuration and ETR Registration"
             anchor="reg">
      <t> 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
      authentication data,
      Authentication Data, so prior to sending a Map-Register message,
      the ETR and Map-Server MUST <bcp14>MUST</bcp14> be configured with a pre-shared secret
      used to derive Map-Register authentication keys. A Map-Server's
      configuration SHOULD <bcp14>SHOULD</bcp14> also include a list of the EID-Prefixes for
      which each ETR is authoritative.  Upon receipt of a Map-Register
      from an ETR, a Map-Server accepts only EID-Prefixes that are
      configured for that ETR.  Failure to implement such a check
      would leave the mapping system Mapping System vulnerable to trivial EID-Prefix
      hijacking attacks.</t>

      <t>
        <t indent="0" pn="section-8.2-2"> In addition to the set of EID-Prefixes defined for each ETR
      that may register, a Map-Server is typically also configured
      with one or more aggregate prefixes that define the part of the
      EID numbering space assigned to it. When LISP-ALT is the
      database in use, aggregate EID-Prefixes are implemented as
      discard routes and advertised into ALT BGP.  The existence of
      aggregate EID-Prefixes in a Map-Server's database means that it
      may receive Map Requests Map-Requests for EID-Prefixes that match an
      aggregate but do not match a registered prefix; <xref target="ms-processing" /> format="default" sectionFormat="of" derivedContent="Section 8.3"/> describes how this is handled.</t>

      <t>
        <t indent="0" pn="section-8.2-3"> Map-Register messages are sent periodically from an ETR to a
      Map-Server with a suggested interval between messages of one
      minute. A Map-Server SHOULD <bcp14>SHOULD</bcp14> time out and remove an ETR's
      registration if it has not received a valid Map-Register message
      within the past three&nbsp;minutes. three minutes. When first contacting a
      Map-Server after restart or changes to its EID-to-RLOC database
      mappings, an ETR MAY <bcp14>MAY</bcp14> initially send Map-Register messages at an
      increased frequency, up to one every 20 seconds.  This "quick
      registration" period is limited to five&nbsp;minutes five minutes in
      duration.</t>

      <t>
        <t indent="0" pn="section-8.2-4"> An ETR MAY <bcp14>MAY</bcp14> request that a Map-Server explicitly acknowledge
      receipt and processing of a Map-Register message by setting the
      "want-map-notify" (M-bit) flag. A Map-Server that receives a
      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
      for Map-Register messages sent during the initial "quick
      registration" with a Map-Server but then set it only
      occasionally during steady-state maintenance of its association
      with that Map-Server. Note that the Map-Notify message is sent
      to UDP destination port 4342, not to the source port specified
      in the original Map-Register message.</t>

      <t>
        <t indent="0" pn="section-8.2-5"> Note that a one-minute minimum registration interval during
      maintenance of an ETR-Map-Server association places a lower
      bound on how quickly and how frequently a mapping database entry
      can be updated. This may have implications for what sorts of
      mobility can be supported directly by the mapping system; Mapping System;
      shorter registration intervals or other mechanisms might be
      needed to support faster mobility in some cases. For a
      discussion on one way that faster mobility may be implemented
      for individual devices, please see <xref target="I-D.ietf-lisp-mn"/>.</t>

      <t> target="I-D.ietf-lisp-mn" format="default" sectionFormat="of" derivedContent="LISP-MN"/>.</t>
        <t indent="0" pn="section-8.2-6"> An ETR MAY <bcp14>MAY</bcp14> also request, by setting the "proxy Map-Reply"
      flag (P-bit) in the Map-Register message, that a Map-Server
      answer Map-Requests instead of forwarding them to the ETR.  See
      <xref target="rloc-probe"/> target="rloc-probe" format="default" sectionFormat="of" derivedContent="Section 7.1"/> for details on how
      the Map-Server sets certain flags (such as those indicating
      whether the message is authoritative and how returned Locators
      SHOULD
      <bcp14>SHOULD</bcp14> be treated) when sending a Map-Reply on behalf of an ETR.
      When an ETR requests proxy reply service, it SHOULD <bcp14>SHOULD</bcp14> include all
      RLOCs for all ETRs for the EID-Prefix being registered, along
      with the routable flag ("R-bit") setting for each RLOC.  The
      Map-Server includes all of this information in Map-Reply
      messages that it sends on behalf of the ETR. This differs from a
      non-proxy registration, since the latter need only provide one
      or more RLOCs for a Map-Server to use for forwarding
      Map-Requests; the registration information is not used in
      Map-Replies, so it being incomplete is not incorrect.</t>

      <t>
        <t indent="0" pn="section-8.2-7"> An ETR that uses a Map-Server to publish its EID-to-RLOC
      mappings does not need to participate further in the mapping
      database protocol(s). When using a LISP-ALT mapping database,
      for example, this means that the ETR does not need to implement
      GRE or BGP, which greatly simplifies its configuration and
      reduces its cost of operation.</t>

      <t>
        <t indent="0" pn="section-8.2-8"> Note that use of a Map-Server does not preclude an ETR from
      also connecting to the mapping database (i.e., it could also
      connect to the LISP-ALT network), but doing so doesn't seem
      particularly useful, as the whole purpose of using a Map-Server
      is to avoid the complexity of the mapping database
      protocols.</t>
      </section>
      <section title="Map-Server Processing" anchor="ms-processing">
      <t> anchor="ms-processing" numbered="true" toc="include" removeInRFC="false" pn="section-8.3">
        <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 registered by its client
      ETRs, it can accept and process Map-Requests for them.</t>

      <t>
        <t indent="0" pn="section-8.3-2"> In response to a Map-Request, the Map-Server first checks to see if the
      destination EID matches a configured EID-Prefix. If there is no
      match, the Map-Server returns a Negative Map-Reply with action
      code "Natively-Forward" and a 15-minute TTL. This can occur if a
      Map Request
      Map-Request is received for a configured aggregate EID-Prefix
      for which no more-specific EID-Prefix exists; it indicates the
      presence of a non-LISP "hole" in the aggregate EID-Prefix.</t>

      <t>Next,
        <t indent="0" pn="section-8.3-3">Next, the Map-Server checks to see if any ETRs have
      registered the matching EID-Prefix. If none are found, then the
      Map-Server returns a Negative Map-Reply with action code
      "Natively-Forward" and a 1-minute TTL.</t>

      <t>If
        <t indent="0" pn="section-8.3-4">If the EID-prefix EID-Prefix is either registered or not registered to
      the mapping system Mapping System and there is a policy in the Map-Server to
      have the requestor requester drop packets for the matching EID-prefix, EID-Prefix,
      then a Drop/Policy-Denied action is returned. If the EID-prefix EID-Prefix
      is registered or not registered and there is a an authentication
      failure, then a Drop/Authentication- failure Drop/Auth-Failure action is
      returned. If either of these actions result results as a temporary state
      in policy or authentication authentication, then a Send-Map-Request action with a
      1-minute TTL MAY <bcp14>MAY</bcp14> be returned to allow the requestor requester to retry the
      Map-Request.</t>

      <t>
        <t indent="0" pn="section-8.3-5"> If any of the registered ETRs for the EID-Prefix have
      requested proxy reply service, then the Map-Server answers the
      request instead of forwarding it. It returns a Map-Reply with
      the EID-Prefix, RLOCs, and other information learned through the
      registration process.</t>

      <t>
        <t indent="0" pn="section-8.3-6"> If none of the ETRs have requested proxy reply service, then
      the Map-Server re-encapsulates and forwards the resulting
      Encapsulated Map-Request to one of the registered ETRs. It does
      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
      Map-Server. Unless also acting as a Map-Resolver, a Map-Server
      should never receive Map-Replies; any such messages SHOULD <bcp14>SHOULD</bcp14> be
      discarded without response, perhaps accompanied by the logging
      of a diagnostic message if the rate of Map-Replies is suggestive
      of malicious traffic.</t>
      </section>
      <section title="Map-Resolver Processing" anchor="mr-processing">
      <t> anchor="mr-processing" numbered="true" toc="include" removeInRFC="false" pn="section-8.4">
        <name slugifiedName="name-map-resolver-processing">Map-Resolver Processing</name>
        <t indent="0" pn="section-8.4-1"> Upon receipt of an Encapsulated Map-Request, a Map-Resolver
      decapsulates the enclosed message and then searches for the
      requested EID in its local database of mapping entries
      (statically configured or learned from associated ETRs if the
      Map-Resolver is also a Map-Server offering proxy reply
      service). If it finds a matching entry, it returns a LISP
      Map-Reply with the known mapping.</t>

      <t>
        <t indent="0" pn="section-8.4-2"> If the Map-Resolver does not have the mapping entry and if
      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
      ALT forwarding table that covers the full EID space), it
      immediately returns a negative LISP Map-Reply, Negative Map-Reply with action code
      "Natively-Forward" and a 15&nbhy;minute 15‑minute TTL.  To minimize the
      number of negative cache entries needed by an ITR, the
      Map-Resolver SHOULD <bcp14>SHOULD</bcp14> return the least-specific prefix that both
      matches the original query and does not match any EID-Prefix
      known to exist in the LISP-capable infrastructure.</t>

      <t>
        <t indent="0" pn="section-8.4-3"> If the Map-Resolver does not have sufficient information to
      know whether the EID exists, it needs to forward the Map-Request
      to another device that has more information about the EID being
      requested. To do this, it forwards the unencapsulated
      Map-Request, with the original ITR RLOC as the source, to the
      mapping database system.  Using LISP-ALT, the Map-Resolver is
      connected to the ALT network and sends the Map-Request to the
      next ALT hop learned from its ALT BGP neighbors. 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
      receives the Map-Request over the ALT and responds will do so
      directly to the ITR.</t>
        <section title="Anycast Operation">
        <t> numbered="true" toc="include" removeInRFC="false" pn="section-8.4.1">
          <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 use "anycast", where the
        same address is assigned to multiple Map-Resolvers and is
        propagated through IGP routing, to facilitate the use of a
        topologically close Map-Resolver by each ITR.</t>

        <t>
          <t indent="0" pn="section-8.4.1-2"> ETRs MAY <bcp14>MAY</bcp14> have anycast RLOC addresses which that are registered
        as part of their RLOC-set RLOC-Set to the mapping system. Mapping System.  However,
        registrations MUST <bcp14>MUST</bcp14> use their unique RLOC addresses, distinct
        authentication keys keys, or different XTR-IDs xTR-IDs to identify security associations with the
        Map-Servers.</t>
        </section>
      </section>
    </section>
    <section title="Security Considerations">
    <t>A numbered="true" toc="include" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-9-1">A LISP threat analysis can be found in <xref
    target="RFC7835"/>. In what follows target="RFC7835" format="default" sectionFormat="of" derivedContent="RFC7835"/>. Here, we highlight security
    considerations that apply when LISP is deployed in environments
    such as those specified in <xref target="soa"/>, target="soa" format="default" sectionFormat="of" derivedContent="Section 1.1"/>, where the
    following assumptions hold:</t>

    <t><list style="numbers">
      <t>The
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-9-2">
	<li pn="section-9-2.1" derivedCounter="1.">The Mapping System is secure and trusted, and for the purpose
      of this these security considerations considerations, the Mapping System is considered
      as one trusted element.</t>

      <t>The element.</li>
        <li pn="section-9-2.2" derivedCounter="2.">The ETRs have a pre-configured preconfigured trust relationship with the Mapping
     System, which includes including some form of shared secret, and the secret.  The Mapping
     System is aware of which EIDs an ETR can advertise. How
      those keys and mappings gets are established is out of the scope of for
      this document.</t>

      <t>LISP-SEC <xref target="I-D.ietf-lisp-sec"/> MUST document.</li>
        <li pn="section-9-2.3" derivedCounter="3.">LISP-SEC <xref target="RFC9303" format="default" sectionFormat="of" derivedContent="RFC9303"/> <bcp14>MUST</bcp14> be
      implemented. Network operators should carefully weight weigh how the
      LISP-SEC threat model applies to their particular use case or
      deployment.  If they decide to ignore a particular
      recommendation, they should make sure the risk associated with
      the corresponding threats is well understood.</t>
    </list></t>

    <t>The understood.</li>
      </ol>
      <t indent="0" pn="section-9-3">The Map-Request/Map-Reply message exchange can be exploited by
    an attacker to mount DoS and/or amplification attacks. Attackers
    can send Map-Requests at high rates to overload LISP nodes and
    increase the state maintained by such nodes or consume CPU
    cycles. Such threats can be mitigated by systematically applying
    filters and rate limiters.</t>

    <t>The
      <t indent="0" pn="section-9-4">The Map-Request/Map-Reply message exchange can also be exploited to inject
    forged mappings directly in into the ITR EID-to-RLOC map-cache. Map-Cache. This
    can lead to traffic being redirected to the attacker, attacker; see further
    details in <xref target="RFC7835"/>. target="RFC7835" format="default" sectionFormat="of" derivedContent="RFC7835"/>. In addition, valid ETRs in
    the system can perform overclaiming attacks. In this case,
    attackers can claim to own an EID-prefix EID-Prefix that is larger than the
    prefix owned by the ETR. Such attacks can be addressed by using
    LISP-SEC <xref target="I-D.ietf-lisp-sec"/>. target="RFC9303" format="default" sectionFormat="of" derivedContent="RFC9303"/>. The LISP-SEC protocol
    defines a mechanism for providing origin authentication,
    integrity protection, and prevention of
    &apos;man-in-the-middle&apos;
    'man-in-the-middle' and &apos;prefix overclaiming&apos; 'prefix overclaiming'
    attacks on the Map-Request/Map-Reply exchange. In addition addition, and
    while beyond the scope of securing an individual Map-Server or
    Map-Resolver, it should be noted that LISP-SEC can be complemented
    by additional security mechanisms defined by the Mapping System
    Infrastructure.
    infrastructure. For instance, BGP-based LISP-ALT <xref
    target="RFC6836"/> target="RFC6836" format="default" sectionFormat="of" derivedContent="RFC6836"/> can take advantage of standards work on adding
    security to BGP BGP, while LISP-DDT <xref target="RFC8111"/> target="RFC8111" format="default" sectionFormat="of" derivedContent="RFC8111"/> defines
    its own additional security mechanisms.</t>

    <t>To
      <t indent="0" pn="section-9-5">To publish an authoritative EID-to-RLOC mapping with a
    Map-Server using the Map-Register message, an ETR includes
    authentication data
    Authentication Data that is a MAC of the entire message using a
    key derived from the pre-shared secret. An implementation SHOULD <bcp14>SHOULD</bcp14> support
	HMAC-SHA256-128+HKDF-SHA256 <xref target="RFC5869"/>. target="RFC5869" format="default" sectionFormat="of" derivedContent="RFC5869"/>. The Map-Register
	message includes protection for against replay
    attacks by a man-in-the-middle. 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
    corresponding Map-Server. To mitigate this and this, as noted in <xref
    target="reg"/>, target="reg" format="default" sectionFormat="of" derivedContent="Section 8.2"/>, a Map-Server MUST <bcp14>MUST</bcp14> verify that all EID-Prefixes
    registered by an ETR match the configuration stored on the
    Map-Server.</t>

    <t>Deployments
      <t indent="0" pn="section-9-6">Deployments concerned about manipulations of Map-Request and
    Map-Reply messages, messages and malicious ETR EID prefix EID-Prefix overclaiming MUST <bcp14>MUST</bcp14>
    drop LISP Control Plane control plane messages that do not contain LISP-SEC
    material (S-bit, EID-AD, OTK-AD, PKT-AD).</t>

    <t>Mechanisms PKT-AD). See <xref target="RFC9303" sectionFormat="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
      exchanged between xTRs, between xTRs and the mapping system, Mapping System, and between nodes that
      make up the mapping system, SHOULD Mapping System <bcp14>SHOULD</bcp14> be deployed. Examples of this are DTLS <xref target="RFC6347"/> or
    LISP-crypto <xref target="RFC8061"/>.</t> target="RFC9147" format="default" sectionFormat="of" derivedContent="RFC9147"/> or
    "lisp-crypto" <xref target="RFC8061" format="default" sectionFormat="of" derivedContent="RFC8061"/>.</t>
    </section>
    <section title="Privacy Considerations">
    <t>As numbered="true" toc="include" removeInRFC="false" pn="section-10">
      <name slugifiedName="name-privacy-considerations">Privacy Considerations</name>
      <t indent="0" pn="section-10-1">As noted by <xref target="RFC6973"/> target="RFC6973" format="default" sectionFormat="of" derivedContent="RFC6973"/>, privacy is a complex issue
    that greatly depends on the specific protocol use-case use case and
    deployment. As noted in section 1.1 of <xref
    target="I-D.ietf-lisp-rfc6830bis"/> 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 use cases
    where entities communicate over the public Internet while keeping
    separate addressing and topology. In what follows Here, we detail the
    privacy threats introduced by the LISP Control Plane, control plane; the analysis
    is based on the guidelines detailed in <xref
    target="RFC6973"/>.</t>

    <t>LISP target="RFC6973" format="default" sectionFormat="of" derivedContent="RFC6973"/>.</t>
      <t indent="0" pn="section-10-2">LISP can use long-lived identifiers (EIDs) that survive
    mobility events. Such identifiers bind to the RLOCs of the nodes,
    which represents nodes.
    The RLOCs represent the topological location with respect to the
    specific LISP deployments. In addition, EID-to-RLOC mappings are
    typically considered public information within the LISP
    deployment when control-plane control plane messages are not encrypted, encrypted and can
    be eavesdropped while Map-Request messages are sent to the
    corresponding Map-Resolvers or Map-Register messages to
    Map-Servers.</t>

    <t>In
      <t indent="0" pn="section-10-3">In this context, attackers can correlate the EID with the RLOC
    and track the corresponding user topological location and/or
    mobility. This can be achieved by off-path attackers, if they are
    authenticated, by querying the mapping system. Mapping System. Deployments
    concerned about this threat can use access control-lists control lists or stronger
    authentication mechanisms <xref target="I-D.ietf-lisp-ecdsa-auth"/> target="I-D.ietf-lisp-ecdsa-auth" format="default" sectionFormat="of" derivedContent="ECDSA-AUTH"/> in
    the mapping system Mapping System to make sure that only authorized users can
    access this information (data minimization). Use of ephemeral EIDs
    <xref target="I-D.ietf-lisp-eid-anonymity"/> target="I-D.ietf-lisp-eid-anonymity" format="default" sectionFormat="of" derivedContent="EID-ANONYMITY"/> to achieve anonymity is
    another mechanism to lessen persistency and identity tracking.</t>
    </section>
    <section title="Changes since RFC 6833">
    <t>For numbered="true" toc="include" removeInRFC="false" pn="section-11">
      <name slugifiedName="name-changes-related-to-rfcs-683">Changes Related to RFCs 6830 and 6833</name>
      <t indent="0" pn="section-11-1">For implementation considerations, the following major changes have
    been made to this document since RFC 6833 was <xref target="RFC6830" format="default" sectionFormat="of" derivedContent="RFC6830"/> and <xref target="RFC6833" format="default" sectionFormat="of" derivedContent="RFC6833"/> were published:</t>

    <t><list style="symbols">
      <t>A
      <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 and Map-Notify messages as defined in <xref target="RFC6830" format="default" sectionFormat="of" derivedContent="RFC6830"/> has been
      split into an 8-bit 'Key ID' field and an 8-bit 'Algorithm ID' field.  Note that this change also applies to the Map-Notify-Ack message is added in defined by this document. See Sections <xref target="MAPREG" format="counter" sectionFormat="of" derivedContent="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 to provide
      reliability for Map-Notify messages.  Any receiver of a
      Map-Notify message must respond with a Map-Notify-Ack
      message. Map-Servers who are senders of Map-Notify messages, messages
      must queue the Map-Notify contents until they receive a
      Map-Notify-Ack with the nonce used in the Map-Notify
      message. Note that implementations for Map-Notify-Ack support
      already exist and predate this document.</t>

      <t>This document.</li>
        <li pn="section-11-2.3">This document is incorporating has incorporated the codepoint for the
      Map-Referral message from the LISP-DDT specification <xref
      target="RFC8111"/> target="RFC8111" format="default" sectionFormat="of" derivedContent="RFC8111"/> to indicate that a Map-Server must send the
      final Map-Referral message when it participates in the LISP-DDT
      mapping system procedures.</t>

      <t>The L"
      Mapping System procedures.</li>
        <li pn="section-11-2.4">Bits L and "D" bits are D have been added to the
      Map-Request message. See <xref target="MAPREQ"/> for details.</t>

      <t>The "S", "I", "E", "T", "a", "R", target="MAPREQ" format="default" sectionFormat="of" derivedContent="Section 5.3"/> for details.</li>
        <li pn="section-11-2.5">Bits S, I, E, T, a, R, and "M" bits are M have been added to the
      Map-Register message. See <xref target="MAPREG"/> for details.</t>

      <t>The 16-bit Key-ID field of the Map-Register message has been
      split into a 8-bit Key-ID field and a 8-bit Algorithm-ID field.</t>

      <t>The target="MAPREG" format="default" sectionFormat="of" derivedContent="Section 5.6"/> for details.</li>
        <li pn="section-11-2.6">The nonce and the authentication data Authentication Data in the Map-Register message
        have a different behaviour,
    each behave differently; see  <xref target="MAPREG"/> for details.</t>

      <t>This target="MAPREG" format="default" sectionFormat="of" derivedContent="Section 5.6"/> for details.</li>
        <li pn="section-11-2.7">This document adds two new Action action values that are in an
      EID-record
      EID-Record that appear appears in Map-Reply, Map-Register, Map-Notify,
      and Map-Notify-Ack messages. The Drop/Policy-Denied and
      Drop/Auth-Failure are the descriptions for the two These new action
      values. values are Drop/Policy-Denied and
      Drop/Auth-Failure. See <xref target="MR-FORMAT"/> target="MR-FORMAT" format="default" sectionFormat="of" derivedContent="Section 5.4"/> for details.</t>
    </list></t> details.</li>
      </ul>
    </section>
    <section title="IANA Considerations">
    <t>This numbered="true" toc="include" removeInRFC="false" pn="section-12">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-12-1">This section provides guidance to the Internet Assigned Numbers
    Authority (IANA) IANA regarding registration of values related to this
    LISP Control-Plane 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 format="default" sectionFormat="of" derivedContent="RFC8126">BCP 26</xref>.</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-12-2">
        <li pn="section-12-2.1">LISP IANA registry allocations should not be made for
      purposes unrelated to LISP routing or transport protocols.</t>

      <t>The protocols.</li>
        <li pn="section-12-2.2">The following policies are used here with the meanings
      defined in BCP 26: <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126">BCP 26</xref>: "Specification Required", "IETF Review",
      "Experimental Use", and "First Come First Served".</t>
    </list></t> Served".</li>
      </ul>
      <t indent="0" pn="section-12-3">There are three namespaces (listed in the sub-sections below) in
    LISP that have been registered (see <xref target="RFC9299" format="default" sectionFormat="of" derivedContent="RFC9299"/>.</t>
      <section title="LISP numbered="true" toc="include" removeInRFC="false" pn="section-12.1">
        <name slugifiedName="name-lisp-udp-port-numbers">LISP UDP Port Numbers">
	  <t>The IANA registry has Numbers</name>
        <t indent="0" pn="section-12.1-1">IANA allocated UDP port number 4342 for the
	  LISP Control-Plane. 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 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
		]]></artwork> </figure> Packets</td>
              <td align="left" colspan="1" rowspan="1">RFC 9301</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section title="LISP numbered="true" toc="include" removeInRFC="false" pn="section-12.2">
        <name slugifiedName="name-lisp-packet-type-codes">LISP Packet Type Codes">
      <t>It Codes</name>
        <t indent="0" pn="section-12.2-1">IANA is being requested that the IANA be now authoritative for LISP
      Packet Type definitions and it is requested to replace definitions, so they have replaced the <xref
      target="RFC6830"/> registry message
      references to <xref target="RFC6830" format="default" sectionFormat="of" derivedContent="RFC6830"/> with the RFC
      number assigned references to this document.</t>

      <t>Based
        <t indent="0" pn="section-12.2-2">Based on deployment experience of related to <xref target="RFC6830"/>, target="RFC6830" format="default" sectionFormat="of" derivedContent="RFC6830"/>,
      the Map-Notify-Ack message, message (message type 5, was added by 5) is defined in this
      document. This document requests IANA to add has registered it to in the LISP "LISP
      Packet Type Registry.</t>

      <figure> <artwork><![CDATA[
      Name                 Number          Defined in
      ----                 ------          -----------
      LISP Map-Notify-Ack  5               RFC6833bis
      ]]></artwork> </figure> 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 title="LISP anchor="act-iana" numbered="true" toc="include" removeInRFC="false" pn="section-12.3">
        <name slugifiedName="name-lisp-map-reply-eid-record-a">LISP Map-Reply EID-Record Action Codes" anchor="act-iana">

      <t>New Codes</name>
        <t indent="0" pn="section-12.3-1">New ACT values can be allocated through IETF review Review or IESG
      approval.
      Approval. Four values have already been allocated by <xref
      target="RFC6830"/>. target="RFC6830" format="default" sectionFormat="of" derivedContent="RFC6830"/>. IANA is requested to replace has replaced the <xref
      target="RFC6830"/> reference for this registry with the RFC
      number assigned pointing to this document and <xref
      target="RFC6830"/>. target="RFC6830" format="default" sectionFormat="of" derivedContent="RFC6830"/> to point to this document.  This specification changes the Action name
      of ACT type 3 value 3 from "Drop" to "Drop/No-Reason" as well as
      adding two "Drop/No-Reason".  It also adds the following
      new ACT values, the "Drop/Policy-Denied" (type 4) and
      "Drop/Authentication-Failure" (type 5).</t>

      <texttable title="LISP values.</t>
        <table align="center" pn="table-4">
          <name slugifiedName="name-lisp-map-reply-action-value">LISP Map-Reply Action Values">
        <ttcol align='left'>Value</ttcol>
        <ttcol align='left'>Action</ttcol>
        <ttcol align='left'>Description</ttcol>
        <ttcol align='left'>Raeference</ttcol>
	    <c>4</c>
        <c>Drop/Policy-Denied</c>
        <c>A 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 Map-Cache entry is dropped because
        the target EWID EID is policy-denied by the xTR or the mapping
        system.</c>
        <c>RFC6833bis</c>
	    <c>5</c>
        <c>Drop/Auth-Failure</c>
        <c>Packet 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 the this Map-Cache entry is dropped beacuse because the
        Map-Request for the target EID fails an authentication check
        by the xTR or the mapping system.</c>
        <c>RFC6833bis</c>
      </texttable>

      <t>In Mapping System.</td>
              <td align="left" colspan="1" rowspan="1">RFC 9301</td>
            </tr>
          </tbody>
        </table>
        <t indent="0" pn="section-12.3-3">In addition, LISP has a number of flag fields and reserved
      fields, such as the flags of the LISP header flags field fields <xref
      target="I-D.ietf-lisp-rfc6830bis" />. target="RFC9300" format="default" sectionFormat="of" derivedContent="RFC9300"/>. New bits for flags in
      these fields can be implemented after IETF review Review or IESG
      approval,
      Approval, but these need not be managed by IANA.</t>
      </section>
      <section anchor="IANA" title="LISP numbered="true" toc="include" removeInRFC="false" pn="section-12.4">
        <name slugifiedName="name-lisp-address-type-codes">LISP Address Type Codes">
      <t>LISP Codes</name>
        <t indent="0" pn="section-12.4-1">LISP Canonical Address Format (LCAF) <xref target="RFC8060"/>
      is target="RFC8060" format="default" sectionFormat="of" derivedContent="RFC8060"/>
      has an 8-bit Type field that defines LISP-specific encodings for AFI
      value 16387. LCAF encodings are used for specific use-cases use cases
      where different address types for EID-records EID-Records and RLOC-records RLOC-Records
      are required.</t>

      <t>The IANA registry
        <t indent="0" pn="section-12.4-2">The "LISP Canonical Address Format (LCAF)
      Types" registry is used for LCAF types. The registry for LCAF types use uses
      the Specification Required policy <xref
      target="RFC8126"/>. target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>. Initial values for the registry as well as
      further information can be found in <xref
      target="RFC8060"/>.</t>

      <t>Therefore, target="RFC8060" format="default" sectionFormat="of" derivedContent="RFC8060"/>.</t>
        <t indent="0" pn="section-12.4-3">Therefore, there is no longer a need for the "LISP Address Type
      Codes" registry requested by <xref target="RFC6830"/>. This document
      requests to remove it.</t> target="RFC6830" format="default" sectionFormat="of" derivedContent="RFC6830"/>. Per this document,
      the registry has been closed.</t>
      </section>
      <section title="LISP anchor="KEYS" numbered="true" toc="include" removeInRFC="false" pn="section-12.5">
        <name slugifiedName="name-lisp-algorithm-id-numbers">LISP Algorithm ID Numbers" anchor="KEYS">
      <t>In Numbers</name>
        <t indent="0" pn="section-12.5-1">In <xref target="RFC6830"/>, target="RFC6830" format="default" sectionFormat="of" derivedContent="RFC6830"/>, a request for a "LISP Key ID
      Numbers" registry was submitted. This document renames Per this document, IANA has renamed the
      registry to "LISP Algorithm ID Numbers" and requests the IANA to
      make listed this document as the name change.</t>

      <t>The registry reference.</t>
        <t indent="0" pn="section-12.5-2">The following Algorithm ID values are defined by this
      specification
      specification, as used in any packet type that references a an
      'Algorithm ID' field:</t>

      <figure> <artwork><![CDATA[
      Name                        Number    MAC        KDF
      -------------------------------------------------------
      None                          0       None       None
      HMAC-SHA-1-96-None            1     [RFC2404]    None
      HMAC-SHA-256-128-None			2	  [RFC4868]    None
	  HMAC-SHA256-128+HKDF-SHA256  3     [RFC4868] [RFC4868]
      ]]></artwork> </figure>

      <t>Number
        <table align="center" pn="table-5">
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Name</th>
              <th align="left" colspan="1" rowspan="1">Number</th>
              <th align="left" colspan="1" rowspan="1">MAC</th>
              <th align="left" colspan="1" rowspan="1">KDF</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">None</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">None</td>
              <td align="left" colspan="1" rowspan="1">None</td>
            </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" derivedContent="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" derivedContent="RFC4868"/></td>
              <td align="left" colspan="1" rowspan="1">None</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">HMAC-SHA256-128+HKDF-SHA256</td>
              <td align="left" colspan="1" rowspan="1">3</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC4868" format="default" sectionFormat="of" derivedContent="RFC4868"/></td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC4868" format="default" sectionFormat="of" derivedContent="RFC4868"/></td>
            </tr>
          </tbody>
        </table>
        <t indent="0" pn="section-12.5-4">Number values are in the range of 0 to 255. The allocation of
      values is
      Values are assigned on a first come first served First Come First Served basis.</t>
      </section>
      <section title="LISP anchor="BITS" numbered="true" toc="include" removeInRFC="false" pn="section-12.6">
        <name slugifiedName="name-lisp-bit-flags">LISP Bit Flags" anchor="BITS">
      <t>This Flags</name>
        <t indent="0" pn="section-12.6-1">This document asks IANA to create a registry for allocation
      of bits in several headers of the LISP control plane, namely in
      the Map-Request, Map-Reply, Map-Register,
      Map-Request messages, Map-Reply messages, Map-Register messages, and Encapsulated Control
      Message (ECM) messages. Messages. Bit allocations are also requested for
      EID-records
      EID-Records and RLOC-records. RLOC-Records.  The registry created should
      be named "LISP Control Plane Header Bits".  A sub-registry subregistry
      needs to be created per each message and EID-record. EID-Record. The name of each
      sub-registry
      subregistry is indicated below, along with its format
      and allocation of bits defined in this document.  Any additional
      bits allocation, requires
      bit allocations require a specification, according in accordance with policies defined in <xref
      target="RFC8126"/> policies.</t>

      <t>Sub-Registry: target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>.</t>
        <t indent="0" pn="section-12.6-2">Subregistry: Map-Request Header Bits [<xref target="NONCE"/>]:</t>
      <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 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  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      </artwork></figure>

      <texttable title="LISP
</artwork>
        <table align="center" pn="table-6">
          <name slugifiedName="name-lisp-map-request-header-bit">LISP Map-Request Header Bits">
        <ttcol align='left'>Spec Name</ttcol>
        <ttcol align='left'>IANA Name</ttcol>
        <ttcol align='left'>Bit Position</ttcol>
        <ttcol align='left'>Description</ttcol>
	    <c>A</c><c>map-request-A</c><c>4</c><c>Authoritative Bit</c>
	    <c>M</c><c>map-request-M</c><c>5</c><c>Map 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">Map-Request-A</td>
              <td align="left" colspan="1" rowspan="1">4</td>
              <td align="left" colspan="1" rowspan="1">Authoritative Bit</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">M</td>
              <td align="left" colspan="1" rowspan="1">Map-Request-M</td>
              <td align="left" colspan="1" rowspan="1">5</td>
              <td align="left" colspan="1" rowspan="1">Map Data Present Bit</c>
	    <c>P</c><c>map-request-P</c><c>6</c><c>RLOC-Probe Bit</td>
            </tr>
            <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">6</td>
              <td align="left" colspan="1" rowspan="1">RLOC-Probe Request Bit</c>
	    <c>S</c><c>map-request-S</c><c>7</c><c>Solicit 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">7</td>
              <td align="left" colspan="1" rowspan="1">Solicit Map-Request (SMR)
        Bit</c>
	    <c>p</c><c>map-request-p</c><c>8</c><c>Proxy-ITR Bit</c>
	    <c>s</c><c>map-request-s</c><c>9</c><c>Solicit
        Bit</td>
            </tr>
            <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 Invoked
        Bit</c>
	    <c>L</c><c>map-request-L</c><c>17</c><c>Local
        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</c>
	    <c>D</c><c>map-request-D</c><c>18</c><c>Don't Map-Reply Bit</c>
      </texttable>

      <t>Sub-Registry: 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 [<xref target="MR-FORMAT"/>]:</t>
      <figure><artwork> (<xref target="MR-FORMAT" format="default" sectionFormat="of" derivedContent="Section 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></figure>

      <texttable title="LISP
</artwork>
        <table align="center" pn="table-7">
          <name slugifiedName="name-lisp-map-reply-header-bits">LISP Map-Reply Header Bits">
        <ttcol align='left'>Spec Name</ttcol>
        <ttcol align='left'>IANA Name</ttcol>
        <ttcol align='left'>Bit Position</ttcol>
        <ttcol align='left'>Description</ttcol>
        <c>P</c><c>map-reply-P</c><c>4</c><c>RLOC-Probe Bit</c>
	    <c>E</c><c>map-reply-E</c><c>5</c><c>Echo Nonce 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</c>
	    <c>S</c><c>map-reply-S</c><c>6</c><c>Security Bit</c>
      </texttable>

      <t>Sub-Registry: Bit</td>
            </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"/>]:</t>
      <figure><artwork> (<xref target="MAPREG" format="default" sectionFormat="of" derivedContent="Section 5.6"/>):</t>
        <artwork name="" type="" align="left" alt="" pn="section-12.6-9">
 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=3 |P|S|I|        Reserved       |E|T|a|R|M| Record Count  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      </artwork></figure>

      <texttable title="LISP
</artwork>
        <table align="center" pn="table-8">
          <name slugifiedName="name-lisp-map-register-header-bi">LISP Map-Register Header Bits">
        <ttcol align='left'>Spec Name</ttcol>
        <ttcol align='left'>IANA Name</ttcol>
        <ttcol align='left'>Bit Position</ttcol>
        <ttcol align='left'>Description</ttcol>
        <c>P</c><c>map-register-P</c><c>4</c><c>Proxy Map-Reply Bit</c>
	    <c>S</c><c>map-register-S</c><c>5</c><c>LISP-SEC 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-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</c>
	    <c>I</c><c>map-register-I</c><c>6</c><c>xTR-ID present flag</c>
      </texttable>

      <t>Sub-Registry: 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 Message (ECM) Header Bits
      [<xref target="encap-mr"/>]:</t>
      <figure><artwork>
      (<xref target="encap-mr" format="default" sectionFormat="of" derivedContent="Section 5.8"/>):</t>
        <artwork name="" type="" align="left" alt="" pn="section-12.6-12">
 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=8 |S|D|E|M|            Reserved                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      </artwork></figure>

      <texttable title="LISP
</artwork>
        <table align="center" pn="table-9">
          <name slugifiedName="name-lisp-encapsulated-control-m">LISP Encapsulated Control Message (ECM) Header Bits">
        <ttcol align='left'>Spec Name</ttcol>
        <ttcol align='left'>IANA Name</ttcol>
        <ttcol align='left'>Bit Position</ttcol>
        <ttcol align='left'>Description</ttcol>
        <c>S</c><c>ecm-S</c><c>4</c><c>Security Bit</c>
        <c>D</c><c>ecm-D</c><c>5</c><c>LISP-DDT Bit</c>
        <c>E</c><c>ecm-E</c><c>6</c><c>Forward to ETR Bit</c>
        <c>M</c><c>ecm-M</c><c>7</c><c>Destined to Map-Server Bit</c>
      </texttable>

      <t>Sub-Registry: 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">S</td>
              <td align="left" colspan="1" rowspan="1">ECM-S</td>
              <td align="left" colspan="1" rowspan="1">4</td>
              <td align="left" colspan="1" rowspan="1">Security Bit</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">D</td>
              <td align="left" colspan="1" rowspan="1">ECM-D</td>
              <td align="left" colspan="1" rowspan="1">5</td>
              <td align="left" colspan="1" rowspan="1">LISP-DDT Bit</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">E</td>
              <td align="left" colspan="1" rowspan="1">ECM-E</td>
              <td align="left" colspan="1" rowspan="1">6</td>
              <td align="left" colspan="1" rowspan="1">Forward to ETR Bit</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">M</td>
              <td align="left" colspan="1" rowspan="1">ECM-M</td>
              <td align="left" colspan="1" rowspan="1">7</td>
              <td align="left" colspan="1" rowspan="1">Destined to Map-Server Bit</td>
            </tr>
          </tbody>
        </table>
        <t indent="0" pn="section-12.6-14">Subregistry: EID-Record Header Bits [<xref target="MR-FORMAT"/>]:</t>
      <figure><artwork> (<xref target="MR-FORMAT" format="default" sectionFormat="of" derivedContent="Section 5.4"/>):</t>
        <artwork name="" type="" align="left" alt="" pn="section-12.6-15">
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Count | EID mask-len  | ACT |A|      Reserved         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      </artwork></figure>

      <texttable title="LISP
</artwork>
        <table align="center" pn="table-10">
          <name slugifiedName="name-lisp-eid-record-header-bits">LISP EID-Record Header Bits">
        <ttcol align='left'>Spec Name</ttcol>
        <ttcol align='left'>IANA Name</ttcol>
        <ttcol align='left'>Bit Position</ttcol>
        <ttcol align='left'>Description</ttcol>
        <c>A</c><c>eid-record-A</c><c>19</c><c>Authoritative Bit</c>
      </texttable>

      <t>Sub-Registry: 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"/>]:</t>
      <figure><artwork> (<xref target="MR-FORMAT" format="default" sectionFormat="of" derivedContent="Section 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></figure>

      <texttable title="LISP
</artwork>
        <table align="center" pn="table-11">
          <name slugifiedName="name-lisp-rloc-record-header-bit">LISP RLOC-Record Header Bits">
        <ttcol align='left'>Spec Name</ttcol>
        <ttcol align='left'>IANA Name</ttcol>
        <ttcol align='left'>Bit Position</ttcol>
        <ttcol align='left'>Description</ttcol>
        <c>L</c><c>rloc-record-L</c><c>13</c><c>Local 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</c>
        <c>p</c><c>rloc-record-p</c><c>19</c><c>RLOC-Probe 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</c>
        <c>R</c><c>rloc-record-R</c><c>19</c><c>RLOC 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</c>
      </texttable> Bit</td>
            </tr>
          </tbody>
        </table>
      </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-FILTER"/>
    <displayreference target="I-D.herbert-intarea-ila" to="INTAREA-ILA"/>
    <references title='Normative References'>
    <?rfc include="reference.RFC.2119'?>
    <?rfc include="reference.RFC.8174'?>
    <?rfc include="reference.RFC.8126'?>
    <?rfc include="reference.RFC.8085'?>
    <?rfc include="reference.RFC.4086'?>
    <?rfc include="reference.RFC.2404'?>
    <?rfc include="reference.RFC.4868'?>
    <?rfc include="reference.RFC.5869'?>
    <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-rfc6830bis.xml'?>
    <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-6834bis.xml'?>
    <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-sec.xml'?>
    <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-rfc8113bis.xml'?>
  </references> pn="section-13">
      <name slugifiedName="name-references">References</name>
      <references title='Informative References'>
    <?rfc include="reference.RFC.4984'?>
    <?rfc include="reference.RFC.6973'?>
    <?rfc include="reference.RFC.8111'?>
    <?rfc include="reference.RFC.6347'?>
    <?rfc include="reference.RFC.6836'?>
    <?rfc include="reference.RFC.8378'?>
    <?rfc include="reference.RFC.8060'?>
    <?rfc include="reference.RFC.8061'?>
    <?rfc include="reference.RFC.6837'?>
    <?rfc include="reference.RFC.6831'?>
    <?rfc include="reference.RFC.6830'?>
    <?rfc include="reference.RFC.1071'?>
    <?rfc include="reference.RFC.1035'?>
    <?rfc include="reference.RFC.2104'?>
    <?rfc include="reference.RFC.6234'?>
    <?rfc include="reference.RFC.6832'?>
    <?rfc include="reference.RFC.7348'?>
    <?rfc include="reference.RFC.7835'?>
    <?rfc include="reference.RFC.2890'?>
    <?rfc include="reference.RFC.8402'?>
    <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-eid-anonymity'?>
    <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-ecdsa-auth.xml'?>
    <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-mn.xml'?>
    <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-eid-mobility.xml'?>
    <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-gpe.xml'?>
    <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-nvo3-vxlan-gpe.xml'?>
    <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-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.herbert-intarea-ila.xml'?> pn="section-13.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="AFI"> anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
	<title>Address Family Identifier (AFIs)</title>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author surname="IANA">
	  <organization />
	</author> fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="Febuary" year="2007" /> 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 capitalized.  This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="ADDRESS FAMILY NUMBERS"
		  value="http://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml?"/> name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="GTP-3GPP"> anchor="RFC2404" target="https://www.rfc-editor.org/info/rfc2404" quoteTitle="true" derivedAnchor="RFC2404">
          <front>
        <title>General Packet Radio System (GPRS) Tunnelling Protocol
        User Plane (GTPv1-U)</title>
            <title>The Use of HMAC-SHA-1-96 within ESP and AH</title>
            <author surname="3GPP">
  	      <organization />
        </author> fullname="C. Madson" initials="C." surname="Madson"/>
            <author fullname="R. Glenn" initials="R." surname="Glenn"/>
            <date month="January" year="2015"/> 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 Authentication Header. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="TS.29.281" value="https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1699"/> name="RFC" value="2404"/>
          <seriesInfo name="DOI" value="10.17487/RFC2404"/>
        </reference>
  </references>

  <section title="Acknowledgments">
    <t>The original authors would like to thank Greg Schudel, Darrel Lewis,
    John Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper
    Skriver, Fabio Maino, and members of the lisp@ietf.org mailing
    list
        <reference anchor="RFC4086" target="https://www.rfc-editor.org/info/rfc4086" quoteTitle="true" derivedAnchor="RFC4086">
          <front>
            <title>Randomness Requirements for their feedback and helpful suggestions.</t>

    <t> Special thanks Security</title>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
            <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 due to Noel Chiappa built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for his extensive work passwords, cryptographic keys, and thought about caching in Map-Resolvers.</t>

    <t>The current authors would like similar quantities. The use of pseudo-random processes to give a sincere thank you generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the people who help put LISP on standards track in environment that produced the IETF.  They
    include Joel Halpern, Luigi Iannone, Deborah Brungard, Fabio
    Maino, Scott Bradner, Kyle Rose, Takeshi Takahashi, Sarah Banks,
    Pete Resnick, Colin Perkins, Mirja Kuhlewind, Francis Dupont,
    Benjamin Kaduk, Eric Rescorla, Alvaro Retana, Alexey Melnikov,
    Alissa Cooper, Suresh Krishnan, Alberto Rodriguez-Natal, Vina
    Ermagen, Mohamed Boucadair, Brian Trammell, Sabrina Tanamal, secret quantities and
    John Drake. The contributions they offered greatly added to search the
    security, scale, and robustness resulting small set of possibilities than to locate the LISP architecture quantities in the whole of the potential number space.</t>
              <t indent="0">Choosing random quantities to foil a resourceful and
    protocols.</t>
  </section>

  <section title="Document Change Log">
    <t>[RFC Editor: Please delete this section motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on publication as RFC.]</t>

    <section title="Changes many systems can be used for this purpose. It provides suggestions to draft-ietf-lisp-rfc6833bis-26">
      <t><list style="symbols">
        <t>Posted November 2019.</t>
        <t>Fixed ameliorate the required (MUST implement) authentcation algorithms.</t>
        <t>Fixed problem when a large set of minor comments hardware solution is not available, and edits.</t>
      </list></t>
    </section>

    <section title="Changes it gives examples of how large such quantities need 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 be for some applications. This document specifies an EID-record.</t>
        <t>Fixed Requirements Notation section per Pete.</t>
		<t>Added KDF Internet Best Current Practices for shared-secret</t>
		<t>Specified several rate-limiters the Internet Community, and requests discussion and suggestions 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 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/rfc4868" 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 LISP-SEC.</t>
        <t>Added to Security Considerations section that DTLS or LISP-crypto of Hashed Message 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 control-plane privacy.</t>
        <t>Make LISP-SEC a normative reference.</t>
        <t>Make it more clear where field descriptions data origin authentication and integrity verification mechanisms for the Authentication Header (AH), Encapsulating Security Payload (ESP), Internet Key Exchange Protocol (IKE), and IKEv2 protocols, and also as Pseudo-Random Functions (PRFs) for IKE and IKEv2.  Truncated output lengths are spec'ed when
        referencing to specified for the same fields authentication-related variants, with the corresponding algorithms designated as HMAC-SHA-256-128, HMAC-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/rfc5869" 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 Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block 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 various protocols and applications.  The key derivation function (KDF) is intended to draft-ietf-lisp-rfc6833bis-21">
      <t><list style="symbols">
        <t>Posted early November 2018.</t>
        <t>Added I-bit back support a wide range of applications and requirements, and is conservative in because its necessary to use of cryptographic hash functions.  This document is not an Internet Standards Track specification; it is published for Map-Register
        replay attack scenarios. The informational 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/rfc6833" quoteTitle="true" derivedAnchor="RFC6833">
          <front>
            <title>Locator/ID Separation Protocol (LISP) Map-Server tracks Interface</title>
            <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 nonce per xTR-ID
        to detect duplicate Mapping Service for the Locator/ID Separation Protocol (LISP), implemented by two new types of LISP- speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provides a simplified "front end" for one 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 more Endpoint ID to state "reserved Routing Locator mapping databases.</t>
              <t indent="0">By using this service interface and
        unassigned".</t>
        <t>Make it more clear how Map-Register nonce processing is
        performed in an ETR communicating with Map-Resolvers 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 Map-Servers, LISP Ingress Tunnel Routers and Egress Tunnel Routers are not dependent on 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 details of mapping database systems, which facilitates experimentation with different database designs. Since these devices implement the "edge" of the LISP infrastructure, connect directly 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 LISP-capable Internet end sites, and comprise the bulk of LISP-speaking devices, reducing their implementation and operational complexity should also reduce the overall cost and effort of deploying LISP. This document defines an applicability statement in section 1 to address
        security concerns from Telechat.</t>
        <t>Moved m-bit description 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/rfc8085" 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. This document provides guidelines on the use of UDP for the designers of applications, tunnels, and IANA request to
        draft-ietf-lisp-mn.</t>
        <t>Moved I-bit description other protocols that use UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of Explicit Congestion Notification (ECN), Differentiated Services Code Points (DSCPs), 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 ports.</t>
              <t indent="0">Because congestion control is critical to be more clear about IANA actions.</t>
      </list></t>
    </section>

	<section title="Changes the stable operation of the Internet, applications and other protocols that choose to draft-ietf-lisp-rfc6833bis-15">
      <t><list style="symbols">
	    <t>Posted mid-September 2018.</t>
        <t>Changes use UDP as an Internet transport must employ mechanisms to reflect comments from Colin prevent congestion collapse 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 establish some degree of fairness with concurrent traffic. They may also need to reflect comments from Genart, RTGarea, and
        Secdir reviews.</t>
      </list></t>
    </section>

	<section title="Changes implement additional mechanisms, depending on how they use UDP.</t>
              <t indent="0">Some guidance is also applicable to draft-ietf-lisp-rfc6833bis-13">
      <t><list style="symbols">
	    <t>Posted August 2018.</t>
	    <t>Final editorial changes before the design of other 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 submission 5405 and adds guidelines for Proposed
	    Standard.</t>
        <t>Added section "Changes since RFC 6833" so implementators
        are informed 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/rfc8126" 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 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 points of extensibility that use constants to ready draft for RFC status identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses 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 promote interoperability, their allocations are often coordinated by a central record keeper. For IETF week March.</t>
        <t>Move AD field encoding after S-bit in protocols, that role is filled by the ECM packet format
        description section.</t>
        <t>Say more about when Internet Assigned Numbers Authority (IANA).</t>
              <t indent="0">To make assignments in a given registry prudently, guidance describing the conditions under which new Drop actions values should be sent.</t>
      </list></t>
    </section>

	<section title="Changes assigned, as well as when and how modifications to draft-ietf-lisp-rfc6833bis-09">
      <t><list style="symbols">
        <t>Posted March IETF week 2018.</t>
        <t>Fixed editorial comments submitted by existing values can be made, is needed. This 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 defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the 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 is clear and addresses the various issues that are likely in the operation of a couple registry.</t>
              <t indent="0">This is the third edition of places this document; it obsoletes 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/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that RLOCs are may be used in protocol specifications.  This document aims to locate ETRs more so than for Map-Server Map-Request
	    forwarding.</t>
	    <t>Make it clear reduce the ambiguity by clarifying that "encapsualted" only UPPERCASE usage of the key words have the defined special meanings.</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/rfc9300" 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" role="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/rfc9302" 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 Bonaventure">
              <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/rfc9303" 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/rfc9304" quoteTitle="true" derivedAnchor="RFC9304">
          <front>
            <title>Locator/ID Separation Protocol (LISP): Shared Extension Message 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 Jacquenet">
              <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="https://datatracker.ietf.org/doc/html/draft-ietf-lisp-ecdsa-auth-09" derivedAnchor="ECDSA-AUTH">
          <front>
            <title>LISP Control-Plane ECDSA Authentication and Authorization</title>
            <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 messages can be
   individually authenticated and authorized without a control message a priori shared-
   key configuration.  Public-key cryptography is
	    an ECM based message.</t>
	    <t>Make it more clear what messages used with no new PKI
   infrastructure required.

              </t>
            </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" derivedAnchor="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 Pillay-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 LISP EIDs can be used
   to create source anonymity.  The idea makes use source-port 4342 of frequently
   changing EIDs much like how a credit-card system uses a different
   credit-card numbers for each transaction.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-lisp-eid-anonymity-13"/>
          <format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-lisp-eid-anonymity-13.txt"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="EID-MOBILITY" quoteTitle="true" target="https://datatracker.ietf.org/doc/html/draft-ietf-lisp-eid-mobility-10" derivedAnchor="EID-MOBILITY">
          <front>
            <title>LISP L2/L3 EID Mobility Using a Unified Control Plane</title>
            <author initials="M" surname="Portoles" fullname="Marc Portoles Comeras">
              <organization showOnFrontPage="true">Cisco Systems</organization>
            </author>
            <author initials="V" surname="Ashtaputre" fullname="Vrushali Ashtaputre">
              <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/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1699" quoteTitle="true" derivedAnchor="GTP-3GPP">
          <front>
            <title>General Packet Radio System (GPRS) Tunnelling Protocol User Plane (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="https://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 addressing (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 ones can be dynamic. Identifier-locator
   addressing can be used to efficiently implement overlay networks for
   network virtualization as well as solutions for use destinatino-port 4342.</t>
	    <t>Don't make DDT references when the mapping transport system cases in
   mobility.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-herbert-intarea-ila-01"/>
          <format type="TXT" target="https://www.ietf.org/archive/id/draft-herbert-intarea-ila-01.txt"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.ietf-lisp-mn" quoteTitle="true" target="https://datatracker.ietf.org/doc/html/draft-ietf-lisp-mn-12" derivedAnchor="LISP-MN">
          <front>
            <title>LISP Mobile Node</title>
            <author initials="D." surname="Farinacci" fullname="Dino Farinacci">
              <organization showOnFrontPage="true">lispers.net</organization>
            </author>
            <author initials="D." surname="Lewis" fullname="Darrel Lewis">
              <organization showOnFrontPage="true">cisco Systems</organization>
            </author>
            <author initials="D." surname="Meyer" fullname="David Meyer">
              <organization showOnFrontPage="true">1-4-5.net</organization>
            </author>
            <author initials="C." surname="White" fullname="Chris White">
              <organization showOnFrontPage="true">Logical Elegance</organization>
            </author>
            <date month="July" day="24" year="2022"/>
            <abstract>
              <t indent="0">   This document describes how a lightweight version of LISP's ITR/ETR
   functionality can be used to provide seamless mobility to a mobile
   node.  The LISP Mobile Node design described in this document uses
   standard LISP functionality to provide scalable mobility for LISP
   mobile nodes.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-lisp-mn-12"/>
          <format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-lisp-mn-12.txt"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.ietf-lisp-pubsub" quoteTitle="true" target="https://datatracker.ietf.org/doc/html/draft-ietf-lisp-pubsub-09" derivedAnchor="LISP-PUBSUB">
          <front>
            <title>Publish/Subscribe Functionality for LISP</title>
            <author initials="A." surname="Rodriguez-Natal" fullname="Alberto Rodriguez-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 Cabellos-Aparicio">
              <organization showOnFrontPage="true">UPC/BarcelonaTech</organization>
            </author>
            <author initials="S." surname="Barkai" fullname="Sharon Barkai">
              <organization showOnFrontPage="true">Nexar</organization>
            </author>
            <author initials="M." surname="Boucadair" fullname="Mohamed Boucadair">
              <organization showOnFrontPage="true">Orange</organization>
            </author>
            <date month="June" day="28" year="2021"/>
            <abstract>
              <t indent="0">   This document specifies an extension to the Request/Reply based LISP
   Control Plane to enable Publish/Subscribe (PubSub) operation.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-lisp-pubsub-09"/>
          <format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-lisp-pubsub-09.txt"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="NVO3-VXLAN-GPE" quoteTitle="true" target="https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-vxlan-gpe-12" derivedAnchor="NVO3-VXLAN-GPE">
          <front>
            <title>Generic Protocol Extension for VXLAN (VXLAN-GPE)</title>
            <author initials="F" surname="Maino" fullname="Fabio Maino" role="editor">
              <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="editor">
              <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" target="https://datatracker.ietf.org/doc/html/draft-ietf-opsec-icmp-filtering-04" derivedAnchor="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 filtering of any type ICMPv4 and
   ICMPv6 messages.  Additionaly, it discusses the referneced text operational and
   interoperability implications of such filtering.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-opsec-icmp-filtering-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/rfc1035" 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 general to
	    it.</t>
	    <t>Generalize text when referring to the revised specification of the protocol and format used in the implementation of an
	    EID-prefix. Can use othe AFIs then IPv4 the Domain Name System.  It obsoletes RFC-883.  This memo documents the details of the domain name client - server communication.</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/rfc1071" 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 IPv6.</t>
	    <t>Many editorial changes to clarify text.</t>
	    <t>Changed some "must", "should", algorithms for efficiently computing the Internet checksum.  It is not a standard, but a set of useful 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/rfc2890" quoteTitle="true" derivedAnchor="RFC2890">
          <front>
            <title>Key and "may" Sequence Number Extensions to capitalized.</t>
	    <t>Added definitions for Map-Request 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 fields, Key and Map-Reply messages.</t>
	    <t>Ran Sequence Number, can be optionally carried in the GRE Header. [STANDARDS-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/rfc4984" 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="Meyer"/>
            <author fullname="L. Zhang" initials="L." role="editor" surname="Zhang"/>
            <author fullname="K. Fall" initials="K." role="editor" surname="Fall"/>
            <date month="September" year="2007"/>
            <abstract>
              <t indent="0">This document through IDNITs.</t>
      </list></t>
    </section>

    <section title="Changes to draft-ietf-lisp-rfc6833bis-06">
      <t><list style="symbols">
        <t>Posted reports the outcome of the Routing and Addressing Workshop that was held by the Internet Architecture Board (IAB) on October 2017.</t>
	    <t>Spec 18-19, 2006, in Amsterdam, Netherlands. The primary goal of the I-bit workshop was to develop a shared understanding of the problems that the large backbone operators are facing regarding the scalability of today's Internet routing system. The key workshop findings include an analysis of the xTR-ID major factors that are driving routing table growth, constraints in a Map-Request
	    message router technology, and the limitations of today's Internet addressing architecture. It is hoped that these findings will serve as input to be consistent with the Map-Register message IETF community and to
	    anticipate help identify next steps towards effective solutions.</t>
              <t indent="0">Note that this document is a report on the introduction proceedings of pubsub functionality 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 allow
	    Map-Requests this workshop report is continuing, and this document does not intend to subscribe reflect the increased understanding of issues nor to RLOC-set changes.</t>
	    <t>Updated references for individual submissions discuss the range of potential solutions that became
	    working group documents.</t>
	    <t>Updated references may be the outcome of this ongoing work. This memo provides information for working group documents 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/rfc6830" 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 protocol 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 enables separation of IP addresses into two new requests
	    from this document numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). No changes from what was requested in
	    <xref target="RFC6830"/>.</t>
      </list></t>
    </section>

    <section title="Changes are required to either host protocol stacks or 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 "core" of the 16-bit field into Internet infrastructure. The Locator/ID Separation Protocol (LISP) can be incrementally deployed, without a 8-bit
	    Key-ID field "flag day", and a 8-bit Algorithm-ID field.</t>
	    <t>Move the Control-Plane codepoints from the IANA
	    Considerations section of RFC6830bis offers Traffic Engineering, multihoming, and mobility benefits to the IANA
	    Considerations section early adopters, even when there are relatively few LISP-capable sites.</t>
              <t indent="0">Design and development of this document.</t>
	    <t>In LISP was largely motivated by the "LISP Control Packet Type Allocations" section,
	    indicate how message Types are IANA allocated problem statement produced by the October 2006 IAB Routing and Addressing Workshop. This document defines an Experimental Protocol for the Internet community.</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/rfc6831" quoteTitle="true" derivedAnchor="RFC6831">
          <front>
            <title>The Locator/ID Separation Protocol (LISP) for Multicast Environments</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
	    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 inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the Locator/ID Separation Protocol (LISP) architecture.  This document defines 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/rfc6832" quoteTitle="true" derivedAnchor="RFC6832">
          <front>
            <title>Interworking between Locator/ID Separation Protocol (LISP) and specify they 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 sites running the Locator/ID Separation Protocol (LISP) to interoperate with Internet sites that may be using either IPv4, IPv6, or both but that are not assigned.</t>
	    <t>Add running LISP.  A fundamental property of LISP-speaking sites is that they use Endpoint Identifiers (EIDs), rather than traditional IP addresses, in the "LISP Shared Extension Message" type source and point destination fields of all traffic they emit or receive.  While EIDs are syntactically identical to
	    RFC8113.</t>
      </list></t>
    </section>

    <section title="Changes IPv4 or IPv6 addresses, normally routes to draft-ietf-lisp-rfc6833bis-02">
      <t><list style="symbols">
        <t>Posted April 2017.</t>
	    <t>Clarify that them are not carried in the global routing system, so an interoperability mechanism is needed for non- LISP-speaking sites to exchange traffic with LISP-speaking sites.  This document introduces three such mechanisms.  The first uses a new network element, the LISP Control-Plane Proxy Ingress Tunnel Router (Proxy-ITR), to act as an intermediate LISP Ingress Tunnel Router (ITR) for non-LISP- speaking hosts.  Second, this document defines how adds Network Address Translation (NAT) functionality to LISP ITRs and LISP Egress Tunnel Routers (ETRs) to substitute routable IP addresses for non-routable EIDs.  Finally, this document introduces the Proxy Egress Tunnel Router (Proxy-ETR) to handle cases where a LISP Data-Plane uses Map-Requests with either ITR cannot send packets to non-LISP sites without encapsulation.  This document defines an Experimental Protocol for the SMR-bit
	    set Internet community.</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/rfc6836" 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 system to be used by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router (ITR) or Map-Resolver (MR) to find the P-bit set supporting mapping updates and
	    RLOC-probing.  Indicating Egress Tunnel Router (ETR) that other Data-Planes can use holds the
	    same mechanisms or their own defined mechanisms mapping information for a particular Endpoint Identifier (EID).  The MR can then query that ETR to achieve obtain the
	    same functionality.</t>
      </list></t>
    </section>

    <section title="Changes actual mapping information, which consists of a list of Routing Locators (RLOCs) for the EID.  Termed the Alternative Logical Topology (ALT), the index is built as an overlay network on the public Internet using 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/rfc6837" quoteTitle="true" derivedAnchor="RFC6837">
          <front>
            <title>NERD: A Not-so-novel Endpoint ID (EID) to draft-ietf-lisp-rfc6833bis-01">
      <t><list style="symbols">
        <t>Posted March 2017.</t>
	    <t>Include references Routing Locator (RLOC) 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 protocol to new RFCs published.</t>
	    <t>Remove references encapsulate IP packets in order to self.</t>
	    <t>Change references from RFC6830 allow end sites to RFC6830bis.</t>
	    <t>Add two new action/reasons route to one another without injecting routes from one end of the Internet to another.  This memo presents an experimental database and a Map-Reply has posted discussion of methods to transport 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 mapping of Endpoint IDs (EIDs) to
	    "experimental".</t>
      </list></t>
    </section>

    <section title="Changes Routing Locators (RLOCs) to draft-ietf-lisp-rfc6833bis-00">
      <t><list style="symbols">
        <t>Posted December 2016.</t>
	    <t>Created working group document from draft-farinacci-lisp
	    -rfc6833-00 individual submission. No other changes made.</t>
      </list></t>
    </section>

    <section title="Changes routers in a reliable, scalable, and secure manner.  Our analysis concludes that transport of all EID-to- RLOC mappings scales well to draft-farinacci-lisp-rfc6833bis-00">
      <t><list style="symbols">
        <t>Posted November 2016.</t>
        <t>This is at least 10^8 entries.  This document defines an Experimental Protocol for the initial draft 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/rfc6973" 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 turn RFC 6833 into make designers, implementers, and users of Internet protocols aware of privacy-related design choices.  It suggests that whether any individual RFC
        6833bis.</t>
	    <t>The warrants a specific privacy 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/rfc7348" quoteTitle="true" derivedAnchor="RFC7348">
          <front>
            <title>Virtual eXtensible Local Area Network (VXLAN): A Framework for 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 name has changed from describes Virtual eXtensible Local Area Network (VXLAN), which is used to address the need for overlay networks within virtualized data centers accommodating multiple tenants.  The scheme and the related protocols can be used in networks for cloud service providers and enterprise data centers.  This memo documents the "Locator/ID deployed VXLAN protocol for the benefit 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/rfc7835" quoteTitle="true" derivedAnchor="RFC7835">
          <front>
            <title>Locator/ID Separation Protocol (LISP) Map-Server Interface" to 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
	    "Locator/ID Locator/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/rfc8060" 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 encoding used in Locator/ID Separation Protocol (LISP) Control-Plane".</t>
	    <t>The fundamental change was to move the Control-Plane control messages from RFC 6830 to this document and in an effort so any
	    IETF developed or industry created 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/rfc8061" quoteTitle="true" derivedAnchor="RFC8061">
          <front>
            <title>Locator/ID Separation Protocol (LISP) Data-Plane could use Confidentiality</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 traffic encapsulated using the Locator/ID Separation Protocol (LISP).  The design describes how key exchange is achieved using existing LISP mapping system and Control-Plane.</t>
	    <t>Update Control-Plane messages control-plane mechanisms as well as how to incorporate what has been
	    implemented in products during secure the early phase 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/rfc8111" 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 Protocol Delegated Database Tree (LISP-DDT), a hierarchical distributed database that embodies the delegation of authority to provide mappings from LISP
	    development but wasn't able Endpoint Identifiers (EIDs) to make it into RFC6830 Routing Locators (RLOCs).  It is a statically defined distribution of the EID namespace among a set of LISP-speaking servers called "DDT nodes".  Each DDT node is configured as "authoritative" for one or more EID-prefixes, along with the set of RLOCs for Map-Servers or "child" DDT nodes to which more-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/rfc8378" 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
	    RFC6833 receivers are active at Locator/ID Separation Protocol (LISP) sites, the core network is required to make use native multicast so packets can be delivered from sources to group members.  When multicast is not available to connect the Experimental RFC deadline.</t>
	    <t>Indicate there may multicast sites together, a signal-free mechanism can be nodes 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 that are
	    not MRs so encapsulators at the source LISP multicast site can find decapsulators at the receiver 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/rfc8402" 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="Previdi"/>
            <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 paradigm. 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 MSs, global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the 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. An ordered list of segments is encoded as a ALT-node or stack of labels. The segment to process is on the top of the stack. Upon completion of a DDT-node.</t>
	    <t>Include LISP-DDT segment, the related label is popped from the stack.</t>
              <t indent="0">SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in Map-Resolver section and explain how
	    they maintain the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a referral-cache.</t>
	    <t>Removed open issue about additional state pointer in Map-Servers.
	    With <xref target="RFC8111"/>, Map-Servers have the same
	    registration state new routing header.</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/rfc9147" 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 applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and can message forgery.</t>
              <t indent="0">The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the 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/rfc9299" quoteTitle="true" derivedAnchor="RFC9299">
          <front>
            <title>An Architectural Introduction to the Locator/ID Separation Protocol (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/rfc9305" quoteTitle="true" derivedAnchor="RFC9305">
          <front>
            <title>Locator/ID Separation Protocol (LISP) Generic Protocol Extension</title>
            <author initials="F" surname="Maino" fullname="Fabio Maino" role="editor">
              <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-appendix.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"/>, <contact fullname="Dave Meyer"/>, <contact fullname="Isidor Kouvelas"/>, <contact fullname="Jesper     Skriver"/>,  and members of the lisp@ietf.org mailing
    list for their feedback and helpful suggestions.</t>
      <t indent="0" pn="section-appendix.a-2"> Special thanks are due to <contact fullname="Noel Chiappa"/> for his extensive work
    and thought about caching in Map-Resolvers.</t>
      <t indent="0" pn="section-appendix.a-3">The current authors would like to give Map-Resolvers complete
	    information a sincere thank you to
    the people who help put LISP on the Standards Track in ms-ack Map-Referral messages.</t>
	    <t>Make reference the IETF.  They
    include <contact fullname="Joel Halpern"/>, <contact fullname="Luigi Iannone"/>, <contact fullname="Deborah Brungard"/>, <contact fullname="Fabio     Maino"/>, <contact fullname="Scott Bradner"/>, <contact fullname="Kyle Rose"/>, <contact fullname="Takeshi Takahashi"/>, <contact fullname="Sarah Banks"/>,
    <contact fullname="Pete Resnick"/>, <contact fullname="Colin Perkins"/>, <contact fullname="Mirja Kühlewind"/>, <contact fullname="Francis Dupont"/>,
    <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     Ermagan"/>, <contact fullname="Mohamed Boucadair"/>, <contact fullname="Brian Trammell"/>, <contact fullname="Sabrina Tanamal"/>, and
    <contact fullname="John Drake"/>. The contributions they offered greatly added to the
    security, scale, and robustness of the LISP Threats Analysis RFC
	    <xref target="RFC7835"/>.</t>
      </list></t> architecture and
    protocols.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="D" surname="Farinacci" fullname="Dino Farinacci">
        <organization showOnFrontPage="true">lispers.net</organization>
        <address>
          <postal>
            <city>San Jose</city>
            <region>CA</region>
            <country>United States of America</country>
          </postal>
          <email>farinacci@gmail.com</email>
        </address>
      </author>
      <author initials="F" surname="Maino" fullname="Fabio Maino">
        <organization showOnFrontPage="true">Cisco Systems</organization>
        <address>
          <postal>
            <city>San Jose</city>
            <region>CA</region>
            <country>United States of America</country>
          </postal>
          <email>fmaino@cisco.com</email>
        </address>
      </author>
      <author initials="V" surname="Fuller" fullname="Vince Fuller">
        <organization showOnFrontPage="true">vaf.net Internet Consulting</organization>
        <address>
          <email>vince.fuller@gmail.com</email>
        </address>
      </author>
      <author initials="A" surname="Cabellos" fullname="Albert Cabellos" role="editor">
        <organization showOnFrontPage="true">Universitat Politecnica de Catalunya</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>
  </back>
</rfc>