IPv6 and Linux

IPv6 is the next generation of Internet Protocol (IP) that will replace IPv4. IP takes care of the basics of getting information from point A to point B on the Internet; it handles the addressing of packets and not much more. If you want integrity, if you want data delivered in the right order, and if you want only one copy of the data to be processed, you'll need a higher layer protocol such as TCP. But, you generally don't get those things unless the packets know where to go. IPv6 is very similar to IPv4 except for the parts that are completely different (e.g., link local and broadcast addresses, auto-discovery, auto-configuration, self-forming networks, IPSec, etc.).

Why You Care about IPv6

IPv4 has been in use since 1981 and is beginning to show its age, especially in one critical area: address space. In theory, IPv4 has about 4.3 billion usable addresses; however, in practice many cannot be used (i.e., all of 127.* is reserved for your local link, 10.* is reserved for internal networks, and 224.* and up are reserved for multicast, so that's half a billion addresses you can't really use).

IPv6 addresses this issue with a rather simple and effective solution: It uses a 128-bit address, which makes for a ridiculously large address space, although back when IPv4 was created, I'm sure they thought the same thing (see the "IPv6 Logging" box).

So, why is larger address space important? Because available IPv4 addresses are rapidly disappearing [1] [2]. In February 2011, the last remaining unclaimed addresses passed from the hands of Internet authorities. Regional registries now hold all remaining Class A address blocks, and they are expected to run out in a few months. The vast majority of ISPs still do not provide IPv6 service, let alone have a high level of experience with it.

IPv6 Differences

Beyond the larger address space, IPv6 has some very different features. For example, allocation of networks can be done more efficiently. In the past, IPv4 addresses were assigned either as Class A (16 million), Class B (65 thousand), or Class C (256), which resulted in some very inefficient allocations (e.g., several universities have Class As). This problem was partially addressed with CIDR (Classless Inter-Domain Routing), which allows for other network sizes (i.e., eight Class Cs in a block).

Because IPv6 has so much more address space, network size is also much larger; apparently, the "smallest" network being assigned as standard is a /64 (i.e., 4 billion times the entire current IPv4 Internet). Larger networks are also being assigned as /56 and /48 (272 and 280 addresses, respectively); however, even with these extremely large assignments, less than one percent of available IPv6 addresses will be assigned. This allocation also has the benefit of consolidating routing tables. (One network block will be assigned to an organization, and chances are they will only ever need that one.)

Another key difference with IPv6 is multicast support. Because of the size of network blocks in IPv6 and the auto-configuration aspect, you will no longer have nice small blocks of addresses used contiguously on a specific subnet. In other words, traditional broadcast traffic would end up being replicated across your entire network (which would quickly bring it down). To address this problem, multicast is used for traditional broadcast-type traffic, as well as for the local link address (i.e., good old 127.0.0.1).

Getting IPv6 Connectivity

You can get IPv6 connectivity in several ways: native IPv6 access, IPv6 tunnels, Teredo (Miredo on Unix), and 6to4. IPv6 tunnels and Teredo are your basic "encapsulate your IPv6 traffic over IPv4 to someone with real IPv6 connectivity," and 6to4 is (in theory) a configuration-free way to get IPv6 connectivity.

Now's the time to start learning how to deploy IPv6 and to become familiar with the problems you will encounter (see "IPv6 Education and Training" box). If you have an ISP that offers native IPv6 support, you can skip the next few sections and go straight to firewalling IPv6. For the 99.9 percent of us that don't have native IPv6 connectivity, keep reading.

IPv6 Tunnel Setup

Of all the methods to get IPv6 access, IPv6 tunnels are probably my favorite way. The process of setting up a tunnel isn't too bad. Step one is simple: Find a tunnel broker [4] and register. Personally, I use Hurricane Electric. (Disclaimer: I also use them to host seifried.org, because they support IPv6 on even their cheap web plans.) Step two is plugging the IP address you appear to be from (either your publicly routed IP or the publicly routed IP of the NAT box you are behind) into their system and requesting a tunnel for it. Hurricane Electric's tunnel broker page has one killer feature: You select your OS from a pull-down box, and it spits out the exact command line needed to get the tunnel up and running (for Linux, *BSD, Windows, several routers, etc.). Listing 1 shows an example that will work on basically any recent Linux.

01 modprobe ipv6
02 ip tunnel add he-ipv6 mode sit remote [remote.IPv4] local [local.IPv4] ttl 255
03 ip link set he-ipv6 up
04 ip addr add [client.IPv6.address] dev he-ipv6
05 ip route add ::/0 dev he-ipv6
06 ip -f inet6 addr

To begin, you can insert the IPv6 module, then set up a tunnel to point at Hurricane's IPv6 tunnel server. Next, you bring up the tunnel and assign the local IPv6 address you've been given for your client end (usually ::2) and add a default route for IPv6 that points at the tunnel. The last command lists your IPv6 settings so you can double-check it. To verify that your IPv6 setup works, try pinging a known host – Google is a good bet (Listing 2).

01 # ping6 ipv6.google.com
02 PING ipv6.google.com(iy-in-x63.1e100.net) 56 data bytes
03 64 bytes from iy-in-x63.1e100.net: icmp_seq=1 ttl=52 time=99.6 ms
04 64 bytes from iy-in-x63.1e100.net: icmp_seq=2 ttl=52 time=100 ms
05 64 bytes from iy-in-x63.1e100.net: icmp_seq=3 ttl=52 time=103 ms

Personally, I prefer using tunnels over Teredo and 6to4 for several reasons – the simplest is that it works with a public IP or behind a NAT box (well, usually). Tunnels also provide some degree of control over where your IPv6 packets go (unlike with Teredo and 6to4).

Teredo/Miredo Setup

Teredo [5] (and the Unix implementation Miredo [6]) is a tunneling protocol with several advantages over straight-up tunneling. For one thing, this protocol is really easy to set up; you connect to a Teredo server, which in turn sends your client to an appropriate Teredo relay that actually handles your IPv6 traffic. Teredo also can make it through NAT machines in some circumstances where tunneling might fail.

Installation of Miredo is pretty standard; you download and unpack it and then compile and install it with the following:

./config --without-Judy
make
make install
You can omit <C>--without-Judy<C> if you have the Judy libraries installed (Judy implements a sparse dynamic array and only consumes memory as data is populated). Using Miredo without Judy will require slightly more memory, but on a modern machine this shouldn't be an issue. The default configuration file, <C>miredo.conf<C>, will work, but you might want to point it at Microsoft if you are also doing this on Windows to have a common configuration and setup. Then, you can simply run the <C>miredo<C> command, and you should have connectivity within a few seconds -- no further configuration required. On Windows 7, Teredo installation and setup is a snap:
netsh interface ipv6 install
netsh interface ipv6 set teredo client

You can see why attackers are starting to like IPv6; with two commands, you can set up a legitimate back door to access a Windows machine that anti-virus software, or most security software for that matter, won't catch. To disable IPv6, simply enter:

netsh interface ipv6 uninstall

6to4

6to4 [7] is designed as a transition mechanism for hosts with IPv4 connectivity but no direct IPv6 connectivity. This approach is slightly similar to Teredo in that you connect to a server and tunnel your traffic, but that's about all they have in common. 6to4 uses the 2002::/16 prefix (so any IPv6 address starting in 2002:: is a 6to4 system) and appends the IPv4 address (meaning a total of 48 bits are used: 16 to specify the IPv6 subnet and 32 for the IPv4 address). This method leaves room for a 16-bit subnet field and a 48-bit address, meaning you can basically serve an entire network with IPv6 connectivity using 6to4 and have no shortage of addresses.

This distinction is important to note because your IPv6 address is created from your IPv4 address, and your IPv4 address needs to be a routable public IP address (i.e., 10.* and 192.168.* won't cut it). To find the prefix you will be using, you need to convert your IPv4 address (which uses dotted quad notation) into an IPv6-compatible notation (which uses hexadecimal); see the "IPv4 and IPv6 Notation" box. From the Bash command line, simply execute:

printf '%02x%02x:%02x%02x\n' 19 83 20 235

Note that 6to4 relays (the machines that handle your traffic) use the anycast address of 192.88.99.1 (2002:c058:6301::), so finding out who is actually handling your traffic can be tricky. On the flip side, you don't need to do any configuration; 6to4 setup consists of:

ip tunnel add 6to4 mode sit remote any local <ßßI>your.IPv4.add.ress<ßßI>
ip link set dev 6to4 up
ip addr add 2002:<ßßI>your.IPv6.prefix<ßßI>:: 1/16 dev 6to4
ip -6 route add ::/0 via ::192.88.99.1 dev 6to4 metric 1026

Unlike IPv6 tunneling and Teredo/Miredo, several consumer-level routers now support 6to4, meaning you can get IPv6 connectivity at home without too much hassle (see the "IPv6 Device Support" box).

Access to Tunnels, Teredo, and 6to4

The advantage of tunnels and Teredo/Miredo is that you don't need a public IP address; however, you do need a public IPv4 address to use 6to4. Thus, any host with IPv4 connectivity (even if it's behind one or more NAT boxes or firewalls) should be able to establish a tunnel or Teredo connection and gain IPv6 connectivity (Figure 1). The downside of this setup is that any host with IPv4 connectivity (even if it's behind a NAT box or firewall) will be able to get IPv6 connectivity and a publicly routable IPv6 address that you can use to reach it.

Configuring modern hosts to use IPv6 is trivial in most cases (two to five commands and you're done), and using IPv6 is an ideal strategy for penetration testers and bad guys alike to maintain access to a host they have attacked. Blocking IPv6 tunnels and Teredo is possible for well-behaved tunnels and Teredo servers. Simply firewalling port 3544 (UDP) will block legitimate Teredo servers, and blocking protocol 41 (IPv6 encapsulation) will block most public tunnel servers and 6to4. Of course, if the bad guys install a Teredo server to use a different UDP port (e.g., port 53, which is rarely blocked), they will be able to get IPv6 traffic through to most systems.

Firewalling IPv6

Because Linux has had IPv6 support for so long, it also has a mature and full-featured, IPv6-capable firewall in the form of ip6tables, which has pretty much the exact same syntax and performance as your regular iptables. A quick and dirty way to get your IPv6 firewall up and running is simply to copy /etc/sysconfig/iptables to /etc/sysconfig/ip6tables (modifying any network or IP addresses, of course) then start up ip6tables and you're done. In fact, the firewall configuration tool in Fedora follows this process; it simply creates two files that are basically identical.

Firewalling IPv6 on all tunnel endpoints is critical because most users will be getting IPv6 connectivity through tunnels and other methods that do not allow existing firewalls to filter tunneled traffic effectively. Remember that most hosts using IPv6 will be assigned addresses dynamically and that free tunnel providers are handing out /64 network blocks, which means that attackers can rotate IP addresses constantly.

Gateway Setup

So, now that you have some form of IPv6 connectivity, how do you get your whole network on board? You could set up a tunnel or 6to4 on each system that needs IPv6 connectivity, but that's probably not the best way to go. Besides, if you ever get real IPv6 connectivity, you'll have to change everything. The simplest method is to set up one system with a tunnel (or Teredo or 6to4) and then configure it as a gateway for the rest of your systems.

For IPv6, this approach means setting up the router advertising daemon, or radvd for short [8]. Many Linux distributions now include radvd (e.g., Red Hat and SUSE); If yours does not, you can simply download it and run the typical ./configure, make, and make install to compile and install. You will also need to enable IPv6 forwarding, so you can either edit /etc/sysctl.conf or run sysctl manually:

sysctl -w net.ipv6.conf.all.forwarding=1

Configuration of radvd is easy. On a system where eth1 is the network interface attached to your internal network for which you want to provide IPv6 access, the configuration shown in Listing 3 should work. Once radvd is working, you should be able to enable IPv6 on other hosts with no further configuration.

01 interface eth1
02 {
03     AdvSendAdvert on;
04     MinRtrAdvInterval 30;
05     MaxRtrAdvInterval 100;
06     prefix 2001:42b5:d64a:0::/64
07     {
08       AdvOnLink on;
09       AdvAutonomous on;
10       AdvRouterAddr off;
11     };
12
13 };

IPv6 Attacks

IPv6 basically suffers from all the existing classes of attacks against IPv4 and also introduces some new weaknesses, especially with respect to auto-configuration. One main difference involves host discovery. IPv4 uses Address Resolution Protocol (ARP), which is done at Layer 2 of the network. Basically, a host sends a special network packet asking which MAC address is associated with a given IPv4 address, then the host replies and you now know which physical network card to send data to. IPv6 does the same thing, but instead of ARP, it uses an ICMP packet (which operates at Layer 3 and can be routed, etc.). However, the basic operation is the same.

Being able to route these ICMP packets is especially important because most IPv6-based hosts will set their address through auto-configuration, resulting in many more opportunities for address collision. Generally, an IPv4 or IPv6 address should only be used by one host, ignoring load balancing and anycast, of course. Impersonating the replies to hosts asking for information is trivial; thus, attackers can easily launch denial of service attacks against a host (by saying the IPv6 address it wants to use is already taken), or they can execute a man-in-the-middle attack (why, yes, I am your DNS server/gateway/file server/web server/etc.). Such attacks against IPv4 using ARP usually can be handled by network equipment; however, security protections for IPv6 are not as widely available on current network equipment.

The same general problems apply to the router advertising daemon (radvd). Routers send router advertisements to the "All-Nodes" multicast address, but these messages are not authenticated in any way, so anyone can send them and thus view all your network traffic.

Again, I hope that equipment manufacturers will embed security protections against such attacks in network switches (e.g., by allowing router advertisement messages to come only from the network port that the gateway is actually attached to). A complete suite of attack tools is available from THC, along with documentation and an extensible framework [9].

DNS Setup

DNS is not affected much by IPv6; you can simply add AAAA records that point to IPv6 addresses and you're good to go. To support DNS names for auto-configured clients, though, you need to enable dynamic updates in your DNS server, which I don't have space to discuss here. If you plan to deploy IPv6, remember that, currently, many hosts think they have IPv6 connectivity, so they will attempt IPv6 connections and then fail (and not all will fall back to IPv4).

IPv6 NAT

Things are going to get ugly here. Currently, IPv4-based NAT has been widely deployed at the edges of the Internet (i.e., almost all residential Internet users, many businesses, etc.). However, NAT does not work that well: It adds latency, it breaks a number of protocols, and unless you manually enable port forwarding, many things will not work at all. The ugly reality is that most of the IPv4 Internet won't be upgrading to native IPv6 connectivity anytime soon (and by soon I mean decades).

If users are lucky, carriers will deploy their own 6to4/Teredo relay servers or tunnel servers (so your traffic isn't sent to another country to gain access to IPv6 networks). This step will also help ISPs because they can restrict how many addresses you get and how those addresses are accessed. So, if you thought IPv6 meant you would get lots of addresses, you were probably wrong. And, if you want to read some really scary documentation, do a Google search for "Carrier Grade NAT."

Clients with Broken IPv6

Unfortunately, many systems think they have IPv6 connectivity but don't, which is especially true with 6to4; 6to4 tunnels are run for free, and some are well run, whereas others are not. In most cases you can't really contact the 6to4 provider for support, so if you have a problem, it won't easily be fixed.

Google has stated that approximately 0.01 percent (one in 1,000) machines on the entire Internet think they have IPv6 connectivity, but when they're given an IPv6 response to a DNS query, they fail to connect at all.

So, if you're planning to offer both IPv6 and IPv4 records for a host (i.e., http://www.example.org) you need to be prepared to lose at least one in a thousand clients, and possibly more (people may give up navigating to your website if it takes too long). A recent Mac OS X update has addressed this by preferring IPv4 over IPv6 when a site replies with both IPv4 and IPv6 records, meaning that it will only use IPv6 when IPv4 connectivity to a site is not available.

One of the simplest ways to deal with all these broken clients is to serve them only on IPv4.

But, how can you tell whether a client has working IPv6 if the majority are still making DNS requests over IPv4? One approach is to provide IPv6 answers only to DNS queries from IPv4 networks that are known to have reliable IPv6 connectivity, which is reportedly the approach Google has taken.

Another approach is to provide IPv6 answers only for DNS queries that come in via IPv6, but this method only moves the problem down one step – instead of clients timing out on WWW requests, they will instead be timing out on DNS requests. Additionally, such an approach means the transition to IPv6 will never actually be accomplished.

About the only solution I can see is to serve clients normally over IPv4 and embed an object (that includes the original IPv4 address in the request) in the page that points at an IPv6 server, thus allowing you to create a list of IPv4 clients that have IPv6 connectivity. Then you would need to tie this information into your DNS infrastructure so that this white list of IPv4 clients would be given IPv6 answers. In other words, to deploy IPv6 for all clients, you need to be willing to drop connectivity with a small group of clients that have broken IPv6 connectivity.

Conclusion

IPv6 is an inevitability; addresses are running out rapidly. To see how rapidly, I suggest getting the Hurricane Electric "ByeBye v4" application [10]. Also, the transition is going to be rather abrupt. Once the regional Internet authorities run low on IP addresses, they will demand increasing evidence that you need addresses. Also, once they run out, you may be able to find recovered IP addresses on the market from companies who are willing to part with unused addresses (for a price).

But, even with a secondary market in IPv4 addresses, you will only gain a few months. Once the addresses run out, they run out. At that point, demand for IPv6-capable equipment, applications, and network administrators will grow very rapidly. Beat the rush now if you can.