My home Internet Service Provider (Time Warner Cable) recently deployed native IPv6 on their cable modem based Internet service. When I noticed this, 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 and to solicit feedback on how we can address some of the problems I encountered.
Below is a simple diagram of my home network. These days, this is fairly representative of the typical home network.
While it can be argued that some of the components are different for a typical residential network, the size and complexity is about average these days. In many cases there are people running gaming PCs (which could act as servers as well), networked thermostats and/or home automation equipment, networked printers, networked storage, and other such devices. The point here 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 kind. In addition, this network, while Internet-connected, tends to serve many local (non-Internet) functions as well. In this case, 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 here is that, in the IPv4 world, this is a complete network with IP addressing independent of the Internet Service Provider (ISP). We accomplished this by using site-local IP addresses (also known as private or RFC1918 addresses). Since we only had a single IPv4 public IP address from our ISP, our router would act as a network address translator (NAT) and all the devices on the network would access the Internet via that single IP address. Consequently, when we wanted to host any kind of service from our Internet connection, we would need to provide special programming in our routers to route specific traffic to a device on our local network. Either through our router or running a local nameserver (such as BIND/named), we could easily translate host names to the private IP addresses we assigned. This would allow all of the devices on our net to access each other. There are many good articles outlining the problems with NAT and the use of private addressing, and so that will not be discussed here. Again, the point is that we have 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 could have its own public IP address, could potentially gain access to or be accessed by a host on the Internet, and all of the issues associated with NAT would be a footnote in Internet history.
When people move away from NAT and replace their device addresses with public IPv6 addresses, the usual concern I hear 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. 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 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, the concept of supporting private IP addressing and NAT in IPv6.
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 has not officially (as of this writing) announced their IPv6 deployment, I noticed some IPv6 packets (specifically ICMP6 RA (router announcement) packets) coming from the cable modem, and realized that they had started the roll-out.
Important note: I am not going to go into fine detail on 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 is a stateful autoconfiguration process -- by this, I mean that instead of providing network information via ICMP6 multicast packets, the customer premise equipment (CPE) 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. This would not work well if, for example, you had a full network behind the router on your cable modem. That being said, IPv6 provides (and TWC implements) two different DHCPv6 methods:
The second method is a departure from the old IPv4 way of doing
things in that we theoretically have an entire block of addresses
for devices on our 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 for us to provide addresses for the systems on
our network. The number of possible addresses in 64 bits is
an amazingly large number. In practice, most people utilize
the full 64 bits on the local side through stateless
autoconfiguration which 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 really no reason why you couldn't
take that /64, subnet it using your router, and have several
physical IPv6 networks using that /64 (although stateless
autoconfiguration would probably be out of the question...).
What is important to understand here is that, for the first time,
the network part of the IP address (specifically, the IPv6
address) will be determined by your ISP, and that network will be
acquired by DHCPv6.
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, 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.confor similar (or even configure a local DHCPv6 server) with the address of the DNS server
Some of the above conditions could be addressed through clever scripting triggered by the DHCPv6 client handling the prefix assignment. However, this still doesn't address the problems associated with the IPv6 prefix being changed and thus having all the addresses on the internal (local) network changing, nor is it clear how the internal network prefix should be assigned prior to the connection to an ISP.
In the IPv6 world, each physical network interface has what is
called a link-local address (prefix
remains no matter what the global ("public") IPv6 address
is. However, the problem with link-local addresses is that
using them requires that the physical interface be specified in
addition to the target address. This is not obvious until
one considers a multi-interface host where it is unclear which
physical network a target host resides on. On Linux,
attempting to access a link-local address without specifying the
interface will return "
connect: Invalid argument" and
most applications are not written to deal with a syntax that
includes the interface. So using link-local addressing for
internal hosts is not practical. Consider also that a home
network could, conceivably, consist of multiple physical networks
(although this would not be the common configuration).
While the standards committees frown upon using local addressing
at the site level, a prefix defining what are called unique local
addresses (ULAs) was defined (this is prefix
defined in RFC4193). ULA is the IPv6 equivalent to the
site-local addresses like
first in RFC1918) that was used in IPv4. Researching this
turned-up article after article strongly discouraging the use of
ULAs, and it is not even clear that the standards committees will
keep ULAs as part of the standard. The biggest reason why
ULA is considered taboo is that an application sending an IP
packet to the Internet will not know whether to source that packet
from the ULA or the Internet global address. In effect, it
would require every host on the network to have details of the
network routing in order to determine the source address to use,
and engineers are justifiably concerned about ULAs ending up on
the global IPv6 Internet.
The best solution to these problems would be for the ISP to provide each customer a specific IPv6 prefix upon signing-up for service, and this prefix would persist for the life of the customer-ISP relationship. In other words, while DHCPv6 could still be used to hand-out the prefix (if desired), the prefix would be predictable from the customer point-of-view, and therefore the customer could treat it as though it were a static prefix when configuring their network. The only time a change would be required is when a customer changed ISPs or, perhaps, changed physical service location within that ISPs service area. Unfortunately, ISPs are not known for being reasonable in this regard (in fact, they may see such a critical requirement such as this as yet another revenue-grabbing opportunity), and it is not clear that the (in the case of Time Warner Cable, for example) cable modem termination system (CMTS) equipment has been set-up to provide this for residential customers. Other options such as residential customers applying for their own IPv6 prefixes and requesting routing by the ISP is quite impractical, and would create ridiculously complex routing tables that impact the entire Internet. It makes good sense for the ISP to assign the IPv6 prefix to the customer for route aggregation purposes, and frankly most residential and small/medium business customers would rather not have to deal with obtaining and coordinating routing for their own prefix.
The unfortunate consequence of the above situation is that the IPv6 Internet is still not ready for global consumption yet. I was disappointed at the lack of thought by ISPs (notably, cable Internet providers) regarding the issues of prefix assignment. I was able to find a document from CableLabs defining specifications for a customer router, which left me with the feeling that the cable ISPs were ultimately going to integrate all IPv6 routing functions inside the ISP-provided modem, leaving no way for the customer to deal with the problems indicated above.
In the meantime, the best workaround is to use dual-stack (IPv4/IPv6) on all hosts on the internal (local) network and prefer using IPv4 for all local traffic (ie. use IPv6 only when addressing Internet hosts). I don't like this solution because it encourages the continued use of IPv4 and underscores the futility of a mass-deployment of IPv6. It additionally gives equipment manufacturers an excuse to not support (or not fully support) IPv6 in new products or updated firmware. Adopting IPv6 in the home motivates manufacturers to move forward with IPv6 support.
Finally, the proper way to deploy IPv6 prefixes to the customer is to assign them on a per-customer basis when establishing service rather than dynamically from a prefix pool. This will require ISPs to provide this information to customers during service establishment (through the customer service portal would be ideal), and the CMTS (or similar on the DSL and FTTx side) to be able to properly handle routing the assigned prefix to the customer's CPE.
Article Copyright ©2012 - Gil Kloepfer