draft-ietf-babel-rfc6126bis-15.txt   draft-ietf-babel-rfc6126bis-16.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: April 20, 2020 October 18, 2019 Expires: July 2, 2020 December 30, 2019
The Babel Routing Protocol The Babel Routing Protocol
draft-ietf-babel-rfc6126bis-15 draft-ietf-babel-rfc6126bis-16
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 April 20, 2020. This Internet-Draft will expire on July 2, 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 22 skipping to change at page 3, line 22
G.8. Changes since draft-ietf-babel-rfc6126bis-05 . . . . . . 67 G.8. Changes since draft-ietf-babel-rfc6126bis-05 . . . . . . 67
G.9. Changes since draft-ietf-babel-rfc6126bis-06 . . . . . . 67 G.9. Changes since draft-ietf-babel-rfc6126bis-06 . . . . . . 67
G.10. Changes since draft-ietf-babel-rfc6126bis-07 . . . . . . 67 G.10. Changes since draft-ietf-babel-rfc6126bis-07 . . . . . . 67
G.11. Changes since draft-ietf-babel-rfc6126bis-08 . . . . . . 67 G.11. Changes since draft-ietf-babel-rfc6126bis-08 . . . . . . 67
G.12. Changes since draft-ietf-babel-rfc6126bis-09 . . . . . . 67 G.12. Changes since draft-ietf-babel-rfc6126bis-09 . . . . . . 67
G.13. Changes since draft-ietf-babel-rfc6126bis-10 . . . . . . 67 G.13. Changes since draft-ietf-babel-rfc6126bis-10 . . . . . . 67
G.14. Changes since draft-ietf-babel-rfc6126bis-11 . . . . . . 67 G.14. Changes since draft-ietf-babel-rfc6126bis-11 . . . . . . 67
G.15. Changes since draft-ietf-babel-rfc6126bis-12 . . . . . . 67 G.15. Changes since draft-ietf-babel-rfc6126bis-12 . . . . . . 67
G.16. Changes since draft-ietf-babel-rfc6126bis-13 . . . . . . 68 G.16. Changes since draft-ietf-babel-rfc6126bis-13 . . . . . . 68
G.17. Changes since draft-ietf-babel-rfc6126bis-14 . . . . . . 68 G.17. Changes since draft-ietf-babel-rfc6126bis-14 . . . . . . 68
G.18. Changes since draft-ietf-babel-rfc6126bis-14 . . . . . . 69
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 69
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 13, line 41 skipping to change at page 13, line 41
(Section 3.4.2), then the TLV MUST be sent early enough to meet the (Section 3.4.2), then the TLV MUST be sent early enough to meet the
explicit deadline (with a small margin to allow for propagation explicit deadline (with a small margin to allow for propagation
delays). In all other cases, the TLV SHOULD be sent out within one- delays). In all other cases, the TLV SHOULD be sent out within one-
half of the Multicast Hello interval. half of the Multicast Hello interval.
In order to avoid packet drops (either at the sender or at the In order to avoid packet drops (either at the sender or at the
receiver), a delay SHOULD be introduced between successive packets receiver), a delay SHOULD be introduced between successive packets
sent out on the same interface, within the constraints of the sent out on the same interface, within the constraints of the
previous paragraph. Note however that such packet pacing might previous paragraph. Note however that such packet pacing might
impair the ability of some link layers (e.g., IEEE 802.11) to perform impair the ability of some link layers (e.g., IEEE 802.11) to perform
link aggregation. packet aggregation.
3.2. Data Structures 3.2. Data Structures
In this section, we give a description of the data structures that In this section, we give a description of the data structures that
every Babel speaker maintains. This description is conceptual: a every Babel speaker maintains. This description is conceptual: a
Babel speaker may use different data structures as long as the Babel speaker may use different data structures as long as the
resulting protocol is the same as the one described in this document. resulting protocol is the same as the one described in this document.
For example, rather than maintaining a single table containing both For example, rather than maintaining a single table containing both
selected and unselected (fallback) routes, as described in selected and unselected (fallback) routes, as described in
Section 3.2.6 below, an actual implementation would probably use two Section 3.2.6 below, an actual implementation would probably use two
skipping to change at page 25, line 23 skipping to change at page 25, line 23
policy MUST only satisfy the following properties: policy MUST only satisfy the following properties:
o a route with infinite metric (a retracted route) is never o a route with infinite metric (a retracted route) is never
selected; selected;
o an unfeasible route is never selected. o an unfeasible route is never selected.
Route selection MUST NOT take seqnos into account: a route MUST NOT Route selection MUST NOT take seqnos into account: a route MUST NOT
be preferred just because it carries a higher (more recent) seqno. be preferred just because it carries a higher (more recent) seqno.
Doing otherwise would cause route oscillation while a new seqno Doing otherwise would cause route oscillation while a new seqno
propagates through the network, possibly following multiple paths of propagates across the network, and might create persistent blackholes
different latency, and might even create persistent blackholes if the if the metric being used is not left-distributive (Section 3.5.2).
metric being used is not left-distributive (Section 3.5.2).
The obvious route selection strategy is to choose for each The obvious route selection strategy is to choose for each
destination the feasible route with lowest metric. However, with destination the feasible route with lowest metric. However, with
continuously varying costs and metrics this simple strategy will in continuously varying costs and metrics this simple strategy will in
some cases lead to route oscillations. See Appendix A.4 for a some cases lead to route oscillations. See Appendix A.4 for a
discussion of the issues and suggested strategies for dealing with discussion of the issues and suggested strategies for dealing with
them. them.
After the route selection procedure is run, triggered updates After the route selection procedure is run, triggered updates
(Section 3.7.2) and requests (Section 3.8.2) are sent. (Section 3.7.2) and requests (Section 3.8.2) are sent.
skipping to change at page 46, line 8 skipping to change at page 46, line 8
wildcard request). wildcard request).
Plen The length in bits of the requested prefix. Plen The length in bits of the requested prefix.
Prefix The prefix being requested. This field's size is Plen/8 Prefix The prefix being requested. This field's size is Plen/8
rounded upwards. rounded upwards.
A Request TLV prompts the receiver to send an update message A Request TLV prompts the receiver to send an update message
(possibly a retraction) for the prefix specified by the AE, Plen, and (possibly a retraction) for the prefix specified by the AE, Plen, and
Prefix fields, or a full dump of its route table if AE is 0 (in which Prefix fields, or a full dump of its route table if AE is 0 (in which
case Plen MUST be 0 and Prefix is of length 0). case Plen must be 0 and Prefix is of length 0).
This TLV is self-terminating, and allows sub-TLVs. This TLV is self-terminating, and allows sub-TLVs.
4.6.11. Seqno Request 4.6.11. Seqno Request
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 10 | Length | AE | Plen | | Type = 10 | Length | AE | Plen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 51, line 36 skipping to change at page 51, line 36
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.
Without additional security mechanisms, Babel trusts any information Without additional security mechanisms, Babel trusts any information
it receives in plaintext UDP datagrams and acts on it. An attacker it receives in plaintext UDP datagrams and acts on it. An attacker
that is present on the local network can impact Babel operation in a that is present on the local network can impact Babel operation in a
variety of ways, for example they can: variety of ways; for example they can:
o spoof a Babel packet, and redirect traffic by announcing a route o spoof a Babel packet, and redirect traffic by announcing a route
with a smaller metric, a larger sequence number, or a longer with a smaller metric, a larger sequence number, or a longer
prefix; prefix;
o spoof a malformed packet, which could cause an insufficiently o spoof a malformed packet, which could cause an insufficiently
robust implementation to crash or interfere with the rest of the robust implementation to crash or interfere with the rest of the
network; network;
o replay a previously captured Babel packet, which could cause o replay a previously captured Babel packet, which could cause
traffic to be redirected, blackholed or otherwise interfere with traffic to be redirected, blackholed or otherwise interfere with
the network. the network.
When carried over IPv6, Babel packets are ignored unless they are When carried over IPv6, Babel packets are ignored unless they are
sent from a link-local IPv6 address; since routers don't forward sent from a link-local IPv6 address; since routers don't forward
link-local IPv6 packets, this mitigates the attacks outlined above by link-local IPv6 packets, this mitigates the attacks outlined above by
restricting them to on-link attackers. No such natural protection restricting them to on-link attackers. No such natural protection
exists when Babel packets are carried over IPv4. exists when Babel packets are carried over IPv4, which is one of the
reasons why it is recommended to deploy Babel over IPv6
(Section 3.1).
If packets arriving at a Babel node cannot be trusted, either because It is usually difficult to ensure that packets arriving at a Babel
it cannot be ensured that they originated on a local link, because node are trusted, even in the case where the local link is believed
the local link itself is not protected by a sufficiently strong to be secure. For that reason, it is RECOMMENDED that all Babel
lower-layer mechanism, or because it is not desirable to trust a traffic be protected by an application-layer cryptographic protocol.
lower-layer security mechanism, then the Babel control traffic must There are currently two suitable mechanisms, which implement
be protected by an application-layer mechanism. There are currently different tradeoffs between implementation simplicity and security:
two such mechanisms, which implement different tradeoffs between
implementation simplicity and security:
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 MAC authentication [BABEL-MAC] appends a message authentication o MAC authentication [BABEL-MAC] appends a message authentication
code (MAC) to every Babel packet to prove that it originated at a code (MAC) to every Babel packet to prove that it originated at a
node that knows a shared secret, and includes sufficient node that knows a shared secret, and includes sufficient
additional information to prove that the packet is fresh (not additional information to prove that the packet is fresh (not
replayed). replayed).
skipping to change at page 52, line 36 skipping to change at page 52, line 36
Both mechanisms enable 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. While Babel-DTLS supports messages and prevent message replay. While Babel-DTLS supports
asymmetric keying and ensures confidentiality, Babel-MAC has a much asymmetric keying and ensures confidentiality, Babel-MAC has a much
more limited scope (see Sections 1.1, 1.2 and 7 of [BABEL-MAC]). more limited scope (see Sections 1.1, 1.2 and 7 of [BABEL-MAC]).
Since Babel-MAC is simpler and more lightweight, it is recommended in Since Babel-MAC is simpler and more lightweight, it is recommended in
preference to Babel-DTLS in deployments where its limitations are preference to Babel-DTLS in deployments where its limitations are
acceptable, i.e., when symmetric keying is sufficient and where the acceptable, i.e., when symmetric keying is sufficient and where the
routing information is not considered confidential. routing information is not considered confidential.
Every implementation of Babel SHOULD implement BABEL-MAC.
One should be aware that the information that a mobile Babel node One should be aware that the information that a mobile Babel node
announces to the whole routing domain is sufficient to determine a announces to the whole routing domain is sufficient to determine the
mobile node's physical location with reasonable precision, which mobile node's physical location with reasonable precision, which
might cause privacy concerns even if the control traffic is protected might cause privacy concerns even if the control traffic is protected
from unauthenticated attackers by Babel-DTLS. This issue may be from unauthenticated attackers by a cryptographic mechanism such as
mitigated somewhat by using randomly chosen router-ids and randomly Babel-DTLS. This issue may be mitigated somewhat by using randomly
chosen IP addresses, and changing them often enough. chosen router-ids and randomly chosen IP addresses, and changing them
often 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, Benjamin Kaduk, Joao Sobrinho and Martin Hoiland-Jorgensen, Benjamin Kaduk, Joao Sobrinho and Martin
Vigoureux. Earlier versions of this document greatly benefited from Vigoureux. Earlier versions of this document greatly benefited from
the input of Joel Halpern. The address compression technique was the input of Joel Halpern. The address compression technique was
inspired by [PACKETBB]. inspired by [PACKETBB].
skipping to change at page 58, line 30 skipping to change at page 58, line 30
Route selection (Section 3.6) is the process by which a node selects Route selection (Section 3.6) is the process by which a node selects
a single route among the routes that it has available towards a given a single route among the routes that it has available towards a given
destination. With Babel, any route selection procedure that only destination. With Babel, any route selection procedure that only
ever chooses feasible routes with a finite metric will yield a set of ever chooses feasible routes with a finite metric will yield a set of
loop-free routes; however, not all route selection policies will loop-free routes; however, not all route selection policies will
yield good results. yield good results.
The obvious route selection procedure is to pick, for every The obvious route selection procedure is to pick, for every
destination, the feasible route with minimal metric. When all destination, the feasible route with minimal metric. When all
metrics are stable, this strategy leads to convergence to a tree of metrics are stable, this strategy ensures convergence to a tree of
shortest paths (assuming that the metric is left-distributive). shortest paths (assuming that the metric is left-distributive).
There are two reasons, however, why this strategy leads to There are two reasons, however, why this strategy leads to
instability in the presence of continously varying metrics such as instability in the presence of continously varying metrics such as
ETX (Appendix A.2.2). First, if two parallel routes oscillate around ETX (Appendix A.2.2). First, if two parallel routes oscillate around
a common value, then the smallest metric strategy will keep switching a common value, then the smallest metric strategy will keep switching
between the two. Second, when a route is selected, congestion along between the two. Second, when a route is selected, congestion along
it increases, which might increase packet loss, which in turn could it increases, which might increase packet loss, which in turn could
cause its metric to increase; this is a feedback loop, of the kind cause its metric to increase; this is a feedback loop, of the kind
that is prone to causing persistent oscillations. that is prone to causing persistent oscillations.
A simple strategy to avoid this kind of instabilities is to only A simple strategy to avoid this kind of instabilities is to only
switch routes when the target route's metric is smaller by some switch routes when the target route's metric is smaller by some
constant than the currently selected metric. However, this approach constant margin than the currently selected metric. However, this
is difficult to tune: if the constant is too small, then it fails to approach is difficult to tune: if the constant is too small, then it
avoid oscillations, and if it is too large, then it leads to sub- doesn't avoid oscillations, and if it is too large, then it leads to
optimal routing. A better strategy is to apply hysteresis sub-optimal routing; thus, a better strategy is to apply hysteresis
(sensitivity to a route's history) to the route selection algorithm. (sensitivity to a route's history) to the route selection algorithm.
The following hysteresis algorithm appears to yield good results with The following hysteresis algorithm appears to yield good results with
a variety of metrics. a variety of metrics.
For every route R, in addition to the route's metric m(R), maintain a For every route R, in addition to the route's metric m(R), maintain a
smoothed version of m(R) written ms(R) (we suggest computing ms(R) as smoothed version of m(R) written ms(R) (we suggest computing ms(R) as
an exponential average of m(R) with a time constant equal to a small an exponential average of m(R) with a time constant equal to a small
multiple of the Hello interval). If no route to a given destination multiple of the Hello interval). If no route to a given destination
is selected, then select the route with the smallest metric, ignoring is selected, then select the route with the smallest metric, ignoring
the smoothed metric. If a route R is selected, then switch to a the smoothed metric. If a route R is selected, then switch to a
skipping to change at page 63, line 44 skipping to change at page 63, line 44
text on 32-bit CISC architecture. text on 32-bit CISC architecture.
Appendix F. Compatibility with previous versions Appendix F. Compatibility with previous versions
The protocol defined in this document is a successor to the protocol The protocol defined in this document is a successor to the protocol
defined in [RFC6126] and [RFC7557]. While the two protocols are not defined in [RFC6126] and [RFC7557]. While the two protocols are not
entirely compatible, the new protocol has been designed so that it entirely compatible, the new protocol has been designed so that it
can be deployed in existing RFC 6126 networks without requiring a can be deployed in existing RFC 6126 networks without requiring a
flag day. flag day.
There are three optional features that make the new protocol There are three optional features that make this protocol
incompatible with its predecessor. First of all, RFC 6126 did not incompatible with its predecessor. First of all, RFC 6126 did not
define Unicast hellos (Section 3.4.1), and an implementation of RFC define Unicast hellos (Section 3.4.1), and an implementation of RFC
6126 will mis-interpret a Unicast Hello for a Multicast one; since 6126 will mis-interpret a Unicast Hello for a Multicast one; since
the sequence number space of Unicast Hellos is distinct from the the sequence number space of Unicast Hellos is distinct from the
sequence space of Multicast Hellos, sending a Unicast Hello to an sequence space of Multicast Hellos, sending a Unicast Hello to an
implementation of RFC 6126 will confuse its link quality estimator. implementation of RFC 6126 will confuse its link quality estimator.
Second, RFC 6126 did not define unscheduled Hellos, and an Second, RFC 6126 did not define unscheduled Hellos, and an
implementation of RFC 6126 will mis-parse Hellos with an interval implementation of RFC 6126 will mis-parse Hellos with an interval
equal to 0. Finally, RFC 7557 did not define mandatory sub-TLVs equal to 0. Finally, RFC 7557 did not define mandatory sub-TLVs
(Section 4.4), and thus, an implementation of RFCs 6126 and 7557 will (Section 4.4), and thus, an implementation of RFCs 6126 and 7557 will
not correctly ignore a TLV that carries an unknown mandatory sub-TLV; not correctly ignore a TLV that carries an unknown mandatory sub-TLV;
depending on the sub-TLV, this might cause routing pathologies. depending on the sub-TLV, this might cause routing pathologies.
An implementation of this specification that never sends Unicast or An implementation of this specification that never sends Unicast or
unscheduled Hellos and doesn't implement any extensions that use unscheduled Hellos and doesn't implement any extensions that use
mandatory sub-TLVs is safe to deploy in a network in which some nodes mandatory sub-TLVs is safe to deploy in a network in which some nodes
implement the old protocol. implement the protocol described in RFCs 6126 and 7557.
Two changes need to be made to an implementation of RFCs 6126 and Two changes need to be made to an implementation of RFCs 6126 and
7557 so that it can safely interoperate in all cases with 7557 so that it can safely interoperate in all cases with
implementations of this protocol. First, it needs to be modified to implementations of this protocol. First, it needs to be modified to
either ignore or process Unicast and unscheduled Hellos. Second, it either ignore or process Unicast and unscheduled Hellos. Second, it
needs to be modified to parse sub-TLVs of all the TLVs that it needs to be modified to parse sub-TLVs of all the TLVs that it
understands and that allow sub-TLVs, and to ignore the TLV if an understands and that allow sub-TLVs, and to ignore the TLV if an
unknown mandatory sub-TLV is found. It is not necessary to parse unknown mandatory sub-TLV is found. It is not necessary to parse
unknown TLVs, as these are ignored in any case. unknown TLVs, as these are ignored in any case.
skipping to change at page 69, line 5 skipping to change at page 69, line 5
G.17. Changes since draft-ietf-babel-rfc6126bis-14 G.17. Changes since draft-ietf-babel-rfc6126bis-14
o Added unscheduled Hellos to compatibility considerations. o Added unscheduled Hellos to compatibility considerations.
o Created new appendix about route selection. o Created new appendix about route selection.
o Reworked security considerations. o Reworked security considerations.
o Added some comments about packet pacing and low update intervals. o Added some comments about packet pacing and low update intervals.
G.18. Changes since draft-ietf-babel-rfc6126bis-14
o Implementing Babel-MAC is now recommended.
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. 18 change blocks. 
29 lines changed or deleted 36 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/