| 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
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.
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 (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.
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 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?
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):
If we consider each type of network, we can see how each of these applies. In the sections below, we analyze each case.
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:
For routing:
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.
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.
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.
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.
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.
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.
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.
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.