idnits 2.17.1 draft-ietf-babel-source-specific-01.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6126], [BABEL]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 204: '...l implementation MUST choose routing t...' RFC 2119 keyword, line 218: '...l implementation MAY use them directly...' RFC 2119 keyword, line 221: '...cs, then the Babel implementation MUST...' RFC 2119 keyword, line 226: '...l implementation MUST silently ignore ...' RFC 2119 keyword, line 244: '... Seqno Request MUST carry a source p...' (13 more instances...) -- The draft header indicates that this document updates RFC6126bis, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 191 has weird spacing: '... source nex...' -- The document date (August 21, 2017) is 2432 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 418 == Outdated reference: A later version (-20) exists of draft-ietf-babel-rfc6126bis-02 ** Obsolete normative reference: RFC 6126 (Obsoleted by RFC 8966) Summary: 3 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 Updates: 6126bis (if approved) IRIF, University of Paris-Diderot 5 Intended status: Standards Track August 21, 2017 6 Expires: February 22, 2018 8 Source-Specific Routing in Babel 9 draft-ietf-babel-source-specific-01 11 Abstract 13 Source-specific routing is an extension to traditional next-hop 14 routing where packets are forwarded according to both their 15 destination and their source address. This document describes the 16 source-specific routing extension to the Standard Track's Babel 17 routing protocol defined in [BABEL]. It is incompatible with the 18 Experimental Track's Babel [RFC6126]. 20 Source-specific routing is also known as Source Address Dependent 21 Routing, SAD Routing, SADR, Destination/Source Routing or Source/ 22 Destination Routing. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on February 22, 2018. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. TODOs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Introduction and background . . . . . . . . . . . . . . . . . 2 60 3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 3 61 3.1. The Source Table . . . . . . . . . . . . . . . . . . . . 3 62 3.2. The Route Table . . . . . . . . . . . . . . . . . . . . . 4 63 3.3. The Table of Pending Seqno Requests . . . . . . . . . . . 4 64 4. Data Forwarding . . . . . . . . . . . . . . . . . . . . . . . 4 65 5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 5 66 5.1. Source-specific messages . . . . . . . . . . . . . . . . 6 67 5.2. Route Acquisition . . . . . . . . . . . . . . . . . . . . 6 68 5.3. Wildcard retractions (update) . . . . . . . . . . . . . . 6 69 5.4. Wildcard requests . . . . . . . . . . . . . . . . . . . . 6 70 6. Compatibility with the base protocol . . . . . . . . . . . . 7 71 6.1. Loop-avoidance . . . . . . . . . . . . . . . . . . . . . 7 72 6.2. Starvation and Blackholes . . . . . . . . . . . . . . . . 8 73 7. Protocol Encoding . . . . . . . . . . . . . . . . . . . . . . 8 74 7.1. Source Prefix sub-TLV . . . . . . . . . . . . . . . . . . 8 75 7.2. Source-specific Update . . . . . . . . . . . . . . . . . 9 76 7.3. Source-specific (Route) Request . . . . . . . . . . . . . 9 77 7.4. Source-Specific Seqno Request . . . . . . . . . . . . . . 9 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 79 9. Security considerations . . . . . . . . . . . . . . . . . . . 9 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 82 10.2. Informative References . . . . . . . . . . . . . . . . . 10 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 85 1. TODOs 87 o Source Prefix sub-TLV type: TBD 89 o check references (Section) for BABEL in 6126bis 91 2. Introduction and background 93 The Babel routing protocol as defined is [BABEL] is a distance vector 94 routing protocol for next-hop routing. In next-hop routing, each 95 node maintains a forwarding table which maps prefixes to next-hops. 96 The forwarding decision is a per-packet operation which depends on 97 the destination address of the packets and on the entries of the 98 forwarding table. When a packet is about to be routed, its 99 destination address is compared to the prefixes of the routing table: 100 the entry with the most specific prefix containing the destination 101 address of the packet is choosen, and the packet is forwarded to the 102 associated next-hop. Next-hop routing is a simple, well understood 103 paradigm that works satisfactorily in a large number of cases. 105 Source-specific routing is a modest extension of next-hop routing 106 where the forwarding decision additionnaly depends on the source 107 address of the packets. The forwarding tables are extended to map 108 pairs of prefixes (destination, source) to a next-hop. When multiple 109 entries are candidate to route a packet, the one with the most 110 specific destination prefix is choosen, and in case of equality the 111 one with the most specific source. In source-specific routing, two 112 packets with the same destination but different sources may be 113 forwarded among different paths. 115 The main application of source-specific routing is, at the time of 116 this writing, multihoming with Provider Agregatable (PA) addresses. 117 In such configuration, each Internet Service Provider (ISP) provides 118 to the network a PA prefix and a default route for this prefix while 119 performing ingress filtering ([BCP84]). Each host has one address 120 per ISP, and sends packets with one of these addresses as source 121 address. Source-specific routing ensures that packets are routed 122 towards the provider of their source address, such that they are not 123 filtered out. More details and more use cases can be found in 124 [SS-ROUTING],[IETF-SSR]. 126 This document describes the source-specific routing extension for the 127 Babel routing protocol [BABEL]. This involves changes to data 128 structures and protocol messages. The data structures receive an 129 additionnal source prefix which is part of the index, similarly to 130 (and with) the destination prefix. The Update, Route Request and 131 Seqno Request are the three messages which carry a (destination) 132 prefix: they are extended with a source prefix. 134 3. Data Structures 136 Some of the data structures of a Babel node contains a destination 137 prefix or are partly indexed by a destination prefix. This extension 138 adds a source prefix to these structures and indexes. 140 3.1. The Source Table 142 Every Babel node maintains a source table, as described in [BABEL], 143 Section 3.2.5. A source-specific Babel node extends this table with 144 the following field. With this extension, the source table is 145 indexed by triples of the form (prefix, source prefix, router-id). 147 o the source prefix specifying the source address of packets to 148 which this entry applies. 150 If a source table entry has a zero length source prefix, then the 151 entry is a non-source-specific entry, and is treated just like a 152 source table entry defined by the original Babel protocol. 154 With this extension, the route entry contains a source which itself 155 contains a source prefix. These are two very different concepts, and 156 should not be confused. 158 3.2. The Route Table 160 Every Babel node maintains a route table, as described in [BABEL], 161 Section 3.2.6. With this extension, the route table is indexed by 162 triples of the form (prefix, source prefix, neighbour) obtained from 163 the associated source table entry. 165 If a route table entry has a zero length source prefix, then the 166 entry is a non-source-specific entry, and is treated just like a 167 route table entry defined by the original Babel protocol. 169 3.3. The Table of Pending Seqno Requests 171 Every Babel node maintains a table of pending seqno requests, as 172 described in [BABEL], Section 3.2.7. A source-specific Babel node 173 extends this table with the following entry. With this extension, 174 the table of pending seqno requests is indexed by triples of the form 175 (prefix, source prefix, router-id). 177 o the source prefix being requested. 179 4. Data Forwarding 181 In next-hop routing, if two routing table entries overlap, then one 182 is necessarily more specific than the other; the "longest prefix 183 rule" specifies that the most specific applicable routing table entry 184 is chosen. 186 With source-specific routing, there might no longer be a most 187 specific applicable entry: two routing table entries might match a 188 given packet without one necessarily being more specific than the 189 other. Consider for example the following routing table: 191 destination source next-hop 192 2001:DB8:0:1::/64 ::/0 A 193 ::/0 2001:DB8:0:2::/64 B 195 This specifies that all packets with destination in 2001:DB8:0:1::/64 196 are to be routed through A, while all packets with source in 197 2001:DB8:0:2::/64 are to be routed through B. A packet with source 198 2001:DB8:0:2::42 and destination 2001:DB8:0:1::57 matches both rules, 199 although neither is more specific than the other. A choice is 200 necessary, and unless the choice being made is the same on all 201 routers in a routing domain, persistent routing loops may occur. 202 More informations are available in [SS-ROUTING] Section IV.C. 204 A Babel implementation MUST choose routing table entries by using the 205 so-called destination-first ordering, where a routing table entry R1 206 is preferred to a routing table entry R2 when either R1's destination 207 prefix is more specific than R2's, or the destination prefixes are 208 equal and R1's source prefix is more specific than R2's. (In more 209 formal terms, routing table entries are compared using the 210 lexicographic product of the destination prefix ordering by the 211 source prefix ordering.) 213 In practice, this means that a source-specific Babel implementation 214 must take care that any lower layer that performs packet forwarding 215 obey this semantics. In particular: 217 o If the lower layers implement the destination-first ordering, then 218 the Babel implementation MAY use them directly; 220 o If the lower layers can hold source-specific routes, but not with 221 the right semantics, then the Babel implementation MUST 222 disambiguate the routing table by using a suitable disambiguation 223 algorithm (see [SS-ROUTING] Section V.B for such an algorithm); 225 o If the lower layers cannot hold source-specific routes, then a 226 Babel implementation MUST silently ignore (drop) any source- 227 specific routes. 229 5. Protocol Operation 231 This extension does not fundamentally change the operation of the 232 Babel protocol. We only describe the fundamental differences between 233 the original protocol and this extension in this section. The other 234 mechanisms described in [BABEL] (Section 3) are extended to pairs of 235 (destination, source) prefixes instead of just (destination) 236 prefixes. 238 5.1. Source-specific messages 240 Three messages carry a destination prefix: Updates, Route Requests 241 and Seqno Requests. These messages are extended to carry, in 242 addition, a source prefix if (and only if) the corresponding route is 243 source-specific. More formally, an Update, a Route Request and a 244 Seqno Request MUST carry a source prefix if they concern a source- 245 specific route (non-zero length source prefix) and MUST NOT carry a 246 source prefix otherwise (zero length source prefix). A message which 247 carries a source prefix is said to be source-specific. 249 5.2. Route Acquisition 251 When a non-source-specific Babel node receives a source-specific 252 update, it silently ignores it. When a source-specific Babel node 253 receives a non-source-specific update, it MUST treat this update as a 254 zero length source-specific update. 256 When a source-specific Babel node receives a source-specific update 257 (prefix, source prefix, router-id, seqno, metric) from a neighbour 258 neigh, it behaves as described in [BABEL] (Section 3.5.4) though 259 indexing entries by (prefix, source prefix, neigh). 261 5.3. Wildcard retractions (update) 263 The original protocol defines a wildcard update with AE equals to 0 264 as being a wildcard retraction. A node receiving a wildcard 265 retraction on an interface must consider that the sending node 266 retracts all the routes it advertised on this interface. 268 Wildcard retractions are used when a node is about to leave the 269 network. Thus, this extension does not define source-specific 270 wildcard retraction, but extends wildcard retraction to apply also to 271 source-specific routes. More formally, a wildcard update MUST NOT 272 carry a source prefix, and a source-specific Babel node receiving a 273 (legacy) wildcard update MUST retracts all routes it learns from this 274 node (including source-specific ones). 276 5.4. Wildcard requests 278 The original Babel protocol states that when a node receives a 279 wildcard route request, it SHOULD send a full routing table dump. 280 This extension does not change this statement: a source-specific node 281 SHOULD send a full routing table dump when receiving a wildcard 282 request. 284 Source-specific wildcard requests does not exist: a wildcard request 285 MUST NOT carry a source prefix, and a source prefix associated with a 286 wildcard update SHOULD be ignored. 288 One of the motivation behalf this design choice is that wildcard 289 requests are defined with AE equals to 0. They naturally apply to AE 290 1, AE 2 and AE 3 defined in [BABEL], but also to any other AE which 291 may be defined in the future. New AEs, new TLVs or new sub-TLVs are 292 extension mechanisms. Thus, the semantics of a wildcard request is 293 clearly to also asks for routes coming from extensions. 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 its known 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 not compatible with the Experimental 305 Track's Babel Routing Protocol [RFC6126]. It requires the mandatory 306 sub-TLV introduced in [BABEL]. Consequently, this extension MUST NOT 307 be used with routers implementing RFC 6126, otherwise persistent 308 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 reannounces the route as D. This 322 reannouncement 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 by 348 the three following existing messages: Update, Route Request and 349 Seqno Request. 351 7.1. Source Prefix sub-TLV 353 0 1 2 3 354 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 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 |Type = TBD[128]| Length | Source Plen | Source Prefix... 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 359 Fields: 361 Type Set to TBD[128] to indicate a Source Prefix sub-TLV. 363 Length The length of the body, exclusive of the Type and Length 364 fields. 366 Source Plen The length of the advertised source prefix. This MUST 367 NOT be 0. 369 Source Prefix The source prefix being advertised. This field's size 370 is (Source Plen)/8 rounded upwards. 372 The source prefix encoding (AE) is the same as the Prefix's. It is 373 defined by the AE field of the corresponding TLV. 375 Note that this sub-TLV is a Mandatory sub-TLV. The whole TLV MUST be 376 ignored if that sub-TLV is not recognized. Otherwise, routing loops 377 may occur (see Section 6.1). 379 7.2. Source-specific Update 381 The source-specific Update is an Update TLV with a Source Prefix sub- 382 TLV. It advertises or retracts source-specific routes in the same 383 manner than routes with non-source-specific Updates (see [BABEL]). A 384 wildcard retraction (Update with AE equals to 0) MUST NOT carry a 385 Source Prefix sub-TLV. 387 Contrary to the destination prefix, this extension does not compress 388 the source prefix attached to Updates. However, as defined in 389 [BABEL] (Section 4.5), the compression is allowed for the destination 390 prefix of source-specific routes. Legacy implementation will 391 correctly update their parser state while ignoring the whole TLV 392 afterwards. 394 7.3. Source-specific (Route) Request 396 A source-specific Route Request is a Route Request TLV with a Source 397 Prefix sub-TLV. It prompts the receiver to send an update for a 398 given pair of destination and source prefixes. A wildcard request 399 (Route Request with AE equals to 0) MUST NOT carry a Source Prefix 400 sub-TLV. 402 7.4. Source-Specific Seqno Request 404 A source-specific Seqno Request is a Seqno Request TLV with a Source 405 Prefix sub-TLV. It is just like a Seqno Request for a source- 406 specific route. It uses the same mechanisms described in [BABEL]. 408 8. IANA Considerations 410 IANA is requested to allocate TBD, a Babel sub-TLV type from the 411 range reserved for mandatory sub-TLVs [value 128 suggested], and to 412 add the following entry to the "Babel mandatory sub-TLV Types" 413 registry: 415 +----------+---------------+-----------------+ 416 | Type | Name | Reference | 417 +----------+---------------+-----------------+ 418 | TBD[128] | Source Prefix | (this document) | 419 +----------+---------------+-----------------+ 421 9. Security considerations 423 The extension defined in this document adds a new sub-TLV to three 424 TLVs already present in the original Babel protocol. It does not by 425 itself change the security properties of the protocol. 427 10. References 429 10.1. Normative References 431 [BABEL] Chroboczek, J., "The Babel Routing Protocol", Internet 432 Draft draft-ietf-babel-rfc6126bis-02, May 2017. 434 [BCP84] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 435 Networks", BCP 84, RFC 3704, March 2004. 437 [IETF-SSR] 438 Lamparter, D. and A. Smirnov, "Destination/Source 439 Routing", Internet Draft draft-ietf-rtgwg-dst-src-routing, 440 May 2017. 442 [RFC6126] Chroboczek, J., "The Babel Routing Protocol 443 (Experimental)", RFC 6126, February 2011. 445 10.2. Informative References 447 [SS-ROUTING] 448 Boutier, M. and J. Chroboczek, "Source-Specific Routing", 449 August 2014. 451 In Proc. IFIP Networking 2015. A slightly earlier 452 version is available online from http://arxiv.org/ 453 pdf/1403.0445. 455 Authors' Addresses 457 Matthieu Boutier 458 IRIF, University of Paris-Diderot 459 Case 7014 460 75205 Paris Cedex 13 461 France 463 Email: boutier@irif.fr 465 Juliusz Chroboczek 466 IRIF, University of Paris-Diderot 467 Case 7014 468 75205 Paris Cedex 13 469 France 471 Email: jch@irif.fr