File: rfc8818.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 (2357 lines) | stat: -rw-r--r-- 103,612 bytes
parent folder | download | duplicates (2)
<!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 8818: Distributed Mobility Anchoring</title>
<meta content="H. Anthony Chan" name="author">
<meta content="Xinpeng Wei" name="author">
<meta content="Jong-Hyouk Lee" name="author">
<meta content="Seil Jeon" name="author">
<meta content="Carlos J. Bernardos" name="author">
<meta content="
       
This document defines distributed mobility anchoring in terms of the different
configurations and functions to provide IP mobility support. A network may be
configured with distributed mobility anchoring functions for both network-based
or host-based mobility support, depending on the network's needs. In a
distributed mobility anchoring environment, multiple anchors are available for
mid-session switching of an IP prefix anchor. To start a new flow or to handle a
flow not requiring IP session continuity as a mobile node moves to a new
network, the flow can be started or restarted using an IP address configured
from the new IP prefix anchored to the new network. If the flow needs to survive
the change of network, there are solutions that can be used to enable IP address
mobility. This document describes different anchoring approaches, depending on
the IP mobility needs, and how this IP address mobility is handled by the
network.
 
    " name="description">
<meta content="xml2rfc 3.3.0" name="generator">
<meta content="anchor" name="keyword">
<meta content="address continuity" name="keyword">
<meta content="reachability" name="keyword">
<meta content="continuity" name="keyword">
<meta content="PMIPv6" name="keyword">
<meta content="MIPv6" name="keyword">
<meta content="8818" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.3.0
    Python 3.6.10
    appdirs 1.4.4
    ConfigArgParse 1.2.3
    google-i18n-address 2.3.5
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.2
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.19.0
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.3.1
    requests 2.22.0
    setuptools 40.6.2
    six 1.14.0
    WeasyPrint 51
-->
<link href="rfc8818.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 {
  border: none;
  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
     support flexbox yet.
  */
  display: table;
  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.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, code {
  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;
}
#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;
  }
  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, code {
  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,
  .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: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: avoid-page;
  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";
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc8818" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-dmm-distributed-mobility-anchoring-15" rel="prev">
  </head>
<body>
<script src="https://www.rfc-editor.org/js/metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">RFC 8818</td>
<td class="center">Distributed Mobility Anchoring</td>
<td class="right">October 2020</td>
</tr></thead>
<tfoot><tr>
<td class="left">Chan, et al.</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/rfc8818" class="eref">8818</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Informational</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2020-10" class="published">October 2020</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">H. Chan, <span class="editor">Ed.</span>
</div>
<div class="org">CIHE</div>
</div>
<div class="author">
      <div class="author-name">X. Wei</div>
<div class="org">Huawei Technologies</div>
</div>
<div class="author">
      <div class="author-name">J. Lee</div>
<div class="org">Sejong University</div>
</div>
<div class="author">
      <div class="author-name">S. Jeon</div>
<div class="org">Sungkyunkwan University</div>
</div>
<div class="author">
      <div class="author-name">CJ. Bernardos, <span class="editor">Ed.</span>
</div>
<div class="org">UC3M</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8818</h1>
<h1 id="title">Distributed Mobility Anchoring</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">
This document defines distributed mobility anchoring in terms of the different
configurations and functions to provide IP mobility support. A network may be
configured with distributed mobility anchoring functions for both network-based
or host-based mobility support, depending on the network's needs. In a
distributed mobility anchoring environment, multiple anchors are available for
mid-session switching of an IP prefix anchor. To start a new flow or to handle a
flow not requiring IP session continuity as a mobile node moves to a new
network, the flow can be started or restarted using an IP address configured
from the new IP prefix anchored to the new network. If the flow needs to survive
the change of network, there are solutions that can be used to enable IP address
mobility. This document describes different anchoring approaches, depending on
the IP mobility needs, and how this IP address mobility is handled by the
network.<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/rfc8818">https://www.rfc-editor.org/info/rfc8818</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) 2020 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 Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified 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="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-conventions-and-terminology" class="xref">Conventions and Terminology</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-distributed-mobility-anchor" class="xref">Distributed Mobility Anchoring</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-configurations-for-differen" class="xref">Configurations for Different Networks</a><a href="#section-toc.1-1.3.2.1.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.3.2.1.2.1">
                    <p id="section-toc.1-1.3.2.1.2.1.1" class="keepWithNext"><a href="#section-3.1.1" class="xref">3.1.1</a>.  <a href="#name-network-based-dmm" class="xref">Network-Based DMM</a><a href="#section-toc.1-1.3.2.1.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty toc compact" id="section-toc.1-1.3.2.1.2.2">
                    <p id="section-toc.1-1.3.2.1.2.2.1"><a href="#section-3.1.2" class="xref">3.1.2</a>.  <a href="#name-client-based-dmm" class="xref">Client-Based DMM</a><a href="#section-toc.1-1.3.2.1.2.2.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-ip-mobility-handling-in-dis" class="xref">IP Mobility Handling in Distributed Anchoring Environments: Mobility Support Only When Needed</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-nomadic-case" class="xref">Nomadic Case</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.4.2.2">
                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-mobility-case-with-traffic-" class="xref">Mobility Case with Traffic Redirection</a><a href="#section-toc.1-1.4.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.4.2.3">
                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-mobility-case-with-anchor-r" class="xref">Mobility Case with Anchor Relocation</a><a href="#section-toc.1-1.4.2.3.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-references" class="xref">References</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.7.2.1">
                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.7.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.7.2.2">
                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.7.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-appendix.a" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-contributors" class="xref">Contributors</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-appendix.c" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="intro">
<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">
A key requirement in distributed mobility management (DMM) <span>[<a href="#RFC7333" class="xref">RFC7333</a>]</span> is
to enable traffic to avoid traversing a single mobility anchor far from an
optimal route. This document defines different configurations, functional
operations, and parameters for distributed mobility anchoring and explains how to
use them to avoid unnecessarily long routes when a mobile node moves.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">
Other distributed mobility management documents already address
source address selection <span>[<a href="#RFC8653" class="xref">RFC8653</a>]</span> and
control-plane and data-plane signaling <span>[<a href="#I-D.ietf-dmm-fpc-cpdp" class="xref">FPC-DMM-PROTOCOL</a>]</span>. A
number of distributed mobility solutions have also been proposed, for example,
in <span>[<a href="#I-D.seite-dmm-dma" class="xref">DMM-DMA</a>]</span>, <span>[<a href="#RFC8885" class="xref">RFC8885</a>]</span>, <span>[<a href="#I-D.sarikaya-dmm-for-wifi" class="xref">DMM-WIFI</a>]</span>, <span>[<a href="#I-D.yhkim-dmm-enhanced-anchoring" class="xref">DMM-ENHANCED-ANCHORING</a>]</span>, and <span>[<a href="#I-D.matsushima-stateless-uplane-vepc" class="xref">STATELESS-UPLANE-VEPC</a>]</span>.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">
Distributed mobility anchoring employs multiple anchors in the data plane. In
general, control-plane functions may be separated from data-plane functions and
be centralized but may also be co-located with the data-plane functions at the
distributed anchors. Different configurations of distributed mobility anchoring
are described in <a href="#sec_distributed-anchoring-configurations" class="xref">Section 3.1</a>.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">
As a Mobile Node (MN) attaches to an access router and establishes a link
between them, a /64 IPv6 prefix anchored to the router may be assigned to the
link for exclusive use by the MN <span>[<a href="#RFC6459" class="xref">RFC6459</a>]</span>. The MN may then
configure a global IPv6 address from this prefix and use it as the source IP
address in a flow to communicate with its Correspondent Node (CN). When there
are multiple mobility anchors assigned to the same MN, an address selection for
a given flow is first required before the flow is initiated. Using an anchor in
an MN's network of attachment has the advantage that the packets can simply be
forwarded according to the forwarding table. However, after the flow has been
initiated, the MN may later move to another network that assigns a new mobility
anchor to the MN. Since the new anchor is located in a different network, the
MN's assigned prefix does not belong to the network where the MN is currently
attached.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">
When the MN wants to continue using its assigned prefix to complete ongoing data
sessions after it has moved to a new network, the network needs to provide
support for the MN's IP address and session continuity, since routing packets
to the MN through the new network deviates from applying default routes. The IP
session continuity needs of a flow (application) determine how the IP address
used by this flow has to be anchored. If the ongoing IP flow can cope with an IP
prefix/address change, the flow can be reinitiated with a new IP address
anchored in the new network. On the other hand, if the ongoing IP flow cannot
cope with such change, mobility support is needed. A network supporting a mix of
flows both requiring and not requiring IP mobility support will need to
distinguish these flows.<a href="#section-1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec_definitions">
<section id="section-2">
      <h2 id="name-conventions-and-terminology">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-conventions-and-terminology" class="section-name selfRef">Conventions and Terminology</a>
      </h2>
<p id="section-2-1">
    The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>",
    "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>",
    "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
    "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document are
    to be interpreted as described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span>
        <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> when, and only when, they appear in all capitals,
    as shown here.<a href="#section-2-1" class="pilcrow">¶</a></p>
<p id="section-2-2">
All general mobility-related terms and their acronyms used in this document
are to be interpreted as defined in the Mobile IPv6 (MIPv6) base specification
<span>[<a href="#RFC6275" class="xref">RFC6275</a>]</span>, the Proxy Mobile IPv6 (PMIPv6)
specification <span>[<a href="#RFC5213" class="xref">RFC5213</a>]</span>, the Mobility
Terminology document <span>[<a href="#RFC3753" class="xref">RFC3753</a>]</span>, and the DMM
Current Practices and Gap Analysis document <span>[<a href="#RFC7429" class="xref">RFC7429</a>]</span>.
These include terms such as Mobile Node (MN), Correspondent Node (CN), Home
Agent (HA), Home Address (HoA), Care-of-Address (CoA), Local Mobility Anchor
(LMA), and Mobile Access Gateway (MAG).<a href="#section-2-2" class="pilcrow">¶</a></p>
<p id="section-2-3">In addition, this document uses the following terms and definitions:<a href="#section-2-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-2-4">
        <dt id="section-2-4.1">IP session continuity:</dt>
        <dd style="margin-left: 1.5em" id="section-2-4.2">
          <p id="section-2-4.2.1">
The ability to maintain an ongoing transport interaction by keeping the same
local endpoint IP address throughout the lifetime of the IP socket despite the
mobile host changing its point of attachment within the IP network topology. The
IP address of the host may change after closing the IP socket and before opening
a new one, but that does not jeopardize the ability of applications using these
IP sockets to work flawlessly. Session continuity is essential for mobile hosts
to maintain ongoing flows without any interruption <span>[<a href="#RFC8653" class="xref">RFC8653</a>]</span>.<a href="#section-2-4.2.1" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-2-4.3">Higher-layer session continuity:</dt>
        <dd style="margin-left: 1.5em" id="section-2-4.4">
          <p id="section-2-4.4.1">
The ability to maintain an ongoing transport- or higher-layer (e.g., application)
interaction by keeping the session identifiers throughout the lifetime of the
session despite the mobile host changing its point of attachment within the IP
network topology. This can be achieved by using mechanisms at the transport or
higher layers.<a href="#section-2-4.4.1" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-2-4.5">IP address reachability:</dt>
        <dd style="margin-left: 1.5em" id="section-2-4.6">
          <p id="section-2-4.6.1">
The ability to maintain the same IP address for an extended period of time. The
IP address stays the same across independent sessions, even in the absence of
any session. The IP address may be published in a long-term registry (e.g., DNS)
and is made available for serving incoming (e.g., TCP) connections. IP address
reachability is essential for mobile hosts to use specific/published IP
addresses <span>[<a href="#RFC8653" class="xref">RFC8653</a>]</span>.<a href="#section-2-4.6.1" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-2-4.7">IP mobility:</dt>
        <dd style="margin-left: 1.5em" id="section-2-4.8">
          <p id="section-2-4.8.1">
The combination of IP address reachability and session continuity.<a href="#section-2-4.8.1" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-2-4.9">Anchoring (of an IP prefix/address):</dt>
        <dd style="margin-left: 1.5em" id="section-2-4.10">
          <p id="section-2-4.10.1">
An IP prefix (i.e., Home Network Prefix (HNP)) or address (i.e., HoA) assigned
for use by an MN is topologically anchored to an anchor node when the anchor
node is able to advertise a route into the routing infrastructure for the
assigned IP prefix. The traffic using the assigned IP address/prefix must
traverse the anchor node. We can refer to the function performed by the IP anchor
node as anchoring, which is a data-plane function.<a href="#section-2-4.10.1" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-2-4.11">Location Management (LM) function:</dt>
        <dd style="margin-left: 1.5em" id="section-2-4.12">
          <p id="section-2-4.12.1">
A control-plane function that keeps and manages the network location information
of an MN. The location information may be a binding of the advertised IP
address/prefix (e.g., HoA or HNP) to the IP routing address of the MN or of a
node that can forward packets destined to the MN.<a href="#section-2-4.12.1" class="pilcrow">¶</a></p>
<p id="section-2-4.12.2"> 

When the MN is a Mobile Router (MR), the location information will also include
the Mobile Network Prefix (MNP), which is the aggregate IP prefix delegated to
the MR to assign IP prefixes for use by the Mobile Network Nodes (MNNs) in the
mobile network.<a href="#section-2-4.12.2" class="pilcrow">¶</a></p>
<p id="section-2-4.12.3"> 
 
In a client-server protocol model, secure (i.e., authenticated and authorized) location query and update messages may be
exchanged between a Location Management client (LMc) and a Location Management
server (LMs), where the location information can be updated or queried from
the LMc.

Optionally, there may be a Location Management proxy (LMp) between LMc and LMs.<a href="#section-2-4.12.3" class="pilcrow">¶</a></p>
<p id="section-2-4.12.4"> 

With separation of control plane and data plane, the LM function is in the
control plane. It may be a logical function at the control-plane node, control-plane anchor, or mobility controller.<a href="#section-2-4.12.4" class="pilcrow">¶</a></p>
<p id="section-2-4.12.5"> 

It may be distributed or centralized.<a href="#section-2-4.12.5" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-2-4.13">Forwarding Management (FM) function:</dt>
        <dd style="margin-left: 1.5em" id="section-2-4.14">
          <p id="section-2-4.14.1">
Packet interception and forwarding to/from the IP address/prefix 
assigned for use by the MN, based on the internetwork location information, 
either to the destination or to some other network element 
that knows how to forward the packets to their destination.<a href="#section-2-4.14.1" class="pilcrow">¶</a></p>
<p id="section-2-4.14.2">

This function may be used to achieve traffic indirection. 
With separation of control plane and data plane, 
the FM function may split into an FM function in the data plane (FM-DP) 
and an FM function in the control plane (FM-CP).<a href="#section-2-4.14.2" class="pilcrow">¶</a></p>
<p id="section-2-4.14.3"> 

FM-DP may be distributed with distributed mobility management. 
It may be a function in a data-plane anchor or data-plane node.<a href="#section-2-4.14.3" class="pilcrow">¶</a></p>
<p id="section-2-4.14.4"> 

FM-CP may be distributed or centralized. 
It may be a function in a control-plane node,
control-plane anchor, or mobility controller.<a href="#section-2-4.14.4" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-2-4.15">Home Control-Plane Anchor (Home-CPA or H-CPA):</dt>
        <dd style="margin-left: 1.5em" id="section-2-4.16">
          <p id="section-2-4.16.1">
The Home-CPA function hosts the MN's mobility
session.  There can be more than one mobility session for a mobile
node, and those sessions may be anchored on the same or different
Home-CPA's.  The Home-CPA will interface with the Home-DPA for
managing the forwarding state.<a href="#section-2-4.16.1" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-2-4.17">Home Data-Plane Anchor (Home-DPA or H-DPA):</dt>
        <dd style="margin-left: 1.5em" id="section-2-4.18">
          <p id="section-2-4.18.1">
The Home-DPA is the topological anchor for the MN's IP address/prefix(es).
The Home-DPA is chosen by the Home-CPA on a session basis.  The Home-DPA is
in the forwarding path for all the mobile node's IP traffic.<a href="#section-2-4.18.1" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-2-4.19">Access Control-Plane Node (Access-CPN or A-CPN):</dt>
        <dd style="margin-left: 1.5em" id="section-2-4.20">
          <p id="section-2-4.20.1">
The Access-CPN is responsible for interfacing with the mobile
node's Home-CPA and with the Access-DPN.  The Access-CPN has a
protocol interface to the Home-CPA.<a href="#section-2-4.20.1" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-2-4.21">Access Data-Plane Node (Access-DPN or A-DPN):</dt>
        <dd style="margin-left: 1.5em" id="section-2-4.22">
          <p id="section-2-4.22.1">
The Access-DPN function is hosted on the first-hop router where
the mobile node is attached.  This function is not hosted on a
Layer 2 bridging device such as an eNode(B) or Access Point.<a href="#section-2-4.22.1" class="pilcrow">¶</a></p>
</dd>
      <dd class="break"></dd>
</dl>
</section>
</div>
<div id="sec_distributed-anchoring">
<section id="section-3">
      <h2 id="name-distributed-mobility-anchor">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-distributed-mobility-anchor" class="section-name selfRef">Distributed Mobility Anchoring</a>
      </h2>
<div id="sec_distributed-anchoring-configurations">
<section id="section-3.1">
        <h3 id="name-configurations-for-differen">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-configurations-for-differen" class="section-name selfRef">Configurations for Different Networks</a>
        </h3>
<p id="section-3.1-1">
We next describe some configurations with multiple distributed anchors. To
cover the widest possible spectrum of scenarios, we consider architectures in
which the control and data planes are separated. We analyze where LM and FM
functions, which are specific sub-functions involved in mobility management,
can be placed when looking at the different scenarios with distributed
anchors.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<div id="sec_distributed-anchoring-network-based">
<section id="section-3.1.1">
          <h4 id="name-network-based-dmm">
<a href="#section-3.1.1" class="section-number selfRef">3.1.1. </a><a href="#name-network-based-dmm" class="section-name selfRef">Network-Based DMM</a>
          </h4>
<p id="section-3.1.1-1">
<a href="#fig_dmm_net-based" class="xref">Figure 1</a> shows a general scenario for network-based
distributed mobility management.<a href="#section-3.1.1-1" class="pilcrow">¶</a></p>
<p id="section-3.1.1-2">
The main characteristics of a network-based DMM solution are:<a href="#section-3.1.1-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.1.1-3.1">
There are multiple data-plane anchors, each with an FM-DP function.<a href="#section-3.1.1-3.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.1.1-3.2">
The control plane may either be distributed (not shown in the figure) or
centralized (as shown in the figure).<a href="#section-3.1.1-3.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.1.1-3.3">


 The Control-Plane Anchor (CPA) and the Data Plane Anchor (DPA) may or may not
 be co-located.  If the CPA is co-located with the distributed DPAs, then
 there are multiple co-located CPA-DPA instances (not shown in the figure).<a href="#section-3.1.1-3.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.1.1-3.4">
An IP prefix/address IP1 (anchored to the DPA with IP address IPa1) is assigned
for use to an MN. The MN uses this IP1 address to communicate with CNs (not
shown in the figure).<a href="#section-3.1.1-3.4" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.1.1-3.5">
The location management (LM) function may be co-located or split (as shown in
the figure) into a separate server (LMs) and a client (LMc). In this case, the
LMs may be centralized whereas the LMc may be distributed or centralized.<a href="#section-3.1.1-3.5" class="pilcrow">¶</a>
</li>
          </ul>
<span id="name-network-based-dmm-configura"></span><div id="fig_dmm_net-based">
<figure id="figure-1">
            <div class="artwork art-text alignLeft" id="section-3.1.1-4.1">
<pre>
           ____________  Network
       ___/            \___________
      /      +-----+                \___
     (       |LMs  |    Control-        \
    /        +-.---+    plane            \
   /  +--------.---+    functions         \
  (   |CPA:    .   |    in the             )
  (   |FM-CP, LMc  |    network            )
  (   +------------+                        \
 /          . .                              \
(           .     .                           )
(           .         .                       )
(           .             .                   \
 \    +------------+ +------------+Distributed )
  (   |DPA(IPa1):  | |DPA(IPa2):  |DPAs        )
  (   |anchors IP1 | |anchors IP2 |          _/
   \  |FM-DP       | |FM-DP       | etc.    /
    \ +------------+ +------------+        /
     \___                Data-plane  _____/
         \______         functions  /
                \__________________/

      +------------+
      |MN(IP1)     | Mobile node attached
      |flow(IP1,..)| to the network
      +------------+
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-network-based-dmm-configura" class="selfRef">Network-Based DMM Configuration</a>
            </figcaption></figure>
</div>
</section>
</div>
<div id="sec_distributed-anchoring-host-based">
<section id="section-3.1.2">
          <h4 id="name-client-based-dmm">
<a href="#section-3.1.2" class="section-number selfRef">3.1.2. </a><a href="#name-client-based-dmm" class="section-name selfRef">Client-Based DMM</a>
          </h4>
<p id="section-3.1.2-1">
<a href="#fig_dmm_client-based" class="xref">Figure 2</a> shows a general scenario for client-based
distributed mobility management. In this configuration, the mobile node performs
Control-Plane Node (CPN) and Data-Plane Node (DPN) mobility functions, namely
the forwarding management and location management (client) roles.<a href="#section-3.1.2-1" class="pilcrow">¶</a></p>
<span id="name-client-based-dmm-configurat"></span><div id="fig_dmm_client-based">
<figure id="figure-2">
            <div class="artwork art-text alignLeft" id="section-3.1.2-2.1">
<pre>
       +-----+
       |LMs  |
       +-.---+
+--------.---+
|CPA:    .   |
|FM-CP, LMp  |
+------------+
      . .
      .     .
      .         .
      .             .
+------------+ +------------+ Distributed
|DPA(IPa1):  | |DPA(IPa2):  | DPAs
|anchors IP1 | |anchors IP2 |
|FM-DP       | |FM-DP       |  etc.
+------------+ +------------+

+------------+
|MN(IP1)     |Mobile node
|flow(IP1,..)|using IP1
|FM,    LMc  |anchored to
+------------+DPA(IPa1)
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-client-based-dmm-configurat" class="selfRef">Client-Based DMM Configuration</a>
            </figcaption></figure>
</div>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="sec_on-demand">
<section id="section-4">
      <h2 id="name-ip-mobility-handling-in-dis">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-ip-mobility-handling-in-dis" class="section-name selfRef">IP Mobility Handling in Distributed Anchoring Environments: Mobility Support Only When Needed</a>
      </h2>
<p id="section-4-1">
IP mobility support may be provided only when needed instead of being provided
by default. Three cases can be considered:<a href="#section-4-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4-2.1">
Nomadic case: No address continuity is required. The IP address used by the MN
changes after a movement and traffic using the old address is disrupted. If
session continuity is required, then it needs to be provided by a solution
running at Layer 4 or above.<a href="#section-4-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-4-2.2">
Mobility case with traffic redirection: Address continuity is required. When the
MN moves, the previous anchor still anchors the traffic using the old IP
address and forwards it to the new MN's location. The MN obtains a new IP
address anchored to the new location and preferably uses it for new
communications established while connected at the new location.<a href="#section-4-2.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-4-2.3">
Mobility case with anchor relocation: Address continuity is required. In this case,
the route followed by the traffic is optimized by using some means for traffic
indirection to deviate from default routes.<a href="#section-4-2.3" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-4-3">

A straightforward choice of mobility anchoring is the following: the MN
chooses, as a source IP address for packets belonging to an IP flow, an
address allocated by the network the MN is attached to when the flow was
initiated.


As such, traffic belonging to this flow traverses the MN's mobility anchor
<span>[<a href="#I-D.seite-dmm-dma" class="xref">DMM-DMA</a>]</span> <span>[<a href="#RFC8885" class="xref">RFC8885</a>]</span>.<a href="#section-4-3" class="pilcrow">¶</a></p>
<p id="section-4-4">
The IP prefix/address at the MN's side of a flow may be anchored to the Access
Router (AR) to which the MN is attached. For example, when an MN attaches to a
network (Net1) or moves to a new network (Net2), an IP prefix from the attached
network is assigned to the MN's interface. In addition to configuring new
link-local addresses, the MN configures from this prefix an IP address that is
typically a dynamic IP address (meaning that this address is only used while the
MN is attached to this access router, so the IP address configured by
the MN dynamically changes when attaching to a different access network). It
then uses this IP address when a flow is initiated. Packets from this flow
addressed to the MN are simply forwarded according to the forwarding table.<a href="#section-4-4" class="pilcrow">¶</a></p>
<p id="section-4-5">
There may be multiple IP prefixes/addresses that an MN can select when
initiating a flow. They may be from the same access network or different
access networks. The network may advertise these prefixes with cost options
<span>[<a href="#I-D.mccann-dmm-prefixcost" class="xref">PREFIX-COST</a>]</span> so that the mobile
node may choose the one with the least cost. In addition, the IP
prefixes/addresses provided by the network may be of different types regarding
whether mobility support is supported <span>[<a href="#RFC8653" class="xref">RFC8653</a>]</span>. An MN will need to choose which IP prefix/address to use
for each flow according to whether or not it needs IP mobility support, 
for example, using the mechanisms described in <span>[<a href="#RFC8653" class="xref">RFC8653</a>]</span>.<a href="#section-4-5" class="pilcrow">¶</a></p>
<div id="sec_changing-anchor">
<section id="section-4.1">
        <h3 id="name-nomadic-case">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-nomadic-case" class="section-name selfRef">Nomadic Case</a>
        </h3>
<p id="section-4.1-1">
When IP mobility support is not needed for a flow, the LM and FM functions are
not utilized so that the configurations in <a href="#sec_distributed-anchoring-configurations" class="xref">Section 3.1</a> are simplified as shown in
<a href="#fig_change-net" class="xref">Figure 3</a>.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<span id="name-changing-to-a-new-ip-addres"></span><div id="fig_change-net">
<figure id="figure-3">
          <div class="artwork art-text alignLeft" id="section-4.1-2.1">
<pre>
Net1                                                Net2

+---------------+                                   +---------------+
|AR1            |            AR is changed          |AR2            |
+---------------+              -------&gt;             +---------------+
|CPA:           |                                   |CPA:           |
|---------------|                                   |---------------|
|DPA(IPa1):     |                                   |DPA(IPa2):     |
|anchors IP1    |                                   |anchors IP2    |
+---------------+                                   +---------------+

+...............+                                   +---------------+
.MN(IP1)        .              MN moves             |MN(IP2)        |
.flow(IP1,...)  .              =======&gt;             |flow(IP2,...)  |
+...............+                                   +---------------+
</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-changing-to-a-new-ip-addres" class="selfRef">Changing to a New IP Address/Prefix</a>
          </figcaption></figure>
</div>
<p id="section-4.1-3">
When there is no need to provide IP mobility to a flow, the flow may use a new
IP address acquired from a new network as the MN moves to the new network.<a href="#section-4.1-3" class="pilcrow">¶</a></p>
<p id="section-4.1-4">
Regardless of whether or not IP mobility is needed, if the flow has not terminated before
the MN moves to a new network, the flow may subsequently restart using the new
IP address assigned from the new network.<a href="#section-4.1-4" class="pilcrow">¶</a></p>
<p id="section-4.1-5">
When IP session continuity is needed, even if an application flow is ongoing as
the MN moves, it may still be desirable for the application flow to change to
using the new IP prefix configured in the new network. The application flow may
then be closed at the IP level and then be restarted using a new IP address
configured in the new network. Such a change in the IP address used by the
application flow may be enabled using a higher-layer mobility support that is
not in the scope of this document.<a href="#section-4.1-5" class="pilcrow">¶</a></p>
<p id="section-4.1-6">
In <a href="#fig_change-net" class="xref">Figure 3</a>, a flow initiated while the MN was using the
IP prefix IP1, anchored to a previous access router AR1 in network Net1, has
terminated before the MN moves to a new network Net2. After moving to Net2, the
MN uses the new IP prefix IP2, anchored to a new access router AR2 in network
Net2, to start a new flow. Packets may then be forwarded without requiring IP-layer mobility support.<a href="#section-4.1-6" class="pilcrow">¶</a></p>
<p id="section-4.1-7">
An example call flow is outlined in <a href="#fig_change-net-flow" class="xref">Figure 4</a>. An MN attaches to AR1, which sends a router advertisement
(RA) including information about the prefix assigned to the MN, from which the
MN configures an IP address (IP1).  This address is used for new
communications, for example, with a correspondent node (CN). If the MN moves to
a new network and attaches to AR2, the process is repeated (the MN obtains a new
IP address, IP2, from AR2). Since the IP address (IP1) configured at the
previously visited network is not valid at the current attachment point,
any existing flows have to be reestablished using IP2.<a href="#section-4.1-7" class="pilcrow">¶</a></p>
<p id="section-4.1-8">
Note that in these scenarios, if there is no mobility support provided by
Layer 4 or
above, application traffic would stop.<a href="#section-4.1-8" class="pilcrow">¶</a></p>
<span id="name-restarting-a-flow-with-new-"></span><div id="fig_change-net-flow">
<figure id="figure-4">
          <div class="artwork art-text alignLeft" id="section-4.1-9.1">
<pre>
 MN                    AR1           AR2                           CN
  |MN attaches to AR1:  |             |                             |
  |acquires MN-ID and profile         |                             |
  |--RS----------------&gt;|             |                             |
  |                     |             |                             |
  |&lt;----------RA(IP1)---|             |                             |
  |                     |             |                             |
Assigned prefix IP1     |             |                             |
IP1 address configuration             |                             |
  |                     |             |                             |
  |&lt;-Flow(IP1,IPcn,...)-+------------------------------------------&gt;|
  |                     |             |                             |
  |MN detaches from AR1 |             |                             |
  |MN attaches to AR2   |             |                             |
  |                     |             |                             |
  |--RS------------------------------&gt;|                             |
  |                     |             |                             |
  |&lt;--------------RA(IP2)-------------|                             |
  |                     |             |                             |
Assigned prefix IP2     |             |                             |
IP2 address configuration             |                             |
  |                     |             |                             |
  |&lt;-new Flow(IP2,IPcn,...)-----------+----------------------------&gt;|
  |                     |             |                             |
</pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
<a href="#name-restarting-a-flow-with-new-" class="selfRef">Restarting a Flow with New IP Prefix/Address</a>
          </figcaption></figure>
</div>
</section>
</div>
<div id="sec_traffic_redirection">
<section id="section-4.2">
        <h3 id="name-mobility-case-with-traffic-">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-mobility-case-with-traffic-" class="section-name selfRef">Mobility Case with Traffic Redirection</a>
        </h3>
<p id="section-4.2-1">
When IP mobility is needed for a flow, the LM and FM functions in <a href="#sec_distributed-anchoring-configurations" class="xref">Section 3.1</a> are utilized. There are two
possible cases: (i) the mobility anchor remains playing that role and forwards traffic to a new locator in the new network, and (ii) the mobility anchor (data-plane
function) is changed but binds the MN's transferred IP address/prefix. 


The latter enables optimized routes but requires some data-plane node that
enforces traffic indirection. We focus on the first case in this section. The
second case is addressed in <a href="#sec_anchor_relocation" class="xref">Section 4.3</a>.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<p id="section-4.2-2">
Mobility support can be provided by using mobility management methods, such as
the approaches surveyed in the following academic papers: <span>[<a href="#IEEE-DISTRIBUTED-MOBILITY" class="xref">IEEE-DISTRIBUTED-MOBILITY</a>]</span>, <span>[<a href="#PMIP-DMA" class="xref">PMIP-DMA</a>]</span>, and <span>[<a href="#DMM-MOBILE-INTERNET" class="xref">DMM-MOBILE-INTERNET</a>]</span>. After moving, a certain MN's traffic flow may continue
using the IP prefix from the prior network of attachment. Yet, some time
later, the application generating this traffic flow may be closed. If the
application is started again, the new flow may not need to use the prior
network's IP address to avoid having to invoke IP mobility support. This may
be the case where a dynamic IP prefix/address, rather than a permanent one, is
used. Packets belonging to this flow may then use the new IP prefix (the one
allocated in the network where the flow is being initiated).  Routing is again
kept simpler without employing IP mobility and will remain so as long as the
MN, which is now in the new network, does not move again to another network.<a href="#section-4.2-2" class="pilcrow">¶</a></p>
<p id="section-4.2-3">
An example call flow in this case is outlined in <a href="#fig_flow-continuity" class="xref">Figure 5</a>. In this example, the AR1
plays the role of the FM-DP entity and redirects the traffic (e.g., using an IP
tunnel) to AR2.<a href="#section-4.2-3" class="pilcrow">¶</a></p>
<span id="name-flow-using-ip-prefix-from-h"></span><div id="fig_flow-continuity">
<figure id="figure-5">
          <div class="artwork art-text alignLeft" id="section-4.2-4.1">
<pre>
 MN                    AR1           AR2                           CN
  |MN attaches to AR1:  |             |                             |
  |acquires MN-ID and profile         |                             |
  |--RS----------------&gt;|             |                             |
  |                     |             |                             |
  |&lt;----------RA(IP1)---|             |                             |
  |                     |             |                             |
Assigned prefix IP1     |             |                             |
IP1 address configuration             |                             |
  |                     |             |                             |
  |&lt;-Flow(IP1,IPcn,...)-+------------------------------------------&gt;|
  |                     |             |                             |
  |MN detaches from AR1 |             |                             |
  |MN attaches to AR2   |             |                             |
  |                     |             |                             |
  |--RS------------------------------&gt;|                             |
   (some IP mobility support solution)
  |&lt;--------------RA(IP2,IP1)---------|                             |
  |                     |             |                             |
  |                     +&lt;-Flow(IP1,IPcn,...)----------------------&gt;|
  |                     +&lt;===========&gt;+                             |
  |&lt;-Flow(IP1,IPcn,...)--------------&gt;+                             |
  |                     |             |                             |
Assigned prefix IP2     |             |                             |
IP2 address configuration             |                             |
  |                     |             |                             |
Flow(IP1,IPcn) terminates             |                             |
  |                     |             |                             |
  |&lt;-new Flow(IP2,IPcn,...)-----------+----------------------------&gt;|
  |                     |             |                             |
</pre>
</div>
<figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
<a href="#name-flow-using-ip-prefix-from-h" class="selfRef">Flow Using IP Prefix from Home Network after MN has
          Moved</a>
          </figcaption></figure>
</div>
<p id="section-4.2-5">
Another solution could be to place an FM-DP entity closer to
the CN network to perform traffic steering to deviate from default routes
(which will bring the packet to AR1 per default routing). The LM and FM
functions are implemented as shown in <a href="#fig_anchor-redirection" class="xref">Figure 6</a>.<a href="#section-4.2-5" class="pilcrow">¶</a></p>
<span id="name-anchor-redirection"></span><div id="fig_anchor-redirection">
<figure id="figure-6">
          <div class="artwork art-text alignLeft" id="section-4.2-6.1">
<pre>
Net1                                                Net2

+---------------+                                   +---------------+
|AR1            |                                   |AR2            |
+---------------+                                   +---------------+
|CPA:           |                                   |CPA:           |
|               |                                   |LM:IP1 at IPa1 |
|---------------|      IP1 (anchored to Net1)       |---------------|
|DPA(IPa1):     |      is redirected to Net2        |DPA(IPa2):     |
|anchors IP1    |              =======&gt;             |anchors IP2    |
|FM:IP1 via IPa2|                                   |FM:IP1 via IPa1|
+---------------+                                   +---------------+

+...............+                                   +---------------+
.MN(IP1)        .              MN moves             |MN(IP2,IP1)    |
.flow(IP1,...)  .              =======&gt;             |flow(IP1,...)  |
.               .                                   |flow(IP2,...)  |
+...............+                                   +---------------+
</pre>
</div>
<figcaption><a href="#figure-6" class="selfRef">Figure 6</a>:
<a href="#name-anchor-redirection" class="selfRef">Anchor Redirection</a>
          </figcaption></figure>
</div>
<p id="section-4.2-7">
Multiple instances of DPAs (at access routers), which are providing IP prefixes
to the MNs, are needed to provide distributed mobility anchoring in an
appropriate configuration such as those described in <a href="#fig_dmm_net-based" class="xref">Figure 1</a> (<a href="#sec_distributed-anchoring-network-based" class="xref">Section 3.1.1</a>) for network-based
distributed mobility or in <a href="#fig_dmm_client-based" class="xref">Figure 2</a> (<a href="#sec_distributed-anchoring-host-based" class="xref">Section 3.1.2</a>) for client-based distributed
mobility.<a href="#section-4.2-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec_anchor_relocation">
<section id="section-4.3">
        <h3 id="name-mobility-case-with-anchor-r">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-mobility-case-with-anchor-r" class="section-name selfRef">Mobility Case with Anchor Relocation</a>
        </h3>
<p id="section-4.3-1">
We focus next on the case where the mobility anchor (data-plane function) is
changed but binds the MN's transferred IP address/prefix. This enables optimized
routes but requires some data-plane node that enforces traffic indirection.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<p id="section-4.3-2">
IP mobility is invoked to enable IP session continuity for an ongoing flow as
the MN moves to a new network. The anchoring of the IP address of the flow is in
the home network of the flow (i.e., different from the current network of
attachment). A centralized mobility management mechanism may employ indirection
from the anchor in the home network to the current network of attachment. Yet, it
may be difficult to avoid using an unnecessarily long route (when the route
between the MN and the CN via the anchor in the home network is significantly
longer than the direct route between them). An alternative is to move the IP
prefix/address anchoring to the new network.<a href="#section-4.3-2" class="pilcrow">¶</a></p>
<p id="section-4.3-3">
The IP prefix/address anchoring may move 
without changing the IP prefix/address of the flow.
The LM function in <a href="#fig_dmm_net-based" class="xref">Figure 1</a> of 
<a href="#sec_distributed-anchoring-network-based" class="xref">Section 3.1.1</a>
is implemented as shown in <a href="#fig_anchor-mobility" class="xref">Figure 7</a>.<a href="#section-4.3-3" class="pilcrow">¶</a></p>
<span id="name-anchor-relocation"></span><div id="fig_anchor-mobility">
<figure id="figure-7">
          <div class="artwork art-text alignLeft" id="section-4.3-4.1">
<pre>
Net1                                              Net2

+---------------+                                 +---------------+
|AR1            |                                 |AR2            |
+---------------+                                 +---------------+
|CPA:           |                                 |CPA:           |
|LM:IP1 at IPa1 |                                 |LM:IP1 at IPa2 |
|   changes to  |                                 |               |
|   IP1 at IPa2 |                                 |               |
|---------------|                                 |---------------|
|DPA(IPa1):     | IP1 anchoring effectively moved |DPA(IPa2):     |
|anchored IP1   |            =======&gt;             |anchors IP2,IP1|
+---------------+                                 +---------------+

+...............+                                 +---------------+
.MN(IP1)        .            MN moves             |MN(IP2,IP1)    |
.flow(IP1,...)  .            =======&gt;             |flow(IP1,...)  |
+...............+                                 +---------------+
</pre>
</div>
<figcaption><a href="#figure-7" class="selfRef">Figure 7</a>:
<a href="#name-anchor-relocation" class="selfRef">Anchor Relocation</a>
          </figcaption></figure>
</div>
<p id="section-4.3-5">
As an MN with an ongoing session moves to a new network, the flow may preserve
IP session continuity by moving the anchoring of the original IP prefix/address
of the flow to the new network.<a href="#section-4.3-5" class="pilcrow">¶</a></p>
<p id="section-4.3-6">
One way to accomplish such a move is to use a centralized routing protocol,
but such a solution may present some scalability concerns and its
applicability is typically limited to small networks. One example of this type
of solution is described in <span>[<a href="#I-D.ietf-rtgwg-atn-bgp" class="xref">BGP-ATN-IPS</a>]</span>. 

When an MN associates with an anchor, the anchor injects the MN's prefix into
the global routing system. If the MN moves to a new anchor, the old anchor
withdraws the /64 and the new anchor injects it instead.<a href="#section-4.3-6" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="security">
<section id="section-5">
      <h2 id="name-security-considerations">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-5-1">
As stated in <span>[<a href="#RFC7333" class="xref">RFC7333</a>]</span>, "a DMM solution <span class="bcp14">MUST</span> support any security
protocols and mechanisms needed to secure the network and to make continuous
security improvements". It "<span class="bcp14">MUST NOT</span> introduce new security risks".<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">
There are different potential deployment models of a DMM solution. The present
document has presented three different scenarios for distributed anchoring:
(i) nomadic case, (ii) mobility case with traffic redirection, and (iii)
mobility case with anchor relocation. Each of these cases has different security
requirements, and the actual security mechanisms depend on the specifics
of each solution/scenario.<a href="#section-5-2" class="pilcrow">¶</a></p>
<p id="section-5-3">
As general rules, for the first distributed anchoring scenario (nomadic case),
no additional security consideration is needed, as this does not involve any
additional mechanism at Layer 3. If session connectivity is required, the
Layer 4 or
above solution used to provide it <span class="bcp14">MUST</span> also provide the
required authentication and security.<a href="#section-5-3" class="pilcrow">¶</a></p>
<p id="section-5-4">
The second and third distributed anchoring scenarios (mobility case) involve
mobility signaling among the mobile node and the control-plane and data-plane
anchors. The control-plane messages exchanged between these entities
<span class="bcp14">MUST</span> be protected using end-to-end security associations with
data-integrity and data-origination capabilities. IPsec <span>[<a href="#RFC8221" class="xref">RFC8221</a>]</span> Encapsulating Security Payload (ESP) in transport mode with
mandatory integrity protection <span class="bcp14">SHOULD</span> be used for protecting
the signaling messages. Internet Key Exchange Protocol Version 2 (IKEv2) <span>[<a href="#RFC8247" class="xref">RFC8247</a>]</span>
        <span class="bcp14">SHOULD</span> be used to set up security associations between the data-plane
and control-plane anchors. Note that in scenarios in which traffic indirection
mechanisms are used to relocate an anchor, authentication and authorization
mechanisms <span class="bcp14">MUST</span> be used.<a href="#section-5-4" class="pilcrow">¶</a></p>
<p id="section-5-5">
Control-plane functionality <span class="bcp14">MUST</span> apply authorization checks to any commands or
updates that are made by the control-plane protocol.<a href="#section-5-5" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-6">
      <h2 id="name-iana-considerations">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-6-1">
This document has no IANA actions.<a href="#section-6-1" class="pilcrow">¶</a></p>
</section>
<section id="section-7">
      <h2 id="name-references">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-7.1">
        <h3 id="name-normative-references">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3753">[RFC3753]</dt>
        <dd>
<span class="refAuthor">Manner, J., Ed.</span><span class="refAuthor"> and M. Kojo, Ed.</span>, <span class="refTitle">"Mobility Related Terminology"</span>, <span class="seriesInfo">RFC 3753</span>, <span class="seriesInfo">DOI 10.17487/RFC3753</span>, <time datetime="2004-06" class="refDate">June 2004</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3753">https://www.rfc-editor.org/info/rfc3753</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5213">[RFC5213]</dt>
        <dd>
<span class="refAuthor">Gundavelli, S., Ed.</span><span class="refAuthor">, Leung, K.</span><span class="refAuthor">, Devarapalli, V.</span><span class="refAuthor">, Chowdhury, K.</span><span class="refAuthor">, and B. Patil</span>, <span class="refTitle">"Proxy Mobile IPv6"</span>, <span class="seriesInfo">RFC 5213</span>, <span class="seriesInfo">DOI 10.17487/RFC5213</span>, <time datetime="2008-08" class="refDate">August 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5213">https://www.rfc-editor.org/info/rfc5213</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><span class="refAuthor">, and 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="RFC7333">[RFC7333]</dt>
        <dd>
<span class="refAuthor">Chan, H., Ed.</span><span class="refAuthor">, Liu, D.</span><span class="refAuthor">, Seite, P.</span><span class="refAuthor">, Yokota, H.</span><span class="refAuthor">, and J. Korhonen</span>, <span class="refTitle">"Requirements for Distributed Mobility Management"</span>, <span class="seriesInfo">RFC 7333</span>, <span class="seriesInfo">DOI 10.17487/RFC7333</span>, <time datetime="2014-08" class="refDate">August 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7333">https://www.rfc-editor.org/info/rfc7333</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7429">[RFC7429]</dt>
        <dd>
<span class="refAuthor">Liu, D., Ed.</span><span class="refAuthor">, Zuniga, JC., Ed.</span><span class="refAuthor">, Seite, P.</span><span class="refAuthor">, Chan, H.</span><span class="refAuthor">, and CJ. Bernardos</span>, <span class="refTitle">"Distributed Mobility Management: Current Practices and Gap Analysis"</span>, <span class="seriesInfo">RFC 7429</span>, <span class="seriesInfo">DOI 10.17487/RFC7429</span>, <time datetime="2015-01" class="refDate">January 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7429">https://www.rfc-editor.org/info/rfc7429</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8174">[RFC8174]</dt>
        <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8221">[RFC8221]</dt>
        <dd>
<span class="refAuthor">Wouters, P.</span><span class="refAuthor">, Migault, D.</span><span class="refAuthor">, Mattsson, J.</span><span class="refAuthor">, Nir, Y.</span><span class="refAuthor">, and T. Kivinen</span>, <span class="refTitle">"Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)"</span>, <span class="seriesInfo">RFC 8221</span>, <span class="seriesInfo">DOI 10.17487/RFC8221</span>, <time datetime="2017-10" class="refDate">October 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8221">https://www.rfc-editor.org/info/rfc8221</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8247">[RFC8247]</dt>
      <dd>
<span class="refAuthor">Nir, Y.</span><span class="refAuthor">, Kivinen, T.</span><span class="refAuthor">, Wouters, P.</span><span class="refAuthor">, and D. Migault</span>, <span class="refTitle">"Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2)"</span>, <span class="seriesInfo">RFC 8247</span>, <span class="seriesInfo">DOI 10.17487/RFC8247</span>, <time datetime="2017-09" class="refDate">September 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8247">https://www.rfc-editor.org/info/rfc8247</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-7.2">
        <h3 id="name-informative-references">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="I-D.ietf-rtgwg-atn-bgp">[BGP-ATN-IPS]</dt>
        <dd>
<span class="refAuthor">Templin, F.</span><span class="refAuthor">, Saccone, G.</span><span class="refAuthor">, Dawra, G.</span><span class="refAuthor">, Lindem, A.</span><span class="refAuthor">, and V. Moreno</span>, <span class="refTitle">"A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-rtgwg-atn-bgp-06</span>, <time datetime="2020-06-30" class="refDate">30 June 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-rtgwg-atn-bgp-06">https://tools.ietf.org/html/draft-ietf-rtgwg-atn-bgp-06</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.seite-dmm-dma">[DMM-DMA]</dt>
        <dd>
<span class="refAuthor">Seite, P.</span><span class="refAuthor">, Bertin, P.</span><span class="refAuthor">, and J. Lee</span>, <span class="refTitle">"Distributed Mobility Anchoring"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-seite-dmm-dma-07</span>, <time datetime="2014-02-06" class="refDate">6 February 2014</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-seite-dmm-dma-07">https://tools.ietf.org/html/draft-seite-dmm-dma-07</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.yhkim-dmm-enhanced-anchoring">[DMM-ENHANCED-ANCHORING]</dt>
        <dd>
<span class="refAuthor">Kim, Y.</span><span class="refAuthor"> and S. Jeon</span>, <span class="refTitle">"Enhanced Mobility Anchoring in Distributed Mobility Management"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-yhkim-dmm-enhanced-anchoring-05</span>, <time datetime="2016-07-08" class="refDate">8 July 2016</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-yhkim-dmm-enhanced-anchoring-05">https://tools.ietf.org/html/draft-yhkim-dmm-enhanced-anchoring-05</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="DMM-MOBILE-INTERNET">[DMM-MOBILE-INTERNET]</dt>
        <dd>
<span class="refAuthor">Chan, H.</span><span class="refAuthor">, Yokota, H.</span><span class="refAuthor">, Xie, J.</span><span class="refAuthor">, Seite, P.</span><span class="refAuthor">, and D. Liu</span>, <span class="refTitle">"Distributed and Dynamic Mobility Management in Mobile Internet: Current Approaches and Issues"</span>, <span class="refContent">Journal of Communications, Vol. 6, No. 1
</span>, <time datetime="2011-02" class="refDate">February 2011</time>. </dd>
<dd class="break"></dd>
<dt id="I-D.sarikaya-dmm-for-wifi">[DMM-WIFI]</dt>
        <dd>
<span class="refAuthor">Sarikaya, B.</span><span class="refAuthor"> and L. Li</span>, <span class="refTitle">"Distributed Mobility Management Protocol for WiFi Users in Fixed Network"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-sarikaya-dmm-for-wifi-05</span>, <time datetime="2017-10-30" class="refDate">30 October 2017</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-sarikaya-dmm-for-wifi-05">https://tools.ietf.org/html/draft-sarikaya-dmm-for-wifi-05</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-dmm-fpc-cpdp">[FPC-DMM-PROTOCOL]</dt>
        <dd>
<span class="refAuthor">Matsushima, S.</span><span class="refAuthor">, Bertz, L.</span><span class="refAuthor">, Liebsch, M.</span><span class="refAuthor">, Gundavelli, S.</span><span class="refAuthor">, Moses, D.</span><span class="refAuthor">, and C. Perkins</span>, <span class="refTitle">"Protocol for Forwarding Policy Configuration (FPC) in DMM"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-dmm-fpc-cpdp-14</span>, <time datetime="2020-09-22" class="refDate">22 September 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp-14">https://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp-14</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="IEEE-DISTRIBUTED-MOBILITY">[IEEE-DISTRIBUTED-MOBILITY]</dt>
        <dd>
<span class="refAuthor">Lee, J.</span><span class="refAuthor">, Bonnin, J.</span><span class="refAuthor">, Seite, P.</span><span class="refAuthor">, and H. A. Chan</span>, <span class="refTitle">"Distributed IP mobility management from the perspective of the IETF: motivations, requirements, approaches, comparison, and challenges"</span>, <span class="refContent">IEEE Wireless Communications, vol. 20, no. 5, pp. 159-168
</span>, <time datetime="2013-10" class="refDate">October 2013</time>. </dd>
<dd class="break"></dd>
<dt id="PMIP-DMA">[PMIP-DMA]</dt>
        <dd>
<span class="refAuthor">Chan, H.</span>, <span class="refTitle">"Proxy mobile IP with distributed mobility anchors"</span>, <span class="refContent">IEEE Globecom Workshops Miami, FL, 2010, pp. 16-20
</span>, <time datetime="2010-12" class="refDate">December 2010</time>. </dd>
<dd class="break"></dd>
<dt id="I-D.mccann-dmm-prefixcost">[PREFIX-COST]</dt>
        <dd>
<span class="refAuthor">McCann, P.</span><span class="refAuthor"> and J. Kaippallimalil</span>, <span class="refTitle">"Communicating Prefix Cost to Mobile Nodes"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-mccann-dmm-prefixcost-03</span>, <time datetime="2016-04-11" class="refDate">11 April 2016</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-mccann-dmm-prefixcost-03">https://tools.ietf.org/html/draft-mccann-dmm-prefixcost-03</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6459">[RFC6459]</dt>
        <dd>
<span class="refAuthor">Korhonen, J., Ed.</span><span class="refAuthor">, Soininen, J.</span><span class="refAuthor">, Patil, B.</span><span class="refAuthor">, Savolainen, T.</span><span class="refAuthor">, Bajko, G.</span><span class="refAuthor">, and K. Iisakkila</span>, <span class="refTitle">"IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)"</span>, <span class="seriesInfo">RFC 6459</span>, <span class="seriesInfo">DOI 10.17487/RFC6459</span>, <time datetime="2012-01" class="refDate">January 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6459">https://www.rfc-editor.org/info/rfc6459</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8653">[RFC8653]</dt>
        <dd>
<span class="refAuthor">Yegin, A.</span><span class="refAuthor">, Moses, D.</span><span class="refAuthor">, and S. Jeon</span>, <span class="refTitle">"On-Demand Mobility Management"</span>, <span class="seriesInfo">RFC 8653</span>, <span class="seriesInfo">DOI 10.17487/RFC8653</span>, <time datetime="2019-10" class="refDate">October 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8653">https://www.rfc-editor.org/info/rfc8653</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8885">[RFC8885]</dt>
        <dd>
<span class="refAuthor">Bernardos, CJ.</span><span class="refAuthor">, de la Oliva, A.</span><span class="refAuthor">, Giust, F.</span><span class="refAuthor">, Zúñiga, JC.</span><span class="refAuthor">, and A. Mourad</span>, <span class="refTitle">"Proxy Mobile IPv6 Extensions for Distributed Mobility Management"</span>, <span class="seriesInfo">RFC 8885</span>, <span class="seriesInfo">DOI 10.17487/RFC8885</span>, <time datetime="2020-10" class="refDate">October 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8885">https://www.rfc-editor.org/info/rfc8885</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.matsushima-stateless-uplane-vepc">[STATELESS-UPLANE-VEPC]</dt>
      <dd>
<span class="refAuthor">Matsushima, S.</span><span class="refAuthor"> and R. Wakikawa</span>, <span class="refTitle">"Stateless user-plane architecture for virtualized EPC (vEPC)"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-matsushima-stateless-uplane-vepc-06</span>, <time datetime="2016-03-21" class="refDate">21 March 2016</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-matsushima-stateless-uplane-vepc-06">https://tools.ietf.org/html/draft-matsushima-stateless-uplane-vepc-06</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<section id="section-appendix.a">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="section-appendix.a-1">The work of <span class="contact-name">Jong-Hyouk Lee</span> was supported by the MSIT (Ministry of Science
and ICT), Korea, under the ITRC (Information Technology Research Center)
support program (IITP-2020-2015-0-00403) supervised by the IITP (Institute for
Information &amp; communications Technology Planning &amp; Evaluation).<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
</section>
<section id="section-appendix.b">
      <h2 id="name-contributors">
<a href="#name-contributors" class="section-name selfRef">Contributors</a>
      </h2>
<p id="section-appendix.b-1">
<span class="contact-name">Alexandre Petrescu</span> and <span class="contact-name">Fred Templin</span> had contributed to earlier draft versions of this document regarding
distributed anchoring for hierarchical networks and for network mobility,
although these extensions were removed to keep the document within reasonable
length.<a href="#section-appendix.b-1" class="pilcrow">¶</a></p>
<p id="section-appendix.b-2">
This document has benefited from other work on mobility support in SDN networks,
on providing mobility support only when needed, and on mobility support in
enterprise networks. These works have been referenced. While some of these
authors have taken the work to jointly write this document, others have
contributed at least indirectly by writing these works. The latter include
<span class="contact-name">Philippe Bertin</span>, <span class="contact-name">Dapeng Liu</span>,
<span class="contact-name">Satoru Matushima</span>, <span class="contact-name">Pierrick Seite</span>,
<span class="contact-name">Jouni Korhonen</span>,
and <span class="contact-name">Sri Gundavelli</span>.<a href="#section-appendix.b-2" class="pilcrow">¶</a></p>
<p id="section-appendix.b-3">
For completeness, some terminology from draft-ietf-dmm-deployment-models-04
has been incorporated into this document.<a href="#section-appendix.b-3" class="pilcrow">¶</a></p>
<p id="section-appendix.b-4">
Valuable comments have been received from <span class="contact-name">John Kaippallimalil</span>, <span class="contact-name">ChunShan Xiong</span>, <span class="contact-name">Dapeng Liu</span>, <span class="contact-name">Fred Templin</span>, <span class="contact-name">Paul Kyzivat</span>, <span class="contact-name">Joseph Salowey</span>, <span class="contact-name">Yoshifumi Nishida</span>, <span class="contact-name">Carlos Pignataro</span>,
<span class="contact-name">Mirja Kuehlewind</span>, <span class="contact-name">Eric Vyncke</span>,
<span class="contact-name">Qin Wu</span>, <span class="contact-name">Warren Kumari</span>, <span class="contact-name">Benjamin Kaduk</span>, <span class="contact-name">Roman Danyliw</span>, and <span class="contact-name">Barry Leiba</span>. <span class="contact-name">Dirk von Hugo</span>, <span class="contact-name">Byju Pularikkal</span>, and <span class="contact-name">Pierrick Seite</span> have
generously provided careful review with helpful corrections and
suggestions. <span class="contact-name">Marco Liebsch</span> and <span class="contact-name">Lyle Bertz</span> also performed very detailed and helpful reviews of this document.<a href="#section-appendix.b-4" class="pilcrow">¶</a></p>
</section>
<div id="authors-addresses">
<section id="section-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">H. Anthony Chan (<span class="role">editor</span>)</span></div>
<div dir="auto" class="left"><span class="org">Caritas Institute of Higher Education</span></div>
<div dir="auto" class="left"><span class="street-address">2 Chui Ling Lane, Tseung Kwan O</span></div>
<div dir="auto" class="left"><span class="locality">N.T.</span></div>
<div dir="auto" class="left"><span class="country-name">Hong Kong</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:h.a.chan@ieee.org" class="email">h.a.chan@ieee.org</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Xinpeng Wei</span></div>
<div dir="auto" class="left"><span class="org">Huawei Technologies</span></div>
<div dir="auto" class="left"><span class="street-address">Xin-Xi Rd. No. 3, Haidian District</span></div>
<div dir="auto" class="left"><span class="locality">Beijing, 100095</span></div>
<div dir="auto" class="left"><span class="country-name">China</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:weixinpeng@huawei.com" class="email">weixinpeng@huawei.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Jong-Hyouk Lee</span></div>
<div dir="auto" class="left"><span class="org">Sejong University</span></div>
<div dir="auto" class="left"><span class="street-address">209, Neungdong-ro, Gwangjin-gu</span></div>
<div dir="auto" class="left"><span class="locality">Seoul</span></div>
<div dir="auto" class="left"><span class="postal-code">05006</span></div>
<div dir="auto" class="left"><span class="country-name">Republic of Korea</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:jonghyouk@sejong.ac.kr" class="email">jonghyouk@sejong.ac.kr</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Seil Jeon</span></div>
<div dir="auto" class="left"><span class="org">Sungkyunkwan University</span></div>
<div dir="auto" class="left"><span class="street-address">2066 Seobu-ro, Jangan-gu</span></div>
<div dir="auto" class="left"><span class="locality">Suwon, Gyeonggi-do</span></div>
<div dir="auto" class="left"><span class="country-name">Republic of Korea</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:seiljeon.ietf@gmail.com" class="email">seiljeon.ietf@gmail.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Carlos J. Bernardos (<span class="role">editor</span>)</span></div>
<div dir="auto" class="left"><span class="org">Universidad Carlos III de Madrid</span></div>
<div dir="auto" class="left"><span class="street-address">Av. Universidad, 30</span></div>
<div dir="auto" class="left">
<span class="postal-code">28911</span> <span class="locality">Leganes, Madrid</span> </div>
<div dir="auto" class="left"><span class="country-name">Spain</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+34%2091624%206236" class="tel">+34 91624 6236</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:cjbc@it.uc3m.es" class="email">cjbc@it.uc3m.es</a>
</div>
<div class="url">
<span>URI:</span>
<a href="http://www.it.uc3m.es/cjbc/" class="url">http://www.it.uc3m.es/cjbc/</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>