idnits 2.17.1 draft-ietf-homenet-babel-profile-03.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 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 ([RFC7788], [RFC6126bis]), 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 121: '...ntation of Babel MUST encapsulate Babe...' RFC 2119 keyword, line 133: '...ntation of Babel MUST implement the IP...' RFC 2119 keyword, line 139: '...ntation of Babel SHOULD implement the ...' RFC 2119 keyword, line 151: '...ntation of Babel MUST implement source...' RFC 2119 keyword, line 160: '...ntation of Babel MUST use metrics that...' (17 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 25, 2017) is 2375 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-babel-source-specific-01 == Outdated reference: A later version (-20) exists of draft-ietf-babel-rfc6126bis-02 == Outdated reference: A later version (-02) exists of draft-jonglez-babel-rtt-extension-01 -- Obsolete informational reference (is this intentional?): RFC 7298 (Obsoleted by RFC 8967) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Chroboczek 3 Internet-Draft IRIF, University of Paris-Diderot 4 Intended status: Experimental October 25, 2017 5 Expires: April 28, 2018 7 Homenet profile of the Babel routing protocol 8 draft-ietf-homenet-babel-profile-03 10 Abstract 12 This document defines the subset of the Babel routing protocol 13 [RFC6126bis] and its extensions that a Homenet router must implement, 14 as well as the interactions between HNCP [RFC7788] and Babel. 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 April 28, 2018. 33 Copyright Notice 35 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. The Homenet profile of Babel . . . . . . . . . . . . . . . . 3 53 2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 54 2.2. Non-requirements . . . . . . . . . . . . . . . . . . . . 4 55 3. Interactions between HNCP and Babel . . . . . . . . . . . . . 5 56 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 5 57 3.2. Non-requirements . . . . . . . . . . . . . . . . . . . . 6 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 59 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 60 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 62 6.2. Informative References . . . . . . . . . . . . . . . . . 7 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 65 1. Introduction 67 The core of the Homenet protocol suite consists of HNCP [RFC7788], a 68 protocol used for flooding configuration information and assigning 69 prefixes to links, combined with the Babel routing protocol 70 [RFC6126bis]. Babel is an extensible, flexible and modular protocol: 71 minimal implementations of Babel have been demonstrated that consist 72 of a few hundred of lines of code, while the "large" implementation 73 includes support for a number of extensions and consists of over ten 74 thousand lines of C code. 76 This document consists of two parts. The first specifies the exact 77 subset of the Babel protocol and its extensions that is required by 78 an implementation of the Homenet protocol suite. The second 79 specifies how HNCP interacts with Babel. 81 1.1. Background 83 The Babel routing protocol and its extensions are defined in a number 84 of documents: 86 o RFC 6126bis [RFC6126bis] defines the Babel routing protocol. It 87 allows Babel's control data to be carried over either link-local 88 IPv6 or IPv4, and in either case allows announcing both IPv4 and 89 IPv6 routes. It leaves link cost estimation, metric computation 90 and route selection to the implementation. Distinct 91 implementations of RFC 6126 Babel will interoperate, in the sense 92 that they will maintain a set of loop-free forwarding paths. 93 However, if they implement conflicting options, they might not be 94 able to exchange a full set of routes; in the worst case, an 95 implementation that only implements the IPv6 subset of the 96 protocol and an implementation that only implements the IPv4 97 subset of the protocol will not exchange any routes. In addition, 98 if implementations use conflicting route selection policies, 99 persistent oscillations might occur. 101 o The informative Appendix A of RFC 6126 suggests a simple and easy 102 to implement algorithm for cost and metric computation that has 103 been found to work satisfactorily in a wide range of topologies. 105 o While RFC 6126 does not provide an algorithm for route selection, 106 its Section 3.6 suggests selecting the route with smallest metric 107 with some hysteresis applied. An algorithm that has been found to 108 work well in practice is described in Section III.E of 109 [DELAY-BASED]. 111 o Five RFCs and Internet-Drafts define optional extensions to Babel: 112 HMAC-based authentication [RFC7298], source-specific routing 113 [BABEL-SS], delay-based routing [BABEL-RTT] and ToS-specific 114 routing [ToS-SPECIFIC]. All of these extensions interoperate with 115 the core protocol as well as with each other. 117 2. The Homenet profile of Babel 119 2.1. Requirements 121 REQ1: a Homenet implementation of Babel MUST encapsulate Babel 122 control traffic in IPv6 packets sent to the IANA-assigned port 6696 123 and either the IANA-assigned multicast group ff02::1:6 or to a link- 124 local unicast address. 126 Rationale: since Babel is able to carry both IPv4 and IPv6 routes 127 over either IPv4 or IPv6, choosing the protocol used for carrying 128 control traffic is a matter of preference. Since IPv6 has some 129 features that make implementations somewhat simpler and more 130 reliable (notably link-local addresses), we require carrying 131 control data over IPv6. 133 REQ2: a Homenet implementation of Babel MUST implement the IPv6 134 subset of the protocol defined in the body of RFC 6126. 136 Rationale: support for IPv6 routing is an essential component of 137 the Homenet architecture. 139 REQ3: a Homenet implementation of Babel SHOULD implement the IPv4 140 subset of the protocol defined in the body of RFC 6126. Use of other 141 techniques for acquiring IPv4 connectivity (such as multiple layers 142 of NAT) is strongly discouraged. 144 Rationale: support for IPv4 will likely remain necessary for years 145 to come, and even in pure IPv6 deployments, including code for 146 supporting IPv4 has very little cost. Since HNCP makes it easy to 147 assign distinct IPv4 prefixes to the links in a network, it is not 148 necessary to resort to multiple layers of NAT, with all of its 149 problems. 151 REQ4: a Homenet implementation of Babel MUST implement source- 152 specific routing for IPv6, as defined in draft-ietf-babel-source- 153 specific [BABEL-SS]. 155 Rationale: source-specific routing is an essential component of 156 the Homenet architecture. Source-specific routing for IPv4 is not 157 required, since HNCP arranges things so that a single non-specific 158 IPv4 default route is announced (Section 6.5 of [RFC7788]). 160 REQ5: a Homenet implementation of Babel MUST use metrics that are of 161 a similar magnitude to the values suggested in Appendix A of 162 RFC 6126. In particular, it SHOULD assign costs that are no less 163 than 256 to wireless links, and SHOULD assign costs between 32 and 164 196 to lossless wired links. 166 Rationale: if two implementations of Babel choose very different 167 values for link costs, combining routers from different vendors 168 will cause sub-optimal routing. 170 REQ6: a Homenet implementation of Babel SHOULD distinguish between 171 wired and wireless links; if it is unable to determine whether a link 172 is wired or wireless, it SHOULD make the worst-case hypothesis that 173 the link is wireless. It SHOULD dynamically probe the quality of 174 wireless links and derive a suitable metric from its quality 175 estimation. The algorithm described in Appendix A of RFC 6126 MAY be 176 used. 178 Rationale: support for wireless transit links is a "killer 179 feature" of Homenet, something that is requested by our users and 180 easy to explain to our bosses. In the absence of dynamically 181 computed metrics, the routing protocol attempts to minimise the 182 number of links crossed by a route, and therefore prefers long, 183 lossy links to shorter, lossless ones. In wireless networks, 184 "hop-count routing is worst-path routing". 186 2.2. Non-requirements 188 NR1: a Homenet implementation of Babel MAY perform route selection by 189 applying hysteresis to route metrics, as suggested in Section 3.6 of 190 RFC 6126 and described in detail in Section III.E of [BABEL-RTT]. 191 However, it MAY simply pick the route with the smallest metric. 193 Rationale: hysteresis is only useful in congested and highly 194 dynamic networks. In a typical home network, stable and 195 uncongested, the feedback loop that hysteresis compensates for 196 does not occur. 198 NR2: a Homenet implementation of Babel MAY include support for other 199 extensions to the protocol, as long as they are known to interoperate 200 with both the core protocol and source-specific routing. 202 Rationale: a number of extensions to the Babel routing protocol 203 have been defined over the years; however, they are useful in 204 fairly specific situations, such as routing over global-scale 205 overlay networks [BABEL-RTT] or multi-hop wireless networks with 206 multiple radio frequencies [BABEL-Z]. Hence, with the exception 207 of source-specific routing, no extensions are required for 208 Homenet. 210 3. Interactions between HNCP and Babel 212 The Homenet architecture cleanly separates between configuration, 213 which is done by HNCP, and routing, which is done by Babel. While 214 the coupling between the two protocols is deliberately kept to a 215 minimum, some interactions are unavoidable. 217 All the interactions between HNCP and Babel consist of HNCP causing 218 Babel to perform an announcement on its behalf (under no 219 circumstances does Babel cause HNCP to perform an action). How this 220 is realised is an implementation detail that is outside the scope of 221 this document; while it could conceivably be done using a private 222 communication channel between HNCP and Babel, in existing 223 implementations HNCP installs a route in the operating system's 224 kernel which is later picked up by Babel using the existing 225 redistribution mechanisms. 227 3.1. Requirements 229 REQ7: if an HNCP node receives a DHCPv6 prefix delegation for prefix 230 P and publishes an External-Connection TLV containing a Delegated- 231 Prefix TLV with prefix P and no Prefix-Policy TLV, then it MUST 232 announce a source-specific default route with source prefix P over 233 Babel. 235 Rationale: source-specific routes are the main tool that Homenet 236 uses to enable optimal routing in the presence of multiple IPv6 237 prefixes. External connections with non-trivial prefix policies 238 are explicitly excluded from this requirement, since their exact 239 behaviour is application-specific. 241 REQ8: if an HNCP node receives a DHCPv4 lease with an IPv4 address 242 and wins the election for NAT gateway, then it MUST act as a NAT 243 gateway and MUST announce a (non-specific) IPv4 default route over 244 Babel. 246 Rationale: the Homenet architecture does not use source-specific 247 routing for IPv4; instead, HNCP elects a single NAT gateway and 248 publishes a single default route towards that gateway ([RFC7788] 249 Section 6.5). 251 REQ9: if an HNCP node assigns a prefix P to an attached link and 252 announces P in an Assigned-Prefix TLV, then it MUST announce a route 253 towards P over Babel. 255 Rationale: prefixes assigned to links must be routable within the 256 Homenet. 258 3.2. Non-requirements 260 NR3: an HNCP node that receives a DHCPv6 prefix delegation MAY 261 announce a non-specific IPv6 default route over Babel in addition to 262 the source-specific default route mandated by requirement REQ7. 264 Rationale: since the source-specific default route is more 265 specific than the non-specific default route, the former will 266 override the latter if all nodes implement source-specific 267 routing. Announcing an additional non-specific route is allowed, 268 since doing that causes no harm and might simplify operations in 269 some circumstances, e.g. when interoperating with a routing 270 protocol that does not support source-specific routing. 272 NR4: an HNCP node that receives a DHCPv4 lease with an IPv4 address 273 and wins the election for NAT gateway SHOULD NOT announce a source- 274 specific IPv4 default route. 276 Homenet does not require support for IPv4 source-specific routing. 277 Announcing IPv4 source-specific routes will not cause routing 278 pathologies (blackholes or routing loops), but it might cause 279 packets sourced in different parts of the Homenet to follow 280 different paths, with all the confusion that this entails. 282 4. Security Considerations 284 Both HNCP and Babel carry their control data in IPv6 packets with a 285 link-local source address, and implementations are required to drop 286 packets sent from a global address. Hence, they are only susceptible 287 to attacks from a directly connected link on which the HNCP and Babel 288 implementations are listening. 290 The security of a Homenet network relies on having a set of 291 "Internal" and "Ad Hoc" interfaces (Section 5.1 of [RFC7788]) that 292 are assumed to be connected to links that are secured at a lower 293 layer. HNCP and Babel packets are only accepted when they originate 294 on these trusted links. "External" and "Guest" interfaces are 295 connected to links that are not trusted, and any HNCP or Babel 296 packets that are received on such interfaces are ignored. ("Leaf" 297 interfaces are a special case, since they are connected to trusted 298 links but HNCP and Babel traffic received on such interfaces is 299 ignored.) 301 If untrusted links are used for transit, which is NOT RECOMMENDED, 302 then any HNCP and Babel traffic that is carried over such links MUST 303 be secured using an upper-layer security protocol. While both HNCP 304 and Babel support cryptographic authentication, at the time of 305 writing no protocol for autonomous configuration of HNCP and Babel 306 security has been defined. 308 5. Acknowledgments 310 A number of people have helped with definining the requirements 311 listed in this document. I am especially indebted to Markus Stenberg 312 for his input. 314 6. References 316 6.1. Normative References 318 [BABEL-SS] 319 Boutier, M. and J. Chroboczek, "Source-Specific Routing in 320 Babel", draft-ietf-babel-source-specific-01 (work in 321 progress), August 2017. 323 [RFC6126bis] 324 Chroboczek, J., "The Babel Routing Protocol", Internet 325 Draft draft-ietf-babel-rfc6126bis-02, May 2017. 327 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 328 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 329 2016. 331 6.2. Informative References 333 [BABEL-RTT] 334 Jonglez, B. and J. Chroboczek, "Delay-based Metric 335 Extension for the Babel Routing Protocol", draft-jonglez- 336 babel-rtt-extension-01 (work in progress), May 2015. 338 [BABEL-Z] Chroboczek, J., "Diversity Routing for the Babel Routing 339 Protocol", draft-chroboczek-babel-diversity-routing-01 340 (work in progress), February 2016. 342 [DELAY-BASED] 343 Jonglez, B. and J. Chroboczek, "A delay-based routing 344 metric", March 2014. 346 Available online from http://arxiv.org/abs/1403.3488 348 [RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code 349 (HMAC) Cryptographic Authentication", RFC 7298, July 2014. 351 [ToS-SPECIFIC] 352 Chouasne, G., "https://tools.ietf.org/id/draft-chouasne- 353 babel-tos-specific-00.xml", draft-chouasne-babel-tos- 354 specific-00 (work in progress), July 2017. 356 Author's Address 358 Juliusz Chroboczek 359 IRIF, University of Paris-Diderot 360 Case 7014 361 75205 Paris Cedex 13 362 France 364 Email: jch@irif.fr