idnits 2.17.00 (12 Aug 2021) /tmp/idnits23491/draft-boutier-babel-source-specific-00.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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 140: '...l implementation MUST choose routing t...' RFC 2119 keyword, line 154: '...l implementation MAY use them directly...' RFC 2119 keyword, line 157: '...cs, then the Babel implementation MUST...' RFC 2119 keyword, line 162: '...l implementation SHOULD silently ignor...' RFC 2119 keyword, line 163: '... routes and MUST NOT reannounce t...' (12 more instances...) -- The draft header indicates that this document updates RFC6126, 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 -- The document date (November 20, 2014) is 2738 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6126 (ref. 'BABEL') (Obsoleted by RFC 8966) == Outdated reference: draft-chroboczek-babel-extension-mechanism has been published as RFC 7557 ** Obsolete normative reference: RFC 7298 (Obsoleted by RFC 8967) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 2 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: 6126 (if approved) PPS, University of Paris-Diderot 5 Intended status: Experimental November 20, 2014 6 Expires: May 24, 2015 8 Source-Specific Routing in Babel 9 draft-boutier-babel-source-specific-00 11 Abstract 13 This document describes extensions to the Babel routing protocol to 14 support source-specific routing. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on May 24, 2015. 33 Copyright Notice 35 Copyright (c) 2014 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction and background . . . . . . . . . . . . . . . . . 2 51 2. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 2 52 2.1. The Source Table . . . . . . . . . . . . . . . . . . . . 2 53 2.2. The Route Table . . . . . . . . . . . . . . . . . . . . . 3 54 2.3. The Table of Pending Requests . . . . . . . . . . . . . . 3 55 3. Data Forwarding . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 4 57 4.1. Sending updates . . . . . . . . . . . . . . . . . . . . . 4 58 4.2. Requests . . . . . . . . . . . . . . . . . . . . . . . . 4 59 5. Protocol Encoding . . . . . . . . . . . . . . . . . . . . . . 5 60 5.1. Source-Specific Update . . . . . . . . . . . . . . . . . 5 61 5.2. Source-Specific Request . . . . . . . . . . . . . . . . . 7 62 5.3. Source-Specific Seqno Request . . . . . . . . . . . . . . 7 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 7. Security considerations . . . . . . . . . . . . . . . . . . . 9 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 68 1. Introduction and background 70 Source-specific routing is an extension to traditional next-hop where 71 packets are routed according to both their destination and their 72 source address. This document describes extensions to the Babel 73 routing protocol [BABEL] to support source-specific routing. 75 Background information about source-specific routing is provided in 76 [SS-ROUTING]. 78 2. Data Structures 80 This extension adds some data to the data structures maintained by a 81 Babel node. 83 2.1. The Source Table 85 Every Babel node maintains a source table, as described in [BABEL], 86 Section 3.2.4. A source-specific Babel node extends this table with 87 the following field: 89 o the source prefix (sprefix, splen) specifying the source of 90 packets to which this entry applies. 92 If splen is 0, then this is a non-specific entry, and is treated just 93 like a source table entry defined by the original Babel protocol. 95 With this extension the route entry contains a source which itself 96 contains a source prefix. Notwithstanding the accidental similarity 97 in their names, these are two very different concepts, and should not 98 be confused. 100 2.2. The Route Table 102 Every Babel node maintains a route table, as described in [BABEL], 103 Section 3.2.5. With this extension, this table is indexed by the 104 5-tuple (prefix, plen, source prefix, source plen, router-id) 105 obtained from the associated source table entry. 107 2.3. The Table of Pending Requests 109 Every Babel node maintains a table of pending requests, as described 110 in [BABEL], Section 3.2.6. A source-specific Babel node extends this 111 table with the following entry: 113 o the source prefix being requested. 115 3. Data Forwarding 117 In next-hop routing, if two routing table entries overlap, then one 118 is necessarily more specific than the other; the "longest prefix 119 rule" specifies that the most specific applicable routing table entry 120 is chosen. 122 With source-specific routing, there might no longer be a most 123 specific applicable prefix: two routing table entries might match a 124 given packet without one necessarily being more specific than the 125 other. Consider for example the following fragment of a routing 126 table: 128 (2001:DB8:0:1::/64, ::/0, A) 130 (::/0, 2001:DB8:0:2::/64, B) 132 This specifies that all packets with destination in 2001:DB8:0:1::/64 133 are to be routed through A, while packets with a source in 134 2001:DB8:0:2::/64 are to be routed through B. A packet with source 135 2001:DB8:0:2::42 and destination 2001:DB8:0:1::57 matches both rules, 136 although neither is more specific than the other. A choice is 137 necessary, and unless the choice being made is the same on all 138 routers in a routing domain, persistent routing loops may occur. 140 A Babel implementation MUST choose routing table entries by using the 141 so-called destination-first ordering, where a routing table entry R1 142 is preferred to a routing table entry R2 when either R1's destination 143 prefix is more specific than R2's, or the destination prefixes are 144 equal and R1's source prefix is more specific than R2's. (In more 145 formal terms, routing table entries are compared using the 146 lexicographic product of the destination prefix ordering by the 147 source prefix ordering.) 149 In practice, this means that a source-specific Babel implementation 150 must take care that any lower layers that perform packet forwarding 151 obey this semantics. In particular: 153 o If the lower layers implement the destination-first ordering, then 154 the Babel implementation MAY use them directly; 156 o If the lower layers can hold source-specific routes, but not with 157 the right semantics, then the Babel implementation MUST 158 disambiguate the routing table by using a suitable disambiguation 159 algorithm (see [SS-ROUTING] for such an algorithm). 161 o If the lower layers cannot hold source-specific routes, then a 162 Babel implementation SHOULD silently ignore any source-specific 163 routes and MUST NOT reannounce them to other nodes. 165 4. Protocol Operation 167 This extension does not fundamentally change the operation of the 168 Babel protocol. 170 4.1. Sending updates 172 This extension introduces a new kind of update, the source-specific 173 update. Whenever a source-specific Babel node needs to send an 174 update, it checks whether the update is for a source-specific route 175 (a route with a source prefix of non-zero length); if that is the 176 case, it sends a source-specific update (Section 5.1), and otherwise 177 it sends a non-specific update ([BABEL], Section 4.4.9). 179 Every Babel node maintains a source table, which it updates whenever 180 it sends an Update ([BABEL], Section 3.7.3). A source-specific Babel 181 node extends this procedure by updating the source table not only 182 when it sends an update, but also when it sends a source-specific 183 update. 185 4.2. Requests 187 This extension duplicates Babel's two request types: there are now 188 two kinds of route requests (source-specific and unspecific), and, 189 similarly, two kinds of seqno requests. 191 This extension does not modify Babel's strategy for sending requests. 192 Whenever a Babel node needs to send a request, it checks whether the 193 request is for a source-specific route; if it is, it should send one 194 of the request types defined in this document; if it is not, then it 195 should send one of the request types defined in the original Babel 196 specification. 198 4.2.1. Wildcard requests 200 The Babel protocol provides the ability to request a full routing 201 table dump by sending a "wildcard request", a route request with the 202 AE field set to 0. This extension does not modify the semantics of 203 wildcard requests: a wildcard request prompts a dump of non-specific 204 routes only, and a Babel node SHOULD NOT send any source-specific 205 updates in reply to a wildcard request. 207 A different request is used for obtaining a dump of the source- 208 specific routes in a node's routing table. A "source-specific 209 wildcard request" is a source-specific request (Section 5.2) whose AE 210 field is 0; it requests a dump of the receiving nodes source-specific 211 routes only (routes with a source prefix length of 1 or more). A 212 node SHOULD NOT send any non-specific updates in reply to a source- 213 specific wildcard request. 215 In consequence, a node requiring a full routing table dump SHOULD 216 send both a non-specific wildcard request and a source-specific 217 wildcard request. 219 5. Protocol Encoding 221 This extension defines three new TLV types that are used by Source- 222 Specific Babel nodes and silently ignored by ordinary Babel nodes, in 223 accordance with [BABEL-EXT]. 225 5.1. Source-Specific Update 226 0 1 2 3 227 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 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Type = 13 | Length | AE | Source Plen | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Plen | Omitted | Interval | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Seqno | Metric | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Prefix... 236 +-+-+-+-+-+-+-+-+-+-+-+- 237 | Source prefix... 238 +-+-+-+-+-+-+-+-+-+-+-+- 240 Fields: 242 Type Set to 13 to indicate a source-specific update TLV. 244 Length The length of the body, exclusive of the Type and Length 245 fields. 247 AE The encoding of the prefix field. 249 Source Plen The length of the advertised source prefix. This MUST 250 NOT be 0. 252 Plen The length of the advertised destination prefix. 254 Omitted The number of octets that have been omitted at the 255 beginning of the advertised prefix and that should be taken 256 from a preceding Update TLV with the flag with value 80 257 hexadecimal set. 259 Interval An upper bound, expressed in centiseconds, on the time 260 after which the sending node will send a new update for 261 this prefix. This MUST NOT be 0 and SHOULD NOT be less 262 than 10. The receiving node will use this value to compute 263 a hold time for this routing table entry. The value FFFF 264 hexadecimal (infinity) expresses that this announcement 265 will not be repeated unless a request is received. 267 Seqno The originator's sequence number for this update. 269 Metric The sender's metric for this route. The value FFFF 270 hexadecimal (infinity) means that this is a route 271 retraction. 273 Prefix The destination prefix being advertised. This field's size 274 is (Plen/8 - Omitted) rounded upwards. 276 Source Prefix The source prefix being advertised. This field's size 277 is (Source Plen)/8 rounded upwards. 279 5.2. Source-Specific Request 281 0 1 2 3 282 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 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Type = 14 | Length | AE | Plen | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Source Plen | Prefix... 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 288 | Source prefix... 289 +-+-+-+-+-+-+-+-+-+-+-+- 291 Fields: 293 Type Set to 14 to indicate a Source-Specific Route Request TLV. 295 Length The length of the body, exclusive of the Type and Length 296 fields. 298 AE The encoding of the prefix field. The value 0 (wildcard) 299 requests a full dump of all the source-specific routes of 300 the receving node (i.e. those with non-zero source prefix 301 length). 303 Plen The length of the requested destination prefix. 305 Source Plen The length of the requested source prefix. This MUST 306 NOT be 0, except for AE 0. 308 Prefix The destination prefix being requested. This field's size 309 is Plen/8 rounded upwards. 311 Source Prefix The source prefix being advertised. This field's size 312 is (Source Plen)/8 rounded upwards. 314 5.3. Source-Specific Seqno Request 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Type = 15 | Length | AE | Plen | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Seqno | Hop Count | Source Plen | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | | 323 + Router-Id + 324 | | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Prefix... 327 +-+-+-+-+-+-+-+-+-+-+-+- 328 | Source prefix... 329 +-+-+-+-+-+-+-+-+-+-+-+- 331 Fields: 333 Type Set to 15 to indicate a Source-Specific Seqno Request TLV. 335 Length The length of the body, exclusive of the Type and Length 336 fields. 338 AE The encoding of the prefix field. This MUST NOT be 0. 340 Plen The length of the requested destination prefix. 342 Seqno The sequence number that is being requested. 344 Hop Count The maximum number of times that this TLV may be forwarded, 345 plus 1. This MUST NOT be 0. 347 Source Plen The length of the requested source prefix. This MUST 348 NOT be 0. 350 Router-Id The Router-ID associated to this route. 352 Prefix The destination prefix being requested. This field's size 353 is Plen/8 rounded upwards. 355 Source Prefix The source prefix being advertised. This field's size 356 is "Source Plen"/8 rounded upwards. 358 A Source-Specific Seqno Request TLV prompts the receiving node to 359 send an Update for the route specified by the AE, Plen, Prefix, 360 Source Plen and Source Prefix fields, with either a router-id 361 different from what is specified by the Router-Id field, or a Seqno 362 no less than what is specified by the Seqno field. If this request 363 cannot be satisfied locally, then it is forwarded according to the 364 rules set out in Section 3.8.1.2 of [BABEL]. 366 Just like an ordinary Seqno Request, a Source-Specific Seqno Request 367 MAY be sent to a multicast address but MUST NOT be forwarded to a 368 multicast address and MUST NOT be forwarded to more than one 369 neighbour. A Source-Specific Seqno Request MUST NOT be forwarded if 370 its Hop Count field is 1. 372 6. IANA Considerations 374 This document defines three new Babel TLV types: 376 13 - Source-Specific Update 378 14 - Source-Specific Request 380 15 - Source-Specific Seqno Request 382 7. Security considerations 384 By itself, the Babel routing protocol is not a secure protocol; this 385 extension doesn't change that fact. Babel can be made secure by 386 using a suitable cryptographic layer, such as the one described in 387 [RFC7298]. 389 8. References 391 [BABEL] Chroboczek, J., "The Babel Routing Protocol", RFC 6126, 392 February 2011. 394 [BABEL-EXT] 395 Chroboczek, J., "Extension Mechanism for the Babel Routing 396 Protocol", Internet Draft draft-chroboczek-babel- 397 extension-mechanism-00, June 2013. 399 [RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code 400 (HMAC) Cryptographic Authentication", RFC 7298, July 2014. 402 [SS-ROUTING] 403 Boutier, M. and J. Chroboczek, "Source-sensitive routing", 404 August 2014. 406 Authors' Addresses 407 Matthieu Boutier 408 PPS, University of Paris-Diderot 409 Case 7014 410 75205 Paris Cedex 13 411 France 413 Email: boutier@pps.univ-paris-diderot.fr 415 Juliusz Chroboczek 416 PPS, University of Paris-Diderot 417 Case 7014 418 75205 Paris Cedex 13 419 France 421 Email: jch@pps.univ-paris-diderot.fr