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
[RFC6126] and [RFC7557].¶
The main property that makes Babel suitable for unstable networks is
that, unlike naive distance-vector routing protocols [RIP],
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
[DSDV].¶
More precisely, Babel has the following properties:¶
- when every prefix is originated by at most one router, Babel never
suffers from routing loops;¶
- 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;¶
- 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.¶
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.¶
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.¶
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.¶
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 [OSPF], IS-IS [IS-IS], or the Enhanced Interior
Gateway Routing Protocol (EIGRP) [EIGRP] might be more
suitable.¶
Second, unless the second algorithm described in Section 3.5.4
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 Section 3.5.4 unsuitable for use in
networks that implement automatic prefix aggregation.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 [RFC2119]
[RFC8174] when, and only when,
they appear in all capitals, as shown here.¶
Babel is a loop-avoiding distance-vector protocol: it is based on the
Bellman-Ford algorithm, just like the venerable RIP [RIP],
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.¶
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.¶
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.¶
Costs and metrics need not be integers. In general, they can be values
in any algebra that satisfies two fairly general conditions
(Section 3.5.2).¶
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.¶
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.¶
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 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.¶
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:¶
B
1 /|
1 / |
S --- A |1
\ |
1 \|
C
¶
After convergence, D(B) = D(C) = 2, with NH(B) = NH(C) = A.¶
Suppose now that the link between S and A fails:¶
B
1 /|
/ |
S A |1
\ |
1 \|
C
¶
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.¶
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.¶
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.¶
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).¶
Another simple feasibility condition, used in the Destination-Sequenced
Distance-Vector (DSDV) routing protocol [DSDV] and in the
Ad hoc On-Demand Distance Vector (AODV) protocol [RFC3561],
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) <= 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) < D(A), which implies that the
forwarding graph is loop-free.¶
Babel uses a slightly more refined feasibility condition, derived from
EIGRP [DUAL]. 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) < FD(A).¶
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) <= 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) <= D(A), hence D(B) < D(A),
and since D(A) <= FD(A), D(B) < FD(A).¶
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 < 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:¶
B
1 / \ 1
/ \
S A
\ /
1 \ / 4
C
¶
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) < 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.¶
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
1 /| D(A) = 1
/ | FD(A) = 1
S |1
\ | D(B) = 2
2 \| FD(B) = 2
B
¶
Suppose now that the link between A and S breaks:¶
A
|
| FD(A) = 1
S |1
\ | D(B) = 2
2 \| FD(B) = 2
B
¶
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).¶
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 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' > s, or s = s' and m' < m.¶
Assuming the sequence number of S is 137, the diagram above becomes:¶
A
|
| FD(A) = (137, 1)
S |1
\ | D(B) = (137, 2)
2 \| FD(B) = (137, 2)
B
¶
After S increases its sequence number, and the new sequence number is
propagated to B, we have:¶
A
|
| FD(A) = (137, 1)
S |1
\ | D(B) = (138, 2)
2 \| FD(B) = (138, 2)
B
¶
at which point the route through B becomes feasible again.¶
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
(Section 3.6). 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.¶
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.¶
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.¶
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.)¶
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.¶
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.¶
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.¶
Consider for example the following topology, where A has selected the
default route through S, and B has selected the one through S':¶
1 1 1
::/0 -- S --- A --- B --- S' -- ::/0
¶
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.¶
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 (Section 3.7.2).¶
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).¶
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.¶
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:¶
1 1
::/0 -- A --- B --- C
¶
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 (Section 3.5.4).¶
IANA has registered the UDP port number 6696, called "babel", for use
by the Babel protocol.¶
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.¶
IANA has created a registry called "Babel TLV Types". The allocation
policy for this registry is Specification Required [RFC8126]
for Types 0-223 and Experimental Use for Types 224-254. The values in
this registry are as follows:¶
Table 1
Type |
Name |
Reference |
0 |
Pad1 |
RFC 8966 |
1 |
PadN |
RFC 8966 |
2 |
Acknowledgment Request |
RFC 8966 |
3 |
Acknowledgment |
RFC 8966 |
4 |
Hello |
RFC 8966 |
5 |
IHU |
RFC 8966 |
6 |
Router-Id |
RFC 8966 |
7 |
Next Hop |
RFC 8966 |
8 |
Update |
RFC 8966 |
9 |
Route Request |
RFC 8966 |
10 |
Seqno Request |
RFC 8966 |
11 |
TS/PC |
[RFC7298]
|
12 |
HMAC |
[RFC7298]
|
13 |
Reserved |
|
14 |
Reserved |
|
15 |
Reserved |
|
224-254 |
Reserved for Experimental Use |
RFC 8966 |
255 |
Reserved for expansion of the type space |
RFC 8966 |
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:¶
Table 2
Type |
Name |
Reference |
0 |
Pad1 |
RFC 8966 |
1 |
PadN |
RFC 8966 |
2 |
Diversity |
[BABEL-DIVERSITY]
|
3 |
Timestamp |
[BABEL-RTT]
|
4-111 |
Unassigned |
|
112-126 |
Reserved for Experimental Use |
RFC 8966 |
127 |
Reserved for expansion of the type space |
RFC 8966 |
128 |
Source Prefix |
[BABEL-SS]
|
129-239 |
Unassigned |
|
240-254 |
Reserved for Experimental Use |
RFC 8966 |
255 |
Reserved for expansion of the type space |
RFC 8966 |
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:¶
Table 3
AE |
Name |
Reference |
0 |
Wildcard address |
RFC 8966 |
1 |
IPv4 address |
RFC 8966 |
2 |
IPv6 address |
RFC 8966 |
3 |
Link-local IPv6 address |
RFC 8966 |
4-223 |
Unassigned |
|
224-254 |
Reserved for Experimental Use |
RFC 8966 |
255 |
Reserved for expansion of the AE space |
RFC 8966 |
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:¶
Table 4
Bit |
Name |
Reference |
0 |
Default prefix |
RFC 8966 |
1 |
Default router-id |
RFC 8966 |
2-7 |
Unassigned |
|
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:¶
Table 5
Bit |
Name |
Reference |
0 |
Unicast |
RFC 8966 |
1-15 |
Unassigned |
|
IANA has replaced all references to RFCs 6126 and 7557
in all of the registries mentioned above with references to this document.¶
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:¶
- spoof a Babel packet, and redirect traffic by announcing a route with
a smaller metric, a larger sequence number, or a longer prefix;¶
- spoof a malformed packet, which could cause an insufficiently robust
implementation to crash or interfere with the rest of the network;¶
- replay a previously captured Babel packet, which could cause traffic to
be redirected, black-holed, or otherwise interfere with the network.¶
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
(Section 3.1).¶
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 RECOMMENDED 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:¶
- Babel over DTLS [RFC8968] runs the majority of Babel
traffic over DTLS and leverages DTLS to authenticate nodes and provide
confidentiality and integrity protection;¶
- MAC authentication [RFC8967] 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).¶
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 1.1,
1.2, and
7 of
[RFC8967]). 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.¶
Every implementation of Babel SHOULD implement BABEL-MAC.¶
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.¶
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:¶
- increasing the version number in the packet header;¶
- defining new TLVs;¶
- defining new sub-TLVs (with or without the mandatory bit set);¶
- defining new AEs;¶
- using the packet trailer.¶
This appendix is intended to guide designers of protocol extensions in
choosing a particular encoding.¶
The version number in the Babel header should only be increased if the
new version is not backwards compatible with the original protocol.¶
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.¶
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).¶
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.¶
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.¶
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.¶
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.¶
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.¶
Nonetheless, in some very constrained environments, such as PDAs,
microwave ovens, or abacuses, it may be desirable to have subset
implementations of the protocol.¶
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.¶
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.¶
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.¶
The protocol defined in this document is a successor to the protocol
defined in [RFC6126] and [RFC7557]. 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.¶
There are three optional features that make this protocol
incompatible with its predecessor. First of all, RFC 6126 did not define
Unicast Hellos (Section 3.4.1), 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
(Section 4.4), 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.¶
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.¶
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.¶
There are other changes, but these are not of a nature to prevent
interoperability:¶
- the conditions on route acquisition (Section 3.5.3)
have been relaxed;¶
- route selection should no longer use the route's sequence number
(Section 3.6);¶
- the format of the packet trailer has been defined
(Section 4.2);¶
- router-ids with a value of all-zeros or all-ones have been forbidden
(Section 4.1.3);¶
- the compression state is now specific to an address family rather than
an address encoding (Section 4.5);¶
- packet pacing is now recommended
(Section 3.1).¶