idnits 2.17.1 draft-ietf-homenet-babel-profile-00.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 116: '...ntation of Babel MUST encapsulate Babe...' RFC 2119 keyword, line 128: '...ntation of Babel MUST implement the IP...' RFC 2119 keyword, line 134: '...ntation of Babel SHOULD implement the ...' RFC 2119 keyword, line 146: '...S suggest that this should be a MUST.]...' RFC 2119 keyword, line 148: '...ntation of Babel MUST implement source...' (16 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 8, 2016) is 2841 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 July 8, 2016 5 Expires: January 9, 2017 7 Homenet profile of the Babel routing protocol 8 draft-ietf-homenet-babel-profile-00 10 Abstract 12 This document defines the subset of the Babel routing protocol 13 [RFC6126] and its extensions that a Homenet router must implement. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on January 9, 2017. 32 Copyright Notice 34 Copyright (c) 2016 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. The Homenet profile of Babel . . . . . . . . . . . . . . . . 3 52 2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 53 2.2. Non-requirements . . . . . . . . . . . . . . . . . . . . 5 54 3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 55 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 4.1. Normative References . . . . . . . . . . . . . . . . . . 6 57 4.2. Informative References . . . . . . . . . . . . . . . . . 6 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 60 1. Introduction 62 The core of the Homenet protocol suite consists of HNCP [RFC7788], a 63 protocol used for flooding configuration information and assigning 64 prefixes to links, combined with the Babel routing protocol 65 [RFC6126]. Babel is an extensible, flexible and modular protocol: 66 minimal implementations of Babel have been demonstrated that consist 67 of a few hundred of lines of code, while the "large" implementation 68 includes support for a number of extensions and consists of over ten 69 thousand lines of C code. 71 This document defines the exact subset of the Babel protocol and its 72 extensions that is required by a conformant implementation of the 73 Homenet protocol suite. 75 1.1. Background 77 The Babel routing protocol and its extensions are defined in a number 78 of documents: 80 o The body of RFC 6126 [RFC6126] defines the core, unextended 81 protocol. It allows Babel's control data to be carried over 82 either link-local IPv6 or IPv4, and in either case allows 83 announcing both IPv4 and IPv6 routes. It leaves link cost 84 estimation, metric computation and route selection to the 85 implementation. Distinct implementations of core RFC 6126 Babel 86 will interoperate and maintain a set of loop-free forwarding 87 paths, but given conflicting metrics or route selection policies 88 may give rise to persistent oscillations. 90 o The informative Appendix A of RFC 6126 suggests a simple and easy 91 to implement algorithm for cost and metric computation that has 92 been found to work satisfactorily in a wide range of topologies. 94 o While RFC 6126 does not provide an algorithm for route selection, 95 its Section 3.6 suggests selecting the route with smallest metric 96 with some hysteresis applied. An algorithm that has been found to 97 work well in practice is described in Section III.E of 98 [DELAY-BASED]. 100 o The extension mechanism for Babel is defined in RFC 7557 101 [RFC7557]. 103 o Four RFCs and Internet-Drafts define optional extensions to Babel: 104 HMAC-based authentication [RFC7298], source-specific routing 105 [BABEL-SS], radio interference aware routing [BABEL-Z], and delay- 106 based routing [BABEL-RTT]. All of these extensions interoperate 107 with the core protocol as well as with each other. 109 2. The Homenet profile of Babel 111 2.1. Requirements 113 [Sentences within square brackets are editorial notes and are not 114 intended for publication.] 116 REQ1: a Homenet implementation of Babel MUST encapsulate Babel 117 control traffic in IPv6 packets sent to the IANA-assigned port 6696 118 and either the IANA-assigned multicast group ff02::1:6 or to a link- 119 local unicast address. 121 Rationale: since Babel is able to carry both IPv4 and IPv6 routes 122 over either IPv4 or IPv6, choosing the protocol used for carrying 123 control traffic is a matter of preference. Since IPv6 has some 124 features that make implementations somewhat simpler and more 125 reliable (notably link-local addresses), we require carrying 126 control data over IPv6. 128 REQ2: a Homenet implementation of Babel MUST implement the IPv6 129 subset of the protocol defined in the body of RFC 6126. 131 Rationale: support for IPv6 routing is an essential component of 132 the Homenet architecture. 134 REQ3: a Homenet implementation of Babel SHOULD implement the IPv4 135 subset of the protocol defined in the body of RFC 6126. Use of other 136 techniques for acquiring IPv4 connectivity (such as multiple layers 137 of NAT) is strongly discouraged. 139 Rationale: support for IPv4 will remain necessary for years to 140 come, and even in pure IPv6 deployments, including code for 141 supporting IPv4 has very little cost. Since HNCP makes it easy to 142 assign distinct IPv4 prefixes to the links in a network, it is not 143 necessary to resort to multiple layers of NAT, with all of its 144 problems. 146 [BS suggest that this should be a MUST.] 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 [There is no consensus about this requirement. A simpler solution 176 is to disable Babel on guest interfaces. MS suggests this might 177 be a SHOULD.] 179 [This needs expanding with an explanation of how HNCP is supposed 180 to signal the use of authentication.] 182 REQ6: a Homenet implementation of Babel MUST use metrics that are of 183 a similar magnitude to the values suggested in Appendix A of 184 RFC 6126. In particular, it SHOULD assign costs that are no less 185 than 256 to wireless links, and SHOULD assign costs between 32 and 186 196 to lossless wired links. 188 Rationale: if two implementations of Babel choose very different 189 values for link costs, combining routers from different vendors 190 will lead to sub-optimal routing. 192 REQ7: a Homenet implementation of Babel SHOULD distinguish between 193 wired and wireless links; if it is unable to determine whether a link 194 is wired or wireless, it SHOULD make the worst-case hypothesis that 195 the link is wireless. It SHOULD dynamically probe the quality of 196 wireless links and derive a suitable metric from its quality 197 estimation. The algorithm described in Appendix A of RFC 6126 MAY be 198 used. 200 Rationale: support for wireless transit links is a "killer 201 feature" of Homenet, something that is requested by our users and 202 easy to explain to our bosses. In the absence of dynamically 203 computed metrics, the routing protocol attempts to minimise the 204 number of links crossed by a route, and therefore prefers long, 205 lossy links to shorter, lossless ones. In wireless networks, 206 "hop-count routing is worst-path routing". 208 [This should probably be MUST, but it might be difficult or even 209 impossible to implement in some environments, especially in the 210 presence of wired-to-wireless bridges.] 212 2.2. Non-requirements 214 NR1: a Homenet implementation of Babel MAY perform route selection by 215 applying hysteresis to route metrics, as suggested in Section 3.6 of 216 RFC 6126 and described in detail in Section III.E of [BABEL-RTT]. 217 However, it MAY simply pick the route with the smallest metric. 219 Rationale: hysteresis is only useful in congested and highly 220 dynamic networks. In a typical home network, stable and 221 uncongested, the feedback loop that hysteresis compensates for 222 does not occur. 224 NR2: a Homenet implementation of Babel MAY include support for other 225 extensions to the protocol, as long as they are known to interoperate 226 with both the core protocol and source-specific routing. 228 Rationale: delay-based routing is useful in redundant meshes of 229 tunnels, which do not occur in typical home networks (which 230 typically use at most one VPN link). Interference-aware routing, 231 on the other hand, is likely to be useful in home networks, but 232 the extension requires further evaluation before it can be 233 recommended for widespread deployment. 235 3. Acknowledgments 237 4. References 239 4.1. Normative References 241 [BABEL-SS] 242 Boutier, M. and J. Chroboczek, "Source-Specific Routing in 243 Babel", draft-boutier-babel-source-specific-01 (work in 244 progress), January 2015. 246 [RFC6126] Chroboczek, J., "The Babel Routing Protocol", RFC 6126, 247 February 2011. 249 [RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code 250 (HMAC) Cryptographic Authentication", RFC 7298, July 2014. 252 [RFC7557] Chroboczek, J., "Extension Mechanism for the Babel Routing 253 Protocol", RFC 7557, May 2015. 255 4.2. Informative References 257 [BABEL-RTT] 258 Jonglez, B. and J. Chroboczek, "Delay-based Metric 259 Extension for the Babel Routing Protocol", draft-jonglez- 260 babel-rtt-extension-01 (work in progress), May 2015. 262 [BABEL-Z] Chroboczek, J., "Diversity Routing for the Babel Routing 263 Protocol", draft-chroboczek-babel-diversity-routing-01 264 (work in progress), February 2016. 266 [DELAY-BASED] 267 Jonglez, B. and J. Chroboczek, "A delay-based routing 268 metric", March 2014. 270 Available online from http://arxiv.org/abs/1403.3488 272 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 273 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 274 2016, . 276 Author's Address 277 Juliusz Chroboczek 278 IRIF, University of Paris-Diderot 279 Case 7014 280 75205 Paris Cedex 13 281 France 283 Email: jch@pps.univ-paris-diderot.fr