IPv6 Overview

Although IPv6 isn’t technically a security technology, this new network transport plays a critical role in many new technologies that do have security implications. Depending on the type of application you’re writing, IPv6 support might be critical; for example, you might choose to implement a game or a collaboration application using the peer-to-peer networking facilities. Even if you’re not creating applications that require IPv6 immediately, it’s always a good thing to keep current.

An obvious reason to create IPv6 is that the original IP (Internet Protocol), known as IPv4 only uses 32 bits for network addresses. Once we subtract out the ranges used for multicast and private address spaces (10.0.0.0/8 and 192.168.0.0/16 are two examples) and then account for wasted address space, we’re clearly going to run out of address space relatively soon. Using NATs helps stave off the inevitable, at the cost of end-to-end connectivity.

As I write this, my home network is behind two NAT devices–a real proxy firewall and a cheap router that accommodates the fact that my ISP regularly changes my address with DHCP–and the ISP has a NAT of its own. To make matters worse, this configuration would be difficult for anyone who didn’t have experience as a professional system administrator. As we move forward, we can foresee needing several network addresses per person and per household, and all of this needs to be easily configured. IPv6 solves most of these problems by design.

One of the most significant changes between IPv4 and IPv6 is that instead of the host portion of an address using a variable number of bits, IPv6 is evenly divided between a 64-bit network address and a 64-bit host portion. This allows for more devices than we’re likely to use on this planet; it works out to several billion available addresses per person. An IPv6 address looks like this:

 fe80::e93a:50e5:6301:aa03

Note that the “::” means some number of sequential zeros. Everything after that sequence is the host portion of this system’s address, and the network portion of the address is fe80:0000:0000:0000, which happens to be the reserved network identifier for link local addresses.

On a typical IPv6 system, there might be a number of assigned addresses; the first would be the link local address, which is only good for the local network segment. When writing applications for IPv4, it can take a good bit of tricky code to restrict your application to just the local network, although the new Windows Vista firewall APIs can help as we’ll see later in this chapter. When you’re writing for IPv6, it’s trivial to just bind your application to the local address, and you won’t need to worry about traffic from outside the network. The second IPv6 address that could be encountered is the site address; it would be used for communications within your enterprise network, but it won’t be passed along by external routers. Finally, if you have a connection to the global IPv6 network, you’d also have a global IPv6 address that’s fully routable. As you can see, we now have several tools available to determine just what the service scope of our applications should be. A fourth type of address you will find on a default installation of Windows Vista is the Teredo “Tunnel Adapter” address; we’ll cover this in more detail shortly.

IPv6 also has a some great features; for example, IPSec is built into the IPv6 requirements; extensibility allows for multiple, arbitrary sized headers; and best yet, autoconfiguration is standard. The current state of running a home network is similar to the bad old days of configuring the interrupts needed by your hardware; eventually, IPv6 will resemble dealing with USB devices–you plug in the network cable and it just works.

If this short overview has sparked your interest, here’s some references that can come in handy:

• IPv6 From Wikipedia, the free encyclopedia, http://en.wikipedia.org/wiki/Ipv6.

• IPv6: The New Internet Protocol, 2nd edition, by Christian Huitema (Prentice Hall 1998).

• Understanding IPv6 by Joseph Davies (Microsoft Press 2002).

• Internetworking with TCP/IP Vol.1: Principles, Protocols and Architecture, 4th edition, by Douglas E. Comer (Prentice Hall 2000).

There are currently many books on this topic, and we’re not asserting these are the best references, just those that we’ve found helpful. Wikipedia has the advantage of staying current, and it has a number of helpful links.

Teredo

Teredo has a somewhat colorful history. Originally, Teredo was known as Shipworm, and the name was created with the idea of enabling applications to transit networks behind NAT devices, but it also gave an entirely different image to people charged with maintaining operational security. Having worms eating holes in the firewalls you put there to protect your network is worthy of horror movies! Possibly due to the connotations of the name “Shipworm,” the protocol was renamed to Teredo, which is really the same thing–the most common type of shipworm has a Latin name of Teredo navalis! Despite the colorful name, Teredo has evolved into one of the more secure and firewall-friendly ways for applications to transit across NAT devices and firewalls.

There are two fundamental problems Teredo is designed to solve. First, there are too many systems behind devices that only support IPv4. We need a way to be able to get IPv6 to a useful state without everyone running out and replacing their home router/firewall devices, not to mention all the Internet service providers updating their networks. Second, most people are behind at least one NAT device, often two. For applications that need end-to-end connectivity (such as peer-to-peer networking, games, and collaboration scenarios), NAT devices are preventing effective solutions from being created.

Teredo works by encapsulating IPv6 on top of IPv4 UDP packets. Although there are other approaches that can be used when we can assume clear end-to-end connectivity, such as on a large enterprise network, Teredo is assuming that NAT devices need to be traversed.

The first thing a client needs to do is send an initial packet to a properly configured Teredo server. The Teredo server is responsible for being able to refer clients to a Teredo relay, and it doesn’t do much else: the goal is for a Teredo server to consume very little network bandwidth. The initial packet consists of an IPv6 ping with a large random number as the payload carried on top of a UDP packet sent to port 3544. The IPv6 portion of the initial packet is then forwarded to the IPv6 address the client is trying to reach, which would then send the reply to the nearest Teredo relay. Thus, the relay can be thought of as a somewhat specialized router.

The relay now needs to be able to put the response back into an IPv4 UDP packet and send it back to the client. It does this by cleverly using portions of the IPv6 address to encapsulate the information needed.

Figure 4-1: Diagram of Teredo initialization.

The first 32 bits of the Teredo IPv6 address is the Teredo prefix: 2001:0000. The next 32 bits contain the IPv4 address of the primary Teredo server that sent the packet, which is followed by 16 bits of flags and some information used to inhibit random scanning attacks. Finally, the actual IPv4 address and the port used by the NAT is obfuscated within the final 48 bits. We now see that the relay has all the information needed to reconstruct the UDP reply packet and send it to the client.

You may be wondering how UDP packets sent to one host will get back to you if another host replies. The answer is that you have 4 different types of NAT devices in general use:

• Full cone–A full-cone NAT establishes an external UDP port when sending an outbound packet and will forward traffic sent to that port from any IP address and any port back to the originating port on the internal system. This doesn’t sound very secure, and it isn’t–this “feature” is why you should never depend on an NAT for security. It does conserve resources on the NAT device, which is the primary design goal of this type of system.

• Restricted cone–This type of NAT maintains some level of state and requires that replies come from the same IP address as the initial request was sent to.

• Port-restricted cone–Replies must come from the same IP address and port as the request.

• Symmetric–In addition to the requirements for a port-restricted cone NAT, the symmetric NAT will create a new mapping of internal IP address and port to external IP address and port for traffic sent to every individual external host. This type of NAT is somewhat more secure and is typically only seen in fairly expensive higher-end firewalls.

Some newer NAT devices can also appear to be port restricted under some conditions and symmetric under others:

In particular, we found out that many NAT have a 5th strategy, “port conservation.” Basically, they will try to keep the same port number inside and outside, unless it is already used for another connection, in which case they pick a different one either sequentially (from a global variable) or randombly. These NATs appear typically “port restricted” during the tests, but behave as “symmetric” under load. (Huitema, personal communication)

If you’re interested in the details, consult RFC 3489 (Rosenberg et al. 2003).

Back to our Teredo relay! It will send the reply back to the Teredo client. If the reply reaches the client, the client then knows it is behind a cone NAT. There are a number of scenarios that can come into play, but the primary thing is that the Teredo relay will attempt to get out of the relay business entirely and just let the clients exchange packets directly, which can be done when two IPv6 systems are behind different Teredo-compatable NAT devices.

What all of this means to you is that it is now possible to create applications that can deal directly with one another, even if they are behind NAT devices. You get end-to-end connectivity, and, as IPv6 becomes ubiquitous, it will continue to work, just better.

There are some security implications of Teredo. If you’re operating a firewall, the protocol is designed to be completely transparent. If you don’t want to allow Teredo, just block one UDP port; if you wanted to selectively manage Teredo traffic, all the information you need is available so that it should be easy to write a Teredo-specific packet handler–and it would be very efficient. Out of all the tunneling approaches currently in use, this one is one of the easiest for the network administrators to deal with–which is smart because happy and secure network admins are less likely to just block your traffic. On the client side, a socket has to specifically request that it would like to accept Teredo traffic on Windows XP, and on Windows Vista, Teredo traffic is controlled by the firewall settings, so the only applications on your system exposed by Teredo would be those that expect to deal directly with the Internet. In later sections, we’ll show you how to create host-based firewall rules that explicitly allow or deny Teredo.