File: rfc8653.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 (1813 lines) | stat: -rw-r--r-- 72,308 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 8653: On-Demand Mobility Management</title>
<meta content="Alper Yegin" name="author">
<meta content="Danny Moses" name="author">
<meta content="Seil Jeon" name="author">
<meta content="
       Applications differ with respect to whether they need session 
   continuity and/or IP address reachability. The network providing the 
   same type of service to any mobile host and any application running on 
   the host yields inefficiencies, as described in RFC 7333. 
   
   This document defines a new concept of enabling applications to influence the 
   network's mobility services (session continuity and/or IP address reachability) 
   on a per-socket basis, and suggests extensions to the networking stack's API
   to accommodate this concept.
       
    " name="description">
<meta content="xml2rfc 2.34.0" name="generator">
<meta content="8653" name="rfc.number">
<link href="rfc8653.xml" type="application/rfc+xml" rel="alternate">
<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;
  }

}
/* Avoid wrapping of URLs in references */
@media screen {
  .references a {
    white-space: nowrap;
  }
}
/* 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: 0 0 0.25em 0;
  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;
}
/* 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; }
}
</style>
<link href="rfc-local.css" type="text/css" rel="stylesheet">
<link href="https://dx.doi.org/10.17487/rfc8653" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-dmm-ondemand-mobility-18" 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 8653</td>
<td class="center">On-Demand Mobility</td>
<td class="right">October 2019</td>
</tr></thead>
<tfoot><tr>
<td class="left">Yegin, 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/rfc8653" class="eref">8653</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Informational</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2019-10" class="published">October 2019</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">A. Yegin</div>
<div class="org">Actility</div>
</div>
<div class="author">
      <div class="author-name">D. Moses</div>
<div class="org">Intel</div>
</div>
<div class="author">
      <div class="author-name">S. Jeon</div>
<div class="org">Sungkyunkwan University</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8653</h1>
<h1 id="title">On-Demand Mobility Management</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">Applications differ with respect to whether they need session 
   continuity and/or IP address reachability. The network providing the 
   same type of service to any mobile host and any application running on 
   the host yields inefficiencies, as described in RFC 7333. 
   
   This document defines a new concept of enabling applications to influence the 
   network's mobility services (session continuity and/or IP address reachability) 
   on a per-socket basis, and suggests extensions to the networking stack's API
   to accommodate this concept.<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/rfc8653">https://www.rfc-editor.org/info/rfc8653</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) 2019 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-boilerplate.3">
        <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="toc ulEmpty">
<li class="toc ulEmpty" id="section-boilerplate.3-1.1">
            <p id="section-boilerplate.3-1.1.1"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-boilerplate.3-1.1.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-boilerplate.3-1.2">
            <p id="section-boilerplate.3-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-notational-conventions" class="xref">Notational Conventions</a><a href="#section-boilerplate.3-1.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-boilerplate.3-1.3">
            <p id="section-boilerplate.3-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-solution" class="xref">Solution</a><a href="#section-boilerplate.3-1.3.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-boilerplate.3-1.3.2.1">
                <p id="section-boilerplate.3-1.3.2.1.1"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-high-level-description" class="xref">High-Level Description</a><a href="#section-boilerplate.3-1.3.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-boilerplate.3-1.3.2.2">
                <p id="section-boilerplate.3-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>.  <a href="#name-types-of-ip-addresses" class="xref">Types of IP Addresses</a><a href="#section-boilerplate.3-1.3.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-boilerplate.3-1.3.2.3">
                <p id="section-boilerplate.3-1.3.2.3.1"><a href="#section-3.3" class="xref">3.3</a>.  <a href="#name-granularity-of-selection" class="xref">Granularity of Selection</a><a href="#section-boilerplate.3-1.3.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-boilerplate.3-1.3.2.4">
                <p id="section-boilerplate.3-1.3.2.4.1"><a href="#section-3.4" class="xref">3.4</a>.  <a href="#name-on-demand-nature" class="xref">On-Demand Nature</a><a href="#section-boilerplate.3-1.3.2.4.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty" id="section-boilerplate.3-1.4">
            <p id="section-boilerplate.3-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-backwards-compatibility-con" class="xref">Backwards Compatibility Considerations</a><a href="#section-boilerplate.3-1.4.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-boilerplate.3-1.4.2.1">
                <p id="section-boilerplate.3-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-applications" class="xref">Applications</a><a href="#section-boilerplate.3-1.4.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-boilerplate.3-1.4.2.2">
                <p id="section-boilerplate.3-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-ip-stack-in-the-mobile-host" class="xref">IP Stack in the Mobile Host</a><a href="#section-boilerplate.3-1.4.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-boilerplate.3-1.4.2.3">
                <p id="section-boilerplate.3-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-network-infrastructure" class="xref">Network Infrastructure</a><a href="#section-boilerplate.3-1.4.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-boilerplate.3-1.4.2.4">
                <p id="section-boilerplate.3-1.4.2.4.1"><a href="#section-4.4" class="xref">4.4</a>.  <a href="#name-merging-this-work-with-rfc-" class="xref">Merging this work with RFC 5014</a><a href="#section-boilerplate.3-1.4.2.4.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty" id="section-boilerplate.3-1.5">
            <p id="section-boilerplate.3-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-boilerplate.3-1.5.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-boilerplate.3-1.6">
            <p id="section-boilerplate.3-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-boilerplate.3-1.6.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-boilerplate.3-1.7">
            <p id="section-boilerplate.3-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-references" class="xref">References</a><a href="#section-boilerplate.3-1.7.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-boilerplate.3-1.7.2.1">
                <p id="section-boilerplate.3-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-boilerplate.3-1.7.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-boilerplate.3-1.7.2.2">
                <p id="section-boilerplate.3-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-boilerplate.3-1.7.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty" id="section-boilerplate.3-1.8">
            <p id="section-boilerplate.3-1.8.1"><a href="#section-appendix.a" class="xref">Appendix A</a>.  <a href="#name-conveying-the-desired-addre" class="xref">Conveying the Desired Address Type</a><a href="#section-boilerplate.3-1.8.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-boilerplate.3-1.9">
            <p id="section-boilerplate.3-1.9.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a><a href="#section-boilerplate.3-1.9.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-boilerplate.3-1.10">
            <p id="section-boilerplate.3-1.10.1"><a href="#section-appendix.c" class="xref"></a><a href="#name-contributors" class="xref">Contributors</a><a href="#section-boilerplate.3-1.10.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-boilerplate.3-1.11">
            <p id="section-boilerplate.3-1.11.1"><a href="#section-appendix.d" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-boilerplate.3-1.11.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="introduction">
<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">In the context of Mobile IP <span>[<a href="#RFC5563" class="xref">RFC5563</a>]</span> <span>[<a href="#RFC6275" class="xref">RFC6275</a>]</span>
        <span>[<a href="#RFC5213" class="xref">RFC5213</a>]</span> <span>[<a href="#RFC5944" class="xref">RFC5944</a>]</span>, 
 the following two attributes are defined for IP service provided to  
 mobile hosts:<a href="#section-1-1" class="pilcrow">¶</a></p>
<dl class="dlNewline" id="section-1-2">
        <dt id="section-1-2.1">Session Continuity</dt>
        <dd id="section-1-2.2">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.<a href="#section-1-2.2" class="pilcrow">¶</a>
</dd>
<dt id="section-1-2.3">IP Address Reachability</dt>
        <dd id="section-1-2.4">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.<a href="#section-1-2.4" class="pilcrow">¶</a>
</dd>
</dl>
<p id="section-1-3">Mobile IP is designed to provide both session continuity and IP 
 address reachability to mobile hosts. Architectures using these 
 protocols (e.g., 3GPP, 3GPP2, WiMAX) ensure that any mobile host 
 attached to a compliant network can enjoy these benefits. Any 
 application running on these mobile hosts is subjected to the same 
 treatment with respect to session continuity and IP address 
 reachability.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">Achieving session continuity and IP address reachability with 
 Mobile IP incurs some cost. Mobile IP forces the mobile host's 
 IP traffic to traverse a centrally located router (Home Agent,  HA), 
 which incurs additional transmission latency and use of additional 
 network resources, adds to the network's operating and capital expenditures, and decreases the 
 reliability of the network due to the introduction of a single point of 
 failure <span>[<a href="#RFC7333" class="xref">RFC7333</a>]</span>. Therefore, session continuity 
 and IP address reachability <span class="bcp14">SHOULD</span> be provided only when necessary.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">In reality, not every application may need 
 these benefits. IP address reachability is required for applications 
 running as servers (e.g., a web server running on the mobile host), but
 a typical client application (e.g., web browser) does not necessarily 
 require IP address reachability. Similarly, session continuity is not 
 required for all types of applications either. Applications performing 
 brief communication (e.g., text messaging) can survive without having session 
 continuity support.<a href="#section-1-5" class="pilcrow">¶</a></p>
<p id="section-1-6">Furthermore, when an application needs session continuity, it may be 
 able to satisfy that need by using a solution above the IP layer, such 
 as Multipath TCP <span>[<a href="#RFC6824" class="xref">RFC6824</a>]</span>, SIP mobility <span>[<a href="#RFC3261" class="xref">RFC3261</a>]</span>, or an application-layer mobility solution. These 
 higher-layer solutions are not subject to the same issues that arise 
 with the use of Mobile IP since they can use the most direct data 
 path between the endpoints. But, if Mobile IP is being applied to the 
 mobile host, the higher-layer protocols are rendered useless because 
 their operation is inhibited by Mobile IP. Since Mobile IP ensures 
 that the IP address of the mobile host remains fixed (despite the location 
 and movement of the mobile host), the higher-layer protocols never 
 detect the IP-layer change and never engage in mobility management.<a href="#section-1-6" class="pilcrow">¶</a></p>
<p id="section-1-7">This document proposes a solution for applications running on 
 mobile hosts to indicate when establishing the network connection ('on 
 demand') whether they need session continuity or IP 
 address reachability. The network protocol stack on the mobile host, in 
 conjunction with the network infrastructure, provides the required 
 type of service. It is for the benefit of both the users and the 
 network operators not to engage an extra level of service unless it is 
 absolutely necessary. It is expected that applications and networks 
 compliant with this specification will utilize this solution to use 
 network resources more efficiently.<a href="#section-1-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="notation">
<section id="section-2">
      <h2 id="name-notational-conventions">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-notational-conventions" class="section-name selfRef">Notational Conventions</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>
</section>
</div>
<div id="solution">
<section id="section-3">
      <h2 id="name-solution">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-solution" class="section-name selfRef">Solution</a>
      </h2>
<div id="hldescription">
<section id="section-3.1">
        <h3 id="name-high-level-description">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-high-level-description" class="section-name selfRef">High-Level Description</a>
        </h3>
<p id="section-3.1-1"> Enabling applications to indicate their mobility service requirements 
 (e.g., session continuity and/or IP address reachability) comprises the 
 following steps:<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal" id="section-3.1-2">
          <li id="section-3.1-2.1">The application indicates to the network stack (local to the 
 mobile host) the desired mobility service.<a href="#section-3.1-2.1" class="pilcrow">¶</a>
</li>
          <li id="section-3.1-2.2">The network stack assigns a source IP address based on an IP prefix 
 with the desired services that was previously provided by the network. 
 If such an IP prefix is not available, the network stack performs the 
 additional steps below.<a href="#section-3.1-2.2" class="pilcrow">¶</a>
</li>
          <li id="section-3.1-2.3">The network stack sends a request to the network for a new source 
 IP prefix that is associated with the desired mobility service.<a href="#section-3.1-2.3" class="pilcrow">¶</a>
</li>
          <li id="section-3.1-2.4">The network responds with the suitable allocated source IP prefix 
 (or responds with a failure indication).<a href="#section-3.1-2.4" class="pilcrow">¶</a>
</li>
          <li id="section-3.1-2.5">If the suitable source IP prefix was allocated, the network stack 
 constructs a source IP address and provides it to the application.<a href="#section-3.1-2.5" class="pilcrow">¶</a>
</li>
        </ol>
<p id="section-3.1-3"> This document specifies the new address types associated with 
 mobility services and details the interaction between the applications 
 and the network stack steps. It uses the socket interface as an example 
 for an API between applications and the network stack. Other steps are 
 outside the scope of this document.<a href="#section-3.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="addresstypes">
<section id="section-3.2">
        <h3 id="name-types-of-ip-addresses">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-types-of-ip-addresses" class="section-name selfRef">Types of IP Addresses</a>
        </h3>
<p id="section-3.2-1"> Four types of IP addresses are defined with respect to mobility 
 management:<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<dl class="dlNewline" id="section-3.2-2">
          <dt id="section-3.2-2.1">Fixed IP address</dt>
          <dd id="section-3.2-2.2">
            <p id="section-3.2-2.2.1"> A Fixed IP address is an address guaranteed to be valid for a 
 very long time, regardless of whether it is being used in any packet 
 to/from the mobile host, or whether or not the mobile host is 
 connected to the network, or whether it moves from one 
 point of attachment to another (with a different IP prefix) while it is 
 connected.<a href="#section-3.2-2.2.1" class="pilcrow">¶</a></p>
<p id="section-3.2-2.2.2">Fixed IP addresses are required by applications that need both session 
 continuity and IP address reachability.<a href="#section-3.2-2.2.2" class="pilcrow">¶</a></p>
</dd>
<dt id="section-3.2-2.3">Session-Lasting IP address</dt>
          <dd id="section-3.2-2.4">
            <p id="section-3.2-2.4.1">A Session-Lasting IP address is an address guaranteed to be 
 valid for the lifetime of the socket(s) for which it was requested. 
 It is guaranteed to be valid even after the mobile host has moved from one 
 point of attachment to another (with a different IP prefix).<a href="#section-3.2-2.4.1" class="pilcrow">¶</a></p>
<p id="section-3.2-2.4.2">Session-Lasting IP addresses are required by applications that need 
 session continuity but do not need IP address reachability.<a href="#section-3.2-2.4.2" class="pilcrow">¶</a></p>
</dd>
<dt id="section-3.2-2.5">Nonpersistent IP address</dt>
          <dd id="section-3.2-2.6">
            <p id="section-3.2-2.6.1">This type of IP address is not guaranteed to exist after a mobile host 
 moves from one point of attachment to another; therefore, no session 
 continuity nor IP address reachability are provided. The IP address is created 
 from an IP prefix that is obtained from the serving IP gateway and is not 
 maintained across gateway changes. In other words, the IP prefix may be released 
 and replaced by a new one when the IP gateway changes due to the movement of the 
 mobile host forcing the creation of a new source IP address with the updated 
 allocated IP prefix.<a href="#section-3.2-2.6.1" class="pilcrow">¶</a></p>
</dd>
<dt id="section-3.2-2.7">Graceful-Replacement IP address</dt>
          <dd id="section-3.2-2.8">
            <p id="section-3.2-2.8.1">In some cases, the network cannot guarantee the validity of the provided 
 IP prefix throughout the duration of the opened socket, but can provide a limited 
 graceful period of time in which both the original IP prefix and a new one are 
 valid. This enables the application some flexibility in the transition from the 
 existing source IP address to the new one.<a href="#section-3.2-2.8.1" class="pilcrow">¶</a></p>
<p id="section-3.2-2.8.2">This gracefulness is still better than the nonpersistence type of address 
 for applications that can handle a change in their source IP address but require 
 that extra flexibility.<a href="#section-3.2-2.8.2" class="pilcrow">¶</a></p>
</dd>
</dl>
<p id="section-3.2-3">Applications running as servers at a published IP address require a 
 Fixed IP address.  Long-standing applications (e.g., an SSH session) 
 may also require this type of address. Enterprise applications that 
 connect to an enterprise network via virtual LAN require a Fixed IP 
         address.<a href="#section-3.2-3" class="pilcrow">¶</a></p>
<p id="section-3.2-4">Applications with short-lived transient sessions (e.g., web browsers) can use 
 Session-Lasting IP addresses.<a href="#section-3.2-4" class="pilcrow">¶</a></p>
<p id="section-3.2-5">Applications with very short sessions, such as DNS clients and 
 instant messengers, can use Nonpersistent IP addresses. Even 
 though they could very well use Fixed or Session-Lasting IP 
 addresses, the transmission latency would be minimized when a 
 Nonpersistent IP address is used.<a href="#section-3.2-5" class="pilcrow">¶</a></p>
<p id="section-3.2-6">Applications that can tolerate a short interruption in connectivity 
 can use the Graceful-Replacement IP addresses, for example, a streaming 
 client that has buffering capabilities.<a href="#section-3.2-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="granularity">
<section id="section-3.3">
        <h3 id="name-granularity-of-selection">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-granularity-of-selection" class="section-name selfRef">Granularity of Selection</a>
        </h3>
<p id="section-3.3-1">IP address type selection is made on a per-socket granularity. 
 Different parts of the same application may have different needs. For 
 example, the control plane of an application may require a Fixed IP 
 address in order to stay reachable, whereas the data plane of the same 
 application may be satisfied with a Session-Lasting IP address.<a href="#section-3.3-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ondemand">
<section id="section-3.4">
        <h3 id="name-on-demand-nature">
<a href="#section-3.4" class="section-number selfRef">3.4. </a><a href="#name-on-demand-nature" class="section-name selfRef">On-Demand Nature</a>
        </h3>
<p id="section-3.4-1">At any point in time, a mobile host may have a combination of IP 
 addresses configured. Zero or more Fixed, zero or more Session-Lasting, 
 zero or more Nonpersistent, and zero or more Graceful-Replacement 
 IP addresses may be configured by the IP stack of the host. The 
 combination may be a result of the host policy, application demand, 
 or a mix of the two.<a href="#section-3.4-1" class="pilcrow">¶</a></p>
<p id="section-3.4-2">When an application requires a specific type of IP address, and such 
 an address is not already configured on the host, the IP stack <span class="bcp14">SHALL</span> 
 attempt to configure one. For example, a host may not always have a 
 Session-Lasting IP address available. When an application requests 
 one, the IP stack <span class="bcp14">SHALL</span> make an attempt to configure one by issuing a 
 request to the network. If the operation fails, the IP stack <span class="bcp14">SHALL</span> 
 fail the associated socket request and return an error. If successful, 
 a Session-Lasting IP address is configured on the mobile host. If 
 another socket requests a Session-Lasting IP address at a later time,
 the same IP address may be served to that socket as well.  When the last 
 socket using the same configured IP address is closed, the IP address 
 may be released, or it may be kept for applications requiring a Session-Lasting 
 IP address that may be launched in the future.<a href="#section-3.4-2" class="pilcrow">¶</a></p>
<p id="section-3.4-3">In some cases, it might be preferable for the mobile host to request 
 a new Session-Lasting IP address for a new opening of an IP socket 
 (even though one was already assigned to the mobile host by the 
 network and might be in use in a different, already active IP 
 socket).  It is outside the scope of this specification to define 
 criteria for choosing to use available addresses or choosing to request 
 new ones. It supports both alternatives (and any combination).<a href="#section-3.4-3" class="pilcrow">¶</a></p>
<p id="section-3.4-4">It is outside the scope of this specification to define how the 
 host requests a specific type of prefix and how the network indicates 
 the type of prefix in its advertisement or in its reply to a request.<a href="#section-3.4-4" class="pilcrow">¶</a></p>
<p id="section-3.4-5">The following are matters of policy, which may be dictated by the 
 host itself, the network operator, or the system architecture 
 standard:<a href="#section-3.4-5" class="pilcrow">¶</a></p>
<ul>
<li id="section-3.4-6.1">The initial set of IP addresses configured on the host at boot 
 time<a href="#section-3.4-6.1" class="pilcrow">¶</a>
</li>
          <li id="section-3.4-6.2">Permission to grant various types of IP addresses to a requesting 
 application<a href="#section-3.4-6.2" class="pilcrow">¶</a>
</li>
          <li id="section-3.4-6.3">Determination of a default address type when an application does 
      not explicitly indicate whether it supports the required API or is a
      legacy application<a href="#section-3.4-6.3" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
</section>
</div>
<div id="compatibility">
<section id="section-4">
      <h2 id="name-backwards-compatibility-con">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-backwards-compatibility-con" class="section-name selfRef">Backwards Compatibility Considerations</a>
      </h2>
<p id="section-4-1"> Backwards compatibility support is <span class="bcp14">REQUIRED</span> by the following three types 
 of entities:<a href="#section-4-1" class="pilcrow">¶</a></p>
<ul>
<li id="section-4-2.1">The applications on the mobile host<a href="#section-4-2.1" class="pilcrow">¶</a>
</li>
        <li id="section-4-2.2">The IP stack in the mobile host<a href="#section-4-2.2" class="pilcrow">¶</a>
</li>
        <li id="section-4-2.3">The network infrastructure<a href="#section-4-2.3" class="pilcrow">¶</a>
</li>
      </ul>
<div id="applications">
<section id="section-4.1">
        <h3 id="name-applications">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-applications" class="section-name selfRef">Applications</a>
        </h3>
<p id="section-4.1-1">Legacy applications that do not support the On-Demand functionality will use 
 the legacy API and will not be able to take advantage of the On-Demand 
 Mobility feature.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<p id="section-4.1-2"> Applications using the new On-Demand functionality should be aware that 
 they may be executed in legacy environments that do not support it. Such 
 environments may include a legacy IP stack on the mobile host, legacy network 
 infrastructure, or both. In either case, the API will return an error code, and 
 the invoking application may just give up and use legacy calls.<a href="#section-4.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="stack">
<section id="section-4.2">
        <h3 id="name-ip-stack-in-the-mobile-host">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-ip-stack-in-the-mobile-host" class="section-name selfRef">IP Stack in the Mobile Host</a>
        </h3>
<p id="section-4.2-1">New IP stacks (that implement On-Demand functionality) <span class="bcp14">MUST</span> continue to support 
 all legacy operations. If an application does not use On-Demand functionality, the 
 IP stack <span class="bcp14">MUST</span> respond in a legacy manner.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<p id="section-4.2-2"> If the network infrastructure supports On-Demand functionality, 
 the IP stack <span class="bcp14">SHOULD</span> follow the application request: If the application 
 requests a specific address type, the stack <span class="bcp14">SHOULD</span> forward this 
        request to the network. 
If the application does not request an address type, the IP stack <span class="bcp14">MUST NOT</span>
request an address type. Instead, the network will choose the type of
allocated IP prefix. How the network selects the type of allocated IP prefix
is outside the scope of this document. If an IP prefix was already allocated to the host, the IP 
 stack uses it and may not request a new one from the network.<a href="#section-4.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="network">
<section id="section-4.3">
        <h3 id="name-network-infrastructure">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-network-infrastructure" class="section-name selfRef">Network Infrastructure</a>
        </h3>
<p id="section-4.3-1"> The network infrastructure may or may not support the On-Demand 
 functionality. How the IP stack on the host and the network 
 infrastructure behave in case of a compatibility issue is outside the 
 scope of this API specification.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="RFC5014ref">
<section id="section-4.4">
        <h3 id="name-merging-this-work-with-rfc-">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-merging-this-work-with-rfc-" class="section-name selfRef">Merging this work with RFC 5014</a>
        </h3>
<p id="section-4.4-1"><span>[<a href="#RFC5014" class="xref">RFC5014</a>]</span> defines new flags that may be used with 
 setsockopt() to influence source IP address selection for a socket. The list of 
 flags include the following: source home address, care-of address, temporary address, public 
 address CGA (Cryptographically Created Address), and non-CGA. When applications 
 require session continuity service, they <span class="bcp14">SHOULD NOT</span> set the flags specified 
 in <span>[<a href="#RFC5014" class="xref">RFC5014</a>]</span>.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
<p id="section-4.4-2">However, if an application erroneously performs a combination of (1) using 
 setsockopt() to set a specific option (using one of the flags specified in 
 <span>[<a href="#RFC5014" class="xref">RFC5014</a>]</span>) and (2) selecting a source IP address type, the 
 IP stack will fulfill the request specified by (2) and ignore the flags set 
 by (1).<a href="#section-4.4-2" 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"> The different service types (session continuity types and address reachability) associated
 with the allocated IP address types may be associated with different costs: the cost 
 to the operator for enabling a type of service, and the cost to applications using a 
 selected service. A malicious application may use these to indirectly
 generate extra billing of a mobile subscriber, and/or impose costly
 services on the mobile operator. When expensive 
 services are limited, malicious applications may exhaust them, preventing other 
 applications on the same mobile host from being able to use them.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2"> Mobile hosts that enable such service options should provide capabilities for 
 ensuring that only authorized applications can use the expensive (or limited) service 
 types.<a href="#section-5-2" class="pilcrow">¶</a></p>
<p id="section-5-3"> The ability to select service types requires the exchange of the association of 
 source IP prefixes and their corresponding service types, between the mobile host and
 mobile network. Exposing these associations may provide information to passive 
 attackers even if the traffic that is used with these addresses is encrypted.<a href="#section-5-3" class="pilcrow">¶</a></p>
<p id="section-5-4">To avoid profiling an application according to the type of IP address,
 it is expected that prefixes provided by the mobile operator are associated with 
 various types of addresses over time. As a result, the type of address
 cannot be associated with the prefix, making application profiling based on the
 type of address more difficult.<a href="#section-5-4" class="pilcrow">¶</a></p>
<p id="section-5-5">The application or the OS should ensure that IP addresses regularly change 
 to limit IP tracking by a passive observer.  The application should regularly 
 set the On-Demand flag. The application should be able to ensure that Session-Lasting 
        IP addresses are regularly changed by setting a lifetime, for example, 
 handled by the application. In addition, the application should consider the use
 of Graceful-Replacement IP addresses.<a href="#section-5-5" class="pilcrow">¶</a></p>
<p id="section-5-6"> Similarly, the OS may also associate IP addresses with a lifetime. Upon
 receiving a request for a given type of IP address, after some time, the
 OS should request a new address to the network even if it already has one IP 
 address available with the requested type. This includes any type of IP address. 
 IP addresses of type Graceful-Replacement or nonpersistent should be 
 regularly renewed by the OS.<a href="#section-5-6" class="pilcrow">¶</a></p>
<p id="section-5-7"> The lifetime of an IP address may be expressed in number of seconds or
 in number of bytes sent through this IP address.<a href="#section-5-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="iana">
<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>
</div>
<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">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>
<dt id="RFC5014">[RFC5014]</dt>
        <dd>
<span class="refAuthor">Nordmark, E.</span><span class="refAuthor">, Chakrabarti, S.</span><span class="refAuthor">, and J. Laganier</span>, <span class="refTitle">"IPv6 Socket API for Source Address Selection"</span>, <span class="seriesInfo">RFC 5014</span>, <span class="seriesInfo">DOI 10.17487/RFC5014</span>, <time datetime="2007-09">September 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5014">https://www.rfc-editor.org/info/rfc5014</a>&gt;</span>. </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">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>
</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.sijeon-dmm-use-cases-api-source">[API-EXT]</dt>
        <dd>
<span class="refAuthor">Jeon, S.</span><span class="refAuthor">, Figueiredo, S.</span><span class="refAuthor">, Kim, Y.</span><span class="refAuthor">, and J. Kaippallimalil</span>, <span class="refTitle">"Use Cases and API Extension for Source IP Address Selection"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-sijeon-dmm-use-cases-api-source-07</span>, <time datetime="2017-09-10">10 September 2017</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-07">https://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-07</a>&gt;</span>. </dd>
<dt id="RFC3261">[RFC3261]</dt>
        <dd>
<span class="refAuthor">Rosenberg, J.</span><span class="refAuthor">, Schulzrinne, H.</span><span class="refAuthor">, Camarillo, G.</span><span class="refAuthor">, Johnston, A.</span><span class="refAuthor">, Peterson, J.</span><span class="refAuthor">, Sparks, R.</span><span class="refAuthor">, Handley, M.</span><span class="refAuthor">, and E. Schooler</span>, <span class="refTitle">"SIP: Session Initiation Protocol"</span>, <span class="seriesInfo">RFC 3261</span>, <span class="seriesInfo">DOI 10.17487/RFC3261</span>, <time datetime="2002-06">June 2002</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3261">https://www.rfc-editor.org/info/rfc3261</a>&gt;</span>. </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">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>
<dt id="RFC5563">[RFC5563]</dt>
        <dd>
<span class="refAuthor">Leung, K.</span><span class="refAuthor">, Dommety, G.</span><span class="refAuthor">, Yegani, P.</span><span class="refAuthor">, and K. Chowdhury</span>, <span class="refTitle">"WiMAX Forum / 3GPP2 Proxy Mobile IPv4"</span>, <span class="seriesInfo">RFC 5563</span>, <span class="seriesInfo">DOI 10.17487/RFC5563</span>, <time datetime="2010-02">February 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5563">https://www.rfc-editor.org/info/rfc5563</a>&gt;</span>. </dd>
<dt id="RFC5944">[RFC5944]</dt>
        <dd>
<span class="refAuthor">Perkins, C., Ed.</span>, <span class="refTitle">"IP Mobility Support for IPv4, Revised"</span>, <span class="seriesInfo">RFC 5944</span>, <span class="seriesInfo">DOI 10.17487/RFC5944</span>, <time datetime="2010-11">November 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5944">https://www.rfc-editor.org/info/rfc5944</a>&gt;</span>. </dd>
<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">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>
<dt id="RFC6824">[RFC6824]</dt>
        <dd>
<span class="refAuthor">Ford, A.</span><span class="refAuthor">, Raiciu, C.</span><span class="refAuthor">, Handley, M.</span><span class="refAuthor">, and O. Bonaventure</span>, <span class="refTitle">"TCP Extensions for Multipath Operation with Multiple Addresses"</span>, <span class="seriesInfo">RFC 6824</span>, <span class="seriesInfo">DOI 10.17487/RFC6824</span>, <time datetime="2013-01">January 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6824">https://www.rfc-editor.org/info/rfc6824</a>&gt;</span>. </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">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>
</dl>
</section>
</section>
<div id="appendix">
<section id="section-appendix.a">
      <h2 id="name-conveying-the-desired-addre">
<a href="#section-appendix.a" class="section-number selfRef">Appendix A. </a><a href="#name-conveying-the-desired-addre" class="section-name selfRef">Conveying the Desired Address Type</a>
      </h2>
<p id="section-appendix.a-1">The following are some suggestions of possible extensions to the socket API 
 for enabling applications to convey their session continuity and address 
 reachability requirements.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
<p id="section-appendix.a-2"><span>[<a href="#RFC5014" class="xref">RFC5014</a>]</span> introduced the ability of applications 
 to influence the source address selection with the IPV6_ADDR_PREFERENCE 
 option at the IPPROTO_IPV6 level. This option is used with setsockopt() 
 and getsockopt() calls to set/get address selection preferences.<a href="#section-appendix.a-2" class="pilcrow">¶</a></p>
<p id="section-appendix.a-3">One alternative is to extend the definition of the IPV6_ADDR_REFERENCE 
 option with flags that express the invoker's desire. An "OnDemand" field could 
 contain one of the following values: FIXED_IP_ADDRESS, SESSION_LASTING_IP_ADDRESS,
 NON_PERSISTENT_IP_ADDRESS, or GRACEFUL_REPLACEMENT_IP_ADDRESS.<a href="#section-appendix.a-3" class="pilcrow">¶</a></p>
<p id="section-appendix.a-4">Another alternative is to define a new socket function used by the invoker
 to convey its desire. This enables the implementation of two behaviors of
 socket functions: the existing setsockopt() is a function that returns after 
 executing, and the new setsc() (Set Service Continuity) is a function that may
 initiate a request for the desired service, and wait until the network responds 
 with the allocated resources, before returning to the invoker.<a href="#section-appendix.a-4" class="pilcrow">¶</a></p>
<p id="section-appendix.a-5">After obtaining an IP address with the desired behavior, the application can 
 call the bind() socket function to associate that received IP address with the 
 socket.<a href="#section-appendix.a-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ack">
<section id="section-appendix.b">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="section-appendix.b-1">We would like to thank Wu-chi Feng, Alexandru Petrescu, Jouni Korhonen, 
   Sri Gundavelli, Dave Dolson, Lorenzo Colitti, and Daniel Migault for their valuable 
   comments and suggestions on this work.<a href="#section-appendix.b-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="contributor">
<section id="section-appendix.c">
      <h2 id="name-contributors">
<a href="#name-contributors" class="section-name selfRef">Contributors</a>
      </h2>
<p id="section-appendix.c-1">This document was merged with "Use Cases and API Extension for Source IP Address 
         Selection" <span>[<a href="#I-D.sijeon-dmm-use-cases-api-source" class="xref">API-EXT</a>]</span>.
         We would like to acknowledge the contribution of the following people to that document as 
   well:<a href="#section-appendix.c-1" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-appendix.c-2">
<pre>
Sergio Figueiredo
Altran Research
France
Email: sergio.figueiredo@altran.com
</pre><a href="#section-appendix.c-2" class="pilcrow">¶</a>
</div>
<div class="artwork art-text alignLeft" id="section-appendix.c-3">
<pre>
Younghan Kim
Soongsil University
Republic of Korea
Email: younghak@ssu.ac.kr
</pre><a href="#section-appendix.c-3" class="pilcrow">¶</a>
</div>
<div class="artwork art-text alignLeft" id="section-appendix.c-4">
<pre>
John Kaippallimalil
Huawei
United States of America
Email: john.kaippallimalil@huawei.com
</pre><a href="#section-appendix.c-4" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="authors-addresses">
<section id="section-appendix.d">
      <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">Alper Yegin</span></div>
<div dir="auto" class="left"><span class="org">Actility</span></div>
<div dir="auto" class="left"> <span class="locality">Istanbul</span>/</div>
<div dir="auto" class="left"><span class="country-name">Turkey</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:alper.yegin@actility.com" class="email">alper.yegin@actility.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Danny Moses</span></div>
<div dir="auto" class="left"><span class="org">Intel Corporation</span></div>
<div dir="auto" class="left">
<span class="locality">Petah Tikva</span> </div>
<div dir="auto" class="left"><span class="country-name">Israel</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:danny.moses@intel.com" class="email">danny.moses@intel.com</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="country-name">Republic of Korea</span></div>
<div dir="auto" class="left"> <span class="locality">Suwon</span> </div>
<div dir="auto" class="left"><span class="org">Sungkyunkwan University</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:seiljeon.ietf@gmail.com" class="email">seiljeon.ietf@gmail.com</a>
</div>
</address>
</section>
</div>
<script>var toc = document.getElementById("toc");
var tocToggle = toc.querySelector("h2");
var tocNav = toc.querySelector("nav");

// mobile menu toggle
tocToggle.onclick = function(event) {
    if (window.innerWidth < 1024) {
 var tocNavDisplay = tocNav.currentStyle ? tocNav.currentStyle.display : getComputedStyle(tocNav, null).display;
 if (tocNavDisplay == "none") {
     tocNav.style.display = "block";
 } else {
     tocNav.style.display = "none";
 }
    }
}

// toc anchor scroll to anchor
tocNav.addEventListener("click", function (event) {
    event.preventDefault();
    if (event.target.nodeName == 'A') {
 if (window.innerWidth < 1024) {
     tocNav.style.display = "none";
 }
 var href = event.target.getAttribute("href");
 var anchorId = href.substr(1);
 var anchor =  document.getElementById(anchorId);
 anchor.scrollIntoView(true);
 window.history.pushState("","",href);
    }
});

// switch toc mode when window resized
window.onresize = function () {
    if (window.innerWidth < 1024) {
 tocNav.style.display = "none";
    } else {
 tocNav.style.display = "block";
    }
}
</script>
</body>
</html>