draft-ietf-babel-rfc6126bis-04.txt   draft-ietf-babel-rfc6126bis-05.txt 
Network Working Group J. Chroboczek Network Working Group J. Chroboczek
Internet-Draft IRIF, University of Paris-Diderot Internet-Draft IRIF, University of Paris-Diderot
Obsoletes: 6126,7557 (if approved) D. Schinazi Obsoletes: 6126,7557 (if approved) D. Schinazi
Intended status: Standards Track Apple Inc. Intended status: Standards Track Apple Inc.
Expires: May 2, 2018 October 29, 2017 Expires: November 30, 2018 May 29, 2018
The Babel Routing Protocol The Babel Routing Protocol
draft-ietf-babel-rfc6126bis-04 draft-ietf-babel-rfc6126bis-05
Abstract Abstract
Babel is a loop-avoiding distance-vector routing protocol that is Babel is a loop-avoiding distance-vector routing protocol that is
robust and efficient both in ordinary wired networks and in wireless robust and efficient both in ordinary wired networks and in wireless
mesh networks. mesh networks. This document describes the Babel routing protocol,
and obsoletes RFCs 6126 and 7557
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 2, 2018. This Internet-Draft will expire on November 30, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 2, line 40 skipping to change at page 2, line 40
4.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . 32 4.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . 32
4.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 33 4.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 33
4.3. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 33 4.3. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 33
4.4. Sub-TLV Format . . . . . . . . . . . . . . . . . . . . . 34 4.4. Sub-TLV Format . . . . . . . . . . . . . . . . . . . . . 34
4.5. Parser state . . . . . . . . . . . . . . . . . . . . . . 35 4.5. Parser state . . . . . . . . . . . . . . . . . . . . . . 35
4.6. Details of Specific TLVs . . . . . . . . . . . . . . . . 35 4.6. Details of Specific TLVs . . . . . . . . . . . . . . . . 35
4.7. Details of specific sub-TLVs . . . . . . . . . . . . . . 46 4.7. Details of specific sub-TLVs . . . . . . . . . . . . . . 46
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
6. Security Considerations . . . . . . . . . . . . . . . . . . . 48 6. Security Considerations . . . . . . . . . . . . . . . . . . . 48
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 49
8.1. Normative References . . . . . . . . . . . . . . . . . . 49 8.1. Normative References . . . . . . . . . . . . . . . . . . 49
8.2. Informative References . . . . . . . . . . . . . . . . . 49 8.2. Informative References . . . . . . . . . . . . . . . . . 49
Appendix A. Cost and Metric Computation . . . . . . . . . . . . 50 Appendix A. Cost and Metric Computation . . . . . . . . . . . . 50
A.1. Maintaining Hello History . . . . . . . . . . . . . . . . 50 A.1. Maintaining Hello History . . . . . . . . . . . . . . . . 50
A.2. Cost Computation . . . . . . . . . . . . . . . . . . . . 51 A.2. Cost Computation . . . . . . . . . . . . . . . . . . . . 51
A.3. Metric Computation . . . . . . . . . . . . . . . . . . . 52 A.3. Metric Computation . . . . . . . . . . . . . . . . . . . 53
Appendix B. Constants . . . . . . . . . . . . . . . . . . . . . 53 Appendix B. Constants . . . . . . . . . . . . . . . . . . . . . 53
Appendix C. Considerations for protocol extensions . . . . . . . 54 Appendix C. Considerations for protocol extensions . . . . . . . 54
Appendix D. Stub Implementations . . . . . . . . . . . . . . . . 55 Appendix D. Stub Implementations . . . . . . . . . . . . . . . . 56
Appendix E. Software Availability . . . . . . . . . . . . . . . 56 Appendix E. Software Availability . . . . . . . . . . . . . . . 56
Appendix F. Changes from previous versions . . . . . . . . . . . 56 Appendix F. Changes from previous versions . . . . . . . . . . . 57
F.1. Changes since RFC 6126 . . . . . . . . . . . . . . . . . 56 F.1. Changes since RFC 6126 . . . . . . . . . . . . . . . . . 57
F.2. Changes since draft-ietf-babel-rfc6126bis-00 . . . . . . 57 F.2. Changes since draft-ietf-babel-rfc6126bis-00 . . . . . . 57
F.3. Changes since draft-ietf-babel-rfc6126bis-01 . . . . . . 57 F.3. Changes since draft-ietf-babel-rfc6126bis-01 . . . . . . 57
F.4. Changes since draft-ietf-babel-rfc6126bis-02 . . . . . . 57 F.4. Changes since draft-ietf-babel-rfc6126bis-02 . . . . . . 58
F.5. Changes since draft-ietf-babel-rfc6126bis-03 . . . . . . 58 F.5. Changes since draft-ietf-babel-rfc6126bis-03 . . . . . . 58
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 F.6. Changes since draft-ietf-babel-rfc6126bis-03 . . . . . . 59
F.7. Changes since draft-ietf-babel-rfc6126bis-04 . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59
1. Introduction 1. Introduction
Babel is a loop-avoiding distance-vector routing protocol that is Babel is a loop-avoiding distance-vector routing protocol that is
designed to be robust and efficient both in networks using prefix- designed to be robust and efficient both in networks using prefix-
based routing and in networks using flat routing ("mesh networks"), based routing and in networks using flat routing ("mesh networks"),
and both in relatively stable wired networks and in highly dynamic and both in relatively stable wired networks and in highly dynamic
wireless networks. wireless networks.
1.1. Features 1.1. Features
skipping to change at page 4, line 45 skipping to change at page 4, line 48
being retracted, and hence does not prevent fast reconvergence should being retracted, and hence does not prevent fast reconvergence should
it become available again, it does apply to any shorter prefix that it become available again, it does apply to any shorter prefix that
covers it. This may make those implementations of Babel that do not covers it. This may make those implementations of Babel that do not
implement the optional algorithm described in Section 3.5.5 implement the optional algorithm described in Section 3.5.5
unsuitable for use in networks that implement automatic prefix unsuitable for use in networks that implement automatic prefix
aggregation. aggregation.
1.3. Specification of Requirements 1.3. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "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.
2. Conceptual Description of the Protocol 2. Conceptual Description of the Protocol
Babel is a loop-avoiding distance vector protocol: it is based on the Babel is a loop-avoiding distance vector protocol: it is based on the
Bellman-Ford protocol, just like the venerable RIP [RIP], but Bellman-Ford protocol, just like the venerable RIP [RIP], but
includes a number of refinements that either prevent loop formation includes a number of refinements that either prevent loop formation
altogether, or ensure that a loop disappears in a timely manner and altogether, or ensure that a loop disappears in a timely manner and
doesn't form again. doesn't form again.
Conceptually, Bellman-Ford is executed in parallel for every source Conceptually, Bellman-Ford is executed in parallel for every source
of routing information (destination of data traffic). In the of routing information (destination of data traffic). In the
following discussion, we fix a source S; the reader will recall that following discussion, we fix a source S; the reader will recall that
the same algorithm is executed for all sources. the same algorithm is executed for all sources.
2.1. Costs, Metrics and Neighbourship 2.1. Costs, Metrics and Neighbourship
As many routing algorithms, Babel computes costs of links between any For every pair of neighbouring nodes A and B, Babel computes an
two neighbouring nodes, abstract values attached to the edges between abstract value known as the cost of the link from A to B., written
two nodes. We write C(A, B) for the cost of the edge from node A to C(A, B). Given a route between any two (not necessarily
node B. neighbouring) nodes, the metric of the route is the sum of the costs
of all the edges along the route. The goal of the routing algorithm
Given a route between any two nodes, the metric of the route is the is to compute, for every source S, the tree of routes of lowest
sum of the costs of all the edges along the route. The goal of the metric to S.
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 Costs and metrics need not be integers. In general, they can be
values in any algebra that satisfies two fairly general conditions values in any algebra that satisfies two fairly general conditions
(Section 3.5.2). (Section 3.5.2).
A Babel node periodically sends Hello messages to all of its A Babel node periodically sends Hello messages to all of its
neighbours; it also periodically sends an IHU ("I Heard You") message neighbours; it also periodically sends an IHU ("I Heard You") message
to every neighbour from which it has recently heard a Hello. From to every neighbour from which it has recently heard a Hello. From
the information derived from Hello and IHU messages received from its 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 neighbour B, a node A computes the cost C(A, B) of the link from A to
skipping to change at page 9, line 6 skipping to change at page 9, line 6
A A
| |
| FD(A) = 1 | FD(A) = 1
S |1 S |1
\ | D(B) = 2 \ | D(B) = 2
2 \| FD(B) = 2 2 \| FD(B) = 2
B B
The only route available from A to S, the one that goes through B, is The only route available from A to S, the one that goes through B, is
not feasible: A suffers from spurious starvation. At this point, the not feasible: A suffers from spurious starvation. At that point, the
whole network must be rebooted in order to solve the starvation; this whole subtree suffering from starvation must be reset, which is
is essentially what EIGRP does when it performs a global essentially what EIGRP does when it performs a global synchronisation
synchronisation of all the routers in the network with the source of all the routers in the sarving subtree (the "active" phase of
(the "active" phase of EIGRP). EIGRP).
Babel reacts to starvation in a less drastic manner, by using Babel reacts to starvation in a less drastic manner, by using
sequenced routes, a technique introduced by DSDV and adopted by AODV. sequenced routes, a technique introduced by DSDV and adopted by AODV.
In addition to a metric, every route carries a sequence number, a In addition to a metric, every route carries a sequence number, a
nondecreasing integer that is propagated unchanged through the nondecreasing integer that is propagated unchanged through the
network and is only ever incremented by the source; a pair (s, m), 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. 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 A received update is feasible when either it is more recent than the
feasibility distance maintained by the receiving node, or it is feasibility distance maintained by the receiving node, or it is
skipping to change at page 11, line 23 skipping to change at page 11, line 23
Suppose that both default routes fail at the same time; then nothing Suppose that both default routes fail at the same time; then nothing
prevents A from switching to B, and B simultaneously switching to A. 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, However, as soon as A has successfully advertised the new route to B,
the route through A will become unfeasible for B. Conversely, as the route through A will become unfeasible for B. Conversely, as
soon as B will have advertised the route through A, the route through soon as B will have advertised the route through A, the route through
B will become unfeasible for A. B will become unfeasible for A.
In effect, the routing loop disappears at the latest when routing In effect, the routing loop disappears at the latest when routing
information has gone around the loop. Since this process can be information has gone around the loop. Since this process can be
delayed by lost packets, Babel makes certain efforts to ensure that delayed by lost packets, Babel makes certain efforts to ensure that
updates are sent reliably after a router-id change Section 3.7.2. updates are sent reliably after a router-id change (Section 3.7.2).
Additionally, after the routers have advertised the two routes, both Additionally, after the routers have advertised the two routes, both
sources will be in their source tables, which will prevent them from sources will be in their source tables, which will prevent them from
ever again participating in a routing loop involving routes from S ever again participating in a routing loop involving routes from S
and S' (up to the source GC time, which, available memory permitting, and S' (up to the source GC time, which, available memory permitting,
can be set to arbitrarily large values). can be set to arbitrarily large values).
2.8. Overlapping Prefixes 2.8. Overlapping Prefixes
In the above discussion, we have assumed that all prefixes are In the above discussion, we have assumed that all prefixes are
skipping to change at page 12, line 16 skipping to change at page 12, line 16
Every Babel speaker is assigned a router-id, which is an arbitrary Every Babel speaker is assigned a router-id, which is an arbitrary
string of 8 octets that is assumed unique across the routing domain. string of 8 octets that is assumed unique across the routing domain.
For example, routers-ids could be assigned randomly, or they could For example, routers-ids could be assigned randomly, or they could
derived from a link-layer address. (The protocol encoding is derived from a link-layer address. (The protocol encoding is
slightly more compact when router-ids are assigned in the same manner slightly more compact when router-ids are assigned in the same manner
as the IPv6 layer assigns host IDs.) as the IPv6 layer assigns host IDs.)
3.1. Message Transmission and Reception 3.1. Message Transmission and Reception
Babel protocol packets are sent in the body of a UDP datagram. Each Babel protocol packets are sent in the body of a UDP datagram (as
Babel packet consists of zero or more TLVs. Most TLVs may contain described in Section 4 below). Each Babel packet consists of zero or
sub-TLVs. more TLVs. Most TLVs may contain sub-TLVs.
The source address of a Babel packet is always a unicast address, 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- 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 known (link-local) multicast address or to a (link-local) unicast
address. In normal operation, a Babel speaker sends both multicast address. In normal operation, a Babel speaker sends both multicast
and unicast packets to its neighbours. and unicast packets to its neighbours.
With the exception of Hello TLVs and acknowledgments, all Babel TLVs With the exception of Hello TLVs and acknowledgments, all Babel TLVs
can be sent to either unicast or multicast addresses, and their can be sent to either unicast or multicast addresses, and their
semantics does not depend on whether the destination is a unicast or semantics does not depend on whether the destination is a unicast or
skipping to change at page 17, line 49 skipping to change at page 17, line 49
below). If the time interval is set to 0, then the Hello TLV does 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 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 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 recent scheduled Hello of the right kind was received at time t0 and
carried interval i, then the previous promise of sending another carried interval i, then the previous promise of sending another
Hello before time t0 + i still holds). We say that a Hello is Hello before time t0 + i still holds). We say that a Hello is
"scheduled" if it carries a non-zero interval, and "unscheduled" "scheduled" if it carries a non-zero interval, and "unscheduled"
otherwise. otherwise.
There are two kinds of Hellos: Multicast Hellos, which use a per- There are two kinds of Hellos: Multicast Hellos, which use a per-
interface Hello counter, and Unicast Hellos, which use a per- interface Hello counter (the Multicast Hello seqno), and Unicast
neighbour counter. A Multicast Hello with a given seqno MUST be sent Hellos, which use a per-neighbour counter (the Multicast Hello
to all neighbours on a given interface, either by sending it to a seqno). A Multicast Hello with a given seqno MUST be sent to all
multicast address or by sending it to one unicast address per neighbours on a given interface, either by sending it to a multicast
neighbour (hence, the term "Multicast Hello" is a slight misnomer). address or by sending it to one unicast address per neighbour (hence,
A Unicast Hello carrying a given seqno should normally be sent to the term "Multicast Hello" is a slight misnomer). A Unicast Hello
just one neighbour (over unicast), since the sequence numbers of carrying a given seqno should normally be sent to just one neighbour
different neighbours are not in general synchronised. (over unicast), since the sequence numbers of different neighbours
are not in general synchronised.
Multicast Hellos sent over multicast can be used for neighbour Multicast Hellos sent over multicast can be used for neighbour
discovery; hence, a node SHOULD send periodic (scheduled) Multicast discovery; hence, a node SHOULD send periodic (scheduled) Multicast
Hellos unless neighbour discovery is performed by means outside of Hellos unless neighbour discovery is performed by means outside of
the Babel protocol. A node MAY send Unicast Hellos or unscheduled the Babel protocol. A node MAY send Unicast Hellos or unscheduled
Hellos of either kind for any reason, such as reducing the amount of Hellos of either kind for any reason, such as reducing the amount of
multicast traffic or improving reliability on link technologies with multicast traffic or improving reliability on link technologies with
poor support for link-layer multicast. poor support for link-layer multicast.
A node MAY send a scheduled Hello ahead of time. A node MAY change A node MAY send a scheduled Hello ahead of time. A node MAY change
skipping to change at page 21, line 45 skipping to change at page 21, line 48
Babel is concerned, the function M(c, m) used for computing a metric Babel is concerned, the function M(c, m) used for computing a metric
from a locally computed link cost and the metric advertised by a from a locally computed link cost and the metric advertised by a
neighbour MUST only satisfy the following conditions: neighbour MUST only satisfy the following conditions:
o if c is infinite, then M(c, m) is infinite; o if c is infinite, then M(c, m) is infinite;
o M is strictly monotonic: M(c, m) > m. o M is strictly monotonic: M(c, m) > m.
Additionally, the metric SHOULD satisfy the following condition: Additionally, the metric SHOULD satisfy the following condition:
o M is isotonic: if m <= m', then M(c, m) <= M(c, m'). o M is left-distributive: if m <= m', then M(c, m) <= M(c, m').
Note that while strict monotonicity is essential to the integrity of Note that while strict monotonicity is essential to the integrity of
the network (persistent routing loops may arise if it is not the network (persistent routing loops may arise if it is not
satisfied), isotonicity is not: if it is not satisfied, Babel will satisfied), left distributivity is not: if it is not satisfied, Babel
still converge to a loop-free configuration, but might not reach a will still converge to a loop-free configuration, but might not reach
global optimum (in fact, a global optimum may not even exist). a global optimum (in fact, a global optimum may not even exist).
As with cost computation, not all strategies for computing route As with cost computation, not all strategies for computing route
metrics will give good results. In particular, some metrics are more metrics will give good results. In particular, some metrics are more
likely than others to lead to routing instabilities (route flapping). likely than others to lead to routing instabilities (route flapping).
In Appendix A.3, we give a number of examples of strictly monotonic, In Appendix A.3, we give a number of examples of strictly monotonic,
isotonic routing metrics that are known to work well in practice. left-distributive routing metrics that are known to work well in
practice.
3.5.3. Encoding of Updates 3.5.3. Encoding of Updates
In a large network, the bulk of Babel traffic consists of route In a large network, the bulk of Babel traffic consists of route
updates; hence, some care has been given to encoding them updates; hence, some care has been given to encoding them
efficiently. An Update TLV itself only contains the prefix, seqno, efficiently. An Update TLV itself only contains the prefix, seqno,
and metric, while the next hop is derived either from the network- and metric, while the next hop is derived either from the network-
layer source address of the packet or from an explicit Next Hop TLV layer source address of the packet or from an explicit Next Hop TLV
in the same packet. The router-id is derived from a separate Router- in the same packet. The router-id is derived from a separate Router-
Id TLV in the same packet, which optimises the case when multiple Id TLV in the same packet, which optimises the case when multiple
skipping to change at page 28, line 24 skipping to change at page 28, line 24
request. request.
The exact behaviour is different for route requests and seqno The exact behaviour is different for route requests and seqno
requests. requests.
3.8.1.1. Route Requests 3.8.1.1. Route Requests
When a node receives a route request for a given prefix, it checks 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 its route table for a selected route to this exact prefix. If such a
route exists, it MUST send an update (over unicast or over route exists, it MUST send an update (over unicast or over
multicast); if such a route does not, it MUST send a retraction for multicast); if such a route does not exist, it MUST send a retraction
that prefix. for that prefix.
When a node receives a wildcard route request, it SHOULD send a full When a node receives a wildcard route request, it SHOULD send a full
route table dump. Full route dumps MAY be rate-limited, especially route table dump. Full route dumps MAY be rate-limited, especially
if they are sent over multicast. if they are sent over multicast.
3.8.1.2. Seqno Requests 3.8.1.2. Seqno Requests
When a node receives a seqno request for a given router-id and When a node receives a seqno request for a given router-id and
sequence number, it checks whether its route table contains a sequence number, it checks whether its route table contains a
selected entry for that prefix. If a selected route for the given selected entry for that prefix. If a selected route for the given
skipping to change at page 29, line 19 skipping to change at page 29, line 19
o otherwise, if the node has one or more (not necessarily feasible) o otherwise, if the node has one or more (not necessarily feasible)
routes to the requested prefix with a next hop that is not the routes to the requested prefix with a next hop that is not the
requesting node, then the node SHOULD forward the request to the requesting node, then the node SHOULD forward the request to the
next hop of one such route. next hop of one such route.
In order to actually forward the request, the node decrements the hop In order to actually forward the request, the node decrements the hop
count and sends the request in a unicast packet destined to the count and sends the request in a unicast packet destined to the
selected neighbour. selected neighbour.
A node SHOULD maintain a list of recently forwarded seqno requests A node SHOULD maintain a list of recently forwarded seqno requests
and forward the reply (an update with a sufficiently large seqno) in and forward the reply (an update with a seqno sufficiently large to
a timely manner. A node SHOULD compare every incoming seqno request satisfy the request) in a timely manner. A node SHOULD compare every
against its list of recently forwarded seqno requests and avoid incoming seqno request against its list of recently forwarded seqno
forwarding it if it is redundant (i.e., if it has recently sent a requests and avoid forwarding it if it is redundant (i.e., if it has
request with the same prefix, router-id and a seqno that is not recently sent a request with the same prefix, router-id and a seqno
smaller modulo 2^16). that is not smaller modulo 2^16).
Since the request-forwarding mechanism does not necessarily obey the Since the request-forwarding mechanism does not necessarily obey the
feasibility condition, it may get caught in routing loops; hence, feasibility condition, it may get caught in routing loops; hence,
requests carry a hop count to limit the time during which they remain requests carry a hop count to limit the time during which they remain
in the network. However, since requests are only ever forwarded as in the network. However, since requests are only ever forwarded as
unicast packets, the initial hop count need not be kept particularly unicast packets, the initial hop count need not be kept particularly
low, and performing an expanding horizon search is not necessary. A low, and performing an expanding horizon search is not necessary. A
single request MUST NOT be duplicated: it MUST NOT be forwarded to a single request MUST NOT be duplicated: it MUST NOT be forwarded to a
multicast address, and it MUST NOT be forwarded to multiple multicast address, and it MUST NOT be forwarded to multiple
neighbours. However, if a seqno request is resent by its originator, neighbours. However, if a seqno request is resent by its originator,
skipping to change at page 33, line 16 skipping to change at page 33, line 16
A network prefix is encoded just like a network address, but it is 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 stored in the smallest number of octets that are enough to hold the
significant bits (up to the prefix length). significant bits (up to the prefix length).
4.2. Packet Format 4.2. Packet Format
A Babel packet consists of a 4-octet header, followed by a sequence A Babel packet consists of a 4-octet header, followed by a sequence
of TLVs. of TLVs.
0 1 2 3 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 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 | | Magic | Version | Body length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Body ... | Packet Body ...
+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-
Fields : Fields :
Magic The arbitrary but carefully chosen value 42 (decimal); Magic The arbitrary but carefully chosen value 42 (decimal);
packets with a first octet different from 42 MUST be packets with a first octet different from 42 MUST be
skipping to change at page 33, line 46 skipping to change at page 33, line 46
fields). fields).
Body The packet body; a sequence of TLVs. Body The packet body; a sequence of TLVs.
Any data following the body MUST be silently ignored. Any data following the body MUST be silently ignored.
4.3. TLV Format 4.3. TLV Format
With the exception of Pad1, all TLVs have the following structure: With the exception of Pad1, all TLVs have the following structure:
0 1 2 3 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 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... | Type | Length | Payload...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Fields : Fields :
Type The type of the TLV. Type The type of the TLV.
Length The length of the body, exclusive of the Type and Length Length The length of the body, exclusive of the Type and Length
fields. If the body is longer than the expected length of fields. If the body is longer than the expected length of
skipping to change at page 35, line 34 skipping to change at page 35, line 34
Since the parser state is separate from the bulk of Babel's state, Since the parser state is separate from the bulk of Babel's state,
and since for correct parsing it must be identical across and since for correct parsing it must be identical across
implementations, it is updated before checking for mandatory TLVs: implementations, it is updated before checking for mandatory TLVs:
parsing a TLV MUST update the parser state even if the TLV is parsing a TLV MUST update the parser state even if the TLV is
otherwise ignored due to an unknown mandatory sub-TLV. otherwise ignored due to an unknown mandatory sub-TLV.
4.6. Details of Specific TLVs 4.6. Details of Specific TLVs
4.6.1. Pad1 4.6.1. Pad1
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Type = 0 | | Type = 0 |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Fields : Fields :
Type Set to 0 to indicate a Pad1 TLV. Type Set to 0 to indicate a Pad1 TLV.
This TLV is silently ignored on reception. This TLV is silently ignored on reception.
4.6.2. PadN 4.6.2. PadN
0 1 2 3 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 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... | Type = 1 | Length | MBZ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Fields : Fields :
Type Set to 1 to indicate a PadN TLV. Type Set to 1 to indicate a PadN TLV.
Length The length of the body, exclusive of the Type and Length Length The length of the body, exclusive of the Type and Length
fields. fields.
MBZ Set to 0 on transmission. MBZ Set to 0 on transmission.
This TLV is silently ignored on reception. This TLV is silently ignored on reception.
4.6.3. Acknowledgment Request 4.6.3. Acknowledgment Request
0 1 2 3 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 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 | | Type = 2 | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce | Interval | | Nonce | Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV requests that the receiver send an Acknowledgment TLV within This TLV requests that the receiver send an Acknowledgment TLV within
the number of centiseconds specified by the Interval field. the number of centiseconds specified by the Interval field.
Fields : Fields :
skipping to change at page 37, line 7 skipping to change at page 37, line 7
Interval A time interval in centiseconds after which the sender will Interval A time interval in centiseconds after which the sender will
assume that this packet has been lost. This MUST NOT be 0. assume that this packet has been lost. This MUST NOT be 0.
The receiver MUST send an Acknowledgment TLV before this The receiver MUST send an Acknowledgment TLV before this
time has elapsed (with a margin allowing for propagation time has elapsed (with a margin allowing for propagation
time). time).
This TLV is self-terminating, and allows sub-TLVs. This TLV is self-terminating, and allows sub-TLVs.
4.6.4. Acknowledgment 4.6.4. Acknowledgment
0 1 2 3 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 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 | Nonce | | Type = 3 | Length | Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV is sent by a node upon receiving an Acknowledgment Request. This TLV is sent by a node upon receiving an Acknowledgment Request.
Fields : Fields :
Type Set to 3 to indicate an Acknowledgment TLV. Type Set to 3 to indicate an Acknowledgment TLV.
skipping to change at page 37, line 32 skipping to change at page 37, line 32
Nonce Set to the Nonce value of the Acknowledgment Request that Nonce Set to the Nonce value of the Acknowledgment Request that
prompted this Acknowledgment. prompted this Acknowledgment.
Since nonce values are not globally unique, this TLV MUST be sent to Since nonce values are not globally unique, this TLV MUST be sent to
a unicast address. a unicast address.
This TLV is self-terminating, and allows sub-TLVs. This TLV is self-terminating, and allows sub-TLVs.
4.6.5. Hello 4.6.5. Hello
0 1 2 3 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 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 | | Type = 4 | Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seqno | Interval | | Seqno | Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV is used for neighbour discovery and for determining a This TLV is used for neighbour discovery and for determining a
neighbour's reception cost. neighbour's reception cost.
Fields : Fields :
skipping to change at page 38, line 19 skipping to change at page 38, line 19
Interval If non-zero, this is an upper bound, expressed in Interval If non-zero, this is an upper bound, expressed in
centiseconds, on the time after which the sending node will centiseconds, on the time after which the sending node will
send a new scheduled Hello TLV with the same setting of the send a new scheduled Hello TLV with the same setting of the
Unicast flag. If this is 0, then this Hello represents an Unicast flag. If this is 0, then this Hello represents an
unscheduled Hello, and doesn't carry any new information unscheduled Hello, and doesn't carry any new information
about times at which Hellos are sent. about times at which Hellos are sent.
The Flags field is interpreted as follows: The Flags field is interpreted as follows:
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| |U|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o U (Unicast) flag (8000 hexadecimal): if set, then this Hello o U (Unicast) flag (8000 hexadecimal): if set, then this Hello
represents a Unicast Hello, otherwise it represents a Multicast represents a Unicast Hello, otherwise it represents a Multicast
Hello; Hello;
o X: all other bits MUST be sent as 0 and silently ignored on o X: all other bits MUST be sent as 0 and silently ignored on
reception. reception.
skipping to change at page 39, line 4 skipping to change at page 39, line 4
destination, or by sending multiple packets to the unicast addresses destination, or by sending multiple packets to the unicast addresses
of all reachable neighbours. Conversely, if the Unicast flag is set, of all reachable neighbours. Conversely, if the Unicast flag is set,
this TLV MUST be sent to a single neighbour, which can achieved by this TLV MUST be sent to a single neighbour, which can achieved by
sending to a unicast destination. In order to avoid large sending to a unicast destination. In order to avoid large
discontinuities in link quality, multiple Hello TLVs SHOULD NOT be discontinuities in link quality, multiple Hello TLVs SHOULD NOT be
sent in the same packet. sent in the same packet.
This TLV is self-terminating, and allows sub-TLVs. This TLV is self-terminating, and allows sub-TLVs.
4.6.6. IHU 4.6.6. IHU
0 1 2 3 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 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 | | Type = 5 | Length | AE | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rxcost | Interval | | Rxcost | Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address... | Address...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
An IHU ("I Heard You") TLV is used for confirming bidirectional An IHU ("I Heard You") TLV is used for confirming bidirectional
reachability and carrying a link's transmission cost. reachability and carrying a link's transmission cost.
skipping to change at page 40, line 12 skipping to change at page 40, line 12
ARP or Neighbour Discovery exchange when a neighbour is not being ARP or Neighbour Discovery exchange when a neighbour is not being
used for data traffic. used for data traffic.
IHU TLVs with an unknown value in the AE field MUST be silently IHU TLVs with an unknown value in the AE field MUST be silently
ignored. ignored.
This TLV is self-terminating, and allows sub-TLVs. This TLV is self-terminating, and allows sub-TLVs.
4.6.7. Router-Id 4.6.7. Router-Id
0 1 2 3 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 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 | | Type = 6 | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Router-Id + + Router-Id +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A Router-Id TLV establishes a router-id that is implied by subsequent A Router-Id TLV establishes a router-id that is implied by subsequent
Update TLVs. This TLV sets the router-id even if it is otherwise Update TLVs. This TLV sets the router-id even if it is otherwise
skipping to change at page 40, line 42 skipping to change at page 40, line 42
Reserved Sent as 0 and MUST be ignored on reception. Reserved Sent as 0 and MUST be ignored on reception.
Router-Id The router-id for routes advertised in subsequent Update Router-Id The router-id for routes advertised in subsequent Update
TLVs. This MUST NOT consist of all zeroes or all ones. TLVs. This MUST NOT consist of all zeroes or all ones.
This TLV is self-terminating, and allows sub-TLVs. This TLV is self-terminating, and allows sub-TLVs.
4.6.8. Next Hop 4.6.8. Next Hop
0 1 2 3 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 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 | | Type = 7 | Length | AE | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next hop... | Next hop...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
A Next Hop TLV establishes a next-hop address for a given address A Next Hop TLV establishes a next-hop address for a given address
family (IPv4 or IPv6) that is implied in subsequent Update TLVs. family (IPv4 or IPv6) that is implied in subsequent Update TLVs.
This TLV sets up the next-hop for subsequent Update TLVs even if it This TLV sets up the next-hop for subsequent Update TLVs even if it
is otherwise ignored due to an unknown mandatory sub-TLV. is otherwise ignored due to an unknown mandatory sub-TLV.
Fields : Fields :
Type Set to 7 to indicate a Next Hop TLV. Type Set to 7 to indicate a Next Hop TLV.
Length The length of the body, exclusive of the Type and Length Length The length of the body, exclusive of the Type and Length
fields. fields.
AE The encoding of the Address field. This SHOULD be 1 or 3 AE The encoding of the Address field. This SHOULD be 1 (IPv4)
and MUST NOT be 0. or 3 (link-local IPv6), and MUST NOT be 0.
Reserved Sent as 0 and MUST be ignored on reception. Reserved Sent as 0 and MUST be ignored on reception.
Next hop The next-hop address advertised by subsequent Update TLVs, Next hop The next-hop address advertised by subsequent Update TLVs,
for this address family. for this address family.
When the address family matches the network-layer protocol that this When the address family matches the network-layer protocol that this
packet is transported over, a Next Hop TLV is not needed: in the packet is transported over, a Next Hop TLV is not needed: in the
absence of a Next Hop TLV in a given address family, the next hop 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. address is taken to be the source address of the packet.
Next Hop TLVs with an unknown value for the AE field MUST be silently Next Hop TLVs with an unknown value for the AE field MUST be silently
ignored. ignored.
This TLV is self-terminating, and allows sub-TLVs. This TLV is self-terminating, and allows sub-TLVs.
4.6.9. Update 4.6.9. Update
0 1 2 3 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 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 | | Type = 8 | Length | AE | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Plen | Omitted | Interval | | Plen | Omitted | Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seqno | Metric | | Seqno | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix... | Prefix...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
skipping to change at page 42, line 41 skipping to change at page 42, line 41
Metric The sender's metric for this route. The value FFFF Metric The sender's metric for this route. The value FFFF
hexadecimal (infinity) means that this is a route hexadecimal (infinity) means that this is a route
retraction. retraction.
Prefix The prefix being advertised. This field's size is Prefix The prefix being advertised. This field's size is
(Plen/8 - Omitted) rounded upwards. (Plen/8 - Omitted) rounded upwards.
The Flags field is interpreted as follows: The Flags field is interpreted as follows:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|P|R|X|X|X|X|X|X| |P|R|X|X|X|X|X|X|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
o P (Prefix) flag (80 hexadecimal): if set, then this Update o P (Prefix) flag (80 hexadecimal): if set, then this Update
establishes a new default prefix for subsequent Update TLVs with a establishes a new default prefix for subsequent Update TLVs with a
matching address encoding within the same packet, even if this TLV matching address encoding within the same packet, even if this TLV
is otherwise ignored due to an unknown mandatory sub-TLV; is otherwise ignored due to an unknown mandatory sub-TLV;
o R (Router-Id) flag (40 hexadecimal): if set, then this TLV o R (Router-Id) flag (40 hexadecimal): if set, then this TLV
skipping to change at page 44, line 14 skipping to change at page 44, line 14
metric is finite, AE MUST NOT be 0. If the metric is infinite and AE metric is finite, AE MUST NOT be 0. If the metric is infinite and AE
is 0, Plen and Omitted MUST both be 0. is 0, Plen and Omitted MUST both be 0.
Update TLVs with an unknown value in the AE field MUST be silently Update TLVs with an unknown value in the AE field MUST be silently
ignored. ignored.
This TLV is self-terminating, and allows sub-TLVs. This TLV is self-terminating, and allows sub-TLVs.
4.6.10. Route Request 4.6.10. Route Request
0 1 2 3 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 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 | | Type = 9 | Length | AE | Plen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix... | Prefix...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
A Route Request TLV prompts the receiver to send an update for a A Route Request TLV prompts the receiver to send an update for a
given prefix, or a full route table dump. given prefix, or a full route table dump.
Fields : Fields :
skipping to change at page 45, line 7 skipping to change at page 45, line 7
A Request TLV prompts the receiver to send an update message A Request TLV prompts the receiver to send an update message
(possibly a retraction) for the prefix specified by the AE, Plen, and (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 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). case Plen MUST be 0 and Prefix is of length 0).
This TLV is self-terminating, and allows sub-TLVs. This TLV is self-terminating, and allows sub-TLVs.
4.6.11. Seqno Request 4.6.11. Seqno Request
0 1 2 3 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 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 | | Type = 10 | Length | AE | Plen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seqno | Hop Count | Reserved | | Seqno | Hop Count | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Router-Id + + Router-Id +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix... | Prefix...
skipping to change at page 46, line 19 skipping to change at page 46, line 19
be forwarded to a multicast address and MUST NOT be forwarded to more be forwarded to a multicast address and MUST NOT be forwarded to more
than one neighbour. A request MUST NOT be forwarded if its Hop Count than one neighbour. A request MUST NOT be forwarded if its Hop Count
field is 1. field is 1.
This TLV is self-terminating, and allows sub-TLVs. This TLV is self-terminating, and allows sub-TLVs.
4.7. Details of specific sub-TLVs 4.7. Details of specific sub-TLVs
4.7.1. Pad1 4.7.1. Pad1
0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Type = 0 | | Type = 0 |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Fields : Fields :
Type Set to 0 to indicate a Pad1 sub-TLV. Type Set to 0 to indicate a Pad1 sub-TLV.
This sub-TLV is silently ignored on reception. It is allowed within This sub-TLV is silently ignored on reception. It is allowed within
skipping to change at page 48, line 45 skipping to change at page 48, line 45
sent from a link-local IPv6 address; since routers don't forward sent from a link-local IPv6 address; since routers don't forward
link-local IPv6 packets, this provides protection against spoofed link-local IPv6 packets, this provides protection against spoofed
Babel packets being sent from the global Internet. No such natural Babel packets being sent from the global Internet. No such natural
protection exists when Babel packets are carried over IPv4. protection exists when Babel packets are carried over IPv4.
7. Acknowledgments 7. Acknowledgments
A number of people have contributed text and ideas to this A number of people have contributed text and ideas to this
specification. The authors are particularly indebted to Matthieu specification. The authors are particularly indebted to Matthieu
Boutier, Gwendoline Chouasne, Margaret Cullen, Donald Eastlake and Boutier, Gwendoline Chouasne, Margaret Cullen, Donald Eastlake and
Toke Hoiland-Jorgensen. The address compression technique was Toke Hoiland-Jorgensen. Earlier versions of this document greatly
inspired by [PACKETBB]. benefited from the input of Joel Halpern. The address compression
technique was inspired by [PACKETBB].
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017.
8.2. Informative References 8.2. Informative References
[DSDV] Perkins, C. and P. Bhagwat, "Highly Dynamic Destination- [DSDV] Perkins, C. and P. Bhagwat, "Highly Dynamic Destination-
Sequenced Distance-Vector Routing (DSDV) for Mobile Sequenced Distance-Vector Routing (DSDV) for Mobile
Computers", ACM SIGCOMM'94 Conference on Communications Computers", ACM SIGCOMM'94 Conference on Communications
Architectures, Protocols and Applications 234-244, 1994. Architectures, Protocols and Applications 234-244, 1994.
[DUAL] Garcia Luna Aceves, J., "Loop-Free Routing Using Diffusing [DUAL] Garcia Luna Aceves, J., "Loop-Free Routing Using Diffusing
Computations", IEEE/ACM Transactions on Networking 1:1, Computations", IEEE/ACM Transactions on Networking 1:1,
February 1993. February 1993.
skipping to change at page 53, line 7 skipping to change at page 53, line 14
unless they send periodic Multicast Hellos (possibly in addition to unless they send periodic Multicast Hellos (possibly in addition to
Unicast Hellos). Unicast Hellos).
A.3. Metric Computation A.3. Metric Computation
As described in Section 3.5.2, the metric advertised by a neighbour As described in Section 3.5.2, the metric advertised by a neighbour
is combined with the link cost to yield a metric. is combined with the link cost to yield a metric.
A.3.1. Additive Metrics A.3.1. Additive Metrics
The simplest approach for obtaining a monotonic, isotonic metric is The simplest approach for obtaining a monotonic, left-distributive
to define the metric of a route as the sum of the costs of the metric is to define the metric of a route as the sum of the costs of
component links. More formally, if a neighbour advertises a route the component links. More formally, if a neighbour advertises a
with metric m over a link with cost c, then the resulting route has route with metric m over a link with cost c, then the resulting route
metric M(c, m) = c + m. has metric M(c, m) = c + m.
A multiplicative metric can be converted into an additive one by A multiplicative metric can be converted into an additive one by
taking the logarithm (in some suitable base) of the link costs. taking the logarithm (in some suitable base) of the link costs.
A.3.2. External Sources of Willingness A.3.2. External Sources of Willingness
A node may want to vary its willingness to forward packets by taking A node may want to vary its willingness to forward packets by taking
into account information that is external to the Babel protocol, such into account information that is external to the Babel protocol, such
as the monetary cost of a link, the node's battery status, CPU load, as the monetary cost of a link, the node's battery status, CPU load,
etc. This can be done by adding to every route's metric a value k etc. This can be done by adding to every route's metric a value k
skipping to change at page 58, line 44 skipping to change at page 59, line 7
o Renamed routing table back to route table. o Renamed routing table back to route table.
o Made buffering outgoing updates a SHOULD. o Made buffering outgoing updates a SHOULD.
o Weakened advice to use modified EUI-64 in router-ids. o Weakened advice to use modified EUI-64 in router-ids.
o Added information about sending requests to Appendix B. o Added information about sending requests to Appendix B.
o A number of minor wording changes and clarifications. o A number of minor wording changes and clarifications.
F.6. Changes since draft-ietf-babel-rfc6126bis-03
Minor editorial changes.
F.7. Changes since draft-ietf-babel-rfc6126bis-04
o Renamed isotonicity to left-distributivity.
o Minor clarifications to unicast hellos.
o Updated requirements boilerplate to RFC 8174.
o Minor editorial changes.
Authors' Addresses Authors' Addresses
Juliusz Chroboczek Juliusz Chroboczek
IRIF, University of Paris-Diderot IRIF, University of Paris-Diderot
Case 7014 Case 7014
75205 Paris Cedex 13 75205 Paris Cedex 13
France France
Email: jch@irif.fr Email: jch@irif.fr
David Schinazi David Schinazi
Apple Inc. Apple Inc.
1 Infinite Loop 1 Infinite Loop
Cupertino, California 95014 Cupertino, California 95014
US US
Email: dschinazi@apple.com Email: dschinazi@apple.com
 End of changes. 48 change blocks. 
92 lines changed or deleted 121 lines changed or added

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