This is the second edition of an article I originally wrote back in June, 2012. Since it has been linked several times by various web sites, I felt compelled to update it with some corrections based on things I've learned since then. There are also some grammatical and content changes that bring things up-to-date.
Back in 2012, my home Internet Service Provider (then Time Warner Cable, now Spectrum) deployed native IPv6 on their cable modem based Internet service. When I noticed this (somewhat by accident), I immediately wanted to jump on the bandwagon and bring my home network into the 21st century. I had already been using an IPv6 tunnel from Hurricane Electric and felt fairly confident that moving to my ISP's native IPv6 networking would be trivial. As detailed below, this confidence would quickly turn to frustration and uncovered a variety of examples showing how unprepared we are for the IPv6 transition. After several days of working on this I felt compelled to document this to give others a starting point so that they can avoid some of the headache I encountered.
Below is a simple diagram of my home network (as it was back in 2012).
While your equipment may vary, today's home network can actually be even more complex, containing more computers (in a family environment), tablets, smart phones, networked storage nodes, "Internet of Things" (IoT) devices like thermostats and doorbells, home automation equipment, etc. The point is that the typical home has a fairly complete network on the "customer" side of the cable modem separated by a so-called "router" of some variety. In addition, this network, while Internet-connected, tends to serve several local (non-Internet) functions as well. In my network, for example, the DVR functions operate independently of the Internet (over-the-air TV from the TV Tuner gets recorded onto the DVR backend server with no Internet involvement).
The important thing to note is that, in the IPv4 world, this is a complete network with IP addressing independent of the Internet Service Provider (ISP). This is accomplished by using site-local IP addresses (also known as private or RFC1918 addresses). Since residential Internet Service Providers (ISPs) generally only provide a single IPv4 public IP address, the router needs to act as a network address translator (NAT) and all the devices on the network accesses the Internet via that single IP address. Consequently, when one needs to host any kind of service using that Internet connection, it is necessary to provide special programming in the router to direct this traffic to a specific device on the local network. Either through the router or by running a local nameserver (such as BIND/named), host names can easily be translated to the private IP addresses assigned. This allows all of the devices on the local net to be able to access each other. There are many good articles outlining the problems with NAT and the use of IPv4 private addressing, and so that will not be discussed here. Again, the point is that we have established a network with ISP-independent addressing and that the devices on this network have a desire to communicate with each other (not just the Internet).
One of the key features of IPv6 is the expansion of the public IP address space. With IPv6 fully deployed, ideally all home equipment can have its own public IP address, can potentially gain access to or be directly accessed by a host on the Internet, and all of the issues associated with NAT could eventually be a footnote in Internet history.
When people move away from NAT and replace their device addresses with public IPv6 addresses, the usual concern is with regard to security. People have become accustomed to protecting their internal hosts by making the assumption that having private addresses and NAT will keep intruders from accessing internal hosts. While this is correct in theory it is a very naive assumption. In reality the most recent attacks on systems take place by dropping some kind of malware on a system (generally by tricking the user into downloading and running the malware), then having that software "phone home" by establishing an outbound connection to a remote-control-type facility (known as "command-and-control"). This succeeds in spite of NAT. NAT is not a security mechanism nor is it a suitable substitute for good system hygene. A very basic stateful firewall with rules blocking all inbound IP traffic by default is an equivalent way to provide the protections that NAT provided.
In short, the architects and standards committees developing IPv6 were so convinced that phasing-out NAT was the right direction that they avoided, at every step it seemed, the concept of supporting private IP addressing and NAT in IPv6. I was later to find out that this is only partially true.
This is where we begin our adventure.
There are several ways to deploy IPv6 in a large-scale service provider network. Most of these are intermediate steps toward what should ultimately be a native IPv6 implementation. A native implementation is where IPv6 packets share the same network pipe with IPv4 packets, with no tunnelling or special treatment required. In the case of Time Warner Cable (TWC) in Austin, Texas, they decided to do a native IPv6 deployment. In very simplistic terms, this means that if I have a device that supports IPv6, all I need to do is hook it up to my cable modem and IPv6 is there. While TWC never officially announced their IPv6 deployment, I discovered it by noticing IPv6 packets (specifically ICMP6 RA (router announcement) packets) at the Internet connection from the cable modem.
Important note: I am not going to elaborate on specifics of the IPv6 protocol in this text. There are several references on IPv6, and you should consult these if you are unfamiliar with IPv6 and how it works.
TWC's IPv6 implementation uses stateful autoconfiguration process -- by this, I mean that instead of providing network information via ICMP6 multicast packets, the customer premise equipment (CPE) -- the customer router -- is expected to request the address information from TWC's servers via DHCPv6. The RA packets that I saw from TWC's equipment had the managed address configuration and other configuration flags set, and this indicates to the CPE that DHCPv6 is used (rather than stateless autoconfiguration, where each host builds its own IPv6 address from information in the RA packet). In the IPv4 world, DHCP provides a host with a single IP address. In the IPv6 world, the default behavior of DHCPv6 is the same. For one host connected to a cable modem, this would work fine, but it would not work well if, for example, one has a full network behind a router connected to the cable modem. That being said, IPv6 provides (and TWC implements) two different DHCPv6 methods:
192.168.1.0/24.The second method is a departure from the old IPv4 way of doing things in that it is now possible to obtain an entire block of public IPv6 addresses for devices on the local network. In the case of TWC, they provide the CPE with a "/64" size network block - leaving 64 bits of a 128 bit IPv6 address to provide addresses for the systems on the local network. The number of possible addresses in 64 bits is an amazingly large number. In practice, most installations utilize the full 64 bits on the local side through stateless autoconfiguration. This takes the 48 bit MAC address of the device and a simple algorithm to form a unique "modified EUI-64 format" host address. There is no reason why one couldn't take that /64, subnet it using the CPE router, and have several physical IPv6 networks using that /64 (at that point stateless autoconfiguration would be out of the question...and the configuration would become a lot more complex).
A Side Note: It seems like it may be possible to use DHCPv6 to request multiple IPv6 address blocks from the ISP, but I have not tried this yet. I recommend being careful not to abuse this feature or it may be gone at some future date.
In order to utilize the acquired IPv6 network block, it will be
necessary to assign a consistent address from that block to the
inside interface of the device acting as a router (I am going to
assume a Linux-based host). This is typically done using
an option within the DHCP client application (general dhclient or
dhcpcd). Since all of my router interfaces end with .1 in the IPv4
world, I assigned {prefix}::1 to my inside interface.
Additionally, it will be necessary to run radvd (the
router advertisement daemon for IPv6) so that other hosts on
the network know about the IPv6 network block and can autoconfigure
their IPv6 addresses.
Congratulations! You now have public IPv6 addresses for the hosts on your network.
While having public network addresses opens up a new world of
opportunity for Internet access, having a dynamic network portion
of the IPv6 address (the IPv6 prefix)
likewise creates a new kind of problem. Recall that when
using private IP addressing, the network
portion of the address (for most home users, it was
192.168.1.0/24) was constant.
Therefore, no matter what happened with the ISP connection, the IP
addresses for nodes on the internal network remained constant. When
the IPv6 prefix is chosen and distributed by the ISP, this creates
the following new problems:
These problems likewise have wide-reaching impact on the network. Based on the above issues, this list now also includes...
resolv.conf or similar (or even configure a local
DHCPv6 server) with the address of the DNS serverRecall that earlier I mentioned that there seemed to be little
regard for private addressing in IPv6. When I first deployed
IPv6 on my network and noted the above problems, I was thinking
in a very "IPv4 mindset." In IPv4, it is typical to
have only one IP address per interface, and it is usually considered
problematic to have a link-local IP (such as 169.254.x.x)
address on the interface. This is not the case for IPv6.
Additionally, site-local IPv6 addresses are quite typical and useful.
In IPv6, it is quite typical for several IP addresses to be on
each interface. The addresses are assigned a "scope"
based on certain bits in their prefix, and these provide hints
to the underlying OS which address to use for source IP purposes.
The link-local IPv6 prefix (FE80::/64) is nearly always
present, and is sometimes utilized when speaking to a host on the
same physical "wire" (actually, on the same switch, but
I'll call it a "wire" for simplicity's sake). For local
IP addressing, there is a construct called
a Unique Local Address (ULA) that is a section of private IPv6 address
space carved-out specifically for traffic on LANs (similar to the
RFC1918 space in IPv4). To maintain a
consistent IPv6 address for each host on the LAN, it will be
necessary to generate an IPv6 ULA prefix and assign a subnet within
the ULA to each LAN (internal) interface on your router. This
becomes the "predictable" IPv6 address that hosts within
the LAN will use to communicate with one another, and can be used
in the internal DNS server for the LAN, etc. Finally, the public,
globally scoped addresses that are acquired from the ISP are assigned (as
noted above) as a third IPv6 address, and will be the source address
of the host when the OS IPv6 stack determines that the destination
IP will go "off-LAN."
When thinking about this in an IPv4 context, this seems kind of dirty. However, it is rather elegant. I will note that this revelation came after messing with a commercially-available IPv6-aware home router, and then looking at the internals of the Linux IPv6 stack in the kernel. It elegantly solves nearly all of the problems noted above.
The only remaining problem is how to provide an Internet-global IPv6 address a name in the global (not local) DNS. Unfortunately, because the IPv6 prefix is acquired via DHCPv6 from the ISP, and that prefix isn't predictable or consistent, the same tricks necessary for mapping an ISP-assigned IPv4 address will still be needed for IPv6. Thankfully, both dhcpcd and dhclient have the ability to call "hook" scripts that can be used to do this. The ability to provide "reverse-DNS" with the actual hostname will also not be possible, just as with ISP-assigned IPv4 addresses. However, in nearly all applications, this is not very important -- especially for home networking applications.
My first attempt at understanding this had resulted in predicting doom and gloom that I happily published for the entire Internet to read. Since then, for the past (at least) three years, I have been using my new understanding of IPv6 with a great deal of success (unfortunately lacking the time to update this article until now). The issues that have come-up have mostly centered around broken networking software -- specifically problems with dhcpcd and radvd. Certain versions of dhcpcd have broken acquiring a prefix and assigning it to a child interface properly. It gets fixed in a subsequent version, then breaks again in a later version. I also found that earlier versions of dhcpcd fail to remove an IPv6 prefix/address when the prefix from the ISP changes, resulting in unroutable addresses on all internal hosts. My problems with radvd are mostly cosmetic (some error messages are displayed that aren't really errors). So while there is doom and gloom, it is managable.
IPv6 is more complicated than IPv4. There are different concepts that need to be understood before being able to set this up on a network. The more common brands of home routers are starting to handle IPv6 correctly and transparently, so that is an option for those who want to just "plug-and-play." To build a good router based on Linux or *BSD requires a lot more knowledge of IPv6 and understanding of the system applications that support it. Likewise, keep in mind that the OS distribution network application developers are still learning as well, and some implementations can be a bit rough. You may well find yourself hacking on some code or developing some utility scripts to fill-in holes resulting from that misunderstanding. Generally speaking, IPv6 from a client perspective works great, but building a router from a Linux distro still requires some work.
Article Copyright ©2012,2018 - Gil Kloepfer