Network Working Group T. Lemon Internet-Draft Nibbhaya Consulting Intended status: Informational March 11, 2019 Expires: September 12, 2019 Homenet vs. the Market: Gap Analysis draft-lemon-homenet-review-00 Abstract This document discusses the homenet problem space and tries to compare what we have both with what the market is now providing, and also with what we need. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 12, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Lemon Expires September 12, 2019 [Page 1] Internet-Draft Homenet Review March 2019 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Finding the Gaps . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Connectivity between hosts on the homenet . . . . . . . . 4 2.2. Connectivity from hosts on the homenet to hosts on the internet (single egress) . . . . . . . . . . . . . . . . 5 2.3. Connectivity from hosts on the internet to hosts on the homenet . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Support for multi-homing (more than one egress) . . . . . 5 2.5. Service discovery . . . . . . . . . . . . . . . . . . . . 6 2.6. Roaming between APs . . . . . . . . . . . . . . . . . . . 6 2.7. IPv4 Connectivity within the home . . . . . . . . . . . . 6 2.8. Connectivity from hosts on IoT leaf networks to hosts on the internet . . . . . . . . . . . . . . . . . . . . . . 6 2.9. Connectivity from hosts on the Internet to hosts on IoT leaf networks . . . . . . . . . . . . . . . . . . . . . . 7 2.10. Connectivity between hosts on the same IoT leaf network . 7 2.11. Connectivity between hosts on different IoT leaf networks within the same home . . . . . . . . . . . . . . . . . . 7 2.12. Connectivity from hosts on the homenet to hosts on the IoT network . . . . . . . . . . . . . . . . . . . . . . . 7 2.12.1. Connectivity from hosts on the IoT network to hosts on the homenet . . . . . . . . . . . . . . . . . . . 7 2.13. Isolation between hosts that shouldn't be communicating on the homenet . . . . . . . . . . . . . . . . . . . . . 8 3. Themes . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction The Homenet working group has been developing a set of specifications for some years with the goal of providing a self-configuring home network with potentially multiple routers. Since Homenet began, the market has changed significantly, and it is worth spending some time looking at how it has changed and how that changes what, if anything, the Homenet working group should be doing. Homenet originally set out to provide for a multi-homed network with a layer 3 routing topology that would isolate individual subnets in the hope of better performance, while preserving end-to-end service and allowing for service discovery throughout the home. At the time, a typical home network either had a single router, or several routers connected together with one or more layers of network address translation. Each router provided an isolated "LAN" link, connected to a "WAN" upstream. Service discovery was restricted to Lemon Expires September 12, 2019 [Page 2] Internet-Draft Homenet Review March 2019 individual LAN links. Some routers provided "air-to-air bridging" or "Wi-Fi range extension" service. In recent years, several competing technologies have shown up. First, there are access points that provide a hub-and-spoke infrastructure service. Each access point provides service, and there is a single layer two with no layer three routing topology. Either a single wired switch is used as an edge router, or one of the access points acts as an edge router, bridging air-to-air to the others. A second technology that has gained market share is wifi mesh. IEEE's 802.11s was not a success when it was initially introduced, but private changes to 802.11s have allowed for deployment of layer two mesh networks using Wi-Fi access points. This functions similarly to infrastructure network, except that all traffic is sent over the Wi-Fi mesh. As with Wi-Fi infrastructure routers, the network appears to the host as a single layer two. There are some significant advantages to the layer 2 approach. First, it means that a host can roam from AP to AP without needing to renumber. Second, at least in principle, service discovery can be accomplished using multicast. Third, if there are multiple egress routes, these can be presented to hosts using router advertisements, allowing the hosts to choose between routes without any new protocol infrastructure as is required by homenet. What homenet provides is a layer three topology with a lot of new protocol infrastructure. Roaming from one AP to another will always result in renumbering, which means that the user experience will be less than ideal. Service discovery is a solved problem at this point, and in fact probably works better than multicast service discovery on a large network. However, by and large, homenets are a lot of work for not much return. We don't have any field experience with them, so we don't know what they look like in terms of customer support load, but it's easy to conjecture that they will be orders of magnitude more expensive to support than layer two mesh networks. Looking at this from the perspective of the IETF, an SDO that deals mostly with layer 3 and above, the question is, what value do we add, or can we add? What should a home network look like? Is layer 2 actually the right solution? What gaps exist? Lemon Expires September 12, 2019 [Page 3] Internet-Draft Homenet Review March 2019 2. Finding the Gaps If we look at the anatomy of a home network, there are some clear problems that any home network needs to solve (or fails to solve): o Connectivity between hosts on the home network o Connectivity from hosts on the home network to hosts on the Internet (single egress) o Connectivity from hosts on the internet to hosts on the homenet network o Support for multi-homing (more than one egress) o Service discovery o Roaming between APs o IPv4 Connectivity within the home o IoT connectivity, specifically: * Connectivity from hosts on IoT leaf networks to hosts on the internet * Connectivity from hosts on the internet to hosts on IoT leaf networks * Connectivity between hosts on the same IoT leaf network * Connectivity between hosts on different IoT leaf networks within the same home * Connectivity from hosts on the homenet to hosts on the IoT network * Connectivity from hosts on the IoT network to hosts on the homenet o Isolation between hosts that shouldn't be communicating on the homenet If we consider each type of network, we can see how each of these applies. In the sections below, we analyze each case. 2.1. Connectivity between hosts on the homenet The problem here is twofold: there needs to be numbering, and there needs to be routing. That is, every host on the homenet needs to have a unique IP address, and every subnet has to be reachable--there has to be a routing in both directions. Additionally, the numbering has to be stable; if when the upstream ISP goes away, the prefix goes away, that doesn't count. For the unique IP address: Single NAT specified Multi-NATted not specified Flat layer 2 specified Homenet specified, but optional for v4 For routing: Lemon Expires September 12, 2019 [Page 4] Internet-Draft Homenet Review March 2019 Single NAT not needed Multi-NATted not specified, no workaround Flat layer 2 not needed Homenet specified 2.2. Connectivity from hosts on the homenet to hosts on the internet (single egress) In order for this to work, there just has to be a default route to the internet. Since this is the most-needed use case, it's not surprising that it works in all cases. "Specified" here is a bit wrong for NAT, but the problem is sufficiently well-understood that we can say there is a clear spec. Single NAT specified Multi-NATted specified Flat layer 2 specified Homenet specified 2.3. Connectivity from hosts on the internet to hosts on the homenet This works in a variety of ways. If the host has a global IP address and there is no firewall, or there is a hole in the firewall that was set up manually or using PCP, then it's reachable. NATted hosts can be reached if they are able to set up a port forward in the NAT either manually or using PCP. Most home gateways will let you set up a manual forward, but this is technically challenging. Support for PCP is nearly nonexistent; in principle it's specified, and works well, but in practice it's not available to most users. In all non- NAT cases, IPv6 support works if it is supported on the router, but only if there is no firewall, PCP is supported, or the user sets it up manually. Single NAT PCP or manual Multi-NATted PCP or manual Flat layer 2 PCP or manual Homenet Specified; optional for v4 2.4. Support for multi-homing (more than one egress) With NAT, multi-egress support is possible, but there is no standard way of doing it, and this is not generally supported. Flat Layer 2 networks can support multi-homing with IPv6 simply by connecting more than one egress router up to the layer 2 and having each one advertise routes. For IPv4 it's just like the Single NAT case. Single NAT not likely Multi-NATted not likely Lemon Expires September 12, 2019 [Page 5] Internet-Draft Homenet Review March 2019 Flat layer 2 v6 only Homenet specified, optional for v4 2.5. Service discovery Service Discovery generally works on single links using multicast, so whether it works depends on whether multicast works. Some routers disable multicast because of its performance characteristics, particularly in the flat layer 2 case. Ad hoc workarounds exist for some use cases, and solutions are specified for homenet-like environments. Service discovery protocols like UPnP work when multicast works. While specifications do exist for multi-link UPnP, it's a safe assumption that no home network routers implement them. Single NAT DNS-SD, UPnP Multi-NATted Not specified Flat layer 2 DNS-SD, UPnP Homenet DNS-SD is specified, but UPnP isn't 2.6. Roaming between APs Single NAT Not specified, doesn't work Multi-NATted Not specified, doesn't work Flat layer 2 Specified Homenet Specified, bad user experience 2.7. IPv4 Connectivity within the home Single NAT Specified Multi-NATted Specified Flat layer 2 Specified Homenet Specified, optional 2.8. Connectivity from hosts on IoT leaf networks to hosts on the internet In all of these cases, there is a specification for how an IoT network can get routing using HNCP on a homenet, but as far as I know there is no specification for an IoT gateway to translate from compressed IP headers to regular IP headers. Single NAT Double NAT Multi-NATted Triple NAT Flat layer 2 Double NAT Homenet Specified (HNCP) Lemon Expires September 12, 2019 [Page 6] Internet-Draft Homenet Review March 2019 2.9. Connectivity from hosts on the Internet to hosts on IoT leaf networks Single NAT PCP Multi-NATted PCP Flat layer 2 PCP Homenet specified (HNCP) 2.10. Connectivity between hosts on the same IoT leaf network Single NAT works Multi-NATted works Flat layer 2 works Homenet works 2.11. Connectivity between hosts on different IoT leaf networks within the same home Single NAT not specified Multi-NATted not specified Flat layer 2 not specified Homenet specified (HNCP) 2.12. Connectivity from hosts on the homenet to hosts on the IoT network Single NAT not specified Multi-NATted not specified Flat layer 2 not specified Homenet specified (HNCP) 2.12.1. Connectivity from hosts on the IoT network to hosts on the homenet In this case, it's possible for an IoT host to connect to a NAT host if the IoT edge router does NAT, but in that case there is no guarantee that there won't be an address conflict. Single NAT not specified Multi-NATted not specified Flat layer 2 not specified Homenet specified (HNCP) Lemon Expires September 12, 2019 [Page 7] Internet-Draft Homenet Review March 2019 2.13. Isolation between hosts that shouldn't be communicating on the homenet There are some devices that really shouldn't be able to connect to everything on the network, and to which everything on the network shouldn't be able to connect. This can be managed using MUD profiles, at least in principle, but only if there is a way to isolate the devices. It's common nowadays for people to set up isolated IoT-only networks in the home, but this is of limited value, and requires manual configuration. There is no reason in principle why this type of isolation couldn't be done for homenets or for Flat Layer 2 solutions. It can also be done in principle on legacy home networks. But at present, how to do this automatically is an unsolved or at best partially-solved problem. Single NAT not specified Multi-NATted not specified Flat layer 2 not specified Homenet not specified 3. Themes One of the common themes here is that it's no surprise that Flat Layer 2 networks are gaining in popularity. Things work better with a flat layer 2 than with a multi-layer NAT, and even a single NAT is too limited for a lot of use cases. It seems to be the case that a lot of the work we have done in Homenet is applicable to FL2 networks. HNCP and routing are useful because they provide end-to-end connectivity to and between IoT leaf networks. Even though an FL2 network can in principle support multicast, the more L2 segments there are, the worse this scales. So in practice, the solution's we've been working on for Homenet Naming are likely applicable in the FL2 use case. The bit about isolation of hosts may seem like a non-sequitur in this analysis but I bring it up because I think it's applicable in two ways. First, it's applicable to the multicast scaling problem. With our DNS-SD solutions for homenet, we can specify a multicast-like service discovery framework that works reliably, but doesn't spray multicasts everywhere. And the problem of isolation of IoT nodes is likely to be something that needs to be addressed; while it's not specifically a homenet problem, my suspicion is that there is interest here. Lemon Expires September 12, 2019 [Page 8] Internet-Draft Homenet Review March 2019 Author's Address Ted Lemon Nibbhaya Consulting P.O. Box 958 Brattleboro, Vermont 05301 United States of America Email: mellon@fugue.com Lemon Expires September 12, 2019 [Page 9]