Eventually, we’ll wind up in a situation where we have “IPv6-only” network stacks and will simply connect out to the network via IPv6. Whether that will occur in our lifetimes, though, is an open question. The reality is that we will be using “dual-stack” systems throughout the “transition” from IPv4 to IPv6 and potentially for quite some time after that. The challenge with dual-stack systems is in verifying that your application can in fact access both IPv4 and IPv6 network stacks—and that your application does choose to bind to both network stacks.

var http = require('http'),

var handler = function (request, response) {
   response.writeHead(200, {"Content-Type":"text/plain"});
   response.end ("Hello World!
");
   console.log("Got a connection from " + request.connection().stream.remoteAddress);
};

var server= http.createServer();
server.addListener("request",handler);
server.listen(80,"198.51.100.22");

console.log("Server running on localhost at port 80");

server.listen(80,"198.51.100.22");

var http = require('http'),

var handler = function (request, response) {
   response.writeHead(200, {"Content-Type":"text/plain"});
   response.end ("Hello World!
");
   console.log("Got a connection from " + request.connection().stream.remoteAddress);
};

var server= http.createServer();
server.addListener("request",handler);
server.listen(80,"198.51.100.22");

var server6= http.createServer();
server6.addListener("request",handler);
server6.listen(80,"2001:db8:42d7::2");

console.log("Server running on localhost at port 80");

Another challenge with IPv6 is that each network interface can have multiple IPv6 addresses. Right from the start, each interface is going to have a link-local IPv6 address by default. Assuming you have real IPv6 connectivity, each interface will also have a global IPv6 address (even if “global” actually means within your network). You also can assign additional IPv6 addresses to each network interface.

Which address should your application use?

The truth is that you shouldn’t have to worry about this choice. RFC 3484, Default Address Selection for Internet Protocol version 6 (IPv6), defines a selection algorithm that must be implemented by IPv6 network stacks. You should just be able to trust the operating system here…but it’s important to consider if you are trying to debug any connection issues or if your application works directly with network interfaces.

One other fact about IPv6 addresses that you may need to be aware of is that the IPv6 address for a given system may change over time if “privacy extensions” are enabled.

To explain what is going on, let’s back up a step and talk about the “autoconfiguration” of IPv6 addresses. As explained in RFC 4862, IPv6 Stateless Address Autoconfiguration, systems on an IPv6 network do not need to use the Dynamic Host Configuration Protocol (DHCP) to receive their IPv6 addresses. Instead, a system can automatically create the IPv6 address by combining a “router advertisement” sent out by the local router with a unique identifier for the network interface. The router advertisement provides the “network” portion of the IPv6 address and the unique identifier for the interface provides the “host” portion of the IPv6 address.

In practice, this “unique identifier” is the IEEE identifier burned into the network interface card at its time of manufacture, commonly known as its “MAC address” or “Ethernet address.” Thus, the creation of an IPv6 address looks like this:

This works wonderfully and provides a very easy way for a system to autoconfigure itself and connect out to the network. There is no need to wait for a DHCP exchange to get on the network. Moving between subnets is also trivial, as the system can simply autoconfigure itself on the new subnet as soon as it gets the router advertisement with the new network prefix.

Now, one problem with this approach is that the host portion of the IPv6 address is now globally unique, which is a very different concept from IPv4. If you were to go around with your laptop or mobile phone from one IPv6 network to other IPv6 networks (perhaps in that far-off day when cafes all have IPv6 WiFi), you would leave a trail of where you had been, based on the unique host portion of your IP address. An attacker with access to network traces or address logs could do some data mining and correlate your network usage across multiple networks, conceivably learning your location or gaining some insight into the type of traffic you generate and applications you use.

Additionally, an attacker even just watching your IPv6 packet stream go across a network could make guesses as to the type of system you had, based on the autoconfigured host address, and tweak his or her attacks to work with your operating system or device type.

Because of these security and privacy concerns, the IETF came out with RFC 4941, Privacy Extensions for Stateless Address Autoconfiguration in IPv6. If this is enabled on a computer, two things will happen:

The primary issue here for you as an application developer is the temporary nature of these IPv6 addresses if you have some reason to rely on an IPv6 address for an extended period of time. You may need to account for this possibility of changing addresses or focus instead on using domain names that could be dynamically updated by the systems when the IPv6 address is changed.

Diving again down into the weeds, if you want to send large blocks of data with IPv4, your network stack would send the packets out on the local network using the maximum transmission unit (MTU) of the underlying network (for example, Ethernet or PPP). If somewhere between your application and the destination there was a network segment with a smaller MTU, the router or other network device connected to that segment would fragment individual packets if necessary to fit the smaller MTU. The packets would then need to be reassembled at the destination.

However, in IPv6, such fragmentation in the network path is not allowed. Instead, IPv6 uses Path MTU Discovery, defined in RFC 1981, to find the smallest MTU in the path between the source and the destination. Once the Path MTU is found, all packets are sent from the source with that MTU. In theory, this would let IPv6 connections make use of underlying network technologies with larger MTU sizes. In practice, however, what this means is that basically all packets are sent on a typical Ethernet network with the minimum MTU of 1280 defined in Section 5 of RFC 2460.

Does your application rely on either multicast or broadcast packets in IPv4? If so, you need to be aware that these aspects of IP have fundamentally changed in IPv6. A full discussion of the changes is beyond the scope of this book, but suffice it to say that there is no longer any concept of a “broadcast” packet—and multicasting is baked into the core of IPv6. To learn more about multicast addresses in IPv6, you can read section 2.7 of RFC 2373 and then RFC 3306, which extends IPv6 multicast addressing to allow the dynamic allocation of multicast addresses. O’Reilly’s IPv6 Essentials also has a good section on the changes in multicast addressing in IPv6.

At an application level, the security aspects of IPv6 are very similar to IPv4. You still will have firewalls. You will still need services to traverse the firewalls. In Linux and UNIX systems, you still have the iptables command, although for IPv6 it may be ip6tables instead. You still have port numbers, services…at the application layer, IP security is still very much the same as IPv4. (Down at the network layer, however, it has changed substantially.)

Two items you should know about, though. First, IPSEC is now mandatory for every IPv6 stack. With IPv4, you often had to install additional software to support IPSEC. With IPv6, IPSEC is baked into the core of the protocol and is mandated to be available. Note that this does not mean that IPSEC is enabled—it just means that it has to be available. If your application needs transport encryption, IPv6 may make that a bit easier.

Second, while it is incredibly easy to set up an IPv6 tunnel via free services such as Tunnelbroker.net and put your office or test lab on the IPv6 Internet, please remember that when you use a service like this you are directly connected to the public Internet! There is no NAT or firewall in the way: you have a direct connection from whatever machine is the tunnel endpoint out to the public IPv6 Internet. Please make sure that you are running some type of IPv6 firewall on that system to protect your system and network.

Finally, a note about Network Address Translation, a.k.a. NAT. We have all gotten used to NAT and its companion, Port Translation, in IPv4 networks. Probably all of our home networks and the vast majority of business networks use NAT to hide the entire internal network behind a single public IPv4 address.

We had to use NAT. There simply weren’t enough IPv4 addresses.

And even now, with IPv4 address allocations exhausted, some ISPs are considering so-called Carrier-Grade NAT or Large Scale NAT as a way to hide their entire network behind a single public IPv4 address, thus extending even further the lifetime of IPv4 usage.

However, NAT creates numerous problems in terms of network architecture, many of which are enumerated in RFC 2993 and countless other documents and articles online. On a fundamental level, NAT breaks the “end-to-end” principle, where the intelligence resides in the network endpoints and they are able to reach other endpoints by direct addresses. RFC 4924 provides a recent summary of the end-to-end principle. For instance, endpoints that use real-time communications using the SIP protocol are unable to communicate with another endpoint across a NAT device without some kind of assistance in terms of an application-layer gateway (ALG), SIP-aware firewall, or session border controller (SBC). All of these add complexity and challenges to the SIP-based communication.

The promise of IPv6 is that with such a large address space there is no longer any need for NAT. NAT can die. This point has been argued quite forcefully within the IETF in many documents, including RFC 4864, Local Network Protection for IPv6. The reasoning is extremely solid and makes a compelling case.

However, the reality of IPv6 is that we will still see NAT being deployed with IPv6. Certainly within many enterprises, network architects and administrators have become wed to NAT for a variety of reasons and will continue to use NAT for both IPv4 and IPv6. Instead of RFC 1918 private IPv4 addresses and firewalls with NAT, they will use RFC 4193 Unique Local Addresses (ULAs) for IPv6 and firewalls with application-layer gateways (ALGs). The results will be the same: an internal network using private, nonroutable addresses connected out to the global network through a limited number of public addresses.

A July 2010 document from the Internet Architecture Board (IAB) captures the thinking from the two sides quite well: RFC 5902, IAB Thoughts on IPv6 Network Address Translation. It includes this problem statement:

The document goes on from there to discuss each of these concerns, the architectural issues around NAT, and potential solutions. The document concludes with the understanding that NAT will be deployed for IPv6 if adequate solutions are not found for the reasons why NAT is desired.

The religious war between those who see NAT for IPv6 as inherently evil and those who see NAT for IPv6 as incredibly useful will undoubtedly continue for quite a long time.

For you as an application developer, there are a number of key points to consider:

No easy answers, unfortunately.