rfc9079.original   rfc9079.txt 
Network Working Group M. Boutier Internet Engineering Task Force (IETF) M. Boutier
Internet-Draft J. Chroboczek Request for Comments: 9079 J. Chroboczek
Intended status: Standards Track IRIF, University of Paris Category: Standards Track IRIF, University of Paris
Expires: 23 October 2021 21 April 2021 ISSN: 2070-1721 August 2021
Source-Specific Routing in Babel Source-Specific Routing in the Babel Routing Protocol
draft-ietf-babel-source-specific-08
Abstract Abstract
Source-specific routing (also known as Source-Address Dependent Source-specific routing, also known as Source Address Dependent
Routing, SADR) is an extension to traditional next-hop routing where Routing (SADR), is an extension to traditional next-hop routing where
packets are forwarded according to both their destination and their packets are forwarded according to both their destination address and
source address. This document describes an extension for source- their source address. This document describes an extension for
specific routing to the Babel routing protocol. source-specific routing to the Babel routing protocol.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 23 October 2021. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9079.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Simplified BSD License text to this document. Code Components extracted from this document must
as described in Section 4.e of the Trust Legal Provisions and are include Simplified BSD License text as described in Section 4.e of
provided without warranty as described in the Simplified BSD License. the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction and background . . . . . . . . . . . . . . . . . 2 1. Introduction and Background
1.1. Application to multihoming . . . . . . . . . . . . . . . 3 1.1. Application to Multihoming
1.2. Other applications . . . . . . . . . . . . . . . . . . . 4 1.2. Other Applications
1.3. Specificity of prefix pairs . . . . . . . . . . . . . . . 5 1.3. Specificity of Prefix Pairs
2. Specification of Requirements . . . . . . . . . . . . . . . . 6 2. Specification of Requirements
3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 7 3. Data Structures
3.1. The Source Table . . . . . . . . . . . . . . . . . . . . 7 3.1. The Source Table
3.2. The Route Table . . . . . . . . . . . . . . . . . . . . . 7 3.2. The Route Table
3.3. The Table of Pending Seqno Requests . . . . . . . . . . . 7 3.3. The Table of Pending Seqno Requests
4. Data Forwarding . . . . . . . . . . . . . . . . . . . . . . . 8 4. Data Forwarding
5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 8 5. Protocol Operation
5.1. Protocol Messages . . . . . . . . . . . . . . . . . . . . 9 5.1. Protocol Messages
5.2. Wildcard Messages . . . . . . . . . . . . . . . . . . . . 9 5.2. Wildcard Messages
6. Compatibility with the base protocol . . . . . . . . . . . . 10 6. Compatibility with the Base Protocol
6.1. Starvation and Blackholes . . . . . . . . . . . . . . . . 10 6.1. Starvation and Blackholes
7. Protocol Encoding . . . . . . . . . . . . . . . . . . . . . . 10 7. Protocol Encoding
7.1. Source Prefix sub-TLV . . . . . . . . . . . . . . . . . . 11 7.1. Source Prefix Sub-TLV
7.2. Source-specific Update . . . . . . . . . . . . . . . . . 12 7.2. Source-Specific Update
7.3. Source-specific Route Request . . . . . . . . . . . . . . 12 7.3. Source-Specific Route Request
7.4. Source-Specific Seqno Request . . . . . . . . . . . . . . 12 7.4. Source-Specific Seqno Request
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations
9. Security considerations . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 10. References
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References
11.1. Normative References . . . . . . . . . . . . . . . . . . 13 10.2. Informative References
11.2. Informative References . . . . . . . . . . . . . . . . . 13 Acknowledgments
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses
1. Introduction and background 1. Introduction and Background
The Babel routing protocol [RFC8966] is a distance vector routing The Babel routing protocol [RFC8966] is a distance vector routing
protocol for next-hop routing. In next-hop routing, each node protocol for next-hop routing. In next-hop routing, each node
maintains a forwarding table which maps destination prefixes to next maintains a forwarding table that maps destination prefixes to next
hops. The forwarding decision is a per-packet operation which hops. The forwarding decision is a per-packet operation that depends
depends on the destination address of the packets and on the entries on the destination address of the packets and on the entries of the
of the forwarding table. When a packet is about to be routed, its forwarding table. When a packet is about to be routed, its
destination address is compared to the prefixes of the routing table: destination address is compared to the prefixes of the routing table:
the entry with the most specific prefix containing the destination the entry with the most specific prefix containing the destination
address of the packet is chosen, and the packet is forwarded to the address of the packet is chosen, and the packet is forwarded to the
associated next-hop. Next-hop routing is a simple, well understood associated next hop. Next-hop routing is a simple, well-understood
paradigm that works satisfactorily in a large number of cases. paradigm that works satisfactorily in a large number of cases.
The use of next-hop routing limits the flexibility of the routing The use of next-hop routing limits the flexibility of the routing
system in two ways. First, since the routing decision is local to system in two ways. First, since the routing decision is local to
each router, a router A can only select a route ABC...Z if its each router, a router A can only select a route ABC...Z if its
neighbouring router B has selected the route BC...Z. Second, the neighbouring router B has selected the route BC...Z. Second, the
only criterion used by a router to choose a route is the destination only criterion used by a router to choose a route is the destination
address: two packets with the same destination follow the same route. address: two packets with the same destination follow the same route.
Yet, there are other data in the IP header that could conceivably be Yet, there are other data in the IP header that could conceivably be
used to guide the routing decision -- the ToS octet and, of course, used to guide the routing decision -- the Type of Service (ToS) octet
the source address. and, of course, the source address.
Source-specific routing [SS-ROUTING], or Source Address Dependent Source-specific routing [SS-ROUTING], or Source Address Dependent
Routing (SADR), is a modest extension to next-hop routing where the Routing (SADR), is a modest extension to next-hop routing where the
forwarding decision depends not only on the destination address but forwarding decision depends not only on the destination address but
also on the source address of the packet being routed, which makes it also on the source address of the packet being routed, which makes it
possible for two packets with the same destination but different possible for two packets with the same destination but different
source addresses to be routed following different paths. source addresses to be routed following different paths.
This document describes a source-specific routing extension for the This document describes a source-specific routing extension for the
Babel routing protocol [RFC8966]. This involves minor changes to the Babel routing protocol [RFC8966]. This involves minor changes to the
data structures, which must include a source prefix in addition to data structures, which must include a source prefix in addition to
the destination prefix already present, and some changes to the the destination prefix already present, and some changes to the
Update, Route Request and Seqno Request TLVs, which are extended with Update, Route Request, and Seqno Request TLVs, which are extended
a source prefix. The source prefix is encoded using a mandatory sub- with a source prefix. The source prefix is encoded using a mandatory
TLV ([RFC8966] Section 4.4). sub-TLV ([RFC8966], Section 4.4).
1.1. Application to multihoming 1.1. Application to Multihoming
Multihoming is the practice of connecting a single network to two or Multihoming is the practice of connecting a single network to two or
more transit networks. The main application of source-specific more transit networks. The main application of source-specific
routing is a form of multihoming known as "multihoming with multiple routing is a form of multihoming known as "multihoming with multiple
addresses". addresses".
Classical multihoming consists in assigning a provider-independent Classical multihoming consists of assigning a provider-independent
range of addresses to the multihomed network and announcing it to all range of addresses to the multihomed network and announcing it to all
transit providers. While classical multihoming works well for large transit providers. While classical multihoming works well for large
networks, the cost of obtaining a provider-independent address range networks, the cost of obtaining a provider-independent address range
and announcing it globally in the Internet is prohibitive for small and announcing it globally in the Internet is prohibitive for small
networks. Unfortunately, it is not possible to implement classical networks. Unfortunately, it is not possible to implement classical
multihoming with ordinary provider-dependent addresses: in a network multihoming with ordinary provider-dependent addresses: in a network
connected to two providers A and B, a packet with a source address connected to two providers A and B, a packet with a source address
allocated by A needs to be routed through the edge router connected allocated by A needs to be routed through the edge router connected
to A. If it is routed through the edge router connected to B, it to A. If it is routed through the edge router connected to B, it
will most likely be filtered (dropped), in accordance with [BCP84]. will most likely be filtered (dropped), in accordance with [BCP84].
skipping to change at page 4, line 6 skipping to change at line 144
In multihoming with multiple addresses, every host in the multihomed In multihoming with multiple addresses, every host in the multihomed
network is assigned multiple addresses, one for each transit network is assigned multiple addresses, one for each transit
provider. Additional mechanisms are needed in order (i) to choose, provider. Additional mechanisms are needed in order (i) to choose,
for each packet, a source address that is associated with a provider for each packet, a source address that is associated with a provider
that is currently up, and (ii) to route each packet towards the that is currently up, and (ii) to route each packet towards the
router connected to the provider associated with its source address. router connected to the provider associated with its source address.
One might argue that multihoming with multiple addresses splits the One might argue that multihoming with multiple addresses splits the
difficult problem of multihoming into two simpler sub-problems. difficult problem of multihoming into two simpler sub-problems.
The issue of choosing a suitable source address is a decision local The issue of choosing a suitable source address is a decision local
to the sending host, and an area of active research. The simplest to the sending host and is an area of active research. The simplest
solution is to use a traditional transport-layer protocol, such as solution is to use a traditional transport-layer protocol, such as
TCP, and to probe all available source addresses at connection time, TCP, and to probe all available source addresses at connection time,
analogously to what is already done with destination addresses, analogously to what is already done with destination addresses,
either sequentially [RFC3484] or in parallel [RFC8305]. Since the either sequentially [RFC6724] or in parallel [RFC8305]. Since the
transport-layer protocol is not aware of the multiple available transport-layer protocol is not aware of the multiple available
addresses, flows are interrupted when the selected provider goes down addresses, flows are interrupted when the selected provider goes down
(from the point of view of the user, all TCP connections are dropped (from the point of view of the user, all TCP connections are dropped
when the network environment changes). A better user experience can when the network environment changes). A better user experience can
be provided by making available all of the potential source and be provided by making all of the potential source and destination
destination addresses to higher layer protocols, either at the addresses available to higher-layer protocols, either at the
transport layer [RFC8684] [RFC4960], or at the applicaton layer transport layer [RFC8684] [RFC4960] or at the application layer
[RFC8445]. [RFC8445].
Source-specific routing solves the problem of routing a packet to the Source-specific routing solves the problem of routing a packet to the
edge router indicated by its source address. Every edge router edge router indicated by its source address. Every edge router
announces into the routing domain a default route specific to the announces into the routing domain a default route specific to the
prefix associated with the provider it is connected to. This route prefix associated with the provider it is connected to. This route
is propagated all the way to the routers on the access link, which is propagated all the way to the routers on the access link, which
are therefore able to route every packet to the correct router. are therefore able to route every packet to the correct router.
Hosts simply send packets to their default router -- no host changes Hosts simply send packets to their default router -- no host changes
are necessary at the network layer. are necessary at the network layer.
1.2. Other applications 1.2. Other Applications
In addition to multihoming with multiple addresses, we are aware of In addition to multihoming with multiple addresses, we are aware of
two applications of source-specific routing. Tunnels and VPNs are two applications of source-specific routing. Tunnels and VPNs are
packet encapsulation techniques that are commonly used in the packet encapsulation techniques that are commonly used in the
Internet to establish a network-layer topology that is different from Internet to establish a network-layer topology that is different from
the physical topology. In some deployments, the default route points the physical topology. In some deployments, the default route points
at the tunnel; this causes the network stack to attempt to send at the tunnel; this causes the network stack to attempt to send
encapsulated packets through the tunnel, which causes it to break. encapsulated packets through the tunnel, which causes it to break.
Various solutions to this problem are possible, the most common of Various solutions to this problem are possible, the most common of
which is to point a host route at the tunnel endpoint. which is to point a host route at the tunnel endpoint.
skipping to change at page 5, line 8 skipping to change at line 195
The third application of source-specific routing is controlled The third application of source-specific routing is controlled
anycast. Anycast is a technique in which a single destination anycast. Anycast is a technique in which a single destination
address is used to represent multiple network endpoints, collectively address is used to represent multiple network endpoints, collectively
called an "anycast group". A packet destined to the anycast group is called an "anycast group". A packet destined to the anycast group is
routed to an arbitrary member of the group, typically the one that is routed to an arbitrary member of the group, typically the one that is
nearest according to the routing protocol. nearest according to the routing protocol.
In many applications of anycast, such as DNS root servers, the In many applications of anycast, such as DNS root servers, the
nondeterminism of anycast is acceptable; some applications, however, nondeterminism of anycast is acceptable; some applications, however,
require finer control. For example, in some Content Distribution require finer control. For example, in some Content Distribution
Networks (CDNs) every endpoint is expected to handle a well-defined Networks (CDNs), every endpoint is expected to handle a well-defined
subset of the client population. With source-specific routing, it is subset of the client population. With source-specific routing, it is
possible for each member of the anycast group to announce a route possible for each member of the anycast group to announce a route
specific to its client population, a technique that is both simpler specific to its client population, a technique that is both simpler
and more robust than manually tweaking the routing protocol's metric and more robust than manually tweaking the routing protocol's metric
("prepending" in BGP). ("prepending" in BGP).
1.3. Specificity of prefix pairs 1.3. Specificity of Prefix Pairs
In ordinary next-hop routing, when multiple routing table entries In ordinary next-hop routing, when multiple routing table entries
match the destination of a packet, the "longest prefix rule" mandates match the destination of a packet, the "longest prefix rule" mandates
that the most specific one applies. The reason why this rule makes that the most specific entry applies. The reason why this rule makes
sense is that the set of prefixes has the following "tree property": sense is that the set of prefixes has the following "tree property":
for any prefixes P and P', either P and P' are disjoint, or one is For any prefixes P and P', either P and P' are disjoint, or one is
more specific than the other. more specific than the other.
It would be a natural proposition to order pairs of prefixes It would be a natural proposition to order pairs of prefixes
pointwise: to define that (D,S) is more specific than (D',S') when D pointwise: to define that (D,S) is more specific than (D',S') when D
is more specific than D and S is more specific than S'. is more specific than D and S is more specific than S'.
Unfortunately, the set of pairs of prefixes with the pointwise Unfortunately, the set of pairs of prefixes with the pointwise
ordering doesn't satisfy the tree property. Indeed, consider the ordering doesn't satisfy the tree property. Indeed, consider the
following two pairs: following two pairs:
(2001:db8:0:1::/64, ::/0) and (::/0, 2001:db8:0:2::/64) (2001:db8:0:1::/64, ::/0) and (::/0, 2001:db8:0:2::/64)
These two pairs are not disjoint (a packet with destination These two pairs are not disjoint (a packet with destination
2001:db8:0:1::1 and source 2001:db8:0:2::1 is matched by both), but 2001:db8:0:1::1 and source 2001:db8:0:2::1 is matched by both), but
neither is more specific than the other. The effect is that there is neither is more specific than the other. The effect is that there is
no natural unambiguous way to interpret a routing table such as the no natural, unambiguous way to interpret a routing table such as the
following: following:
destination source next-hop destination source next-hop
2001:db8:0:1::/64 ::/0 A 2001:db8:0:1::/64 ::/0 A
::/0 2001:db8:0:2::/64 B ::/0 2001:db8:0:2::/64 B
A more refined ordering over pairs of prefixes is required in order A finer ordering of pairs of prefixes is required in order to avoid
to avoid all ambiguities. There are two natural choices: the all ambiguities. There are two natural choices: destination-first
destination-first ordering, where (D,S) is more specific than (D',S') ordering, where (D,S) is more specific than (D',S') when
when
* D is strictly more specific than D'; or * D is strictly more specific than D', or
* D = D' and S is more specific than S', * D = D', and S is more specific than S'
and, symmetrically, the source-first ordering, in which sources are
and, symmetrically, source-first ordering, in which sources are
compared first and destinations second. compared first and destinations second.
Expedient as it would be to leave the choice to the implementation, Expedient as it would be to leave the choice to the implementation,
this is not possible: all routers in a routing domain must use the this is not possible: all routers in a routing domain must use the
same ordering, lest persistent routing loops occur. Indeed, consider same ordering lest persistent routing loops occur. Indeed, consider
the following topology: the following topology:
A --- B --- C --- D A --- B --- C --- D
Suppose that A announces a route for (::/0, 2001:db8:0:2::/64), while Suppose that A announces a route for (::/0, 2001:db8:0:2::/64), while
D announces a route for (2001:db8:0:1::/64, ::/0). Suppose further D announces a route for (2001:db8:0:1::/64, ::/0). Suppose further
that B uses the destination-first ordering, while C uses the source- that B uses destination-first ordering while C uses source-first
first ordering. Then a packet that matches both routes, say, with ordering. Then a packet that matches both routes, say, with
destination 2001:db8:0:1::1 and source 2001:db8:0:2::1, would be sent destination 2001:db8:0:1::1 and source 2001:db8:0:2::1, would be sent
by B towards D and by C towards A, and would therefore loop by B towards D and by C towards A and would therefore loop
indefinitely between B and C. indefinitely between B and C.
This document mandates (Section 4) that all routers use the This document mandates (Section 4) that all routers use destination-
destination-first ordering, which is generally believed to be more first ordering, which is generally believed to be more useful than
useful than the source-first ordering. Consider the following source-first ordering. Consider the following topology, where A is
topology, where A is an edge router connected to the Internet and B an edge router connected to the Internet and B is an internal router
is an internal router connected to an access network N: connected to an access network N:
(::/0, S) (D, ::/0) (::/0, S) (D, ::/0)
Internet --- A --- B --- N Internet --- A --- B --- N
A announces a source-specific default route with source S (::/0, S), A announces a source-specific default route with source S (::/0, S),
while B announces a non-specific route to prefix D. Consider what while B announces a nonspecific route to prefix D. Consider what
happens to a packet with a desination in D and a source in S. With happens to a packet with a destination in D and a source in S. With
the destination-first ordering, the packet is routed towards the destination-first ordering, the packet is routed towards the network
network N, which is the only way it can possibly reach its N, which is the only way it can possibly reach its destination. With
destination. With the source-first ordering, on the other hand, the source-first ordering, on the other hand, the packet is sent towards
packet is sent towards the Internet, with no hope to ever reach its the Internet, with no hope of ever reaching its destination in N.
destination in N.
2. Specification of Requirements 2. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Data Structures 3. Data Structures
A number of the conceptual data structures described in Section 3.2 A number of the conceptual data structures described in Section 3.2
of [RFC8966] contain a destination prefix. This specification of [RFC8966] contain a destination prefix. This specification
extends these data structures with a source prefix. Data from the extends these data structures with a source prefix. Data from the
original protocol, which do not specify a source prefix, are stored original protocol, which do not specify a source prefix, are stored
with a zero length source prefix, which matches exactly the same set with a zero-length source prefix, which matches the exact same set of
of packets as the original, non-source-specific data. packets as the original, non-source-specific data.
3.1. The Source Table 3.1. The Source Table
Every Babel node maintains a source table, as described in [RFC8966] Every Babel node maintains a source table, as described in [RFC8966],
Section 3.2.5. A source-specific Babel node extends this table with Section 3.2.5. A source-specific Babel node extends this table with
the following field: the following field:
* The source prefix (sprefix, splen) specifying the source address * The source prefix (sprefix, splen) specifying the source address
of packets to which this entry applies. of packets to which this entry applies.
The source table is now indexed by 5-tuples of the form (prefix, The source table is now indexed by 5-tuples of the form (prefix,
plen, sprefix, splen, router-id). plen, sprefix, splen, router-id).
Note that the route entry contains a source (see sections 2 and 3.2.5 Note that the route entry contains a source (see Sections 2 and 3.2.5
of [RFC8966]) which itself contains both destination and source of [RFC8966]) that itself contains both destination and source
prefixes. These are two different concepts, and must not be prefixes. These are two different concepts and must not be confused.
confused.
3.2. The Route Table 3.2. The Route Table
Every Babel node maintains a route table, as described in [RFC8966] Every Babel node maintains a route table, as described in [RFC8966],
Section 3.2.6. Each route table entry contains, among other data, a Section 3.2.6. Each route table entry contains, among other data, a
source, which this specification extends with a source prefix as source, which this specification extends with a source prefix as
described above. The route table is now indexed by 5-tuples of the described above. The route table is now indexed by 5-tuples of the
form (prefix, plen, sprefix, splen, neighbour), where the first four form (prefix, plen, sprefix, splen, neighbour), where the first four
components are obtained from the source. components are obtained from the source.
3.3. The Table of Pending Seqno Requests 3.3. The Table of Pending Seqno Requests
Every Babel node maintains a table of pending seqno requests, as Every Babel node maintains a table of pending seqno requests, as
described in [RFC8966], Section 3.2.7. A source-specific Babel node described in [RFC8966], Section 3.2.7. A source-specific Babel node
extends this table with the following entry: extends this table with the following entry:
* The source prefix (sprefix, splen) being requested. * The source prefix (sprefix, splen) being requested.
The table of pending seqno requests is now indexed by 5-tuples of the The table of pending seqno requests is now indexed by 5-tuples of the
form (prefix, plen, sprefix, splen, router-id). form (prefix, plen, sprefix, splen, router-id).
4. Data Forwarding 4. Data Forwarding
As noted in Section 1.3 above, source-specific tables can, in As noted in Section 1.3, source-specific tables can, in general, be
general, be ambiguous, and all routers in a routing domain must use ambiguous, and all routers in a routing domain must use the same
the same algorithm for choosing applicable routes. An implementation algorithm for choosing applicable routes. An implementation of the
of the extension described in this document MUST choose routing table extension described in this document MUST choose routing table
entries by using the destination-first ordering, where a routing entries by using destination-first ordering, where routing table
table entry R1 is preferred to a routing table entry R2 when either entry R1 is preferred to routing table entry R2 when either R1's
R1's destination prefix is more specific than R2's, or the destination prefix is more specific than R2's or the destination
destination prefixes are equal and R1's source prefix is more prefixes are equal and R1's source prefix is more specific than R2's.
specific than R2's.
In practice, this means that a source-specific Babel implementation In practice, this means that a source-specific Babel implementation
must take care that any lower layer that performs packet forwarding must take care that any lower layer that performs packet forwarding
obey this semantics. More precisely: obey these semantics. More precisely:
* if the lower layers implement the destination-first ordering, then * if the lower layers implement destination-first ordering, then the
the Babel implementation SHOULD use them directly; Babel implementation SHOULD use them directly;
* if the lower layers can hold source-specific routes, but not with * if the lower layers can hold source-specific routes but not with
the right semantics, then the Babel implementation MUST either the right semantics, then the Babel implementation MUST either
silently ignore any source-specific routes, or disambiguate the silently ignore any source-specific routes or disambiguate the
routing table by using a suitable disambiguation algorithm (see routing table by using a suitable disambiguation algorithm (see
Section V.B of [SS-ROUTING] for such an algorithm); Section V.B of [SS-ROUTING] for such an algorithm);
* if the lower layers cannot hold source-specific routes, then a * if the lower layers cannot hold source-specific routes, then a
Babel implementation MUST silently ignore any source-specific Babel implementation MUST silently ignore any source-specific
routes. routes.
5. Protocol Operation 5. Protocol Operation
This extension does not fundamentally change the operation of the This extension does not fundamentally change the operation of the
Babel protocol, and we therefore only describe differences between Babel protocol, and we therefore only describe differences between
the original protocol and the extended protocol. the original protocol and the extended protocol.
In the original protocol, three TLVs carry a destination prefix: In the original protocol, three TLVs carry a destination prefix:
Updates, Route Requests and Seqno Requests. This specification Update, Route Request, and Seqno Request TLVs. This specification
extends these messages so that they may carry a Source Prefix sub- extends these messages so that they may carry a Source Prefix sub-
TLV, as described in Section 7 below. The sub-TLV is marked as TLV, as described in Section 7. The sub-TLV is marked as mandatory
mandatory, so that an unextended implementation will silently ignore so that an unextended implementation will silently ignore the whole
the whole enclosing TLV. A node obeying this specification MUST NOT enclosing TLV. A node obeying this specification MUST NOT send a TLV
send a TLV with a zero-length source prefix: instead, it sends a TLV with a zero-length source prefix; instead, it sends a TLV with no
with no Source Prefix sub-TLV. Conversely, an extended Source Prefix sub-TLV. Conversely, an extended implementation MUST
implementation MUST interpret an unextended TLV as carrying a source interpret an unextended TLV as carrying a source prefix of zero
prefix of zero length. Taken together, these properties ensure length. Taken together, these properties ensure interoperability
interoperability between the original and extended protocols (see between the original and extended protocols (see Section 6).
Section 6 below).
5.1. Protocol Messages 5.1. Protocol Messages
This extension allows three TLVs of the original Babel protocol to This extension allows three TLVs of the original Babel protocol to
carry a source prefix: Update TLVs, Route Request TLVs, and Seqno carry a source prefix: Update TLVs, Route Request TLVs, and Seqno
Request TLVs. Request TLVs.
In order to advertise a route with a non-zero length source prefix, a In order to advertise a route with a non-zero length source prefix, a
node sends a source-specific Update, i.e., an Update with a Source node sends a source-specific update, i.e., an update with a Source
Prefix sub-TLV. When a node receives a source-specific Update Prefix sub-TLV. When a node receives a source-specific update
(prefix, source prefix, router-id, seqno, metric) from a neighbour (prefix, source prefix, router-id, seqno, metric) from a neighbour
neigh, it behaves as described in [RFC8966] Section 3.5.3, except neigh, it behaves as described in [RFC8966], Section 3.5.3, except
that the entry under consideration is indexed by (prefix, plen, that the entry under consideration is indexed by (prefix, plen,
sprefix, splen, neigh) rather than just (prefix, plen, neigh). sprefix, splen, neigh) rather than just (prefix, plen, neigh).
Similarly, when a node needs to send a Request of either kind that Similarly, when a node needs to send a request of either kind that
applies to a route with a non-zero length source prefix, it sends a applies to a route with a non-zero length source prefix, it sends a
source-specific Request, i.e., a Request with a Source Prefix sub- source-specific request, i.e., a request with a Source Prefix sub-
TLV. When a node receives a source-specific Request, it behaves as TLV. When a node receives a source-specific request, it behaves as
described in Section 3.8 of [RFC8966], except that the request described in Section 3.8 of [RFC8966], except that the request
applies to the Route Table entry carrying the source prefix indicated applies to the route table entry carrying the source prefix indicated
by the Source Prefix sub-TLV. by the Source Prefix sub-TLV.
5.2. Wildcard Messages 5.2. Wildcard Messages
In the original protocol, the Address Encoding (AE) value 0 is used In the original protocol, the address encoding (AE) value 0 is used
for wildcard messages: messages that apply to all routes, of any for wildcard messages: messages that apply to all routes of any
address family and with any destination prefix. Wildcard messages address family and with any destination prefix. Wildcard messages
are allowed in two places in the protocol: wildcard retractions are are allowed in two places in the protocol: wildcard retractions are
used to retract all of the routes previously advertised by a node on used to retract all of the routes previously advertised by a node on
a given interface, and wildcard Route Requests are used to request a a given interface, and wildcard route requests are used to request a
full dump of the Route Table from a given node. Wildcard messages full dump of the route table from a given node. Wildcard messages
are intended to apply to all routes, including routes decorated with are intended to apply to all routes, including routes decorated with
additional data and AE values to be defined by future extensions, and additional data and AE values to be defined by future extensions;
hence this specification extends wildcard operations to apply to all hence, this specification extends wildcard operations to apply to all
routes, whatever the value of the source prefix. routes, whatever the value of the source prefix.
More precisely, a node receiving an Update with the AE field set to 0 More precisely, a node receiving an update with the AE field set to 0
and the Metric field set to infinity (a wildcard retraction) MUST and the Metric field set to infinity (a wildcard retraction) MUST
apply the route acquisition procedure described in Section 3.5.3 of apply the route acquisition procedure described in Section 3.5.3 of
[RFC8966] to all of the routes that it has learned from the sending [RFC8966] to all of the routes that it has learned from the sending
node, whatever the value of the source prefix. A node MUST NOT send node, whatever the value of the source prefix. A node MUST NOT send
a wildcard retraction with an attached source prefix, and a node that a wildcard retraction with an attached source prefix, and a node that
receives a wildcard retraction with a source prefix MUST ignore the receives a wildcard retraction with a source prefix MUST ignore the
retraction. retraction.
Similarly, a node that receives a route request with the AE field set Similarly, a node that receives a route request with the AE field set
to 0 (a wildcard route request) SHOULD send a full routing table to 0 (a wildcard route request) SHOULD send a full routing table
dump, including routes with a non-zero length source prefix. A node dump, including routes with a non-zero length source prefix. A node
MUST NOT send a wildcard request that carries a source prefix, and a MUST NOT send a wildcard request that carries a source prefix, and a
node receiving a wildcard request with a source prefix MUST ignore node receiving a wildcard request with a source prefix MUST ignore
the request. the request.
6. Compatibility with the base protocol 6. Compatibility with the Base Protocol
The protocol extension defined in this document is, to a great The protocol extension defined in this document is, to a great
extent, interoperable with the base protocol defined in [RFC8966] extent, interoperable with the base protocol defined in [RFC8966]
(and all previously standardised extensions). More precisely, if (and all previously standardised extensions). More precisely, if
non-source-specific routers and source-specific routers are mixed in non-source-specific routers and source-specific routers are mixed in
a single routing domain, Babel's loop-avoidance properties are a single routing domain, Babel's loop-avoidance properties are
preserved, and, in particular, no persistent routing loops will preserved, and, in particular, no persistent routing loops will
occur. occur.
However, this extension is encoded using mandatory sub-TLVs, However, this extension is encoded using mandatory sub-TLVs,
introduced in [RFC8966], and therefore is not compatible with the introduced in [RFC8966], and therefore is not compatible with the
older version of the Babel Routing Protocol [RFC6126] which does not older version of the Babel routing protocol [RFC6126], which does not
support mandatory sub-TLVs. Consequently, this extension MUST NOT be support mandatory sub-TLVs. Consequently, this extension MUST NOT be
used in a routing domain in which some routers implement RFC 6126, used in a routing domain in which some routers implement [RFC6126];
otherwise persistent routing loops may occur. otherwise, persistent routing loops may occur.
6.1. Starvation and Blackholes 6.1. Starvation and Blackholes
In general, the discarding of source-specific routes by non-source- In general, the discarding of source-specific routes by non-source-
specific routers will cause route starvation. Intuitively, unless specific routers will cause route starvation. Intuitively, unless
there are enough non-source-specific routes in the network, non- there are enough non-source-specific routes in the network, non-
source-specific routers will suffer starvation, and discard packets source-specific routers will suffer starvation and discard packets
for destinations that are only announced by source-specific routers. for destinations that are only announced by source-specific routers.
In the common case where all source-specific routes are originated at In the common case where all source-specific routes are originated at
one of a small set of edge routers, a simple yet sufficient condition one of a small set of edge routers, a simple yet sufficient condition
for avoiding starvation is to build a connected source-specific for avoiding starvation is to build a connected source-specific
backbone that includes all of the edge routers, and announce a non- backbone that includes all of the edge routers and announce a non-
source-specific default route towards the backbone. source-specific default route towards the backbone.
7. Protocol Encoding 7. Protocol Encoding
This extension defines a new sub-TLV used to carry a source prefix: This extension defines a new sub-TLV used to carry a source prefix:
the Source Prefix sub-TLV. It can be used within an Update, a Route the Source Prefix sub-TLV. It can be used within an Update, Route
Request or a Seqno Request TLV to match a source-specific entry of Request, or Seqno Request TLV to match a source-specific entry of the
the Route Table, in conjunction with the destination prefix natively route table in conjunction with the destination prefix natively
carried by these TLVs. carried by these TLVs.
Since a source-specific routing entry is characterized by a single Since a source-specific routing entry is characterised by a single
destination prefix and a single source prefix, a source-specific destination prefix and a single source prefix, a source-specific
contains message exactly one Source Prefix sub-TLV. A node MUST NOT message contains exactly one Source Prefix sub-TLV. A node MUST NOT
send more than one Source Prefix sub-TLV in a TLV, and a node send more than one Source Prefix sub-TLV in a TLV, and a node
receiving more than one Source Prefix sub-TLV in a single TLV MUST receiving more than one Source Prefix sub-TLV in a single TLV MUST
ignore the TLV. It MAY ignore the whole packet. ignore the TLV. It MAY ignore the whole packet.
7.1. Source Prefix sub-TLV 7.1. Source Prefix Sub-TLV
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 = 128 | Length | Source Plen | Source Prefix... | Type = 128 | Length | Source Plen | Source Prefix...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Fields: Fields:
Type Set to 128 to indicate a Source Prefix sub-TLV. Type Set to 128 to indicate a Source Prefix sub-TLV.
Length The length of the body, in octets, exclusive of the Type Length The length of the body, in octets, exclusive of the
and Length fields. Type and Length fields.
Source Plen The length of the advertised source prefix, in bits. Source Plen The length of the advertised source prefix, in bits.
This MUST NOT be 0. This MUST NOT be 0.
Source Prefix The source prefix being advertised. This field's size Source Prefix The source prefix being advertised. This field's size
is (Source Plen)/8 octets rounded upwards. is (Source Plen)/8 octets rounded upwards.
The length of the body TLV is normally of size 1+(Source Plen)/8 The length of the body TLV is normally of size 1+(Source Plen)/8
rounded upwards. If the Length field indicates a length smaller than rounded upwards. If the Length field indicates a length smaller than
that, then the sub-TLV is corrupt, and the whole enclosing TLV must that, then the sub-TLV is corrupt, and the whole enclosing TLV must
be ignored; if the Length field indicates a length that is larger, be ignored; if the Length field indicates a length that is larger,
then the extra octets contained in the sub-TLV MUST be silently then the extra octets contained in the sub-TLV MUST be silently
ignored. ignored.
The contents of the Source Prefix sub-TLV are interpreted according The contents of the Source Prefix sub-TLV are interpreted according
to the AE of the enclosing TLV. If a TLV with AE equal to 0 contains to the AE of the enclosing TLV. If a TLV with AE equal to 0 contains
a Source Prefix sub-TLV, then the whole enclosing TLV MUST be a Source Prefix sub-TLV, then the whole enclosing TLV MUST be
ignored. If a TLV contains multiple Source Prefix sub-TLVs, then the ignored. If a TLV contains multiple Source Prefix sub-TLVs, then the
whole TLV MUST be ignored. whole TLV MUST be ignored.
Note that this sub-TLV is a mandatory sub-TLV. Therefore, as Note that this sub-TLV is a mandatory sub-TLV. Therefore, as
described in Section 4.4 of [RFC8966], the whole TLV MUST be ignored described in Section 4.4 of [RFC8966], the whole TLV MUST be ignored
if that sub-TLV is not understood (or malformed). if that sub-TLV is not understood (or malformed).
7.2. Source-specific Update 7.2. Source-Specific Update
The source-specific Update is an Update TLV with a Source Prefix sub- The source-specific update is an Update TLV with a Source Prefix sub-
TLV. It advertises or retracts source-specific routes in the same TLV. It advertises or retracts source-specific routes in the same
manner as routes with non-source-specific Updates (see [RFC8966]). A manner as routes with non-source-specific updates (see [RFC8966]). A
wildcard retraction (Update with AE equal to 0) MUST NOT carry a wildcard retraction (update with AE equal to 0) MUST NOT carry a
Source Prefix sub-TLV. Source Prefix sub-TLV.
Babel uses a stateful compression scheme to reduce the size taken by Babel uses a stateful compression scheme to reduce the size taken by
destination prefixes in update TLVs (see Section 4.5 of [RFC8966]). destination prefixes in Update TLVs (see Section 4.5 of [RFC8966]).
The source prefix defined by this extension is not compressed. On The source prefix defined by this extension is not compressed. On
the other hand, compression is allowed for the destination prefixes the other hand, compression is allowed for the destination prefixes
carried by source-specific updates. As described in Section 4.5 of carried by source-specific updates. As described in Section 4.5 of
[RFC8966], unextended implementations will correctly update their [RFC8966], unextended implementations will correctly update their
parser state while otherwise ignoring the whole TLV. parser state while otherwise ignoring the whole TLV.
7.3. Source-specific Route Request 7.3. Source-Specific Route Request
A source-specific Route Request is a Route Request TLV with a Source A source-specific route request is a Route Request TLV with a Source
Prefix sub-TLV. It prompts the receiver to send an update for a Prefix sub-TLV. It prompts the receiver to send an update for a
given pair of destination and source prefixes, as described in given pair of destination and source prefixes, as described in
Section 3.8.1.1 of [RFC8966]. A wildcard request (Route Request with Section 3.8.1.1 of [RFC8966]. A wildcard request (route request with
AE equals to 0) MUST NOT carry a Source Prefix sub-TLV; if a wildcard AE equal to 0) MUST NOT carry a Source Prefix sub-TLV; if a wildcard
request with a Source Prefix sub-TLV is received, then the request request with a Source Prefix sub-TLV is received, then the request
MUST be ignored. MUST be ignored.
7.4. Source-Specific Seqno Request 7.4. Source-Specific Seqno Request
A source-specific Seqno Request is a Seqno Request TLV with a Source A source-specific seqno request is a Seqno Request TLV with a Source
Prefix sub-TLV. It requests the receiving node to perform the Prefix sub-TLV. It requests that the receiving node perform the
procedure described in Section 3.8.1.2 of [RFC8966], but applied to a procedure described in Section 3.8.1.2 of [RFC8966] but applied to a
pair of a destination and source prefix. pair consisting of a destination and source prefix.
8. IANA Considerations 8. IANA Considerations
IANA has allocated sub-TLV number 128 for the Source Prefix sub-TLV IANA has allocated sub-TLV number 128 for the Source Prefix sub-TLV
in the Babel sub-TLV types registry. in the "Babel Sub-TLV Types" registry.
9. Security considerations 9. Security Considerations
The extension defined in this document adds a new sub-TLV to three The extension defined in this document adds a new sub-TLV to three
sub-TLVs already present in the original Babel protocol, and does not sub-TLVs already present in the original Babel protocol and does not
change the security properties of the protocol itself. However, the change the security properties of the protocol itself. However, the
additional flexibility provided by source-specific routing might additional flexibility provided by source-specific routing might
invalidate the assumptions made by some network administrators, which invalidate the assumptions made by some network administrators, which
could conceivably lead to security issues. could conceivably lead to security issues.
For example, a network administrator might be tempted to abuse route For example, a network administrator might be tempted to abuse route
filtering (Appendix C of [RFC8966]) as a security mechanism. Unless filtering (Appendix C of [RFC8966]) as a security mechanism. Unless
the filtering rules are designed to take source-specific routing into the filtering rules are designed to take source-specific routing into
account, they might be bypassed by a source-specific route, which account, they might be bypassed by a source-specific route, which
might cause traffic to reach a portion of a network that was thought might cause traffic to reach a portion of a network that was thought
to be protected. A network administrator might also assume that no to be protected. A network administrator might also assume that no
route is more specific than a host route, and use a host route in route is more specific than a host route and use a host route in
order to direct traffic for a given destination through a security order to direct traffic for a given destination through a security
device (e.g., a firewall); source-specific routing invalidates this device (e.g., a firewall); source-specific routing invalidates this
assumption, and in some topologies announcing a source-specific route assumption, and, in some topologies, announcing a source-specific
might conceivably be used to bypass the security device. route might conceivably be used to bypass the security device.
10. Acknowledgments 10. References
The authors are indebted to Donald Eastlake, Joel Halpern, and Toke 10.1. Normative References
Hoiland-Jorgensen for their help with this document.
11. References [BCP84] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
11.1. Normative References Sriram, K., Montgomery, D., and J. Haas, "Enhanced
Feasible-Path Unicast Reverse Path Forwarding", BCP 84,
RFC 8704, February 2020.
[BCP84] Baker, F. and P. Savola, "Ingress Filtering for Multihomed <https://www.rfc-editor.org/info/bcp84>
Networks", BCP 84, RFC 3704, March 2004,
<https://www.rfc-editor.org/rfc/rfc3704>.
[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,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8966] Chroboczek, J. and D. Schinazi, "The Babel Routing [RFC8966] Chroboczek, J. and D. Schinazi, "The Babel Routing
Protocol", RFC 8966, DOI 10.17487/RFC8966, January 2021, Protocol", RFC 8966, DOI 10.17487/RFC8966, January 2021,
<https://www.rfc-editor.org/info/rfc8966>. <https://www.rfc-editor.org/info/rfc8966>.
11.2. Informative References 10.2. Informative References
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484,
DOI 10.17487/RFC3484, February 2003,
<https://www.rfc-editor.org/info/rfc3484>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007, RFC 4960, DOI 10.17487/RFC4960, September 2007,
<https://www.rfc-editor.org/info/rfc4960>. <https://www.rfc-editor.org/info/rfc4960>.
[RFC6126] Chroboczek, J., "The Babel Routing Protocol", RFC 6126, [RFC6126] Chroboczek, J., "The Babel Routing Protocol", RFC 6126,
DOI 10.17487/RFC6126, April 2011, DOI 10.17487/RFC6126, April 2011,
<https://www.rfc-editor.org/info/rfc6126>. <https://www.rfc-editor.org/info/rfc6126>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<https://www.rfc-editor.org/info/rfc6724>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305, Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017, DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc8305>. <https://www.rfc-editor.org/info/rfc8305>.
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445, Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018, DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/info/rfc8445>. <https://www.rfc-editor.org/info/rfc8445>.
[RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C.
Paasch, "TCP Extensions for Multipath Operation with Paasch, "TCP Extensions for Multipath Operation with
Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March
2020, <https://www.rfc-editor.org/info/rfc8684>. 2020, <https://www.rfc-editor.org/info/rfc8684>.
[SS-ROUTING] [SS-ROUTING]
Boutier, M. and J. Chroboczek, "Source-Specific Routing", Boutier, M. and J. Chroboczek, "Source-Specific Routing",
August 2014, <http://arxiv.org/pdf/1403.0445>. In Proc. IFIP Networking Conference,
IFIP Networking 2015. DOI 10.1109/IFIPNetworking.2015.7145305, May 2015,
<http://arxiv.org/pdf/1403.0445>.
Acknowledgments
The authors are indebted to Donald Eastlake, Joel Halpern, and Toke
Hoiland-Jorgensen for their help with this document.
Authors' Addresses Authors' Addresses
Matthieu Boutier Matthieu Boutier
IRIF, University of Paris IRIF, University of Paris
Case 7014 Case 7014
75205 Paris Cedex 13 75205 Paris Cedex 13
France France
Email: boutier@irif.fr Email: boutier@irif.fr
 End of changes. 88 change blocks. 
205 lines changed or deleted 204 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/