rfc8965xml2.original.xml   rfc8965.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" number="8965" do
<?rfc toc="yes"?> cName="draft-ietf-babel-applicability-10" ipr="trust200902" obsoletes="" updates
<?rfc tocdepth="2"?> ="" submissionType="IETF" consensus="true" xml:lang="en" tocInclude="true" tocDe
<?rfc symrefs="yes"?> pth="2" symRefs="true" sortRefs="true" version="3">
<?rfc sortrefs="yes" ?> <!-- xml2rfc v2v3 conversion 3.0.0 -->
<?rfc compact="no" ?> <front>
<rfc category="info" docName="draft-ietf-babel-applicability-10" <title abbrev="Babel Protocol Applicability">Applicability of the Babel
ipr="trust200902"> Routing Protocol</title>
<front> <seriesInfo name="RFC" value="8965"/>
<title abbrev="Babel Protocol Applicability">Applicability of the Babel <author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek">
routing protocol</title> <organization>IRIF, University of Paris-Diderot</organization>
<author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek"> <address>
<organization>IRIF, University of Paris-Diderot</organization> <postal>
<address> <street>Case 7014</street>
<postal> <city>Paris CEDEX 13</city>
<street>Case 7014</street> <region/>
<city>75205 Paris Cedex 13</city> <code>75205</code>
<region></region> <country>France</country>
<code></code> </postal>
<country>France</country> <email>jch@irif.fr</email>
</postal> </address>
<email>jch@irif.fr</email> </author>
</address> <date month="January" year="2021"/>
</author>
<date day="17" month="August" year="2019"/> <keyword>distance-vector</keyword>
<keyword>loop</keyword>
<keyword>starvation</keyword>
<keyword>Bellman-Ford</keyword>
<keyword>routing</keyword>
<keyword>routing protocol</keyword>
<keyword>wireless</keyword>
<keyword>mesh network</keyword>
<keyword>IGP</keyword>
<abstract> <abstract>
<t>Babel is a routing protocol based on the distance-vector algorithm <t>Babel is a routing protocol based on the distance-vector algorithm
augmented with mechanisms for loop avoidance and starvation avoidance. augmented with mechanisms for loop avoidance and starvation avoidance.
This document describes a number of niches where Babel has been found This document describes a number of niches where Babel has been found
to be useful and that are arguably not adequately served by more mature to be useful and that are arguably not adequately served by more mature
protocols.</t> protocols.</t>
</abstract> </abstract>
</front>
</front> <middle>
<section numbered="true" toc="default">
<middle> <name>Introduction and Background</name>
<t>Babel <xref target="RFC8966" format="default"/> is a routing protocol b
<section title="Introduction and background"> ased on the
<t>Babel <xref target="RFC6126bis"/> is a routing protocol based on the
familiar distance-vector algorithm (sometimes known as distributed familiar distance-vector algorithm (sometimes known as distributed
Bellman-Ford) augmented with mechanisms for loop avoidance (there is no Bellman-Ford) augmented with mechanisms for loop avoidance (there is no
"counting to infinity") and starvation avoidance. This document describes "counting to infinity") and starvation avoidance. This document describes
a number of niches where Babel is useful and that are arguably not a number of niches where Babel is useful and that are arguably not
adequately served by more mature protocols such as OSPF <xref adequately served by more mature protocols such as OSPF <xref target="RFC5340" f
target="RFC5340"/> and IS-IS <xref target="RFC1195"/>.</t> ormat="default"/> and IS-IS <xref target="RFC1195" format="default"/>.</t>
<section numbered="true" toc="default">
<section title="Technical overview of the Babel protocol"> <name>Technical Overview of the Babel Protocol</name>
<t>At its core, Babel is a distance-vector protocol based on the
<t>At its core, Babel is a distance-vector protocol based on the
distributed Bellman-Ford algorithm, similar in principle to RIP distributed Bellman-Ford algorithm, similar in principle to RIP
<xref target="RFC2453"/>, but with two important extensions: provisions for <xref target="RFC2453" format="default"/> but with two important extensions: pro
sensing of neighbour reachability, bidirectional reachability and link visions for
sensing of neighbour reachability, bidirectional reachability, and link
quality, and support for multiple address families (e.g., IPv6 and IPv4) quality, and support for multiple address families (e.g., IPv6 and IPv4)
in a single protocol instance.</t> in a single protocol instance.</t>
<t>Algorithms of this class are simple to understand and simple to
<t>Algorithms of this class are simple to understand and simple to implement, but unfortunately they do not work very well -- they
implement, but unfortunately they do not work very well &mdash; they
suffer from "counting to infinity", a case of pathologically slow suffer from "counting to infinity", a case of pathologically slow
convergence in some topologies after a link failure. Babel uses a mechanism convergence in some topologies after a link failure. Babel uses a mechanism
pioneered by EIGRP <xref target="DUAL"/> <xref target="RFC7868"/>, known pioneered by the Enhanced Interior Gateway Routing Protocol (EIGRP) <xref target ="DUAL" format="default"/> <xref target="RFC7868" format="default"/>, known
as "feasibility", which avoids routing loops and therefore makes counting as "feasibility", which avoids routing loops and therefore makes counting
to infinity impossible.</t> to infinity impossible.</t>
<t>Feasibility is a conservative mechanism, one that not only avoids all
<t>Feasibility is a conservative mechanism, one that not only avoids all
looping routes but also rejects some loop-free routes. Thus, it can lead looping routes but also rejects some loop-free routes. Thus, it can lead
to a situation known as "starvation", where a router rejects all routes to to a situation known as "starvation", where a router rejects all routes to
a given destination, even those that are loop-free. In order to recover a given destination, even those that are loop-free. In order to recover
from starvation, Babel uses a mechanism pioneered by the from starvation, Babel uses a mechanism pioneered by the
Destination-Sequenced Distance-Vector Routing Protocol (DSDV) Destination-Sequenced Distance-Vector Routing Protocol (DSDV)
<xref target="DSDV"/> and known as "sequenced routes". In Babel, this <xref target="DSDV" format="default"/> and known as "sequenced routes". In Babe l, this
mechanism is generalised to deal with prefixes of arbitrary length and mechanism is generalised to deal with prefixes of arbitrary length and
routes announced at multiple points in a single routing domain (DSDV was routes announced at multiple points in a single routing domain (DSDV was
a pure mesh protocol, and only carried host routes).</t> a pure mesh protocol, and only carried host routes).</t>
<t>In DSDV, the sequenced routes algorithm is slow to react to
<t>In DSDV, the sequenced routes algorithm is slow to react to
a starvation episode. In Babel, starvation recovery is accelerated by a starvation episode. In Babel, starvation recovery is accelerated by
using explicit requests (known as "seqno requests" in the protocol) that using explicit requests (known as "seqno requests" in the protocol) that
signal a starvation episode and cause a new sequenced route to be signal a starvation episode and cause a new sequenced route to be
propagated in a timely manner. In the absence of packet loss, this propagated in a timely manner. In the absence of packet loss, this
mechanism is provably complete and clears the starvation in time mechanism is provably complete and clears the starvation in time
proportional to the diameter of the network, at the cost of some proportional to the diameter of the network, at the cost of some
additional signalling traffic.</t> additional signalling traffic.</t>
</section>
</section> </section>
<section numbered="true" toc="default">
</section> <name>Properties of the Babel Protocol</name>
<t>This section describes the properties of the Babel protocol as well as
<section title="Properties of the Babel protocol">
<t>This section describes the properties of the Babel protocol as well as
its known limitations.</t> its known limitations.</t>
<section numbered="true" toc="default">
<section title="Simplicity and implementability"> <name>Simplicity and Implementability</name>
<t>Babel is a conceptually simple protocol. It consists of a familiar
<t>Babel is a conceptually simple protocol. It consists of a familiar
algorithm (distributed Bellman-Ford) augmented with three simple and algorithm (distributed Bellman-Ford) augmented with three simple and
well-defined mechanisms (feasibility, sequenced routes and explicit well-defined mechanisms (feasibility, sequenced routes, and explicit
requests). Given a sufficiently friendly audience, the principles behind requests). Given a sufficiently friendly audience, the principles behind
Babel can be explained in 15 minutes, and a full description of the Babel can be explained in 15 minutes, and a full description of the
protocol can be done in 52 minutes (one microcentury).</t> protocol can be done in 52 minutes (one microcentury).</t>
<t>An important consequence is that Babel is easy to implement. At the
<t>An important consequence is that Babel is easy to implement. At the
time of writing, there exist four independent, interoperable implementations, time of writing, there exist four independent, interoperable implementations,
including one that was reportedly written and debugged in just two nights.</t> including one that was reportedly written and debugged in just two nights.</t>
</section>
</section> <section numbered="true" toc="default">
<name>Robustness</name>
<section title="Robustness"> <t>The fairly strong properties of the Babel protocol (convergence, loop
avoidance, and starvation avoidance) rely on some reasonably weak properties
<t>The fairly strong properties of the Babel protocol (convergence, loop
avoidance, starvation avoidance) rely on some reasonably weak properties
of the network and the metric being used. The most significant are: of the network and the metric being used. The most significant are:
<list style="symbols"> </t> <ul empty="true"><li>
<t>causality: the "happens-before" relation is acyclic (intuitively, <dl spacing="normal">
a control message is not received before it has been sent);</t> <dt>causality:</dt><dd>the "happens-before" relation is acyclic (intui
<t>strict monotonicity of the metric: for any metric M and link cost&nbsp;C, tively,
M&nbsp;&lt;&nbsp;C&nbsp;+&nbsp;M (intuitively, this implies that cycles a control message is not received before it has been sent);</dd>
have a strictly positive metric);</t> <dt>strict monotonicity of the metric:</dt><dd>for any metric M and li
<t>left-distributivity of the metric: for any metrics M and M' nk cost C,
and cost&nbsp;C, if M&nbsp;&le;&nbsp;M', then M &lt; C + M (intuitively, this implies that cycles
C&nbsp;+&nbsp;M&nbsp;&le;&nbsp;C&nbsp;+&nbsp;M' (intuitively, this implies have a strictly positive metric);</dd>
<dt>left-distributivity of the metric:</dt><dd>for any metrics M and M
'
and cost C, if M &lt;= M', then
C + M &lt;= C + M' (intuitively, this implies
that a good choice made by a neighbour B of a node A is also a good choice that a good choice made by a neighbour B of a node A is also a good choice
for A).</t> for A).</dd>
</list> </dl>
See <xref target="METAROUTING"/> for more information about these </li>
</ul>
<t>
See <xref target="METAROUTING" format="default"/> for more information about the
se
properties and their consequences.</t> properties and their consequences.</t>
<t>In particular, Babel does not assume a reliable transport, it does no
<t>In particular, Babel does not assume a reliable transport, it does not t
assume ordered delivery, it does not assume that communication is assume ordered delivery, it does not assume that communication is
transitive, and it does not require that the metric be discrete transitive, and it does not require that the metric be discrete
(continuous metrics are possible, reflecting for example packet loss (continuous metrics are possible, for example, reflecting packet loss
rates). This is in contrast to link-state routing protocols such as OSPF rates). This is in contrast to link-state routing protocols such as OSPF
<xref target="RFC5340"/> or IS-IS <xref target="RFC1195"/>, which <xref target="RFC5340" format="default"/> or IS-IS <xref target="RFC1195" format ="default"/>, which
incorporate a reliable flooding algorithm and make stronger requirements incorporate a reliable flooding algorithm and make stronger requirements
on the underlying network and metric.</t> on the underlying network and metric.</t>
<t>These weak requirements make Babel a robust protocol:
<t>These weak requirements make Babel a robust protocol: </t>
<list style="symbols"> <ul empty="true"><li>
<t>robust with respect to unusual networks: an unusual network <dl spacing="normal">
<dt>robust with respect to unusual networks:</dt><dd>an unusual networ
k
(non-transitive links, unstable link costs, etc.) is likely not (non-transitive links, unstable link costs, etc.) is likely not
to violate the assumptions of the protocol;</t> to violate the assumptions of the protocol;</dd>
<t>robust with respect to novel metrics: an unusual metric (continuous, <dt>robust with respect to novel metrics:</dt><dd>an unusual metric (c
ontinuous,
constantly fluctuating, etc.) is likely not to violate the assumptions of constantly fluctuating, etc.) is likely not to violate the assumptions of
the protocol.</t> the protocol.</dd></dl></li>
</list> </ul>
<xref target="successful"/> below gives examples of successful deployments <t>
<xref target="successful" format="default"/> gives examples of successful deploy
ments
of Babel that illustrate these properties.</t> of Babel that illustrate these properties.</t>
<t>These robustness properties have important consequences for the
<t>These robustness properties have important consequences for the
applicability of the protocol: Babel works (more or less efficiently) in applicability of the protocol: Babel works (more or less efficiently) in
a range of circumstances where traditional routing protocols don't work a range of circumstances where traditional routing protocols don't work
well (or at all).</t> well (or at all).</t>
</section>
</section> <section numbered="true" toc="default">
<name>Extensibility</name>
<section title="Extensibility"> <t>Babel's packet format has a number of features that make the protocol
extensible (see <xref target="RFC8966" section="D" sectionFormat="of" format="de
<t>Babel's packet format has a number of features that make the protocol fault"/>), and
extensible (see Appendix&nbsp;C of <xref target="RFC6126bis"/>), and
a number of extensions have been designed to make Babel work better in a number of extensions have been designed to make Babel work better in
situations that were not envisioned when the protocol was initially situations that were not envisioned when the protocol was initially
designed. The ease of extensibility is not an accident, but a consequence designed. The ease of extensibility is not an accident, but a consequence
of the design of the protocol: it is reasonably easy to check whether of the design of the protocol: it is reasonably easy to check whether
a given extension violates the assumptions on which Babel relies.</t> a given extension violates the assumptions on which Babel relies.</t>
<t>All of the extensions designed to date interoperate with the base
<t>All of the extensions designed to date interoperate with the base
protocol and with each other. This, again, is a consequence of the protocol and with each other. This, again, is a consequence of the
protocol design: in order to check that two extensions to the Babel protocol design: in order to check that two extensions to the Babel
protocol are interoperable, it is enough to verify that the interaction of protocol are interoperable, it is enough to verify that the interaction of
the two does not violate the base protocol's assumptions.</t> the two does not violate the base protocol's assumptions.</t>
<t>Notable extensions deployed to date include:
<t>Notable extensions deployed to date include: </t>
<list style="symbols"> <ul spacing="normal">
<t>source-specific routing (SADR) <xref target="BABEL-SS"/> allows <li>source-specific routing (also known as Source-Address Dependent
Routing, SADR) <xref target="I-D.ietf-babel-source-specific" format="default"
/> allows
forwarding to take a packet's source address into account, thus enabling forwarding to take a packet's source address into account, thus enabling
a cheap form of multihoming <xref target="SS-ROUTING"/>;</t> a cheap form of multihoming <xref target="SS-ROUTING" format="default"/>;</li>
<t>RTT-based routing <xref target="BABEL-RTT"/> minimises link delay, <li>RTT-based routing <xref target="I-D.jonglez-babel-rtt-extension" f
ormat="default"/> minimises link delay,
which is useful in overlay network (where both hop count and packet loss which is useful in overlay network (where both hop count and packet loss
are poor metrics).</t> are poor metrics).</li>
</list> </ul>
Some other extensions have been designed, but have not seen deployment <t>
Some other extensions have been designed but have not seen deployment
in production (and their usefulness is yet to be demonstrated): in production (and their usefulness is yet to be demonstrated):
<list style="symbols"> </t>
<t>frequency-aware routing <xref target="BABEL-Z"/> aims to minimise radio <ul spacing="normal">
interference in wireless networks;</t> <li>frequency-aware routing <xref target="I-D.chroboczek-babel-diversi
<t>ToS-aware routing <xref target="BABEL-TOS"/> allows routing to take ty-routing" format="default"/> aims to minimise radio
a packet's ToS marking into account for selected routes without incurring interference in wireless networks;</li>
the full cost of a multi-topology routing protocol.</t> <li>ToS-aware routing
</list></t> <xref target="I-D.chouasne-babel-tos-specific" format="default"/> allows routing
to take
</section> a packet's Type of Service (ToS) marking into account for selected routes withou
t incurring
<section title="Limitations"> the full cost of a multi-topology routing protocol.</li>
</ul>
<t>Babel has some undesirable properties that make it suboptimal or even </section>
<section numbered="true" toc="default">
<name>Limitations</name>
<t>Babel has some undesirable properties that make it suboptimal or even
unusable in some deployments.</t> unusable in some deployments.</t>
<section numbered="true" toc="default">
<section title="Periodic updates"> <name>Periodic Updates</name>
<t>The main mechanisms used by Babel to reconverge after a topology ch
<t>The main mechanisms used by Babel to reconverge after a topology change ange
are reactive: triggered updates, triggered retractions and explicit are reactive: triggered updates, triggered retractions and explicit
requests. However, Babel relies on periodic updates to clear pathologies requests. However, Babel relies on periodic updates to clear pathologies
after a mobility event or in the presence of heavy packet loss. The use after a mobility event or in the presence of heavy packet loss. The use
of periodic updates makes Babel unsuitable in at least two kinds of of periodic updates makes Babel unsuitable in at least two kinds of
environments: environments:
<list style="symbols"> </t>
<t>large, stable networks: since Babel sends periodic updates even in the <ul empty="true"><li>
<dl spacing="normal">
<dt>large, stable networks:</dt><dd>since Babel sends periodic updat
es even in the
absence of topology changes, in well-managed, large, stable networks the absence of topology changes, in well-managed, large, stable networks the
amount of control traffic will be reduced by using a protocol that uses amount of control traffic will be reduced by using a protocol that uses
a reliable transport (such as OSPF, IS-IS or EIGRP);</t> a reliable transport (such as OSPF, IS-IS, or EIGRP);</dd>
<t>low-power networks: the periodic updates use up battery power even when <dt>low-power networks:</dt><dd>the periodic updates use up battery
power even when
there are no topology changes and no user traffic, which makes Babel there are no topology changes and no user traffic, which makes Babel
wasteful in low-power networks.</t> wasteful in low-power networks.</dd>
</list></t> </dl></li>
</ul>
</section> </section>
<section numbered="true" toc="default">
<section title="Full routing table"> <name>Full Routing Table</name>
<t>While there exist techniques that allow a Babel speaker to function
<t>While there exist techniques that allow a Babel speaker to function
with a partial routing table (e.g., by learning just a default route or, with a partial routing table (e.g., by learning just a default route or,
more generally, performing route aggregation), Babel is designed around more generally, performing route aggregation), Babel is designed around
the assumption that every router has a full routing table. In networks the assumption that every router has a full routing table. In networks
where some nodes are too constrained to hold a full routing table, it where some nodes are too constrained to hold a full routing table, it
might be preferable to use a protocol that was designed from the outset to might be preferable to use a protocol that was designed from the outset to
work with a partial routing table (such as AODV <xref target="RFC3561"/>, work with a partial routing table (such as
RPL <xref target="RFC6550"/> or LOADng <xref target="LOADng"/>).</t> the Ad hoc On-Demand Distance Vector (AODV) routing protocol <xref target="RFC35
61" format="default"/>,
</section> the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) <xref target="R
FC6550" format="default"/>, or the
<section title="Slow aggregation"> Lightweight On-demand Ad hoc Distance-vector Routing Protocol - Next Generation
(LOADng) <xref target="I-D.clausen-lln-loadng" format="default"/>).</t>
<t>Babel's loop-avoidance mechanism relies on making a route unreachable </section>
<section numbered="true" toc="default">
<name>Slow Aggregation</name>
<t>Babel's loop-avoidance mechanism relies on making a route unreachab
le
after a retraction until all neighbours have been guaranteed to have acted after a retraction until all neighbours have been guaranteed to have acted
upon the retraction, even in the presence of packet loss. Unless the upon the retraction, even in the presence of packet loss. Unless the
second algorithm described in Section 3.5.5 of <xref target="RFC6126bis"/> second algorithm described in <xref target="RFC8966" sectionFormat="of" section= "3.5.5"/>
is implemented, this entails that a node is unreachable for a few minutes is implemented, this entails that a node is unreachable for a few minutes
after the most specific route to it has been retracted. This delay makes after the most specific route to it has been retracted. This delay makes
Babel slow to recover from a topology change in networks that perform Babel slow to recover from a topology change in networks that perform
automatic route aggregation.</t> automatic route aggregation.</t>
</section>
</section> </section>
</section>
</section> <section anchor="successful" numbered="true" toc="default">
<name>Successful Deployments of Babel</name>
</section> <t>This section gives a few examples of environments where Babel has been
<section title="Successful deployments of Babel" anchor="successful">
<t>This section gives a few examples of environments where Babel has been
successfully deployed.</t> successfully deployed.</t>
<section numbered="true" toc="default">
<section title="Heterogeneous networks"> <name>Heterogeneous Networks</name>
<t>Babel is able to deal with both classical, prefix-based
<t>Babel is able to deal with both classical, prefix-based
("Internet-style") routing and flat ("mesh-style") routing over ("Internet-style") routing and flat ("mesh-style") routing over
non-transitive link technologies. Just like traditional distance-vector non-transitive link technologies. Just like traditional distance-vector
protocols, Babel is able to carry prefixes of arbitrary length, to supress protocols, Babel is able to carry prefixes of arbitrary length, to suppress
redundant announcements by applying the split-horizon optimisation where redundant announcements by applying the split-horizon optimisation where
applicable, and can be configured to filter out redundant announcements applicable, and can be configured to filter out redundant announcements
(manual aggregation). Just like specialised mesh protocols, Babel doesn't (manual aggregation). Just like specialised mesh protocols, Babel doesn't
by default assume that links are transitive or symmetric, can dynamically by default assume that links are transitive or symmetric, can dynamically
compute metrics based on an estimation of link quality, and carries large compute metrics based on an estimation of link quality, and carries large
numbers of host routes efficiently by omitting common prefixes.</t> numbers of host routes efficiently by omitting common prefixes.</t>
<t>Because of these properties, Babel has seen a number of successful
<t>Because of these properties, Babel has seen a number of successful
deployments in medium-sized heterogeneous networks, networks that combine deployments in medium-sized heterogeneous networks, networks that combine
a wired, aggregated backbone with meshy wireless bits at the edges.</t> a wired, aggregated backbone with meshy wireless bits at the edges.</t>
<t>Efficient operation in heterogeneous networks requires the implementa
<t>Efficient operation in heterogeneous networks requires the implementation tion
to distinguish between wired and wireless links, and to perform link quality to distinguish between wired and wireless links, and to perform link quality
estimation on wireless links.</t> estimation on wireless links.</t>
</section>
</section> <section numbered="true" toc="default">
<section title="Large scale overlay networks"> <name>Large-Scale Overlay Networks</name>
<t>The algorithms used by Babel (loop avoidance, hysteresis, delayed
<t>The algorithms used by Babel (loop avoidance, hysteresis, delayed
updates) allow it to remain stable in the presence of unstable metrics, updates) allow it to remain stable in the presence of unstable metrics,
even in the presence of a feedback loop. For this reason, it has been even in the presence of a feedback loop. For this reason, it has been
successfully deployed in large scale overlay networks, built out of successfully deployed in large-scale overlay networks, built out of
thousands of tunnels spanning continents, where it is used with a metric thousands of tunnels spanning continents, where it is used with a metric
computed from links' latencies.</t> computed from links' latencies.</t>
<t>This particular application depends on the extension for RTT-sensitiv
<t>This particular application depends on the extension for RTT-sensitive e
routing <xref target="DELAY-BASED"/>.</t> routing <xref target="DELAY-BASED" format="default"/>.</t>
</section>
</section> <section numbered="true" toc="default">
<name>Pure Mesh Networks</name>
<section title="Pure mesh networks"> <t>While Babel is a general-purpose routing protocol, it has been shown
to
<t>While Babel is a general-purpose routing protocol, it has been shown to
be competitive with dedicated routing protocols for wireless mesh networks be competitive with dedicated routing protocols for wireless mesh networks
<xref target="REAL-WORLD"/> <xref target="BRIDGING-LAYERS"/>. Although <xref target="REAL-WORLD" format="default"/> <xref target="BRIDGING-LAYERS" form at="default"/>. Although
this particular niche is already served by a number of mature protocols, this particular niche is already served by a number of mature protocols,
notably OLSR-ETX and OLSRv2 <xref target="RFC7181"/> (equipped notably the Optimized Link State Routing Protocol with Expected Transmission Cou
e.g.&nbsp;with the DAT metric <xref target="RFC7779"/>), Babel has seen nt (OLSR-ETX) and
OLSRv2 (OLSR Version 2) <xref target="RFC7181" format="default"/> (equipped
e.g., with the Directional Airtime (DAT) metric <xref target="RFC7779" format="d
efault"/>), Babel has seen
a moderate amount of successful deployment in pure mesh networks.</t> a moderate amount of successful deployment in pure mesh networks.</t>
</section>
</section> <section numbered="true" toc="default">
<name>Small Unmanaged Networks</name>
<section title="Small unmanaged networks"> <t>Because of its small size and simple configuration, Babel has been
<t>Because of its small size and simple configuration, Babel has been
deployed in small, unmanaged networks (e.g., home and small office deployed in small, unmanaged networks (e.g., home and small office
networks), where it serves as a more efficient replacement for RIP networks), where it serves as a more efficient replacement for RIP
<xref target="RFC2453"/>, over which it has two significant advantages: the <xref target="RFC2453" format="default"/>, over which it has two significant adv antages: the
ability to route multiple address families (IPv6 and IPv4) in a single ability to route multiple address families (IPv6 and IPv4) in a single
protocol instance, and good support for using wireless links for protocol instance and good support for using wireless links for
transit.</t> transit.</t>
</section>
</section> </section>
<section numbered="true" toc="default">
</section> <name>Security Considerations</name>
<t>As is the case in all distance-vector routing protocols, a Babel
<section title="IANA Considerations">
<t>This document requires no IANA actions. [RFC Editor: please remove this
section before publication.]</t>
</section>
<section title="Security Considerations">
<t>As is the case in all distance-vector routing protocols, a Babel
speaker receives reachability information from its neighbours, which by speaker receives reachability information from its neighbours, which by
default is trusted by all nodes in the routing domain.</t> default is trusted by all nodes in the routing domain.</t>
<t>At the time of writing, the Babel protocol is usually run over
<t>At the time of writing, the Babel protocol is usually run over
a network that is secured either at the physical layer (e.g., physically a network that is secured either at the physical layer (e.g., physically
protecting Ethernet sockets) or at the link layer (using a protocol such protecting Ethernet sockets) or at the link layer (using a protocol such
as WiFi Protected Access (WPA2)). If Babel is being run over an as Wi-Fi Protected Access 2 (WPA2)). If Babel is being run over an
unprotected network, then the routing traffic needs to be protected using unprotected network, then the routing traffic needs to be protected using
a sufficiently strong cryptographic mechanism.</t> a sufficiently strong cryptographic mechanism.</t>
<t>At the time of writing, two such mechanisms have been defined.
<t>At the time of writing, two such mechanisms have been defined. Message Authentication Code (MAC) authentication for Babel (Babel-MAC)
Babel-MAC <xref target="BABEL-MAC"/> is a simple and easy to implement <xref target="RFC8967" format="default"/> is a simple and easy to implement
mechanism that only guarantees authenticity, integrity and replay mechanism that only guarantees authenticity, integrity, and replay
protection of the routing traffic, and only supports symmetric keying with protection of the routing traffic and only supports symmetric keying with
a small number of keys (typically just one or two). Babel-DTLS a small number of keys (typically just one or two). Babel-DTLS
<xref target="BABEL-DTLS"/> is a more complex mechanism, that requires <xref target="RFC8968" format="default"/> is a more complex mechanism that requi res
some minor changes to be made to a typical Babel implementation and some minor changes to be made to a typical Babel implementation and
depends on a DTLS stack being available, but inherits all of the features depends on a DTLS stack being available, but inherits all of the features
of DTLS, notably confidentiality, optional replay protection, and the of DTLS, notably confidentiality, optional replay protection, and the
ability to use asymmetric keys.</t> ability to use asymmetric keys.</t>
<t>Due to its simplicity, Babel-MAC should be the preferred security
<t>Due to its simplicity, Babel-MAC should be the preferred security
mechanism in most deployments, with Babel-DTLS available for networks mechanism in most deployments, with Babel-DTLS available for networks
that require its additional features.</t> that require its additional features.</t>
<t>In addition to the above, the information that a mobile Babel node
<t>In addition to the above, the information that a mobile Babel node
announces to the whole routing domain is often sufficient to determine announces to the whole routing domain is often sufficient to determine
a mobile node's physical location with reasonable precision. This might a mobile node's physical location with reasonable precision. This might
make Babel unapplicable in scenarios where a node's location is considered make Babel unapplicable in scenarios where a node's location is considered
confidential.</t> confidential.</t>
</section>
</middle>
<back>
</section> <displayreference target="I-D.chouasne-babel-tos-specific" to="BABEL-TOS"/>
<displayreference target="I-D.ietf-babel-source-specific" to="BABEL-SS"/>
<section title="Acknowledgments"> <displayreference target="I-D.jonglez-babel-rtt-extension" to="BABEL-RTT"/>
<displayreference target="I-D.chroboczek-babel-diversity-routing" to="BABEL-Z"/>
<t>The author is indebted to Jean-Paul Smetz and Alexander Vainshtein for <displayreference target="I-D.clausen-lln-loadng" to="LOADng"/>
their input to this document.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC6126bis"><front>
<title>The Babel Routing Protocol</title>
<author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek"/>
<author fullname="David Schinazi" initials="D." surname="Schinazi"/>
<date month="August" year="2019"/>
</front>
<seriesInfo name="Internet Draft" value="draft-ietf-babel-rfc6126bis-14"/>
</reference>
</references>
<references title="Informational References">
<reference anchor="DELAY-BASED" target="http://arxiv.org/abs/1403.3488"><front> <references>
<title>A delay-based routing metric</title> <name>References</name>
<author fullname="Baptiste Jonglez" initials="B." surname="Jonglez"/> <references>
<author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek"/> <name>Normative References</name>
<date month="March" year="2014"/>
</front>
</reference>
<reference anchor="RFC2453"> <reference anchor="RFC8966" target="https://www.rfc-editor.org/info/rfc8
<front> 966">
<title>RIP Version 2</title> <front>
<author initials="G." surname="Malkin" fullname="G. Malkin"> <title>The Babel Routing Protocol</title>
<organization/> <author fullname="Juliusz Chroboczek" initials="J." surname="Chroboc
</author> zek"/>
<date year="1998" month="November"/> <author fullname="David Schinazi" initials="D." surname="Schinazi"/>
</front> <date month="January" year="2021"/>
<seriesInfo name="STD" value="56"/> </front>
<seriesInfo name="RFC" value="2453"/> <seriesInfo name="RFC" value="8966"/>
</reference> <seriesInfo name="DOI" value="10.17487/RFC8966"/>
</reference>
<reference anchor="RFC7181"> </references>
<front> <references>
<title> <name>Informative References</name>
The Optimized Link State Routing Protocol Version 2
</title>
<author initials="T." surname="Clausen" fullname="T. Clausen">
<organization/>
</author>
<author initials="C." surname="Dearlove" fullname="C. Dearlove">
<organization/>
</author>
<author initials="P." surname="Jacquet" fullname="P. Jacquet">
<organization/>
</author>
<author initials="U." surname="Herberg" fullname="U. Herberg">
<organization/>
</author>
<date year="2014" month="April"/>
</front>
<seriesInfo name="RFC" value="7181"/>
</reference>
<reference anchor="RFC7779"> <reference anchor="DELAY-BASED" target="http://arxiv.org/abs/1403.3488">
<front> <front>
<title> <title>A delay-based routing metric</title>
Directional Airtime Metric Based on Packet Sequence Numbers for Optimized Link S <author fullname="Baptiste Jonglez" initials="B." surname="Jonglez"/
tate Routing Version 2 (OLSRv2) >
</title> <author fullname="Matthieu Boutier" initials="M." surname="Boutier"/
<author initials="H." surname="Rogge" fullname="H. Rogge"> >
<organization/> <author fullname="Juliusz Chroboczek" initials="J." surname="Chroboc
</author> zek"/>
<author initials="E." surname="Baccelli" fullname="E. Baccelli"> <date month="March" year="2014"/>
<organization/> </front>
</author> </reference>
<date year="2016" month="April"/>
</front>
<seriesInfo name="RFC" value="7779"/>
<seriesInfo name="DOI" value="10.17487/RFC7779"/>
</reference>
<reference anchor="RFC5340"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<front> FC.2453.xml"/>
<title>OSPF for IPv6</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<author initials="R." surname="Coltun" fullname="R. Coltun"/> FC.7181.xml"/>
<author initials="D." surname="Ferguson" fullname="D. Ferguson"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<author initials="J." surname="Moy" fullname="J. Moy"/> FC.7779.xml"/>
<author initials="A." surname="Lindem" fullname="A. Lindem"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<date year="2008" month="July"/> FC.5340.xml"/>
</front>
<seriesInfo name="RFC" value="5340"/>
</reference>
<reference anchor="DUAL"><front> <reference anchor="DUAL">
<title>Loop-Free Routing Using Diffusing Computations</title> <front>
<author fullname="J. J. Garcia Luna Aceves" <title>Loop-Free Routing Using Diffusing Computations</title>
initials="J. J." surname="Garcia Luna Aceves"/> <author fullname="J. J. Garcia-Luna-Aceves" initials="J. J." surname
<date month="February" year="1993"/> ="Garcia-Luna-Aceves"/>
</front> <date month="February" year="1993"/>
<seriesInfo name="IEEE/ACM Transactions on Networking" value="1:1"/> </front>
</reference> <refcontent>IEEE/ACM Transactions on Networking, Volume 1, Issue 1</re
fcontent>
<seriesInfo name="DOI" value="10.1109/90.222913"/>
</reference>
<reference anchor="RFC7868"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<front> FC.7868.xml"/>
<title>
Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP)
</title>
<author initials="D." surname="Savage" fullname="D. Savage">
<organization/>
</author>
<author initials="J." surname="Ng" fullname="J. Ng">
<organization/>
</author>
<author initials="S." surname="Moore" fullname="S. Moore">
<organization/>
</author>
<author initials="D." surname="Slice" fullname="D. Slice">
<organization/>
</author>
<author initials="P." surname="Paluch" fullname="P. Paluch">
<organization/>
</author>
<author initials="R." surname="White" fullname="R. White">
<organization/>
</author>
<date year="2016" month="May"/>
</front>
<seriesInfo name="RFC" value="7868"/>
<seriesInfo name="DOI" value="10.17487/RFC7868"/>
</reference>
<reference anchor="DSDV"><front> <reference anchor="DSDV" target="https://doi.org/10.1145/190314.190336">
<title>Highly Dynamic Destination-Sequenced Distance-Vector Routing <front>
<title>Highly Dynamic Destination-Sequenced Distance-Vector Routing
(DSDV) for Mobile Computers</title> (DSDV) for Mobile Computers</title>
<author fullname="Charles Perkins" initials="C." surname="Perkins"/> <author fullname="Charles Perkins" initials="C." surname="Perkins"/>
<author fullname="Pravin Bhagwat" initials="P." surname="Bhagwat"/> <author fullname="Pravin Bhagwat" initials="P." surname="Bhagwat"/>
<date year="1994"/> <date month="October" year="1994"/>
</front> </front>
<seriesInfo name="ACM SIGCOMM'94 Conference on Communications <refcontent>ACM SIGCOMM '94: Proceedings of the Conference on Communic
Architectures, Protocols and Applications" value="234-244"/> ations Architectures, Protocols and Applications, pp. 234-244</refcontent>
</reference> <seriesInfo name="DOI" value="10.1145/190314.190336"/>
</reference>
<reference anchor="RFC1195">
<front>
<title>
Use of OSI IS-IS for routing in TCP/IP and dual environments
</title>
<author initials="R.W." surname="Callon" fullname="R.W. Callon">
<organization/>
</author>
<date year="1990" month="December"/>
</front>
<seriesInfo name="RFC" value="1195"/>
</reference>
<reference anchor="RFC3561" target="https://www.rfc-editor.org/info/rfc3561">
<front>
<title>Ad hoc On-Demand Distance Vector (AODV) Routing</title>
<author initials="C." surname="Perkins" fullname="C. Perkins"/>
<author initials="E." surname="Belding-Royer" fullname="E. Belding-Royer"/>
<author initials="S." surname="Das" fullname="S. Das"/>
<date year="2003" month="July"/>
</front>
<seriesInfo name="RFC" value="3561"/>
<seriesInfo name="DOI" value="10.17487/RFC3561"/>
</reference>
<reference anchor="RFC6550"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<front> FC.1195.xml"/>
<title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks FC.3561.xml"/>
</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<author initials="T." surname="Winter" fullname="T. Winter" role="editor"/> FC.6550.xml"/>
<author initials="P." surname="Thubert" fullname="P. Thubert" role="editor"/>
<author initials="A." surname="Brandt" fullname="A. Brandt"/>
<author initials="J." surname="Hui" fullname="J. Hui"/>
<author initials="R." surname="Kelsey" fullname="R. Kelsey"/>
<author initials="P." surname="Levis" fullname="P. Levis"/>
<author initials="K." surname="Pister" fullname="K. Pister"/>
<author initials="R." surname="Struik" fullname="R. Struik"/>
<author initials="JP." surname="Vasseur" fullname="JP. Vasseur"/>
<author initials="R." surname="Alexander" fullname="R. Alexander"/>
<date year="2012" month="March"/>
</front>
<seriesInfo name="RFC" value="6550"/>
</reference>
<reference anchor='LOADng'> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
<front> .clausen-lln-loadng.xml"/>
<title>The Lightweight On-demand Ad hoc Distance-vector Routing Protocol - Next
Generation (LOADng)</title>
<author initials='T' surname='Clausen' fullname='Thomas Clausen'/>
<author initials='A' surname='Verdiere' fullname='Axel Verdiere'/>
<author initials='J' surname='Yi' fullname='Jiazi Yi'/>
<author initials='A' surname='Niktash' fullname='Afshin Niktash'/>
<author initials='Y' surname='Igarashi' fullname='Yuichi Igarashi'/>
<author initials='H' surname='Satoh' fullname='Hiroki Satoh'/>
<author initials='U' surname='Herberg' fullname='Ulrich Herberg'/>
<author initials='C' surname='Lavenu' fullname='Cedric Lavenu'/>
<author initials='T' surname='Lys' fullname='Thierry Lys'/>
<author initials='J' surname='Dean' fullname='Justin Dean'/>
<date month='January' day='5' year='2017' />
</front>
<seriesInfo name='Internet-Draft' value='draft-clausen-lln-loadng-15' />
</reference>
<reference anchor="REAL-WORLD"><front> <reference anchor="REAL-WORLD">
<title>Real-world performance of current proactive multi-hop mesh <front>
protocols</title> <title>Real-world performance of current proactive multi-hop mesh pr
<author initials="M." surname="Abolhasan"/> otocols</title>
<author initials="B." surname="Hagelstein"/> <author initials="M." surname="Abolhasan"/>
<author initials="J. C.-P." surname="Wang"/> <author initials="B." surname="Hagelstein"/>
<date year="2009"/> <author initials="J. C.-P." surname="Wang"/>
</front> <date month="October" year="2009"/>
<seriesInfo name="Asia-Pacific Conference on Communication" value="2009"/> </front>
</reference> <refcontent>15th Asia-Pacific Conference on Communications</refcontent
>
<seriesInfo name="DOI" value="10.1109/APCC.2009.5375690"/>
</reference>
<reference anchor="BRIDGING-LAYERS"><front> <reference anchor="BRIDGING-LAYERS">
<title>An Experimental Comparison of Routing Protocols in Multi Hop Ad Hoc <front>
<title>An Experimental Comparison of Routing Protocols in Multi Hop
Ad Hoc
Networks</title> Networks</title>
<author initials="D." surname="Murray" fullname="David Murray"/> <author initials="D." surname="Murray" fullname="David Murray"/>
<author initials="M." surname="Dixon" fullname="Michael Dixon"/> <author initials="M." surname="Dixon" fullname="Michael Dixon"/>
<author initials="T." surname="Koziniec" fullname="Terry Koziniec"/> <author initials="T." surname="Koziniec" fullname="Terry Koziniec"/>
<date year="2010"/> <date month="October" year="2010"/>
</front> </front>
<seriesInfo name="Proc. ATNAC" value="2010"/> <refcontent>In Proceedings of ATNAC</refcontent>
</reference> <seriesInfo name="DOI" value="10.1109/ATNAC.2010.5680190"/>
</reference>
<reference anchor="BABEL-SS"> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
<front> .ietf-babel-source-specific.xml"/>
<title>Source-Specific Routing in Babel</title>
<author initials='M' surname='Boutier' fullname='Matthieu Boutier'></author>
<author initials='J' surname='Chroboczek' fullname='Juliusz Chroboczek'></author
>
<date day="23" month="October" year="2018"/>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-babel-source-specific-04'/>
</reference>
<reference anchor="BABEL-RTT"> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
<front> .jonglez-babel-rtt-extension.xml"/>
<title>Delay-based Metric Extension for the Babel Routing Protocol</title>
<author initials='B' surname='Jonglez' fullname='Baptiste Jonglez'></author>
<author initials='J' surname='Chroboczek' fullname='Juliusz Chroboczek'></author
>
<date month='May' day='27' year='2015' />
</front>
<seriesInfo name='Internet-Draft' value='draft-jonglez-babel-rtt-extension-01' /
>
</reference>
<reference anchor="BABEL-TOS"> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
<front> .chouasne-babel-tos-specific.xml"/>
<title>TOS-Specific Routing in Babel</title>
<author fullname="Gwendoline Chouasne" initials="G." surname="Chouasne"/>
<author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek"/>
<date day="3" month="July" year="2017"/>
</front>
<seriesInfo name='Internet-Draft' value='draft-chouasne-babel-tos-specific-00'/>
</reference>
<reference anchor="BABEL-Z"><front> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
<title>Diversity Routing for the Babel Routing Protocol</title> .chroboczek-babel-diversity-routing.xml"/>
<author initials='J' surname='Chroboczek' fullname='Juliusz Chroboczek'></author
>
<date month='February' day='15' year='2016' />
</front>
<seriesInfo name='Internet-Draft' value='draft-chroboczek-babel-diversity-routin
g-01'/>
</reference>
<reference anchor="SS-ROUTING" target="http://arxiv.org/pdf/1403.0445"><front> <reference anchor="SS-ROUTING" target="http://arxiv.org/pdf/1403.0445">
<title>Source-Specific Routing</title> <front>
<author initials="M." surname="Boutier" fullname="Matthieu Boutier"/> <title>Source-specific routing</title>
<author initials="J." surname="Chroboczek" fullname="Juliusz Chroboczek"/> <author initials="M." surname="Boutier" fullname="Matthieu Boutier"/
<date year="2014" month="August"/> >
</front> <author initials="J." surname="Chroboczek" fullname="Juliusz Chroboc
<annotation>In Proc. IFIP Networking 2015.</annotation> zek"/>
</reference> <date year="2015" month="May"/>
</front>
<refcontent>In Proceedings of the IFIP Networking Conference</refconte
nt>
<seriesInfo name="DOI" value="10.1109/IFIPNetworking.2015.7145305"/>
</reference>
<reference anchor="BABEL-MAC"><front> <reference anchor="RFC8967" target="https://www.rfc-editor.org/info/rfc8967">
<title>MAC authentication for the Babel routing protocol</title>
<author fullname="Clara Do" initials="C." surname="Do"/>
<author fullname="Weronika Kolodziejak" initials="W." surname="Kolodziejak"/>
<author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek"/>
<date month="August" year="2019"/></front>
<seriesInfo name="Internet Draft" value="draft-ietf-babel-hmac-10"/>
</reference>
<reference anchor="BABEL-DTLS"><front> <front>
<title>Babel Routing Protocol over Datagram Transport Layer Security</title> <title>MAC Authentication for the Babel Routing Protocol</title>
<author fullname="Antonin Decimo" initials="A." surname="Decimo"/> <author initials="C." surname="Dô" fullname="Clara Dô">
<author fullname="David Schinazi" initials="D." surname="Schinazi"/> <organization/>
<author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek"/> </author>
<date month="August" year="2019"/></front> <author initials="W." surname="Kolodziejak" fullname="Weronika Kolodziejak
<seriesInfo name="Internet Draft" value="draft-ietf-babel-dtls-09"/> ">
</reference> <organization/>
</author>
<author initials="J." surname="Chroboczek" fullname="Juliusz Chroboczek">
<organization/>
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8967"/>
<seriesInfo name="DOI" value="10.17487/RFC8967"/>
</reference>
<reference anchor="METAROUTING"><front> <reference anchor="RFC8968" target="https://www.rfc-editor.org/info/rfc8968">
<title>Metarouting</title> <front>
<author initials="T. G." surname="Griffin" fullname="Timothy G. Griffin"/> <title>Babel Routing Protocol over Datagram Transport Layer Security</tit
<author initials="J. L." surname="Sobrinho" fullname="Joao Luis Sobrinho"/> le>
<date year="2005"/> <author initials="A." surname="Décimo" fullname="Antonin Décimo">
</front> <organization/>
<annotation>In Proceedings of the 2005 conference on Applications, </author>
technologies, architectures, and protocols for computer communications <author initials="D." surname="Schinazi" fullname="David Schinazi">
(SIGCOMM'05).</annotation> <organization/>
</reference> </author>
<author initials="J." surname="Chroboczek" fullname="Juliusz Chroboczek">
<organization/>
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8968"/>
<seriesInfo name="DOI" value="10.17487/RFC8968"/>
</reference>
</references> <reference anchor="METAROUTING">
<front>
<title>Metarouting</title>
<author initials="T. G." surname="Griffin" fullname="Timothy G. Grif
fin"/>
<author initials="J. L." surname="Sobrinho" fullname="Joao Luis Sobr
inho"/>
<date month="August" year="2005"/>
</front>
<refcontent>ACM SIGCOMM Computer Communication Review, Volume 35, Issu
e 4</refcontent>
<seriesInfo name="DOI" value="10.1145/1090191.1080094"/>
</reference>
</references>
</references>
</back> <section numbered="false" toc="default">
<name>Acknowledgments</name>
<t>The author is indebted to <contact fullname="Jean-Paul Smetz"/> and
<contact fullname="Alexander Vainshtein"/> for their input to this documen
t.</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 84 change blocks. 
525 lines changed or deleted 415 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/