< draft-ietf-babel-rfc6126bis-13.txt   draft-ietf-babel-rfc6126bis-14.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: February 11, 2020 August 10, 2019 Expires: February 18, 2020 August 17, 2019
The Babel Routing Protocol The Babel Routing Protocol
draft-ietf-babel-rfc6126bis-13 draft-ietf-babel-rfc6126bis-14
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 February 11, 2020. This Internet-Draft will expire on February 18, 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 2, line 13 skipping to change at page 2, line 13
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Features . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Features . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Specification of Requirements . . . . . . . . . . . . . . 5 1.3. Specification of Requirements . . . . . . . . . . . . . . 5
2. Conceptual Description of the Protocol . . . . . . . . . . . 5 2. Conceptual Description of the Protocol . . . . . . . . . . . 5
2.1. Costs, Metrics and Neighbourship . . . . . . . . . . . . 5 2.1. Costs, Metrics and Neighbourship . . . . . . . . . . . . 5
2.2. The Bellman-Ford Algorithm . . . . . . . . . . . . . . . 5 2.2. The Bellman-Ford Algorithm . . . . . . . . . . . . . . . 6
2.3. Transient Loops in Bellman-Ford . . . . . . . . . . . . . 6 2.3. Transient Loops in Bellman-Ford . . . . . . . . . . . . . 6
2.4. Feasibility Conditions . . . . . . . . . . . . . . . . . 7 2.4. Feasibility Conditions . . . . . . . . . . . . . . . . . 7
2.5. Solving Starvation: Sequencing Routes . . . . . . . . . . 8 2.5. Solving Starvation: Sequencing Routes . . . . . . . . . . 8
2.6. Requests . . . . . . . . . . . . . . . . . . . . . . . . 10 2.6. Requests . . . . . . . . . . . . . . . . . . . . . . . . 10
2.7. Multiple Routers . . . . . . . . . . . . . . . . . . . . 10 2.7. Multiple Routers . . . . . . . . . . . . . . . . . . . . 11
2.8. Overlapping Prefixes . . . . . . . . . . . . . . . . . . 11 2.8. Overlapping Prefixes . . . . . . . . . . . . . . . . . . 12
3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 12 3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 12
3.1. Message Transmission and Reception . . . . . . . . . . . 12 3.1. Message Transmission and Reception . . . . . . . . . . . 12
3.2. Data Structures . . . . . . . . . . . . . . . . . . . . . 13 3.2. Data Structures . . . . . . . . . . . . . . . . . . . . . 13
3.3. Acknowledgments and acknowledgment requests . . . . . . . 17 3.3. Acknowledgments and acknowledgment requests . . . . . . . 17
3.4. Neighbour Acquisition . . . . . . . . . . . . . . . . . . 18 3.4. Neighbour Acquisition . . . . . . . . . . . . . . . . . . 18
3.5. Routing Table Maintenance . . . . . . . . . . . . . . . . 20 3.5. Routing Table Maintenance . . . . . . . . . . . . . . . . 21
3.6. Route Selection . . . . . . . . . . . . . . . . . . . . . 24 3.6. Route Selection . . . . . . . . . . . . . . . . . . . . . 25
3.7. Sending Updates . . . . . . . . . . . . . . . . . . . . . 25 3.7. Sending Updates . . . . . . . . . . . . . . . . . . . . . 26
3.8. Explicit Requests . . . . . . . . . . . . . . . . . . . . 28 3.8. Explicit Requests . . . . . . . . . . . . . . . . . . . . 28
4. Protocol Encoding . . . . . . . . . . . . . . . . . . . . . . 32 4. Protocol Encoding . . . . . . . . . . . . . . . . . . . . . . 32
4.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . 32 4.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . 32
4.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 33 4.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 33
4.3. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 34 4.3. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 34
4.4. Sub-TLV Format . . . . . . . . . . . . . . . . . . . . . 34 4.4. Sub-TLV Format . . . . . . . . . . . . . . . . . . . . . 35
4.5. Parser state and encoding of updates . . . . . . . . . . 35 4.5. Parser state and encoding of updates . . . . . . . . . . 35
4.6. Details of Specific TLVs . . . . . . . . . . . . . . . . 36 4.6. Details of Specific TLVs . . . . . . . . . . . . . . . . 37
4.7. Details of specific sub-TLVs . . . . . . . . . . . . . . 47 4.7. Details of specific sub-TLVs . . . . . . . . . . . . . . 47
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
6. Security Considerations . . . . . . . . . . . . . . . . . . . 51 6. Security Considerations . . . . . . . . . . . . . . . . . . . 51
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
8.1. Normative References . . . . . . . . . . . . . . . . . . 52 8.1. Normative References . . . . . . . . . . . . . . . . . . 53
8.2. Informative References . . . . . . . . . . . . . . . . . 53 8.2. Informative References . . . . . . . . . . . . . . . . . 53
Appendix A. Cost and Metric Computation . . . . . . . . . . . . 54 Appendix A. Cost and Metric Computation . . . . . . . . . . . . 55
A.1. Maintaining Hello History . . . . . . . . . . . . . . . . 55 A.1. Maintaining Hello History . . . . . . . . . . . . . . . . 55
A.2. Cost Computation . . . . . . . . . . . . . . . . . . . . 56 A.2. Cost Computation . . . . . . . . . . . . . . . . . . . . 56
A.3. Metric Computation . . . . . . . . . . . . . . . . . . . 57 A.3. Metric Computation . . . . . . . . . . . . . . . . . . . 57
Appendix B. Constants . . . . . . . . . . . . . . . . . . . . . 58 Appendix B. Protocol parameters . . . . . . . . . . . . . . . . 58
Appendix C. Route filtering . . . . . . . . . . . . . . . . . . 59 Appendix C. Route filtering . . . . . . . . . . . . . . . . . . 59
Appendix D. Considerations for protocol extensions . . . . . . . 60 Appendix D. Considerations for protocol extensions . . . . . . . 60
Appendix E. Stub Implementations . . . . . . . . . . . . . . . . 61 Appendix E. Stub Implementations . . . . . . . . . . . . . . . . 61
Appendix F. Changes from previous versions . . . . . . . . . . . 62 Appendix F. Compatibility with previous versions . . . . . . . . 62
F.1. Changes since RFC 6126 . . . . . . . . . . . . . . . . . 62 Appendix G. Changes from previous versions . . . . . . . . . . . 63
F.2. Changes since draft-ietf-babel-rfc6126bis-00 . . . . . . 62 G.1. Changes since RFC 6126 . . . . . . . . . . . . . . . . . 63
F.3. Changes since draft-ietf-babel-rfc6126bis-01 . . . . . . 63 G.2. Changes since draft-ietf-babel-rfc6126bis-00 . . . . . . 64
F.4. Changes since draft-ietf-babel-rfc6126bis-02 . . . . . . 63 G.3. Changes since draft-ietf-babel-rfc6126bis-01 . . . . . . 64
F.5. Changes since draft-ietf-babel-rfc6126bis-03 . . . . . . 64 G.4. Changes since draft-ietf-babel-rfc6126bis-02 . . . . . . 64
F.6. Changes since draft-ietf-babel-rfc6126bis-03 . . . . . . 64 G.5. Changes since draft-ietf-babel-rfc6126bis-03 . . . . . . 65
F.7. Changes since draft-ietf-babel-rfc6126bis-04 . . . . . . 64 G.6. Changes since draft-ietf-babel-rfc6126bis-03 . . . . . . 65
F.8. Changes since draft-ietf-babel-rfc6126bis-05 . . . . . . 65 G.7. Changes since draft-ietf-babel-rfc6126bis-04 . . . . . . 65
F.9. Changes since draft-ietf-babel-rfc6126bis-06 . . . . . . 65 G.8. Changes since draft-ietf-babel-rfc6126bis-05 . . . . . . 66
F.10. Changes since draft-ietf-babel-rfc6126bis-07 . . . . . . 65 G.9. Changes since draft-ietf-babel-rfc6126bis-06 . . . . . . 66
F.11. Changes since draft-ietf-babel-rfc6126bis-08 . . . . . . 65 G.10. Changes since draft-ietf-babel-rfc6126bis-07 . . . . . . 66
F.12. Changes since draft-ietf-babel-rfc6126bis-09 . . . . . . 65 G.11. Changes since draft-ietf-babel-rfc6126bis-08 . . . . . . 66
F.13. Changes since draft-ietf-babel-rfc6126bis-10 . . . . . . 65 G.12. Changes since draft-ietf-babel-rfc6126bis-09 . . . . . . 66
F.14. Changes since draft-ietf-babel-rfc6126bis-11 . . . . . . 65 G.13. Changes since draft-ietf-babel-rfc6126bis-10 . . . . . . 66
F.15. Changes since draft-ietf-babel-rfc6126bis-12 . . . . . . 65 G.14. Changes since draft-ietf-babel-rfc6126bis-11 . . . . . . 66
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 66 G.15. Changes since draft-ietf-babel-rfc6126bis-12 . . . . . . 66
G.16. Changes since draft-ietf-babel-rfc6126bis-13 . . . . . . 67
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67
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. This document describes the Babel routing wireless networks. This document describes the Babel routing
protocol, and obsoletes [RFC6126] and [RFC7557]. protocol, and obsoletes [RFC6126] and [RFC7557].
skipping to change at page 4, line 42 skipping to change at page 4, line 46
Babel has two limitations that make it unsuitable for use in some Babel has two limitations that make it unsuitable for use in some
environments. First, Babel relies on periodic routing table updates environments. First, Babel relies on periodic routing table updates
rather than using a reliable transport; hence, in large, stable rather than using a reliable transport; hence, in large, stable
networks it generates more traffic than protocols that only send networks it generates more traffic than protocols that only send
updates when the network topology changes. In such networks, updates when the network topology changes. In such networks,
protocols such as OSPF [OSPF], IS-IS [IS-IS], or the Enhanced protocols such as OSPF [OSPF], IS-IS [IS-IS], or the Enhanced
Interior Gateway Routing Protocol (EIGRP) [EIGRP] might be more Interior Gateway Routing Protocol (EIGRP) [EIGRP] might be more
suitable. suitable.
Second, unless the optional algorithm described in Section 3.5.4 is Second, unless the second algorithm described in Section 3.5.4 is
implemented, Babel does impose a hold time when a prefix is implemented, Babel does impose a hold time when a prefix is
retracted. While this hold time does not apply to the exact prefix retracted. While this hold time does not apply to the exact prefix
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.4 implement the optional algorithm described in Section 3.5.4
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
skipping to change at page 8, line 30 skipping to change at page 8, line 41
/ \ / \
S A S A
\ / \ /
1 \ / 4 1 \ / 4
C C
To show that this feasibility condition still guarantees loop- To show that this feasibility condition still guarantees loop-
freedom, recall that at the time when A accepts an update from B, the freedom, recall that at the time when A accepts an update from B, the
metric D(B) announced by B is no smaller than FD(B); since it is metric D(B) announced by B is no smaller than FD(B); since it is
smaller than FD(A), at that point in time FD(B) < FD(A). Since this smaller than FD(A), at that point in time FD(B) < FD(A). Since this
property is preserved when A sends updates, it remains true at all property is preserved both when A sends updates and when it picks a
times, which ensures that the forwarding graph has no loops. different next hop, it remains true at all times, which ensures that
the forwarding graph has no loops.
2.5. Solving Starvation: Sequencing Routes 2.5. Solving Starvation: Sequencing Routes
Obviously, the feasibility conditions defined above cause starvation Obviously, the feasibility conditions defined above cause starvation
when a router runs out of feasible routes. Consider the following when a router runs out of feasible routes. Consider the following
diagram, where both A and B have selected the direct route to S: diagram, where both A and B have selected the direct route to S:
A A
1 /| D(A) = 1 1 /| D(A) = 1
/ | FD(A) = 1 / | FD(A) = 1
skipping to change at page 16, line 31 skipping to change at page 16, line 40
3.2.6. The Route Table 3.2.6. The Route Table
The route table contains the routes known to this node. It is The route table contains the routes known to this node. It is
indexed by triples of the form (prefix, plen, neighbour), and every indexed by triples of the form (prefix, plen, neighbour), and every
route table entry contains the following data: route table entry contains the following data:
o the source (prefix, plen, router-id) for which this route is o the source (prefix, plen, router-id) for which this route is
advertised; advertised;
o the neighbour that advertised this route; o the neighbour (an entry in the neighbour table) that advertised
this route;
o the metric with which this route was advertised by the neighbour, o the metric with which this route was advertised by the neighbour,
or FFFF hexadecimal (infinity) for a recently retracted route; or FFFF hexadecimal (infinity) for a recently retracted route;
o the sequence number with which this route was advertised; o the sequence number with which this route was advertised;
o the next-hop address of this route; o the next-hop address of this route;
o a boolean flag indicating whether this route is selected, i.e., o a boolean flag indicating whether this route is selected, i.e.,
whether it is currently being used for forwarding and is being whether it is currently being used for forwarding and is being
advertised. advertised.
There is one timer associated with each route table entry -- the There is one timer associated with each route table entry -- the
route expiry timer. It is initialised and reset as specified in route expiry timer. It is initialised and reset as specified in
Section 3.5.3. Section 3.5.3.
Note that there are two distinct (seqno, metric) pairs associated to Note that there are two distinct (seqno, metric) pairs associated to
each route: the route's distance, which is stored in the route table, each route: the route's distance, which is stored in the route table,
skipping to change at page 30, line 14 skipping to change at page 30, line 22
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,
the subsequent copies MAY be forwarded to a different neighbour than the subsequent copies may be forwarded to a different neighbour than
the initial one. the initial one.
3.8.2. Sending Requests 3.8.2. Sending Requests
A Babel node MAY send a route or seqno request at any time, to a A Babel node MAY send a route or seqno request at any time, to a
multicast or a unicast address; there is only one case when multicast or a unicast address; there is only one case when
originating requests is required (Section 3.8.2.1). originating requests is required (Section 3.8.2.1).
3.8.2.1. Avoiding Starvation 3.8.2.1. Avoiding Starvation
skipping to change at page 30, line 45 skipping to change at page 31, line 4
hop count, which is used as a last-resort mechanism to ensure that it hop count, which is used as a last-resort mechanism to ensure that it
eventually vanishes from the network; it MAY be set to any value that eventually vanishes from the network; it MAY be set to any value that
is larger than the diameter of the network (64 is a suitable default is larger than the diameter of the network (64 is a suitable default
value). value).
If the node has any (unfeasible) routes to the requested destination, If the node has any (unfeasible) routes to the requested destination,
then it MUST send the request to at least one of the next-hop then it MUST send the request to at least one of the next-hop
neighbours that advertised these routes, and SHOULD send it to all of neighbours that advertised these routes, and SHOULD send it to all of
them; in any case, it MAY send the request to any other neighbours, them; in any case, it MAY send the request to any other neighbours,
whether they advertise a route to the requested destination or not. whether they advertise a route to the requested destination or not.
A simple implementation strategy is therefore to unconditionally A simple implementation strategy is therefore to unconditionally
multicast the request over all interfaces. multicast the request over all interfaces.
Similar requests will be sent by other nodes that are affected by the Similar requests will be sent by other nodes that are affected by the
route's loss. If the network is still connected, and assuming no route's loss. If the network is still connected, and assuming no
packet loss, then at least one of these requests will be forwarded to packet loss, then at least one of these requests will be forwarded to
the source, resulting in a route being advertised with a new sequence the source, resulting in a route being advertised with a new sequence
number. (Due to duplicate suppression, only a small number of such number. (Due to duplicate suppression, only a small number of such
requests will actually reach the source.) requests are expected to actually reach the source.)
In order to compensate for packet loss, a node SHOULD repeat such a In order to compensate for packet loss, a node SHOULD repeat such a
request a small number of times if no route becomes feasible within a request a small number of times if no route becomes feasible within a
short time (see "Request Timeout" in Appendix B for suggested short time (see "Request Timeout" in Appendix B for suggested
values). In the presence of heavy packet loss, however, all such values). In the presence of heavy packet loss, however, all such
requests might be lost; in that case, the mechanism in the next requests might be lost; in that case, the mechanism in the next
section will eventually ensure that a new seqno is received. section will eventually ensure that a new seqno is received.
3.8.2.2. Dealing with Unfeasible Updates 3.8.2.2. Dealing with Unfeasible Updates
skipping to change at page 36, line 38 skipping to change at page 36, line 44
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 must be identical across implementations, it Since the parser state must be identical across implementations, it
is updated before checking for mandatory sub-TLVs: parsing a TLV MUST is updated before checking for mandatory sub-TLVs: parsing a TLV MUST
update the parser state even if the TLV is otherwise ignored due to update the parser state even if the TLV is otherwise ignored due to
an unknown mandatory sub-TLV. an unknown mandatory sub-TLV or for any other reason.
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 37, line 38 skipping to change at page 37, line 49
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce | Interval | | Opaque | 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 :
Type Set to 2 to indicate an Acknowledgment Request TLV. Type Set to 2 to indicate an Acknowledgment Request TLV.
Length The length of the body in octets, exclusive of the Type and Length The length of the body in octets, exclusive of the Type and
Length fields. Length fields.
skipping to change at page 38, line 5 skipping to change at page 38, line 16
Fields : Fields :
Type Set to 2 to indicate an Acknowledgment Request TLV. Type Set to 2 to indicate an Acknowledgment Request TLV.
Length The length of the body in octets, exclusive of the Type and Length The length of the body in octets, exclusive of the Type and
Length fields. Length fields.
Reserved Sent as 0 and MUST be ignored on reception. Reserved Sent as 0 and MUST be ignored on reception.
Nonce An arbitrary value that will be echoed in the receiver's Opaque An arbitrary value that will be echoed in the receiver's
Acknowledgment TLV. Acknowledgment TLV.
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 | Opaque |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Length The length of the body in octets, exclusive of the Type and Length The length of the body in octets, exclusive of the Type and
Length fields. Length fields.
Nonce Set to the Nonce value of the Acknowledgment Request that Opaque Set to the Opaque 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 Opaque 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 |
skipping to change at page 49, line 29 skipping to change at page 49, line 29
| 11 | TS/PC | [RFC7298] | | 11 | TS/PC | [RFC7298] |
| | | | | | | |
| 12 | HMAC | [RFC7298] | | 12 | HMAC | [RFC7298] |
| | | | | | | |
| 13 | Source-specific Update | [BABEL-SS] | | 13 | Source-specific Update | [BABEL-SS] |
| | | | | | | |
| 14 | Source-specific Request | [BABEL-SS] | | 14 | Source-specific Request | [BABEL-SS] |
| | | | | | | |
| 15 | Source-specific Seqno Request | [BABEL-SS] | | 15 | Source-specific Seqno Request | [BABEL-SS] |
| | | | | | | |
| 16 | HMAC | [BABEL-HMAC] | | 16 | MAC | [BABEL-MAC] |
| | | | | | | |
| 17 | PC | [BABEL-HMAC] | | 17 | PC | [BABEL-MAC] |
| | | | | | | |
| 18 | Challenge Request | [BABEL-HMAC] | | 18 | Challenge Request | [BABEL-MAC] |
| | | | | | | |
| 19 | Challenge Reply | [BABEL-HMAC] | | 19 | Challenge Reply | [BABEL-MAC] |
| | | | | | | |
| 20-223 | Unassigned | | | 20-223 | Unassigned | |
| | | | | | | |
| 224-254 | Reserved for Experimental Use | this document | | 224-254 | Reserved for Experimental Use | this document |
| | | | | | | |
| 255 | Reserved for expansion of the type | this document | | 255 | Reserved for expansion of the type | this document |
| | space | | | | space | |
+---------+-----------------------------------------+---------------+ +---------+-----------------------------------------+---------------+
IANA has created a registry called "Babel TLV Types". The allocation IANA has created a registry called "Babel sub-TLV Types". The
policy for this registry is Specification Required for Types 0-111 allocation policy for this registry is Specification Required for
and 128-239, and Experimental Use for Types 112-126 and 240-254. The Types 0-111 and 128-239, and Experimental Use for Types 112-126 and
values in this registry are as follows: 240-254. The values in this registry are as follows:
+---------+-------------------------------------+-------------------+ +---------+-------------------------------------+-------------------+
| Type | Name | Reference | | Type | Name | Reference |
+---------+-------------------------------------+-------------------+ +---------+-------------------------------------+-------------------+
| 0 | Pad1 | this document | | 0 | Pad1 | this document |
| | | | | | | |
| 1 | PadN | this document | | 1 | PadN | this document |
| | | | | | | |
| 2 | Diversity | [BABEL-DIVERSITY] | | 2 | Diversity | [BABEL-DIVERSITY] |
| | | | | | | |
skipping to change at page 50, line 33 skipping to change at page 50, line 33
| 128 | Source Prefix | [BABEL-SS] | | 128 | Source Prefix | [BABEL-SS] |
| | | | | | | |
| 129-239 | Unassigned | | | 129-239 | Unassigned | |
| | | | | | | |
| 240-254 | Reserved for Experimental Use | this document | | 240-254 | Reserved for Experimental Use | this document |
| | | | | | | |
| 255 | Reserved for expansion of the type | this document | | 255 | Reserved for expansion of the type | this document |
| | space | | | | space | |
+---------+-------------------------------------+-------------------+ +---------+-------------------------------------+-------------------+
IANA is instructed to create a registry called "Babel Address
Encodings". The allocation policy for this registry is Specification
Required. The values in this registry are as follows:
+----+-------------------------+---------------+
| AE | Name | Reference |
+----+-------------------------+---------------+
| 0 | Wildcard address | this document |
| | | |
| 1 | IPv4 address | this document |
| | | |
| 2 | IPv6 address | this document |
| | | |
| 3 | Link-local IPv6 address | this document |
+----+-------------------------+---------------+
IANA has created a registry called "Babel Flags Values". The IANA has created a registry called "Babel Flags Values". The
allocation policy for this registry is Specification Required. IANA allocation policy for this registry is Specification Required. IANA
is instructed to rename this registry to "Babel Update Flags Values". is instructed to rename this registry to "Babel Update Flags Values".
The values in this registry are as follows: The values in this registry are as follows:
+-----+-------------------+---------------+ +-----+-------------------+---------------+
| Bit | Name | Reference | | Bit | Name | Reference |
+-----+-------------------+---------------+ +-----+-------------------+---------------+
| 0 | Default prefix | this document | | 0 | Default prefix | this document |
| | | | | | | |
skipping to change at page 52, line 5 skipping to change at page 52, line 18
datagrams are fresh and originated from a trusted node. This can be datagrams are fresh and originated from a trusted node. This can be
achieved either by a lower-layer security mechanism (e.g., link-layer achieved either by a lower-layer security mechanism (e.g., link-layer
security or IPsec), or by deploying a suitable authentication security or IPsec), or by deploying a suitable authentication
mechanism within Babel itself. There are currently two such mechanism within Babel itself. There are currently two such
mechanisms: mechanisms:
o Babel over DTLS [BABEL-DTLS] runs the majority of Babel traffic o Babel over DTLS [BABEL-DTLS] runs the majority of Babel traffic
over DTLS, and leverages DTLS to authenticate nodes and provide over DTLS, and leverages DTLS to authenticate nodes and provide
confidentiality and integrity protection; confidentiality and integrity protection;
o HMAC-based authentication [BABEL-HMAC] appends a message o MAC authentication [BABEL-MAC] appends a message authentication
authentication code to all Babel datagrams to prove they code to all Babel datagrams to prove they originated from a node
originated from a node that possesses a shared secret. that possesses a shared secret.
Both mechanisms allow nodes to ignore packets generated by attackers Both mechanisms enable nodes to ignore packets generated by attackers
without the proper credentials. They also ensure integrity of without the proper credentials. They also ensure integrity of
messages and prevent message replay. However, only DTLS supports messages and prevent message replay. However, only DTLS supports
asymmetric keying and message confidentiality. HMAC is simpler and asymmetric keying and message confidentiality. MAC authentication is
does not depend on DTLS, and therefore its use is RECOMMENDED when simpler and does not depend on DTLS, and therefore its use is
the target deployment does not require confidentiality or asymmetric RECOMMENDED when the target deployment does not require
keying. confidentiality or asymmetric keying.
The information that a mobile Babel node announces to the whole The information that a mobile Babel node announces to the whole
routing domain is often sufficient to determine a mobile node's routing domain is often sufficient to determine a mobile node's
physical location with reasonable precision. The privacy issues that physical location with reasonable precision. The privacy issues that
this causes can be mitigated somewhat by using randomly chosen this causes can be mitigated somewhat by using randomly chosen
router-ids and randomly chosen IP addresses, and changing them often router-ids and randomly chosen IP addresses, and changing them often
enough. enough.
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, Toke Boutier, Gwendoline Chouasne, Margaret Cullen, Donald Eastlake, Toke
Hoiland-Jorgensen, Joao Sobrinho and Martin Vigoureux. Earlier Hoiland-Jorgensen, Benjamin Kaduk, Joao Sobrinho and Martin
versions of this document greatly benefited from the input of Joel Vigoureux. Earlier versions of this document greatly benefited from
Halpern. The address compression technique was inspired by the input of Joel Halpern. The address compression technique was
[PACKETBB]. inspired by [PACKETBB].
8. References 8. References
8.1. Normative References 8.1. Normative References
[BABEL-HMAC] [BABEL-MAC]
Do, C., Kolodziejak, W., and J. Chroboczek, "HMAC Do, C., Kolodziejak, W., and J. Chroboczek, "MAC
authentication for the Babel routing protocol", Internet authentication for the Babel routing protocol", Internet
Draft draft-ietf-babel-hmac-07, June 2019. Draft draft-ietf-babel-hmac-10, August 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997. DOI 10.17487/RFC2119, March 1997.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, June 2017. RFC 8126, June 2017.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
skipping to change at page 53, line 19 skipping to change at page 53, line 33
8.2. Informative References 8.2. Informative References
[BABEL-DIVERSITY] [BABEL-DIVERSITY]
Chroboczek, J., "Diversity Routing for the Babel Routing Chroboczek, J., "Diversity Routing for the Babel Routing
Protocol", draft-chroboczek-babel-diversity-routing-01 Protocol", draft-chroboczek-babel-diversity-routing-01
(work in progress), February 2016. (work in progress), February 2016.
[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-07, July 2019. Internet Draft draft-ietf-babel-dtls-09, August 2019.
[BABEL-RTT] [BABEL-RTT]
Jonglez, B. and J. Chroboczek, "Delay-based Metric Jonglez, B. and J. Chroboczek, "Delay-based Metric
Extension for the Babel Routing Protocol", draft-ietf- Extension for the Babel Routing Protocol", draft-ietf-
babel-rtt-extension-00 (work in progress), April 2019. babel-rtt-extension-00 (work in progress), April 2019.
[BABEL-SS] [BABEL-SS]
Boutier, M. and J. Chroboczek, "Source-Specific Routing in Boutier, M. and J. Chroboczek, "Source-Specific Routing in
Babel", draft-ietf-babel-source-specific-05 (work in Babel", draft-ietf-babel-source-specific-05 (work in
progress), April 2019. progress), April 2019.
skipping to change at page 56, line 16 skipping to change at page 56, line 28
This section discusses how to compute costs based on Hello history. This section discusses how to compute costs based on Hello history.
A.2.1. k-out-of-j A.2.1. k-out-of-j
K-out-of-j link sensing is suitable for wired links that are either K-out-of-j link sensing is suitable for wired links that are either
up, in which case they only occasionally drop a packet, or down, in up, in which case they only occasionally drop a packet, or down, in
which case they drop all packets. which case they drop all packets.
The k-out-of-j strategy is parameterised by two small integers k and The k-out-of-j strategy is parameterised by two small integers k and
j, such that 0 < k <= j, and the nominal link cost, a constant K >= j, such that 0 < k <= j, and the nominal link cost, a constant C >=
1. A node keeps a history of the last j hellos; if k or more of 1. A node keeps a history of the last j hellos; if k or more of
those have been correctly received, the link is assumed to be up, and those have been correctly received, the link is assumed to be up, and
the rxcost is set to K; otherwise, the link is assumed to be down, the rxcost is set to C; otherwise, the link is assumed to be down,
and the rxcost is set to infinity. and the rxcost is set to infinity.
Since Babel supports two kinds of Hellos, a Babel node performs k- Since Babel supports two kinds of Hellos, a Babel node performs k-
out-of-j twice for each neighbour, once on the Unicast and once on out-of-j twice for each neighbour, once on the Unicast and once on
the Multicast Hello history. If either of the instances of k-out- the Multicast Hello history. If either of the instances of k-out-
of-j indicates that the link is up, then the link is assumed to be of-j indicates that the link is up, then the link is assumed to be
up, and the rxcost is set to K; if both instances indicate that the up, and the rxcost is set to K; if both instances indicate that the
link is down, then the link is assumed to be down, and the rxcost is link is down, then the link is assumed to be down, and the rxcost is
set to infinity. In other words, the resulting rxcost is the minimum set to infinity. In other words, the resulting rxcost is the minimum
of the rxcosts yielded by the two instances of k-out-of-j link of the rxcosts yielded by the two instances of k-out-of-j link
skipping to change at page 57, line 47 skipping to change at page 58, line 16
The simplest approach for obtaining a monotonic, left-distributive The simplest approach for obtaining a monotonic, left-distributive
metric is to define the metric of a route as the sum of the costs of metric is to define the metric of a route as the sum of the costs of
the component links. More formally, if a neighbour advertises a the component links. More formally, if a neighbour advertises a
route with metric m over a link with cost c, then the resulting route route with metric m over a link with cost c, then the resulting route
has 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 Appendix B. Protocol parameters
A node may want to vary its willingness to forward packets by taking
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,
etc. This can be done by adding to every route's metric a value k
that depends on the external data. For example, if a battery-powered
node receives an update with metric m over a link with cost c, it
might compute a metric M(c, m) = k + c + m, where k depends on the
battery status.
In order to preserve strict monotonicity (Section 3.5.2), the value k
must be greater than -c.
Appendix B. Constants
The choice of time constants is a trade-off between fast detection of The choice of time constants is a trade-off between fast detection of
mobility events and protocol overhead. Two instances of Babel mobility events and protocol overhead. Two instances of Babel
running with different time constants will interoperate, although the running with different time constants will interoperate, although the
resulting worst-case convergence time will be dictated by the slower resulting worst-case convergence time will be dictated by the slower
of the two. of the two.
The Hello interval is the most important time constant: an outage or The Hello interval is the most important time constant: an outage or
a mobility event is detected within 1.5 to 3.5 Hello intervals. Due a mobility event is detected within 1.5 to 3.5 Hello intervals. Due
to Babel's use of a redundant route table, and due to its reliance on to Babel's use of a redundant route table, and due to its reliance on
skipping to change at page 58, line 37 skipping to change at page 58, line 40
acquire new routes after a mobility event. acquire new routes after a mobility event.
The following values are recommended in a network with little The following values are recommended in a network with little
mobility, and where occasional outages of up to 14 seconds are mobility, and where occasional outages of up to 14 seconds are
acceptable: acceptable:
Multicast Hello Interval: 4 seconds. Multicast Hello Interval: 4 seconds.
Unicast Hello Interval: infinite (no Unicast Hellos are sent). Unicast Hello Interval: infinite (no Unicast Hellos are sent).
Link cost: estimated using ETX on wireless links; 2-out-of-3 with
C=96 on wired links.
IHU Interval: the advertised IHU interval is always 3 times the IHU Interval: the advertised IHU interval is always 3 times the
Multicast Hello interval. IHUs are actually sent with each Hello Multicast Hello interval. IHUs are actually sent with each Hello
on lossy links (as determined from the Hello history), but only on lossy links (as determined from the Hello history), but only
with every third Multicast Hello on lossless links. with every third Multicast Hello on lossless links.
Update Interval: 4 times the Multicast Hello interval. Update Interval: 4 times the Multicast Hello interval.
IHU Hold Time: 3.5 times the advertised IHU interval. IHU Hold Time: 3.5 times the advertised IHU interval.
Route Expiry Time: 3.5 times the advertised update interval. Route Expiry Time: 3.5 times the advertised update interval.
skipping to change at page 59, line 14 skipping to change at page 59, line 19
Source GC time: 3 minutes. Source GC time: 3 minutes.
The following values are recommended in a network where reconvergence The following values are recommended in a network where reconvergence
within 2 seconds after a mobility event is desired: within 2 seconds after a mobility event is desired:
Multicast Hello Interval: 0.5 seconds. Multicast Hello Interval: 0.5 seconds.
Unicast Hello Interval: infinite (no Unicast Hellos are sent). Unicast Hello Interval: infinite (no Unicast Hellos are sent).
IHU Interval, Update Interval, IHU Hold Time, and Route Expiry Link cost, IHU Interval, Update Interval, IHU Hold Time, and Route
Time: computed as in the first case above. Expiry Time: computed as in the first case above.
Request Timeout: initially 0.5 seconds, doubled every time a Request Timeout: initially 0.5 seconds, doubled every time a
request is resent, up to a maximum of three times. request is resent, up to a maximum of three times.
Urgent timeout: 0.2 seconds. Urgent timeout: 0.2 seconds.
Source GC time: 3 minutes. Source GC time: 3 minutes.
Appendix C. Route filtering Appendix C. Route filtering
skipping to change at page 62, line 30 skipping to change at page 62, line 34
attached to any TLVs that it understands and check the mandatory bit. attached to any TLVs that it understands and check the mandatory bit.
It must answer acknowledgment requests and must participate in the It must answer acknowledgment requests and must participate in the
Hello/IHU protocol. It must also be able to reply to seqno requests Hello/IHU protocol. It must also be able to reply to seqno requests
for routes that it announces and, and it should be able to reply to for routes that it announces and, and it should be able to reply to
route requests. route requests.
Experience shows that an IPv6-only stub implementation of Babel can Experience shows that an IPv6-only stub implementation of Babel can
be written in less than 1000 lines of C code and compile to 13 kB of be written in less than 1000 lines of C code and compile to 13 kB of
text on 32-bit CISC architecture. text on 32-bit CISC architecture.
Appendix F. Changes from previous versions Appendix F. Compatibility with previous versions
F.1. Changes since RFC 6126 The protocol defined in this document is a successor to the protocol
defined in [RFC6126] and [RFC7557]. While the two protocols are not
entirely compatible, the new protocol has been designed so that it
can be deployed in existing RFC 6126 networks without requiring a
flag day.
There are two optioal features that make the new protocol
incompatible with its predecessor. First of all, RFC 6126 did not
define Unicast hellos (Section 3.4.1), and an implementation of RFC
6126 will mis-interpret a Unicast Hello for a Multicast one; since
the sequence number space of Unicast Hellos is distinct from the
sequence space of Multicast Hellos, sending a Unicast Hello to an
implementation of RFC 6126 will confuse its link quality estimator.
Second, RFC 7557 did not define mandatory sub-TLVs (Section 4.4);
thus, an implementation of RFCs 6126 and 7557 will not correctly
ignore a TLV that carries an unknown mandatory sub-TLV; depending on
the sub-TLV, this might cause routing pathologies.
An implementation of this specification that never sends Unicast
Hellos and doesn't implement any extensions that use mandatory sub-
TLVs is safe to deploy in a network in which some nodes implement the
old protocol.
Two changes need to be made to an implementation of RFCs 6126 and
7557 so that it can safely interoperate in all cases with
implementations of this protocol. First, it needs to be modified to
either ignore or process Unicast Hellos. Second, it needs to be
modified to parse sub-TLVs of all the TLVs that it understands and
that allow sub-TLVs, and to ignore the TLV is an unknown mandatory
sub-TLV is found. It is not necessary to parse unknown TLVs, since
these are ignored in any case.
There are other changes, but these are not of a nature to prevent
interoperability:
o the conditions on route acquisition (Section 3.5.3) have been
relaxed;
o route selection should no longer use the route's sequence number
(Section 3.6);
o the format of the packet trailer has been defined (Section 4.2);
o router-ids with a value of all-zeros or all-ones have been
forbidden (Section 4.1.2);
o the compression state is now specific to an address family rather
than an address encoding Section 4.5;
o packet pacing is now recommended (Section 3.1).
Appendix G. Changes from previous versions
G.1. Changes since RFC 6126
o Changed UDP port number to 6696. o Changed UDP port number to 6696.
o Consistently use router-id rather than id. o Consistently use router-id rather than id.
o Clarified that the source garbage collection timer is reset after o Clarified that the source garbage collection timer is reset after
sending an update even if the entry was not modified. sending an update even if the entry was not modified.
o In section "Seqno Requests", fixed an erroneous "route request". o In section "Seqno Requests", fixed an erroneous "route request".
o In the description of the Seqno Request TLV, added the description o In the description of the Seqno Request TLV, added the description
of the Router-Id field. of the Router-Id field.
o Made router-ids all-0 and all-1 forbidden. o Made router-ids all-0 and all-1 forbidden.
F.2. Changes since draft-ietf-babel-rfc6126bis-00 G.2. Changes since draft-ietf-babel-rfc6126bis-00
o Added security considerations. o Added security considerations.
F.3. Changes since draft-ietf-babel-rfc6126bis-01 G.3. Changes since draft-ietf-babel-rfc6126bis-01
o Integrated the format of sub-TLVs. o Integrated the format of sub-TLVs.
o Mentioned for each TLV whether it supports sub-TLVs. o Mentioned for each TLV whether it supports sub-TLVs.
o Added Appendix D. o Added Appendix D.
o Added a mandatory bit in sub-TLVs. o Added a mandatory bit in sub-TLVs.
o Changed compression state to be per-AF rather than per-AE. o Changed compression state to be per-AF rather than per-AE.
skipping to change at page 63, line 28 skipping to change at page 64, line 34
o Clarified how router-ids are computed when bit 0x40 is set in o Clarified how router-ids are computed when bit 0x40 is set in
Updates. Updates.
o Relaxed the conditions for sending requests, and tightened the o Relaxed the conditions for sending requests, and tightened the
conditions for forwarding requests. conditions for forwarding requests.
o Clarified that neighbours should be acquired at some point, but it o Clarified that neighbours should be acquired at some point, but it
doesn't matter when. doesn't matter when.
F.4. Changes since draft-ietf-babel-rfc6126bis-02 G.4. Changes since draft-ietf-babel-rfc6126bis-02
o Added Unicast Hellos. o Added Unicast Hellos.
o Added unscheduled (interval-less) Hellos. o Added unscheduled (interval-less) Hellos.
o Changed Appendix A to consider Unicast and unscheduled Hellos. o Changed Appendix A to consider Unicast and unscheduled Hellos.
o Changed Appendix B to agree with the reference implementation. o Changed Appendix B to agree with the reference implementation.
o Added optional algorithm to avoid the hold time. o Added optional algorithm to avoid the hold time.
o Changed the table of pending seqno requests to be indexed by o Changed the table of pending seqno requests to be indexed by
router-id in addition to prefixes. router-id in addition to prefixes.
o Relaxed the route acquisition algorithm. o Relaxed the route acquisition algorithm.
o Replaced minimal implementations by stub implementations. o Replaced minimal implementations by stub implementations.
o Added acknowledgments section. o Added acknowledgments section.
F.5. Changes since draft-ietf-babel-rfc6126bis-03 G.5. Changes since draft-ietf-babel-rfc6126bis-03
o Clarified that all the data structures are conceptual. o Clarified that all the data structures are conceptual.
o Made sending and receiving Multicast Hellos a SHOULD, avoids o Made sending and receiving Multicast Hellos a SHOULD, avoids
expressing any opinion about Unicast Hellos. expressing any opinion about Unicast Hellos.
o Removed opinion about Multicast vs. Unicast Hellos (Appendix A.4). o Removed opinion about Multicast vs. Unicast Hellos (Appendix A.4).
o Made hold-time into a SHOULD rather than MUST. o Made hold-time into a SHOULD rather than MUST.
skipping to change at page 64, line 35 skipping to change at page 65, line 37
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 G.6. Changes since draft-ietf-babel-rfc6126bis-03
Minor editorial changes. Minor editorial changes.
F.7. Changes since draft-ietf-babel-rfc6126bis-04 G.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 G.8. Changes since draft-ietf-babel-rfc6126bis-05
o Added information about the packet trailer, now that it is used by o Added information about the packet trailer, now that it is used by
draft-ietf-babel-hmac. draft-ietf-babel-hmac.
F.9. Changes since draft-ietf-babel-rfc6126bis-06 G.9. Changes since draft-ietf-babel-rfc6126bis-06
o Added references to security documents. o Added references to security documents.
F.10. Changes since draft-ietf-babel-rfc6126bis-07 G.10. Changes since draft-ietf-babel-rfc6126bis-07
o Added list of obsoleted drafts to the abstract. o Added list of obsoleted drafts to the abstract.
o Updated references. o Updated references.
F.11. Changes since draft-ietf-babel-rfc6126bis-08 G.11. Changes since draft-ietf-babel-rfc6126bis-08
o Added recommendation that route selection should not take seqnos o Added recommendation that route selection should not take seqnos
into account. into account.
F.12. Changes since draft-ietf-babel-rfc6126bis-09 G.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 G.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 G.14. Changes since draft-ietf-babel-rfc6126bis-11
o Added recommendation that control traffic should be carried over o Added recommendation that control traffic should be carried over
IPv6 only. IPv6 only.
F.15. Changes since draft-ietf-babel-rfc6126bis-12 G.15. Changes since draft-ietf-babel-rfc6126bis-12
o Removed appendix about software availability. o Removed appendix about software availability.
o Expanded appendix about recommended values and added more o Expanded appendix about recommended values and added more
references to it in the body of the document. references to it in the body of the document.
o Added appendix about route filtering. o Added appendix about route filtering.
o Clarified definition of mandatory bit. o Clarified definition of mandatory bit.
skipping to change at page 66, line 21 skipping to change at page 67, line 21
o Added error checking requirements. o Added error checking requirements.
o Reworked security considerations. o Reworked security considerations.
o Added "in octets" and "in bits" in random places. o Added "in octets" and "in bits" in random places.
o Inserted full IANA registries. o Inserted full IANA registries.
o Editorial changes. o Editorial changes.
G.16. Changes since draft-ietf-babel-rfc6126bis-13
o Added a section about compatibility with 6126.
o Added AE registry to IANA considerations.
o Replaced Babel-HMAC with Babel-MAC, consistent with the change in
draft-ietf-babel-hmac.
o Removed section about external sources of willingness; filtering
is a better approach.
o Added recommendation to use a cost of 96 on wired links.
o 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
Google LLC Google LLC
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, California 94043 Mountain View, California 94043
USA USA
Email: dschinazi.ietf@gmail.com Email: dschinazi.ietf@gmail.com
 End of changes. 63 change blocks. 
106 lines changed or deleted 181 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/