idnits 2.17.1 draft-ietf-babel-source-specific-08.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 (21 April 2021) is 1101 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) -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 6126 (Obsoleted by RFC 8966) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 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 5 Expires: 23 October 2021 21 April 2021 7 Source-Specific Routing in Babel 8 draft-ietf-babel-source-specific-08 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 https://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 23 October 2021. 35 Copyright Notice 37 Copyright (c) 2021 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 (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Simplified BSD License text 46 as described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction and background . . . . . . . . . . . . . . . . . 2 52 1.1. Application to multihoming . . . . . . . . . . . . . . . 3 53 1.2. Other applications . . . . . . . . . . . . . . . . . . . 4 54 1.3. Specificity of prefix pairs . . . . . . . . . . . . . . . 5 55 2. Specification of Requirements . . . . . . . . . . . . . . . . 6 56 3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 7 57 3.1. The Source Table . . . . . . . . . . . . . . . . . . . . 7 58 3.2. The Route Table . . . . . . . . . . . . . . . . . . . . . 7 59 3.3. The Table of Pending Seqno Requests . . . . . . . . . . . 7 60 4. Data Forwarding . . . . . . . . . . . . . . . . . . . . . . . 8 61 5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 8 62 5.1. Protocol Messages . . . . . . . . . . . . . . . . . . . . 9 63 5.2. Wildcard Messages . . . . . . . . . . . . . . . . . . . . 9 64 6. Compatibility with the base protocol . . . . . . . . . . . . 10 65 6.1. Starvation and Blackholes . . . . . . . . . . . . . . . . 10 66 7. Protocol Encoding . . . . . . . . . . . . . . . . . . . . . . 10 67 7.1. Source Prefix sub-TLV . . . . . . . . . . . . . . . . . . 11 68 7.2. Source-specific Update . . . . . . . . . . . . . . . . . 12 69 7.3. Source-specific Route Request . . . . . . . . . . . . . . 12 70 7.4. Source-Specific Seqno Request . . . . . . . . . . . . . . 12 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 72 9. Security considerations . . . . . . . . . . . . . . . . . . . 12 73 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 76 11.2. Informative References . . . . . . . . . . . . . . . . . 13 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 79 1. Introduction and background 81 The Babel routing protocol [RFC8966] is a distance vector routing 82 protocol for next-hop routing. In next-hop routing, each node 83 maintains a forwarding table which maps destination prefixes to next 84 hops. The forwarding decision is a per-packet operation which 85 depends on the destination address of the packets and on the entries 86 of the forwarding table. When a packet is about to be routed, its 87 destination address is compared to the prefixes of the routing table: 88 the entry with the most specific prefix containing the destination 89 address of the packet is chosen, and the packet is forwarded to the 90 associated next-hop. Next-hop routing is a simple, well understood 91 paradigm that works satisfactorily in a large number of cases. 93 The use of next-hop routing limits the flexibility of the routing 94 system in two ways. First, since the routing decision is local to 95 each router, a router A can only select a route ABC...Z if its 96 neighbouring router B has selected the route BC...Z. Second, the 97 only criterion used by a router to choose a route is the destination 98 address: two packets with the same destination follow the same route. 99 Yet, there are other data in the IP header that could conceivably be 100 used to guide the routing decision -- the ToS octet and, of course, 101 the source address. 103 Source-specific routing [SS-ROUTING], or Source Address Dependent 104 Routing (SADR), is a modest extension to next-hop routing where the 105 forwarding decision depends not only on the destination address but 106 also on the source address of the packet being routed, which makes it 107 possible for two packets with the same destination but different 108 source addresses to be routed following different paths. 110 This document describes a source-specific routing extension for the 111 Babel routing protocol [RFC8966]. This involves minor changes to the 112 data structures, which must include a source prefix in addition to 113 the destination prefix already present, and some changes to the 114 Update, Route Request and Seqno Request TLVs, which are extended with 115 a source prefix. The source prefix is encoded using a mandatory sub- 116 TLV ([RFC8966] Section 4.4). 118 1.1. Application to multihoming 120 Multihoming is the practice of connecting a single network to two or 121 more transit networks. The main application of source-specific 122 routing is a form of multihoming known as "multihoming with multiple 123 addresses". 125 Classical multihoming consists in assigning a provider-independent 126 range of addresses to the multihomed network and announcing it to all 127 transit providers. While classical multihoming works well for large 128 networks, the cost of obtaining a provider-independent address range 129 and announcing it globally in the Internet is prohibitive for small 130 networks. Unfortunately, it is not possible to implement classical 131 multihoming with ordinary provider-dependent addresses: in a network 132 connected to two providers A and B, a packet with a source address 133 allocated by A needs to be routed through the edge router connected 134 to A. If it is routed through the edge router connected to B, it 135 will most likely be filtered (dropped), in accordance with [BCP84]. 137 In multihoming with multiple addresses, every host in the multihomed 138 network is assigned multiple addresses, one for each transit 139 provider. Additional mechanisms are needed in order (i) to choose, 140 for each packet, a source address that is associated with a provider 141 that is currently up, and (ii) to route each packet towards the 142 router connected to the provider associated with its source address. 143 One might argue that multihoming with multiple addresses splits the 144 difficult problem of multihoming into two simpler sub-problems. 146 The issue of choosing a suitable source address is a decision local 147 to the sending host, and an area of active research. The simplest 148 solution is to use a traditional transport-layer protocol, such as 149 TCP, and to probe all available source addresses at connection time, 150 analogously to what is already done with destination addresses, 151 either sequentially [RFC3484] or in parallel [RFC8305]. Since the 152 transport-layer protocol is not aware of the multiple available 153 addresses, flows are interrupted when the selected provider goes down 154 (from the point of view of the user, all TCP connections are dropped 155 when the network environment changes). A better user experience can 156 be provided by making available all of the potential source and 157 destination addresses to higher layer protocols, either at the 158 transport layer [RFC8684] [RFC4960], or at the applicaton layer 159 [RFC8445]. 161 Source-specific routing solves the problem of routing a packet to the 162 edge router indicated by its source address. Every edge router 163 announces into the routing domain a default route specific to the 164 prefix associated with the provider it is connected to. This route 165 is propagated all the way to the routers on the access link, which 166 are therefore able to route every packet to the correct router. 167 Hosts simply send packets to their default router -- no host changes 168 are necessary at the network layer. 170 1.2. Other applications 172 In addition to multihoming with multiple addresses, we are aware of 173 two applications of source-specific routing. Tunnels and VPNs are 174 packet encapsulation techniques that are commonly used in the 175 Internet to establish a network-layer topology that is different from 176 the physical topology. In some deployments, the default route points 177 at the tunnel; this causes the network stack to attempt to send 178 encapsulated packets through the tunnel, which causes it to break. 179 Various solutions to this problem are possible, the most common of 180 which is to point a host route at the tunnel endpoint. 182 When source-specific routing is available, it becomes possible to 183 announce through the tunnel a default route that is specific to the 184 prefix served by the tunnel. Since the encapsulated packets have a 185 source address that is not within that prefix, they are not routed 186 through the tunnel. 188 The third application of source-specific routing is controlled 189 anycast. Anycast is a technique in which a single destination 190 address is used to represent multiple network endpoints, collectively 191 called an "anycast group". A packet destined to the anycast group is 192 routed to an arbitrary member of the group, typically the one that is 193 nearest according to the routing protocol. 195 In many applications of anycast, such as DNS root servers, the 196 nondeterminism of anycast is acceptable; some applications, however, 197 require finer control. For example, in some Content Distribution 198 Networks (CDNs) every endpoint is expected to handle a well-defined 199 subset of the client population. With source-specific routing, it is 200 possible for each member of the anycast group to announce a route 201 specific to its client population, a technique that is both simpler 202 and more robust than manually tweaking the routing protocol's metric 203 ("prepending" in BGP). 205 1.3. Specificity of prefix pairs 207 In ordinary next-hop routing, when multiple routing table entries 208 match the destination of a packet, the "longest prefix rule" mandates 209 that the most specific one applies. The reason why this rule makes 210 sense is that the set of prefixes has the following "tree property": 212 for any prefixes P and P', either P and P' are disjoint, or one is 213 more specific than the other. 215 It would be a natural proposition to order pairs of prefixes 216 pointwise: to define that (D,S) is more specific than (D',S') when D 217 is more specific than D and S is more specific than S'. 218 Unfortunately, the set of pairs of prefixes with the pointwise 219 ordering doesn't satisfy the tree property. Indeed, consider the 220 following two pairs: 222 (2001:db8:0:1::/64, ::/0) and (::/0, 2001:db8:0:2::/64) 224 These two pairs are not disjoint (a packet with destination 225 2001:db8:0:1::1 and source 2001:db8:0:2::1 is matched by both), but 226 neither is more specific than the other. The effect is that there is 227 no natural unambiguous way to interpret a routing table such as the 228 following: 230 destination source next-hop 231 2001:db8:0:1::/64 ::/0 A 232 ::/0 2001:db8:0:2::/64 B 234 A more refined ordering over pairs of prefixes is required in order 235 to avoid all ambiguities. There are two natural choices: the 236 destination-first ordering, where (D,S) is more specific than (D',S') 237 when 239 * D is strictly more specific than D'; or 241 * D = D' and S is more specific than S', 242 and, symmetrically, the source-first ordering, in which sources are 243 compared first and destinations second. 245 Expedient as it would be to leave the choice to the implementation, 246 this is not possible: all routers in a routing domain must use the 247 same ordering, lest persistent routing loops occur. Indeed, consider 248 the following topology: 250 A --- B --- C --- D 252 Suppose that A announces a route for (::/0, 2001:db8:0:2::/64), while 253 D announces a route for (2001:db8:0:1::/64, ::/0). Suppose further 254 that B uses the destination-first ordering, while C uses the source- 255 first ordering. Then a packet that matches both routes, say, with 256 destination 2001:db8:0:1::1 and source 2001:db8:0:2::1, would be sent 257 by B towards D and by C towards A, and would therefore loop 258 indefinitely between B and C. 260 This document mandates (Section 4) that all routers use the 261 destination-first ordering, which is generally believed to be more 262 useful than the source-first ordering. Consider the following 263 topology, where A is an edge router connected to the Internet and B 264 is an internal router connected to an access network N: 266 (::/0, S) (D, ::/0) 267 Internet --- A --- B --- N 269 A announces a source-specific default route with source S (::/0, S), 270 while B announces a non-specific route to prefix D. Consider what 271 happens to a packet with a desination in D and a source in S. With 272 the destination-first ordering, the packet is routed towards the 273 network N, which is the only way it can possibly reach its 274 destination. With the source-first ordering, on the other hand, the 275 packet is sent towards the Internet, with no hope to ever reach its 276 destination in N. 278 2. Specification of Requirements 280 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 281 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 282 "OPTIONAL" in this document are to be interpreted as described in 283 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 284 capitals, as shown here. 286 3. Data Structures 288 A number of the conceptual data structures described in Section 3.2 289 of [RFC8966] contain a destination prefix. This specification 290 extends these data structures with a source prefix. Data from the 291 original protocol, which do not specify a source prefix, are stored 292 with a zero length source prefix, which matches exactly the same set 293 of packets as the original, non-source-specific data. 295 3.1. The Source Table 297 Every Babel node maintains a source table, as described in [RFC8966] 298 Section 3.2.5. A source-specific Babel node extends this table with 299 the following field: 301 * The source prefix (sprefix, splen) specifying the source address 302 of packets to which this entry applies. 304 The source table is now indexed by 5-tuples of the form (prefix, 305 plen, sprefix, splen, router-id). 307 Note that the route entry contains a source (see sections 2 and 3.2.5 308 of [RFC8966]) which itself contains both destination and source 309 prefixes. These are two different concepts, and must not be 310 confused. 312 3.2. The Route Table 314 Every Babel node maintains a route table, as described in [RFC8966] 315 Section 3.2.6. Each route table entry contains, among other data, a 316 source, which this specification extends with a source prefix as 317 described above. The route table is now indexed by 5-tuples of the 318 form (prefix, plen, sprefix, splen, neighbour), where the first four 319 components are obtained from the source. 321 3.3. The Table of Pending Seqno Requests 323 Every Babel node maintains a table of pending seqno requests, as 324 described in [RFC8966], Section 3.2.7. A source-specific Babel node 325 extends this table with the following entry: 327 * The source prefix (sprefix, splen) being requested. 329 The table of pending seqno requests is now indexed by 5-tuples of the 330 form (prefix, plen, sprefix, splen, router-id). 332 4. Data Forwarding 334 As noted in Section 1.3 above, source-specific tables can, in 335 general, be ambiguous, and all routers in a routing domain must use 336 the same algorithm for choosing applicable routes. An implementation 337 of the extension described in this document MUST choose routing table 338 entries by using the destination-first ordering, where a routing 339 table entry R1 is preferred to a routing table entry R2 when either 340 R1's destination prefix is more specific than R2's, or the 341 destination prefixes are equal and R1's source prefix is more 342 specific than R2's. 344 In practice, this means that a source-specific Babel implementation 345 must take care that any lower layer that performs packet forwarding 346 obey this semantics. More precisely: 348 * if the lower layers implement the destination-first ordering, then 349 the Babel implementation SHOULD use them directly; 351 * if the lower layers can hold source-specific routes, but not with 352 the right semantics, then the Babel implementation MUST either 353 silently ignore any source-specific routes, or disambiguate the 354 routing table by using a suitable disambiguation algorithm (see 355 Section V.B of [SS-ROUTING] for such an algorithm); 357 * if the lower layers cannot hold source-specific routes, then a 358 Babel implementation MUST silently ignore any source-specific 359 routes. 361 5. Protocol Operation 363 This extension does not fundamentally change the operation of the 364 Babel protocol, and we therefore only describe differences between 365 the original protocol and the extended protocol. 367 In the original protocol, three TLVs carry a destination prefix: 368 Updates, Route Requests and Seqno Requests. This specification 369 extends these messages so that they may carry a Source Prefix sub- 370 TLV, as described in Section 7 below. The sub-TLV is marked as 371 mandatory, so that an unextended implementation will silently ignore 372 the whole enclosing TLV. A node obeying this specification MUST NOT 373 send a TLV with a zero-length source prefix: instead, it sends a TLV 374 with no Source Prefix sub-TLV. Conversely, an extended 375 implementation MUST interpret an unextended TLV as carrying a source 376 prefix of zero length. Taken together, these properties ensure 377 interoperability between the original and extended protocols (see 378 Section 6 below). 380 5.1. Protocol Messages 382 This extension allows three TLVs of the original Babel protocol to 383 carry a source prefix: Update TLVs, Route Request TLVs, and Seqno 384 Request TLVs. 386 In order to advertise a route with a non-zero length source prefix, a 387 node sends a source-specific Update, i.e., an Update with a Source 388 Prefix sub-TLV. When a node receives a source-specific Update 389 (prefix, source prefix, router-id, seqno, metric) from a neighbour 390 neigh, it behaves as described in [RFC8966] Section 3.5.3, except 391 that the entry under consideration is indexed by (prefix, plen, 392 sprefix, splen, neigh) rather than just (prefix, plen, neigh). 394 Similarly, when a node needs to send a Request of either kind that 395 applies to a route with a non-zero length source prefix, it sends a 396 source-specific Request, i.e., a Request with a Source Prefix sub- 397 TLV. When a node receives a source-specific Request, it behaves as 398 described in Section 3.8 of [RFC8966], except that the request 399 applies to the Route Table entry carrying the source prefix indicated 400 by the Source Prefix sub-TLV. 402 5.2. Wildcard Messages 404 In the original protocol, the Address Encoding (AE) value 0 is used 405 for wildcard messages: messages that apply to all routes, of any 406 address family and with any destination prefix. Wildcard messages 407 are allowed in two places in the protocol: wildcard retractions are 408 used to retract all of the routes previously advertised by a node on 409 a given interface, and wildcard Route Requests are used to request a 410 full dump of the Route Table from a given node. Wildcard messages 411 are intended to apply to all routes, including routes decorated with 412 additional data and AE values to be defined by future extensions, and 413 hence this specification extends wildcard operations to apply to all 414 routes, whatever the value of the source prefix. 416 More precisely, a node receiving an Update with the AE field set to 0 417 and the Metric field set to infinity (a wildcard retraction) MUST 418 apply the route acquisition procedure described in Section 3.5.3 of 419 [RFC8966] to all of the routes that it has learned from the sending 420 node, whatever the value of the source prefix. A node MUST NOT send 421 a wildcard retraction with an attached source prefix, and a node that 422 receives a wildcard retraction with a source prefix MUST ignore the 423 retraction. 425 Similarly, a node that receives a route request with the AE field set 426 to 0 (a wildcard route request) SHOULD send a full routing table 427 dump, including routes with a non-zero length source prefix. A node 428 MUST NOT send a wildcard request that carries a source prefix, and a 429 node receiving a wildcard request with a source prefix MUST ignore 430 the request. 432 6. Compatibility with the base protocol 434 The protocol extension defined in this document is, to a great 435 extent, interoperable with the base protocol defined in [RFC8966] 436 (and all previously standardised extensions). More precisely, if 437 non-source-specific routers and source-specific routers are mixed in 438 a single routing domain, Babel's loop-avoidance properties are 439 preserved, and, in particular, no persistent routing loops will 440 occur. 442 However, this extension is encoded using mandatory sub-TLVs, 443 introduced in [RFC8966], and therefore is not compatible with the 444 older version of the Babel Routing Protocol [RFC6126] which does not 445 support mandatory sub-TLVs. Consequently, this extension MUST NOT be 446 used in a routing domain in which some routers implement RFC 6126, 447 otherwise persistent routing loops may occur. 449 6.1. Starvation and Blackholes 451 In general, the discarding of source-specific routes by non-source- 452 specific routers will cause route starvation. Intuitively, unless 453 there are enough non-source-specific routes in the network, non- 454 source-specific routers will suffer starvation, and discard packets 455 for destinations that are only announced by source-specific routers. 457 In the common case where all source-specific routes are originated at 458 one of a small set of edge routers, a simple yet sufficient condition 459 for avoiding starvation is to build a connected source-specific 460 backbone that includes all of the edge routers, and announce a non- 461 source-specific default route towards the backbone. 463 7. Protocol Encoding 465 This extension defines a new sub-TLV used to carry a source prefix: 466 the Source Prefix sub-TLV. It can be used within an Update, a Route 467 Request or a Seqno Request TLV to match a source-specific entry of 468 the Route Table, in conjunction with the destination prefix natively 469 carried by these TLVs. 471 Since a source-specific routing entry is characterized by a single 472 destination prefix and a single source prefix, a source-specific 473 contains message exactly one Source Prefix sub-TLV. A node MUST NOT 474 send more than one Source Prefix sub-TLV in a TLV, and a node 475 receiving more than one Source Prefix sub-TLV in a single TLV MUST 476 ignore the TLV. It MAY ignore the whole packet. 478 7.1. Source Prefix sub-TLV 480 0 1 2 3 481 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 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Type = 128 | Length | Source Plen | Source Prefix... 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 486 Fields: 488 Type Set to 128 to indicate a Source Prefix sub-TLV. 490 Length The length of the body, in octets, exclusive of the Type 491 and Length fields. 493 Source Plen The length of the advertised source prefix, in bits. 494 This MUST NOT be 0. 496 Source Prefix The source prefix being advertised. This field's size 497 is (Source Plen)/8 octets rounded upwards. 499 The length of the body TLV is normally of size 1+(Source Plen)/8 500 rounded upwards. If the Length field indicates a length smaller than 501 that, then the sub-TLV is corrupt, and the whole enclosing TLV must 502 be ignored; if the Length field indicates a length that is larger, 503 then the extra octets contained in the sub-TLV MUST be silently 504 ignored. 506 The contents of the Source Prefix sub-TLV are interpreted according 507 to the AE of the enclosing TLV. If a TLV with AE equal to 0 contains 508 a Source Prefix sub-TLV, then the whole enclosing TLV MUST be 509 ignored. If a TLV contains multiple Source Prefix sub-TLVs, then the 510 whole TLV MUST be ignored. 512 Note that this sub-TLV is a mandatory sub-TLV. Therefore, as 513 described in Section 4.4 of [RFC8966], the whole TLV MUST be ignored 514 if that sub-TLV is not understood (or malformed). 516 7.2. Source-specific Update 518 The source-specific Update is an Update TLV with a Source Prefix sub- 519 TLV. It advertises or retracts source-specific routes in the same 520 manner as routes with non-source-specific Updates (see [RFC8966]). A 521 wildcard retraction (Update with AE equal to 0) MUST NOT carry a 522 Source Prefix sub-TLV. 524 Babel uses a stateful compression scheme to reduce the size taken by 525 destination prefixes in update TLVs (see Section 4.5 of [RFC8966]). 526 The source prefix defined by this extension is not compressed. On 527 the other hand, compression is allowed for the destination prefixes 528 carried by source-specific updates. As described in Section 4.5 of 529 [RFC8966], unextended implementations will correctly update their 530 parser state while otherwise ignoring the whole TLV. 532 7.3. Source-specific Route Request 534 A source-specific Route Request is a Route Request TLV with a Source 535 Prefix sub-TLV. It prompts the receiver to send an update for a 536 given pair of destination and source prefixes, as described in 537 Section 3.8.1.1 of [RFC8966]. A wildcard request (Route Request with 538 AE equals to 0) MUST NOT carry a Source Prefix sub-TLV; if a wildcard 539 request with a Source Prefix sub-TLV is received, then the request 540 MUST be ignored. 542 7.4. Source-Specific Seqno Request 544 A source-specific Seqno Request is a Seqno Request TLV with a Source 545 Prefix sub-TLV. It requests the receiving node to perform the 546 procedure described in Section 3.8.1.2 of [RFC8966], but applied to a 547 pair of a destination and source prefix. 549 8. IANA Considerations 551 IANA has allocated sub-TLV number 128 for the Source Prefix sub-TLV 552 in the Babel sub-TLV types registry. 554 9. Security considerations 556 The extension defined in this document adds a new sub-TLV to three 557 sub-TLVs already present in the original Babel protocol, and does not 558 change the security properties of the protocol itself. However, the 559 additional flexibility provided by source-specific routing might 560 invalidate the assumptions made by some network administrators, which 561 could conceivably lead to security issues. 563 For example, a network administrator might be tempted to abuse route 564 filtering (Appendix C of [RFC8966]) as a security mechanism. Unless 565 the filtering rules are designed to take source-specific routing into 566 account, they might be bypassed by a source-specific route, which 567 might cause traffic to reach a portion of a network that was thought 568 to be protected. A network administrator might also assume that no 569 route is more specific than a host route, and use a host route in 570 order to direct traffic for a given destination through a security 571 device (e.g., a firewall); source-specific routing invalidates this 572 assumption, and in some topologies announcing a source-specific route 573 might conceivably be used to bypass the security device. 575 10. Acknowledgments 577 The authors are indebted to Donald Eastlake, Joel Halpern, and Toke 578 Hoiland-Jorgensen for their help with this document. 580 11. References 582 11.1. Normative References 584 [BCP84] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 585 Networks", BCP 84, RFC 3704, March 2004, 586 . 588 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 589 Requirement Levels", BCP 14, RFC 2119, 590 DOI 10.17487/RFC2119, March 1997, 591 . 593 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 594 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 595 May 2017, . 597 [RFC8966] Chroboczek, J. and D. Schinazi, "The Babel Routing 598 Protocol", RFC 8966, DOI 10.17487/RFC8966, January 2021, 599 . 601 11.2. Informative References 603 [RFC3484] Draves, R., "Default Address Selection for Internet 604 Protocol version 6 (IPv6)", RFC 3484, 605 DOI 10.17487/RFC3484, February 2003, 606 . 608 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 609 RFC 4960, DOI 10.17487/RFC4960, September 2007, 610 . 612 [RFC6126] Chroboczek, J., "The Babel Routing Protocol", RFC 6126, 613 DOI 10.17487/RFC6126, April 2011, 614 . 616 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 617 Better Connectivity Using Concurrency", RFC 8305, 618 DOI 10.17487/RFC8305, December 2017, 619 . 621 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 622 Connectivity Establishment (ICE): A Protocol for Network 623 Address Translator (NAT) Traversal", RFC 8445, 624 DOI 10.17487/RFC8445, July 2018, 625 . 627 [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. 628 Paasch, "TCP Extensions for Multipath Operation with 629 Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 630 2020, . 632 [SS-ROUTING] 633 Boutier, M. and J. Chroboczek, "Source-Specific Routing", 634 August 2014, . In Proc. 635 IFIP Networking 2015. 637 Authors' Addresses 639 Matthieu Boutier 640 IRIF, University of Paris 641 Case 7014 642 75205 Paris Cedex 13 643 France 645 Email: boutier@irif.fr 647 Juliusz Chroboczek 648 IRIF, University of Paris 649 Case 7014 650 75205 Paris Cedex 13 651 France 653 Email: jch@irif.fr