idnits 2.17.1 draft-ietf-homenet-babel-profile-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 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 122: '...ntation of Babel MUST encapsulate Babe...' RFC 2119 keyword, line 134: '...ntation of Babel MUST implement the IP...' RFC 2119 keyword, line 140: '...ntation of Babel SHOULD implement the ...' RFC 2119 keyword, line 152: '...ntation of Babel MUST implement source...' RFC 2119 keyword, line 161: '...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 (January 3, 2018) is 2305 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) == 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-04 == 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: Standards Track January 3, 2018 5 Expires: July 7, 2018 7 Homenet profile of the Babel routing protocol 8 draft-ietf-homenet-babel-profile-04 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 July 7, 2018. 33 Copyright Notice 35 Copyright (c) 2018 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 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 6126bis Babel will interoperate, in the 92 sense 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 6126bis suggests a simple and 102 easy to implement algorithm for cost and metric computation that 103 has been found to work satisfactorily in a wide range of 104 topologies. 106 o While RFC 6126bis does not provide an algorithm for route 107 selection, its Section 3.6 suggests selecting the route with 108 smallest metric with some hysteresis applied. An algorithm that 109 has been found to work well in practice is described in 110 Section III.E of [DELAY-BASED]. 112 o Five RFCs and Internet-Drafts define optional extensions to Babel: 113 HMAC-based authentication [RFC7298], source-specific routing 114 [BABEL-SS], delay-based routing [BABEL-RTT] and ToS-specific 115 routing [ToS-SPECIFIC]. All of these extensions interoperate with 116 the core protocol as well as with each other. 118 2. The Homenet profile of Babel 120 2.1. Requirements 122 REQ1: a Homenet implementation of Babel MUST encapsulate Babel 123 control traffic in IPv6 packets sent to the IANA-assigned port 6696 124 and either the IANA-assigned multicast group ff02::1:6 or to a link- 125 local unicast address. 127 Rationale: since Babel is able to carry both IPv4 and IPv6 routes 128 over either IPv4 or IPv6, choosing the protocol used for carrying 129 control traffic is a matter of preference. Since IPv6 has some 130 features that make implementations somewhat simpler and more 131 reliable (notably link-local addresses), we require carrying 132 control data over IPv6. 134 REQ2: a Homenet implementation of Babel MUST implement the IPv6 135 subset of the protocol defined in the body of RFC 6126bis. 137 Rationale: support for IPv6 routing is an essential component of 138 the Homenet architecture. 140 REQ3: a Homenet implementation of Babel SHOULD implement the IPv4 141 subset of the protocol defined in the body of RFC 6126bis. Use of 142 other techniques for acquiring IPv4 connectivity (such as multiple 143 layers of NAT) is strongly discouraged. 145 Rationale: support for IPv4 will likely remain necessary for years 146 to come, and even in pure IPv6 deployments, including code for 147 supporting IPv4 has very little cost. Since HNCP makes it easy to 148 assign distinct IPv4 prefixes to the links in a network, it is not 149 necessary to resort to multiple layers of NAT, with all of its 150 problems. 152 REQ4: a Homenet implementation of Babel MUST implement source- 153 specific routing for IPv6, as defined in draft-ietf-babel-source- 154 specific [BABEL-SS]. 156 Rationale: source-specific routing is an essential component of 157 the Homenet architecture. Source-specific routing for IPv4 is not 158 required, since HNCP arranges things so that a single non-specific 159 IPv4 default route is announced (Section 6.5 of [RFC7788]). 161 REQ5: a Homenet implementation of Babel MUST use metrics that are of 162 a similar magnitude to the values suggested in Appendix A of 163 RFC 6126bis. In particular, it SHOULD assign costs that are no less 164 than 256 to wireless links, and SHOULD assign costs between 32 and 165 196 to lossless wired links. 167 Rationale: if two implementations of Babel choose very different 168 values for link costs, combining routers from different vendors 169 will cause sub-optimal routing. 171 REQ6: a Homenet implementation of Babel SHOULD distinguish between 172 wired and wireless links; if it is unable to determine whether a link 173 is wired or wireless, it SHOULD make the worst-case hypothesis that 174 the link is wireless. It SHOULD dynamically probe the quality of 175 wireless links and derive a suitable metric from its quality 176 estimation. The algorithm described in Appendix A of RFC 6126bis MAY 177 be used. 179 Rationale: support for wireless transit links is a "killer 180 feature" of Homenet, something that is requested by our users and 181 easy to explain to our bosses. In the absence of dynamically 182 computed metrics, the routing protocol attempts to minimise the 183 number of links crossed by a route, and therefore prefers long, 184 lossy links to shorter, lossless ones. In wireless networks, 185 "hop-count routing is worst-path routing". 187 2.2. Non-requirements 189 NR1: a Homenet implementation of Babel MAY perform route selection by 190 applying hysteresis to route metrics, as suggested in Section 3.6 of 191 RFC 6126bis and described in detail in Section III.E of [BABEL-RTT]. 192 However, it MAY simply pick the route with the smallest metric. 194 Rationale: hysteresis is only useful in congested and highly 195 dynamic networks. In a typical home network, stable and 196 uncongested, the feedback loop that hysteresis compensates for 197 does not occur. 199 NR2: a Homenet implementation of Babel MAY include support for other 200 extensions to the protocol, as long as they are known to interoperate 201 with both the core protocol and source-specific routing. 203 Rationale: a number of extensions to the Babel routing protocol 204 have been defined over the years; however, they are useful in 205 fairly specific situations, such as routing over global-scale 206 overlay networks [BABEL-RTT] or multi-hop wireless networks with 207 multiple radio frequencies [BABEL-Z]. Hence, with the exception 208 of source-specific routing, no extensions are required for 209 Homenet. 211 3. Interactions between HNCP and Babel 213 The Homenet architecture cleanly separates between configuration, 214 which is done by HNCP, and routing, which is done by Babel. While 215 the coupling between the two protocols is deliberately kept to a 216 minimum, some interactions are unavoidable. 218 All the interactions between HNCP and Babel consist of HNCP causing 219 Babel to perform an announcement on its behalf (under no 220 circumstances does Babel cause HNCP to perform an action). How this 221 is realised is an implementation detail that is outside the scope of 222 this document; while it could conceivably be done using a private 223 communication channel between HNCP and Babel, in existing 224 implementations HNCP installs a route in the operating system's 225 kernel which is later picked up by Babel using the existing 226 redistribution mechanisms. 228 3.1. Requirements 230 REQ7: if an HNCP node receives a DHCPv6 prefix delegation for prefix 231 P and publishes an External-Connection TLV containing a Delegated- 232 Prefix TLV with prefix P and no Prefix-Policy TLV, then it MUST 233 announce a source-specific default route with source prefix P over 234 Babel. 236 Rationale: source-specific routes are the main tool that Homenet 237 uses to enable optimal routing in the presence of multiple IPv6 238 prefixes. External connections with non-trivial prefix policies 239 are explicitly excluded from this requirement, since their exact 240 behaviour is application-specific. 242 REQ8: if an HNCP node receives a DHCPv4 lease with an IPv4 address 243 and wins the election for NAT gateway, then it MUST act as a NAT 244 gateway and MUST announce a (non-specific) IPv4 default route over 245 Babel. 247 Rationale: the Homenet architecture does not use source-specific 248 routing for IPv4; instead, HNCP elects a single NAT gateway and 249 publishes a single default route towards that gateway ([RFC7788] 250 Section 6.5). 252 REQ9: if an HNCP node assigns a prefix P to an attached link and 253 announces P in an Assigned-Prefix TLV, then it MUST announce a route 254 towards P over Babel. 256 Rationale: prefixes assigned to links must be routable within the 257 Homenet. 259 3.2. Non-requirements 261 NR3: an HNCP node that receives a DHCPv6 prefix delegation MAY 262 announce a non-specific IPv6 default route over Babel in addition to 263 the source-specific default route mandated by requirement REQ7. 265 Rationale: since the source-specific default route is more 266 specific than the non-specific default route, the former will 267 override the latter if all nodes implement source-specific 268 routing. Announcing an additional non-specific route is allowed, 269 since doing that causes no harm and might simplify operations in 270 some circumstances, e.g. when interoperating with a routing 271 protocol that does not support source-specific routing. 273 NR4: an HNCP node that receives a DHCPv4 lease with an IPv4 address 274 and wins the election for NAT gateway SHOULD NOT announce a source- 275 specific IPv4 default route. 277 Homenet does not require support for IPv4 source-specific routing. 278 Announcing IPv4 source-specific routes will not cause routing 279 pathologies (blackholes or routing loops), but it might cause 280 packets sourced in different parts of the Homenet to follow 281 different paths, with all the confusion that this entails. 283 4. Security Considerations 285 Both HNCP and Babel carry their control data in IPv6 packets with a 286 link-local source address, and implementations are required to drop 287 packets sent from a global address. Hence, they are only susceptible 288 to attacks from a directly connected link on which the HNCP and Babel 289 implementations are listening. 291 The security of a Homenet network relies on having a set of 292 "Internal" and "Ad Hoc" interfaces (Section 5.1 of [RFC7788]) that 293 are assumed to be connected to links that are secured at a lower 294 layer. HNCP and Babel packets are only accepted when they originate 295 on these trusted links. "External" and "Guest" interfaces are 296 connected to links that are not trusted, and any HNCP or Babel 297 packets that are received on such interfaces are ignored. ("Leaf" 298 interfaces are a special case, since they are connected to trusted 299 links but HNCP and Babel traffic received on such interfaces is 300 ignored.) 302 If untrusted links are used for transit, which is NOT RECOMMENDED, 303 then any HNCP and Babel traffic that is carried over such links MUST 304 be secured using an upper-layer security protocol. While both HNCP 305 and Babel support cryptographic authentication, at the time of 306 writing no protocol for autonomous configuration of HNCP and Babel 307 security has been defined. 309 5. Acknowledgments 311 A number of people have helped with defining the requirements listed 312 in this document. I am especially indebted to Barbara Stark, Markus 313 Stenberg, and Stephen Farrell. 315 6. References 317 6.1. Normative References 319 [BABEL-SS] 320 Boutier, M. and J. Chroboczek, "Source-Specific Routing in 321 Babel", draft-ietf-babel-source-specific-01 (work in 322 progress), August 2017. 324 [RFC6126bis] 325 Chroboczek, J. and D. Schinazi, "The Babel Routing 326 Protocol", Internet Draft draft-ietf-babel-rfc6126bis-04, 327 October 2017. 329 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 330 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 331 2016. 333 6.2. Informative References 335 [BABEL-RTT] 336 Jonglez, B. and J. Chroboczek, "Delay-based Metric 337 Extension for the Babel Routing Protocol", draft-jonglez- 338 babel-rtt-extension-01 (work in progress), May 2015. 340 [BABEL-Z] Chroboczek, J., "Diversity Routing for the Babel Routing 341 Protocol", draft-chroboczek-babel-diversity-routing-01 342 (work in progress), February 2016. 344 [DELAY-BASED] 345 Jonglez, B. and J. Chroboczek, "A delay-based routing 346 metric", March 2014. 348 Available online from http://arxiv.org/abs/1403.3488 350 [RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code 351 (HMAC) Cryptographic Authentication", RFC 7298, July 2014. 353 [ToS-SPECIFIC] 354 Chouasne, G., "https://tools.ietf.org/id/draft-chouasne- 355 babel-tos-specific-00.xml", draft-chouasne-babel-tos- 356 specific-00 (work in progress), July 2017. 358 Author's Address 360 Juliusz Chroboczek 361 IRIF, University of Paris-Diderot 362 Case 7014 363 75205 Paris Cedex 13 364 France 366 Email: jch@irif.fr