Home / Blogs

The Future of Home Networking: A Problem Statement

I’m a network engineer, and like many engineers I often gravitate to the big projects; large networks with problems of scale and complexity in my case. However, I also consider myself a student of Occam’s razor and often quote Antoine de Saint-Exupéry: “perfection is reached not when there is nothing left to add, but when there is nothing left to take away.” In this spirit of “less is more” I have recently become intrigued by the problems appearing in home networking.

Up till now home networks have been fairly simple; a single home router and one LAN. A single WAN IP address, DHCP RFC 1918 space in the LAN, and NAT on the home router. If the user needed extra Ethernet ports or more WiFi coverage they simply hooked up another home router, which DHCP’d it’s own RFC 1918 LAN and NAT’d that into the “primary” LAN.

For the most part this seems to work, so why fix what ain’t (too) broke? Why is this an interesting area now?

What’s New?

Home networks are starting to be bombarded by a plethora of new use cases:

  • Ever increasing devices in the subscriber home: Tablets, smartphones, laptops, smart-TVs, game consoles, smart appliances, the list goes on and on.
  • Separation of guest users from home users: As more and more of our lives become digital, the need to keep guests from accessing your personal data (photos, tax returns, etc.) is growing. More and more homes require a trusted network for their own use and a guest network to grant visitors Internet access.
  • Community Wi-Fi: Another new wireless use-case is the addition of a Wi-Fi GW (or additional SSID) in the subscriber home is used to provide Wi-Fi roaming services to folks passing by outside of the home.
  • Femto cell: A GW in the subscriber home used to provide cellular services over the existing Internet connection.
  • Smart grid: Home routers providing connectivity to utility company equipment.
  • Security, Monitoring, & Automation: More and more sensors and other devices are becoming IP enabled and need network connectivity to function.
  • Multi-homing: Users who are increasingly dependent on Internet access may choose to reduce their odds of failure by having two distinct connections, maybe Cable and DSL, or Cable with an LTE backup, etc.
  • IP video streaming from the Internet: Video is going IP. Netflix, Youtube, Hulu, HBO-Go, and soon perhaps even your cable channels, IP video is the largest consumer of Internet bandwidth today and shows no sign of slowing.
  • Video content sharing and streaming between the devices inside the home: Home movies, downloaded content, ripped DVDs, etc. We need ways to play any content from any source any time.
  • Telecommuting and corporate IT requirements: As more people choose to work from home, more companies are requiring strict security measures for their employees home networks, including completely separate networks for telecommuting.
  • Emergence of Heterogeneous link layer technologies: ZigBee, Bluetooth, and others are making plays for home device connectivity, and these devices will need to communicate with the rest of the home network to provide the most benefit.

So what does this mean for home networks?

Tomorrow’s Home Network

These emerging use cases for the home network, along with the facilitating technologies (including IPv6), seem to be pushing us away from the simple, single router home network of the past to a much more complicated multi-router future.

For one example, I think it will become common to buy a pre-packaged “home security system in a box” that will include a multitude of door and window sensors, motion detectors, glass break sensors, etc. all IP enabled and ready to connect wirelessly (perhaps with 6LoWPAN) to the included router / gateway. This home security router will then be plugged in (likely quite arbitrarily) to the existing home network, alongside a home theater router, a smart kitchen router (perhaps embedded in an eFridge), etc.

Of course, adding routers to a network increases its complexity. In enterprise and service provider networks, increased complexity can be dealt with by training or hiring network engineers (or bringing in contractors). In the home however, I do not believe that we can assume that network users will increase in complexity themselves (nor will they hire engineers). This is the crux of the home network problem statement; how do we deal with increasing network complexity in home networks without increasing the complexity of operating a home network? We must design a network that is completely self-configuring in (almost) every situation. This raises several problems that must be solved.

Opportunities for Innovation

There are a number of problems, er opportunities, that must be addressed to enable this multi-router, arbitrary-topology, configuration-less home network:

  • Prefix-distribution & Routing: The first problem that likely needs to be considered when developing a multi-router home-network architecture is how to distribute IP prefixes throughout the home, and how to route packets within and out of the home network once it’s established. The current default with IPv4 home routers is NAT-stacking, where each router creates its own private (RFC 1918) LAN addresses and NATs into the upstream network, and bridging, where the home router recognizes a private address on its WAN port and stops routing altogether. Some proposed options (focused on Pv6) are recursive DHCPv6 PD, DHCPv6 relay, and a routing protocol (yes, OSPF in your Grandmothers house). More work is needed.
  • Network Detection: This problem can be split into two; edge detection and up detection. Edge detection is important for routers to understand if they are a Customer Edge Router (CER) connected to an ISP, or an Internal Router (IR). This is necessary information for many other decisions like whether to activate a firewall, when to perform NAT, etc. Up detection could facilitate “directionless” home routers, common in other environments, and allow hierarchical logical topologies to be built over looped, meshy or other non-linear physical topologies.
  • Multi-homing and Failover: Having multiple Internet connections greatly complicates routing, especially if the desire is for active/active load-balancing over multiple ISPs. Without introducing BGP and complex routing and forwarding tables, how can we get functional auto-configuring multi-homing? Do we need to?
  • Service Discovery: Most current service discovery technologies assume a single broadcast domain (a single home LAN). The introduction of multiple home routers will make it more challenging for networked devices to discover each other, especially when they are several hops away from each other (when there are several routers between them). We need solutions for whole-home service discovery that “just work.” This could mean additional multicast support, centralized service discovery services, etc.
  • RF Interference: As we add multiple SSIDs, technologies that utilize multiple channels, and multiple new wireless protocols, how do we avoid service impacting RF interference?
  • Non-IP Gateways: There are additional challenges that may arise when connecting Zigbee, Bluetooth, and other non-IP networks into your home IP network.
  • Troubleshooting: After all this is working, we must be able to keep it working. What is an ISP call center going to do to help customers with networking problems in this more complicated environment? How will hired-geeks be able to quickly analyze and mitigate network issues?
  • And More…This is just the tip of the iceberg, as we start designing, building, and deploying these networks in earnest, there are likely to be plenty of surprises and more “opportunities for innovation.”

Moving Forward

As network engineers begin to address the future of home networking, we should keep the principle of Occam’s razor and the words of Antoine de Saint-Exupéry top of mind. We need to ask ourselves about the expected level of sophistication, for both devices and users. I think we can generally agree that while home networks will become more complex, home users will not (and the gear can’t get more expensive either). We should remember that while we may have gained our experience and expertise working on enterprise, campus, or service provider networks; home networks are a new and different challenge, requiring a new and different approach. We must also consider the 80/20 rule and not let exceptions (often our own “home networks”) rule the conversation and spoil the solution for everyone else. Finally, like any design endeavor, we should fight to keep the solution(s) as open and extensible as possible - while we need to solve for an unmanaged network, we mustn’t close the door on configurability for more advanced users and uses.

For a bit more on this problem statement, you can watch my recent talk at NANOG 56, and/or check out the slides.

By Chris Grundemann, Creative|Technologist

Filed Under


Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet




Sponsored byVerisign

Brand Protection

Sponsored byCSC

New TLDs

Sponsored byRadix

Domain Names

Sponsored byVerisign

IPv4 Markets

Sponsored byIPv4.Global

Threat Intelligence

Sponsored byWhoisXML API


Sponsored byDNIB.com