idnits 2.17.1 draft-ietf-babel-source-specific-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 20, 2018) is 2285 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '128' on line 429 == Outdated reference: A later version (-20) exists of draft-ietf-babel-rfc6126bis-04 == Outdated reference: A later version (-07) exists of draft-ietf-rtgwg-dst-src-routing-06 -- Obsolete informational reference (is this intentional?): RFC 6126 (Obsoleted by RFC 8966) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boutier 3 Internet-Draft J. Chroboczek 4 Intended status: Standards Track IRIF, University of Paris-Diderot 5 Expires: July 24, 2018 January 20, 2018 7 Source-Specific Routing in Babel 8 draft-ietf-babel-source-specific-02 10 Abstract 12 Source-specific routing (also known as Source-Address Dependent 13 Routing, SADR) is an extension to traditional next-hop routing where 14 packets are forwarded according to both their destination and their 15 source address. This document describes an extension for source- 16 specific routing to the Babel routing protocol. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on July 24, 2018. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction and background . . . . . . . . . . . . . . . . . 2 53 2. Specification of Requirements . . . . . . . . . . . . . . . . 3 54 3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 3 55 3.1. The Source Table . . . . . . . . . . . . . . . . . . . . 3 56 3.2. The Route Table . . . . . . . . . . . . . . . . . . . . . 4 57 3.3. The Table of Pending Seqno Requests . . . . . . . . . . . 4 58 4. Data Forwarding . . . . . . . . . . . . . . . . . . . . . . . 4 59 5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 5 60 5.1. Protocol Messages . . . . . . . . . . . . . . . . . . . . 6 61 5.2. Wildcard Messages . . . . . . . . . . . . . . . . . . . . 6 62 6. Compatibility with the base protocol . . . . . . . . . . . . 7 63 6.1. Loop-avoidance . . . . . . . . . . . . . . . . . . . . . 7 64 6.2. Starvation and Blackholes . . . . . . . . . . . . . . . . 7 65 7. Protocol Encoding . . . . . . . . . . . . . . . . . . . . . . 8 66 7.1. Source Prefix sub-TLV . . . . . . . . . . . . . . . . . . 8 67 7.2. Source-specific Update . . . . . . . . . . . . . . . . . 9 68 7.3. Source-specific (Route) Request . . . . . . . . . . . . . 9 69 7.4. Source-Specific Seqno Request . . . . . . . . . . . . . . 9 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 9. Security considerations . . . . . . . . . . . . . . . . . . . 9 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 74 10.2. Informative References . . . . . . . . . . . . . . . . . 10 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction and background 79 The Babel routing protocol [BABEL] is a distance vector routing 80 protocol for next-hop routing. In next-hop routing, each node 81 maintains a forwarding table which maps destination prefixes to next 82 hops. The forwarding decision is a per-packet operation which 83 depends on the destination address of the packets and on the entries 84 of the forwarding table. When a packet is about to be routed, its 85 destination address is compared to the prefixes of the routing table: 86 the entry with the most specific prefix containing the destination 87 address of the packet is chosen, and the packet is forwarded to the 88 associated next-hop. Next-hop routing is a simple, well understood 89 paradigm that works satisfactorily in a large number of cases. 91 Source-specific routing [SS-ROUTING], or Source Address Dependent 92 Routing (SADR) [DSR], is a modest extension to next-hop routing where 93 the forwarding decision depends not only on the destination address 94 but also on the source address of the packet being routed, which 95 makes it possible for two packets with the same destination but 96 different source addresses to be routed following different paths. 97 The forwarding tables are extended to map pairs of prefixes 98 (destination, source) to next hops. When multiple entries match a 99 given packet, the one with the most specific destination prefix is 100 chosen, and, in case of equality, the one with the most specific 101 source prefix. 103 The main application of source-specific routing is multihoming with 104 multiple addresses, a technique for multihoming which, unlike 105 multihoming, does not require the use of provider-independent 106 addresses and does not cause excessive growth of the global routing 107 table. In a network using this form of multihoming, each host is 108 given multiple addresses, one per upstream provider. When a host 109 sources a packet, it picks one of its addresses as the source address 110 of the packet, and source-specific routing is used to route the 111 packet to an edge router that is connected to the corresponding 112 provider, which is compatible with [BCP84]. More details are given 113 in [SS-ROUTING] and [DSR]. 115 This document describes a source-specific routing extension for the 116 Babel routing protocol [BABEL]. This involves minor changes to the 117 data structures, which must include a source prefix in addition to 118 the destination prefix already present, and some changes to the 119 Update, Route Request and Seqno Request TLVs, which are extended with 120 a source prefix. The source prefix is encoded using a mandatory sub- 121 TLV ([BABEL] Section 4.4). 123 2. Specification of Requirements 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 3. Data Structures 131 A number of the conceptual data structures described in Section 3.2 132 of [BABEL] contain a destination prefix. This specification extends 133 these data structures with a source prefix. Data from the original 134 protocol, which do not specify a source prefix, are stored with a 135 zero length source prefix, which matches exactly the same set of 136 packets as the original, non-source-specific data. 138 3.1. The Source Table 140 Every Babel node maintains a source table, as described in [BABEL] 141 Section 3.2.5. A source-specific Babel node extends this table with 142 the following field: 144 o The source prefix specifying the source address of packets to 145 which this entry applies. 147 The source table is now indexed by triples of the form (prefix, 148 source prefix, router-id). 150 Note that the route entry contains a source which itself contains a 151 source prefix. These are two very different concepts that should not 152 be confused. 154 3.2. The Route Table 156 Every Babel node maintains a route table, as described in [BABEL] 157 Section 3.2.6. Each route table entry contains, among other data, a 158 source, which this specification extends with a source prefix as 159 described above. The route table is now indexed by triples of the 160 form (prefix, source prefix, neighbour), where the prefix and source 161 prefix are obtained from the source. 163 3.3. The Table of Pending Seqno Requests 165 Every Babel node maintains a table of pending seqno requests, as 166 described in [BABEL], Section 3.2.7. A source-specific Babel node 167 extends this table with the following entry: 169 o The source prefix being requested. 171 The table of pending seqno requests is now indexed by triples of the 172 form (prefix, source prefix, router-id). 174 4. Data Forwarding 176 In next-hop routing, if two routing table entries overlap, then one 177 is necessarily more specific than the other; the "longest prefix 178 rule" specifies that the most specific applicable routing table entry 179 is chosen. 181 With source-specific routing, there might no longer be a most 182 specific applicable entry: two routing table entries might match a 183 given packet without one necessarily being more specific than the 184 other. Consider for example the following routing table: 186 destination source next-hop 187 2001:DB8:0:1::/64 ::/0 A 188 ::/0 2001:DB8:0:2::/64 B 190 This specifies that all packets with destination in 2001:DB8:0:1::/64 191 are to be routed through A, while all packets with source in 192 2001:DB8:0:2::/64 are to be routed through B. A packet with source 193 2001:DB8:0:2::42 and destination 2001:DB8:0:1::57 matches both rules, 194 although neither is more specific than the other. A choice is 195 necessary, and unless the choice being made is the same on all 196 routers in a routing domain, persistent routing loops may occur. 197 More details are given in [SS-ROUTING] Section IV.C. 199 A Babel implementation MUST choose routing table entries by using the 200 so-called destination-first ordering, where a routing table entry R1 201 is preferred to a routing table entry R2 when either R1's destination 202 prefix is more specific than R2's, or the destination prefixes are 203 equal and R1's source prefix is more specific than R2's. (In more 204 formal terms, routing table entries are compared using the 205 lexicographic product of the destination prefix ordering by the 206 source prefix ordering.) This is consistent with the behaviour 207 described in Section 3.3 of [DSR]. 209 In practice, this means that a source-specific Babel implementation 210 must take care that any lower layer that performs packet forwarding 211 obey this semantics. In particular: 213 o If the lower layers implement the destination-first ordering, then 214 the Babel implementation MAY use them directly; 216 o If the lower layers can hold source-specific routes, but not with 217 the right semantics, then the Babel implementation MUST 218 disambiguate the routing table by using a suitable disambiguation 219 algorithm (see [SS-ROUTING] Section V.B for such an algorithm); 221 o If the lower layers cannot hold source-specific routes, then a 222 Babel implementation MUST silently ignore (drop) any source- 223 specific routes. 225 5. Protocol Operation 227 This extension does not fundamentally change the operation of the 228 Babel protocol, and we therefore only describe differences between 229 the original protocol and the extended protocol. 231 In the original protocol, three TLVs carry a destination prefix: 232 Updates, Route Requests and Seqno Requests. This specification 233 extends these messages to optionally carry a source prefix sub-TLV, 234 as described in Section 7 below. The sub-TLV is marked as mandatory, 235 so that an unextended implementation will silently ignore the whole 236 enclising TLV. A node obeying this specification MUST NOT send a TLV 237 with a zero-length source prefix: instead, it sends a TLV with no 238 source prefix sub-TLV. Conversely, an extended implementation MUST 239 interpret an unextended TLV as carrying a source prefix of zero 240 length. Taken together, these properties ensure interoperability 241 between the original and extended protocols (see Section 6 below). 243 5.1. Protocol Messages 245 This extension allows three TLVs of the original Babel protocol to 246 carry a source prefix: Update TLVs, Route Request TLVs and Seqno 247 Request TLVs. 249 In order to advertise a route with a non-zero-length source prefix, a 250 node sends a source-specific Update, i.e., an Update with a source 251 prefix sub-TLV. When a node receives a source-specific Update 252 (prefix, source prefix, router-id, seqno, metric) from a neighbour 253 neigh, it behaves as described in [BABEL] Section 3.5.4, except that 254 the entry under consideration is indexed by (prefix, source prefix, 255 neigh) rather than just (prefix, neigh). 257 Similarly, when a node needs to send a Request of either kind that 258 applies to a route with a non-zero length source prefix, it sends a 259 source-specific Request, i.e., a Request with a source prefix sub- 260 TLV. When a node receives a source-specific Request, it behaves as 261 described in Section 3.8 of [BABEL], except that the request applies 262 to the Route Table entry carrying the source prefix indicated by the 263 sub-TLV. 265 5.2. Wildcard Messages 267 In the original protocol, the Address Encoding value 0 is used for 268 wildcard messages: messages that apply to all routes, of any address 269 family and with any destination prefix. Wildcard messages are 270 allowed in two places in the protocol: wildcard retractions are used 271 to retract all of the routes previously advertised by a node on a 272 given interface, and wildcard Route Requests are used to request a 273 full dump of the Route Table from a given node. Wildcard messages 274 are intended to apply to all routes, including routes decorated with 275 additional data and AE values to be defined by future extensions, and 276 hence this specification extends wildcard operations to apply to all 277 routes, whatever the value of the source prefix. 279 More precisely, a node receiving an Update with the AE field set to 0 280 and the Metric field set to infinity (a wildcard retraction) MUST 281 apply the route acquisition procedure described in Section 3.5.4 of 282 [BABEL] to all of the routes that is has learned from the sending 283 node, whatever the value of the source prefix. A node MUST NOT send 284 a wildcard retraction with an attached source prefix, and a node that 285 receives a wildcard retraction with a source prefix MUST silently 286 ignore it. 288 Similarly, a node that receives a route request with the AE field set 289 to 0 (a wildcard route request) SHOULD send a full routing table 290 dump, including routes with a non-zero-length source prefix. A node 291 MUST NOT send a wildcard request that carries a source prefix, and a 292 node receiving a wildcard request with a with a source prefix MUST 293 silently ignore it. 295 6. Compatibility with the base protocol 297 The protocol extension defined in this document is, to a great 298 extent, interoperable with the base protocol defined in [BABEL] (and 299 all of its extensions). More precisely, if non-source-specific 300 routers and source-specific routers are mixed in a single routing 301 domain, Babel's loop-avoidance properties are preserved, and, in 302 particular, no persistent routing loops will occur. 304 However, this extension is encoded using mandatory sub-TLVs, 305 introduced in [BABEL], and therefore is not compatible with the older 306 version of the Babel Routing Protocol [RFC6126]. Consequently, this 307 extension MUST NOT be used with routers implementing RFC 6126, 308 otherwise persistent routing loops may occur. 310 6.1. Loop-avoidance 312 The extension defined in this protocol uses a new Mandatory sub-TLV 313 to carry the source prefix information. As discussed in Section 4.4 314 of [BABEL], this encoding ensures that non-source-specific routers 315 will silently ignore the whole TLV, which is necessary to avoid 316 persistent routing loops in hybrid networks. 318 Consider two nodes A and B, with A source-specific announcing a route 319 to (D, S). Suppose that B (non source-specific) merely ignores the 320 source prefix information when it receives the update rather than 321 ignoring the whole TLV, and re-announces the route as D. This re- 322 announcement reaches A, which treats it as (D, ::/0). Packets 323 destined to D but not sourced in S will be forwarded by A to B, and 324 by B to A, causing a persistent routing loop: 326 (D,S) (D) 327 <-- <-- 328 ------ A ----------------- B 329 --> 330 (D,::/0) 332 6.2. Starvation and Blackholes 334 In general, discarding source-specific routes by non-source-specific 335 routers will cause route starvation. Intuitively, unless there are 336 enough non-source-specific routes in the network, non-source-specific 337 routers will suffer starvation, and discard packets for destinations 338 that are only announced by source-specific routers. 340 A simple yet sufficient condition for avoiding starvation is to build 341 a connected source-specific backbone that includes all of the edge 342 routers, and announce a (non-source-specific) default route towards 343 the backbone. 345 7. Protocol Encoding 347 This extension defines a new sub-TLV used to carry a source prefix: 348 the Source Prefix sub-TLV. It can be used within an Update, a Route 349 Request or a Seqno Request TLV to match a source-specific entry of 350 the Route Table, in conjunction with the destination prefix natively 351 carried by these TLVs. 353 Since a source-specific routing entry is characterized by a single 354 destination prefix and a single source prefix, a source-specific 355 message contains exactly one Source Prefix sub-TLV. A node MUST NOT 356 send more that one Source Prefix sub-TLV in a TLV, and a node 357 receiving more than one Source Prefix sub-TLV in a single TLV SHOULD 358 ignore this TLV. It MAY ignore the whole packet. 360 7.1. Source Prefix sub-TLV 362 0 1 2 3 363 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 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Type = TBD | Length | Source Plen | Source Prefix... 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 368 Fields: 370 Type Set to TBD to indicate a Source Prefix sub-TLV. 372 Length The length of the body, exclusive of the Type and Length 373 fields. 375 Source Plen The length of the advertised source prefix. This MUST 376 NOT be 0. 378 Source Prefix The source prefix being advertised. This field's size 379 is (Source Plen)/8 rounded upwards. 381 The contents of the source prefix sub-TLV are interpreted according 382 to the AE of the enclosing TLV. 384 Note that this sub-TLV is a mandatory sub-TLV. Threfore, as 385 described in Section 4.4 of [BABEL], the whole TLV MUST be ignored if 386 that sub-TLV is not understood (or malformed). Otherwise, routing 387 loops may occur (see Section 6.1). 389 7.2. Source-specific Update 391 The source-specific Update is an Update TLV with a Source Prefix sub- 392 TLV. It advertises or retracts source-specific routes in the same 393 manner than routes with non-source-specific Updates (see [BABEL]). A 394 wildcard retraction (Update with AE equals to 0) MUST NOT carry a 395 Source Prefix sub-TLV. 397 Contrary to the destination prefix, this extension does not compress 398 the source prefix attached to Updates. However, compression is 399 allowed for the destination prefix of source-specific routes. As 400 described in Section 4.5 of [BABEL], unextended implementations will 401 correctly update their parser state while otherwise ignoring the 402 whole TLV. 404 7.3. Source-specific (Route) Request 406 A source-specific Route Request is a Route Request TLV with a Source 407 Prefix sub-TLV. It prompts the receiver to send an update for a 408 given pair of destination and source prefixes, as described in 409 Section 3.8.1.1 of [BABEL]. A wildcard request (Route Request with 410 AE equals to 0) MUST NOT carry a Source Prefix sub-TLV. 412 7.4. Source-Specific Seqno Request 414 A source-specific Seqno Request is a Seqno Request TLV with a Source 415 Prefix sub-TLV. It requests the receiving node to perform the 416 procedure described in Section 3.8.1.2 of [BABEL], but applied to a 417 pair of a destination and source prefix. 419 8. IANA Considerations 421 IANA is requested to allocate TBD, a Babel sub-TLV type from the 422 range reserved for mandatory sub-TLVs [value 128 suggested], and to 423 add the following entry to the "Babel mandatory sub-TLV Types" 424 registry: 426 +----------+---------------+-----------------+ 427 | Type | Name | Reference | 428 +----------+---------------+-----------------+ 429 | TBD[128] | Source Prefix | (this document) | 430 +----------+---------------+-----------------+ 432 9. Security considerations 434 The extension defined in this document adds a new sub-TLV to three 435 TLVs already present in the original Babel protocol, and does not in 436 itself change the security properties of the protocol. However, 437 source-specific routing gives more control over routing to the 438 sending hosts, which might have security implications (see Section 8 439 of [DSR]). 441 10. References 443 10.1. Normative References 445 [BABEL] Chroboczek, J., "The Babel Routing Protocol", Internet 446 Draft draft-ietf-babel-rfc6126bis-04, May 2017. 448 [BCP84] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 449 Networks", BCP 84, RFC 3704, March 2004. 451 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 452 Requirement Levels", BCP 14, RFC 2119, 453 DOI 10.17487/RFC2119, March 1997. 455 10.2. Informative References 457 [DSR] Lamparter, D. and A. Smirnov, "Destination/Source 458 Routing", Internet Draft draft-ietf-rtgwg-dst-src-routing- 459 06, May 2018. 461 [RFC6126] Chroboczek, J., "The Babel Routing Protocol 462 (Experimental)", RFC 6126, February 2011. 464 [SS-ROUTING] 465 Boutier, M. and J. Chroboczek, "Source-Specific Routing", 466 August 2014. 468 In Proc. IFIP Networking 2015. A slightly earlier 469 version is available online from http://arxiv.org/ 470 pdf/1403.0445. 472 Authors' Addresses 474 Matthieu Boutier 475 IRIF, University of Paris-Diderot 476 Case 7014 477 75205 Paris Cedex 13 478 France 480 Email: boutier@irif.fr 481 Juliusz Chroboczek 482 IRIF, University of Paris-Diderot 483 Case 7014 484 75205 Paris Cedex 13 485 France 487 Email: jch@irif.fr