File: rfc8979.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 (1908 lines) | stat: -rw-r--r-- 79,762 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 8979: Subscriber and Performance Policy Identifier Context Headers in the Network Service Header (NSH)</title>
<meta content="Behcet Sarikaya" name="author">
<meta content="Dirk von Hugo" name="author">
<meta content="Mohamed Boucadair" name="author">
<meta content="
       This document defines the Subscriber and Performance Policy Identifier Context Headers.  These Variable-Length Context Headers can be
      carried in the Network Service Header (NSH) and are used to inform Service
      Functions (SFs) of subscriber- and performance-related information for the
      sake of policy enforcement and appropriate Service Function Chaining (SFC)
      operations. The structure of each Context Header and their use and
      processing by NSH-aware nodes are described. 
    " name="description">
<meta content="xml2rfc 3.5.0" name="generator">
<meta content="subscriber policy" name="keyword">
<meta content="policy enforcement" name="keyword">
<meta content="subscriber" name="keyword">
<meta content="policy" name="keyword">
<meta content="quota" name="keyword">
<meta content="identification" name="keyword">
<meta content="implicit identification" name="keyword">
<meta content="service chain" name="keyword">
<meta content="service function chain" name="keyword">
<meta content="sfc" name="keyword">
<meta content="SFP" name="keyword">
<meta content="service function path" name="keyword">
<meta content="classification" name="keyword">
<meta content="5G" name="keyword">
<meta content="traffic steering" name="keyword">
<meta content="8979" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.5.0
    Python 3.6.10
    appdirs 1.4.4
    ConfigArgParse 1.2.3
    google-i18n-address 2.3.5
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.2
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.19.0
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.3.1
    requests 2.22.0
    setuptools 40.6.2
    six 1.14.0
    WeasyPrint 51
-->
<link href="rfc8979.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

  NOTE: Changes at the bottom of this file overrides some earlier settings.

  Once the style has stabilized and has been adopted as an official RFC style,
  this can be consolidated so that style settings occur only in one place, but
  for now the contents of this file consists first of the initial CSS work as
  provided to the RFC Formatter (xml2rfc) work, followed by itemized and
  commented changes found necssary during the development of the v3
  formatters.

*/

/* fonts */
@import url('https://fonts.googleapis.com/css?family=Noto+Sans'); /* Sans-serif */
@import url('https://fonts.googleapis.com/css?family=Noto+Serif'); /* Serif (print) */
@import url('https://fonts.googleapis.com/css?family=Roboto+Mono'); /* Monospace */

@viewport {
  zoom: 1.0;
  width: extend-to-zoom;
}
@-ms-viewport {
  width: extend-to-zoom;
  zoom: 1.0;
}
/* general and mobile first */
html {
}
body {
  max-width: 90%;
  margin: 1.5em auto;
  color: #222;
  background-color: #fff;
  font-size: 14px;
  font-family: 'Noto Sans', Arial, Helvetica, sans-serif;
  line-height: 1.6;
  scroll-behavior: smooth;
}
.ears {
  display: none;
}

/* headings */
#title, h1, h2, h3, h4, h5, h6 {
  margin: 1em 0 0.5em;
  font-weight: bold;
  line-height: 1.3;
}
#title {
  clear: both;
  border-bottom: 1px solid #ddd;
  margin: 0 0 0.5em 0;
  padding: 1em 0 0.5em;
}
.author {
  padding-bottom: 4px;
}
h1 {
  font-size: 26px;
  margin: 1em 0;
}
h2 {
  font-size: 22px;
  margin-top: -20px;  /* provide offset for in-page anchors */
  padding-top: 33px;
}
h3 {
  font-size: 18px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h4 {
  font-size: 16px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h5, h6 {
  font-size: 14px;
}
#n-copyright-notice {
  border-bottom: 1px solid #ddd;
  padding-bottom: 1em;
  margin-bottom: 1em;
}
/* general structure */
p {
  padding: 0;
  margin: 0 0 1em 0;
  text-align: left;
}
div, span {
  position: relative;
}
div {
  margin: 0;
}
.alignRight.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignRight.art-text pre {
  padding: 0;
}
.alignRight {
  margin: 1em 0;
}
.alignRight > *:first-child {
  border: none;
  margin: 0;
  float: right;
  clear: both;
}
.alignRight > *:nth-child(2) {
  clear: both;
  display: block;
  border: none;
}
svg {
  display: block;
}
.alignCenter.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignCenter.art-text pre {
  padding: 0;
}
.alignCenter {
  margin: 1em 0;
}
.alignCenter > *:first-child {
  border: none;
  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
     support flexbox yet.
  */
  display: table;
  margin: 0 auto;
}

/* lists */
ol, ul {
  padding: 0;
  margin: 0 0 1em 2em;
}
ol ol, ul ul, ol ul, ul ol {
  margin-left: 1em;
}
li {
  margin: 0 0 0.25em 0;
}
.ulCompact li {
  margin: 0;
}
ul.empty, .ulEmpty {
  list-style-type: none;
}
ul.empty li, .ulEmpty li {
  margin-top: 0.5em;
}
ul.compact, .ulCompact,
ol.compact, .olCompact {
  line-height: 100%;
  margin: 0 0 0 2em;
}

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

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

/* Figures */
tt, code, pre, code {
  background-color: #f9f9f9;
  font-family: 'Roboto Mono', monospace;
}
pre {
  border: 1px solid #eee;
  margin: 0;
  padding: 1em;
}
img {
  max-width: 100%;
}
figure {
  margin: 0;
}
figure blockquote {
  margin: 0.8em 0.4em 0.4em;
}
figcaption {
  font-style: italic;
  margin: 0 0 1em 0;
}
@media screen {
  pre {
    overflow-x: auto;
    max-width: 100%;
    max-width: calc(100% - 22px);
  }
}

/* aside, blockquote */
aside, blockquote {
  margin-left: 0;
  padding: 1.2em 2em;
}
blockquote {
  background-color: #f9f9f9;
  color: #111; /* Arlen: WCAG 2019 */
  border: 1px solid #ddd;
  border-radius: 3px;
  margin: 1em 0;
}
cite {
  display: block;
  text-align: right;
  font-style: italic;
}

/* tables */
table {
  width: 100%;
  margin: 0 0 1em;
  border-collapse: collapse;
  border: 1px solid #eee;
}
th, td {
  text-align: left;
  vertical-align: top;
  padding: 0.5em 0.75em;
}
th {
  text-align: left;
  background-color: #e9e9e9;
}
tr:nth-child(2n+1) > td {
  background-color: #f5f5f5;
}
table caption {
  font-style: italic;
  margin: 0;
  padding: 0;
  text-align: left;
}
table p {
  /* XXX to avoid bottom margin on table row signifiers. If paragraphs should
     be allowed within tables more generally, it would be far better to select on a class. */
  margin: 0;
}

/* pilcrow */
a.pilcrow {
  color: #666; /* Arlen: AHDJ 2019 */
  text-decoration: none;
  visibility: hidden;
  user-select: none;
  -ms-user-select: none;
  -o-user-select:none;
  -moz-user-select: none;
  -khtml-user-select: none;
  -webkit-user-select: none;
  -webkit-touch-callout: none;
}
@media screen {
  aside:hover > a.pilcrow,
  p:hover > a.pilcrow,
  blockquote:hover > a.pilcrow,
  div:hover > a.pilcrow,
  li:hover > a.pilcrow,
  pre:hover > a.pilcrow {
    visibility: visible;
  }
  a.pilcrow:hover {
    background-color: transparent;
  }
}

/* misc */
hr {
  border: 0;
  border-top: 1px solid #eee;
}
.bcp14 {
  font-variant: small-caps;
}

.role {
  font-variant: all-small-caps;
}

/* info block */
#identifiers {
  margin: 0;
  font-size: 0.9em;
}
#identifiers dt {
  width: 3em;
  clear: left;
}
#identifiers dd {
  float: left;
  margin-bottom: 0;
}
#identifiers .authors .author {
  display: inline-block;
  margin-right: 1.5em;
}
#identifiers .authors .org {
  font-style: italic;
}

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

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

.refInstance {
  margin-bottom: 1.25em;
}

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

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

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

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

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

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

/* pagination */
@media print {
  body {

    width: 100%;
  }
  p {
    orphans: 3;
    widows: 3;
  }
  #n-copyright-notice {
    border-bottom: none;
  }
  #toc, #n-introduction {
    page-break-before: always;
  }
  #toc {
    border-top: none;
    padding-top: 0;
  }
  figure, pre {
    page-break-inside: avoid;
  }
  figure {
    overflow: scroll;
  }
  h1, h2, h3, h4, h5, h6 {
    page-break-after: avoid;
  }
  h2+*, h3+*, h4+*, h5+*, h6+* {
    page-break-before: avoid;
  }
  pre {
    white-space: pre-wrap;
    word-wrap: break-word;
    font-size: 10pt;
  }
  table {
    border: 1px solid #ddd;
  }
  td {
    border-top: 1px solid #ddd;
  }
}

/* This is commented out here, as the string-set: doesn't
   pass W3C validation currently */
/*
.ears thead .left {
  string-set: ears-top-left content();
}

.ears thead .center {
  string-set: ears-top-center content();
}

.ears thead .right {
  string-set: ears-top-right content();
}

.ears tfoot .left {
  string-set: ears-bottom-left content();
}

.ears tfoot .center {
  string-set: ears-bottom-center content();
}

.ears tfoot .right {
  string-set: ears-bottom-right content();
}
*/

@page :first {
  padding-top: 0;
  @top-left {
    content: normal;
    border: none;
  }
  @top-center {
    content: normal;
    border: none;
  }
  @top-right {
    content: normal;
    border: none;
  }
}

@page {
  size: A4;
  margin-bottom: 45mm;
  padding-top: 20px;
  /* The follwing is commented out here, but set appropriately by in code, as
     the content depends on the document */
  /*
  @top-left {
    content: 'Internet-Draft';
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-left {
    content: string(ears-top-left);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-center {
    content: string(ears-top-center);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-right {
    content: string(ears-top-right);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @bottom-left {
    content: string(ears-bottom-left);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-center {
    content: string(ears-bottom-center);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-right {
      content: '[Page ' counter(page) ']';
      vertical-align: top;
      border-top: solid 1px #ccc;
  }
  */

}

/* Changes introduced to fix issues found during implementation */
/* Make sure links are clickable even if overlapped by following H* */
a {
  z-index: 2;
}
/* Separate body from document info even without intervening H1 */
section {
  clear: both;
}


/* Top align author divs, to avoid names without organization dropping level with org names */
.author {
  vertical-align: top;
}

/* Leave room in document info to show Internet-Draft on one line */
#identifiers dt {
  width: 8em;
}

/* Don't waste quite as much whitespace between label and value in doc info */
#identifiers dd {
  margin-left: 1em;
}

/* Give floating toc a background color (needed when it's a div inside section */
#toc {
  background-color: white;
}

/* Make the collapsed ToC header render white on gray also when it's a link */
@media screen and (max-width: 1023px) {
  #toc h2 a,
  #toc h2 a:link,
  #toc h2 a:focus,
  #toc h2 a:hover,
  #toc a.toplink,
  #toc a.toplink:hover {
    color: white;
    background-color: #444;
    text-decoration: none;
  }
}

/* Give the bottom of the ToC some whitespace */
@media screen and (min-width: 1024px) {
  #toc {
    padding: 0 0 1em 1em;
  }
}

/* Style section numbers with more space between number and title */
.section-number {
  padding-right: 0.5em;
}

/* prevent monospace from becoming overly large */
tt, code, pre, code {
  font-size: 95%;
}

/* Fix the height/width aspect for ascii art*/
pre.sourcecode,
.art-text pre {
  line-height: 1.12;
}


/* Add styling for a link in the ToC that points to the top of the document */
a.toplink {
  float: right;
  margin-right: 0.5em;
}

/* Fix the dl styling to match the RFC 7992 attributes */
dl > dt,
dl.dlParallel > dt {
  float: left;
  margin-right: 1em;
}
dl.dlNewline > dt {
  float: none;
}

/* Provide styling for table cell text alignment */
table td.text-left,
table th.text-left {
  text-align: left;
}
table td.text-center,
table th.text-center {
  text-align: center;
}
table td.text-right,
table th.text-right {
  text-align: right;
}

/* Make the alternative author contact informatio look less like just another
   author, and group it closer with the primary author contact information */
.alternative-contact {
  margin: 0.5em 0 0.25em 0;
}
address .non-ascii {
  margin: 0 0 0 2em;
}

/* With it being possible to set tables with alignment
  left, center, and right, { width: 100%; } does not make sense */
table {
  width: auto;
}

/* Avoid reference text that sits in a block with very wide left margin,
   because of a long floating dt label.*/
.references dd {
  overflow: visible;
}

/* Control caption placement */
caption {
  caption-side: bottom;
}

/* Limit the width of the author address vcard, so names in right-to-left
   script don't end up on the other side of the page. */

address.vcard {
  max-width: 30em;
  margin-right: auto;
}

/* For address alignment dependent on LTR or RTL scripts */
address div.left {
  text-align: left;
}
address div.right {
  text-align: right;
}

/* Provide table alignment support.  We can't use the alignX classes above
   since they do unwanted things with caption and other styling. */
table.right {
 margin-left: auto;
 margin-right: 0;
}
table.center {
 margin-left: auto;
 margin-right: auto;
}
table.left {
 margin-left: 0;
 margin-right: auto;
}

/* Give the table caption label the same styling as the figcaption */
caption a[href] {
  color: #222;
}

@media print {
  .toplink {
    display: none;
  }

  /* avoid overwriting the top border line with the ToC header */
  #toc {
    padding-top: 1px;
  }

  /* Avoid page breaks inside dl and author address entries */
  .vcard {
    page-break-inside: avoid;
  }

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: avoid-page;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc8979" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-sfc-serviceid-header-14" 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 8979</td>
<td class="center">Subscriber/Performance Policy Headers</td>
<td class="right">February 2021</td>
</tr></thead>
<tfoot><tr>
<td class="left">Sarikaya, et al.</td>
<td class="center">Standards Track</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/rfc8979" class="eref">8979</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Standards Track</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2021-02" class="published">February 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">B. Sarikaya</div>
</div>
<div class="author">
      <div class="author-name">D. von Hugo</div>
<div class="org">Deutsche Telekom</div>
</div>
<div class="author">
      <div class="author-name">M. Boucadair</div>
<div class="org">Orange</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8979</h1>
<h1 id="title">Subscriber and Performance Policy Identifier Context Headers in the Network Service Header (NSH)</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">This document defines the Subscriber and Performance Policy Identifier Context Headers.  These Variable-Length Context Headers can be
      carried in the Network Service Header (NSH) and are used to inform Service
      Functions (SFs) of subscriber- and performance-related information for the
      sake of policy enforcement and appropriate Service Function Chaining (SFC)
      operations. The structure of each Context Header and their use and
      processing by NSH-aware nodes are described.<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 is an Internet Standards Track document.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in 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/rfc8979">https://www.rfc-editor.org/info/rfc8979</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 toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-conventions-and-terminology" class="xref">Conventions and Terminology</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1" class="keepWithNext"><a href="#section-3" class="xref">3</a>.  <a href="#name-subscriber-identifier-nsh-v" class="xref">Subscriber Identifier NSH Variable-Length Context Header</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-performance-policy-identifi" class="xref">Performance Policy Identifier NSH Variable-Length Context Headers</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-mtu-considerations" class="xref">MTU Considerations</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty toc compact" 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-references" class="xref">References</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.8.2.1">
                <p id="section-toc.1-1.8.2.1.1"><a href="#section-8.1" class="xref">8.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.8.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.8.2.2">
                <p id="section-toc.1-1.8.2.2.1"><a href="#section-8.2" class="xref">8.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.8.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-appendix.a" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">This document discusses how to inform Service Functions (SFs) <span>[<a href="#RFC7665" class="xref">RFC7665</a>]</span> about subscriber and service policy
      information when required for the sake of policy enforcement within a
      single administrative domain. In particular, subscriber-related
      information may be required to enforce subscriber-specific SFC-based
      traffic policies. However, the information carried in packets may not be
      sufficient to unambiguously identify a subscriber.

      This document fills
      this void by specifying a new Network Service Header (NSH) <span>[<a href="#RFC8300" class="xref">RFC8300</a>]</span> Context Header to convey and disseminate such
      information within the boundaries of a single administrative domain. As
      discussed in <a href="#solutions" class="xref">Section 3</a>, the use of obfuscated and
      non-persistent identifiers is recommended.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">Also, traffic steering by means of SFC may be driven, for example, by
      Quality of Service (QoS) considerations. Typically, QoS information may
      serve as an input for the computation, establishment, and selection of
      the Service Function Path (SFP). Furthermore, the dynamic structuring of
      Service Function Chains and their subsequent SFPs may be conditioned by
      QoS requirements that will affect the identification,
      location, and sequencing of SF instances.

      Hence, the need arises to provide downstream
      SFs with a performance policy identifier in order for them to
      appropriately meet the QoS requirements. This document also
      specifies a new NSH Context Header (<a href="#sol2" class="xref">Section 4</a>) to
      convey such policy identifiers.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">The context information defined in this document can be applicable in
      the context of mobile networks (particularly in the 3GPP-defined (S)Gi
      interface) <span>[<a href="#I-D.ietf-sfc-use-case-mobility" class="xref">CASE-MOBILITY</a>]</span>.
      Typically, because of the widespread use of private IPv4 addresses in
      those networks, if the SFs to be invoked are located after a NAT
      function, the identification based on the internal IPv4 address is not
      possible once the NAT has been crossed. NAT functionality can reside in
      a distinct node. For a 4G 3GPP network, that node can be the Packet Data
      Network (PDN) Gateway (PGW) as specified in <span>[<a href="#TS23401" class="xref">TS23401</a>]</span>. For a 5G 3GPP network, it can be the User
      Plane Function (UPF) facing the external Data Network (DN) <span>[<a href="#TS23501" class="xref">TS23501</a>]</span>. As such, a mechanism to pass the internal
      information past the NAT boundary may optimize packet traversal within
      an SFC-enabled mobile network domain. Furthermore, some SFs that are not
      enabled on the PGW/UPF may require a subscriber identifier to properly
      operate (see, for example, those listed in <span>[<a href="#RFC8371" class="xref">RFC8371</a>]</span>). It is outside the scope of this document to
      include a comprehensive list of deployments that may make use of the
      Context Headers defined in the document.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">Since subscriber identifiers are distinct from those used to identify
      a performance policy and given that multiple policies may be associated
      with a single subscriber within a Service Function Chain, these
      identifiers are carried in distinct Context Headers rather than
being multiplexed in one single Context Header. This approach avoids a
      requirement for additional internal structure in the Context Headers to
      specify whether an identifier refers to a subscriber or to a policy.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">This document does not make any assumptions about the structure of
      subscriber or performance policy identifiers; each such identifier is
      treated as an opaque value. The semantics and validation of these
      identifiers are policies local to each SFC-enabled domain. This document
      focuses on the data plane behavior. Control plane considerations are
      out of the scope.<a href="#section-1-5" class="pilcrow">¶</a></p>
<p id="section-1-6">This document adheres to the SFC data plane architecture defined in
      <span>[<a href="#RFC7665" class="xref">RFC7665</a>]</span>. This document assumes the reader is
      familiar with <span>[<a href="#RFC8300" class="xref">RFC8300</a>]</span>.<a href="#section-1-6" class="pilcrow">¶</a></p>
<p id="section-1-7">This document assumes the NSH is used exclusively within a single
      administrative domain. This document follows the recommendations in
      <span>[<a href="#RFC8300" class="xref">RFC8300</a>]</span> for handling the Context Headers at both
      ingress and egress SFC boundary nodes (i.e., to strip the entire NSH,
      including Context Headers). Revealing any subscriber-related information
      to parties outside the SFC-enabled domain is avoided by design.
      Accordingly, the scope for privacy breaches and user tracking is limited
      to within the SFC-enabled domain where the NSH is used. It is assumed
      that appropriate mechanisms to monitor and audit an SFC-enabled domain
      to detect misbehavior and to deter misuse are in place.<a href="#section-1-7" class="pilcrow">¶</a></p>
<p id="section-1-8">MTU considerations are discussed in <a href="#MTU" class="xref">Section 5</a>.<a href="#section-1-8" class="pilcrow">¶</a></p>
</section>
<section id="section-2">
      <h2 id="name-conventions-and-terminology">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-conventions-and-terminology" class="section-name selfRef">Conventions and Terminology</a>
      </h2>
<p id="section-2-1">
    The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>", "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>", "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
    "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document are to be interpreted as
    described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> 
    when, and only when, they appear in all capitals, as shown here.<a href="#section-2-1" class="pilcrow">¶</a></p>
<p id="section-2-2">The reader should be familiar with the terms defined in <span>[<a href="#RFC7665" class="xref">RFC7665</a>]</span>.<a href="#section-2-2" class="pilcrow">¶</a></p>
<p id="section-2-3">"SFC Control Element" refers to a logical entity that instructs one or
      more SFC data plane functional elements on how to process packets within
      an SFC-enabled domain.<a href="#section-2-3" class="pilcrow">¶</a></p>
</section>
<div id="solutions">
<section id="section-3">
      <h2 id="name-subscriber-identifier-nsh-v">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-subscriber-identifier-nsh-v" class="section-name selfRef">Subscriber Identifier NSH Variable-Length Context Header</a>
      </h2>
<p id="section-3-1">Subscriber Identifier is defined as an optional Variable-Length NSH
      Context Header. Its structure is shown in <a href="#arch7" class="xref">Figure 1</a>.<a href="#section-3-1" class="pilcrow">¶</a></p>
<span id="name-subscriber-identifier-varia"></span><div id="arch7">
<figure id="figure-1">
        <div class="artwork art-text alignLeft" id="section-3-2.1">
<pre>
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Metadata Class       |      Type     |U|    Length   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                      Subscriber Identifier                    ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-subscriber-identifier-varia" class="selfRef">Subscriber Identifier Variable-Length Context Header</a>
        </figcaption></figure>
</div>
<p id="section-3-3">The fields are described as follows:<a href="#section-3-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3-4">
        <dt id="section-3-4.1">Metadata Class:</dt>
        <dd style="margin-left: 1.5em" id="section-3-4.2">
          <span class="bcp14">MUST</span> be set to 0x0 <span>[<a href="#RFC8300" class="xref">RFC8300</a>]</span>.<a href="#section-3-4.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-4.3">Type:</dt>
        <dd style="margin-left: 1.5em" id="section-3-4.4">0x00 (see <a href="#IANA" class="xref">Section 6</a>).<a href="#section-3-4.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-4.5">U bit:</dt>
        <dd style="margin-left: 1.5em" id="section-3-4.6">Unassigned bit (see <span><a href="https://www.rfc-editor.org/rfc/rfc8300#section-2.5.1" class="relref">Section 2.5.1</a> of [<a href="#RFC8300" class="xref">RFC8300</a>]</span>).<a href="#section-3-4.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-4.7">Length:</dt>
        <dd style="margin-left: 1.5em" id="section-3-4.8">Indicates the length of the Subscriber Identifier, in
          bytes (see <span><a href="https://www.rfc-editor.org/rfc/rfc8300#section-2.5.1" class="relref">Section 2.5.1</a> of [<a href="#RFC8300" class="xref">RFC8300</a>]</span>).<a href="#section-3-4.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-4.9">Subscriber Identifier:</dt>
        <dd style="margin-left: 1.5em" id="section-3-4.10">
          <p id="section-3-4.10.1">Carries an opaque local identifier that is
          assigned to a subscriber by a network operator.<a href="#section-3-4.10.1" class="pilcrow">¶</a></p>
<p id="section-3-4.10.2">While this document does not specify an internal
          structure for these identifiers, it also does not provide any
          cryptographic protection for them; any internal structure to the
          identifier values chosen will thus be visible on the wire if no
          secure transport encapsulation is used. Accordingly, in alignment
          with <span><a href="https://www.rfc-editor.org/rfc/rfc8300#section-8.2.2" class="relref">Section 8.2.2</a> of [<a href="#RFC8300" class="xref">RFC8300</a>]</span>, identifier
          values <span class="bcp14">SHOULD</span> be obfuscated.<a href="#section-3-4.10.2" class="pilcrow">¶</a></p>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-3-5">The Subscriber Identifier Context Header is used by SFs
      to enforce per-subscriber policies (e.g., resource quota, customized
      filtering profile, accounting). To that aim, network operators may rely
      on identifiers that are generated from those used in legacy deployments
      (e.g., <span><a href="https://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility-09#section-3.3" class="relref">Section 3.3</a> of [<a href="#I-D.ietf-sfc-use-case-mobility" class="xref">CASE-MOBILITY</a>]</span>). Alternatively, network
      operators may use identifiers that are associated with customized policy
      profiles that are preconfigured on SFs using an out-of-band mechanism.
      Such a mechanism can be used to rotate the identifiers, thus allowing for
      better unlinkability (<span><a href="https://www.rfc-editor.org/rfc/rfc6973#section-3.2" class="relref">Section 3.2</a> of [<a href="#RFC6973" class="xref">RFC6973</a>]</span>).
      Such alternative methods may be suboptimal (e.g., scalability issues
      induced by maintaining and processing finer granular profiles) or
      inadequate for providing some per-subscriber policies. The assessment of
      whether a method for defining a subscriber identifier provides the
      required functionality and whether
      it is compatible with the capabilities of the SFs at 
      the intended performance level is deployment specific.<a href="#section-3-5" class="pilcrow">¶</a></p>
<p id="section-3-6">The classifier and NSH-aware SFs <span class="bcp14">MAY</span> inject a Subscriber Identifier
      Context Header as a function of a local policy. This local policy should
      indicate the SFP(s) for which the Subscriber Identifier Context Header
      will be added. In order to prevent interoperability issues, the type and
      format of the identifiers to be injected in a Subscriber Identifier
      Context Header should be configured to nodes authorized to inject and
      consume such headers. For example, a node can be instructed to insert
      such data following a type/set scheme (e.g., node X should inject
      subscriber ID type Y). Other schemes may be envisaged.<a href="#section-3-6" class="pilcrow">¶</a></p>
<p id="section-3-7">Failures to inject such headers should be logged locally, while a
      notification alarm may be sent to a Control Element. The details of
      sending notification alarms (i.e., the parameters affecting the
      transmission of the notification alarms) might depend on the nature of
      the information in the Context Header. Parameters for sending alarms,
      such as frequency, thresholds, and content of the alarm, should be
      configurable.<a href="#section-3-7" class="pilcrow">¶</a></p>
<p id="section-3-8">The default behavior of intermediary NSH-aware nodes is to preserve
      Subscriber Identifier Context Headers (i.e., the information can be
      passed to next-hop NSH-aware nodes), but local policy may require an
      intermediary NSH-aware node to strip a Subscriber Identifier Context
      Header after processing it.<a href="#section-3-8" class="pilcrow">¶</a></p>
<p id="section-3-9">NSH-aware SFs <span class="bcp14">MUST</span> ignore Context Headers carrying unknown subscriber
      identifiers.<a href="#section-3-9" class="pilcrow">¶</a></p>
<p id="section-3-10">Local policies at NSH-aware SFs may require running additional
      validation checks on the content of these Context Headers (e.g., accepting
      only some lengths or types). These policies may also indicate the
      behavior to be followed by an NSH-aware SF if the validation checks fail
      (e.g., removing the Context Header from the packet). These additional
      validation checks are deployment specific. If validation checks fail on
      a Subscriber Identifier Context Header, an NSH-aware SF <span class="bcp14">MUST</span> ignore that
      Context Header. The event should be logged locally, while a notification
      alarm may be sent to a Control Element if the NSH-aware SF is instructed
      to do so. For example, an SF will discard Subscriber Identifier
      Context Headers conveying identifiers in all formats that are different from the
      one the SF is instructed to expect.<a href="#section-3-10" class="pilcrow">¶</a></p>
<p id="section-3-11">Multiple Subscriber Identifier Context Headers <span class="bcp14">MAY</span> be present in the
      NSH, each carrying a distinct opaque value but all pointing to the same
      subscriber. This may be required, e.g., by policy enforcement mechanisms
      in a mobile network where some SFs rely on IP addresses as subscriber
      identifiers, while others use non-IP-specific identifiers such as those
      listed in <span>[<a href="#RFC8371" class="xref">RFC8371</a>]</span> and <span><a href="https://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility-09#section-3.3.2" class="relref">Section 3.3.2</a> of [<a href="#I-D.ietf-sfc-use-case-mobility" class="xref">CASE-MOBILITY</a>]</span>. When multiple
      Subscriber Identifier Context Headers are present and an SF is
      instructed to strip the Subscriber Identifier Context Header, that SF
      <span class="bcp14">MUST</span> remove all Subscriber Identifier Context Headers.<a href="#section-3-11" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sol2">
<section id="section-4">
      <h2 id="name-performance-policy-identifi">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-performance-policy-identifi" class="section-name selfRef">Performance Policy Identifier NSH Variable-Length Context Headers</a>
      </h2>
<p id="section-4-1">Dedicated service-specific performance identifiers are defined to
      differentiate between services that require specific treatment in order
      to exhibit a performance characterized by, e.g., ultra-low latency (ULL)
      or ultra-high reliability (UHR). Other policies can be considered when
      instantiating a Service Function Chain within an SFC-enabled domain.
      They are conveyed in the Performance Policy Identifier Context
      Header.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">The Performance Policy Identifier Context Header is inserted in an NSH packet so that downstream NSH-aware nodes can make use of the performance information for proper selection of suitably distributed SFC paths, SF instances, or applicable policy at SFs. Note that the use of the performance policy identifier is not helpful if the path computation is
      centralized and a strict SFP is presented as local policy to SF
      Forwarders (SFFs).<a href="#section-4-2" class="pilcrow">¶</a></p>
<p id="section-4-3">The Performance Policy Identifier Context Header allows for the distributed
      enforcement of a per-service policy such as requiring
      an SFP to
      only include specific SF instances (e.g., SFs located within the same
      Data Center (DC) or those that are exposing the shortest delay from an SFF). Details
      of this process are implementation specific. For illustration purposes,
      an SFF may retrieve the details of usable SFs based upon the
      corresponding performance policy identifier. Typical criteria for
      instantiating specific SFs include location, performance, or proximity
      considerations. For the particular case of UHR services, the standby
      operation of backup capacity or the presence of SFs deployed in
      multiple instances may be requested.<a href="#section-4-3" class="pilcrow">¶</a></p>
<p id="section-4-4">In an environment characterized by frequent changes of link and path
      behavior (for example, due to variable load or availability caused by
      propagation conditions on a wireless link), the SFP may have to be
      adapted dynamically by on-the-move SFC path and SF instance
      selection.<a href="#section-4-4" class="pilcrow">¶</a></p>
<p id="section-4-5">Performance Policy Identifier is defined as an optional Variable-Length Context Header. Its structure is shown in <a href="#arch9" class="xref">Figure 2</a>.<a href="#section-4-5" class="pilcrow">¶</a></p>
<p id="section-4-6">The default behavior of intermediary NSH-aware nodes is to preserve
      such Context Headers (i.e., the information can be passed to next-hop
      NSH-aware nodes), but local policy may require an intermediary NSH-aware
      node to strip one Context Header after processing it.<a href="#section-4-6" class="pilcrow">¶</a></p>
<p id="section-4-7">Multiple Performance Policy Identifier Context Headers <span class="bcp14">MAY</span> be present
      in the NSH, each carrying an opaque value for a distinct policy that
      needs to be enforced for a flow. Supplying conflicting policies may
      complicate the SFP computation and SF instance location. Corresponding
      rules to detect conflicting policies may be provided as a local policy
      to the NSH-aware nodes. When such conflict is detected by an NSH-aware
      node, the default behavior of the node is to discard the packet and send
      a notification alarm to a Control Element.<a href="#section-4-7" class="pilcrow">¶</a></p>
<span id="name-performance-policy-identifie"></span><div id="arch9">
<figure id="figure-2">
        <div class="artwork art-text alignLeft" id="section-4-8.1">
<pre>
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Metadata Class       |      Type     |U|    Length   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                     Performance Policy Identifier             ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-performance-policy-identifie" class="selfRef">Performance Policy Identifier Variable-Length Context Header</a>
        </figcaption></figure>
</div>
<p id="section-4-9">The fields are described as follows:<a href="#section-4-9" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4-10">
        <dt id="section-4-10.1">Metadata Class:</dt>
        <dd style="margin-left: 1.5em" id="section-4-10.2">
          <span class="bcp14">MUST</span> be set to 0x0 <span>[<a href="#RFC8300" class="xref">RFC8300</a>]</span>.<a href="#section-4-10.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-4-10.3">Type:</dt>
        <dd style="margin-left: 1.5em" id="section-4-10.4">0x01 (see <a href="#IANA" class="xref">Section 6</a>).<a href="#section-4-10.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-4-10.5">U bit:</dt>
        <dd style="margin-left: 1.5em" id="section-4-10.6">Unassigned bit (see <span><a href="https://www.rfc-editor.org/rfc/rfc8300#section-2.5.1" class="relref">Section 2.5.1</a> of [<a href="#RFC8300" class="xref">RFC8300</a>]</span>).<a href="#section-4-10.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-4-10.7">Length:</dt>
        <dd style="margin-left: 1.5em" id="section-4-10.8">Indicates the length of the Performance Policy
          Identifier, in bytes (see <span><a href="https://www.rfc-editor.org/rfc/rfc8300#section-2.5.1" class="relref">Section 2.5.1</a> of [<a href="#RFC8300" class="xref">RFC8300</a>]</span>).<a href="#section-4-10.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-4-10.9">Performance Policy Identifier:</dt>
        <dd style="margin-left: 1.5em" id="section-4-10.10">Represents an opaque value
          pointing to a specific performance policy to be enforced. The
          structure and semantics of this field are deployment specific.<a href="#section-4-10.10" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
</section>
</div>
<div id="MTU">
<section id="section-5">
      <h2 id="name-mtu-considerations">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-mtu-considerations" class="section-name selfRef">MTU Considerations</a>
      </h2>
<p id="section-5-1">As discussed in <span><a href="https://www.rfc-editor.org/rfc/rfc7665#section-5.6" class="relref">Section 5.6</a> of [<a href="#RFC7665" class="xref">RFC7665</a>]</span>, the
      SFC architecture prescribes that additional information be added to
      packets to:<a href="#section-5-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5-2.1">Identify SFPs. This is typically the NSH Base Header (<span><a href="https://www.rfc-editor.org/rfc/rfc8300#section-2.2" class="relref">Section 2.2</a> of [<a href="#RFC8300" class="xref">RFC8300</a>]</span>) and Service Path Header (<span><a href="https://www.rfc-editor.org/rfc/rfc8300#section-2.3" class="relref">Section 2.3</a> of [<a href="#RFC8300" class="xref">RFC8300</a>]</span>).<a href="#section-5-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-5-2.2">Carry metadata such those defined in Sections <a href="#solutions" class="xref">3</a> and <a href="#sol2" class="xref">4</a>.<a href="#section-5-2.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-5-2.3">Steer the traffic along the SFPs: This is realized by means of transport encapsulation.<a href="#section-5-2.3" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-5-3">This added information increases the size of the packet to be carried
      along an SFP.<a href="#section-5-3" class="pilcrow">¶</a></p>
<p id="section-5-4">Aligned with <span><a href="https://www.rfc-editor.org/rfc/rfc8300#section-5" class="relref">Section 5</a> of [<a href="#RFC8300" class="xref">RFC8300</a>]</span>, it is
      <span class="bcp14">RECOMMENDED</span> for network operators to increase the underlying MTU so that
      NSH traffic is forwarded within an SFC-enabled domain without
      fragmentation. The available underlying MTU should be taken into account
      by network operators when providing SFs with the required Context
      Headers to be injected per SFP and the size of the data to be carried in
      these Context Headers.<a href="#section-5-4" class="pilcrow">¶</a></p>
<p id="section-5-5">If the underlying MTU cannot be increased to accommodate the NSH
      overhead, network operators may rely upon a transport encapsulation
      protocol with the required fragmentation handling. The impact of
      activating such feature on SFFs should be carefully assessed by network
      operators (<span><a href="https://www.rfc-editor.org/rfc/rfc7665#section-5.6" class="relref">Section 5.6</a> of [<a href="#RFC7665" class="xref">RFC7665</a>]</span>).<a href="#section-5-5" class="pilcrow">¶</a></p>
<p id="section-5-6">When dealing with MTU issues, network operators should consider the
      limitations of various transport encapsulations such as those discussed
      in <span>[<a href="#I-D.ietf-intarea-tunnels" class="xref">INTAREA-TUNNELS</a>]</span>.<a href="#section-5-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="IANA">
<section id="section-6">
      <h2 id="name-iana-considerations">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-6-1">IANA has assigned the following types from the
      "NSH IETF-Assigned Optional Variable-Length Metadata Types" subregistry (0x0000
      IETF Base NSH MD Class) available at:
      <span>&lt;<a href="https://www.iana.org/assignments/nsh">https://www.iana.org/assignments/nsh</a>&gt;</span>.<a href="#section-6-1" class="pilcrow">¶</a></p>
<span id="name-nsh-ietf-assigned-optional-"></span><table class="center" id="table-1">
        <caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-nsh-ietf-assigned-optional-" class="selfRef">NSH IETF-Assigned Optional Variable-Length Metadata Types Additions</a>
        </caption>
<thead>
          <tr>
            <th class="text-left" rowspan="1" colspan="1">Value</th>
            <th class="text-left" rowspan="1" colspan="1">Description</th>
            <th class="text-left" rowspan="1" colspan="1">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">0x00</td>
            <td class="text-left" rowspan="1" colspan="1">Subscriber Identifier</td>
            <td class="text-left" rowspan="1" colspan="1">[RFC8979]</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">0x01</td>
            <td class="text-left" rowspan="1" colspan="1">Performance Policy Identifier</td>
            <td class="text-left" rowspan="1" colspan="1">[RFC8979]</td>
          </tr>
        </tbody>
      </table>
</section>
</div>
<div id="Security">
<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">Data plane SFC-related security considerations, including privacy,
      are discussed in <span><a href="https://www.rfc-editor.org/rfc/rfc7665#section-6" class="relref">Section 6</a> of [<a href="#RFC7665" class="xref">RFC7665</a>]</span> and <span><a href="https://www.rfc-editor.org/rfc/rfc8300#section-8" class="relref">Section 8</a> of [<a href="#RFC8300" class="xref">RFC8300</a>]</span>. In particular, <span><a href="https://www.rfc-editor.org/rfc/rfc8300#section-8.2.2" class="relref">Section 8.2.2</a> of [<a href="#RFC8300" class="xref">RFC8300</a>]</span> states that attached metadata (i.e.,
      Context Headers) should be limited to that necessary for correct
      operation of the SFP. <span><a href="https://www.rfc-editor.org/rfc/rfc8300#section-8.2.2" class="relref">Section 8.2.2</a> of [<a href="#RFC8300" class="xref">RFC8300</a>]</span> indicates that metadata
      considerations that operators can take into account when using NSH are
      discussed in <span>[<a href="#RFC8165" class="xref">RFC8165</a>]</span>.<a href="#section-7-1" class="pilcrow">¶</a></p>
<p id="section-7-2">As specified in <span>[<a href="#RFC8300" class="xref">RFC8300</a>]</span>, means to prevent
      leaking privacy-related information outside an SFC-enabled domain are
      natively supported by the NSH given that the last SFF of an SFP will
      systematically remove the NSH (and therefore the identifiers defined in
      this specification) before forwarding a packet exiting the SFP.<a href="#section-7-2" class="pilcrow">¶</a></p>
<p id="section-7-3">Nodes that are involved in an SFC-enabled domain are assumed to be
      trusted (<span><a href="https://www.rfc-editor.org/rfc/rfc8300#section-1.1" class="relref">Section 1.1</a> of [<a href="#RFC8300" class="xref">RFC8300</a>]</span>). Discussion of means to check
      that only authorized nodes are traversed when a packet is crossing an
      SFC-enabled domain is out of scope of this document.<a href="#section-7-3" class="pilcrow">¶</a></p>
<p id="section-7-4">Both Subscriber Identifier and Performance Policy Identifier Context Headers
      carry opaque data. In particular, the Subscriber Identifier Context Header is locally assigned by a network
      provider and can be generated from some of the information that is
      already conveyed in the original packets from a host (e.g., internal IP
      address) or other information that is collected from various sources
      within an SFC-enabled domain (e.g., line identifier). The structure of
      the identifiers conveyed in these Context Headers is communicated only
      to entitled NSH-aware nodes. Nevertheless, some structures may be easily
      inferred from the headers if trivial structures are used (e.g., IP
      addresses). As persistent identifiers facilitate tracking over time, the
      use of indirect and non-persistent identification is thus
      <span class="bcp14">RECOMMENDED</span>.<a href="#section-7-4" class="pilcrow">¶</a></p>
<p id="section-7-5">Moreover, the presence of multiple Subscriber Identifier Context
      Headers in the same NSH allows a misbehaving node from within the
      SFC-enabled domain to bind these identifiers to the same subscriber.
      This can be used to track that subscriber more effectively.    
      
      The use of non-persistent (e.g., regularly randomized) identifiers as
      well as the removal of the Subscriber Identifier Context Headers from
      the NSH by the last SF making use of such headers soften this issue
      (see "data minimization" discussed in <span><a href="https://www.rfc-editor.org/rfc/rfc8165#section-3" class="relref">Section 3</a> of [<a href="#RFC8165" class="xref">RFC8165</a>]</span>).
      Such behavior is especially strongly recommended in case no 
      encryption is enabled.<a href="#section-7-5" class="pilcrow">¶</a></p>
<p id="section-7-6">A misbehaving node from within the SFC-enabled domain may alter the
      content of Subscriber Identifier and Performance Policy Identifier Context Headers,
      which may lead to service disruption. Such an attack is not unique to the
      Context Headers defined in this document; measures discussed in <span><a href="https://www.rfc-editor.org/rfc/rfc8300#section-8" class="relref">Section 8</a> of [<a href="#RFC8300" class="xref">RFC8300</a>]</span> are to be followed. A mechanism for
      NSH integrity is specified in <span>[<a href="#I-D.ietf-sfc-nsh-integrity" class="xref">NSH-INTEGRITY</a>]</span>.<a href="#section-7-6" class="pilcrow">¶</a></p>
<p id="section-7-7">If no secure transport encapsulation is enabled, the use of trivial
      subscriber identifier structures, together with the presence of specific
      SFs in a Service Function Chain, may reveal sensitive information to
      every on-path device. Also, operational staff in 
teams managing these
devices could gain access to such user privacy-affecting data.

Such
      disclosure can be a violation of legal requirements because such
      information should be available to very few network operator personnel.
      Furthermore, access to subscriber data usually requires specific access
      privilege levels. To maintain that protection, an SF keeping operational
      logs should not log the content of Subscriber and Performance Policy
      Identifier Context Headers unless the SF actually uses the content of these headers
      for its operation. As discussed in <span><a href="https://www.rfc-editor.org/rfc/rfc8300#section-8.2.2" class="relref">Section 8.2.2</a> of [<a href="#RFC8300" class="xref">RFC8300</a>]</span>, subscriber-identifying information should be
      obfuscated, and, if an operator deems cryptographic integrity protection is needed, security features in the transport encapsulation protocol (such
      as IPsec) must be used. A mechanism for encrypting sensitive NSH data is
      specified in <span>[<a href="#I-D.ietf-sfc-nsh-integrity" class="xref">NSH-INTEGRITY</a>]</span>. This
      mechanism can be considered by network operators when enhanced SF-to-SF
      security protection of NSH metadata is required (e.g., to protect against
      compromised SFFs).<a href="#section-7-7" class="pilcrow">¶</a></p>
<p id="section-7-8">Some events are logged locally with notification alerts sent by
      NSH-aware nodes to a Control Element. These events <span class="bcp14">SHOULD</span> be rate
      limited.<a href="#section-7-8" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-8">
      <h2 id="name-references">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-8.1">
        <h3 id="name-normative-references">
<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7665">[RFC7665]</dt>
        <dd>
<span class="refAuthor">Halpern, J., Ed.</span><span class="refAuthor"> and C. Pignataro, Ed.</span>, <span class="refTitle">"Service Function Chaining (SFC) Architecture"</span>, <span class="seriesInfo">RFC 7665</span>, <span class="seriesInfo">DOI 10.17487/RFC7665</span>, <time datetime="2015-10" class="refDate">October 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7665">https://www.rfc-editor.org/info/rfc7665</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="RFC8300">[RFC8300]</dt>
      <dd>
<span class="refAuthor">Quinn, P., Ed.</span><span class="refAuthor">, Elzur, U., Ed.</span><span class="refAuthor">, and C. Pignataro, Ed.</span>, <span class="refTitle">"Network Service Header (NSH)"</span>, <span class="seriesInfo">RFC 8300</span>, <span class="seriesInfo">DOI 10.17487/RFC8300</span>, <time datetime="2018-01" class="refDate">January 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8300">https://www.rfc-editor.org/info/rfc8300</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-8.2">
        <h3 id="name-informative-references">
<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="I-D.ietf-sfc-use-case-mobility">[CASE-MOBILITY]</dt>
        <dd>
<span class="refAuthor">Haeffner, W.</span><span class="refAuthor">, Napper, J.</span><span class="refAuthor">, Stiemerling, M.</span><span class="refAuthor">, Lopez, D. R.</span><span class="refAuthor">, and J. Uttaro</span>, <span class="refTitle">"Service Function Chaining Use Cases in Mobile Networks"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-sfc-use-case-mobility-09</span>, <time datetime="2019-01-01" class="refDate">1 January 2019</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility-09">https://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility-09</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-intarea-tunnels">[INTAREA-TUNNELS]</dt>
        <dd>
<span class="refAuthor">Touch, J.</span><span class="refAuthor"> and M. Townsley</span>, <span class="refTitle">"IP Tunnels in the Internet Architecture"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-intarea-tunnels-10</span>, <time datetime="2019-09-12" class="refDate">12 September 2019</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-intarea-tunnels-10">https://tools.ietf.org/html/draft-ietf-intarea-tunnels-10</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-sfc-nsh-integrity">[NSH-INTEGRITY]</dt>
        <dd>
<span class="refAuthor">Boucadair, M.</span><span class="refAuthor">, Reddy.K, T.</span><span class="refAuthor">, and D. Wing</span>, <span class="refTitle">"Integrity Protection for the Network Service Header (NSH) and Encryption of Sensitive Context Headers"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-sfc-nsh-integrity-03</span>, <time datetime="2021-01-22" class="refDate">22 January 2021</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-sfc-nsh-integrity-03">https://tools.ietf.org/html/draft-ietf-sfc-nsh-integrity-03</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6973">[RFC6973]</dt>
        <dd>
<span class="refAuthor">Cooper, A.</span><span class="refAuthor">, Tschofenig, H.</span><span class="refAuthor">, Aboba, B.</span><span class="refAuthor">, Peterson, J.</span><span class="refAuthor">, Morris, J.</span><span class="refAuthor">, Hansen, M.</span><span class="refAuthor">, and R. Smith</span>, <span class="refTitle">"Privacy Considerations for Internet Protocols"</span>, <span class="seriesInfo">RFC 6973</span>, <span class="seriesInfo">DOI 10.17487/RFC6973</span>, <time datetime="2013-07" class="refDate">July 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6973">https://www.rfc-editor.org/info/rfc6973</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8165">[RFC8165]</dt>
        <dd>
<span class="refAuthor">Hardie, T.</span>, <span class="refTitle">"Design Considerations for Metadata Insertion"</span>, <span class="seriesInfo">RFC 8165</span>, <span class="seriesInfo">DOI 10.17487/RFC8165</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8165">https://www.rfc-editor.org/info/rfc8165</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8371">[RFC8371]</dt>
        <dd>
<span class="refAuthor">Perkins, C.</span><span class="refAuthor"> and V. Devarapalli</span>, <span class="refTitle">"Mobile Node Identifier Types for MIPv6"</span>, <span class="seriesInfo">RFC 8371</span>, <span class="seriesInfo">DOI 10.17487/RFC8371</span>, <time datetime="2018-07" class="refDate">July 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8371">https://www.rfc-editor.org/info/rfc8371</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="TS23401">[TS23401]</dt>
        <dd>
<span class="refAuthor">3GPP</span>, <span class="refTitle">"General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access, Release 16"</span>, <span class="seriesInfo">Version 16.5.0</span>, <span class="seriesInfo">TS 23.401</span>, <time datetime="2019-12" class="refDate">December 2019</time>. </dd>
<dd class="break"></dd>
<dt id="TS23501">[TS23501]</dt>
      <dd>
<span class="refAuthor">3GPP</span>, <span class="refTitle">"System architecture for the 5G System (5GS), Release 16"</span>, <span class="seriesInfo">Version 16.3.0</span>, <span class="seriesInfo">TS 23.501</span>, <time datetime="2019-12" class="refDate">December 2019</time>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<section id="section-appendix.a">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="section-appendix.a-1">Comments from <span class="contact-name">Joel Halpern</span> on a previous draft version and from <span class="contact-name">Carlos       Bernardos</span> are appreciated.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
<p id="section-appendix.a-2">Contributions and review by <span class="contact-name">Christian Jacquenet</span>, <span class="contact-name">Danny Lachos</span>,
      <span class="contact-name">Debashish Purkayastha</span>, <span class="contact-name">Christian Esteve Rothenberg</span>, <span class="contact-name">Kyle Larose</span>, <span class="contact-name">Donald       Eastlake</span>, <span class="contact-name">Qin Wu</span>, <span class="contact-name">Shunsuke Homma</span>, and <span class="contact-name">Greg Mirsky</span> are thankfully
      acknowledged.<a href="#section-appendix.a-2" class="pilcrow">¶</a></p>
<p id="section-appendix.a-3">Many thanks to <span class="contact-name">Robert Sparks</span> for the secdir review.<a href="#section-appendix.a-3" class="pilcrow">¶</a></p>
<p id="section-appendix.a-4">Thanks to <span class="contact-name">Barry Leiba</span>, <span class="contact-name">Erik Kline</span>, <span class="contact-name">Éric Vyncke</span>, <span class="contact-name">Robert Wilton</span>, and
      <span class="contact-name">Magnus Westerlund</span> for the IESG review.<a href="#section-appendix.a-4" class="pilcrow">¶</a></p>
<p id="section-appendix.a-5">Special thanks to <span class="contact-name">Benjamin Kaduk</span> for the careful review and
      suggestions that enhanced this specification.<a href="#section-appendix.a-5" class="pilcrow">¶</a></p>
</section>
<div id="authors-addresses">
<section id="section-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">Behcet Sarikaya</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:sarikaya@ieee.org" class="email">sarikaya@ieee.org</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Dirk von Hugo</span></div>
<div dir="auto" class="left"><span class="org">Deutsche Telekom</span></div>
<div dir="auto" class="left"><span class="street-address">Deutsche-Telekom-Allee 9</span></div>
<div dir="auto" class="left">
<span class="postal-code">D-64295</span> <span class="locality">Darmstadt</span>
</div>
<div dir="auto" class="left"><span class="country-name">Germany</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:Dirk.von-Hugo@telekom.de" class="email">Dirk.von-Hugo@telekom.de</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Mohamed Boucadair</span></div>
<div dir="auto" class="left"><span class="org">Orange</span></div>
<div dir="auto" class="left">
<span class="postal-code">3500</span> <span class="locality">Rennes</span>
</div>
<div dir="auto" class="left"><span class="country-name">France</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:mohamed.boucadair@orange.com" class="email">mohamed.boucadair@orange.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>