<?xml version="1.0" encoding="utf-8" ?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<rfc ipr="trust200902"
     docName="draft-lemon-homenet-review-00"
     category="info">

  <?rfc toc="yes"?> <?rfc symrefs="yes"?> <?rfc autobreaks="yes"?>
  <?rfc tocindent="yes"?> <?rfc compact="yes"?> <?rfc subcompact="yes"?>

  <front>
    <title abbrev="Homenet Review">Homenet vs. the Market: Gap Analysis</title>

    <author initials="T" surname="Lemon" fullname="Ted Lemon">
      <organization>Nibbhaya Consulting</organization>
      <address>
        <postal>
          <street>P.O. Box 958</street>
          <city>Brattleboro</city>
          <region>Vermont</region>
          <country>United States of America</country>
          <code>05301</code>
        </postal>
        <email>mellon@fugue.com</email>
      </address>
    </author>

    <date year='2019' month='March' day='11'/>

    <abstract>
      <t>
		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.
      </t>
    </abstract>
  </front>

  <middle>

    <section anchor="intro" title="Introduction">
	  <t>
		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.
	  </t>
	  <t>
		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.
	  </t>
	  <t>
		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.
	  </t>
	  <t>
		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.
	  </t>
	  <t>
		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.
	  </t>
	  <t>
		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.
	  </t>
	  <t>
		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.
	  </t>
	  <t>
		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.
	  </t>
	  <t>
		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?
	  </t>
	</section>
	<section title="Finding the Gaps">
	  <t>
		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):

		<list style="symbols">
		  <t>Connectivity between hosts on the home network</t>
		  <t>Connectivity from hosts on the home network to hosts on the Internet (single egress)</t>
		  <t>Connectivity from hosts on the internet to hosts on the homenet network</t>
		  <t>Support for multi-homing (more than one egress)</t>
		  <t>Service discovery</t>
		  <t>Roaming between APs</t>
		  <t>IPv4 Connectivity within the home</t>
		  <t>IoT connectivity, specifically:
		  <list style="symbols">
			<t>Connectivity from hosts on IoT leaf networks to hosts on the internet</t>
			<t>Connectivity from hosts on the internet to hosts on IoT leaf networks</t>
			<t>Connectivity between hosts on the same IoT leaf network</t>
			<t>Connectivity between hosts on different IoT leaf networks within the same home</t>
			<t>Connectivity from hosts on the homenet to hosts on the IoT network</t>
			<t>Connectivity from hosts on the IoT network to hosts on the homenet</t>
		  </list>
		  </t>
		  <t>Isolation between hosts that shouldn't be communicating on the homenet</t>
		</list>
	  </t>

	  <t>
		If we consider each type of network, we can see how each of these applies.   In the sections
		below, we analyze each case.
	  </t>

	  <section title="Connectivity between hosts on the homenet">
		<t>
		  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:
		  <list style="hanging">
			<t hangText="Single NAT">specified</t>
			<t hangText="Multi-NATted">not specified</t>
			<t hangText="Flat layer 2">specified</t>
			<t hangText="Homenet">specified, but optional for v4</t>
		  </list>
		</t>
		<t>
		  For routing:
		  <list style="hanging">
			<t hangText="Single NAT">not needed</t>
			<t hangText="Multi-NATted">not specified, no workaround</t>
			<t hangText="Flat layer 2">not needed</t>
			<t hangText="Homenet">specified</t>
		  </list>
		</t>
	  </section>
	  <section title="Connectivity from hosts on the homenet to hosts on the internet (single egress)">
		<t>
		  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.
		  <list style="hanging">
			<t hangText="Single NAT">specified</t>
			<t hangText="Multi-NATted">specified</t>
			<t hangText="Flat layer 2">specified</t>
			<t hangText="Homenet">specified</t>
		  </list>
		</t>
	  </section>
	  <section title="Connectivity from hosts on the internet to hosts on the homenet">
		<t>
		  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.

		  <list style="hanging">
			<t hangText="Single NAT">PCP or manual</t>
			<t hangText="Multi-NATted">PCP or manual</t>
			<t hangText="Flat layer 2">PCP or manual</t>
			<t hangText="Homenet">Specified; optional for v4</t>
		  </list>
		</t>
	  </section>
	  <section title="Support for multi-homing (more than one egress)">
		<t>
		  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.
		  <list style="hanging">
			<t hangText="Single NAT">not likely</t>
			<t hangText="Multi-NATted">not likely</t>
			<t hangText="Flat layer 2">v6 only</t>
			<t hangText="Homenet">specified, optional for v4</t>
		  </list>
		</t>
	  </section>
	  <section title="Service discovery">
		<t>
		  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.
		  <list style="hanging">
			<t hangText="Single NAT">DNS-SD, UPnP</t>
			<t hangText="Multi-NATted">Not specified</t>
			<t hangText="Flat layer 2">DNS-SD, UPnP</t>
			<t hangText="Homenet">DNS-SD is specified, but UPnP isn't</t>
		  </list>
		</t>
	  </section>
	  <section title="Roaming between APs">
		<t>
		  <list style="hanging">
			<t hangText="Single NAT">Not specified, doesn't work</t>
			<t hangText="Multi-NATted">Not specified, doesn't work</t>
			<t hangText="Flat layer 2">Specified</t>
			<t hangText="Homenet">Specified, bad user experience</t>
		  </list>
		</t>
	  </section>
	  <section title="IPv4 Connectivity within the home">
		<t>
		  <list style="hanging">
			<t hangText="Single NAT">Specified</t>
			<t hangText="Multi-NATted">Specified</t>
			<t hangText="Flat layer 2">Specified</t>
			<t hangText="Homenet">Specified, optional</t>
		  </list>
		</t>
	  </section>
	  <section title="Connectivity from hosts on IoT leaf networks to hosts on the internet">
		<t>
		  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.
		  <list style="hanging">
			<t hangText="Single NAT">Double NAT</t>
			<t hangText="Multi-NATted">Triple NAT</t>
			<t hangText="Flat layer 2">Double NAT</t>
			<t hangText="Homenet">Specified (HNCP)</t>
		  </list>
		</t>
	  </section>
	  <section title="Connectivity from hosts on the Internet to hosts on IoT leaf networks">
		<t>
		  <list style="hanging">
			<t hangText="Single NAT">PCP</t>
			<t hangText="Multi-NATted">PCP</t>
			<t hangText="Flat layer 2">PCP</t>
			<t hangText="Homenet">specified (HNCP)</t>
		  </list>
		</t>
	  </section>
	  <section title="Connectivity between hosts on the same IoT leaf network">
		<t>
		  <list style="hanging">
			<t hangText="Single NAT">works</t>
			<t hangText="Multi-NATted">works</t>
			<t hangText="Flat layer 2">works</t>
			<t hangText="Homenet">works</t>
		  </list>
		</t>
	  </section>
	  <section title="Connectivity between hosts on different IoT leaf networks within the same home">
		<t>
		  <list style="hanging">
			<t hangText="Single NAT">not specified</t>
			<t hangText="Multi-NATted">not specified</t>
			<t hangText="Flat layer 2">not specified</t>
			<t hangText="Homenet">specified (HNCP)</t>
		  </list>
		</t>
	  </section>
	  <section title="Connectivity from hosts on the homenet to hosts on the IoT network">
		<t>
		  <list style="hanging">
			<t hangText="Single NAT">not specified</t>
			<t hangText="Multi-NATted">not specified</t>
			<t hangText="Flat layer 2">not specified</t>
			<t hangText="Homenet">specified (HNCP)</t>
		  </list>
		</t>
	  <section title="Connectivity from hosts on the IoT network to hosts on the homenet">
		<t>
		  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.
		  <list style="hanging">
			<t hangText="Single NAT">not specified</t>
			<t hangText="Multi-NATted">not specified</t>
			<t hangText="Flat layer 2">not specified</t>
			<t hangText="Homenet">specified (HNCP)</t>
		  </list>
		</t>
	  </section>
	  </section>
	  <section title="Isolation between hosts that shouldn't be communicating on the homenet">
		<t>
		  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.
		  <list style="hanging">
			<t hangText="Single NAT">not specified</t>
			<t hangText="Multi-NATted">not specified</t>
			<t hangText="Flat layer 2">not specified</t>
			<t hangText="Homenet">not specified</t>
		  </list>
		</t>
	  </section>
	</section>
	<section title="Themes">
	  <t>
		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.
	  </t>
	  <t>
		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.
	  </t>
	  <t>
		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.
	  </t>
	</section>
  </middle>
</rfc>
