Chapter 15. Getting Acquainted with IPv6

IPv6 has far more to recommend it than merely providing a vastly larger pool of IP addresses. Here are some handy bullet-pointed highlights:

In short, it promises to make the life of the network administrator significantly easier, and to make a whole new generation of high-quality on-demand streaming audio and video services a reality.

In this chapter, you'll learn the basics of using IPv6: network addressing, autoconfiguration, network interface configuration, ad-hoc IPv6 LANs, and how to calculate IPv6 addresses without needing hundreds of fingers to count on.

IPv6 adoption is proceeding slowly in the U.S., but it is inevitable. It doesn't cost anything but a bit of time to get acquainted with it in your test lab. Linux has supported IPv6 since the later 2.1.x kernels, and most of the important Linux networking utilities now support IPv6.

Most of the pieces are in place: most networking hardware (e.g., switches, interfaces, routers) supports IPv6 now. Cameras, cell phones, PDAs, and all manner of devices now support IPv6. Growing numbers of Internet service providers offer native IPv6, and you can set up an IPv6-over-IPv4 tunnel that works over existing networks, which is good for practice and testing. Standards and protocols are pretty much hammered out and in place.

The two final pieces that are needed are first, application support (because networked applications must explicitly support IPv6), and second, service providers actually migrating to native IPv6. Some network engineers predict that the majority of ISPs will not get serious about it until the day they call up their Regional Internet Registry (RIR) to get more IPv4 addresses, and their RIR regretfully informs them that there aren't any more.

The barriers to faster IPv6 adoption are the usual suspects: cost, inertia, and lack of knowledge. The scarcity of IPv4 addresses means they are nice little revenue-generators because ISPs typically charge extra for static, routable addresses. This will change with IPv6—I will let the numbers speak for themselves. There are theoretically:

4,294,967,296

IPv4 addresses available because IPv4 uses a 32-bit address space. In contrast, there are theoretically:

340,282,366,920,938,463,463,374,607,431,768,211,456

addresses available under IPv6 because it is a 128-bit address space. In practice, because of reserved addresses and the way in which blocks of IPv4 addresses are allocated, the usable pool of IPv4 addresses is reported as 3,706,650,000, or about three-fourths of the theoretical total. The U.S. owns nearly 60 percent of these. (For details, see the "BGP Expert 2006 IPv4 Address Use Report" at http://www.bgpexpert.com/addrspace2006.php.)

The actual number of available IPv6 addresses is somewhat smaller than the theoretical number, but not enough to matter here on planet Earth. If we ever expand to a galaxy-wide Internet, then we'll need more addresses, but we'll cross that bridge when we come to it.

Interestingly, while the U.S. hogs the IPv4 address space, it lags considerably behind other countries in IPv6 adoption and affordable high-speed broadband. Many U.S. ISPs do dominate in one area: silly terms of service that forbid running servers, sharing your Internet connection, or supporting any operating system other than Microsoft Windows (which we know is ridiculous—favoring the most notoriously porous operating system, with all of its well-known security flaws and tens of thousands of Internet-clogging botnets is a policy direct from the planet Bizarro). Trying to control how many users share a single Internet connection is like charging per-user for tap water.

So, IPv6 uptake is more motivated in countries outside the U.S. Japan and the European Union lead in IPv6 adoption, and also in advanced broadband and wireless services.

IPv6 is not backward-compatible with IPv4. We're going to have IPv4 and IPv6 running side-by-side for some time, with all the added complexity and overhead that comes with that. But eventually, IPv4 is going to go away.

IPv6 addresses contain eight dotted quads totaling 128 bits, as this example of a global unicast address shows:

	2001:0db8:3c4d:0015:0000:0000:abcd:ef12

An IPv6 global unicast address is like a static, publicly routable unicast IPv4 address, such as 208.201.239.36 (one of oreilly.com addresses). These are globally unique addresses controlled by a central registrar. (For a list of regional registrars, see ICANN.org at http://aso.icann.org/rirs/index.html.)

In the IPv4 world, the provider's prefix can consume up to the first three dotted quads. whois shows us that the service provider's prefix eats up three-fourths of the oreilly.com address:

	$ whois 208.201.239.36
	[...]
	SONIC.NET, INC. UU-208-201-224 (NET-208-201-224-0-1)
	                    208.201.224.0 - 208.201.255.255

If O'Reilly wants more addresses, it has to get them assigned from its upstream service provider. IPv4 addresses are doled out in a miserly fashion; a small customer might get lucky and get five, and a bigger customer can, with a bit of luck, get a larger number. It is unlikely that either one will receive enough to provision their whole organization, but either one will have to use nonroutable private addresses behind NAT. But, no matter how generous the service provider is, they can't come close to a typical IPv6 assignment, which is 2^64 active hosts per subnet. Spelled out, that totals:

	18,446,744,073,709,551,616

That is a pool of globally unique, routable addresses just for you, times your number of subnets, which can be as many as 65,536. This should be sufficient to meet your needs.

Let's dissect our example IPv6 global unicast address:

	2001:0db8:3c4d:0015:0000:0000:abcd:ef12
	______________|____|___________________
	global prefix subnet Interface ID

Each quad is 16 bits. The global prefix is assigned by an ISP to its customers. Typically, this is /48 bits, as shown here, but it can vary; a large company might get /32, and a small company /56. This portion is not something you can arbitrarily change because it is assigned to you by your service provider. So, the network portion of the address is the first 64 bits, and the host portion is the remaining 64 bits. Even though it is a larger number, this is simpler than remembering all of those different IPv4 address classes and many ways to make subnets.

The next quad is for your own use for subnetting. With 16 bits to play with, this means you can have 65,536 subnets all for your very own.

The final 64 bits is the interface ID, or the network interface's address. This is often derived from the 48-bit MAC address of the network interface card, but this is not a requirement. Just like the subnet portion, you may use this however you want. So, under IPv6 you won't be a beggar any more, but truly the lord of your own domain.

These are the address ranges you'll be most concerned with. These are assigned by the Internet Assigned Numbers Authority (IANA) http://www.iana.org/assignments/ipv6-address-space. All the other addresses are reserved:

	IPv6 Prefix     Allocation
	--------------------------------
	0000::/8        Reserved by IETF
	2000::/3        Global Unicast
	FC00::/7        Unique Local Unicast
	FE80::/10       Link Local Unicast
	FF00::/8        Multicast

These blocks are reserved for examples and documentation:

	--------------------------------
	3fff:ffff::/32
	2001:0DB8::/32 EXAMPLENET-WF

The loopback address and IPv6 addresses with embedded IPv4 addresses come from the 0000::/8 address block. Your Linux system probably comes with IPv6 addressing already enabled:

	$ ifconfig
	eth0       Link encap:Ethernet HWaddr 00:03:6D:00:83:CF
	           inet addr:192.168.1.10 Bcast:192.168.1.255 Mask:255.255.255.0
	           inet6 addr: fe80::203:6dff:fe00:83cf/64 Scope:Link
	           UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
	           [...]
	lo         Link encap:Local Loopback
	           inet addr:127.0.0.1 Mask:255.0.0.0
	           inet6 addr: ::1/128 Scope:Host
	           UP LOOPBACK RUNNING MTU:16436 Metric:1
	           [...]

Scope:Link, or the Link Local Unicast address for eth0 means this is a private, non-routable IPv6 address that operates only within a single subnet. Link Local addresses are for easily throwing together ad-hoc networks, such as for conferences or meetings, and on most Linux distributions are created automatically.

Scope:Host for lo is the loopback address, which means packets from this address never leave the host.

Unique Local Unicast addresses are similar to Link Local Unicast addresses. They are meant to be routable locally, but not over the Internet. Link Local addresses may not always be unique, so you have a risk of address collisions; Unique Local Unicast addresses have a globally unique prefix, and are independent of any service provider, so they give you a unique private class of addresses to use internally.

Multicast in IPv6 is similar to the broadcast address in IPv4, with some useful differences. A packet sent to a multicast address is delivered to every interface in a defined group. So, it is targeted—only hosts who are members of the multicast group receive the multicast packets. Routers will not forward multicast packets unless there are members of the multicast groups to forward the packets to, which pretty much spells the end of broadcast storms. They always start with ff.

Where are these multicast groups defined? For a complete listing, see "IPv6 multicast addresses" at http://www.iana.org/assignments/ipv6-multicast-addresses.

An anycast address is a single address assigned to multiple nodes. A packet sent to an anycast address is then delivered to the first available node. This is a great way to provide both load-balancing and automatic failover. Several of the DNS root servers use a router-based anycast implementation. Anycast addresses can only be used as destination addresses, and not source addresses. Anycast addresses come from the unicast address space, so you can't tell from the prefix that they are anycast addresses.

You've probably seen 3FFE::/16 addresses in various How-tos. These were for the 6Bone test network that shut down in June 2006, so they don't work anymore.