idnits 2.17.1 draft-lemon-homenet-review-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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 183 has weird spacing: '...-NATted not s...' == Line 185 has weird spacing: '...Homenet speci...' == Line 190 has weird spacing: '...-NATted not s...' == Line 192 has weird spacing: '...Homenet speci...' == Line 204 has weird spacing: '...-NATted speci...' == (14 more instances...) -- The document date (March 11, 2019) is 1866 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Lemon 3 Internet-Draft Nibbhaya Consulting 4 Intended status: Informational March 11, 2019 5 Expires: September 12, 2019 7 Homenet vs. the Market: Gap Analysis 8 draft-lemon-homenet-review-00 10 Abstract 12 This document discusses the homenet problem space and tries to 13 compare what we have both with what the market is now providing, and 14 also with what we need. 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 https://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 September 12, 2019. 33 Copyright Notice 35 Copyright (c) 2019 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 (https://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 2. Finding the Gaps . . . . . . . . . . . . . . . . . . . . . . 4 52 2.1. Connectivity between hosts on the homenet . . . . . . . . 4 53 2.2. Connectivity from hosts on the homenet to hosts on the 54 internet (single egress) . . . . . . . . . . . . . . . . 5 55 2.3. Connectivity from hosts on the internet to hosts on the 56 homenet . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 2.4. Support for multi-homing (more than one egress) . . . . . 5 58 2.5. Service discovery . . . . . . . . . . . . . . . . . . . . 6 59 2.6. Roaming between APs . . . . . . . . . . . . . . . . . . . 6 60 2.7. IPv4 Connectivity within the home . . . . . . . . . . . . 6 61 2.8. Connectivity from hosts on IoT leaf networks to hosts on 62 the internet . . . . . . . . . . . . . . . . . . . . . . 6 63 2.9. Connectivity from hosts on the Internet to hosts on IoT 64 leaf networks . . . . . . . . . . . . . . . . . . . . . . 7 65 2.10. Connectivity between hosts on the same IoT leaf network . 7 66 2.11. Connectivity between hosts on different IoT leaf networks 67 within the same home . . . . . . . . . . . . . . . . . . 7 68 2.12. Connectivity from hosts on the homenet to hosts on the 69 IoT network . . . . . . . . . . . . . . . . . . . . . . . 7 70 2.12.1. Connectivity from hosts on the IoT network to hosts 71 on the homenet . . . . . . . . . . . . . . . . . . . 7 72 2.13. Isolation between hosts that shouldn't be communicating 73 on the homenet . . . . . . . . . . . . . . . . . . . . . 8 74 3. Themes . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 77 1. Introduction 79 The Homenet working group has been developing a set of specifications 80 for some years with the goal of providing a self-configuring home 81 network with potentially multiple routers. Since Homenet began, the 82 market has changed significantly, and it is worth spending some time 83 looking at how it has changed and how that changes what, if anything, 84 the Homenet working group should be doing. 86 Homenet originally set out to provide for a multi-homed network with 87 a layer 3 routing topology that would isolate individual subnets in 88 the hope of better performance, while preserving end-to-end service 89 and allowing for service discovery throughout the home. 91 At the time, a typical home network either had a single router, or 92 several routers connected together with one or more layers of network 93 address translation. Each router provided an isolated "LAN" link, 94 connected to a "WAN" upstream. Service discovery was restricted to 95 individual LAN links. Some routers provided "air-to-air bridging" or 96 "Wi-Fi range extension" service. 98 In recent years, several competing technologies have shown up. 99 First, there are access points that provide a hub-and-spoke 100 infrastructure service. Each access point provides service, and 101 there is a single layer two with no layer three routing topology. 102 Either a single wired switch is used as an edge router, or one of the 103 access points acts as an edge router, bridging air-to-air to the 104 others. 106 A second technology that has gained market share is wifi mesh. 107 IEEE's 802.11s was not a success when it was initially introduced, 108 but private changes to 802.11s have allowed for deployment of layer 109 two mesh networks using Wi-Fi access points. This functions 110 similarly to infrastructure network, except that all traffic is sent 111 over the Wi-Fi mesh. As with Wi-Fi infrastructure routers, the 112 network appears to the host as a single layer two. 114 There are some significant advantages to the layer 2 approach. 115 First, it means that a host can roam from AP to AP without needing to 116 renumber. Second, at least in principle, service discovery can be 117 accomplished using multicast. Third, if there are multiple egress 118 routes, these can be presented to hosts using router advertisements, 119 allowing the hosts to choose between routes without any new protocol 120 infrastructure as is required by homenet. 122 What homenet provides is a layer three topology with a lot of new 123 protocol infrastructure. Roaming from one AP to another will always 124 result in renumbering, which means that the user experience will be 125 less than ideal. Service discovery is a solved problem at this 126 point, and in fact probably works better than multicast service 127 discovery on a large network. 129 However, by and large, homenets are a lot of work for not much 130 return. We don't have any field experience with them, so we don't 131 know what they look like in terms of customer support load, but it's 132 easy to conjecture that they will be orders of magnitude more 133 expensive to support than layer two mesh networks. 135 Looking at this from the perspective of the IETF, an SDO that deals 136 mostly with layer 3 and above, the question is, what value do we add, 137 or can we add? What should a home network look like? Is layer 2 138 actually the right solution? What gaps exist? 140 2. Finding the Gaps 142 If we look at the anatomy of a home network, there are some clear 143 problems that any home network needs to solve (or fails to solve): 145 o Connectivity between hosts on the home network 146 o Connectivity from hosts on the home network to hosts on the 147 Internet (single egress) 148 o Connectivity from hosts on the internet to hosts on the homenet 149 network 150 o Support for multi-homing (more than one egress) 151 o Service discovery 152 o Roaming between APs 153 o IPv4 Connectivity within the home 154 o IoT connectivity, specifically: 156 * Connectivity from hosts on IoT leaf networks to hosts on the 157 internet 158 * Connectivity from hosts on the internet to hosts on IoT leaf 159 networks 160 * Connectivity between hosts on the same IoT leaf network 161 * Connectivity between hosts on different IoT leaf networks 162 within the same home 163 * Connectivity from hosts on the homenet to hosts on the IoT 164 network 165 * Connectivity from hosts on the IoT network to hosts on the 166 homenet 167 o Isolation between hosts that shouldn't be communicating on the 168 homenet 170 If we consider each type of network, we can see how each of these 171 applies. In the sections below, we analyze each case. 173 2.1. Connectivity between hosts on the homenet 175 The problem here is twofold: there needs to be numbering, and there 176 needs to be routing. That is, every host on the homenet needs to 177 have a unique IP address, and every subnet has to be reachable--there 178 has to be a routing in both directions. Additionally, the numbering 179 has to be stable; if when the upstream ISP goes away, the prefix goes 180 away, that doesn't count. For the unique IP address: 182 Single NAT specified 183 Multi-NATted not specified 184 Flat layer 2 specified 185 Homenet specified, but optional for v4 187 For routing: 189 Single NAT not needed 190 Multi-NATted not specified, no workaround 191 Flat layer 2 not needed 192 Homenet specified 194 2.2. Connectivity from hosts on the homenet to hosts on the internet 195 (single egress) 197 In order for this to work, there just has to be a default route to 198 the internet. Since this is the most-needed use case, it's not 199 surprising that it works in all cases. "Specified" here is a bit 200 wrong for NAT, but the problem is sufficiently well-understood that 201 we can say there is a clear spec. 203 Single NAT specified 204 Multi-NATted specified 205 Flat layer 2 specified 206 Homenet specified 208 2.3. Connectivity from hosts on the internet to hosts on the homenet 210 This works in a variety of ways. If the host has a global IP address 211 and there is no firewall, or there is a hole in the firewall that was 212 set up manually or using PCP, then it's reachable. NATted hosts can 213 be reached if they are able to set up a port forward in the NAT 214 either manually or using PCP. Most home gateways will let you set up 215 a manual forward, but this is technically challenging. Support for 216 PCP is nearly nonexistent; in principle it's specified, and works 217 well, but in practice it's not available to most users. In all non- 218 NAT cases, IPv6 support works if it is supported on the router, but 219 only if there is no firewall, PCP is supported, or the user sets it 220 up manually. 222 Single NAT PCP or manual 223 Multi-NATted PCP or manual 224 Flat layer 2 PCP or manual 225 Homenet Specified; optional for v4 227 2.4. Support for multi-homing (more than one egress) 229 With NAT, multi-egress support is possible, but there is no standard 230 way of doing it, and this is not generally supported. Flat Layer 2 231 networks can support multi-homing with IPv6 simply by connecting more 232 than one egress router up to the layer 2 and having each one 233 advertise routes. For IPv4 it's just like the Single NAT case. 235 Single NAT not likely 236 Multi-NATted not likely 237 Flat layer 2 v6 only 238 Homenet specified, optional for v4 240 2.5. Service discovery 242 Service Discovery generally works on single links using multicast, so 243 whether it works depends on whether multicast works. Some routers 244 disable multicast because of its performance characteristics, 245 particularly in the flat layer 2 case. Ad hoc workarounds exist for 246 some use cases, and solutions are specified for homenet-like 247 environments. Service discovery protocols like UPnP work when 248 multicast works. While specifications do exist for multi-link UPnP, 249 it's a safe assumption that no home network routers implement them. 251 Single NAT DNS-SD, UPnP 252 Multi-NATted Not specified 253 Flat layer 2 DNS-SD, UPnP 254 Homenet DNS-SD is specified, but UPnP isn't 256 2.6. Roaming between APs 258 Single NAT Not specified, doesn't work 259 Multi-NATted Not specified, doesn't work 260 Flat layer 2 Specified 261 Homenet Specified, bad user experience 263 2.7. IPv4 Connectivity within the home 265 Single NAT Specified 266 Multi-NATted Specified 267 Flat layer 2 Specified 268 Homenet Specified, optional 270 2.8. Connectivity from hosts on IoT leaf networks to hosts on the 271 internet 273 In all of these cases, there is a specification for how an IoT 274 network can get routing using HNCP on a homenet, but as far as I know 275 there is no specification for an IoT gateway to translate from 276 compressed IP headers to regular IP headers. 278 Single NAT Double NAT 279 Multi-NATted Triple NAT 280 Flat layer 2 Double NAT 281 Homenet Specified (HNCP) 283 2.9. Connectivity from hosts on the Internet to hosts on IoT leaf 284 networks 286 Single NAT PCP 287 Multi-NATted PCP 288 Flat layer 2 PCP 289 Homenet specified (HNCP) 291 2.10. Connectivity between hosts on the same IoT leaf network 293 Single NAT works 294 Multi-NATted works 295 Flat layer 2 works 296 Homenet works 298 2.11. Connectivity between hosts on different IoT leaf networks within 299 the same home 301 Single NAT not specified 302 Multi-NATted not specified 303 Flat layer 2 not specified 304 Homenet specified (HNCP) 306 2.12. Connectivity from hosts on the homenet to hosts on the IoT 307 network 309 Single NAT not specified 310 Multi-NATted not specified 311 Flat layer 2 not specified 312 Homenet specified (HNCP) 314 2.12.1. Connectivity from hosts on the IoT network to hosts on the 315 homenet 317 In this case, it's possible for an IoT host to connect to a NAT host 318 if the IoT edge router does NAT, but in that case there is no 319 guarantee that there won't be an address conflict. 321 Single NAT not specified 322 Multi-NATted not specified 323 Flat layer 2 not specified 324 Homenet specified (HNCP) 326 2.13. Isolation between hosts that shouldn't be communicating on the 327 homenet 329 There are some devices that really shouldn't be able to connect to 330 everything on the network, and to which everything on the network 331 shouldn't be able to connect. This can be managed using MUD 332 profiles, at least in principle, but only if there is a way to 333 isolate the devices. It's common nowadays for people to set up 334 isolated IoT-only networks in the home, but this is of limited value, 335 and requires manual configuration. There is no reason in principle 336 why this type of isolation couldn't be done for homenets or for Flat 337 Layer 2 solutions. It can also be done in principle on legacy home 338 networks. But at present, how to do this automatically is an 339 unsolved or at best partially-solved problem. 341 Single NAT not specified 342 Multi-NATted not specified 343 Flat layer 2 not specified 344 Homenet not specified 346 3. Themes 348 One of the common themes here is that it's no surprise that Flat 349 Layer 2 networks are gaining in popularity. Things work better with 350 a flat layer 2 than with a multi-layer NAT, and even a single NAT is 351 too limited for a lot of use cases. 353 It seems to be the case that a lot of the work we have done in 354 Homenet is applicable to FL2 networks. HNCP and routing are useful 355 because they provide end-to-end connectivity to and between IoT leaf 356 networks. Even though an FL2 network can in principle support 357 multicast, the more L2 segments there are, the worse this scales. So 358 in practice, the solution's we've been working on for Homenet Naming 359 are likely applicable in the FL2 use case. 361 The bit about isolation of hosts may seem like a non-sequitur in this 362 analysis but I bring it up because I think it's applicable in two 363 ways. First, it's applicable to the multicast scaling problem. With 364 our DNS-SD solutions for homenet, we can specify a multicast-like 365 service discovery framework that works reliably, but doesn't spray 366 multicasts everywhere. And the problem of isolation of IoT nodes is 367 likely to be something that needs to be addressed; while it's not 368 specifically a homenet problem, my suspicion is that there is 369 interest here. 371 Author's Address 373 Ted Lemon 374 Nibbhaya Consulting 375 P.O. Box 958 376 Brattleboro, Vermont 05301 377 United States of America 379 Email: mellon@fugue.com