draft-ietf-babel-source-specific-03.txt   draft-ietf-babel-source-specific-04.txt 
Network Working Group M. Boutier Network Working Group M. Boutier
Internet-Draft J. Chroboczek Internet-Draft J. Chroboczek
Intended status: Standards Track IRIF, University of Paris-Diderot Intended status: Standards Track IRIF, University of Paris-Diderot
Expires: August 4, 2018 January 31, 2018 Expires: April 26, 2019 October 23, 2018
Source-Specific Routing in Babel Source-Specific Routing in Babel
draft-ietf-babel-source-specific-03 draft-ietf-babel-source-specific-04
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 and their
source address. This document describes an extension for source- source address. This document describes an extension for source-
specific routing to the Babel routing protocol. specific routing to the Babel routing protocol.
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 August 4, 2018. This Internet-Draft will expire on April 26, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 10 skipping to change at page 2, line 10
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction and background . . . . . . . . . . . . . . . . . 2 1. Introduction and background . . . . . . . . . . . . . . . . . 2
2. Specification of Requirements . . . . . . . . . . . . . . . . 3 2. Specification of Requirements . . . . . . . . . . . . . . . . 3
3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 3 3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. The Source Table . . . . . . . . . . . . . . . . . . . . 3 3.1. The Source Table . . . . . . . . . . . . . . . . . . . . 4
3.2. The Route Table . . . . . . . . . . . . . . . . . . . . . 4 3.2. The Route Table . . . . . . . . . . . . . . . . . . . . . 4
3.3. The Table of Pending Seqno Requests . . . . . . . . . . . 4 3.3. The Table of Pending Seqno Requests . . . . . . . . . . . 4
4. Data Forwarding . . . . . . . . . . . . . . . . . . . . . . . 4 4. Data Forwarding . . . . . . . . . . . . . . . . . . . . . . . 4
5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 5 5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 5
5.1. Protocol Messages . . . . . . . . . . . . . . . . . . . . 6 5.1. Protocol Messages . . . . . . . . . . . . . . . . . . . . 6
5.2. Wildcard Messages . . . . . . . . . . . . . . . . . . . . 6 5.2. Wildcard Messages . . . . . . . . . . . . . . . . . . . . 6
6. Compatibility with the base protocol . . . . . . . . . . . . 7 6. Compatibility with the base protocol . . . . . . . . . . . . 7
6.1. Loop-avoidance . . . . . . . . . . . . . . . . . . . . . 7 6.1. Loop-avoidance . . . . . . . . . . . . . . . . . . . . . 7
6.2. Starvation and Blackholes . . . . . . . . . . . . . . . . 8 6.2. Starvation and Blackholes . . . . . . . . . . . . . . . . 8
7. Protocol Encoding . . . . . . . . . . . . . . . . . . . . . . 8 7. Protocol Encoding . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Source Prefix sub-TLV . . . . . . . . . . . . . . . . . . 8 7.1. Source Prefix sub-TLV . . . . . . . . . . . . . . . . . . 8
7.2. Source-specific Update . . . . . . . . . . . . . . . . . 9 7.2. Source-specific Update . . . . . . . . . . . . . . . . . 9
7.3. Source-specific (Route) Request . . . . . . . . . . . . . 9 7.3. Source-specific (Route) Request . . . . . . . . . . . . . 9
7.4. Source-Specific Seqno Request . . . . . . . . . . . . . . 9 7.4. Source-Specific Seqno Request . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Security considerations . . . . . . . . . . . . . . . . . . . 9 9. Security considerations . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . 10 11.1. Normative References . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction and background 1. Introduction and background
The Babel routing protocol [BABEL] is a distance vector routing The Babel routing protocol [BABEL] 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 which maps destination prefixes to next
hops. The forwarding decision is a per-packet operation which hops. The forwarding decision is a per-packet operation which
depends on the destination address of the packets and on the entries depends on the destination address of the packets and on the entries
of the forwarding table. When a packet is about to be routed, its of the 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:
skipping to change at page 3, line 35 skipping to change at page 3, line 35
Babel routing protocol [BABEL]. This involves minor changes to the Babel routing protocol [BABEL]. 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 with
a source prefix. The source prefix is encoded using a mandatory sub- a source prefix. The source prefix is encoded using a mandatory sub-
TLV ([BABEL] Section 4.4). TLV ([BABEL] Section 4.4).
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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
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 [BABEL] contain a destination prefix. This specification extends of [BABEL] contain a destination prefix. This specification extends
these data structures with a source prefix. Data from the original these data structures with a source prefix. Data from the original
protocol, which do not specify a source prefix, are stored with a protocol, which do not specify a source prefix, are stored with a
zero length source prefix, which matches exactly the same set of zero length source prefix, which matches exactly the same set of
packets as the original, non-source-specific data. packets as the original, non-source-specific data.
skipping to change at page 4, line 11 skipping to change at page 4, line 17
Every Babel node maintains a source table, as described in [BABEL] Every Babel node maintains a source table, as described in [BABEL]
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:
o The source prefix specifying the source address of packets to o The source prefix specifying the source address of packets to
which this entry applies. which this entry applies.
The source table is now indexed by triples of the form (prefix, The source table is now indexed by triples of the form (prefix,
source prefix, router-id). source prefix, router-id).
Note that the route entry contains a source which itself contains a Note that the route entry contains a source (see sections 2 and 3.2.5
source prefix. These are two very different concepts that should not of [BABEL]) which itself contains a source prefix. These are two
be confused. very different concepts that should not be confused.
3.2. The Route Table 3.2. The Route Table
Every Babel node maintains a route table, as described in [BABEL] Every Babel node maintains a route table, as described in [BABEL]
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 triples of the described above. The route table is now indexed by triples of the
form (prefix, source prefix, neighbour), where the prefix and source form (prefix, source prefix, neighbour), where the prefix and source
prefix are obtained from the source. prefix are obtained from the source.
skipping to change at page 5, line 9 skipping to change at page 5, line 16
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
This specifies that all packets with destination in 2001:DB8:0:1::/64 This specifies that all packets with destination in 2001:DB8:0:1::/64
are to be routed through A, while all packets with source in are to be routed through A, while all packets with source in
2001:DB8:0:2::/64 are to be routed through B. A packet with source 2001:DB8:0:2::/64 are to be routed through B. A packet with source
2001:DB8:0:2::42 and destination 2001:DB8:0:1::57 matches both rules, 2001:DB8:0:2::42 and destination 2001:DB8:0:1::57 matches both rules,
although neither is more specific than the other. A choice is although neither is more specific than the other. A choice is
necessary, and unless the choice being made is the same on all necessary, and unless the choice being made is the same on all
routers in a routing domain, persistent routing loops may occur. routers in a routing domain, persistent routing loops may occur.
More details are given in [SS-ROUTING] Section IV.C. More details are given in Section IV.C of [SS-ROUTING].
A Babel implementation MUST choose routing table entries by using the A Babel implementation MUST choose routing table entries by using the
so-called destination-first ordering, where a routing table entry R1 so-called destination-first ordering, where a routing table entry R1
is preferred to a routing table entry R2 when either R1's destination is preferred to a routing table entry R2 when either R1's destination
prefix is more specific than R2's, or the destination prefixes are prefix is more specific than R2's, or the destination prefixes are
equal and R1's source prefix is more specific than R2's. (In more equal and R1's source prefix is more specific than R2's. (In more
formal terms, routing table entries are compared using the formal terms, routing table entries are compared using the
lexicographic product of the destination prefix ordering by the lexicographic product of the destination prefix ordering by the
source prefix ordering.) This is consistent with the behaviour source prefix ordering.) This is consistent with the behaviour
described in Section 3.3 of [DSR]. described in Section 3.3 of [DSR].
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. In particular: obey this semantics. More precisely:
o If the lower layers implement the destination-first ordering, then o If the lower layers implement the destination-first ordering, then
the Babel implementation MAY use them directly; the Babel implementation MAY use them directly;
o If the lower layers can hold source-specific routes, but not with o If the lower layers can hold source-specific routes, but not with
the right semantics, then the Babel implementation MUST the right semantics, then the Babel implementation MUST
disambiguate the routing table by using a suitable disambiguation disambiguate the routing table by using a suitable disambiguation
algorithm (see [SS-ROUTING] Section V.B for such an algorithm); algorithm (see Section V.B of [SS-ROUTING] for such an algorithm);
o If the lower layers cannot hold source-specific routes, then a o If the lower layers cannot hold source-specific routes, then a
Babel implementation MUST silently ignore (drop) any source- Babel implementation MUST silently ignore (drop) any source-
specific routes. specific 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 Updates, Route Requests and Seqno Requests. This specification
extends these messages to optionally carry a source prefix sub-TLV, extends these messages to optionally carry a source prefix sub-TLV,
as described in Section 7 below. The sub-TLV is marked as mandatory, as described in Section 7 below. The sub-TLV is marked as mandatory,
so that an unextended implementation will silently ignore the whole so that an unextended implementation will silently ignore the whole
enclising TLV. A node obeying this specification MUST NOT send a TLV enclosing TLV. A node obeying this specification MUST NOT send a TLV
with a zero-length source prefix: instead, it sends a TLV with no with a zero-length source prefix: instead, it sends a TLV with no
source prefix sub-TLV. Conversely, an extended implementation MUST source prefix sub-TLV. Conversely, an extended implementation MUST
interpret an unextended TLV as carrying a source prefix of zero interpret an unextended TLV as carrying a source prefix of zero
length. Taken together, these properties ensure interoperability length. Taken together, these properties ensure interoperability
between the original and extended protocols (see Section 6 below). between the original and extended protocols (see 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 [BABEL] Section 3.5.4, except that neigh, it behaves as described in [BABEL] Section 3.5.4, except that
the entry under consideration is indexed by (prefix, source prefix, the entry under consideration is indexed by (prefix, source prefix,
neigh) rather than just (prefix, neigh). neigh) rather than just (prefix, 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-
skipping to change at page 6, line 46 skipping to change at page 7, line 4
given interface, and wildcard Route Requests are used to request 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, and
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.4 of apply the route acquisition procedure described in Section 3.5.4 of
[BABEL] to all of the routes that is has learned from the sending [BABEL] to all of the routes that is 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 silently receives a wildcard retraction with a source prefix MUST ignore it.
ignore it.
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 with a source prefix MUST node receiving a wildcard request with a source prefix MUST ignore
silently ignore it. it.
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 [BABEL] (and extent, interoperable with the base protocol defined in [BABEL] (and
all of its extensions). More precisely, if non-source-specific all of its extensions). More precisely, if non-source-specific
routers and source-specific routers are mixed in a single routing routers and source-specific routers are mixed in a single routing
domain, Babel's loop-avoidance properties are preserved, and, in domain, Babel's loop-avoidance properties are preserved, and, in
particular, no persistent routing loops will occur. particular, no persistent routing loops will occur.
However, this extension is encoded using mandatory sub-TLVs, However, this extension is encoded using mandatory sub-TLVs,
introduced in [BABEL], and therefore is not compatible with the older introduced in [BABEL], and therefore is not compatible with the older
version of the Babel Routing Protocol [RFC6126]. Consequently, this version of the Babel Routing Protocol [RFC6126] which does not
extension MUST NOT be used with routers implementing RFC 6126, support such sub-TLVs. Consequently, this extension MUST NOT be used
otherwise persistent routing loops may occur. with routers implementing RFC 6126, otherwise persistent routing
loops may occur.
6.1. Loop-avoidance 6.1. Loop-avoidance
The extension defined in this protocol uses a new Mandatory sub-TLV The extension defined in this protocol uses a new Mandatory sub-TLV
to carry the source prefix information. As discussed in Section 4.4 to carry the source prefix information. As discussed in Section 4.4
of [BABEL], this encoding ensures that non-source-specific routers of [BABEL], this encoding ensures that non-source-specific routers
will silently ignore the whole TLV, which is necessary to avoid will silently ignore the whole TLV, which is necessary to avoid
persistent routing loops in hybrid networks. persistent routing loops in hybrid networks.
Consider two nodes A and B, with A source-specific announcing a route Consider two nodes A and B, with A source-specific announcing a route
to (D, S). Suppose that B (non source-specific) merely ignores the to (D, S). Suppose that B (non-source-specific) merely ignores the
source prefix information when it receives the update rather than source prefix information when it receives the update rather than
ignoring the whole TLV, and re-announces the route as D. This re- ignoring the whole TLV, and re-announces the route as D. This re-
announcement reaches A, which treats it as (D, ::/0). Packets announcement reaches A, which treats it as (D, ::/0). Packets
destined to D but not sourced in S will be forwarded by A to B, and destined to D but not sourced in S will be forwarded by A to B, and
by B to A, causing a persistent routing loop: by B to A, causing a persistent routing loop:
(D,S) (D) (D,S) (D)
<-- <-- <-- <--
------ A ----------------- B ------ A ----------------- B
--> -->
skipping to change at page 9, line 8 skipping to change at page 9, line 14
Source Plen The length of the advertised source prefix. This MUST Source Plen The length of the advertised source prefix. This MUST
NOT be 0. 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 rounded upwards. is (Source Plen)/8 rounded upwards.
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. to the AE of the enclosing TLV.
Note that this sub-TLV is a mandatory sub-TLV. Threfore, as Note that this sub-TLV is a mandatory sub-TLV. Therefore, as
described in Section 4.4 of [BABEL], the whole TLV MUST be ignored if described in Section 4.4 of [BABEL], the whole TLV MUST be ignored if
that sub-TLV is not understood (or malformed). Otherwise, routing that sub-TLV is not understood (or malformed). Otherwise, routing
loops may occur (see Section 6.1). loops may occur (see Section 6.1).
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 than routes with non-source-specific Updates (see [BABEL]). A manner than routes with non-source-specific Updates (see [BABEL]). A
wildcard retraction (Update with AE equals 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.
Contrary to the destination prefix, this extension does not compress Babel uses a stateful compression scheme to reduce the size taken by
the source prefix attached to Updates. However, compression is destination prefixes in update TLVs (see Section 4.5 of [BABEL]).
allowed for the destination prefix of source-specific routes. As The source prefix defined by this extension is not compressed. On
described in Section 4.5 of [BABEL], unextended implementations will the other hand, compression is allowed for the destination prefixes
correctly update their parser state while otherwise ignoring the carried by source-specific updates. As described in Section 4.5 of
whole TLV. [BABEL], unextended implementations will correctly update their
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 [BABEL]. A wildcard request (Route Request with Section 3.8.1.1 of [BABEL]. A wildcard request (Route Request with
AE equals to 0) MUST NOT carry a Source Prefix sub-TLV. AE equals to 0) MUST NOT carry a Source Prefix sub-TLV.
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 the receiving node to perform the
procedure described in Section 3.8.1.2 of [BABEL], but applied to a procedure described in Section 3.8.1.2 of [BABEL], but applied to a
pair of a destination and source prefix. pair 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 Numbers 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
TLVs already present in the original Babel protocol, and does not in TLVs already present in the original Babel protocol, and does not in
itself change the security properties of the protocol. However, itself change the security properties of the protocol. However,
source-specific routing gives more control over routing to the source-specific routing gives more control over routing to the
sending hosts, which might have security implications (see Section 8 sending hosts, which might have security implications (see Section 8
of [DSR]). of [DSR]).
10. Acknowledgments 10. Acknowledgments
The authors are grateful to Joel Halpern for his help with this The authors are grateful to Joel Halpern for his help with this
document. document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[BABEL] Chroboczek, J., "The Babel Routing Protocol", Internet [BABEL] Chroboczek, J., "The Babel Routing Protocol", Internet
Draft draft-ietf-babel-rfc6126bis-04, May 2017. Draft draft-ietf-babel-rfc6126bis-06, October 2018.
[BCP84] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [BCP84] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004.
[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.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017.
11.2. Informative References 11.2. Informative References
[DSR] Lamparter, D. and A. Smirnov, "Destination/Source [DSR] Lamparter, D. and A. Smirnov, "Destination/Source
Routing", Internet Draft draft-ietf-rtgwg-dst-src-routing- Routing", Internet Draft draft-ietf-rtgwg-dst-src-routing-
06, May 2018. 06, May 2018.
[RFC6126] Chroboczek, J., "The Babel Routing Protocol [RFC6126] Chroboczek, J., "The Babel Routing Protocol", RFC 6126,
(Experimental)", RFC 6126, February 2011. DOI 10.17487/RFC6126, April 2011,
<https://www.rfc-editor.org/info/rfc6126>.
[SS-ROUTING] [SS-ROUTING]
Boutier, M. and J. Chroboczek, "Source-Specific Routing", Boutier, M. and J. Chroboczek, "Source-Specific Routing",
August 2014. August 2014.
In Proc. IFIP Networking 2015. A slightly earlier In Proc. IFIP Networking 2015. A slightly earlier
version is available online from http://arxiv.org/ version is available online from http://arxiv.org/
pdf/1403.0445. pdf/1403.0445.
Authors' Addresses Authors' Addresses
 End of changes. 26 change blocks. 
38 lines changed or deleted 47 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/