File: rfc9028.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 (5024 lines) | stat: -rw-r--r-- 306,927 bytes
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 9028: Native NAT Traversal Mode for the Host Identity Protocol</title>
<meta content="Ari Keränen" name="author">
<meta content="Jan Melén" name="author">
<meta content="Miika Komu" name="author">
<meta content="
        This document specifies a new Network Address Translator (NAT)
      traversal mode for the Host Identity Protocol (HIP). The new mode is
      based on the Interactive Connectivity Establishment (ICE) methodology
      and UDP encapsulation of data and signaling traffic. The main difference
      from the previously specified modes is the use of HIP messages instead
      of ICE for all NAT traversal procedures due to the kernel-space
      dependencies of HIP.
       
    " name="description">
<meta content="xml2rfc 3.9.1" name="generator">
<meta content="HIP" name="keyword">
<meta content="NAT" name="keyword">
<meta content="NAT traversal" name="keyword">
<meta content="9028" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.9.1
    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="rfc9028.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.ulBare, li.ulBare {
  margin-left: 0em !important;
}
ul.compact, .ulCompact,
ol.compact, .olCompact {
  line-height: 100%;
  margin: 0 0 0 2em;
}

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

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

/* Figures */
tt, code, pre, 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";
}
/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
li > p {
  margin-bottom: 0.5em
}
/* Don't let p margin spill out from inside list items */
li > p:last-of-type {
  margin-bottom: 0;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc9028" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal-33" 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 9028</td>
<td class="center">HIP Native NAT Traversal Mode</td>
<td class="right">July 2021</td>
</tr></thead>
<tfoot><tr>
<td class="left">Keränen, et al.</td>
<td class="center">Experimental</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/rfc9028" class="eref">9028</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Experimental</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2021-07" class="published">July 2021</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. Keränen</div>
<div class="org">Ericsson</div>
</div>
<div class="author">
      <div class="author-name">J. Melén</div>
<div class="org">Ericsson</div>
</div>
<div class="author">
      <div class="author-name">M. Komu, <span class="editor">Ed.</span>
</div>
<div class="org">Ericsson</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9028</h1>
<h1 id="title">Native NAT Traversal Mode for the Host Identity Protocol</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1"> This document specifies a new Network Address Translator (NAT)
      traversal mode for the Host Identity Protocol (HIP). The new mode is
      based on the Interactive Connectivity Establishment (ICE) methodology
      and UDP encapsulation of data and signaling traffic. The main difference
      from the previously specified modes is the use of HIP messages instead
      of ICE for all NAT traversal procedures due to the kernel-space
      dependencies of HIP.<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 examination, experimental implementation, and
            evaluation.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document defines an Experimental Protocol for the Internet
            community.  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/rfc9028">https://www.rfc-editor.org/info/rfc9028</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) 2021 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 ulBare compact toc">
<li class="ulEmpty ulBare compact toc" 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></p>
</li>
          <li class="ulEmpty ulBare compact toc" 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-terminology" class="xref">Terminology</a></p>
</li>
          <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1" class="keepWithNext"><a href="#section-3" class="xref">3</a>.  <a href="#name-overview-of-operation" class="xref">Overview of Operation</a></p>
</li>
          <li class="ulEmpty ulBare compact toc" 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-protocol-description" class="xref">Protocol Description</a></p>
<ul class="ulEmpty compact ulBare toc">
<li class="ulEmpty compact ulBare toc" 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-relay-registration" class="xref">Relay Registration</a></p>
</li>
              <li class="ulEmpty compact ulBare toc" 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-transport-address-candidate" class="xref">Transport Address Candidate Gathering at the Relay Client</a></p>
</li>
              <li class="ulEmpty compact ulBare toc" 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-nat-traversal-mode-negotiat" class="xref">NAT Traversal Mode Negotiation</a></p>
</li>
              <li class="ulEmpty compact ulBare toc" id="section-toc.1-1.4.2.4">
                <p id="section-toc.1-1.4.2.4.1"><a href="#section-4.4" class="xref">4.4</a>.  <a href="#name-connectivity-check-pacing-n" class="xref">Connectivity Check Pacing Negotiation</a></p>
</li>
              <li class="ulEmpty compact ulBare toc" id="section-toc.1-1.4.2.5">
                <p id="section-toc.1-1.4.2.5.1"><a href="#section-4.5" class="xref">4.5</a>.  <a href="#name-base-exchange-via-control-r" class="xref">Base Exchange via Control Relay Server</a></p>
</li>
              <li class="ulEmpty compact ulBare toc" id="section-toc.1-1.4.2.6">
                <p id="section-toc.1-1.4.2.6.1"><a href="#section-4.6" class="xref">4.6</a>.  <a href="#name-connectivity-checks" class="xref">Connectivity Checks</a></p>
<ul class="ulEmpty compact ulBare toc">
<li class="ulEmpty compact ulBare toc" id="section-toc.1-1.4.2.6.2.1">
                    <p id="section-toc.1-1.4.2.6.2.1.1"><a href="#section-4.6.1" class="xref">4.6.1</a>.  <a href="#name-connectivity-check-procedur" class="xref">Connectivity Check Procedure</a></p>
</li>
                  <li class="ulEmpty compact ulBare toc" id="section-toc.1-1.4.2.6.2.2">
                    <p id="section-toc.1-1.4.2.6.2.2.1"><a href="#section-4.6.2" class="xref">4.6.2</a>.  <a href="#name-rules-for-connectivity-chec" class="xref">Rules for Connectivity Checks</a></p>
</li>
                  <li class="ulEmpty compact ulBare toc" id="section-toc.1-1.4.2.6.2.3">
                    <p id="section-toc.1-1.4.2.6.2.3.1"><a href="#section-4.6.3" class="xref">4.6.3</a>.  <a href="#name-rules-for-concluding-connec" class="xref">Rules for Concluding Connectivity Checks</a></p>
</li>
                </ul>
</li>
              <li class="ulEmpty compact ulBare toc" id="section-toc.1-1.4.2.7">
                <p id="section-toc.1-1.4.2.7.1"><a href="#section-4.7" class="xref">4.7</a>.  <a href="#name-nat-traversal-optimizations" class="xref">NAT Traversal Optimizations</a></p>
<ul class="ulEmpty compact ulBare toc">
<li class="ulEmpty compact ulBare toc" id="section-toc.1-1.4.2.7.2.1">
                    <p id="section-toc.1-1.4.2.7.2.1.1"><a href="#section-4.7.1" class="xref">4.7.1</a>.  <a href="#name-minimal-nat-traversal-suppo" class="xref">Minimal NAT Traversal Support</a></p>
</li>
                  <li class="ulEmpty compact ulBare toc" id="section-toc.1-1.4.2.7.2.2">
                    <p id="section-toc.1-1.4.2.7.2.2.1"><a href="#section-4.7.2" class="xref">4.7.2</a>.  <a href="#name-base-exchange-without-conne" class="xref">Base Exchange without Connectivity Checks</a></p>
</li>
                  <li class="ulEmpty compact ulBare toc" id="section-toc.1-1.4.2.7.2.3">
                    <p id="section-toc.1-1.4.2.7.2.3.1"><a href="#section-4.7.3" class="xref">4.7.3</a>.  <a href="#name-initiating-a-base-exchange-" class="xref">Initiating a Base Exchange Both with and without UDP Encapsulation</a></p>
</li>
                </ul>
</li>
              <li class="ulEmpty compact ulBare toc" id="section-toc.1-1.4.2.8">
                <p id="section-toc.1-1.4.2.8.1"><a href="#section-4.8" class="xref">4.8</a>.  <a href="#name-sending-control-packets-aft" class="xref">Sending Control Packets after the Base Exchange</a></p>
</li>
              <li class="ulEmpty compact ulBare toc" id="section-toc.1-1.4.2.9">
                <p id="section-toc.1-1.4.2.9.1"><a href="#section-4.9" class="xref">4.9</a>.  <a href="#name-mobility-handover-procedure" class="xref">Mobility Handover Procedure</a></p>
</li>
              <li class="ulEmpty compact ulBare toc" id="section-toc.1-1.4.2.10">
                <p id="section-toc.1-1.4.2.10.1"><a href="#section-4.10" class="xref">4.10</a>. <a href="#name-nat-keepalives" class="xref">NAT Keepalives</a></p>
</li>
              <li class="ulEmpty compact ulBare toc" id="section-toc.1-1.4.2.11">
                <p id="section-toc.1-1.4.2.11.1"><a href="#section-4.11" class="xref">4.11</a>. <a href="#name-closing-procedure" class="xref">Closing Procedure</a></p>
</li>
              <li class="ulEmpty compact ulBare toc" id="section-toc.1-1.4.2.12">
                <p id="section-toc.1-1.4.2.12.1"><a href="#section-4.12" class="xref">4.12</a>. <a href="#name-relaying-considerations" class="xref">Relaying Considerations</a></p>
<ul class="ulEmpty compact ulBare toc">
<li class="ulEmpty compact ulBare toc" id="section-toc.1-1.4.2.12.2.1">
                    <p id="section-toc.1-1.4.2.12.2.1.1"><a href="#section-4.12.1" class="xref">4.12.1</a>.  <a href="#name-forwarding-rules-and-permis" class="xref">Forwarding Rules and Permissions</a></p>
</li>
                  <li class="ulEmpty compact ulBare toc" id="section-toc.1-1.4.2.12.2.2">
                    <p id="section-toc.1-1.4.2.12.2.2.1"><a href="#section-4.12.2" class="xref">4.12.2</a>.  <a href="#name-hip-data-relay-and-relaying" class="xref">HIP Data Relay and Relaying of Control Packets</a></p>
</li>
                  <li class="ulEmpty compact ulBare toc" id="section-toc.1-1.4.2.12.2.3">
                    <p id="section-toc.1-1.4.2.12.2.3.1"><a href="#section-4.12.3" class="xref">4.12.3</a>.  <a href="#name-handling-conflicting-spi-va" class="xref">Handling Conflicting SPI Values</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="ulEmpty ulBare compact toc" 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-packet-formats" class="xref">Packet Formats</a></p>
<ul class="ulEmpty compact ulBare toc">
<li class="ulEmpty compact ulBare toc" id="section-toc.1-1.5.2.1">
                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-hip-control-packets" class="xref">HIP Control Packets</a></p>
</li>
              <li class="ulEmpty compact ulBare toc" id="section-toc.1-1.5.2.2">
                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-connectivity-checks-3" class="xref">Connectivity Checks</a></p>
</li>
              <li class="ulEmpty compact ulBare toc" id="section-toc.1-1.5.2.3">
                <p id="section-toc.1-1.5.2.3.1"><a href="#section-5.3" class="xref">5.3</a>.  <a href="#name-keepalives" class="xref">Keepalives</a></p>
</li>
              <li class="ulEmpty compact ulBare toc" id="section-toc.1-1.5.2.4">
                <p id="section-toc.1-1.5.2.4.1"><a href="#section-5.4" class="xref">5.4</a>.  <a href="#name-nat-traversal-mode-paramete" class="xref">NAT Traversal Mode Parameter</a></p>
</li>
              <li class="ulEmpty compact ulBare toc" id="section-toc.1-1.5.2.5">
                <p id="section-toc.1-1.5.2.5.1"><a href="#section-5.5" class="xref">5.5</a>.  <a href="#name-connectivity-check-transact" class="xref">Connectivity Check Transaction Pacing Parameter</a></p>
</li>
              <li class="ulEmpty compact ulBare toc" id="section-toc.1-1.5.2.6">
                <p id="section-toc.1-1.5.2.6.1"><a href="#section-5.6" class="xref">5.6</a>.  <a href="#name-relay-and-registration-para" class="xref">Relay and Registration Parameters</a></p>
</li>
              <li class="ulEmpty compact ulBare toc" id="section-toc.1-1.5.2.7">
                <p id="section-toc.1-1.5.2.7.1"><a href="#section-5.7" class="xref">5.7</a>.  <a href="#name-locator_set-parameter" class="xref">LOCATOR_SET Parameter</a></p>
</li>
              <li class="ulEmpty compact ulBare toc" id="section-toc.1-1.5.2.8">
                <p id="section-toc.1-1.5.2.8.1"><a href="#section-5.8" class="xref">5.8</a>.  <a href="#name-relay_hmac-parameter" class="xref">RELAY_HMAC Parameter</a></p>
</li>
              <li class="ulEmpty compact ulBare toc" id="section-toc.1-1.5.2.9">
                <p id="section-toc.1-1.5.2.9.1"><a href="#section-5.9" class="xref">5.9</a>.  <a href="#name-registration-types" class="xref">Registration Types</a></p>
</li>
              <li class="ulEmpty compact ulBare toc" id="section-toc.1-1.5.2.10">
                <p id="section-toc.1-1.5.2.10.1"><a href="#section-5.10" class="xref">5.10</a>. <a href="#name-notify-packet-types" class="xref">Notify Packet Types</a></p>
</li>
              <li class="ulEmpty compact ulBare toc" id="section-toc.1-1.5.2.11">
                <p id="section-toc.1-1.5.2.11.1"><a href="#section-5.11" class="xref">5.11</a>. <a href="#name-esp-data-packets" class="xref">ESP Data Packets</a></p>
</li>
              <li class="ulEmpty compact ulBare toc" id="section-toc.1-1.5.2.12">
                <p id="section-toc.1-1.5.2.12.1"><a href="#section-5.12" class="xref">5.12</a>. <a href="#name-relayed_address-and-mapped_" class="xref">RELAYED_ADDRESS and MAPPED_ADDRESS Parameters</a></p>
</li>
              <li class="ulEmpty compact ulBare toc" id="section-toc.1-1.5.2.13">
                <p id="section-toc.1-1.5.2.13.1"><a href="#section-5.13" class="xref">5.13</a>. <a href="#name-peer_permission-parameter" class="xref">PEER_PERMISSION Parameter</a></p>
</li>
              <li class="ulEmpty compact ulBare toc" id="section-toc.1-1.5.2.14">
                <p id="section-toc.1-1.5.2.14.1"><a href="#section-5.14" class="xref">5.14</a>. <a href="#name-hip-connectivity-check-pack" class="xref">HIP Connectivity Check Packets</a></p>
</li>
              <li class="ulEmpty compact ulBare toc" id="section-toc.1-1.5.2.15">
                <p id="section-toc.1-1.5.2.15.1"><a href="#section-5.15" class="xref">5.15</a>. <a href="#name-nominate-parameter" class="xref">NOMINATE Parameter</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty ulBare compact toc" 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-iab-considerations" class="xref">IAB Considerations</a></p>
</li>
          <li class="ulEmpty ulBare compact toc" 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-security-considerations" class="xref">Security Considerations</a></p>
<ul class="ulEmpty compact ulBare toc">
<li class="ulEmpty compact ulBare toc" 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-privacy-considerations" class="xref">Privacy Considerations</a></p>
</li>
              <li class="ulEmpty compact ulBare toc" 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-opportunistic-mode" class="xref">Opportunistic Mode</a></p>
</li>
              <li class="ulEmpty compact ulBare toc" id="section-toc.1-1.7.2.3">
                <p id="section-toc.1-1.7.2.3.1"><a href="#section-7.3" class="xref">7.3</a>.  <a href="#name-base-exchange-replay-protec" class="xref">Base Exchange Replay Protection for Control Relay Server</a></p>
</li>
              <li class="ulEmpty compact ulBare toc" id="section-toc.1-1.7.2.4">
                <p id="section-toc.1-1.7.2.4.1"><a href="#section-7.4" class="xref">7.4</a>.  <a href="#name-demultiplexing-different-hi" class="xref">Demultiplexing Different HIP Associations</a></p>
</li>
              <li class="ulEmpty compact ulBare toc" id="section-toc.1-1.7.2.5">
                <p id="section-toc.1-1.7.2.5.1"><a href="#section-7.5" class="xref">7.5</a>.  <a href="#name-reuse-of-ports-at-the-data-" class="xref">Reuse of Ports at the Data Relay Server</a></p>
</li>
              <li class="ulEmpty compact ulBare toc" id="section-toc.1-1.7.2.6">
                <p id="section-toc.1-1.7.2.6.1"><a href="#section-7.6" class="xref">7.6</a>.  <a href="#name-amplification-attacks" class="xref">Amplification Attacks</a></p>
</li>
              <li class="ulEmpty compact ulBare toc" id="section-toc.1-1.7.2.7">
                <p id="section-toc.1-1.7.2.7.1"><a href="#section-7.7" class="xref">7.7</a>.  <a href="#name-attacks-against-connectivit" class="xref">Attacks against Connectivity Checks and Candidate Gathering</a></p>
</li>
              <li class="ulEmpty compact ulBare toc" id="section-toc.1-1.7.2.8">
                <p id="section-toc.1-1.7.2.8.1"><a href="#section-7.8" class="xref">7.8</a>.  <a href="#name-cross-protocol-attacks" class="xref">Cross-Protocol Attacks</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a></p>
</li>
          <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-references" class="xref">References</a></p>
<ul class="ulEmpty compact ulBare toc">
<li class="ulEmpty compact ulBare toc" id="section-toc.1-1.9.2.1">
                <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="xref">9.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a></p>
</li>
              <li class="ulEmpty compact ulBare toc" id="section-toc.1-1.9.2.2">
                <p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2" class="xref">9.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#appendix-A" class="xref">Appendix A</a>.  <a href="#name-selecting-a-value-for-check" class="xref">Selecting a Value for Check Pacing</a></p>
</li>
          <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#appendix-B" class="xref">Appendix B</a>.  <a href="#name-differences-with-respect-to" class="xref">Differences with Respect to ICE</a></p>
</li>
          <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#appendix-C" class="xref">Appendix C</a>.  <a href="#name-differences-to-base-exchang" class="xref">Differences to Base Exchange and UPDATE Procedures</a></p>
</li>
          <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#appendix-D" class="xref">Appendix D</a>.  <a href="#name-multihoming-considerations" class="xref">Multihoming Considerations</a></p>
</li>
          <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.14">
            <p id="section-toc.1-1.14.1"><a href="#appendix-E" class="xref">Appendix E</a>.  <a href="#name-dns-considerations" class="xref">DNS Considerations</a></p>
</li>
          <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.15">
            <p id="section-toc.1-1.15.1"><a href="#appendix-F" class="xref"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</a></p>
</li>
          <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.16">
            <p id="section-toc.1-1.16.1"><a href="#appendix-G" class="xref"></a><a href="#name-contributors" class="xref">Contributors</a></p>
</li>
          <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.17">
            <p id="section-toc.1-1.17.1"><a href="#appendix-H" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="sec_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"> The Host Identity Protocol (HIP) <span>[<a href="#RFC7401" class="xref">RFC7401</a>]</span> is specified to run directly on top of IPv4 or
      IPv6. However, many middleboxes found in the Internet, such as NATs and
      firewalls, often allow only UDP or TCP traffic to pass <span>[<a href="#RFC5207" class="xref">RFC5207</a>]</span>. Also, NATs usually require the host
      behind a NAT to create a forwarding state in the NAT before other hosts
      outside of the NAT can contact the host behind the NAT. To overcome this
      problem, different methods, commonly referred to as NAT traversal
      techniques, have been developed.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">As one solution, the HIP experiment report <span>[<a href="#RFC6538" class="xref">RFC6538</a>]</span> mentions Teredo-based NAT traversal for HIP and
      related Encapsulating Security Payload (ESP) traffic (with double
      tunneling overhead). Another solution is specified in <span>[<a href="#RFC5770" class="xref">RFC5770</a>]</span>, which will be referred to as
      "Legacy ICE-HIP" in this document. The experimental Legacy ICE-HIP
      specification combines the Interactive Connectivity Establishment (ICE)
      protocol (originally <span>[<a href="#RFC5245" class="xref">RFC5245</a>]</span>) with HIP so that
      basically, ICE is responsible for NAT traversal and connectivity
      testing, while HIP is responsible for end-host authentication and IPsec
      key management. The resulting protocol uses HIP, Session Traversal
      Utilities for NAT (STUN), and ESP messages tunneled over a single UDP
      flow. The benefit of using ICE and its STUN / Traversal Using Relays
      around NAT (TURN) messaging formats is
      that one can reuse the NAT traversal infrastructure already available
      in the Internet, such as STUN and TURN servers. Also, some middleboxes
      may be STUN aware and may be able to do something "smart" when they see
      STUN being used for NAT traversal.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">HIP poses a unique challenge to using standard ICE, not only due to
      kernel-space dependencies of HIP, but also due to its close integration
      with kernel-space IPsec; and, while <span>[<a href="#RFC5770" class="xref">RFC5770</a>]</span> provides a technically workable path, HIP incurs
      unacceptable performance drawbacks for kernel-space
      implementations. Also, implementing and integrating a full ICE/STUN/TURN
      protocol stack as specified in Legacy ICE-HIP results in a considerable
      amount of effort and code, which could be avoided by reusing and
      extending HIP messages and state machines for the same purpose. Thus,
      this document specifies an alternative NAT traversal mode referred to as
      "Native ICE-HIP" that employs the HIP messaging format instead of STUN
      or TURN for the connectivity checks, keepalives, and data relaying.
      Native ICE-HIP also specifies how mobility management works in the
      context of NAT traversal, which is missing from the Legacy ICE-HIP
      specification. The native specification is also based on HIPv2, whereas
      the legacy specification is based on HIPv1. The differences to Legacy
      ICE-HIP are further elaborated in <a href="#sec_ice_diff" class="xref">Appendix B</a>.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">Similar to Legacy ICE-HIP, this specification builds on the HIP
      registration extensions <span>[<a href="#RFC8003" class="xref">RFC8003</a>]</span> and
      the base exchange procedure <span>[<a href="#RFC7401" class="xref">RFC7401</a>]</span>
      and its closing procedures; therefore, the reader is recommended to get
      familiar with the relevant specifications. In a nutshell, the
      registration extensions allow a HIP Initiator (usually a "client" host)
      to ask for specific services from a HIP Responder (usually a "server"
      host). The registration parameters are included in a base exchange,
      which is essentially a four-way Diffie-Hellman key exchange
      authenticated using the public keys of the end hosts. When the hosts
      negotiate support for ESP <span>[<a href="#RFC7402" class="xref">RFC7402</a>]</span>
      during the base exchange, they can deliver ESP-protected application
      payload to each other.  When either of the hosts moves and changes its
      IP address, the two hosts re-establish connectivity using the mobility
      extensions <span>[<a href="#RFC8046" class="xref">RFC8046</a>]</span>. The reader is also
      recommended to get familiar with the mobility extensions; basically,
      the process is a three-way procedure where the mobile host first
      announces its new location to the peer; then, the peer tests
      for connectivity (the so-called return routability check); and then, the
      mobile host must respond to the announcement in order to activate its
      new location. This specification builds on the mobility procedures, but
      modifies them to be compatible with ICE. The differences in the mobility
      extensions are specified in <a href="#sec_hip_diff" class="xref">Appendix C</a>. It is worth noting that multihoming support as
      specified in <span>[<a href="#RFC8047" class="xref">RFC8047</a>]</span> is left for
      further study.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">This specification builds heavily on the ICE methodology, so it is
      recommended that the reader is familiar with the ICE specification <span>[<a href="#RFC8445" class="xref">RFC8445</a>]</span> (especially the overview). However,
      Native ICE-HIP does not implement all the features in ICE; hence,
      the different features of ICE are cross referenced using <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> terminology for clarity. <a href="#sec_ice_diff" class="xref">Appendix B</a> explains the differences to
      ICE, and it is recommended that the reader read this section
      in addition to the ICE specification.<a href="#section-1-5" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-2">
      <h2 id="name-terminology">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-terminology" class="section-name selfRef">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">This document borrows terminology from <span>[<a href="#RFC5770" class="xref">RFC5770</a>]</span>, <span>[<a href="#RFC7401" class="xref">RFC7401</a>]</span>, <span>[<a href="#RFC8046" class="xref">RFC8046</a>]</span>, <span>[<a href="#RFC9063" class="xref">RFC9063</a>]</span>, <span>[<a href="#RFC8445" class="xref">RFC8445</a>]</span>, and <span>[<a href="#RFC8489" class="xref">RFC8489</a>]</span>. The following terms recur in the text:<a href="#section-2-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-2-3">
        <dt id="section-2-3.1">ICE:</dt>
        <dd style="margin-left: 1.5em" id="section-2-3.2">Interactive Connectivity Establishment (ICE) protocol as specified
 in <span>[<a href="#RFC8445" class="xref">RFC8445</a>]</span>.<a href="#section-2-3.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.3">Legacy ICE-HIP:</dt>
        <dd style="margin-left: 1.5em" id="section-2-3.4">Refers to the "Basic Host Identity Protocol (HIP) Extensions for
 Traversal of Network Address Translators" as specified in <span>[<a href="#RFC5770" class="xref">RFC5770</a>]</span>. The protocol specified in this
 document offers an alternative to Legacy ICE-HIP.<a href="#section-2-3.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.5">Native ICE-HIP:</dt>
        <dd style="margin-left: 1.5em" id="section-2-3.6">The protocol specified in this document (Native NAT Traversal Mode
 for HIP).<a href="#section-2-3.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.7">Initiator:</dt>
        <dd style="margin-left: 1.5em" id="section-2-3.8">The host that initiates the base exchange using
 I1 message <span>[<a href="#RFC7401" class="xref">RFC7401</a>]</span>.<a href="#section-2-3.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.9">Responder:</dt>
        <dd style="margin-left: 1.5em" id="section-2-3.10"> The host that receives the I1 packet from the
 Initiator <span>[<a href="#RFC7401" class="xref">RFC7401</a>]</span>.<a href="#section-2-3.10" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.11">Control Relay Server</dt>
        <dd style="margin-left: 1.5em" id="section-2-3.12">A registrar host that forwards any kind of HIP control plane
 packets between the Initiator and the Responder. This host is critical
 because it relays the locators between the Initiator and the
 Responder so that they can try to establish a direct communication
 path with each other. This host is used to replace HIP Rendezvous
 Servers <span>[<a href="#RFC8004" class="xref">RFC8004</a>]</span> for hosts operating
 in private address realms. In the Legacy ICE-HIP specification <span>[<a href="#RFC5770" class="xref">RFC5770</a>]</span>, this host is denoted as "HIP
 Relay Server".<a href="#section-2-3.12" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.13">Control Relay Client:</dt>
        <dd style="margin-left: 1.5em" id="section-2-3.14">A requester host that registers to a Control Relay Server
 requesting it to forward control plane traffic (i.e., HIP control
 messages). In the Legacy ICE-HIP specification <span>[<a href="#RFC5770" class="xref">RFC5770</a>]</span>, this is denoted as "HIP Relay Client".<a href="#section-2-3.14" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.15">Data Relay Server:</dt>
        <dd style="margin-left: 1.5em" id="section-2-3.16">A new entity introduced in this document; a registrar host that
 forwards HIP related data plane packets, such as Encapsulating
 Security Payload (ESP) <span>[<a href="#RFC7402" class="xref">RFC7402</a>]</span>,
 between two hosts. This host implements similar functionality as TURN
 servers.<a href="#section-2-3.16" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.17">Data Relay Client:</dt>
        <dd style="margin-left: 1.5em" id="section-2-3.18">A requester host that registers to a Data Relay Server requesting
 it to forward data plane traffic (e.g. ESP traffic). This
 functionality is a new and introduced in this document.<a href="#section-2-3.18" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.19">Locator:</dt>
        <dd style="margin-left: 1.5em" id="section-2-3.20">
          <p id="section-2-3.20.1">As defined in <span>[<a href="#RFC8046" class="xref">RFC8046</a>]</span>: "A
        name that controls how the packet is routed through the network and
        demultiplexed by the end host. It may include a concatenation of
        traditional network addresses such as an IPv6 address and end-to-end
        identifiers such as an ESP SPI. It may also include transport port
        numbers or IPv6 Flow Labels as demultiplexing context, or it may
        simply be a network address."<a href="#section-2-3.20.1" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.21">LOCATOR_SET (written in capital letters):</dt>
        <dd style="margin-left: 1.5em" id="section-2-3.22">Denotes a HIP control packet parameter that bundles multiple
 locators together <span>[<a href="#RFC8046" class="xref">RFC8046</a>]</span>.<a href="#section-2-3.22" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.23">HIP offer:</dt>
        <dd style="margin-left: 1.5em" id="section-2-3.24">Before two end hosts can establish a communication channel using
        the NAT traversal procedures defined in this document, they need to
        exchange their locators (i.e., candidates) with each other. In ICE,
        this procedure is called Candidate Exchange; it does not specify how
        the candidates are exchanged, but Session Description Protocol (SDP)
        "offer/answer" is mentioned as an example. In contrast, the Candidate
        Exchange in HIP is the base exchange itself or a subsequent UPDATE
        procedure occurring after a handover. Following <span>[<a href="#RFC5770" class="xref">RFC5770</a>]</span> and SDP-related naming conventions <span>[<a href="#RFC3264" class="xref">RFC3264</a>]</span>, "HIP offer" is the Initiator's
        LOCATOR_SET parameter in a HIP I2 or in an UPDATE control packet.<a href="#section-2-3.24" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.25">HIP answer:</dt>
        <dd style="margin-left: 1.5em" id="section-2-3.26"> The Responder's LOCATOR_SET parameter in a HIP R2 or UPDATE
 control packet. The HIP answer corresponds to the SDP answer parameter <span>[<a href="#RFC3264" class="xref">RFC3264</a>]</span> but is HIP specific. Please refer
 also to the longer description of the "HIP offer" term above.<a href="#section-2-3.26" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.27">HIP connectivity checks:</dt>
        <dd style="margin-left: 1.5em" id="section-2-3.28"> In order to obtain a direct end-to-end communication path
 (without employing a Data Relay Server), two communicating HIP hosts
 try to "punch holes" through their NAT boxes using this mechanism. It
 is similar to the ICE connectivity checks but implemented using HIP
 return routability checks.<a href="#section-2-3.28" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.29">Controlling host:</dt>
        <dd style="margin-left: 1.5em" id="section-2-3.30">The controlling host <span>[<a href="#RFC8445" class="xref">RFC8445</a>]</span> is
 always the Initiator in the context of this specification. It
 nominates the candidate pair to be used with the controlled host.<a href="#section-2-3.30" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.31">Controlled host:</dt>
        <dd style="margin-left: 1.5em" id="section-2-3.32">The controlled host <span>[<a href="#RFC8445" class="xref">RFC8445</a>]</span> is
 always the Responder in the context of this specification. It waits
 for the controlling host to nominate an address candidate pair.<a href="#section-2-3.32" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.33">Checklist:</dt>
        <dd style="margin-left: 1.5em" id="section-2-3.34">A list of address candidate pairs that need to be tested for
 connectivity (same as in <span>[<a href="#RFC8445" class="xref">RFC8445</a>]</span>).<a href="#section-2-3.34" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.35">Transport address:</dt>
        <dd style="margin-left: 1.5em" id="section-2-3.36">Transport-layer port and the corresponding IPv4/v6 address (same
 as in <span>[<a href="#RFC8445" class="xref">RFC8445</a>]</span>).<a href="#section-2-3.36" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.37">Candidate:</dt>
        <dd style="margin-left: 1.5em" id="section-2-3.38">A transport address that is a potential point of contact for
 receiving data (same as in <span>[<a href="#RFC8445" class="xref">RFC8445</a>]</span>).<a href="#section-2-3.38" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.39">Host candidate:</dt>
        <dd style="margin-left: 1.5em" id="section-2-3.40">A candidate obtained by binding to a specific port from an IP
 address on the host (same as in <span>[<a href="#RFC8445" class="xref">RFC8445</a>]</span>).<a href="#section-2-3.40" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.41">Server-reflexive candidate:</dt>
        <dd style="margin-left: 1.5em" id="section-2-3.42">A translated transport address of a host as observed by a Control
 or Data Relay Server (same as in <span>[<a href="#RFC8445" class="xref">RFC8445</a>]</span>).<a href="#section-2-3.42" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.43">Peer-reflexive candidate:</dt>
        <dd style="margin-left: 1.5em" id="section-2-3.44">A translated transport address of a host as observed by its peer
 (same as in <span>[<a href="#RFC8445" class="xref">RFC8445</a>]</span>).<a href="#section-2-3.44" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.45">Relayed candidate:</dt>
        <dd style="margin-left: 1.5em" id="section-2-3.46">A transport address that exists on a Data Relay Server. Packets
 that arrive at this address are relayed towards the Data Relay
 Client. The concept is the same as in <span>[<a href="#RFC8445" class="xref">RFC8445</a>]</span>, but a Data Relay Server is used instead of a TURN
 server.<a href="#section-2-3.46" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.47">Permission:</dt>
        <dd style="margin-left: 1.5em" id="section-2-3.48">In the context of Data Relay Server, permission refers to a
 concept similar to TURN's <span>[<a href="#RFC8656" class="xref">RFC8656</a>]</span>
 channels. Before a host can use a relayed candidate to forward traffic
 through a Data Relay Server, the host must activate the relayed
 candidate with a specific peer host.<a href="#section-2-3.48" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.49">Base:</dt>
        <dd style="margin-left: 1.5em" id="section-2-3.50">Similar to that described in <span>[<a href="#RFC8445" class="xref">RFC8445</a>]</span>, the
 base of a candidate is the local source address a host uses to send
 packets for the associated candidate. For example, the base of a
 server-reflexive address is the local address the host used for
 registering itself to the associated Control or Data Relay Server. The
 base of a host candidate is equal to the host candidate itself.<a href="#section-2-3.50" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
</section>
<section id="section-3">
      <h2 id="name-overview-of-operation">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-overview-of-operation" class="section-name selfRef">Overview of Operation</a>
      </h2>
<span id="name-example-network-configurati"></span><div id="fig_overview">
<figure id="figure-1">
        <div class="artwork art-text alignCenter" id="section-3-1.1">
<pre>
               +--------------+
               |    Control   |
+--------+     | Relay Server |      +--------+
| Data   |     +----+-----+---+      | Data   |
| Relay  |         /       \         | Relay  |
| Server |        /         \        | Server |
+--------+       /           \       +--------+
                /             \
               /               \
              /                 \
             /  &lt;- Signaling -&gt;  \
            /                     \
      +-------+                +-------+
      |  NAT  |                |  NAT  |
      +-------+                +-------+
       /                              \
      /                                \
 +-------+                           +-------+
 | Init- |                           | Resp- |
 | iator |                           | onder |
 +-------+                           +-------+
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-example-network-configurati" class="selfRef">Example Network Configuration</a>
        </figcaption></figure>
</div>
<p id="section-3-2"> In the example configuration depicted in <a href="#fig_overview" class="xref">Figure 1</a>, both Initiator and Responder are behind one or more
      NATs, and both private networks are connected to the public Internet. To
      be contacted from behind a NAT, at least the Responder must be
      registered with a Control Relay Server reachable on the public
      Internet. The Responder may have also registered to a Data Relay Server
      that can forward the data plane in case NAT traversal fails. While,
      strictly speaking, the Initiator does not need a Data Relay Server, it
      may act in the other role with other hosts; connectivity with the
      Data Relay Server of the Responder may fail, so the Initiator may also
      need to register to a Control and/or Data Relay Server. It is worth
      noting that a Control and Data Relay does not forge the source address
      of a passing packet but always translates the source address and source
      port of a packet to be forwarded (to its own).<a href="#section-3-2" class="pilcrow">¶</a></p>
<p id="section-3-3">We assume, as a starting point, that the Initiator knows both the
      Responder's Host Identity Tag (HIT) and the address(es) of the
      Responder's Control Relay Server(s) (how the Initiator learns of the
      Responder's Control Relay Server is outside of the scope of this
      document, but it may be learned through DNS or another name service). The first
      steps are for both the Initiator and Responder to register with a
      Control Relay Server (need not be the same one) and gather a set of
      address candidates. The hosts use either Control Relay Servers or Data
      Relay Servers for gathering the candidates. Next, the HIP base exchange
      is carried out by encapsulating the HIP control packets in UDP datagrams
      and sending them through the Responder's Control Relay Server.  As part
      of the base exchange, each HIP host learns of the peer's candidate
      addresses through the HIP offer/answer procedure embedded in the base
      exchange.<a href="#section-3-3" class="pilcrow">¶</a></p>
<p id="section-3-4"> Once the base exchange is completed, two HIP hosts have established
      a working communication session (for signaling) via a Control Relay
      Server, but the hosts still have to find a better path, preferably
      without a Data Relay Server, for the ESP data flow. For this,
      connectivity checks are carried out until a working pair of addresses is
      discovered.  At the end of the procedure, if successful, the hosts will
      have established a UDP-based tunnel that traverses both NATs with the
      data flowing directly from NAT to NAT or via a Data Relay Server. At
      this point, the HIP signaling can also be sent over the same
      address/port pair, and is demultiplexed (or, in other words, separated)
      from IPsec as described in the UDP encapsulation standard for IPsec
      <span>[<a href="#RFC3948" class="xref">RFC3948</a>]</span>. Finally, the two hosts send
      NAT keepalives as needed in order keep their UDP-tunnel state active in
      the associated NAT boxes.<a href="#section-3-4" class="pilcrow">¶</a></p>
<p id="section-3-5"> If either one of the hosts knows that it is not behind a NAT, hosts
      can negotiate during the base exchange a different mode of NAT traversal
      that does not use HIP connectivity checks, but only UDP encapsulation of
      HIP and ESP. Also, it is possible for the Initiator to simultaneously try
      a base exchange with and without UDP encapsulation. If a base exchange
      without UDP encapsulation succeeds, no HIP connectivity checks or UDP
      encapsulation of ESP are needed.<a href="#section-3-5" class="pilcrow">¶</a></p>
</section>
<div id="sec_protocol">
<section id="section-4">
      <h2 id="name-protocol-description">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-protocol-description" class="section-name selfRef">Protocol Description</a>
      </h2>
<p id="section-4-1"> This section describes the normative behavior of the "Native
      ICE-HIP" protocol extension. Most of the procedures are similar to what
      is defined in <span>[<a href="#RFC5770" class="xref">RFC5770</a>]</span> but with
      different, or additional, parameter types and values. In addition, a new
      type of relaying server, Data Relay Server, is specified. Also, it
      should be noted that HIP version 2 <span>[<a href="#RFC7401" class="xref">RFC7401</a>]</span> <span class="bcp14">MUST</span> be used instead of HIPv1 with
      this NAT traversal mode.<a href="#section-4-1" class="pilcrow">¶</a></p>
<div id="sec_registration">
<section id="section-4.1">
        <h3 id="name-relay-registration">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-relay-registration" class="section-name selfRef">Relay Registration</a>
        </h3>
<p id="section-4.1-1">In order for two hosts to communicate over NATed environments,
 they need a reliable way to exchange information. To achieve this,
 "HIP Relay Server" is defined in <span>[<a href="#RFC5770" class="xref">RFC5770</a>]</span>. It supports the relaying of HIP control plane traffic
 over UDP in NATed environments and forwards HIP control packets
 between the Initiator and the Responder. In this document, the HIP
 Relay Server is denoted as "Control Relay Server" for better alignment
 with the rest of the terminology.  The registration to the Control
 Relay Server can be achieved using the RELAY_UDP_HIP parameter as
 explained later in this section.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<p id="section-4.1-2">To also guarantee data plane delivery over varying types of NAT
 devices, a host <span class="bcp14">MAY</span> also register for UDP-encapsulated
 ESP relaying using Registration Type RELAY_UDP_ESP (value 3).  This service may be coupled with the Control Relay Server
 or offered separately on another server. If the server supports
 relaying of UDP-encapsulated ESP, the host is allowed to register for
 a data-relaying service using the registration extensions in <span><a href="https://www.rfc-editor.org/rfc/rfc8003#section-3.3" class="relref">Section 3.3</a> of [<a href="#RFC8003" class="xref">RFC8003</a>]</span>. If the server
 has sufficient relaying resources (free port numbers, bandwidth, etc.)
 available, it opens a UDP port on one of its addresses and signals the
 address and port to the registering host using the RELAYED_ADDRESS
 parameter (as defined in <a href="#sec_relayed_address" class="xref">Section 5.12</a> in this document). If the Data Relay Server would
 accept the data-relaying request but does not currently have enough
 resources to provide data-relaying service, it <span class="bcp14">MUST</span>
 reject the request with Failure Type "Insufficient resources" <span>[<a href="#RFC8003" class="xref">RFC8003</a>]</span>.<a href="#section-4.1-2" class="pilcrow">¶</a></p>
<p id="section-4.1-3">The registration process follows the generic registration
 extensions defined in <span>[<a href="#RFC8003" class="xref">RFC8003</a>]</span>. The
 HIP control plane relaying registration follows <span>[<a href="#RFC5770" class="xref">RFC5770</a>]</span>, but the data plane registration is different. It
 is worth noting that if the HIP control and data plane relay services
 reside on different hosts, the client has to register separately to
 each of them. In the example shown in <a href="#fig_reg" class="xref">Figure 2</a>, the two services are coupled on a single host. The
 text uses "Relay Client" and "Relay Server" as a shorthand when the
 procedures apply both to control and data cases.<a href="#section-4.1-3" class="pilcrow">¶</a></p>
<span id="name-example-registration-with-a"></span><div id="fig_reg">
<figure id="figure-2">
          <div class="artwork art-text alignCenter" id="section-4.1-4.1">
<pre>
  Control/Data                                           Control/Data
  Relay Client (Initiator)                   Relay Server (Responder)
  |   1. UDP(I1)                                                    |
  +----------------------------------------------------------------&gt;|
  |                                                                 |
  |   2. UDP(R1(REG_INFO(RELAY_UDP_HIP,[RELAY_UDP_ESP])))           |
  |&lt;----------------------------------------------------------------+
  |                                                                 |
  |   3. UDP(I2(REG_REQ(RELAY_UDP_HIP),[RELAY_UDP_ESP]))            |
  +----------------------------------------------------------------&gt;|
  |                                                                 |
  |   4. UDP(R2(REG_RES(RELAY_UDP_HIP,[RELAY_UDP_ESP]), REG_FROM,   |
  |          [RELAYED_ADDRESS]))                                    |
  |&lt;----------------------------------------------------------------+
  |                                                                 |
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-example-registration-with-a" class="selfRef">Example Registration with a HIP Relay</a>
          </figcaption></figure>
</div>
<p id="section-4.1-5"> In step 1, the Relay Client (Initiator) starts the registration
 procedure by sending an I1 packet over UDP to the Relay Server. It is
 <span class="bcp14">RECOMMENDED</span> that the Relay Client select a random
 source port number from the ephemeral port range 49152-65535 for
 initiating a base exchange.  Alternatively, a host <span class="bcp14">MAY</span>
 also use a single fixed port for initiating all outgoing
 connections. However, the allocated port <span class="bcp14">MUST</span> be
 maintained until all of the corresponding HIP associations are
 closed. It is <span class="bcp14">RECOMMENDED</span> that the Relay Server listen
 to incoming connections at UDP port 10500. If some other port number
 is used, it needs to be known by potential Relay Clients.<a href="#section-4.1-5" class="pilcrow">¶</a></p>
<p id="section-4.1-6"> In step 2, the Relay Server (Responder) lists the services that it
        supports in the R1 packet. The support for HIP control plane over UDP
        relaying is denoted by the Registration Type value RELAY_UDP_HIP (see
        <a href="#sec_reg-types" class="xref">Section 5.9</a>). If the server also
        supports the relaying of ESP traffic over UDP, it also includes
        the Registration Type value RELAY_UDP_ESP.<a href="#section-4.1-6" class="pilcrow">¶</a></p>
<p id="section-4.1-7"> In step 3, the Relay Client selects the services for which it
 registers and lists them in the REG_REQ parameter. The Relay Client
 registers for the Control Relay service by listing the RELAY_UDP_HIP
 value in the request parameter. If the Relay Client also requires ESP
 relaying over UDP, it lists also RELAY_UDP_ESP.<a href="#section-4.1-7" class="pilcrow">¶</a></p>
<p id="section-4.1-8"> In step 4, the Relay Server concludes the registration procedure
 with an R2 packet and acknowledges the registered services in the
 REG_RES parameter. The Relay Server denotes unsuccessful registrations
 (if any) in the REG_FAILED parameter of R2. The Relay Server also
 includes a REG_FROM parameter that contains the transport address of
 the Relay Client as observed by the Relay Server (server-reflexive
 candidate). If the Relay Client registered to ESP-relaying service,
 the Relay Server includes a RELAYED_ADDRESS parameter that describes the
 UDP port allocated to the Relay Client for ESP relaying. It is worth
 noting that the Data Relay Client must first activate this UDP port by
 sending an UPDATE message to the Data Relay Server that includes a
 PEER_PERMISSION parameter as described in <a href="#sec_forwarding" class="xref">Section 4.12.1</a> both after base exchange
 and handover procedures. Also, the Data Relay Server should follow the
 port allocation recommendations in <a href="#sec_reuse" class="xref">Section 7.5</a>.<a href="#section-4.1-8" class="pilcrow">¶</a></p>
<p id="section-4.1-9">After the registration, the Relay Client periodically sends NAT
        keepalives to the Relay Server in order to keep the NAT bindings
        between the Relay Client and the relay alive. The keepalive extensions
        are described in <a href="#sec_nat-keepalives" class="xref">Section 4.10</a>.<a href="#section-4.1-9" class="pilcrow">¶</a></p>
<p id="section-4.1-10"> The Data Relay Client <span class="bcp14">MUST</span> maintain an active HIP
        association with the Data Relay Server as long as it requires the
        data-relaying service. When the HIP association is closed (or times
        out), or the registration lifetime passes without the Data Relay
        Client refreshing the registration, the Data Relay Server
        <span class="bcp14">MUST</span> stop relaying packets for that host and close the
        corresponding UDP port (unless other Data Relay Clients are still
        using it).<a href="#section-4.1-10" class="pilcrow">¶</a></p>
<p id="section-4.1-11"> The Data Relay Server <span class="bcp14">SHOULD</span> offer a different
 relayed address and port for each Data Relay Client because not doing
 so can cause problems with stateful firewalls (see <a href="#sec_reuse" class="xref">Section 7.5</a>).<a href="#section-4.1-11" class="pilcrow">¶</a></p>
<p id="section-4.1-12">When a Control Relay Client sends an UPDATE (e.g., due to host
 movement or to renew service registration), the Control Relay Server
 <span class="bcp14">MUST</span> follow the general guidelines defined in <span>[<a href="#RFC8003" class="xref">RFC8003</a>]</span>, with the difference that all
 UPDATE messages are delivered on top of UDP. In addition to this, the
 Control Relay Server <span class="bcp14">MUST</span> include the REG_FROM
 parameter in all UPDATE responses sent to the Control Relay Client.
 This applies to both renewals of service registration and to host
 movement.  It is especially important for the case of host
 movement, as this is the mechanism that allows the Control Relay
 Client to learn its new server-reflexive address candidate.<a href="#section-4.1-12" class="pilcrow">¶</a></p>
<p id="section-4.1-13">A Data Relay Client can request multiple relayed candidates from
 the Data Relay Server (e.g., for the reasons described in <a href="#sec_conflicting" class="xref">Section 4.12.3</a>). After the base exchange
 with registration, the Data Relay Client can request additional
 relayed candidates similarly as during the base exchange. The Data
 Relay Client sends an UPDATE message REG_REQ parameter requesting for
 the RELAY_UDP_ESP service. The UPDATE message <span class="bcp14">MUST</span> also
 include a SEQ and an ECHO_REQUEST_SIGNED parameter. The Data Relay
 Server <span class="bcp14">MUST</span> respond with an UPDATE message that
 includes the corresponding response parameters: REG_RES, ACK and
 ECHO_REQUEST_SIGNED. In case the Data Relay Server allocated a new
 relayed UDP port for the Data Relay Client, the REG_RES parameter
 <span class="bcp14">MUST</span> list RELAY_UDP_ESP as a service and the UPDATE
 message <span class="bcp14">MUST</span> also include a RELAYED_ADDRESS parameter
 describing the relayed UDP port. The Data Relay Server
 <span class="bcp14">MUST</span> also include the server-reflexive candidate in a
 REG_FROM parameter. It is worth mentioning that the Data Relay Client
 <span class="bcp14">MUST</span> activate the UDP port as described in <a href="#sec_forwarding" class="xref">Section 4.12.1</a> before it can be used for
 any ESP relaying.<a href="#section-4.1-13" class="pilcrow">¶</a></p>
<p id="section-4.1-14">A Data Relay Client may unregister a relayed candidate in
 two ways. It can wait for its lifetime to expire or it can
 explicitly request it with zero lifetime using the UPDATE
 mechanism. The Data Relay Client can send a REG_REQ parameter
 with zero lifetime to the Data Relay Server in order to expire
 all relayed candidates. To expire a specific relayed
 candidate, the Data Relay Client <span class="bcp14">MUST</span> also include
 a RELAYED_ADDRESS parameter as sent by the server in the UPDATE
 message. Upon closing the HIP association (CLOSE-CLOSE-ACK
 procedure initiated by either party), the Data Relay Server
 <span class="bcp14">MUST</span> also expire all relayed candidates.<a href="#section-4.1-14" class="pilcrow">¶</a></p>
<p id="section-4.1-15">Please also refer to <a href="#sec_cross_protocol" class="xref">Section 7.8</a> for protection against cross-protocol attacks for
 both Control Relay Client and Server.<a href="#section-4.1-15" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec_gathering">
<section id="section-4.2">
        <h3 id="name-transport-address-candidate">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-transport-address-candidate" class="section-name selfRef">Transport Address Candidate Gathering at the Relay Client</a>
        </h3>
<p id="section-4.2-1"> An Initiator needs to gather a set of address candidates
        before contacting a (non-relay) Responder. The candidates are
        needed for connectivity checks that allow two hosts to
        discover a direct, non-relayed path for communicating with
        each other. One server-reflexive candidate can be discovered
        during the registration with the Control Relay Server from the
        REG_FROM parameter (and another from Data Relay Server if one
        is employed).<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<p id="section-4.2-2"> The candidate gathering can be done at any time, but it needs to be
        done before sending an I2 or R2 in the base exchange if ICE-HIP-UDP mode is to be
        used for the connectivity checks. It is <span class="bcp14">RECOMMENDED</span> that all three
        types of candidates (host, server reflexive, and relayed) are gathered
        to maximize the probability of successful NAT traversal. However, if no
        Data Relay Server is used, and the host has only a single local IP address to
        use, the host <span class="bcp14">MAY</span> use the local address as the only host candidate and
        the address from the REG_FROM parameter discovered during the Control Relay Server
        registration as a server-reflexive candidate. In this case, no further
        candidate gathering is needed.<a href="#section-4.2-2" class="pilcrow">¶</a></p>
<p id="section-4.2-3">A Data Relay Client <span class="bcp14">MAY</span> register only a single
 relayed candidate that it uses with multiple other peers. However, it
 is <span class="bcp14">RECOMMENDED</span> that a Data Relay Client registers a new
 server relayed candidate for each of its peers for the reasons
 described in <a href="#sec_conflicting" class="xref">Section 4.12.3</a>. The
 procedures for registering multiple relayed candidates are described
 in <a href="#sec_registration" class="xref">Section 4.1</a>.<a href="#section-4.2-3" class="pilcrow">¶</a></p>
<p id="section-4.2-4"> If a Relay Client has more than one network interface, it
        can discover additional server-reflexive candidates by sending
        UPDATE messages from each of its interfaces to the Relay
        Server.  Each such UPDATE message <span class="bcp14">MUST</span> include the following
        parameters: the registration request (REG_REQ) parameter with
        Registration Type CANDIDATE_DISCOVERY (value 4)
        and the ECHO_REQUEST_SIGNED parameter.  When a Control Relay Server
        receives an UPDATE message with registration request
        containing a CANDIDATE_DISCOVERY type, it <span class="bcp14">MUST</span> include a
        REG_FROM parameter, containing the same information as if this
        were a Control Relay Server registration, to the response (in
        addition to the mandatory ECHO_RESPONSE_SIGNED parameter). This request
        type <span class="bcp14">SHOULD NOT</span> create any state at the Control Relay
        Server.<a href="#section-4.2-4" class="pilcrow">¶</a></p>
<p id="section-4.2-5">The rules in <span><a href="https://www.rfc-editor.org/rfc/rfc8445#section-5.1.1" class="relref">Section 5.1.1</a> of [<a href="#RFC8445" class="xref">RFC8445</a>]</span> for candidate gathering are followed here. A number
 of host candidates (loopback, anycast and others) should be excluded as
 described in the ICE specification (<span><a href="https://www.rfc-editor.org/rfc/rfc8445#section-5.1.1.1" class="relref">Section 5.1.1.1</a> of [<a href="#RFC8445" class="xref">RFC8445</a>]</span>). Relayed candidates
 <span class="bcp14">SHOULD</span> be gathered in order to guarantee successful NAT
 traversal, and implementations <span class="bcp14">SHOULD</span> support this
 functionality even if it will not be used in deployments in order to
 enable it by software configuration update if needed at some point.

 Similarly, as explained in the ICE specification (<span><a href="https://www.rfc-editor.org/rfc/rfc8445#section-5.1.1.2" class="relref">Section 5.1.1.2</a> of [<a href="#RFC8445" class="xref">RFC8445</a>]</span>), if an
 IPv6-only host is in a network that utilizes NAT64 <span>[<a href="#RFC6146" class="xref">RFC6146</a>]</span> and DNS64 <span>[<a href="#RFC6147" class="xref">RFC6147</a>]</span> technologies, it may also gather IPv4
 server-reflexive and/or relayed candidates from IPv4-only Control or
 Data Relay Servers.  IPv6-only hosts <span class="bcp14">SHOULD</span> also
 utilize IPv6 prefix discovery <span>[<a href="#RFC7050" class="xref">RFC7050</a>]</span> to discover the IPv6 prefix used by NAT64 (if any)
 and generate server-reflexive candidates for each IPv6-only interface,
 accordingly.  The NAT64 server-reflexive candidates are prioritized
 like IPv4 server-reflexive candidates.<a href="#section-4.2-5" class="pilcrow">¶</a></p>
<p id="section-4.2-6">HIP-based connectivity can be utilized by IPv4 applications using
 Local Scope Identifiers (LSIs) and by IPv6-based applications using
 HITs. The LSIs and HITs of the local virtual interfaces
 <span class="bcp14">MUST</span> be excluded in the candidate gathering phase as
 well to avoid creating unnecessary loopback connectivity tests.<a href="#section-4.2-6" class="pilcrow">¶</a></p>
<p id="section-4.2-7">Gathering of candidates <span class="bcp14">MAY</span> also be performed by other
      means than described in this section. For example, the candidates could
      be gathered as specified in <span><a href="https://www.rfc-editor.org/rfc/rfc5770#section-4.2" class="relref">Section 4.2</a> of [<a href="#RFC5770" class="xref">RFC5770</a>]</span> if STUN servers are available, or if
      the host has just a single interface and no STUN or Data Relay Server
      are available.<a href="#section-4.2-7" class="pilcrow">¶</a></p>
<p id="section-4.2-8">Each local address candidate <span class="bcp14">MUST</span> be assigned a
 priority.  The following recommended formula (as described in <span>[<a href="#RFC8445" class="xref">RFC8445</a>]</span>) <span class="bcp14">SHOULD</span> be
 used:<a href="#section-4.2-8" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-4.2-9">
          priority = (2<sup>24</sup>)*(type preference) +
                      (2<sup>8</sup>)*(local preference) +
                      (2<sup>0</sup>)*(256 - component ID)<a href="#section-4.2-9" class="pilcrow">¶</a></p>
<p id="section-4.2-10">In the formula, the type preference follows the ICE specification
        (as defined in <span><a href="https://www.rfc-editor.org/rfc/rfc8445#section-5.1.2.1" class="relref">Section 5.1.2.1</a> of [<a href="#RFC8445" class="xref">RFC8445</a>]</span>): the <span class="bcp14">RECOMMENDED</span> values are 126
        for host candidates, 100 for server-reflexive candidates, 110 for
        peer-reflexive candidates, and 0 for relayed candidates.  The highest
        value is 126 (the most preferred) and lowest is 0 (last resort). For
        all candidates of the same type, the preference type value
        <span class="bcp14">MUST</span> be identical, and, correspondingly, the value
        <span class="bcp14">MUST</span> be different for different types. For
        peer-reflexive values, the type preference value <span class="bcp14">MUST</span>
        be higher than for server-reflexive types. It should be noted that
        peer-reflexive values are learned later during connectivity
        checks.<a href="#section-4.2-10" class="pilcrow">¶</a></p>
<p id="section-4.2-11">Following the ICE specification, the local preference
        <span class="bcp14">MUST</span> be an integer from 0 (lowest preference) to 65535
        (highest preference) inclusive. In the case the host has only a single
        address candidate, the value <span class="bcp14">SHOULD</span> be 65535. In the
        case of multiple candidates, each local preference value
        <span class="bcp14">MUST</span> be unique. Dual-stack considerations for IPv6 also
        apply here as defined in <span><a href="https://www.rfc-editor.org/rfc/rfc8445#section-5.1.2.2" class="relref">Section 5.1.2.2</a> of [<a href="#RFC8445" class="xref">RFC8445</a>]</span>.<a href="#section-4.2-11" class="pilcrow">¶</a></p>
<p id="section-4.2-12">Unlike with SDP used in conjunction with ICE, this protocol only
 creates a single UDP flow between the two communicating hosts, so only
 a single component exists. Hence, the component ID value
 <span class="bcp14">MUST</span> always be set to 1.<a href="#section-4.2-12" class="pilcrow">¶</a></p>
<p id="section-4.2-13">As defined in <span><a href="https://www.rfc-editor.org/rfc/rfc8445#section-14.3" class="relref">Section 14.3</a> of [<a href="#RFC8445" class="xref">RFC8445</a>]</span>, the retransmission timeout (RTO) for address
 gathering from a Control/Data Relay Server <span class="bcp14">SHOULD</span> be
 calculated as follows:<a href="#section-4.2-13" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-4.2-14">
          RTO = MAX (1000 ms, Ta * (Num-Of-Cands))<a href="#section-4.2-14" class="pilcrow">¶</a></p>
<p id="section-4.2-15">where Ta is the value used for the connectivity check pacing and
 Num-Of-Cands is the number of server-reflexive and relay candidates. A
 smaller value than 1000 ms for the RTO <span class="bcp14">MUST NOT</span> be
 used.<a href="#section-4.2-15" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec_nat_traversal_mode">
<section id="section-4.3">
        <h3 id="name-nat-traversal-mode-negotiat">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-nat-traversal-mode-negotiat" class="section-name selfRef">NAT Traversal Mode Negotiation</a>
        </h3>
<p id="section-4.3-1"> This section describes the usage of a non-critical parameter type
 called NAT_TRAVERSAL_MODE with a new mode called ICE-HIP-UDP. The
 presence of the new mode in the NAT_TRAVERSAL_MODE parameter in a HIP
 base exchange means that the end host supports NAT traversal
 extensions described in this document. As the parameter is
 non-critical (as defined in <span><a href="https://www.rfc-editor.org/rfc/rfc7401#section-5.2.1" class="relref">Section 5.2.1</a> of [<a href="#RFC7401" class="xref">RFC7401</a>]</span>), it can be ignored by an end host, which means that
 the host is not required to support it or may decline to use it.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<p id="section-4.3-2"> With registration with a Control/Data Relay Server, it is usually
 sufficient to use the UDP-ENCAPSULATION mode of NAT traversal since
 the Relay Server is assumed to be in public address space. Thus, the
 Relay Server <span class="bcp14">SHOULD</span> propose the UDP-ENCAPSULATION mode
 as the preferred or only mode.  The NAT traversal mode negotiation in
 a HIP base exchange is illustrated in <a href="#fig_nat_traversal_mode" class="xref">Figure 3</a>. It is worth noting
 that the Relay Server could be located between the hosts, but is
 omitted here for simplicity.<a href="#section-4.3-2" class="pilcrow">¶</a></p>
<span id="name-negotiation-of-nat-traversa"></span><div id="fig_nat_traversal_mode">
<figure id="figure-3">
          <div class="artwork art-text alignCenter" id="section-4.3-3.1">
<pre>
Initiator                                                  Responder
| 1. UDP(I1)                                                       |
+-----------------------------------------------------------------&gt;|
|                                                                  |
| 2. UDP(R1(.., NAT_TRAVERSAL_MODE(ICE-HIP-UDP), ..))              |
|&lt;-----------------------------------------------------------------+
|                                                                  |
| 3. UDP(I2(.., NAT_TRAVERSAL_MODE(ICE-HIP-UDP), ENC(LOC_SET), ..))|
+-----------------------------------------------------------------&gt;|
|                                                                  |
| 4. UDP(R2(.., ENC(LOC_SET), ..))                                 |
|&lt;-----------------------------------------------------------------+
|                                                                  |
</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-negotiation-of-nat-traversa" class="selfRef">Negotiation of NAT Traversal Mode</a>
          </figcaption></figure>
</div>
<p id="section-4.3-4"> In step 1, the Initiator sends an I1 to the Responder.<a href="#section-4.3-4" class="pilcrow">¶</a></p>
<p id="section-4.3-5">In step 2,
 the Responder responds with an R1. As specified in  <span>[<a href="#RFC5770" class="xref">RFC5770</a>]</span>, the NAT_TRAVERSAL_MODE parameter
 in R1 contains a list of NAT traversal modes the Responder
 supports. The mode specified in this document is ICE-HIP-UDP (value
 3).<a href="#section-4.3-5" class="pilcrow">¶</a></p>
<p id="section-4.3-6"> In step 3, the Initiator sends an I2 that includes a
 NAT_TRAVERSAL_MODE parameter. It contains the mode selected by the
 Initiator from the list of modes offered by the Responder. If
 ICE-HIP-UDP mode was selected, the I2 also includes the "Transport
 address" locators (as defined in <a href="#sec_locator_format" class="xref">Section 5.7</a>) of the Initiator in a LOCATOR_SET parameter
 (denoted here with LOC_SET). With ICE-HIP-UDP mode, the LOCATOR_SET
 parameter <span class="bcp14">MUST</span> be encapsulated within an ENCRYPTED
 parameter (denoted here with ENC) according to the procedures in
 Sections <a href="https://www.rfc-editor.org/rfc/rfc7401#section-5.2.18" class="relref">5.2.18</a> and <a href="https://www.rfc-editor.org/rfc/rfc7401#section-6.5" class="relref">6.5</a> in <span>[<a href="#RFC7401" class="xref">RFC7401</a>]</span>. The locators in I2 are the "HIP offer".<a href="#section-4.3-6" class="pilcrow">¶</a></p>
<p id="section-4.3-7"> In step 4, the Responder concludes the base exchange with an R2
 packet. If the Initiator chose ICE-HIP-UDP traversal mode, the
 Responder includes a LOCATOR_SET parameter in the R2 packet. With
 ICE-HIP-UDP mode, the LOCATOR_SET parameter <span class="bcp14">MUST</span> be
 encapsulated within an ENCRYPTED parameter according to the procedures
 in Sections <a href="https://www.rfc-editor.org/rfc/rfc7401#section-5.2.18" class="relref">5.2.18</a> and <a href="https://www.rfc-editor.org/rfc/rfc7401#section-6.5" class="relref">6.5</a> in <span>[<a href="#RFC7401" class="xref">RFC7401</a>]</span>. The locators in R2, encoded like the locators in
 I2, are the "ICE answer". If the NAT traversal mode selected by the
 Initiator is not supported by the Responder, the Responder
 <span class="bcp14">SHOULD</span> reply with a NOTIFY packet with type
 NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER and abort the base exchange.<a href="#section-4.3-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec_check_pacing_neg">
<section id="section-4.4">
        <h3 id="name-connectivity-check-pacing-n">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-connectivity-check-pacing-n" class="section-name selfRef">Connectivity Check Pacing Negotiation</a>
        </h3>
<p id="section-4.4-1"> As explained in Legacy ICE-HIP <span>[<a href="#RFC5770" class="xref">RFC5770</a>]</span>, when a NAT
        traversal mode with connectivity checks is used, new transactions
        should not be started too fast to avoid congestion and overwhelming the
        NATs. For this purpose, during the base exchange, hosts can negotiate a
        transaction pacing value, Ta, using a TRANSACTION_PACING parameter in
        R1 and I2 packets. The parameter contains the minimum time (expressed
        in milliseconds) the host would wait between two NAT traversal
        transactions, such as starting a new connectivity check or retrying a
        previous check. The value that is used by both of the hosts is the higher
        of the two offered values.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
<p id="section-4.4-2"> The minimum Ta value <span class="bcp14">SHOULD</span> be configurable, and if
 no value is configured, a value of 50 ms <span class="bcp14">MUST</span> be
 used. Guidelines for selecting a Ta value are given in <a href="#sec_selecting_pacing_value" class="xref">Appendix A</a>.  Hosts
 <span class="bcp14">MUST NOT</span> use values smaller than 5 ms for the minimum
 Ta, since such values may not work well with some NATs (as explained
 in <span>[<a href="#RFC8445" class="xref">RFC8445</a>]</span>). The Initiator
 <span class="bcp14">MUST NOT</span> propose a smaller value than what the
 Responder offered.  If a host does not include the TRANSACTION_PACING
 parameter in the base exchange, a Ta value of 50 ms
 <span class="bcp14">MUST</span> be used as that host's minimum value.<a href="#section-4.4-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec_relay_bex">
<section id="section-4.5">
        <h3 id="name-base-exchange-via-control-r">
<a href="#section-4.5" class="section-number selfRef">4.5. </a><a href="#name-base-exchange-via-control-r" class="section-name selfRef">Base Exchange via Control Relay Server</a>
        </h3>
<p id="section-4.5-1"> This section describes how the Initiator and Responder perform a
 base exchange through a Control Relay Server. Connectivity pacing
 (denoted as TA_P here) was described in <a href="#sec_check_pacing_neg" class="xref">Section 4.4</a> and is not repeated
 here.  Similarly, the NAT traversal mode negotiation process (denoted
 as NAT_TM in the example) was described in <a href="#sec_nat_traversal_mode" class="xref">Section 4.3</a> and is also not
 repeated here. If a Control Relay Server receives an R1 or I2 packet
 without the NAT traversal mode parameter, it <span class="bcp14">MUST</span> drop
 it and <span class="bcp14">SHOULD</span> send a NOTIFY error packet with type
 NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER to the sender of the R1 or
 I2.<a href="#section-4.5-1" class="pilcrow">¶</a></p>
<p id="section-4.5-2"> It is <span class="bcp14">RECOMMENDED</span> that the Initiator send an I1 packet
        encapsulated in UDP when it is destined to an IP address of the
        Responder. Respectively, the Responder <span class="bcp14">MUST</span> respond to such an I1
        packet with a UDP-encapsulated R1 packet, and also the rest of the communication
        related to the HIP association <span class="bcp14">MUST</span> also use UDP encapsulation.<a href="#section-4.5-2" class="pilcrow">¶</a></p>
<p id="section-4.5-3"><a href="#fig_bex" class="xref">Figure 4</a> illustrates a base
 exchange via a Control Relay Server. We assume that the Responder
 (i.e., a Control Relay Client) has already registered to the Control
 Relay Server. The Initiator may have also registered to another (or
 the same Control Relay Server), but the base exchange will traverse
 always through the Control Relay Server of the Responder.<a href="#section-4.5-3" class="pilcrow">¶</a></p>
<span id="name-base-exchange-via-a-hip-rel"></span><div id="fig_bex">
<figure id="figure-4">
          <div class="artwork art-text alignCenter" id="section-4.5-4.1">
<pre>
Initiator                  Control Relay Server             Responder
| 1. UDP(I1)                       |                                |
+---------------------------------&gt;| 2. UDP(I1(RELAY_FROM))         |
|                                  +-------------------------------&gt;|
|                                  |                                |
|                                  | 3. UDP(R1(RELAY_TO, NAT_TM,    |
|                                  |        TA_P))                  |
| 4. UDP(R1(RELAY_TO, NAT_TM,      |&lt;-------------------------------+
|        TA_P))                    |                                |
|&lt;---------------------------------+                                |
|                                  |                                |
| 5. UDP(I2(ENC(LOC_SET)),         |                                |
|        NAT_TM, TA_P))            |                                |
+---------------------------------&gt;| 6. UDP(I2(ENC(LOC_SET),        |
|                                  |      RELAY_FROM, NAT_TM, TA_P))|
|                                  +-------------------------------&gt;|
|                                  |                                |
|                                  | 7. UDP(R2(ENC(LOC_SET),        |
| 8. UDP(R2(ENC(LOC_SET),          |        RELAY_TO))              |
|        RELAY_TO))                |&lt;-------------------------------+
|&lt;---------------------------------+                                |
|                                  |                                |
</pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
<a href="#name-base-exchange-via-a-hip-rel" class="selfRef">Base Exchange via a HIP Relay Server</a>
          </figcaption></figure>
</div>
<p id="section-4.5-5"> In step 1 of <a href="#fig_bex" class="xref">Figure 4</a>, the
 Initiator sends an I1 packet over UDP via the Control Relay Server to
 the Responder. In the HIP header, the source HIT belongs to the
 Initiator and the destination HIT to the Responder. The Initiator
 sends the I1 packet from its IP address to the IP address of the
 Control Relay Server over UDP.<a href="#section-4.5-5" class="pilcrow">¶</a></p>
<p id="section-4.5-6"> In step 2, the Control Relay Server receives the I1 packet. If the 
        destination HIT belongs to a successfully registered Control Relay
 Client (i.e., the host marked "Responder" in <a href="#fig_bex" class="xref">Figure 4</a>), the Control Relay Server processes the
 packet. Otherwise, the Control Relay Server <span class="bcp14">MUST</span> drop
 the packet silently. The Control Relay Server appends a RELAY_FROM
 parameter to the I1 packet, which contains the transport source
 address and port of the I1 as observed by the Control Relay
 Server. The Control Relay Server protects the I1 packet with
 RELAY_HMAC, except that the parameter type is different as described
 in <a href="#sec_relay-hmac" class="xref">Section 5.8</a>. The Control Relay
 Server changes the source and destination ports and IP addresses of
 the packet to match the values the Responder used when registering to
 the Control Relay Server, i.e., the reverse of the R2 used in the
 registration. The Control Relay Server <span class="bcp14">MUST</span> recalculate
 the transport checksum and forward the packet to the Responder.<a href="#section-4.5-6" class="pilcrow">¶</a></p>
<p id="section-4.5-7"> In step 3, the Responder receives the I1 packet. The Responder
 processes it according to the rules in <span>[<a href="#RFC7401" class="xref">RFC7401</a>]</span>. In addition, the Responder validates the
 RELAY_HMAC according to <a href="#sec_relay-hmac" class="xref">Section 5.8</a> and silently drops the packet if the validation
 fails. The Responder replies with an R1 packet to which it includes
 RELAY_TO and NAT traversal mode parameters. The Responder
 <span class="bcp14">MUST</span> include ICE-HIP-UDP in the NAT traversal
 modes. The RELAY_TO parameter <span class="bcp14">MUST</span> contain the same
 information as the RELAY_FROM parameter, i.e., the Initiator's
 transport address, but the type of the parameter is different. The
 RELAY_TO parameter is not integrity protected by the signature of the
 R1 to allow pre-created R1 packets at the Responder.<a href="#section-4.5-7" class="pilcrow">¶</a></p>
<p id="section-4.5-8"> In step 4, the Control Relay Server receives the R1 packet. The
 Control Relay Server drops the packet silently if the source HIT
 belongs to a Control Relay Client that has not successfully
 registered. The Control Relay Server <span class="bcp14">MAY</span> verify the
 signature of the R1 packet and drop it if the signature is
 invalid. Otherwise, the Control Relay Server rewrites the source
 address and port, and changes the destination address and port to
 match RELAY_TO information. Finally, the Control Relay Server
 recalculates the transport checksum and forwards the packet.<a href="#section-4.5-8" class="pilcrow">¶</a></p>
<p id="section-4.5-9"> In step 5, the Initiator receives the R1 packet and processes it
        according to <span>[<a href="#RFC7401" class="xref">RFC7401</a>]</span>. The Initiator
        <span class="bcp14">MAY</span> use the address in the RELAY_TO parameter as a
        local peer-reflexive candidate for this HIP association if it is
        different from all known local candidates. The Initiator replies with
        an I2 packet that uses the destination transport address of R1 as the
        source address and port. The I2 packet contains a LOCATOR_SET
        parameter inside an ENCRYPTED parameter that lists all the HIP
        candidates (HIP offer) of the Initiator.  The candidates are encoded
        using the format defined in <a href="#sec_locator_format" class="xref">Section 5.7</a>. The I2 packet <span class="bcp14">MUST</span> also contain a
        NAT traversal mode parameter that includes ICE-HIP-UDP mode. The
        ENCRYPTED parameter along with its key material generation is
        described in detail in Sections <a href="https://www.rfc-editor.org/rfc/rfc7401#section-5.2.18" class="relref">5.2.18</a> and <a href="https://www.rfc-editor.org/rfc/rfc7401#section-6.5" class="relref">6.5</a> in <span>[<a href="#RFC7401" class="xref">RFC7401</a>]</span>.<a href="#section-4.5-9" class="pilcrow">¶</a></p>
<p id="section-4.5-10"> In step 6, the Control Relay Server receives the I2 packet. The
 Control Relay Server appends a RELAY_FROM and a RELAY_HMAC to the I2
 packet similar to that explained in step 2, and forwards the packet to
 the Responder.<a href="#section-4.5-10" class="pilcrow">¶</a></p>
<p id="section-4.5-11"> In step 7, the Responder receives the I2 packet and processes it
        according to <span>[<a href="#RFC7401" class="xref">RFC7401</a>]</span>. The Responder
        validates the RELAY_HMAC according to <a href="#sec_relay-hmac" class="xref">Section 5.8</a> and silently drops the packet if the validation
        fails. It replies with an R2 packet and includes a RELAY_TO parameter
        as explained in step 3. The R2 packet includes a LOCATOR_SET parameter
        inside an ENCRYPTED parameter that lists all the HIP candidates (ICE
        answer) of the Responder. The RELAY_TO parameter is protected by the
        Hashed Message Authentication Code (HMAC). The ENCRYPTED parameter
        along with its key material generation is described in detail in
        Sections <a href="https://www.rfc-editor.org/rfc/rfc7401#section-5.2.18" class="relref">5.2.18</a> and <a href="https://www.rfc-editor.org/rfc/rfc7401#section-6.5" class="relref">6.5</a> in <span>[<a href="#RFC7401" class="xref">RFC7401</a>]</span>.<a href="#section-4.5-11" class="pilcrow">¶</a></p>
<p id="section-4.5-12"> In step 8, the Control Relay Server processes the R2 as described
 in step 4. The Control Relay Server forwards the packet to the
 Initiator. After the Initiator has received the R2 and processed it
 successfully, the base exchange is completed.<a href="#section-4.5-12" class="pilcrow">¶</a></p>
<p id="section-4.5-13"> Hosts <span class="bcp14">MUST</span> include the address of one or more
 Control Relay Servers (including the one that is being used for the
 initial signaling) in the LOCATOR_SET parameter in I2 and R2 messages
 if they intend to use such servers for relaying HIP signaling
 immediately after the base exchange completes. The traffic type of
 these addresses <span class="bcp14">MUST</span> be "HIP signaling" (see <a href="#sec_locator_format" class="xref">Section 5.7</a>) and they <span class="bcp14">MUST NOT</span> be used for the connectivity tests described in <a href="#sec_conn_checks" class="xref">Section 4.6</a>.  If the Control Relay
 Server locator used for relaying the base exchange is not included in
 I2 or R2 LOCATOR_SET parameters, it <span class="bcp14">SHOULD NOT</span> be used
 after the base exchange. Instead, further HIP signaling
 <span class="bcp14">SHOULD</span> use the same path as the data traffic. It is
 <span class="bcp14">RECOMMENDED</span> to use the same Control Relay Server
 throughout the lifetime of the host association that was used for
 forwarding the base exchange if the Responder includes it in the
 locator parameter of the R2 message.<a href="#section-4.5-13" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec_conn_checks">
<section id="section-4.6">
        <h3 id="name-connectivity-checks">
<a href="#section-4.6" class="section-number selfRef">4.6. </a><a href="#name-connectivity-checks" class="section-name selfRef">Connectivity Checks</a>
        </h3>
<p id="section-4.6-1">When the Initiator and Responder complete the base exchange through
        the Control Relay Server, both of them employ the IP address of the
        Control Relay Server as the destination address for the packets. The
        address of the Control Relay Server <span class="bcp14">MUST NOT</span> be used as
        a destination for data plane traffic unless the server also supports
        Data Relay Server functionality, and the Client has successfully
        registered to use it. When NAT traversal mode with ICE-HIP-UDP was
        successfully negotiated and selected, the Initiator and Responder
        <span class="bcp14">MUST</span> start the connectivity checks in order to attempt
        to obtain direct end-to-end connectivity through NAT devices. It is
        worth noting that the connectivity checks <span class="bcp14">MUST</span> be
        completed even though no ESP_TRANSFORM would be negotiated and
        selected.<a href="#section-4.6-1" class="pilcrow">¶</a></p>
<p id="section-4.6-2">The connectivity checks follow the ICE methodology <span>[<a href="#I-D.rosenberg-mmusic-ice-nonsip" class="xref">ICE-NONSIP</a>]</span>, but
        UDP-encapsulated HIP control messages are used instead of ICE
        messages. As stated in the ICE specification, the basic procedure for
        connectivity checks has three phases: sorting the candidate pairs
        according to their priority, sending checks in the prioritized order,
        and acknowledging the checks from the peer host.<a href="#section-4.6-2" class="pilcrow">¶</a></p>
<p id="section-4.6-3">The Initiator <span class="bcp14">MUST</span> take the role of controlling
        host, and the Responder acts as the controlled host. The roles
        <span class="bcp14">MUST</span> persist throughout the HIP associate lifetime (to
        be reused even during mobility UPDATE procedures).  In the case in
        which both communicating nodes are initiating communication to
        each other using an I1 packet, the conflict is resolved as defined in
        <span><a href="https://www.rfc-editor.org/rfc/rfc7401#section-6.7" class="relref">Section 6.7</a> of [<a href="#RFC7401" class="xref">RFC7401</a>]</span>; the host
        with the "larger" HIT changes its role to Responder. In such a
        case, the host changing its role to Responder <span class="bcp14">MUST</span> also
        switch to the controlled role.<a href="#section-4.6-3" class="pilcrow">¶</a></p>
<p id="section-4.6-4">The protocol follows standard HIP UPDATE sending and processing
        rules as defined in Sections <a href="https://www.rfc-editor.org/rfc/rfc7401#section-6.11" class="relref">6.11</a> and <a href="https://www.rfc-editor.org/rfc/rfc7401#section-6.12" class="relref">6.12</a> in <span>[<a href="#RFC7401" class="xref">RFC7401</a>]</span>,
        but some new parameters are introduced (CANDIDATE_PRIORITY,
        MAPPED_ADDRESS, NOMINATE, PEER_PERMISSION, and RELAYED_ADDRESS).<a href="#section-4.6-4" class="pilcrow">¶</a></p>
<div id="sec_conn_check_proc">
<section id="section-4.6.1">
          <h4 id="name-connectivity-check-procedur">
<a href="#section-4.6.1" class="section-number selfRef">4.6.1. </a><a href="#name-connectivity-check-procedur" class="section-name selfRef">Connectivity Check Procedure</a>
          </h4>
<p id="section-4.6.1-1"><a href="#fig_cc1" class="xref">Figure 5</a> illustrates connectivity checks
          in a simplified scenario where the Initiator and Responder
          have only a single candidate pair to check. Typically, NATs
          drop messages until both sides have sent messages using the
          same port pair. In this scenario, the Responder sends a
          connectivity check first but the NAT of the Initiator drops
          it. However, the connectivity check from the Initiator
          reaches the Responder because it uses the same port pair as
          the first message. It is worth noting that the message flow
          in this section is idealistic, and, in practice, more
          messages would be dropped, especially in the beginning. For
          instance, connectivity tests always start with the
          candidates with the highest priority, which would be host
          candidates (which would not reach the recipient in this
          scenario).<a href="#section-4.6.1-1" class="pilcrow">¶</a></p>
<span id="name-connectivity-checks-2"></span><div id="fig_cc1">
<figure id="figure-5">
            <div class="artwork art-text alignCenter" id="section-4.6.1-2.1">
<pre>
Initiator  NAT1                                 NAT2        Responder
|             | 1. UDP(UPDATE(SEQ, CAND_PRIO,      |                |
|             |        ECHO_REQ_SIGN))             |                |
|             X&lt;-----------------------------------+----------------+
|             |                                    |                |
| 2. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO))    |                |
+-------------+------------------------------------+---------------&gt;|
|             |                                    |                |
| 3. UDP(UPDATE(ACK, ECHO_RESP_SIGN, MAPPED_ADDR)) |                |
|&lt;------------+------------------------------------+----------------+
|             |                                    |                |
| 4. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO))    |                |
|&lt;------------+------------------------------------+----------------+
|             |                                    |                |
| 5. UDP(UPDATE(ACK, ECHO_RESP_SIGN, MAPPED_ADDR)) |                |
+-------------+------------------------------------+---------------&gt;|
|             |                                    |                |
| 6. Other connectivity checks using UPDATE over UDP                |
|&lt;------------+------------------------------------+----------------&gt;
|             |                                    |                |
| 7. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO, NOMINATE))           |
+-------------+------------------------------------+---------------&gt;|
|             |                                    |                |
| 8. UDP(UPDATE(SEQ, ACK, ECHO_REQ_SIGN, ECHO_RESP_SIGN,            |
|           NOMINATE))                             |                |
|&lt;------------+------------------------------------+----------------+
|             |                                    |                |
| 9. UDP(UPDATE(ACK, ECHO_RESP_SIGN))              |                |
+-------------+------------------------------------+---------------&gt;+
|             |                                    |                |
| 10. ESP data traffic over UDP                     |               |
+&lt;------------+------------------------------------+---------------&gt;+
|             |                                    |                |
</pre>
</div>
<figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
<a href="#name-connectivity-checks-2" class="selfRef">Connectivity Checks</a>
            </figcaption></figure>
</div>
<p id="section-4.6.1-3">In step 1, the Responder sends a connectivity check to the
          Initiator that the NAT of the Initiator drops. The message includes
   a number of parameters. As specified in <span>[<a href="#RFC7401" class="xref">RFC7401</a>]</span>, the SEQ parameter includes a running sequence
   identifier for the connectivity check. The candidate priority
   (denoted CAND_PRIO in the figure) describes the priority of the
   address candidate being tested. The ECHO_REQUEST_SIGNED (denoted
   ECHO_REQ_SIGN in the figure) includes a nonce that the recipient
   must sign and echo back as it is.<a href="#section-4.6.1-3" class="pilcrow">¶</a></p>
<p id="section-4.6.1-4">In step 2, the Initiator sends a connectivity check, using
          the same address pair candidate as in the previous step, and the
          message successfully traverses the NAT boxes. The message
          includes the same parameters as in the previous step. It
          should be noted that the sequence identifier is locally
          assigned by the Initiator, so it can be different than in
          the previous step.<a href="#section-4.6.1-4" class="pilcrow">¶</a></p>
<p id="section-4.6.1-5">In step 3, the Responder has successfully received the previous
          connectivity check from the Initiator and starts to build a response
          message. Since the message from the Initiator included a SEQ, the
          Responder must acknowledge it using an ACK parameter. Also, the
          nonce contained in the echo request must be echoed back in an
          ECHO_RESPONSE_SIGNED (denoted ECHO_RESP_SIGN) parameter. The
          Responder also includes a MAPPED_ADDRESS parameter (denoted
          MAPPED_ADDR in the figure) that contains the transport address of
          the Initiator as observed by the Responder (i.e., peer-reflexive
          candidate). This message is successfully delivered to the Initiator;
          upon reception, the Initiator marks the candidate pair as valid.<a href="#section-4.6.1-5" class="pilcrow">¶</a></p>
<p id="section-4.6.1-6">In step 4, the Responder retransmits the connectivity
          check sent in the first step, since it was not acknowledged
          yet.<a href="#section-4.6.1-6" class="pilcrow">¶</a></p>
<p id="section-4.6.1-7">In step 5, the Initiator responds to the previous
          connectivity check message from the Responder. The Initiator
          acknowledges the SEQ parameter from the previous message
          using an ACK parameter and the ECHO_REQUEST_SIGNED parameter with
          ECHO_RESPONSE_SIGNED. In addition, it includes the MAPPED_ADDR
          parameter that includes the peer-reflexive candidate. This
          response message is successfully delivered to the
          Responder; upon reception, the Initiator marks the candidate pair as valid.<a href="#section-4.6.1-7" class="pilcrow">¶</a></p>
<p id="section-4.6.1-8">In step 6, despite the two hosts now having valid address
   candidates, the hosts still test the remaining address candidates
   in a similar way as in the previous steps. It should be noted that each
   connectivity check has a unique sequence number in the SEQ
   parameter.<a href="#section-4.6.1-8" class="pilcrow">¶</a></p>
<p id="section-4.6.1-9">In step 7, the Initiator has completed testing all
          address candidates and nominates one address candidate to be
          used. It sends an UPDATE message using the selected address
          candidates that includes a number of parameters: SEQ,
          ECHO_REQUEST_SIGNED, CANDIDATE_PRIORITY, and the NOMINATE parameter.<a href="#section-4.6.1-9" class="pilcrow">¶</a></p>
<p id="section-4.6.1-10">In step 8, the Responder receives the message with the NOMINATE
          parameter from the Initiator. It sends a response that includes the
          NOMINATE parameter in addition to a number of other parameters. The
          ACK and ECHO_RESPONSE_SIGNED parameters acknowledge the SEQ and
          ECHO_REQUEST_SIGNED parameters from the previous message from the
          Initiator. The Responder includes SEQ and ECHO_REQUEST_SIGNED
          parameters in order to receive an acknowledgment from the
          Responder.<a href="#section-4.6.1-10" class="pilcrow">¶</a></p>
<p id="section-4.6.1-11">In step 9, the Initiator completes the candidate
          nomination process by confirming the message reception to
          the Responder. In the confirmation message, the ACK and
          ECHO_RESPONSE_SIGNED parameters correspond to the SEQ and
          ECHO_REQUEST_SIGNED parameters in the message sent by the
          Responder in the previous step.<a href="#section-4.6.1-11" class="pilcrow">¶</a></p>
<p id="section-4.6.1-12">In step 10, the Initiator and Responder can start sending
          application payload over the successfully nominated address
          candidates.<a href="#section-4.6.1-12" class="pilcrow">¶</a></p>
<p id="section-4.6.1-13">It is worth noting that if either host has registered a relayed
   address candidate from a Data Relay Server, the host
   <span class="bcp14">MUST</span> activate the address before connectivity checks
   by sending an UPDATE message containing the PEER_PERMISSION parameter as
   described in <a href="#sec_forwarding" class="xref">Section 4.12.1</a>. Otherwise, the Data Relay Server drops ESP
   packets using the relayed address.<a href="#section-4.6.1-13" class="pilcrow">¶</a></p>
<p id="section-4.6.1-14">It should be noted that in the case in which both the Initiator and
   Responder are advertising their own relayed address
   candidates, it is possible that the two hosts choose the two
   relayed addresses as a result of the ICE nomination
   algorithm. While this is possible (and even could be
   desirable for privacy reasons), it can be unlikely due to
   low priority assigned for the relayed address candidates. In
   such an event, the nominated address pair is always
   symmetric; the nomination algorithm prevents asymmetric
   address pairs (i.e., each side choosing different pair) such
   as a Data Relay Client using its own Data Relay Server to
   send data directly to its peer while receiving data from the
   Data Relay Server of its peer.<a href="#section-4.6.1-14" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-4.6.2">
          <h4 id="name-rules-for-connectivity-chec">
<a href="#section-4.6.2" class="section-number selfRef">4.6.2. </a><a href="#name-rules-for-connectivity-chec" class="section-name selfRef">Rules for Connectivity Checks</a>
          </h4>
<p id="section-4.6.2-1">The HITs of the two communicating hosts <span class="bcp14">MUST</span> be
   used as credentials in this protocol (in contrast to ICE, which
   employs username-password fragments). A HIT pair uniquely identifies
   the corresponding HIT association, and a SEQ number in an UPDATE
   message identifies a particular connectivity check.<a href="#section-4.6.2-1" class="pilcrow">¶</a></p>
<p id="section-4.6.2-2">All of the connectivity check messages <span class="bcp14">MUST</span> be
          protected with HIP_HMAC and signatures (even though the
          illustrations in this specification omit them for simplicity)
          according to <span>[<a href="#RFC7401" class="xref">RFC7401</a>]</span>. Each
          connectivity check sent by a host <span class="bcp14">MUST</span> include a SEQ
          parameter and ECHO_REQUEST_SIGNED parameter; correspondingly, the
          peer <span class="bcp14">MUST</span> respond to these using ACK and
          ECHO_RESPONSE_SIGNED according to the rules specified in <span>[<a href="#RFC7401" class="xref">RFC7401</a>]</span>.<a href="#section-4.6.2-2" class="pilcrow">¶</a></p>
<p id="section-4.6.2-3">The host sending a connectivity check <span class="bcp14">MUST</span> validate that
   the response uses the same pair of UDP ports, and drop the
   packet if this is not the case.<a href="#section-4.6.2-3" class="pilcrow">¶</a></p>
<p id="section-4.6.2-4">A host may receive a connectivity check before it has received
   the candidates from its peer. In such a case, the host
   <span class="bcp14">MUST</span> immediately queue a response by placing it in
   the triggered-check queue and then continue waiting for the
   candidates. A host <span class="bcp14">MUST NOT</span> select a candidate pair
   until it has verified the pair using a connectivity check as defined
   in <a href="#sec_conn_check_proc" class="xref">Section 4.6.1</a>.<a href="#section-4.6.2-4" class="pilcrow">¶</a></p>
<p id="section-4.6.2-5"><span><a href="https://www.rfc-editor.org/rfc/rfc7401#section-5.3.5" class="relref">Section 5.3.5</a> of [<a href="#RFC7401" class="xref">RFC7401</a>]</span>
   states that UPDATE packets have to include either a SEQ or ACK
   parameter (but can include both). In the connectivity check
   procedure specified in <a href="#sec_conn_check_proc" class="xref">Section 4.6.1</a>, each SEQ parameter should be acknowledged
   separately. In the context of NATs, this means that some of the SEQ
   parameters sent in connectivity checks will be lost or arrive out of
   order. From the viewpoint of the recipient, this is not a problem
   since the recipient will just "blindly" acknowledge the
   SEQ. However, the sender needs to be prepared for lost sequence
   identifiers and ACK parameters that arrive out of order.<a href="#section-4.6.2-5" class="pilcrow">¶</a></p>
<p id="section-4.6.2-6">As specified in <span>[<a href="#RFC7401" class="xref">RFC7401</a>]</span>, an ACK
          parameter may acknowledge multiple sequence
          identifiers. While the examples in the previous sections do
          not illustrate such functionality, it is also permitted when
          employing ICE-HIP-UDP mode.<a href="#section-4.6.2-6" class="pilcrow">¶</a></p>
<p id="section-4.6.2-7">In ICE-HIP-UDP mode, a retransmission of a connectivity check
          <span class="bcp14">SHOULD</span> be sent with the same sequence identifier in
          the SEQ parameter. Some tested address candidates will never produce
          a working address pair and may thus cause retransmissions. Upon
          successful nomination of an address pair, a host
          <span class="bcp14">SHOULD</span> immediately stop sending such
          retransmissions.<a href="#section-4.6.2-7" class="pilcrow">¶</a></p>
<p id="section-4.6.2-8">Full ICE procedures for prioritizing candidates, eliminating
   redundant candidates, forming checklists (including pruning), and
   triggered-check queues <span class="bcp14">MUST</span> be followed as specified
   in <span><a href="https://www.rfc-editor.org/rfc/rfc8445#section-6.1" class="relref">Section 6.1</a> of [<a href="#RFC8445" class="xref">RFC8445</a>]</span>, with
   the exception being that the foundation, frozen candidates, and
   default candidates are not used. From the viewpoint of the ICE
   specification <span>[<a href="#RFC8445" class="xref">RFC8445</a>]</span>, the
   protocol specified in this document operates using a component ID of
   1 on all candidates, and the foundation of all candidates is
   unique. This specification defines only "full ICE" mode, and the
   "lite ICE" is not supported. The reasoning behind the missing
   features is described in <a href="#sec_ice_diff" class="xref">Appendix B</a>.<a href="#section-4.6.2-8" class="pilcrow">¶</a></p>
<p id="section-4.6.2-9"> The connectivity check messages <span class="bcp14">MUST</span> be paced by
   the Ta value negotiated during the base exchange as described in
   <a href="#sec_check_pacing_neg" class="xref">Section 4.4</a>. If neither
   one of the hosts announced a minimum pacing value, a value of 50 ms
   <span class="bcp14">MUST</span> be used.<a href="#section-4.6.2-9" class="pilcrow">¶</a></p>
<p id="section-4.6.2-10">Both hosts <span class="bcp14">MUST</span> form a
          priority ordered checklist and begin to check transactions every Ta
          milliseconds as long as the checks are running and there are candidate
          pairs whose tests have not started. The retransmission timeout (RTO)
          for the connectivity check UPDATE packets <span class="bcp14">SHOULD</span> be
   calculated as follows:<a href="#section-4.6.2-10" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-4.6.2-11">
            RTO = MAX (1000 ms, Ta * (Num-Waiting + Num-In-Progress))<a href="#section-4.6.2-11" class="pilcrow">¶</a></p>
<p id="section-4.6.2-12"> In the RTO formula, Ta is the value used for the connectivity
   check pacing, Num-Waiting is the number of pairs in the checklist in
   the "Waiting" state, and Num-In-Progress is the number of pairs in
   the "In-Progress" state. This is identical to the formula in <span>[<a href="#RFC8445" class="xref">RFC8445</a>]</span> when there is only one
   checklist. A smaller value than 1000 ms for the RTO <span class="bcp14">MUST NOT</span> be used.<a href="#section-4.6.2-12" class="pilcrow">¶</a></p>
<p id="section-4.6.2-13"> Each connectivity check request packet <span class="bcp14">MUST</span> contain a
          CANDIDATE_PRIORITY parameter (see <a href="#sec_con-check" class="xref">Section 5.14</a>) with
          the priority value that would be assigned to a peer-reflexive candidate
          if one was learned from the corresponding check. An UPDATE packet that acknowledges
          a connectivity check request <span class="bcp14">MUST</span> be sent from the same address that
          received the check and delivered to the same address where the check was received
          from. Each acknowledgment UPDATE packet <span class="bcp14">MUST</span> contain a MAPPED_ADDRESS
          parameter with the port, protocol, and IP address of the address where
          the connectivity check request was received from.<a href="#section-4.6.2-13" class="pilcrow">¶</a></p>
<p id="section-4.6.2-14">Following the ICE guidelines <span>[<a href="#RFC8445" class="xref">RFC8445</a>]</span>, it is <span class="bcp14">RECOMMENDED</span> to restrict the
   total number of connectivity checks to 100 for each host
   association. This can be achieved by limiting the connectivity
   checks to the 100 candidate pairs with the highest priority.<a href="#section-4.6.2-14" class="pilcrow">¶</a></p>
</section>
<section id="section-4.6.3">
          <h4 id="name-rules-for-concluding-connec">
<a href="#section-4.6.3" class="section-number selfRef">4.6.3. </a><a href="#name-rules-for-concluding-connec" class="section-name selfRef">Rules for Concluding Connectivity Checks</a>
          </h4>
<p id="section-4.6.3-1">The controlling agent may find multiple working candidate
          pairs. To conclude the connectivity checks, it <span class="bcp14">SHOULD</span>
          nominate the pair with the highest priority. The controlling agent
          <span class="bcp14">MUST</span> nominate a candidate pair essentially by
          repeating a connectivity check using an UPDATE message that contains
          a SEQ parameter (with a new sequence number), an ECHO_REQUEST_SIGNED
          parameter, the priority of the candidate in a CANDIDATE_PRIORITY
          parameter, and a NOMINATE parameter to signify conclusion of the
          connectivity checks. Since the nominated address pair has already
          been tested for reachability, the controlled host should be able to
          receive the message. Upon reception, the controlled host
          <span class="bcp14">SHOULD</span> select the nominated address pair. The
          response message <span class="bcp14">MUST</span> include a SEQ parameter with a
          new sequence identifier, acknowledgment of the sequence from the controlling
          host in an ACK parameter, a new ECHO_REQUEST_SIGNED parameter,
          an ECHO_RESPONSE_SIGNED parameter corresponding to the
          ECHO_REQUEST_SIGNED parameter from the controlling host, and the
          NOMINATE parameter. After sending this packet, the controlled host
          can create IPsec security associations using the nominated address
          candidate for delivering application payload to the controlling
          host. Since the message from the controlled host included a new
          sequence identifier echo request for the signature, the controlling host
          <span class="bcp14">MUST</span> acknowledge this with a new UPDATE message that
          includes an ACK and ECHO_RESPONSE_SIGNED parameters. After this
          final concluding message, the controlling host also can create IPsec
          security associations for delivering application payload to the
          controlled host.<a href="#section-4.6.3-1" class="pilcrow">¶</a></p>
<p id="section-4.6.3-2">It is possible that packets are delayed by the network. Both
   hosts <span class="bcp14">MUST</span> continue to respond to any connectivity
   checks despite an address pair having been nominated.<a href="#section-4.6.3-2" class="pilcrow">¶</a></p>
<p id="section-4.6.3-3"> If all the connectivity checks have failed, the hosts
   <span class="bcp14">MUST NOT</span> send ESP traffic to each other but
   <span class="bcp14">MAY</span> continue communicating using HIP packets and the
   locators used for the base exchange. Also, the hosts
   <span class="bcp14">SHOULD</span> notify each other about the failure with a
   CONNECTIVITY_CHECKS_FAILED NOTIFY packet (see <a href="#sec_notify-types" class="xref">Section 5.10</a>).<a href="#section-4.6.3-3" class="pilcrow">¶</a></p>
</section>
</section>
</div>
<div id="sec_alternatives">
<section id="section-4.7">
        <h3 id="name-nat-traversal-optimizations">
<a href="#section-4.7" class="section-number selfRef">4.7. </a><a href="#name-nat-traversal-optimizations" class="section-name selfRef">NAT Traversal Optimizations</a>
        </h3>
<div id="sec_minimal">
<section id="section-4.7.1">
          <h4 id="name-minimal-nat-traversal-suppo">
<a href="#section-4.7.1" class="section-number selfRef">4.7.1. </a><a href="#name-minimal-nat-traversal-suppo" class="section-name selfRef">Minimal NAT Traversal Support</a>
          </h4>
<p id="section-4.7.1-1">If the Responder has a fixed and publicly reachable IPv4
          address and does not employ a Control Relay Server, the explicit NAT
          traversal mode negotiation <span class="bcp14">MAY</span> be omitted; thus, even the
          UDP-ENCAPSULATION mode does not have to be negotiated. In
          such a scenario, the Initiator sends an I1 message over UDP
          and the Responder responds with an R1 message over UDP without
          including any NAT traversal mode parameter. The rest of the
          base exchange follows the procedures defined in <span>[<a href="#RFC7401" class="xref">RFC7401</a>]</span>, except that the control and
   data plane use UDP encapsulation. Here, the use of UDP for NAT
          traversal is agreed upon implicitly. This way of operation is still
   subject to NAT timeouts, and the hosts <span class="bcp14">MUST</span> employ
   NAT keepalives as defined in <a href="#sec_nat-keepalives" class="xref">Section 4.10</a>.<a href="#section-4.7.1-1" class="pilcrow">¶</a></p>
<p id="section-4.7.1-2">When UDP-ENCAPSULATION mode is chosen either explicitly or
   implicitly, the connectivity checks as defined in this document
   <span class="bcp14">MUST NOT</span> be used. When hosts lose connectivity, they
   <span class="bcp14">MUST</span> instead utilize <span>[<a href="#RFC8046" class="xref">RFC8046</a>]</span> or <span>[<a href="#RFC8047" class="xref">RFC8047</a>]</span>
   procedures, but with the difference being that UDP-based tunneling
   <span class="bcp14">MUST</span> be employed for the entire lifetime of the
   corresponding HIP association.<a href="#section-4.7.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec_no_relay">
<section id="section-4.7.2">
          <h4 id="name-base-exchange-without-conne">
<a href="#section-4.7.2" class="section-number selfRef">4.7.2. </a><a href="#name-base-exchange-without-conne" class="section-name selfRef">Base Exchange without Connectivity Checks</a>
          </h4>
<p id="section-4.7.2-1">It is possible to run a base exchange without any connectivity
          checks as defined in Legacy ICE-HIP (<span><a href="https://www.rfc-editor.org/rfc/rfc5770#section-4.8" class="relref">Section 4.8</a> of [<a href="#RFC5770" class="xref">RFC5770</a>]</span>). The procedure is also applicable
          in the context of this specification, so it is repeated here for
          completeness.<a href="#section-4.7.2-1" class="pilcrow">¶</a></p>
<p id="section-4.7.2-2"> In certain network environments, the connectivity checks can be
          omitted to reduce initial connection setup latency because a base
          exchange acts as an implicit connectivity test itself. For this to
          work, the Initiator <span class="bcp14">MUST</span> be able to reach the Responder by simply UDP
          encapsulating HIP and ESP packets sent to the Responder's address.
          Detecting and configuring this particular scenario is prone to failure
          unless carefully planned.<a href="#section-4.7.2-2" class="pilcrow">¶</a></p>
<p id="section-4.7.2-3"> In such a scenario, the Responder <span class="bcp14">MAY</span> include
   UDP-ENCAPSULATION NAT traversal mode as one of the supported modes
   in the R1 packet. If the Responder has registered to a Control Relay
   Server in order to discover its address candidates, it
   <span class="bcp14">MUST</span> also include a LOCATOR_SET parameter
   encapsulated inside an ENCRYPTED parameter in an R1 message that
   contains a preferred address where the Responder is able to receive
   UDP-encapsulated ESP and HIP packets. This locator
   <span class="bcp14">MUST</span> be of type "Transport address", its Traffic type
   <span class="bcp14">MUST</span> be "both", and it <span class="bcp14">MUST</span> have the
   "Preferred bit" set (see <a href="#tbl_locator" class="xref">Table 2</a>). If there is no such locator in R1, the
   Initiator <span class="bcp14">MUST</span> use the source address of the R1 as
   the Responder's preferred address.<a href="#section-4.7.2-3" class="pilcrow">¶</a></p>
<p id="section-4.7.2-4"> The Initiator <span class="bcp14">MAY</span> choose the UDP-ENCAPSULATION
   mode if the Responder listed it in the supported modes and the
   Initiator does not wish to use the connectivity checks defined in
   this document for searching for a more optimal path. In this case,
   the Initiator sends the I2 with UDP-ENCAPSULATION mode in the NAT
   traversal mode parameter directly to the Responder's preferred
   address (i.e., to the preferred locator in R1 or to the address
   where R1 was received from if there was no preferred locator in
   R1). The Initiator <span class="bcp14">MAY</span> include locators in I2 but
   they <span class="bcp14">MUST NOT</span> be taken as address candidates, since
   connectivity checks defined in this document will not be used for
   connections with UDP-ENCAPSULATION NAT traversal mode. Instead, if
   R2 and I2 are received and processed successfully, a security
   association can be created and UDP-encapsulated ESP can be exchanged
   between the hosts after the base exchange completes according to the
   rules in <span><a href="https://www.rfc-editor.org/rfc/rfc7401#section-4.4" class="relref">Section 4.4</a> of [<a href="#RFC7401" class="xref">RFC7401</a>]</span>.<a href="#section-4.7.2-4" class="pilcrow">¶</a></p>
<p id="section-4.7.2-5">The Control Relay Server can be used for discovering address
   candidates but it is not intended to be used for relaying end-host
   packets using the UDP-ENCAPSULATION NAT mode. Since an I2 packet
   with UDP-ENCAPSULATION NAT traversal mode selected <span class="bcp14">MUST NOT</span> be sent via a Control Relay Server, the Responder
   <span class="bcp14">SHOULD</span> reject such I2 packets and reply with a
   NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER NOTIFY packet (see <a href="#sec_notify-types" class="xref">Section 5.10</a>).<a href="#section-4.7.2-5" class="pilcrow">¶</a></p>
<p id="section-4.7.2-6"> If there is no answer for the I2 packet sent directly to the
   Responder's preferred address, the Initiator <span class="bcp14">MAY</span> send
   another I2 via the Control Relay Server, but it <span class="bcp14">MUST NOT</span> choose UDP-ENCAPSULATION NAT traversal mode for that
   I2.<a href="#section-4.7.2-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec_no_udp">
<section id="section-4.7.3">
          <h4 id="name-initiating-a-base-exchange-">
<a href="#section-4.7.3" class="section-number selfRef">4.7.3. </a><a href="#name-initiating-a-base-exchange-" class="section-name selfRef">Initiating a Base Exchange Both with and without UDP Encapsulation</a>
          </h4>
<p id="section-4.7.3-1">It is possible to run a base exchange in parallel both with and
   without UDP encapsulation as defined in Legacy ICE-HIP (<span><a href="https://www.rfc-editor.org/rfc/rfc5770#section-4.9" class="relref">Section 4.9</a> of [<a href="#RFC5770" class="xref">RFC5770</a>]</span>). The procedure
   is also applicable in the context of this specification, so it is
   repeated here for completeness.<a href="#section-4.7.3-1" class="pilcrow">¶</a></p>
<p id="section-4.7.3-2">The Initiator <span class="bcp14">MAY</span> also try to simultaneously
          perform a base exchange with the Responder without UDP
          encapsulation. In such a case, the Initiator sends two I1 packets,
          one without and one with UDP encapsulation, to the Responder. The
          Initiator <span class="bcp14">MAY</span> wait for a while before sending the
          other I1. How long to wait and in which order to send the I1 packets
          can be decided based on local policy.  For retransmissions, the
          procedure is repeated.<a href="#section-4.7.3-2" class="pilcrow">¶</a></p>
<p id="section-4.7.3-3">The I1 packet without UDP encapsulation may arrive directly,
          without passing a Control Relay Server, at the Responder. When
          this happens, the procedures in <span>[<a href="#RFC7401" class="xref">RFC7401</a>]</span> are followed for the rest of the base
          exchange. The Initiator may receive multiple R1 packets, with and
          without UDP encapsulation, from the Responder. However, after
          receiving a valid R1 and answering it with an I2, further R1 packets
          that are not retransmissions of the R1 message received first
          <span class="bcp14">MUST</span> be ignored.<a href="#section-4.7.3-3" class="pilcrow">¶</a></p>
<p id="section-4.7.3-4">The I1 packet without UDP encapsulation may also arrive at a
          HIP-capable middlebox. When the middlebox is a HIP Rendezvous Server
          and the Responder has successfully registered with the rendezvous
          service, the middlebox follows rendezvous procedures in <span>[<a href="#RFC8004" class="xref">RFC8004</a>]</span>.<a href="#section-4.7.3-4" class="pilcrow">¶</a></p>
<p id="section-4.7.3-5">If the Initiator receives a NAT traversal mode parameter in R1
   without UDP encapsulation, the Initiator <span class="bcp14">MAY</span> ignore
   this parameter and send an I2 without UDP encapsulation and without
   any selected NAT traversal mode. When the Responder receives the I2
   without UDP encapsulation and without NAT traversal mode, it will
   assume that no NAT traversal mechanism is needed. The packet
   processing will be done as described in <span>[<a href="#RFC7401" class="xref">RFC7401</a>]</span>. The Initiator <span class="bcp14">MAY</span> store the NAT
   traversal modes for future use, e.g., in case of a mobility or
   multihoming event that causes NAT traversal to be used during the
   lifetime of the HIP association.<a href="#section-4.7.3-5" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sec_control_no_relay">
<section id="section-4.8">
        <h3 id="name-sending-control-packets-aft">
<a href="#section-4.8" class="section-number selfRef">4.8. </a><a href="#name-sending-control-packets-aft" class="section-name selfRef">Sending Control Packets after the Base Exchange</a>
        </h3>
<p id="section-4.8-1">The same considerations with regard to sending control packets after the base
 exchange as described in Legacy ICE-HIP (<span><a href="https://www.rfc-editor.org/rfc/rfc5770#section-5.10" class="relref">Section 5.10</a> of [<a href="#RFC5770" class="xref">RFC5770</a>]</span>) also apply here, so they are
 repeated here for completeness.<a href="#section-4.8-1" class="pilcrow">¶</a></p>
<p id="section-4.8-2">After the base exchange, the two end hosts <span class="bcp14">MAY</span> send
        HIP control packets directly to each other using the transport address
        pair established for a data channel without sending the control
        packets through any Control Relay Servers. When a host does not
        receive acknowledgments, e.g., to an UPDATE or CLOSE packet after a
        timeout based on local policies, a host <span class="bcp14">SHOULD</span> resend
        the packet through the associated Data Relay Server of the peer (if
        the peer listed it in its LOCATOR_SET parameter in the base exchange
        according to the rules specified in <span><a href="https://www.rfc-editor.org/rfc/rfc7401#section-4.4.2" class="relref">Section 4.4.2</a> of [<a href="#RFC7401" class="xref">RFC7401</a>]</span>).<a href="#section-4.8-2" class="pilcrow">¶</a></p>
<p id="section-4.8-3"> If a Control Relay Client sends a packet through a Control Relay
 Server, the Control Relay Client <span class="bcp14">MUST</span> always utilize
 the RELAY_TO parameter. The Control Relay Server <span class="bcp14">SHOULD</span>
 forward HIP control packets originating from a Control Relay Client to
 the address denoted in the RELAY_TO parameter. In the other direction,
 the Control Relay Server <span class="bcp14">SHOULD</span> forward HIP control
 packets to the Control Relay Clients and <span class="bcp14">MUST</span> add a
 RELAY_FROM parameter to the control packets it relays to the Control
 Relay Clients.<a href="#section-4.8-3" class="pilcrow">¶</a></p>
<p id="section-4.8-4"> If the Control Relay Server is not willing or able to relay a HIP
        packet, it <span class="bcp14">MAY</span> notify the sender of the packet with a
        MESSAGE_NOT_RELAYED error notification (see <a href="#sec_notify-types" class="xref">Section 5.10</a>).<a href="#section-4.8-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec_mobility">
<section id="section-4.9">
        <h3 id="name-mobility-handover-procedure">
<a href="#section-4.9" class="section-number selfRef">4.9. </a><a href="#name-mobility-handover-procedure" class="section-name selfRef">Mobility Handover Procedure</a>
        </h3>
<p id="section-4.9-1">A host may move after base exchange and connectivity
        checks. Mobility extensions for HIP <span>[<a href="#RFC8046" class="xref">RFC8046</a>]</span> define handover procedures 
        without NATs. In this section, we define how two hosts
        interact with handover procedures in scenarios involving
        NATs. The specified extensions define only simple mobility
        using a pair of security associations, and multihoming
        extensions are left to be defined in later specifications.
        The procedures in this section offer the same functionality as "ICE
 restart" specified in <span>[<a href="#RFC8445" class="xref">RFC8445</a>]</span>. The 
        example described in this section shows only a Control Relay Server
        for the peer host for the sake of simplicity, but the
        mobile host may also have a Control Relay Server.<a href="#section-4.9-1" class="pilcrow">¶</a></p>
<p id="section-4.9-2">The assumption here is that the two hosts have successfully negotiated
        and chosen the ICE-HIP-UDP mode during the base exchange as
        defined in <a href="#sec_nat_traversal_mode" class="xref">Section 4.3</a>. The Initiator of the base 
        exchange <span class="bcp14">MUST</span> store information that it was the controlling
        host during the base exchange. Similarly, the Responder <span class="bcp14">MUST</span>
        store information that it was the controlled host during the
        base exchange.<a href="#section-4.9-2" class="pilcrow">¶</a></p>
<p id="section-4.9-3">Prior to starting the handover procedures with all peer hosts, the
        mobile host <span class="bcp14">SHOULD</span> first send its locators in UPDATE
        messages to its Control and Data Relay Servers if it has registered to
        such. It <span class="bcp14">SHOULD</span> wait for all of them to respond for a
        configurable time, by default two minutes, and then continue with the
        handover procedure without information from the Relay Server that did
        not respond. As defined in <a href="#sec_registration" class="xref">Section 4.1</a>, a response message from a Control Relay Server
        includes a REG_FROM parameter that describes the server-reflexive
        candidate of the mobile host to be used in the candidate exchange
        during the handover. Similarly, an UPDATE to a Data Relay Server is
        necessary to make sure the Data Relay Server can forward data to the
        correct IP address after a handover.<a href="#section-4.9-3" class="pilcrow">¶</a></p>
<p id="section-4.9-4">The mobility extensions for NAT traversal are illustrated
        in <a href="#fig_update" class="xref">Figure 6</a>. The mobile host is the
        host that has changed its locators, and the peer host is the
        host it has a host association with. The mobile host may have
        multiple peers, and it repeats the process with all of its
        peers. In the figure, the Control Relay Server belongs to the peer host,
        i.e., the peer host is a Control Relay Client for the Control Relay Server.
        Note that the figure corresponds to figure 3 in <span>[<a href="#RFC8046" class="xref">RFC8046</a>]</span>, but the difference is that the main 
        UPDATE procedure is carried over the relay and the
        connectivity is tested separately. Next, we describe the
        procedure of that figure in detail.<a href="#section-4.9-4" class="pilcrow">¶</a></p>
<span id="name-hip-update-procedure"></span><div id="fig_update">
<figure id="figure-6">
          <div class="artwork art-text alignCenter" id="section-4.9-5.1">
<pre>
Mobile Host               Control Relay Server              Peer Host
| 1. UDP(UPDATE(ESP_INFO,          |                                |
|          ENC(LOC_SET), SEQ))     |                                |
+---------------------------------&gt;| 2. UDP(UPDATE(ESP_INFO,        |
|                                  |          ENC(LOC_SET), SEQ,    |
|                                  |          RELAY_FROM))          |
|                                  +-------------------------------&gt;|
|                                  |                                |
|                                  | 3. UDP(UPDATE(ESP_INFO, SEQ,   |
|                                  |          ACK, ECHO_REQ_SIGN,   |
|                                  |          RELAY_TO))            |
| 4. UDP(UPDATE(ESP_INFO, SEQ,     |&lt;-------------------------------+
|          ACK, ECHO_REQ_SIGN,     |                                |
|          RELAY_TO))              |                                |
|&lt;---------------------------------+                                |
|                                  |                                |
| 5. UDP(UPDATE(ACK,               |                                |
|          ECHO_RESP_SIGNED))      |                                |
+---------------------------------&gt;| 6. UDP(UPDATE(ACK,             |
|                                  |          ECHO_RESP_SIGNED,     |
|                                  |          RELAY_FROM))          |
|                                  +-------------------------------&gt;|
|                                  |                                |
|                   7. connectivity checks over UDP                 |
+&lt;-----------------------------------------------------------------&gt;+
|                                  |                                |
|                      8. ESP data over UDP                         |
+&lt;-----------------------------------------------------------------&gt;+
|                                  |                                |
</pre>
</div>
<figcaption><a href="#figure-6" class="selfRef">Figure 6</a>:
<a href="#name-hip-update-procedure" class="selfRef">HIP UPDATE Procedure</a>
          </figcaption></figure>
</div>
<p id="section-4.9-6">In step 1, the mobile host has changed location and sends a
        location update to its peer through the Control Relay Server of the
        peer. It sends an UPDATE packet with the source HIT belonging to
        itself and destination HIT belonging to the peer host. In the packet,
        the source IP address belongs to the mobile host and the destination
        to the Control Relay Server. The packet contains an ESP_INFO parameter
        where, in this case, the OLD SPI and NEW SPI parameters both contain
        the pre-existing incoming SPI. The packet also contains the locators
        of the mobile host in a LOCATOR_SET parameter, encapsulated inside an
        ENCRYPTED parameter (see Sections <a href="https://www.rfc-editor.org/rfc/rfc7401#section-5.2.18" class="relref">5.2.18</a> and <a href="https://www.rfc-editor.org/rfc/rfc7401#section-6.5" class="relref">6.5</a> in <span>[<a href="#RFC7401" class="xref">RFC7401</a>]</span> for details on the ENCRYPTED parameter). The packet
        also contains a SEQ number to be acknowledged by the peer. As
        specified in <span>[<a href="#RFC8046" class="xref">RFC8046</a>]</span>, the packet may
        also include a HOST_ID (for middlebox inspection) and DIFFIE_HELLMAN
        parameter for rekeying.<a href="#section-4.9-6" class="pilcrow">¶</a></p>
<p id="section-4.9-7">In step 2, the Control Relay Server receives the UPDATE packet and forwards it
        to the peer host (i.e., Control Relay Client). The Control Relay Server
        rewrites the destination IP address and appends a RELAY_FROM
        parameter to the message.<a href="#section-4.9-7" class="pilcrow">¶</a></p>
<p id="section-4.9-8">In step 3, the peer host receives the UPDATE packet,
        processes it, and responds with another UPDATE message. The
        message is destined to the HIT of the mobile host and to the IP
        address of the Control Relay Server. The message includes an ESP_INFO
        parameter where, in this case, the OLD SPI and NEW SPI
        parameters both contain the pre-existing incoming SPI. The
        peer includes a new SEQ and ECHO_REQUEST_SIGNED parameter to be
        acknowledged by the mobile host.  The message acknowledges the
        SEQ parameter of the earlier message with an ACK parameter.
        The RELAY_TO parameter specifies the address of the mobile host where the
        Control Relay Server should forward the message.<a href="#section-4.9-8" class="pilcrow">¶</a></p>
<p id="section-4.9-9">In step 4, the Control Relay Server receives the message, rewrites the
        destination IP address and UDP port according to the RELAY_TO parameter, and
        then forwards the modified message to the mobile host.<a href="#section-4.9-9" class="pilcrow">¶</a></p>
<p id="section-4.9-10">In step 5, the mobile host receives the UPDATE packet and processes
        it. The mobile host concludes the handover procedure by acknowledging
        the received SEQ parameter with an ACK parameter and the
        ECHO_REQUEST_SIGNED parameter with an ECHO_RESPONSE_SIGNED
        parameter. The mobile host sends the packet to the HIT of the peer and
        to the address of the HIP relay. The mobile host can start
        connectivity checks after this packet.<a href="#section-4.9-10" class="pilcrow">¶</a></p>
<p id="section-4.9-11">In step 6, the HIP relay receives the UPDATE packet and
        forwards it to the peer host (i.e., Relay Client). The HIP
        relay rewrites the destination IP address and port, and then appends a
        RELAY_FROM parameter to the message. When the peer host
        receives this concluding UPDATE packet, it can initiate the
        connectivity checks.<a href="#section-4.9-11" class="pilcrow">¶</a></p>
<p id="section-4.9-12">In step 7, the two hosts test for connectivity across NATs
        according to procedures described in <a href="#sec_conn_checks" class="xref">Section 4.6</a>. The original Initiator of the 
        communications is the controlling host and the original Responder is
        the controlled host.<a href="#section-4.9-12" class="pilcrow">¶</a></p>
<p id="section-4.9-13">In step 8, the connectivity checks are successfully
        completed and the controlling host has nominated one address
        pair to be used. The hosts set up security associations to
        deliver the application payload.<a href="#section-4.9-13" class="pilcrow">¶</a></p>
<p id="section-4.9-14">It is worth noting that the Control and Data Relay Client
        do not have to reregister for the related services after a
        handover. However, if a Data Relay Client has registered a
        relayed address candidate from a Data Relay Server, the Data
        Relay Client <span class="bcp14">MUST</span> reactivate the address before the
        connectivity checks by sending an UPDATE message containing
        the PEER_PERMISSION parameter as described in <a href="#sec_forwarding" class="xref">Section 4.12.1</a>. Otherwise, the Data Relay
 Server 
        drops ESP packets sent to the relayed address.<a href="#section-4.9-14" class="pilcrow">¶</a></p>
<p id="section-4.9-15">In the so-called "double jump" or simultaneous mobility
 scenario, both peers change their location simultaneously. In
 such a case, both peers trigger the procedure described
 earlier in this section at the same time. In other words, both
 of the communicating hosts send an UPDATE packet carrying
 locators at the same time or with some delay. When the
 locators are exchanged almost simultaneously (reliably via
 Control Relay Servers), the two hosts can continue with
 connectivity checks after both have completed separately the
 steps in <a href="#fig_update" class="xref">Figure 6</a>. The problematic case
 occurs when one of the hosts (referred to here as host "M")
 moves later during the connectivity checks.  In such a case,
 host M sends a locator to the peer, which is in the middle of
 connectivity checks. Upon receiving the UPDATE message, the
 peer responds with an UPDATE with ECHO_REQ_SIGN as described
 in step 3 in <a href="#fig_update" class="xref">Figure 6</a>. Upon receiving the
 valid response from host M as described in step 6, the peer
 host <span class="bcp14">MUST</span> restart the connectivity checks with host M. This
 way, both hosts start the connectivity checks roughly in a
 synchronized way. It is also important that the peer host does not
 restart the connectivity checks until step 6 is
 successfully completed, because the UPDATE message
 carrying locators in step 1 could be replayed by an attacker.<a href="#section-4.9-15" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec_nat-keepalives">
<section id="section-4.10">
        <h3 id="name-nat-keepalives">
<a href="#section-4.10" class="section-number selfRef">4.10. </a><a href="#name-nat-keepalives" class="section-name selfRef">NAT Keepalives</a>
        </h3>
<p id="section-4.10-1">To prevent NAT states from expiring, communicating hosts
        <span class="bcp14">MUST</span> send periodic keepalives to other hosts with which
        they have established a HIP association every 15 seconds (the
        so-called Tr value in ICE). Other values <span class="bcp14">MAY</span> be used,
        but a Tr value smaller than 15 seconds <span class="bcp14">MUST NOT</span> be
        used.  Both a Control/Data Relay Client and Control/Data Relay Server,
        as well as two peers employing UDP-ENCAPSULATION or ICE-HIP-UDP mode,
        <span class="bcp14">SHOULD</span> send HIP NOTIFY packets unless they have
        exchanged some other traffic over the used UDP ports.  However, the
        Data Relay Client and Data Relay Server <span class="bcp14">MUST</span> employ
        only HIP NOTIFY packets in order to keep the server-reflexive
        candidates alive.  The keepalive message encoding format is defined in
        <a href="#sec_keepalive" class="xref">Section 5.3</a>.


        If the base exchange or mobility handover procedure occurs during an
 extremely slow path, a host (with a HIP association with the peer)
 <span class="bcp14">MAY</span> also 
        send HIP NOTIFY packets every 15 seconds to keep the path active with the recipient.<a href="#section-4.10-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec_close">
<section id="section-4.11">
        <h3 id="name-closing-procedure">
<a href="#section-4.11" class="section-number selfRef">4.11. </a><a href="#name-closing-procedure" class="section-name selfRef">Closing Procedure</a>
        </h3>
<p id="section-4.11-1">The two-way procedure for closing a HIP association and the related
        security associations is defined in <span>[<a href="#RFC7401" class="xref">RFC7401</a>]</span>. One host initiates the procedure by sending a
        CLOSE message and the recipient confirms it with CLOSE_ACK. All
        packets are protected using HMACs and signatures, and the CLOSE
        messages include an ECHO_REQUEST_SIGNED parameter to protect against
        replay attacks.<a href="#section-4.11-1" class="pilcrow">¶</a></p>
<p id="section-4.11-2">The same procedure for closing HIP associations also applies here,
        but the messaging occurs using the UDP-encapsulated tunnel that the
        two hosts employ. A host sending the CLOSE message
        <span class="bcp14">SHOULD</span> first send the message over a direct link. After
        a number of retransmissions, it <span class="bcp14">MUST</span> send over a
        Control Relay Server of the recipient if one exists. The host
        receiving the CLOSE message directly without a Control Relay Server
        <span class="bcp14">SHOULD</span> respond directly. If the CLOSE message came via a
        Control Relay Server, the host <span class="bcp14">SHOULD</span> respond using the
        same Control Relay Server.<a href="#section-4.11-2" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-4.12">
        <h3 id="name-relaying-considerations">
<a href="#section-4.12" class="section-number selfRef">4.12. </a><a href="#name-relaying-considerations" class="section-name selfRef">Relaying Considerations</a>
        </h3>
<div id="sec_forwarding">
<section id="section-4.12.1">
          <h4 id="name-forwarding-rules-and-permis">
<a href="#section-4.12.1" class="section-number selfRef">4.12.1. </a><a href="#name-forwarding-rules-and-permis" class="section-name selfRef">Forwarding Rules and Permissions</a>
          </h4>
<p id="section-4.12.1-1"> The Data Relay Server uses a similar permission model as a
          TURN server: before the Data Relay Server forwards any ESP data
          packets from a peer to a Data Relay Client (or the other direction),
          the client <span class="bcp14">MUST</span> set a permission for the peer's address. The
          permissions also install a forwarding rule for each direction, similar to
          TURN's channels, based on the Security Parameter Index (SPI)
          values in the ESP packets.<a href="#section-4.12.1-1" class="pilcrow">¶</a></p>
<p id="section-4.12.1-2">Permissions are not required for HIP control packets.
          However, if a relayed address (as conveyed in the RELAYED_ADDRESS
   parameter from the Data Relay Server) is selected to be used for 
          data, the Control Relay Client <span class="bcp14">MUST</span> send an UPDATE message to the
          Data Relay Server containing a PEER_PERMISSION parameter (see <a href="#sec_peer_permission" class="xref">Section 5.13</a>) with the following
   information: the UDP port and address for the server-reflexive
   address, the UDP port and 
          address of the peer, and the inbound and outbound SPIs used for ESP.
          The packet <span class="bcp14">MUST</span> be sent to the same UDP tunnel
          the Client employed in the base exchange to contact the Server
   (i.e., not to the port occupied by the server-reflexive candidate). 
          To avoid packet
          dropping of ESP packets, the Control Relay Client <span class="bcp14">SHOULD</span> send the
          PEER_PERMISSION parameter before connectivity checks both in
          the case of base exchange and a mobility handover.  It is
          worth noting that the UPDATE message includes a SEQ
          parameter (as specified in <span>[<a href="#RFC7401" class="xref">RFC7401</a>]</span>) that
          the Data Relay Server must acknowledge, so that the Control Relay Client
          can resend the message with the PEER_PERMISSION parameter if it
          gets lost.<a href="#section-4.12.1-2" class="pilcrow">¶</a></p>
<p id="section-4.12.1-3"> When a Data Relay Server receives an UPDATE with a
          PEER_PERMISSION parameter, it <span class="bcp14">MUST</span> check if the
          sender of the UPDATE is registered for data-relaying service, and
          drop the UPDATE if the host was not registered. If the host was
          registered, the Data Relay Server checks if there is a permission
          with matching information (protocol, addresses, ports, and SPI
          values). If there is no such permission, a new permission
          <span class="bcp14">MUST</span> be created and its lifetime <span class="bcp14">MUST</span>
          be set to 5 minutes. If an identical permission already existed, it
          <span class="bcp14">MUST</span> be refreshed by setting the lifetime to 5
          minutes. A Data Relay Client <span class="bcp14">SHOULD</span> refresh
          permissions 1 minute before the expiration when the permission is
          still needed.<a href="#section-4.12.1-3" class="pilcrow">¶</a></p>
<p id="section-4.12.1-4">When a Data Relay Server receives an UPDATE from a registered
          client but without a PEER_PERMISSION parameter and with a new
          locator set, the Data Relay Server can assume that the mobile host
          has changed its location and is thus not reachable in its previous
          location. In such an event, the Data Relay Server
          <span class="bcp14">SHOULD</span> deactivate the permission and stop relaying
          data plane traffic to the client.<a href="#section-4.12.1-4" class="pilcrow">¶</a></p>
<p id="section-4.12.1-5">The relayed address <span class="bcp14">MUST</span> be activated with the
          PEER_PERMISSION parameter both after a base exchange and after a
          handover procedure with another ICE-HIP-UDP-capable host. Unless
          activated, the Data Relay Server <span class="bcp14">MUST</span> drop all ESP
          packets. It is worth noting that a Data Relay Client does not have
          to renew its registration upon a change of location UPDATE, but only
          when the lifetime of the registration is close to end.<a href="#section-4.12.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-4.12.2">
          <h4 id="name-hip-data-relay-and-relaying">
<a href="#section-4.12.2" class="section-number selfRef">4.12.2. </a><a href="#name-hip-data-relay-and-relaying" class="section-name selfRef">HIP Data Relay and Relaying of Control Packets</a>
          </h4>
<p id="section-4.12.2-1">When a Data Relay Server accepts to relay UDP-encapsulated ESP
   between a Data Relay Client and its peer, the Data Relay Server
   opens a UDP port (relayed address) for this purpose as described in
   <a href="#sec_registration" class="xref">Section 4.1</a>. This port can be
   used for also delivering control packets because connectivity checks
   also cover the path through the Data Relay Server. If the Data Relay
   Server receives a UDP-encapsulated HIP control packet on that port,
   it <span class="bcp14">MUST</span> forward the packet to the Data Relay Client
   and add a RELAY_FROM parameter to the packet as if the Data Relay
   Server were acting as a Control Relay Server. When the Data Relay
   Client replies to a control packet with a RELAY_FROM parameter via
   its Data Relay Server, the Data Relay Client <span class="bcp14">MUST</span> add
   a RELAY_TO parameter containing the peer's address and use the
   address of its Data Relay Server as the destination
   address. Further, the Data Relay Server <span class="bcp14">MUST</span> send
   this packet to the peer's address from the relayed address.<a href="#section-4.12.2-1" class="pilcrow">¶</a></p>
<p id="section-4.12.2-2"> If the Data Relay Server receives a UDP packet that is not a
          HIP control packet to the relayed address, it <span class="bcp14">MUST</span> check if
          it has a permission set for the peer the packet is arriving
          from (i.e., the sender's address and SPI value matches to an
          installed permission). If permissions are set, the Data Relay Server
          <span class="bcp14">MUST</span> forward the packet to the Data Relay Client that
          created the permission. The Data Relay Server <span class="bcp14">MUST</span> also implement
          the similar checks for the reverse direction (i.e., ESP packets
          from the Data Relay Client to the peer). Packets without a
   permission <span class="bcp14">MUST</span> be dropped silently.<a href="#section-4.12.2-2" class="pilcrow">¶</a></p>
</section>
<div id="sec_conflicting">
<section id="section-4.12.3">
          <h4 id="name-handling-conflicting-spi-va">
<a href="#section-4.12.3" class="section-number selfRef">4.12.3. </a><a href="#name-handling-conflicting-spi-va" class="section-name selfRef">Handling Conflicting SPI Values</a>
          </h4>
<p id="section-4.12.3-1">From the viewpoint of a host, its remote peers can have
          overlapping inbound SPI numbers because the IPsec also uses the
          destination IP address to index the remote peer host. However, a
          Data Relay Server can represent multiple remote peers, thus
          masquerading the actual destination. Since a Data Relay Server may
          have to deal with a multitude of Relay Clients and their peers, a
          Data Relay Server may experience collisions in the SPI namespace,
          thus being unable to forward datagrams to the correct
          destination. Since the SPI space is 32 bits and the SPI values
          should be random, the probability for a conflicting SPI value is
          fairly small but could occur on a busy Data Relay Server.  The two
          problematic cases are described in this section.<a href="#section-4.12.3-1" class="pilcrow">¶</a></p>
<p id="section-4.12.3-2">In the first scenario, the SPI collision problem occurs
          if two hosts have registered to the same Data Relay Server
          and a third host initiates base exchange with both of
          them. Here, the two Responders (i.e., Data Relay Clients)
          claim the same inbound SPI number with the same Initiator
          (peer). However, in this case, the Data Relay Server has
          allocated separate UDP ports for the two Data Relay Clients
          acting now as Responders (as recommended in <a href="#sec_reuse" class="xref">Section 7.5</a>). When the third host sends an ESP packet, 
          the Data Relay Server is able to forward the packet to the
          correct Data Relay Client because the destination UDP port
          is different for each of the clients.<a href="#section-4.12.3-2" class="pilcrow">¶</a></p>
<p id="section-4.12.3-3">In the second scenario, an SPI collision may occur when
   two Initiators run a base exchange to the same Responder
   (i.e., Data Relay Client), and both of the Initiators claim
   the same inbound SPI at the Data Relay Server using
   the PEER_PERMISSION parameter. In this case, the Data Relay
   Server cannot disambiguate the correct destination of an ESP
   packet originating from the Data Relay Client because the
   SPI could belong to either of the peers (and the destination IP
   and UDP port belonging to the Data Relay Server are not
   unique either). The recommended way and a contingency plan
   to solve this issue are described below.<a href="#section-4.12.3-3" class="pilcrow">¶</a></p>
<p id="section-4.12.3-4">The recommend way to mitigate the problem is as follows. For each
          new HIP association, a Data Relay Client acting as a Responder
          <span class="bcp14">SHOULD</span> register a new server-reflexive candidate as
          described in <a href="#sec_gathering" class="xref">Section 4.2</a>. Similarly, the Data Relay Server <span class="bcp14">SHOULD NOT</span> reuse the port numbers as described in <a href="#sec_reuse" class="xref">Section 7.5</a>. This way, each
          server-reflexive candidate for the Data Relay Client has a separate
          UDP port that the Data Relay Server can use to disambiguate packet
          destinations in case of SPI collisions.<a href="#section-4.12.3-4" class="pilcrow">¶</a></p>
<p id="section-4.12.3-5">When the Data Relay Client is not registering or failed
   to register a new relay candidate for a new peer, the Data
   Relay Client <span class="bcp14">MUST</span> follow a contingency plan as follows.
   Upon receiving an I2 with a colliding SPI, the Data Relay
   Client acting as the Responder <span class="bcp14">MUST NOT</span> include the relayed
   address candidate in the R2 message because the Data Relay
   Server would not be able to demultiplex the related ESP packet
   to the correct Initiator.  The same also applies to the
   handover procedures; the Data Relay Client <span class="bcp14">MUST NOT</span> include
   the relayed address candidate when sending its new locator
   set in an UPDATE to its peer if it would cause an SPI
   conflict with another peer.<a href="#section-4.12.3-5" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</section>
</div>
<div id="sec_format">
<section id="section-5">
      <h2 id="name-packet-formats">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-packet-formats" class="section-name selfRef">Packet Formats</a>
      </h2>
<p id="section-5-1"> The following subsections define the parameter and packet encodings
      for the HIP and ESP packets. All values <span class="bcp14">MUST</span> be in
      network byte order.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">It is worth noting that all of the parameters are shown for the sake
      of completeness even though they are specified already in Legacy ICE-HIP
      <span>[<a href="#RFC5770" class="xref">RFC5770</a>]</span>. New parameters are explicitly
      described as new.<a href="#section-5-2" class="pilcrow">¶</a></p>
<div id="sec_udphip">
<section id="section-5.1">
        <h3 id="name-hip-control-packets">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-hip-control-packets" class="section-name selfRef">HIP Control Packets</a>
        </h3>
<p id="section-5.1-1"><a href="#fig_udphip" class="xref">Figure 7</a> illustrates the packet
 format for UDP-encapsulated HIP. The format is identical to Legacy
 ICE-HIP <span>[<a href="#RFC5770" class="xref">RFC5770</a>]</span>.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<span id="name-format-of-udp-encapsulated-"></span><div id="fig_udphip">
<figure id="figure-7">
          <div class="artwork art-text alignCenter" id="section-5.1-2.1">
<pre>
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Source Port            |       Destination Port        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Length              |           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       32 bits of zeroes                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                    HIP Header and Parameters                  ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
</div>
<figcaption><a href="#figure-7" class="selfRef">Figure 7</a>:
<a href="#name-format-of-udp-encapsulated-" class="selfRef">Format of UDP-Encapsulated HIP Control Packets</a>
          </figcaption></figure>
</div>
<p id="section-5.1-3"> HIP control packets are encapsulated in UDP packets as defined in
 <span><a href="https://www.rfc-editor.org/rfc/rfc3948#section-2.2" class="relref">Section 2.2</a> of [<a href="#RFC3948" class="xref">RFC3948</a>]</span>, "IKE Header
 Format for Port 4500", except that a different port number is
 used. <a href="#fig_udphip" class="xref">Figure 7</a> illustrates the
 encapsulation.  The UDP header is followed by 32 zero bits that can be
 used to differentiate HIP control packets from ESP packets. The HIP
 header and parameters follow the conventions of <span>[<a href="#RFC7401" class="xref">RFC7401</a>]</span> with the exception that the HIP header checksum
 <span class="bcp14">MUST</span> be zero. The HIP header checksum is zero for two
 reasons. First, the UDP header already contains a checksum. Second,
 the checksum definition in <span>[<a href="#RFC7401" class="xref">RFC7401</a>]</span>
 includes the IP addresses in the checksum calculation. The NATs that
 are unaware of HIP cannot recompute the HIP checksum after changing IP
 addresses.<a href="#section-5.1-3" class="pilcrow">¶</a></p>
<p id="section-5.1-4"> A Control/Data Relay Server or a non-relay Responder
 <span class="bcp14">SHOULD</span> listen at UDP port 10500 for incoming
 UDP-encapsulated HIP control packets. If some other port number is
 used, it needs to be known by potential Initiators.<a href="#section-5.1-4" class="pilcrow">¶</a></p>
<p id="section-5.1-5">UDP encapsulation of HIP packets reduces the Maximum
 Transmission Unit (MTU) size of the control plane by 12 bytes
 (8-byte UDP header plus 4-byte zero SPI marker), and the data
 plane by 8 bytes.  Additional HIP relay parameters, such as
 RELAY_HMAC, RELAY_UDP_HIP, RELAY_UDP_ESP, etc., further
 increase the size of certain HIP packets. In regard to MTU,
 the following aspects need to be considered in an
 implementation:<a href="#section-5.1-5" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.1-6.1">A HIP host <span class="bcp14">SHOULD</span> implement ICMP message handling
   to support Path MTU Discovery (PMTUD) as described in
   <span>[<a href="#RFC1191" class="xref">RFC1191</a>]</span> and <span>[<a href="#RFC8201" class="xref">RFC8201</a>]</span>.<a href="#section-5.1-6.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.1-6.2">Reliance on IP fragmentation is unlikely to be a viable strategy
   through NATs. If ICMP MTU discovery is not working, MTU-related path
   black holes may occur.<a href="#section-5.1-6.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.1-6.3">A mitigation strategy is to constrain the MTU, especially for
   virtual interfaces, to expected safe MTU values, e.g., 1400 bytes
   for the underlying interfaces that support 1500 bytes MTU.<a href="#section-5.1-6.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.1-6.4">Further extensions to this specification may define a HIP-based
   mechanism to find a working path MTU without unnecessary
   constraining that size using Packetization Layer Path MTU Discovery
   for Datagram Transports <span>[<a href="#RFC8899" class="xref">RFC8899</a>]</span>. For
   instance, such a mechanism could be implemented between a HIP Relay
   Client and HIP Relay Server.<a href="#section-5.1-6.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.1-6.5">It is worth noting that further HIP extensions can trim off 8
          bytes in the ESP header by negotiating implicit initialization
          vector (IV) support in the ESP_TRANSFORM parameter as described in
          <span>[<a href="#RFC8750" class="xref">RFC8750</a>]</span>.<a href="#section-5.1-6.5" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="sec_con_checks">
<section id="section-5.2">
        <h3 id="name-connectivity-checks-3">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-connectivity-checks-3" class="section-name selfRef">Connectivity Checks</a>
        </h3>
<p id="section-5.2-1">HIP connectivity checks are HIP UPDATE packets. The format
        is specified in <span>[<a href="#RFC7401" class="xref">RFC7401</a>]</span>.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec_keepalive">
<section id="section-5.3">
        <h3 id="name-keepalives">
<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-keepalives" class="section-name selfRef">Keepalives</a>
        </h3>
<p id="section-5.3-1">The <span class="bcp14">RECOMMENDED</span> encoding format for keepalives is
        HIP NOTIFY packets as specified in <span>[<a href="#RFC7401" class="xref">RFC7401</a>]</span> with the Notify message type field set to
        NAT_KEEPALIVE (16385) and with an empty Notification data field. It is
        worth noting that the sending of such a HIP NOTIFY message
        <span class="bcp14">SHOULD</span> be omitted if the host is sending some other
        traffic (HIP or ESP) to the peer host over the related UDP tunnel
        during the Tr period. For instance, the host <span class="bcp14">MAY</span>
        actively send ICMPv6 requests (or respond with an ICMPv6 response)
        inside the ESP tunnel to test the health of the associated IPsec
        security association. Alternatively, the host <span class="bcp14">MAY</span> use
        UPDATE packets as a substitute. A minimal UPDATE packet would consist
        of a SEQ and a single ECHO_REQ_SIGN parameter, and a more complex one
        would involve rekeying procedures as specified in <span><a href="https://www.rfc-editor.org/rfc/rfc7402#section-6.8" class="relref">Section 6.8</a> of [<a href="#RFC7402" class="xref">RFC7402</a>]</span>. It is worth
        noting that a host actively sending periodic UPDATE packets to a busy
        server may increase the computational load of the server since it has
        to verify HMACs and signatures in UPDATE messages.<a href="#section-5.3-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec_nat_tm-param">
<section id="section-5.4">
        <h3 id="name-nat-traversal-mode-paramete">
<a href="#section-5.4" class="section-number selfRef">5.4. </a><a href="#name-nat-traversal-mode-paramete" class="section-name selfRef">NAT Traversal Mode Parameter</a>
        </h3>
<p id="section-5.4-1">The format of the NAT traversal mode parameter is defined in Legacy
        ICE-HIP <span>[<a href="#RFC5770" class="xref">RFC5770</a>]</span> but repeated here
        for completeness.  The format of the NAT_TRAVERSAL_MODE parameter is
        similar to the format of the ESP_TRANSFORM parameter in <span>[<a href="#RFC7402" class="xref">RFC7402</a>]</span> and is shown in <a href="#fig_nat_tfm" class="xref">Figure 8</a>. The Native ICE-HIP extension
        specified in this document defines the new NAT traversal mode
        identifier for ICE-HIP-UDP and reuses the UDP-ENCAPSULATION mode from
        Legacy ICE-HIP <span>[<a href="#RFC5770" class="xref">RFC5770</a>]</span>. The
        identifier named RESERVED is reserved for future use. Future
        specifications may define more traversal modes.<a href="#section-5.4-1" class="pilcrow">¶</a></p>
<span id="name-format-of-the-nat_traversal"></span><div id="fig_nat_tfm">
<figure id="figure-8">
          <div class="artwork art-text alignCenter" id="section-5.4-2.1">
<pre>
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Reserved            |            Mode ID #1         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Mode ID #2          |            Mode ID #3         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Mode ID #n          |             Padding           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
</div>
<figcaption><a href="#figure-8" class="selfRef">Figure 8</a>:
<a href="#name-format-of-the-nat_traversal" class="selfRef">Format of the NAT_TRAVERSAL_MODE Parameter</a>
          </figcaption></figure>
</div>
<span class="break"></span><dl class="dlParallel" id="section-5.4-3">
          <dt id="section-5.4-3.1">Type:</dt>
          <dd style="margin-left: 6.0em" id="section-5.4-3.2">608<a href="#section-5.4-3.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.4-3.3">Length:</dt>
          <dd style="margin-left: 6.0em" id="section-5.4-3.4">Length in octets, excluding Type, Length, and Padding<a href="#section-5.4-3.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.4-3.5">Reserved:</dt>
          <dd style="margin-left: 6.0em" id="section-5.4-3.6">Zero when sent, ignored when received<a href="#section-5.4-3.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.4-3.7">Mode ID:</dt>
          <dd style="margin-left: 6.0em" id="section-5.4-3.8">Defines the proposed or selected NAT traversal mode(s)<a href="#section-5.4-3.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-5.4-4">The following NAT traversal mode IDs are defined:<a href="#section-5.4-4" class="pilcrow">¶</a></p>
<span id="name-nat-traversal-mode-ids"></span><table class="center" id="table-1">
          <caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-nat-traversal-mode-ids" class="selfRef">NAT Traversal Mode IDs</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">ID name</th>
              <th class="text-left" rowspan="1" colspan="1">Value</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">RESERVED</td>
              <td class="text-left" rowspan="1" colspan="1">0</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">UDP-ENCAPSULATION</td>
              <td class="text-left" rowspan="1" colspan="1">1</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">ICE-STUN-UDP</td>
              <td class="text-left" rowspan="1" colspan="1">2</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">ICE-HIP-UDP</td>
              <td class="text-left" rowspan="1" colspan="1">3</td>
            </tr>
          </tbody>
        </table>
<p id="section-5.4-6"> The sender of a NAT_TRAVERSAL_MODE parameter <span class="bcp14">MUST</span> make sure that
        there are no more than six (6) Mode IDs in one NAT_TRAVERSAL_MODE
        parameter. Conversely, a recipient <span class="bcp14">MUST</span> be prepared to handle received
        NAT traversal mode parameters that contain more than six Mode IDs by
        accepting the first six Mode IDs and dropping the rest. The limited
        number of Mode IDs sets the maximum size of the NAT_TRAVERSAL_MODE
        parameter. The modes <span class="bcp14">MUST</span> be in preference order, most preferred
        mode(s) first.<a href="#section-5.4-6" class="pilcrow">¶</a></p>
<p id="section-5.4-7">Implementations conforming to this specification
 <span class="bcp14">MUST</span> implement UDP-ENCAPSULATION and
 <span class="bcp14">SHOULD</span> implement ICE-HIP-UDP modes.<a href="#section-5.4-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec_check-pacing-param">
<section id="section-5.5">
        <h3 id="name-connectivity-check-transact">
<a href="#section-5.5" class="section-number selfRef">5.5. </a><a href="#name-connectivity-check-transact" class="section-name selfRef">Connectivity Check Transaction Pacing Parameter</a>
        </h3>
<p id="section-5.5-1"> The TRANSACTION_PACING parameter is defined in <span>[<a href="#RFC5770" class="xref">RFC5770</a>]</span> but repeated in <a href="#fig_check_pacing" class="xref">Figure 9</a> for completeness. It contains only the connectivity
 check pacing value, expressed in milliseconds, as a 32-bit unsigned
 integer.<a href="#section-5.5-1" class="pilcrow">¶</a></p>
<span id="name-format-of-the-transaction_p"></span><div id="fig_check_pacing">
<figure id="figure-9">
          <div class="artwork art-text alignLeft" id="section-5.5-2.1">
<pre>
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Min Ta                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
</div>
<figcaption><a href="#figure-9" class="selfRef">Figure 9</a>:
<a href="#name-format-of-the-transaction_p" class="selfRef">Format of the TRANSACTION_PACING Parameter</a>
          </figcaption></figure>
</div>
<span class="break"></span><dl class="dlParallel" id="section-5.5-3">
          <dt id="section-5.5-3.1">Type:</dt>
          <dd style="margin-left: 6.0em" id="section-5.5-3.2">610<a href="#section-5.5-3.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.5-3.3">Length:</dt>
          <dd style="margin-left: 6.0em" id="section-5.5-3.4">4<a href="#section-5.5-3.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.5-3.5">Min Ta:</dt>
          <dd style="margin-left: 6.0em" id="section-5.5-3.6">The minimum connectivity check transaction pacing value the host would
  use (in milliseconds)<a href="#section-5.5-3.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="sec_rel-reg-params">
<section id="section-5.6">
        <h3 id="name-relay-and-registration-para">
<a href="#section-5.6" class="section-number selfRef">5.6. </a><a href="#name-relay-and-registration-para" class="section-name selfRef">Relay and Registration Parameters</a>
        </h3>
<p id="section-5.6-1"> The format of the REG_FROM, RELAY_FROM, and RELAY_TO parameters is
 shown in <a href="#fig_reg_from" class="xref">Figure 10</a>. All
 parameters are identical except for the type. Of the three, only
 REG_FROM is covered by the signature.<a href="#section-5.6-1" class="pilcrow">¶</a></p>
<span id="name-format-of-the-reg_from-rela"></span><div id="fig_reg_from">
<figure id="figure-10">
          <div class="artwork art-text alignCenter" id="section-5.6-2.1">
<pre>
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Port              |    Protocol   |     Reserved  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                            Address                            |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
</div>
<figcaption><a href="#figure-10" class="selfRef">Figure 10</a>:
<a href="#name-format-of-the-reg_from-rela" class="selfRef">Format of the REG_FROM, RELAY_FROM, and RELAY_TO Parameters</a>
          </figcaption></figure>
</div>
<span class="break"></span><dl class="dlParallel" id="section-5.6-3">
          <dt id="section-5.6-3.1">Type:</dt>
          <dd style="margin-left: 6.0em" id="section-5.6-3.2">
            <span class="break"></span><dl class="dlParallel dlCompact" id="section-5.6-3.2.1">
              <dt id="section-5.6-3.2.1.1">REG_FROM:</dt>
              <dd style="margin-left: 1.5em" id="section-5.6-3.2.1.2">950<a href="#section-5.6-3.2.1.2" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-5.6-3.2.1.3">RELAY_FROM:</dt>
              <dd style="margin-left: 1.5em" id="section-5.6-3.2.1.4">63998<a href="#section-5.6-3.2.1.4" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-5.6-3.2.1.5">RELAY_TO:</dt>
              <dd style="margin-left: 1.5em" id="section-5.6-3.2.1.6">64002<a href="#section-5.6-3.2.1.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
</dd>
          <dd class="break"></dd>
<dt id="section-5.6-3.3">Length:</dt>
          <dd style="margin-left: 6.0em" id="section-5.6-3.4">20<a href="#section-5.6-3.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.6-3.5">Port:</dt>
          <dd style="margin-left: 6.0em" id="section-5.6-3.6">Transport port number; zero when plain IP is used<a href="#section-5.6-3.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.6-3.7">Protocol:</dt>
          <dd style="margin-left: 6.0em" id="section-5.6-3.8">IANA-assigned, Internet Protocol number. 17 for UDP; 0 for plain
    IP<a href="#section-5.6-3.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.6-3.9">Reserved:</dt>
          <dd style="margin-left: 6.0em" id="section-5.6-3.10">Reserved for future use; zero when sent, ignored when received<a href="#section-5.6-3.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.6-3.11">Address:</dt>
          <dd style="margin-left: 6.0em" id="section-5.6-3.12">An IPv6 address or an IPv4 address in "IPv4-mapped IPv6 address"
    format<a href="#section-5.6-3.12" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-5.6-4"> REG_FROM contains the transport address and protocol from which the Control
        Relay Server sees the registration coming. RELAY_FROM contains the
        address from which the relayed packet was received by the Control Relay Server
        and the protocol that was used. RELAY_TO contains the same information
        about the address to which a packet should be forwarded.<a href="#section-5.6-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec_locator_format">
<section id="section-5.7">
        <h3 id="name-locator_set-parameter">
<a href="#section-5.7" class="section-number selfRef">5.7. </a><a href="#name-locator_set-parameter" class="section-name selfRef">LOCATOR_SET Parameter</a>
        </h3>
<p id="section-5.7-1">This specification reuses the format for UDP-based locators as
 specified in Legacy ICE-HIP <span>[<a href="#RFC5770" class="xref">RFC5770</a>]</span>
 to be used for communicating the address candidates between two
 hosts. The generic and NAT-traversal-specific locator parameters are
 illustrated in <a href="#fig_locator" class="xref">Figure 11</a>.<a href="#section-5.7-1" class="pilcrow">¶</a></p>
<span id="name-locator_set-parameter-2"></span><div id="fig_locator">
<figure id="figure-11">
          <div class="artwork art-text alignCenter" id="section-5.7-2.1">
<pre>
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Type  |  Locator Type | Locator Length|  Reserved   |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Locator Lifetime                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Locator                            |
|                                                               |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Type  |  Loc Type = 2 | Locator Length|  Reserved   |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Locator Lifetime                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Transport Port            |  Transp. Proto|     Kind      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Priority                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SPI                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Address                            |
|                                                               |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
</div>
<figcaption><a href="#figure-11" class="selfRef">Figure 11</a>:
<a href="#name-locator_set-parameter-2" class="selfRef">LOCATOR_SET Parameter</a>
          </figcaption></figure>
</div>
<p id="section-5.7-3"> The individual fields in the LOCATOR_SET parameter are described in
        <a href="#tbl_locator" class="xref">Table 2</a>.<a href="#section-5.7-3" class="pilcrow">¶</a></p>
<span id="name-fields-of-the-locator_set-p"></span><div id="tbl_locator">
<table class="center" id="table-2">
          <caption>
<a href="#table-2" class="selfRef">Table 2</a>:
<a href="#name-fields-of-the-locator_set-p" class="selfRef">Fields of the LOCATOR_SET Parameter</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Field</th>
              <th class="text-left" rowspan="1" colspan="1">Value(s)</th>
              <th class="text-left" rowspan="1" colspan="1">Purpose</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Type</td>
              <td class="text-left" rowspan="1" colspan="1">193</td>
              <td class="text-left" rowspan="1" colspan="1">Parameter type</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Length</td>
              <td class="text-left" rowspan="1" colspan="1">Variable</td>
              <td class="text-left" rowspan="1" colspan="1">Length in octets, excluding Type and Length fields and padding</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Traffic Type</td>
              <td class="text-left" rowspan="1" colspan="1">0-2</td>
              <td class="text-left" rowspan="1" colspan="1">The locator for either HIP signaling (1) or ESP (2), or for 
           both (0)</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Locator Type</td>
              <td class="text-left" rowspan="1" colspan="1">2</td>
              <td class="text-left" rowspan="1" colspan="1">"Transport address" locator type</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Locator Length</td>
              <td class="text-left" rowspan="1" colspan="1">7</td>
              <td class="text-left" rowspan="1" colspan="1">Length of the fields after Locator Lifetime in 4-octet units</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Reserved</td>
              <td class="text-left" rowspan="1" colspan="1">0</td>
              <td class="text-left" rowspan="1" colspan="1">Reserved for future extensions</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Preferred (P) bit</td>
              <td class="text-left" rowspan="1" colspan="1">0 or 1</td>
              <td class="text-left" rowspan="1" colspan="1">Set to 1 for a Locator in R1 if the Responder can use it for the
          rest of the base exchange, otherwise set to zero</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Locator Lifetime</td>
              <td class="text-left" rowspan="1" colspan="1">Variable</td>
              <td class="text-left" rowspan="1" colspan="1">Locator lifetime in seconds, see
       <span><a href="https://www.rfc-editor.org/rfc/rfc8046#section-4" class="relref">Section 4</a> of [<a href="#RFC8046" class="xref">RFC8046</a>]</span>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Transport Port</td>
              <td class="text-left" rowspan="1" colspan="1">Variable</td>
              <td class="text-left" rowspan="1" colspan="1">Transport-layer port number</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Transport Protocol</td>
              <td class="text-left" rowspan="1" colspan="1">Variable</td>
              <td class="text-left" rowspan="1" colspan="1">IANA-assigned, transport-layer Internet Protocol number. 
           Currently, only UDP (17) is supported.</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Kind</td>
              <td class="text-left" rowspan="1" colspan="1">Variable</td>
              <td class="text-left" rowspan="1" colspan="1">0 for host, 1 for server reflexive, 2 for peer
       reflexive (currently unused), or 3 for relayed address</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Priority</td>
              <td class="text-left" rowspan="1" colspan="1">Variable</td>
              <td class="text-left" rowspan="1" colspan="1">Locator's priority as described in <span>[<a href="#RFC8445" class="xref">RFC8445</a>]</span>. It is worth noting that
              while the priority of a single locator candidate is 32 bits, an
              implementation should a 64-bit integer to calculate the priority
              of a candidate pair for the ICE priority algorithm.</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">SPI</td>
              <td class="text-left" rowspan="1" colspan="1">Variable</td>
              <td class="text-left" rowspan="1" colspan="1">Security Parameter Index (SPI) value that the
       host expects to see in incoming ESP packets that use this
       locator</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Address</td>
              <td class="text-left" rowspan="1" colspan="1">Variable</td>
              <td class="text-left" rowspan="1" colspan="1">IPv6 address or an "IPv4-mapped IPv6 address"
       format IPv4 address <span>[<a href="#RFC4291" class="xref">RFC4291</a>]</span>
</td>
            </tr>
          </tbody>
        </table>
</div>
<p id="section-5.7-5">The LOCATOR parameter <span class="bcp14">MUST</span> be encapsulated inside an
 ENCRYPTED parameter.<a href="#section-5.7-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec_relay-hmac">
<section id="section-5.8">
        <h3 id="name-relay_hmac-parameter">
<a href="#section-5.8" class="section-number selfRef">5.8. </a><a href="#name-relay_hmac-parameter" class="section-name selfRef">RELAY_HMAC Parameter</a>
        </h3>
<p id="section-5.8-1">As specified in Legacy ICE-HIP <span>[<a href="#RFC5770" class="xref">RFC5770</a>]</span>, the RELAY_HMAC parameter value has the TLV type
 65520. It has the same semantics as RVS_HMAC as specified in <span><a href="https://www.rfc-editor.org/rfc/rfc8004#section-4.2.1" class="relref">Section 4.2.1</a> of [<a href="#RFC8004" class="xref">RFC8004</a>]</span>.  Similar to
 RVS_HMAC, RELAY_HMAC is also keyed with the HIP integrity key
 (HIP-lg or HIP-gl as specified in <span><a href="https://www.rfc-editor.org/rfc/rfc7401#section-6.5" class="relref">Section 6.5</a> of [<a href="#RFC7401" class="xref">RFC7401</a>]</span>), established during the relay registration
 procedure as described in <a href="#sec_registration" class="xref">Section 4.1</a>.<a href="#section-5.8-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec_reg-types">
<section id="section-5.9">
        <h3 id="name-registration-types">
<a href="#section-5.9" class="section-number selfRef">5.9. </a><a href="#name-registration-types" class="section-name selfRef">Registration Types</a>
        </h3>
<p id="section-5.9-1"> The REG_INFO, REG_REQ, REG_RESP, and REG_FAILED parameters contain
 Registration Type <span>[<a href="#RFC8003" class="xref">RFC8003</a>]</span> values for
 Control Relay Server registration. The value for RELAY_UDP_HIP is 2 as
 specified in Legacy ICE-HIP <span>[<a href="#RFC5770" class="xref">RFC5770</a>]</span>. The value for RELAY_UDP_ESP is 3.<a href="#section-5.9-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec_notify-types">
<section id="section-5.10">
        <h3 id="name-notify-packet-types">
<a href="#section-5.10" class="section-number selfRef">5.10. </a><a href="#name-notify-packet-types" class="section-name selfRef">Notify Packet Types</a>
        </h3>
<p id="section-5.10-1">A Control/Data Relay Server and end hosts can use NOTIFY packets to
 signal different error conditions. The NOTIFY packet types are the
 same as in Legacy ICE-HIP <span>[<a href="#RFC5770" class="xref">RFC5770</a>]</span>
 except for the two last ones, which are new.<a href="#section-5.10-1" class="pilcrow">¶</a></p>
<p id="section-5.10-2">The Notify Packet Types <span>[<a href="#RFC7401" class="xref">RFC7401</a>]</span>
 are shown below. The Notification Data field for the error
 notifications <span class="bcp14">SHOULD</span> contain the HIP header of the
 rejected packet and <span class="bcp14">SHOULD</span> be empty for the
 CONNECTIVITY_CHECKS_FAILED type.<a href="#section-5.10-2" class="pilcrow">¶</a></p>
<span id="name-notify-packet-types-2"></span><div id="notif-param-error-types">
<table class="center" id="table-3">
          <caption>
<a href="#table-3" class="selfRef">Table 3</a>:
<a href="#name-notify-packet-types-2" class="selfRef">Notify Packet Types</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">NOTIFICATION PARAMETER - ERROR TYPES</th>
              <th class="text-left" rowspan="1" colspan="1">Value</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">
                <p id="section-5.10-3.2.1.1.1">NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER<a href="#section-5.10-3.2.1.1.1" class="pilcrow">¶</a></p>
<p id="section-5.10-3.2.1.1.2">If a Control Relay Server does not forward a base exchange packet due
      to a missing NAT traversal mode parameter, or the Initiator selects a
      NAT traversal mode that the (non-relay) Responder did not expect, the
      Control Relay Server or the Responder may send back a NOTIFY error
      packet with this type.<a href="#section-5.10-3.2.1.1.2" class="pilcrow">¶</a></p>
</td>
              <td class="text-left" rowspan="1" colspan="1">60</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">
                <p id="section-5.10-3.2.2.1.1">CONNECTIVITY_CHECKS_FAILED<a href="#section-5.10-3.2.2.1.1" class="pilcrow">¶</a></p>
<p id="section-5.10-3.2.2.1.2">Used by the end hosts to signal that NAT traversal                             
      connectivity checks failed and did not produce a working path.<a href="#section-5.10-3.2.2.1.2" class="pilcrow">¶</a></p>
</td>
              <td class="text-left" rowspan="1" colspan="1">61</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">
                <p id="section-5.10-3.2.3.1.1">MESSAGE_NOT_RELAYED<a href="#section-5.10-3.2.3.1.1" class="pilcrow">¶</a></p>
<p id="section-5.10-3.2.3.1.2">Used by a Control Relay Server to signal that it was not able or
      willing to relay a HIP packet.<a href="#section-5.10-3.2.3.1.2" class="pilcrow">¶</a></p>
</td>
              <td class="text-left" rowspan="1" colspan="1">62</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">
                <p id="section-5.10-3.2.4.1.1">SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED<a href="#section-5.10-3.2.4.1.1" class="pilcrow">¶</a></p>
<p id="section-5.10-3.2.4.1.2">Used by a Data Relay Server to signal that it was not able or
      willing to allocate a new server-reflexive candidate for the Data
      Relay Client.<a href="#section-5.10-3.2.4.1.2" class="pilcrow">¶</a></p>
</td>
              <td class="text-left" rowspan="1" colspan="1">63</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">
                <p id="section-5.10-3.2.5.1.1">RVS_HMAC_PROHIBITED_WITH_RELAY<a href="#section-5.10-3.2.5.1.1" class="pilcrow">¶</a></p>
<p id="section-5.10-3.2.5.1.2">In the unintended event that a Control Relay Server sends any HIP
      message with an RVS_HMAC parameter, the Control Relay Client drops the
      received HIP message and sends a notify message back to the  Control
      Relay Server using this notify type.<a href="#section-5.10-3.2.5.1.2" class="pilcrow">¶</a></p>
</td>
              <td class="text-left" rowspan="1" colspan="1">64</td>
            </tr>
          </tbody>
        </table>
</div>
</section>
</div>
<div id="sec_udpesp">
<section id="section-5.11">
        <h3 id="name-esp-data-packets">
<a href="#section-5.11" class="section-number selfRef">5.11. </a><a href="#name-esp-data-packets" class="section-name selfRef">ESP Data Packets</a>
        </h3>
<p id="section-5.11-1">The format for ESP data packets is identical to Legacy ICE-HIP
 <span>[<a href="#RFC5770" class="xref">RFC5770</a>]</span>.<a href="#section-5.11-1" class="pilcrow">¶</a></p>
<p id="section-5.11-2"> <span>[<a href="#RFC3948" class="xref">RFC3948</a>]</span> describes the UDP encapsulation of the
        IPsec ESP transport and tunnel mode. On the wire, the HIP ESP packets
        do not differ from the transport mode ESP; thus, the encapsulation
        of the HIP ESP packets is same as the UDP encapsulation transport mode
        ESP. However, the (semantic) difference to Bound End-to-End Tunnel
        (BEET) mode ESP packets used by HIP is that the IP header is not used in
        BEET integrity protection calculation.<a href="#section-5.11-2" class="pilcrow">¶</a></p>
<p id="section-5.11-3"> During the HIP base exchange, the two peers exchange parameters
        that enable them to define a pair of IPsec ESP security associations
        (SAs) as described in <span>[<a href="#RFC7402" class="xref">RFC7402</a>]</span>. When two peers perform
        a UDP-encapsulated base exchange, they <span class="bcp14">MUST</span> define a pair of IPsec SAs
        that produces UDP-encapsulated ESP data traffic.<a href="#section-5.11-3" class="pilcrow">¶</a></p>
<p id="section-5.11-4"> The management of encryption/authentication protocols and SPIs is
 defined in <span>[<a href="#RFC7402" class="xref">RFC7402</a>]</span>. The UDP
 encapsulation format and processing of HIP ESP traffic is described in
 <span><a href="https://www.rfc-editor.org/rfc/rfc7402#section-6.1" class="relref">Section 6.1</a> of [<a href="#RFC7402" class="xref">RFC7402</a>]</span>.<a href="#section-5.11-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec_relayed_address">
<section id="section-5.12">
        <h3 id="name-relayed_address-and-mapped_">
<a href="#section-5.12" class="section-number selfRef">5.12. </a><a href="#name-relayed_address-and-mapped_" class="section-name selfRef">RELAYED_ADDRESS and MAPPED_ADDRESS Parameters</a>
        </h3>
<p id="section-5.12-1">While the type values are new, the format of the RELAYED_ADDRESS
        and MAPPED_ADDRESS parameters (<a href="#fig_relayed_address" class="xref">Figure 12</a>) is identical to REG_FROM, RELAY_FROM, and RELAY_TO
        parameters. This document specifies only the use of UDP relaying;
        thus, only protocol 17 is allowed. However, future documents may
        specify support for other protocols.<a href="#section-5.12-1" class="pilcrow">¶</a></p>
<span id="name-format-of-the-relayed_addre"></span><div id="fig_relayed_address">
<figure id="figure-12">
          <div class="artwork art-text alignCenter" id="section-5.12-2.1">
<pre>
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Port              |    Protocol   |    Reserved   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                            Address                            |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
</div>
<figcaption><a href="#figure-12" class="selfRef">Figure 12</a>:
<a href="#name-format-of-the-relayed_addre" class="selfRef">Format of the RELAYED_ADDRESS and MAPPED_ADDRESS Parameters</a>
          </figcaption></figure>
</div>
<span class="break"></span><dl class="dlParallel" id="section-5.12-3">
          <dt id="section-5.12-3.1">Type:</dt>
          <dd style="margin-left: 6.0em" id="section-5.12-3.2">
            <span class="break"></span><dl class="dlParallel dlCompact" id="section-5.12-3.2.1">
              <dt id="section-5.12-3.2.1.1">RELAYED_ADDRESS:</dt>
              <dd style="margin-left: 1.5em" id="section-5.12-3.2.1.2">4650<a href="#section-5.12-3.2.1.2" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-5.12-3.2.1.3">MAPPED_ADDRESS:</dt>
              <dd style="margin-left: 1.5em" id="section-5.12-3.2.1.4">4660<a href="#section-5.12-3.2.1.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
</dd>
          <dd class="break"></dd>
<dt id="section-5.12-3.3">Length:</dt>
          <dd style="margin-left: 6.0em" id="section-5.12-3.4">20<a href="#section-5.12-3.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.12-3.5">Port:</dt>
          <dd style="margin-left: 6.0em" id="section-5.12-3.6">The UDP port number<a href="#section-5.12-3.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.12-3.7">Protocol:</dt>
          <dd style="margin-left: 6.0em" id="section-5.12-3.8">IANA-assigned, Internet Protocol number (17 for UDP)<a href="#section-5.12-3.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.12-3.9">Reserved:</dt>
          <dd style="margin-left: 6.0em" id="section-5.12-3.10">Reserved for future use; zero when sent, ignored when received<a href="#section-5.12-3.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.12-3.11">Address:</dt>
          <dd style="margin-left: 6.0em" id="section-5.12-3.12">An IPv6 address or an IPv4 address in "IPv4-mapped IPv6 address"
  format<a href="#section-5.12-3.12" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="sec_peer_permission">
<section id="section-5.13">
        <h3 id="name-peer_permission-parameter">
<a href="#section-5.13" class="section-number selfRef">5.13. </a><a href="#name-peer_permission-parameter" class="section-name selfRef">PEER_PERMISSION Parameter</a>
        </h3>
<p id="section-5.13-1"> The format of the new PEER_PERMISSION parameter is shown in <a href="#fig_peer_permission" class="xref">Figure 13</a>. The parameter is used
 for setting up and refreshing forwarding rules and the permissions for
 data packets at the Data Relay Server. The parameter contains one or
 more sets of Port, Protocol, Address, Outbound SPI (OSPI), and Inbound
 SPI (ISPI) values. One set defines a rule for one peer address.<a href="#section-5.13-1" class="pilcrow">¶</a></p>
<span id="name-format-of-the-peer_permissi"></span><div id="fig_peer_permission">
<figure id="figure-13">
          <div class="artwork art-text alignCenter" id="section-5.13-2.1">
<pre>
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            RPort              |             PPort             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Protocol    |          Reserved                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                            RAddress                           |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                            PAddress                           |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              OSPI                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              ISPI                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
</div>
<figcaption><a href="#figure-13" class="selfRef">Figure 13</a>:
<a href="#name-format-of-the-peer_permissi" class="selfRef">Format of the PEER_PERMISSION Parameter</a>
          </figcaption></figure>
</div>
<span class="break"></span><dl class="dlParallel" id="section-5.13-3">
          <dt id="section-5.13-3.1">Type:</dt>
          <dd style="margin-left: 6.0em" id="section-5.13-3.2">4680<a href="#section-5.13-3.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.13-3.3">Length:</dt>
          <dd style="margin-left: 6.0em" id="section-5.13-3.4">48<a href="#section-5.13-3.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.13-3.5">RPort:</dt>
          <dd style="margin-left: 6.0em" id="section-5.13-3.6">The transport-layer (UDP) port at the Data Relay Server (i.e., the port
  of the server-reflexive candidate)<a href="#section-5.13-3.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.13-3.7">PPort:</dt>
          <dd style="margin-left: 6.0em" id="section-5.13-3.8">The transport-layer (UDP) port number of the peer<a href="#section-5.13-3.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.13-3.9">Protocol:</dt>
          <dd style="margin-left: 6.0em" id="section-5.13-3.10">IANA-assigned, Internet Protocol number (17 for UDP)<a href="#section-5.13-3.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.13-3.11">Reserved:</dt>
          <dd style="margin-left: 6.0em" id="section-5.13-3.12">Reserved for future use; zero when sent, ignored when received<a href="#section-5.13-3.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.13-3.13">RAddress:</dt>
          <dd style="margin-left: 6.0em" id="section-5.13-3.14">An IPv6 address, or an IPv4 address in "IPv4-mapped IPv6 address"
  format, of the server-reflexive candidate<a href="#section-5.13-3.14" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.13-3.15">PAddress:</dt>
          <dd style="margin-left: 6.0em" id="section-5.13-3.16">An IPv6 address, or an IPv4 address in "IPv4-mapped IPv6 address"
  format, of the peer<a href="#section-5.13-3.16" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.13-3.17">OSPI:</dt>
          <dd style="margin-left: 6.0em" id="section-5.13-3.18">The outbound SPI value the Data Relay Client is using for the peer<a href="#section-5.13-3.18" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.13-3.19">ISPI:</dt>
          <dd style="margin-left: 6.0em" id="section-5.13-3.20">The inbound SPI value the Data Relay Client is using for the peer<a href="#section-5.13-3.20" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="sec_con-check">
<section id="section-5.14">
        <h3 id="name-hip-connectivity-check-pack">
<a href="#section-5.14" class="section-number selfRef">5.14. </a><a href="#name-hip-connectivity-check-pack" class="section-name selfRef">HIP Connectivity Check Packets</a>
        </h3>
<p id="section-5.14-1">The connectivity request messages are HIP UPDATE packets containing
 a new CANDIDATE_PRIORITY parameter (<a href="#fig_candidate_priority" class="xref">Figure 14</a>). Response UPDATE
 packets contain a MAPPED_ADDRESS parameter (<a href="#fig_relayed_address" class="xref">Figure 12</a>).<a href="#section-5.14-1" class="pilcrow">¶</a></p>
<span id="name-format-of-the-candidate_pri"></span><div id="fig_candidate_priority">
<figure id="figure-14">
          <div class="artwork art-text alignCenter" id="section-5.14-2.1">
<pre>
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Priority                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
</div>
<figcaption><a href="#figure-14" class="selfRef">Figure 14</a>:
<a href="#name-format-of-the-candidate_pri" class="selfRef">Format of the CANDIDATE_PRIORITY Parameter</a>
          </figcaption></figure>
</div>
<span class="break"></span><dl class="dlParallel" id="section-5.14-3">
          <dt id="section-5.14-3.1">Type:</dt>
          <dd style="margin-left: 6.0em" id="section-5.14-3.2">4700<a href="#section-5.14-3.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.14-3.3">Length:</dt>
          <dd style="margin-left: 6.0em" id="section-5.14-3.4">4<a href="#section-5.14-3.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.14-3.5">Priority:</dt>
          <dd style="margin-left: 6.0em" id="section-5.14-3.6">The priority of a (potential) peer-reflexive candidate<a href="#section-5.14-3.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="sec_nominate">
<section id="section-5.15">
        <h3 id="name-nominate-parameter">
<a href="#section-5.15" class="section-number selfRef">5.15. </a><a href="#name-nominate-parameter" class="section-name selfRef">NOMINATE Parameter</a>
        </h3>
<p id="section-5.15-1"><a href="#fig_nominate" class="xref">Figure 15</a> shows the NOMINATE
        parameter that is used to conclude the candidate nomination
 process.<a href="#section-5.15-1" class="pilcrow">¶</a></p>
<span id="name-format-of-the-nominate-para"></span><div id="fig_nominate">
<figure id="figure-15">
          <div class="artwork art-text alignCenter" id="section-5.15-2.1">
<pre>
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Reserved                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
</div>
<figcaption><a href="#figure-15" class="selfRef">Figure 15</a>:
<a href="#name-format-of-the-nominate-para" class="selfRef">Format of the NOMINATE Parameter</a>
          </figcaption></figure>
</div>
<span class="break"></span><dl class="dlParallel" id="section-5.15-3">
          <dt id="section-5.15-3.1">Type:</dt>
          <dd style="margin-left: 6.0em" id="section-5.15-3.2">4710<a href="#section-5.15-3.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.15-3.3">Length:</dt>
          <dd style="margin-left: 6.0em" id="section-5.15-3.4">4<a href="#section-5.15-3.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.15-3.5">Reserved:</dt>
          <dd style="margin-left: 6.0em" id="section-5.15-3.6">Reserved for future extension purposes<a href="#section-5.15-3.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
</section>
</div>
<section id="section-6">
      <h2 id="name-iab-considerations">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-iab-considerations" class="section-name selfRef">IAB Considerations</a>
      </h2>
<p id="section-6-1">The ICE specification <span>[<a href="#RFC8445" class="xref">RFC8445</a>]</span> discusses
      "Unilateral Self-Address Fixing" in Section <a href="https://www.rfc-editor.org/rfc/rfc8445#section-18" class="relref">18</a>. This protocol is based on ICE; thus,
      the same considerations also apply here.<a href="#section-6-1" class="pilcrow">¶</a></p>
</section>
<section id="section-7">
      <h2 id="name-security-considerations">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-7-1">Since the control plane protocol and Control Relay Server are
      essentially the same (with some minor differences) in this document as
      in Legacy ICE-HIP <span>[<a href="#RFC5770" class="xref">RFC5770</a>]</span>, the same
      security considerations (in Sections <a href="#sec_privacy" class="xref">7.1</a>, <a href="#sec_opportunistic" class="xref">7.2</a>,
      <a href="#sec_bex_replay" class="xref">7.3</a>, and <a href="#sec_demux" class="xref">7.4</a>) are still valid, but are
      repeated here for the sake of completeness. New security considerations
      related to the new Data Relay Server are discussed in <a href="#sec_reuse" class="xref">Section 7.5</a>, and considerations related to the
      new connectivity check protocol are discussed in Sections <a href="#sec_amplification" class="xref">7.6</a> and  <a href="#sec_conn_attack" class="xref">7.7</a>.<a href="#section-7-1" class="pilcrow">¶</a></p>
<div id="sec_privacy">
<section id="section-7.1">
        <h3 id="name-privacy-considerations">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-privacy-considerations" class="section-name selfRef">Privacy Considerations</a>
        </h3>
<p id="section-7.1-1"> It is also possible that end users may not want to reveal all
        locators to each other. For example, tracking the physical location of
        a multihoming end host may become easier if it reveals all locators to
        its peer during a base exchange. Also, revealing host addresses exposes
        information about the local topology that may not be allowed in all
        corporate environments.
 For these two local policy reasons, it might be tempting to exclude
        certain host addresses from the LOCATOR_SET parameter of an end host, but
 this is <span class="bcp14">NOT RECOMMENDED</span>.

 For instance, such
        behavior creates non-optimal paths when the hosts are located behind
        the same NAT. Especially, this could be problematic with a legacy NAT
        that does not support routing from the private address realm back to
        itself through the outer address of the NAT. This scenario is referred
        to as the hairpin problem <span>[<a href="#RFC5128" class="xref">RFC5128</a>]</span>. With such a legacy
        NAT, the only option left would be to use a relayed transport address
        from a Data Relay Server.<a href="#section-7.1-1" class="pilcrow">¶</a></p>
<p id="section-7.1-2"> The use of Control and Data Relay Servers can also be useful for
        privacy purposes. For example, a privacy-concerned Responder may reveal
        only its Control Relay Server and Relayed candidates to Initiators. This
        partially protects the Responder against Denial-of-Service (DoS)
        attacks by allowing the Responder to initiate new connections even if
        its relays would be unavailable due to a DoS attack.<a href="#section-7.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec_opportunistic">
<section id="section-7.2">
        <h3 id="name-opportunistic-mode">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-opportunistic-mode" class="section-name selfRef">Opportunistic Mode</a>
        </h3>
<p id="section-7.2-1">In opportunistic HIP mode (cf. <span><a href="https://www.rfc-editor.org/rfc/rfc7401#section-4.1.8" class="relref">Section 4.1.8</a> of [<a href="#RFC7401" class="xref">RFC7401</a>]</span>), an Initiator sends an I1
        without setting the destination HIT of the Responder (i.e., the
        Control Relay Client). A Control Relay Server <span class="bcp14">SHOULD</span>
        have a unique IP address per the Control Relay Client when the Control
        Relay Server is serving more than one Control Relay Client and
        supports opportunistic mode. Otherwise, the Control Relay Server
        cannot guarantee to deliver the I1 packet to the intended recipient.
        Future extensions of this document may allow opportunistic mode to be
        used with non-unique IP addresses to be utilized either as a HIP-level
        anycast or multicast mechanism. Both of the mentioned cases would
        require separate registration parameters that the Control Relay
        Server proposes and the Control Client Server accepts during
        registration.<a href="#section-7.2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec_bex_replay">
<section id="section-7.3">
        <h3 id="name-base-exchange-replay-protec">
<a href="#section-7.3" class="section-number selfRef">7.3. </a><a href="#name-base-exchange-replay-protec" class="section-name selfRef">Base Exchange Replay Protection for Control Relay Server</a>
        </h3>
<p id="section-7.3-1"> In certain scenarios, it is possible that an attacker, or two
        attackers, can replay an earlier base exchange through a Control Relay Server
        by masquerading as the original Initiator and Responder. The
        attack does not require the attacker(s) to compromise the private
        key(s) of the attacked host(s). However, for this attack to succeed,
        the legitimate Responder has to be disconnected from the Control Relay Server.<a href="#section-7.3-1" class="pilcrow">¶</a></p>
<p id="section-7.3-2"> The Control Relay Server can protect itself against replay attacks by becoming
        involved in the base exchange by introducing nonces that the end hosts
        (Initiator and Responder) are required to sign. One way to do this is
        to add ECHO_REQUEST_M parameters to the R1 and I2 packets as described
        in <span>[<a href="#I-D.heer-hip-middle-auth" class="xref">HIP-MIDDLEBOXES</a>]</span> and drop the I2 or R2
        packets if the corresponding ECHO_RESPONSE_M parameters are not
        present.<a href="#section-7.3-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec_demux">
<section id="section-7.4">
        <h3 id="name-demultiplexing-different-hi">
<a href="#section-7.4" class="section-number selfRef">7.4. </a><a href="#name-demultiplexing-different-hi" class="section-name selfRef">Demultiplexing Different HIP Associations</a>
        </h3>
<p id="section-7.4-1"><span><a href="https://www.rfc-editor.org/rfc/rfc3948#section-5.1" class="relref">Section 5.1</a> of [<a href="#RFC3948" class="xref">RFC3948</a>]</span> describes
 a security issue for the UDP encapsulation in the standard IP tunnel
 mode when two hosts behind different NATs have the same private IP
 address and initiate communication to the same Responder in the public
 Internet. The Responder cannot distinguish between two hosts because
 security associations are based on the same inner IP addresses.<a href="#section-7.4-1" class="pilcrow">¶</a></p>
<p id="section-7.4-2"> This issue does not exist with the UDP encapsulation of HIP ESP
        transport format because the Responder uses HITs to distinguish between
        different Initiators.<a href="#section-7.4-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec_reuse">
<section id="section-7.5">
        <h3 id="name-reuse-of-ports-at-the-data-">
<a href="#section-7.5" class="section-number selfRef">7.5. </a><a href="#name-reuse-of-ports-at-the-data-" class="section-name selfRef">Reuse of Ports at the Data Relay Server</a>
        </h3>
<p id="section-7.5-1"> If the Data Relay Server uses the same relayed address and port
 (as conveyed in the RELAYED_ADDRESS parameter) for multiple Data Relay
 Clients, it appears to all the peers, and their firewalls, that all
 the Data Relay Clients are at the same address. Thus, a stateful
 firewall may allow packets to pass from hosts that would not normally be
 able to send packets to a peer behind the firewall. Therefore, a Data
 Relay Server <span class="bcp14">SHOULD NOT</span> reuse the port numbers. If
 port numbers need to be reused, the Data Relay Server
 <span class="bcp14">SHOULD</span> have a sufficiently large pool of port numbers
 and randomly select ports from the pool to decrease the chances of a
 Data Relay Client obtaining the same address that another host
 behind the same firewall is using.<a href="#section-7.5-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec_amplification">
<section id="section-7.6">
        <h3 id="name-amplification-attacks">
<a href="#section-7.6" class="section-number selfRef">7.6. </a><a href="#name-amplification-attacks" class="section-name selfRef">Amplification Attacks</a>
        </h3>
<p id="section-7.6-1">A malicious host may send an invalid list of candidates to
 its peer that are used for targeting a victim host by flooding
 it with connectivity checks. To mitigate the attack, this
 protocol adopts the ICE mechanism to cap the total amount of
 connectivity checks as defined in <a href="#sec_alternatives" class="xref">Section 4.7</a>.<a href="#section-7.6-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec_conn_attack">
<section id="section-7.7">
        <h3 id="name-attacks-against-connectivit">
<a href="#section-7.7" class="section-number selfRef">7.7. </a><a href="#name-attacks-against-connectivit" class="section-name selfRef">Attacks against Connectivity Checks and Candidate Gathering</a>
        </h3>
<p id="section-7.7-1"><span><a href="https://www.rfc-editor.org/rfc/rfc8445#section-19.2" class="relref">Section 19.2</a> of [<a href="#RFC8445" class="xref">RFC8445</a>]</span>
        describes attacks against ICE connectivity checks. HIP bases its
        control plane security on Diffie-Hellman key exchange, public keys,
        and Hashed Message Authentication codes, meaning that the mentioned
        security concerns do not apply to HIP either. The mentioned section
        also discusses man-in-the-middle replay attacks that are difficult to
        prevent. The connectivity checks in this protocol are effectively
        immune against replay attacks because a connectivity request includes
        a random nonce that the recipient must sign and send back as a
        response.<a href="#section-7.7-1" class="pilcrow">¶</a></p>
<p id="section-7.7-2"><span><a href="https://www.rfc-editor.org/rfc/rfc8445#section-19.3" class="relref">Section 19.3</a> of [<a href="#RFC8445" class="xref">RFC8445</a>]</span>
 describes attacks on server-reflexive address
 gathering. Similarly here, if the DNS, a Control Relay Server, or a Data Relay Server
 has been compromised, not much can be done. However,
 the case where attackers can inject fake messages (located on a
 shared network segment like Wi-Fi) does not apply here. HIP
 messages are integrity and replay protected, so it is not
 possible to inject fake server-reflexive address candidates.<a href="#section-7.7-2" class="pilcrow">¶</a></p>
<p id="section-7.7-3"><span><a href="https://www.rfc-editor.org/rfc/rfc8445#section-19.4" class="relref">Section 19.4</a> of [<a href="#RFC8445" class="xref">RFC8445</a>]</span>
 describes attacks on relayed candidate gathering. Similarly to
 ICE TURN servers, a Data Relay Server requires an authenticated base
 exchange that protects relayed address gathering against fake
 requests and responses. Further, replay attacks are not
 possible because the HIP base exchange (and also UPDATE
 procedure) is protected against replay attacks.<a href="#section-7.7-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec_cross_protocol">
<section id="section-7.8">
        <h3 id="name-cross-protocol-attacks">
<a href="#section-7.8" class="section-number selfRef">7.8. </a><a href="#name-cross-protocol-attacks" class="section-name selfRef">Cross-Protocol Attacks</a>
        </h3>
<p id="section-7.8-1"><a href="#sec_registration" class="xref">Section 4.1</a> explains how a
        Control Relay Client registers for the RELAY_UDP_HIP service from a
        Control Relay Server. However, the same server may also offer
        Rendezvous functionality; thus, a client can register both to a
        RELAY_UDP_HIP and a RENDEZVOUS (see <span>[<a href="#RFC8004" class="xref">RFC8004</a>]</span>) service from the same server. Potentially, this
        introduces a cross-protocol attack (or actually a "cross-message"
        attack) because the key material is the same for the Control Relay
        Service and Rendezvous HMACs. While the problem could be avoided by
        deriving different keys for the Control Relay Service, a more simple
        measure was chosen because the exact attack scenario was
        unclear. Consequently, this section defines a mandatory mitigation
        mechanism against the cross-protocol attack that works by preventing
        the simultaneous use of Rendezvous and Control Relay Service in the
        context of a single HIP Association.<a href="#section-7.8-1" class="pilcrow">¶</a></p>
<p id="section-7.8-2">The registration involves three parameters typically
 delivered sequentially in R1 (REG_INFO parameter), I2
 (REG_REQUEST), and R2 (REG_RESPONSE) messages but can also be
 delivered in UPDATE messages as described in <span>[<a href="#RFC8003" class="xref">RFC8003</a>]</span>. The parameters and the 
 modifications to their processing are described below:<a href="#section-7.8-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-7.8-3">
          <dt id="section-7.8-3.1">REG_INFO:</dt>
          <dd style="margin-left: 1.5em" id="section-7.8-3.2">The Control Relay Server advertises its available services using
   this parameter. RELAY_UDP_HIP and RENDEZVOUS services
   <span class="bcp14">MAY</span> be included in the first advertisement for the
   HIP association, but subsequent ones <span class="bcp14">MUST</span> include only
   one of them as agreed in earlier registrations (see steps 2 and
   3).<a href="#section-7.8-3.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-7.8-3.3">REG_REQUEST:</dt>
          <dd style="margin-left: 1.5em" id="section-7.8-3.4">The Control Relay Client chooses the services it requires using
   this parameter. If the Control Relay Server offered both RENDEZVOUS
   or RELAY_UDP_HIP, the Control Relay Client <span class="bcp14">MUST</span>
   choose only one of them in the REG_REQUEST parameter. Upon choosing
   one of the two, it persists throughout the lifetime of the HIP
   association, and the Control Relay Client <span class="bcp14">MUST NOT</span>
   register the other remaining one in a subsequent UPDATE
   message.<a href="#section-7.8-3.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-7.8-3.5">REG_RESPONSE:</dt>
          <dd style="margin-left: 1.5em" id="section-7.8-3.6">The Control Relay Server verifies the services requested by the
   Control Relay Client using this parameter. If the Control Relay
   Server offered both RENDEZVOUS and RELAY_UDP_HIP service, and the
   Control Relay Client requested for both of them, the Control Relay
   Client <span class="bcp14">MUST</span> offer only RELAY_UDP_HIP service in the
   REG_RESPONSE parameter and include a REG_FAILED parameter in the
   same message, with RENDEZVOUS as the Registration Type and 
   9 as the Failure Type.<a href="#section-7.8-3.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-7.8-4">As a further measure against cross-protocol attacks, the Control Relay
 Client <span class="bcp14">MUST</span> drop any HIP message that includes an
 RVS_HMAC parameter when it originates from a successfully registered
 Control Relay Server. Upon such an (unintended) event, the Control
 Relay Client <span class="bcp14">MUST</span> send a NOTIFY message with
 RVS_HMAC_PROHIBITED_WITH_RELAY as the Notify Message Type to the
 Control Relay Server.<a href="#section-7.8-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
<div id="sec_iana">
<section id="section-8">
      <h2 id="name-iana-considerations">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-8-1"> This section is to be interpreted according to <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>.<a href="#section-8-1" class="pilcrow">¶</a></p>
<p id="section-8-2">This document reuses the same default UDP port number 10500 as
      specified by Legacy ICE-HIP <span>[<a href="#RFC5770" class="xref">RFC5770</a>]</span>
      for tunneling both HIP control and data plane traffic. The port was
      registered separately for <span>[<a href="#RFC5770" class="xref">RFC5770</a>]</span> to
      coauthor <span class="contact-name">Ari Keränen</span> originally, but it has been
      reassigned for IESG control. With the permission of <span class="contact-name">Ari Keränen</span>, the new assignee is the IESG and the contact
      is &lt;chair@ietf.org&gt;. In addition, IANA has added a reference to
      this document in the entry for UDP port 10500 in the "Service Name and
      Transport Protocol Port Number Registry". The selection between Legacy
      ICE-HIP and Native ICE-HIP mode is negotiated using the
      NAT_TRAVERSAL_MODE parameter during the base exchange. By default, hosts
      listen to this port for incoming UDP datagrams and can also use it for
      sending UDP datagrams. Other ephemeral port numbers are negotiated and
      utilized dynamically.<a href="#section-8-2" class="pilcrow">¶</a></p>
<p id="section-8-3">IANA has assigned the following values in the HIP "Parameter Types" registry 
      <span>[<a href="#RFC7401" class="xref">RFC7401</a>]</span>: 
      4650 for RELAYED_ADDRESS (length 20),
      4660 for MAPPED_ADDRESS (length 20; defined in <a href="#sec_relayed_address" class="xref">Section 5.12</a>), 
      4680 for PEER_PERMISSION (length 48; defined in <a href="#sec_peer_permission" class="xref">Section 5.13</a>), 
      4700 for CANDIDATE_PRIORITY
      (length 4; defined in <a href="#sec_con-check" class="xref">Section 5.14</a>), and 
      4710 for NOMINATE (length 4; defined in <a href="#sec_nominate" class="xref">Section 5.15</a>).<a href="#section-8-3" class="pilcrow">¶</a></p>
<p id="section-8-4">IANA has assigned the following value in the "HIP NAT Traversal Modes"
      registry specified in Legacy ICE-HIP <span>[<a href="#RFC5770" class="xref">RFC5770</a>]</span>:
      3 for ICE-HIP-UDP (defined in <a href="#sec_nat_tm-param" class="xref">Section 5.4</a>).<a href="#section-8-4" class="pilcrow">¶</a></p>
<p id="section-8-5">IANA has assigned the following values in the HIP "Notify Message Types" registry:
      16385 for NAT_KEEPALIVE in <a href="#sec_keepalive" class="xref">Section 5.3</a>, 63 for 
      SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED in <a href="#sec_notify-types" class="xref">Section 5.10</a>, and 64 for
      RVS_HMAC_PROHIBITED_WITH_RELAY in <a href="#sec_notify-types" class="xref">Section 5.10</a>.<a href="#section-8-5" class="pilcrow">¶</a></p>
<p id="section-8-6"> IANA has assigned the following values in the "Registration Types" registry for the HIP
      Registration Extension <span>[<a href="#RFC8003" class="xref">RFC8003</a>]</span>:
      3 for RELAY_UDP_ESP (defined in <a href="#sec_reg-types" class="xref">Section 5.9</a>) for allowing registration with a Data Relay Server for ESP-relaying service, and
      4 for CANDIDATE_DISCOVERY (defined in <a href="#sec_gathering" class="xref">Section 4.2</a>) for performing server-reflexive candidate discovery.<a href="#section-8-6" class="pilcrow">¶</a></p>
<p id="section-8-7">IANA has assigned one value in the "Registration Failure Types" registry as
      defined in <a href="#sec_cross_protocol" class="xref">Section 7.8</a>. The
      value is 9, and the Registration Failure Type is
      "Simultaneous Rendezvous and Control Relay Service usage
      prohibited".<a href="#section-8-7" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-9">
      <h2 id="name-references">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-9.1">
        <h3 id="name-normative-references">
<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC1191">[RFC1191]</dt>
        <dd>
<span class="refAuthor">Mogul, J.</span> and <span class="refAuthor">S. Deering</span>, <span class="refTitle">"Path MTU discovery"</span>, <span class="seriesInfo">RFC 1191</span>, <span class="seriesInfo">DOI 10.17487/RFC1191</span>, <time datetime="1990-11" class="refDate">November 1990</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1191">https://www.rfc-editor.org/info/rfc1191</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="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="RFC4291">[RFC4291]</dt>
        <dd>
<span class="refAuthor">Hinden, R.</span> and <span class="refAuthor">S. Deering</span>, <span class="refTitle">"IP Version 6 Addressing Architecture"</span>, <span class="seriesInfo">RFC 4291</span>, <span class="seriesInfo">DOI 10.17487/RFC4291</span>, <time datetime="2006-02" class="refDate">February 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4291">https://www.rfc-editor.org/info/rfc4291</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5770">[RFC5770]</dt>
        <dd>
<span class="refAuthor">Komu, M.</span>, <span class="refAuthor">Henderson, T.</span>, <span class="refAuthor">Tschofenig, H.</span>, <span class="refAuthor">Melen, J.</span>, and <span class="refAuthor">A. Keranen, Ed.</span>, <span class="refTitle">"Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators"</span>, <span class="seriesInfo">RFC 5770</span>, <span class="seriesInfo">DOI 10.17487/RFC5770</span>, <time datetime="2010-04" class="refDate">April 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5770">https://www.rfc-editor.org/info/rfc5770</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7050">[RFC7050]</dt>
        <dd>
<span class="refAuthor">Savolainen, T.</span>, <span class="refAuthor">Korhonen, J.</span>, and <span class="refAuthor">D. Wing</span>, <span class="refTitle">"Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis"</span>, <span class="seriesInfo">RFC 7050</span>, <span class="seriesInfo">DOI 10.17487/RFC7050</span>, <time datetime="2013-11" class="refDate">November 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7050">https://www.rfc-editor.org/info/rfc7050</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7401">[RFC7401]</dt>
        <dd>
<span class="refAuthor">Moskowitz, R., Ed.</span>, <span class="refAuthor">Heer, T.</span>, <span class="refAuthor">Jokela, P.</span>, and <span class="refAuthor">T. Henderson</span>, <span class="refTitle">"Host Identity Protocol Version 2 (HIPv2)"</span>, <span class="seriesInfo">RFC 7401</span>, <span class="seriesInfo">DOI 10.17487/RFC7401</span>, <time datetime="2015-04" class="refDate">April 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7401">https://www.rfc-editor.org/info/rfc7401</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7402">[RFC7402]</dt>
        <dd>
<span class="refAuthor">Jokela, P.</span>, <span class="refAuthor">Moskowitz, R.</span>, and <span class="refAuthor">J. Melen</span>, <span class="refTitle">"Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)"</span>, <span class="seriesInfo">RFC 7402</span>, <span class="seriesInfo">DOI 10.17487/RFC7402</span>, <time datetime="2015-04" class="refDate">April 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7402">https://www.rfc-editor.org/info/rfc7402</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8003">[RFC8003]</dt>
        <dd>
<span class="refAuthor">Laganier, J.</span> and <span class="refAuthor">L. Eggert</span>, <span class="refTitle">"Host Identity Protocol (HIP) Registration Extension"</span>, <span class="seriesInfo">RFC 8003</span>, <span class="seriesInfo">DOI 10.17487/RFC8003</span>, <time datetime="2016-10" class="refDate">October 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8003">https://www.rfc-editor.org/info/rfc8003</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8004">[RFC8004]</dt>
        <dd>
<span class="refAuthor">Laganier, J.</span> and <span class="refAuthor">L. Eggert</span>, <span class="refTitle">"Host Identity Protocol (HIP) Rendezvous Extension"</span>, <span class="seriesInfo">RFC 8004</span>, <span class="seriesInfo">DOI 10.17487/RFC8004</span>, <time datetime="2016-10" class="refDate">October 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8004">https://www.rfc-editor.org/info/rfc8004</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8005">[RFC8005]</dt>
        <dd>
<span class="refAuthor">Laganier, J.</span>, <span class="refTitle">"Host Identity Protocol (HIP) Domain Name System (DNS) Extension"</span>, <span class="seriesInfo">RFC 8005</span>, <span class="seriesInfo">DOI 10.17487/RFC8005</span>, <time datetime="2016-10" class="refDate">October 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8005">https://www.rfc-editor.org/info/rfc8005</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8046">[RFC8046]</dt>
        <dd>
<span class="refAuthor">Henderson, T., Ed.</span>, <span class="refAuthor">Vogt, C.</span>, and <span class="refAuthor">J. Arkko</span>, <span class="refTitle">"Host Mobility with the Host Identity Protocol"</span>, <span class="seriesInfo">RFC 8046</span>, <span class="seriesInfo">DOI 10.17487/RFC8046</span>, <time datetime="2017-02" class="refDate">February 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8046">https://www.rfc-editor.org/info/rfc8046</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8047">[RFC8047]</dt>
        <dd>
<span class="refAuthor">Henderson, T., Ed.</span>, <span class="refAuthor">Vogt, C.</span>, and <span class="refAuthor">J. Arkko</span>, <span class="refTitle">"Host Multihoming with the Host Identity Protocol"</span>, <span class="seriesInfo">RFC 8047</span>, <span class="seriesInfo">DOI 10.17487/RFC8047</span>, <time datetime="2017-02" class="refDate">February 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8047">https://www.rfc-editor.org/info/rfc8047</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8126">[RFC8126]</dt>
        <dd>
<span class="refAuthor">Cotton, M.</span>, <span class="refAuthor">Leiba, B.</span>, and <span class="refAuthor">T. Narten</span>, <span class="refTitle">"Guidelines for Writing an IANA Considerations Section in RFCs"</span>, <span class="seriesInfo">BCP 26</span>, <span class="seriesInfo">RFC 8126</span>, <span class="seriesInfo">DOI 10.17487/RFC8126</span>, <time datetime="2017-06" class="refDate">June 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8126">https://www.rfc-editor.org/info/rfc8126</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8174">[RFC8174]</dt>
        <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8201">[RFC8201]</dt>
        <dd>
<span class="refAuthor">McCann, J.</span>, <span class="refAuthor">Deering, S.</span>, <span class="refAuthor">Mogul, J.</span>, and <span class="refAuthor">R. Hinden, Ed.</span>, <span class="refTitle">"Path MTU Discovery for IP version 6"</span>, <span class="seriesInfo">STD 87</span>, <span class="seriesInfo">RFC 8201</span>, <span class="seriesInfo">DOI 10.17487/RFC8201</span>, <time datetime="2017-07" class="refDate">July 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8201">https://www.rfc-editor.org/info/rfc8201</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8445">[RFC8445]</dt>
        <dd>
<span class="refAuthor">Keranen, A.</span>, <span class="refAuthor">Holmberg, C.</span>, and <span class="refAuthor">J. Rosenberg</span>, <span class="refTitle">"Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal"</span>, <span class="seriesInfo">RFC 8445</span>, <span class="seriesInfo">DOI 10.17487/RFC8445</span>, <time datetime="2018-07" class="refDate">July 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8445">https://www.rfc-editor.org/info/rfc8445</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8489">[RFC8489]</dt>
        <dd>
<span class="refAuthor">Petit-Huguenin, M.</span>, <span class="refAuthor">Salgueiro, G.</span>, <span class="refAuthor">Rosenberg, J.</span>, <span class="refAuthor">Wing, D.</span>, <span class="refAuthor">Mahy, R.</span>, and <span class="refAuthor">P. Matthews</span>, <span class="refTitle">"Session Traversal Utilities for NAT (STUN)"</span>, <span class="seriesInfo">RFC 8489</span>, <span class="seriesInfo">DOI 10.17487/RFC8489</span>, <time datetime="2020-02" class="refDate">February 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8489">https://www.rfc-editor.org/info/rfc8489</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8961">[RFC8961]</dt>
      <dd>
<span class="refAuthor">Allman, M.</span>, <span class="refTitle">"Requirements for Time-Based Loss Detection"</span>, <span class="seriesInfo">BCP 233</span>, <span class="seriesInfo">RFC 8961</span>, <span class="seriesInfo">DOI 10.17487/RFC8961</span>, <time datetime="2020-11" class="refDate">November 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8961">https://www.rfc-editor.org/info/rfc8961</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-9.2">
        <h3 id="name-informative-references">
<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="I-D.heer-hip-middle-auth">[HIP-MIDDLEBOXES]</dt>
        <dd>
<span class="refAuthor">Heer, T.</span>, <span class="refAuthor">Hummen, R.</span>, <span class="refAuthor">Wehrle, K.</span>, and <span class="refAuthor">M. Komu</span>, <span class="refTitle">"End-Host Authentication for HIP Middleboxes"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-heer-hip-middle-auth-04</span>, <time datetime="2011-10-31" class="refDate">31 October 2011</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-heer-hip-middle-auth-04">https://datatracker.ietf.org/doc/html/draft-heer-hip-middle-auth-04</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.rosenberg-mmusic-ice-nonsip">[ICE-NONSIP]</dt>
        <dd>
<span class="refAuthor">Rosenberg, J.</span>, <span class="refTitle">"Guidelines for Usage of Interactive Connectivity Establishment (ICE) by non Session Initiation Protocol (SIP) Protocols"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-rosenberg-mmusic-ice-nonsip-01</span>, <time datetime="2008-07-14" class="refDate">14 July 2008</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-rosenberg-mmusic-ice-nonsip-01">https://datatracker.ietf.org/doc/html/draft-rosenberg-mmusic-ice-nonsip-01</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2475">[RFC2475]</dt>
        <dd>
<span class="refAuthor">Blake, S.</span>, <span class="refAuthor">Black, D.</span>, <span class="refAuthor">Carlson, M.</span>, <span class="refAuthor">Davies, E.</span>, <span class="refAuthor">Wang, Z.</span>, and <span class="refAuthor">W. Weiss</span>, <span class="refTitle">"An Architecture for Differentiated Services"</span>, <span class="seriesInfo">RFC 2475</span>, <span class="seriesInfo">DOI 10.17487/RFC2475</span>, <time datetime="1998-12" class="refDate">December 1998</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2475">https://www.rfc-editor.org/info/rfc2475</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3264">[RFC3264]</dt>
        <dd>
<span class="refAuthor">Rosenberg, J.</span> and <span class="refAuthor">H. Schulzrinne</span>, <span class="refTitle">"An Offer/Answer Model with Session Description Protocol (SDP)"</span>, <span class="seriesInfo">RFC 3264</span>, <span class="seriesInfo">DOI 10.17487/RFC3264</span>, <time datetime="2002-06" class="refDate">June 2002</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3264">https://www.rfc-editor.org/info/rfc3264</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3948">[RFC3948]</dt>
        <dd>
<span class="refAuthor">Huttunen, A.</span>, <span class="refAuthor">Swander, B.</span>, <span class="refAuthor">Volpe, V.</span>, <span class="refAuthor">DiBurro, L.</span>, and <span class="refAuthor">M. Stenberg</span>, <span class="refTitle">"UDP Encapsulation of IPsec ESP Packets"</span>, <span class="seriesInfo">RFC 3948</span>, <span class="seriesInfo">DOI 10.17487/RFC3948</span>, <time datetime="2005-01" class="refDate">January 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3948">https://www.rfc-editor.org/info/rfc3948</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5128">[RFC5128]</dt>
        <dd>
<span class="refAuthor">Srisuresh, P.</span>, <span class="refAuthor">Ford, B.</span>, and <span class="refAuthor">D. Kegel</span>, <span class="refTitle">"State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs)"</span>, <span class="seriesInfo">RFC 5128</span>, <span class="seriesInfo">DOI 10.17487/RFC5128</span>, <time datetime="2008-03" class="refDate">March 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5128">https://www.rfc-editor.org/info/rfc5128</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5207">[RFC5207]</dt>
        <dd>
<span class="refAuthor">Stiemerling, M.</span>, <span class="refAuthor">Quittek, J.</span>, and <span class="refAuthor">L. Eggert</span>, <span class="refTitle">"NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication"</span>, <span class="seriesInfo">RFC 5207</span>, <span class="seriesInfo">DOI 10.17487/RFC5207</span>, <time datetime="2008-04" class="refDate">April 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5207">https://www.rfc-editor.org/info/rfc5207</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5245">[RFC5245]</dt>
        <dd>
<span class="refAuthor">Rosenberg, J.</span>, <span class="refTitle">"Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols"</span>, <span class="seriesInfo">RFC 5245</span>, <span class="seriesInfo">DOI 10.17487/RFC5245</span>, <time datetime="2010-04" class="refDate">April 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5245">https://www.rfc-editor.org/info/rfc5245</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6146">[RFC6146]</dt>
        <dd>
<span class="refAuthor">Bagnulo, M.</span>, <span class="refAuthor">Matthews, P.</span>, and <span class="refAuthor">I. van Beijnum</span>, <span class="refTitle">"Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers"</span>, <span class="seriesInfo">RFC 6146</span>, <span class="seriesInfo">DOI 10.17487/RFC6146</span>, <time datetime="2011-04" class="refDate">April 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6146">https://www.rfc-editor.org/info/rfc6146</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6147">[RFC6147]</dt>
        <dd>
<span class="refAuthor">Bagnulo, M.</span>, <span class="refAuthor">Sullivan, A.</span>, <span class="refAuthor">Matthews, P.</span>, and <span class="refAuthor">I. van Beijnum</span>, <span class="refTitle">"DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers"</span>, <span class="seriesInfo">RFC 6147</span>, <span class="seriesInfo">DOI 10.17487/RFC6147</span>, <time datetime="2011-04" class="refDate">April 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6147">https://www.rfc-editor.org/info/rfc6147</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6538">[RFC6538]</dt>
        <dd>
<span class="refAuthor">Henderson, T.</span> and <span class="refAuthor">A. Gurtov</span>, <span class="refTitle">"The Host Identity Protocol (HIP) Experiment Report"</span>, <span class="seriesInfo">RFC 6538</span>, <span class="seriesInfo">DOI 10.17487/RFC6538</span>, <time datetime="2012-03" class="refDate">March 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6538">https://www.rfc-editor.org/info/rfc6538</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8656">[RFC8656]</dt>
        <dd>
<span class="refAuthor">Reddy, T., Ed.</span>, <span class="refAuthor">Johnston, A., Ed.</span>, <span class="refAuthor">Matthews, P.</span>, and <span class="refAuthor">J. Rosenberg</span>, <span class="refTitle">"Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)"</span>, <span class="seriesInfo">RFC 8656</span>, <span class="seriesInfo">DOI 10.17487/RFC8656</span>, <time datetime="2020-02" class="refDate">February 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8656">https://www.rfc-editor.org/info/rfc8656</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8750">[RFC8750]</dt>
        <dd>
<span class="refAuthor">Migault, D.</span>, <span class="refAuthor">Guggemos, T.</span>, and <span class="refAuthor">Y. Nir</span>, <span class="refTitle">"Implicit Initialization Vector (IV) for Counter-Based Ciphers in Encapsulating Security Payload (ESP)"</span>, <span class="seriesInfo">RFC 8750</span>, <span class="seriesInfo">DOI 10.17487/RFC8750</span>, <time datetime="2020-03" class="refDate">March 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8750">https://www.rfc-editor.org/info/rfc8750</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8899">[RFC8899]</dt>
        <dd>
<span class="refAuthor">Fairhurst, G.</span>, <span class="refAuthor">Jones, T.</span>, <span class="refAuthor">Tüxen, M.</span>, <span class="refAuthor">Rüngeler, I.</span>, and <span class="refAuthor">T. Völker</span>, <span class="refTitle">"Packetization Layer Path MTU Discovery for Datagram Transports"</span>, <span class="seriesInfo">RFC 8899</span>, <span class="seriesInfo">DOI 10.17487/RFC8899</span>, <time datetime="2020-09" class="refDate">September 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8899">https://www.rfc-editor.org/info/rfc8899</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9063">[RFC9063]</dt>
      <dd>
<span class="refAuthor">Moskowitz, R., Ed.</span> and <span class="refAuthor">M. Komu</span>, <span class="refTitle">"Host Identity Protocol Architecture"</span>, <span class="seriesInfo">RFC 9063</span>, <span class="seriesInfo">DOI 10.17487/RFC9063</span>, <time datetime="2021-07" class="refDate">July 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9063">https://www.rfc-editor.org/info/rfc9063</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="sec_selecting_pacing_value">
<section id="appendix-A">
      <h2 id="name-selecting-a-value-for-check">
<a href="#appendix-A" class="section-number selfRef">Appendix A. </a><a href="#name-selecting-a-value-for-check" class="section-name selfRef">Selecting a Value for Check Pacing</a>
      </h2>
<p id="appendix-A-1"> Selecting a suitable value for the connectivity check transaction
      pacing is essential for the performance of connectivity check-based NAT
      traversal. The value should not be so small that the checks cause
      network congestion or overwhelm the NATs.  On the other hand, a pacing
      value that is too high makes the checks last for a long time, thus
      increasing the connection setup delay.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
<p id="appendix-A-2"> The Ta value may be configured by the user in environments where the
      network characteristics are known beforehand. However, if the
      characteristics are not known, it is recommended that the value is
      adjusted dynamically. In this case, it is recommended that the hosts
      estimate the round-trip time (RTT) between them, and they
      <span class="bcp14">SHOULD</span> set the minimum Ta value so that at most a single
      connectivity check message is sent on every RTT.<a href="#appendix-A-2" class="pilcrow">¶</a></p>
<p id="appendix-A-3"> One way to estimate the RTT is to use the time that it takes for the
      Control Relay Server registration exchange to complete; this would give
      an estimate on the registering host's access link's RTT. Also, the I1/R1
      exchange could be used for estimating the RTT, but since the R1 can be
      cached in the network, or the relaying service can increase the delay
      notably, this is not recommended.  In general, estimating RTT can be
      difficult and error prone; thus, the guidelines for choosing a Ta value
      in <a href="#sec_check_pacing_neg" class="xref">Section 4.4</a>
        <span class="bcp14">MUST</span> be followed.<a href="#appendix-A-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec_ice_diff">
<section id="appendix-B">
      <h2 id="name-differences-with-respect-to">
<a href="#appendix-B" class="section-number selfRef">Appendix B. </a><a href="#name-differences-with-respect-to" class="section-name selfRef">Differences with Respect to ICE</a>
      </h2>
<p id="appendix-B-1">Legacy ICE-HIP reuses the ICE/STUN/TURN protocol stack as it is. The
      benefits of such as an approach include the reuse of STUN/TURN
      infrastructure and possibly the reuse of existing software libraries,
      but there are also drawbacks with the approach. For example, ICE is
      meant for application-layer protocols, whereas HIP operates at layer 3.5
      between transport and network layers. This is particularly problematic
      because the implementations employ kernel-space IPsec ESP as their data
      plane: demultiplexing of incoming ESP, HIP, and TURN messages required
      the capturing of all UDP packets destined to port 10500 to the userspace
      (due to different, incompatible markers in ESP and STUN), thus causing
      additional software complexity and an unnecessary latency/throughput
      bottleneck for the dataplane performance. It is also worth noting that
      the demultiplexing of STUN packets in the kernel would also incur a
      performance impact (albeit smaller than with userspace demultiplexing),
      and secure verification of STUN messages would require communication
      between the kernel-space STUN detector and HIP daemon typically residing
      in the userspace (thus again increasing the performance overhead).<a href="#appendix-B-1" class="pilcrow">¶</a></p>
<p id="appendix-B-2">Legacy ICE-HIP also involves some other complexities when compared to
      the approach taken in this document.  The relaying of ESP packets via
      TURN relays was not considered that simple because TURN relays require
      adding and removing extra TURN framing for the relayed packets. Finally,
      the developers of the two Legacy ICE-HIP implementations concluded that
           
effort needed for integrating an ICE library into a HIP implementation turned
out to be quite a bit higher than initially estimated. Also, the amount of
extra code (some 10 kLoC) needed for all the new parsers, state machines,
etc., was quite high and by reusing the HIP code, one should be able to do
with much less. This should result in smaller binary size, less bugs, and
easier debugging.<a href="#appendix-B-2" class="pilcrow">¶</a></p>
<p id="appendix-B-3"> Consequently, the HIP working group decided to follow ICE
       methodology but reuse HIP messaging format to achieve the same
       functionality as ICE; the result of that is this document, which
       specifies the Native ICE-HIP protocol.<a href="#appendix-B-3" class="pilcrow">¶</a></p>
<p id="appendix-B-4">The Native ICE-HIP protocol specified in this document follows the semantics
      of ICE as close as possible, and most of the differences are
      syntactical due to the use of a different protocol. In this
      section, we describe the differences to the ICE protocol.<a href="#appendix-B-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="appendix-B-5.1">ICE operates at the application layer, whereas this
 protocol operates between transport and network layers, thus
 hiding the protocol details from the application.<a href="#appendix-B-5.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-B-5.2">The STUN protocol is not employed. Instead, Native ICE-HIP
 reuses the HIP control plane format in order to simplify
 the demultiplexing of different protocols. For example, the STUN
 binding response is replaced with a HIP UPDATE message
 containing an ECHO_REQUEST_SIGNED parameter and the STUN
 binding response with a HIP UPDATE message containing an
 ECHO_RESPONSE_SIGNED parameter as defined in <a href="#sec_conn_checks" class="xref">Section 4.6</a>.  It is worth noting that
 a 
 drawback of not employing STUN is that discovery of the address
 candidates requires creating (using HIP base exchange) and
 maintaining (using HIP UPDATE procedures) state at the Control Relay Client and
 Control Relay Server. Future extensions to this document may define
 a stateless, HIP-specific mechanism for an end host to discover its address candidates.<a href="#appendix-B-5.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-B-5.3">The TURN protocol is not utilized. Instead, Native ICE-HIP reuses
 Control Relay Servers for the same purpose.<a href="#appendix-B-5.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-B-5.4">ICMP errors may be used in ICE to signal failure. In the Native ICE-HIP
 protocol, HIP NOTIFY messages are used instead.<a href="#appendix-B-5.4" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-B-5.5">Instead of the ICE username fragment and password mechanism for
        credentials, Native ICE-HIP uses the HIT, derived from a public key,
        for the same purpose. The username fragments are "transient host
        identifiers, bound to a particular session established as part of the
        candidate exchange" <span>[<a href="#RFC8445" class="xref">RFC8445</a>]</span>. Generally in HIP, a local public key and the
        derived HIT are considered long-term identifiers and invariant across
        different host associations and different transport-layer flows.<a href="#appendix-B-5.5" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-B-5.6">In ICE, the conflict when two communicating endpoints take the
        same controlling role is solved using random values (a so-called
        tie-breaker value). In the Native ICE-HIP protocol, the conflict is solved
        by the standard HIP base exchange procedure, where the host with the
        "larger" HIT switches to the Responder role, thus also changing to
        the controlled role.<a href="#appendix-B-5.6" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-B-5.7">The ICE-CONTROLLED and ICE-CONTROLLING attributes are not
 included in the connectivity checks.<a href="#appendix-B-5.7" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-B-5.8">The foundation concept is unnecessary in Native ICE-HIP
 because only a single UDP flow for the IPsec tunnel will be
 negotiated.<a href="#appendix-B-5.8" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-B-5.9">Frozen candidates are omitted for the same reason the
 foundation concept is excluded.<a href="#appendix-B-5.9" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-B-5.10">Components are omitted for the same reason the
 foundation concept is excluded.<a href="#appendix-B-5.10" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-B-5.11">Native ICE-HIP supports only "full ICE" where the two
 communicating hosts participate actively to the connectivity checks,
 and the "lite" mode is not supported.  This design decision follows
 the guidelines of ICE, which recommends full ICE implementations.
 However, it should be noted that a publicly reachable Responder may
 refuse to negotiate the ICE mode as described in <a href="#sec_no_relay" class="xref">Section 4.7.2</a>.  This would result in a HIP
 base exchange (as per <span>[<a href="#RFC7401" class="xref">RFC7401</a>]</span>)
 tunneled over UDP, followed by ESP traffic over the same tunnel, without
 the connectivity check procedures defined in this document (in some
 sense, this mode corresponds to the case where two ICE lite
 implementations connect since no connectivity checks are sent).<a href="#appendix-B-5.11" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-B-5.12">As the "ICE lite" is not adopted here and both sides are
 capable of ICE-HIP-UDP mode (negotiated during the base
 exchange), default candidates are not employed in Native ICE-HIP.<a href="#appendix-B-5.12" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-B-5.13"> If the agent is using Diffserv Codepoint markings <span>[<a href="#RFC2475" class="xref">RFC2475</a>]</span> in its media packets, it
        <span class="bcp14">SHOULD</span> apply those same markings to its connectivity
        checks.<a href="#appendix-B-5.13" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-B-5.14">Unlike in ICE, the addresses are not XORed in the Native ICE-HIP
 protocol but rather encrypted to avoid middlebox tampering.<a href="#appendix-B-5.14" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-B-5.15">ICE defines Related Address and Port attributes used for diagnostic/SIP
purposes, but the Native ICE-HIP protocol does not employ these attributes.<a href="#appendix-B-5.15" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-B-5.16">The minimum RTO is 500 ms in ICE but 1000 ms in the Native ICE-HIP
        protocol in favor of <span>[<a href="#RFC8961" class="xref">RFC8961</a>]</span>.<a href="#appendix-B-5.16" class="pilcrow">¶</a>
</li>
      </ul>
</section>
</div>
<div id="sec_hip_diff">
<section id="appendix-C">
      <h2 id="name-differences-to-base-exchang">
<a href="#appendix-C" class="section-number selfRef">Appendix C. </a><a href="#name-differences-to-base-exchang" class="section-name selfRef">Differences to Base Exchange and UPDATE Procedures</a>
      </h2>
<p id="appendix-C-1">This section gives some design guidance for implementers on how the
      extensions in this protocol extend and differ from <span>[<a href="#RFC7401" class="xref">RFC7401</a>]</span> and <span>[<a href="#RFC8046" class="xref">RFC8046</a>]</span>.<a href="#appendix-C-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="appendix-C-2.1">Both the control and data plane are operated on top of UDP, not directly on IP.<a href="#appendix-C-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-C-2.2">A minimal implementation would conform only to Sections <a href="#sec_minimal" class="xref">4.7.1</a> or <a href="#sec_no_relay" class="xref">4.7.2</a>, thus merely tunneling HIP control and data traffic
        over UDP. The drawback here is that it works only in the limited cases
        where the Responder has a public address.<a href="#appendix-C-2.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-C-2.3">It is worth noting that while a Rendezvous Server <span>[<a href="#RFC8004" class="xref">RFC8004</a>]</span> has not been designed to be used
        in NATed scenarios because it just relays the first I1 packet and does
        not employ UDP encapsulation, the Control Relay Server forwards all
        control traffic and, hence, is more suitable in NATed
        environments. Further, the Data Relay Server guarantees forwarding of
        data plane traffic also in cases where the NAT traversal procedures
        fail.<a href="#appendix-C-2.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-C-2.4">Registration procedures with a Control/Data Relay Server are
        similar as with a Rendezvous Server. However, a Control/Data Relay
        Server has different registration parameters than a Rendezvous Server
        because it offers a different service. Also, the Control/Data Relay
        Server also includes a REG_FROM parameter that informs the
        Control/Data Relay Client about its server-reflexive address. A Data
        Relay Server also includes a RELAYED_ADDRESS containing the relayed
        address for the Data Relay Client.<a href="#appendix-C-2.4" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-C-2.5">In <span>[<a href="#RFC7401" class="xref">RFC7401</a>]</span>, the Initiator and Responder
 can start to exchange application payload immediately after
 the base exchange. While exchanging data immediately after a
 base exchange via a Data Control Relay would also be possible here, we
 follow the ICE methodology to establish a direct path between
 two hosts using connectivity checks. This means that there
 will be some additional delay after the base exchange before
 application payload can be transmitted. The same applies for
 the UPDATE procedure as the connectivity checks introduce some
 additional delay.<a href="#appendix-C-2.5" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-C-2.6">In HIP without any NAT traversal support, the base exchange
 acts as an implicit connectivity check, and the mobility and
 multihoming extensions support explicit connectivity
 checks. After a base exchange or UPDATE-based connectivity
 checks, a host can use the associated address pair for
 transmitting application payload. In this Native ICE-HIP extension, we follow
 the ICE methodology where one endpoint acting in the
 controlled role chooses the used address pair also on behalf
 of the other endpoint acting in the controlled role, which is
 different from HIP without NAT traversal support. Another
 difference is that the process of choosing an address pair is
 explicitly signaled using the nomination packets. The
 nomination process in this protocol supports only a single
 address pair, and multihoming extensions are left for further
 study.<a href="#appendix-C-2.6" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-C-2.7">The UPDATE procedure resembles the mobility extensions
 defined in <span>[<a href="#RFC8046" class="xref">RFC8046</a>]</span>. The
 first UPDATE message from the mobile host is exactly the same
 as in the mobility extensions. The second UPDATE message from
 the peer host and third from the mobile host are different in
 the sense that they merely acknowledge and conclude the
 reception of the candidates through the Control Relay Server. In other words,
 they do not yet test for connectivity (besides reachability
 through the Control Relay Server) unlike in the mobility extensions. The
 idea is that the connectivity check procedure follows the ICE
 specification, which is somewhat different from the HIP
 mobility extensions.<a href="#appendix-C-2.7" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-C-2.8">The connectivity checks as defined in the mobility
 extensions <span>[<a href="#RFC8046" class="xref">RFC8046</a>]</span> are
 triggered only by the peer of the mobile host. Since
 successful NAT traversal requires that both endpoints test
 connectivity, both the mobile host and its peer host have to
 test for connectivity. In addition, this protocol
 also validates the UDP ports; the ports in the connectivity
 check must match with the response, as required by ICE.<a href="#appendix-C-2.8" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-C-2.9">In HIP mobility extensions <span>[<a href="#RFC8046" class="xref">RFC8046</a>]</span>, an outbound locator has some associated state:
        UNVERIFIED means that the locator has not been tested for
        reachability, ACTIVE means that the address has been verified for
        reachability and is being used actively, and DEPRECATED means that the
        locator lifetime has expired. In the subset of ICE specifications used
        by this protocol, an individual address candidate has only two
        properties: type and priority. Instead, the actual state in ICE is
        associated with candidate pairs rather than individual addresses. The
        subset of ICE specifications utilized by this protocol require the
        following attributes for a candidate pair: valid bit, nominated bit,
        base, and the state of the connectivity check. The connectivity checks
        have the following states: Waiting, In-progress, Succeeded, and
        Failed. Handling of this state attribute requires some additional
        logic when compared to the mobility extensions, since the state is
        associated with a local-remote address pair rather than just a remote
        address; thus, the mobility and ICE states do not have an unambiguous
        one-to-one mapping.<a href="#appendix-C-2.9" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-C-2.10">Credit-based authorization as defined in <span>[<a href="#RFC8046" class="xref">RFC8046</a>]</span> could be used before
 candidate nomination has been concluded upon discovering
 working candidate pairs. However, this may result in the use
 of asymmetric paths for a short time period in the beginning
 of communications. Thus, support of credit-based authorization is left
 for further study.<a href="#appendix-C-2.10" class="pilcrow">¶</a>
</li>
      </ul>
</section>
</div>
<div id="sec_multihoming">
<section id="appendix-D">
      <h2 id="name-multihoming-considerations">
<a href="#appendix-D" class="section-number selfRef">Appendix D. </a><a href="#name-multihoming-considerations" class="section-name selfRef">Multihoming Considerations</a>
      </h2>
<p id="appendix-D-1">This document allows a host to collect address candidates from
      multiple interfaces but does not support activation and the simultaneous
      use of multiple address candidates.  While multihoming extensions to
      support functionality similar to that found in <span>[<a href="#RFC8047" class="xref">RFC8047</a>]</span> are left for further study and experimentation, we
      envision here some potential compatibility improvements to support
      multihoming:<a href="#appendix-D-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="appendix-D-2">
        <dt id="appendix-D-2.1">Data Relay Registration:</dt>
        <dd style="margin-left: 1.5em" id="appendix-D-2.2">a Data Relay Client acting as an
 Initiator with another peer host should register a new
 server-reflexive candidate for each local transport address candidate. A
 Data Relay Client acting as a Responder should register a new
 server-reflexive candidate for each {local transport address candidate,
 new peer host} pair for the reasons described in <a href="#sec_conflicting" class="xref">Section 4.12.3</a>. In both cases, the Data
 Relay Client should 
 request the additional server-reflexive candidates by sending UPDATE
 messages originating from each of the local address candidates as
 described in <a href="#sec_registration" class="xref">Section 4.1</a>. As the
        UPDATE messages are originating from an unknown location from the
 viewpoint of the Data Relay Server, 
        it must also include an ECHO_REQUEST_SIGNED in the response in order to
 test for return routability.<a href="#appendix-D-2.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="appendix-D-2.3">Data Relay unregistration:</dt>
        <dd style="margin-left: 1.5em" id="appendix-D-2.4">This follows the procedure in <a href="#sec_protocol" class="xref">Section 4</a>, but the Data Relay Client should unregister using
 the particular transport address to be unregistered.  All transport
 address pair registrations can be unregistered when no RELAYED_ADDRESS
 parameter is included.<a href="#appendix-D-2.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="appendix-D-2.5">PEER_PERMISSION parameter:</dt>
        <dd style="margin-left: 1.5em" id="appendix-D-2.6">This needs to be extended or
 an additional parameter is needed to declare the specific local
 candidate of the Data Relay Client. Alternatively, the use of
 the PEER_PERMISSION could be used as a wild card to open permissions
 for a specific peer to all 
 of the candidates of the Data Relay Client.<a href="#appendix-D-2.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="appendix-D-2.7">Connectivity checks:</dt>
        <dd style="margin-left: 1.5em" id="appendix-D-2.8">The controlling host should be able to
 nominate multiple candidates (by repeating step 7 in <a href="#fig_cc1" class="xref">Figure 5</a> in <a href="#sec_conn_checks" class="xref">Section 4.6</a> using the additional candidate pairs).<a href="#appendix-D-2.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="appendix-D-2.9">Keepalives:</dt>
        <dd style="margin-left: 1.5em" id="appendix-D-2.10">These should be sent for all the nominated candidate
 pairs. Similarly, the Control/Data Relay Client should send keepalives
 from its local candidates to its Control/Data Relay Server transport
 addresses.<a href="#appendix-D-2.10" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
</section>
</div>
<div id="sec_dns">
<section id="appendix-E">
      <h2 id="name-dns-considerations">
<a href="#appendix-E" class="section-number selfRef">Appendix E. </a><a href="#name-dns-considerations" class="section-name selfRef">DNS Considerations</a>
      </h2>
<p id="appendix-E-1">This section updates <span><a href="https://www.rfc-editor.org/rfc/rfc5770#appendix-B" class="relref">Appendix B</a> of [<a href="#RFC5770" class="xref">RFC5770</a>]</span>, which will be replaced with the mechanism  described in
      this section.<a href="#appendix-E-1" class="pilcrow">¶</a></p>
<p id="appendix-E-2"><span>[<a href="#RFC5770" class="xref">RFC5770</a>]</span> did not specify how an
      end host can look up another end host via DNS and initiate a UDP-based
      HIP base exchange with it, so this section makes an attempt to fill this
      gap.<a href="#appendix-E-2" class="pilcrow">¶</a></p>
<p id="appendix-E-3"><span>[<a href="#RFC8005" class="xref">RFC8005</a>]</span> specifies how a HIP end
      host and its Rendezvous Server is registered to DNS.  Essentially, the
      public key of the end host is stored as a HI record and its Rendezvous
      Server as an A or AAAA record. This way, the Rendezvous Server can act
      as an intermediary for the end host and forward packets to it based on
      the DNS configuration.  The Control Relay Server offers similar
      functionality to the Rendezvous Server, with the difference being that the
      Control Relay Server forwards all control messages, not just the first
      I1 message.<a href="#appendix-E-3" class="pilcrow">¶</a></p>
<p id="appendix-E-4">
      Prior to this document, the A and AAAA records in the DNS
      refer either to the HIP end host itself or a Rendezvous Server <span>[<a href="#RFC8005" class="xref">RFC8005</a>]</span>,
      and control and data plane communication with the associated
      host has been assumed to occur directly over IPv4 or
      IPv6. However, this specification extends the records to be used for
      UDP-based communications.<a href="#appendix-E-4" class="pilcrow">¶</a></p>
<p id="appendix-E-5">Let us consider the case of a HIP Initiator with the default policy
      to employ UDP encapsulation and the extensions defined in this document.
      The Initiator looks up the Fully Qualified Domain Name (FQDN) of a
      Responder, and retrieves its HI, A, and AAAA records.  Since the default
      policy is to use UDP encapsulation, the Initiator <span class="bcp14">MUST</span>
      send the I1 message over UDP to destination port 10500 (either over IPv4
      in the case of an A record or over IPv6 in the case of an AAAA
      record). It <span class="bcp14">MAY</span> send an I1 message both with and without
      UDP encapsulation in parallel.

      In the case in which the Initiator receives R1 messages both with and without UDP
      encapsulation from the Responder, the Initiator <span class="bcp14">SHOULD</span>
      ignore the R1 messages without UDP encapsulation.<a href="#appendix-E-5" class="pilcrow">¶</a></p>
<p id="appendix-E-6">The UDP-encapsulated I1 packet could be received by four different
      types of hosts:<a href="#appendix-E-6" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="appendix-E-7">
        <dt id="appendix-E-7.1">HIP Control Relay Server:</dt>
        <dd style="margin-left: 1.5em" id="appendix-E-7.2">In this case, the A/AAAA records refer to a Control Relay Server,
 which will forward the packet to the corresponding Control Relay
 Client based on the destination HIT in the I1 packet.<a href="#appendix-E-7.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="appendix-E-7.3">HIP Responder supporting UDP encapsulation:</dt>
        <dd style="margin-left: 1.5em" id="appendix-E-7.4">In this case, the A/AAAA records refer to the end host. Assuming
 the destination HIT belongs to the Responder, the Responder receives
 and processes the I1 packet according to the negotiated NAT traversal
 mechanism. The support for the protocol defined in this document, as
 opposed to the support defined in <span>[<a href="#RFC5770" class="xref">RFC5770</a>]</span>, is dynamically negotiated during the base
 exchange. The details are specified in <a href="#sec_nat_traversal_mode" class="xref">Section 4.3</a>.<a href="#appendix-E-7.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="appendix-E-7.5">HIP Rendezvous Server:</dt>
        <dd style="margin-left: 1.5em" id="appendix-E-7.6">This entity is not listening to UDP port 10500, so it will drop
 the I1 message.<a href="#appendix-E-7.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="appendix-E-7.7">HIP Responder not supporting UDP encapsulation:</dt>
        <dd style="margin-left: 1.5em" id="appendix-E-7.8">The targeted end host is not listening to UDP port 10500, so it
 will drop the I1 message.<a href="#appendix-E-7.8" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="appendix-E-8">The A/AAAA record <span class="bcp14">MUST NOT</span> be configured to refer to a
      Data Relay Server unless the host in question also supports Control
      Relay Server functionality.<a href="#appendix-E-8" class="pilcrow">¶</a></p>
<p id="appendix-E-9">It is also worth noting that SRV records are not employed in this
      specification. While they could be used for more flexible UDP
      port selection, they are not suitable for end-host discovery but
      rather would be more suitable for the discovery of HIP-specific infrastructure. Further
      extensions to this document may define SRV records for Control
      and Data Relay Server discovery within a DNS domain.<a href="#appendix-E-9" class="pilcrow">¶</a></p>
</section>
</div>
<section id="appendix-F">
      <h2 id="name-acknowledgments">
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
      </h2>
<p id="appendix-F-1">Thanks to <span class="contact-name">Jonathan Rosenberg</span>, <span class="contact-name">Christer Holmberg</span>, and the rest of the MMUSIC WG folks for
      the excellent work on ICE. The authors would also like to thank <span class="contact-name">Andrei Gurtov</span>, <span class="contact-name">Simon Schuetz</span>,
      <span class="contact-name">Martin Stiemerling</span>, <span class="contact-name">Lars       Eggert</span>, <span class="contact-name">Vivien Schmitt</span>, and <span class="contact-name">Abhinav Pathak</span> for their contributions, and <span class="contact-name">Tobias Heer</span>, <span class="contact-name">Teemu Koponen</span>, <span class="contact-name">Juhana Mattila</span>, <span class="contact-name">Jeffrey M. Ahrenholz</span>,
      <span class="contact-name">Kristian Slavov</span>, <span class="contact-name">Janne       Lindqvist</span>, <span class="contact-name">Pekka Nikander</span>, <span class="contact-name">Lauri Silvennoinen</span>, <span class="contact-name">Jukka Ylitalo</span>,
      <span class="contact-name">Juha Heinanen</span>, <span class="contact-name">Joakim       Koskela</span>, <span class="contact-name">Samu Varjonen</span>, <span class="contact-name">Dan       Wing</span>, <span class="contact-name">Tom Henderson</span>, <span class="contact-name">Alex       Elsayed</span>, <span class="contact-name">Jani Hautakorpi</span>, <span class="contact-name">Tero Kauppinen</span>, and <span class="contact-name">Timo Simanainen</span>
      for their comments to <span>[<a href="#RFC5770" class="xref">RFC5770</a>]</span> and this
      document.  Thanks to <span class="contact-name">Éric Vyncke</span>, <span class="contact-name">Alvaro Retana</span>, <span class="contact-name">Adam Roach</span>, <span class="contact-name">Ben Campbell</span>, <span class="contact-name">Eric Rescorla</span>, <span class="contact-name">Mirja Kühlewind</span>, <span class="contact-name">Spencer Dawkins</span>,
      <span class="contact-name">Derek Fawcus</span>, <span class="contact-name">Tianran Zhou</span>,
      <span class="contact-name">Amanda Barber</span>, <span class="contact-name">Colin       Perkins</span>, <span class="contact-name">Roni Even</span>, <span class="contact-name">Alissa       Cooper</span>, <span class="contact-name">Carl Wallace</span>, <span class="contact-name">Martin       Duke</span>, and <span class="contact-name">Benjamin Kaduk</span> for reviewing this
      document.<a href="#appendix-F-1" class="pilcrow">¶</a></p>
<p id="appendix-F-2">This work has been partially funded by the Cyber Trust Program
      by Digile/Tekes in Finland.<a href="#appendix-F-2" class="pilcrow">¶</a></p>
</section>
<section id="appendix-G">
      <h2 id="name-contributors">
<a href="#name-contributors" class="section-name selfRef">Contributors</a>
      </h2>
<p id="appendix-G-1"><span class="contact-name">Marcelo Bagnulo</span>, <span class="contact-name">Philip       Matthews</span>, and <span class="contact-name">Hannes Tschofenig</span> have
      contributed to <span>[<a href="#RFC5770" class="xref">RFC5770</a>]</span>. This document
      leans heavily on the work in that RFC.<a href="#appendix-G-1" class="pilcrow">¶</a></p>
</section>
<div id="authors-addresses">
<section id="appendix-H">
      <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">Ari Keränen</span></div>
<div dir="auto" class="left"><span class="org">Ericsson</span></div>
<div dir="auto" class="left"><span class="street-address">Hirsalantie 11</span></div>
<div dir="auto" class="left">FI-<span class="postal-code">02420</span> <span class="locality">Jorvas</span>
</div>
<div dir="auto" class="left"><span class="country-name">Finland</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:ari.keranen@ericsson.com" class="email">ari.keranen@ericsson.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Jan Melén</span></div>
<div dir="auto" class="left"><span class="org">Ericsson</span></div>
<div dir="auto" class="left"><span class="street-address">Hirsalantie 11</span></div>
<div dir="auto" class="left">FI-<span class="postal-code">02420</span> <span class="locality">Jorvas</span>
</div>
<div dir="auto" class="left"><span class="country-name">Finland</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:jan.melen@ericsson.com" class="email">jan.melen@ericsson.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Miika Komu (<span class="role">editor</span>)</span></div>
<div dir="auto" class="left"><span class="org">Ericsson</span></div>
<div dir="auto" class="left"><span class="street-address">Hirsalantie 11</span></div>
<div dir="auto" class="left">FI-<span class="postal-code">02420</span> <span class="locality">Jorvas</span>
</div>
<div dir="auto" class="left"><span class="country-name">Finland</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:miika.komu@ericsson.com" class="email">miika.komu@ericsson.com</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>