idnits 2.17.00 (12 Aug 2021) /tmp/idnits60659/draft-hoeiland-joergensen-babel-implementation-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 a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC6126]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 05, 2016) is 2237 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6126 (Obsoleted by RFC 8966) ** Obsolete normative reference: RFC 7557 (Obsoleted by RFC 8966) Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Babel T. Hoeiland-Joergensen 3 Internet-Draft Karlstad University 4 Intended status: Informational April 05, 2016 5 Expires: October 7, 2016 7 Experiences implementing the Babel routing protocol 8 draft-hoeiland-joergensen-babel-implementation-00 10 Abstract 12 This document describes the experiences creating independent 13 implementations of the Babel routing protocol [RFC6126], based on the 14 two independent implementations currently available. 16 The Babel routing protocol is easy to implement, and it is quite 17 feasible for someone with no prior experience with routing protocols 18 to create a working implementation. The few issues that needed 19 clarification during the independent implementation work are 20 documented, with the hope of aiding others seeking to implement 21 Babel. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on October 7, 2016. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Overall experiences . . . . . . . . . . . . . . . . . . . . . 3 59 3. Specific issues encountered . . . . . . . . . . . . . . . . . 3 60 3.1. Port number . . . . . . . . . . . . . . . . . . . . . . . 3 61 3.2. Metric functions . . . . . . . . . . . . . . . . . . . . 3 62 3.3. Sequence number space . . . . . . . . . . . . . . . . . . 3 63 3.4. Error handling on packet parsing . . . . . . . . . . . . 3 64 3.5. Router ID issues . . . . . . . . . . . . . . . . . . . . 4 65 3.6. The need for blackhole routing . . . . . . . . . . . . . 4 66 3.7. Extra space at the end of TLVs . . . . . . . . . . . . . 4 67 3.8. Imprecise language concerning IDs . . . . . . . . . . . . 4 68 4. In summary . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 5.1. Normative References . . . . . . . . . . . . . . . . . . 5 71 5.2. Informative References . . . . . . . . . . . . . . . . . 5 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 74 1. Introduction 76 Babel [RFC6126] is a distance vector routing protocol especially 77 suited for hybrid networks (with both stable and unstable parts) 78 [I-D.chroboczek-babel-applicability]. The reference implementation 79 (Babeld, available from http://www.pps.univ-paris- 80 diderot.fr/~jch/software/babel/) is released as open source and has 81 been deployed in several places. However, having separate clean- 82 slate implementations of the protocol from the specification is an 83 important part of the work to standardise the protocol. This 84 document is an attempt to collect the experiences of implementing 85 Babel from the RFC, to serve as information for others wanting to 86 implement the protocol. 88 There currently exists two independent implementations of the 89 protocol, Pybabel by Markus Stenberg (https://github.com/fingon/ 90 pybabel/) and a patch to the Bird routing daemon by Toke Hoeiland- 91 Joergensen (http://trubka.network.cz/pipermail/bird- 92 users/2016-April/010300.html). This document is based on the 93 experiences from these two implementations. 95 2. Overall experiences 97 Overall, the Babel protocol is remarkably easy to implement. The 98 specification is just over 40 pages, of which around 30 (sections 3 99 and 4 of [RFC6126]) contain the details required for an 100 implementation and the rest is background and supporting text. This 101 means that it is possible to understand the protocol and keep it 102 present in one's mind in its entirety. Indeed, a feeling of "really, 103 that's it?" presents itself in the early stages of the work with the 104 protocol. 106 The two independent implementations were created in a few days and a 107 few weeks, respectively. And while none of them are as complete as 108 the reference implementation (for instance, none of them currently 109 implement any extensions, and both are IPv6-only), this attests to 110 the ease with which a new implementation can be written. 112 3. Specific issues encountered 114 This section documents the issues that needed clarification during 115 the implementation work. All of these issues were resolved on the 116 public mailing lists during the work with the implementation, but 117 they are collected and documented here to help future implementers. 119 3.1. Port number 121 The port number specified in [RFC6126] is wrong; an errata exists 122 that changes the port number to the right one (6696), but this can 123 easily be missed. 125 3.2. Metric functions 127 The base specification does not include any metric functions. 128 Workable functions are specified in the RFC appendix, however, and 129 using those leads to a workable and interoperable implementation. 131 3.3. Sequence number space 133 The handling of sequence number space is not specified in the RFC. 134 The sequence numbers should be computed by module arithmetic as 135 specified by [RFC1982], but no reference exists for this in 136 [RFC6126]. 138 3.4. Error handling on packet parsing 140 The Babel specification does not specify how to handle parsing errors 141 when processing incoming packets. For instance, some TLVs have 142 implicit dependencies on earlier TLVs in the same packet (such as 143 Update TLVs depending on earlier Router ID TLVs), and so continuing 144 processing if the earlier TLV fails to parse is likely to lead to 145 errors. Some care is needed when implementing this logic, and 146 [RFC6126] does not offer a lot of guidance. 148 3.5. Router ID issues 150 The Babel specification includes a mechanism to infer router IDs from 151 prefixes in an Update TLV; however, it does not specify how to do 152 this for IPv4 addresses. In addition, while a mechanism to generate 153 router IDs is specified that is unlikely to generate duplicates, this 154 is optional and no mechanism for detecting or reacting to duplicate 155 IDs is specified. Finally, when writing an implementation it is easy 156 to assume that one can simply check for an empty router ID to 157 discover if a router ID TLV has been seen; however, an all-zero 158 router ID is not in fact disallowed by the specification, and so an 159 extra explicit flag is needed in the parsing state. 161 3.6. The need for blackhole routing 163 When a route is retracted, Babel temporarily installs it as an 164 explicit unreachable route in the kernel routing table. This is done 165 to avoid routing loops when a more specific route fails. The reason 166 for this mechanism is explained in section 2.8 of [RFC6126]. 167 However, since this is in the background section of the document, one 168 is not likely to refer to that after an initial reading. And since 169 this practice is somewhat unusual, it can lead to confusion. 171 3.7. Extra space at the end of TLVs 173 The Babel specification explicitly allows extra space at the end of 174 TLVs, and uses this for its extension mechanism (specified in 175 [RFC7557]). However, this fact can easily be missed leading one to 176 implement the protocol in a way that rejects TLVs with extra trailing 177 data. 179 3.8. Imprecise language concerning IDs 181 In section 3.5 of [RFC6126] (specifying route table maintenance), 182 there is some confusing use of 'id' in various contexts that may take 183 a few readings to sort out. 185 4. In summary 187 The Babel routing protocol is easy to implement, as has been shown by 188 two independent implementations created in a few days and weeks 189 respectively. The specification is very readable with only a few 190 omissions and unclear points as noted above. It is quite feasible 191 for someone with no prior experience with routing protocols to create 192 a working implementation, and doing so is instructive for someone 193 looking to understand both routing protocols in general and the Babel 194 protocol in particular. 196 5. References 198 5.1. Normative References 200 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 201 DOI 10.17487/RFC1982, August 1996, 202 . 204 [RFC6126] Chroboczek, J., "The Babel Routing Protocol", RFC 6126, 205 DOI 10.17487/RFC6126, April 2011, 206 . 208 [RFC7557] Chroboczek, J., "Extension Mechanism for the Babel Routing 209 Protocol", RFC 7557, DOI 10.17487/RFC7557, May 2015, 210 . 212 5.2. Informative References 214 [I-D.chroboczek-babel-applicability] 215 Chroboczek, J., "Applicability of the Babel routing 216 protocol", draft-chroboczek-babel-applicability-01 (work 217 in progress), February 2016. 219 Author's Address 221 Toke Hoeiland-Joergensen 222 Karlstad University 223 Dept. of Computer Science 224 Karlstad 65188 225 Sweden 227 Email: toke.hoiland-jorgensen@kau.se