idnits 2.17.1 draft-ietf-homenet-babel-profile-07.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 18, 2018) is 2106 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-03 == 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: 0 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 July 18, 2018 5 Expires: January 19, 2019 7 Homenet profile of the Babel routing protocol 8 draft-ietf-homenet-babel-profile-07 10 Abstract 12 This document defines the exact subset of the Babel routing protocol 13 and its extensions that is required by an implementation of the 14 Homenet protocol suite, as well as the interactions between the Home 15 Networking Control Protocol (HNCP) and Babel. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 19, 2019. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Requirement Language . . . . . . . . . . . . . . . . . . 2 53 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. The Homenet profile of Babel . . . . . . . . . . . . . . . . 3 55 2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 56 2.2. Optional features . . . . . . . . . . . . . . . . . . . . 5 57 3. Interactions between HNCP and Babel . . . . . . . . . . . . . 5 58 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 6 59 3.2. Optional features . . . . . . . . . . . . . . . . . . . . 6 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 62 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 65 7.2. Informative References . . . . . . . . . . . . . . . . . 8 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 68 1. Introduction 70 The core of the Homenet protocol suite consists of the Home 71 Networking Control Protocol (HNCP) [RFC7788], a protocol used for 72 flooding configuration information and assigning prefixes to links, 73 combined with the Babel routing protocol [RFC6126bis]. Babel is an 74 extensible, flexible and modular protocol: minimal implementations of 75 Babel have been demonstrated that consist of a few hundred lines of 76 code, while the "large" implementation includes support for a number 77 of extensions and consists of over ten thousand lines of C code. 79 This document consists of two parts. The first specifies the exact 80 subset of the Babel protocol and its extensions that is required by 81 an implementation of the Homenet protocol suite. The second 82 specifies how HNCP interacts with Babel. 84 1.1. Requirement Language 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 88 "OPTIONAL" in this document are to be interpreted as described in BCP 89 14 [RFC2119] [RFC8174] when, and only when, they appear in all 90 capitals, as shown here. 92 1.2. Background 94 The Babel routing protocol and its extensions are defined in a number 95 of documents: 97 o RFC 6126bis [RFC6126bis] defines the Babel routing protocol. It 98 allows Babel's control data to be carried either over link-local 99 IPv6 or over IPv4, and in either case allows announcing both IPv4 100 and IPv6 routes. It leaves link cost estimation, metric 101 computation and route selection to the implementation. Distinct 102 implementations of RFC 6126bis Babel will interoperate, in the 103 sense that they will maintain a set of loop-free forwarding paths. 104 However, if they implement conflicting options, they might not be 105 able to exchange a full set of routes; in the worst case, an 106 implementation that only implements the IPv6 subset of the 107 protocol and an implementation that only implements the IPv4 108 subset of the protocol will not exchange any routes. In addition, 109 if implementations use conflicting route selection policies, 110 persistent oscillations might occur. 112 o The informative Appendix A of RFC 6126bis suggests a simple and 113 easy to implement algorithm for cost and metric computation that 114 has been found to work satisfactorily in a wide range of 115 topologies. 117 o While RFC 6126bis does not provide an algorithm for route 118 selection, its Section 3.6 suggests selecting the route with 119 smallest metric with some hysteresis applied. An algorithm that 120 has been found to work well in practice is described in 121 Section III.E of [DELAY-BASED]. 123 o Five RFCs and Internet-Drafts define optional extensions to Babel: 124 HMAC-based authentication [RFC7298], source-specific routing 125 [BABEL-SS], delay-based routing [BABEL-RTT] and ToS-specific 126 routing [ToS-SPECIFIC]. All of these extensions interoperate with 127 the core protocol as well as with each other. 129 2. The Homenet profile of Babel 131 2.1. Requirements 133 REQ1: a Homenet implementation of Babel MUST encapsulate Babel 134 control traffic in IPv6 packets sent to the IANA-assigned port 6696 135 and either the IANA-assigned multicast group ff02::1:6 or to a link- 136 local unicast address. 138 Rationale: since Babel is able to carry both IPv4 and IPv6 routes 139 over either IPv4 or IPv6, choosing the protocol used for carrying 140 control traffic is a matter of preference. Since IPv6 has some 141 features that make implementations somewhat simpler and more 142 reliable (notably properly scoped and reasonably stable link-local 143 addresses), we require carrying control data over IPv6. 145 REQ2: a Homenet implementation of Babel MUST implement the IPv6 146 subset of the protocol defined in the body of RFC 6126bis. 148 Rationale: support for IPv6 routing is an essential component of 149 the Homenet architecture. 151 REQ3: a Homenet implementation of Babel SHOULD implement the IPv4 152 subset of the protocol defined in the body of RFC 6126bis. Use of 153 other techniques for acquiring IPv4 connectivity (such as multiple 154 layers of NAT) is strongly discouraged. 156 Rationale: support for IPv4 will likely remain necessary for years 157 to come, and even in pure IPv6 deployments, including code for 158 supporting IPv4 has very little cost. Since HNCP makes it easy to 159 assign distinct IPv4 prefixes to the links in a network, it is not 160 necessary to resort to multiple layers of NAT, with all of its 161 problems. 163 REQ4: a Homenet implementation of Babel MUST implement source- 164 specific routing for IPv6, as defined in draft-ietf-babel-source- 165 specific [BABEL-SS]. 167 Rationale: source-specific routing is an essential component of 168 the Homenet architecture. Source-specific routing for IPv4 is not 169 required, since HNCP arranges things so that a single non-specific 170 IPv4 default route is announced (Section 6.5 of [RFC7788]). 172 REQ5: a Homenet implementation of Babel must use metrics that are of 173 a similar magnitude to the values suggested in Appendix A of 174 RFC 6126bis. In particular, it SHOULD assign costs that are no less 175 than 256 to wireless links, and SHOULD assign costs between 32 and 176 196 to lossless wired links. 178 Rationale: if two implementations of Babel choose very different 179 values for link costs, combining routers from different vendors 180 will cause sub-optimal routing. 182 REQ6: a Homenet implementation of Babel SHOULD distinguish between 183 wired and wireless links; if it is unable to determine whether a link 184 is wired or wireless, it SHOULD make the worst-case hypothesis that 185 the link is wireless. It SHOULD dynamically probe the quality of 186 wireless links and derive a suitable metric from its quality 187 estimation. Appendix A of RFC 6126bis gives an example of a suitable 188 algorithm. 190 Rationale: support for wireless transit links is a distinguishing 191 feature of Homenet, and one that is requested by our users. In 192 the absence of dynamically computed metrics, the routing protocol 193 attempts to minimise the number of links crossed by a route, and 194 therefore prefers long, lossy links to shorter, lossless ones. In 195 wireless networks, "hop-count routing is worst-path routing". 197 While it would be desirable to perform link-quality probing on 198 some wired link technologies, notably power-line networks, these 199 kinds of links tend to be difficult or impossible to detect 200 automatically, and we are not aware of any published link-quality 201 algorithms for them. Hence, we do not require link-quality 202 estimation for wired links of any kind. 204 2.2. Optional features 206 OPT1: a Homenet implementation of Babel MAY perform route selection 207 by applying hysteresis to route metrics, as suggested in Section 3.6 208 of RFC 6126bis and described in detail in Section III.E of 209 [BABEL-RTT]. However, hysteresis is not required, and the 210 implementation may simply pick the route with the smallest metric. 212 Rationale: hysteresis is only useful in congested and highly 213 dynamic networks. In a typical home network, stable and 214 uncongested, the feedback loop that hysteresis compensates for 215 does not occur. 217 OPT2: a Homenet implementation of Babel may include support for other 218 extensions to the protocol, as long as they are known to interoperate 219 with both the core protocol and source-specific routing. 221 Rationale: a number of extensions to the Babel routing protocol 222 have been defined over the years; however, they are useful in 223 fairly specific situations, such as routing over global-scale 224 overlay networks [BABEL-RTT] or multi-hop wireless networks with 225 multiple radio frequencies [BABEL-Z]. Hence, with the exception 226 of source-specific routing, no extensions are required for 227 Homenet. 229 3. Interactions between HNCP and Babel 231 The Homenet architecture cleanly separates configuration, which is 232 done by HNCP, from routing, which is done by Babel. While the 233 coupling between the two protocols is deliberately kept to a minimum, 234 some interactions are unavoidable. 236 All the interactions between HNCP and Babel consist of HNCP causing 237 Babel to perform an announcement on its behalf (under no 238 circumstances does Babel cause HNCP to perform an action). How this 239 is realised is an implementation detail that is outside the scope of 240 this document; while it could conceivably be done using a private 241 communication channel between HNCP and Babel, in existing 242 implementations HNCP installs a route in the operating system's 243 kernel which is later picked up by Babel using the existing 244 redistribution mechanisms. 246 3.1. Requirements 248 REQ7: if an HNCP node receives a DHCPv6 prefix delegation for prefix 249 P and publishes an External-Connection TLV containing a Delegated- 250 Prefix TLV with prefix P and no Prefix-Policy TLV, then it MUST 251 announce a source-specific default route with source prefix P over 252 Babel. 254 Rationale: source-specific routes are the main tool that Homenet 255 uses to enable optimal routing in the presence of multiple IPv6 256 prefixes. External connections with non-trivial prefix policies 257 are explicitly excluded from this requirement, since their exact 258 behaviour is application-specific. 260 REQ8: if an HNCP node receives a DHCPv4 lease with an IPv4 address 261 and wins the election for NAT gateway, then it MUST act as a NAT 262 gateway and MUST announce a (non-specific) IPv4 default route over 263 Babel. 265 Rationale: the Homenet stack does not use source-specific routing 266 for IPv4; instead, HNCP elects a single NAT gateway and publishes 267 a single default route towards that gateway ([RFC7788] 268 Section 6.5). 270 REQ9: if an HNCP node assigns a prefix P to an attached link and 271 announces P in an Assigned-Prefix TLV, then it MUST announce a route 272 towards P over Babel. 274 Rationale: prefixes assigned to links must be routable within the 275 Homenet. 277 3.2. Optional features 279 OPT3: an HNCP node that receives a DHCPv6 prefix delegation MAY 280 announce a non-specific IPv6 default route over Babel in addition to 281 the source-specific default route mandated by requirement REQ7. 283 Rationale: since the source-specific default route is more 284 specific than the non-specific default route, the former will 285 override the latter if all nodes implement source-specific 286 routing. Announcing an additional non-specific route is allowed, 287 since doing that causes no harm and might simplify operations in 288 some circumstances, e.g. when interoperating with a routing 289 protocol that does not support source-specific routing. 291 OPT4: an HNCP node that receives a DHCPv4 lease with an IPv4 address 292 and wins the election for NAT gateway SHOULD NOT announce a source- 293 specific IPv4 default route. 295 Homenet does not require support for IPv4 source-specific routing. 296 Announcing IPv4 source-specific routes will not cause routing 297 pathologies (blackholes or routing loops), but it might cause 298 packets sourced in different parts of the Homenet to follow 299 different paths, with all the confusion that this entails. 301 4. Security Considerations 303 Both HNCP and Babel carry their control data in IPv6 packets with a 304 link-local source address, and implementations are required to drop 305 packets sent from a global address. Hence, they are only susceptible 306 to attacks from a directly connected link on which the HNCP and Babel 307 implementations are listening. 309 The security of a Homenet network relies on having a set of 310 "Internal", "Ad Hoc" and "Hybrid" interfaces (Section 5.1 of 311 [RFC7788]) that are assumed to be connected to links that are secured 312 at a lower layer. HNCP and Babel packets are only accepted when they 313 originate on these trusted links. "External" and "Guest" interfaces 314 are connected to links that are not trusted, and any HNCP or Babel 315 packets that are received on such interfaces are ignored. ("Leaf" 316 interfaces are a special case, since they are connected to trusted 317 links but HNCP and Babel traffic received on such interfaces is 318 ignored.) This implies that the security of a Homenet network 319 depends on the reliability of the border discovery procedure 320 described in Section 5.3 of [RFC7788]. 322 If untrusted links are used for transit, which is NOT RECOMMENDED, 323 then any HNCP and Babel traffic that is carried over such links MUST 324 be secured using an upper-layer security protocol. While both HNCP 325 and Babel support cryptographic authentication, at the time of 326 writing no protocol for autonomous configuration of HNCP and Babel 327 security has been defined. 329 5. IANA Considerations 331 This document requires no actions from IANA. 333 6. Acknowledgments 335 A number of people have helped with defining the requirements listed 336 in this document. I am especially indebted to Barbara Stark and 337 Markus Stenberg. 339 7. References 341 7.1. Normative References 343 [BABEL-SS] 344 Boutier, M. and J. Chroboczek, "Source-Specific Routing in 345 Babel", draft-ietf-babel-source-specific-03 (work in 346 progress), August 2018. 348 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 349 Requirement Levels", BCP 14, RFC 2119, 350 DOI 10.17487/RFC2119, March 1997. 352 [RFC6126bis] 353 Chroboczek, J. and D. Schinazi, "The Babel Routing 354 Protocol", Internet Draft draft-ietf-babel-rfc6126bis-04, 355 October 2017. 357 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 358 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 359 2016. 361 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 362 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 363 May 2017. 365 7.2. Informative References 367 [BABEL-RTT] 368 Jonglez, B. and J. Chroboczek, "Delay-based Metric 369 Extension for the Babel Routing Protocol", draft-jonglez- 370 babel-rtt-extension-01 (work in progress), May 2015. 372 [BABEL-Z] Chroboczek, J., "Diversity Routing for the Babel Routing 373 Protocol", draft-chroboczek-babel-diversity-routing-01 374 (work in progress), February 2016. 376 [DELAY-BASED] 377 Jonglez, B. and J. Chroboczek, "A delay-based routing 378 metric", March 2014. 380 Available online from http://arxiv.org/abs/1403.3488 382 [RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code 383 (HMAC) Cryptographic Authentication", RFC 7298, July 2014. 385 [ToS-SPECIFIC] 386 Chouasne, G., "https://tools.ietf.org/id/ 387 draft-chouasne-babel-tos-specific-00.xml", draft-chouasne- 388 babel-tos-specific-00 (work in progress), July 2017. 390 Author's Address 392 Juliusz Chroboczek 393 IRIF, University of Paris-Diderot 394 Case 7014 395 75205 Paris Cedex 13 396 France 398 Email: jch@irif.fr