File: rfc9299.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 (2752 lines) | stat: -rw-r--r-- 141,205 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 9299: An Architectural Introduction to the Locator/ID Separation Protocol (LISP)</title>
<meta content="Albert Cabellos" name="author">
<meta content="Damien Saucez" name="author">
<meta content="
       This document describes the architecture of the Locator/ID Separation
 Protocol (LISP), making it easier to read the rest of the LISP
 specifications and providing a basis for discussion about the details
 of the LISP protocols. This document is used for introductory purposes; 
 more details can be found in the protocol specifications, RFCs 9300 and 9301. 
    " name="description">
<meta content="xml2rfc 3.15.1" name="generator">
<meta content="LISP" name="keyword">
<meta content="Architecture" name="keyword">
<meta content="9299" 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="rfc9299.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/rfc9299" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-lisp-introduction-15" 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 9299</td>
<td class="center">LISP Introduction</td>
<td class="right">October 2022</td>
</tr></thead>
<tfoot><tr>
<td class="left">Cabellos &amp; Saucez</td>
<td class="center">Informational</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/rfc9299" class="eref">9299</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Informational</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">A. Cabellos</div>
<div class="org">Universitat Politecnica de Catalunya</div>
</div>
<div class="author">
      <div class="author-name">D. Saucez, <span class="editor">Ed.</span>
</div>
<div class="org">Inria</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9299</h1>
<h1 id="title">An Architectural Introduction to the Locator/ID Separation Protocol (LISP)</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 architecture of the Locator/ID Separation
 Protocol (LISP), making it easier to read the rest of the LISP
 specifications and providing a basis for discussion about the details
 of the LISP protocols. This document is used for introductory purposes; 
 more details can be found in the protocol specifications, RFCs 9300 and 9301.<a href="#section-abstract-1" 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 document is not an Internet Standards Track specification; it is
            published for informational purposes.<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).  Not all documents
            approved by the IESG are candidates for any level of Internet
            Standard; see 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/rfc9299">https://www.rfc-editor.org/info/rfc9299</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>
</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-definitions-of-terms" class="internal xref">Definitions of Terms</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-lisp-architecture" class="internal xref">LISP Architecture</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1" class="keepWithNext"><a href="#section-3.1" class="auto internal xref">3.1</a>.  <a href="#name-design-principles" class="internal xref">Design Principles</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2">
                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="auto internal xref">3.2</a>.  <a href="#name-overview-of-the-architectur" class="internal xref">Overview of the Architecture</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.3">
                <p id="section-toc.1-1.3.2.3.1"><a href="#section-3.3" class="auto internal xref">3.3</a>.  <a href="#name-data-plane" class="internal xref">Data Plane</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.3.2.1">
                    <p id="section-toc.1-1.3.2.3.2.1.1"><a href="#section-3.3.1" class="auto internal xref">3.3.1</a>.  <a href="#name-lisp-encapsulation" class="internal xref">LISP Encapsulation</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.3.2.2">
                    <p id="section-toc.1-1.3.2.3.2.2.1"><a href="#section-3.3.2" class="auto internal xref">3.3.2</a>.  <a href="#name-lisp-forwarding-state" class="internal xref">LISP Forwarding State</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.4">
                <p id="section-toc.1-1.3.2.4.1"><a href="#section-3.4" class="auto internal xref">3.4</a>.  <a href="#name-control-plane" class="internal xref">Control Plane</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.4.2.1">
                    <p id="section-toc.1-1.3.2.4.2.1.1"><a href="#section-3.4.1" class="auto internal xref">3.4.1</a>.  <a href="#name-lisp-mappings" class="internal xref">LISP Mappings</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.4.2.2">
                    <p id="section-toc.1-1.3.2.4.2.2.1"><a href="#section-3.4.2" class="auto internal xref">3.4.2</a>.  <a href="#name-mapping-system-interface" class="internal xref">Mapping System Interface</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.4.2.3">
                    <p id="section-toc.1-1.3.2.4.2.3.1"><a href="#section-3.4.3" class="auto internal xref">3.4.3</a>.  <a href="#name-mapping-system" class="internal xref">Mapping System</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.5">
                <p id="section-toc.1-1.3.2.5.1"><a href="#section-3.5" class="auto internal xref">3.5</a>.  <a href="#name-internetworking-mechanisms" class="internal xref">Internetworking Mechanisms</a></p>
</li>
            </ul>
</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-lisp-operational-mechanisms" class="internal xref">LISP Operational Mechanisms</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="auto internal xref">4.1</a>.  <a href="#name-cache-management" class="internal xref">Cache Management</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2">
                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="auto internal xref">4.2</a>.  <a href="#name-rloc-reachability" class="internal xref">RLOC Reachability</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.3">
                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="auto internal xref">4.3</a>.  <a href="#name-etr-synchronization" class="internal xref">ETR Synchronization</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.4">
                <p id="section-toc.1-1.4.2.4.1"><a href="#section-4.4" class="auto internal xref">4.4</a>.  <a href="#name-mtu-handling" class="internal xref">MTU Handling</a></p>
</li>
            </ul>
</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-mobility" class="internal xref">Mobility</a></p>
</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-multicast" class="internal xref">Multicast</a></p>
</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-use-cases" class="internal xref">Use Cases</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-traffic-engineering" class="internal xref">Traffic Engineering</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.2">
                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="auto internal xref">7.2</a>.  <a href="#name-lisp-for-ipv6-co-existence" class="internal xref">LISP for IPv6 Co-existence</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.3">
                <p id="section-toc.1-1.7.2.3.1"><a href="#section-7.3" class="auto internal xref">7.3</a>.  <a href="#name-lisp-for-virtual-private-ne" class="internal xref">LISP for Virtual Private Networks</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.4">
                <p id="section-toc.1-1.7.2.4.1"><a href="#section-7.4" class="auto internal xref">7.4</a>.  <a href="#name-lisp-for-virtual-machine-mo" class="internal xref">LISP for Virtual Machine Mobility in Data Centers</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-security-considerations" class="internal xref">Security Considerations</a></p>
</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-iana-considerations" class="internal xref">IANA 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-references" class="internal xref">References</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.1">
                <p id="section-toc.1-1.10.2.1.1"><a href="#section-10.1" class="auto internal xref">10.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.10.2.2">
                <p id="section-toc.1-1.10.2.2.1"><a href="#section-10.2" class="auto internal xref">10.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.11">
            <p id="section-toc.1-1.11.1"><a href="#appendix-A" class="auto internal xref">Appendix A</a>.  <a href="#name-a-brief-history-of-location" class="internal xref">A Brief History of Location/Identity Separation</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.1">
                <p id="section-toc.1-1.11.2.1.1"><a href="#appendix-A.1" class="auto internal xref">A.1</a>.  <a href="#name-old-lisp-models" class="internal xref">Old LISP Models</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#appendix-B" 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.13">
            <p id="section-toc.1-1.13.1"><a href="#appendix-C" 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">This document introduces the Locator/ID Separation Protocol (LISP) architecture
      <span>[<a href="#RFC9300" class="cite xref">RFC9300</a>]</span> <span>[<a href="#RFC9301" class="cite xref">RFC9301</a>]</span>, its
      main operational mechanisms, and its design rationale. Fundamentally, LISP is
      built following a well-known architectural idea: decoupling the overloaded semantics of IP addresses. As pointed out by <span class="contact-name">Noel Chiappa</span>
        <span>[<a href="#RFC4984" class="cite xref">RFC4984</a>]</span>, currently, IP addresses identify
      both the topological location of a network attachment point as well
      as the node's identity.  However, nodes and
 routing have fundamentally different requirements.  On one hand,
 routing systems require that addresses be aggregatable and have
 topological meaning; on the other hand, nodes must be identified
 independently of their current location <span>[<a href="#RFC4984" class="cite xref">RFC4984</a>]</span>.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">LISP creates two separate namespaces, Endpoint Identifiers (EIDs) and
 Routing Locators (RLOCs). Both are 
 syntactically identical to the current IPv4 and IPv6 addresses.  However, EIDs
 are used to uniquely identify nodes irrespective of their topological
 location and are typically routed intra-domain. RLOCs are assigned
 topologically to network attachment points and are typically routed
 inter-domain.  With LISP, the edge of the Internet (where the nodes
 are connected) and the core (where inter-domain routing occurs) can be
 logically separated. LISP-capable routers interconnect the two logical spaces.
 LISP also introduces a database, called the
 Mapping System, to store and retrieve mappings between identity and
 location.  LISP-capable routers exchange packets over the Internet
 core by encapsulating them to the appropriate location.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">In summary:<a href="#section-1-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1-4.1">RLOCs have meaning only in the underlay network, that is, the
 underlying core routing system.<a href="#section-1-4.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-4.2">EIDs have meaning only in the overlay network, which is the
 encapsulation relationship between LISP-capable routers.<a href="#section-1-4.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-4.3">The LISP edge maps EIDs to RLOCs.<a href="#section-1-4.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-4.4">Within the underlay network, RLOCs have both Locator and
        identifier semantics.<a href="#section-1-4.4" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-4.5">An EID within a LISP site carries both identifier and Locator
        semantics to other nodes within that site.<a href="#section-1-4.5" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-4.6">An EID within a LISP site carries identifier and limited Locator
        semantics to nodes at other LISP sites (i.e., enough Locator
        information to tell that the EID is external to the site).<a href="#section-1-4.6" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-1-5">The relationship described above is not unique to LISP, and it is
    common to other overlay technologies.<a href="#section-1-5" class="pilcrow">¶</a></p>
<p id="section-1-6">   The initial motivation in the LISP effort is to be found in the
   routing scalability problem <span>[<a href="#RFC4984" class="cite xref">RFC4984</a>]</span>, where, if LISP were to be
   completely deployed, the Internet core is populated with RLOCs while
   Traffic Engineering (TE) mechanisms are pushed to the Mapping System.   
In such a scenario, RLOCs are quasi-static (i.e., low
      churn), hence making the routing system scalable <span>[<a href="#Quoitin" class="cite xref">Quoitin</a>]</span>, while EIDs can roam anywhere with no churn to the
      underlying global routing system. <span>[<a href="#RFC7215" class="cite xref">RFC7215</a>]</span>
      discusses the impact of LISP on the global routing system during the
      transition period. However, the separation between location and identity
      that LISP offers makes it suitable for use in additional scenarios, such
      as TE, multihoming, and mobility among others.<a href="#section-1-6" class="pilcrow">¶</a></p>
<p id="section-1-7">This document describes the LISP architecture and its main
      operational mechanisms as well as its design rationale. It is important
      to note that this document does not specify or complement LISP. The
      interested reader should refer to the main LISP 
      specifications (see <span>[<a href="#RFC9300" class="cite xref">RFC9300</a>]</span> and <span>[<a href="#RFC9301" class="cite xref">RFC9301</a>]</span>), as well as the
      complementary documents (i.e., <span>[<a href="#RFC6831" class="cite xref">RFC6831</a>]</span>, <span>[<a href="#RFC6832" class="cite xref">RFC6832</a>]</span>, <span>[<a href="#RFC9302" class="cite xref">RFC9302</a>]</span>, <span>[<a href="#RFC6835" class="cite xref">RFC6835</a>]</span>, <span>[<a href="#RFC6836" class="cite xref">RFC6836</a>]</span>, and <span>[<a href="#RFC7052" class="cite xref">RFC7052</a>]</span>) for the
      protocol specifications along with the LISP deployment guidelines <span>[<a href="#RFC7215" class="cite xref">RFC7215</a>]</span>.<a href="#section-1-7" class="pilcrow">¶</a></p>
</section>
<section id="section-2">
      <h2 id="name-definitions-of-terms">
<a href="#section-2" class="section-number selfRef">2. </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-2-1">
        <dt id="section-2-1.1">Endpoint Identifier (EID):</dt>
        <dd style="margin-left: 1.5em" id="section-2-1.2">Addresses used to uniquely identify nodes irrespective
 of their topological location. Typically routed
 intra-domain.<a href="#section-2-1.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-1.3">Routing Locator (RLOC):</dt>
        <dd style="margin-left: 1.5em" id="section-2-1.4">Addresses assigned topologically to network attachment
 points. Typically routed inter-domain.<a href="#section-2-1.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-1.5">Ingress Tunnel Router (ITR):</dt>
        <dd style="margin-left: 1.5em" id="section-2-1.6">A LISP-capable router that encapsulates packets from a LISP site
 towards the core network.<a href="#section-2-1.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-1.7">Egress Tunnel Router (ETR):</dt>
        <dd style="margin-left: 1.5em" id="section-2-1.8">A LISP-capable router that decapsulates packets from the core of
 the network towards a LISP site.<a href="#section-2-1.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-1.9">xTR:</dt>
        <dd style="margin-left: 1.5em" id="section-2-1.10">A router that implements both ITR and ETR functionalities.<a href="#section-2-1.10" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-1.11">Map-Request:</dt>
        <dd style="margin-left: 1.5em" id="section-2-1.12">A LISP signaling message used to request an EID-to-RLOC mapping.<a href="#section-2-1.12" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-1.13">Map-Reply:</dt>
        <dd style="margin-left: 1.5em" id="section-2-1.14">A LISP signaling message sent in response to a Map-Request that
 contains a resolved EID-to-RLOC mapping.<a href="#section-2-1.14" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-1.15">Map-Register:</dt>
        <dd style="margin-left: 1.5em" id="section-2-1.16">A LISP signaling message used to register an EID-to-RLOC
 mapping.<a href="#section-2-1.16" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-1.17">Map-Notify:</dt>
        <dd style="margin-left: 1.5em" id="section-2-1.18">A LISP signaling message sent in response of a Map-Register to
 acknowledge the correct reception of an EID-to-RLOC mapping.<a href="#section-2-1.18" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-2-2">This document describes the LISP architecture and does not introduce
      any new terms. The reader is referred to <span>[<a href="#RFC9300" class="cite xref">RFC9300</a>]</span>,
      <span>[<a href="#RFC9301" class="cite xref">RFC9301</a>]</span>, <span>[<a href="#RFC6831" class="cite xref">RFC6831</a>]</span>,
      <span>[<a href="#RFC6832" class="cite xref">RFC6832</a>]</span>, <span>[<a href="#RFC9302" class="cite xref">RFC9302</a>]</span>,
      <span>[<a href="#RFC6835" class="cite xref">RFC6835</a>]</span>, <span>[<a href="#RFC6836" class="cite xref">RFC6836</a>]</span>, <span>[<a href="#RFC7052" class="cite xref">RFC7052</a>]</span>, and <span>[<a href="#RFC7215" class="cite xref">RFC7215</a>]</span> for the complete definition of
      terms.<a href="#section-2-2" class="pilcrow">¶</a></p>
</section>
<section id="section-3">
      <h2 id="name-lisp-architecture">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-lisp-architecture" class="section-name selfRef">LISP Architecture</a>
      </h2>
<p id="section-3-1">This section presents the LISP architecture. It first details the
      design principles of LISP, and then it proceeds to describe its main aspects:
      data plane, control plane, and internetworking mechanisms.<a href="#section-3-1" class="pilcrow">¶</a></p>
<section id="section-3.1">
        <h3 id="name-design-principles">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-design-principles" class="section-name selfRef">Design Principles</a>
        </h3>
<p id="section-3.1-1">The LISP architecture is built on top of four basic design
        principles:<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3.1-2">
          <dt id="section-3.1-2.1">Locator/Identifier split:</dt>
          <dd style="margin-left: 1.5em" id="section-3.1-2.2">Decoupling the overloaded semantics of current IP addresses
   allows devices to have identity-based addresses that are separate
   from topologically meaningful addresses.  By allowing only the
   topologically meaningful addresses to be exposed to the Internet
   core, those topologically meaningful addresses can be aggregated to
   support substantial scaling.  Individual devices are assigned
   identity-based addresses that are not used for forwarding in the
   Internet core.<a href="#section-3.1-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-3.1-2.3">Overlay architecture:</dt>
          <dd style="margin-left: 1.5em" id="section-3.1-2.4"> This architecture overlays route packets over the current Internet, allowing
   deployment of new protocols without changing the current
   infrastructure; hence, this results in a low deployment cost.<a href="#section-3.1-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-3.1-2.5">Decoupled data plane and control plane:</dt>
          <dd style="margin-left: 1.5em" id="section-3.1-2.6"> Separating the
   data plane from the control plane allows them to scale independently
   and use different architectural approaches. This is important given
   that they typically have different requirements and allows for other
   data planes to be added. Even though the data plane and the control plane are
   decoupled, they are not completely isolated, because the LISP data plane may trigger
   control plane activity.<a href="#section-3.1-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-3.1-2.7">Incremental deployability:</dt>
          <dd style="margin-left: 1.5em" id="section-3.1-2.8"> This principle ensures that the protocol interoperates with the
   legacy Internet while providing some of the targeted benefits to
   early adopters.<a href="#section-3.1-2.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
<section id="section-3.2">
        <h3 id="name-overview-of-the-architectur">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-overview-of-the-architectur" class="section-name selfRef">Overview of the Architecture</a>
        </h3>
<p id="section-3.2-1">LISP architecturally splits the core from the edge of the
        Internet by creating two separate namespaces: Endpoint
        Identifiers (EIDs) and Routing Locators (RLOCs). The edge
        consists of LISP sites (e.g., an Autonomous System) that use
        EID addresses. EIDs are IPv4 or IPv6 addresses that uniquely
        identify communication end hosts and are assigned and
        configured by the same mechanisms that exist at the time of
        this writing. EIDs do not contain inter-domain topological
        information, and because of this, EIDs are usually routable at
        the edge (within LISP sites) but not in the core; see
         <a href="#sect-3.5" class="auto internal xref">Section 3.5</a> for discussion of LISP site
        internetworking with non-LISP sites and domains in the
        Internet.<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<p id="section-3.2-2">LISP sites (at the edge) are connected to the interconnecting core
 of the Internet by means of LISP-capable routers (e.g., border
 routers).  LISP sites are connected across the interconnecting core of the Internet
 using tunnels between the LISP-capable routers. When packets
 originated from a LISP site are flowing towards the core network, they
 ingress into an encapsulated tunnel via an Ingress Tunnel Router
 (ITR). When packets flow from the core network to a LISP site, they
 egress from an encapsulated tunnel to an Egress Tunnel Router
 (ETR). An xTR is a router that can perform both ITR and ETR
 operations. In this context, ITRs encapsulate packets, while ETRs
 decapsulate them; hence, LISP operates as an overlay on top of the
 current Internet core.<a href="#section-3.2-2" class="pilcrow">¶</a></p>
<span id="name-a-schema-of-the-lisp-archit"></span><figure id="figure-1">
          <div class="alignLeft art-text artwork" id="section-3.2-3.1">
<pre>
                       /-----------------\                 ---
                       |     Mapping     |                  |
                       .     System      |                  | Control
                      -|                 |`,                | Plane
                    ,' \-----------------/  .               |
                   /                         |             ---
   ,..,           -        _,....,,          |      ,..,    |
 /     `        ,'      ,-`        `',       |    /     `   |
/        \ +-----+   ,'              `,  +-----+ /        \ |
|  EID   |-| xTR |--/        RLOC     ,--| xTR |-|  EID   | | Data
| Space  |-|     |--|       Space     |--|     |-| Space  | | Plane
\        / +-----+  .                 /  +-----+ \        / |
 `.    .'            `.              ,'           `.    .'  |
   `'-`                `.,        ,.'               `'-`   ---
                          ``'''``
  LISP Site (Edge)            Core              LISP Site (Edge)
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-a-schema-of-the-lisp-archit" class="selfRef">A Schema of the LISP Architecture</a>
          </figcaption></figure>
<p id="section-3.2-4">With LISP, the core uses RLOCs. An RLOC is an IPv4 or IPv6
        address assigned to a core-facing network interface of an ITR or
        ETR.<a href="#section-3.2-4" class="pilcrow">¶</a></p>
<p id="section-3.2-5">A database that is typically distributed, called the Mapping System,
 stores mappings between EIDs and RLOCs. Such mappings relate
        the identity of the devices attached to LISP sites (EIDs) to the set
        of RLOCs configured at the LISP-capable routers servicing the site.
        Furthermore, the mappings also include TE policies
        and can be configured to achieve multihoming and load balancing. The
        LISP Mapping System is conceptually similar to the DNS, where it is
 organized as a distributed multi-organization network database. With
 LISP, ETRs register mappings, while ITRs retrieve them.<a href="#section-3.2-5" class="pilcrow">¶</a></p>
<p id="section-3.2-6">Finally, the LISP architecture emphasizes incremental
 deployment. Given that LISP represents an 
        overlay to the current Internet architecture, end hosts, as well as
        intra-domain and inter-domain routers, remain unchanged. The only required
        changes to the existing infrastructure are to routers connecting the
        EID space with the RLOC space. Additionally, LISP requires the deployment of
        an independent Mapping System; such a distributed database is a new
        network entity.<a href="#section-3.2-6" class="pilcrow">¶</a></p>
<p id="section-3.2-7">The following describes a simplified packet flow sequence between
 two nodes that are attached to LISP sites. Please note that typical
 LISP-capable routers are xTRs (both ITR and ETR). Client HostA wants
 to send a packet to server HostB.<a href="#section-3.2-7" class="pilcrow">¶</a></p>
<span id="name-packet-flow-sequence-in-lis"></span><figure id="figure-2">
          <div class="alignLeft art-text artwork" id="section-3.2-8.1">
<pre>
                         /----------------\
                         |     Mapping    |
                         |     System     |
                        .|                |-
                       ` \----------------/ `.
                     ,`                       \
                    /                          `.
                  ,'         _,..-..,,           ',
                 /         -`         `-,          \
               .'        ,'              \          `,
               `        '                 \           '
           +-----+     |                   | RLOC_B1+-----+
    HostA  |     |    |        RLOC         |-------|     |  HostB
    EID_A--|ITR_A|----|        Space        |       |ETR_B|--EID_B
           |     | RLOC_A1                  |-------|     |
           +-----+     |                   | RLOC_B2+-----+
                        ,                 /
                         \               /
                          `',         ,-`
                             ``''-''``
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-packet-flow-sequence-in-lis" class="selfRef">Packet Flow Sequence in LISP</a>
          </figcaption></figure>
<ol start="1" type="1" class="normal type-1" id="section-3.2-9">
          <li id="section-3.2-9.1">HostA retrieves the EID_B of HostB, typically querying the DNS
   and obtaining an A or AAAA record. 
            Then, it generates an IP packet as in the Internet. The packet
            has source address EID_A and destination address EID_B.<a href="#section-3.2-9.1" class="pilcrow">¶</a>
</li>
          <li id="section-3.2-9.2">The packet is forwarded towards ITR_A in the LISP site using
            standard intra-domain mechanisms.<a href="#section-3.2-9.2" class="pilcrow">¶</a>
</li>
          <li id="section-3.2-9.3">ITR_A, upon receiving the packet, queries the Mapping System to
            retrieve the Locator of ETR_B that is servicing HostB's EID_B. In order
            to do so, it uses a LISP control message called Map-Request. The
            message contains EID_B as the lookup key. In turn, it receives
            another LISP control message called Map-Reply. The message
            contains two Locators: RLOC_B1 and RLOC_B2. It also contains
            TE policies: priority and weight per Locator. Note that a
   Map-Reply can contain more Locators if needed. ITR_A can cache the mapping
   in local storage to speed up forwarding of subsequent
   packets.<a href="#section-3.2-9.3" class="pilcrow">¶</a>
</li>
          <li id="section-3.2-9.4">ITR_A encapsulates the packet towards RLOC_B1 (chosen according
            to the priorities/weights specified in the mapping). The packet contains two
            IP headers. The outer header has RLOC_A1 as source and RLOC_B1 as
            destination. The inner original header has EID_A as source and EID_B as
            destination. Furthermore, ITR_A adds a LISP header. More details
            about LISP encapsulation can be found in <a href="#encapsulation" class="auto internal xref">Section 3.3.1</a>.<a href="#section-3.2-9.4" class="pilcrow">¶</a>
</li>
          <li id="section-3.2-9.5">The encapsulated packet is forwarded over the interconnecting core as a
            normal IP packet, making the EID invisible from the core.<a href="#section-3.2-9.5" class="pilcrow">¶</a>
</li>
          <li id="section-3.2-9.6">Upon reception of the encapsulated packet by ETR_B, it
            decapsulates the packet and forwards it to HostB.<a href="#section-3.2-9.6" class="pilcrow">¶</a>
</li>
        </ol>
</section>
<section id="section-3.3">
        <h3 id="name-data-plane">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-data-plane" class="section-name selfRef">Data Plane</a>
        </h3>
<p id="section-3.3-1">This section provides a high-level description of the LISP data plane, 
 which is specified in detail in <span>[<a href="#RFC9300" class="cite xref">RFC9300</a>]</span>. The LISP data plane is responsible for 
        encapsulating and decapsulating data packets and caching the
        appropriate forwarding state. It includes two main entities, the ITR
        and the ETR. Both are LISP-capable routers that connect the EID with
 the RLOC space (ITR) and vice versa (ETR).<a href="#section-3.3-1" class="pilcrow">¶</a></p>
<div id="encapsulation">
<section id="section-3.3.1">
          <h4 id="name-lisp-encapsulation">
<a href="#section-3.3.1" class="section-number selfRef">3.3.1. </a><a href="#name-lisp-encapsulation" class="section-name selfRef">LISP Encapsulation</a>
          </h4>
<p id="section-3.3.1-1">ITRs encapsulate data packets towards ETRs. LISP data packets are
          encapsulated using UDP (port 4341). The source port is usually
   selected by the ITR using a 5-tuple hash of the inner header (so as to
   be consistent in case of multipath solutions, such as ECMP <span>[<a href="#RFC2992" class="cite xref">RFC2992</a>]</span>) and ignored on reception.  LISP
   data packets are often encapsulated in UDP packets that include a
   zero checksum <span>[<a href="#RFC6935" class="cite xref">RFC6935</a>]</span> <span>[<a href="#RFC6936" class="cite xref">RFC6936</a>]</span> that may not be verified when it is
   received, because LISP data packets typically include an inner
   transport protocol header with a non-zero checksum. The use of UDP zero checksums
   over IPv6 for all tunneling protocols like LISP is subject to the applicability
   statement in <span>[<a href="#RFC6936" class="cite xref">RFC6936</a>]</span>. If LISP data packets are
   encapsulated in
   UDP packets with non-zero checksums, the outer UDP checksums are
   verified when the UDP packets are received, as part of normal UDP
   processing.<a href="#section-3.3.1-1" class="pilcrow">¶</a></p>
<p id="section-3.3.1-2">LISP-encapsulated packets also include a LISP header (after the
          UDP header and before the original IP header). The LISP header is
   prepended by ITRs and stripped by ETRs. It carries reachability
   information (see more details in <a href="#reachability" class="auto internal xref">Section 4.2</a>) and the 'Instance ID' field.  
   The 'Instance ID' field is used to distinguish traffic to/from
   different tenant address spaces at the LISP site, and this use of the
   Instance ID may use
   overlapped but logically separated EID addressing.<a href="#section-3.3.1-2" class="pilcrow">¶</a></p>
<p id="section-3.3.1-3">Overall, LISP works on 4 headers: the inner header the source
   constructed and the 3 headers a LISP encapsulator prepends ("outer"
   to "inner"):<a href="#section-3.3.1-3" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-3.3.1-4">
            <li id="section-3.3.1-4.1">Outer IP header containing RLOCs as source and destination
              addresses. This header is originated by ITRs and stripped by
              ETRs.<a href="#section-3.3.1-4.1" class="pilcrow">¶</a>
</li>
            <li id="section-3.3.1-4.2">UDP header (port 4341), usually with zero checksum. This header is
              originated by ITRs and stripped by ETRs.<a href="#section-3.3.1-4.2" class="pilcrow">¶</a>
</li>
            <li id="section-3.3.1-4.3">LISP header that contains various forwarding-plane features
     (such as reachability) and an 
              'Instance ID' field. This header is originated by ITRs and
              stripped by ETRs.<a href="#section-3.3.1-4.3" class="pilcrow">¶</a>
</li>
            <li id="section-3.3.1-4.4">Inner IP header containing EIDs as source and destination
              addresses. This header is created by the source end host and
              is left unchanged by the LISP data plane processing on the ITR and ETR.<a href="#section-3.3.1-4.4" class="pilcrow">¶</a>
</li>
          </ol>
<p id="section-3.3.1-5">Finally, in some scenarios, re-encapsulating and/or recursive
   tunnels are useful to choose a specified path in the underlay
   network, for instance, to avoid congestion or
   failure. Re-encapsulating tunnels are consecutive LISP tunnels and
   occur when a decapsulator (an ETR action) removes a LISP header and
   then acts as an encapsulator (an ITR action) to prepend another one.
   On the other hand, recursive tunnels are nested tunnels and are
   implemented by using multiple LISP encapsulations on a packet. Such
   functions are implemented by Re-encapsulating Tunnel Routers
   (RTRs). An RTR can be thought of as a router that first acts as an
   ETR by decapsulating packets and then as an ITR by encapsulating
   them towards another Locator; more information can be found in <span>[<a href="#RFC9300" class="cite xref">RFC9300</a>]</span> and <span>[<a href="#RFC9301" class="cite xref">RFC9301</a>]</span>.<a href="#section-3.3.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-3.3.2">
          <h4 id="name-lisp-forwarding-state">
<a href="#section-3.3.2" class="section-number selfRef">3.3.2. </a><a href="#name-lisp-forwarding-state" class="section-name selfRef">LISP Forwarding State</a>
          </h4>
<p id="section-3.3.2-1"> In the LISP architecture, ITRs keep just enough information to route
   traffic flowing through them. In other words, ITRs only need to retrieve
   from the LISP Mapping System mappings between EID-Prefixes (blocks of EIDs)
   and RLOCs that are used to encapsulate packets.
   Such mappings are stored in a local cache
    called the LISP Map-Cache for subsequent packets addressed to the same EID-Prefix.  Note that in the case of overlapping EID-Prefixes, after a request,
   the ITR may receive a set of mappings covering the requested EID-Prefix and
   all more-specific EID-Prefixes (cf., <span><a href="https://www.rfc-editor.org/rfc/rfc9301#section-5.5" class="relref">Section 5.5</a> of [<a href="#RFC9301" class="cite xref">RFC9301</a>]</span>). Mappings include a Time to Live
   (TTL) (set by the ETR). More details about the Map-Cache
   management can be found in <a href="#management" class="auto internal xref">Section 4.1</a>.<a href="#section-3.3.2-1" class="pilcrow">¶</a></p>
</section>
</section>
<section id="section-3.4">
        <h3 id="name-control-plane">
<a href="#section-3.4" class="section-number selfRef">3.4. </a><a href="#name-control-plane" class="section-name selfRef">Control Plane</a>
        </h3>
<p id="section-3.4-1">The LISP control plane, specified in <span>[<a href="#RFC9301" class="cite xref">RFC9301</a>]</span>, provides a standard 
 interface to register and request mappings.  
 The LISP
 Mapping System is a database that stores such
 mappings.  The following sub-sections first describe the mappings, then the
 standard interface to the Mapping System, and finally its architecture.<a href="#section-3.4-1" class="pilcrow">¶</a></p>
<section id="section-3.4.1">
          <h4 id="name-lisp-mappings">
<a href="#section-3.4.1" class="section-number selfRef">3.4.1. </a><a href="#name-lisp-mappings" class="section-name selfRef">LISP Mappings</a>
          </h4>
<p id="section-3.4.1-1">Each mapping includes the bindings between EID-Prefix(es) and a
          set of RLOCs as well as TE policies, in the form of
          priorities and weights for the RLOCs. Priorities allow the ETR to
          configure active/backup policies, while weights are used to
          load-balance traffic among the RLOCs (on a per-flow basis).<a href="#section-3.4.1-1" class="pilcrow">¶</a></p>
<p id="section-3.4.1-2">Typical mappings in LISP bind EIDs in the form of IP prefixes
   with a set of RLOCs, also in the form of IP addresses.  IPv4 and IPv6
   addresses are encoded using the appropriate Address Family
   Identifier (AFI) <span>[<a href="#RFC8060" class="cite xref">RFC8060</a>]</span>. 
   However,
   LISP can also support more general address encoding by means of the
   ongoing effort around the LISP Canonical Address Format (LCAF) <span>[<a href="#RFC8060" class="cite xref">RFC8060</a>]</span>.<a href="#section-3.4.1-2" class="pilcrow">¶</a></p>
<p id="section-3.4.1-3">With such a general syntax for address encoding in place, LISP
          aims to provide flexibility to current and future applications. For
          instance, LCAFs could support Media Access Control (MAC) addresses,
   geocoordinates, ASCII names, and application-specific data.<a href="#section-3.4.1-3" class="pilcrow">¶</a></p>
</section>
<section id="section-3.4.2">
          <h4 id="name-mapping-system-interface">
<a href="#section-3.4.2" class="section-number selfRef">3.4.2. </a><a href="#name-mapping-system-interface" class="section-name selfRef">Mapping System Interface</a>
          </h4>
<p id="section-3.4.2-1">LISP defines a standard interface between data and control
          planes. The interface is specified in <span>[<a href="#RFC9301" class="cite xref">RFC9301</a>]</span> and
          defines two entities:<a href="#section-3.4.2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3.4.2-2">
            <dt id="section-3.4.2-2.1">Map-Server:</dt>
            <dd style="margin-left: 1.5em" id="section-3.4.2-2.2">A network infrastructure component
              that learns mappings from ETRs and publishes them into the LISP
              Mapping System. Typically, Map-Servers are not authoritative to
              reply to queries; hence, they forward them to the ETR.
              However, they can also operate in proxy-mode, where the ETRs
              delegate replying to queries to Map-Servers. This setup is
              useful when the ETR has limited resources (e.g., CPU or power).<a href="#section-3.4.2-2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.4.2-2.3">Map-Resolver:</dt>
            <dd style="margin-left: 1.5em" id="section-3.4.2-2.4">A network infrastructure component
              that interfaces ITRs with the Mapping System by proxying queries
              and, in some cases, responses.<a href="#section-3.4.2-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-3.4.2-3"> The interface defines four LISP control messages that are
          sent as UDP datagrams (port 4342):<a href="#section-3.4.2-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3.4.2-4">
            <dt id="section-3.4.2-4.1">Map-Register:</dt>
            <dd style="margin-left: 1.5em" id="section-3.4.2-4.2">This message is used by ETRs to
              register mappings in the Mapping System, and it is authenticated
              using a shared key between the ETR and the Map-Server.<a href="#section-3.4.2-4.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.4.2-4.3">Map-Notify:</dt>
            <dd style="margin-left: 1.5em" id="section-3.4.2-4.4">When requested by the ETR, this message is sent by the
     Map-Server in response to a Map-Register to acknowledge the
     correct reception of the mapping and convey the latest Map-Server
     state on the EID-to-RLOC mapping. In some cases, a Map-Notify can
     be sent to the previous RLOCs when an EID is registered by a new
     set of RLOCs.<a href="#section-3.4.2-4.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.4.2-4.5">Map-Request:</dt>
            <dd style="margin-left: 1.5em" id="section-3.4.2-4.6">This message is used by ITRs or
              Map-Resolvers to resolve the mapping of a given EID.<a href="#section-3.4.2-4.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.4.2-4.7">Map-Reply:</dt>
            <dd style="margin-left: 1.5em" id="section-3.4.2-4.8">This message is sent by Map-Servers or ETRs in response to a
     Map-Request and contains the resolved mapping.  Please note that a
     Map-Reply may contain a negative reply if, for example, the
     queried EID is not part of the LISP EID space.  In such cases, the
     ITR typically forwards the traffic as is (non-encapsulated) to
     the public Internet. This behavior is defined to support
     incremental deployment of LISP.<a href="#section-3.4.2-4.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</section>
<section id="section-3.4.3">
          <h4 id="name-mapping-system">
<a href="#section-3.4.3" class="section-number selfRef">3.4.3. </a><a href="#name-mapping-system" class="section-name selfRef">Mapping System</a>
          </h4>
<p id="section-3.4.3-1">LISP architecturally decouples control and data planes by means of
          a standard interface. This interface glues the data plane -- routers
          responsible for forwarding data packets -- with the LISP Mapping
          System -- a database responsible for storing mappings.<a href="#section-3.4.3-1" class="pilcrow">¶</a></p>
<p id="section-3.4.3-2">With this separation in place, the data and control planes can use
          different architectures if needed and scale independently.
          Typically, the data plane is optimized to route packets according to
          hierarchical IP addresses. However, the control plane may have
          different requirements, for instance, and by taking advantage of the
          LCAFs, the Mapping System may be used to store
          nonhierarchical keys (such as MAC addresses),
          requiring different architectural approaches for scalability.
          Another important difference between the LISP control and
          data planes is that, and as a result of the local mapping cache
          available at the ITR, the Mapping System does not need to operate at
          line-rate.<a href="#section-3.4.3-2" class="pilcrow">¶</a></p>
<p id="section-3.4.3-3">Many of the existing mechanisms to create distributed systems
   have been explored and considered for the Mapping System
   architecture: graph-based databases in the form of LISP Alternative
   Logical Topology (LISP-ALT) <span>[<a href="#RFC6836" class="cite xref">RFC6836</a>]</span>, hierarchical databases in the
   form of the LISP Delegated Database Tree (LISP-DDT) <span>[<a href="#RFC8111" class="cite xref">RFC8111</a>]</span>, monolithic databases in the
   form of the LISP Not-so-novel EID-to-RLOC Database (LISP-NERD) <span>[<a href="#RFC6837" class="cite xref">RFC6837</a>]</span>, flat databases in the form of
   the LISP Distributed Hash Table (LISP-DHT) <span>[<a href="#I-D.cheng-lisp-shdht" class="cite xref">LISP-SHDHT</a>]</span> <span>[<a href="#Mathy" class="cite xref">Mathy</a>]</span>, and a multicast-based database <span>[<a href="#I-D.curran-lisp-emacs" class="cite xref">LISP-EMACS</a>]</span>. Furthermore, it
   is worth noting that, in some scenarios, such as private deployments,
   the Mapping System can operate as logically centralized. In such
   cases, it is typically composed of a single
   Map-Server/Map-Resolver.<a href="#section-3.4.3-3" class="pilcrow">¶</a></p>
<p id="section-3.4.3-4">The following sub-sections focus on the two Mapping Systems that have
          been implemented and deployed (LISP-ALT and LISP-DDT).<a href="#section-3.4.3-4" class="pilcrow">¶</a></p>
<section id="section-3.4.3.1">
            <h5 id="name-lisp-alt">
<a href="#section-3.4.3.1" class="section-number selfRef">3.4.3.1. </a><a href="#name-lisp-alt" class="section-name selfRef">LISP-ALT</a>
            </h5>
<p id="section-3.4.3.1-1">LISP-ALT <span>[<a href="#RFC6836" class="cite xref">RFC6836</a>]</span> was the first 
 Mapping System proposed, developed, and deployed on the LISP pilot
 network.  It is based on a distributed BGP overlay in which 
 Map-Servers and Map-Resolvers participate. The nodes connect to their peers
 through static tunnels. Each Map-Server involved in the ALT topology
 advertises the EID-Prefixes registered by the serviced ETRs, making
 the EID routable on the ALT topology.<a href="#section-3.4.3.1-1" class="pilcrow">¶</a></p>
<p id="section-3.4.3.1-2">When an ITR needs a mapping, it sends a Map-Request to a Map-Resolver
     that, using the ALT topology, forwards the Map-Request towards the
     Map-Server responsible for the mapping. Upon reception, the Map-Server
     forwards the request to the ETR, which in turn replies directly to the ITR.<a href="#section-3.4.3.1-2" class="pilcrow">¶</a></p>
</section>
<section id="section-3.4.3.2">
            <h5 id="name-lisp-ddt">
<a href="#section-3.4.3.2" class="section-number selfRef">3.4.3.2. </a><a href="#name-lisp-ddt" class="section-name selfRef">LISP-DDT</a>
            </h5>
<p id="section-3.4.3.2-1">LISP-DDT <span>[<a href="#RFC8111" class="cite xref">RFC8111</a>]</span> is
     conceptually similar to the DNS, a hierarchical directory whose
     internal structure mirrors the hierarchical nature of the EID
     address space.  The DDT hierarchy is composed of DDT nodes forming
     a tree structure; the leafs of the tree are Map-Servers.  On top
     of the structure, there is the DDT root node, which is a particular
     instance of a DDT node, that matches the entire address space.  As
     in the case of DNS, DDT supports multiple redundant DDT nodes
     and/or DDT roots. Finally, Map-Resolvers are the clients of the
     DDT hierarchy and can query the DDT root and/or other DDT
     nodes.<a href="#section-3.4.3.2-1" class="pilcrow">¶</a></p>
<span id="name-a-schematic-representation-"></span><figure id="figure-3">
              <div class="alignLeft art-text artwork" id="section-3.4.3.2-2.1">
<pre>
                        /---------\
                        |         |
                        | DDT Root|
                        |   /0    |
                      ,.\---------/-,
                  ,-'`       |       `'.,
               -'`           |           `-
           /-------\     /-------\    /-------\
           |  DDT  |     |  DDT  |    |  DDT  |
           | Node  |     | Node  |    | Node  |  ...
           |  0/8  |     |  1/8  |    |  2/8  |
           \-------/     \-------/    \-------/
         _.                _.            . -..,,,_
       -`                -`              \        ````''--
+------------+     +------------+   +------------+ +------------+
| Map-Server |     | Map-Server |   | Map-Server | | Map-Server |
| EID-Prefix1|     | EID-Prefix2|   | EID-Prefix3| | EID-Prefix4|
+------------+     +------------+   +------------+ +------------+
</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-a-schematic-representation-" class="selfRef">A Schematic Representation of the DDT Tree Structure</a>
              </figcaption></figure>
<p id="section-3.4.3.2-3">Please note that the prefixes and the structure depicted in the
     figure above should only be considered as an example.<a href="#section-3.4.3.2-3" class="pilcrow">¶</a></p>
<p id="section-3.4.3.2-4"> The DDT structure does not actually index EID-Prefixes; rather, it
     indexes Extended EID-Prefixes (XEID-Prefixes). An XEID-Prefix is just the
            concatenation of the following fields (from most significant bit
            to less significant bits): Database-ID, Instance ID, Address Family
            Identifier, and the actual EID-Prefix. The Database-ID is provided
            for possible future requirements of higher levels in the hierarchy
            and to enable the creation of multiple and separate database
            trees.<a href="#section-3.4.3.2-4" class="pilcrow">¶</a></p>
<p id="section-3.4.3.2-5">In order to resolve a query, LISP-DDT operates in a similar way to the
     DNS but only supports iterative lookups. DDT clients (usually Map-Resolvers)
            generate Map-Requests to the DDT root node. In response, they
            receive a newly introduced LISP control message: a Map-Referral. A
            Map-Referral provides the list of RLOCs of the set of DDT nodes
            matching a configured XEID delegation. That is, the information
            contained in the Map-Referral points to the child of the queried
            DDT node that has more specific information about the queried
            XEID-Prefix. This process is repeated until the DDT client walks
            the tree structure (downwards) and discovers the Map-Server
            servicing the queried XEID. At this point, the client sends a
            Map-Request and receives a Map-Reply containing the mappings. It
            is important to note that DDT clients can also cache the
            information contained in Map-Referrals; that is, they cache the
            DDT structure.  This is used to reduce the time required to retrieve
     mappings <span>[<a href="#Jakab" class="cite xref">Jakab</a>]</span>.<a href="#section-3.4.3.2-5" class="pilcrow">¶</a></p>
<p id="section-3.4.3.2-6">The DDT Mapping System relies on manual configuration. That is,
            Map-Resolvers are configured with the set of available
            DDT root nodes, while DDT nodes are configured with the
            appropriate XEID delegations. Configuration changes in the DDT
            nodes are only required when the tree structure changes itself,
            but it doesn't depend on EID dynamics (RLOC allocation or
            TE policy changes).<a href="#section-3.4.3.2-6" class="pilcrow">¶</a></p>
</section>
</section>
</section>
<div id="sect-3.5">
<section id="section-3.5">
        <h3 id="name-internetworking-mechanisms">
<a href="#section-3.5" class="section-number selfRef">3.5. </a><a href="#name-internetworking-mechanisms" class="section-name selfRef">Internetworking Mechanisms</a>
        </h3>
<p id="section-3.5-1">EIDs are typically identical to either IPv4 or IPv6 addresses, and
        they are stored in the LISP Mapping System. However, they are usually not
        announced in the routing system beyond the local LISP domain. As a result, LISP
        requires an internetworking mechanism to allow LISP sites to speak
        with non-LISP sites and vice versa. LISP internetworking mechanisms are
        specified in <span>[<a href="#RFC6832" class="cite xref">RFC6832</a>]</span>.<a href="#section-3.5-1" class="pilcrow">¶</a></p>
<p id="section-3.5-2">LISP defines two entities to provide internetworking:<a href="#section-3.5-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3.5-3">
          <dt id="section-3.5-3.1">Proxy Ingress Tunnel Router (PITR):</dt>
          <dd style="margin-left: 1.5em" id="section-3.5-3.2">PITRs provide
            connectivity from the legacy Internet to LISP sites. PITRs
            announce in the global routing system blocks of EID-Prefixes
            (aggregating when possible) to attract traffic. For each incoming
     packet from a source not in a LISP site (a non-EID),  
 the PITR LISP-encapsulates it towards the RLOC(s) of
            the appropriate LISP site. The impact of PITRs on the routing
            table size of the Default-Free Zone (DFZ) is, in the worst case, similar to the case
            in which LISP is not deployed. EID-Prefixes will be aggregated 
            as much as possible, both by the PITR and by the global routing system.<a href="#section-3.5-3.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-3.5-3.3">Proxy Egress Tunnel Router (PETR):</dt>
          <dd style="margin-left: 1.5em" id="section-3.5-3.4">PETRs provide connectivity from LISP sites to the legacy
   Internet. In some scenarios, LISP sites may be unable to send
   encapsulated packets with a local EID address as a source to the
   legacy Internet, for instance, when Unicast Reverse Path 
            Forwarding (uRPF) is used by Provider Edge routers or when an
            intermediate network between a LISP site and a non-LISP site does
            not support the desired version of IP (IPv4 or IPv6). In both
            cases, the PETR  overcomes such limitations by
            encapsulating packets over the network. There is no specified
   provision for the distribution of PETR RLOC addresses to the
   ITRs.<a href="#section-3.5-3.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-3.5-4">Additionally, LISP also defines mechanisms to operate with private
 EIDs <span>[<a href="#RFC1918" class="cite xref">RFC1918</a>]</span> by means of LISP-NAT
 <span>[<a href="#RFC6832" class="cite xref">RFC6832</a>]</span>. In this case, the xTR
 replaces a private EID source address with a routable one. At the time
 of this writing, work is ongoing to define NAT-traversal capabilities,
 that is, xTRs behind a NAT using non-routable RLOCs.<a href="#section-3.5-4" class="pilcrow">¶</a></p>
<p id="section-3.5-5">PITRs, PETRs, and LISP-NAT enable incremental deployment of LISP by
 providing significant flexibility in the placement of the boundaries
 between the LISP and non-LISP portions of the network and making it
 easy to change those boundaries over time.<a href="#section-3.5-5" class="pilcrow">¶</a></p>
</section>
</div>
</section>
<section id="section-4">
      <h2 id="name-lisp-operational-mechanisms">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-lisp-operational-mechanisms" class="section-name selfRef">LISP Operational Mechanisms</a>
      </h2>
<p id="section-4-1">This section details the main operational mechanisms defined in
      LISP.<a href="#section-4-1" class="pilcrow">¶</a></p>
<div id="management">
<section id="section-4.1">
        <h3 id="name-cache-management">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-cache-management" class="section-name selfRef">Cache Management</a>
        </h3>
<p id="section-4.1-1">LISP's decoupled control and data planes, where mappings are
          stored in the control plane and used for forwarding in the data
          plane, require a local cache in ITRs to reduce signaling
          overhead (Map-Request/Map-Reply) and increase forwarding speed. The
          local cache available at the ITRs, called Map-Cache, is used by the
          router to LISP-encapsulate packets. The Map-Cache is indexed by
          (Instance ID, EID-Prefix) and contains basically the set
          of RLOCs with the associated TE policies (priorities and
          weights).<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<p id="section-4.1-2">The Map-Cache, as with any other cache, requires cache coherence
          mechanisms to maintain up-to-date information. LISP defines three
          main mechanisms for cache coherence:<a href="#section-4.1-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.1-3">
          <dt id="section-4.1-3.1">Record Time To Live (TTL):</dt>
          <dd style="margin-left: 1.5em" id="section-4.1-3.2">Each mapping record contains a TTL set by the ETR. Upon
   expiration of the TTL, the ITR can't use the mapping until it is refreshed by 
   sending a new Map-Request.<a href="#section-4.1-3.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-3.3">Solicit-Map-Request (SMR):</dt>
          <dd style="margin-left: 1.5em" id="section-4.1-3.4">SMR is an explicit
              mechanism to update mapping information. In particular, a special
              type of Map-Request can be sent on demand by ETRs to request refreshing
             a mapping. Upon reception of an SMR
              message, the ITR must refresh the bindings by sending a
              Map-Request to the Mapping System. Further uses of SMRs are
   documented in <span>[<a href="#RFC9301" class="cite xref">RFC9301</a>]</span>.<a href="#section-4.1-3.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-3.5">Map-Versioning:</dt>
          <dd style="margin-left: 1.5em" id="section-4.1-3.6">This optional mechanism piggybacks, in the LISP header of data packets, the
          version number of the mappings used by an xTR.  This way, when an xTR receives
          a LISP-encapsulated packet from a remote xTR, it can check whether its own
          Map-Cache or the one of the remote xTR is outdated.  If its Map-Cache is
          outdated, it sends a Map-Request for the remote EID so as to obtain the newest
          mappings.  On the contrary, if it detects that the remote xTR Map-Cache is
          outdated, it sends an SMR to notify it that a new mapping is available. Further
   details are available in <span>[<a href="#RFC9302" class="cite xref">RFC9302</a>]</span>.<a href="#section-4.1-3.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-4.1-4">Finally, it is worth noting that, in some cases, an entry in the
 Map-Cache can be proactively refreshed using the mechanisms described
 in the section below.<a href="#section-4.1-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="reachability">
<section id="section-4.2">
        <h3 id="name-rloc-reachability">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-rloc-reachability" class="section-name selfRef">RLOC Reachability</a>
        </h3>
<p id="section-4.2-1">In most cases, LISP operates with a pull-based Mapping System (e.g.,
 DDT). This results in an edge-to-edge pull architecture. In such a
 scenario, the network state is stored in the control plane while the
 data plane pulls it on demand. This has consequences concerning the
 propagation of xTRs' reachability/liveness information, since pull
 architectures require explicit mechanisms to propagate this
 information. As a result, LISP defines a set of mechanisms to inform
 ITRs and PITRs about the reachability of the cached RLOCs:<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.2-2">
          <dt id="section-4.2-2.1">Locator-Status-Bits (LSBs):</dt>
          <dd style="margin-left: 1.5em" id="section-4.2-2.2">Using LSBs is a passive technique. The 'LSB'
 field is carried by data packets in the LISP header and can be set by
 ETRs to specify which RLOCs of the ETR site are up/down. This information
        can be used by the ITRs as a hint about the reachability to perform
        additional checks. Also note that LSBs do not provide path
        reachability status; they only provide hints about the status of RLOCs.  As such, they must not be
 used over the public Internet and should be coupled with Map-Versioning to prevent
 race conditions where LSBs are interpreted as referring to different RLOCs than
 intended.<a href="#section-4.2-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.2-2.3">Echo-Nonce:</dt>
          <dd style="margin-left: 1.5em" id="section-4.2-2.4">This is also a passive technique that can only operate
        effectively when data flows bidirectionally between two communicating xTRs.
        Basically, an ITR piggybacks a random number (called a nonce) in LISP
        data packets. If the path and the probed Locator are up, the ETR will
        piggyback the same random number on the next data packet; if this is
        not the case, the ITR can set the Locator as unreachable. When traffic
        flow is unidirectional or when the ETR receiving the traffic is not
        the same as the ITR that transmits it back, additional mechanisms are
        required. The Echo-Nonce mechanism must be used in trusted environments only, not
 over the public Internet.<a href="#section-4.2-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.2-2.5">RLOC-Probing:</dt>
          <dd style="margin-left: 1.5em" id="section-4.2-2.6">This is an active probing algorithm where ITRs send
 probes to specific Locators. This effectively probes both the Locator
 and the path.  In particular, this is done by sending a
 Map-Request (with certain flags activated) on the data plane (RLOC
 space) and then waiting for a Map-Reply (also sent on the data
 plane). The active
        nature of RLOC-Probing provides an effective mechanism for determining
        reachability and, in case of failure, switching to a different
        Locator. Furthermore, the mechanism also provides useful RTT
        estimates of the delay of the path that can be used by other network
        algorithms.<a href="#section-4.2-2.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-4.2-3">It is worth noting that RLOC-Probing and the Echo-Nonce can work together.
 Specifically, if a nonce is not echoed, an ITR cannot determine which path direction has failed. In this scenario, an ITR can use RLOC-Probing.<a href="#section-4.2-3" class="pilcrow">¶</a></p>
<p id="section-4.2-4">Additionally, LISP also recommends inferring the reachability of
        Locators by using information provided by the underlay, 
        particularly:<a href="#section-4.2-4" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.2-5">
          <dt id="section-4.2-5.1">ICMP signaling:</dt>
          <dd style="margin-left: 1.5em" id="section-4.2-5.2">The LISP underlay -- the current Internet -- uses 
        ICMP to signal unreachability (among other things). LISP can
        take advantage of this, and the reception of an ICMP Network Unreachable
        or ICMP Host Unreachable message can be seen as a hint that a Locator
        might be unreachable. This should lead to performing additional
        checks.<a href="#section-4.2-5.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.2-5.3">Underlay routing:</dt>
          <dd style="margin-left: 1.5em" id="section-4.2-5.4">Both BGP and IGP carry reachability information.
        LISP-capable routers that have access to underlay routing information
        can use it to determine if a given Locator or path is reachable.<a href="#section-4.2-5.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<section id="section-4.3">
        <h3 id="name-etr-synchronization">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-etr-synchronization" class="section-name selfRef">ETR Synchronization</a>
        </h3>
<p id="section-4.3-1">All the ETRs that are authoritative to a particular EID-Prefix must 
 announce the same mapping to the requesters. This means that ETRs must be 
 aware of the status of the RLOCs of the remaining ETRs. This is known as
 ETR synchronization.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<p id="section-4.3-2">At the time of this writing, LISP does not specify a mechanism to
 achieve ETR synchronization. Although many well-known techniques could
 be applied to solve this issue, it is still under research. As a
 result, operators must rely on coherent manual configuration.<a href="#section-4.3-2" class="pilcrow">¶</a></p>
</section>
<section id="section-4.4">
        <h3 id="name-mtu-handling">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-mtu-handling" class="section-name selfRef">MTU Handling</a>
        </h3>
<p id="section-4.4-1">Since LISP encapsulates packets, it requires dealing with packets
 that exceed the MTU of the path between the ITR and the
 ETR. Specifically, LISP defines two mechanisms:<a href="#section-4.4-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.4-2">
          <dt id="section-4.4-2.1">Stateless:</dt>
          <dd style="margin-left: 1.5em" id="section-4.4-2.2">With this mechanism, the effective MTU is assumed from the ITR's
   perspective. If a payload packet is too big for the effective MTU
   and can be fragmented, the payload packet is fragmented on the ITR,
   such that reassembly is performed at the destination host.<a href="#section-4.4-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.4-2.3">Stateful:</dt>
          <dd style="margin-left: 1.5em" id="section-4.4-2.4">With this mechanism, ITRs keep track of the MTU of the paths
   towards the destination Locators by parsing the ICMP Too Big packets
   sent by intermediate routers. ITRs will send ICMP Too Big messages
   to inform the sources about the effective MTU. Additionally, ITRs can
   use mechanisms such as Path MTU Discovery (PMTUD) <span>[<a href="#RFC1191" class="cite xref">RFC1191</a>]</span> or Packetization Layer Path MTU Discovery (PLPMTUD) <span>[<a href="#RFC4821" class="cite xref">RFC4821</a>]</span> to keep track of the MTU towards the
   Locators.<a href="#section-4.4-2.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-4.4-3">In both cases, if the packet cannot be fragmented (IPv4 with DF=1 or
 IPv6), then the ITR drops it and replies with an ICMP Too Big message to
 the source.<a href="#section-4.4-3" class="pilcrow">¶</a></p>
</section>
</section>
<section id="section-5">
      <h2 id="name-mobility">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-mobility" class="section-name selfRef">Mobility</a>
      </h2>
<p id="section-5-1">The separation between Locators and identifiers in LISP is suitable 
 for TE purposes where LISP sites can change their attachment
 points to the Internet (i.e., RLOCs) without impacting endpoints or the
 Internet core. In this context, the border routers operate the xTR
 functionality, and endpoints are not aware of the existence of
 LISP. This functionality is similar to Network Mobility
 <span>[<a href="#RFC3963" class="cite xref">RFC3963</a>]</span>. However, 
 this mode of operation does not allow seamless mobility of endpoints between
 different LISP sites, as the EID address might not be routable in a visited
 site.  Nevertheless, LISP can be used to enable seamless
 IP mobility when LISP
 is directly implemented in the endpoint or when the endpoint
 roams to an attached xTR.   
 Each endpoint is then an xTR, and the EID address is the one
 presented to the network stack used by applications 
 while the RLOC is the address gathered from the network when
      it is visited. This functionality is similar to Mobile IP (<span>[<a href="#RFC5944" class="cite xref">RFC5944</a>]</span> and <span>[<a href="#RFC6275" class="cite xref">RFC6275</a>]</span>).<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2"> Whenever a device changes its RLOC, the xTR updates the RLOC of its
      local mapping and registers it to its Map-Server, typically with a
      low TTL value (1 min). To avoid the need for a 
          home gateway, the ITR also indicates the RLOC change to all remote devices
          that have ongoing communications with the device that moved.  The
          combination of both methods ensures the scalability of the system, as
          signaling is strictly limited to the Map-Server and to hosts with which
          communications are ongoing. In the mobility case, the EID-Prefix can
      be as small as a full /32 or /128 (IPv4 or IPv6, respectively), depending
      on the specific use case (e.g., subnet mobility vs. single VM/Mobile node mobility).<a href="#section-5-2" class="pilcrow">¶</a></p>
<p id="section-5-3">The decoupled identity and location provided by LISP allow it to
      operate with other Layer 2 and Layer 3 mobility solutions.<a href="#section-5-3" class="pilcrow">¶</a></p>
</section>
<section id="section-6">
      <h2 id="name-multicast">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-multicast" class="section-name selfRef">Multicast</a>
      </h2>
<p id="section-6-1">LISP also supports transporting IP multicast packets sent from the EID
      space. The required operational changes to the multicast protocols are
      documented in <span>[<a href="#RFC6831" class="cite xref">RFC6831</a>]</span>.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">In such scenarios, LISP may create multicast state both at the core
      and at the sites (both source and receiver). When signaling is used to
      create multicast state at the sites, LISP
      routers encapsulate PIM Join/Prune messages from receiver to source
      sites as unicast packets. At the core,
      ETRs build a new PIM Join/Prune message addressed to the RLOC of the
      ITR servicing the source.  A simplified sequence is shown below.<a href="#section-6-2" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-6-3">
        <li id="section-6-3.1">An end host willing to join a multicast channel sends an IGMP
 report. Multicast PIM routers at the LISP site propagate PIM
 Join/Prune messages (S-EID, G) towards the ETR.<a href="#section-6-3.1" class="pilcrow">¶</a>
</li>
        <li id="section-6-3.2">The Join message flows to the ETR. Upon reception, the ETR builds
 two Join messages. The first one unicast LISP-encapsulates the
 original Join message towards the RLOC of the ITR servicing the
 source. This message creates (S-EID, G) multicast state at the source
 site. 
 The second Join message contains, as a destination address, the RLOC
 of the ITR servicing the source (S-RLOC, G) and creates multicast
 state at the core.<a href="#section-6-3.2" class="pilcrow">¶</a>
</li>
        <li id="section-6-3.3">Multicast data packets originated by the source (S-EID, G) flow
 from the source to the ITR. The ITR LISP-encapsulates the multicast
 packets. The outer header includes its own RLOC as the source
 (S-RLOC) and the original multicast group address (G) as the
 destination. Please note that multicast group addresses are logical and
 are not resolved by the Mapping System.  Then, the
 multicast packets are transmitted through the core towards the
 receiving ETRs, which decapsulate the packets and forward them
 using the receiver site's multicast state.<a href="#section-6-3.3" class="pilcrow">¶</a>
</li>
      </ol>
<p id="section-6-4">Please note that the inner and outer multicast addresses are
      generally different, except in specific cases where the underlay provider
      implements tight control on the overlay. LISP specifications already
      support all PIM modes <span>[<a href="#RFC6831" class="cite xref">RFC6831</a>]</span>. Additionally, LISP can also support non-PIM
      mechanisms in order to maintain multicast state.<a href="#section-6-4" class="pilcrow">¶</a></p>
<p id="section-6-5">When multicast sources and receivers are active at LISP sites and the
      core network between the sites does not provide multicast support, a
      signal-free mechanism can be used to create an overlay that will allow
      multicast traffic to flow between sites and connect the multicast trees at
      the different sites <span>[<a href="#RFC8378" class="cite xref">RFC8378</a>]</span>. Registrations
      from the different receiver sites will be merged in the Mapping System to
      assemble a multicast replication list inclusive of all RLOCs that lead to receivers for a particular multicast group or multicast
      channel. The replication list for each specific multicast entry is maintained
      as a database mapping entry in the LISP Mapping System.<a href="#section-6-5" class="pilcrow">¶</a></p>
</section>
<section id="section-7">
      <h2 id="name-use-cases">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-use-cases" class="section-name selfRef">Use Cases</a>
      </h2>
<section id="section-7.1">
        <h3 id="name-traffic-engineering">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-traffic-engineering" class="section-name selfRef">Traffic Engineering</a>
        </h3>
<p id="section-7.1-1"> A LISP site can strictly impose via which ETRs the
          traffic must enter the LISP site network even though the path followed to reach the
          ETR is not under the control of the LISP site.  This fine control is
          implemented with the mappings.  When a remote site is willing to send
          traffic to a LISP site, it retrieves the mapping associated with the
          destination EID via the Mapping System.  The mapping is sent directly by an
          authoritative ETR of the EID and is not altered by any intermediate network.<a href="#section-7.1-1" class="pilcrow">¶</a></p>
<p id="section-7.1-2">A mapping associates a list of RLOCs with an EID-Prefix.  Each RLOC
          corresponds to an interface of an ETR (or set of ETRs) that is able to correctly forward
          packets to EIDs in the prefix.  Each RLOC is tagged with a priority and a
          weight in the mapping.  The priority is used to indicate which RLOCs
          should be preferred for sending packets (the least preferred ones being
          provided for backup purposes).  The weight permits balancing the load
          between the RLOCs with the same priority, in proportion to the weight
          value.<a href="#section-7.1-2" class="pilcrow">¶</a></p>
<p id="section-7.1-3"> As mappings are directly issued by the authoritative ETR of the EID
 and are not altered when transmitted to the remote site, it offers
 highly flexible incoming inter-domain TE and even
 makes it possible for a site to support a different mapping policy
 for each remote site.<a href="#section-7.1-3" class="pilcrow">¶</a></p>
</section>
<section id="section-7.2">
        <h3 id="name-lisp-for-ipv6-co-existence">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-lisp-for-ipv6-co-existence" class="section-name selfRef">LISP for IPv6 Co-existence</a>
        </h3>
<p id="section-7.2-1">LISP encapsulations allow transporting packets using EIDs from a
 given address family (e.g., IPv6) with packets from other address
 families (e.g., IPv4). The absence of correlation between the address
 families of RLOCs and EIDs makes LISP a candidate to allow, e.g., IPv6
 to be deployed when all of the core network may not have IPv6 enabled.<a href="#section-7.2-1" class="pilcrow">¶</a></p>
<p id="section-7.2-2">For example, two IPv6-only data centers could be interconnected via the
          legacy IPv4 Internet. If their border routers are LISP capable, sending
          packets between the data centers is done without any form of translation, as
          the original IPv6 packets (in the EID space) will be LISP encapsulated and
          transmitted over the IPv4 legacy Internet via IPv4 RLOCs.<a href="#section-7.2-2" class="pilcrow">¶</a></p>
</section>
<section id="section-7.3">
        <h3 id="name-lisp-for-virtual-private-ne">
<a href="#section-7.3" class="section-number selfRef">7.3. </a><a href="#name-lisp-for-virtual-private-ne" class="section-name selfRef">LISP for Virtual Private Networks</a>
        </h3>
<p id="section-7.3-1">It is common to operate several virtual networks over the same
        physical infrastructure.  In such virtual private networks, determining to
 which virtual network a packet belongs is essential; tags or labels are used
 for that purpose. When using LISP, the distinction can be made with the 
   'Instance ID' field.  When an
          ITR encapsulates a packet from a particular virtual network (e.g., known
          via Virtual Routing and Forwarding (VRF) or the VLAN), it tags the encapsulated packet with the Instance ID
          corresponding to the virtual network of the packet.  When an ETR receives a
          packet tagged with an Instance ID, it uses the Instance ID to determine how
          to treat the packet.<a href="#section-7.3-1" class="pilcrow">¶</a></p>
<p id="section-7.3-2">The main usage of LISP for virtual private networks does not introduce 
additional requirements on the underlying network, as long as it runs IP.<a href="#section-7.3-2" class="pilcrow">¶</a></p>
</section>
<section id="section-7.4">
        <h3 id="name-lisp-for-virtual-machine-mo">
<a href="#section-7.4" class="section-number selfRef">7.4. </a><a href="#name-lisp-for-virtual-machine-mo" class="section-name selfRef">LISP for Virtual Machine Mobility in Data Centers</a>
        </h3>
<p id="section-7.4-1">A way to enable seamless virtual machine (VM) mobility in the data center is to
          conceive the data center backbone as the RLOC space and the subnet
          where servers are hosted as forming the EID space. A LISP router is placed
          at the border between the backbone and each subnet. When a VM
          is moved to another subnet, it can keep (temporarily) the address it had before the move so as to continue without a transport-layer connection reset. When an xTR detects a source address received on a subnet to be an address not assigned to the subnet, it registers the address to the Mapping System.<a href="#section-7.4-1" class="pilcrow">¶</a></p>
<p id="section-7.4-2">To inform the other LISP routers that the machine moved and where, and then
 to avoid detours via the initial subnetwork, mechanisms such as the
 Solicit-Map-Request messages are used.<a href="#section-7.4-2" class="pilcrow">¶</a></p>
</section>
</section>
<section id="section-8">
      <h2 id="name-security-considerations">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-8-1">This section describes the security considerations associated with
      LISP.<a href="#section-8-1" class="pilcrow">¶</a></p>
<p id="section-8-2">In a push Mapping System, the state necessary to forward packets is learned
   independently of the traffic itself. However, with a pull architecture, the
   system becomes reactive, and data plane events (e.g., the arrival of a
   packet with an unknown destination address) may trigger control plane events.
   This on-demand learning of mappings provides many advantages, as
   discussed above, but may also affect the way security is enforced.<a href="#section-8-2" class="pilcrow">¶</a></p>
<p id="section-8-3">Usually, the data plane is implemented in the fast path of routers to
        provide high-performance forwarding capabilities, while the control plane
        features are implemented in the slow path to offer high flexibility, and a
        performance gap of several orders of magnitude can be observed between the
 slow and fast paths.
 As a consequence, the way to notify the control plane of data plane events must be considered carefully so as not to overload the
 slow path, and rate limiting should be used as specified in <span>[<a href="#RFC9300" class="cite xref">RFC9300</a>]</span> and <span>[<a href="#RFC9301" class="cite xref">RFC9301</a>]</span>.<a href="#section-8-3" class="pilcrow">¶</a></p>
<p id="section-8-4">Care must also be taken not to overload the Mapping System (i.e., the
        control plane infrastructure), as the operations to be performed by the
 Mapping
        System may be more complex than those on the data plane. For that reason,
        <span>[<a href="#RFC9300" class="cite xref">RFC9300</a>]</span> and <span>[<a href="#RFC9301" class="cite xref">RFC9301</a>]</span> recommend rate limiting the
 sending of messages to the Mapping System.<a href="#section-8-4" class="pilcrow">¶</a></p>
<p id="section-8-5"> To improve resiliency and reduce the overall number of messages
      exchanged, LISP makes it possible to leak certain information, such
      as the reachability of Locators, directly into data plane packets. In
      environments that are not
        fully trusted, like the open Internet, control information gleaned from
 data plane packets must not be used or must be
        verified before using it.<a href="#section-8-5" class="pilcrow">¶</a></p>
<p id="section-8-6">Mappings are the centerpiece of LISP, and all precautions must be taken to
      prevent malicious entities from manipulating or misusing them.  Using
      trustable Map-Servers that strictly respect <span>[<a href="#RFC9301" class="cite xref">RFC9301</a>]</span> and the
      authentication mechanism proposed by LISP-SEC <span>[<a href="#RFC9303" class="cite xref">RFC9303</a>]</span> reduces
      the risk of attacks on mapping integrity.  In more critical
      environments, secure measures may be needed.  The way security is
      implemented for a given Mapping System strongly depends on the architecture
      of the Mapping System itself and the threat model assumed for the
      deployment. Thus, Mapping System security has to be discussed in the 
      relevant documents proposing the Mapping System architecture.<a href="#section-8-6" class="pilcrow">¶</a></p>
<p id="section-8-7">As with any other tunneling mechanism, middleboxes on the path
      between an ITR (or PITR) and an ETR (or PETR)  must implement mechanisms
      to strip the LISP encapsulation to correctly inspect the content of
      LISP-encapsulated packets.<a href="#section-8-7" class="pilcrow">¶</a></p>
<p id="section-8-8">Like other map-and-encap mechanisms, LISP enables triangular routing
      (i.e., packets of a flow cross different border routers, depending on
      their direction). This means that intermediate boxes may have an
      incomplete view of the traffic they inspect or manipulate. Moreover,
      LISP-encapsulated packets are routed based on the outer IP address
      (i.e., the RLOC) and can be delivered to an ETR that is not responsible
      for the destination EID of the packet or even delivered to a network element that
      is not an ETR. Mitigation consists of applying appropriate filtering
      techniques on the network elements that can potentially receive
      unexpected LISP-encapsulated packets.<a href="#section-8-8" class="pilcrow">¶</a></p>
<p id="section-8-9">More details about security implications of LISP are discussed in
        <span>[<a href="#RFC7835" class="cite xref">RFC7835</a>]</span>.<a href="#section-8-9" class="pilcrow">¶</a></p>
</section>
<section id="section-9">
      <h2 id="name-iana-considerations">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-9-1">This document has no IANA actions.<a href="#section-9-1" class="pilcrow">¶</a></p>
</section>
<section id="section-10">
      <h2 id="name-references">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-10.1">
        <h3 id="name-normative-references">
<a href="#section-10.1" class="section-number selfRef">10.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC1191">[RFC1191]</dt>
        <dd>
<span class="refAuthor">Mogul, J.</span> and <span class="refAuthor">S. Deering</span>, <span class="refTitle">"Path MTU discovery"</span>, <span class="seriesInfo">RFC 1191</span>, <span class="seriesInfo">DOI 10.17487/RFC1191</span>, <time datetime="1990-11" class="refDate">November 1990</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1191">https://www.rfc-editor.org/info/rfc1191</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC1918">[RFC1918]</dt>
        <dd>
<span class="refAuthor">Rekhter, Y.</span>, <span class="refAuthor">Moskowitz, B.</span>, <span class="refAuthor">Karrenberg, D.</span>, <span class="refAuthor">de Groot, G. J.</span>, and <span class="refAuthor">E. Lear</span>, <span class="refTitle">"Address Allocation for Private Internets"</span>, <span class="seriesInfo">BCP 5</span>, <span class="seriesInfo">RFC 1918</span>, <span class="seriesInfo">DOI 10.17487/RFC1918</span>, <time datetime="1996-02" class="refDate">February 1996</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1918">https://www.rfc-editor.org/info/rfc1918</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2992">[RFC2992]</dt>
        <dd>
<span class="refAuthor">Hopps, C.</span>, <span class="refTitle">"Analysis of an Equal-Cost Multi-Path Algorithm"</span>, <span class="seriesInfo">RFC 2992</span>, <span class="seriesInfo">DOI 10.17487/RFC2992</span>, <time datetime="2000-11" class="refDate">November 2000</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2992">https://www.rfc-editor.org/info/rfc2992</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3963">[RFC3963]</dt>
        <dd>
<span class="refAuthor">Devarapalli, V.</span>, <span class="refAuthor">Wakikawa, R.</span>, <span class="refAuthor">Petrescu, A.</span>, and <span class="refAuthor">P. Thubert</span>, <span class="refTitle">"Network Mobility (NEMO) Basic Support Protocol"</span>, <span class="seriesInfo">RFC 3963</span>, <span class="seriesInfo">DOI 10.17487/RFC3963</span>, <time datetime="2005-01" class="refDate">January 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3963">https://www.rfc-editor.org/info/rfc3963</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4821">[RFC4821]</dt>
        <dd>
<span class="refAuthor">Mathis, M.</span> and <span class="refAuthor">J. Heffner</span>, <span class="refTitle">"Packetization Layer Path MTU Discovery"</span>, <span class="seriesInfo">RFC 4821</span>, <span class="seriesInfo">DOI 10.17487/RFC4821</span>, <time datetime="2007-03" class="refDate">March 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4821">https://www.rfc-editor.org/info/rfc4821</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="RFC5944">[RFC5944]</dt>
        <dd>
<span class="refAuthor">Perkins, C., Ed.</span>, <span class="refTitle">"IP Mobility Support for IPv4, Revised"</span>, <span class="seriesInfo">RFC 5944</span>, <span class="seriesInfo">DOI 10.17487/RFC5944</span>, <time datetime="2010-11" class="refDate">November 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5944">https://www.rfc-editor.org/info/rfc5944</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6275">[RFC6275]</dt>
        <dd>
<span class="refAuthor">Perkins, C., Ed.</span>, <span class="refAuthor">Johnson, D.</span>, and <span class="refAuthor">J. Arkko</span>, <span class="refTitle">"Mobility Support in IPv6"</span>, <span class="seriesInfo">RFC 6275</span>, <span class="seriesInfo">DOI 10.17487/RFC6275</span>, <time datetime="2011-07" class="refDate">July 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6275">https://www.rfc-editor.org/info/rfc6275</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="RFC6835">[RFC6835]</dt>
        <dd>
<span class="refAuthor">Farinacci, D.</span> and <span class="refAuthor">D. Meyer</span>, <span class="refTitle">"The Locator/ID Separation Protocol Internet Groper (LIG)"</span>, <span class="seriesInfo">RFC 6835</span>, <span class="seriesInfo">DOI 10.17487/RFC6835</span>, <time datetime="2013-01" class="refDate">January 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6835">https://www.rfc-editor.org/info/rfc6835</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="RFC6935">[RFC6935]</dt>
        <dd>
<span class="refAuthor">Eubanks, M.</span>, <span class="refAuthor">Chimento, P.</span>, and <span class="refAuthor">M. Westerlund</span>, <span class="refTitle">"IPv6 and UDP Checksums for Tunneled Packets"</span>, <span class="seriesInfo">RFC 6935</span>, <span class="seriesInfo">DOI 10.17487/RFC6935</span>, <time datetime="2013-04" class="refDate">April 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6935">https://www.rfc-editor.org/info/rfc6935</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6936">[RFC6936]</dt>
        <dd>
<span class="refAuthor">Fairhurst, G.</span> and <span class="refAuthor">M. Westerlund</span>, <span class="refTitle">"Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums"</span>, <span class="seriesInfo">RFC 6936</span>, <span class="seriesInfo">DOI 10.17487/RFC6936</span>, <time datetime="2013-04" class="refDate">April 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6936">https://www.rfc-editor.org/info/rfc6936</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7052">[RFC7052]</dt>
        <dd>
<span class="refAuthor">Schudel, G.</span>, <span class="refAuthor">Jain, A.</span>, and <span class="refAuthor">V. Moreno</span>, <span class="refTitle">"Locator/ID Separation Protocol (LISP) MIB"</span>, <span class="seriesInfo">RFC 7052</span>, <span class="seriesInfo">DOI 10.17487/RFC7052</span>, <time datetime="2013-10" class="refDate">October 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7052">https://www.rfc-editor.org/info/rfc7052</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7215">[RFC7215]</dt>
        <dd>
<span class="refAuthor">Jakab, L.</span>, <span class="refAuthor">Cabellos-Aparicio, A.</span>, <span class="refAuthor">Coras, F.</span>, <span class="refAuthor">Domingo-Pascual, J.</span>, and <span class="refAuthor">D. Lewis</span>, <span class="refTitle">"Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations"</span>, <span class="seriesInfo">RFC 7215</span>, <span class="seriesInfo">DOI 10.17487/RFC7215</span>, <time datetime="2014-04" class="refDate">April 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7215">https://www.rfc-editor.org/info/rfc7215</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="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="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="RFC9301">[RFC9301]</dt>
        <dd>
<span class="refAuthor">Farinacci, D.</span>, <span class="refAuthor">Maino, F.</span>, <span class="refAuthor">Fuller, V.</span>, and <span class="refAuthor">A. Cabellos, Ed.</span>, <span class="refTitle">"Locator/ID Separation Protocol (LISP) Control Plane"</span>, <span class="seriesInfo">RFC 9301</span>, <span class="seriesInfo">DOI 10.17487/RFC9301</span>, <time datetime="2022-10" class="refDate">October 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9301">https://www.rfc-editor.org/info/rfc9301</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>
</dl>
</section>
<section id="section-10.2">
        <h3 id="name-informative-references">
<a href="#section-10.2" class="section-number selfRef">10.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="Jakab">[Jakab]</dt>
        <dd>
<span class="refAuthor">Jakab, L.</span>, <span class="refAuthor">Cabellos-Aparicio, A.</span>, <span class="refAuthor">Coras, F.</span>, <span class="refAuthor">Saucez, D.</span>, and <span class="refAuthor">O. Bonaventure</span>, <span class="refTitle">"LISP-TREE: A DNS Hierarchy to Support the LISP Mapping System"</span>, <span class="refContent">IEEE Journal on Selected Areas in Communications, vol. 28,
          no. 8, pp. 1332-1343</span>, <span class="seriesInfo">DOI 10.1109/JSAC.2010.101011</span>, <time datetime="2010-10" class="refDate">October 2010</time>, <span>&lt;<a href="https://ieeexplore.ieee.org/document/5586446">https://ieeexplore.ieee.org/document/5586446</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.curran-lisp-emacs">[LISP-EMACS]</dt>
        <dd>
<span class="refAuthor">Brim, S.</span>, <span class="refAuthor">Farinacci, D.</span>, <span class="refAuthor">Meyer, D.</span>, and <span class="refAuthor">J. Curran</span>, <span class="refTitle">"EID Mappings Multicast Across Cooperating Systems for LISP"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-curran-lisp-emacs-00</span>, <time datetime="2007-11-09" class="refDate">9 November 2007</time>, <span>&lt;<a href="https://www.ietf.org/archive/id/draft-curran-lisp-emacs-00.txt">https://www.ietf.org/archive/id/draft-curran-lisp-emacs-00.txt</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.cheng-lisp-shdht">[LISP-SHDHT]</dt>
        <dd>
<span class="refAuthor">Cheng, L.</span> and <span class="refAuthor">M. Sun</span>, <span class="refTitle">"LISP Single-Hop DHT Mapping Overlay"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-cheng-lisp-shdht-04</span>, <time datetime="2013-07-15" class="refDate">15 July 2013</time>, <span>&lt;<a href="https://www.ietf.org/archive/id/draft-cheng-lisp-shdht-04.txt">https://www.ietf.org/archive/id/draft-cheng-lisp-shdht-04.txt</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Mathy">[Mathy]</dt>
        <dd>
<span class="refAuthor">Mathy, L.</span> and <span class="refAuthor">L. Iannone</span>, <span class="refTitle">"LISP-DHT: Towards a DHT to map identifiers onto locators"</span>, <span class="refContent">CoNEXT '08: Proceedings of the 2008 ACM CoNEXT Conference, ReArch '08 - Re-Architecting the Internet</span>, <span class="seriesInfo">DOI 10.1145/1544012.1544073</span>, <time datetime="2008-12" class="refDate">December 2008</time>, <span>&lt;<a href="https://dl.acm.org/doi/10.1145/1544012.1544073">https://dl.acm.org/doi/10.1145/1544012.1544073</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Quoitin">[Quoitin]</dt>
      <dd>
<span class="refAuthor">Quoitin, B.</span>, <span class="refAuthor">Iannone, L.</span>, <span class="refAuthor">de Launois, C.</span>, and <span class="refAuthor">O. Bonaventure</span>, <span class="refTitle">"Evaluating the Benefits of the Locator/Identifier Separation"</span>, <span class="refContent">Proceedings of 2nd ACM/IEEE International Workshop
     on Mobility in the Evolving Internet Architecture</span>, <span class="seriesInfo">DOI 10.1145/1366919.1366926</span>, <time datetime="2007-08" class="refDate">August 2007</time>, <span>&lt;<a href="https://dl.acm.org/doi/10.1145/1366919.1366926">https://dl.acm.org/doi/10.1145/1366919.1366926</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<section id="appendix-A">
      <h2 id="name-a-brief-history-of-location">
<a href="#appendix-A" class="section-number selfRef">Appendix A. </a><a href="#name-a-brief-history-of-location" class="section-name selfRef">A Brief History of Location/Identity Separation</a>
      </h2>
<p id="appendix-A-1">The LISP architecture for separation of location and identity resulted from
      the discussions of this topic at the Amsterdam IAB Routing and
      Addressing Workshop, which took place in October 2006 <span>[<a href="#RFC4984" class="cite xref">RFC4984</a>]</span>.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
<p id="appendix-A-2">A small group of like-minded personnel spontaneously formed immediately after that
 workshop to work on an idea that came out of informal discussions at
 the workshop and on various mailing lists.  The first
 Internet-Draft on LISP appeared in January 2007.<a href="#appendix-A-2" class="pilcrow">¶</a></p>
<p id="appendix-A-3">Trial implementations started at that time, with initial trial
      deployments underway since June 2007; the results of early experience
      have been fed back into the design in a continuous, ongoing process
      over several years. At this point, LISP represents a moderately
      mature system, having undergone a long, organic series of changes and
      updates.<a href="#appendix-A-3" class="pilcrow">¶</a></p>
<p id="appendix-A-4">LISP transitioned from an IRTF activity to an IETF WG in March 2009.
      After numerous revisions, the basic specifications moved to
      becoming RFCs at the start of 2013; work to expand,
      improve, and find new uses for it continues (and undoubtedly will
      for a long time to come). The LISP WG was rechartered in 2018 to continue work on the LISP base protocol and produce Standards Track documents.<a href="#appendix-A-4" class="pilcrow">¶</a></p>
<section id="appendix-A.1">
        <h3 id="name-old-lisp-models">
<a href="#appendix-A.1" class="section-number selfRef">A.1. </a><a href="#name-old-lisp-models" class="section-name selfRef">Old LISP Models</a>
        </h3>
<p id="appendix-A.1-1">LISP, as initially conceived, had a number of potential operating
      modes, named 'models'.  Although they are not used anymore, one
      occasionally sees mention of them, so they are briefly described
      here.<a href="#appendix-A.1-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="appendix-A.1-2">
          <dt id="appendix-A.1-2.1">LISP 1:</dt>
          <dd style="margin-left: 1.5em" id="appendix-A.1-2.2">EIDs all appear in the normal routing and forwarding
            tables of the network (i.e., they are 'routable'). This property is used
     to load EID-to-RLOC mappings via bootstrapping operations. Packets are
     sent with the EID as the destination in
            the outer wrapper; when an ETR sees such a packet, it sends a
            Map-Reply to the source ITR, giving the full mapping.<a href="#appendix-A.1-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="appendix-A.1-2.3">LISP 1.5:</dt>
          <dd style="margin-left: 1.5em" id="appendix-A.1-2.4">LISP 1.5 is similar to LISP 1, but the routability of EIDs happens
            on a separate network.<a href="#appendix-A.1-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="appendix-A.1-2.5">LISP 2:</dt>
          <dd style="margin-left: 1.5em" id="appendix-A.1-2.6">EIDs are not routable; EID-to-RLOC mappings are available
            from the DNS.<a href="#appendix-A.1-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="appendix-A.1-2.7">LISP 3:</dt>
          <dd style="margin-left: 1.5em" id="appendix-A.1-2.8">EIDs are not routable and have to be looked up in a
            new EID-to-RLOC mapping database (in the initial concept, a system
            using Distributed Hash Tables).  Two variants were possible: a
            'push' system in which all mappings were distributed to all ITRs
            and a 'pull' system in which ITRs load the mappings when they need them.<a href="#appendix-A.1-2.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</section>
<div id="Acknowledgments">
<section id="appendix-B">
      <h2 id="name-acknowledgments">
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
      </h2>
<p id="appendix-B-1">This document was initiated by <span class="contact-name">Noel Chiappa</span>,
      and much of the core philosophy came from him.  The authors acknowledge
      the important contributions he has made to this work and thank him for
      his past efforts.<a href="#appendix-B-1" class="pilcrow">¶</a></p>
<p id="appendix-B-2">The authors would also like to thank <span class="contact-name">Dino       Farinacci</span>, <span class="contact-name">Fabio Maino</span>, <span class="contact-name">Luigi Iannone</span>, <span class="contact-name">Sharon Barkai</span>,
      <span class="contact-name">Isidoros Kouvelas</span>, <span class="contact-name">Christian       Cassar</span>, <span class="contact-name">Florin Coras</span>, <span class="contact-name">Marc       Binderberger</span>, <span class="contact-name">Alberto Rodriguez-Natal</span>,
      <span class="contact-name">Ronald Bonica</span>, <span class="contact-name">Chad Hintz</span>,
      <span class="contact-name">Robert Raszuk</span>, <span class="contact-name">Joel       M. Halpern</span>, <span class="contact-name">Darrel Lewis</span>, and <span class="contact-name">David Black</span>.<a href="#appendix-B-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="appendix-C">
      <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">Albert Cabellos</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>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Damien Saucez (<span class="role">editor</span>)</span></div>
<div dir="auto" class="left"><span class="org">Inria</span></div>
<div dir="auto" class="left"><span class="street-address">2004 route des Lucioles - BP 93</span></div>
<div dir="auto" class="left"><span class="locality">Sophia Antipolis</span></div>
<div dir="auto" class="left"><span class="country-name">France</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:damien.saucez@inria.fr" class="email">damien.saucez@inria.fr</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>