IPv6 has far more to recommend it than merely providing a vastly larger pool of IP addresses. Here are some handy bullet-pointed highlights:
Network autoconfiguration (say goodbye to DHCP)
No more private address collisions
Better multicast routing
The newfangled anycast routing
Network Address Translation (NAT) becomes an option, rather than a necessity
Simplified, more efficient routing and smaller routing tables
Genuine quality of service (QoS)
Good-quality streaming media delivery
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.
IPv6 addresses are not dotted-decimal like IPv4, but base-16 numbers expressed in hexadecimal. So, you count like this:
0 1 2 3 4 5 6 7 8 9 A B C D E F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
When your lefthand digit gets to 9, you roll over to letters to keep going:
90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 BA BB BC BD BE BF
IP addresses start out as binary numbers. We use hexadecimal notation for convenience. Don't worry about managing these larger addresses because ipv6calc will do the calculating for you.
Mac OS X has excellent IPv6 support, which should work out of the box.
Support for IPv6 in Microsoft Windows is a bit of a hodgepodge. Windows Vista, Windows Server 2008, Windows Server 2003, Windows XP with Service Pack 2, Windows XP with Service Pack 1, Windows XP Embedded SP1, and Windows CE .NET include native IPv6 support.
Windows 2000 admins can try the MS Tech Preview IPv6 stack. It's not intended for production systems, but for testing:
tpipv6-001205-SP2-IE6.zip, SP2
tpipv6-001205-SP3-IE6.zip, SP3
tpipv6-001205-SP4-IE6.zip, SP4
Instructions are at http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp.
Admins of Windows 95/98/ME and NT systems can try Trumpet Winsock v5.0.
For the least hassle and hair loss, you'll want the later Windows editions with native IPv6 suppport.