idnits 2.17.1 draft-ietf-homenet-babel-profile-02.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], [RFC6126]), 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 119: '...ntation of Babel MUST encapsulate Babe...' RFC 2119 keyword, line 131: '...ntation of Babel MUST implement the IP...' RFC 2119 keyword, line 137: '...ntation of Babel SHOULD implement the ...' RFC 2119 keyword, line 149: '...ntation of Babel MUST implement source...' RFC 2119 keyword, line 151: '... specific [BABEL-SS]. This implies that it MUST implement the...' (18 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 3, 2017) is 2483 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-boutier-babel-source-specific-01 ** Obsolete normative reference: RFC 6126 (Obsoleted by RFC 8966) ** Obsolete normative reference: RFC 7557 (Obsoleted by RFC 8966) == 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: 5 errors (**), 0 flaws (~~), 3 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 July 3, 2017 5 Expires: January 4, 2018 7 Homenet profile of the Babel routing protocol 8 draft-ietf-homenet-babel-profile-02 10 Abstract 12 This document defines the subset of the Babel routing protocol 13 [RFC6126] and its extensions that a Homenet router must implement, as 14 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 January 4, 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 [RFC6126]. 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 The body of RFC 6126 [RFC6126] defines the core, unextended 87 protocol. It allows Babel's control data to be carried over 88 either link-local IPv6 or IPv4, and in either case allows 89 announcing both IPv4 and IPv6 routes. It leaves link cost 90 estimation, metric computation and route selection to the 91 implementation. Distinct implementations of core RFC 6126 Babel 92 will interoperate and maintain a set of loop-free forwarding 93 paths, but given conflicting metrics or route selection policies 94 may give rise to persistent oscillations. 96 o The informative Appendix A of RFC 6126 suggests a simple and easy 97 to implement algorithm for cost and metric computation that has 98 been found to work satisfactorily in a wide range of topologies. 100 o While RFC 6126 does not provide an algorithm for route selection, 101 its Section 3.6 suggests selecting the route with smallest metric 102 with some hysteresis applied. An algorithm that has been found to 103 work well in practice is described in Section III.E of 104 [DELAY-BASED]. 106 o The extension mechanism for Babel is defined in RFC 7557 107 [RFC7557]. 109 o Four RFCs and Internet-Drafts define optional extensions to Babel: 110 HMAC-based authentication [RFC7298], source-specific routing 111 [BABEL-SS], radio interference aware routing [BABEL-Z], and delay- 112 based routing [BABEL-RTT]. All of these extensions interoperate 113 with the core protocol as well as with each other. 115 2. The Homenet profile of Babel 117 2.1. Requirements 119 REQ1: a Homenet implementation of Babel MUST encapsulate Babel 120 control traffic in IPv6 packets sent to the IANA-assigned port 6696 121 and either the IANA-assigned multicast group ff02::1:6 or to a link- 122 local unicast address. 124 Rationale: since Babel is able to carry both IPv4 and IPv6 routes 125 over either IPv4 or IPv6, choosing the protocol used for carrying 126 control traffic is a matter of preference. Since IPv6 has some 127 features that make implementations somewhat simpler and more 128 reliable (notably link-local addresses), we require carrying 129 control data over IPv6. 131 REQ2: a Homenet implementation of Babel MUST implement the IPv6 132 subset of the protocol defined in the body of RFC 6126. 134 Rationale: support for IPv6 routing is an essential component of 135 the Homenet architecture. 137 REQ3: a Homenet implementation of Babel SHOULD implement the IPv4 138 subset of the protocol defined in the body of RFC 6126. Use of other 139 techniques for acquiring IPv4 connectivity (such as multiple layers 140 of NAT) is strongly discouraged. 142 Rationale: support for IPv4 will remain necessary for years to 143 come, and even in pure IPv6 deployments, including code for 144 supporting IPv4 has very little cost. Since HNCP makes it easy to 145 assign distinct IPv4 prefixes to the links in a network, it is not 146 necessary to resort to multiple layers of NAT, with all of its 147 problems. 149 REQ4: a Homenet implementation of Babel MUST implement source- 150 specific routing for IPv6, as defined in draft-boutier-babel-source- 151 specific [BABEL-SS]. This implies that it MUST implement the 152 extension mechanism defined in RFC 7557. 154 Rationale: source-specific routing is an essential component of 155 the Homenet architecture. The extension mechanism is required by 156 source-specific routing. 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 (in particular, under 219 no circumstances does Babel cause HNCP to perform an action). How 220 this is realised is an implementation detail that is outside the 221 scope of this document: while it could conceivably be done using a 222 private communication channel between HNCP and Babel, existing 223 implementations have HNCP install 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 7788 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 trusted 291 "internal" links that are secured at a lower layer (either physically 292 or at the link layer); HNCP and Babel packets are only accepted when 293 they originate on these trusted links (see Section 5 of [RFC7788]). 294 External, leaf and guest links are not trusted, and any HNCP or Babel 295 packets that are received on such links are ignored. 297 If untrusted links are used for transit, which is NOT RECOMMENDED, 298 and therefore need to carry HNCP and Babel traffic, then HNCP and 299 Babel MUST be secured using an upper-layer security protocol. While 300 both HNCP and Babel support cryptographic authentication, at the time 301 of writing no protocol for autonomous configuration of HNCP and Babel 302 security has been defined. 304 5. Acknowledgments 306 A number of people have helped with definining the requirements 307 listed in this document. I am especially indebted to Markus Stenberg 308 for his help. 310 6. References 312 6.1. Normative References 314 [BABEL-SS] 315 Boutier, M. and J. Chroboczek, "Source-Specific Routing in 316 Babel", draft-boutier-babel-source-specific-01 (work in 317 progress), January 2015. 319 [RFC6126] Chroboczek, J., "The Babel Routing Protocol", RFC 6126, 320 February 2011. 322 [RFC7557] Chroboczek, J., "Extension Mechanism for the Babel Routing 323 Protocol", RFC 7557, May 2015. 325 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 326 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 327 2016. 329 6.2. Informative References 331 [BABEL-RTT] 332 Jonglez, B. and J. Chroboczek, "Delay-based Metric 333 Extension for the Babel Routing Protocol", draft-jonglez- 334 babel-rtt-extension-01 (work in progress), May 2015. 336 [BABEL-Z] Chroboczek, J., "Diversity Routing for the Babel Routing 337 Protocol", draft-chroboczek-babel-diversity-routing-01 338 (work in progress), February 2016. 340 [DELAY-BASED] 341 Jonglez, B. and J. Chroboczek, "A delay-based routing 342 metric", March 2014. 344 Available online from http://arxiv.org/abs/1403.3488 346 [RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code 347 (HMAC) Cryptographic Authentication", RFC 7298, July 2014. 349 Author's Address 351 Juliusz Chroboczek 352 IRIF, University of Paris-Diderot 353 Case 7014 354 75205 Paris Cedex 13 355 France 357 Email: jch@irif.fr