Microsoft’s support for IPv6 is quite thorough, albeit relatively recent and unfortunately geared towards for their current and future products more than their past ones. Microsoft’s plan for IPv6, and numerous useful articles are available at http://www.microsoft.com/ipv6.

The Unix-like layer, Darwin, that underlies Mac OS X supports IPv6 as of version 10.2 (Jaguar) and automatic configuration is enabled by default. While many of the lower level Darwin utilities support IPv6, this has not yet percolated upwards to most familiar Mac OS applications. In essence, this means that most of the command line tools support IPv6, including ping6, traceroute6, telnet and so on, but things like iSync, iPhoto, etc., don’t necessarily. One thing that’s missing in 10.2 is IPv6 support in ssh.^[6] Naturally, OS X’s IPv6 support derives from the KAME project, so resources and documentation for KAME will apply usefully to OS X. Version 10.3 of Mac OS X is based on FreeBSD 5.x and also supports IPv6.

Panther (OS X version 10.3) extends the IPv6 support introduced in Jaguar into the OS X network control panels and also into a number of subsystems, including allowing DNS lookups over IPv6, IPv6 personal firewalling and IPv6 support in ssh.

As far as we’re aware, you’re out of luck if you want to run IPv6 on Mac OS 9 or anything earlier.

IPv6 in the Linux kernel has a slightly uneven history. Initial support began in 1996, with contributions by Pedro Roque, who later went on to work for Cisco. Under-resourcing got the better of developer effort some while thereafter, and the stack quality suffered, with the result that a project called USAGI was started in Japan in late 2000, whose aim was to bring the kernel implementation up to spec with the reality of what the RFCs required. Thankfully things these days are a lot better; most of the Linux vendors have brought their stack into shape with the relevant USAGI patches, and if you are running a 2.4.x (or better) kernel, many of the more egregious faults with 2.2.x are no longer a problem. The USAGI patches provide things like ICMPv6 node information queries, IPsec support, and fix a number of bugs. If any of these are important to your network, you may want to investigate applying these patches.^[7]

To get IPv6 working with Linux, you must first distinguish between the kernel and the distribution or userland that you happen to be running. All modern kernels (=>2.2, but you really want =>2.4) support IPv6—you can either compile it into the kernel statically, following the standard Linux kernel compilation instructions, or use a module. Most modern Linux software vendors will ship this as the module ipv6.o. The kernel module supplies the ability to actually speak the protocol; the userland tools supply the ability to work with it. It is unfortunately possible, although unlikely, to have kernel support but no userland support, and vice versa.

A lack of userland support is the easiest problem to remedy: simply download the relevant RPMs and install them.

If you are missing kernel support and the ipv6.o module is not provided then you will have to recompile your kernel.^[8] Recompiling your kernel is something that your Linux distributor should provide documentation for. In general, it involves going to where your kernel sources are, generally /usr/src/linux, typing make menuconfig, selecting IPv6 under Networking Options, saving your changes and then doing make bzImage, but the your vendor’s documentation should be your guide here. One complication you might encounter is that IPv6 may be marked “Experimental” and hence might not be shown as a selectable option unless you indicate that you want to see experimental options under menuconfig’s Code Maturity Level Options. Note that while you are adding IPv6 support, you may also want to enable the IPv6 firewalling support (a.k.a. netfilter/iptables) as well.

If you are wondering whether your current kernel has IPv6 support, there are two quick tests you can do. If you are using a software vendor’s distribution, try the simple modprobe ipv6. That should load the module in question (lsmod | grep -w ^ipv6 should report the presence of the module if you want to be extra sure). If that doesn’t work, perhaps because the kernel has it statically compiled in, then check out the contents of /proc/net/—network protocols register their presence here when they are loaded, so if_inet6 and igmp6 will be present if the kernel had IPv6 compiled in.

Of course the kernel itself has some knobs allowing you to change its IPv6 behavior more to your satisfaction. Possibly the most useful of these is being able to turn off address autoconfiguration on a per-interface basis by running echo 0 > /proc/sys/net/ipv6/conf/eth0/autoconf where eth0 can be replaced by the relevant interface name. This only disables address configuration, but other information like default routes can still be learned from router advertisement packets. You can more completely disable the processing router advertisements with echo 0 > /proc/sys/net/ipv6/conf/eth0/accept_ra. Both of these commands have a system-wide equivalent, but we’ve found it simpler and more reliable to use the per-interface settings.

The first place to go to if you want to find out more is Peter Bieringer’s wonderful IPv6 resources at http://www.bieringer.de/linux/IPv6/, which provide not only useful resources for IPv6 users under Linux, but also a wealth of information about IPv6 support in various applications and services on all Unix-like platforms.

We deal with the different distributions below.

NETWORKING_IPV6="yes"

IP6ADDR="<IPv6 address>/<prefix length>"

iface sit1 inet6 v4tunnel
        address <your end>
        netmask <tunnel netmask>
        endpoint <tunnel broker IPv4 address>
        up ip route add 2000::/3 via <their end>

iface eth0 inet6 static
        pre-up modprobe ipv6
        address 2001:db8:1234:5::1:1
        netmask 64

From Solaris 8 onwards, IPv6 is included in the normal Solaris installation process, and you are asked if you want to configure IPv6 during the install. There is good coverage of both IPsec and IPv6 in the networking sections of the Solaris Administration Guide, available online at http://docs.sun.com/.

Sun have always been advocates of NIS, and have extended the Solaris Name services to deal with IPv6. The traditional /etc/hosts database, which is actually a symbolic link to /etc/inet/hosts, is only used for IPv4 addresses in Solaris. A new database, /etc/inet/ipnodes, can be used for both IPv4 and IPv6 name lookups: which of these is used can be controlled with settings in /etc/nsswitch. If the hosts database is commented out, the ipnodes database will be used for all lookups.

People familiar with Solaris may remember that the IPv4 address for an interface is stored in the file /etc/hostname. ifname. Similarly, the IPv6 configuration of an interface is controlled by /etc/hostname6. ifname. As with IPv4, this file can contain a numerical address, or a hostname to be looked up using the Solaris name service. It is also possible to leave this file empty, which will cause the interface to use IPv6 autoconfiguration. Autoconfiguration is managed by the in.ndpd daemon, which sends Router Solicitation messages and acts on the Router Advertisements received.

The ping and traceroute commands both support IPv4 and IPv6. Specifying an IPv4 address causes these commands to use IPv4. Specifying an IPv6 address causes these commands to use IPv6. Specifying a hostname causes the commands to use IPv6, if the host has an IPv6 address and IPv4 otherwise. You can explicitly choose address family by using the flags -A inet4 and -A inet6 respectively.

There are IPv6 patches for some earlier versions of Solaris available from Sun, however these were considered “developer” quality.

IPv6 should be available in AIX from version 4.3.3 onwards. Autoconfiguration can be enabled from AIX’s SMIT configuration tool under the following menus: Communications Applications and Services → TCP/IP → IPV6 Configuration → IPV6 Daemon/Process Configuration → Autoconf6 Process → Start Using the Autoconf6 Process. In addition, you will want to enable ndpd-host, also available under the IPV6 Daemon/Process Configuration menu.

AIX’s version of ping and traceroute includes support for IPv6. Utilities such as telnet also include IPv6 support. The IPv6 support in AIX is based on work at INRIA.

Although not strictly related to AIX, IBM also offer a prototype IPv6 implementation for OS/390.

Version 5.1 of Tru64 contains basic IPv6 support. The first step is to make sure your kernel supports IPv6; if you’ve built or installed a kernel with support for all optional features, then it will contain IPv6 support. Otherwise, you’ll need to configure your kernel with doconfig -c KERNELNAME, choose to include the IPV6 option, install it with cp /sys/KERNELNAME/vmunix /vmunix and reboot.

A script, /usr/sbin/ip6_setup, is provided to make enabling IPv6 easier. It will ask you if you have network interfaces on which you want to enable IPv6, and if you want to configure tunnels for IPv6 connectivity. As a minimum, you can tell it to configure IPv6 on your Ethernet interface, probably tu0, then tell it to save the changes and start IPv6 networking.

The usual ping and traceroute commands support IPv6 in Tru64, with a flag -V 4 or -V 6 to determine the version of IP to use (IPv6 is the default for hostnames with both types of addresses). Other base utilities such as telnet and ftp support IPv6. The version of ssh shipped with Tru64 5.1 seems to support IPv6, but prefers IPv4 DNS records over IPv6, so you need to give explicit IPv6 addresses on the command line, or only have quad A records in your internal DNS for servers to which you want to ssh using IPv6.

The Tru64 Network Administration Manual contains both an introduction to IPv6 and details of how it can be configured under Tru64.

The IPv6 support in FreeBSD is based on the work by the KAME group. Initially it was available as a set of patches to FreeBSD, but IPv6 has been a shipping feature of the FreeBSD distribution for some time, and is included in the standard `GENERIC’ kernel. In fact, it is possible to install FreeBSD over IPv6 if you choose an IPv6 enabled FTP server during the setup process.

If, for some reason, IPv6 is not present in your kernel you will need to recompile it after adding the options INET6 line to your kernel configuration (full details of how to recompile your kernel are in the FreeBSD handbook at http://www.freebsd.org/handbook/).

IPsec is also incorporated into FreeBSD and more recent releases include support for hardware acceleration of IPsec. However, IPsec is not part of the GENERIC kernel, and may require a kernel recompilation after the addition of options IPSEC and options IPSEC_ESP to your kernel’s configuration file.

Most of the FreeBSD base applications support IPv6 including ssh, telnet, ftp, sendmail, and inetd. Where possible, additional software from the FreeBSD ports/packages system is compiled with IPv6 support; there’s even a ports category specifically for IPv6 software!

To enable the boot-time configuration of IPv6 on FreeBSD, you must add a line ipv6_enable="YES" to your /etc/rc.conf file. Other configuration options for the setting up of tunnels, routing and so on, are listed in /etc/defaults/rc.conf under the “IPv6 options” heading.

Naturally, the list of operating systems that now support IPv6 goes on and on. The list above is just a sample of the operating systems commonly associated with IP networking, biased by the authors’ experience. Let’s take a moment to glance at some of the other OSs in this area.

BSDi, NetBSD, and OpenBSD certainly warrant a mention, as they are other platforms based on the KAME IPv6 code and have supported IPv6 for several years. On these platforms, the command line utilities will be similar to those on FreeBSD and Mac OS X, though boot-time configuration knobs will differ slightly. It is also worth noting that if you require up-to-the minute IPv6 features, KAME provide snap kits of their development work for various platforms. These are available from the KAME web site http://www.kame.net/ but are strictly for the courageous expert.

IPv6 support for SGI’s Irix has been available as a beta release for some time to people with support contracts. Since February 2003 it has been available in the normal releases of Irix 6.5.19 and above. Similarly, IPv6 is available for HP-UX 11i from the HP web site, http://www.hp.com/products1/unix/operating/internet/ipv.html. The IP stack shipped with VMS and Multinet both support IPv6.

Cisco detail support for IPv6 across their various routers on their web site at http://www.cisco.com/ipv6/. However, IPv6 performance varies from platform to platform.

For software-based routers, such as the 2500, 2600 and 7200, it is possible to achieve respectable IPv6 performance at the current time with just an IOS upgrade. Maximum speeds are not yet on a par with IPv4, and many of the more complex features haven’t been implemented for IPv6 yet, but this should improve as releases continue.

Cisco IOS support for IPv6 first appeared on the public radar with the 12.2T stream. As a “new technology” release, some readers may be familiar with the T streams if they are using other new features. Like all new technology releases, it has a rather large memory footprint, and may contain other new features that one may not wish to deploy in production yet.

The 12.3 stream is the first mainline IOS stream with support for IPv6. Cisco provides TAC support for the IPv6 features of 12.3. This is also a fairly hefty piece of code, and older equipment might require memory upgrades in order to support it.

An alternative is the 12.2S stream which appeared in 2004. It is aimed at service providers who wish to use IPv6 in a smaller package more tuned to their needs, or who are reluctant to make the leap to 12.3 mainline for a single feature. At the time of writing, this is also the stream on which IPv6 support for layer 3 switches, such as the Catalyst 6500/Cisco 7600, is based.

For hardware-based routers, such as the 12000 series, the situation is rather different. The 12.0S stream of code now supports IPv6 in its more recent incarnations, and a number of ISPs are using this in their backbones. However, performance of these routers is dependent on hardware support in the linecard, not the central routing processor, and this could mean expensive upgrades. Engine 3 linecards support IPv6 in hardware; Engine 0, 1, 2 and (perhaps surprisingly) 4+ linecards only support IPv6 with software forwarding, with a much lower throughput. Engine 5 linecards were promised but not yet available at the time of writing, so check with your equipment vendor for more details on those.

To discover the types of linecard already deployed in a 12000 series router, use the show diag command—it is listed for each slot on the line starting “L3 Engine:”.

If you have a mix of cards, the throughput you may achieve depends on the input interface; if it’s capable of native IPv6, you should achieve reasonable traffic rates, regardless of the output interface. If it’s not, the packet will be forwarded in software, with a much lower maximum throughput. For those providers who use MPLS in their backbone, Cisco suggests 6PE, a method of transiting traffic from a dual-stacked provider edge (presumably based on 7200/7500 routers or similar) over an IPv4-only core, using MPLS tunnels. This might be an excellent workaround for an organization already familiar with MPLS, but those who aren’t already using MPLS might think twice about deploying it solely for IPv6.

IPv6 configuration on Cisco is typically straightforward, especially if one is already familiar with the procedure in IPv4. IOS commands are generally derivable from the names of their predecessors by the simple expedient of replacing “ip” with “ipv6” (s/ip/ipv6/ for all you regexp fans). This works for commands like show ipv6 route and show ipv6 interface. However, there are ipv6 specific commands like show ipv6 neighbors and ipv6 unicast-routing.

In BGP land, there have been some subtle changes; sh ip bgp becomes sh bgp ipv6. Also, when you configure your first BGP session over IPv6, you might get a bit of a shock when you look over your configuration; the IPv4-specific parts are moved automagically into their own section. We’ll deal with this in more detail when we discuss routing in Section 6.3.3 in Chapter 6.

Juniper have been offering IPv6 support in JUNOS for some time; most of the features arrived in JUNOS 5.1 or JUNOS 5.2. This support covers the core parts of IPv6: the protocol itself, forwarding, IPv6 over various media and the all routing protocols you’d expect. Hardware support extends to all Juniper’s platforms and interface cards.

Again, the obvious commands are fairly similar to their IPv4 equivalents—or in many cases, show IPv6 information alongside IPv4. Like Cisco, ping on Juniper will attempt IPv6 if it is available. Unlike Cisco, show bgp summary lists IPv4 and IPv6 sessions in sequence.

To configure an IPv6 address on an interface, one substitutes family inet6 for family inet. Example 5-1 shows the configuration of a dual-stacked Fast Ethernet interface on a Juniper router.

interfaces{
    fe-1/0/0 {
        description "HEAnet Cork PoP LAN";
        unit 0 {
            family inet {
                address 193.1.199.75/26;
            }
            family inet6 {
                address 2001:0770:0800:0003::1/64;
            }
        }
    }
}

One important note about Juniper’s IPv6 support is that if you plan to use IPv6 tunnelled over IPv4 (configured tunnels, 6to4 etc.), then you’ll need to have a suitable processor to do the encapsulation and decapsulation. For example, the devolved architecture of M-series routers doesn’t allow the router’s CPU to get bogged down in intensive tasks like forwarding packets over tunnels. You may need an a tunnel services PIC or a adaptive services PIC. Some routers, such as the T-series, don’t need extra hardware.

Table 5-1 show a summary of how to enable IPv6 at boot on the various operating systems we are considering. Once IPv6 is enabled, the boot-time behavior of most platforms is to perform autoconfiguration, unless they are explicitly configured otherwise. As it may not be easy to restart the network subsystem to initialize IPv6, Table 5-2 shows how to configure IPv6 and enable autoconfiguration while the system is actually running. This may be useful during your initial experimentation. In fact, on some systems, squeezing variations on these commands into a user-editable part of the boot sequence is the only way to introduce persistent IPv6 configuration. Caveat configurator.

Of course, if you do not have an IPv6 router on your network, autoconfiguration isn’t much use. You can do the initial testing with link-local addresses, but manually configuring addresses may be more satisfactory. Tables Table 5-3 and Table 5-4 show how to manually configure addresses on a variety of systems, at boot time and while they are running.

                                 IPV6INIT="yes"
                                 IPV6ADDR="2001:db8::1/64"

The first thing to check on a host is what IPv6 addresses are automatically configured. Either use the commands in Table 5-1 to enable IPv6 with autoconfiguration at boot, or the commands in Table 5-2 to enable IPv6 at runtime. Then display the configured addresses using the commands outlined in Table 5-5. The link-local addresses, beginning fe80::, should be available and the loopback address ::1 will also be available. If you see any 2001::, 3ffe:: or 2002:: addresses and you are surprised by their presence, then either a tunnel has been automatically configured, or someone has set up an IPv6 router on your network unbeknownst to you.

Example 5-2 shows the interface configuration on a FreeBSD host and Solaris host using the ifconfig command. They both have link-local addresses and autoconfigured 2001:: addresses provided by the local router. Note, FreeBSD assigns all the addresses to a single interface, while Solaris uses sub-interfaces and displays different families of addresses separately. These are cosmetic differences that have no real impact on the operation of IPv6. Note there are other minor differences such as how the prefix length or scope information is displayed.

freebsdhost% ifconfig -a
dc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255
        inet6 fe80::204:e2ff:fe33:e3ac%dc0 prefixlen 64 scopeid 0x1 
        inet6 2001:db8:babe:1:204:e2ff:fe33:e3ac prefixlen 64 autoconf 
        ether 00:04:e2:33:e3:ac
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
        inet6 ::1 prefixlen 128 
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 
        inet 127.0.0.1 netmask 0xff000000 

solarishost% ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000 
le0: flags=1004843<UP,BROADCAST,RUNNING,MULTICAST,DHCP,IPv4> mtu 1500 index 2
        inet 10.0.0.15 netmask ffffff00 broadcast 10.0.0.255
        ether 8:0:20:72:74:9e 
lo0: flags=2000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6> mtu 8252 index 1
        inet6 ::1/128 
le0: flags=2000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2
        ether 8:0:20:72:74:9e 
        inet6 fe80::a00:20ff:fe72:749e/10 
le0:1: flags=2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 2
        inet6 2001:db8:babe:1:a00:20ff:fe72:749e/64

Initially, the most useful test you can make is to check that you can ping localhost. Check the ping command in Table 5-6 and try pinging ::1 and any link-local addresses that are configured.

To ping link-local addresses, you may need to specify the interface to use. This can usually be done with an option to ping or by giving a scope ID in the address (as supported by KAME and Microsoft stacks). See Example 5-3. Scope IDs are explained in the Section 3.2.3.4 of Chapter 3.

% ping6 ::1
PING6(56=40+8+8 bytes) ::1 --> ::1
16 bytes from ::1, icmp_seq=0 hlim=64 time=0.537 ms
16 bytes from ::1, icmp_seq=1 hlim=64 time=0.381 ms
16 bytes from ::1, icmp_seq=2 hlim=64 time=0.384 ms
16 bytes from ::1, icmp_seq=3 hlim=64 time=0.384 ms
^C
--- ::1 ping6 statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 0.381/0.421/0.537/0.067 ms

Of course, networking is moderately uninteresting unless there are multiple computers in the picture. If you have a second machine with IPv6 enabled, you should be able to ping that computer using its link-local IPv6 address. For example, if you have a Linux machine that has autoconfigured address fe80::2b0:d0ff:fed7:741d on eth0 and a FreeBSD machine that has configured address fe80::202:b3ff:fe65:604b on fxp1, then the Linux host should be able to ping the FreeBSD host with the command ping6 -I eth0 fe80::202:b3ff:fe65:604b and the FreeBSD machine should be able to ping the Linux machine with the command ping6 fe80::2b0:d0ff:fed7:741d%fxp1 ^[9]. Note that we’ve used an explicit flag to ping to give the interface in the Linux case, but used the KAME scope ID in the FreeBSD case.

Naturally, if there are global addresses assigned to these hosts then you should also be able to ping these without specifying any scope ID.

There is a nice trick for finding the addresses of IPv6 nodes on your network using ping: we can do this by pinging the all-nodes multicast address, ff02::1. For example, on the Linux machine mentioned above, we can ping this address on eth0 via the command ping6 -I eth0 ff02::1. The output is shown in Example 5-4—here we received six responses to the ping (five of which are marked as duplicates) and the addresses of the nodes are shown.

$ /usr/sbin/ping6 -I eth0 ff02::1
PING ff02::1(ff02::1) from fe80::2b0:d0ff:fed7:741d eth0: 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.062 ms
64 bytes from fe80::2b0:d0ff:fe05:fc06: icmp_seq=1 ttl=64 time=0.194 ms (DUP!)
64 bytes from fe80::206:5bff:fe68:249b: icmp_seq=1 ttl=64 time=0.224 ms (DUP!)
64 bytes from fe80::202:b3ff:fe65:604b: icmp_seq=1 ttl=64 time=0.256 ms (DUP!)
64 bytes from fe80::2b0:d0ff:fef4:c6c5: icmp_seq=1 ttl=64 time=0.334 ms (DUP!)
64 bytes from fe80::203:93ff:fe46:17a6: icmp_seq=1 ttl=64 time=0.384 ms (DUP!)

--- ff02::1 ping statistics ---
1 packets transmitted, 1 received, +5 duplicates, 0% loss, time 0ms
rtt min/avg/max/mdev = 0.062/0.242/0.384/0.103 ms

Unfortunately, this trick is not completely foolproof. Some versions of ping do not show duplicates and some nodes reply with an address other than their link-local address. However, it will usually even work on manually configured tunnels, which can be very useful for testing if the host at the remote end is properly configured.

This trick isn’t limited to pinging the all-nodes multicast address; so with very little effort, it can be used to perform small administration tasks on arbitrary multicast groups. This is useful for working with specific, generally functional, groups of servers.

Even we occasionally forget that ICMPv6 includes features that didn’t exist in IPv4. For example, these days you can request a lot more than a simple ECHO_REPLY; using an ICMPv6 node information query you can request the addresses used by the responder, and hostnames of the destination endpoint. KAME’s version of ping6 supports these queries nicely—you can ask remote nodes what they think their host name is with the -w flag. We can squeeze even more out of this technique by combining it with pinging multicast groups, as shown in Example 5-5. The figure shows a node information query being sent to the all-nodes multicast group with ping6, which then displays the address and name of each host that replied.

% ping6 -w -I en0 ff02::1
PING6(72=40+8+24 bytes) fe80::203:93ff:fe46:17a6%en0 --> ff02::1
39 bytes from fe80::206:5bff:fe68:249b%en0: adric
26 bytes from fe80::2b0:d0ff:fe05:fc06%en0: ace
37 bytes from fe80::202:b3ff:fe65:604b%en0: jo
40 bytes from fe80::2b0:d0ff:fef4:c6c5%en0: sarah-jane
^C
--- ff02::1 ping6 statistics ---
1 packets transmitted, 1 packets received, +3 duplicates, 0% packet loss

If we compare Example 5-4 and Example 5-5 we can see that not all nodes responded to the node information request. Unfortunately, these queries are not yet a full part of the standard.

If ping is working okay, then it should also be possible to telnet, even if you only get a “connection refused” message in response. Note that most versions of telnet do not have an explicit option to allow you to specify the interface to be used for a link-local address. To get around this, some platforms automatically use a default interface. On platforms that support scope IDs in addresses, these can be used instead. Example 5-6 shows some examples of these in use. The first example, on Linux, shows telnetting to a unscoped link-local address and the corresponding error. In the next example, on Windows XP, it is unclear why the unscoped connect failed, but adding a scope ID allows the connection to proceed. The final example is with a Solaris host, where the LAN interface is used by default for link-local addresses.

linuxhost% telnet fe80::204:e2ff:fe33:e3ac
Trying fe80::204:e2ff:fe33:e3ac...
telnet: connect to address fe80::204:e2ff:fe33:e3ac: Invalid argument

C:Documents and Settings>telnet fe80::204:e2ff:fe33:e3ac
Connecting To fe80::204:e2ff:fe33:e3ac...Could not open connection to the host, 
on port 23: Connect failed
C:Documents and Settings>telnet fe80::204:e2ff:fe33:e3ac%4
FreeBSD/i386 (gonzo) (ttypb)

login:


solarishost% telnet fe80::204:e2ff:fe33:e3ac
Trying fe80::204:e2ff:fe33:e3ac...
Connected to fe80::204:e2ff:fe33:e3ac.
Escape character is '^]'.

FreeBSD/i386 (gonzo) (ttypc)

login:

Pinging a node on your local network only requires Neighbor Discovery to be working correctly. The commands in Table 5-7 show how to display the neighbor cache. After pinging a host, its link-layer address should show up in the neighbor cache. If it does not, there is probably some problem with multicast—see the Section 5.7 later in this chapter for problems we’ve encountered in this area. Table 5-8 shows how to display IPv6 caches.

Example 5-7 shows the neighbor cache on a Red Hat Linux host. The first two entries are actually for two different addresses on the same node. The first is a global 2001:: address. It is marked as stale because no communication has recently taken place using this address; the cache entry would be renewed by neighbor discovery if the address needed to be used. The second is the link-local address for the same node—we can tell this because the link-layer addresses and interface IDs are the same for both addresses. Note that this address is marked as a router. Finally, there is a global address for another node on the same network. Note that the corresponding link-local address is not in the table, indicating that these two nodes have been communicating using only the global address.

$ ip -f inet6 neigh
2001:db8::202:b3ff:fe65:604b dev eth0 lladdr 00:02:b3:65:60:4b nud stale
fe80::202:b3ff:fe65:604b dev eth0 lladdr 00:02:b3:65:60:4b router nud reachable
2001:db8::2b0:d0ff:fef4:c6c5 dev eth0 lladdr 00:b0:d0:f4:c6:c5 nud reachable

Name resolution is the process of turning host names into addresses and back again. Usually, configuring name resolution amounts to telling the operating system the IP address of your nameserver. Of course, now you have a choice of telling it an IPv4 or an IPv6 address.^[10]

The easy option is to use an IPv4 address. You probably either already know the IPv4 address of your nameserver, or you don’t need to know it, because it’s been automatically configured by DHCP or PPP. Configuring an IPv4 address for your nameserver is quite simple because it doesn’t involve any configuration other than the usual procedure for setting up IPv4 on a host, and then editing /etc/resolv.conf on Unix-like systems or using the network control panels on Windows and Mac OS.

Of course, in the long run we’ll want to tell the operating system to be able to configure an IPv6 address as a nameserver. This is essential when we are configuring, say, an IPv6-only node. However, there are several obstacles to doing this from the start. First, we have to make sure our nameserver has an IPv6 address, which we discuss in Section 6.1.2 of Chapter 6. Second, we need the operating system’s resolver libraries to support the use of an IPv6 nameserver. Unfortunately, at the time of writing, many operating systems have a problem with this. Even on platforms such as Linux and FreeBSD, where this is supported, there can be unexpected problems: Chapter 5 gives an example of the sort of problem that might crop up.

Finally, most of us don’t manually configure the DNS servers on every host, instead we use DHCP to manage this information centrally. In the IPv6 world the same effect can be achieved with DHCPv6, which we describe in Section 4.3.3.

If you plan to do some small scale testing, you may want to add names for some of the IPv6 addresses you will be using. For small scale testing, setting up DNS records (as we describe in Section 6.1 of Chapter 6) may be too heavy-duty, especially if the DNS server is not under your direct control. For this type of situation, it may be sufficient to add addresses to the /etc/hosts file, or its equivalent.

Table 5-9 shows how to configure DNS resolving over IPv6, if it is available.^[11] In some cases, you may want to use hostnames without configuring DNS, and so you may want to use a mechanism equivalent to the hosts file. Table 5-10 shows how to do this on the platforms considered in this chapter.

As we have outlined, there are several choices for how you can connect to the IPv6 Internet. Rather than go into the details of those right now, let us assume that someone has provided you with a working IPv6 router and that autoconfiguration has provided you with a global address. What tests might you now perform?

Well, the telnet and ping tests listed in Section 5.3.2 earlier in this chapter should work, but using the global addresses of local machines instead of their link-local addresses.

If routing is in place, you should also be able to telnet and ping machines out on the Internet—www.kame.net is probably a good machine to test with. Try telnet www.kame.net 80 and then typing GET / HTTP/1.0 and then pressing return twice.^[12] If everything works, you should be presented with the HTML for the KAME home page.^[13]

What can go wrong here? Well, the first thing is that you’ll need working DNS to get the IPv6 address for www.kame.net. The only situation where configuring DNS is tricky is if you have an IPv6-only host but have not yet set up an IPv6-capable nameserver. In this case you can always look up the address on an IPv4 host, using a command like nslookup -query=aaaa www.kame.net or dig aaaa www.kame.net, and then transfer it the old-fashioned way.^[14]

If the name is being translated to the address correctly, the next step is that the packets will need to get to your local router. Autoconfiguration should result in hosts learning the local default routers correctly, and you can check this by examining the routing table using the commands shown in Table 5-8. If the routing table is configured correctly a default route or a route for 2000::/3 should exist.

Note that the default router may advertise its link-local address, rather than a global address, so be prepared to see either as the gateway. Both router-discovery and neighbor-discovery are important here, because once a host has learned its default router’s address, it may need to do neighbor discovery to learn the router’s link-layer address.

If there is a routing problem, it should be possible to narrow it down using traceroute, as is done in IPv4. Table 5-6 shows the syntax of the IPv6 commands on our various platforms and Example 5-8 shows three traceroute examples. Each example shows tracerouting between two organizations under the same ISP. The first traceroute gets to its destination successfully; the times shown are the round trip times to each hop. The second example shows a situation where packets are being lost because a router had been powered off. Note that a “*” is shown instead of a time, to indicate a timeout. The final example shows a router returning ICMPv6 errors for an address that is not currently routable, indicated by the `A!’ after the time.

freebsdhost% traceroute6 -n 
 2001:db8:10:300::86e2:5103
traceroute6 to 2001:db8:10:300::86e2:5103 (2001:db8:10:300::86e2:5103) from 
 2001:db8:68:ff::1, 30 hops max, 12 byte packets
 1  2001:db8:68:ff::2  0.801 ms  0.691 ms  0.669 ms
 2  2001:db8:8:9::1  6.843 ms  3.472 ms  3.457 ms
 3  2001:db8:8:3::2  4.432 ms  4.1 ms  4.166 ms
 4  2001:db8:8:4::2  4.665 ms  4.417 ms  4.458 ms
 5  2001:db8:10:100::86e2:a33  5.306 ms  4.781 ms  4.798 ms
 6  2001:db8:10:300::86e2:5103  5.369 ms  5.228 ms  5.076 ms

freebsdhost% traceroute6 -n 2001:db8:10:200::86e2:5103
traceroute6 to 2001:db8:10:200::86e2:5103 (2001:db8:10:200::86e2:5103) from 
2001:db8:68:ff::1, 30 hops max, 12 byte packets
 1  2001:db8:68:ff::2  0.779 ms  0.721 ms  0.669 ms
 2  2001:db8:8:9::1  3.719 ms  3.409 ms  3.269 ms
 3  2001:db8:8:3::2  4.527 ms  4.606 ms  3.966 ms
 4  2001:db8:8:4::2  4.649 ms  4.294 ms  4.374 ms
 5  2001:db8:10:100::86e2:a33  4.997 ms  6.483 ms  5.125 ms
 6  * * *
 7  * * *
 8  * * *
 9  *^C

freebsdhost% traceroute6 -n 2001:db8:100:300::86e2:5103
traceroute6 to 2001:db8:100:300::86e2:5103 (2001:db8:100:300::86e2:5103) from 
 2001:db8:68:ff::1, 30 hops max, 12 byte packets
 1  2001:db8:68:ff::2  0.786 ms  0.701 ms  0.647 ms
 2  2001:db8:8:9::1  9.608 ms  3.649 ms  3.298 ms
 3  2001:db8:18:2:201:3ff:fe2c:960c  4.142 ms !A  3.936 ms !A  4.167 ms !A

As we have mentioned, path MTU discovery is an important part of IPv6 because IPv6 routers are not permitted to fragment packets. If some firewall between you and the destination does not allow ICMPv6 Packet Too Big messages through, then Path MTU discovery may not work correctly. The usual symptom is that TCP connections involving interactive or slow transfers work OK, but large or fast transfers hang unexpectedly and then time out. Some versions of traceroute, or variants of it such as Linux’s tracepath can display Path MTU information, which may help diagnose this sort of problem.

Configured tunnels are normally used to encapsulate IPv6 in IPv4 and ship it from one point in the Internet to another. To configure a tunnel of this sort you usually need 4 pieces of information: the source and destination IPv4 addresses used for encapsulation, and the source and destination IPv6 addresses assigned to either end of the virtual, point-to-point link.

The exact mechanism used to create tunnels varies a bit from platform to platform. On some platforms, the tunnel is presented as a point-to-point interface, but on others, the tunnel is created by setting the next hop to be an IPv4 compatible IPv6 address. Table 5-13 and Table 5-14 show the steps for boot-time and run-time configuration of tunnels on our selected operating systems.

                                 tsrc 
                                 localv4 tdst remotev4 up
addif 
                                 localv6 
                                 remotev6 up

                                 DEVICE="sit
                                 X"
BOOTPROTO="none"
ONBOOT="yes"
IPV6INIT="yes"
IPV6TUNNELIPV4="
                                 remotev4"
IPV6ADDR="
                                 localv6/prefixlen"

                                 ipv6 rtu 2000::/3 2/::remotev4
                                 ipv6 adu 2/localv6

                                 netsh interface ipv6 add route prefix=2000::/3 interface=2 nexthop=::remotev4
                                 netsh interface ipv6 add address interface=2 address=localv6

                                 gif_interfaces="gif0"
gifconfig_gif0="
                                 localv4 
                                 remotev4"
ipv6_ifconfig_gif0="
                                 localv6 
                                 remotev6 prefixlen 128"

                                 interface Tunnel0
                                  ipv6 address 
                                 localv6/64
 tunnel source 
                                 localv4
                                  tunnel destination 
                                 remotev4
                                  tunnel mode ipv6ip

                                 set interfaces ip-1/0/0 unit 0 tunnel source 
                                 localv4
                                 set interfaces ip-1/0/0 unit 0 tunnel destination 
                                 remotev4
                                 set interfaces ip-1/0/0 unit 0 tunnel family inet6 address 
                                 localv6/64

                                 ifconfig ip.tun0 inet6 plumb
ifconfig ip.tun0 inet6 tsrc localv4 tdst remotev4 up
ifconfig ip.tun0 inet6 addif localv6 
                                 remotev6 up

                                 ip tunnel add sit1 mode sit ttl 64 remote 
                                 remotev4 local localv4
                                 ip link set dev sit1 up

                                 ipv6 rtu ::/0 2/::remotev4
                                 ipv6 adu 2/localv6

                                 netsh interface ipv6 add route prefix=2000::/3 interface=2 nexthop=::remotev4
                                 netsh interface ipv6 add address interface=2 address=localv6

                                 ifconfig gif0 create
ifconfig gif0 tunnel localv4 
                                 remotev4
                                 ifconfig gif0 inet6 localv6 
                                 remotev6 prefixlen 128 up

                                 ifconfig gif0 tunnel localv4 
                                 remotev4
                                 ifconfig gif0 inet6 localv6 
                                 remotev6 prefixlen 128 up

                                 iptunnel create -I ipt0 
                                 remotev4 
                                 localv4
                                 ifconfig ipt0 ipv6
ifconfig ipt0 inet6 localv6
                                 ifconfig ipt0 up
route add -host -inet6 
                                 remotev6 
                                 localv6 -interface -dev ipt0

                                 interface Tunnel0
                                  ipv6 address 
                                 localv6/64
 tunnel source 
                                 localv4
                                  tunnel destination 
                                 remotev4
                                  tunnel mode ipv6ip

                                 set interfaces ip-1/0/0 unit 0 tunnel source 
                                 localv4
                                 set interfaces ip-1/0/0 unit 0 tunnel destination 
                                 remotev4
                                 set interfaces ip-1/0/0 unit 0 tunnel family inet6 address 
                                 localv6/64

After you have configured your tunnel, testing configured tunnels is like testing any other link. First, you’ll want to check that you can ping all the addresses of both ends of the link, from both ends of the link. If the link is represented as an interface on your platform, then you may even be able to ping the all-nodes multicast address and get a response from both ends!

Debugging configured tunnels is slightly more tricky. Using a tool such as tcpdump can be quite useful. Generally, tcpdump allows you to attach to a specified interface and watch the packets arriving. The first thing to check is that the encapsulated IPv6 packet is being transmitted and arrives as expected. We can do this by using tcpdump’s -i flag to specify the actual interface we expect the IPv4 packet to pass through. If the IPv4 packet does not arrive, then some firewall may be filtering protocol 41. Remember also to check the hosts at both ends of the tunnel, as either of them might be running IPv4 or IPv6 firewall software.

On some platforms, we can actually run tcpdump on the tunnelling interface itself and see the IPv6 packet once it has been decapsulated. Seeing the decapsulated packet will confirm there is no problem with the encapsulation/decapsulation.^[16] Example 5-9 shows an example of running tcpdump on both the PPP interface (tun0) and then on the tunnel interface (gif0) on a FreeBSD host. Some versions of tcpdump give a warning when run on an interface with no IPv4 address configured, but this is harmless. Note that when we see the packets on the PPP interface, we can see the IPv4 addresses used for the tunnel, but when the packet gets to the tunnel interface the IPv4 addresses are stripped off.

# tcpdump -i tun0 -n -s0 ip proto 41
tcpdump: listening on tun0
11:34:09.181300 192.0.2.151 > 192.0.2.1: 2001:db8:68:1ff:2b0:d0ff:fef4:c6c5 > 
2001:db8:ccc1:1::1: icmp6: echo request
11:34:09.181486 192.0.2.1 > 192.0.2.151: 2001:db8:ccc1:1::1 > 
2001:db8:68:1ff:2b0:d0ff:fef4:c6c5: icmp6: echo reply

# tcpdump -i gif0 -n -s0 
tcpdump: WARNING: gif0: no IPv4 address assigned
tcpdump: listening on gif0
11:35:17.736014 2001:db8:68:1ff:2b0:d0ff:fef4:c6c5 > 2001:db8:ccc1:1::1: icmp6: 
echo request
11:35:17.736093 2001:db8:ccc1:1::1 > 2001:db8:68:1ff:2b0:d0ff:fef4:c6c5: icmp6: 
echo reply

If the encapsulated packets are visible at both ends, but there still seem to be problems, then one possible occurrence is that the routing table is not directing all the desired IPv6 packets to the tunnel interface. Check that the routing table contains the correct routes using the commands shown in Table 5-8. The Section 5.4 earlier in this chapter shows how to configure static routes.

Note, that some NAT systems will actually allow configured tunnels to function through NAT! In this case the NAT device will replace the destination/source IPv4 address of tunnelled packets on the way in/out of the NATed network. This complicates the configuration of the tunnel: the end of the tunnel inside the NATed network should use its private IP as the local IPv4 address and the end of the tunnel outside the NAT should use the NAT’s public IP address as the remote end. To create the necessary NAT state and keep the connection alive, you may need to arrange for packets to be sent over the tunnel regularly (say, by running ping6 with an inter-packet time of a minute or so).

Setup of 6to4 is relatively straight-forward; in many ways it is like a configured tunnel, but you don’t need to ask anyone for the local and remote IPv4 and IPv6 addresses. This makes things even simpler!

What you do need to know is your local IPv4 address and then a script like the one shown in Example 5-10 can do the rest. This script takes the IPv4 address of the host as its first argument, computes an IPv6 address for the host and configures the stf0, which is the 6to4 interface on KAME-derived systems. Table 5-15 and Table 5-16 show configuration details for various operating systems. The examples also show how to point the default route to the 6to4 interface, as this is a common configuration.

Note that not all the operating systems that we’re considering can act as a 6to4 router. Solaris, for example, only supports it if you have the Solaris 9 4/03 Update installed. This shouldn’t pose a problem though because you only need one 6to4 router to provide connectivity for a whole network.^[17]

#!/bin/sh

IPV4=$1
PARTS=`echo $IPV4 | tr . ' '`
PREFIX48=`printf "2002:%02x%02x:%02x%02x" $PARTS`

STF_IF="stf0"
STF_NET6="$PREFIX48":0000
STF_IP6="$STF_NET6"::1

ifconfig $STF_IF inet6 $STF_IP6 prefixlen 16 alias
route add -inet6 default 2002:c058:6301::

                                 tsrc 
                                 v4addr 
                                 6to4addr/64 up

                                 IPV6TO4INIT=yes

                                 IPV6_DEFAULTDEV=tun6to4

                                 stf_interface_ipv4addr="
                                 v4addr"
ipv6_defaultrouter="2002:c058:6301::"

                                 interface Tunnel2002
                                  ipv6 address 
                                 6to4addr/16
 tunnel source 
                                 if
                                  tunnel mode ipv6ip 6to4
                                 ipv6 route ::/0 2002:c058:6301::1

                                 ifconfig ip.6to4tun0 inet6 plumb
ifconfig ip6to4tun0 inet6 tsrc IPv4-address 6to4-address/64 up
6to4relay -e -a 192.88.99.1

                                 ip tunnel add tun6to4 mode sit ttl 64 remote any local 
                                 v4addr
                                 ip link set dev tun6to4 up
                                 ip -6 addr add 
                                 6to4addr/16 dev tun6to4
ip -6 route add 2000::/3 via ::192.88.99.1 dev tun6to4 metric 1

                                 ifconfig stf0 inet6 6to4addr prefixlen 16
route add -inet6 default 2002:c058:6301::

                                 ifconfig tun1 ip6interfaceid ::v4addr ipv6 up
ifconfig tun1 inet6 ip6prefix 6to4addr/64
route add -inet6 2002::/16 fe80::
                                 v4addr -iface -dev tun1
route add -inet6 default 2002:c058:6301:: -dev tun1

                                 interface Tunnel2002
                                  ipv6 address 
                                 6to4addr/128
 tunnel source 
                                 if
                                  tunnel mode ipv6ip 6to4
                                 ipv6 route 2002::/16 Tunnel2002
                                 ipv6 route ::/0 2002:c058:6301::1

As 6to4 is another tunnelling technology, the techniques used to debug it are pretty similar to those we described for configured tunnels. One thing that you may want to do is find out where the nearest relay router is. You can do this by tracerouting to its anycast address 192.88.99.1, which will reveal its location within the IPv4 network. Example 5-11 shows an example of this. If the relay is a long distance away, then you may want to talk to your ISP about a configured tunnel or ask them to provide a 6to4 relay for their customers.

% traceroute 192.88.99.1
traceroute to 192.88.99.1 (192.88.99.1), 64 hops max, 44 byte packets
 1  gw-81 (134.226.81.1)  0.290 ms  0.171 ms  0.156 ms
 2  gswte1r1-vlan3.tcd.ie (134.226.1.104)  0.488 ms  0.440 ms  0.406 ms
 3  tcd.ge.link.hea.net (193.1.192.185)  0.738 ms  1.228 ms  0.615 ms
 4  Mantova-v101.Dublin.core.hea.net (193.1.196.149)  0.850 ms  0.892 ms  0.909 ms
 5  193.1.196.18 (193.1.196.18)  2.106 ms 2.960 ms  4.325 ms

A growing number of web browsers now support IPv6. In some cases the support varies from platform to platform; for example, some browsers have restrictions on how IPv6 web servers can be specified.

There are various sites you can visit to check if your browser supports IPv6. The standard test is to visit http://www.kame.net/, where the turtle at the top of this page will dance if you requested the page by IPv6. The KAME page also shows your IPv4 or IPv6 address at the bottom of the page.

Note that on all platforms it is possible to view IPv6 content on an IPv4-only browser by using a dual-stack proxy. We’ll talk more about this in Section 7.3.4 of Chapter 7.

Outlook Express, as shipped with Windows XP SP 1, doesn’t seem to support IPv6 for POP, IMAP or SMTP. Apple’s Mail client seems to be similarly constrained under Jaguar but has the beginnings of IPv6 support under Panther. Older Unix mail programs such as elm and mh do not yet support IPv6, though work is under way for some of the more recent ones like pine, kmail, and Evolution.

Now that telnet has been thoroughly discredited, SSH tends to be the remote access service of choice, especially for people who care about security. Many of the systems we talk about ship with the portable release of OpenSSH, from http://www.openssh.com/, which supports IPv6 if your system provides the standard IPv6 APIs. OpenSSH provides -4 and -6 flags for restricting operation to IPv4 or IPv6. It also accepts IPv6 addresses on the command line. The scp command uses a colon as a separator between hostname and filename, so if you want to use an IPv6 address with scp, it needs to be enclosed in square brackets, for example scp "user@[2001:db8::a00:2]:/etc/ipnodes" /tmp.

For Windows users, a version of Simon Tatham’s popular PuTTY program, compiled with IPv6 support, is available from http://unfix.org/projects/ipv6/. Some versions of IPv6 PuTTY would only connect to hosts that have IPv6 DNS records, but up-to-date versions should also connect to hosts with IPv4-only DNS. Which protocol is preferred can be configured in PuTTY’s connection panel. At some time in the future, IPv6 support should be rolled into the standard version of PuTTY.

Full support for IPv6 is currently in development by Wipro Technologies for the Gnome Desktop and Developer Platform, and should begin to appear in Gnome 2.4.

Naturally, a prerequisite for IPv6 on Unix desktops is IPv6 support in X11. This work is well underway and the first release of this code was in version X11R6.7. Details of the design of the IPv6 support can be found at http://www.x.org/IPV6_Review.html. Release 4.4.0 of XFree86 and X.org’s 6.7.0 release both use this code on platforms that support IPv6. From an end user’s point of view there should be no noticeable change, though you can now prefix a display name with inet/ or inet6/ to force a connection to be made over IPv4 or IPv6. Thus, you can say:

xclock -display desktop.example.com:0 
xclock -display inet6/desktop.example.com:0

or even:

xclock -display ::1:0