 |
| The routers in my automatically configured IPv6 home network |
I wanted to talk about personal home networks on IPv6. I have built a prototype of some cool new technology and my first network is now up and running, having configured itself completely automatically. My implementation is a hack, and only works in very limited cases. Nevertheless, I think it is the first implementation of this technology, currently under development at the IETF's new HOMENET working group. And I believe this technology might have an impact on how people set up their home networks in the future. Hence this article.
(Note that the blog is not about finding an ISP that supports IPv6. And not about home gateway products that are IPv6 capable. Of course those are important issues, but there has been enough discussion about those topics in various forums already. See the end of the article for further details on those.)
What I want to talk about is your home network itself. Can you have any type of network? Any number of nodes? What kind of network architecture should you choose? Is there a lot of configuration effort? The simple case is easy, when there is one router and network behind it -- RFC 6204 has the details. And we all know how to handle this and even the little bit more complex cases on IPv4; it is far from perfect but the technology is well understood.
I Have a Dream
The dream is that you can have any number of routers and hosts and connect them in any way you see fit. And the network comes alive automatically, all parts of the network shall have address space, routers shall know where to send packets, and names get resolved to addresses. And all this should happen without any human touch. (Especially by my mother. Bless her, she is a wonderful person. But she is not that good in configuring IPv6 routing entries.)
"One Subnet Should Be Enough for Everybody"
The simple case with one subnet is easy to deal with. There is already plenty of equipment out in the market that does that. There is an argument that says going beyond this model leads to problems, and that it would be prudent to stick with the simple model. I just don't know if the simple model is sufficient. I can offer a few example cases where it is clearly not sufficient, however:
- Network separation through policy. Many of today's wireless routers have by default a "Guest" and "Private" networks. It is expected that upcoming applications -- such as smart energy networking for power companies -- may increase requirements for having multiple networks in homes.
- Heterogeneous network technology. Some types of link layer technologies can not be bridged together, leaving routing or NATting as a the only option. Other technologies may be bridgeable, but their speed differences are too big to make it wise. For instance, bridging together Gigabit Ethernet and some low-speed sensor networking technology may lead to the latter being overcome by the multicast and broadcast traffic of the former.
- Organic growth of networks. People who have, for instance, insufficient wireless coverage in their houses often end up buying a new device and adding it to their networks. More often than not, these new devices have been routers/NATs in the IPv4 world.
The HOMENET WG is trying to address these requirements, by creating a solution that supports multiple routers, multiple subnets, automatic prefix-configuration, automatic routing, and across-the-home name resolution. The working group is currently designing the architecture and various proposals for solutions exist as individual proposals. The group is focused on recommending the use of existing tools, as things like DHCP-based prefix delegation and prefix announcements via Router Advertisements are the right thing to do. And if routing is needed, the existing routing protocols can certainly handle the task. However, the group will have to create a few extensions in some cases where fully automatic configuration is not possible otherwise.
 |
| HOMENET WG meeting in Paris, France |
The group is looking at a number of different solutions. There are routing protocol designs based on OSPFv3, RIPng, RPL, and even simple routing extensions for Neighbor Discovery options. For prefix assignment, the group has two alternate designs, one based on hierarchical DHCP prefix delegation and another one based on distributed operation over a routing protocol.
The picture below shows the architecture for an OSPFv3-based design, providing both routing and prefix assignment capabilities.
 |
| OSPF-based home routing architecture |
Example Network
The below figure shows my home network, a good example of a network that would benefit from the HOMENET technology. The network has over 200 Gigabit Ethernet ports, 4 kilometers of Cat6 cable, and enables things like my laundry talking to me via Facebook. In other words, it does all the usual geek network things.
 |
| One home network |
But the important point from the perspective of the actual network architecture is that I had to create a dozen different subnets within my network. I obviously needed my primary internal subnet, but also had to create other subnets for visitor networks, NAT64 networks (these consume two prefixes), and some of my home automation and utility networks were in their own address space for various reasons.
 |
| Subnets in the above home network |
I'm a geek, and at the beginning I thought I could easily handle all this manually. Then I realized that I had to run a routing protocol to keep the route entries correct. And a tool to monitor what devices I have in my network, as I had lost count. And then I forgot what prefixes were assigned where. It was too hard to keep all those numbers in my brain.
And this was only the beginning of my problems. A couple of months ago I woke up one morning to realize that my ISP had renumbered my entire network. I had to start over. The moral of the story is that even us geeks need automation, let alone our mothers and other people who have no expertise in networking technology.
Implementing HOMENET
I created a prototype to test the ideas of HOMENET. The primary goal was to understand what the real needs were, find out the missing pieces, as well as to see if our specifications for the OSPFv3 extensions were on the right track. I now have a small implementation. The code is unreadable, the design is a hack, and it still misses large parts of the necessary functionality. But it has already given me an opportunity to see if the ideas work in practice.
First off, the technology seems to be working as intended. I'm writing this article in a network configured by the prototype, so it works. And it feels like the natural way of doing things. If we get the technology fully specified, I'd expect other networks to want to use it as well. Corporate networks, for instance, would probably find it useful.
The implementation is capable of automatic configuration of OSPFv3 itself, generating router identifiers for all involved routers, assigning address space in an optimal manner to the entire network, discovering all available DNS servers, and configuring Router Advertisement daemon to advertise the assigned prefixes and DNS server addresses. And since this week, the prototype also automatically configures Ericsson NAT64 devices by making an assignment for the address space that those devices need.
 |
| Logs showing how router IDs, prefixes, RAs, DNS, and NAT64 have been configured automatically |
I've learned a number of detailed lessons about the protocols necessary to do this; those lessons will be fed back to the IETF working group. But the main lesson for me was how connected the routing protocol based auto-configuration software is to other parts of the system. Obviously, an OSPF router talks to other OSPF routers. But in this case it has several other interactions as well, illustrated in the below figure.
 |
| Dependencies |
The first group of interactions relates to where the system gets the usable address space it needs. The preferred source for address space is your ISP, and DHCP prefix delegation is the best way to retrieve address space from your ISP. However, not all ISPs support this protocol, and some users may have to manually configure their address space in one of the routers. From there on the HOMENET technology can distribute the address space to all other routers in the network. Finally, when the home routers are coming up for the first time and if no connection to the ISP has been set up yet, they are in a difficult position. There is no address space to be used, but communication between the different nodes in the network is going to be difficult without addresses that can be used across the entire home network. At this point it might be useful to generate some Unique Local Address space -- a feature of IPv6 -- that can be used until actual ISP connectivity comes online.
Another set of interactions relates to where the address space is used: the address space needs to be configured to interfaces, advertised in Router Advertisements, given to the use of a NAT64 implementation, and so on. In my network I also need some address for servers that represent legacy sensor networks on IPv6.
Finally, even when addresses have been assigned and packets are routed correctly, the end user will not be happy unless hosts can resolve names to addresses. For this to happen, the hosts need to be told where the DNS servers are. This can be done via adding DNS server addresses in options to Router Advertisement messages. But the auto-configuration system still has to figure out where the DNS servers are! There are couple of different approaches to this. One straightforward approach would be to run a server on each router, resolving names through the global DNS root system. I have chosen to use a different approach, where I attempt to discover existing DNS servers from my ISP or from my own network. I use the DNS Discovery Daemon (DDD) for this task. There is an interesting complication, however, in that IPv6-only and dual-stack networks are different in some respects. First of all, in a dual stack network the configuration of IPv6 DNS servers is often not absolutely necessary, as the IPv4 DNS servers can serve IPv6 content. But things get more complicated with network tools like NAT64, because they involve translation of DNS results through a technique called DNS64. Given this, a name server that acts as a DNS64 is something that you want to use behind a NAT64 device, but not elsewhere in the network. DDD uses an advanced technique for probing the name servers to determine whether it is performing normal or DNS64 operations.
Some of these interactions have interesting aspects that require further work. The assignment of DNS servers is one such area. Timing the start of the ULA generation process is another one. We will be addressing these issues in the coming months.
Implementation Experiences
The OSPFv3 auto-configuration parts were very simple to implement. The prefix assignment was not as trivial to implement, but still relatively easy. These new extensions of OSPFv3 are in the order of two thousand lines of code, so they should be relatively easily be added to any OSPFv3 implementation. Assuming the implementation has been made reasonably extensible.
However, OSPF itself is a very complex and difficult protocol to implement. I chose to implement it from scratch. How hard could it be? It turned out that it is very hard. I do not yet have a full implementation, among other things the actual route computation is still missing even if the flooding process is complete. In any case, any sane person would start from an existing implementation and would just add the new parts. Oh well. I have learned a lot from routing protocols with this exercise, which was part of my goals.
Conclusions
HOMENET is an interesting piece of technology that has promise to make the configuration of home and other networks much simpler in IPv6. The working group at the IETF is in an active design phase; the participation of all interested parties would be welcome there. There are also several implementation efforts under way, not just mine. I would say, however, that we are still in the exploration phase as we keep discovering what this technology could do. The specifics of the protocols will for sure keep changing. If you have feedback on what kinds of things should be auto-configured in networks or how we should go about it, let me or the working group know!
Details
HORD, my routing daemon is not open source, at least not at this time. But DDD, the DNS discovery part is. Look here for the details.
IPv6-capable ISPs and Routers
Note: Regarding IPv6-capable ISPs: there are plenty, check out Comcast in US, Nebula in Finland, or Mobitel in Slovenia for instance.
There are also plenty of IPv6-capable routers, my personal preference is Linux-based small PCs but you can also check out commercial models from Netgear, Cisco, and others.
 |
| Start of the HOMENET implementation effort in Christmas 2011 |
Photo credits (c) 2010-2012 by Jari Arkko
Ei kommentteja:
Lähetä kommentti