idnits 2.17.1 draft-ietf-homenet-babel-profile-01.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 a Security Considerations section. ** 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 ([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 118: '...ntation of Babel MUST encapsulate Babe...' RFC 2119 keyword, line 130: '...ntation of Babel MUST implement the IP...' RFC 2119 keyword, line 136: '...ntation of Babel SHOULD implement the ...' RFC 2119 keyword, line 148: '...ntation of Babel MUST implement source...' RFC 2119 keyword, line 150: '... specific [BABEL-SS]. This implies that it MUST implement the...' (19 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 2, 2016) is 2699 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 7298 (Obsoleted by RFC 8967) ** Obsolete normative reference: RFC 7557 (Obsoleted by RFC 8966) == Outdated reference: A later version (-02) exists of draft-jonglez-babel-rtt-extension-01 Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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 December 2, 2016 5 Expires: June 5, 2017 7 Homenet profile of the Babel routing protocol 8 draft-ietf-homenet-babel-profile-01 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 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 June 5, 2017. 33 Copyright Notice 35 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . 5 55 3. Interactions between HNCP and Babel . . . . . . . . . . . . . 5 56 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 6 57 3.2. Non-requirements . . . . . . . . . . . . . . . . . . . . 6 58 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 59 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 5.1. Normative References . . . . . . . . . . . . . . . . . . 7 61 5.2. Informative References . . . . . . . . . . . . . . . . . 7 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 64 1. Introduction 66 The core of the Homenet protocol suite consists of HNCP [RFC7788], a 67 protocol used for flooding configuration information and assigning 68 prefixes to links, combined with the Babel routing protocol 69 [RFC6126]. Babel is an extensible, flexible and modular protocol: 70 minimal implementations of Babel have been demonstrated that consist 71 of a few hundred of lines of code, while the "large" implementation 72 includes support for a number of extensions and consists of over ten 73 thousand lines of C code. 75 This document consists of two parts. The first specifies the exact 76 subset of the Babel protocol and its extensions that is required by 77 an implementation of the Homenet protocol suite. The second 78 specifies how HNCP interacts with Babel. 80 1.1. Background 82 The Babel routing protocol and its extensions are defined in a number 83 of documents: 85 o The body of RFC 6126 [RFC6126] defines the core, unextended 86 protocol. It allows Babel's control data to be carried over 87 either link-local IPv6 or IPv4, and in either case allows 88 announcing both IPv4 and IPv6 routes. It leaves link cost 89 estimation, metric computation and route selection to the 90 implementation. Distinct implementations of core RFC 6126 Babel 91 will interoperate and maintain a set of loop-free forwarding 92 paths, but given conflicting metrics or route selection policies 93 may give rise to persistent oscillations. 95 o The informative Appendix A of RFC 6126 suggests a simple and easy 96 to implement algorithm for cost and metric computation that has 97 been found to work satisfactorily in a wide range of topologies. 99 o While RFC 6126 does not provide an algorithm for route selection, 100 its Section 3.6 suggests selecting the route with smallest metric 101 with some hysteresis applied. An algorithm that has been found to 102 work well in practice is described in Section III.E of 103 [DELAY-BASED]. 105 o The extension mechanism for Babel is defined in RFC 7557 106 [RFC7557]. 108 o Four RFCs and Internet-Drafts define optional extensions to Babel: 109 HMAC-based authentication [RFC7298], source-specific routing 110 [BABEL-SS], radio interference aware routing [BABEL-Z], and delay- 111 based routing [BABEL-RTT]. All of these extensions interoperate 112 with the core protocol as well as with each other. 114 2. The Homenet profile of Babel 116 2.1. Requirements 118 REQ1: a Homenet implementation of Babel MUST encapsulate Babel 119 control traffic in IPv6 packets sent to the IANA-assigned port 6696 120 and either the IANA-assigned multicast group ff02::1:6 or to a link- 121 local unicast address. 123 Rationale: since Babel is able to carry both IPv4 and IPv6 routes 124 over either IPv4 or IPv6, choosing the protocol used for carrying 125 control traffic is a matter of preference. Since IPv6 has some 126 features that make implementations somewhat simpler and more 127 reliable (notably link-local addresses), we require carrying 128 control data over IPv6. 130 REQ2: a Homenet implementation of Babel MUST implement the IPv6 131 subset of the protocol defined in the body of RFC 6126. 133 Rationale: support for IPv6 routing is an essential component of 134 the Homenet architecture. 136 REQ3: a Homenet implementation of Babel SHOULD implement the IPv4 137 subset of the protocol defined in the body of RFC 6126. Use of other 138 techniques for acquiring IPv4 connectivity (such as multiple layers 139 of NAT) is strongly discouraged. 141 Rationale: support for IPv4 will remain necessary for years to 142 come, and even in pure IPv6 deployments, including code for 143 supporting IPv4 has very little cost. Since HNCP makes it easy to 144 assign distinct IPv4 prefixes to the links in a network, it is not 145 necessary to resort to multiple layers of NAT, with all of its 146 problems. 148 REQ4: a Homenet implementation of Babel MUST implement source- 149 specific routing for IPv6, as defined in draft-boutier-babel-source- 150 specific [BABEL-SS]. This implies that it MUST implement the 151 extension mechanism defined in RFC 7557. 153 Rationale: source-specific routing is an essential component of 154 the Homenet architecture. The extension mechanism is required by 155 source-specific routing. Source-specific routing for IPv4 is not 156 required, since HNCP arranges things so that a single non-specific 157 IPv4 default route is announced (Section 6.5 of [RFC7788]). 159 REQ5: a Homenet implementation of Babel MUST implement HMAC-based 160 authentication, as defined in RFC 7298, MUST implement the two 161 mandatory-to-implement algorithms defined in RFC 7298, and MUST 162 enable and require authentication when instructed to do so by HNCP. 164 Rationale: some home networks include "guest" links that can be 165 used by third parties that are not necessarily fully trusted. In 166 such networks, it is essential that either the routing protocol is 167 secured or the guest links are carefully firewalled. 169 Generic mechanisms such as DTLS and dynamically keyed IPsec are 170 not able to protect multicast traffic, and are therefore difficult 171 to use with Babel. Statically keyed IPsec, perhaps with keys 172 rotated by HNCP, is vulnerable to replay attacks and would 173 therefore require the addition of a nonce mechanism to Babel. 175 REQ6: a Homenet implementation of Babel MUST use metrics that are of 176 a similar magnitude to the values suggested in Appendix A of 177 RFC 6126. In particular, it SHOULD assign costs that are no less 178 than 256 to wireless links, and SHOULD assign costs between 32 and 179 196 to lossless wired links. 181 Rationale: if two implementations of Babel choose very different 182 values for link costs, combining routers from different vendors 183 will lead to sub-optimal routing. 185 REQ7: a Homenet implementation of Babel SHOULD distinguish between 186 wired and wireless links; if it is unable to determine whether a link 187 is wired or wireless, it SHOULD make the worst-case hypothesis that 188 the link is wireless. It SHOULD dynamically probe the quality of 189 wireless links and derive a suitable metric from its quality 190 estimation. The algorithm described in Appendix A of RFC 6126 MAY be 191 used. 193 Rationale: support for wireless transit links is a "killer 194 feature" of Homenet, something that is requested by our users and 195 easy to explain to our bosses. In the absence of dynamically 196 computed metrics, the routing protocol attempts to minimise the 197 number of links crossed by a route, and therefore prefers long, 198 lossy links to shorter, lossless ones. In wireless networks, 199 "hop-count routing is worst-path routing". 201 2.2. Non-requirements 203 NR1: a Homenet implementation of Babel MAY perform route selection by 204 applying hysteresis to route metrics, as suggested in Section 3.6 of 205 RFC 6126 and described in detail in Section III.E of [BABEL-RTT]. 206 However, it MAY simply pick the route with the smallest metric. 208 Rationale: hysteresis is only useful in congested and highly 209 dynamic networks. In a typical home network, stable and 210 uncongested, the feedback loop that hysteresis compensates for 211 does not occur. 213 NR2: a Homenet implementation of Babel MAY include support for other 214 extensions to the protocol, as long as they are known to interoperate 215 with both the core protocol and source-specific routing. 217 Rationale: delay-based routing is useful in redundant meshes of 218 tunnels, which do not occur in typical home networks (which 219 typically use at most one VPN link). Interference-aware routing, 220 on the other hand, is likely to be useful in home networks, but 221 the extension requires further evaluation before it can be 222 recommended for widespread deployment. 224 3. Interactions between HNCP and Babel 226 The Homenet architecture cleanly separates between configuration, 227 which is done by HNCP, and routing, which is done by Babel. While 228 the coupling between the two protocols is deliberately kept to a 229 minimum, some interactions are unavoidable. 231 All the interactions between HNCP and Babel consist of HNCP causing 232 Babel to perform an announcement on its behalf (in particular, under 233 no circumstances does Babel cause HNCP to perform an action). How 234 this is realised is an implementation detail that is outside the 235 scope of this document: while it could conceivably be done using a 236 private communication channel between HNCP and Babel, existing 237 implementations have HNCP install a route in the operating system's 238 kernel which is later picked up by Babel. 240 3.1. Requirements 242 REQ7: if an HNCP node receives a DHCPv6 prefix delegation for prefix 243 P and publishes an External-Connection TLV containing a Delegated- 244 Prefix TLV with prefix P and no Prefix-Policy TLV, then it MUST 245 announce a source-specific default route with source prefix P over 246 Babel. 248 Rationale: source-specific routes are the main tool that Homenet 249 uses to enable optimal routing in the presence of multiple IPv6 250 prefixes. External connections with non-trivial prefix policies 251 are explicitly excluded from this requirement, since their exact 252 behaviour is application-specific. 254 REQ8: if an HNCP node receives a DHCPv4 lease with an IPv4 address 255 and wins the election for NAT gateway, then it MUST act as a NAT 256 gateway and MUST announce a (non-specific) IPv4 default route over 257 Babel. 259 Rationale: the Homenet architecture does not use source-specific 260 routing for IPv4; instead, HNCP elects a single NAT gateway and 261 publishes a single default route towards that gateway (RFC 7788 262 Section 6.5). 264 REQ9: if an HNCP node assigns a prefix P to an attached link and 265 announces P in an Assigned-Prefix TLV, then it MUST announce a route 266 towards P over Babel. 268 Rationale: prefixes assigned to links must be routable within the 269 Homenet. 271 3.2. Non-requirements 273 NR3: an HNCP node that receives a DHCPv6 prefix delegation MAY 274 announce a non-specific IPv6 default route over Babel in addition to 275 the source-specific default route mandated by requirement REQ7. 277 Rationale: since the source-specific default route is more 278 specific than the non-specific default route, the former will 279 override the latter if all nodes implement source-specific 280 routing. Announcing an additional non-specific route is allowed, 281 since doing that causes no harm and might simplify operations in 282 some circumstances, e.g. when interoperating with a rougint 283 protocol that does not support source-specific routing. 285 NR4: an HNCP node that receives a DHCPv4 lease with an IPv4 address 286 and wins the election for NAT gateway SHOULD NOT announce a source- 287 specific IPv4 default route. 289 Homenet does not require support for IPv4 source-specific routing. 290 Announcing source-specific routes will not cause routing 291 pathologies (blackholes or routing loops), but it might cause 292 packets sourced in different parts of the Homenet to follow 293 different paths, with all the confusion that this entails. 295 4. Acknowledgments 297 5. References 299 5.1. Normative References 301 [BABEL-SS] 302 Boutier, M. and J. Chroboczek, "Source-Specific Routing in 303 Babel", draft-boutier-babel-source-specific-01 (work in 304 progress), January 2015. 306 [RFC6126] Chroboczek, J., "The Babel Routing Protocol", RFC 6126, 307 February 2011. 309 [RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code 310 (HMAC) Cryptographic Authentication", RFC 7298, July 2014. 312 [RFC7557] Chroboczek, J., "Extension Mechanism for the Babel Routing 313 Protocol", RFC 7557, May 2015. 315 5.2. Informative References 317 [BABEL-RTT] 318 Jonglez, B. and J. Chroboczek, "Delay-based Metric 319 Extension for the Babel Routing Protocol", draft-jonglez- 320 babel-rtt-extension-01 (work in progress), May 2015. 322 [BABEL-Z] Chroboczek, J., "Diversity Routing for the Babel Routing 323 Protocol", draft-chroboczek-babel-diversity-routing-01 324 (work in progress), February 2016. 326 [DELAY-BASED] 327 Jonglez, B. and J. Chroboczek, "A delay-based routing 328 metric", March 2014. 330 Available online from http://arxiv.org/abs/1403.3488 332 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 333 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 334 2016, . 336 Author's Address 338 Juliusz Chroboczek 339 IRIF, University of Paris-Diderot 340 Case 7014 341 75205 Paris Cedex 13 342 France 344 Email: jch@irif.fr