File: rfc8966.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 (4893 lines) | stat: -rw-r--r-- 276,181 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 8966: The Babel Routing Protocol</title>
<meta content="Juliusz Chroboczek" name="author">
<meta content="David Schinazi" name="author">
<meta content="
       Babel is a loop-avoiding, distance-vector routing protocol that is
robust and efficient both in ordinary wired networks and in wireless mesh
networks.  This document describes the Babel routing protocol and
obsoletes RFC 6126 and RFC 7557. 
    " name="description">
<meta content="xml2rfc 3.5.0" name="generator">
<meta content="Bellman-Ford" name="keyword">
<meta content="IGP" name="keyword">
<meta content="loop-avoidance" name="keyword">
<meta content="mesh network" name="keyword">
<meta content="8966" 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="rfc8966.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/rfc8966" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-babel-rfc6126bis-20" 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 8966</td>
<td class="center">The Babel Routing Protocol</td>
<td class="right">January 2021</td>
</tr></thead>
<tfoot><tr>
<td class="left">Chroboczek &amp; Schinazi</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/rfc8966" class="eref">8966</a></dd>
<dt class="label-obsoletes">Obsoletes:</dt>
<dd class="obsoletes">
<a href="https://www.rfc-editor.org/rfc/rfc6126" class="eref">6126</a>, <a href="https://www.rfc-editor.org/rfc/rfc7557" class="eref">7557</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-01" class="published">January 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">J. Chroboczek</div>
<div class="org">IRIF, University of Paris-Diderot</div>
</div>
<div class="author">
      <div class="author-name">D. Schinazi</div>
<div class="org">Google LLC</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8966</h1>
<h1 id="title">The Babel Routing Protocol</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">Babel is a loop-avoiding, distance-vector routing protocol that is
robust and efficient both in ordinary wired networks and in wireless mesh
networks.  This document describes the Babel routing protocol and
obsoletes RFC 6126 and RFC 7557.<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/rfc8966">https://www.rfc-editor.org/info/rfc8966</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="compact ulEmpty toc">
<li class="compact ulEmpty toc" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1"><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>
<ul class="toc ulEmpty compact">
<li class="toc ulEmpty compact" id="section-toc.1-1.1.2.1">
                <p id="section-toc.1-1.1.2.1.1" class="keepWithNext"><a href="#section-1.1" class="xref">1.1</a>.  <a href="#name-features" class="xref">Features</a><a href="#section-toc.1-1.1.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.1.2.2">
                <p id="section-toc.1-1.1.2.2.1" class="keepWithNext"><a href="#section-1.2" class="xref">1.2</a>.  <a href="#name-limitations" class="xref">Limitations</a><a href="#section-toc.1-1.1.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.1.2.3">
                <p id="section-toc.1-1.1.2.3.1" class="keepWithNext"><a href="#section-1.3" class="xref">1.3</a>.  <a href="#name-specification-of-requiremen" class="xref">Specification of Requirements</a><a href="#section-toc.1-1.1.2.3.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-conceptual-description-of-t" class="xref">Conceptual Description of the Protocol</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty compact">
<li class="toc ulEmpty compact" id="section-toc.1-1.2.2.1">
                <p id="section-toc.1-1.2.2.1.1"><a href="#section-2.1" class="xref">2.1</a>.  <a href="#name-costs-metrics-and-neighbour" class="xref">Costs, Metrics, and Neighbourship</a><a href="#section-toc.1-1.2.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.2.2.2">
                <p id="section-toc.1-1.2.2.2.1"><a href="#section-2.2" class="xref">2.2</a>.  <a href="#name-the-bellman-ford-algorithm" class="xref">The Bellman-Ford Algorithm</a><a href="#section-toc.1-1.2.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.2.2.3">
                <p id="section-toc.1-1.2.2.3.1"><a href="#section-2.3" class="xref">2.3</a>.  <a href="#name-transient-loops-in-bellman-" class="xref">Transient Loops in Bellman-Ford</a><a href="#section-toc.1-1.2.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.2.2.4">
                <p id="section-toc.1-1.2.2.4.1"><a href="#section-2.4" class="xref">2.4</a>.  <a href="#name-feasibility-conditions" class="xref">Feasibility Conditions</a><a href="#section-toc.1-1.2.2.4.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.2.2.5">
                <p id="section-toc.1-1.2.2.5.1"><a href="#section-2.5" class="xref">2.5</a>.  <a href="#name-solving-starvation-sequenci" class="xref">Solving Starvation: Sequencing Routes</a><a href="#section-toc.1-1.2.2.5.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.2.2.6">
                <p id="section-toc.1-1.2.2.6.1"><a href="#section-2.6" class="xref">2.6</a>.  <a href="#name-requests" class="xref">Requests</a><a href="#section-toc.1-1.2.2.6.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.2.2.7">
                <p id="section-toc.1-1.2.2.7.1"><a href="#section-2.7" class="xref">2.7</a>.  <a href="#name-multiple-routers" class="xref">Multiple Routers</a><a href="#section-toc.1-1.2.2.7.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.2.2.8">
                <p id="section-toc.1-1.2.2.8.1"><a href="#section-2.8" class="xref">2.8</a>.  <a href="#name-overlapping-prefixes" class="xref">Overlapping Prefixes</a><a href="#section-toc.1-1.2.2.8.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-protocol-operation" class="xref">Protocol Operation</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty compact">
<li class="toc ulEmpty compact" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-message-transmission-and-re" class="xref">Message Transmission and Reception</a><a href="#section-toc.1-1.3.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.3.2.2">
                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>.  <a href="#name-data-structures" class="xref">Data Structures</a><a href="#section-toc.1-1.3.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.3.2.3">
                <p id="section-toc.1-1.3.2.3.1"><a href="#section-3.3" class="xref">3.3</a>.  <a href="#name-acknowledgments-and-acknowl" class="xref">Acknowledgments and Acknowledgment Requests</a><a href="#section-toc.1-1.3.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.3.2.4">
                <p id="section-toc.1-1.3.2.4.1"><a href="#section-3.4" class="xref">3.4</a>.  <a href="#name-neighbour-acquisition" class="xref">Neighbour Acquisition</a><a href="#section-toc.1-1.3.2.4.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.3.2.5">
                <p id="section-toc.1-1.3.2.5.1"><a href="#section-3.5" class="xref">3.5</a>.  <a href="#name-routing-table-maintenance" class="xref">Routing Table Maintenance</a><a href="#section-toc.1-1.3.2.5.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.3.2.6">
                <p id="section-toc.1-1.3.2.6.1"><a href="#section-3.6" class="xref">3.6</a>.  <a href="#name-route-selection" class="xref">Route Selection</a><a href="#section-toc.1-1.3.2.6.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.3.2.7">
                <p id="section-toc.1-1.3.2.7.1"><a href="#section-3.7" class="xref">3.7</a>.  <a href="#name-sending-updates" class="xref">Sending Updates</a><a href="#section-toc.1-1.3.2.7.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.3.2.8">
                <p id="section-toc.1-1.3.2.8.1"><a href="#section-3.8" class="xref">3.8</a>.  <a href="#name-explicit-requests" class="xref">Explicit Requests</a><a href="#section-toc.1-1.3.2.8.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-protocol-encoding" class="xref">Protocol Encoding</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty compact">
<li class="toc ulEmpty compact" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-data-types" class="xref">Data Types</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.4.2.2">
                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-packet-format" class="xref">Packet Format</a><a href="#section-toc.1-1.4.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.4.2.3">
                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-tlv-format" class="xref">TLV Format</a><a href="#section-toc.1-1.4.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.4.2.4">
                <p id="section-toc.1-1.4.2.4.1"><a href="#section-4.4" class="xref">4.4</a>.  <a href="#name-sub-tlv-format" class="xref">Sub-TLV Format</a><a href="#section-toc.1-1.4.2.4.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.4.2.5">
                <p id="section-toc.1-1.4.2.5.1"><a href="#section-4.5" class="xref">4.5</a>.  <a href="#name-parser-state-and-encoding-o" class="xref">Parser State and Encoding of Updates</a><a href="#section-toc.1-1.4.2.5.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.4.2.6">
                <p id="section-toc.1-1.4.2.6.1"><a href="#section-4.6" class="xref">4.6</a>.  <a href="#name-details-of-specific-tlvs" class="xref">Details of Specific TLVs</a><a href="#section-toc.1-1.4.2.6.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.4.2.7">
                <p id="section-toc.1-1.4.2.7.1"><a href="#section-4.7" class="xref">4.7</a>.  <a href="#name-details-of-specific-sub-tlv" class="xref">Details of specific sub-TLVs</a><a href="#section-toc.1-1.4.2.7.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-references" class="xref">References</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty compact">
<li class="toc ulEmpty compact" id="section-toc.1-1.7.2.1">
                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.7.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.7.2.2">
                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.7.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-appendix.a" class="xref">Appendix A</a>.  <a href="#name-cost-and-metric-computation" class="xref">Cost and Metric Computation</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty compact">
<li class="toc ulEmpty compact" id="section-toc.1-1.8.2.1">
                <p id="section-toc.1-1.8.2.1.1"><a href="#section-a.1" class="xref">A.1</a>.  <a href="#name-maintaining-hello-history" class="xref">Maintaining Hello History</a><a href="#section-toc.1-1.8.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.8.2.2">
                <p id="section-toc.1-1.8.2.2.1"><a href="#section-a.2" class="xref">A.2</a>.  <a href="#name-cost-computation-2" class="xref">Cost Computation</a><a href="#section-toc.1-1.8.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.8.2.3">
                <p id="section-toc.1-1.8.2.3.1"><a href="#section-a.3" class="xref">A.3</a>.  <a href="#name-route-selection-and-hystere" class="xref">Route Selection and Hysteresis</a><a href="#section-toc.1-1.8.2.3.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-appendix.b" class="xref">Appendix B</a>.  <a href="#name-protocol-parameters" class="xref">Protocol Parameters</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-appendix.c" class="xref">Appendix C</a>.  <a href="#name-route-filtering" class="xref">Route Filtering</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-appendix.d" class="xref">Appendix D</a>.  <a href="#name-considerations-for-protocol" class="xref">Considerations for Protocol Extensions</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#section-appendix.e" class="xref">Appendix E</a>.  <a href="#name-stub-implementations" class="xref">Stub Implementations</a><a href="#section-toc.1-1.12.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#section-appendix.f" class="xref">Appendix F</a>.  <a href="#name-compatibility-with-previous" class="xref">Compatibility with Previous Versions</a><a href="#section-toc.1-1.13.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.14">
            <p id="section-toc.1-1.14.1"><a href="#section-appendix.g" class="xref"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</a><a href="#section-toc.1-1.14.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.15">
            <p id="section-toc.1-1.15.1"><a href="#section-appendix.h" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.15.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">Babel is a loop-avoiding distance-vector routing protocol that is
designed to be robust and efficient both in networks using prefix-based
routing and in networks using flat routing ("mesh networks"), and both in
relatively stable wired networks and in highly dynamic wireless networks.
This document describes the Babel routing protocol and obsoletes
<span>[<a href="#RFC6126" class="xref">RFC6126</a>]</span> and <span>[<a href="#RFC7557" class="xref">RFC7557</a>]</span>.<a href="#section-1-1" class="pilcrow">¶</a></p>
<section id="section-1.1">
        <h3 id="name-features">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-features" class="section-name selfRef">Features</a>
        </h3>
<p id="section-1.1-1">The main property that makes Babel suitable for unstable networks is
that, unlike naive distance-vector routing protocols <span>[<a href="#RFC2453" class="xref">RIP</a>]</span>,
it strongly limits the frequency and duration of routing pathologies such
as routing loops and black-holes during reconvergence.  Even after
a mobility event is detected, a Babel network usually remains loop-free.
Babel then quickly reconverges to a configuration that preserves the
loop-freedom and connectedness of the network, but is not necessarily
optimal; in many cases, this operation requires no packet exchanges at
all.  Babel then slowly converges, in a time on the scale of minutes, to
an optimal configuration.  This is achieved by using sequenced routes,
a technique pioneered by Destination-Sequenced Distance-Vector routing
<span>[<a href="#DSDV" class="xref">DSDV</a>]</span>.<a href="#section-1.1-1" class="pilcrow">¶</a></p>
<p id="section-1.1-2">More precisely, Babel has the following properties:<a href="#section-1.1-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1.1-3.1">when every prefix is originated by at most one router, Babel never
  suffers from routing loops;<a href="#section-1.1-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.1-3.2">when a single prefix is originated by multiple routers, Babel may
  occasionally create a transient routing loop for this particular prefix;
  this loop disappears in time proportional to the loop's diameter, and never
  again (up to an arbitrary garbage-collection (GC) time) will the routers
  involved participate in a routing loop for the same prefix;<a href="#section-1.1-3.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.1-3.3">assuming bounded packet loss rates, any routing black-holes that
  may appear after a mobility event are corrected in a time at most
  proportional to the network's diameter.<a href="#section-1.1-3.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-1.1-4">Babel has provisions for link quality estimation and for fairly
arbitrary metrics.  When configured suitably, Babel can implement
shortest-path routing, or it may use a metric based, for example, on
measured packet loss.<a href="#section-1.1-4" class="pilcrow">¶</a></p>
<p id="section-1.1-5">Babel nodes will successfully establish an association even when they
are configured with different parameters.  For example, a mobile node that
is low on battery may choose to use larger time constants (hello and update
intervals, etc.) than a node that has access to wall power.  Conversely, a
node that detects high levels of mobility may choose to use smaller time
constants.  The ability to build such heterogeneous networks makes Babel
particularly adapted to the unmanaged or wireless environment.<a href="#section-1.1-5" class="pilcrow">¶</a></p>
<p id="section-1.1-6">Finally, Babel is a hybrid routing protocol, in the sense that it can
carry routes for multiple network-layer protocols (IPv4 and IPv6),
regardless of which protocol the Babel packets are themselves being
carried over.<a href="#section-1.1-6" class="pilcrow">¶</a></p>
</section>
<section id="section-1.2">
        <h3 id="name-limitations">
<a href="#section-1.2" class="section-number selfRef">1.2. </a><a href="#name-limitations" class="section-name selfRef">Limitations</a>
        </h3>
<p id="section-1.2-1">Babel has two limitations that make it unsuitable for use in some
environments.  First, Babel relies on periodic routing table updates
rather than using a reliable transport; hence, in large, stable networks
it generates more traffic than protocols that only send updates when the
network topology changes.  In such networks, protocols such as OSPF <span>[<a href="#RFC2328" class="xref">OSPF</a>]</span>, IS-IS <span>[<a href="#IS-IS" class="xref">IS-IS</a>]</span>, or the Enhanced Interior
Gateway Routing Protocol (EIGRP) <span>[<a href="#EIGRP" class="xref">EIGRP</a>]</span> might be more
suitable.<a href="#section-1.2-1" class="pilcrow">¶</a></p>
<p id="section-1.2-2">Second, unless the second algorithm described in <a href="#hold-time" class="xref">Section 3.5.4</a>
is implemented, Babel does impose a hold time when a prefix is retracted.
While this hold time does not apply to the exact prefix being retracted,
and hence does not prevent fast reconvergence should it become available
again, it does apply to any shorter prefix that covers it.  This may make
those implementations of Babel that do not implement the optional
algorithm described in <a href="#hold-time" class="xref">Section 3.5.4</a> unsuitable for use in
networks that implement automatic prefix aggregation.<a href="#section-1.2-2" class="pilcrow">¶</a></p>
</section>
<section id="section-1.3">
        <h3 id="name-specification-of-requiremen">
<a href="#section-1.3" class="section-number selfRef">1.3. </a><a href="#name-specification-of-requiremen" class="section-name selfRef">Specification of Requirements</a>
        </h3>
<p id="section-1.3-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-1.3-1" class="pilcrow">¶</a></p>
</section>
</section>
<section id="section-2">
      <h2 id="name-conceptual-description-of-t">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-conceptual-description-of-t" class="section-name selfRef">Conceptual Description of the Protocol</a>
      </h2>
<p id="section-2-1">Babel is a loop-avoiding distance-vector protocol: it is based on the
Bellman-Ford algorithm, just like the venerable RIP <span>[<a href="#RFC2453" class="xref">RIP</a>]</span>,
but includes a number of refinements that either prevent loop formation
altogether, or ensure that a loop disappears in a timely manner and
doesn't form again.<a href="#section-2-1" class="pilcrow">¶</a></p>
<p id="section-2-2">Conceptually, Bellman-Ford is executed in parallel for every source of
routing information (destination of data traffic).  In the following
discussion, we fix a source S; the reader will recall that the same
algorithm is executed for all sources.<a href="#section-2-2" class="pilcrow">¶</a></p>
<section id="section-2.1">
        <h3 id="name-costs-metrics-and-neighbour">
<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-costs-metrics-and-neighbour" class="section-name selfRef">Costs, Metrics, and Neighbourship</a>
        </h3>
<p id="section-2.1-1">For every pair of neighbouring nodes A and B, Babel computes an
abstract value known as the cost of the link from A to B, written
C(A, B).  Given a route between any two (not necessarily
neighbouring) nodes, the metric of the route is the sum of the costs of
all the links along the route.  The goal of the routing algorithm is to
compute, for every source S, the tree of routes of lowest metric to S.<a href="#section-2.1-1" class="pilcrow">¶</a></p>
<p id="section-2.1-2">Costs and metrics need not be integers.  In general, they can be values
in any algebra that satisfies two fairly general conditions
(<a href="#metric-computation" class="xref">Section 3.5.2</a>).<a href="#section-2.1-2" class="pilcrow">¶</a></p>
<p id="section-2.1-3">A Babel node periodically sends Hello messages to all of its
neighbours; it also periodically sends an IHU ("I Heard You") message to
every neighbour from which it has recently heard a Hello.  From the
information derived from Hello and IHU messages received from its neighbour
B, a node A computes the cost C(A, B) of the link from A to B.<a href="#section-2.1-3" class="pilcrow">¶</a></p>
</section>
<section id="section-2.2">
        <h3 id="name-the-bellman-ford-algorithm">
<a href="#section-2.2" class="section-number selfRef">2.2. </a><a href="#name-the-bellman-ford-algorithm" class="section-name selfRef">The Bellman-Ford Algorithm</a>
        </h3>
<p id="section-2.2-1">Every node A maintains two pieces of data: its estimated distance to S,
written D(A), and its next-hop router to S, written NH(A).  Initially, D(S)
= 0, D(A) is infinite, and NH(A) is undefined.<a href="#section-2.2-1" class="pilcrow">¶</a></p>
<p id="section-2.2-2">Periodically, every node B sends to all of its neighbours a route
update, a message containing D(B).  When a neighbour A of B receives the
route update, it checks whether B is its selected next hop; if that is the
case, then NH(A) is set to B, and D(A) is set to C(A, B) + D(B).  If that
is not the case, then A compares C(A, B) + D(B) to its current value of
D(A).  If that value is smaller, meaning that the received update
advertises a route that is better than the currently selected route, then
NH(A) is set to B, and D(A) is set to C(A, B) + D(B).<a href="#section-2.2-2" class="pilcrow">¶</a></p>
<p id="section-2.2-3">A number of refinements to this algorithm are possible, and are used by
Babel.  In particular, convergence speed may be increased by sending
unscheduled "triggered updates" whenever a major change in the topology is
detected, in addition to the regular, scheduled updates.  Additionally,
a node may maintain a number of alternate routes, which are being
advertised by neighbours other than its selected neighbour, and which can
be used immediately if the selected route were to fail.<a href="#section-2.2-3" class="pilcrow">¶</a></p>
</section>
<section id="section-2.3">
        <h3 id="name-transient-loops-in-bellman-">
<a href="#section-2.3" class="section-number selfRef">2.3. </a><a href="#name-transient-loops-in-bellman-" class="section-name selfRef">Transient Loops in Bellman-Ford</a>
        </h3>
<p id="section-2.3-1">It is well known that a naive application of Bellman-Ford to distributed
routing can cause transient loops after a topology change.  Consider for
example the following topology:<a href="#section-2.3-1" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-2.3-2">
<pre>
         B
      1 /|
   1   / |
S --- A  |1
       \ |
      1 \|
         C
</pre><a href="#section-2.3-2" class="pilcrow">¶</a>
</div>
<p id="section-2.3-3">
After convergence, D(B) = D(C) = 2, with NH(B) = NH(C) = A.<a href="#section-2.3-3" class="pilcrow">¶</a></p>
<p id="section-2.3-4">Suppose now that the link between S and A fails:<a href="#section-2.3-4" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-2.3-5">
<pre>
         B
      1 /|
       / |
S     A  |1
       \ |
      1 \|
         C
</pre><a href="#section-2.3-5" class="pilcrow">¶</a>
</div>
<p id="section-2.3-6">When it detects the failure of the link, A switches its next hop to
B (which is still advertising a route to S with metric 2), and advertises
a metric equal to 3, and then advertises a new route with metric 3.  This
process of nodes changing selected neighbours and increasing their metric
continues until the advertised metric reaches "infinity", a value larger
than all the metrics that the routing protocol is able to carry.<a href="#section-2.3-6" class="pilcrow">¶</a></p>
</section>
<section id="section-2.4">
        <h3 id="name-feasibility-conditions">
<a href="#section-2.4" class="section-number selfRef">2.4. </a><a href="#name-feasibility-conditions" class="section-name selfRef">Feasibility Conditions</a>
        </h3>
<p id="section-2.4-1">Bellman-Ford is a very robust algorithm: its convergence properties
are preserved when routers delay route acquisition or when they
discard some updates.  Babel routers discard received route
announcements unless they can prove that accepting them cannot
possibly cause a routing loop.<a href="#section-2.4-1" class="pilcrow">¶</a></p>
<p id="section-2.4-2">More formally, we define a condition over route announcements, known as
the "feasibility condition", that guarantees the absence of routing loops
whenever all routers ignore route updates that do not satisfy the
feasibility condition.  In effect, this makes Bellman-Ford into a family
of routing algorithms, parameterised by the feasibility condition.<a href="#section-2.4-2" class="pilcrow">¶</a></p>
<p id="section-2.4-3">Many different feasibility conditions are possible.  For example, BGP
can be modelled as being a distance-vector protocol with a (rather
drastic) feasibility condition: a routing update is only accepted when the
receiving node's AS number is not included in the update's AS_PATH
attribute (note that BGP's feasibility condition does not ensure the
absence of transient "micro-loops" during reconvergence).<a href="#section-2.4-3" class="pilcrow">¶</a></p>
<p id="section-2.4-4">Another simple feasibility condition, used in the Destination-Sequenced
Distance-Vector (DSDV) routing protocol <span>[<a href="#DSDV" class="xref">DSDV</a>]</span> and in the
Ad hoc On-Demand Distance Vector (AODV) protocol <span>[<a href="#RFC3561" class="xref">RFC3561</a>]</span>,
stems from the following observation: a routing loop can only arise after
a router has switched to a route with a larger metric than the route that
it had previously selected.  Hence, one may define that a route is
feasible when its metric at the local node would be no larger than
the metric of the currently selected route, i.e., an announcement carrying
a metric D(B) is accepted by A when C(A, B) + D(B) &lt;= D(A).  If all
routers obey this constraint, then the metric at every router is
nonincreasing, and the following invariant is always preserved: if A has
selected B as its next hop, then D(B) &lt; D(A), which implies that the
forwarding graph is loop-free.<a href="#section-2.4-4" class="pilcrow">¶</a></p>
<p id="section-2.4-5">Babel uses a slightly more refined feasibility condition, derived from
EIGRP <span>[<a href="#DUAL" class="xref">DUAL</a>]</span>.  Given a router A, define the feasibility
distance of A, written FD(A), as the smallest metric that A has ever
advertised for S to any of its neighbours.  An update sent by a neighbour
B of A is feasible when the metric D(B) advertised by B is strictly
smaller than A's feasibility distance, i.e., when D(B) &lt; FD(A).<a href="#section-2.4-5" class="pilcrow">¶</a></p>
<p id="section-2.4-6">It is easy to see that this latter condition is no more restrictive than
DSDV-feasibility.  Suppose that node A obeys DSDV-feasibility; then D(A) is
nonincreasing, hence at all times D(A) &lt;= FD(A).  Suppose now that
A receives a DSDV-feasible update that advertises a metric D(B).  Since the
update is DSDV-feasible, C(A, B) + D(B) &lt;= D(A), hence D(B) &lt; D(A),
and since D(A) &lt;= FD(A), D(B) &lt; FD(A).<a href="#section-2.4-6" class="pilcrow">¶</a></p>
<p id="section-2.4-7">To see that it is strictly less restrictive, consider the following
diagram, where A has selected the route through B, and D(A) = FD(A) = 2.
Since D(C) = 1 &lt; FD(A), the alternate route through C is feasible for A,
although its metric C(A, C) + D(C) = 5 is larger than that of the
currently selected route:<a href="#section-2.4-7" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-2.4-8">
<pre>
   B
1 / \ 1
 /   \
S     A
 \   /
1 \ / 4
   C
</pre><a href="#section-2.4-8" class="pilcrow">¶</a>
</div>
<p id="section-2.4-9">To show that this feasibility condition still guarantees loop-freedom,
recall that at the time when A accepts an update from B, the metric D(B)
announced by B is no smaller than FD(B); since it is smaller than FD(A),
at that point in time FD(B) &lt; FD(A).  Since this property is preserved
when A sends updates and also when it picks a different next hop, it
remains true at all times, which ensures that the forwarding graph has no
loops.<a href="#section-2.4-9" class="pilcrow">¶</a></p>
</section>
<section id="section-2.5">
        <h3 id="name-solving-starvation-sequenci">
<a href="#section-2.5" class="section-number selfRef">2.5. </a><a href="#name-solving-starvation-sequenci" class="section-name selfRef">Solving Starvation: Sequencing Routes</a>
        </h3>
<p id="section-2.5-1">Obviously, the feasibility conditions defined above cause starvation
when a router runs out of feasible routes.  Consider the following diagram,
where both A and B have selected the direct route to S:<a href="#section-2.5-1" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-2.5-2">
<pre>
   A
1 /|        D(A) = 1
 / |       FD(A) = 1
S  |1
 \ |        D(B) = 2
2 \|       FD(B) = 2
   B
</pre><a href="#section-2.5-2" class="pilcrow">¶</a>
</div>
<p id="section-2.5-3">Suppose now that the link between A and S breaks:<a href="#section-2.5-3" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-2.5-4">
<pre>
   A
   |
   |       FD(A) = 1
S  |1
 \ |        D(B) = 2
2 \|       FD(B) = 2
   B
</pre><a href="#section-2.5-4" class="pilcrow">¶</a>
</div>
<p id="section-2.5-5">The only route available from A to S, the one that goes through B, is
not feasible: A suffers from spurious starvation.  At that point, the
whole subtree suffering from starvation must be reset, which is
essentially what EIGRP does when it performs a global synchronisation of
all the routers in the starving subtree (the "active" phase of EIGRP).<a href="#section-2.5-5" class="pilcrow">¶</a></p>
<p id="section-2.5-6">Babel reacts to starvation in a less drastic manner, by using sequenced
routes, a technique introduced by DSDV and adopted by AODV.  In addition to
a metric, every route carries a sequence number, a nondecreasing integer
that is propagated unchanged through the network and is only ever
incremented by the source; a pair (s, m), where s is a sequence number and
m a metric, is called a distance.<a href="#section-2.5-6" class="pilcrow">¶</a></p>
<p id="section-2.5-7">A received update is feasible when either it is more recent than the
feasibility distance maintained by the receiving node, or it is equally
recent and the metric is strictly smaller.  More formally, if FD(A) =
(s, m), then an update carrying the distance (s', m') is feasible
when either s' &gt; s, or s = s' and m' &lt; m.<a href="#section-2.5-7" class="pilcrow">¶</a></p>
<p id="section-2.5-8">Assuming the sequence number of S is 137, the diagram above becomes:<a href="#section-2.5-8" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-2.5-9">
<pre>
   A
   |
   |       FD(A) = (137, 1)
S  |1
 \ |        D(B) = (137, 2)
2 \|       FD(B) = (137, 2)
   B
</pre><a href="#section-2.5-9" class="pilcrow">¶</a>
</div>
<p id="section-2.5-10">After S increases its sequence number, and the new sequence number is
propagated to B, we have:<a href="#section-2.5-10" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-2.5-11">
<pre>
   A
   |
   |       FD(A) = (137, 1)
S  |1
 \ |        D(B) = (138, 2)
2 \|       FD(B) = (138, 2)
   B
</pre><a href="#section-2.5-11" class="pilcrow">¶</a>
</div>
<p id="section-2.5-12">
at which point the route through B becomes feasible again.<a href="#section-2.5-12" class="pilcrow">¶</a></p>
<p id="section-2.5-13">Note that while sequence numbers are used for determining feasibility,
they are not used in route selection: a node ignores the sequence number
when selecting the best route to a given destination
(<a href="#route-selection" class="xref">Section 3.6</a>).  Doing otherwise would cause
route oscillation while a sequence number propagates through the network,
and might even cause persistent black-holes with some exotic metrics.<a href="#section-2.5-13" class="pilcrow">¶</a></p>
</section>
<section id="section-2.6">
        <h3 id="name-requests">
<a href="#section-2.6" class="section-number selfRef">2.6. </a><a href="#name-requests" class="section-name selfRef">Requests</a>
        </h3>
<p id="section-2.6-1">In DSDV, the sequence number of a source is increased periodically.
A route becomes feasible again after the source increases its sequence
number, and the new sequence number is propagated through the network,
which may, in general, require a significant amount of time.<a href="#section-2.6-1" class="pilcrow">¶</a></p>
<p id="section-2.6-2">Babel takes a different approach.  When a node detects that it is
suffering from a potentially spurious starvation, it sends an explicit
request to the source for a new sequence number.  This request is forwarded
hop by hop to the source, with no regard to the feasibility condition.
Upon receiving the request, the source increases its sequence number and
broadcasts an update, which is forwarded to the requesting node.<a href="#section-2.6-2" class="pilcrow">¶</a></p>
<p id="section-2.6-3">Note that after a change in network topology not all such requests
will, in general, reach the source, as some will be sent over links that
are now broken.  However, if the network is still connected, then at least
one among the nodes suffering from spurious starvation has an (unfeasible)
route to the source; hence, in the absence of packet loss, at least one
such request will reach the source.  (Resending requests a small number of
times compensates for packet loss.)<a href="#section-2.6-3" class="pilcrow">¶</a></p>
<p id="section-2.6-4">Since requests are forwarded with no regard to the feasibility
condition, they may, in general, be caught in a forwarding loop; this is
avoided by having nodes perform duplicate detection for the requests that
they forward.<a href="#section-2.6-4" class="pilcrow">¶</a></p>
</section>
<section id="section-2.7">
        <h3 id="name-multiple-routers">
<a href="#section-2.7" class="section-number selfRef">2.7. </a><a href="#name-multiple-routers" class="section-name selfRef">Multiple Routers</a>
        </h3>
<p id="section-2.7-1">The above discussion assumes that each prefix is originated by a single
router.  In real networks, however, it is often necessary to have a single
prefix originated by multiple routers: for example, the default route will
be originated by all of the edge routers of a routing domain.<a href="#section-2.7-1" class="pilcrow">¶</a></p>
<p id="section-2.7-2">Since synchronising sequence numbers between distinct routers is
problematic, Babel treats routes for the same prefix as distinct entities
when they are originated by different routers: every route announcement
carries the router-id of its originating router, and feasibility distances
are not maintained per prefix, but per source, where a source is a pair of
a router-id and a prefix.  In effect, Babel guarantees loop-freedom for the
forwarding graph to every source; since the union of multiple acyclic
graphs is not in general acyclic, Babel does not in general guarantee
loop-freedom when a prefix is originated by multiple routers, but any
loops will be broken in a time at most proportional to the diameter of the
loop -- as soon as an update has "gone around" the routing loop.<a href="#section-2.7-2" class="pilcrow">¶</a></p>
<p id="section-2.7-3">Consider for example the following topology, where A has selected the
default route through S, and B has selected the one through S':<a href="#section-2.7-3" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-2.7-4">
<pre>
           1     1     1
::/0 -- S --- A --- B --- S' -- ::/0
</pre><a href="#section-2.7-4" class="pilcrow">¶</a>
</div>
<p id="section-2.7-5">Suppose that both default routes fail at the same time; then nothing
prevents A from switching to B, and B simultaneously switching to A.
However, as soon as A has successfully advertised the new route to B, the
route through A will become unfeasible for B.  Conversely, as soon as
B will have advertised the route through A, the route through B will
become unfeasible for A.<a href="#section-2.7-5" class="pilcrow">¶</a></p>
<p id="section-2.7-6">In effect, the routing loop disappears at the latest when routing
information has gone around the loop.  Since this process can be delayed by
lost packets, Babel makes certain efforts to ensure that updates are sent
reliably after a router-id change (<a href="#triggered-updates" class="xref">Section 3.7.2</a>).<a href="#section-2.7-6" class="pilcrow">¶</a></p>
<p id="section-2.7-7">Additionally, after the routers have advertised the two routes, both
sources will be in their source tables, which will prevent them from ever
again participating in a routing loop involving routes from S and S' (up to
the source GC time, which, available memory permitting, can be set to
arbitrarily large values).<a href="#section-2.7-7" class="pilcrow">¶</a></p>
</section>
<div id="overlapping-prefixes">
<section id="section-2.8">
        <h3 id="name-overlapping-prefixes">
<a href="#section-2.8" class="section-number selfRef">2.8. </a><a href="#name-overlapping-prefixes" class="section-name selfRef">Overlapping Prefixes</a>
        </h3>
<p id="section-2.8-1">In the above discussion, we have assumed that all prefixes are disjoint,
as is the case in flat ("mesh") routing.  In practice, however, prefixes
may overlap: for example, the default route overlaps with all of the routes
present in the network.<a href="#section-2.8-1" class="pilcrow">¶</a></p>
<p id="section-2.8-2">After a route fails, it is not correct in general to switch to a route
that subsumes the failed route.  Consider for example the following
configuration:<a href="#section-2.8-2" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-2.8-3">
<pre>
           1     1
::/0 -- A --- B --- C
</pre><a href="#section-2.8-3" class="pilcrow">¶</a>
</div>
<p id="section-2.8-4">Suppose that node C fails.  If B forwards packets destined to C by
following the default route, a routing loop will form, and persist until
A learns of B's retraction of the direct route to C.  B avoids this
pitfall by installing an "unreachable" route after a route is retracted;
this route is maintained until it can be guaranteed that the former route
has been retracted by all of B's neighbours (<a href="#hold-time" class="xref">Section 3.5.4</a>).<a href="#section-2.8-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
<section id="section-3">
      <h2 id="name-protocol-operation">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-protocol-operation" class="section-name selfRef">Protocol Operation</a>
      </h2>
<p id="section-3-1">Every Babel speaker is assigned a router-id, which is an arbitrary
string of 8 octets that is assumed unique across the routing domain.  For
example, router-ids could be assigned randomly, or they could be derived
from a link-layer address.  (The protocol encoding is slightly more
compact when router-ids are assigned in the same manner as the IPv6 layer
assigns host IDs; see the definition of the "R" flag in
<a href="#update" class="xref">Section 4.6.9</a>.)<a href="#section-3-1" class="pilcrow">¶</a></p>
<div id="transmission-reception">
<section id="section-3.1">
        <h3 id="name-message-transmission-and-re">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-message-transmission-and-re" class="section-name selfRef">Message Transmission and Reception</a>
        </h3>
<p id="section-3.1-1">Babel protocol packets are sent in the body of a UDP datagram (as
described in <a href="#protocol-encoding" class="xref">Section 4</a>).  Each Babel packet
consists of zero or more TLVs.  Most TLVs may contain sub-TLVs.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<p id="section-3.1-2">Babel's control traffic can be carried indifferently over IPv6
or over IPv4, and prefixes of either address family can be announced over
either protocol.  Thus, there are at least two natural deployment models:
using IPv6 exclusively for all control traffic, or running two distinct
protocol instances, one for each address family.  The exclusive use of
IPv6 for all control traffic is <span class="bcp14">RECOMMENDED</span>, since using both protocols at
the same time doubles the amount of traffic devoted to neighbour discovery
and link quality estimation.<a href="#section-3.1-2" class="pilcrow">¶</a></p>
<p id="section-3.1-3">The source address of a Babel packet is always a unicast address,
link-local in the case of IPv6.  Babel packets may be sent to a well-known
(link-local) multicast address or to a (link-local) unicast address.  In
normal operation, a Babel speaker sends both multicast and unicast packets
to its neighbours.<a href="#section-3.1-3" class="pilcrow">¶</a></p>
<p id="section-3.1-4">With the exception of acknowledgments, all Babel TLVs
can be sent to either unicast or multicast addresses, and their semantics
does not depend on whether the destination is a unicast or a multicast
address.  Hence, a Babel speaker does not need to determine the destination
address of a packet that it receives in order to interpret it.<a href="#section-3.1-4" class="pilcrow">¶</a></p>
<p id="section-3.1-5">A moderate amount of jitter may be applied to packets sent by a Babel
speaker: outgoing TLVs are buffered and <span class="bcp14">SHOULD</span> be sent with a random
delay.  This is done for two purposes: it avoids synchronisation of
multiple Babel speakers across a network <span>[<a href="#JITTER" class="xref">JITTER</a>]</span>, and it
allows for the aggregation of multiple TLVs into a single packet.<a href="#section-3.1-5" class="pilcrow">¶</a></p>
<p id="section-3.1-6">The maximum amount of delay a TLV can be subjected to depends on the
TLV.  When the protocol description specifies that a TLV is urgent (as in
<a href="#triggered-updates" class="xref">Section 3.7.2</a> and <a href="#handling-requests" class="xref">Section 3.8.1</a>),
then the TLV <span class="bcp14">MUST</span> be sent within a short time known as the urgent timeout
(see <a href="#parameters" class="xref">Appendix B</a> for recommended values).  When the TLV is
governed by a timeout explicitly included in a previous TLV, such as in
the case of Acknowledgments (<a href="#ack" class="xref">Section 4.6.4</a>),
Updates (<a href="#sending-updates" class="xref">Section 3.7</a>), and IHUs
(<a href="#bidirectional-reachability" class="xref">Section 3.4.2</a>), then the TLV <span class="bcp14">MUST</span> be sent
early enough to meet the explicit deadline (with a small margin to allow
for propagation delays).  In all other cases, the TLV <span class="bcp14">SHOULD</span> be sent out
within one-half of the Multicast Hello interval.<a href="#section-3.1-6" class="pilcrow">¶</a></p>
<p id="section-3.1-7">In order to avoid packet drops (either at the sender or at the
receiver), a delay <span class="bcp14">SHOULD</span> be introduced between successive packets sent
out on the same interface, within the constraints of the previous
paragraph.  Note, however, that such packet pacing might impair the ability
of some link layers (e.g., IEEE 802.11 <span>[<a href="#IEEE802.11" class="xref">IEEE802.11</a>]</span>)
to perform packet aggregation.<a href="#section-3.1-7" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-3.2">
        <h3 id="name-data-structures">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-data-structures" class="section-name selfRef">Data Structures</a>
        </h3>
<p id="section-3.2-1">In this section, we describe the data structures that
every Babel speaker maintains.  This description is conceptual: a Babel
speaker may use different data structures as long as the resulting
protocol is the same as the one described in this document.  For example,
rather than maintaining a single table containing both selected and
unselected (fallback) routes, as described in <a href="#route-table" class="xref">Section 3.2.6</a>, 
an actual implementation would probably use two tables, one with
selected routes and one with fallback routes.<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<div id="sequence-number">
<section id="section-3.2.1">
          <h4 id="name-sequence-number-arithmetic">
<a href="#section-3.2.1" class="section-number selfRef">3.2.1. </a><a href="#name-sequence-number-arithmetic" class="section-name selfRef">Sequence Number Arithmetic</a>
          </h4>
<p id="section-3.2.1-1">Sequence numbers (seqnos) appear in a number of Babel data structures,
and they are interpreted as integers modulo 2<sup>16</sup>.  For the purposes of
this document, arithmetic on sequence numbers is defined as follows.<a href="#section-3.2.1-1" class="pilcrow">¶</a></p>
<p id="section-3.2.1-2">Given a seqno s and a non-negative integer n, the sum of s and n is
defined by the following:<a href="#section-3.2.1-2" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-3.2.1-3">s + n (modulo 2<sup>16</sup>) = (s + n) MOD 2<sup>16</sup><a href="#section-3.2.1-3" class="pilcrow">¶</a></p>
<p id="section-3.2.1-4">
or, equivalently,<a href="#section-3.2.1-4" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-3.2.1-5">s + n (modulo 2<sup>16</sup>) = (s + n) AND 65535<a href="#section-3.2.1-5" class="pilcrow">¶</a></p>
<p id="section-3.2.1-6">
where MOD is the modulo operation yielding a non-negative integer, and AND is
the bitwise conjunction operation.<a href="#section-3.2.1-6" class="pilcrow">¶</a></p>
<p id="section-3.2.1-7">Given two sequence numbers s and s', the relation s is less than s'
(s &lt; s') is defined by the following:<a href="#section-3.2.1-7" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-3.2.1-8">s &lt; s' (modulo 2<sup>16</sup>) when 0 &lt; ((s' - s) MOD 2<sup>16</sup>) &lt; 32768<a href="#section-3.2.1-8" class="pilcrow">¶</a></p>
<p id="section-3.2.1-9">
or, equivalently,<a href="#section-3.2.1-9" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-3.2.1-10">s &lt; s' (modulo 2<sup>16</sup>) when s /= s' and ((s' - s) AND 32768) = 0.<a href="#section-3.2.1-10" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-3.2.2">
          <h4 id="name-node-sequence-number">
<a href="#section-3.2.2" class="section-number selfRef">3.2.2. </a><a href="#name-node-sequence-number" class="section-name selfRef">Node Sequence Number</a>
          </h4>
<p id="section-3.2.2-1">A node's sequence number is a 16-bit integer that is included in route
updates sent for routes originated by this node.<a href="#section-3.2.2-1" class="pilcrow">¶</a></p>
<p id="section-3.2.2-2">A node increments its sequence number (modulo 2<sup>16</sup>) whenever it
receives a request for a new sequence number (<a href="#handling-seqno-requests" class="xref">Section 3.8.1.2</a>).  A node <span class="bcp14">SHOULD NOT</span> increment its
sequence number (seqno) spontaneously, since increasing seqnos makes it
less likely that other nodes will have feasible alternate routes when
their selected routes fail.<a href="#section-3.2.2-2" class="pilcrow">¶</a></p>
</section>
<section id="section-3.2.3">
          <h4 id="name-the-interface-table">
<a href="#section-3.2.3" class="section-number selfRef">3.2.3. </a><a href="#name-the-interface-table" class="section-name selfRef">The Interface Table</a>
          </h4>
<p id="section-3.2.3-1">The interface table contains the list of interfaces on which the node
speaks the Babel protocol.  Every interface table entry contains the
interface's outgoing Multicast Hello seqno, a 16-bit integer that is sent
with each Multicast Hello TLV on this interface and is incremented (modulo
2<sup>16</sup>) whenever a Multicast Hello is sent.  (Note that an interface's
Multicast Hello seqno is unrelated to the node's seqno.)<a href="#section-3.2.3-1" class="pilcrow">¶</a></p>
<p id="section-3.2.3-2">There are two timers associated with each interface table entry.
The periodic multicast hello timer governs the sending of scheduled
Multicast Hello and IHU packets (<a href="#neighbour-acquisition" class="xref">Section 3.4</a>).
The periodic Update timer governs the sending of periodic route updates
(<a href="#periodic-updates" class="xref">Section 3.7.1</a>).  See <a href="#parameters" class="xref">Appendix B</a> for
suggested time constants.<a href="#section-3.2.3-2" class="pilcrow">¶</a></p>
</section>
<section id="section-3.2.4">
          <h4 id="name-the-neighbour-table">
<a href="#section-3.2.4" class="section-number selfRef">3.2.4. </a><a href="#name-the-neighbour-table" class="section-name selfRef">The Neighbour Table</a>
          </h4>
<p id="section-3.2.4-1">The neighbour table contains the list of all neighbouring interfaces
from which a Babel packet has been recently received.  The neighbour table
is indexed by pairs of the form (interface, address), and every neighbour table
entry contains the following data:<a href="#section-3.2.4-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.2.4-2.1">the local node's interface over which this neighbour is reachable;<a href="#section-3.2.4-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.2.4-2.2">the address of the neighbouring interface;<a href="#section-3.2.4-2.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.2.4-2.3">a history of recently received Multicast Hello packets from this
neighbour; this can, for example, be a sequence of n bits, for some small
value n, indicating which of the n hellos most recently sent by this
neighbour have been received by the local node;<a href="#section-3.2.4-2.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.2.4-2.4">a history of recently received Unicast Hello packets from this neighbour;<a href="#section-3.2.4-2.4" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.2.4-2.5">the "transmission cost" value from the last IHU packet received from
this neighbour, or FFFF hexadecimal (infinity) if the IHU hold timer for
this neighbour has expired;<a href="#section-3.2.4-2.5" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.2.4-2.6">the expected incoming Multicast Hello sequence number for this neighbour,
an integer modulo 2<sup>16</sup>.<a href="#section-3.2.4-2.6" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.2.4-2.7">the expected incoming Unicast Hello sequence number for this neighbour,
an integer modulo 2<sup>16</sup>.<a href="#section-3.2.4-2.7" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.2.4-2.8">the outgoing Unicast Hello sequence number for this neighbour, an integer
modulo 2<sup>16</sup> that is sent with each Unicast Hello TLV to this neighbour and
is incremented (modulo 2<sup>16</sup>) whenever a Unicast Hello is sent.  (Note that
the outgoing Unicast Hello seqno for a neighbour is distinct from the
interface's outgoing Multicast Hello seqno.)<a href="#section-3.2.4-2.8" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-3.2.4-3">There are three timers associated with each neighbour entry -- the
multicast hello timer, which is set to the interval value carried by
scheduled Multicast Hello TLVs sent by this neighbour, the unicast hello
timer, which is set to the interval value carried by scheduled Unicast
Hello TLVs, and the IHU timer, which is set to a small multiple of the
interval carried in IHU TLVs (see "IHU Hold time" in
<a href="#parameters" class="xref">Appendix B</a> for suggested values).<a href="#section-3.2.4-3" class="pilcrow">¶</a></p>
<p id="section-3.2.4-4">Note that the neighbour table is indexed by IP addresses, not by
router-ids: neighbourship is a relationship between interfaces, not between
nodes.  Therefore, two nodes with multiple interfaces can participate in
multiple neighbourship relationships, a situation that can notably arise
when wireless nodes with multiple radios are involved.<a href="#section-3.2.4-4" class="pilcrow">¶</a></p>
</section>
<section id="section-3.2.5">
          <h4 id="name-the-source-table">
<a href="#section-3.2.5" class="section-number selfRef">3.2.5. </a><a href="#name-the-source-table" class="section-name selfRef">The Source Table</a>
          </h4>
<p id="section-3.2.5-1">The source table is used to record feasibility distances.  It is indexed
by triples of the form (prefix, plen, router-id), and every source table
entry contains the following data:<a href="#section-3.2.5-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.2.5-2.1">the prefix (prefix, plen), where plen is the prefix length in bits,
that this entry applies to;<a href="#section-3.2.5-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.2.5-2.2">the router-id of a router originating this prefix;<a href="#section-3.2.5-2.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.2.5-2.3">a pair (seqno, metric), this source's feasibility distance.<a href="#section-3.2.5-2.3" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-3.2.5-3">There is one timer associated with each entry in the source table
-- the source garbage-collection timer.  It is initialised to a time
on the order of minutes and reset as specified in <a href="#maintaining-fd" class="xref">Section 3.7.3</a>.<a href="#section-3.2.5-3" class="pilcrow">¶</a></p>
</section>
<div id="route-table">
<section id="section-3.2.6">
          <h4 id="name-the-route-table">
<a href="#section-3.2.6" class="section-number selfRef">3.2.6. </a><a href="#name-the-route-table" class="section-name selfRef">The Route Table</a>
          </h4>
<p id="section-3.2.6-1">The route table contains the routes known to this node.  It is indexed
by triples of the form (prefix, plen, neighbour), and every route table
entry contains the following data:<a href="#section-3.2.6-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.2.6-2.1">the source (prefix, plen, router-id) for which this route is advertised;<a href="#section-3.2.6-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.2.6-2.2">the neighbour (an entry in the neighbour table) that advertised this
route;<a href="#section-3.2.6-2.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.2.6-2.3">the metric with which this route was advertised by the neighbour, or
FFFF hexadecimal (infinity) for a recently retracted route;<a href="#section-3.2.6-2.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.2.6-2.4">the sequence number with which this route was advertised;<a href="#section-3.2.6-2.4" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.2.6-2.5">the next-hop address of this route;<a href="#section-3.2.6-2.5" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.2.6-2.6">a boolean flag indicating whether this route is selected, i.e., whether
it is currently being used for forwarding and is being advertised.<a href="#section-3.2.6-2.6" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-3.2.6-3">There is one timer associated with each route table entry -- the
route expiry timer.  It is initialised and reset as specified in
<a href="#route-acquisition" class="xref">Section 3.5.3</a>.<a href="#section-3.2.6-3" class="pilcrow">¶</a></p>
<p id="section-3.2.6-4">Note that there are two distinct (seqno, metric) pairs associated with 
each route: the route's distance, which is stored in the route table, and
the feasibility distance, which is stored in the source table and shared between
all routes with the same source.<a href="#section-3.2.6-4" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-3.2.7">
          <h4 id="name-the-table-of-pending-seqno-">
<a href="#section-3.2.7" class="section-number selfRef">3.2.7. </a><a href="#name-the-table-of-pending-seqno-" class="section-name selfRef">The Table of Pending Seqno Requests</a>
          </h4>
<p id="section-3.2.7-1">The table of pending seqno requests contains a list of seqno requests
that the local node has sent (either because they have been originated
locally, or because they were forwarded) and to which no reply has been
received yet.  This table is indexed by triples of the form (prefix, plen,
router-id), and every entry in this table contains the following data:<a href="#section-3.2.7-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.2.7-2.1">the prefix, plen, router-id, and seqno being requested;<a href="#section-3.2.7-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.2.7-2.2">the neighbour, if any, on behalf of which we are forwarding this
request;<a href="#section-3.2.7-2.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.2.7-2.3">a small integer indicating the number of times that this request will be
resent if it remains unsatisfied.<a href="#section-3.2.7-2.3" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-3.2.7-3">There is one timer associated with each pending seqno request; it governs
both the resending of requests and their expiry.<a href="#section-3.2.7-3" class="pilcrow">¶</a></p>
</section>
</section>
<div id="acknowledgments">
<section id="section-3.3">
        <h3 id="name-acknowledgments-and-acknowl">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-acknowledgments-and-acknowl" class="section-name selfRef">Acknowledgments and Acknowledgment Requests</a>
        </h3>
<p id="section-3.3-1">A Babel speaker may request that a neighbour receiving a given packet
reply with an explicit acknowledgment within a given time.  While the use
of acknowledgment requests is optional, every Babel speaker <span class="bcp14">MUST</span> be able
to reply to such a request.<a href="#section-3.3-1" class="pilcrow">¶</a></p>
<p id="section-3.3-2">An acknowledgment <span class="bcp14">MUST</span> be sent to a unicast destination.  On the other
hand, acknowledgment requests may be sent to either unicast or multicast
destinations, in which case they request an acknowledgment from all of the
receiving nodes.<a href="#section-3.3-2" class="pilcrow">¶</a></p>
<p id="section-3.3-3">When to request acknowledgments is a matter of local policy; the
simplest strategy is to never request acknowledgments and to rely on
periodic updates to ensure that any reachable routes are eventually
propagated throughout the routing domain.  In order to improve convergence
speed and to reduce the amount of control traffic, acknowledgment requests
<span class="bcp14">MAY</span> be used in order to reliably send urgent updates (<a href="#triggered-updates" class="xref">Section 3.7.2</a>) and retractions (<a href="#hold-time" class="xref">Section 3.5.4</a>),
especially when the number of neighbours on a given interface is small.
Since Babel is designed to deal gracefully with packet loss on unreliable
media, sending all packets with acknowledgment requests is not necessary
and <span class="bcp14">NOT RECOMMENDED</span>, as the acknowledgments cause additional traffic and
may force additional Address Resolution Protocol (ARP) or Neighbour
Discovery (ND) exchanges.<a href="#section-3.3-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="neighbour-acquisition">
<section id="section-3.4">
        <h3 id="name-neighbour-acquisition">
<a href="#section-3.4" class="section-number selfRef">3.4. </a><a href="#name-neighbour-acquisition" class="section-name selfRef">Neighbour Acquisition</a>
        </h3>
<p id="section-3.4-1">Neighbour acquisition is the process by which a Babel node discovers the
set of neighbours heard over each of its interfaces and ascertains
bidirectional reachability.  On unreliable media, neighbour acquisition
additionally provides some statistics that may be useful for link quality
computation.<a href="#section-3.4-1" class="pilcrow">¶</a></p>
<p id="section-3.4-2">Before it can exchange routing information with a neighbour, a Babel
node <span class="bcp14">MUST</span> create an entry for that neighbour in the neighbour table.  When
to do that is implementation-specific; suitable strategies include
creating an entry when any Babel packet is received, or creating an entry
when a Hello TLV is parsed.  Similarly, in order to conserve system
resources, an implementation <span class="bcp14">SHOULD</span> discard an entry when it has been
unused for long enough; suitable strategies include dropping the neighbour
after a timeout, and dropping a neighbour when the associated Hello
histories become empty (see <a href="#cost-computation-examples" class="xref">Appendix A.2</a>).<a href="#section-3.4-2" class="pilcrow">¶</a></p>
<div id="reverse-reachability">
<section id="section-3.4.1">
          <h4 id="name-reverse-reachability-detect">
<a href="#section-3.4.1" class="section-number selfRef">3.4.1. </a><a href="#name-reverse-reachability-detect" class="section-name selfRef">Reverse Reachability Detection</a>
          </h4>
<p id="section-3.4.1-1">Every Babel node sends Hello TLVs to its neighbours, at regular or irregular intervals, to indicate that it
is alive.  Each Hello TLV carries an
increasing (modulo 2<sup>16</sup>) sequence number and an upper bound on the time
interval until the next Hello of the same type (see below).  If the time
interval is set to 0, then the Hello TLV does not establish a new promise:
the deadline carried by the previous Hello of the same type still applies
to the next Hello (if the most recent scheduled Hello of the right kind
was received at time t0 and carried interval i, then the previous promise
of sending another Hello before time t0 + i still holds).  We
say that a Hello is "scheduled" if it carries a nonzero interval, and
"unscheduled" otherwise.<a href="#section-3.4.1-1" class="pilcrow">¶</a></p>
<p id="section-3.4.1-2">There are two kinds of Hellos: Multicast Hellos, which use
a per-interface Hello counter (the Multicast Hello seqno), and Unicast
Hellos, which use a per-neighbour counter (the Unicast Hello seqno).
A Multicast Hello with a given seqno <span class="bcp14">MUST</span> be sent to all neighbours on
a given interface, either by sending it to a multicast address or by
sending it to one unicast address per neighbour (hence, the term
"Multicast Hello" is a slight misnomer).  A Unicast Hello carrying a given
seqno should normally be sent to just one neighbour (over unicast), since
the sequence numbers of different neighbours are not in general
synchronised.<a href="#section-3.4.1-2" class="pilcrow">¶</a></p>
<p id="section-3.4.1-3">Multicast Hellos sent over multicast can be used for neighbour
discovery; hence, a node <span class="bcp14">SHOULD</span> send periodic (scheduled) Multicast Hellos
unless neighbour discovery is performed by means outside of the Babel
protocol.  A node <span class="bcp14">MAY</span> send Unicast Hellos or unscheduled Hellos of either
kind for any reason, such as reducing the amount of multicast traffic or
improving reliability on link technologies with poor support for
link-layer multicast.<a href="#section-3.4.1-3" class="pilcrow">¶</a></p>
<p id="section-3.4.1-4">A node <span class="bcp14">MAY</span> send a scheduled Hello ahead of time.  A node <span class="bcp14">MAY</span> change its
scheduled Hello interval.  The Hello interval <span class="bcp14">MAY</span> be decreased at any
time; it <span class="bcp14">MAY</span> be increased immediately before sending a Hello TLV, but
<span class="bcp14">SHOULD NOT</span> be increased at other times.  (Equivalently, a node <span class="bcp14">SHOULD</span> send
a scheduled Hello immediately after increasing its Hello interval.)<a href="#section-3.4.1-4" class="pilcrow">¶</a></p>
<p id="section-3.4.1-5">How to deal with received Hello TLVs and what statistics to maintain
are considered local implementation matters; typically, a node will
maintain some sort of history of recently received Hellos.  An example of
a suitable algorithm is described in <a href="#hello-history" class="xref">Appendix A.1</a>.<a href="#section-3.4.1-5" class="pilcrow">¶</a></p>
<p id="section-3.4.1-6">After receiving a Hello, or determining that it has missed one, the node
recomputes the association's cost (<a href="#cost-computation" class="xref">Section 3.4.3</a>) and
runs the route selection procedure (<a href="#route-selection" class="xref">Section 3.6</a>).<a href="#section-3.4.1-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="bidirectional-reachability">
<section id="section-3.4.2">
          <h4 id="name-bidirectional-reachability-">
<a href="#section-3.4.2" class="section-number selfRef">3.4.2. </a><a href="#name-bidirectional-reachability-" class="section-name selfRef">Bidirectional Reachability Detection</a>
          </h4>
<p id="section-3.4.2-1">In order to establish bidirectional reachability, every node sends
periodic IHU ("I Heard You") TLVs to each of its neighbours.  Since IHUs
carry an explicit interval value, they <span class="bcp14">MAY</span> be sent less often than Hellos
in order to reduce the amount of routing traffic in dense networks; in
particular, they <span class="bcp14">SHOULD</span> be sent less often than Hellos over links with
little packet loss.  While IHUs are conceptually unicast, they <span class="bcp14">MAY</span> be
sent to a multicast address in order to avoid an ARP or Neighbour Discovery
exchange and to aggregate multiple IHUs into a single packet.<a href="#section-3.4.2-1" class="pilcrow">¶</a></p>
<p id="section-3.4.2-2">In addition to the periodic IHUs, a node <span class="bcp14">MAY</span>, at any time, send an
unscheduled IHU packet.  It <span class="bcp14">MAY</span> also, at any time, decrease its IHU
interval, and it <span class="bcp14">MAY</span> increase its IHU interval immediately before sending
an IHU, but <span class="bcp14">SHOULD NOT</span> increase it at any other time.  (Equivalently,
a node <span class="bcp14">SHOULD</span> send an extra IHU immediately after increasing its Hello
interval.)<a href="#section-3.4.2-2" class="pilcrow">¶</a></p>
<p id="section-3.4.2-3">Every IHU TLV contains two pieces of data: the link's rxcost (reception
cost) from the sender's perspective, used by the neighbour for computing
link costs (<a href="#cost-computation" class="xref">Section 3.4.3</a>), and the interval between
periodic IHU packets.  A node receiving an IHU sets the value of the
txcost (transmission cost) maintained in the neighbour table to the value
contained in the IHU, and resets the IHU timer associated to this
neighbour to a small multiple of the interval value received in the IHU
(see "IHU Hold time" in <a href="#parameters" class="xref">Appendix B</a> for suggested values).
When a neighbour's IHU timer expires, the neighbour's txcost is set to
infinity.<a href="#section-3.4.2-3" class="pilcrow">¶</a></p>
<p id="section-3.4.2-4">After updating a neighbour's txcost, the receiving node recomputes the
neighbour's cost (<a href="#cost-computation" class="xref">Section 3.4.3</a>) and runs the route
selection procedure (<a href="#route-selection" class="xref">Section 3.6</a>).<a href="#section-3.4.2-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="cost-computation">
<section id="section-3.4.3">
          <h4 id="name-cost-computation">
<a href="#section-3.4.3" class="section-number selfRef">3.4.3. </a><a href="#name-cost-computation" class="section-name selfRef">Cost Computation</a>
          </h4>
<p id="section-3.4.3-1">A neighbourship association's link cost is computed from the values
maintained in the neighbour table: the statistics kept in the neighbour
table about the reception of Hellos, and the txcost computed from received
IHU packets.<a href="#section-3.4.3-1" class="pilcrow">¶</a></p>
<p id="section-3.4.3-2">For every neighbour, a Babel node computes a value known as this
neighbour's rxcost.  This value is usually derived from the Hello history,
which may be combined with other data, such as statistics maintained by
the link layer.  The rxcost is sent to a neighbour in each IHU.<a href="#section-3.4.3-2" class="pilcrow">¶</a></p>
<p id="section-3.4.3-3">Since nodes do not necessarily send periodic Unicast Hellos but do
usually send periodic Multicast Hellos (<a href="#reverse-reachability" class="xref">Section 3.4.1</a>),
a node <span class="bcp14">SHOULD</span> use an algorithm that yields a finite rxcost when only
Multicast Hellos are received, unless interoperability with nodes that
only send Multicast Hellos is not required.<a href="#section-3.4.3-3" class="pilcrow">¶</a></p>
<p id="section-3.4.3-4">How the txcost and rxcost are combined in order to compute a link's
cost is a matter of local policy; as far as Babel's correctness is
concerned, only the following conditions <span class="bcp14">MUST</span> be satisfied:<a href="#section-3.4.3-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.4.3-5.1">the cost is strictly positive;<a href="#section-3.4.3-5.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.4.3-5.2">if no Hello TLVs of either kind were received recently, then the cost
  is infinite;<a href="#section-3.4.3-5.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.4.3-5.3">if the txcost is infinite, then the cost is infinite.<a href="#section-3.4.3-5.3" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-3.4.3-6">See <a href="#cost-computation-examples" class="xref">Appendix A.2</a> for <span class="bcp14">RECOMMENDED</span>
strategies for computing a link's cost.<a href="#section-3.4.3-6" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="route-maintenance">
<section id="section-3.5">
        <h3 id="name-routing-table-maintenance">
<a href="#section-3.5" class="section-number selfRef">3.5. </a><a href="#name-routing-table-maintenance" class="section-name selfRef">Routing Table Maintenance</a>
        </h3>
<p id="section-3.5-1">Conceptually, a Babel update is a quintuple (prefix, plen, router-id,
seqno, metric), where (prefix, plen) is the prefix for which a route is
being advertised, router-id is the router-id of the router originating this
update, seqno is a nondecreasing (modulo 2<sup>16</sup>) integer that carries the
originating router seqno, and metric is the announced metric.<a href="#section-3.5-1" class="pilcrow">¶</a></p>
<p id="section-3.5-2">Before being accepted, an update is checked against the feasibility
condition (<a href="#feasibility-condition" class="xref">Section 3.5.1</a>), which ensures that the
route does not create a routing loop.  If the feasibility condition is not
satisfied, the update is either ignored or prevents the route from being
selected, as described in <a href="#route-acquisition" class="xref">Section 3.5.3</a>.  If the
feasibility condition is satisfied, then the update cannot possibly cause
a routing loop.<a href="#section-3.5-2" class="pilcrow">¶</a></p>
<div id="feasibility-condition">
<section id="section-3.5.1">
          <h4 id="name-the-feasibility-condition">
<a href="#section-3.5.1" class="section-number selfRef">3.5.1. </a><a href="#name-the-feasibility-condition" class="section-name selfRef">The Feasibility Condition</a>
          </h4>
<p id="section-3.5.1-1">The feasibility condition is applied to all received updates.  The
feasibility condition compares the metric in the received update with the
metrics of the updates previously sent by the receiving node; updates that
fail the feasibility condition, and therefore have metrics large enough to
cause a routing loop, are either ignored or prevent the resulting route
from being selected.<a href="#section-3.5.1-1" class="pilcrow">¶</a></p>
<p id="section-3.5.1-2">A feasibility distance is a pair (seqno, metric), where seqno is an
integer modulo 2<sup>16</sup> and metric is a positive integer.  Feasibility
distances are compared lexicographically, with the first component
inverted: we say that a distance (seqno, metric) is strictly better than
a distance (seqno', metric'), written<a href="#section-3.5.1-2" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-3.5.1-3">(seqno, metric) &lt; (seqno', metric')<a href="#section-3.5.1-3" class="pilcrow">¶</a></p>
<p id="section-3.5.1-4">
when<a href="#section-3.5.1-4" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-3.5.1-5">seqno &gt; seqno' or (seqno = seqno' and metric &lt; metric')<a href="#section-3.5.1-5" class="pilcrow">¶</a></p>
<p id="section-3.5.1-6">
where sequence numbers are compared modulo 2<sup>16</sup>.<a href="#section-3.5.1-6" class="pilcrow">¶</a></p>
<p id="section-3.5.1-7">Given a source (prefix, plen, router-id), a node's feasibility distance
for this source is the minimum, according to the ordering defined above,
of the distances of all the finite updates ever sent by this particular
node for the prefix (prefix, plen) and the given router-id.  Feasibility
distances are maintained in the source table, the exact procedure is given
in <a href="#maintaining-fd" class="xref">Section 3.7.3</a>.<a href="#section-3.5.1-7" class="pilcrow">¶</a></p>
<p id="section-3.5.1-8">A received update is feasible when either it is a retraction (its metric
is FFFF hexadecimal), or the advertised distance is strictly better, in the
sense defined above, than the feasibility distance for the corresponding
source.  More precisely, a route advertisement carrying the quintuple
(prefix, plen, router-id, seqno, metric) is feasible if one of the
following conditions holds:<a href="#section-3.5.1-8" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.5.1-9.1">metric is infinite; or<a href="#section-3.5.1-9.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.5.1-9.2">no entry exists in the source table indexed by (prefix, plen, router-id);
  or<a href="#section-3.5.1-9.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.5.1-9.3">
              <p id="section-3.5.1-9.3.1">an entry (prefix, plen, router-id, seqno', metric') exists in the
    source table, and either<a href="#section-3.5.1-9.3.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.5.1-9.3.2.1">seqno' &lt; seqno or<a href="#section-3.5.1-9.3.2.1" class="pilcrow">¶</a>
</li>
                <li class="normal" id="section-3.5.1-9.3.2.2">seqno = seqno' and metric &lt; metric'.<a href="#section-3.5.1-9.3.2.2" class="pilcrow">¶</a>
</li>
              </ul>
</li>
          </ul>
<p id="section-3.5.1-10">Note that the feasibility condition considers the metric advertised by
the neighbour, not the route's metric; hence, a fluctuation in
a neighbour's cost cannot render a selected route unfeasible.  Note
further that retractions (updates with infinite metric) are always
feasible, since they cannot possibly cause a routing loop.<a href="#section-3.5.1-10" class="pilcrow">¶</a></p>
</section>
</div>
<div id="metric-computation">
<section id="section-3.5.2">
          <h4 id="name-metric-computation">
<a href="#section-3.5.2" class="section-number selfRef">3.5.2. </a><a href="#name-metric-computation" class="section-name selfRef">Metric Computation</a>
          </h4>
<p id="section-3.5.2-1">A route's metric is computed from the metric advertised by the neighbour
and the neighbour's link cost.  Just like cost computation, metric
computation is considered a local policy matter; as far as Babel is
concerned, the function M(c, m) used for computing a metric from
a locally computed link cost c and the metric m advertised by a neighbour
<span class="bcp14">MUST</span> only satisfy the following conditions:<a href="#section-3.5.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.5.2-2.1">if c is infinite, then M(c, m) is infinite;<a href="#section-3.5.2-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.5.2-2.2">M is strictly monotonic: M(c, m) &gt; m.<a href="#section-3.5.2-2.2" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-3.5.2-3">
Additionally, the metric <span class="bcp14">SHOULD</span> satisfy the following condition:<a href="#section-3.5.2-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.5.2-4.1">M is left-distributive: if m &lt;= m', then M(c, m) &lt;= M(c, m').<a href="#section-3.5.2-4.1" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-3.5.2-5">
While strict monotonicity is essential to the integrity of the network
(persistent routing loops may arise if it is not satisfied), 
left-distributivity is not: if it is not satisfied, Babel will still converge
to a loop-free configuration, but might not reach a global optimum (in
fact, a global optimum may not even exist).<a href="#section-3.5.2-5" class="pilcrow">¶</a></p>
<p id="section-3.5.2-6">The conditions above are easily satisfied by using the additive metric,
i.e., by defining M(c, m) = c + m.  Since the additive
metric is useful with a large range of cost computation strategies, it is
the <span class="bcp14">RECOMMENDED</span> default.  See also <a href="#filtering" class="xref">Appendix C</a>, which
describes a technique that makes it possible to tweak the values of
individual metrics without running the risk of creating routing loops.<a href="#section-3.5.2-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="route-acquisition">
<section id="section-3.5.3">
          <h4 id="name-route-acquisition">
<a href="#section-3.5.3" class="section-number selfRef">3.5.3. </a><a href="#name-route-acquisition" class="section-name selfRef">Route Acquisition</a>
          </h4>
<p id="section-3.5.3-1">When a Babel node receives an update (prefix, plen, router-id, seqno,
metric) from a neighbour neigh, it checks whether it already has a route
table entry indexed by (prefix, plen, neigh).<a href="#section-3.5.3-1" class="pilcrow">¶</a></p>
<p id="section-3.5.3-2">If no such entry exists:<a href="#section-3.5.3-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.5.3-3.1">if the update is unfeasible, it <span class="bcp14">MAY</span> be ignored;<a href="#section-3.5.3-3.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.5.3-3.2">if the metric is infinite (the update is a retraction of a route we
  do not know about), the update is ignored;<a href="#section-3.5.3-3.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.5.3-3.3">otherwise, a new entry is created in the route table, indexed by (prefix,
  plen, neigh), with source equal to (prefix, plen, router-id), seqno
  equal to seqno, and an advertised metric equal to the metric carried by
  the update.<a href="#section-3.5.3-3.3" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-3.5.3-4">
If such an entry exists:<a href="#section-3.5.3-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.5.3-5.1">if the entry is currently selected, the update is unfeasible, and the
  router-id of the update is equal to the router-id of the entry, then the
  update <span class="bcp14">MAY</span> be ignored;<a href="#section-3.5.3-5.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.5.3-5.2">otherwise, the entry's sequence number, advertised metric, metric,
  and router-id are updated, and if the advertised metric is not infinite,
  the route's expiry timer is reset to a small multiple of the interval
  value included in the update (see "Route Expiry time" in
  <a href="#parameters" class="xref">Appendix B</a> for suggested values).  If the update is
  unfeasible, then the (now unfeasible) entry <span class="bcp14">MUST</span> be immediately
  unselected.  If the update caused the router-id of the entry to change,
  an update (possibly a retraction) <span class="bcp14">MUST</span> be sent in a timely manner as
  described in <a href="#triggered-updates" class="xref">Section 3.7.2</a>.<a href="#section-3.5.3-5.2" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-3.5.3-6">
Note that the route table may contain unfeasible routes, either because
they were created by an unfeasible update or due to a metric fluctuation.
Such routes are never selected, since they are not known to be loop-free.
Should all the feasible routes become unusable, however, the unfeasible
routes can be made feasible and therefore possible to select by sending
requests along them (see <a href="#sending-requests" class="xref">Section 3.8.2</a>).<a href="#section-3.5.3-6" class="pilcrow">¶</a></p>
<p id="section-3.5.3-7">When a route's expiry timer triggers, the behaviour depends on whether
the route's metric is finite.  If the metric is finite, it is set to
infinity and the expiry timer is reset.  If the metric is already infinite,
the route is flushed from the route table.<a href="#section-3.5.3-7" class="pilcrow">¶</a></p>
<p id="section-3.5.3-8">After the route table is updated, the route selection procedure
(<a href="#route-selection" class="xref">Section 3.6</a>) is run.<a href="#section-3.5.3-8" class="pilcrow">¶</a></p>
</section>
</div>
<div id="hold-time">
<section id="section-3.5.4">
          <h4 id="name-hold-time">
<a href="#section-3.5.4" class="section-number selfRef">3.5.4. </a><a href="#name-hold-time" class="section-name selfRef">Hold Time</a>
          </h4>
<p id="section-3.5.4-1">When a prefix P is retracted (because all routes are unfeasible or have
an infinite metric, whether due to the expiry timer or for other reasons),
and a shorter prefix P' that covers P is reachable, P' cannot in general
be used for routing packets destined to P without running the risk of
creating a routing loop (<a href="#overlapping-prefixes" class="xref">Section 2.8</a>).<a href="#section-3.5.4-1" class="pilcrow">¶</a></p>
<p id="section-3.5.4-2">To avoid this issue, whenever a prefix P is retracted, a route table
entry with infinite metric is maintained as described in <a href="#route-acquisition" class="xref">Section 3.5.3</a>.  
As long as this entry is maintained,
packets destined to an address within P <span class="bcp14">MUST NOT</span> be forwarded by following
a route for a shorter prefix.  This entry is removed as soon as
a finite-metric update for prefix P is received and the resulting route
selected.  If no such update is forthcoming, the infinite metric entry
<span class="bcp14">SHOULD</span> be maintained at least until it is guaranteed that no neighbour has
selected the current node as next hop for prefix P.  This can be achieved
by either:<a href="#section-3.5.4-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.5.4-3.1">waiting until the route's expiry timer has expired 
                (<a href="#route-acquisition" class="xref">Section 3.5.3</a>); or<a href="#section-3.5.4-3.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.5.4-3.2">sending a retraction with an acknowledgment request (<a href="#acknowledgments" class="xref">Section 3.3</a>) to every reachable neighbour that has not
explicitly retracted prefix P, and waiting for all acknowledgments.<a href="#section-3.5.4-3.2" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-3.5.4-4">
The former option is simpler and ensures that, at that point, any routes
for prefix P pointing at the current node have expired.  However, since
the expiry time can be as high as a few minutes, doing that prevents
automatic aggregation by creating spurious black-holes for aggregated
routes.  The latter option is <span class="bcp14">RECOMMENDED</span> as it dramatically reduces the
time for which a prefix is unreachable in the presence of aggregated
routes.<a href="#section-3.5.4-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="route-selection">
<section id="section-3.6">
        <h3 id="name-route-selection">
<a href="#section-3.6" class="section-number selfRef">3.6. </a><a href="#name-route-selection" class="section-name selfRef">Route Selection</a>
        </h3>
<p id="section-3.6-1">Route selection is the process by which a single route for a given
prefix is selected to be used for forwarding packets and to be
re-advertised to a node's neighbours.<a href="#section-3.6-1" class="pilcrow">¶</a></p>
<p id="section-3.6-2">Babel is designed to allow flexible route selection policies.  As far as
  the algorithm's correctness is concerned, the route selection policy <span class="bcp14">MUST</span>
  only satisfy the following properties:<a href="#section-3.6-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.6-3.1">a route with infinite metric (a retracted route) is never selected;<a href="#section-3.6-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.6-3.2">an unfeasible route is never selected.<a href="#section-3.6-3.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-3.6-4">
Babel nodes using different route selection strategies will interoperate
and will not create routing loops as long as these two properties hold.<a href="#section-3.6-4" class="pilcrow">¶</a></p>
<p id="section-3.6-5">Route selection <span class="bcp14">MUST NOT</span> take seqnos into account: a route <span class="bcp14">MUST NOT</span> be
preferred just because it carries a higher (more recent) seqno.  Doing
otherwise would cause route oscillation while a new seqno propagates
across the network, and might create persistent black-holes if the metric
being used is not left-distributive (<a href="#metric-computation" class="xref">Section 3.5.2</a>).<a href="#section-3.6-5" class="pilcrow">¶</a></p>
<p id="section-3.6-6">The obvious route selection strategy is to pick, for every destination,
the feasible route with minimal metric.  When all metrics are stable, this
approach ensures convergence to a tree of shortest paths (assuming that
the metric is left-distributive, see <a href="#metric-computation" class="xref">Section 3.5.2</a>).
There are two reasons, however, why this strategy may lead to instability
in the presence of continuously varying metrics.  First, if two parallel
routes oscillate around a common value, then the smallest metric strategy
will keep switching between the two.  
   Second, the selection of a route increases congestion along it,
   which might increase packet loss, which in turn could
   cause its metric to increase; this kind of feedback loop
   is prone to causing persistent oscillations.<a href="#section-3.6-6" class="pilcrow">¶</a></p>
<p id="section-3.6-7">In order to limit these kinds of instabilities, a route selection
strategy <span class="bcp14">SHOULD</span> include some form of hysteresis, i.e., be sensitive to
a route's history: 
the strategy should only switch from the currently selected route
to a different route if the latter has been
consistently good for some period of time.  A <span class="bcp14">RECOMMENDED</span> hysteresis
algorithm is given in <a href="#route-selection-hysteresis" class="xref">Appendix A.3</a>.<a href="#section-3.6-7" class="pilcrow">¶</a></p>
<p id="section-3.6-8">After the route selection procedure is run, triggered updates
(<a href="#triggered-updates" class="xref">Section 3.7.2</a>) and requests
(<a href="#sending-requests" class="xref">Section 3.8.2</a>) are sent.<a href="#section-3.6-8" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sending-updates">
<section id="section-3.7">
        <h3 id="name-sending-updates">
<a href="#section-3.7" class="section-number selfRef">3.7. </a><a href="#name-sending-updates" class="section-name selfRef">Sending Updates</a>
        </h3>
<p id="section-3.7-1">A Babel speaker advertises to its neighbours its set of selected
routes.  Normally, this is done by sending one or more multicast packets
containing Update TLVs on all of its connected interfaces; however, on
link technologies where multicast is significantly more expensive than
unicast, a node <span class="bcp14">MAY</span> choose to send multiple copies of updates in unicast
packets, especially when the number of neighbours is small.<a href="#section-3.7-1" class="pilcrow">¶</a></p>
<p id="section-3.7-2">Additionally, in order to ensure that any black-holes are reliably
cleared in a timely manner, a Babel node may send retractions (updates
with an infinite metric) for any recently retracted prefixes.<a href="#section-3.7-2" class="pilcrow">¶</a></p>
<p id="section-3.7-3">If an update is for a route injected into the Babel domain by the local
node (e.g., it carries the address of a local interface, the prefix of
a directly attached network, or a prefix redistributed from a different
routing protocol), the router-id is set to the local node's router-id, the
metric is set to some arbitrary finite value (typically 0), and the seqno
is set to the local router's sequence number.<a href="#section-3.7-3" class="pilcrow">¶</a></p>
<p id="section-3.7-4">If an update is for a route learnt from another Babel speaker, the
router-id and sequence number are copied from the route table entry, and
the metric is computed as specified in <a href="#metric-computation" class="xref">Section 3.5.2</a>.<a href="#section-3.7-4" class="pilcrow">¶</a></p>
<div id="periodic-updates">
<section id="section-3.7.1">
          <h4 id="name-periodic-updates">
<a href="#section-3.7.1" class="section-number selfRef">3.7.1. </a><a href="#name-periodic-updates" class="section-name selfRef">Periodic Updates</a>
          </h4>
<p id="section-3.7.1-1">Every Babel speaker <span class="bcp14">MUST</span> advertise each of its selected routes on every
interface, at least once every Update interval.  Since Babel doesn't
suffer from routing loops (there is no "counting to infinity") and relies
heavily on triggered updates (<a href="#triggered-updates" class="xref">Section 3.7.2</a>), this
full dump only needs to happen infrequently (see <a href="#parameters" class="xref">Appendix B</a>
for suggested intervals).<a href="#section-3.7.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="triggered-updates">
<section id="section-3.7.2">
          <h4 id="name-triggered-updates">
<a href="#section-3.7.2" class="section-number selfRef">3.7.2. </a><a href="#name-triggered-updates" class="section-name selfRef">Triggered Updates</a>
          </h4>
<p id="section-3.7.2-1">In addition to periodic routing updates, a Babel speaker sends
unscheduled, or triggered, updates in order to inform its neighbours of
a significant change in the network topology.<a href="#section-3.7.2-1" class="pilcrow">¶</a></p>
<p id="section-3.7.2-2">A change of router-id for the selected route to a given prefix may be
indicative of a routing loop in formation; hence, whenever it changes the
selected router-id for a given destination, a node <span class="bcp14">MUST</span> send an update as
an urgent TLV (as defined in <a href="#transmission-reception" class="xref">Section 3.1</a>).
Additionally, it <span class="bcp14">SHOULD</span> make a reasonable attempt at ensuring that all
reachable neighbours receive this update.<a href="#section-3.7.2-2" class="pilcrow">¶</a></p>
<p id="section-3.7.2-3">There are two strategies for ensuring that.  If the number of neighbours
is small, then it is reasonable to send the update together with an
acknowledgment request; the update is resent until all neighbours have
acknowledged the packet, up to some number of times.  If the number of
neighbours is large, however, requesting acknowledgments from all of them
might cause a non-negligible amount of network traffic; in that case, it
may be preferable to simply repeat the update some reasonable number of
times (say, 3 for wireless and 2 for wired links).  The number of copies
<span class="bcp14">MUST NOT</span> exceed 5, and the copies <span class="bcp14">SHOULD</span> be separated by a small delay, as
described in <a href="#transmission-reception" class="xref">Section 3.1</a>.<a href="#section-3.7.2-3" class="pilcrow">¶</a></p>
<p id="section-3.7.2-4">A route retraction is somewhat less worrying: if the route retraction
doesn't reach all neighbours, a black-hole might be created, which, unlike
a routing loop, does not endanger the integrity of the network.  When a
route is retracted, a node <span class="bcp14">SHOULD</span> send a triggered update and <span class="bcp14">SHOULD</span> make
a reasonable attempt at ensuring that all neighbours receive this
retraction.<a href="#section-3.7.2-4" class="pilcrow">¶</a></p>
<p id="section-3.7.2-5">Finally, a node <span class="bcp14">MAY</span> send a triggered update when the metric for a given
prefix changes in a significant manner, due to a received update, because
a link's cost has changed or because a different next hop has been
selected.  A node <span class="bcp14">SHOULD NOT</span> send triggered updates for other reasons,
such as when there is a minor fluctuation in a route's metric, when the
selected next hop changes without inducing a significant change to the
route's metric, or to propagate a new sequence number (except to satisfy
a request, as specified in <a href="#requests" class="xref">Section 3.8</a>).<a href="#section-3.7.2-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="maintaining-fd">
<section id="section-3.7.3">
          <h4 id="name-maintaining-feasibility-dis">
<a href="#section-3.7.3" class="section-number selfRef">3.7.3. </a><a href="#name-maintaining-feasibility-dis" class="section-name selfRef">Maintaining Feasibility Distances</a>
          </h4>
<p id="section-3.7.3-1">Before sending an update (prefix, plen, router-id, seqno, metric) with
finite metric (i.e., not a route retraction), a Babel node updates the
feasibility distance maintained in the source table.  This is done as
follows.<a href="#section-3.7.3-1" class="pilcrow">¶</a></p>
<p id="section-3.7.3-2">If no entry indexed by (prefix, plen, router-id) exists in the source
table, then one is created with value (prefix, plen, router-id, seqno,
metric).<a href="#section-3.7.3-2" class="pilcrow">¶</a></p>
<p id="section-3.7.3-3">If an entry (prefix, plen, router-id, seqno', metric') exists, then it
is updated as follows:<a href="#section-3.7.3-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.7.3-4.1">if seqno &gt; seqno', then seqno' := seqno, metric' := metric;<a href="#section-3.7.3-4.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.7.3-4.2">if seqno = seqno' and metric' &gt; metric, then metric' := metric;<a href="#section-3.7.3-4.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.7.3-4.3">otherwise, nothing needs to be done.<a href="#section-3.7.3-4.3" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-3.7.3-5">The garbage-collection timer for the entry is then reset.  Note that
the feasibility distance is not updated and the garbage-collection timer
is not reset when a retraction (an update with infinite metric) is
sent.<a href="#section-3.7.3-5" class="pilcrow">¶</a></p>
<p id="section-3.7.3-6">When the garbage-collection timer expires, the entry is removed from
the source table.<a href="#section-3.7.3-6" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-3.7.4">
          <h4 id="name-split-horizon">
<a href="#section-3.7.4" class="section-number selfRef">3.7.4. </a><a href="#name-split-horizon" class="section-name selfRef">Split Horizon</a>
          </h4>
<p id="section-3.7.4-1">When running over a transitive, symmetric link technology, e.g.,
a point-to-point link or a wired LAN technology such as Ethernet, a Babel
node <span class="bcp14">SHOULD</span> use an optimisation known as split horizon.  When split
horizon is used on a given interface, a routing update for prefix P is not
sent on the particular interface over which the selected route towards
prefix P was learnt.<a href="#section-3.7.4-1" class="pilcrow">¶</a></p>
<p id="section-3.7.4-2">Split horizon <span class="bcp14">SHOULD NOT</span> be applied to an interface unless the interface
is known to be symmetric and transitive; in particular, split horizon is
not applicable to decentralised wireless link technologies
(e.g., IEEE 802.11 in ad hoc mode) when routing updates are sent over
multicast.<a href="#section-3.7.4-2" class="pilcrow">¶</a></p>
</section>
</section>
</div>
<div id="requests">
<section id="section-3.8">
        <h3 id="name-explicit-requests">
<a href="#section-3.8" class="section-number selfRef">3.8. </a><a href="#name-explicit-requests" class="section-name selfRef">Explicit Requests</a>
        </h3>
<p id="section-3.8-1">In normal operation, a node's route table is populated by the regular
and triggered updates sent by its neighbours.  Under some circumstances,
however, a node sends explicit requests in order to cause a resynchronisation
with the source after a mobility event or to prevent a route from
spuriously expiring.<a href="#section-3.8-1" class="pilcrow">¶</a></p>
<p id="section-3.8-2">The Babel protocol provides two kinds of explicit requests: route
requests, which simply request an update for a given prefix, and seqno
requests, which request an update for a given prefix with a specific
sequence number.  The former are never forwarded; the latter are forwarded
if they cannot be satisfied by the receiver.<a href="#section-3.8-2" class="pilcrow">¶</a></p>
<div id="handling-requests">
<section id="section-3.8.1">
          <h4 id="name-handling-requests">
<a href="#section-3.8.1" class="section-number selfRef">3.8.1. </a><a href="#name-handling-requests" class="section-name selfRef">Handling Requests</a>
          </h4>
<p id="section-3.8.1-1">Upon receiving a request, a node either forwards the request or sends an
update in reply to the request, as described in the following sections.  If
this causes an update to be sent, the update is either sent to a multicast
address on the interface on which the request was received, or to the
unicast address of the neighbour that sent the request.<a href="#section-3.8.1-1" class="pilcrow">¶</a></p>
<p id="section-3.8.1-2">The exact behaviour is different for route requests and seqno requests.<a href="#section-3.8.1-2" class="pilcrow">¶</a></p>
<div id="handling-route-requests">
<section id="section-3.8.1.1">
            <h5 id="name-route-requests">
<a href="#section-3.8.1.1" class="section-number selfRef">3.8.1.1. </a><a href="#name-route-requests" class="section-name selfRef">Route Requests</a>
            </h5>
<p id="section-3.8.1.1-1">When a node receives a route request for a given prefix, it checks its
route table for a selected route to this exact prefix.  If such a route
exists, it <span class="bcp14">MUST</span> send an update (over unicast or over multicast); if such
a route does not exist, it <span class="bcp14">MUST</span> send a retraction for that prefix.<a href="#section-3.8.1.1-1" class="pilcrow">¶</a></p>
<p id="section-3.8.1.1-2">When a node receives a wildcard route request, it <span class="bcp14">SHOULD</span> send a full
route table dump.  Full route dumps <span class="bcp14">SHOULD</span> be rate-limited, especially if
they are sent over multicast.<a href="#section-3.8.1.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="handling-seqno-requests">
<section id="section-3.8.1.2">
            <h5 id="name-seqno-requests">
<a href="#section-3.8.1.2" class="section-number selfRef">3.8.1.2. </a><a href="#name-seqno-requests" class="section-name selfRef">Seqno Requests</a>
            </h5>
<p id="section-3.8.1.2-1">When a node receives a seqno request for a given router-id and sequence
number, it checks whether its route table contains a selected entry for
that prefix.  If a selected route for the given prefix exists and has
finite metric, and either the router-ids are different or the router-ids
are equal and the entry's sequence number is no smaller (modulo 2<sup>16</sup>) than
the requested sequence number, the node <span class="bcp14">MUST</span> send an update for the given
prefix.  If the router-ids match, but the requested seqno is larger (modulo
2<sup>16</sup>) than the route entry's, the node compares the router-id against its
own router-id.  If the router-id is its own, then it increases its
sequence number by 1 (modulo 2<sup>16</sup>) and sends an update.  A node <span class="bcp14">MUST NOT</span>
increase its sequence number by more than 1 in reaction to a single seqno
request.<a href="#section-3.8.1.2-1" class="pilcrow">¶</a></p>
<p id="section-3.8.1.2-2">Otherwise, if the requested router-id is not its own, the received node
consults the Hop Count field of the request.  If the hop count is 2 or
more, and the node is advertising the prefix to its neighbours, the node
selects a neighbour to forward the request to as follows:<a href="#section-3.8.1.2-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.8.1.2-3.1">if the node has one or more feasible routes towards the requested prefix
with a next hop that is not the requesting node, then the node <span class="bcp14">MUST</span>
forward the request to the next hop of one such route;<a href="#section-3.8.1.2-3.1" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-3.8.1.2-3.2">otherwise, if the node has one or more (not feasible) routes to the
requested prefix with a next hop that is not the requesting node, then the
node <span class="bcp14">SHOULD</span> forward the request to the next hop of one such route.<a href="#section-3.8.1.2-3.2" class="pilcrow">¶</a>
</li>
            </ul>
<p id="section-3.8.1.2-4">
In order to actually forward the request, the node decrements the hop
count and sends the request in a unicast packet destined to the selected
neighbour.  The forwarded request <span class="bcp14">SHOULD</span> be sent as an urgent TLV (as
defined in <a href="#transmission-reception" class="xref">Section 3.1</a>).<a href="#section-3.8.1.2-4" class="pilcrow">¶</a></p>
<p id="section-3.8.1.2-5">A node <span class="bcp14">SHOULD</span> maintain a list of recently forwarded seqno requests and
forward the reply (an update with a seqno sufficiently large to satisfy
the request) as an urgent TLV (as defined in
<a href="#transmission-reception" class="xref">Section 3.1</a>).  A node <span class="bcp14">SHOULD</span> compare every
incoming seqno request against its list of recently forwarded seqno
requests and avoid forwarding the request if it is redundant (i.e., if the node has
recently sent a request with the same prefix, router-id, and a seqno that
is not smaller modulo 2<sup>16</sup>).<a href="#section-3.8.1.2-5" class="pilcrow">¶</a></p>
<p id="section-3.8.1.2-6">Since the request-forwarding mechanism does not necessarily obey the
feasibility condition, it may get caught in routing loops; hence, requests
carry a hop count to limit the time during which they remain in the network.
However, since requests are only ever forwarded as unicast packets, the
initial hop count need not be kept particularly low, and performing an
expanding horizon search is not necessary.  A single request <span class="bcp14">MUST NOT</span> be
duplicated: it <span class="bcp14">MUST NOT</span> be forwarded to a multicast address, and it <span class="bcp14">MUST NOT</span> be forwarded to multiple neighbours.  However, if a seqno request is
resent by its originator, the subsequent copies may be forwarded to
a different neighbour than the initial one.<a href="#section-3.8.1.2-6" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sending-requests">
<section id="section-3.8.2">
          <h4 id="name-sending-requests">
<a href="#section-3.8.2" class="section-number selfRef">3.8.2. </a><a href="#name-sending-requests" class="section-name selfRef">Sending Requests</a>
          </h4>
<p id="section-3.8.2-1">A Babel node <span class="bcp14">MAY</span> send a route or seqno request at any time to a
multicast or a unicast address; there is only one case when originating
requests is required (<a href="#avoiding-starvation" class="xref">Section 3.8.2.1</a>).<a href="#section-3.8.2-1" class="pilcrow">¶</a></p>
<div id="avoiding-starvation">
<section id="section-3.8.2.1">
            <h5 id="name-avoiding-starvation">
<a href="#section-3.8.2.1" class="section-number selfRef">3.8.2.1. </a><a href="#name-avoiding-starvation" class="section-name selfRef">Avoiding Starvation</a>
            </h5>
<p id="section-3.8.2.1-1">When a route is retracted or expires, a Babel node usually switches to
another feasible route for the same prefix.  It may be the case, however,
that no such routes are available.<a href="#section-3.8.2.1-1" class="pilcrow">¶</a></p>
<p id="section-3.8.2.1-2">A node that has lost all feasible routes to a given destination but
still has unexpired unfeasible routes to that destination <span class="bcp14">MUST</span> send
a seqno request; if it doesn't have any such routes, it <span class="bcp14">MAY</span> still send
a seqno request.  The router-id of the request is set to the router-id of
the route that it has just lost, and the requested seqno is the value
contained in the source table plus 1.  The request carries a hop count,
which is used as a last-resort mechanism to ensure that it eventually
vanishes from the network; it <span class="bcp14">MAY</span> be set to any value that is larger than
the diameter of the network (64 is a suitable default value).<a href="#section-3.8.2.1-2" class="pilcrow">¶</a></p>
<p id="section-3.8.2.1-3">If the node has any (unfeasible) routes to the requested destination,
then it <span class="bcp14">MUST</span> send the request to at least one of the next-hop neighbours
that advertised these routes, and <span class="bcp14">SHOULD</span> send it to all of them; in any
case, it <span class="bcp14">MAY</span> send the request to any other neighbours, whether they
advertise a route to the requested destination or not.  A simple
implementation strategy is therefore to unconditionally multicast the
request over all interfaces.<a href="#section-3.8.2.1-3" class="pilcrow">¶</a></p>
<p id="section-3.8.2.1-4">Similar requests will be sent by other nodes that are affected by the
route's loss.  If the network is still connected, and assuming no packet
loss, then at least one of these requests will be forwarded to the source,
resulting in a route being advertised with a new sequence number.  (Due to
duplicate suppression, only a small number of such requests are expected
to actually reach the source.)<a href="#section-3.8.2.1-4" class="pilcrow">¶</a></p>
<p id="section-3.8.2.1-5">In order to compensate for packet loss, a node <span class="bcp14">SHOULD</span> repeat such
a request a small number of times if no route becomes feasible within
a short time (see "Request timeout" in <a href="#parameters" class="xref">Appendix B</a> for
suggested values).  In the presence of heavy packet loss, however, all
such requests might be lost; in that case, the mechanism in the next
section will eventually ensure that a new seqno is received.<a href="#section-3.8.2.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="request-unfeasible">
<section id="section-3.8.2.2">
            <h5 id="name-dealing-with-unfeasible-upd">
<a href="#section-3.8.2.2" class="section-number selfRef">3.8.2.2. </a><a href="#name-dealing-with-unfeasible-upd" class="section-name selfRef">Dealing with Unfeasible Updates</a>
            </h5>
<p id="section-3.8.2.2-1">When a route's metric increases, a node might receive an unfeasible
update for a route that it has currently selected.  As specified in
<a href="#feasibility-condition" class="xref">Section 3.5.1</a>, the receiving node will either
ignore the update or unselect the route.<a href="#section-3.8.2.2-1" class="pilcrow">¶</a></p>
<p id="section-3.8.2.2-2">In order to keep routes from spuriously expiring because they have
become unfeasible, a node <span class="bcp14">SHOULD</span> send a unicast seqno request when it
receives an unfeasible update for a route that is currently selected.  The
requested sequence number is computed from the source table as in <a href="#avoiding-starvation" class="xref">Section 3.8.2.1</a>.<a href="#section-3.8.2.2-2" class="pilcrow">¶</a></p>
<p id="section-3.8.2.2-3">Additionally, since metric computation does not necessarily coincide
with the delay in propagating updates, a node might receive an unfeasible
update from a currently unselected neighbour that is preferable to the
currently selected route (e.g., because it has a much smaller metric); in
that case, the node <span class="bcp14">SHOULD</span> send a unicast seqno request to the neighbour
that advertised the preferable update.<a href="#section-3.8.2.2-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="request-expiring">
<section id="section-3.8.2.3">
            <h5 id="name-preventing-routes-from-expi">
<a href="#section-3.8.2.3" class="section-number selfRef">3.8.2.3. </a><a href="#name-preventing-routes-from-expi" class="section-name selfRef">Preventing Routes from Expiring</a>
            </h5>
<p id="section-3.8.2.3-1">In normal operation, a route's expiry timer never triggers: since
a route's hold time is computed from an explicit interval included in
Update TLVs, a new update (possibly a retraction) should arrive in time to
prevent a route from expiring.<a href="#section-3.8.2.3-1" class="pilcrow">¶</a></p>
<p id="section-3.8.2.3-2">In the presence of packet loss, however, it may be the case that no
update is successfully received for an extended period of time, causing
a route to expire.  In order to avoid such spurious expiry, shortly before
a selected route expires, a Babel node <span class="bcp14">SHOULD</span> send a unicast route request
to the neighbour that advertised this route; since nodes always send
either updates or retractions in response to non-wildcard route requests
(<a href="#handling-route-requests" class="xref">Section 3.8.1.1</a>), this will usually result in
the route being either refreshed or retracted.<a href="#section-3.8.2.3-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
</section>
</div>
</section>
<div id="protocol-encoding">
<section id="section-4">
      <h2 id="name-protocol-encoding">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-protocol-encoding" class="section-name selfRef">Protocol Encoding</a>
      </h2>
<p id="section-4-1">A Babel packet <span class="bcp14">MUST</span> be sent as the body of a UDP datagram, with
network-layer hop count set to 1, destined to a well-known multicast
address or to a unicast address, over IPv4 or IPv6; in the case of IPv6,
these addresses are link-local.  Both the source and destination UDP port
are set to a well-known port number.  A Babel packet <span class="bcp14">MUST</span> be silently
ignored unless its source address is either a link-local IPv6 address or
an IPv4 address belonging to the local network, and its source port is the
well-known Babel port.  It <span class="bcp14">MAY</span> be silently ignored if its destination
address is a global IPv6 address.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">In order to minimise the number of packets being sent while avoiding
lower-layer fragmentation, a Babel node <span class="bcp14">SHOULD</span> maximise the size of the
packets it sends, up to the outgoing interface's MTU adjusted for
lower-layer headers (28 octets for UDP over IPv4, 48 octets for UDP over
IPv6).  It <span class="bcp14">MUST NOT</span> send packets larger than the attached interface's MTU
adjusted for lower-layer headers or 512 octets, whichever is larger, but
not exceeding 2<sup>16</sup> - 1 adjusted for lower-layer headers.  Every Babel
speaker <span class="bcp14">MUST</span> be able to receive packets that are as large as any attached
interface's MTU adjusted for lower-layer headers or 512 octets, whichever
is larger.  Babel packets <span class="bcp14">MUST NOT</span> be sent in IPv6 jumbograms
<span>[<a href="#RFC2675" class="xref">RFC2675</a>]</span>.<a href="#section-4-2" class="pilcrow">¶</a></p>
<section id="section-4.1">
        <h3 id="name-data-types">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-data-types" class="section-name selfRef">Data Types</a>
        </h3>
<section id="section-4.1.1">
          <h4 id="name-representation-of-integers">
<a href="#section-4.1.1" class="section-number selfRef">4.1.1. </a><a href="#name-representation-of-integers" class="section-name selfRef">Representation of Integers</a>
          </h4>
<p id="section-4.1.1-1">All multi-octet fields that represent integers are encoded with the
most significant octet first (in Big-Endian format <span>[<a href="#IEN137" class="xref">IEN137</a>]</span>,
also called network order).  The base protocol only carries unsigned
values; if an extension needs to carry signed values, it will need to
specify their encoding (e.g., two's complement).<a href="#section-4.1.1-1" class="pilcrow">¶</a></p>
</section>
<section id="section-4.1.2">
          <h4 id="name-interval">
<a href="#section-4.1.2" class="section-number selfRef">4.1.2. </a><a href="#name-interval" class="section-name selfRef">Interval</a>
          </h4>
<p id="section-4.1.2-1">Relative times are carried as 16-bit values specifying a number of
centiseconds (hundredths of a second).  This allows times up to roughly 11
minutes with a granularity of 10 ms, which should cover all reasonable
applications of Babel (see also <a href="#parameters" class="xref">Appendix B</a>).<a href="#section-4.1.2-1" class="pilcrow">¶</a></p>
</section>
<div id="router-id-def">
<section id="section-4.1.3">
          <h4 id="name-router-id">
<a href="#section-4.1.3" class="section-number selfRef">4.1.3. </a><a href="#name-router-id" class="section-name selfRef">Router-Id</a>
          </h4>
<p id="section-4.1.3-1">A router-id is an arbitrary 8-octet value.  A router-id <span class="bcp14">MUST NOT</span>
consist of either all binary zeroes (0000000000000000 hexadecimal) or all
binary ones (FFFFFFFFFFFFFFFF hexadecimal).<a href="#section-4.1.3-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-4.1.4">
          <h4 id="name-address">
<a href="#section-4.1.4" class="section-number selfRef">4.1.4. </a><a href="#name-address" class="section-name selfRef">Address</a>
          </h4>
<p id="section-4.1.4-1">Since the bulk of the protocol is taken by addresses, multiple ways of
encoding addresses are defined.  Additionally, within Update TLVs a common
subnet prefix may be omitted when multiple addresses are sent in a single
packet -- this is known as address compression (<a href="#update" class="xref">Section 4.6.9</a>).<a href="#section-4.1.4-1" class="pilcrow">¶</a></p>
<p id="section-4.1.4-2">Address encodings (AEs):<a href="#section-4.1.4-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.1.4-3">
            <dt id="section-4.1.4-3.1">AE 0:</dt>
            <dd style="margin-left: 5.0em" id="section-4.1.4-3.2">Wildcard address.  The value is 0 octets long.<a href="#section-4.1.4-3.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.1.4-3.3">AE 1:</dt>
            <dd style="margin-left: 5.0em" id="section-4.1.4-3.4">IPv4 address.  Compression is allowed.  4 octets or less.<a href="#section-4.1.4-3.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.1.4-3.5">AE 2:</dt>
            <dd style="margin-left: 5.0em" id="section-4.1.4-3.6">IPv6 address.  Compression is allowed.  16 octets or less.<a href="#section-4.1.4-3.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.1.4-3.7">AE 3:</dt>
            <dd style="margin-left: 5.0em" id="section-4.1.4-3.8">Link-local IPv6 address.  Compression is not allowed.  The value
is 8 octets long, a prefix of fe80::/64 is implied.<a href="#section-4.1.4-3.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-4.1.4-4">The address family associated with an address encoding is either IPv4 or
IPv6: it is undefined for AE 0, IPv4 for AE 1, and IPv6 for AEs 2 and
3.<a href="#section-4.1.4-4" class="pilcrow">¶</a></p>
</section>
<section id="section-4.1.5">
          <h4 id="name-prefixes">
<a href="#section-4.1.5" class="section-number selfRef">4.1.5. </a><a href="#name-prefixes" class="section-name selfRef">Prefixes</a>
          </h4>
<p id="section-4.1.5-1">A network prefix is encoded just like a network address, but it is
stored in the smallest number of octets that are enough to hold the
significant bits (up to the prefix length).<a href="#section-4.1.5-1" class="pilcrow">¶</a></p>
</section>
</section>
<div id="packet-format">
<section id="section-4.2">
        <h3 id="name-packet-format">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-packet-format" class="section-name selfRef">Packet Format</a>
        </h3>
<p id="section-4.2-1">A Babel packet consists of a 4-octet header, followed by a sequence of
TLVs (the packet body), optionally followed by a second sequence of TLVs
(the packet trailer).  The format is designed to be extensible; see
<a href="#extensions" class="xref">Appendix D</a> for extensibility considerations.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-4.2-2">
<pre>
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Magic     |    Version    |        Body length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Packet Body...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|         Packet Trailer...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
</pre><a href="#section-4.2-2" class="pilcrow">¶</a>
</div>
<p id="section-4.2-3">Fields:<a href="#section-4.2-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.2-4">
          <dt id="section-4.2-4.1">Magic</dt>
          <dd style="margin-left: 5.0em" id="section-4.2-4.2">The arbitrary but carefully chosen value 42 (decimal);
packets with a first octet different from 42 <span class="bcp14">MUST</span> be silently ignored.<a href="#section-4.2-4.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.2-4.3">Version</dt>
          <dd style="margin-left: 5.0em" id="section-4.2-4.4">This document specifies version 2 of the Babel
  protocol.  Packets with a second octet different from 2 <span class="bcp14">MUST</span> be silently
  ignored.<a href="#section-4.2-4.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.2-4.5">Body length</dt>
          <dd style="margin-left: 5.0em" id="section-4.2-4.6">The length in octets of the body following the
packet header (excluding the Magic, Version, and Body length fields, and
excluding the packet trailer).<a href="#section-4.2-4.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.2-4.7">Packet Body</dt>
          <dd style="margin-left: 5.0em" id="section-4.2-4.8">The packet body; a sequence of TLVs.<a href="#section-4.2-4.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.2-4.9">Packet Trailer</dt>
          <dd style="margin-left: 5.0em" id="section-4.2-4.10">The packet trailer; another sequence of TLVs.<a href="#section-4.2-4.10" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-4.2-5">The packet body and trailer are both sequences of TLVs.  The packet
body is the normal place to store TLVs; the packet trailer only contains
specialised TLVs that do not need to be protected by cryptographic
security mechanisms.  When parsing the trailer, the receiver <span class="bcp14">MUST</span> ignore
any TLV unless its definition explicitly states that it is allowed to
appear there.  Among the TLVs defined in this document, only Pad1 and PadN
are allowed in the trailer; since these TLVs are ignored in any case, an
implementation <span class="bcp14">MAY</span> silently ignore the packet trailer without even parsing
it, unless it implements at least one protocol extension that defines TLVs
that are allowed to appear in the trailer.<a href="#section-4.2-5" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-4.3">
        <h3 id="name-tlv-format">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-tlv-format" class="section-name selfRef">TLV Format</a>
        </h3>
<p id="section-4.3-1">With the exception of Pad1, all TLVs have the following structure:<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-4.3-2">
<pre>
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |     Payload...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
</pre><a href="#section-4.3-2" class="pilcrow">¶</a>
</div>
<p id="section-4.3-3">Fields:<a href="#section-4.3-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.3-4">
          <dt id="section-4.3-4.1">Type</dt>
          <dd style="margin-left: 5.0em" id="section-4.3-4.2">The type of the TLV.<a href="#section-4.3-4.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.3-4.3">Length</dt>
          <dd style="margin-left: 5.0em" id="section-4.3-4.4">The length of the body in octets, exclusive of the
Type and Length fields.<a href="#section-4.3-4.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.3-4.5">Payload</dt>
          <dd style="margin-left: 5.0em" id="section-4.3-4.6">The TLV payload, which consists of a body and, for
selected TLV types, an optional list of sub-TLVs.<a href="#section-4.3-4.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-4.3-5">TLVs with an unknown type value <span class="bcp14">MUST</span> be silently ignored.<a href="#section-4.3-5" class="pilcrow">¶</a></p>
</section>
<div id="sub-tlv-format">
<section id="section-4.4">
        <h3 id="name-sub-tlv-format">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-sub-tlv-format" class="section-name selfRef">Sub-TLV Format</a>
        </h3>
<p id="section-4.4-1">Every TLV carries an explicit length in its header; however, most TLVs
are self-terminating, in the sense that it is possible to determine the
length of the body without reference to the explicit Length field.  If
a TLV has a self-terminating format, then the space between the natural
size of the TLV and the size announced in the Length field may be used to
store a sequence of sub-TLVs.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
<p id="section-4.4-2">Sub-TLVs have the same structure as TLVs.  With the exception of Pad1,
all TLVs have the following structure:<a href="#section-4.4-2" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-4.4-3">
<pre>
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |     Body...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
</pre><a href="#section-4.4-3" class="pilcrow">¶</a>
</div>
<p id="section-4.4-4">Fields:<a href="#section-4.4-4" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.4-5">
          <dt id="section-4.4-5.1">Type</dt>
          <dd style="margin-left: 5.0em" id="section-4.4-5.2">The type of the sub-TLV.<a href="#section-4.4-5.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.4-5.3">Length</dt>
          <dd style="margin-left: 5.0em" id="section-4.4-5.4">The length of the body in octets, exclusive of the
Type and Length fields.<a href="#section-4.4-5.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.4-5.5">Body</dt>
          <dd style="margin-left: 5.0em" id="section-4.4-5.6">The sub-TLV body, the interpretation of which depends
on both the type of the sub-TLV and the type of the TLV within which it is
embedded.<a href="#section-4.4-5.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-4.4-6">The most significant bit of the sub-TLV type (the bit with value 80
hexadecimal), is called the mandatory bit; in other words, sub-TLV types
128 through 255 have the mandatory bit set.  This bit indicates how to
handle unknown sub-TLVs.  If the mandatory bit is not set, then an unknown
sub-TLV <span class="bcp14">MUST</span> be silently ignored, and the rest of the TLV is processed
normally.  If the mandatory bit is set, then the whole enclosing TLV <span class="bcp14">MUST</span>
be silently ignored (except for updating the parser state by a Router-Id,
Next Hop, or Update TLV, as described in the next section).<a href="#section-4.4-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="parser-state">
<section id="section-4.5">
        <h3 id="name-parser-state-and-encoding-o">
<a href="#section-4.5" class="section-number selfRef">4.5. </a><a href="#name-parser-state-and-encoding-o" class="section-name selfRef">Parser State and Encoding of Updates</a>
        </h3>
<p id="section-4.5-1">In a large network, the bulk of Babel traffic consists of route
updates; hence, some care has been given to encoding them efficiently.
The data conceptually contained in an update (<a href="#route-maintenance" class="xref">Section 3.5</a>)
is split into three pieces:<a href="#section-4.5-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.5-2.1">the prefix, seqno, and metric are contained in the Update TLV itself
(<a href="#update" class="xref">Section 4.6.9</a>);<a href="#section-4.5-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.5-2.2">the router-id is taken from the Router-Id TLV that precedes the Update TLV
and may be shared among multiple Update TLVs (<a href="#router-id" class="xref">Section 4.6.7</a>);<a href="#section-4.5-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.5-2.3">the next hop is taken either from the source address of the
network-layer packet that contains the Babel packet or from an explicit
Next Hop TLV (<a href="#next-hop" class="xref">Section 4.6.8</a>).<a href="#section-4.5-2.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-4.5-3">
In addition to the above, an Update TLV can omit a prefix of the prefix
being announced, which is then extracted from the preceding Update TLV
in the same address family (IPv4 or IPv6).  Finally, as a special
optimisation for the case when a router-id coincides with the interface-id
part of an IPv6 address, the Router-Id TLV itself may be omitted, and the
router-id is derived from the low-order bits of the advertised prefix
(<a href="#update" class="xref">Section 4.6.9</a>).<a href="#section-4.5-3" class="pilcrow">¶</a></p>
<p id="section-4.5-4">In order to implement these compression techniques, Babel uses
a stateful parser: a TLV may refer to data from a previous TLV.  The
parser state consists of the following pieces of data:<a href="#section-4.5-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.5-5.1">for each address encoding that allows compression, the current
  default prefix: this is undefined at the start of the packet and is
  updated by each Update TLV with the Prefix flag set
  (<a href="#update" class="xref">Section 4.6.9</a>);<a href="#section-4.5-5.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.5-5.2">for each address family (IPv4 or IPv6), the current next hop: this is
  the source address of the enclosing packet for the matching address
  family at the start of a packet, and it is updated by each Next Hop TLV
  (<a href="#next-hop" class="xref">Section 4.6.8</a>);<a href="#section-4.5-5.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.5-5.3">the current router-id: this is undefined at the start of the packet,
  and it is updated by each Router-Id TLV (<a href="#router-id" class="xref">Section 4.6.7</a>)
  and by each Update TLV with Router-Id flag set.<a href="#section-4.5-5.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-4.5-6">Since the parser state must be identical across implementations, it is
updated before checking for mandatory sub-TLVs: parsing a TLV <span class="bcp14">MUST</span> update
the parser state even if the TLV is otherwise ignored due to an unknown
mandatory sub-TLV or for any other reason.<a href="#section-4.5-6" class="pilcrow">¶</a></p>
<p id="section-4.5-7">None of the TLVs that modify the parser state are allowed in the packet
trailer; hence, an implementation may choose to use a dedicated stateless
parser to parse the packet trailer.<a href="#section-4.5-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="tlv-details">
<section id="section-4.6">
        <h3 id="name-details-of-specific-tlvs">
<a href="#section-4.6" class="section-number selfRef">4.6. </a><a href="#name-details-of-specific-tlvs" class="section-name selfRef">Details of Specific TLVs</a>
        </h3>
<section id="section-4.6.1">
          <h4 id="name-pad1">
<a href="#section-4.6.1" class="section-number selfRef">4.6.1. </a><a href="#name-pad1" class="section-name selfRef">Pad1</a>
          </h4>
<div class="artwork art-text alignLeft" id="section-4.6.1-1">
<pre>
 0
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|   Type = 0    |
+-+-+-+-+-+-+-+-+
</pre><a href="#section-4.6.1-1" class="pilcrow">¶</a>
</div>
<p id="section-4.6.1-2">Fields:<a href="#section-4.6.1-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.6.1-3">
            <dt id="section-4.6.1-3.1">Type</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.1-3.2">Set to 0 to indicate a Pad1 TLV.<a href="#section-4.6.1-3.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-4.6.1-4">This TLV is silently ignored on reception.  It is allowed in the packet
trailer.<a href="#section-4.6.1-4" class="pilcrow">¶</a></p>
</section>
<section id="section-4.6.2">
          <h4 id="name-padn">
<a href="#section-4.6.2" class="section-number selfRef">4.6.2. </a><a href="#name-padn" class="section-name selfRef">PadN</a>
          </h4>
<div class="artwork art-text alignLeft" id="section-4.6.2-1">
<pre>
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type = 1   |    Length     |      MBZ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
</pre><a href="#section-4.6.2-1" class="pilcrow">¶</a>
</div>
<p id="section-4.6.2-2">Fields:<a href="#section-4.6.2-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.6.2-3">
            <dt id="section-4.6.2-3.1">Type</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.2-3.2">Set to 1 to indicate a PadN TLV.<a href="#section-4.6.2-3.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.2-3.3">Length</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.2-3.4">The length of the body in octets, exclusive of the
Type and Length fields.<a href="#section-4.6.2-3.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.2-3.5">MBZ</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.2-3.6">Must be zero, set to 0 on transmission.<a href="#section-4.6.2-3.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-4.6.2-4">This TLV is silently ignored on reception.  It is allowed in the packet
trailer.<a href="#section-4.6.2-4" class="pilcrow">¶</a></p>
</section>
<section id="section-4.6.3">
          <h4 id="name-acknowledgment-request">
<a href="#section-4.6.3" class="section-number selfRef">4.6.3. </a><a href="#name-acknowledgment-request" class="section-name selfRef">Acknowledgment Request</a>
          </h4>
<div class="artwork art-text alignLeft" id="section-4.6.3-1">
<pre>
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type = 2   |    Length     |          Reserved             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Opaque            |          Interval             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre><a href="#section-4.6.3-1" class="pilcrow">¶</a>
</div>
<p id="section-4.6.3-2">This TLV requests that the receiver send an Acknowledgment TLV
within the number of centiseconds specified by the Interval field.<a href="#section-4.6.3-2" class="pilcrow">¶</a></p>
<p id="section-4.6.3-3">Fields:<a href="#section-4.6.3-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.6.3-4">
            <dt id="section-4.6.3-4.1">Type</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.3-4.2">Set to 2 to indicate an Acknowledgment Request TLV.<a href="#section-4.6.3-4.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.3-4.3">Length</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.3-4.4">The length of the body in octets, exclusive of the
Type and Length fields.<a href="#section-4.6.3-4.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.3-4.5">Reserved</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.3-4.6">Sent as 0 and <span class="bcp14">MUST</span> be ignored on
  reception.<a href="#section-4.6.3-4.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.3-4.7">Opaque</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.3-4.8">An arbitrary value that will be echoed in the
receiver's Acknowledgment TLV.<a href="#section-4.6.3-4.8" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.3-4.9">Interval</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.3-4.10">A time interval in centiseconds after which the
sender will assume that this packet has been lost.  This <span class="bcp14">MUST NOT</span> be 0.
The receiver <span class="bcp14">MUST</span> send an Acknowledgment TLV before this time has elapsed
(with a margin allowing for propagation time).<a href="#section-4.6.3-4.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-4.6.3-5">This TLV is self-terminating and allows sub-TLVs.<a href="#section-4.6.3-5" class="pilcrow">¶</a></p>
</section>
<div id="ack">
<section id="section-4.6.4">
          <h4 id="name-acknowledgment">
<a href="#section-4.6.4" class="section-number selfRef">4.6.4. </a><a href="#name-acknowledgment" class="section-name selfRef">Acknowledgment</a>
          </h4>
<div class="artwork art-text alignLeft" id="section-4.6.4-1">
<pre>
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type = 3   |    Length     |           Opaque              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre><a href="#section-4.6.4-1" class="pilcrow">¶</a>
</div>
<p id="section-4.6.4-2">This TLV is sent by a node upon receiving an Acknowledgment Request TLV.<a href="#section-4.6.4-2" class="pilcrow">¶</a></p>
<p id="section-4.6.4-3">Fields:<a href="#section-4.6.4-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.6.4-4">
            <dt id="section-4.6.4-4.1">Type</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.4-4.2">Set to 3 to indicate an Acknowledgment TLV.<a href="#section-4.6.4-4.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.4-4.3">Length</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.4-4.4">The length of the body in octets, exclusive of the
Type and Length fields.<a href="#section-4.6.4-4.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.4-4.5">Opaque</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.4-4.6">Set to the Opaque value of the Acknowledgment Request
that prompted this Acknowledgment.<a href="#section-4.6.4-4.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-4.6.4-5">Since Opaque values are not globally unique, this TLV <span class="bcp14">MUST</span> be sent to
a unicast address.<a href="#section-4.6.4-5" class="pilcrow">¶</a></p>
<p id="section-4.6.4-6">This TLV is self-terminating and allows sub-TLVs.<a href="#section-4.6.4-6" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-4.6.5">
          <h4 id="name-hello">
<a href="#section-4.6.5" class="section-number selfRef">4.6.5. </a><a href="#name-hello" class="section-name selfRef">Hello</a>
          </h4>
<div class="artwork art-text alignLeft" id="section-4.6.5-1">
<pre>
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type = 4   |    Length     |            Flags              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Seqno              |          Interval             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre><a href="#section-4.6.5-1" class="pilcrow">¶</a>
</div>
<p id="section-4.6.5-2">This TLV is used for neighbour discovery and for determining a
neighbour's reception cost.<a href="#section-4.6.5-2" class="pilcrow">¶</a></p>
<p id="section-4.6.5-3">Fields:<a href="#section-4.6.5-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.6.5-4">
            <dt id="section-4.6.5-4.1">Type</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.5-4.2">Set to 4 to indicate a Hello TLV.<a href="#section-4.6.5-4.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.5-4.3">Length</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.5-4.4">The length of the body in octets, exclusive of the
Type and Length fields.<a href="#section-4.6.5-4.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.5-4.5">Flags</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.5-4.6">The individual bits of this field specify special
handling of this TLV (see below).<a href="#section-4.6.5-4.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.5-4.7">Seqno</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.5-4.8">If the Unicast flag is set, this is the value of the
sending node's outgoing Unicast Hello seqno for this neighbour.  Otherwise,
it is the sending node's outgoing Multicast Hello seqno for this interface.<a href="#section-4.6.5-4.8" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.5-4.9">Interval</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.5-4.10">If nonzero, this is an upper bound, expressed in
centiseconds, on the time after which the sending node will send a new
scheduled Hello TLV with the same setting of the Unicast flag.  If this is
0, then this Hello represents an unscheduled Hello and doesn't carry any
new information about times at which Hellos are sent.<a href="#section-4.6.5-4.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-4.6.5-5">The Flags field is interpreted as follows:<a href="#section-4.6.5-5" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-4.6.5-6">
<pre>
 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre><a href="#section-4.6.5-6" class="pilcrow">¶</a>
</div>
<span class="break"></span><dl class="dlParallel" id="section-4.6.5-7">
            <dt id="section-4.6.5-7.1">U (Unicast) flag (8000 hexadecimal):</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.5-7.2">if set, then this Hello
represents a Unicast Hello, otherwise it represents a Multicast Hello;<a href="#section-4.6.5-7.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.5-7.3">X:</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.5-7.4">all other bits <span class="bcp14">MUST</span> be sent as 0 and silently ignored on reception.<a href="#section-4.6.5-7.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-4.6.5-8">Every time a Hello is sent, the corresponding seqno counter <span class="bcp14">MUST</span> be
incremented.  Since there is a single seqno counter for all the Multicast
Hellos sent by a given node over a given interface, if the Unicast flag is
not set, this TLV <span class="bcp14">MUST</span> be sent to all neighbours on this link, which can be
achieved by sending to a multicast destination or by sending multiple
packets to the unicast addresses of all reachable neighbours.  Conversely,
if the Unicast flag is set, this TLV <span class="bcp14">MUST</span> be sent to a single neighbour,
which can achieved by sending to a unicast destination.  In order to avoid
large discontinuities in link quality, multiple Hello TLVs <span class="bcp14">SHOULD NOT</span> be
sent in the same packet.<a href="#section-4.6.5-8" class="pilcrow">¶</a></p>
<p id="section-4.6.5-9">This TLV is self-terminating and allows sub-TLVs.<a href="#section-4.6.5-9" class="pilcrow">¶</a></p>
</section>
<section id="section-4.6.6">
          <h4 id="name-ihu">
<a href="#section-4.6.6" class="section-number selfRef">4.6.6. </a><a href="#name-ihu" class="section-name selfRef">IHU</a>
          </h4>
<div class="artwork art-text alignLeft" id="section-4.6.6-1">
<pre>
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type = 5   |    Length     |       AE      |    Reserved   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Rxcost             |          Interval             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Address...
+-+-+-+-+-+-+-+-+-+-+-+-
</pre><a href="#section-4.6.6-1" class="pilcrow">¶</a>
</div>
<p id="section-4.6.6-2">An IHU ("I Heard You") TLV is used for confirming bidirectional
reachability and carrying a link's transmission cost.<a href="#section-4.6.6-2" class="pilcrow">¶</a></p>
<p id="section-4.6.6-3">Fields:<a href="#section-4.6.6-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.6.6-4">
            <dt id="section-4.6.6-4.1">Type</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.6-4.2">Set to 5 to indicate an IHU TLV.<a href="#section-4.6.6-4.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.6-4.3">Length</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.6-4.4">The length of the body in octets, exclusive of the
Type and Length fields.<a href="#section-4.6.6-4.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.6-4.5">AE</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.6-4.6">The encoding of the Address field.  This should be 1 or 3
in most cases.  As an optimisation, it <span class="bcp14">MAY</span> be 0 if the TLV is
sent to a unicast address, if the association is over a point-to-point
link, or when bidirectional reachability is ascertained by means outside of
the Babel protocol.<a href="#section-4.6.6-4.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.6-4.7">Reserved</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.6-4.8">Sent as 0 and <span class="bcp14">MUST</span> be ignored on reception.<a href="#section-4.6.6-4.8" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.6-4.9">Rxcost</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.6-4.10">The rxcost according to the sending node of the
interface whose address is specified in the Address field.  The value FFFF
hexadecimal (infinity) indicates that this interface is unreachable.<a href="#section-4.6.6-4.10" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.6-4.11">Interval</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.6-4.12">An upper bound, expressed in centiseconds, on the
time after which the sending node will send a new IHU; this <span class="bcp14">MUST NOT</span> be 0.
The receiving node will use this value in order to compute a hold time for
this symmetric association.<a href="#section-4.6.6-4.12" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.6-4.13">Address</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.6-4.14">The address of the destination node, in the format
specified by the AE field.  Address compression is not allowed.<a href="#section-4.6.6-4.14" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-4.6.6-5">Conceptually, an IHU is destined to a single neighbour.  However, IHU
TLVs contain an explicit destination address, and <span class="bcp14">MAY</span> be sent to
a multicast address, as this allows aggregation of IHUs destined to
distinct neighbours into a single packet and avoids the need for an ARP or
Neighbour Discovery exchange when a neighbour is not being used for data
traffic.<a href="#section-4.6.6-5" class="pilcrow">¶</a></p>
<p id="section-4.6.6-6">IHU TLVs with an unknown value in the AE field <span class="bcp14">MUST</span> be silently
ignored.<a href="#section-4.6.6-6" class="pilcrow">¶</a></p>
<p id="section-4.6.6-7">This TLV is self-terminating and allows sub-TLVs.<a href="#section-4.6.6-7" class="pilcrow">¶</a></p>
</section>
<div id="router-id">
<section id="section-4.6.7">
          <h4 id="name-router-id-2">
<a href="#section-4.6.7" class="section-number selfRef">4.6.7. </a><a href="#name-router-id-2" class="section-name selfRef">Router-Id</a>
          </h4>
<div class="artwork art-text alignLeft" id="section-4.6.7-1">
<pre>
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type = 6   |    Length     |          Reserved             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                           Router-Id                           +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre><a href="#section-4.6.7-1" class="pilcrow">¶</a>
</div>
<p id="section-4.6.7-2">A Router-Id TLV establishes a router-id that is implied by subsequent
Update TLVs, as described in <a href="#parser-state" class="xref">Section 4.5</a>.  This TLV sets
the router-id even if it is otherwise ignored due to an unknown mandatory
sub-TLV.<a href="#section-4.6.7-2" class="pilcrow">¶</a></p>
<p id="section-4.6.7-3">Fields:<a href="#section-4.6.7-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.6.7-4">
            <dt id="section-4.6.7-4.1">Type</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.7-4.2">Set to 6 to indicate a Router-Id TLV.<a href="#section-4.6.7-4.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.7-4.3">Length</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.7-4.4">The length of the body in octets, exclusive of the
Type and Length fields.<a href="#section-4.6.7-4.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.7-4.5">Reserved</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.7-4.6">Sent as 0 and <span class="bcp14">MUST</span> be ignored on reception.<a href="#section-4.6.7-4.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.7-4.7">Router-Id</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.7-4.8">The router-id for routes advertised in subsequent
Update TLVs.  This <span class="bcp14">MUST NOT</span> consist of all zeroes or all ones.<a href="#section-4.6.7-4.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-4.6.7-5">This TLV is self-terminating and allows sub-TLVs.<a href="#section-4.6.7-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="next-hop">
<section id="section-4.6.8">
          <h4 id="name-next-hop">
<a href="#section-4.6.8" class="section-number selfRef">4.6.8. </a><a href="#name-next-hop" class="section-name selfRef">Next Hop</a>
          </h4>
<div class="artwork art-text alignLeft" id="section-4.6.8-1">
<pre>
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type = 7   |    Length     |      AE       |   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Next hop...
+-+-+-+-+-+-+-+-+-+-+-+-
</pre><a href="#section-4.6.8-1" class="pilcrow">¶</a>
</div>
<p id="section-4.6.8-2">A Next Hop TLV establishes a next-hop address for a given address
family (IPv4 or IPv6) that is implied in subsequent Update TLVs, as
described in <a href="#parser-state" class="xref">Section 4.5</a>.  This TLV sets up the next hop
for subsequent Update TLVs even if it is otherwise ignored due to an
unknown mandatory sub-TLV.<a href="#section-4.6.8-2" class="pilcrow">¶</a></p>
<p id="section-4.6.8-3">Fields:<a href="#section-4.6.8-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.6.8-4">
            <dt id="section-4.6.8-4.1">Type</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.8-4.2">Set to 7 to indicate a Next Hop TLV.<a href="#section-4.6.8-4.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.8-4.3">Length</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.8-4.4">The length of the body in octets, exclusive of the
Type and Length fields.<a href="#section-4.6.8-4.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.8-4.5">AE</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.8-4.6">The encoding of the Address field.  This <span class="bcp14">SHOULD</span> be
1 (IPv4) or 3 (link-local IPv6), and <span class="bcp14">MUST NOT</span> be 0.<a href="#section-4.6.8-4.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.8-4.7">Reserved</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.8-4.8">Sent as 0 and <span class="bcp14">MUST</span> be ignored on reception.<a href="#section-4.6.8-4.8" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.8-4.9">Next hop</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.8-4.10">The next-hop address advertised by subsequent Update
TLVs for this address family.<a href="#section-4.6.8-4.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-4.6.8-5">When the address family matches the network-layer protocol over which this
packet is transported, a Next Hop TLV is not needed: in the absence
of a Next Hop TLV in a given address family, the next-hop address is taken
to be the source address of the packet.<a href="#section-4.6.8-5" class="pilcrow">¶</a></p>
<p id="section-4.6.8-6">Next Hop TLVs with an unknown value for the AE field <span class="bcp14">MUST</span> be silently
ignored.<a href="#section-4.6.8-6" class="pilcrow">¶</a></p>
<p id="section-4.6.8-7">This TLV is self-terminating, and allows sub-TLVs.<a href="#section-4.6.8-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="update">
<section id="section-4.6.9">
          <h4 id="name-update">
<a href="#section-4.6.9" class="section-number selfRef">4.6.9. </a><a href="#name-update" class="section-name selfRef">Update</a>
          </h4>
<div class="artwork art-text alignLeft" id="section-4.6.9-1">
<pre>
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type = 8   |    Length     |       AE      |    Flags      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Plen      |    Omitted    |            Interval           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Seqno             |            Metric             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Prefix...
+-+-+-+-+-+-+-+-+-+-+-+-
</pre><a href="#section-4.6.9-1" class="pilcrow">¶</a>
</div>
<p id="section-4.6.9-2">An Update TLV advertises or retracts a route.  As an optimisation, it
can optionally have the side effect of establishing a new implied
router-id and a new default prefix, as described in
<a href="#parser-state" class="xref">Section 4.5</a>.<a href="#section-4.6.9-2" class="pilcrow">¶</a></p>
<p id="section-4.6.9-3">Fields:<a href="#section-4.6.9-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.6.9-4">
            <dt id="section-4.6.9-4.1">Type</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.9-4.2">Set to 8 to indicate an Update TLV.<a href="#section-4.6.9-4.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.9-4.3">Length</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.9-4.4">The length of the body in octets, exclusive of the
Type and Length fields.<a href="#section-4.6.9-4.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.9-4.5">AE</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.9-4.6">The encoding of the Prefix field.<a href="#section-4.6.9-4.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.9-4.7">Flags</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.9-4.8">The individual bits of this field specify special
handling of this TLV (see below).<a href="#section-4.6.9-4.8" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.9-4.9">Plen</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.9-4.10">The length in bits of the advertised prefix.  If AE is
3 (link-local IPv6), the Omitted field <span class="bcp14">MUST</span> be 0.<a href="#section-4.6.9-4.10" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.9-4.11">Omitted</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.9-4.12">The number of octets that have been omitted at
the beginning of the advertised prefix and that should be taken from a
preceding Update TLV in the same address family with the Prefix flag set.<a href="#section-4.6.9-4.12" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.9-4.13">Interval</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.9-4.14">An upper bound, expressed in centiseconds, on the
time after which the sending node will send a new update for this prefix.
This <span class="bcp14">MUST NOT</span> be 0.  The receiving node will use this value to compute
a hold time for the route table entry.  The value FFFF hexadecimal
(infinity) expresses that this announcement will not be repeated unless
a request is received (<a href="#request-expiring" class="xref">Section 3.8.2.3</a>).<a href="#section-4.6.9-4.14" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.9-4.15">Seqno</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.9-4.16">The originator's sequence number for this update.<a href="#section-4.6.9-4.16" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.9-4.17">Metric</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.9-4.18">The sender's metric for this route.  The value FFFF
hexadecimal (infinity) means that this is a route retraction.<a href="#section-4.6.9-4.18" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.9-4.19">Prefix</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.9-4.20">The prefix being advertised.  This field's size is
(Plen/8 - Omitted) rounded upwards.<a href="#section-4.6.9-4.20" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-4.6.9-5">The Flags field is interpreted as follows:<a href="#section-4.6.9-5" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-4.6.9-6">
<pre>
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|P|R|X|X|X|X|X|X|
+-+-+-+-+-+-+-+-+
</pre><a href="#section-4.6.9-6" class="pilcrow">¶</a>
</div>
<span class="break"></span><dl class="dlParallel" id="section-4.6.9-7">
            <dt id="section-4.6.9-7.1">P (Prefix) flag (80 hexadecimal):</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.9-7.2">if set, then this Update
TLV establishes a new default prefix for subsequent Update TLVs with a matching
address encoding within the same packet, even if this TLV is otherwise
ignored due to an unknown mandatory sub-TLV;<a href="#section-4.6.9-7.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.9-7.3">R (Router-Id) flag (40 hexadecimal):</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.9-7.4">
              <p id="section-4.6.9-7.4.1">if set, then this TLV establishes
a new default router-id for this TLV and subsequent Update TLVs in the
same packet, even if this TLV is otherwise ignored due to an unknown
mandatory sub-TLV.  This router-id is computed from the first address of
the advertised prefix as follows:<a href="#section-4.6.9-7.4.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.6.9-7.4.2.1">if the length of the address is 8 octets or more, then the new
  router-id is taken from the 8 last octets of the address;<a href="#section-4.6.9-7.4.2.1" class="pilcrow">¶</a>
</li>
                <li class="normal" id="section-4.6.9-7.4.2.2">if the length of the address is smaller than 8 octets, then the new
  router-id consists of the required number of zero octets followed by the
  address, i.e., the address is stored on the right of the router-id.  For
  example, for an IPv4 address, the router-id consists of 4 octets of
  zeroes followed by the IPv4 address.<a href="#section-4.6.9-7.4.2.2" class="pilcrow">¶</a>
</li>
              </ul>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.9-7.5">X:</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.9-7.6">all other bits <span class="bcp14">MUST</span> be sent as 0 and silently ignored on reception.<a href="#section-4.6.9-7.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-4.6.9-8">The prefix being advertised by an Update TLV is computed as follows:<a href="#section-4.6.9-8" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.6.9-9.1">the first Omitted octets of the prefix are taken from the previous
Update TLV with the Prefix flag set and the same address encoding,
even if it was ignored due to an unknown mandatory sub-TLV; if the Omitted field is
not zero and there is no such TLV, then this Update <span class="bcp14">MUST</span> be ignored;<a href="#section-4.6.9-9.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.6.9-9.2">the next (Plen/8 - Omitted) rounded upwards octets are taken from the
Prefix field;<a href="#section-4.6.9-9.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.6.9-9.3">if Plen is not a multiple of 8, then any bits beyond Plen (i.e., the
low-order (8 - Plen MOD 8) bits of the last octet) are cleared;<a href="#section-4.6.9-9.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.6.9-9.4">the remaining octets are set to 0.<a href="#section-4.6.9-9.4" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-4.6.9-10">If the Metric field is finite, the router-id of the originating node
for this announcement is taken from the prefix advertised by this Update
if the Router-Id flag is set, computed as described above.  Otherwise, it
is taken either from the preceding Router-Id TLV, or the preceding
Update TLV with the Router-Id flag set, whichever comes last, even if
that TLV is otherwise ignored due to an unknown mandatory sub-TLV; if
there is no suitable TLV, then this update is ignored.<a href="#section-4.6.9-10" class="pilcrow">¶</a></p>
<p id="section-4.6.9-11">The next-hop address for this update is taken from the last preceding
Next Hop TLV with a matching address family (IPv4 or IPv6) in the same
packet even if it was otherwise ignored due to an unknown mandatory
sub-TLV; if no such TLV exists, it is taken from the network-layer source
address of this packet if it belongs to the same address family as the
prefix being announced; otherwise, this Update <span class="bcp14">MUST</span> be ignored.<a href="#section-4.6.9-11" class="pilcrow">¶</a></p>
<p id="section-4.6.9-12">If the metric field is FFFF hexadecimal, this TLV specifies
a retraction.  In that case, the router-id, next hop, and seqno are not
used.  AE <span class="bcp14">MAY</span> then be 0, in which case this Update retracts all of the
routes previously advertised by the sending interface.  If the metric is
finite, AE <span class="bcp14">MUST NOT</span> be 0; Update TLVs with finite metric and AE equal to
0 <span class="bcp14">MUST</span> be ignored.  If the metric is infinite and AE is 0, Plen and
Omitted <span class="bcp14">MUST</span> both be 0; Update TLVs that do not satisfy this requirement
<span class="bcp14">MUST</span> be ignored.<a href="#section-4.6.9-12" class="pilcrow">¶</a></p>
<p id="section-4.6.9-13">Update TLVs with an unknown value in the AE field <span class="bcp14">MUST</span> be silently
ignored.<a href="#section-4.6.9-13" class="pilcrow">¶</a></p>
<p id="section-4.6.9-14">This TLV is self-terminating and allows sub-TLVs.<a href="#section-4.6.9-14" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-4.6.10">
          <h4 id="name-route-request">
<a href="#section-4.6.10" class="section-number selfRef">4.6.10. </a><a href="#name-route-request" class="section-name selfRef">Route Request</a>
          </h4>
<div class="artwork art-text alignLeft" id="section-4.6.10-1">
<pre>
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type = 9   |    Length     |      AE       |     Plen      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Prefix...
+-+-+-+-+-+-+-+-+-+-+-+-
</pre><a href="#section-4.6.10-1" class="pilcrow">¶</a>
</div>
<p id="section-4.6.10-2">A Route Request TLV prompts the receiver to send an update for a given
prefix, or a full route table dump.<a href="#section-4.6.10-2" class="pilcrow">¶</a></p>
<p id="section-4.6.10-3">Fields:<a href="#section-4.6.10-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.6.10-4">
            <dt id="section-4.6.10-4.1">Type</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.10-4.2">Set to 9 to indicate a Route Request TLV.<a href="#section-4.6.10-4.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.10-4.3">Length</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.10-4.4">The length of the body in octets, exclusive of the
Type and Length fields.<a href="#section-4.6.10-4.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.10-4.5">AE</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.10-4.6">The encoding of the Prefix field.  The value 0 specifies
that this is a request for a full route table dump (a wildcard
request).<a href="#section-4.6.10-4.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.10-4.7">Plen</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.10-4.8">The length in bits of the requested prefix.<a href="#section-4.6.10-4.8" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.10-4.9">Prefix</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.10-4.10">The prefix being requested.  This field's size is
Plen/8 rounded upwards.<a href="#section-4.6.10-4.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-4.6.10-5">A Request TLV prompts the receiver to send an update message (possibly
a retraction) for the prefix specified by the AE, Plen, and Prefix fields,
or a full dump of its route table if AE is 0 (in which case Plen must be
0 and Prefix is of length 0).  A Request TLV with AE set to 0 and Plen not
set to 0 <span class="bcp14">MUST</span> be ignored.<a href="#section-4.6.10-5" class="pilcrow">¶</a></p>
<p id="section-4.6.10-6">This TLV is self-terminating and allows sub-TLVs.<a href="#section-4.6.10-6" class="pilcrow">¶</a></p>
</section>
<section id="section-4.6.11">
          <h4 id="name-seqno-request">
<a href="#section-4.6.11" class="section-number selfRef">4.6.11. </a><a href="#name-seqno-request" class="section-name selfRef">Seqno Request</a>
          </h4>
<div class="artwork art-text alignLeft" id="section-4.6.11-1">
<pre>
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type = 10  |    Length     |      AE       |    Plen       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Seqno             |  Hop Count    |   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                          Router-Id                            +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Prefix...
+-+-+-+-+-+-+-+-+-+-+
</pre><a href="#section-4.6.11-1" class="pilcrow">¶</a>
</div>
<p id="section-4.6.11-2">A Seqno Request TLV prompts the receiver to send an Update for a given
prefix with a given sequence number, or to forward the request further if
it cannot be satisfied locally.<a href="#section-4.6.11-2" class="pilcrow">¶</a></p>
<p id="section-4.6.11-3">Fields:<a href="#section-4.6.11-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.6.11-4">
            <dt id="section-4.6.11-4.1">Type</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.11-4.2">Set to 10 to indicate a Seqno Request TLV.<a href="#section-4.6.11-4.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.11-4.3">Length</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.11-4.4">The length of the body in octets, exclusive of the
Type and Length fields.<a href="#section-4.6.11-4.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.11-4.5">AE</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.11-4.6">The encoding of the Prefix field.  This <span class="bcp14">MUST NOT</span> be 0.<a href="#section-4.6.11-4.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.11-4.7">Plen</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.11-4.8">The length in bits of the requested prefix.<a href="#section-4.6.11-4.8" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.11-4.9">Seqno</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.11-4.10">The sequence number that is being requested.<a href="#section-4.6.11-4.10" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.11-4.11">Hop Count</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.11-4.12">The maximum number of times that this TLV may be
forwarded, plus 1.  This <span class="bcp14">MUST NOT</span> be 0.<a href="#section-4.6.11-4.12" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.11-4.13">Reserved</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.11-4.14">Sent as 0 and <span class="bcp14">MUST</span> be ignored on reception.<a href="#section-4.6.11-4.14" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.11-4.15">Router-Id</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.11-4.16">The Router-Id that is being requested.  This <span class="bcp14">MUST NOT</span> consist of all zeroes or all ones.<a href="#section-4.6.11-4.16" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.6.11-4.17">Prefix</dt>
            <dd style="margin-left: 5.0em" id="section-4.6.11-4.18">The prefix being requested.  This field's size is
Plen/8 rounded upwards.<a href="#section-4.6.11-4.18" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-4.6.11-5">A Seqno Request TLV prompts the receiving node to send a finite-metric
Update for the prefix specified by the AE, Plen, and Prefix fields, with
either a router-id different from what is specified by the Router-Id
field, or a Seqno no less (modulo 2<sup>16</sup>) than what is specified by the
Seqno field.  If this request cannot be satisfied locally, then it is
forwarded according to the rules set out in
 <a href="#handling-seqno-requests" class="xref">Section 3.8.1.2</a>.<a href="#section-4.6.11-5" class="pilcrow">¶</a></p>
<p id="section-4.6.11-6">While a Seqno Request <span class="bcp14">MAY</span> be sent to a multicast address, it <span class="bcp14">MUST NOT</span> be
forwarded to a multicast address and <span class="bcp14">MUST NOT</span> be forwarded to more than
one neighbour.  A request <span class="bcp14">MUST NOT</span> be forwarded if its Hop Count field is
1.<a href="#section-4.6.11-6" class="pilcrow">¶</a></p>
<p id="section-4.6.11-7">This TLV is self-terminating and allows sub-TLVs.<a href="#section-4.6.11-7" class="pilcrow">¶</a></p>
</section>
</section>
</div>
<section id="section-4.7">
        <h3 id="name-details-of-specific-sub-tlv">
<a href="#section-4.7" class="section-number selfRef">4.7. </a><a href="#name-details-of-specific-sub-tlv" class="section-name selfRef">Details of specific sub-TLVs</a>
        </h3>
<div id="pad1">
<section id="section-4.7.1">
          <h4 id="name-pad1-2">
<a href="#section-4.7.1" class="section-number selfRef">4.7.1. </a><a href="#name-pad1-2" class="section-name selfRef">Pad1</a>
          </h4>
<div class="artwork art-text alignLeft" id="section-4.7.1-1">
<pre>
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|   Type = 0    |
+-+-+-+-+-+-+-+-+
</pre><a href="#section-4.7.1-1" class="pilcrow">¶</a>
</div>
<p id="section-4.7.1-2">Fields:<a href="#section-4.7.1-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.7.1-3">
            <dt id="section-4.7.1-3.1">Type</dt>
            <dd style="margin-left: 5.0em" id="section-4.7.1-3.2">Set to 0 to indicate a Pad1 sub-TLV.<a href="#section-4.7.1-3.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-4.7.1-4">This sub-TLV is silently ignored on reception.  It is allowed within
any TLV that allows sub-TLVs.<a href="#section-4.7.1-4" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-4.7.2">
          <h4 id="name-padn-2">
<a href="#section-4.7.2" class="section-number selfRef">4.7.2. </a><a href="#name-padn-2" class="section-name selfRef">PadN</a>
          </h4>
<div class="artwork art-text alignLeft" id="section-4.7.2-1">
<pre>
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type = 1   |    Length     |      MBZ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
</pre><a href="#section-4.7.2-1" class="pilcrow">¶</a>
</div>
<p id="section-4.7.2-2">Fields:<a href="#section-4.7.2-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.7.2-3">
            <dt id="section-4.7.2-3.1">Type</dt>
            <dd style="margin-left: 5.0em" id="section-4.7.2-3.2">Set to 1 to indicate a PadN sub-TLV.<a href="#section-4.7.2-3.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.7.2-3.3">Length</dt>
            <dd style="margin-left: 5.0em" id="section-4.7.2-3.4">The length of the body in octets, exclusive of the
Type and Length fields.<a href="#section-4.7.2-3.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.7.2-3.5">MBZ</dt>
            <dd style="margin-left: 5.0em" id="section-4.7.2-3.6">Must be zero, set to 0 on transmission.<a href="#section-4.7.2-3.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-4.7.2-4">This sub-TLV is silently ignored on reception.  It is allowed within
any TLV that allows sub-TLVs.<a href="#section-4.7.2-4" class="pilcrow">¶</a></p>
</section>
</section>
</section>
</div>
<section id="section-5">
      <h2 id="name-iana-considerations">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-5-1">IANA has registered the UDP port number 6696, called "babel", for use
by the Babel protocol.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">IANA has registered the IPv6 multicast group ff02::1:6 and the
IPv4 multicast group 224.0.0.111 for use by the Babel protocol.<a href="#section-5-2" class="pilcrow">¶</a></p>
<p id="section-5-3">IANA has created a registry called "Babel TLV Types".  The allocation
policy for this registry is Specification Required <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>
for Types 0-223 and Experimental Use for Types 224-254.  The values in
this registry are as follows:<a href="#section-5-3" class="pilcrow">¶</a></p>
<table class="center" id="table-1">
        <caption><a href="#table-1" class="selfRef">Table 1</a></caption>
<thead>
          <tr>
            <th class="text-left" rowspan="1" colspan="1">Type</th>
            <th class="text-left" rowspan="1" colspan="1">Name</th>
            <th class="text-left" rowspan="1" colspan="1">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">0</td>
            <td class="text-left" rowspan="1" colspan="1">Pad1</td>
            <td class="text-left" rowspan="1" colspan="1">RFC 8966</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">1</td>
            <td class="text-left" rowspan="1" colspan="1">PadN</td>
            <td class="text-left" rowspan="1" colspan="1">RFC 8966</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">2</td>
            <td class="text-left" rowspan="1" colspan="1">Acknowledgment Request</td>
            <td class="text-left" rowspan="1" colspan="1">RFC 8966</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">3</td>
            <td class="text-left" rowspan="1" colspan="1">Acknowledgment</td>
            <td class="text-left" rowspan="1" colspan="1">RFC 8966</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">4</td>
            <td class="text-left" rowspan="1" colspan="1">Hello</td>
            <td class="text-left" rowspan="1" colspan="1">RFC 8966</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">5</td>
            <td class="text-left" rowspan="1" colspan="1">IHU</td>
            <td class="text-left" rowspan="1" colspan="1">RFC 8966</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">6</td>
            <td class="text-left" rowspan="1" colspan="1">Router-Id</td>
            <td class="text-left" rowspan="1" colspan="1">RFC 8966</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">7</td>
            <td class="text-left" rowspan="1" colspan="1">Next Hop</td>
            <td class="text-left" rowspan="1" colspan="1">RFC 8966</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">8</td>
            <td class="text-left" rowspan="1" colspan="1">Update</td>
            <td class="text-left" rowspan="1" colspan="1">RFC 8966</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">9</td>
            <td class="text-left" rowspan="1" colspan="1">Route Request</td>
            <td class="text-left" rowspan="1" colspan="1">RFC 8966</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">10</td>
            <td class="text-left" rowspan="1" colspan="1">Seqno Request</td>
            <td class="text-left" rowspan="1" colspan="1">RFC 8966</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">11</td>
            <td class="text-left" rowspan="1" colspan="1">TS/PC</td>
            <td class="text-left" rowspan="1" colspan="1">
              <span>[<a href="#RFC7298" class="xref">RFC7298</a>]</span>
</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">12</td>
            <td class="text-left" rowspan="1" colspan="1">HMAC</td>
            <td class="text-left" rowspan="1" colspan="1">
              <span>[<a href="#RFC7298" class="xref">RFC7298</a>]</span>
</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">13</td>
            <td class="text-left" rowspan="1" colspan="1">Reserved</td>
            <td class="text-left" rowspan="1" colspan="1"></td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">14</td>
            <td class="text-left" rowspan="1" colspan="1">Reserved</td>
            <td class="text-left" rowspan="1" colspan="1"></td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">15</td>
            <td class="text-left" rowspan="1" colspan="1">Reserved</td>
            <td class="text-left" rowspan="1" colspan="1"></td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">224-254</td>
            <td class="text-left" rowspan="1" colspan="1">Reserved for Experimental Use</td>
            <td class="text-left" rowspan="1" colspan="1">RFC 8966</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">255</td>
            <td class="text-left" rowspan="1" colspan="1">Reserved for expansion of the type space</td>
            <td class="text-left" rowspan="1" colspan="1">RFC 8966</td>
          </tr>
        </tbody>
      </table>
<p id="section-5-5">IANA has created a registry called "Babel Sub-TLV Types".  The allocation
policy for this registry is Specification Required for Types 0-111 and
128-239, and Experimental Use for Types 112-126 and 240-254.  The values
in this registry are as follows:<a href="#section-5-5" class="pilcrow">¶</a></p>
<table class="center" id="table-2">
        <caption><a href="#table-2" class="selfRef">Table 2</a></caption>
<thead>
          <tr>
            <th class="text-left" rowspan="1" colspan="1">Type</th>
            <th class="text-left" rowspan="1" colspan="1">Name</th>
            <th class="text-left" rowspan="1" colspan="1">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">0</td>
            <td class="text-left" rowspan="1" colspan="1">Pad1</td>
            <td class="text-left" rowspan="1" colspan="1">RFC 8966</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">1</td>
            <td class="text-left" rowspan="1" colspan="1">PadN</td>
            <td class="text-left" rowspan="1" colspan="1">RFC 8966</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">2</td>
            <td class="text-left" rowspan="1" colspan="1">Diversity</td>
            <td class="text-left" rowspan="1" colspan="1">
              <span>[<a href="#I-D.chroboczek-babel-diversity-routing" class="xref">BABEL-DIVERSITY</a>]</span>
</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">3</td>
            <td class="text-left" rowspan="1" colspan="1">Timestamp</td>
            <td class="text-left" rowspan="1" colspan="1">
              <span>[<a href="#I-D.ietf-babel-rtt-extension" class="xref">BABEL-RTT</a>]</span>
</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">4-111</td>
            <td class="text-left" rowspan="1" colspan="1">Unassigned</td>
            <td class="text-left" rowspan="1" colspan="1"></td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">112-126</td>
            <td class="text-left" rowspan="1" colspan="1">Reserved for Experimental Use</td>
            <td class="text-left" rowspan="1" colspan="1">RFC 8966</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">127</td>
            <td class="text-left" rowspan="1" colspan="1">Reserved for expansion of the type space</td>
            <td class="text-left" rowspan="1" colspan="1">RFC 8966</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">128</td>
            <td class="text-left" rowspan="1" colspan="1">Source Prefix</td>
            <td class="text-left" rowspan="1" colspan="1">
              <span>[<a href="#I-D.ietf-babel-source-specific" class="xref">BABEL-SS</a>]</span>
</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">129-239</td>
            <td class="text-left" rowspan="1" colspan="1">Unassigned</td>
            <td class="text-left" rowspan="1" colspan="1"></td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">240-254</td>
            <td class="text-left" rowspan="1" colspan="1">Reserved for Experimental Use</td>
            <td class="text-left" rowspan="1" colspan="1">RFC 8966</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">255</td>
            <td class="text-left" rowspan="1" colspan="1">Reserved for expansion of the type space</td>
            <td class="text-left" rowspan="1" colspan="1">RFC 8966</td>
          </tr>
        </tbody>
      </table>
<p id="section-5-7">IANA has created a registry called "Babel Address
Encodings".  The allocation policy for this registry is Specification
Required for Address Encodings (AEs) 0-223, and Experimental Use for AEs
224-254.  The values in this registry are as follows:<a href="#section-5-7" class="pilcrow">¶</a></p>
<table class="center" id="table-3">
        <caption><a href="#table-3" class="selfRef">Table 3</a></caption>
<thead>
          <tr>
            <th class="text-left" rowspan="1" colspan="1">AE</th>
            <th class="text-left" rowspan="1" colspan="1">Name</th>
            <th class="text-left" rowspan="1" colspan="1">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">0</td>
            <td class="text-left" rowspan="1" colspan="1">Wildcard address</td>
            <td class="text-left" rowspan="1" colspan="1">RFC 8966</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">1</td>
            <td class="text-left" rowspan="1" colspan="1">IPv4 address</td>
            <td class="text-left" rowspan="1" colspan="1">RFC 8966</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">2</td>
            <td class="text-left" rowspan="1" colspan="1">IPv6 address</td>
            <td class="text-left" rowspan="1" colspan="1">RFC 8966</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">3</td>
            <td class="text-left" rowspan="1" colspan="1">Link-local IPv6 address</td>
            <td class="text-left" rowspan="1" colspan="1">RFC 8966</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">4-223</td>
            <td class="text-left" rowspan="1" colspan="1">Unassigned</td>
            <td class="text-left" rowspan="1" colspan="1"></td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">224-254</td>
            <td class="text-left" rowspan="1" colspan="1">Reserved for Experimental Use</td>
            <td class="text-left" rowspan="1" colspan="1">RFC 8966</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">255</td>
            <td class="text-left" rowspan="1" colspan="1">Reserved for expansion of the AE space</td>
            <td class="text-left" rowspan="1" colspan="1">RFC 8966</td>
          </tr>
        </tbody>
      </table>
<p id="section-5-9">IANA has renamed the registry called "Babel Flags Values" to "Babel Update Flags Values".  The allocation policy for this registry is Specification Required.  
The values in this registry are as follows:<a href="#section-5-9" class="pilcrow">¶</a></p>
<table class="center" id="table-4">
        <caption><a href="#table-4" class="selfRef">Table 4</a></caption>
<thead>
          <tr>
            <th class="text-left" rowspan="1" colspan="1">Bit</th>
            <th class="text-left" rowspan="1" colspan="1">Name</th>
            <th class="text-left" rowspan="1" colspan="1">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">0</td>
            <td class="text-left" rowspan="1" colspan="1">Default prefix</td>
            <td class="text-left" rowspan="1" colspan="1">RFC 8966</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">1</td>
            <td class="text-left" rowspan="1" colspan="1">Default router-id</td>
            <td class="text-left" rowspan="1" colspan="1">RFC 8966</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">2-7</td>
            <td class="text-left" rowspan="1" colspan="1">Unassigned</td>
            <td class="text-left" rowspan="1" colspan="1"></td>
          </tr>
        </tbody>
      </table>
<p id="section-5-11">IANA has created a new registry called "Babel Hello Flags
Values".  The allocation policy for this registry is Specification
Required.  The initial values in this registry are as follows:<a href="#section-5-11" class="pilcrow">¶</a></p>
<table class="center" id="table-5">
        <caption><a href="#table-5" class="selfRef">Table 5</a></caption>
<thead>
          <tr>
            <th class="text-left" rowspan="1" colspan="1">Bit</th>
            <th class="text-left" rowspan="1" colspan="1">Name</th>
            <th class="text-left" rowspan="1" colspan="1">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">0</td>
            <td class="text-left" rowspan="1" colspan="1">Unicast</td>
            <td class="text-left" rowspan="1" colspan="1">RFC 8966</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">1-15</td>
            <td class="text-left" rowspan="1" colspan="1">Unassigned</td>
            <td class="text-left" rowspan="1" colspan="1"></td>
          </tr>
        </tbody>
      </table>
<p id="section-5-13">IANA has replaced all references to RFCs 6126 and 7557
in all of the registries mentioned above with references to this document.<a href="#section-5-13" class="pilcrow">¶</a></p>
</section>
<section id="section-6">
      <h2 id="name-security-considerations">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-6-1">As defined in this document, Babel is a completely insecure protocol.
Without additional security mechanisms, Babel trusts any information it
receives in plaintext UDP datagrams and acts on it.  An attacker that is
present on the local network can impact Babel operation in a variety of
ways; for example they can:<a href="#section-6-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6-2.1">spoof a Babel packet, and redirect traffic by announcing a route with
a smaller metric, a larger sequence number, or a longer prefix;<a href="#section-6-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-6-2.2">spoof a malformed packet, which could cause an insufficiently robust
implementation to crash or interfere with the rest of the network;<a href="#section-6-2.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-6-2.3">replay a previously captured Babel packet, which could cause traffic to
be redirected, black-holed, or otherwise interfere with the network.<a href="#section-6-2.3" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-6-3">
When carried over IPv6, Babel packets are ignored unless they are sent
from a link-local IPv6 address; since routers don't forward link-local
IPv6 packets, this mitigates the attacks outlined above by restricting
them to on-link attackers.  No such natural protection exists when Babel
packets are carried over IPv4, which is one of the reasons why it is
recommended to deploy Babel over IPv6
(<a href="#transmission-reception" class="xref">Section 3.1</a>).<a href="#section-6-3" class="pilcrow">¶</a></p>
<p id="section-6-4">It is usually difficult to ensure that packets arriving at a Babel node
are trusted, even in the case where the local link is believed to be
secure.  For that reason, it is <span class="bcp14">RECOMMENDED</span> that all Babel traffic be
protected by an application-layer cryptographic protocol.  There are
currently two suitable mechanisms, which implement different trade-offs
between implementation simplicity and security:<a href="#section-6-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6-5.1">Babel over DTLS <span>[<a href="#RFC8968" class="xref">RFC8968</a>]</span> runs the majority of Babel
traffic over DTLS and leverages DTLS to authenticate nodes and provide
confidentiality and integrity protection;<a href="#section-6-5.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-6-5.2">MAC authentication <span>[<a href="#RFC8967" class="xref">RFC8967</a>]</span> appends a message
authentication code (MAC) to every Babel packet to prove that it
originated at a node that knows a shared secret, and includes sufficient
additional information to prove that the packet is fresh (not replayed).<a href="#section-6-5.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-6-6">
Both mechanisms enable nodes to ignore packets generated by attackers
without the proper credentials.  They also ensure integrity of messages
and prevent message replay.  While Babel-DTLS supports asymmetric keying
and ensures confidentiality, Babel-MAC has a much more limited scope (see
Sections <a href="https://www.rfc-editor.org/rfc/rfc8967#section-1.1" class="relref">1.1</a>, 
<a href="https://www.rfc-editor.org/rfc/rfc8967#section-1.2" class="relref">1.2</a>, and 
<a href="https://www.rfc-editor.org/rfc/rfc8967#section-7" class="relref">7</a> of 
<span>[<a href="#RFC8967" class="xref">RFC8967</a>]</span>).  Since Babel-MAC
is simpler and more lightweight, it is recommended in preference to
Babel-DTLS in deployments where its limitations are acceptable, i.e., when
symmetric keying is sufficient and where the routing information is not
considered confidential.<a href="#section-6-6" class="pilcrow">¶</a></p>
<p id="section-6-7">Every implementation of Babel <span class="bcp14">SHOULD</span> implement BABEL-MAC.<a href="#section-6-7" class="pilcrow">¶</a></p>
<p id="section-6-8">One should be aware that the information that a mobile Babel node
announces to the whole routing domain is sufficient to determine the mobile
node's physical location with reasonable precision, which might cause
privacy concerns even if the control traffic is protected from
unauthenticated attackers by a cryptographic mechanism such as Babel-DTLS.
This issue may be mitigated somewhat by using randomly chosen router-ids
and randomly chosen IP addresses, and changing them often enough.<a href="#section-6-8" class="pilcrow">¶</a></p>
</section>
<section id="section-7">
      <h2 id="name-references">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-7.1">
        <h3 id="name-normative-references">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC0793">[RFC793]</dt>
        <dd>
<span class="refAuthor">Postel, J.</span>, <span class="refTitle">"Transmission Control Protocol"</span>, <span class="seriesInfo">STD 7</span>, <span class="seriesInfo">RFC 793</span>, <span class="seriesInfo">DOI 10.17487/RFC0793</span>, <time datetime="1981-09" class="refDate">September 1981</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc793">https://www.rfc-editor.org/info/rfc793</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8126">[RFC8126]</dt>
        <dd>
<span class="refAuthor">Cotton, M.</span><span class="refAuthor">, Leiba, B.</span><span class="refAuthor">, and T. Narten</span>, <span class="refTitle">"Guidelines for Writing an IANA Considerations Section in RFCs"</span>, <span class="seriesInfo">BCP 26</span>, <span class="seriesInfo">RFC 8126</span>, <span class="seriesInfo">DOI 10.17487/RFC8126</span>, <time datetime="2017-06" class="refDate">June 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8126">https://www.rfc-editor.org/info/rfc8126</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8174">[RFC8174]</dt>
        <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8967">[RFC8967]</dt>
      <dd>
<span class="refAuthor">Dô, C.</span><span class="refAuthor">, Kolodziejak, W.</span><span class="refAuthor">, and J. Chroboczek</span>, <span class="refTitle">"MAC Authentication for the Babel Routing Protocol"</span>, <span class="seriesInfo">RFC 8967</span>, <span class="seriesInfo">DOI 10.17487/RFC8967</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8967">https://www.rfc-editor.org/info/rfc8967</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-7.2">
        <h3 id="name-informative-references">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="I-D.chroboczek-babel-diversity-routing">[BABEL-DIVERSITY]</dt>
        <dd>
<span class="refAuthor">Chroboczek, J.</span>, <span class="refTitle">"Diversity Routing for the Babel Routing Protocol"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-chroboczek-babel-diversity-routing-01</span>, <time datetime="2016-02-15" class="refDate">15 February 2016</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-chroboczek-babel-diversity-routing-01">https://tools.ietf.org/html/draft-chroboczek-babel-diversity-routing-01</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-babel-rtt-extension">[BABEL-RTT]</dt>
        <dd>
<span class="refAuthor">Jonglez, B.</span><span class="refAuthor"> and J. Chroboczek</span>, <span class="refTitle">"Delay-based Metric Extension for the Babel Routing Protocol"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-babel-rtt-extension-00</span>, <time datetime="2019-04-26" class="refDate">26 April 2019</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-babel-rtt-extension-00">https://tools.ietf.org/html/draft-ietf-babel-rtt-extension-00</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-babel-source-specific">[BABEL-SS]</dt>
        <dd>
<span class="refAuthor">Boutier, M.</span><span class="refAuthor"> and J. Chroboczek</span>, <span class="refTitle">"Source-Specific Routing in Babel"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-babel-source-specific-07</span>, <time datetime="2020-10-28" class="refDate">28 October 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-babel-source-specific-07">https://tools.ietf.org/html/draft-ietf-babel-source-specific-07</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="DSDV">[DSDV]</dt>
        <dd>
<span class="refAuthor">Perkins, C.</span><span class="refAuthor"> and P. Bhagwat</span>, <span class="refTitle">"Highly dynamic Destination-Sequenced Distance-Vector routing (DSDV) for mobile computers"</span>, <span class="refContent">ACM SIGCOMM '94: Proceedings of the conference on 
           Communications architectures, protocols and applications</span>, <span class="refContent">234-244</span>, <span class="seriesInfo">DOI 10.1145/190314.190336</span>, <time datetime="1994-10" class="refDate">October 1994</time>, <span>&lt;<a href="https://doi.org/10.1145/190314.190336">https://doi.org/10.1145/190314.190336</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="DUAL">[DUAL]</dt>
        <dd>
<span class="refAuthor">Garcia Luna Aceves, J. J.</span>, <span class="refTitle">"Loop-free routing using diffusing computations"</span>, <span class="refContent">IEEE/ACM Transactions on Networking</span>, <span class="refContent">1:1</span>, <span class="seriesInfo">DOI 10.1109/90.222913</span>, <time datetime="1993-02" class="refDate">February 1993</time>, <span>&lt;<a href="https://doi.org/10.1109/90.222913">https://doi.org/10.1109/90.222913</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="EIGRP">[EIGRP]</dt>
        <dd>
<span class="refAuthor">Albrightson, B.</span><span class="refAuthor">, Garcia Luna Aceves, J. J.</span><span class="refAuthor">, and J. Boyle</span>, <span class="refTitle">"EIGRP -- a Fast Routing Protocol Based on Distance Vectors"</span>, <span class="refContent">Proc. Networld/Interop 94</span>, <time datetime="1994" class="refDate">1994</time>. </dd>
<dd class="break"></dd>
<dt id="ETX">[ETX]</dt>
        <dd>
<span class="refAuthor">De Couto, D.</span><span class="refAuthor">, Aguayo, D.</span><span class="refAuthor">, Bicket, J.</span><span class="refAuthor">, and R. Morris</span>, <span class="refTitle">"A high-throughput path metric for multi-hop wireless networks"</span>, <span class="refContent">MobiCom '03: Proceedings of the 9th annual international 
           conference on Mobile computing and networking</span>, <span class="refContent">134-146</span>, <span class="seriesInfo">DOI 10.1145/938985.939000</span>, <time datetime="2003-09" class="refDate">September 2003</time>, <span>&lt;<a href="https://doi.org/10.1145/938985.939000">https://doi.org/10.1145/938985.939000</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="IEEE802.11">[IEEE802.11]</dt>
        <dd>
<span class="refAuthor">IEEE</span>, <span class="refTitle">"IEEE Standard for Information technology--Telecommunications and information exchange between systems Local and metropolitan area networks--Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications"</span>, <span class="seriesInfo">IEEE 802.11-2012</span>, <span class="seriesInfo">DOI 10.1109/ieeestd.2012.6178212</span>, <time datetime="2012-04" class="refDate">April 2012</time>, <span>&lt;<a href="https://doi.org/10.1109/ieeestd.2012.6178212">https://doi.org/10.1109/ieeestd.2012.6178212</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="IEN137">[IEN137]</dt>
        <dd>
<span class="refAuthor">Cohen, D.</span>, <span class="refTitle">"On Holy Wars and a Plea for Peace"</span>, <span class="seriesInfo">IEN 137</span>, <time datetime="1980-04-01" class="refDate">1 April 1980</time>. </dd>
<dd class="break"></dd>
<dt id="IS-IS">[IS-IS]</dt>
        <dd>
<span class="refAuthor">International Organization for Standardization</span>, <span class="refTitle">"Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)"</span>, <span class="refContent">ISO/IEC 10589:2002</span>, <time datetime="2002" class="refDate">2002</time>. </dd>
<dd class="break"></dd>
<dt id="JITTER">[JITTER]</dt>
        <dd>
<span class="refAuthor">Floyd, S.</span><span class="refAuthor"> and V. Jacobson</span>, <span class="refTitle">"The Synchronization of Periodic Routing Messages"</span>, <span class="refContent">IEEE/ACM Transactions on Networking</span>, <span class="refContent">2, 2, 122-136</span>, <span class="seriesInfo">DOI 10.1109/90.298431</span>, <time datetime="1994-04" class="refDate">April 1994</time>, <span>&lt;<a href="https://doi.org/10.1109/90.298431">https://doi.org/10.1109/90.298431</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2328">[OSPF]</dt>
        <dd>
<span class="refAuthor">Moy, J.</span>, <span class="refTitle">"OSPF Version 2"</span>, <span class="seriesInfo">STD 54</span>, <span class="seriesInfo">RFC 2328</span>, <span class="seriesInfo">DOI 10.17487/RFC2328</span>, <time datetime="1998-04" class="refDate">April 1998</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2328">https://www.rfc-editor.org/info/rfc2328</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5444">[PACKETBB]</dt>
        <dd>
<span class="refAuthor">Clausen, T.</span><span class="refAuthor">, Dearlove, C.</span><span class="refAuthor">, Dean, J.</span><span class="refAuthor">, and C. Adjih</span>, <span class="refTitle">"Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format"</span>, <span class="seriesInfo">RFC 5444</span>, <span class="seriesInfo">DOI 10.17487/RFC5444</span>, <time datetime="2009-02" class="refDate">February 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5444">https://www.rfc-editor.org/info/rfc5444</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2675">[RFC2675]</dt>
        <dd>
<span class="refAuthor">Borman, D.</span><span class="refAuthor">, Deering, S.</span><span class="refAuthor">, and R. Hinden</span>, <span class="refTitle">"IPv6 Jumbograms"</span>, <span class="seriesInfo">RFC 2675</span>, <span class="seriesInfo">DOI 10.17487/RFC2675</span>, <time datetime="1999-08" class="refDate">August 1999</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2675">https://www.rfc-editor.org/info/rfc2675</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3561">[RFC3561]</dt>
        <dd>
<span class="refAuthor">Perkins, C.</span><span class="refAuthor">, Belding-Royer, E.</span><span class="refAuthor">, and S. Das</span>, <span class="refTitle">"Ad hoc On-Demand Distance Vector (AODV) Routing"</span>, <span class="seriesInfo">RFC 3561</span>, <span class="seriesInfo">DOI 10.17487/RFC3561</span>, <time datetime="2003-07" class="refDate">July 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3561">https://www.rfc-editor.org/info/rfc3561</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6126">[RFC6126]</dt>
        <dd>
<span class="refAuthor">Chroboczek, J.</span>, <span class="refTitle">"The Babel Routing Protocol"</span>, <span class="seriesInfo">RFC 6126</span>, <span class="seriesInfo">DOI 10.17487/RFC6126</span>, <time datetime="2011-04" class="refDate">April 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6126">https://www.rfc-editor.org/info/rfc6126</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7298">[RFC7298]</dt>
        <dd>
<span class="refAuthor">Ovsienko, D.</span>, <span class="refTitle">"Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication"</span>, <span class="seriesInfo">RFC 7298</span>, <span class="seriesInfo">DOI 10.17487/RFC7298</span>, <time datetime="2014-07" class="refDate">July 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7298">https://www.rfc-editor.org/info/rfc7298</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7557">[RFC7557]</dt>
        <dd>
<span class="refAuthor">Chroboczek, J.</span>, <span class="refTitle">"Extension Mechanism for the Babel Routing Protocol"</span>, <span class="seriesInfo">RFC 7557</span>, <span class="seriesInfo">DOI 10.17487/RFC7557</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7557">https://www.rfc-editor.org/info/rfc7557</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8968">[RFC8968]</dt>
        <dd>
<span class="refAuthor">Décimo, A.</span><span class="refAuthor">, Schinazi, D.</span><span class="refAuthor">, and J. Chroboczek</span>, <span class="refTitle">"Babel Routing Protocol over Datagram Transport Layer Security"</span>, <span class="seriesInfo">RFC 8968</span>, <span class="seriesInfo">DOI 10.17487/RFC8968</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8968">https://www.rfc-editor.org/info/rfc8968</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2453">[RIP]</dt>
      <dd>
<span class="refAuthor">Malkin, G.</span>, <span class="refTitle">"RIP Version 2"</span>, <span class="seriesInfo">STD 56</span>, <span class="seriesInfo">RFC 2453</span>, <span class="seriesInfo">DOI 10.17487/RFC2453</span>, <time datetime="1998-11" class="refDate">November 1998</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2453">https://www.rfc-editor.org/info/rfc2453</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<section id="section-appendix.a">
      <h2 id="name-cost-and-metric-computation">
<a href="#section-appendix.a" class="section-number selfRef">Appendix A. </a><a href="#name-cost-and-metric-computation" class="section-name selfRef">Cost and Metric Computation</a>
      </h2>
<p id="section-appendix.a-1">The strategy for computing link costs and route metrics is a local
matter; Babel itself only requires that it comply with the conditions given
in <a href="#cost-computation" class="xref">Section 3.4.3</a> and <a href="#metric-computation" class="xref">Section 3.5.2</a>.
Different nodes may use different strategies in a single network and may
use different strategies on different interface types.  This section describes
a set of strategies that have been found to work well in actual networks.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
<p id="section-appendix.a-2">In summary, a node maintains per-neighbour statistics about the last 16
received Hello TLVs of each kind (<a href="#hello-history" class="xref">Appendix A.1</a>),
it computes costs by using the 2-out-of-3 strategy (<a href="#k-j" class="xref">Appendix A.2.1</a>) on
wired links and Expected Transmission Cost (ETX) (<a href="#etx" class="xref">Appendix A.2.2</a>) on wireless links.  It uses an
additive algebra for metric computation (<a href="#metric-computation" class="xref">Section 3.5.2</a>).<a href="#section-appendix.a-2" class="pilcrow">¶</a></p>
<div id="hello-history">
<section id="section-a.1">
        <h2 id="name-maintaining-hello-history">
<a href="#section-a.1" class="section-number selfRef">A.1. </a><a href="#name-maintaining-hello-history" class="section-name selfRef">Maintaining Hello History</a>
        </h2>
<p id="section-a.1-1">For each neighbour, a node maintains two sets of Hello history, one for
each kind of Hello, and an expected sequence number, one for Multicast and
one for Unicast Hellos.  Each Hello history is a vector of 16 bits, where
a 1 value represents a received Hello, and a 0 value a missed Hello.  For
each kind of Hello, the expected sequence number, written ne, is the
sequence number that is expected to be carried by the next received Hello
from this neighbour.<a href="#section-a.1-1" class="pilcrow">¶</a></p>
<p id="section-a.1-2">Whenever it receives a Hello packet of a given kind from a neighbour,
a node compares the received sequence number nr for that kind of Hello
with its expected sequence number ne.  Depending on the outcome of this
comparison, one of the following actions is taken:<a href="#section-a.1-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-a.1-3.1">if the two differ by more than 16 (modulo 2<sup>16</sup>), then the sending
  node has probably rebooted and lost its sequence number; the whole
  associated neighbour table entry is flushed and a new one is created;<a href="#section-a.1-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.1-3.2">otherwise, if the received nr is smaller (modulo 2<sup>16</sup>) than the
  expected sequence number ne, then the sending node has increased its
  Hello interval without our noticing; the receiving node removes the last
  (ne - nr) entries from this neighbour's Hello history (we "undo
  history");<a href="#section-a.1-3.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.1-3.3">otherwise, if nr is larger (modulo 2<sup>16</sup>) than ne, then the sending
  node has decreased its Hello interval, and some Hellos were lost; the
  receiving node adds (nr - ne) 0 bits to the Hello history (we
  "fast-forward").<a href="#section-a.1-3.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-a.1-4">
The receiving node then appends a 1 bit to the Hello history and sets ne
to (nr + 1).  If the Interval field of the received Hello is not zero, it
resets the neighbour's hello timer to 1.5 times the advertised Interval
(the extra margin allows for delay due to jitter).<a href="#section-a.1-4" class="pilcrow">¶</a></p>
<p id="section-a.1-5">Whenever either hello timer associated with a neighbour expires, the
local node adds a 0 bit to the corresponding Hello history, and increments
the expected Hello number.  If both Hello histories are empty (they
contain 0 bits only), the neighbour entry is flushed; otherwise, the
relevant hello timer is reset to the value advertised in the last Hello of
that kind received from this neighbour (no extra margin is necessary in
this case, since jitter was already taken into account when computing the
timeout that has just expired).<a href="#section-a.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="cost-computation-examples">
<section id="section-a.2">
        <h2 id="name-cost-computation-2">
<a href="#section-a.2" class="section-number selfRef">A.2. </a><a href="#name-cost-computation-2" class="section-name selfRef">Cost Computation</a>
        </h2>
<p id="section-a.2-1">This section describes two algorithms suitable for computing costs
(<a href="#cost-computation" class="xref">Section 3.4.3</a>) based on Hello history.
<a href="#k-j" class="xref">Appendix A.2.1</a> applies to wired links and <a href="#etx" class="xref">Appendix A.2.2</a> to
wireless links.  <span class="bcp14">RECOMMENDED</span> default values of the parameters that appear
in these algorithms are given in <a href="#parameters" class="xref">Appendix B</a>.<a href="#section-a.2-1" class="pilcrow">¶</a></p>
<div id="k-j">
<section id="section-a.2.1">
          <h3 id="name-k-out-of-j">
<a href="#section-a.2.1" class="section-number selfRef">A.2.1. </a><a href="#name-k-out-of-j" class="section-name selfRef">k-out-of-j</a>
          </h3>
<p id="section-a.2.1-1">K-out-of-j link sensing is suitable for wired links that are either up,
in which case they only occasionally drop a packet, or down, in which case
they drop all packets.<a href="#section-a.2.1-1" class="pilcrow">¶</a></p>
<p id="section-a.2.1-2">The k-out-of-j strategy is parameterised by two small integers k and j,
such that 0 &lt; k &lt;= j, and the nominal link cost, a constant C &gt;= 1.
A node keeps a history of the last j hellos; if k or more of those have
been correctly received, the link is assumed to be up, and the rxcost is
set to C; otherwise, the link is assumed to be down, and the rxcost is set
to infinity.<a href="#section-a.2.1-2" class="pilcrow">¶</a></p>
<p id="section-a.2.1-3">Since Babel supports two kinds of Hellos, a Babel node performs
k-out-of-j twice for each neighbour, once on the Unicast Hello history and once on the
Multicast Hello history.  If either of the instances of k-out-of-j
indicates that the link is up, then the link is assumed to be up, and the
rxcost is set to C; if both instances indicate that the link is down, then
the link is assumed to be down, and the rxcost is set to infinity.  In
other words, the resulting rxcost is the minimum of the rxcosts yielded by
the two instances of k-out-of-j link sensing.<a href="#section-a.2.1-3" class="pilcrow">¶</a></p>
<p id="section-a.2.1-4">The cost of a link performing k-out-of-j link sensing is defined as
follows:<a href="#section-a.2.1-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-a.2.1-5.1">cost = FFFF hexadecimal if rxcost = FFFF hexadecimal;<a href="#section-a.2.1-5.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-a.2.1-5.2">cost = txcost otherwise.<a href="#section-a.2.1-5.2" class="pilcrow">¶</a>
</li>
          </ul>
</section>
</div>
<div id="etx">
<section id="section-a.2.2">
          <h3 id="name-etx">
<a href="#section-a.2.2" class="section-number selfRef">A.2.2. </a><a href="#name-etx" class="section-name selfRef">ETX</a>
          </h3>
<p id="section-a.2.2-1">Unlike wired links which are bimodal (either up or down), wireless
links exhibit continuous variation of the link quality.  Naive application
of hop-count routing in networks that use wireless links for transit tends
to select long, lossy links in preference to shorter, lossless links,
which can dramatically reduce throughput.  For that reason, a routing
protocol designed to support wireless links must perform some form of
link quality estimation.<a href="#section-a.2.2-1" class="pilcrow">¶</a></p>
<p id="section-a.2.2-2">The Expected Transmission Cost algorithm, or ETX <span>[<a href="#ETX" class="xref">ETX</a>]</span>,
is a simple link quality estimation algorithm that is designed to work
well with the IEEE 802.11 MAC <span>[<a href="#IEEE802.11" class="xref">IEEE802.11</a>]</span>.  By
default, the IEEE 802.11 MAC performs Automatic Repeat Query (ARQ)
and rate adaptation on unicast frames, but not on multicast frames, which
are sent at a fixed rate with no ARQ; therefore, measuring the loss rate
of multicast frames yields a useful estimate of a link's quality.<a href="#section-a.2.2-2" class="pilcrow">¶</a></p>
<p id="section-a.2.2-3">A node performing ETX link quality estimation uses a neighbour's
Multicast Hello history to compute an estimate, written beta, of the
probability that a Hello TLV is successfully received.  Beta can be
computed as the fraction of 1 bits within a small number (say, 6) of the
most recent entries in the Multicast Hello history, or it can be an
exponential average, or some combination of both approaches.  Let rxcost
be 256/beta.<a href="#section-a.2.2-3" class="pilcrow">¶</a></p>
<p id="section-a.2.2-4">Let alpha be MIN(1, 256/txcost), an estimate of the probability of
successfully sending a Hello TLV.  The cost is then computed by<a href="#section-a.2.2-4" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-a.2.2-5">cost = 256/(alpha * beta)<a href="#section-a.2.2-5" class="pilcrow">¶</a></p>
<p id="section-a.2.2-6">
or, equivalently,<a href="#section-a.2.2-6" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-a.2.2-7">cost = (MAX(txcost, 256) * rxcost) / 256.<a href="#section-a.2.2-7" class="pilcrow">¶</a></p>
<p id="section-a.2.2-8">Since the IEEE 802.11 MAC performs ARQ on unicast frames, unicast
frames do not provide a useful measure of link quality, and therefore ETX
ignores the Unicast Hello history.  Thus, a node performing ETX
link quality estimation will not route through neighbouring nodes unless
they send periodic Multicast Hellos (possibly in addition to Unicast
Hellos).<a href="#section-a.2.2-8" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="route-selection-hysteresis">
<section id="section-a.3">
        <h2 id="name-route-selection-and-hystere">
<a href="#section-a.3" class="section-number selfRef">A.3. </a><a href="#name-route-selection-and-hystere" class="section-name selfRef">Route Selection and Hysteresis</a>
        </h2>
<p id="section-a.3-1">Route selection (<a href="#route-selection" class="xref">Section 3.6</a>) is the process by
which a node selects a single route among the routes that it has available
towards a given destination.  With Babel, any route selection procedure
that only ever chooses feasible routes with a finite metric will yield
a set of loop-free routes; however, in the presence of continuously
variable metrics such as ETX (<a href="#etx" class="xref">Appendix A.2.2</a>), a naive route
selection procedure might lead to persistent oscillations.  Such
oscillations can be limited or avoided altogether by implementing
hysteresis within the route selection algorithm, i.e., by making the route
selection algorithm sensitive to a route's history.  Any reasonable
hysteresis algorithm should yield good results; the following algorithm
is simple to implement and has been successfully deployed in a variety of
environments.<a href="#section-a.3-1" class="pilcrow">¶</a></p>
<p id="section-a.3-2">For every route R, in addition to the route's metric m(R), maintain
a smoothed version of m(R) written ms(R) (we RECOMMEND computing ms(R) as an
exponentially smoothed average (see <span><a href="https://www.rfc-editor.org/rfc/rfc793#section-3.7" class="relref">Section 3.7</a> of [<a href="#RFC0793" class="xref">RFC793</a>]</span>)
of m(R) with a time constant equal to the Hello interval multiplied by
a small number such as 3).  If no route to a given destination is selected,
then select the route with the smallest metric, ignoring the smoothed
metric.  If a route R is selected, then switch to a route R' only when
both m(R') &lt; m(R) and ms(R') &lt; ms(R).<a href="#section-a.3-2" class="pilcrow">¶</a></p>
<p id="section-a.3-3">Intuitively, the smoothed metric is a long-term estimate of the quality
of a route.  The algorithm above works by only switching routes when both
the instantaneous and the long-term estimates of the route's quality
indicate that switching is profitable.<a href="#section-a.3-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
<div id="parameters">
<section id="section-appendix.b">
      <h2 id="name-protocol-parameters">
<a href="#section-appendix.b" class="section-number selfRef">Appendix B. </a><a href="#name-protocol-parameters" class="section-name selfRef">Protocol Parameters</a>
      </h2>
<p id="section-appendix.b-1">The choice of time constants is a trade-off between fast detection of
mobility events and protocol overhead.  Two instances of Babel running
with different time constants will interoperate, although the resulting
worst-case convergence time will be dictated by the slower of the two.<a href="#section-appendix.b-1" class="pilcrow">¶</a></p>
<p id="section-appendix.b-2">The Hello interval is the most important time constant: an outage or
a mobility event is detected within 1.5 to 3.5 Hello intervals.  Due to
Babel's use of a redundant route table, and due to its reliance on
triggered updates and explicit requests, the Update interval has little
influence on the time needed to reconverge after an outage: in practice,
it only has a significant effect on the time needed to acquire new routes
after a mobility event.  While the protocol allows intervals as low as
10 ms, such low values would cause significant amounts of protocol traffic
for little practical benefit.<a href="#section-appendix.b-2" class="pilcrow">¶</a></p>
<p id="section-appendix.b-3">The following values have been found to work well in a variety of
environments and are therefore <span class="bcp14">RECOMMENDED</span> default values:<a href="#section-appendix.b-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-appendix.b-4">
        <dt id="section-appendix.b-4.1">Multicast Hello interval:</dt>
        <dd style="margin-left: 5.0em" id="section-appendix.b-4.2">4 seconds.<a href="#section-appendix.b-4.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-appendix.b-4.3">Unicast Hello interval:</dt>
        <dd style="margin-left: 5.0em" id="section-appendix.b-4.4">infinite (no Unicast Hellos are sent).<a href="#section-appendix.b-4.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-appendix.b-4.5">Link cost:</dt>
        <dd style="margin-left: 5.0em" id="section-appendix.b-4.6">estimated using ETX on wireless links; 2-out-of-3 with C=96
on wired links.<a href="#section-appendix.b-4.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-appendix.b-4.7">IHU interval:</dt>
        <dd style="margin-left: 5.0em" id="section-appendix.b-4.8">the advertised IHU interval is always 3 times the
Multicast Hello interval.  IHUs are actually sent with each Hello on lossy
links (as determined from the Hello history), but only with every third
Multicast Hello on lossless links.<a href="#section-appendix.b-4.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-appendix.b-4.9">Update interval:</dt>
        <dd style="margin-left: 5.0em" id="section-appendix.b-4.10">4 times the Multicast Hello interval.<a href="#section-appendix.b-4.10" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-appendix.b-4.11">IHU Hold time:</dt>
        <dd style="margin-left: 5.0em" id="section-appendix.b-4.12">3.5 times the advertised IHU interval.<a href="#section-appendix.b-4.12" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-appendix.b-4.13">Route Expiry time:</dt>
        <dd style="margin-left: 5.0em" id="section-appendix.b-4.14">3.5 times the advertised update interval.<a href="#section-appendix.b-4.14" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-appendix.b-4.15">Request timeout:</dt>
        <dd style="margin-left: 5.0em" id="section-appendix.b-4.16">initially 2 seconds, doubled every time a request is
resent, up to a maximum of three times.<a href="#section-appendix.b-4.16" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-appendix.b-4.17">Urgent timeout:</dt>
        <dd style="margin-left: 5.0em" id="section-appendix.b-4.18">0.2 seconds.<a href="#section-appendix.b-4.18" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-appendix.b-4.19">Source GC time:</dt>
        <dd style="margin-left: 5.0em" id="section-appendix.b-4.20">3 minutes.<a href="#section-appendix.b-4.20" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
</section>
</div>
<div id="filtering">
<section id="section-appendix.c">
      <h2 id="name-route-filtering">
<a href="#section-appendix.c" class="section-number selfRef">Appendix C. </a><a href="#name-route-filtering" class="section-name selfRef">Route Filtering</a>
      </h2>
<p id="section-appendix.c-1">Route filtering is a procedure where an instance of a routing protocol
either discards some of the routes announced by its neighbours or learns
them with a metric that is higher than what would be expected.  Like all
distance-vector protocols, Babel has the ability to apply arbitrary
filtering to the routes it learns, and implementations of Babel that apply
different sets of filtering rules will interoperate without causing
routing loops.  The protocol's ability to perform route filtering is
a consequence of the latitude given in <a href="#metric-computation" class="xref">Section 3.5.2</a>:
Babel can use any metric that is strictly monotonic, including one that
assigns an infinite metric to a selected subset of routes.  (See also
<a href="#handling-requests" class="xref">Section 3.8.1</a>, where requests for nonexistent routes
are treated in the same way as requests for routes with infinite metric.)<a href="#section-appendix.c-1" class="pilcrow">¶</a></p>
<p id="section-appendix.c-2">It is not in general correct to learn a route with a metric smaller
than the one it was announced with, or to replace a route's destination
prefix with a more specific (longer) one.  Doing either of these may cause
persistent routing loops.<a href="#section-appendix.c-2" class="pilcrow">¶</a></p>
<p id="section-appendix.c-3">Route filtering is a useful tool, since it allows fine-grained tuning
of the routing decisions made by the routing protocol.  Accordingly, some
implementations of Babel implement a rich configuration language that
allows applying filtering to sets of routes defined, for example, by
incoming interface and destination prefix.<a href="#section-appendix.c-3" class="pilcrow">¶</a></p>
<p id="section-appendix.c-4">In order to limit the consequences of misconfiguration, Babel
implementations provide a reasonable set of default filtering rules even
when they don't allow configuration of filtering by the user.  At
a minimum, they discard routes with a destination prefix in fe80::/64,
ff00::/8, 127.0.0.1/32, 0.0.0.0/32, and 224.0.0.0/8.<a href="#section-appendix.c-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="extensions">
<section id="section-appendix.d">
      <h2 id="name-considerations-for-protocol">
<a href="#section-appendix.d" class="section-number selfRef">Appendix D. </a><a href="#name-considerations-for-protocol" class="section-name selfRef">Considerations for Protocol Extensions</a>
      </h2>
<p id="section-appendix.d-1">Babel is an extensible protocol, and this document defines a number of
mechanisms that can be used to extend the protocol in a backwards
compatible manner:<a href="#section-appendix.d-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-appendix.d-2.1">increasing the version number in the packet header;<a href="#section-appendix.d-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-appendix.d-2.2">defining new TLVs;<a href="#section-appendix.d-2.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-appendix.d-2.3">defining new sub-TLVs (with or without the mandatory bit set);<a href="#section-appendix.d-2.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-appendix.d-2.4">defining new AEs;<a href="#section-appendix.d-2.4" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-appendix.d-2.5">using the packet trailer.<a href="#section-appendix.d-2.5" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-appendix.d-3">This appendix is intended to guide designers of protocol extensions in
choosing a particular encoding.<a href="#section-appendix.d-3" class="pilcrow">¶</a></p>
<p id="section-appendix.d-4">The version number in the Babel header should only be increased if the
new version is not backwards compatible with the original protocol.<a href="#section-appendix.d-4" class="pilcrow">¶</a></p>
<p id="section-appendix.d-5">In many cases, an extension could be implemented either by defining
a new TLV or by adding a new sub-TLV to an existing TLV.  For example, an
extension whose purpose is to attach additional data to route updates can
be implemented either by creating a new "enriched" Update TLV, by adding
a nonmandatory sub-TLV to the Update TLV, or by adding a mandatory
sub-TLV.<a href="#section-appendix.d-5" class="pilcrow">¶</a></p>
<p id="section-appendix.d-6">The various encodings are treated differently by implementations that
do not understand the extension.  In the case of a new TLV or of a sub-TLV
with the mandatory bit set, the whole TLV is ignored by implementations
that do not implement the extension, while in the case of a nonmandatory
sub-TLV, the TLV is parsed and acted upon, and only the unknown sub-TLV is
silently ignored.  Therefore, a nonmandatory sub-TLV should be used by
extensions that extend the Update in a compatible manner (the extension
data may be silently ignored), while a mandatory sub-TLV or a new TLV must
be used by extensions that make incompatible extensions to the meaning of
the TLV (the whole TLV must be thrown away if the extension data is not
understood).<a href="#section-appendix.d-6" class="pilcrow">¶</a></p>
<p id="section-appendix.d-7">Experience shows that the need for additional data tends to crop up in
the most unexpected places.  Hence, it is recommended that extensions that
define new TLVs should make them self-terminating and allow attaching
sub-TLVs to them.<a href="#section-appendix.d-7" class="pilcrow">¶</a></p>
<p id="section-appendix.d-8">Adding a new AE is essentially equivalent to adding a new TLV: Update
TLVs with an unknown AE are ignored, just like unknown TLVs.  However,
adding a new AE is more involved than adding a new TLV, since it creates
a new set of compression state.  Additionally, since the Next Hop TLV
creates state specific to a given address family, as opposed to a given
AE, a new AE for a previously defined address family must not be used in
the Next Hop TLV if backwards compatibility is required.  A similar issue
arises with Update TLVs with unknown AEs establishing a new router-id (due
to the Router-Id flag being set).  Therefore, defining new AEs must be
done with care if compatibility with unextended implementations is
required.<a href="#section-appendix.d-8" class="pilcrow">¶</a></p>
<p id="section-appendix.d-9">The packet trailer is intended to carry cryptographic signatures that
only cover the packet body; storing the cryptographic signatures in the
packet trailer avoids clearing the signature before computing a hash of
the packet body, and makes it possible to check a cryptographic signature
before running the full, stateful TLV parser.  Hence, only TLVs that don't
need to be protected by cryptographic security protocols should be allowed
in the packet trailer.  Any such TLVs should be easy to parse and, in
particular, should not require stateful parsing.<a href="#section-appendix.d-9" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-appendix.e">
      <h2 id="name-stub-implementations">
<a href="#section-appendix.e" class="section-number selfRef">Appendix E. </a><a href="#name-stub-implementations" class="section-name selfRef">Stub Implementations</a>
      </h2>
<p id="section-appendix.e-1">Babel is a fairly economic protocol.  Updates take between 12 and 40
octets per destination, depending on the address family and how successful
compression is; in a dual-stack flat network, an average of less than 24
octets per update is typical.  The route table occupies about 35 octets
per IPv6 entry.  To put these values into perspective, a single full-size
Ethernet frame can carry some 65 route updates, and a megabyte of memory
can contain a 20,000-entry route table and the associated source table.<a href="#section-appendix.e-1" class="pilcrow">¶</a></p>
<p id="section-appendix.e-2">Babel is also a reasonably simple protocol.  One complete implementation
consists of less than 12,000 lines of C code, and it compiles to less
than 120 KB of text on a 32-bit CISC architecture; about half of this
figure is due to protocol extensions and user-interface code.<a href="#section-appendix.e-2" class="pilcrow">¶</a></p>
<p id="section-appendix.e-3">Nonetheless, in some very constrained environments, such as PDAs,
microwave ovens, or abacuses, it may be desirable to have subset
implementations of the protocol.<a href="#section-appendix.e-3" class="pilcrow">¶</a></p>
<p id="section-appendix.e-4">There are many different definitions of a stub router, but for the
needs of this section, a stub implementation of Babel is one that announces
one or more directly attached prefixes into a Babel network but doesn't
re-announce any routes that it has learnt from its neighbours, and always
prefers the direct route to a directly attached prefix to a route learnt
over the Babel protocol, even when the prefixes are the same.  It may
either maintain a full routing table or simply select a default gateway
through any one of its neighbours that announces a default route.  Since
a stub implementation never forwards packets except from or to a directly
attached link, it cannot possibly participate in a routing loop, and hence
it need not evaluate the feasibility condition or maintain a source
table.<a href="#section-appendix.e-4" class="pilcrow">¶</a></p>
<p id="section-appendix.e-5">No matter how primitive, a stub implementation must parse sub-TLVs
attached to any TLVs that it understands and check the mandatory bit.
It must answer acknowledgment requests and must participate in the
Hello/IHU protocol.  It must also be able to reply to seqno requests for
routes that it announces, and it should be able to reply to route
requests.<a href="#section-appendix.e-5" class="pilcrow">¶</a></p>
<p id="section-appendix.e-6">Experience shows that an IPv6-only stub implementation of Babel can be
written in less than 1,000 lines of C code and compile to 13 KB of
text on 32-bit CISC architecture.<a href="#section-appendix.e-6" class="pilcrow">¶</a></p>
</section>
<section id="section-appendix.f">
      <h2 id="name-compatibility-with-previous">
<a href="#section-appendix.f" class="section-number selfRef">Appendix F. </a><a href="#name-compatibility-with-previous" class="section-name selfRef">Compatibility with Previous Versions</a>
      </h2>
<p id="section-appendix.f-1">The protocol defined in this document is a successor to the protocol
defined in <span>[<a href="#RFC6126" class="xref">RFC6126</a>]</span> and <span>[<a href="#RFC7557" class="xref">RFC7557</a>]</span>.  While
the two protocols are not entirely compatible, the new protocol has been
designed so that it can be deployed in existing RFC 6126 networks without
requiring a flag day.<a href="#section-appendix.f-1" class="pilcrow">¶</a></p>
<p id="section-appendix.f-2">There are three optional features that make this protocol
incompatible with its predecessor.  First of all, RFC 6126 did not define
Unicast Hellos (<a href="#reverse-reachability" class="xref">Section 3.4.1</a>), and an
implementation of RFC 6126 will misinterpret a Unicast Hello for
a Multicast one; since the sequence number space of Unicast Hellos is
distinct from the sequence number space of Multicast Hellos, sending a Unicast
Hello to an implementation of RFC 6126 will confuse its link quality
estimator.  Second, RFC 6126 did not define unscheduled Hellos, and an
implementation of RFC 6126 will mis-parse Hellos with an interval equal to
0.  Finally, RFC 7557 did not define mandatory sub-TLVs 
(<a href="#sub-tlv-format" class="xref">Section 4.4</a>), and thus an implementation of RFCs 6126 and
7557 will not correctly ignore a TLV that carries an unknown mandatory
sub-TLV; depending on the sub-TLV, this might cause routing pathologies.<a href="#section-appendix.f-2" class="pilcrow">¶</a></p>
<p id="section-appendix.f-3">An implementation of this specification that never sends Unicast or
unscheduled Hellos and doesn't implement any extensions that use mandatory
sub-TLVs is safe to deploy in a network in which some nodes implement the
protocol described in RFCs 6126 and 7557.<a href="#section-appendix.f-3" class="pilcrow">¶</a></p>
<p id="section-appendix.f-4">Two changes need to be made to an implementation of RFCs 6126 and 7557
so that it can safely interoperate in all cases with implementations of
this protocol.  First, it needs to be modified either to ignore or to process
Unicast and unscheduled Hellos.  Second, it needs to be modified to parse
sub-TLVs of all the TLVs that it understands and that allow sub-TLVs, and
to ignore the TLV if an unknown mandatory sub-TLV is found.  It is not
necessary to parse unknown TLVs, as these are ignored in any case.<a href="#section-appendix.f-4" class="pilcrow">¶</a></p>
<p id="section-appendix.f-5">There are other changes, but these are not of a nature to prevent
interoperability:<a href="#section-appendix.f-5" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-appendix.f-6.1">the conditions on route acquisition (<a href="#route-acquisition" class="xref">Section 3.5.3</a>)
have been relaxed;<a href="#section-appendix.f-6.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-appendix.f-6.2">route selection should no longer use the route's sequence number
(<a href="#route-selection" class="xref">Section 3.6</a>);<a href="#section-appendix.f-6.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-appendix.f-6.3">the format of the packet trailer has been defined
(<a href="#packet-format" class="xref">Section 4.2</a>);<a href="#section-appendix.f-6.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-appendix.f-6.4">router-ids with a value of all-zeros or all-ones have been forbidden
(<a href="#router-id-def" class="xref">Section 4.1.3</a>);<a href="#section-appendix.f-6.4" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-appendix.f-6.5">the compression state is now specific to an address family rather than
an address encoding (<a href="#parser-state" class="xref">Section 4.5</a>);<a href="#section-appendix.f-6.5" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-appendix.f-6.6">packet pacing is now recommended
(<a href="#transmission-reception" class="xref">Section 3.1</a>).<a href="#section-appendix.f-6.6" class="pilcrow">¶</a>
</li>
      </ul>
</section>
<section id="section-appendix.g">
      <h2 id="name-acknowledgments">
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
      </h2>
<p id="section-appendix.g-1">A number of people have contributed text and ideas to this
specification.  The authors are particularly indebted to <span class="contact-name">Matthieu Boutier</span>,
<span class="contact-name">Gwendoline Chouasne</span>, <span class="contact-name">Margaret Cullen</span>, 
<span class="contact-name">Donald Eastlake</span>, <span class="contact-name">Toke Høiland-Jørgensen</span>, 
<span class="contact-name">Benjamin Kaduk</span>, <span class="contact-name">Joao Sobrinho</span>, and 
<span class="contact-name">Martin Vigoureux</span>.
The previous version of this specification <span>[<a href="#RFC6126" class="xref">RFC6126</a>]</span>  
greatly benefited from the input of <span class="contact-name">Joel Halpern</span>.  The address compression
technique was inspired by <span>[<a href="#RFC5444" class="xref">PACKETBB</a>]</span>.<a href="#section-appendix.g-1" class="pilcrow">¶</a></p>
</section>
<div id="authors-addresses">
<section id="section-appendix.h">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Juliusz Chroboczek</span></div>
<div dir="auto" class="left"><span class="org">IRIF, University of Paris-Diderot</span></div>
<div dir="auto" class="left"><span class="street-address">Case 7014</span></div>
<div dir="auto" class="left">
<span class="postal-code">75205</span> <span class="locality">Paris CEDEX 13</span>
</div>
<div dir="auto" class="left"><span class="country-name">France</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:jch@irif.fr" class="email">jch@irif.fr</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">David Schinazi</span></div>
<div dir="auto" class="left"><span class="org">Google LLC</span></div>
<div dir="auto" class="left"><span class="street-address">1600 Amphitheatre Parkway</span></div>
<div dir="auto" class="left">
<span class="locality">Mountain View</span>, <span class="region">California</span> <span class="postal-code">94043</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:dschinazi.ietf@gmail.com" class="email">dschinazi.ietf@gmail.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>