idnits 2.17.1 draft-chroboczek-babel-extension-mechanism-04.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 an Introduction section. ** The document seems to lack a Security Considerations section. ** The abstract seems to contain references ([RFC6126]), 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 75: '...ersion number different from 2 MUST be...' RFC 2119 keyword, line 78: '... o an unknown TLV MUST be silently ignored ([RFC6126], Section 4.3);...' RFC 2119 keyword, line 81: '... extra data included in a TLV MUST be silently ignored ([RFC6126],...' RFC 2119 keyword, line 85: '... MUST be silently ignored ([RFC6126], Section 4.4.9);...' RFC 2119 keyword, line 87: '...TLV of a Babel packet MUST be silently...' (16 more instances...) -- The draft header indicates that this document updates RFC6126, but the abstract doesn't seem to directly say this. It does mention RFC6126 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 27, 2015) is 3280 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 6126 (Obsoleted by RFC 8966) == Outdated reference: A later version (-01) exists of draft-chroboczek-babel-diversity-routing-00 == Outdated reference: A later version (-02) exists of draft-jonglez-babel-rtt-extension-00 == Outdated reference: A later version (-03) exists of draft-boutier-babel-source-specific-00 -- Obsolete informational reference (is this intentional?): RFC 7298 (Obsoleted by RFC 8967) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Chroboczek 3 Internet-Draft PPS, University of Paris-Diderot 4 Updates: 6126 (if approved) March 27, 2015 5 Intended status: Experimental 6 Expires: September 28, 2015 8 Extension Mechanism for the Babel Routing Protocol 9 draft-chroboczek-babel-extension-mechanism-04 11 Abstract 13 This document defines the encoding of extensions to the Babel routing 14 protocol [RFC6126]. 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 September 28, 2015. 33 Copyright Notice 35 Copyright (c) 2015 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. Extending the Babel routing protocol . . . . . . . . . . . . 2 51 2. Mechanisms for extending the Babel protocol . . . . . . . . . 3 52 2.1. New versions of the Babel protocol . . . . . . . . . . . 3 53 2.2. New TLVs . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.3. Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2.4. The Flags field . . . . . . . . . . . . . . . . . . . . . 4 56 2.5. Packet trailer . . . . . . . . . . . . . . . . . . . . . 5 57 3. Format of sub-TLVs . . . . . . . . . . . . . . . . . . . . . 5 58 3.1. Sub-TLVs specified in this document . . . . . . . . . . . 5 59 3.2. Unknown sub-TLVs . . . . . . . . . . . . . . . . . . . . 6 60 4. Choosing between extension mechanisms . . . . . . . . . . . . 6 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 62 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 65 7.2. Informative References . . . . . . . . . . . . . . . . . 10 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 68 1. Extending the Babel routing protocol 70 A Babel packet [RFC6126] contains a header followed by a sequence of 71 TLVs, each of which is a sequence of octets having an explicit type 72 and length. The original Babel protocol has the following provisions 73 for including extension data: 75 o a Babel packet with a version number different from 2 MUST be 76 silently ignored ([RFC6126], Section 4.2); 78 o an unknown TLV MUST be silently ignored ([RFC6126], Section 4.3); 80 o except for Pad1 and PadN, all TLVs are self-terminating, and any 81 extra data included in a TLV MUST be silently ignored ([RFC6126], 82 Section 4.2); 84 o the Flags field of the Update TLV contains 6 undefined bits that 85 MUST be silently ignored ([RFC6126], Section 4.4.9); 87 o any data following the last TLV of a Babel packet MUST be silently 88 ignored ([RFC6126], Section 4.2). 90 Each of these provisions provides a place to store data needed by 91 extensions of the Babel protocol. However, in the absence of any 92 further conventions, independently developed extensions to the Babel 93 protocol might make conflicting uses of the available space, and 94 therefore lead to implementations that would fail to interoperate. 95 This document formalises a set of rules for extending the Babel 96 protocol that are designed to ensure that no such incompatibilities 97 arise, and that are currently respected by a number of deployed 98 extensions. 100 In the rest of this document, we call "original protocol" the 101 protocol defined in [RFC6126], and "extended protocol" any extension 102 of the Babel protocol that follows the rules set out in this 103 document. 105 2. Mechanisms for extending the Babel protocol 107 This section describes each of the mechanisms available for extending 108 the Babel protocol. 110 2.1. New versions of the Babel protocol 112 The header of a Babel packet contains an eight-bit protocol version. 113 The current version of the Babel protocol is version 2; any packets 114 containing a version number different from 2 MUST be silently 115 ignored. 117 Versions 0 and 1 were earlier experimental versions of the Babel 118 protocol that have seen some modest deployment; these version numbers 119 SHOULD NOT be reused by future versions of the Babel protocol. 120 Version numbers larger than 2 might be used by a future incompatible 121 protocol. 123 2.2. New TLVs 125 An extension may carry its data in a new TLV type. Such new TLVs 126 will be silently ignored by implementations of the original Babel 127 protocol, as well as by other extended implementations of the Babel 128 protocol, as long as the TLV types do not collide. 130 All new TLVs MUST have the format defined in [RFC6126], Section 4.3. 131 New TLVs SHOULD be self-terminating, in the sense defined in the next 132 section, and any data found after the main data section of the TLV 133 SHOULD be treated as a series of sub-TLVs. 135 TLV types 224 through 254 are reserved for Experimental Use 136 [RFC3692]. TLV type 255 is reserved for expansion of the TLV type 137 space, in the unlikely event that eight bits turn out not to be 138 enough. 140 2.3. Sub-TLVs 142 With the exception of the Pad1 TLV, all Babel TLVs carry an explicit 143 length. With the exception of Pad1 and PadN, all TLVs defined by the 144 original protocol are self-terminating, in the sense that the length 145 of the meaningful data that they contain (the "natural length") can 146 be determined without reference to the explicitly encoded length. In 147 some cases, the natural length is trivial to determine: for example, 148 a HELLO TLV always has a natural length of 2 (4 including the Type 149 and Length fields). In other cases, determining the natural length 150 is not that easy, but needs to be done in any case by an 151 implementation that interprets the given TLV: for example, the 152 natural length of an Update TLV depends on both the prefix length and 153 the amount of prefix compression being performed. 155 If the explicit length of a TLV defined by the original protocol is 156 larger than its natural length, the extra space present in the TLV is 157 silently ignored by an implementation of the original protocol; 158 extended implementations MAY use it to store arbitrary data, and 159 SHOULD structure the additional data as a sequence of sub-TLVs. 160 Unlike TLVs, the sub-TLVs themselves need not be self-terminating. 162 An extension MAY be assigned one or more sub-TLV types. Sub-TLV 163 types are assigned independently from TLV types: the same numeric 164 type can be assigned to a TLV and a sub-TLV. Sub-TLV types are 165 assigned globally: once an extension is assigned a given sub-TLV 166 number, it MAY use this number within any TLV; however, the 167 interpretation of a given sub-TLV type can depend on which particular 168 TLV it is embedded within. 170 Sub-TLV types 224 through 254 are reserved for Experimental Use 171 [RFC3692]. TLV type 255 is reserved for expansion of the sub-TLV 172 type space, in the unlikely event that eight bits turn out not to be 173 enough. The format of sub-TLVs is defined in Section 3 below. 175 2.4. The Flags field 177 The Flags field is an eight-bit field in the Update TLV. Bits 0 and 178 1 (the bits with values 80 and 40 hexadecimal) are defined by the 179 original protocol, and MUST be recognised and used by every 180 implementation. The remaining six bits are not currently used, and 181 are silently ignored by implementations of the original protocol. 183 Due to the small size of the Flags field, it is NOT RECOMMENDED that 184 one or more bits be assigned to an extension; a sub-TLV SHOULD be 185 assigned instead. An implementation MUST ignore any bits in the 186 Flags field that it does not know about, and MUST send them as zero. 188 2.5. Packet trailer 190 A Babel packet carries an explicit length in its header. A Babel 191 packet is carried by a UDP datagram, which in turn contains an 192 explicit length in its header. It is possible for a UDP datagram 193 carrying a Babel packet to be larger than the size of the Babel 194 packet. In that case, the extra space after the Babel packet, known 195 as the packet trailer, is silently ignored by an implementation of 196 the original protocol. 198 The packet trailer was originally intended to be used as a 199 cryptographic trailer. However, the authentication extension to 200 Babel [RFC7298] ended up using a pair of new TLVs, and no currently 201 deployed extension of Babel uses the packet trailer. The format and 202 purpose of the packet trailer is therefore currently left undefined. 204 3. Format of sub-TLVs 206 A sub-TLV has exactly the same structure as a TLV. Except for Pad1 207 (Section 3.1.1), all sub-TLVs have the following structure: 209 0 1 2 3 210 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 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Type | Length | Body... 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 215 Fields : 217 Type The type of the sub-TLV. 219 Length The length of the body, in octets, exclusive of the Type 220 and Length fields. 222 Body The sub-TLV body, the interpretation of which depends on 223 both the type of the sub-TLV and the type of the TLV within 224 which it is embedded. 226 3.1. Sub-TLVs specified in this document 228 This document defines two types of sub-TLVs, Pad1 and PadN. These 229 two sub-TLVs MUST be correctly parsed and ignored by any extended 230 implementation of the Babel protocol that uses sub-TLVs. 232 3.1.1. Pad1 234 0 235 0 1 2 3 4 5 6 7 236 +-+-+-+-+-+-+-+-+ 237 | Type = 0 | 238 +-+-+-+-+-+-+-+-+ 240 Fields : 242 Type Set to 0 to indicate a Pad1 sub-TLV. 244 This sub-TLV is silently ignored on reception. 246 3.1.2. PadN 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Type = 1 | Length | MBZ... 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 254 Fields : 256 Type Set to 1 to indicate a PadN sub-TLV. 258 Length The length of the body, in octets, exclusive of the Type 259 and Length fields. 261 MBZ Set to 0 on transmission. 263 This sub-TLV is silently ignored on reception. 265 3.2. Unknown sub-TLVs 267 Any unknown sub-TLV MUST be silently ignored by an extended 268 implementation that uses sub-TLVs. 270 4. Choosing between extension mechanisms 272 New versions of the Babel protocol should only be defined if the new 273 version is not backwards compatible with the original protocol. 275 In many cases, an extension could be implemented either by defining a 276 new TLV, or by adding a new sub-TLV to an existing TLV. For example, 277 an extension whose purpose is to attach additional data to route 278 updates can be implemented either by creating a new "enriched" Update 279 TLV, or by adding a sub-TLV to the Update TLV. 281 The two encodings are treated differently by implementations that do 282 not understand the extension. In the case of a new TLV, the whole 283 unknown TLV is ignored by an implementation of the original protocol, 284 while in the case of a new sub-TLV, the TLV is parsed and acted upon, 285 and the unknown sub-TLV is silently ignored. Therefore, a sub-TLV 286 should be used by extensions that extend the Update in a compatible 287 manner (the extension data may be silently ignored), while a new TLV 288 must be used by extensions that make incompatible extensions to the 289 meaning of the TLV (the whole TLV must be thrown away if the 290 extension data is not understood). 292 Using a new bit in the Flags field is equivalent to defining a new 293 sub-TLV while using less space in the Babel packet. Due to the 294 limited Flags space, and the doubtful space savings, we do not 295 recommend the use of bits in the Flags field -- a new sub-TLVs should 296 be used instead. 298 We refrain from making any recommendations about the usage of the 299 packet trailer due to the lack of implementation experience. 301 5. IANA Considerations 303 IANA is to create three new registries, called "Babel TLV types", 304 "Babel sub-TLV types", and "Babel Flags values". The allocation 305 policy for all three of these registries is Expert Review with 306 Specification Required [RFC5226]. 308 The initial value of the Babel TLV types registry is as follows: 310 +---------+---------------------------------------+-----------------+ 311 | Type | Name | Reference | 312 +---------+---------------------------------------+-----------------+ 313 | 0 | Pad1 | [RFC6126] | 314 | | | | 315 | 1 | PadN | [RFC6126] | 316 | | | | 317 | 2 | Acknowledgment Request | [RFC6126] | 318 | | | | 319 | 3 | Acknowledgment | [RFC6126] | 320 | | | | 321 | 4 | Hello | [RFC6126] | 322 | | | | 323 | 5 | IHU | [RFC6126] | 324 | | | | 325 | 6 | Router-Id | [RFC6126] | 326 | | | | 327 | 7 | Next Hop | [RFC6126] | 328 | | | | 329 | 8 | Update | [RFC6126] | 330 | | | | 331 | 9 | Route Request | [RFC6126] | 332 | | | | 333 | 10 | Seqno Request | [RFC6126] | 334 | | | | 335 | 11 | TS/PC | [RFC7298] | 336 | | | | 337 | 12 | HMAC | [RFC7298] | 338 | | | | 339 | 13 | Source-specific Update | [BABEL-SS] | 340 | | | | 341 | 14 | Source-specific Request | [BABEL-SS] | 342 | | | | 343 | 15 | Source-specific Seqno Request | [BABEL-SS] | 344 | | | | 345 | 224-254 | Reserved for Experimental Use | (this document) | 346 | | | | 347 | 255 | Reserved for expansion of the type | (this document) | 348 | | space | | 349 +---------+---------------------------------------+-----------------+ 350 The initial value of the Babel sub-TLV types registry is as follows: 352 +---------+-------------------------------------+-------------------+ 353 | Type | Name | Reference | 354 +---------+-------------------------------------+-------------------+ 355 | 0 | Pad1 | (this document) | 356 | | | | 357 | 1 | PadN | (this document) | 358 | | | | 359 | 2 | Diversity | [BABEL-DIVERSITY] | 360 | | | | 361 | 3 | Timestamp | [BABEL-RTT] | 362 | | | | 363 | 224-254 | Reserved for Experimental Use | (this document) | 364 | | | | 365 | 255 | Reserved for expansion of the type | (this document) | 366 | | space | | 367 +---------+-------------------------------------+-------------------+ 369 The initial value of the Babel Flags values registry is as follows: 371 +-----+-------------------+-----------+ 372 | Bit | Name | Reference | 373 +-----+-------------------+-----------+ 374 | 0 | Default prefix | [RFC6126] | 375 | | | | 376 | 1 | Default router-id | [RFC6126] | 377 +-----+-------------------+-----------+ 379 6. Acknowledgments 381 I am grateful to Denis Ovsienko and Gabriel Kerneis for their 382 feedback on previous versions of this document. 384 7. References 386 7.1. Normative References 388 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 389 Considered Useful", BCP 82, RFC 3692, January 2004. 391 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 392 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 393 May 2008. 395 [RFC6126] Chroboczek, J., "The Babel Routing Protocol", RFC 6126, 396 February 2011. 398 7.2. Informative References 400 [BABEL-DIVERSITY] 401 Chroboczek, J., "Diversity Routing for the Babel Routing 402 Protocol", draft-chroboczek-babel-diversity-routing-00 403 (work in progress), July 2014. 405 [BABEL-RTT] 406 Jonglez, B. and J. Chroboczek, "Delay-based Metric 407 Extension for the Babel Routing Protocol", draft-jonglez- 408 babel-rtt-extension-00 (work in progress), July 2014. 410 [BABEL-SS] 411 Boutier, M. and J. Chroboczek, "Source-Specific Routing in 412 Babel", draft-boutier-babel-source-specific-00 (work in 413 progress), November 2014. 415 [RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code 416 (HMAC) Cryptographic Authentication", RFC 7298, July 2014. 418 Author's Address 420 Juliusz Chroboczek 421 PPS, University of Paris-Diderot 422 Case 7014 423 75205 Paris Cedex 13 424 France 426 Email: jch@pps.univ-paris-diderot.fr