File: rfc9301.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: bookworm, forky, sid, trixie
size: 1,609,944 kB
file content (4267 lines) | stat: -rw-r--r-- 243,322 bytes
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 9301: Locator/ID Separation Protocol (LISP) Control Plane</title>
<meta content="Dino Farinacci" name="author">
<meta content="Fabio Maino" name="author">
<meta content="Vince Fuller" name="author">
<meta content="Albert Cabellos" name="author">
<meta content='
        This document describes the 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 provide a simplified "front end" for one
    or more Endpoint IDs (EIDs) to Routing Locator mapping databases. 
       By using this 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; this behavior facilitates modularity
    with different database designs.  Since these devices implement the "edge" of the
    LISP control plane infrastructure, connecting EID addressable nodes
    of a LISP site, the implementation and operational complexity of the
      overall cost and effort of deploying LISP is reduced. 
       This document obsoletes RFCs 6830 and 6833. 
    ' name="description">
<meta content="xml2rfc 3.15.1" name="generator">
<meta content="9301" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.15.1
    Python 3.9.13
    appdirs 1.4.4
    ConfigArgParse 1.5.3
    google-i18n-address 2.5.1
    html5lib 1.1
    intervaltree 3.1.0
    Jinja2 3.1.2
    kitchen 1.2.6
    lxml 4.9.0
    MarkupSafe 2.1.1
    pycountry 22.3.5
    PyYAML 6.0
    requests 2.28.0
    setuptools 44.1.1
    six 1.16.0
    weasyprint 56.1
-->
<link href="rfc9301.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

  NOTE: Changes at the bottom of this file overrides some earlier settings.

  Once the style has stabilized and has been adopted as an official RFC style,
  this can be consolidated so that style settings occur only in one place, but
  for now the contents of this file consists first of the initial CSS work as
  provided to the RFC Formatter (xml2rfc) work, followed by itemized and
  commented changes found necssary during the development of the v3
  formatters.

*/

/* fonts */
@import url('https://fonts.googleapis.com/css?family=Noto+Sans'); /* Sans-serif */
@import url('https://fonts.googleapis.com/css?family=Noto+Serif'); /* Serif (print) */
@import url('https://fonts.googleapis.com/css?family=Roboto+Mono'); /* Monospace */

@viewport {
  zoom: 1.0;
  width: extend-to-zoom;
}
@-ms-viewport {
  width: extend-to-zoom;
  zoom: 1.0;
}
/* general and mobile first */
html {
}
body {
  max-width: 90%;
  margin: 1.5em auto;
  color: #222;
  background-color: #fff;
  font-size: 14px;
  font-family: 'Noto Sans', Arial, Helvetica, sans-serif;
  line-height: 1.6;
  scroll-behavior: smooth;
}
.ears {
  display: none;
}

/* headings */
#title, h1, h2, h3, h4, h5, h6 {
  margin: 1em 0 0.5em;
  font-weight: bold;
  line-height: 1.3;
}
#title {
  clear: both;
  border-bottom: 1px solid #ddd;
  margin: 0 0 0.5em 0;
  padding: 1em 0 0.5em;
}
.author {
  padding-bottom: 4px;
}
h1 {
  font-size: 26px;
  margin: 1em 0;
}
h2 {
  font-size: 22px;
  margin-top: -20px;  /* provide offset for in-page anchors */
  padding-top: 33px;
}
h3 {
  font-size: 18px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h4 {
  font-size: 16px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h5, h6 {
  font-size: 14px;
}
#n-copyright-notice {
  border-bottom: 1px solid #ddd;
  padding-bottom: 1em;
  margin-bottom: 1em;
}
/* general structure */
p {
  padding: 0;
  margin: 0 0 1em 0;
  text-align: left;
}
div, span {
  position: relative;
}
div {
  margin: 0;
}
.alignRight.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignRight.art-text pre {
  padding: 0;
}
.alignRight {
  margin: 1em 0;
}
.alignRight > *:first-child {
  border: none;
  margin: 0;
  float: right;
  clear: both;
}
.alignRight > *:nth-child(2) {
  clear: both;
  display: block;
  border: none;
}
svg {
  display: block;
}
.alignCenter.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignCenter.art-text pre {
  padding: 0;
}
.alignCenter {
  margin: 1em 0;
}
.alignCenter > *:first-child {
  display: table;
  border: none;
  margin: 0 auto;
}

/* lists */
ol, ul {
  padding: 0;
  margin: 0 0 1em 2em;
}
ol ol, ul ul, ol ul, ul ol {
  margin-left: 1em;
}
li {
  margin: 0 0 0.25em 0;
}
.ulCompact li {
  margin: 0;
}
ul.empty, .ulEmpty {
  list-style-type: none;
}
ul.empty li, .ulEmpty li {
  margin-top: 0.5em;
}
ul.ulBare, li.ulBare {
  margin-left: 0em !important;
}
ul.compact, .ulCompact,
ol.compact, .olCompact {
  line-height: 100%;
  margin: 0 0 0 2em;
}

/* definition lists */
dl {
}
dl > dt {
  float: left;
  margin-right: 1em;
}
/* 
dl.nohang > dt {
  float: none;
}
*/
dl > dd {
  margin-bottom: .8em;
  min-height: 1.3em;
}
dl.compact > dd, .dlCompact > dd {
  margin-bottom: 0em;
}
dl > dd > dl {
  margin-top: 0.5em;
  margin-bottom: 0em;
}

/* links */
a {
  text-decoration: none;
}
a[href] {
  color: #22e; /* Arlen: WCAG 2019 */
}
a[href]:hover {
  background-color: #f2f2f2;
}
figcaption a[href],
a[href].selfRef {
  color: #222;
}
/* XXX probably not this:
a.selfRef:hover {
  background-color: transparent;
  cursor: default;
} */

/* Figures */
tt, code, pre {
  background-color: #f9f9f9;
  font-family: 'Roboto Mono', monospace;
}
pre {
  border: 1px solid #eee;
  margin: 0;
  padding: 1em;
}
img {
  max-width: 100%;
}
figure {
  margin: 0;
}
figure blockquote {
  margin: 0.8em 0.4em 0.4em;
}
figcaption {
  font-style: italic;
  margin: 0 0 1em 0;
}
@media screen {
  pre {
    overflow-x: auto;
    max-width: 100%;
    max-width: calc(100% - 22px);
  }
}

/* aside, blockquote */
aside, blockquote {
  margin-left: 0;
  padding: 1.2em 2em;
}
blockquote {
  background-color: #f9f9f9;
  color: #111; /* Arlen: WCAG 2019 */
  border: 1px solid #ddd;
  border-radius: 3px;
  margin: 1em 0;
}
cite {
  display: block;
  text-align: right;
  font-style: italic;
}

/* tables */
table {
  width: 100%;
  margin: 0 0 1em;
  border-collapse: collapse;
  border: 1px solid #eee;
}
th, td {
  text-align: left;
  vertical-align: top;
  padding: 0.5em 0.75em;
}
th {
  text-align: left;
  background-color: #e9e9e9;
}
tr:nth-child(2n+1) > td {
  background-color: #f5f5f5;
}
table caption {
  font-style: italic;
  margin: 0;
  padding: 0;
  text-align: left;
}
table p {
  /* XXX to avoid bottom margin on table row signifiers. If paragraphs should
     be allowed within tables more generally, it would be far better to select on a class. */
  margin: 0;
}

/* pilcrow */
a.pilcrow {
  color: #666; /* Arlen: AHDJ 2019 */
  text-decoration: none;
  visibility: hidden;
  user-select: none;
  -ms-user-select: none;
  -o-user-select:none;
  -moz-user-select: none;
  -khtml-user-select: none;
  -webkit-user-select: none;
  -webkit-touch-callout: none;
}
@media screen {
  aside:hover > a.pilcrow,
  p:hover > a.pilcrow,
  blockquote:hover > a.pilcrow,
  div:hover > a.pilcrow,
  li:hover > a.pilcrow,
  pre:hover > a.pilcrow {
    visibility: visible;
  }
  a.pilcrow:hover {
    background-color: transparent;
  }
}

/* misc */
hr {
  border: 0;
  border-top: 1px solid #eee;
}
.bcp14 {
  font-variant: small-caps;
}

.role {
  font-variant: all-small-caps;
}

/* info block */
#identifiers {
  margin: 0;
  font-size: 0.9em;
}
#identifiers dt {
  width: 3em;
  clear: left;
}
#identifiers dd {
  float: left;
  margin-bottom: 0;
}
/* Fix PDF info block run off issue */
@media print {
  #identifiers dd {
    float: none;
  }
}
#identifiers .authors .author {
  display: inline-block;
  margin-right: 1.5em;
}
#identifiers .authors .org {
  font-style: italic;
}

/* The prepared/rendered info at the very bottom of the page */
.docInfo {
  color: #666; /* Arlen: WCAG 2019 */
  font-size: 0.9em;
  font-style: italic;
  margin-top: 2em;
}
.docInfo .prepared {
  float: left;
}
.docInfo .prepared {
  float: right;
}

/* table of contents */
#toc  {
  padding: 0.75em 0 2em 0;
  margin-bottom: 1em;
}
nav.toc ul {
  margin: 0 0.5em 0 0;
  padding: 0;
  list-style: none;
}
nav.toc li {
  line-height: 1.3em;
  margin: 0.75em 0;
  padding-left: 1.2em;
  text-indent: -1.2em;
}
/* references */
.references dt {
  text-align: right;
  font-weight: bold;
  min-width: 7em;
}
.references dd {
  margin-left: 8em;
  overflow: auto;
}

.refInstance {
  margin-bottom: 1.25em;
}

.references .ascii {
  margin-bottom: 0.25em;
}

/* index */
.index ul {
  margin: 0 0 0 1em;
  padding: 0;
  list-style: none;
}
.index ul ul {
  margin: 0;
}
.index li {
  margin: 0;
  text-indent: -2em;
  padding-left: 2em;
  padding-bottom: 5px;
}
.indexIndex {
  margin: 0.5em 0 1em;
}
.index a {
  font-weight: 700;
}
/* make the index two-column on all but the smallest screens */
@media (min-width: 600px) {
  .index ul {
    -moz-column-count: 2;
    -moz-column-gap: 20px;
  }
  .index ul ul {
    -moz-column-count: 1;
    -moz-column-gap: 0;
  }
}

/* authors */
address.vcard {
  font-style: normal;
  margin: 1em 0;
}

address.vcard .nameRole {
  font-weight: 700;
  margin-left: 0;
}
address.vcard .label {
  font-family: "Noto Sans",Arial,Helvetica,sans-serif;
  margin: 0.5em 0;
}
address.vcard .type {
  display: none;
}
.alternative-contact {
  margin: 1.5em 0 1em;
}
hr.addr {
  border-top: 1px dashed;
  margin: 0;
  color: #ddd;
  max-width: calc(100% - 16px);
}

/* temporary notes */
.rfcEditorRemove::before {
  position: absolute;
  top: 0.2em;
  right: 0.2em;
  padding: 0.2em;
  content: "The RFC Editor will remove this note";
  color: #9e2a00; /* Arlen: WCAG 2019 */
  background-color: #ffd; /* Arlen: WCAG 2019 */
}
.rfcEditorRemove {
  position: relative;
  padding-top: 1.8em;
  background-color: #ffd; /* Arlen: WCAG 2019 */
  border-radius: 3px;
}
.cref {
  background-color: #ffd; /* Arlen: WCAG 2019 */
  padding: 2px 4px;
}
.crefSource {
  font-style: italic;
}
/* alternative layout for smaller screens */
@media screen and (max-width: 1023px) {
  body {
    padding-top: 2em;
  }
  #title {
    padding: 1em 0;
  }
  h1 {
    font-size: 24px;
  }
  h2 {
    font-size: 20px;
    margin-top: -18px;  /* provide offset for in-page anchors */
    padding-top: 38px;
  }
  #identifiers dd {
    max-width: 60%;
  }
  #toc {
    position: fixed;
    z-index: 2;
    top: 0;
    right: 0;
    padding: 0;
    margin: 0;
    background-color: inherit;
    border-bottom: 1px solid #ccc;
  }
  #toc h2 {
    margin: -1px 0 0 0;
    padding: 4px 0 4px 6px;
    padding-right: 1em;
    min-width: 190px;
    font-size: 1.1em;
    text-align: right;
    background-color: #444;
    color: white;
    cursor: pointer;
  }
  #toc h2::before { /* css hamburger */
    float: right;
    position: relative;
    width: 1em;
    height: 1px;
    left: -164px;
    margin: 6px 0 0 0;
    background: white none repeat scroll 0 0;
    box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
    content: "";
  }
  #toc nav {
    display: none;
    padding: 0.5em 1em 1em;
    overflow: auto;
    height: calc(100vh - 48px);
    border-left: 1px solid #ddd;
  }
}

/* alternative layout for wide screens */
@media screen and (min-width: 1024px) {
  body {
    max-width: 724px;
    margin: 42px auto;
    padding-left: 1.5em;
    padding-right: 29em;
  }
  #toc {
    position: fixed;
    top: 42px;
    right: 42px;
    width: 25%;
    margin: 0;
    padding: 0 1em;
    z-index: 1;
  }
  #toc h2 {
    border-top: none;
    border-bottom: 1px solid #ddd;
    font-size: 1em;
    font-weight: normal;
    margin: 0;
    padding: 0.25em 1em 1em 0;
  }
  #toc nav {
    display: block;
    height: calc(90vh - 84px);
    bottom: 0;
    padding: 0.5em 0 0;
    overflow: auto;
  }
  img { /* future proofing */
    max-width: 100%;
    height: auto;
  }
}

/* pagination */
@media print {
  body {

    width: 100%;
  }
  p {
    orphans: 3;
    widows: 3;
  }
  #n-copyright-notice {
    border-bottom: none;
  }
  #toc, #n-introduction {
    page-break-before: always;
  }
  #toc {
    border-top: none;
    padding-top: 0;
  }
  figure, pre {
    page-break-inside: avoid;
  }
  figure {
    overflow: scroll;
  }
  pre.breakable {
    break-inside: auto;
  }
  h1, h2, h3, h4, h5, h6 {
    page-break-after: avoid;
  }
  h2+*, h3+*, h4+*, h5+*, h6+* {
    page-break-before: avoid;
  }
  pre {
    white-space: pre-wrap;
    word-wrap: break-word;
    font-size: 10pt;
  }
  table {
    border: 1px solid #ddd;
  }
  td {
    border-top: 1px solid #ddd;
  }
}

/* This is commented out here, as the string-set: doesn't
   pass W3C validation currently */
/*
.ears thead .left {
  string-set: ears-top-left content();
}

.ears thead .center {
  string-set: ears-top-center content();
}

.ears thead .right {
  string-set: ears-top-right content();
}

.ears tfoot .left {
  string-set: ears-bottom-left content();
}

.ears tfoot .center {
  string-set: ears-bottom-center content();
}

.ears tfoot .right {
  string-set: ears-bottom-right content();
}
*/

@page :first {
  padding-top: 0;
  @top-left {
    content: normal;
    border: none;
  }
  @top-center {
    content: normal;
    border: none;
  }
  @top-right {
    content: normal;
    border: none;
  }
}

@page {
  size: A4;
  margin-bottom: 45mm;
  padding-top: 20px;
  /* The follwing is commented out here, but set appropriately by in code, as
     the content depends on the document */
  /*
  @top-left {
    content: 'Internet-Draft';
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-left {
    content: string(ears-top-left);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-center {
    content: string(ears-top-center);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-right {
    content: string(ears-top-right);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @bottom-left {
    content: string(ears-bottom-left);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-center {
    content: string(ears-bottom-center);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-right {
      content: '[Page ' counter(page) ']';
      vertical-align: top;
      border-top: solid 1px #ccc;
  }
  */

}

/* Changes introduced to fix issues found during implementation */
/* Make sure links are clickable even if overlapped by following H* */
a {
  z-index: 2;
}
/* Separate body from document info even without intervening H1 */
section {
  clear: both;
}


/* Top align author divs, to avoid names without organization dropping level with org names */
.author {
  vertical-align: top;
}

/* Leave room in document info to show Internet-Draft on one line */
#identifiers dt {
  width: 8em;
}

/* Don't waste quite as much whitespace between label and value in doc info */
#identifiers dd {
  margin-left: 1em;
}

/* Give floating toc a background color (needed when it's a div inside section */
#toc {
  background-color: white;
}

/* Make the collapsed ToC header render white on gray also when it's a link */
@media screen and (max-width: 1023px) {
  #toc h2 a,
  #toc h2 a:link,
  #toc h2 a:focus,
  #toc h2 a:hover,
  #toc a.toplink,
  #toc a.toplink:hover {
    color: white;
    background-color: #444;
    text-decoration: none;
  }
}

/* Give the bottom of the ToC some whitespace */
@media screen and (min-width: 1024px) {
  #toc {
    padding: 0 0 1em 1em;
  }
}

/* Style section numbers with more space between number and title */
.section-number {
  padding-right: 0.5em;
}

/* prevent monospace from becoming overly large */
tt, code, pre {
  font-size: 95%;
}

/* Fix the height/width aspect for ascii art*/
pre.sourcecode,
.art-text pre {
  line-height: 1.12;
}


/* Add styling for a link in the ToC that points to the top of the document */
a.toplink {
  float: right;
  margin-right: 0.5em;
}

/* Fix the dl styling to match the RFC 7992 attributes */
dl > dt,
dl.dlParallel > dt {
  float: left;
  margin-right: 1em;
}
dl.dlNewline > dt {
  float: none;
}

/* Provide styling for table cell text alignment */
table td.text-left,
table th.text-left {
  text-align: left;
}
table td.text-center,
table th.text-center {
  text-align: center;
}
table td.text-right,
table th.text-right {
  text-align: right;
}

/* Make the alternative author contact informatio look less like just another
   author, and group it closer with the primary author contact information */
.alternative-contact {
  margin: 0.5em 0 0.25em 0;
}
address .non-ascii {
  margin: 0 0 0 2em;
}

/* With it being possible to set tables with alignment
  left, center, and right, { width: 100%; } does not make sense */
table {
  width: auto;
}

/* Avoid reference text that sits in a block with very wide left margin,
   because of a long floating dt label.*/
.references dd {
  overflow: visible;
}

/* Control caption placement */
caption {
  caption-side: bottom;
}

/* Limit the width of the author address vcard, so names in right-to-left
   script don't end up on the other side of the page. */

address.vcard {
  max-width: 30em;
  margin-right: auto;
}

/* For address alignment dependent on LTR or RTL scripts */
address div.left {
  text-align: left;
}
address div.right {
  text-align: right;
}

/* Provide table alignment support.  We can't use the alignX classes above
   since they do unwanted things with caption and other styling. */
table.right {
 margin-left: auto;
 margin-right: 0;
}
table.center {
 margin-left: auto;
 margin-right: auto;
}
table.left {
 margin-left: 0;
 margin-right: auto;
}

/* Give the table caption label the same styling as the figcaption */
caption a[href] {
  color: #222;
}

@media print {
  .toplink {
    display: none;
  }

  /* avoid overwriting the top border line with the ToC header */
  #toc {
    padding-top: 1px;
  }

  /* Avoid page breaks inside dl and author address entries */
  .vcard {
    page-break-inside: avoid;
  }

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .artwork > pre,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr {
  break-inside: avoid;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: auto;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
li > p {
  margin-bottom: 0.5em
}
/* Don't let p margin spill out from inside list items */
li > p:last-of-type {
  margin-bottom: 0;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc9301" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis-31" rel="prev">
  </head>
<body class="xml2rfc">
<script src="https://www.rfc-editor.org/js/metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">RFC 9301</td>
<td class="center">LISP Control Plane</td>
<td class="right">October 2022</td>
</tr></thead>
<tfoot><tr>
<td class="left">Farinacci, et al.</td>
<td class="center">Standards Track</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Internet Engineering Task Force (IETF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc9301" class="eref">9301</a></dd>
<dt class="label-obsoletes">Obsoletes:</dt>
<dd class="obsoletes">
<a href="https://www.rfc-editor.org/rfc/rfc6830" class="eref">6830</a>, <a href="https://www.rfc-editor.org/rfc/rfc6833" class="eref">6833</a> </dd>
<dt class="label-category">Category:</dt>
<dd class="category">Standards Track</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2022-10" class="published">October 2022</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">D. Farinacci</div>
<div class="org">lispers.net</div>
</div>
<div class="author">
      <div class="author-name">F. Maino</div>
<div class="org">Cisco Systems</div>
</div>
<div class="author">
      <div class="author-name">V. Fuller</div>
<div class="org">vaf.net Internet Consulting</div>
</div>
<div class="author">
      <div class="author-name">A. Cabellos, <span class="editor">Ed.</span>
</div>
<div class="org">Universitat Politecnica de Catalunya</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9301</h1>
<h1 id="title">Locator/ID Separation Protocol (LISP) Control Plane</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1"> This document describes the 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 provide a simplified "front end" for one
    or more Endpoint IDs (EIDs) to Routing Locator mapping databases.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
<p id="section-abstract-2">By using this 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; this behavior facilitates modularity
    with different database designs.  Since these devices implement the "edge" of the
    LISP control plane infrastructure, connecting EID addressable nodes
    of a LISP site, the implementation and operational complexity of the
      overall cost and effort of deploying LISP is reduced.<a href="#section-abstract-2" class="pilcrow">¶</a></p>
<p id="section-abstract-3">This document obsoletes RFCs 6830 and 6833.<a href="#section-abstract-3" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This is an Internet Standards Track document.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="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.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="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
            <span><a href="https://www.rfc-editor.org/info/rfc9301">https://www.rfc-editor.org/info/rfc9301</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2022 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) 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.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="auto internal xref">1</a>.  <a href="#name-introduction" class="internal xref">Introduction</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.1">
                <p id="section-toc.1-1.1.2.1.1" class="keepWithNext"><a href="#section-1.1" class="auto internal xref">1.1</a>.  <a href="#name-scope-of-applicability" class="internal xref">Scope of Applicability</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="auto internal xref">2</a>.  <a href="#name-requirements-notation" class="internal xref">Requirements Notation</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="auto internal xref">3</a>.  <a href="#name-definitions-of-terms" class="internal xref">Definitions of Terms</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="auto internal xref">4</a>.  <a href="#name-basic-overview" class="internal xref">Basic Overview</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="auto internal xref">5</a>.  <a href="#name-lisp-ipv4-and-ipv6-control-" class="internal xref">LISP IPv4 and IPv6 Control Plane Packet Formats</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.1">
                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="auto internal xref">5.1</a>.  <a href="#name-lisp-control-packet-type-al" class="internal xref">LISP Control Packet Type Allocations</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.2">
                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="auto internal xref">5.2</a>.  <a href="#name-map-request-message-format" class="internal xref">Map-Request Message Format</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.3">
                <p id="section-toc.1-1.5.2.3.1"><a href="#section-5.3" class="auto internal xref">5.3</a>.  <a href="#name-eid-to-rloc-udp-map-request" class="internal xref">EID-to-RLOC UDP Map-Request Message</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.4">
                <p id="section-toc.1-1.5.2.4.1"><a href="#section-5.4" class="auto internal xref">5.4</a>.  <a href="#name-map-reply-message-format" class="internal xref">Map-Reply Message Format</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.5">
                <p id="section-toc.1-1.5.2.5.1"><a href="#section-5.5" class="auto internal xref">5.5</a>.  <a href="#name-eid-to-rloc-udp-map-reply-m" class="internal xref">EID-to-RLOC UDP Map-Reply Message</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.6">
                <p id="section-toc.1-1.5.2.6.1"><a href="#section-5.6" class="auto internal xref">5.6</a>.  <a href="#name-map-register-message-format" class="internal xref">Map-Register Message Format</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.7">
                <p id="section-toc.1-1.5.2.7.1"><a href="#section-5.7" class="auto internal xref">5.7</a>.  <a href="#name-map-notify-and-map-notify-a" class="internal xref">Map-Notify and Map-Notify-Ack Message Formats</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.8">
                <p id="section-toc.1-1.5.2.8.1"><a href="#section-5.8" class="auto internal xref">5.8</a>.  <a href="#name-encapsulated-control-messag" class="internal xref">Encapsulated Control Message Format</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="auto internal xref">6</a>.  <a href="#name-changing-the-contents-of-ei" class="internal xref">Changing the Contents of EID-to-RLOC Mappings</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.1">
                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="auto internal xref">6.1</a>.  <a href="#name-solicit-map-request-smr" class="internal xref">Solicit-Map-Request (SMR)</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="auto internal xref">7</a>.  <a href="#name-routing-locator-reachabilit" class="internal xref">Routing Locator Reachability</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.1">
                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="auto internal xref">7.1</a>.  <a href="#name-rloc-probing-algorithm" class="internal xref">RLOC-Probing Algorithm</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="auto internal xref">8</a>.  <a href="#name-interactions-with-other-lis" class="internal xref">Interactions with Other LISP Components</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.1">
                <p id="section-toc.1-1.8.2.1.1"><a href="#section-8.1" class="auto internal xref">8.1</a>.  <a href="#name-itr-eid-to-rloc-mapping-res" class="internal xref">ITR EID-to-RLOC Mapping Resolution</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.2">
                <p id="section-toc.1-1.8.2.2.1"><a href="#section-8.2" class="auto internal xref">8.2</a>.  <a href="#name-eid-prefix-configuration-an" class="internal xref">EID-Prefix Configuration and ETR Registration</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.3">
                <p id="section-toc.1-1.8.2.3.1"><a href="#section-8.3" class="auto internal xref">8.3</a>.  <a href="#name-map-server-processing" class="internal xref">Map-Server Processing</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.4">
                <p id="section-toc.1-1.8.2.4.1"><a href="#section-8.4" class="auto internal xref">8.4</a>.  <a href="#name-map-resolver-processing" class="internal xref">Map-Resolver Processing</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.4.2.1">
                    <p id="section-toc.1-1.8.2.4.2.1.1"><a href="#section-8.4.1" class="auto internal xref">8.4.1</a>.  <a href="#name-anycast-operation" class="internal xref">Anycast Operation</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="auto internal xref">9</a>.  <a href="#name-security-considerations" class="internal xref">Security Considerations</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-10" class="auto internal xref">10</a>. <a href="#name-privacy-considerations" class="internal xref">Privacy Considerations</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-11" class="auto internal xref">11</a>. <a href="#name-changes-related-to-rfcs-683" class="internal xref">Changes Related to RFCs 6830 and 6833</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#section-12" class="auto internal xref">12</a>. <a href="#name-iana-considerations" class="internal xref">IANA Considerations</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12.2.1">
                <p id="section-toc.1-1.12.2.1.1"><a href="#section-12.1" class="auto internal xref">12.1</a>.  <a href="#name-lisp-udp-port-numbers" class="internal xref">LISP UDP Port Numbers</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12.2.2">
                <p id="section-toc.1-1.12.2.2.1"><a href="#section-12.2" class="auto internal xref">12.2</a>.  <a href="#name-lisp-packet-type-codes" class="internal xref">LISP Packet Type Codes</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12.2.3">
                <p id="section-toc.1-1.12.2.3.1"><a href="#section-12.3" class="auto internal xref">12.3</a>.  <a href="#name-lisp-map-reply-eid-record-a" class="internal xref">LISP Map-Reply EID-Record Action Codes</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12.2.4">
                <p id="section-toc.1-1.12.2.4.1"><a href="#section-12.4" class="auto internal xref">12.4</a>.  <a href="#name-lisp-address-type-codes" class="internal xref">LISP Address Type Codes</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12.2.5">
                <p id="section-toc.1-1.12.2.5.1"><a href="#section-12.5" class="auto internal xref">12.5</a>.  <a href="#name-lisp-algorithm-id-numbers" class="internal xref">LISP Algorithm ID Numbers</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12.2.6">
                <p id="section-toc.1-1.12.2.6.1"><a href="#section-12.6" class="auto internal xref">12.6</a>.  <a href="#name-lisp-bit-flags" class="internal xref">LISP Bit Flags</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#section-13" class="auto internal xref">13</a>. <a href="#name-references" class="internal xref">References</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.13.2.1">
                <p id="section-toc.1-1.13.2.1.1"><a href="#section-13.1" class="auto internal xref">13.1</a>.  <a href="#name-normative-references" class="internal xref">Normative References</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.13.2.2">
                <p id="section-toc.1-1.13.2.2.1"><a href="#section-13.2" class="auto internal xref">13.2</a>.  <a href="#name-informative-references" class="internal xref">Informative References</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.14">
            <p id="section-toc.1-1.14.1"><a href="#appendix-A" class="auto internal xref"></a><a href="#name-acknowledgments" class="internal xref">Acknowledgments</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.15">
            <p id="section-toc.1-1.15.1"><a href="#appendix-B" class="auto internal xref"></a><a href="#name-authors-addresses" class="internal xref">Authors' Addresses</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">The Locator/ID Separation Protocol <span>[<a href="#RFC9300" class="cite xref">RFC9300</a>]</span> (see also <span>[<a href="#RFC9299" class="cite xref">RFC9299</a>]</span>) specifies an architecture
    and mechanism for dynamic tunneling by logically separating the
    addresses currently used by IP in two separate 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 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) <span>[<a href="#RFC6837" class="cite xref">RFC6837</a>]</span>, LISP Alternative Logical
    Topology (LISP-ALT) <span>[<a href="#RFC6836" class="cite xref">RFC6836</a>]</span>, and LISP Delegated
    Database Tree (LISP-DDT) <span>[<a href="#RFC8111" class="cite xref">RFC8111</a>]</span>.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="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.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3"> This LISP control plane and Mapping Service can be used by many
    different encapsulation-based or translation-based data planes, including
    but not limited to those defined in LISP
    <span>[<a href="#RFC9300" class="cite xref">RFC9300</a>]</span>, the LISP Generic Protocol Extension (LISP-GPE) <span>[<a href="#RFC9305" class="cite xref">RFC9305</a>]</span>, Virtual eXtensible Local Area Networks (VXLANs) <span>[<a href="#RFC7348" class="cite xref">RFC7348</a>]</span>,
    VXLAN-GPE <span>[<a href="#NVO3-VXLAN-GPE" class="cite xref">NVO3-VXLAN-GPE</a>]</span>,
    GRE <span>[<a href="#RFC2890" class="cite xref">RFC2890</a>]</span>, the GPRS Tunneling Protocol (GTP) <span>[<a href="#GTP-3GPP" class="cite xref">GTP-3GPP</a>]</span>,
    Identifier-Locator Addressing (ILA) <span>[<a href="#I-D.herbert-intarea-ila" class="cite xref">INTAREA-ILA</a>]</span>, and Segment Routing (SRv6)
    <span>[<a href="#RFC8402" class="cite xref">RFC8402</a>]</span>.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4"> Conceptually, LISP Map-Servers share some of the same basic
    configuration and maintenance properties as Domain Name System
    (DNS) servers <span>[<a href="#RFC1035" class="cite xref">RFC1035</a>]</span>; 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.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="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 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.<a href="#section-1-5" class="pilcrow">¶</a></p>
<p id="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 
<span><a href="https://www.rfc-editor.org/rfc/rfc9300#section-1.1" class="relref">Section 1.1</a> of [<a href="#RFC9300" class="cite xref">RFC9300</a>]</span>.<a href="#section-1-6" class="pilcrow">¶</a></p>
<p id="section-1-7">This document obsoletes <span>[<a href="#RFC6830" class="cite xref">RFC6830</a>]</span> and <span>[<a href="#RFC6833" class="cite xref">RFC6833</a>]</span>.<a href="#section-1-7" class="pilcrow">¶</a></p>
<div id="soa">
<section id="section-1.1">
        <h3 id="name-scope-of-applicability">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-scope-of-applicability" class="section-name selfRef">Scope of Applicability</a>
        </h3>
<p id="section-1.1-1">LISP was originally developed to address the Internet-wide
      route scaling problem <span>[<a href="#RFC4984" class="cite xref">RFC4984</a>]</span>.  While there
      are a number of approaches of interest for that problem, as LISP
      has been developed and refined, a large number of other uses for LISP have
      been found and are being implemented.  As such, the design and
      development of LISP have changed so as to focus on these use
      cases.  The common property of these uses is a large set of
      cooperating entities seeking to communicate over the public
      Internet or other large underlay IP infrastructures while
      keeping the addressing and topology of the cooperating entities
      separate from the underlay and Internet topology, routing, and
      addressing.<a href="#section-1.1-1" class="pilcrow">¶</a></p>
<p id="section-1.1-2">When communicating over the public Internet, deployers <span class="bcp14">MUST</span> consider
        the following guidelines:<a href="#section-1.1-2" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-1.1-3">
   <li id="section-1.1-3.1">LISP Security (LISP-SEC) <span class="bcp14">MUST</span> be implemented <span>[<a href="#RFC9303" class="cite xref">RFC9303</a>]</span>. This means that the S-bit <span class="bcp14">MUST</span> be set in the Map-Reply (<a href="#MR-FORMAT" class="auto internal xref">Section 5.4</a>), Map-Register (<a href="#MAPREG" class="auto internal xref">Section 5.6</a>), and Encapsulated Control Messages (ECMs) (<a href="#encap-mr" class="auto internal xref">Section 5.8</a>).<a href="#section-1.1-3.1" class="pilcrow">¶</a>
</li>
          <li id="section-1.1-3.2">Implementations <span class="bcp14">SHOULD</span> use 'HMAC-SHA256-128+HKDF-SHA256'
          as the Algorithm ID (<a href="#KEYS" class="auto internal xref">Section 12.5</a>)
          in the Map-Register message (<a href="#MAPREG" class="auto internal xref">Section 5.6</a>) and <span class="bcp14">MUST NOT</span> use 'None' or 'HMAC-SHA-1-96-None' as the Algorithm ID (<a href="#KEYS" class="auto internal xref">Section 12.5</a>) in the Map-Register message (<a href="#MAPREG" class="auto internal xref">Section 5.6</a>).<a href="#section-1.1-3.2" class="pilcrow">¶</a>
</li>
        </ol>
</section>
</div>
</section>
<section id="section-2">
      <h2 id="name-requirements-notation">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-requirements-notation" class="section-name selfRef">Requirements Notation</a>
      </h2>
<p id="section-2-1">
    The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>", "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>", "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
    "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document are to be interpreted as
    described in BCP 14 <span>[<a href="#RFC2119" class="cite xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="cite xref">RFC8174</a>]</span> 
    when, and only when, they appear in all capitals, as shown here.<a href="#section-2-1" class="pilcrow">¶</a></p>
</section>
<section id="section-3">
      <h2 id="name-definitions-of-terms">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-definitions-of-terms" class="section-name selfRef">Definitions of Terms</a>
      </h2>
<span class="break"></span><dl class="dlParallel" id="section-3-1">
        <dt id="section-3-1.1">Map-Server: </dt>
        <dd style="margin-left: 1.5em" id="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.<a href="#section-3-1.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-1.3">Map-Request: </dt>
        <dd style="margin-left: 1.5em" id="section-3-1.4">A control plane message that queries the 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.<a href="#section-3-1.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-1.5">Map-Reply: </dt>
        <dd style="margin-left: 1.5em" id="section-3-1.6">A control plane
      message returned in response to a Map-Request sent to the Mapping
      System when resolving an EID. A LISP Map-Reply can also be returned by
      a decapsulator in response to a Map-Request sent by an encapsulator
      to test for reachability. This type of Map-Reply is known as an RLOC-Probe
      Reply.<a href="#section-3-1.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-1.7">Encapsulated Map-Request: </dt>
        <dd style="margin-left: 1.5em" id="section-3-1.8">A LISP Map-Request
      carried within an 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.<a href="#section-3-1.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-1.9">Map-Resolver: </dt>
        <dd style="margin-left: 1.5em" id="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.<a href="#section-3-1.10" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-1.11">Negative Map-Reply: </dt>
        <dd style="margin-left: 1.5em" id="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, is policy-denied, or fails authentication.<a href="#section-3-1.12" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-1.13">Map-Register message: </dt>
        <dd style="margin-left: 1.5em" id="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 (reformatted as
      Encapsulated Map-Requests).  An ETR <span class="bcp14">MAY</span> request that the
      Map-Server answer Map-Requests on its behalf by setting the
      "proxy Map-Reply" flag (P-bit) in the message.<a href="#section-3-1.14" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-1.15">Map-Notify message: </dt>
        <dd style="margin-left: 1.5em" id="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.<a href="#section-3-1.16" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="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 specification
    <span>[<a href="#RFC9300" class="cite xref">RFC9300</a>]</span>.<a href="#section-3-2" class="pilcrow">¶</a></p>
</section>
<div id="OVERVIEW">
<section id="section-4">
      <h2 id="name-basic-overview">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-basic-overview" class="section-name selfRef">Basic Overview</a>
      </h2>
<p id="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 (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.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2"> When LISP-ALT <span>[<a href="#RFC6836" class="cite xref">RFC6836</a>]</span> 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.<a href="#section-4-2" class="pilcrow">¶</a></p>
<p id="section-4-3"> When LISP-DDT <span>[<a href="#RFC8111" class="cite xref">RFC8111</a>]</span> is used as
    the mapping database, a Map-Server sends the final Map-Referral
    messages from the Delegated Database Tree.<a href="#section-4-3" class="pilcrow">¶</a></p>
<p id="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 <span>[<a href="#RFC8111" class="cite xref">RFC8111</a>]</span>, a
    Map-Resolver maintains a referral cache and acts as a "first-hop"
    DDT node. The Map-Resolver uses the referral information to
    forward Map-Requests.<a href="#section-4-4" class="pilcrow">¶</a></p>
<p id="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 would be
    reliable and practical. In this specification, Map-Resolvers will
    operate only in a non-caching mode, decapsulating and forwarding
    Encapsulated Map-Requests received from ITRs.  Any specification
    of caching functionality is out of scope for this document.<a href="#section-4-5" class="pilcrow">¶</a></p>
<p id="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, 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, connecting Map-Resolvers and Map-Servers together to
    make up the Mapping System.<a href="#section-4-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="lispcp">
<section id="section-5">
      <h2 id="name-lisp-ipv4-and-ipv6-control-">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-lisp-ipv4-and-ipv6-control-" class="section-name selfRef">LISP IPv4 and IPv6 Control Plane Packet Formats</a>
      </h2>
<p id="section-5-1">The following UDP packet formats are used by the LISP
      control plane.<a href="#section-5-1" class="pilcrow">¶</a></p>
<span id="name-ipv4-udp-lisp-control-messa"></span><figure id="figure-1">
        <div class="alignLeft art-text artwork" id="section-5-2.1">
<pre>
     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                          |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-ipv4-udp-lisp-control-messa" class="selfRef">IPv4 UDP LISP Control Message</a>
        </figcaption></figure>
<span id="name-ipv6-udp-lisp-control-messa"></span><figure id="figure-2">
        <div class="alignLeft art-text artwork" id="section-5-3.1">
<pre>
     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                          |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-ipv6-udp-lisp-control-messa" class="selfRef">IPv6 UDP LISP Control Message</a>
        </figcaption></figure>
<p id="section-5-4">When a UDP Map-Request, Map-Register, or 
      Map-Notify (when used
    as a notification message) is sent, the UDP source port is chosen
    by the sender and the destination UDP port number is set to
    4342. When a UDP Map-Reply, Map-Notify (when used as an
    acknowledgment to a Map-Register), or Map-Notify-Ack 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 <span class="bcp14">MUST</span> 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.<a href="#section-5-4" class="pilcrow">¶</a></p>
<p id="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 <span class="bcp14">MUST</span> be limited to 576 bytes
 for IPv4 or 1280 bytes for IPv6 -- considering the entire IP packet -- as outlined in <span>[<a href="#RFC8085" class="cite xref">RFC8085</a>]</span>.<a href="#section-5-5" class="pilcrow">¶</a></p>
<p id="section-5-6">The UDP checksum is computed and set to non-zero for all
    messages sent to or from port 4342.  It <span class="bcp14">MUST</span> be checked on
    receipt, and if the checksum fails, the control message <span class="bcp14">MUST</span> be
    dropped <span>[<a href="#RFC1071" class="cite xref">RFC1071</a>]</span>.<a href="#section-5-6" class="pilcrow">¶</a></p>
<p id="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.<a href="#section-5-7" class="pilcrow">¶</a></p>
<section id="section-5.1">
        <h3 id="name-lisp-control-packet-type-al">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-lisp-control-packet-type-al" class="section-name selfRef">LISP Control Packet Type Allocations</a>
        </h3>
<p id="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 <span>[<a href="#RFC9304" class="cite xref">RFC9304</a>]</span>.  Message type definitions
      are:<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<table class="center" id="table-1">
          <caption><a href="#table-1" class="selfRef">Table 1</a></caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Message</th>
              <th class="text-left" rowspan="1" colspan="1">Code</th>
              <th class="text-left" rowspan="1" colspan="1">Codepoint</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Reserved</td>
              <td class="text-left" rowspan="1" colspan="1">0</td>
              <td class="text-left" rowspan="1" colspan="1">b'0000'</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">LISP Map-Request</td>
              <td class="text-left" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1">b'0001'</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">LISP Map-Reply</td>
              <td class="text-left" rowspan="1" colspan="1">2</td>
              <td class="text-left" rowspan="1" colspan="1">b'0010'</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">LISP Map-Register</td>
              <td class="text-left" rowspan="1" colspan="1">3</td>
              <td class="text-left" rowspan="1" colspan="1">b'0011'</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">LISP Map-Notify</td>
              <td class="text-left" rowspan="1" colspan="1">4</td>
              <td class="text-left" rowspan="1" colspan="1">b'0100'</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">LISP Map-Notify-Ack</td>
              <td class="text-left" rowspan="1" colspan="1">5</td>
              <td class="text-left" rowspan="1" colspan="1">b'0101'</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">LISP DDT Map-Referral</td>
              <td class="text-left" rowspan="1" colspan="1">6</td>
              <td class="text-left" rowspan="1" colspan="1">b'0110'</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Unassigned</td>
              <td class="text-left" rowspan="1" colspan="1">7</td>
              <td class="text-left" rowspan="1" colspan="1">b'0111'</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">LISP Encapsulated Control Message</td>
              <td class="text-left" rowspan="1" colspan="1">8</td>
              <td class="text-left" rowspan="1" colspan="1">b'1000'</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Unassigned</td>
              <td class="text-left" rowspan="1" colspan="1">9-14</td>
              <td class="text-left" rowspan="1" colspan="1">b'1001'- b'1110'</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">LISP Shared Extension Message</td>
              <td class="text-left" rowspan="1" colspan="1">15</td>
              <td class="text-left" rowspan="1" colspan="1">b'1111'</td>
            </tr>
          </tbody>
        </table>
<p id="section-5.1-3">Protocol designers experimenting with new message formats are
      recommended to use the LISP Shared Extension Message Type described
      in <span>[<a href="#RFC9304" class="cite xref">RFC9304</a>]</span>.<a href="#section-5.1-3" class="pilcrow">¶</a></p>
<p id="section-5.1-4">All LISP control plane messages use Address Family
      Identifiers (AFIs) <span>[<a href="#AFN" class="cite xref">AFN</a>]</span> or LISP Canonical Address
      Format (LCAF) entries <span>[<a href="#RFC8060" class="cite xref">RFC8060</a>]</span> to encode either
      fixed-length or variable-length addresses. This includes explicit
      fields in each control message or part of EID-Records or
      RLOC-Records in commonly formatted messages. LISP control plane
      messages that include an unrecognized AFI <span class="bcp14">MUST</span> be
      dropped, and the event <span class="bcp14">MUST</span> be logged.<a href="#section-5.1-4" class="pilcrow">¶</a></p>
<p id="section-5.1-5">The LISP control plane describes how other data planes can
      encode messages to support the soliciting of Map-Requests as well as
      RLOC-Probing procedures.<a href="#section-5.1-5" class="pilcrow">¶</a></p>
</section>
<div id="NONCE">
<section id="section-5.2">
        <h3 id="name-map-request-message-format">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-map-request-message-format" class="section-name selfRef">Map-Request Message Format</a>
        </h3>
<div class="alignLeft art-text artwork" id="section-5.2-1">
<pre>
     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  ...                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre><a href="#section-5.2-1" class="pilcrow">¶</a>
</div>
<p id="section-5.2-2">Packet field descriptions:<a href="#section-5.2-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-5.2-3">
          <dt id="section-5.2-3.1">Type: </dt>
          <dd style="margin-left: 1.5em" id="section-5.2-3.2">1 (Map-Request)<a href="#section-5.2-3.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.2-3.3">A:</dt>
          <dd style="margin-left: 1.5em" id="section-5.2-3.4">This is an authoritative bit. It is set to 1
        when an ITR wants the destination site to return the Map-Reply
        rather than the mapping database system returning a Map-Reply and
        is set to 0 otherwise.<a href="#section-5.2-3.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.2-3.5">M:</dt>
          <dd style="margin-left: 1.5em" id="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.<a href="#section-5.2-3.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.2-3.7">P:</dt>
          <dd style="margin-left: 1.5em" id="section-5.2-3.8">This is the probe-bit, which indicates that a
        Map-Request <span class="bcp14">MUST</span> be treated as a Locator reachability
        probe. The receiver <span class="bcp14">MUST</span> 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
        "<a href="#rloc-probe" class="internal xref">RLOC-Probing Algorithm</a>" (<a href="#rloc-probe" class="auto internal xref">Section 7.1</a>) for
        more details. This RLOC-Probe Map-Request <span class="bcp14">MUST NOT</span> be sent to
        the Mapping System. If a Map-Resolver or Map-Server receives a
        Map-Request with the probe-bit set, it <span class="bcp14">MUST</span> drop the message.<a href="#section-5.2-3.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.2-3.9">S:</dt>
          <dd style="margin-left: 1.5em" id="section-5.2-3.10"> This is the Solicit-Map-Request (SMR)
        bit. See "<a href="#SMR" class="internal xref">Solicit-Map-Request (SMR)</a>" (<a href="#SMR" class="auto internal xref">Section 6.1</a>) for
        details.<a href="#section-5.2-3.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.2-3.11">p:</dt>
          <dd style="margin-left: 1.5em" id="section-5.2-3.12"> This is the 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.<a href="#section-5.2-3.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.2-3.13">s:</dt>
          <dd style="margin-left: 1.5em" id="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.<a href="#section-5.2-3.14" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.2-3.15">R:</dt>
          <dd style="margin-left: 1.5em" id="section-5.2-3.16">This reserved and unassigned bit <span class="bcp14">MUST</span> be set to 0 on
        transmit and <span class="bcp14">MUST</span> be ignored on receipt.<a href="#section-5.2-3.16" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.2-3.17">Rsvd:</dt>
          <dd style="margin-left: 1.5em" id="section-5.2-3.18">This field <span class="bcp14">MUST</span> be set to 0 on transmit
        and <span class="bcp14">MUST</span> be ignored on receipt.<a href="#section-5.2-3.18" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.2-3.19">L:</dt>
          <dd style="margin-left: 1.5em" id="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 for the LISP site. The L-bit is set to
        1 when the RLOC is the sender's IP address.<a href="#section-5.2-3.20" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.2-3.21">D:</dt>
          <dd style="margin-left: 1.5em" id="section-5.2-3.22"> This is the dont-map-reply bit. It is used
        in the SMR procedure described in <a href="#SMR" class="auto internal xref">Section 6.1</a>. 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.<a href="#section-5.2-3.22" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.2-3.23">IRC:</dt>
          <dd style="margin-left: 1.5em" id="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) pair <span class="bcp14">MUST</span> 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.<a href="#section-5.2-3.24" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.2-3.25">Record Count:</dt>
          <dd style="margin-left: 1.5em" id="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 <span class="bcp14">MUST</span> accept and process Map-Requests
        that contain one or more records, but a sender <span class="bcp14">MUST</span> only send
        Map-Requests containing one record.<a href="#section-5.2-3.26" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.2-3.27">Nonce:</dt>
          <dd style="margin-left: 1.5em" id="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 <span class="bcp14">MUST</span> be generated by a
        properly seeded pseudo-random source; for example, see
        <span>[<a href="#RFC4086" class="cite xref">RFC4086</a>]</span>.<a href="#section-5.2-3.28" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.2-3.29">Source-EID-AFI:</dt>
          <dd style="margin-left: 1.5em" id="section-5.2-3.30"> This is the address family of
        the 'Source EID Address' field.<a href="#section-5.2-3.30" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.2-3.31">Source EID Address:</dt>
          <dd style="margin-left: 1.5em" id="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,
        and this field is of zero length.<a href="#section-5.2-3.32" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.2-3.33">ITR-RLOC-AFI:</dt>
          <dd style="margin-left: 1.5em" id="section-5.2-3.34"> This is the address family of the
        'ITR-RLOC Address' field that follows this field.<a href="#section-5.2-3.34" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.2-3.35">ITR-RLOC Address:</dt>
          <dd style="margin-left: 1.5em" id="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 <span class="bcp14">MUST</span> be
        a routable RLOC address of the sender of the Map-Request
        message.<a href="#section-5.2-3.36" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.2-3.37">EID mask-len:</dt>
          <dd style="margin-left: 1.5em" id="section-5.2-3.38"> This is the mask length for the
        EID-Prefix.<a href="#section-5.2-3.38" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.2-3.39">EID-Prefix-AFI:</dt>
          <dd style="margin-left: 1.5em" id="section-5.2-3.40"> This is the address family of
        the EID-Prefix according to <span>[<a href="#AFN" class="cite xref">AFN</a>]</span> and <span>[<a href="#RFC8060" class="cite xref">RFC8060</a>]</span>.<a href="#section-5.2-3.40" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.2-3.41">EID-Prefix:</dt>
          <dd style="margin-left: 1.5em" id="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 <span>[<a href="#AFN" class="cite xref">AFN</a>]</span>, the address
        length varies, and for the LCAF AFI, the format is defined in
        <span>[<a href="#RFC8060" class="cite xref">RFC8060</a>]</span>.  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 as the EID-Prefix
        returned from the site when it sent a Map-Reply message.<a href="#section-5.2-3.42" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.2-3.43">Map-Reply Record:</dt>
          <dd style="margin-left: 1.5em" id="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 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.<a href="#section-5.2-3.44" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="MAPREQ">
<section id="section-5.3">
        <h3 id="name-eid-to-rloc-udp-map-request">
<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-eid-to-rloc-udp-map-request" class="section-name selfRef">EID-to-RLOC UDP Map-Request Message</a>
        </h3>
<p id="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 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.<a href="#section-5.3-1" class="pilcrow">¶</a></p>
<p id="section-5.3-2">One or more Map-Request ('ITR-RLOC-AFI', 'ITR-RLOC Address')
      fields <span class="bcp14">MUST</span> be filled in by the ITR. The number of fields (minus
      1) encoded <span class="bcp14">MUST</span> be placed in the 'IRC' field. The ITR <span class="bcp14">MAY</span>
      include all locally configured Locators in this list or just
      provide one Routing Locator Address from each address family it
      supports. If the ITR erroneously provides no ITR-RLOC addresses,
      the Map-Replier <span class="bcp14">MUST</span> drop the Map-Request.<a href="#section-5.3-2" class="pilcrow">¶</a></p>
<p id="section-5.3-3">Map-Requests can also be LISP encapsulated using UDP
      destination 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 <a href="#encap-mr" class="auto internal xref">Section 5.8</a>.<a href="#section-5.3-3" class="pilcrow">¶</a></p>
<p id="section-5.3-4">Map-Requests <span class="bcp14">MUST</span> be rate limited to 1 per second per EID-Prefix.
      After 10 retransmits without receiving the corresponding Map-Reply, the sender <span class="bcp14">MUST</span> wait 30 seconds.<a href="#section-5.3-4" class="pilcrow">¶</a></p>
<p id="section-5.3-5">An ITR that is configured with mapping database information
      (i.e., it is also an ETR) <span class="bcp14">MAY</span> 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 <span class="bcp14">MUST</span> originate
      a "verifying Map-Request" through the mapping database to validate
      the "piggybacked" mapping data.<a href="#section-5.3-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="MR-FORMAT">
<section id="section-5.4">
        <h3 id="name-map-reply-message-format">
<a href="#section-5.4" class="section-number selfRef">5.4. </a><a href="#name-map-reply-message-format" class="section-name selfRef">Map-Reply Message Format</a>
        </h3>
<div class="alignLeft art-text artwork" id="section-5.4-1">
<pre>
     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; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre><a href="#section-5.4-1" class="pilcrow">¶</a>
</div>
<p id="section-5.4-2">Packet field descriptions:<a href="#section-5.4-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-5.4-3">
          <dt id="section-5.4-3.1">Type: </dt>
          <dd style="margin-left: 1.5em" id="section-5.4-3.2">2 (Map-Reply)<a href="#section-5.4-3.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.4-3.3">P:</dt>
          <dd style="margin-left: 1.5em" id="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 
        "<a href="#rloc-probe" class="internal xref">RLOC-Probing Algorithm</a>" (<a href="#rloc-probe" class="auto internal xref">Section 7.1</a>) for more details. When the
        probe-bit is set to 1 in a Map-Reply message, the A-bit in
        each EID-Record included in the message <span class="bcp14">MUST</span> be set to 1;
        otherwise, it <span class="bcp14">MUST</span> be silently discarded.<a href="#section-5.4-3.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.4-3.5">E:</dt>
          <dd style="margin-left: 1.5em" id="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
Section <span><a href="https://www.rfc-editor.org/rfc/rfc9300#section-10.1" class="relref">10.1</a> (<a href="https://www.rfc-editor.org/rfc/rfc9300#section-10.1" class="relref">"Echo-Nonce Algorithm"</a>)</span> of <span>[<a href="#RFC9300" class="cite xref">RFC9300</a>]</span> for more
        details.<a href="#section-5.4-3.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.4-3.7">S:</dt>
          <dd style="margin-left: 1.5em" id="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. Details can be found in <span>[<a href="#RFC9303" class="cite xref">RFC9303</a>]</span>.<a href="#section-5.4-3.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<div class="alignLeft art-text artwork" id="section-5.4-4">
<pre>
 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 . . .       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre><a href="#section-5.4-4" class="pilcrow">¶</a>
</div>
<span class="break"></span><dl class="dlParallel" id="section-5.4-5">
          <dt id="section-5.4-5.1">Reserved:</dt>
          <dd style="margin-left: 1.5em" id="section-5.4-5.2"> This unassigned field <span class="bcp14">MUST</span> be set to 0 on
        transmit and <span class="bcp14">MUST</span> be ignored on receipt.<a href="#section-5.4-5.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.4-5.3">Record Count:</dt>
          <dd style="margin-left: 1.5em" id="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, when more-specific prefixes are present.<a href="#section-5.4-5.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.4-5.5">Nonce:</dt>
          <dd style="margin-left: 1.5em" id="section-5.4-5.6"> This 64-bit value from the Map-Request
        is echoed in this 'Nonce' field of the Map-Reply.<a href="#section-5.4-5.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.4-5.7">Record TTL:</dt>
          <dd style="margin-left: 1.5em" id="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 <span class="bcp14">MUST</span> be removed from the cache immediately.
        If the value is 0xffffffff, the recipient can decide locally
        how long to store the mapping.<a href="#section-5.4-5.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.4-5.9">Locator Count:</dt>
          <dd style="margin-left: 1.5em" id="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
        'Loc'. The Locator count can be 0, indicating that
        there are no Locators for the EID-Prefix.<a href="#section-5.4-5.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.4-5.11">EID mask-len:</dt>
          <dd style="margin-left: 1.5em" id="section-5.4-5.12"> This is the mask length for the
        EID-Prefix.<a href="#section-5.4-5.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.4-5.13">ACT:</dt>
          <dd style="margin-left: 1.5em" id="section-5.4-5.14">
            <p id="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 an empty Locator-Set was returned from the
        Mapping System and how it stores the Map-Cache entry.
        See <a href="#act-iana" class="auto internal xref">Section 12.3</a> for additional information.<a href="#section-5.4-5.14.1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-5.4-5.14.2">
              <dt id="section-5.4-5.14.2.1">(0) No-Action:</dt>
              <dd style="margin-left: 2.0em" id="section-5.4-5.14.2.2">The Map-Cache is kept alive,
          and no packet encapsulation occurs.<a href="#section-5.4-5.14.2.2" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-5.4-5.14.2.3">(1) Natively-Forward:</dt>
              <dd style="margin-left: 2.0em" id="section-5.4-5.14.2.4">The packet is not
          encapsulated or dropped but natively forwarded.<a href="#section-5.4-5.14.2.4" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-5.4-5.14.2.5">(2) Send-Map-Request:</dt>
              <dd style="margin-left: 2.0em" id="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.<a href="#section-5.4-5.14.2.6" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-5.4-5.14.2.7">(3) Drop/No-Reason:</dt>
              <dd style="margin-left: 2.0em" id="section-5.4-5.14.2.8">A packet that matches this
          Map-Cache entry is dropped. An ICMP Destination Unreachable
          message <span class="bcp14">SHOULD</span> be sent.<a href="#section-5.4-5.14.2.8" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-5.4-5.14.2.9">(4) Drop/Policy-Denied:</dt>
              <dd style="margin-left: 2.0em" id="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 is being
       policy-denied by either an xTR or the Mapping System.<a href="#section-5.4-5.14.2.10" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-5.4-5.14.2.11">(5) Drop/Auth-Failure:</dt>
              <dd style="margin-left: 2.0em" id="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 fails
       an authentication verification check by either an xTR or the
       Mapping System.<a href="#section-5.4-5.14.2.12" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
</dd>
          <dd class="break"></dd>
<dt id="section-5.4-5.15">A:</dt>
          <dd style="margin-left: 1.5em" id="section-5.4-5.16"> The Authoritative bit <span class="bcp14">MAY</span> only be set to 1 by an ETR.
        A Map-Server generating Map-Reply messages as a proxy <span class="bcp14">MUST NOT</span> 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.<a href="#section-5.4-5.16" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.4-5.17">Map-Version Number:</dt>
          <dd style="margin-left: 1.5em" id="section-5.4-5.18"> When this 12-bit value in an EID-Record of a
          Map-Reply message is non-zero, see <span>[<a href="#RFC9302" class="cite xref">RFC9302</a>]</span> for details.<a href="#section-5.4-5.18" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.4-5.19">EID-Prefix-AFI:</dt>
          <dd style="margin-left: 1.5em" id="section-5.4-5.20">This is the address family of the
        EID-Prefix according to <span>[<a href="#AFN" class="cite xref">AFN</a>]</span> and <span>[<a href="#RFC8060" class="cite xref">RFC8060</a>]</span>.<a href="#section-5.4-5.20" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.4-5.21">EID-Prefix:</dt>
          <dd style="margin-left: 1.5em" id="section-5.4-5.22"> This prefix is 4 octets for an IPv4
        address family and 16 octets for an IPv6 address family.<a href="#section-5.4-5.22" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.4-5.23">Priority:</dt>
          <dd style="margin-left: 1.5em" id="section-5.4-5.24"> Each RLOC is assigned a unicast
        Priority.  Lower values are preferable. When multiple
        RLOCs have the same Priority, they may be used in a load-split
        fashion.  A value of 255 means the RLOC <span class="bcp14">MUST NOT</span> be used for
        unicast forwarding.<a href="#section-5.4-5.24" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.4-5.25">Weight:</dt>
          <dd style="margin-left: 1.5em" id="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 second and third Locators will
        each get 25% of the traffic, and the fourth Locator will get 12.5% of
        the traffic. If all Weights for a Locator-Set are equal, the
        receiver of the Map-Reply will decide how to load-split the
        traffic. See Section <span><a href="https://www.rfc-editor.org/rfc/rfc9300#section-12" class="relref">12</a> (<a href="https://www.rfc-editor.org/rfc/rfc9300#section-12" class="relref">"Routing Locator Hashing"</a>)</span> of <span>[<a href="#RFC9300" class="cite xref">RFC9300</a>]</span> for a suggested hash
        algorithm to distribute the load across Locators with the same
        Priority and equal Weight values.<a href="#section-5.4-5.26" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.4-5.27">M Priority:</dt>
          <dd style="margin-left: 1.5em" id="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 <span class="bcp14">MUST NOT</span> be
        used for joining a multicast distribution tree.  For more
        details, see <span>[<a href="#RFC6831" class="cite xref">RFC6831</a>]</span>.<a href="#section-5.4-5.28" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.4-5.29">M Weight:</dt>
          <dd style="margin-left: 1.5em" id="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
        <span>[<a href="#RFC6831" class="cite xref">RFC6831</a>]</span>.<a href="#section-5.4-5.30" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.4-5.31">Unused Flags:</dt>
          <dd style="margin-left: 1.5em" id="section-5.4-5.32">These are set to 0 when sending
        and ignored on receipt.<a href="#section-5.4-5.32" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.4-5.33">L:</dt>
          <dd style="margin-left: 1.5em" id="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.<a href="#section-5.4-5.34" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.4-5.35">p:</dt>
          <dd style="margin-left: 1.5em" id="section-5.4-5.36">When this bit is set, an ETR informs the
        RLOC-Probing ITR that the Routing Locator Address for which this bit
        is set is the one being RLOC-Probed and may be different from
        the source address of the Map-Reply. An ITR that RLOC-Probes a
        particular Locator <span class="bcp14">MUST</span> 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 <span class="bcp14">MUST</span> select the
        first set p-bit Locator. The p-bit <span class="bcp14">MUST NOT</span> be set for Locator-Set
        records sent in Map-Request and Map-Register messages.<a href="#section-5.4-5.36" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.4-5.37">R:</dt>
          <dd style="margin-left: 1.5em" id="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.<a href="#section-5.4-5.38" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.4-5.39">Locator:</dt>
          <dd style="margin-left: 1.5em" id="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 <span class="bcp14">MAY</span> be an anycast
        address. A source RLOC of a LISP encapsulated packet can be an
        anycast address as well.  The source or destination RLOC <span class="bcp14">MUST NOT</span> be the broadcast address (255.255.255.255 or any subnet
        broadcast address known to the router) and <span class="bcp14">MUST NOT</span> be a
        link-local multicast address.  The source RLOC <span class="bcp14">MUST NOT</span> be a
        multicast address. The destination RLOC <span class="bcp14">SHOULD</span> be a multicast
        address if it is being mapped from a multicast destination
        EID.<a href="#section-5.4-5.40" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-5.4-6">Map-Replies <span class="bcp14">MUST</span> be rate limited. It is <span class="bcp14">RECOMMENDED</span> that a Map-Reply
      for the same destination RLOC be sent to no more than one packet every 3 seconds.<a href="#section-5.4-6" class="pilcrow">¶</a></p>
<p id="section-5.4-7">The Record format, as defined here, is used both in the Map-Reply
    and Map-Register messages; this includes all the field definitions.<a href="#section-5.4-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="MR">
<section id="section-5.5">
        <h3 id="name-eid-to-rloc-udp-map-reply-m">
<a href="#section-5.5" class="section-number selfRef">5.5. </a><a href="#name-eid-to-rloc-udp-map-reply-m" class="section-name selfRef">EID-to-RLOC UDP Map-Reply Message</a>
        </h3>
<p id="section-5.5-1">A Map-Reply returns an EID-Prefix with a mask length that
      is less than or equal to the EID being requested. The EID being
      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 "<a href="#rloc-probe" class="internal xref">RLOC-Probing Algorithm</a>" (<a href="#rloc-probe" class="auto internal xref">Section 7.1</a>) for
      details.<a href="#section-5.5-1" class="pilcrow">¶</a></p>
<p id="section-5.5-2">Note that a Map-Reply <span class="bcp14">MAY</span> contain different EID-Prefix
      granularity (prefix + 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.<a href="#section-5.5-2" class="pilcrow">¶</a></p>
<p id="section-5.5-3">When an EID moves out of a LISP site <span>[<a href="#EID-MOBILITY" class="cite xref">EID-MOBILITY</a>]</span>, the database Mapping System
      may have overlapping EID-Prefixes. Or when a LISP site is
      configured with multiple sets of ETRs that support different
      EID-Prefix mask lengths, the database Mapping System may have
      overlapping EID-Prefixes. When overlapping EID-Prefixes exist, a
      Map-Request with an EID that best matches any EID-Prefix <span class="bcp14">MUST</span> be
      returned in a single Map-Reply message. For instance, if an ETR
      had database mapping entries for EID-Prefixes:<a href="#section-5.5-3" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-5.5-4">
<pre>
  2001:db8::/32
  2001:db8:1::/48
  2001:db8:1:1::/64
  2001:db8:1:2::/64
</pre><a href="#section-5.5-4" class="pilcrow">¶</a>
</div>
<p id="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.<a href="#section-5.5-5" class="pilcrow">¶</a></p>
<p id="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-specific prefixes
      that exist in the Mapping System.<a href="#section-5.5-6" class="pilcrow">¶</a></p>
<p id="section-5.5-7">Note that not all overlapping EID-Prefixes need to be
      returned but only the more-specific entries (note 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 <span class="bcp14">SHOULD</span> use
      the same TTL value so they can all time out at the same
      time. When a more-specific EID-Prefix is received later, its
      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
      <span class="bcp14">SHOULD</span> 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.<a href="#section-5.5-7" class="pilcrow">¶</a></p>
<p id="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.<a href="#section-5.5-8" class="pilcrow">¶</a></p>
<p id="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.<a href="#section-5.5-9" class="pilcrow">¶</a></p>
<p id="section-5.5-10">For each Map-Reply record, the list of Locators in a
      Locator-Set <span class="bcp14">MUST</span> be sorted
      in order of ascending IP address where an IPv4 Routing Locator
      Address is considered numerically "less than" an IPv6 Routing
 Locator Address.<a href="#section-5.5-10" class="pilcrow">¶</a></p>
<p id="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 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; 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.<a href="#section-5.5-11" class="pilcrow">¶</a></p>
</section>
</div>
<div id="MAPREG">
<section id="section-5.6">
        <h3 id="name-map-register-message-format">
<a href="#section-5.6" class="section-number selfRef">5.6. </a><a href="#name-map-register-message-format" class="section-name selfRef">Map-Register Message Format</a>
        </h3>
<p id="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.<a href="#section-5.6-1" class="pilcrow">¶</a></p>
<p id="section-5.6-2">The fields below are used in multiple control messages. They
      are defined for Map-Register, Map-Notify, and Map-Notify-Ack message
      types.<a href="#section-5.6-2" class="pilcrow">¶</a></p>
<p id="section-5.6-3">The Map-Register message format is:<a href="#section-5.6-3" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-5.6-4">
<pre>
     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; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre><a href="#section-5.6-4" class="pilcrow">¶</a>
</div>
<p id="section-5.6-5">Packet field descriptions:<a href="#section-5.6-5" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-5.6-6">
          <dt id="section-5.6-6.1">Type: </dt>
          <dd style="margin-left: 1.5em" id="section-5.6-6.2">3 (Map-Register)<a href="#section-5.6-6.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.6-6.3">P:</dt>
          <dd style="margin-left: 1.5em" id="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.<a href="#section-5.6-6.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.6-6.5">S:</dt>
          <dd style="margin-left: 1.5em" id="section-5.6-6.6">This is the security-capable bit. When set,
        the procedures from <span>[<a href="#RFC9303" class="cite xref">RFC9303</a>]</span> are
        supported.<a href="#section-5.6-6.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.6-6.7">I:</dt>
          <dd style="margin-left: 1.5em" id="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' field and a 64-bit 'Site-ID' field are present at the end
        of the Map-Register message.  If an xTR is configured with an
        xTR-ID and Site-ID, it <span class="bcp14">MUST</span> set the 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.<a href="#section-5.6-6.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.6-6.9">Reserved:</dt>
          <dd style="margin-left: 1.5em" id="section-5.6-6.10">This unassigned field <span class="bcp14">MUST</span> be set to 0 on
        transmit and <span class="bcp14">MUST</span> be ignored on receipt.<a href="#section-5.6-6.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.6-6.11">E:</dt>
          <dd style="margin-left: 1.5em" id="section-5.6-6.12">This is the Map-Register EID-notify bit. This
        is used by a First-Hop Router  that discovers a
        dynamic EID. This EID-notify-based Map-Register is sent by the
        First-Hop Router to a same site xTR that propagates the Map-Register to
        the Mapping System. The site xTR keeps state to later
        Map-Notify the First-Hop Router after the EID has moved away. See <span>[<a href="#EID-MOBILITY" class="cite xref">EID-MOBILITY</a>]</span> for a detailed
        use case.<a href="#section-5.6-6.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.6-6.13">T:</dt>
          <dd style="margin-left: 1.5em" id="section-5.6-6.14">This is the 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' field of this
        message. Otherwise, the default timeout described in <a href="#reg" class="auto internal xref">Section 8.2</a> is used.<a href="#section-5.6-6.14" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.6-6.15">a:</dt>
          <dd style="margin-left: 1.5em" id="section-5.6-6.16">This is the merge-request bit. When set to 1,
        the xTR requests to merge RLOC-Records from different xTRs
        registering the same EID-Record. See Signal-Free Multicast
        <span>[<a href="#RFC8378" class="cite xref">RFC8378</a>]</span> for one
        use-case example.<a href="#section-5.6-6.16" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.6-6.17">R:</dt>
          <dd style="margin-left: 1.5em" id="section-5.6-6.18">This reserved and unassigned bit <span class="bcp14">MUST</span> be set to 0 on
        transmit and <span class="bcp14">MUST</span> be ignored on receipt.<a href="#section-5.6-6.18" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.6-6.19">M:</dt>
          <dd style="margin-left: 1.5em" id="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.<a href="#section-5.6-6.20" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.6-6.21">Record Count:</dt>
          <dd style="margin-left: 1.5em" id="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.<a href="#section-5.6-6.22" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.6-6.23">Nonce:</dt>
          <dd style="margin-left: 1.5em" id="section-5.6-6.24"> This 8-octet 'Nonce' field is
        incremented each time a Map-Register message is sent. When a
        Map-Register 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 <span class="bcp14">SHOULD</span>
        store the last nonce sent in persistent storage, so when it
        restarts, it can continue using an incrementing nonce. If
        the ETR cannot support saving the nonce, then when it restarts,
        it <span class="bcp14">MUST</span> use a new authentication key to register to the
        Mapping System. A Map-Server <span class="bcp14">MUST</span> 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 <span class="bcp14">MUST</span> drop the
        Map-Register message and <span class="bcp14">SHOULD</span> log the fact that a replay attack could
        have occurred.<a href="#section-5.6-6.24" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.6-6.25">Key ID:</dt>
          <dd style="margin-left: 1.5em" id="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 rotating between multiple pre-shared
 secrets in a nondisruptive way. The pre-shared secret <span class="bcp14">MUST</span>
 be unique per each LISP Site-ID.<a href="#section-5.6-6.26" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.6-6.27">Algorithm ID:</dt>
          <dd style="margin-left: 1.5em" id="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 <a href="#KEYS" class="auto internal xref">Section 12.5</a> for codepoint assignments.<a href="#section-5.6-6.28" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.6-6.29">Authentication Data Length:</dt>
          <dd style="margin-left: 1.5em" id="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.<a href="#section-5.6-6.30" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.6-6.31">Authentication Data:</dt>
          <dd style="margin-left: 1.5em" id="section-5.6-6.32">
            <p id="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:<a href="#section-5.6-6.32.1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-5.6-6.32.2">
              <li id="section-5.6-6.32.2.1">The KDF algorithm is identified by the
   'Algorithm ID' field according to the table in <a href="#KEYS" class="auto internal xref">Section 12.5</a>. Implementations of this specification <span class="bcp14">MUST</span> implement HMAC-SHA-256-128 <span>[<a href="#RFC4868" class="cite xref">RFC4868</a>]</span> and <span class="bcp14">SHOULD</span> implement HMAC-SHA-256-128+HKDF-SHA256 <span>[<a href="#RFC5869" class="cite xref">RFC5869</a>]</span>.<a href="#section-5.6-6.32.2.1" class="pilcrow">¶</a>
</li>
              <li id="section-5.6-6.32.2.2">The MAC algorithm is identified by the 'Algorithm ID' field
   according to the table in <a href="#KEYS" class="auto internal xref">Section 12.5</a>.<a href="#section-5.6-6.32.2.2" class="pilcrow">¶</a>
</li>
              <li id="section-5.6-6.32.2.3">The pre-shared secret used to derive the per-message key is represented by PSK[Key ID], that is, the pre-shared secret identified by the Key ID.<a href="#section-5.6-6.32.2.3" class="pilcrow">¶</a>
</li>
              <li id="section-5.6-6.32.2.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' field of the Map-Register, "+" denotes concatenation and "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 <a href="#KEYS" class="auto internal xref">Section 12.5</a> 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.<a href="#section-5.6-6.32.2.4" class="pilcrow">¶</a>
</li>
              <li id="section-5.6-6.32.2.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) with the authenticated data field preset to 0.<a href="#section-5.6-6.32.2.5" class="pilcrow">¶</a>
</li>
            </ol>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-5.6-7">The definition of the rest of the Map-Register can be found
      in the EID-Record description in <a href="#MR-FORMAT" class="auto internal xref">Section 5.4</a>. When
      the I-bit is set, the following fields are added to the end of
      the Map-Register message:<a href="#section-5.6-7" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-5.6-8">
          <dt id="section-5.6-8.1">xTR-ID:</dt>
          <dd style="margin-left: 1.5em" id="section-5.6-8.2">'xTR-ID' is a 128-bit field at the end of
        the Map-Register message, starting after the final Record in
        the message. The xTR-ID is used to uniquely identify an xTR.
        The same xTR-ID value <span class="bcp14">MUST NOT</span> be used in two different xTRs in the scope of the Site-ID.<a href="#section-5.6-8.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.6-8.3">Site-ID:</dt>
          <dd style="margin-left: 1.5em" id="section-5.6-8.4">'Site-ID' is a 64-bit field at the end of
        the 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' field.
        Informally, it provides an indication that a group of xTRs have some relationship, either administratively, topologically, or otherwise.<a href="#section-5.6-8.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="MAP-NOTIF-MAP-NOTIF-ACK">
<section id="section-5.7">
        <h3 id="name-map-notify-and-map-notify-a">
<a href="#section-5.7" class="section-number selfRef">5.7. </a><a href="#name-map-notify-and-map-notify-a" class="section-name selfRef">Map-Notify and Map-Notify-Ack Message Formats</a>
        </h3>
<p id="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.<a href="#section-5.7-1" class="pilcrow">¶</a></p>
<p id="section-5.7-2">The Map-Notify and Map-Notify-Ack message formats are:<a href="#section-5.7-2" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-5.7-3">
<pre>
     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; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre><a href="#section-5.7-3" class="pilcrow">¶</a>
</div>
<p id="section-5.7-4">Packet field descriptions:<a href="#section-5.7-4" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-5.7-5">
          <dt id="section-5.7-5.1">Type: </dt>
          <dd style="margin-left: 1.5em" id="section-5.7-5.2">4/5 (Map-Notify/Map-Notify-Ack)<a href="#section-5.7-5.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-5.7-6">The Map-Notify message has the same contents as a
      Map-Register message. See "<a href="#MAPREG" class="internal xref">Map-Register Message Format</a>" (<a href="#MAPREG" class="auto internal xref">Section 5.6</a>) for field descriptions and
"<a href="#MR-FORMAT" class="internal xref">Map-Reply Message Format</a>" (<a href="#MR-FORMAT" class="auto internal xref">Section 5.4</a>) for EID-Record and RLOC-Record descriptions.<a href="#section-5.7-6" class="pilcrow">¶</a></p>
<p id="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-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 be used in an unsolicited manner.  This topic is out of scope for this document. See <span>[<a href="#I-D.ietf-lisp-pubsub" class="cite xref">LISP-PUBSUB</a>]</span> for details.<a href="#section-5.7-7" class="pilcrow">¶</a></p>
<p id="section-5.7-8">After sending a Map-Register, if a Map-Notify is not
   received after 1 second, the transmitter <span class="bcp14">MUST</span> retransmit
   the original Map-Register with an exponential backoff (base of 2, that is, the next backoff timeout interval is 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; Map-Notify messages are not retransmitted. The only exception to this is for unsolicited Map-Notify messages; see below.<a href="#section-5.7-8" class="pilcrow">¶</a></p>
<p id="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 Section <span><a href="https://www.rfc-editor.org/rfc/rfc8085#section-3.1" class="relref">3.1</a> (<a href="https://www.rfc-editor.org/rfc/rfc8085#section-3.1" class="relref">"Congestion Control Guidelines"</a>)</span> of <span>[<a href="#RFC8085" class="cite xref">RFC8085</a>]</span> and Section <span><a href="https://www.rfc-editor.org/rfc/rfc8085#section-3.3" class="relref">3.3</a> (<a href="https://www.rfc-editor.org/rfc/rfc8085#section-3.3" class="relref">"Reliability Guidelines"</a>)</span> of <span>[<a href="#RFC8085" class="cite xref">RFC8085</a>]</span>. 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 <span class="bcp14">SHOULD</span> retransmit up to
      3 times at 3-second retransmission intervals, after which time
      the retransmission interval is exponentially 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-Ack messages are not retransmitted.<a href="#section-5.7-9" class="pilcrow">¶</a></p>
<p id="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 Authentication Data is validated, allows 
 the sender to stop retransmitting a Map-Notify with the same nonce
 and (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.<a href="#section-5.7-10" class="pilcrow">¶</a></p>
<p id="section-5.7-11">Upon reception of a Map-Register, Map-Notify, or Map-Notify-Ack, the receiver verifies
        the Authentication Data. If the Authentication Data fails to validate, the
message is dropped without further processing.<a href="#section-5.7-11" class="pilcrow">¶</a></p>
</section>
</div>
<div id="encap-mr">
<section id="section-5.8">
        <h3 id="name-encapsulated-control-messag">
<a href="#section-5.8" class="section-number selfRef">5.8. </a><a href="#name-encapsulated-control-messag" class="section-name selfRef">Encapsulated Control Message Format</a>
        </h3>
<p id="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.<a href="#section-5.8-1" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-5.8-2">
<pre>
      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                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre><a href="#section-5.8-2" class="pilcrow">¶</a>
</div>
<p id="section-5.8-3">Packet header descriptions:<a href="#section-5.8-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-5.8-4">
          <dt id="section-5.8-4.1">OH:</dt>
          <dd style="margin-left: 3.0em" id="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.<a href="#section-5.8-4.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.8-4.3">UDP:</dt>
          <dd style="margin-left: 3.0em" id="section-5.8-4.4">This is the outer UDP header with destination port
        4342. The source port is randomly allocated. The checksum
        field <span class="bcp14">MUST</span> be non-zero.<a href="#section-5.8-4.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.8-4.5">LISP:</dt>
          <dd style="margin-left: 3.0em" id="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, as encoded by the first 4 bits after the 'Reserved'
        field, or the 'Authentication Data' field <span>[<a href="#RFC9303" class="cite xref">RFC9303</a>]</span> if the S-bit (see below) is set.<a href="#section-5.8-4.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.8-4.7">Type: </dt>
          <dd style="margin-left: 3.0em" id="section-5.8-4.8">8 (Encapsulated Control Message (ECM))<a href="#section-5.8-4.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.8-4.9">S:</dt>
          <dd style="margin-left: 3.0em" id="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 <span>[<a href="#RFC9303" class="cite xref">RFC9303</a>]</span>.<a href="#section-5.8-4.10" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<div class="alignLeft art-text artwork" id="section-5.8-5">
<pre>
 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 . . .       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre><a href="#section-5.8-5" class="pilcrow">¶</a>
</div>
<span class="break"></span><dl class="dlParallel" id="section-5.8-6">
          <dt id="section-5.8-6.1">D:</dt>
          <dd style="margin-left: 3.0em" id="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. Details regarding this procedure are described in <span>[<a href="#RFC8111" class="cite xref">RFC8111</a>]</span>.<a href="#section-5.8-6.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.8-6.3">R:</dt>
          <dd style="margin-left: 3.0em" id="section-5.8-6.4">This reserved and unassigned bit <span class="bcp14">MUST</span> be set to 0 on
        transmit and <span class="bcp14">MUST</span> be ignored on receipt.<a href="#section-5.8-6.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<span class="break"></span><dl class="dlParallel" id="section-5.8-7">
          <dt id="section-5.8-7.1">IH:</dt>
          <dd style="margin-left: 3.0em" id="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.<a href="#section-5.8-7.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.8-7.3">UDP:</dt>
          <dd style="margin-left: 3.0em" id="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 <span class="bcp14">MUST NOT</span> be assigned to either
        port. The checksum field <span class="bcp14">MUST</span> be non-zero.<a href="#section-5.8-7.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.8-7.5">LCM:</dt>
          <dd style="margin-left: 3.0em" id="section-5.8-7.6">The format is one of the control message
        formats described in <a href="#lispcp" class="auto internal xref">Section 5</a>. Map-Request messages are
        allowed to be control plane (ECM) encapsulated. When
        Map-Requests are sent for RLOC-Probing purposes (i.e., the
        probe-bit is set), they <span class="bcp14">MUST NOT</span> be sent inside Encapsulated
        Control Messages. PIM Join/Prune messages <span>[<a href="#RFC6831" class="cite xref">RFC6831</a>]</span> are also allowed to be control plane (ECM)
        encapsulated.<a href="#section-5.8-7.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
</section>
</div>
<section id="section-6">
      <h2 id="name-changing-the-contents-of-ei">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-changing-the-contents-of-ei" class="section-name selfRef">Changing the Contents of EID-to-RLOC Mappings</a>
      </h2>
<p id="section-6-1">In the LISP architecture, ITRs/PITRs use a local Map-Cache to
    store EID-to-RLOC mappings for forwarding. When an ETR updates a
    mapping, a mechanism is required to inform ITRs/PITRs that are
    using such mappings.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">The LISP data plane defines several mechanisms to update
    mappings <span>[<a href="#RFC9300" class="cite xref">RFC9300</a>]</span>. This document
    specifies the Solicit-Map-Request (SMR), a control plane
    push-based mechanism.  An additional control plane mechanism based
    on the Publish/Subscribe paradigm is specified in
    <span>[<a href="#I-D.ietf-lisp-pubsub" class="cite xref">LISP-PUBSUB</a>]</span>.<a href="#section-6-2" class="pilcrow">¶</a></p>
<div id="SMR">
<section id="section-6.1">
        <h3 id="name-solicit-map-request-smr">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-solicit-map-request-smr" class="section-name selfRef">Solicit-Map-Request (SMR)</a>
        </h3>
<p id="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.<a href="#section-6.1-1" class="pilcrow">¶</a></p>
<p id="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, 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.<a href="#section-6.1-2" class="pilcrow">¶</a></p>
<p id="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 it receives an SMR
          message. While the SMR message is sent through the data plane, the SMR-invoked Map-Request
          <span class="bcp14">MUST</span> be sent through the Mapping System (not directly).<a href="#section-6.1-3" class="pilcrow">¶</a></p>
<p id="section-6.1-4">Both the SMR sender and the SMR responder
           <span class="bcp14">MUST</span> rate limit these messages. It is <span class="bcp14">RECOMMENDED</span> that
   the SMR sender rate limit a Map-Request for the same destination RLOC to
   no more than one packet every 3 seconds. It is <span class="bcp14">RECOMMENDED</span> that the
      SMR responder rate limit a Map-Request for the same EID-Prefix to no more than once
      every 3 seconds.<a href="#section-6.1-4" class="pilcrow">¶</a></p>
<p id="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 <span class="bcp14">SHOULD NOT</span> 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.<a href="#section-6.1-5" class="pilcrow">¶</a></p>
</section>
</div>
</section>
<section id="section-7">
      <h2 id="name-routing-locator-reachabilit">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-routing-locator-reachabilit" class="section-name selfRef">Routing Locator Reachability</a>
      </h2>
<p id="section-7-1">This document defines several control plane mechanisms
   for determining RLOC reachability. Please note that additional data plane
   reachability mechanisms are defined in <span>[<a href="#RFC9300" class="cite xref">RFC9300</a>]</span>.<a href="#section-7-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-7-2">
 <li id="section-7-2.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
            <span>[<a href="#I-D.ietf-opsec-icmp-filtering" class="cite xref">OPSEC-ICMP-FILTER</a>]</span>.<a href="#section-7-2.1" class="pilcrow">¶</a>
</li>
        <li id="section-7-2.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.<a href="#section-7-2.2" class="pilcrow">¶</a>
</li>
        <li id="section-7-2.3">An ITR may receive an ICMP Port Unreachable message
            from a destination host. This occurs if an ITR
            attempts to use interworking <span>[<a href="#RFC6832" class="cite xref">RFC6832</a>]</span> and
            LISP-encapsulated data is sent to a non-LISP-capable site.<a href="#section-7-2.3" class="pilcrow">¶</a>
</li>
        <li id="section-7-2.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 the
            outer header -- can be a spoofable field.<a href="#section-7-2.4" class="pilcrow">¶</a>
</li>
        <li id="section-7-2.5">An ITR/ETR pair can use the 'RLOC-Probing' mechanism
            described below.<a href="#section-7-2.5" class="pilcrow">¶</a>
</li>
      </ol>
<p id="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.<a href="#section-7-3" class="pilcrow">¶</a></p>
<p id="section-7-4">If an ITR does receive an ICMP Network Unreachable or Host
        Unreachable message, it <span class="bcp14">MAY</span> originate its own ICMP Destination
        Unreachable message destined for the host that originated
        the data packet the ITR encapsulated.<a href="#section-7-4" class="pilcrow">¶</a></p>
<p id="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.<a href="#section-7-5" class="pilcrow">¶</a></p>
<p id="section-7-6">The ITR can test the reachability of the unreachable
        Locator by sending periodic Map-Requests. Both Map-Requests and
        Map-Replies <span class="bcp14">MUST</span> be rate limited; see Sections <a href="#MAPREQ" class="auto internal xref">5.3</a> and <a href="#MR-FORMAT" class="auto internal xref">5.4</a> for information about rate limiting. Locator reachability testing
        is never done with data packets, since that increases the
        risk of packet loss for end-to-end sessions.<a href="#section-7-6" class="pilcrow">¶</a></p>
<div id="rloc-probe">
<section id="section-7.1">
        <h3 id="name-rloc-probing-algorithm">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-rloc-probing-algorithm" class="section-name selfRef">RLOC-Probing Algorithm</a>
        </h3>
<p id="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.<a href="#section-7.1-1" class="pilcrow">¶</a></p>
<p id="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 Routing Locator Address from one of its
        own Routing Locator Addresses. A Map-Request used as an RLOC-Probe
        is NOT encapsulated and NOT sent to a Map-Server or to the
        mapping database system as one would when requesting mapping data.
        The EID-Record encoded in the Map-Request is the EID-Prefix of
        the Map-Cache entry cached by the ITR or PITR. The ITR
        <span class="bcp14">MAY</span> include a mapping data record for its own database mapping
        information that contains the local EID-Prefixes and RLOCs for
        its site. RLOC-Probes are sent periodically using a jittered
        timer interval.<a href="#section-7.1-2" class="pilcrow">¶</a></p>
<p id="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 <span class="bcp14">SHOULD</span> 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
        to get mapping updates if there were changes to the ETR's
        database mapping entries.<a href="#section-7.1-3" class="pilcrow">¶</a></p>
<p id="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, 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 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.<a href="#section-7.1-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
<section id="section-8">
      <h2 id="name-interactions-with-other-lis">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-interactions-with-other-lis" class="section-name selfRef">Interactions with Other LISP Components</a>
      </h2>
<section id="section-8.1">
        <h3 id="name-itr-eid-to-rloc-mapping-res">
<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-itr-eid-to-rloc-mapping-res" class="section-name selfRef">ITR EID-to-RLOC Mapping Resolution</a>
        </h3>
<p id="section-8.1-1">An ITR is configured with one or more Map-Resolver addresses.
      These addresses are "Locators" (or RLOCs) and <span class="bcp14">MUST</span> be routable
      on the underlying core network; they <span class="bcp14">MUST NOT</span> 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.<a href="#section-8.1-1" class="pilcrow">¶</a></p>
<p id="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.<a href="#section-8.1-2" class="pilcrow">¶</a></p>
<p id="section-8.1-3"> In response to an Encapsulated Map-Request, the ITR can
      expect one of the following:<a href="#section-8.1-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-8.1-4.1"> An immediate Negative Map-Reply (with action code
        "Natively-Forward" and a 15-minute 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.<a href="#section-8.1-4.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-8.1-4.2"> A Negative Map-Reply (with action code
        "Natively-Forward") from a Map-Server that is authoritative (within the LISP deployment (<a href="#soa" class="auto internal xref">Section 1.1</a>))
        for an EID-Prefix that matches the requested EID but that does
        not have an actively registered, more-specific 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 <a href="#reg" class="auto internal xref">Section 8.2</a> for a discussion of aggregate EID-Prefixes and
        details regarding Map-Server EID-Prefix matching.<a href="#section-8.1-4.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="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 <a href="#mr-processing" class="auto internal xref">Section 8.4</a> for more details
        on Map-Resolver message processing.<a href="#section-8.1-4.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-8.1-5"> Note that an ITR may be configured to both use a
      Map-Resolver and participate in a LISP-ALT logical
      network. In such a situation, the ITR <span class="bcp14">SHOULD</span> 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.<a href="#section-8.1-5" class="pilcrow">¶</a></p>
</section>
<div id="reg">
<section id="section-8.2">
        <h3 id="name-eid-prefix-configuration-an">
<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-eid-prefix-configuration-an" class="section-name selfRef">EID-Prefix Configuration and ETR Registration</a>
        </h3>
<p id="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, so prior to sending a Map-Register message,
      the ETR and Map-Server <span class="bcp14">MUST</span> be configured with a pre-shared secret
      used to derive Map-Register authentication keys. A Map-Server's
      configuration <span class="bcp14">SHOULD</span> 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 vulnerable to trivial EID-Prefix
      hijacking attacks.<a href="#section-8.2-1" class="pilcrow">¶</a></p>
<p id="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 for EID-Prefixes that match an
      aggregate but do not match a registered prefix; <a href="#ms-processing" class="auto internal xref">Section 8.3</a> describes how this is handled.<a href="#section-8.2-2" class="pilcrow">¶</a></p>
<p id="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 <span class="bcp14">SHOULD</span> time out and remove an ETR's
      registration if it has not received a valid Map-Register message
      within the past three minutes. When first contacting a
      Map-Server after restart or changes to its EID-to-RLOC database
      mappings, an ETR <span class="bcp14">MAY</span> initially send Map-Register messages at an
      increased frequency, up to one every 20 seconds.  This "quick
      registration" period is limited to five minutes in
      duration.<a href="#section-8.2-3" class="pilcrow">¶</a></p>
<p id="section-8.2-4"> An ETR <span class="bcp14">MAY</span> 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.<a href="#section-8.2-4" class="pilcrow">¶</a></p>
<p id="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;
      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 <span>[<a href="#I-D.ietf-lisp-mn" class="cite xref">LISP-MN</a>]</span>.<a href="#section-8.2-5" class="pilcrow">¶</a></p>
<p id="section-8.2-6"> An ETR <span class="bcp14">MAY</span> 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
      <a href="#rloc-probe" class="auto internal xref">Section 7.1</a> for details on how
      the Map-Server sets certain flags (such as those indicating
      whether the message is authoritative and how returned Locators
      <span class="bcp14">SHOULD</span> be treated) when sending a Map-Reply on behalf of an ETR.
      When an ETR requests proxy reply service, it <span class="bcp14">SHOULD</span> 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.<a href="#section-8.2-6" class="pilcrow">¶</a></p>
<p id="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.<a href="#section-8.2-7" class="pilcrow">¶</a></p>
<p id="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.<a href="#section-8.2-8" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ms-processing">
<section id="section-8.3">
        <h3 id="name-map-server-processing">
<a href="#section-8.3" class="section-number selfRef">8.3. </a><a href="#name-map-server-processing" class="section-name selfRef">Map-Server Processing</a>
        </h3>
<p id="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.<a href="#section-8.3-1" class="pilcrow">¶</a></p>
<p id="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 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.<a href="#section-8.3-2" class="pilcrow">¶</a></p>
<p id="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.<a href="#section-8.3-3" class="pilcrow">¶</a></p>
<p id="section-8.3-4">If the EID-Prefix is either registered or not registered to
      the Mapping System and there is a policy in the Map-Server to
      have the requester drop packets for the matching EID-Prefix,
      then a Drop/Policy-Denied action is returned. If the EID-Prefix
      is registered or not registered and there is an authentication
      failure, then a Drop/Auth-Failure action is
      returned. If either of these actions results as a temporary state
      in policy or authentication, then a Send-Map-Request action with a
      1-minute TTL <span class="bcp14">MAY</span> be returned to allow the requester to retry the
      Map-Request.<a href="#section-8.3-4" class="pilcrow">¶</a></p>
<p id="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.<a href="#section-8.3-5" class="pilcrow">¶</a></p>
<p id="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 <span class="bcp14">SHOULD</span> be
      discarded without response, perhaps accompanied by the logging
      of a diagnostic message if the rate of Map-Replies is suggestive
      of malicious traffic.<a href="#section-8.3-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="mr-processing">
<section id="section-8.4">
        <h3 id="name-map-resolver-processing">
<a href="#section-8.4" class="section-number selfRef">8.4. </a><a href="#name-map-resolver-processing" class="section-name selfRef">Map-Resolver Processing</a>
        </h3>
<p id="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.<a href="#section-8.4-1" class="pilcrow">¶</a></p>
<p id="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 Map-Reply with action code
      "Natively-Forward" and a 15‑minute TTL.  To minimize the
      number of negative cache entries needed by an ITR, the
      Map-Resolver <span class="bcp14">SHOULD</span> 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.<a href="#section-8.4-2" class="pilcrow">¶</a></p>
<p id="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.<a href="#section-8.4-3" class="pilcrow">¶</a></p>
<section id="section-8.4.1">
          <h4 id="name-anycast-operation">
<a href="#section-8.4.1" class="section-number selfRef">8.4.1. </a><a href="#name-anycast-operation" class="section-name selfRef">Anycast Operation</a>
          </h4>
<p id="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.<a href="#section-8.4.1-1" class="pilcrow">¶</a></p>
<p id="section-8.4.1-2"> ETRs <span class="bcp14">MAY</span> have anycast RLOC addresses that are registered
        as part of their RLOC-Set to the Mapping System.  However,
        registrations <span class="bcp14">MUST</span> use their unique RLOC addresses, distinct
        authentication keys, or different xTR-IDs to identify security associations with the
        Map-Servers.<a href="#section-8.4.1-2" class="pilcrow">¶</a></p>
</section>
</section>
</div>
</section>
<section id="section-9">
      <h2 id="name-security-considerations">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-9-1">A LISP threat analysis can be found in <span>[<a href="#RFC7835" class="cite xref">RFC7835</a>]</span>. Here, we highlight security
    considerations that apply when LISP is deployed in environments
    such as those specified in <a href="#soa" class="auto internal xref">Section 1.1</a>, where the
    following assumptions hold:<a href="#section-9-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-9-2">
 <li id="section-9-2.1">The Mapping System is secure and trusted, and for the purpose
      of these security considerations, the Mapping System is considered
      as one trusted element.<a href="#section-9-2.1" class="pilcrow">¶</a>
</li>
        <li id="section-9-2.2">The ETRs have a preconfigured trust relationship with the Mapping
     System, including some form of shared secret.  The Mapping
     System is aware of which EIDs an ETR can advertise. How
      those keys and mappings are established is out of scope for
      this document.<a href="#section-9-2.2" class="pilcrow">¶</a>
</li>
        <li id="section-9-2.3">LISP-SEC <span>[<a href="#RFC9303" class="cite xref">RFC9303</a>]</span> <span class="bcp14">MUST</span> be
      implemented. Network operators should carefully 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.<a href="#section-9-2.3" class="pilcrow">¶</a>
</li>
      </ol>
<p id="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.<a href="#section-9-3" class="pilcrow">¶</a></p>
<p id="section-9-4">The Map-Request/Map-Reply message exchange can also be exploited to inject
    forged mappings directly into the ITR EID-to-RLOC Map-Cache. This
    can lead to traffic being redirected to the attacker; see further
    details in <span>[<a href="#RFC7835" class="cite xref">RFC7835</a>]</span>. In addition, valid ETRs in
    the system can perform overclaiming attacks. In this case,
    attackers can claim to own an EID-Prefix that is larger than the
    prefix owned by the ETR. Such attacks can be addressed by using
    LISP-SEC <span>[<a href="#RFC9303" class="cite xref">RFC9303</a>]</span>. The LISP-SEC protocol
    defines a mechanism for providing origin authentication,
    integrity protection, and prevention of
    'man-in-the-middle' and 'prefix overclaiming'
    attacks on the Map-Request/Map-Reply exchange. In 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. For instance, BGP-based LISP-ALT <span>[<a href="#RFC6836" class="cite xref">RFC6836</a>]</span> can take advantage of standards work on adding
    security to BGP, while LISP-DDT <span>[<a href="#RFC8111" class="cite xref">RFC8111</a>]</span> defines
    its own additional security mechanisms.<a href="#section-9-4" class="pilcrow">¶</a></p>
<p id="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 that is a MAC of the entire message using a
    key derived from the pre-shared secret. An implementation <span class="bcp14">SHOULD</span> support
 HMAC-SHA256-128+HKDF-SHA256 <span>[<a href="#RFC5869" class="cite xref">RFC5869</a>]</span>. The Map-Register
 message includes protection against replay
    attacks by a man in the middle. However, there is a potential attack where a compromised ETR could overclaim
    the prefix it owns and successfully register it on its
    corresponding Map-Server. To mitigate this, as noted in <a href="#reg" class="auto internal xref">Section 8.2</a>, a Map-Server <span class="bcp14">MUST</span> verify that all EID-Prefixes
    registered by an ETR match the configuration stored on the
    Map-Server.<a href="#section-9-5" class="pilcrow">¶</a></p>
<p id="section-9-6">Deployments concerned about manipulations of Map-Request and
    Map-Reply messages and malicious ETR EID-Prefix overclaiming <span class="bcp14">MUST</span>
    drop LISP control plane messages that do not contain LISP-SEC
    material (S-bit, EID-AD, OTK-AD, PKT-AD). See <span><a href="https://www.rfc-editor.org/rfc/rfc9303#section-3" class="relref">Section 3</a> of [<a href="#RFC9303" class="cite xref">RFC9303</a>]</span> for definitions of "EID-AD", "OTK-AD", and "PKT-AD".<a href="#section-9-6" class="pilcrow">¶</a></p>
<p id="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, and between nodes that
      make up the Mapping System <span class="bcp14">SHOULD</span> be deployed. Examples of this are DTLS <span>[<a href="#RFC9147" class="cite xref">RFC9147</a>]</span> or
    "lisp-crypto" <span>[<a href="#RFC8061" class="cite xref">RFC8061</a>]</span>.<a href="#section-9-7" class="pilcrow">¶</a></p>
</section>
<section id="section-10">
      <h2 id="name-privacy-considerations">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-privacy-considerations" class="section-name selfRef">Privacy Considerations</a>
      </h2>
<p id="section-10-1">As noted by <span>[<a href="#RFC6973" class="cite xref">RFC6973</a>]</span>, privacy is a complex issue
    that greatly depends on the specific protocol use case and
    deployment. As noted in <span><a href="https://www.rfc-editor.org/rfc/rfc9300#section-1.1" class="relref">Section 1.1</a> of [<a href="#RFC9300" class="cite xref">RFC9300</a>]</span>, LISP focuses on use cases
    where entities communicate over the public Internet while keeping
    separate addressing and topology. Here, we detail the
    privacy threats introduced by the LISP control plane; the analysis
    is based on the guidelines detailed in <span>[<a href="#RFC6973" class="cite xref">RFC6973</a>]</span>.<a href="#section-10-1" class="pilcrow">¶</a></p>
<p id="section-10-2">LISP can use long-lived identifiers (EIDs) that survive
    mobility events. Such identifiers bind to the RLOCs of the 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 messages are not encrypted and can
    be eavesdropped while Map-Request messages are sent to the
    corresponding Map-Resolvers or Map-Register messages to
    Map-Servers.<a href="#section-10-2" class="pilcrow">¶</a></p>
<p id="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. Deployments
    concerned about this threat can use access control lists or stronger
    authentication mechanisms <span>[<a href="#I-D.ietf-lisp-ecdsa-auth" class="cite xref">ECDSA-AUTH</a>]</span> in
    the Mapping System to make sure that only authorized users can
    access this information (data minimization). Use of ephemeral EIDs
    <span>[<a href="#I-D.ietf-lisp-eid-anonymity" class="cite xref">EID-ANONYMITY</a>]</span> to achieve anonymity is
    another mechanism to lessen persistency and identity tracking.<a href="#section-10-3" class="pilcrow">¶</a></p>
</section>
<section id="section-11">
      <h2 id="name-changes-related-to-rfcs-683">
<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-changes-related-to-rfcs-683" class="section-name selfRef">Changes Related to RFCs 6830 and 6833</a>
      </h2>
<p id="section-11-1">For implementation considerations, the following major changes have
    been made to this document since <span>[<a href="#RFC6830" class="cite xref">RFC6830</a>]</span> and <span>[<a href="#RFC6833" class="cite xref">RFC6833</a>]</span> were published:<a href="#section-11-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-11-2.1">The 16-bit 'Key ID' field of the Map-Register and Map-Notify messages as defined in <span>[<a href="#RFC6830" class="cite xref">RFC6830</a>]</span> 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 defined by this document. See Sections <a href="#MAPREG" class="auto internal xref">5.6</a> and <a href="#MAP-NOTIF-MAP-NOTIF-ACK" class="auto internal xref">5.7</a>.<a href="#section-11-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="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
      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.<a href="#section-11-2.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-11-2.3">This document has incorporated the codepoint for the
      Map-Referral message from the LISP-DDT specification <span>[<a href="#RFC8111" class="cite xref">RFC8111</a>]</span> to indicate that a Map-Server must send the
      final Map-Referral message when it participates in the LISP-DDT
      Mapping System procedures.<a href="#section-11-2.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-11-2.4">Bits L and D have been added to the
      Map-Request message. See <a href="#MAPREQ" class="auto internal xref">Section 5.3</a> for details.<a href="#section-11-2.4" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-11-2.5">Bits S, I, E, T, a, R, and M have been added to the
      Map-Register message. See <a href="#MAPREG" class="auto internal xref">Section 5.6</a> for details.<a href="#section-11-2.5" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-11-2.6">The nonce and the Authentication Data in the Map-Register message
    each behave differently; see  <a href="#MAPREG" class="auto internal xref">Section 5.6</a> for details.<a href="#section-11-2.6" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-11-2.7">This document adds two new action values that are in an
      EID-Record that appears in Map-Reply, Map-Register, Map-Notify,
      and Map-Notify-Ack messages. These new action values are Drop/Policy-Denied and
      Drop/Auth-Failure. See <a href="#MR-FORMAT" class="auto internal xref">Section 5.4</a> for details.<a href="#section-11-2.7" class="pilcrow">¶</a>
</li>
      </ul>
</section>
<section id="section-12">
      <h2 id="name-iana-considerations">
<a href="#section-12" class="section-number selfRef">12. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-12-1">This section provides guidance to IANA regarding registration of values related to this
    LISP control plane specification, in accordance with <span><a href="#RFC8126" class="internal xref">BCP 26</a> [<a href="#RFC8126" class="cite xref">RFC8126</a>]</span>.<a href="#section-12-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-12-2.1">LISP IANA registry allocations should not be made for
      purposes unrelated to LISP routing or transport protocols.<a href="#section-12-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-12-2.2">The following policies are used here with the meanings
      defined in <span><a href="#RFC8126" class="internal xref">BCP 26</a> [<a href="#RFC8126" class="cite xref">RFC8126</a>]</span>: "Specification Required", "IETF Review",
      "Experimental Use", and "First Come First Served".<a href="#section-12-2.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-12-3">There are three namespaces (listed in the sub-sections below) in
    LISP that have been registered (see <span>[<a href="#RFC9299" class="cite xref">RFC9299</a>]</span>.<a href="#section-12-3" class="pilcrow">¶</a></p>
<section id="section-12.1">
        <h3 id="name-lisp-udp-port-numbers">
<a href="#section-12.1" class="section-number selfRef">12.1. </a><a href="#name-lisp-udp-port-numbers" class="section-name selfRef">LISP UDP Port Numbers</a>
        </h3>
<p id="section-12.1-1">IANA allocated UDP port number 4342 for the
   LISP control plane. IANA has updated the description for UDP
   port 4342 to reflect the following:<a href="#section-12.1-1" class="pilcrow">¶</a></p>
<table class="center" id="table-2">
          <caption><a href="#table-2" class="selfRef">Table 2</a></caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Service Name</th>
              <th class="text-left" rowspan="1" colspan="1">Port Number</th>
              <th class="text-left" rowspan="1" colspan="1">Transport Protocol</th>
              <th class="text-left" rowspan="1" colspan="1">Description</th>
              <th class="text-left" rowspan="1" colspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">lisp-control</td>
              <td class="text-left" rowspan="1" colspan="1">4342</td>
              <td class="text-left" rowspan="1" colspan="1">udp</td>
              <td class="text-left" rowspan="1" colspan="1">LISP Control Packets</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9301</td>
            </tr>
          </tbody>
        </table>
</section>
<section id="section-12.2">
        <h3 id="name-lisp-packet-type-codes">
<a href="#section-12.2" class="section-number selfRef">12.2. </a><a href="#name-lisp-packet-type-codes" class="section-name selfRef">LISP Packet Type Codes</a>
        </h3>
<p id="section-12.2-1">IANA is now authoritative for LISP
      Packet Type definitions, so they have replaced the registry 
      references to <span>[<a href="#RFC6830" class="cite xref">RFC6830</a>]</span> with references to this document.<a href="#section-12.2-1" class="pilcrow">¶</a></p>
<p id="section-12.2-2">Based on deployment experience related to <span>[<a href="#RFC6830" class="cite xref">RFC6830</a>]</span>,
      the Map-Notify-Ack message (message type 5) is defined in this
      document. IANA has registered it in the "LISP
      Packet Types" registry.<a href="#section-12.2-2" class="pilcrow">¶</a></p>
<table class="center" id="table-3">
          <caption><a href="#table-3" class="selfRef">Table 3</a></caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Message</th>
              <th class="text-left" rowspan="1" colspan="1">Code</th>
              <th class="text-left" rowspan="1" colspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">LISP Map-Notify-Ack</td>
              <td class="text-left" rowspan="1" colspan="1">5</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9301</td>
            </tr>
          </tbody>
        </table>
</section>
<div id="act-iana">
<section id="section-12.3">
        <h3 id="name-lisp-map-reply-eid-record-a">
<a href="#section-12.3" class="section-number selfRef">12.3. </a><a href="#name-lisp-map-reply-eid-record-a" class="section-name selfRef">LISP Map-Reply EID-Record Action Codes</a>
        </h3>
<p id="section-12.3-1">New ACT values can be allocated through IETF Review or IESG
      Approval. Four values have already been allocated by <span>[<a href="#RFC6830" class="cite xref">RFC6830</a>]</span>. IANA has replaced the reference pointing to <span>[<a href="#RFC6830" class="cite xref">RFC6830</a>]</span> to point to this document.  This specification changes the Action name
      of value 3 from "Drop" to "Drop/No-Reason".  It also adds the following 
      new ACT values.<a href="#section-12.3-1" class="pilcrow">¶</a></p>
<span id="name-lisp-map-reply-action-value"></span><table class="center" id="table-4">
          <caption>
<a href="#table-4" class="selfRef">Table 4</a>:
<a href="#name-lisp-map-reply-action-value" class="selfRef">LISP Map-Reply Action Values</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Value</th>
              <th class="text-left" rowspan="1" colspan="1">Action</th>
              <th class="text-left" rowspan="1" colspan="1">Description</th>
              <th class="text-left" rowspan="1" colspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">4</td>
              <td class="text-left" rowspan="1" colspan="1">Drop/Policy-Denied</td>
              <td class="text-left" rowspan="1" colspan="1">A packet matching this Map-Cache entry is dropped because
        the target EID is policy-denied by the xTR or the Mapping
        System.</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9301</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">5</td>
              <td class="text-left" rowspan="1" colspan="1">Drop/Auth-Failure</td>
              <td class="text-left" rowspan="1" colspan="1">A packet matching this Map-Cache entry is dropped because the
        Map-Request for the target EID fails an authentication check
        by the xTR or the Mapping System.</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9301</td>
            </tr>
          </tbody>
        </table>
<p id="section-12.3-3">In addition, LISP has a number of flag fields and reserved
      fields, such as the flags of the LISP header fields <span>[<a href="#RFC9300" class="cite xref">RFC9300</a>]</span>. New bits for flags in
      these fields can be implemented after IETF Review or IESG
      Approval, but these need not be managed by IANA.<a href="#section-12.3-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="IANA">
<section id="section-12.4">
        <h3 id="name-lisp-address-type-codes">
<a href="#section-12.4" class="section-number selfRef">12.4. </a><a href="#name-lisp-address-type-codes" class="section-name selfRef">LISP Address Type Codes</a>
        </h3>
<p id="section-12.4-1">LISP Canonical Address Format (LCAF) <span>[<a href="#RFC8060" class="cite xref">RFC8060</a>]</span>
      has an 8-bit Type field that defines LISP-specific encodings for AFI
      value 16387. LCAF encodings are used for specific use cases
      where different address types for EID-Records and RLOC-Records
      are required.<a href="#section-12.4-1" class="pilcrow">¶</a></p>
<p id="section-12.4-2">The "LISP Canonical Address Format (LCAF)
      Types" registry is used for LCAF types. The registry for LCAF types uses
      the Specification Required policy <span>[<a href="#RFC8126" class="cite xref">RFC8126</a>]</span>. Initial values for the registry as well as
      further information can be found in <span>[<a href="#RFC8060" class="cite xref">RFC8060</a>]</span>.<a href="#section-12.4-2" class="pilcrow">¶</a></p>
<p id="section-12.4-3">Therefore, there is no longer a need for the "LISP Address Type
      Codes" registry requested by <span>[<a href="#RFC6830" class="cite xref">RFC6830</a>]</span>. Per this document, 
      the registry has been closed.<a href="#section-12.4-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="KEYS">
<section id="section-12.5">
        <h3 id="name-lisp-algorithm-id-numbers">
<a href="#section-12.5" class="section-number selfRef">12.5. </a><a href="#name-lisp-algorithm-id-numbers" class="section-name selfRef">LISP Algorithm ID Numbers</a>
        </h3>
<p id="section-12.5-1">In <span>[<a href="#RFC6830" class="cite xref">RFC6830</a>]</span>, a request for a "LISP Key ID
      Numbers" registry was submitted. Per this document, IANA has renamed the
      registry to "LISP Algorithm ID Numbers" and listed this document as the registry reference.<a href="#section-12.5-1" class="pilcrow">¶</a></p>
<p id="section-12.5-2">The following Algorithm ID values are defined by this
      specification, as used in any packet type that references an
      'Algorithm ID' field:<a href="#section-12.5-2" class="pilcrow">¶</a></p>
<table class="center" id="table-5">
          <caption><a href="#table-5" class="selfRef">Table 5</a></caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Name</th>
              <th class="text-left" rowspan="1" colspan="1">Number</th>
              <th class="text-left" rowspan="1" colspan="1">MAC</th>
              <th class="text-left" rowspan="1" colspan="1">KDF</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">None</td>
              <td class="text-left" rowspan="1" colspan="1">0</td>
              <td class="text-left" rowspan="1" colspan="1">None</td>
              <td class="text-left" rowspan="1" colspan="1">None</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">HMAC-SHA-1-96-None</td>
              <td class="text-left" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1">
                <span>[<a href="#RFC2404" class="cite xref">RFC2404</a>]</span>
</td>
              <td class="text-left" rowspan="1" colspan="1">None</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">HMAC-SHA-256-128-None</td>
              <td class="text-left" rowspan="1" colspan="1">2</td>
              <td class="text-left" rowspan="1" colspan="1">
                <span>[<a href="#RFC4868" class="cite xref">RFC4868</a>]</span>
</td>
              <td class="text-left" rowspan="1" colspan="1">None</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">HMAC-SHA256-128+HKDF-SHA256</td>
              <td class="text-left" rowspan="1" colspan="1">3</td>
              <td class="text-left" rowspan="1" colspan="1">
                <span>[<a href="#RFC4868" class="cite xref">RFC4868</a>]</span>
</td>
              <td class="text-left" rowspan="1" colspan="1">
                <span>[<a href="#RFC4868" class="cite xref">RFC4868</a>]</span>
</td>
            </tr>
          </tbody>
        </table>
<p id="section-12.5-4">Number values are in the range of 0 to 255. 
      Values are assigned on a First Come First Served basis.<a href="#section-12.5-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="BITS">
<section id="section-12.6">
        <h3 id="name-lisp-bit-flags">
<a href="#section-12.6" class="section-number selfRef">12.6. </a><a href="#name-lisp-bit-flags" class="section-name selfRef">LISP Bit Flags</a>
        </h3>
<p id="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
      Map-Request messages, Map-Reply messages, Map-Register messages, and Encapsulated Control Messages. Bit allocations are also requested for
      EID-Records and RLOC-Records.  The registry created should
      be named "LISP Control Plane Header Bits".  A subregistry
      needs to be created per each message and EID-Record. The name of each
      subregistry is indicated below, along with its format
      and allocation of bits defined in this document.  Any additional
      bit allocations require a specification, in accordance with policies defined in <span>[<a href="#RFC8126" class="cite xref">RFC8126</a>]</span>.<a href="#section-12.6-1" class="pilcrow">¶</a></p>
<p id="section-12.6-2">Subregistry: Map-Request Header Bits (<a href="#NONCE" class="auto internal xref">Section 5.2</a>):<a href="#section-12.6-2" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-12.6-3">
<pre>
 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  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre><a href="#section-12.6-3" class="pilcrow">¶</a>
</div>
<span id="name-lisp-map-request-header-bit"></span><table class="center" id="table-6">
          <caption>
<a href="#table-6" class="selfRef">Table 6</a>:
<a href="#name-lisp-map-request-header-bit" class="selfRef">LISP Map-Request Header Bits</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Spec Name</th>
              <th class="text-left" rowspan="1" colspan="1">IANA Name</th>
              <th class="text-left" rowspan="1" colspan="1">Bit Position</th>
              <th class="text-left" rowspan="1" colspan="1">Description</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">A</td>
              <td class="text-left" rowspan="1" colspan="1">Map-Request-A</td>
              <td class="text-left" rowspan="1" colspan="1">4</td>
              <td class="text-left" rowspan="1" colspan="1">Authoritative Bit</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">M</td>
              <td class="text-left" rowspan="1" colspan="1">Map-Request-M</td>
              <td class="text-left" rowspan="1" colspan="1">5</td>
              <td class="text-left" rowspan="1" colspan="1">Map Data Present Bit</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">P</td>
              <td class="text-left" rowspan="1" colspan="1">Map-Request-P</td>
              <td class="text-left" rowspan="1" colspan="1">6</td>
              <td class="text-left" rowspan="1" colspan="1">RLOC-Probe Request Bit</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">S</td>
              <td class="text-left" rowspan="1" colspan="1">Map-Request-S</td>
              <td class="text-left" rowspan="1" colspan="1">7</td>
              <td class="text-left" rowspan="1" colspan="1">Solicit Map-Request (SMR)
        Bit</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">p</td>
              <td class="text-left" rowspan="1" colspan="1">Map-Request-p</td>
              <td class="text-left" rowspan="1" colspan="1">8</td>
              <td class="text-left" rowspan="1" colspan="1">Proxy-ITR Bit</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">s</td>
              <td class="text-left" rowspan="1" colspan="1">Map-Request-s</td>
              <td class="text-left" rowspan="1" colspan="1">9</td>
              <td class="text-left" rowspan="1" colspan="1">Solicit Map-Request Invoked
        Bit</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">L</td>
              <td class="text-left" rowspan="1" colspan="1">Map-Request-L</td>
              <td class="text-left" rowspan="1" colspan="1">17</td>
              <td class="text-left" rowspan="1" colspan="1">Local xTR Bit</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">D</td>
              <td class="text-left" rowspan="1" colspan="1">Map-Request-D</td>
              <td class="text-left" rowspan="1" colspan="1">18</td>
              <td class="text-left" rowspan="1" colspan="1">Don't Map-Reply Bit</td>
            </tr>
          </tbody>
        </table>
<p id="section-12.6-5">Subregistry: Map-Reply Header Bits (<a href="#MR-FORMAT" class="auto internal xref">Section 5.4</a>):<a href="#section-12.6-5" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-12.6-6">
<pre>
 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  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre><a href="#section-12.6-6" class="pilcrow">¶</a>
</div>
<span id="name-lisp-map-reply-header-bits"></span><table class="center" id="table-7">
          <caption>
<a href="#table-7" class="selfRef">Table 7</a>:
<a href="#name-lisp-map-reply-header-bits" class="selfRef">LISP Map-Reply Header Bits</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Spec Name</th>
              <th class="text-left" rowspan="1" colspan="1">IANA Name</th>
              <th class="text-left" rowspan="1" colspan="1">Bit Position</th>
              <th class="text-left" rowspan="1" colspan="1">Description</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">P</td>
              <td class="text-left" rowspan="1" colspan="1">Map-Reply-P</td>
              <td class="text-left" rowspan="1" colspan="1">4</td>
              <td class="text-left" rowspan="1" colspan="1">RLOC-Probe Bit</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">E</td>
              <td class="text-left" rowspan="1" colspan="1">Map-Reply-E</td>
              <td class="text-left" rowspan="1" colspan="1">5</td>
              <td class="text-left" rowspan="1" colspan="1">Echo-Nonce Capable Bit</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">S</td>
              <td class="text-left" rowspan="1" colspan="1">Map-Reply-S</td>
              <td class="text-left" rowspan="1" colspan="1">6</td>
              <td class="text-left" rowspan="1" colspan="1">Security Bit</td>
            </tr>
          </tbody>
        </table>
<p id="section-12.6-8">Subregistry: Map-Register Header Bits (<a href="#MAPREG" class="auto internal xref">Section 5.6</a>):<a href="#section-12.6-8" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-12.6-9">
<pre>
 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  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre><a href="#section-12.6-9" class="pilcrow">¶</a>
</div>
<span id="name-lisp-map-register-header-bi"></span><table class="center" id="table-8">
          <caption>
<a href="#table-8" class="selfRef">Table 8</a>:
<a href="#name-lisp-map-register-header-bi" class="selfRef">LISP Map-Register Header Bits</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Spec Name</th>
              <th class="text-left" rowspan="1" colspan="1">IANA Name</th>
              <th class="text-left" rowspan="1" colspan="1">Bit Position</th>
              <th class="text-left" rowspan="1" colspan="1">Description</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">P</td>
              <td class="text-left" rowspan="1" colspan="1">Map-Register-P</td>
              <td class="text-left" rowspan="1" colspan="1">4</td>
              <td class="text-left" rowspan="1" colspan="1">Proxy Map-Reply Bit</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">S</td>
              <td class="text-left" rowspan="1" colspan="1">Map-Register-S</td>
              <td class="text-left" rowspan="1" colspan="1">5</td>
              <td class="text-left" rowspan="1" colspan="1">LISP-SEC Capable Bit</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">I</td>
              <td class="text-left" rowspan="1" colspan="1">Map-Register-I</td>
              <td class="text-left" rowspan="1" colspan="1">6</td>
              <td class="text-left" rowspan="1" colspan="1">xTR-ID Present Bit</td>
            </tr>
          </tbody>
        </table>
<p id="section-12.6-11">Subregistry: Encapsulated Control Message (ECM) Header Bits
      (<a href="#encap-mr" class="auto internal xref">Section 5.8</a>):<a href="#section-12.6-11" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-12.6-12">
<pre>
 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                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre><a href="#section-12.6-12" class="pilcrow">¶</a>
</div>
<span id="name-lisp-encapsulated-control-m"></span><table class="center" id="table-9">
          <caption>
<a href="#table-9" class="selfRef">Table 9</a>:
<a href="#name-lisp-encapsulated-control-m" class="selfRef">LISP Encapsulated Control Message (ECM) Header Bits</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Spec Name</th>
              <th class="text-left" rowspan="1" colspan="1">IANA Name</th>
              <th class="text-left" rowspan="1" colspan="1">Bit Position</th>
              <th class="text-left" rowspan="1" colspan="1">Description</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">S</td>
              <td class="text-left" rowspan="1" colspan="1">ECM-S</td>
              <td class="text-left" rowspan="1" colspan="1">4</td>
              <td class="text-left" rowspan="1" colspan="1">Security Bit</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">D</td>
              <td class="text-left" rowspan="1" colspan="1">ECM-D</td>
              <td class="text-left" rowspan="1" colspan="1">5</td>
              <td class="text-left" rowspan="1" colspan="1">LISP-DDT Bit</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">E</td>
              <td class="text-left" rowspan="1" colspan="1">ECM-E</td>
              <td class="text-left" rowspan="1" colspan="1">6</td>
              <td class="text-left" rowspan="1" colspan="1">Forward to ETR Bit</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">M</td>
              <td class="text-left" rowspan="1" colspan="1">ECM-M</td>
              <td class="text-left" rowspan="1" colspan="1">7</td>
              <td class="text-left" rowspan="1" colspan="1">Destined to Map-Server Bit</td>
            </tr>
          </tbody>
        </table>
<p id="section-12.6-14">Subregistry: EID-Record Header Bits (<a href="#MR-FORMAT" class="auto internal xref">Section 5.4</a>):<a href="#section-12.6-14" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-12.6-15">
<pre>
 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         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre><a href="#section-12.6-15" class="pilcrow">¶</a>
</div>
<span id="name-lisp-eid-record-header-bits"></span><table class="center" id="table-10">
          <caption>
<a href="#table-10" class="selfRef">Table 10</a>:
<a href="#name-lisp-eid-record-header-bits" class="selfRef">LISP EID-Record Header Bits</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Spec Name</th>
              <th class="text-left" rowspan="1" colspan="1">IANA Name</th>
              <th class="text-left" rowspan="1" colspan="1">Bit Position</th>
              <th class="text-left" rowspan="1" colspan="1">Description</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">A</td>
              <td class="text-left" rowspan="1" colspan="1">EID-Record-A</td>
              <td class="text-left" rowspan="1" colspan="1">19</td>
              <td class="text-left" rowspan="1" colspan="1">Authoritative Bit</td>
            </tr>
          </tbody>
        </table>
<p id="section-12.6-17">Subregistry: RLOC-Record Header Bits (<a href="#MR-FORMAT" class="auto internal xref">Section 5.4</a>):<a href="#section-12.6-17" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-12.6-18">
<pre>
 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             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre><a href="#section-12.6-18" class="pilcrow">¶</a>
</div>
<span id="name-lisp-rloc-record-header-bit"></span><table class="center" id="table-11">
          <caption>
<a href="#table-11" class="selfRef">Table 11</a>:
<a href="#name-lisp-rloc-record-header-bit" class="selfRef">LISP RLOC-Record Header Bits</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Spec Name</th>
              <th class="text-left" rowspan="1" colspan="1">IANA Name</th>
              <th class="text-left" rowspan="1" colspan="1">Bit Position</th>
              <th class="text-left" rowspan="1" colspan="1">Description</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">L</td>
              <td class="text-left" rowspan="1" colspan="1">RLOC-Record-L</td>
              <td class="text-left" rowspan="1" colspan="1">13</td>
              <td class="text-left" rowspan="1" colspan="1">Local RLOC Bit</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">p</td>
              <td class="text-left" rowspan="1" colspan="1">RLOC-Record-p</td>
              <td class="text-left" rowspan="1" colspan="1">14</td>
              <td class="text-left" rowspan="1" colspan="1">RLOC-Probe Reply Bit</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">R</td>
              <td class="text-left" rowspan="1" colspan="1">RLOC-Record-R</td>
              <td class="text-left" rowspan="1" colspan="1">15</td>
              <td class="text-left" rowspan="1" colspan="1">RLOC Reachable Bit</td>
            </tr>
          </tbody>
        </table>
</section>
</div>
</section>
<section id="section-13">
      <h2 id="name-references">
<a href="#section-13" class="section-number selfRef">13. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-13.1">
        <h3 id="name-normative-references">
<a href="#section-13.1" class="section-number selfRef">13.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2404">[RFC2404]</dt>
        <dd>
<span class="refAuthor">Madson, C.</span> and <span class="refAuthor">R. Glenn</span>, <span class="refTitle">"The Use of HMAC-SHA-1-96 within ESP and AH"</span>, <span class="seriesInfo">RFC 2404</span>, <span class="seriesInfo">DOI 10.17487/RFC2404</span>, <time datetime="1998-11" class="refDate">November 1998</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2404">https://www.rfc-editor.org/info/rfc2404</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4086">[RFC4086]</dt>
        <dd>
<span class="refAuthor">Eastlake 3rd, D.</span>, <span class="refAuthor">Schiller, J.</span>, and <span class="refAuthor">S. Crocker</span>, <span class="refTitle">"Randomness Requirements for Security"</span>, <span class="seriesInfo">BCP 106</span>, <span class="seriesInfo">RFC 4086</span>, <span class="seriesInfo">DOI 10.17487/RFC4086</span>, <time datetime="2005-06" class="refDate">June 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4086">https://www.rfc-editor.org/info/rfc4086</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4868">[RFC4868]</dt>
        <dd>
<span class="refAuthor">Kelly, S.</span> and <span class="refAuthor">S. Frankel</span>, <span class="refTitle">"Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec"</span>, <span class="seriesInfo">RFC 4868</span>, <span class="seriesInfo">DOI 10.17487/RFC4868</span>, <time datetime="2007-05" class="refDate">May 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4868">https://www.rfc-editor.org/info/rfc4868</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5869">[RFC5869]</dt>
        <dd>
<span class="refAuthor">Krawczyk, H.</span> and <span class="refAuthor">P. Eronen</span>, <span class="refTitle">"HMAC-based Extract-and-Expand Key Derivation Function (HKDF)"</span>, <span class="seriesInfo">RFC 5869</span>, <span class="seriesInfo">DOI 10.17487/RFC5869</span>, <time datetime="2010-05" class="refDate">May 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5869">https://www.rfc-editor.org/info/rfc5869</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6833">[RFC6833]</dt>
        <dd>
<span class="refAuthor">Fuller, V.</span> and <span class="refAuthor">D. Farinacci</span>, <span class="refTitle">"Locator/ID Separation Protocol (LISP) Map-Server Interface"</span>, <span class="seriesInfo">RFC 6833</span>, <span class="seriesInfo">DOI 10.17487/RFC6833</span>, <time datetime="2013-01" class="refDate">January 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6833">https://www.rfc-editor.org/info/rfc6833</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8085">[RFC8085]</dt>
        <dd>
<span class="refAuthor">Eggert, L.</span>, <span class="refAuthor">Fairhurst, G.</span>, and <span class="refAuthor">G. Shepherd</span>, <span class="refTitle">"UDP Usage Guidelines"</span>, <span class="seriesInfo">BCP 145</span>, <span class="seriesInfo">RFC 8085</span>, <span class="seriesInfo">DOI 10.17487/RFC8085</span>, <time datetime="2017-03" class="refDate">March 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8085">https://www.rfc-editor.org/info/rfc8085</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8126">[RFC8126]</dt>
        <dd>
<span class="refAuthor">Cotton, M.</span>, <span class="refAuthor">Leiba, B.</span>, and <span class="refAuthor">T. Narten</span>, <span class="refTitle">"Guidelines for Writing an IANA Considerations Section in RFCs"</span>, <span class="seriesInfo">BCP 26</span>, <span class="seriesInfo">RFC 8126</span>, <span class="seriesInfo">DOI 10.17487/RFC8126</span>, <time datetime="2017-06" class="refDate">June 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8126">https://www.rfc-editor.org/info/rfc8126</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8174">[RFC8174]</dt>
        <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9300">[RFC9300]</dt>
        <dd>
<span class="refAuthor">Farinacci, D.</span>, <span class="refAuthor">Fuller, V.</span>, <span class="refAuthor">Meyer, D.</span>, <span class="refAuthor">Lewis, D.</span>, and <span class="refAuthor">A. Cabellos, Ed.</span>, <span class="refTitle">"The Locator/ID Separation Protocol (LISP)"</span>, <span class="seriesInfo">RFC 9300</span>, <span class="seriesInfo">DOI 10.17487/RFC9300</span>, <time datetime="2022-10" class="refDate">October 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9300">https://www.rfc-editor.org/info/rfc9300</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9302">[RFC9302]</dt>
        <dd>
<span class="refAuthor">Iannone, L.</span>, <span class="refAuthor">Saucez, D.</span>, and <span class="refAuthor">O. Bonaventure</span>, <span class="refTitle">"Locator/ID Separation Protocol (LISP) Map-Versioning"</span>, <span class="seriesInfo">RFC 9302</span>, <span class="seriesInfo">DOI 10.17487/RFC9302</span>, <time datetime="2022-10" class="refDate">October 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9302">https://www.rfc-editor.org/info/rfc9302</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9303">[RFC9303]</dt>
        <dd>
<span class="refAuthor">Maino, F.</span>, <span class="refAuthor">Ermagan, V.</span>, <span class="refAuthor">Cabellos, A.</span>, and <span class="refAuthor">D. Saucez</span>, <span class="refTitle">"Locator/ID Separation Protocol Security (LISP-SEC)"</span>, <span class="seriesInfo">RFC 9303</span>, <span class="seriesInfo">DOI 10.17487/RFC9303</span>, <time datetime="2022-10" class="refDate">October 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9303">https://www.rfc-editor.org/info/rfc9303</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9304">[RFC9304]</dt>
      <dd>
<span class="refAuthor">Boucadair, M.</span> and <span class="refAuthor">C. Jacquenet</span>, <span class="refTitle">"Locator/ID Separation Protocol (LISP): Shared Extension Message and IANA Registry for Packet Type Allocations"</span>, <span class="seriesInfo">RFC 9304</span>, <span class="seriesInfo">DOI 10.17487/RFC9304</span>, <time datetime="2022-10" class="refDate">October 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9304">https://www.rfc-editor.org/info/rfc9304</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-13.2">
        <h3 id="name-informative-references">
<a href="#section-13.2" class="section-number selfRef">13.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="AFN">[AFN]</dt>
        <dd>
<span class="refAuthor">IANA</span>, <span class="refTitle">"Address Family Numbers"</span>, <span>&lt;<a href="http://www.iana.org/assignments/address-family-numbers/">http://www.iana.org/assignments/address-family-numbers/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-lisp-ecdsa-auth">[ECDSA-AUTH]</dt>
        <dd>
<span class="refAuthor">Farinacci, D.</span> and <span class="refAuthor">E. Nordmark</span>, <span class="refTitle">"LISP Control-Plane ECDSA Authentication and Authorization"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-lisp-ecdsa-auth-09</span>, <time datetime="2022-09-11" class="refDate">11 September 2022</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-lisp-ecdsa-auth-09">https://datatracker.ietf.org/doc/html/draft-ietf-lisp-ecdsa-auth-09</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-lisp-eid-anonymity">[EID-ANONYMITY]</dt>
        <dd>
<span class="refAuthor">Farinacci, D.</span>, <span class="refAuthor">Pillay-Esnault, P.</span>, and <span class="refAuthor">W. Haddad</span>, <span class="refTitle">"LISP EID Anonymity"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-lisp-eid-anonymity-13</span>, <time datetime="2022-09-11" class="refDate">11 September 2022</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-lisp-eid-anonymity-13">https://datatracker.ietf.org/doc/html/draft-ietf-lisp-eid-anonymity-13</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="EID-MOBILITY">[EID-MOBILITY]</dt>
        <dd>
<span class="refAuthor">Portoles, M.</span>, <span class="refAuthor">Ashtaputre, V.</span>, <span class="refAuthor">Maino, F.</span>, <span class="refAuthor">Moreno, V.</span>, and <span class="refAuthor">D. Farinacci</span>, <span class="refTitle">"LISP L2/L3 EID Mobility Using a Unified Control Plane"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-lisp-eid-mobility-10</span>, <time datetime="2022-07-10" class="refDate">10 July 2022</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-lisp-eid-mobility-10">https://datatracker.ietf.org/doc/html/draft-ietf-lisp-eid-mobility-10</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="GTP-3GPP">[GTP-3GPP]</dt>
        <dd>
<span class="refAuthor">3GPP</span>, <span class="refTitle">"General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTPv1-U)"</span>, <span class="refContent">TS.29.281</span>, <time datetime="2022-06" class="refDate">June 2022</time>, <span>&lt;<a href="https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1699">https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1699</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.herbert-intarea-ila">[INTAREA-ILA]</dt>
        <dd>
<span class="refAuthor">Herbert, T.</span> and <span class="refAuthor">P. Lapukhov</span>, <span class="refTitle">"Identifier-locator addressing for IPv6"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-herbert-intarea-ila-01</span>, <time datetime="2018-03-05" class="refDate">5 March 2018</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-herbert-intarea-ila-01">https://datatracker.ietf.org/doc/html/draft-herbert-intarea-ila-01</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-lisp-mn">[LISP-MN]</dt>
        <dd>
<span class="refAuthor">Farinacci, D.</span>, <span class="refAuthor">Lewis, D.</span>, <span class="refAuthor">Meyer, D.</span>, and <span class="refAuthor">C. White</span>, <span class="refTitle">"LISP Mobile Node"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-lisp-mn-12</span>, <time datetime="2022-07-24" class="refDate">24 July 2022</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-lisp-mn-12">https://datatracker.ietf.org/doc/html/draft-ietf-lisp-mn-12</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-lisp-pubsub">[LISP-PUBSUB]</dt>
        <dd>
<span class="refAuthor">Rodriguez-Natal, A.</span>, <span class="refAuthor">Ermagan, V.</span>, <span class="refAuthor">Cabellos-Aparicio, A.</span>, <span class="refAuthor">Barkai, S.</span>, and <span class="refAuthor">M. Boucadair</span>, <span class="refTitle">"Publish/Subscribe Functionality for LISP"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-lisp-pubsub-09</span>, <time datetime="2021-06-28" class="refDate">28 June 2021</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-lisp-pubsub-09">https://datatracker.ietf.org/doc/html/draft-ietf-lisp-pubsub-09</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="NVO3-VXLAN-GPE">[NVO3-VXLAN-GPE]</dt>
        <dd>
<span class="refAuthor">Maino, F., Ed.</span>, <span class="refAuthor">Kreeger, L., Ed.</span>, and <span class="refAuthor">U. Elzur, Ed.</span>, <span class="refTitle">"Generic Protocol Extension for VXLAN (VXLAN-GPE)"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-nvo3-vxlan-gpe-12</span>, <time datetime="2021-09-22" class="refDate">22 September 2021</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-vxlan-gpe-12">https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-vxlan-gpe-12</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-opsec-icmp-filtering">[OPSEC-ICMP-FILTER]</dt>
        <dd>
<span class="refAuthor">Gont, F.</span>, <span class="refAuthor">Gont, G.</span>, and <span class="refAuthor">C. Pignataro</span>, <span class="refTitle">"Recommendations for filtering ICMP messages"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-opsec-icmp-filtering-04</span>, <time datetime="2013-07-03" class="refDate">3 July 2013</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-opsec-icmp-filtering-04">https://datatracker.ietf.org/doc/html/draft-ietf-opsec-icmp-filtering-04</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC1035">[RFC1035]</dt>
        <dd>
<span class="refAuthor">Mockapetris, P.</span>, <span class="refTitle">"Domain names - implementation and specification"</span>, <span class="seriesInfo">STD 13</span>, <span class="seriesInfo">RFC 1035</span>, <span class="seriesInfo">DOI 10.17487/RFC1035</span>, <time datetime="1987-11" class="refDate">November 1987</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1035">https://www.rfc-editor.org/info/rfc1035</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC1071">[RFC1071]</dt>
        <dd>
<span class="refAuthor">Braden, R.</span>, <span class="refAuthor">Borman, D.</span>, and <span class="refAuthor">C. Partridge</span>, <span class="refTitle">"Computing the Internet checksum"</span>, <span class="seriesInfo">RFC 1071</span>, <span class="seriesInfo">DOI 10.17487/RFC1071</span>, <time datetime="1988-09" class="refDate">September 1988</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1071">https://www.rfc-editor.org/info/rfc1071</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2890">[RFC2890]</dt>
        <dd>
<span class="refAuthor">Dommety, G.</span>, <span class="refTitle">"Key and Sequence Number Extensions to GRE"</span>, <span class="seriesInfo">RFC 2890</span>, <span class="seriesInfo">DOI 10.17487/RFC2890</span>, <time datetime="2000-09" class="refDate">September 2000</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2890">https://www.rfc-editor.org/info/rfc2890</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4984">[RFC4984]</dt>
        <dd>
<span class="refAuthor">Meyer, D., Ed.</span>, <span class="refAuthor">Zhang, L., Ed.</span>, and <span class="refAuthor">K. Fall, Ed.</span>, <span class="refTitle">"Report from the IAB Workshop on Routing and Addressing"</span>, <span class="seriesInfo">RFC 4984</span>, <span class="seriesInfo">DOI 10.17487/RFC4984</span>, <time datetime="2007-09" class="refDate">September 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4984">https://www.rfc-editor.org/info/rfc4984</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6830">[RFC6830]</dt>
        <dd>
<span class="refAuthor">Farinacci, D.</span>, <span class="refAuthor">Fuller, V.</span>, <span class="refAuthor">Meyer, D.</span>, and <span class="refAuthor">D. Lewis</span>, <span class="refTitle">"The Locator/ID Separation Protocol (LISP)"</span>, <span class="seriesInfo">RFC 6830</span>, <span class="seriesInfo">DOI 10.17487/RFC6830</span>, <time datetime="2013-01" class="refDate">January 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6830">https://www.rfc-editor.org/info/rfc6830</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6831">[RFC6831]</dt>
        <dd>
<span class="refAuthor">Farinacci, D.</span>, <span class="refAuthor">Meyer, D.</span>, <span class="refAuthor">Zwiebel, J.</span>, and <span class="refAuthor">S. Venaas</span>, <span class="refTitle">"The Locator/ID Separation Protocol (LISP) for Multicast Environments"</span>, <span class="seriesInfo">RFC 6831</span>, <span class="seriesInfo">DOI 10.17487/RFC6831</span>, <time datetime="2013-01" class="refDate">January 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6831">https://www.rfc-editor.org/info/rfc6831</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6832">[RFC6832]</dt>
        <dd>
<span class="refAuthor">Lewis, D.</span>, <span class="refAuthor">Meyer, D.</span>, <span class="refAuthor">Farinacci, D.</span>, and <span class="refAuthor">V. Fuller</span>, <span class="refTitle">"Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites"</span>, <span class="seriesInfo">RFC 6832</span>, <span class="seriesInfo">DOI 10.17487/RFC6832</span>, <time datetime="2013-01" class="refDate">January 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6832">https://www.rfc-editor.org/info/rfc6832</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6836">[RFC6836]</dt>
        <dd>
<span class="refAuthor">Fuller, V.</span>, <span class="refAuthor">Farinacci, D.</span>, <span class="refAuthor">Meyer, D.</span>, and <span class="refAuthor">D. Lewis</span>, <span class="refTitle">"Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)"</span>, <span class="seriesInfo">RFC 6836</span>, <span class="seriesInfo">DOI 10.17487/RFC6836</span>, <time datetime="2013-01" class="refDate">January 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6836">https://www.rfc-editor.org/info/rfc6836</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6837">[RFC6837]</dt>
        <dd>
<span class="refAuthor">Lear, E.</span>, <span class="refTitle">"NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database"</span>, <span class="seriesInfo">RFC 6837</span>, <span class="seriesInfo">DOI 10.17487/RFC6837</span>, <time datetime="2013-01" class="refDate">January 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6837">https://www.rfc-editor.org/info/rfc6837</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6973">[RFC6973]</dt>
        <dd>
<span class="refAuthor">Cooper, A.</span>, <span class="refAuthor">Tschofenig, H.</span>, <span class="refAuthor">Aboba, B.</span>, <span class="refAuthor">Peterson, J.</span>, <span class="refAuthor">Morris, J.</span>, <span class="refAuthor">Hansen, M.</span>, and <span class="refAuthor">R. Smith</span>, <span class="refTitle">"Privacy Considerations for Internet Protocols"</span>, <span class="seriesInfo">RFC 6973</span>, <span class="seriesInfo">DOI 10.17487/RFC6973</span>, <time datetime="2013-07" class="refDate">July 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6973">https://www.rfc-editor.org/info/rfc6973</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7348">[RFC7348]</dt>
        <dd>
<span class="refAuthor">Mahalingam, M.</span>, <span class="refAuthor">Dutt, D.</span>, <span class="refAuthor">Duda, K.</span>, <span class="refAuthor">Agarwal, P.</span>, <span class="refAuthor">Kreeger, L.</span>, <span class="refAuthor">Sridhar, T.</span>, <span class="refAuthor">Bursell, M.</span>, and <span class="refAuthor">C. Wright</span>, <span class="refTitle">"Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks"</span>, <span class="seriesInfo">RFC 7348</span>, <span class="seriesInfo">DOI 10.17487/RFC7348</span>, <time datetime="2014-08" class="refDate">August 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7348">https://www.rfc-editor.org/info/rfc7348</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7835">[RFC7835]</dt>
        <dd>
<span class="refAuthor">Saucez, D.</span>, <span class="refAuthor">Iannone, L.</span>, and <span class="refAuthor">O. Bonaventure</span>, <span class="refTitle">"Locator/ID Separation Protocol (LISP) Threat Analysis"</span>, <span class="seriesInfo">RFC 7835</span>, <span class="seriesInfo">DOI 10.17487/RFC7835</span>, <time datetime="2016-04" class="refDate">April 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7835">https://www.rfc-editor.org/info/rfc7835</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8060">[RFC8060]</dt>
        <dd>
<span class="refAuthor">Farinacci, D.</span>, <span class="refAuthor">Meyer, D.</span>, and <span class="refAuthor">J. Snijders</span>, <span class="refTitle">"LISP Canonical Address Format (LCAF)"</span>, <span class="seriesInfo">RFC 8060</span>, <span class="seriesInfo">DOI 10.17487/RFC8060</span>, <time datetime="2017-02" class="refDate">February 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8060">https://www.rfc-editor.org/info/rfc8060</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8061">[RFC8061]</dt>
        <dd>
<span class="refAuthor">Farinacci, D.</span> and <span class="refAuthor">B. Weis</span>, <span class="refTitle">"Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality"</span>, <span class="seriesInfo">RFC 8061</span>, <span class="seriesInfo">DOI 10.17487/RFC8061</span>, <time datetime="2017-02" class="refDate">February 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8061">https://www.rfc-editor.org/info/rfc8061</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8111">[RFC8111]</dt>
        <dd>
<span class="refAuthor">Fuller, V.</span>, <span class="refAuthor">Lewis, D.</span>, <span class="refAuthor">Ermagan, V.</span>, <span class="refAuthor">Jain, A.</span>, and <span class="refAuthor">A. Smirnov</span>, <span class="refTitle">"Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT)"</span>, <span class="seriesInfo">RFC 8111</span>, <span class="seriesInfo">DOI 10.17487/RFC8111</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8111">https://www.rfc-editor.org/info/rfc8111</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8378">[RFC8378]</dt>
        <dd>
<span class="refAuthor">Moreno, V.</span> and <span class="refAuthor">D. Farinacci</span>, <span class="refTitle">"Signal-Free Locator/ID Separation Protocol (LISP) Multicast"</span>, <span class="seriesInfo">RFC 8378</span>, <span class="seriesInfo">DOI 10.17487/RFC8378</span>, <time datetime="2018-05" class="refDate">May 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8378">https://www.rfc-editor.org/info/rfc8378</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8402">[RFC8402]</dt>
        <dd>
<span class="refAuthor">Filsfils, C., Ed.</span>, <span class="refAuthor">Previdi, S., Ed.</span>, <span class="refAuthor">Ginsberg, L.</span>, <span class="refAuthor">Decraene, B.</span>, <span class="refAuthor">Litkowski, S.</span>, and <span class="refAuthor">R. Shakir</span>, <span class="refTitle">"Segment Routing Architecture"</span>, <span class="seriesInfo">RFC 8402</span>, <span class="seriesInfo">DOI 10.17487/RFC8402</span>, <time datetime="2018-07" class="refDate">July 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8402">https://www.rfc-editor.org/info/rfc8402</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9147">[RFC9147]</dt>
        <dd>
<span class="refAuthor">Rescorla, E.</span>, <span class="refAuthor">Tschofenig, H.</span>, and <span class="refAuthor">N. Modadugu</span>, <span class="refTitle">"The Datagram Transport Layer Security (DTLS) Protocol Version 1.3"</span>, <span class="seriesInfo">RFC 9147</span>, <span class="seriesInfo">DOI 10.17487/RFC9147</span>, <time datetime="2022-04" class="refDate">April 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9147">https://www.rfc-editor.org/info/rfc9147</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9299">[RFC9299]</dt>
        <dd>
<span class="refAuthor">Cabellos, A.</span> and <span class="refAuthor">D. Saucez, Ed.</span>, <span class="refTitle">"An Architectural Introduction to the Locator/ID Separation Protocol (LISP)"</span>, <span class="seriesInfo">RFC 9299</span>, <span class="seriesInfo">DOI 10.17487/RFC9299</span>, <time datetime="2022-10" class="refDate">October 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9299">https://www.rfc-editor.org/info/rfc9299</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9305">[RFC9305]</dt>
      <dd>
<span class="refAuthor">Maino, F., Ed.</span>, <span class="refAuthor">Lemon, J.</span>, <span class="refAuthor">Agarwal, P.</span>, <span class="refAuthor">Lewis, D.</span>, and <span class="refAuthor">M. Smith</span>, <span class="refTitle">"Locator/ID Separation Protocol (LISP) Generic Protocol Extension"</span>, <span class="seriesInfo">RFC 9305</span>, <span class="seriesInfo">DOI 10.17487/RFC9305</span>, <time datetime="2022-10" class="refDate">October 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9305">https://www.rfc-editor.org/info/rfc9305</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<section id="appendix-A">
      <h2 id="name-acknowledgments">
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
      </h2>
<p id="appendix-A-1">The original authors would like to thank <span class="contact-name">Greg Schudel</span>, <span class="contact-name">Darrel Lewis</span>,
    <span class="contact-name">John Zwiebel</span>, <span class="contact-name">Andrew Partan</span>, <span class="contact-name">Dave Meyer</span>, <span class="contact-name">Isidor Kouvelas</span>, <span class="contact-name">Jesper     Skriver</span>,  and members of the lisp@ietf.org mailing
    list for their feedback and helpful suggestions.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
<p id="appendix-A-2"> Special thanks are due to <span class="contact-name">Noel Chiappa</span> for his extensive work
    and thought about caching in Map-Resolvers.<a href="#appendix-A-2" class="pilcrow">¶</a></p>
<p id="appendix-A-3">The current authors would like to give a sincere thank you to
    the people who help put LISP on the Standards Track in the IETF.  They
    include <span class="contact-name">Joel Halpern</span>, <span class="contact-name">Luigi Iannone</span>, <span class="contact-name">Deborah Brungard</span>, <span class="contact-name">Fabio     Maino</span>, <span class="contact-name">Scott Bradner</span>, <span class="contact-name">Kyle Rose</span>, <span class="contact-name">Takeshi Takahashi</span>, <span class="contact-name">Sarah Banks</span>,
    <span class="contact-name">Pete Resnick</span>, <span class="contact-name">Colin Perkins</span>, <span class="contact-name">Mirja Kühlewind</span>, <span class="contact-name">Francis Dupont</span>,
    <span class="contact-name">Benjamin Kaduk</span>, <span class="contact-name">Eric Rescorla</span>, <span class="contact-name">Alvaro Retana</span>, <span class="contact-name">Alexey Melnikov</span>,
    <span class="contact-name">Alissa Cooper</span>, <span class="contact-name">Suresh Krishnan</span>, <span class="contact-name">Alberto Rodriguez-Natal</span>, <span class="contact-name">Vina     Ermagan</span>, <span class="contact-name">Mohamed Boucadair</span>, <span class="contact-name">Brian Trammell</span>, <span class="contact-name">Sabrina Tanamal</span>, and
    <span class="contact-name">John Drake</span>. The contributions they offered greatly added to the
    security, scale, and robustness of the LISP architecture and
    protocols.<a href="#appendix-A-3" class="pilcrow">¶</a></p>
</section>
<div id="authors-addresses">
<section id="appendix-B">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Dino Farinacci</span></div>
<div dir="auto" class="left"><span class="org">lispers.net</span></div>
<div dir="auto" class="left">
<span class="locality">San Jose</span>, <span class="region">CA</span> </div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:farinacci@gmail.com" class="email">farinacci@gmail.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Fabio Maino</span></div>
<div dir="auto" class="left"><span class="org">Cisco Systems</span></div>
<div dir="auto" class="left">
<span class="locality">San Jose</span>, <span class="region">CA</span> </div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:fmaino@cisco.com" class="email">fmaino@cisco.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Vince Fuller</span></div>
<div dir="auto" class="left"><span class="org">vaf.net Internet Consulting</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:vince.fuller@gmail.com" class="email">vince.fuller@gmail.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Albert Cabellos (<span class="role">editor</span>)</span></div>
<div dir="auto" class="left"><span class="org">Universitat Politecnica de Catalunya</span></div>
<div dir="auto" class="left"><span class="street-address">c/ Jordi Girona s/n</span></div>
<div dir="auto" class="left">
<span class="postal-code">08034</span> <span class="locality">Barcelona</span> </div>
<div dir="auto" class="left"><span class="country-name">Spain</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:acabello@ac.upc.edu" class="email">acabello@ac.upc.edu</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>