File: rfc9236.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 (1983 lines) | stat: -rw-r--r-- 77,740 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 9236: Architectural Considerations of Information-Centric Networking (ICN) Using a Name Resolution Service</title>
<meta content="Jungha Hong" name="author">
<meta content="Tae-Wan You" name="author">
<meta content="Ved Kafle" name="author">
<meta content="
       
        This document describes architectural considerations and implications
        related to the use of a Name Resolution Service (NRS) in Information-Centric Networking (ICN).
        It explains how the ICN architecture can change when an NRS is utilized
        and how its use influences the ICN routing system. This document is a product
        of the Information-Centric Networking Research Group (ICNRG).
       
    " name="description">
<meta content="xml2rfc 3.12.2" name="generator">
<meta content="Information-Centric Networking" name="keyword">
<meta content="Name Resolution Service" name="keyword">
<meta content="Name to location mapping" name="keyword">
<meta content="9236" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.12.2
    Python 3.6.15
    appdirs 1.4.4
    ConfigArgParse 1.4.1
    google-i18n-address 2.4.0
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.3
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.15.1
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.4.1
    requests 2.24.0
    setuptools 40.5.0
    six 1.14.0
    WeasyPrint 52.5
-->
<link href="rfc9236.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;
}
/* Fix PDF info block run off issue */
@media print {
  #identifiers dd {
    float: none;
  }
}
#identifiers .authors .author {
  display: inline-block;
  margin-right: 1.5em;
}
#identifiers .authors .org {
  font-style: italic;
}

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

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

.refInstance {
  margin-bottom: 1.25em;
}

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

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

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

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

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

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

/* pagination */
@media print {
  body {

    width: 100%;
  }
  p {
    orphans: 3;
    widows: 3;
  }
  #n-copyright-notice {
    border-bottom: none;
  }
  #toc, #n-introduction {
    page-break-before: always;
  }
  #toc {
    border-top: none;
    padding-top: 0;
  }
  figure, pre {
    page-break-inside: avoid;
  }
  figure {
    overflow: scroll;
  }
  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: auto;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
li > p {
  margin-bottom: 0.5em
}
/* Don't let p margin spill out from inside list items */
li > p:last-of-type {
  margin-bottom: 0;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc9236" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-irtf-icnrg-nrsarch-considerations-07" 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 9236</td>
<td class="center">Arch Considerations of ICN Using NRS</td>
<td class="right">April 2022</td>
</tr></thead>
<tfoot><tr>
<td class="left">Hong, et al.</td>
<td class="center">Informational</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Internet Research Task Force (IRTF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc9236" class="eref">9236</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Informational</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2022-04" class="published">April 2022</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">J. Hong</div>
<div class="org">ETRI</div>
</div>
<div class="author">
      <div class="author-name">T. You</div>
<div class="org">ETRI</div>
</div>
<div class="author">
      <div class="author-name">V. Kafle</div>
<div class="org">NICT</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9236</h1>
<h1 id="title">Architectural Considerations of Information-Centric Networking (ICN) Using a Name Resolution Service</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">
        This document describes architectural considerations and implications
        related to the use of a Name Resolution Service (NRS) in Information-Centric Networking (ICN).
        It explains how the ICN architecture can change when an NRS is utilized
        and how its use influences the ICN routing system. This document is a product
        of the Information-Centric Networking Research Group (ICNRG).<a href="#section-abstract-1" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document is a product of the Internet Research Task Force
            (IRTF).  The IRTF publishes the results of Internet-related
            research and development activities.  These results might not be
            suitable for deployment.  This RFC represents the consensus of the Information-Centric Networking
            Research Group of the Internet Research Task Force (IRTF).
            Documents approved for publication by the IRSG are not
            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/rfc9236">https://www.rfc-editor.org/info/rfc9236</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2022 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-terminology" class="xref">Terminology</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" 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-background" class="xref">Background</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-implications-of-an-nrs-in-i" class="xref">Implications of an NRS in ICN</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-icn-architectural-considera" class="xref">ICN Architectural Considerations for NRS</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.1">
                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-name-mapping-records-regist" class="xref">Name Mapping Records Registration, Resolution, and Update</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.2">
                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-protocols-and-semantics" class="xref">Protocols and Semantics</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.3">
                <p id="section-toc.1-1.5.2.3.1"><a href="#section-5.3" class="xref">5.3</a>.  <a href="#name-routing-system" class="xref">Routing System</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-conclusion" class="xref">Conclusion</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-references" class="xref">References</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" 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="compact toc ulBare ulEmpty" 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="compact toc ulBare ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#appendix-A" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#appendix-B" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">
          Information-Centric Networking (ICN) is an approach to evolving the
          Internet infrastructure to provide direct access to Named Data
          Objects (NDOs) by names. In two common ICN architectures, Named Data
          Networking (NDN) <span>[<a href="#NDN" class="xref">NDN</a>]</span> and
          Content-Centric Networking (CCNx) <span>[<a href="#CCNx" class="xref">CCNx</a>]</span>, the name of an NDO is used directly to route a
          request to retrieve the data object. Such direct name-based routing
          has inherent challenges in enabling a globally scalable routing
          system, accommodating producer mobility, and supporting off-path
          caching.  These specific issues are discussed in detail in <a href="#background" class="xref">Section 3</a>. In order to address these challenges, a Name
          Resolution Service (NRS) has been utilized in the literature as well
          as the proposals of several ICN projects <span>[<a href="#Afanasyev" class="xref">Afanasyev</a>]</span> <span>[<a href="#Zhang2" class="xref">Zhang2</a>]</span> <span>[<a href="#I-D.ravi-icnrg-ccn-forwarding-label" class="xref">Ravindran</a>]</span>
        <span>[<a href="#SAIL" class="xref">SAIL</a>]</span> <span>[<a href="#MF" class="xref">MF</a>]</span> <span>[<a href="#Bayhan" class="xref">Bayhan</a>]</span>.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">
          This document describes the potential changes in the ICN
          architecture caused by the introduction of an NRS and the
          corresponding implication to the ICN routing system. It also
          describes ICN architectural considerations for the integration of an
          NRS. The scope of this document includes considerations from the
          perspective of an ICN architecture and routing system when using an NRS
          in ICN. A description of the NRS itself is provided in the companion
          NRS design considerations document <span>[<a href="#RFC9138" class="xref">RFC9138</a>]</span>, which provides the NRS approaches, functions, and
          design considerations.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">
          This document represents the consensus of the Information-Centric
          Networking Research Group (ICNRG). It has been reviewed extensively
          by the Research Group (RG) members who are actively involved in the
          research and development of the technology covered by this document.
          It is not an IETF product and is not a standard.<a href="#section-1-3" class="pilcrow">¶</a></p>
</section>
<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>
<span class="break"></span><dl class="dlParallel" id="section-2-1">
        <dt id="section-2-1.1">Name Resolution Service (NRS):
        </dt>
        <dd style="margin-left: 1.5em" id="section-2-1.2">An NRS in ICN is defined as a service that provides the function
 of translating a content name or a data object name into some other
 information such as a routable prefix, a locator, an off-path-cache
 pointer, or an alias name that is more amenable than the input name to
 forwarding the object request toward the target destination storing
 the NDO <span>[<a href="#RFC9138" class="xref">RFC9138</a>]</span>.  An NRS is most
 likely implemented through the use of a distributed mapping database
 system. The Domain Name System (DNS) may be used as an NRS.  However, in
 this case, the requirements of frequent updates of NRS records due to
 the creations of a lot of new NDOs and changes in their locations in
 the network need to be considered.<a href="#section-2-1.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-1.3">NRS server:
        </dt>
        <dd style="margin-left: 1.5em" id="section-2-1.4">An NRS comprises the distributed NRS servers storing the mapping
 records in their databases.  NRS servers store and maintain the
 mapping records that keep the mappings of content or object name to
 some other information that is used for forwarding the content request
 or the content itself.<a href="#section-2-1.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-1.5">NRS resolver:
        </dt>
        <dd style="margin-left: 1.5em" id="section-2-1.6">The client-side function of an NRS is called an NRS resolver.  The
 NRS resolver is responsible for initiating name resolution request
 queries that ultimately lead to a name resolution of the target data
 objects.  NRS resolvers can be located in the consumer (or client)
 nodes and/or ICN routers.  An NRS resolver may also cache the mapping
 records obtained through the name resolution for later usage.<a href="#section-2-1.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-1.7">Name registration:
        </dt>
        <dd style="margin-left: 1.5em" id="section-2-1.8">In order to populate the NRS, the content names and their mapping
 records must be registered in the NRS system by a publisher who has
 access rights to at least one authoritative NRS server or by a producer
 who generates named data objects.  The records contain the mapping of
 an object name to some information such as other alias names, routable
 prefixes, and locators, which are used for forwarding the content
 request.  Thus, a publisher or producer of content creates an NRS
 registration request and sends it to an NRS server.  On registration,
 the NRS server stores (or updates) the name mapping record in the
 database and sends an acknowledgement back to the producer or
 publisher that made the registration request.<a href="#section-2-1.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-1.9">Name resolution:
        </dt>
        <dd style="margin-left: 1.5em" id="section-2-1.10">Name resolution is the main function of the NRS system. It is
 performed by an NRS resolver, which can be deployed on a consumer node
 or an ICN router.  Resolvers are responsible for either returning a
 cached mapping record (whose lifetime has not expired) or
 alternatively sending a name resolution request toward an NRS server.
 The NRS server searches for the content name in its mapping record
 database and, if found, retrieves the mapping record and returns it in
 a name resolution response message to the NRS resolver.<a href="#section-2-1.10" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-1.11">NRS node:
        </dt>
        <dd style="margin-left: 1.5em" id="section-2-1.12">NRS servers are also referred to as NRS nodes that maintain the
 name records. The terms are used interchangeably.<a href="#section-2-1.12" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-1.13">NRS client:
        </dt>
        <dd style="margin-left: 1.5em" id="section-2-1.14">A node that uses the NRS is called an NRS client.  Any node that
 initiates a name registration, resolution, or update procedure is an
 NRS client; that is, NRS resolvers, ICN client nodes, ICN routers, or
 producers can be NRS clients.<a href="#section-2-1.14" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
</section>
<div id="background">
<section id="section-3">
      <h2 id="name-background">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-background" class="section-name selfRef">Background</a>
      </h2>
<p id="section-3-1">
      A pure name-based routing approach in ICN has inherent challenges in enabling
      a globally scalable routing system, accommodating producer mobility, and
      supporting off-path caching. In order to address these challenges, an NRS
      has been utilized in proposals and literature of several ICN projects as follows:<a href="#section-3-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3-2">
        <dt id="section-3-2.1">Routing scalability:
        </dt>
        <dd style="margin-left: 1.5em" id="section-3-2.2">In ICN, application names identifying content are intended to be
 used directly for packet delivery, so ICN routers run a name-based
 routing protocol to build name-based routing and forwarding tables.
 Similar to the scalability challenge of IP routing, if
 non-aggregatable name prefixes are injected into the Default Route
 Free Zone (DFZ) of ICN routers, they would be driving the uncontrolled
 growth of the DFZ routing table size.  Thus, providing the level of
 indirection enabled by an NRS in ICN can be an approach to keeping the
 routing table size under control. The NRS system resolves name
 prefixes that do not exist in the DFZ forwarding table into globally
 routable prefixes such as the one proposed in NDN <span>[<a href="#Afanasyev" class="xref">Afanasyev</a>]</span>.  Another approach dealing with routing scalability
 is the Multi-level Distributed Hash Table (MDHT) used in NetInf <span>[<a href="#Dannewitz" class="xref">Dannewitz</a>]</span>.  It provides name-based anycast
 routing that can support a non-hierarchical namespace and can be
 adopted on a global scale <span>[<a href="#Dannewitz2" class="xref">Dannewitz2</a>]</span>.<a href="#section-3-2.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.3">Producer mobility:
        </dt>
        <dd style="margin-left: 1.5em" id="section-3-2.4">In ICN, if a producer moves into a different name domain that uses
 a different name prefix, the request for a content produced by the
 moving producer with the origin content name must be forwarded to the
 moving producer's new location.  Especially in a hierarchical naming
 scheme, producer mobility support is much harder than in a flat naming
 scheme since the routing tables in a broader area need to be updated
 to track the producer movement.  Therefore, various ICN architectures
 such as NetInf <span>[<a href="#Dannewitz" class="xref">Dannewitz</a>]</span> and
 MobilityFirst <span>[<a href="#MF" class="xref">MF</a>]</span> have adopted NRS
 systems to tackle the issues of producers whose location changes.<a href="#section-3-2.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.5">Off-path caching:
        </dt>
        <dd style="margin-left: 1.5em" id="section-3-2.6">In-network caching is a common feature of an ICN architecture.
 Caching approaches can be categorized into on-path caching and
 off-path caching, according to the location of caches in relation to
 the forwarding path from the original content store to a consumer.
 Off-path caching, sometimes also referred to as content replication or
 content storing, aims to replicate a Named Data Object in various
 locations within a network in order to increase the availability of
 content, reduce access latency, or both. These caching locations may
 not be lying along the content forwarding path.  Thus, finding
 off-path cached content requires more complex forwarding procedures
 if a pure name-based routing is employed. In order to support access
 to off-path caches, the locations of replicas are usually advertised
 into a name-based routing system or into an NRS as described in <span>[<a href="#Bayhan" class="xref">Bayhan</a>]</span>.<a href="#section-3-2.6" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-3-3">
          This document discusses architectural considerations and implications
          of ICN when an NRS is utilized to solve such challenges facing a name-based
          routing in ICN.<a href="#section-3-3" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-4">
      <h2 id="name-implications-of-an-nrs-in-i">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-implications-of-an-nrs-in-i" class="section-name selfRef">Implications of an NRS in ICN</a>
      </h2>
<p id="section-4-1">
          An NRS is not a mandatory part of an ICN architecture, as the majority
          of ICN architectures uses name-based routing that avoids the need for
          a name resolution procedure. Therefore, the utilization of an NRS in
          an ICN architecture changes some architectural aspects at least with
          respect to forwarding procedures, latency, and security, as discussed below:<a href="#section-4-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4-2">
        <dt id="section-4-2.1">Forwarding procedure:
        </dt>
        <dd style="margin-left: 1.5em" id="section-4-2.2">When an NRS is included in an ICN architecture, the name
 resolution procedure has to be included in the ICN overall routing and
 forwarding architectural procedures.  To integrate an NRS into an ICN
 architecture, there are certain things that have to be decided and
 specified such as where, when, and how the name resolution task is
 performed.<a href="#section-4-2.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-4-2.3">Latency:
        </dt>
        <dd style="margin-left: 1.5em" id="section-4-2.4">When an NRS is included in an ICN architecture, additional latency
 introduced by the name resolution process is incurred by the routing
 and forwarding system.  Although the latency due to the name
 resolution is added, the total latency of individual requests being
 served could be lower if the nearest copies or off-path caches can be
 located by the NRS lookup procedure.  Additionally, there might be a
 favorable trade-off between the name resolution latency and
 inter-domain traffic reduction by finding the nearest off-path cached
 copy of the content.  Finding the nearest cache holding the content
 might significantly reduce the content discovery as well as delivery
 latency.<a href="#section-4-2.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-4-2.5">Security:
        </dt>
        <dd style="margin-left: 1.5em" id="section-4-2.6">When any new component such as an NRS is introduced in the ICN
 architecture, the attack surface may increase. Protection of the NRS
 system itself against attacks such as Distributed Denial of Service
 (DDoS) and spoofing or alteration of name mapping records and related
 signaling messages may be challenging.<a href="#section-4-2.6" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
</section>
<section id="section-5">
      <h2 id="name-icn-architectural-considera">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-icn-architectural-considera" class="section-name selfRef">ICN Architectural Considerations for NRS</a>
      </h2>
<p id="section-5-1">
          This section discusses the various items that can be considered from
          the perspective of ICN architecture when employing an NRS system.
          These items are related to the registration, resolution, and update of
          name mapping records, protocols and messages, and integration with the
          routing system.<a href="#section-5-1" class="pilcrow">¶</a></p>
<section id="section-5.1">
        <h3 id="name-name-mapping-records-regist">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-name-mapping-records-regist" class="section-name selfRef">Name Mapping Records Registration, Resolution, and Update</a>
        </h3>
<p id="section-5.1-1">
         When an NRS is integrated in ICN architecture, the functions related to
         the registration, resolution, and update of name mapping records have to
         be considered. The NRS nodes maintain the name mapping records and may
         exist as an overlay network over the ICN routers, that is, they communicate
         to each other through ICN routers. <a href="#rl-fig1" class="xref">Figure 1</a> shows the NRS nodes and NRS
         clients connected through an underlying network. The NRS nodes should be
         deployed in such a manner that an NRS node is always available at a short distance from
         an NRS client so that communication latency for the name registration and
         resolution requested by the NRS client remains very low. The name registration,
         name resolution, and name record update procedures are briefly discussed below.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<span id="name-nrs-nodes-and-nrs-clients-c"></span><div id="rl-fig1">
<figure id="figure-1">
          <div class="alignCenter art-text artwork" id="section-5.1-2.1">
<pre>
               +------------+             +------------+
               |  NRS Node  |             |  NRS Node  |
               +------------+             +------------+
                     |                          |
                     |                          |
  +------------+     |                          |     +------------+
  | NRS Client |--------------------------------------| NRS Client |
  +------------+         underlying network           +------------+
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-nrs-nodes-and-nrs-clients-c" class="selfRef">NRS Nodes and NRS Clients Connected through an Underlying Network</a>
          </figcaption></figure>
</div>
<p id="section-5.1-3" class="keepWithPrevious"></p>
<span class="break"></span><dl class="dlParallel" id="section-5.1-4">
          <dt id="section-5.1-4.1">Name registration:
</dt>
          <dd style="margin-left: 1.5em" id="section-5.1-4.2">Name registration is performed by the producer (as an
NRS client) when it creates a new content.  When a producer creates content
and assigns a name from its name prefix space to the content, the producer
performs the name registration in an NRS node.  Name registration may be
performed by an ICN router when the ICN architecture supports off-path caching
or cooperative caching since involving an NRS may be a good idea for off-path
caching.  The ICN routers with forwarder caches do not require name
registration for their cached content because they lie on the path toward an
upstream content store or producer.  They will be hit when a future request is
forwarded to the content producer by an ICN router lying downstream toward the
ICN client node.  However, ICN routers performing off-path caching of content
must invoke the name registration procedure so that other ICN routers can
depend on name resolutions to know about the off-path cache locations.  If a
content gets cached in many off-path ICN routers, all of them may register the
same content names in the same NRS node, resulting in multiple registration
actions.  In this case, the NRS node adds the new location of the content to
the name record together with the previous locations. In this way, each of the
name records stored in the NRS node may contain multiple locations of the
content. Assigning validity time or a lifetime of each mapping record may be
considered especially for the off-path caching content and managing mobility.<a href="#section-5.1-4.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.1-4.3">Name resolution:
</dt>
          <dd style="margin-left: 1.5em" id="section-5.1-4.4">Name resolution is performed by an NRS client to obtain the name record
from an NRS node by sending a name resolution request message and getting a
response containing the record.  In the name-based ICN routing context, the
name resolution is needed by any ICN router whose forwarding information base
(FIB) does not contain the requested name prefix.  Name resolution may also be
performed by the consumer (especially in the case where the consumer is
multihomed) to forward the content request in a better direction so that it
obtains the content from the nearest cache. If the consumer is single homed,
it may not bother to perform name resolution, instead depending on either
straightforward name-based routing or name resolution by an upstream ICN
router. In this case, the consumer creates the content request packet
containing the content name and forwards to the nearest ICN router.  The ICN
router checks its FIB table to see where to forward the content request.  If
the ICN router fails to identify whether the requested content is reachable,
it performs name resolution to obtain the name mapping record and adds this
information to its FIB.  The ICN router may also perform name resolution even
before the arrival of a content request to use the name mapping record to
configure its FIB.<a href="#section-5.1-4.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.1-4.5">Name record update: 
</dt>
          <dd style="margin-left: 1.5em" id="section-5.1-4.6">Name record update is carried out when a content name mapping record
changes, e.g., the content is not available in one or more of the previous
locations.  The name record update includes the substitution and deletion of
the name mapping records. The name record update may take place explicitly by
the exchange of name record update messages or implicitly when a timeout
occurs and a name record is deemed to be invalid.  The implicit update is
possible when each record is accompanied by a lifetime value.  The lifetime
can be renewed only by the authoritative producer or node. The cached mapping
records get erased after the lifetime expires unless a lifetime extension
indication is obtained from the authoritative producer.<a href="#section-5.1-4.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
<section id="section-5.2">
        <h3 id="name-protocols-and-semantics">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-protocols-and-semantics" class="section-name selfRef">Protocols and Semantics</a>
        </h3>
<p id="section-5.2-1">
         In order to develop an NRS system within a local ICN network domain or
         global ICN network domain, new protocols and semantics must be designed
         and implemented to manage and resolve names among different namespaces.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
<p id="section-5.2-2">
         One way of implementing an NRS for CCNx is by extending the basic TLV
         format and semantics <span>[<a href="#RFC8569" class="xref">RFC8569</a>]</span> <span>[<a href="#RFC8609" class="xref">RFC8609</a>]</span>.
         For instance, name resolution and response messages can be implemented
         by defining new type fields in the Interest and Content Object
         messages <span>[<a href="#I-D.hong-icnrg-ccnx-nrs" class="xref">CCNxNRS</a>]</span>. By leveraging the existing CCNx
         Interest and Content Object packets for name resolution and registration,
         the NRS system can be deployed with a few ICN protocol changes. However,
         because of confining the changes to the basic ICN protocol and semantics,
         the NRS system may not be able to exploit more flexible and scalable designs.<a href="#section-5.2-2" class="pilcrow">¶</a></p>
<p id="section-5.2-3">
         On the other hand, an NRS system can be designed independently with its
         own protocol and semantics like the NRS system described in <span>[<a href="#Hong" class="xref">Hong</a>]</span>.
         For instance, the NRS protocol and messages can be implemented by using
         a RESTful API, and the NRS can be operated as an application protocol
         independent of the rest of the ICN protocol.<a href="#section-5.2-3" class="pilcrow">¶</a></p>
</section>
<section id="section-5.3">
        <h3 id="name-routing-system">
<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-routing-system" class="section-name selfRef">Routing System</a>
        </h3>
<p id="section-5.3-1">
         An NRS reduces the routing complexity of ICN architecture compared to pure
         name-based routing. It does so by permitting the routing system to update
         the routing table on demand with the help of name records obtained
         from NRS. The routing system therefore needs to make name resolution
         requests and process the information returned, such as a prefix, a locator, an
         off-path-cache pointer, or an alias name, obtained from the name resolution.<a href="#section-5.3-1" class="pilcrow">¶</a></p>
<p id="section-5.3-2">
         No matter what kind of information is obtained from the name resolution,
         as long as it is in the form of a name, the content request message in
         the routing system may be reformatted with the obtained information.
         In this case, the content name requested originally by a consumer needs
         to be involved in the reformatted content request to check the integrity
         of the binding between the name and the requested content. In other words,
         the information obtained from the name resolution is used to forward
         the content request, and the original content name requested by a consumer
         is used to identify the content. Alternatively, the resolved information
         may be used to build the routing table.<a href="#section-5.3-2" class="pilcrow">¶</a></p>
<p id="section-5.3-3">
         The information obtained from name resolution may not be in the form of
         a name. For example, it may identify tunnel endpoints by IP address
         and instead be used to construct an IP protocol tunnel through which
         to forward the content request.<a href="#section-5.3-3" class="pilcrow">¶</a></p>
</section>
</section>
<section id="section-6">
      <h2 id="name-conclusion">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-conclusion" class="section-name selfRef">Conclusion</a>
      </h2>
<p id="section-6-1">
      A Name Resolution Service (NRS) is not a mandatory part in an ICN architecture,
      as the majority of ICN architectures use name-based routing that does not
      employ a name resolution procedure. However, such name-based routing in ICN
      has inherent challenges in enabling a globally scalable routing system,
      accommodating producer mobility, and supporting off-path caching.
      In order to address these challenges, an NRS system has been introduced in
      several ICN projects. Therefore, this document describes how the ICN architecture
      changes when an NRS is utilized and how this affects the ICN routing system.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">
      The document defines a few terminologies related to an NRS and explains
      some inherent challenges of pure name-based routing in ICN such as routing
      scalability, producer mobility, and off-path caching. This document describes
      how the ICN architecture would change with respect to procedures, latency,
      and security when an NRS is utilized. According to the ICN architectural
      changes, this document describes ICN architectural considerations for NRS
      such as the functions related to the registration, resolution and update
      of name mapping records, protocols and semantics to implement an NRS system,
      and the routing system involving the name resolution.<a href="#section-6-2" class="pilcrow">¶</a></p>
</section>
<div id="IANA">
<section id="section-7">
      <h2 id="name-iana-considerations">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-7-1">This document has no IANA actions.<a href="#section-7-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-8">
      <h2 id="name-security-considerations">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-8-1">
        When any new component such as an NRS is introduced in the ICN architecture,
        the attack surface increases. The related security vulnerability issues
        are discussed below:<a href="#section-8-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-8-2">
        <dt id="section-8-2.1">Namespace security:
</dt>
        <dd style="margin-left: 1.5em" id="section-8-2.2">In order to deploy an NRS system in ICN architecture, ICN namespaces,
which may be assigned by authoritative entities, must be securely mapped to
the content publishers and securely managed by them. According to the ICN
research challenges <span>[<a href="#RFC7927" class="xref">RFC7927</a>]</span>, a new namespace can also provide an integrity verification function to authenticate its
publisher.  The issues of namespace authentication and the mapping among
different namespaces require further investigation.<a href="#section-8-2.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-8-2.3">NRS system security:
</dt>
        <dd style="margin-left: 1.5em" id="section-8-2.4">An NRS requires the deployment of new entities (e.g., NRS servers) to
build distributed and scalable NRS systems.  Thus, the entities, e.g., an NRS
server maintaining a mapping database, could be the focus of attacks by
receiving malicious requests from innumerable adversaries comprising of
Denial-of-Service or Distributed-Denial-of-Service attacks.  In addition, NRS
clients in general must trust the NRS nodes in other network domains to some
degree, and communication among them must also be protected securely to prevent
malicious entities from participating in this communication. The history of
name resolution data requires to be stored and analyzed as in passive DNS to
uncover potential security incidents or discover malicious infrastructures.<a href="#section-8-2.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-8-2.5">NRS protocol and message security:
</dt>
        <dd style="margin-left: 1.5em" id="section-8-2.6">In an NRS system, the protocols to generate, transmit, and receive NRS
messages related to the name registration, resolution, and record update
should be protected by proper security mechanisms. Proper security measures
must be provided so that only legitimate nodes can initiate and read NRS
messages. These messages must be secured by integrity protection and
authentication mechanisms so that unauthorized parties cannot manipulate them
when being forwarded through the network. Security measures to encrypt these
messages should also be developed to thwart all threats to both security and
privacy. Numerous problems similar to the security issues of an IP network and
DNS can affect the overall ICN architecture.  The DNS QNAME minimization type
of approach would be suitable for preserving privacy in the name resolution
process.  Therefore, security mechanisms such as accessibility,
authentication, etc., for the NRS system <span>[<a href="#RFC9138" class="xref">RFC9138</a>]</span> should be considered to protect not only the NRS system but
also the ICN architecture overall.<a href="#section-8-2.6" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
</section>
<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="RFC7927">[RFC7927]</dt>
        <dd>
<span class="refAuthor">Kutscher, D., Ed.</span>, <span class="refAuthor">Eum, S.</span>, <span class="refAuthor">Pentikousis, K.</span>, <span class="refAuthor">Psaras, I.</span>, <span class="refAuthor">Corujo, D.</span>, <span class="refAuthor">Saucez, D.</span>, <span class="refAuthor">Schmidt, T.</span>, and <span class="refAuthor">M. Waehlisch</span>, <span class="refTitle">"Information-Centric Networking (ICN) Research Challenges"</span>, <span class="seriesInfo">RFC 7927</span>, <span class="seriesInfo">DOI 10.17487/RFC7927</span>, <time datetime="2016-07" class="refDate">July 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7927">https://www.rfc-editor.org/info/rfc7927</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8569">[RFC8569]</dt>
        <dd>
<span class="refAuthor">Mosko, M.</span>, <span class="refAuthor">Solis, I.</span>, and <span class="refAuthor">C. Wood</span>, <span class="refTitle">"Content-Centric Networking (CCNx) Semantics"</span>, <span class="seriesInfo">RFC 8569</span>, <span class="seriesInfo">DOI 10.17487/RFC8569</span>, <time datetime="2019-07" class="refDate">July 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8569">https://www.rfc-editor.org/info/rfc8569</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8609">[RFC8609]</dt>
        <dd>
<span class="refAuthor">Mosko, M.</span>, <span class="refAuthor">Solis, I.</span>, and <span class="refAuthor">C. Wood</span>, <span class="refTitle">"Content-Centric Networking (CCNx) Messages in TLV Format"</span>, <span class="seriesInfo">RFC 8609</span>, <span class="seriesInfo">DOI 10.17487/RFC8609</span>, <time datetime="2019-07" class="refDate">July 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8609">https://www.rfc-editor.org/info/rfc8609</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9138">[RFC9138]</dt>
      <dd>
<span class="refAuthor">Hong, J.</span>, <span class="refAuthor">You, T.</span>, <span class="refAuthor">Dong, L.</span>, <span class="refAuthor">Westphal, C.</span>, and <span class="refAuthor">B. Ohlman</span>, <span class="refTitle">"Design Considerations for Name Resolution Service in Information-Centric Networking (ICN)"</span>, <span class="seriesInfo">RFC 9138</span>, <span class="seriesInfo">DOI 10.17487/RFC9138</span>, <time datetime="2021-12" class="refDate">December 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9138">https://www.rfc-editor.org/info/rfc9138</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="Afanasyev">[Afanasyev]</dt>
        <dd>
<span class="refAuthor">Afanasyev, A.</span>, <span class="refAuthor">Yi, C.</span>, <span class="refAuthor">Wang, L.</span>, <span class="refAuthor">Zhang, B.</span>, and <span class="refAuthor">L. Zhang</span>, <span class="refTitle">"SNAMP: Secure namespace mapping to scale NDN forwarding"</span>, <span class="refContent">2015 IEEE Conference on Computer Communications
   Workshops (INFOCOM WKSHPS)</span>, <span class="seriesInfo">DOI 10.1109/INFCOMW.2015.7179398</span>, <time datetime="2015-04" class="refDate">April 2015</time>, <span>&lt;<a href="https://doi.org/10.1109/INFCOMW.2015.7179398">https://doi.org/10.1109/INFCOMW.2015.7179398</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Bayhan">[Bayhan]</dt>
        <dd>
<span class="refAuthor">Bayhan, S.</span>, <span class="refAuthor">Ott, J.</span>, <span class="refAuthor">Kangasharju, J.</span>, <span class="refAuthor">Sathiaseelan, A.</span>, and <span class="refAuthor">J. Crowcroft</span>, <span class="refTitle">"On Content Indexing for Off-Path Caching in Information-Centric Networks"</span>, <span class="refContent">ACM ICN</span>, <span class="seriesInfo">DOI 10.1145/2984356.2984372</span>, <time datetime="2016-09" class="refDate">September 2016</time>, <span>&lt;<a href="https://doi.org/10.1145/2984356.2984372">https://doi.org/10.1145/2984356.2984372</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="CCNx">[CCNx]</dt>
        <dd>
<span class="refTitle">"Cicn"</span>, <span>&lt;<a href="https://wiki.fd.io/view/Cicn">https://wiki.fd.io/view/Cicn</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.hong-icnrg-ccnx-nrs">[CCNxNRS]</dt>
        <dd>
<span class="refAuthor">Hong, J.</span>, <span class="refAuthor">You, T.</span>, and <span class="refAuthor">Y. Hong</span>, <span class="refTitle">"CCNx Extension for Name Resolution Service"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-hong-icnrg-ccnx-nrs-02</span>, <time datetime="2018-07-02" class="refDate">2 July 2018</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-hong-icnrg-ccnx-nrs-02">https://datatracker.ietf.org/doc/html/draft-hong-icnrg-ccnx-nrs-02</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Dannewitz">[Dannewitz]</dt>
        <dd>
<span class="refAuthor">Dannewitz, C.</span>, <span class="refAuthor">Kutscher, D.</span>, <span class="refAuthor">Ohlman, B.</span>, <span class="refAuthor">Farrell, S.</span>, <span class="refAuthor">Ahlgren, B.</span>, and <span class="refAuthor">H. Karl</span>, <span class="refTitle">"Network of Information (NetInf) - An information-centric networking architecture"</span>, <span class="refContent">Computer Communications vol. 36, issue 7</span>, <span class="seriesInfo">DOI 10.1016/j.comcom.2013.01.009</span>, <time datetime="2013-04" class="refDate">April 2013</time>, <span>&lt;<a href="https://doi.org/10.1016/j.comcom.2013.01.009">https://doi.org/10.1016/j.comcom.2013.01.009</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Dannewitz2">[Dannewitz2]</dt>
        <dd>
<span class="refAuthor">Dannewitz, C.</span>, <span class="refAuthor">D'Ambrosio, M.</span>, and <span class="refAuthor">V. Vercellone</span>, <span class="refTitle">"Hierarchical DHT-based name resolution for information-centric networks"</span>, <span class="refContent">Computer Communications vol. 36, issue 7</span>, <span class="seriesInfo">DOI 10.1016/j.comcom.2013.01.014</span>, <time datetime="2013-04" class="refDate">April 2013</time>, <span>&lt;<a href="https://doi.org/10.1016/j.comcom.2013.01.014">https://doi.org/10.1016/j.comcom.2013.01.014</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Hong">[Hong]</dt>
        <dd>
<span class="refAuthor">Hong, J.</span>, <span class="refAuthor">Chun, W.</span>, and <span class="refAuthor">H. Jung</span>, <span class="refTitle">"Demonstrating a Scalable Name Resolution System for Information-Centric Networking"</span>, <span class="refContent">ACM ICN</span>, <span class="seriesInfo">DOI 10.1145/2810156.2812617</span>, <time datetime="2015-09" class="refDate">September 2015</time>, <span>&lt;<a href="https://doi.org/10.1145/2810156.2812617">https://doi.org/10.1145/2810156.2812617</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="MF">[MF]</dt>
        <dd>
<span class="refAuthor">Future Internet Architecture (FIA)</span>, <span class="refTitle">"MobilityFirst"</span>, <span>&lt;<a href="http://mobilityfirst.cs.umass.edu/">http://mobilityfirst.cs.umass.edu/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="NDN">[NDN]</dt>
        <dd>
<span class="refAuthor">NDN</span>, <span class="refTitle">"Named Data Networking"</span>, <time datetime="2010-09" class="refDate">September 2010</time>, <span>&lt;<a href="https://www.named-data.net">https://www.named-data.net</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ravi-icnrg-ccn-forwarding-label">[Ravindran]</dt>
        <dd>
<span class="refAuthor">Ravindran, R.</span>, <span class="refAuthor">Chakraborti, A.</span>, and <span class="refAuthor">A. Azgin</span>, <span class="refTitle">"Forwarding Label support in CCN Protocol"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ravi-icnrg-ccn-forwarding-label-02</span>, <time datetime="2018-03-05" class="refDate">5 March 2018</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ravi-icnrg-ccn-forwarding-label-02">https://datatracker.ietf.org/doc/html/draft-ravi-icnrg-ccn-forwarding-label-02</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="SAIL">[SAIL]</dt>
        <dd>
<span class="refTitle">"Scalable and Adaptive Internet Solutions (SAIL)"</span>, <span>&lt;<a href="https://www.sail-project.eu/">https://www.sail-project.eu/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Zhang2">[Zhang2]</dt>
      <dd>
<span class="refAuthor">Zhang, Y.</span>, <span class="refAuthor">Afanasyev, A.</span>, <span class="refAuthor">Burke, J.</span>, and <span class="refAuthor">L. Zhang</span>, <span class="refTitle">"A Survey of Mobility Support in Named Data Networking"</span>, <span class="refContent">Named Data Networking</span>, <span class="refContent">Workshop on Name-Oriented Mobility: Architecture,
   Algorithms and Applications (NOM)</span>, <time datetime="2016-04" class="refDate">April 2016</time>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="Acknowledgements">
<section id="appendix-A">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="appendix-A-1">
        The authors would like to thank <span class="contact-name">Dave Oran</span> (ICNRG Co-chair)
        for very useful reviews and comments, which helped to
        immeasurably improve this document.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="appendix-B">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Jungha Hong</span></div>
<div dir="auto" class="left"><span class="org">ETRI</span></div>
<div dir="auto" class="left"><span class="extended-address">Yuseung-Gu</span></div>
<div dir="auto" class="left"><span class="street-address">218 Gajeong-ro</span></div>
<div dir="auto" class="left"><span class="locality">Daejeon</span></div>
<div dir="auto" class="left"><span class="postal-code">34129</span></div>
<div dir="auto" class="left"><span class="country-name">Republic of Korea</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:jhong@etri.re.kr" class="email">jhong@etri.re.kr</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Tae-Wan You</span></div>
<div dir="auto" class="left"><span class="org">ETRI</span></div>
<div dir="auto" class="left"><span class="extended-address">Yuseung-Gu</span></div>
<div dir="auto" class="left"><span class="street-address">218 Gajeong-ro</span></div>
<div dir="auto" class="left"><span class="locality">Daejeon</span></div>
<div dir="auto" class="left"><span class="postal-code">34129</span></div>
<div dir="auto" class="left"><span class="country-name">Republic of Korea</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:twyou@etri.re.kr" class="email">twyou@etri.re.kr</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Ved Kafle</span></div>
<div dir="auto" class="left"><span class="org">NICT</span></div>
<div dir="auto" class="left"><span class="extended-address">Koganei</span></div>
<div dir="auto" class="left">
<span class="street-address">4-2-1 Nukui-Kitamachi</span>, <span class="region">Tokyo</span>
</div>
<div dir="auto" class="left"><span class="postal-code">184-8795</span></div>
<div dir="auto" class="left"><span class="country-name">Japan</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:kafle@nict.go.jp" class="email">kafle@nict.go.jp</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>