draft-ietf-babel-rfc6126bis-05.txt   draft-ietf-babel-rfc6126bis-06.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: November 30, 2018 May 29, 2018 Expires: April 26, 2019 October 23, 2018
The Babel Routing Protocol The Babel Routing Protocol
draft-ietf-babel-rfc6126bis-05 draft-ietf-babel-rfc6126bis-06
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 November 30, 2018. This Internet-Draft will expire on April 26, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
(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 2, line 32 skipping to change at page 2, line 32
3.2. Data Structures . . . . . . . . . . . . . . . . . . . . . 12 3.2. Data Structures . . . . . . . . . . . . . . . . . . . . . 12
3.3. Acknowledgments and acknowledgment requests . . . . . . . 16 3.3. Acknowledgments and acknowledgment requests . . . . . . . 16
3.4. Neighbour Acquisition . . . . . . . . . . . . . . . . . . 17 3.4. Neighbour Acquisition . . . . . . . . . . . . . . . . . . 17
3.5. Routing Table Maintenance . . . . . . . . . . . . . . . . 20 3.5. Routing Table Maintenance . . . . . . . . . . . . . . . . 20
3.6. Route Selection . . . . . . . . . . . . . . . . . . . . . 24 3.6. Route Selection . . . . . . . . . . . . . . . . . . . . . 24
3.7. Sending Updates . . . . . . . . . . . . . . . . . . . . . 25 3.7. Sending Updates . . . . . . . . . . . . . . . . . . . . . 25
3.8. Explicit Requests . . . . . . . . . . . . . . . . . . . . 27 3.8. Explicit Requests . . . . . . . . . . . . . . . . . . . . 27
4. Protocol Encoding . . . . . . . . . . . . . . . . . . . . . . 31 4. Protocol Encoding . . . . . . . . . . . . . . . . . . . . . . 31
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 . . . . . . . . . . . . . . . . . . . . . . . 34
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 . . . . . . . . . . . . . . . . 36
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 . . . . . . . . . . . . . . . . . . . . . . . 49
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 49
8.1. Normative References . . . . . . . . . . . . . . . . . . 49 8.1. Normative References . . . . . . . . . . . . . . . . . . 49
8.2. Informative References . . . . . . . . . . . . . . . . . 49 8.2. Informative References . . . . . . . . . . . . . . . . . 50
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 . . . . . . . . . . . . . . . . 51
A.2. Cost Computation . . . . . . . . . . . . . . . . . . . . 51 A.2. Cost Computation . . . . . . . . . . . . . . . . . . . . 52
A.3. Metric Computation . . . . . . . . . . . . . . . . . . . 53 A.3. Metric Computation . . . . . . . . . . . . . . . . . . . 53
Appendix B. Constants . . . . . . . . . . . . . . . . . . . . . 53 Appendix B. Constants . . . . . . . . . . . . . . . . . . . . . 54
Appendix C. Considerations for protocol extensions . . . . . . . 54 Appendix C. Considerations for protocol extensions . . . . . . . 55
Appendix D. Stub Implementations . . . . . . . . . . . . . . . . 56 Appendix D. Stub Implementations . . . . . . . . . . . . . . . . 56
Appendix E. Software Availability . . . . . . . . . . . . . . . 56 Appendix E. Software Availability . . . . . . . . . . . . . . . 57
Appendix F. Changes from previous versions . . . . . . . . . . . 57 Appendix F. Changes from previous versions . . . . . . . . . . . 57
F.1. Changes since RFC 6126 . . . . . . . . . . . . . . . . . 57 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 . . . . . . 58
F.3. Changes since draft-ietf-babel-rfc6126bis-01 . . . . . . 57 F.3. Changes since draft-ietf-babel-rfc6126bis-01 . . . . . . 58
F.4. Changes since draft-ietf-babel-rfc6126bis-02 . . . . . . 58 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 . . . . . . 59
F.6. Changes since draft-ietf-babel-rfc6126bis-03 . . . . . . 59 F.6. Changes since draft-ietf-babel-rfc6126bis-03 . . . . . . 59
F.7. Changes since draft-ietf-babel-rfc6126bis-04 . . . . . . 59 F.7. Changes since draft-ietf-babel-rfc6126bis-04 . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 F.8. Changes since draft-ietf-babel-rfc6126bis-05 . . . . . . 60
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60
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 33, line 14 skipping to change at page 33, line 14
4.1.4. Prefixes 4.1.4. Prefixes
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 (the packet body), optionally followed by a second sequence
of TLVs (the packet trailer).
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Packet Trailer...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
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
silently ignored. silently ignored.
Version This document specifies version 2 of the Babel protocol. Version This document specifies version 2 of the Babel protocol.
Packets with a second octet different from 2 MUST be Packets with a second octet different from 2 MUST be
silently ignored. silently ignored.
Body length The length in octets of the body following the packet Body length The length in octets of the body following the packet
header (excluding the Magic, Version and Body length header (excluding the Magic, Version and Body length
fields). fields, and excluding the packet trailer).
Body The packet body; a sequence of TLVs. Packet Body The packet body; a sequence of TLVs.
Any data following the body MUST be silently ignored. Packet Trailer The packet trailer; another sequence of TLVs.
The packet body and the packet trailer are both sequences of TLVs. A
TLV may appear in the packet trailer only if it is explicitly allowed
to do so: the receiver MUST silently ignore any TLV that appears in
the packet trailer unless it is explicitly specified to be allowed in
the packet trailer. Among the TLVs defined in this document, only
Pad1 and PadN are allowed in the packet trailer; since these TLVs are
ignored in any case, an implementation MAY silently ignore the packet
trailer unless it implements at least one extension that uses the
packet trailer.
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
skipping to change at page 35, line 30 skipping to change at page 35, line 45
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 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.
None of the TLVs that modify the parser state are allowed in the
packet trailer; hence, an implementation may choose to use a
dedicated stateless parser to parse the packet trailer.
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. It is allowed in the
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 Set to 0 on transmission.
This TLV is silently ignored on reception. This TLV is silently ignored on reception. It is allowed in the
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce | Interval | | Nonce | Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 48, line 21 skipping to change at page 49, line 4
+------+------------+---------------+ +------+------------+---------------+
IANA is instructed to replace all references to RFCs 6126 and 7557 in IANA is instructed to replace all references to RFCs 6126 and 7557 in
all of the registries mentioned above by references to this document. all of the registries mentioned above by references to this document.
6. Security Considerations 6. Security Considerations
As defined in this document, Babel is a completely insecure protocol. As defined in this document, Babel is a completely insecure protocol.
Any attacker can misdirect data traffic by advertising routes with a Any attacker can misdirect data traffic by advertising routes with a
low metric or a high seqno. This issue can be solved either by a low metric or a high seqno. This issue can be solved either by a
lower-layer security mechanism (e.g. link-layer security), or by lower-layer security mechanism (e.g., link-layer security), or by
deploying a suitable authentication mechanism within Babel itself. deploying a suitable authentication mechanism within Babel itself.
With the exception of Hello TLVs used for discovery, Babel control With the exception of Hello TLVs used for discovery, Babel control
traffic can be carried over unicast, which makes it possible to traffic can be carried over unicast, which makes it possible to
protect Babel traffic with a protocol that can only protect unicast protect Babel traffic with a protocol that can only protect unicast
data, for example IPsec with IKEv2, or DTLS. data, for example IPsec with IKEv2, or DTLS.
The information that a Babel node announces to the whole routing The information that a Babel node announces to the whole routing
domain is often sufficient to determine a mobile node's physical domain is often sufficient to determine a mobile node's physical
location with reasonable precision. The privacy issues that this location with reasonable precision. The privacy issues that this
causes can be mitigated somewhat by using randomly chosen router-ids causes can be mitigated somewhat by using randomly chosen router-ids
skipping to change at page 55, line 46 skipping to change at page 56, line 27
However, adding a new AE is more involved than adding a new TLV, However, adding a new AE is more involved than adding a new TLV,
since it creates a new set of compression state. Additionally, since since it creates a new set of compression state. Additionally, since
the Next Hop TLV creates state specific to a given address family, as 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 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 family must not be used in the Next Hop TLV if backwards
compatibility is required. A similar issue arises with Update TLVs compatibility is required. A similar issue arises with Update TLVs
with unknown AEs establishing a new router-id (due to the Router-Id 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 flag being set). Therefore, defining new AEs must be done with care
if compatibility with unextended implementations is required. if compatibility with unextended implementations is required.
The packet trailer (the space after the declared length of the packet The packet trailer is intended to carry cryptographic signatures that
but within the payload of the UDP datagram) was originally intended only cover the packet body; storing the cryptographic signatures in
to carry a cryptographic signature. However, no extension has used the packet trailer avoids clearing the signature before computing a
it to date, and therefore we refrain from making any recommendations hash of the packet body, and makes it possible to check a
about its use due to the lack of implementation experience. cryptographic signature before running the full, stateful TLV parser.
Thus, any TLV that is allowed to appear in the packet trailer must
not need to be protected by cryptographic security protocols, it
should be easy to parse, and should not require stateful parsing.
Appendix D. Stub Implementations Appendix D. Stub Implementations
Babel is a fairly economic protocol. Updates take between 12 and 40 Babel is a fairly economic protocol. Updates take between 12 and 40
octets per destination, depending on the address family and how octets per destination, depending on the address family and how
successful compression is; in a double-stack flat network, an average successful compression is; in a double-stack flat network, an average
of less than 24 octets per update is typical. The route table of less than 24 octets per update is typical. The route table
occupies about 35 octets per IPv6 entry. To put these values into occupies about 35 octets per IPv6 entry. To put these values into
perspective, a single full-size Ethernet frame can carry some 65 perspective, a single full-size Ethernet frame can carry some 65
route updates, and a megabyte of memory can contain a 20000-entry route updates, and a megabyte of memory can contain a 20000-entry
skipping to change at page 59, line 21 skipping to change at page 60, line 5
F.7. Changes since draft-ietf-babel-rfc6126bis-04 F.7. Changes since draft-ietf-babel-rfc6126bis-04
o Renamed isotonicity to left-distributivity. o Renamed isotonicity to left-distributivity.
o Minor clarifications to unicast hellos. o Minor clarifications to unicast hellos.
o Updated requirements boilerplate to RFC 8174. o Updated requirements boilerplate to RFC 8174.
o Minor editorial changes. o Minor editorial changes.
F.8. Changes since draft-ietf-babel-rfc6126bis-05
o Added information about the packet trailer, now that it is used by
draft-ietf-babel-hmac.
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. 25 change blocks. 
30 lines changed or deleted 59 lines changed or added

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