idnits 2.17.1 draft-ietf-homenet-babel-profile-06.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 (February 23, 2018) is 2253 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 February 23, 2018 5 Expires: August 27, 2018 7 Homenet profile of the Babel routing protocol 8 draft-ietf-homenet-babel-profile-06 10 Abstract 12 This document defines the subset of the Babel routing protocol and 13 its extensions that a Homenet router must implement, as well as the 14 interactions between the Home Networking Control Protocol (HNCP) and 15 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 August 27, 2018. 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. Non-requirements . . . . . . . . . . . . . . . . . . . . 5 57 3. Interactions between HNCP and Babel . . . . . . . . . . . . . 5 58 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 6 59 3.2. Non-requirements . . . . . . . . . . . . . . . . . . . . 6 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 62 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 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 RFC 89 2119 [RFC2119]. 91 1.2. Background 93 The Babel routing protocol and its extensions are defined in a number 94 of documents: 96 o RFC 6126bis [RFC6126bis] defines the Babel routing protocol. It 97 allows Babel's control data to be carried either over link-local 98 IPv6 or over IPv4, and in either case allows announcing both IPv4 99 and IPv6 routes. It leaves link cost estimation, metric 100 computation and route selection to the implementation. Distinct 101 implementations of RFC 6126bis Babel will interoperate, in the 102 sense that they will maintain a set of loop-free forwarding paths. 103 However, if they implement conflicting options, they might not be 104 able to exchange a full set of routes; in the worst case, an 105 implementation that only implements the IPv6 subset of the 106 protocol and an implementation that only implements the IPv4 107 subset of the protocol will not exchange any routes. In addition, 108 if implementations use conflicting route selection policies, 109 persistent oscillations might occur. 111 o The informative Appendix A of RFC 6126bis suggests a simple and 112 easy to implement algorithm for cost and metric computation that 113 has been found to work satisfactorily in a wide range of 114 topologies. 116 o While RFC 6126bis does not provide an algorithm for route 117 selection, its Section 3.6 suggests selecting the route with 118 smallest metric with some hysteresis applied. An algorithm that 119 has been found to work well in practice is described in 120 Section III.E of [DELAY-BASED]. 122 o Five RFCs and Internet-Drafts define optional extensions to Babel: 123 HMAC-based authentication [RFC7298], source-specific routing 124 [BABEL-SS], delay-based routing [BABEL-RTT] and ToS-specific 125 routing [ToS-SPECIFIC]. All of these extensions interoperate with 126 the core protocol as well as with each other. 128 2. The Homenet profile of Babel 130 2.1. Requirements 132 REQ1: a Homenet implementation of Babel MUST encapsulate Babel 133 control traffic in IPv6 packets sent to the IANA-assigned port 6696 134 and either the IANA-assigned multicast group ff02::1:6 or to a link- 135 local unicast address. 137 Rationale: since Babel is able to carry both IPv4 and IPv6 routes 138 over either IPv4 or IPv6, choosing the protocol used for carrying 139 control traffic is a matter of preference. Since IPv6 has some 140 features that make implementations somewhat simpler and more 141 reliable (notably link-local addresses), we require carrying 142 control data over IPv6. 144 REQ2: a Homenet implementation of Babel MUST implement the IPv6 145 subset of the protocol defined in the body of RFC 6126bis. 147 Rationale: support for IPv6 routing is an essential component of 148 the Homenet architecture. 150 REQ3: a Homenet implementation of Babel SHOULD implement the IPv4 151 subset of the protocol defined in the body of RFC 6126bis. Use of 152 other techniques for acquiring IPv4 connectivity (such as multiple 153 layers of NAT) is strongly discouraged. 155 Rationale: support for IPv4 will likely remain necessary for years 156 to come, and even in pure IPv6 deployments, including code for 157 supporting IPv4 has very little cost. Since HNCP makes it easy to 158 assign distinct IPv4 prefixes to the links in a network, it is not 159 necessary to resort to multiple layers of NAT, with all of its 160 problems. 162 REQ4: a Homenet implementation of Babel MUST implement source- 163 specific routing for IPv6, as defined in draft-ietf-babel-source- 164 specific [BABEL-SS]. 166 Rationale: source-specific routing is an essential component of 167 the Homenet architecture. Source-specific routing for IPv4 is not 168 required, since HNCP arranges things so that a single non-specific 169 IPv4 default route is announced (Section 6.5 of [RFC7788]). 171 REQ5: a Homenet implementation of Babel MUST use metrics that are of 172 a similar magnitude to the values suggested in Appendix A of 173 RFC 6126bis. In particular, it SHOULD assign costs that are no less 174 than 256 to wireless links, and SHOULD assign costs between 32 and 175 196 to lossless wired links. 177 Rationale: if two implementations of Babel choose very different 178 values for link costs, combining routers from different vendors 179 will cause sub-optimal routing. 181 REQ6: a Homenet implementation of Babel SHOULD distinguish between 182 wired and wireless links; if it is unable to determine whether a link 183 is wired or wireless, it SHOULD make the worst-case hypothesis that 184 the link is wireless. It SHOULD dynamically probe the quality of 185 wireless links and derive a suitable metric from its quality 186 estimation. The algorithm described in Appendix A of RFC 6126bis MAY 187 be used. 189 Rationale: support for wireless transit links is a distinguishing 190 feature of Homenet, and one that is requested by our users. In 191 the absence of dynamically computed metrics, the routing protocol 192 attempts to minimise the number of links crossed by a route, and 193 therefore prefers long, lossy links to shorter, lossless ones. In 194 wireless networks, "hop-count routing is worst-path routing". 196 While it would be desirable to perform link-quality probing on 197 some wired link technologies, notably power-line networks, these 198 kinds of links tend to be difficult or impossible to detect 199 automatically, and we are not aware of any published link-quality 200 algorithms for them. Hence, we do not require link-quality 201 estimation for wired links of any kind. 203 2.2. Non-requirements 205 NR1: a Homenet implementation of Babel MAY perform route selection by 206 applying hysteresis to route metrics, as suggested in Section 3.6 of 207 RFC 6126bis and described in detail in Section III.E of [BABEL-RTT]. 208 However, it MAY simply pick the route with the smallest metric. 210 Rationale: hysteresis is only useful in congested and highly 211 dynamic networks. In a typical home network, stable and 212 uncongested, the feedback loop that hysteresis compensates for 213 does not occur. 215 NR2: a Homenet implementation of Babel MAY include support for other 216 extensions to the protocol, as long as they are known to interoperate 217 with both the core protocol and source-specific routing. 219 Rationale: a number of extensions to the Babel routing protocol 220 have been defined over the years; however, they are useful in 221 fairly specific situations, such as routing over global-scale 222 overlay networks [BABEL-RTT] or multi-hop wireless networks with 223 multiple radio frequencies [BABEL-Z]. Hence, with the exception 224 of source-specific routing, no extensions are required for 225 Homenet. 227 3. Interactions between HNCP and Babel 229 The Homenet architecture cleanly separates between configuration, 230 which is done by HNCP, and routing, which is done by Babel. While 231 the coupling between the two protocols is deliberately kept to a 232 minimum, some interactions are unavoidable. 234 All the interactions between HNCP and Babel consist of HNCP causing 235 Babel to perform an announcement on its behalf (under no 236 circumstances does Babel cause HNCP to perform an action). How this 237 is realised is an implementation detail that is outside the scope of 238 this document; while it could conceivably be done using a private 239 communication channel between HNCP and Babel, in existing 240 implementations HNCP installs a route in the operating system's 241 kernel which is later picked up by Babel using the existing 242 redistribution mechanisms. 244 3.1. Requirements 246 REQ7: if an HNCP node receives a DHCPv6 prefix delegation for prefix 247 P and publishes an External-Connection TLV containing a Delegated- 248 Prefix TLV with prefix P and no Prefix-Policy TLV, then it MUST 249 announce a source-specific default route with source prefix P over 250 Babel. 252 Rationale: source-specific routes are the main tool that Homenet 253 uses to enable optimal routing in the presence of multiple IPv6 254 prefixes. External connections with non-trivial prefix policies 255 are explicitly excluded from this requirement, since their exact 256 behaviour is application-specific. 258 REQ8: if an HNCP node receives a DHCPv4 lease with an IPv4 address 259 and wins the election for NAT gateway, then it MUST act as a NAT 260 gateway and MUST announce a (non-specific) IPv4 default route over 261 Babel. 263 Rationale: the Homenet stack does not use source-specific routing 264 for IPv4; instead, HNCP elects a single NAT gateway and publishes 265 a single default route towards that gateway ([RFC7788] 266 Section 6.5). 268 REQ9: if an HNCP node assigns a prefix P to an attached link and 269 announces P in an Assigned-Prefix TLV, then it MUST announce a route 270 towards P over Babel. 272 Rationale: prefixes assigned to links must be routable within the 273 Homenet. 275 3.2. Non-requirements 277 NR3: an HNCP node that receives a DHCPv6 prefix delegation MAY 278 announce a non-specific IPv6 default route over Babel in addition to 279 the source-specific default route mandated by requirement REQ7. 281 Rationale: since the source-specific default route is more 282 specific than the non-specific default route, the former will 283 override the latter if all nodes implement source-specific 284 routing. Announcing an additional non-specific route is allowed, 285 since doing that causes no harm and might simplify operations in 286 some circumstances, e.g. when interoperating with a routing 287 protocol that does not support source-specific routing. 289 NR4: an HNCP node that receives a DHCPv4 lease with an IPv4 address 290 and wins the election for NAT gateway SHOULD NOT announce a source- 291 specific IPv4 default route. 293 Homenet does not require support for IPv4 source-specific routing. 294 Announcing IPv4 source-specific routes will not cause routing 295 pathologies (blackholes or routing loops), but it might cause 296 packets sourced in different parts of the Homenet to follow 297 different paths, with all the confusion that this entails. 299 4. Security Considerations 301 Both HNCP and Babel carry their control data in IPv6 packets with a 302 link-local source address, and implementations are required to drop 303 packets sent from a global address. Hence, they are only susceptible 304 to attacks from a directly connected link on which the HNCP and Babel 305 implementations are listening. 307 The security of a Homenet network relies on having a set of 308 "Internal", "Ad Hoc" and "Hybrid" interfaces (Section 5.1 of 309 [RFC7788]) that are assumed to be connected to links that are secured 310 at a lower layer. HNCP and Babel packets are only accepted when they 311 originate on these trusted links. "External" and "Guest" interfaces 312 are connected to links that are not trusted, and any HNCP or Babel 313 packets that are received on such interfaces are ignored. ("Leaf" 314 interfaces are a special case, since they are connected to trusted 315 links but HNCP and Babel traffic received on such interfaces is 316 ignored.) This implies that the security of a Homenet network 317 depends on the reliability of the border discovery procedure 318 described in Section 5.3 of [RFC7788]. 320 If untrusted links are used for transit, which is NOT RECOMMENDED, 321 then any HNCP and Babel traffic that is carried over such links MUST 322 be secured using an upper-layer security protocol. While both HNCP 323 and Babel support cryptographic authentication, at the time of 324 writing no protocol for autonomous configuration of HNCP and Babel 325 security has been defined. 327 5. IANA Considerations 329 This document requires no actions from IANA. 331 6. Acknowledgments 333 A number of people have helped with defining the requirements listed 334 in this document. I am especially indebted to Barbara Stark and 335 Markus Stenberg. 337 7. References 339 7.1. Normative References 341 [BABEL-SS] 342 Boutier, M. and J. Chroboczek, "Source-Specific Routing in 343 Babel", draft-ietf-babel-source-specific-03 (work in 344 progress), August 2018. 346 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 347 Requirement Levels", BCP 14, RFC 2119, 348 DOI 10.17487/RFC2119, March 1997. 350 [RFC6126bis] 351 Chroboczek, J. and D. Schinazi, "The Babel Routing 352 Protocol", Internet Draft draft-ietf-babel-rfc6126bis-04, 353 October 2017. 355 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 356 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 357 2016. 359 7.2. Informative References 361 [BABEL-RTT] 362 Jonglez, B. and J. Chroboczek, "Delay-based Metric 363 Extension for the Babel Routing Protocol", draft-jonglez- 364 babel-rtt-extension-01 (work in progress), May 2015. 366 [BABEL-Z] Chroboczek, J., "Diversity Routing for the Babel Routing 367 Protocol", draft-chroboczek-babel-diversity-routing-01 368 (work in progress), February 2016. 370 [DELAY-BASED] 371 Jonglez, B. and J. Chroboczek, "A delay-based routing 372 metric", March 2014. 374 Available online from http://arxiv.org/abs/1403.3488 376 [RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code 377 (HMAC) Cryptographic Authentication", RFC 7298, July 2014. 379 [ToS-SPECIFIC] 380 Chouasne, G., "https://tools.ietf.org/id/ 381 draft-chouasne-babel-tos-specific-00.xml", draft-chouasne- 382 babel-tos-specific-00 (work in progress), July 2017. 384 Author's Address 386 Juliusz Chroboczek 387 IRIF, University of Paris-Diderot 388 Case 7014 389 75205 Paris Cedex 13 390 France 392 Email: jch@irif.fr