< draft-ietf-babel-rfc6126bis-11.txt   draft-ietf-babel-rfc6126bis-12.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 Google LLC Intended status: Standards Track Google LLC
Expires: December 31, 2019 June 29, 2019 Expires: February 8, 2020 August 7, 2019
The Babel Routing Protocol The Babel Routing Protocol
draft-ietf-babel-rfc6126bis-11 draft-ietf-babel-rfc6126bis-12
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. This document describes the Babel routing protocol, mesh networks. This document describes the Babel routing protocol,
and obsoletes RFCs 6126 and 7557. and obsoletes RFCs 6126 and 7557.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 https://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 December 31, 2019. This Internet-Draft will expire on February 8, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://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
skipping to change at page 3, line 16 skipping to change at page 3, line 16
F.4. Changes since draft-ietf-babel-rfc6126bis-02 . . . . . . 59 F.4. Changes since draft-ietf-babel-rfc6126bis-02 . . . . . . 59
F.5. Changes since draft-ietf-babel-rfc6126bis-03 . . . . . . 59 F.5. Changes since draft-ietf-babel-rfc6126bis-03 . . . . . . 59
F.6. Changes since draft-ietf-babel-rfc6126bis-03 . . . . . . 60 F.6. Changes since draft-ietf-babel-rfc6126bis-03 . . . . . . 60
F.7. Changes since draft-ietf-babel-rfc6126bis-04 . . . . . . 60 F.7. Changes since draft-ietf-babel-rfc6126bis-04 . . . . . . 60
F.8. Changes since draft-ietf-babel-rfc6126bis-05 . . . . . . 60 F.8. Changes since draft-ietf-babel-rfc6126bis-05 . . . . . . 60
F.9. Changes since draft-ietf-babel-rfc6126bis-06 . . . . . . 60 F.9. Changes since draft-ietf-babel-rfc6126bis-06 . . . . . . 60
F.10. Changes since draft-ietf-babel-rfc6126bis-07 . . . . . . 60 F.10. Changes since draft-ietf-babel-rfc6126bis-07 . . . . . . 60
F.11. Changes since draft-ietf-babel-rfc6126bis-08 . . . . . . 60 F.11. Changes since draft-ietf-babel-rfc6126bis-08 . . . . . . 60
F.12. Changes since draft-ietf-babel-rfc6126bis-09 . . . . . . 61 F.12. Changes since draft-ietf-babel-rfc6126bis-09 . . . . . . 61
F.13. Changes since draft-ietf-babel-rfc6126bis-10 . . . . . . 61 F.13. Changes since draft-ietf-babel-rfc6126bis-10 . . . . . . 61
F.14. Changes since draft-ietf-babel-rfc6126bis-11 . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61
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.
skipping to change at page 3, line 48 skipping to change at page 3, line 49
by using sequenced routes, a technique pioneered by Destination- by using sequenced routes, a technique pioneered by Destination-
Sequenced Distance-Vector routing [DSDV]. Sequenced Distance-Vector routing [DSDV].
More precisely, Babel has the following properties: More precisely, Babel has the following properties:
o when every prefix is originated by at most one router, Babel never o when every prefix is originated by at most one router, Babel never
suffers from routing loops; suffers from routing loops;
o when a single prefix is originated by multiple routers, Babel may o when a single prefix is originated by multiple routers, Babel may
occasionally create a transient routing loop for this particular occasionally create a transient routing loop for this particular
prefix; this loop disappears in a time proportional to its prefix; this loop disappears in time proportional to the loop's
diameter, and never again (up to an arbitrary garbage-collection diameter, and never again (up to an arbitrary garbage-collection
(GC) time) will the routers involved participate in a routing loop (GC) time) will the routers involved participate in a routing loop
for the same prefix; for the same prefix;
o assuming bounded packet loss rates, any routing black-holes that o assuming bounded packet loss rates, any routing black-holes that
may appear after a mobility event are corrected in a time at most may appear after a mobility event are corrected in a time at most
proportional to the network's diameter. proportional to the network's diameter.
Babel has provisions for link quality estimation and for fairly Babel has provisions for link quality estimation and for fairly
arbitrary metrics. When configured suitably, Babel can implement arbitrary metrics. When configured suitably, Babel can implement
skipping to change at page 12, line 23 skipping to change at page 12, line 23
the former route has been retracted by all of B's neighbours the former route has been retracted by all of B's neighbours
(Section 3.5.5). (Section 3.5.5).
3. Protocol Operation 3. Protocol Operation
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, router-ids could be assigned randomly, or they could be For example, router-ids could be assigned randomly, or they could be
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, see the definition of the "R"
flag in Section 4.6.9.)
3.1. Message Transmission and Reception 3.1. Message Transmission and Reception
Babel protocol packets are sent in the body of a UDP datagram (as Babel protocol packets are sent in the body of a UDP datagram (as
described in Section 4 below). Each Babel packet consists of zero or described in Section 4 below). Each Babel packet consists of zero or
more TLVs. Most TLVs may contain sub-TLVs. more TLVs. Most TLVs may contain sub-TLVs.
The protocol's control traffic can be carried indifferently over IPv6
or over IPv4, and prefixes of either address family can be announced
over either protocol. Thus, there are at least two natural
deployment models: using IPv6 exclusively for all control traffic, or
running two distinct protocol instances, one for each address family.
The exclusive use of IPv6 for all control traffic is RECOMMENDED,
since using both protocols at the same time doubles the amount of
traffic devoted to neighbour discovery and link quality estimation.
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 acknowledgments, all Babel TLVs can be sent to With the exception of acknowledgments, all Babel TLVs can be sent to
either unicast or multicast addresses, and their semantics does not either unicast or multicast addresses, and their semantics does not
depend on whether the destination is a unicast or a multicast depend on whether the destination is a unicast or a multicast
address. Hence, a Babel speaker does not need to determine the address. Hence, a Babel speaker does not need to determine the
skipping to change at page 32, line 49 skipping to change at page 32, line 49
Relative times are carried as 16-bit values specifying a number of Relative times are carried as 16-bit values specifying a number of
centiseconds (hundredths of a second). This allows times up to centiseconds (hundredths of a second). This allows times up to
roughly 11 minutes with a granularity of 10ms, which should cover all roughly 11 minutes with a granularity of 10ms, which should cover all
reasonable applications of Babel. reasonable applications of Babel.
4.1.2. Router-Id 4.1.2. Router-Id
A router-id is an arbitrary 8-octet value. A router-id MUST NOT A router-id is an arbitrary 8-octet value. A router-id MUST NOT
consist of either all binary zeroes (0000000000000000 hexadecimal) or consist of either all binary zeroes (0000000000000000 hexadecimal) or
all binary ones ones (ffffffffffffffff hexadecimal). all binary ones ones (FFFFFFFFFFFFFFFF hexadecimal).
4.1.3. Address 4.1.3. Address
Since the bulk of the protocol is taken by addresses, multiple ways Since the bulk of the protocol is taken by addresses, multiple ways
of encoding addresses are defined. Additionally, a common subnet of encoding addresses are defined. Additionally, a common subnet
prefix may be omitted when multiple addresses are sent in a single prefix may be omitted when multiple addresses are sent in a single
packet -- this is known as address compression (Section 4.6.9). packet -- this is known as address compression (Section 4.6.9).
Address encodings: Address encodings:
skipping to change at page 35, line 38 skipping to change at page 35, line 38
Type The type of the sub-TLV. Type The type of the sub-TLV.
Length The length of the body, in octets, exclusive of the Type Length The length of the body, in octets, exclusive of the Type
and Length fields. and Length fields.
Body The sub-TLV body, the interpretation of which depends on Body The sub-TLV body, the interpretation of which depends on
both the type of the sub-TLV and the type of the TLV within both the type of the sub-TLV and the type of the TLV within
which it is embedded. which it is embedded.
The most-significant bit of the sub-TLV, called the mandatory bit, The most-significant bit of the sub-TLV type (the bit with value 80
indicates how to handle unknown sub-TLVs. If the mandatory bit is hexadecimal), called the mandatory bit, indicates how to handle
not set, then an unknown sub-TLV MUST be silently ignored, and the unknown sub-TLVs. If the mandatory bit is not set, then an unknown
rest of the TLV processed normally. If the mandatory bit is set, sub-TLV MUST be silently ignored, and the rest of the TLV is
then the whole enclosing TLV MUST be silently ignored (except for processed normally. If the mandatory bit is set, then the whole
updating the parser state by a Router-Id, Next-Hop or Update TLV, see enclosing TLV MUST be silently ignored (except for updating the
parser state by a Router-Id, Next-Hop or Update TLV, see
Section 4.6.7, Section 4.6.8, and Section 4.6.9). Section 4.6.7, Section 4.6.8, and Section 4.6.9).
4.5. Parser state 4.5. Parser state
Babel uses a stateful parser: a TLV may refer to data from a previous Babel uses a stateful parser: a TLV may refer to data from a previous
TLV. The parser state consists of the following pieces of data: TLV. The parser state consists of the following pieces of data:
o for each address encoding that allows compression, the current o for each address encoding that allows compression, the current
default prefix; this is undefined at the start of the packet, and default prefix; this is undefined at the start of the packet, and
is updated by each Update TLV with the Prefix flag set is updated by each Update TLV with the Prefix flag set
skipping to change at page 36, line 16 skipping to change at page 36, line 19
o for each address family (IPv4 or IPv6), the current next-hop; this o for each address family (IPv4 or IPv6), the current next-hop; this
is the source address of the enclosing packet for the matching is the source address of the enclosing packet for the matching
address family at the start of a packet, and is updated by each address family at the start of a packet, and is updated by each
Next-Hop TLV (Section 4.6.8); Next-Hop TLV (Section 4.6.8);
o the current router-id; this is undefined at the start of the o the current router-id; this is undefined at the start of the
packet, and is updated by each Router-ID TLV (Section 4.6.7) and packet, and is updated by each Router-ID TLV (Section 4.6.7) and
by each Update TLV with Router-Id flag set. by each Update TLV with Router-Id flag set.
Since the parser state is separate from the bulk of Babel's state, Since the parser state must be identical across implementations, it
and since for correct parsing it must be identical across is updated before checking for mandatory TLVs: parsing a TLV MUST
implementations, it is updated before checking for mandatory TLVs: update the parser state even if the TLV is otherwise ignored due to
parsing a TLV MUST update the parser state even if the TLV is an unknown mandatory sub-TLV.
otherwise ignored due to an unknown mandatory sub-TLV.
None of the TLVs that modify the parser state are allowed in the None of the TLVs that modify the parser state are allowed in the
packet trailer; hence, an implementation may choose to use a packet trailer; hence, an implementation may choose to use a
dedicated stateless parser to parse the packet trailer. dedicated stateless parser to parse the packet trailer.
4.6. Details of Specific TLVs 4.6. Details of Specific TLVs
4.6.1. Pad1 4.6.1. Pad1
0 0
skipping to change at page 36, line 50 skipping to change at page 37, line 4
This TLV is silently ignored on reception. It is allowed in the This TLV is silently ignored on reception. It is allowed in the
packet trailer. packet trailer.
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 Must be zero, set to 0 on transmission.
This TLV is silently ignored on reception. It is allowed in the This TLV is silently ignored on reception. It is allowed in the
packet trailer. packet trailer.
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 |
skipping to change at page 47, line 46 skipping to change at page 47, line 46
| Type = 1 | Length | MBZ... | Type = 1 | Length | MBZ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Fields : Fields :
Type Set to 1 to indicate a PadN sub-TLV. Type Set to 1 to indicate a PadN sub-TLV.
Length The length of the body, in octets, exclusive of the Type Length The length of the body, in octets, exclusive of the Type
and Length fields. and Length fields.
MBZ Set to 0 on transmission. MBZ Must be zero, set to 0 on transmission.
This sub-TLV is silently ignored on reception. It is allowed within This sub-TLV is silently ignored on reception. It is allowed within
any TLV that allows sub-TLVs. any TLV that allows sub-TLVs.
5. IANA Considerations 5. IANA Considerations
IANA has registered the UDP port number 6696, called "babel", for use IANA has registered the UDP port number 6696, called "babel", for use
by the Babel protocol. by the Babel protocol.
IANA has registered the IPv6 multicast group ff02::1:6 and the IPv4 IANA has registered the IPv6 multicast group ff02::1:6 and the IPv4
skipping to change at page 50, line 22 skipping to change at page 50, line 22
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017. May 2017.
8.2. Informative References 8.2. Informative References
[BABEL-DTLS] [BABEL-DTLS]
Decimo, A., Schinazi, D., and J. Chroboczek, "Babel Decimo, A., Schinazi, D., and J. Chroboczek, "Babel
Routing Protocol over Datagram Transport Layer Security", Routing Protocol over Datagram Transport Layer Security",
Internet Draft draft-ietf-babel-dtls-04, February 2019. Internet Draft draft-ietf-babel-dtls-07, July 2019.
[BABEL-HMAC] [BABEL-HMAC]
Do, C., Kolodziejak, W., and J. Chroboczek, "HMAC Do, C., Kolodziejak, W., and J. Chroboczek, "HMAC
authentication for the Babel routing protocol", Internet authentication for the Babel routing protocol", Internet
Draft draft-ietf-babel-hmac-04, March 2019. Draft draft-ietf-babel-hmac-07, June 2019.
[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 61, line 13 skipping to change at page 61, line 13
into account. into account.
F.12. Changes since draft-ietf-babel-rfc6126bis-09 F.12. Changes since draft-ietf-babel-rfc6126bis-09
o Editorial changes only. o Editorial changes only.
F.13. Changes since draft-ietf-babel-rfc6126bis-10 F.13. Changes since draft-ietf-babel-rfc6126bis-10
o Editorial changes only. o Editorial changes only.
F.14. Changes since draft-ietf-babel-rfc6126bis-11
o Added recommendation that control traffic should be carried over
IPv6 only.
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
 End of changes. 16 change blocks. 
22 lines changed or deleted 37 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/