Address space is, with both IPv4 and IPv6, a finite resource. There are only so many addresses that can be allocated from any fixed range. Furthermore it’s a hard limit, pending a change in the meaning of addresses as they are currently understood; one day, you will reach into your “address bag” to assign some new addresses, and there won’t be any more there. Perhaps this won’t be a problem for you immediately—who can say when you might need to grow your network—but it will certainly be a problem for the people you need to communicate with, so it thereby becomes everybody’s problem.

So what’s the scale of this risk? Well, prior to CIDR,^[1] IPv4 address allocation, based on class A, B and C addresses, had been over-generous to some users, and address space allocation was running out of control. Today, allocation policies are much stricter, and address space is assigned more frugally. So, the end has not been deferred indefinitely, but the process is definitely under much better control. However, time is inevitably running out: only 36% of the total IPv4 address space remained in 2002, and, depending on whose extrapolations you believe, the remaining space runs out some time between 2005 and 2035. Recent measurements by Geoff Huston suggest that stricter policies have helped considerably, and we may be looking at the upper end of that range. However, even if IPv4 addresses remain available for the next 200 years, but obtaining them requires you to write longer and increasingly baroque essays on why you deserve them, that’s little good to anyone.

Figure 3-1 shows the Internet Systems Consortium’s host count. This count is based on DNS records, which gives data only loosely related to the actual number of live hosts,^[2] but does grow proportionally to the amount of address space that has been allocated. We can see that even though growth stalled a little in the last few years, the clock is still ticking.

Figure 3-1. Internet Systems Consortium’s host count (source: www.isc.org)

Optimization in this context means two things. First, the design of IPv6 takes into account the problems of IPv4, focusing, in particular, on the consequences for the end user. In other words, the lack of certain desired features is addressed. Management features are one thread in this part of IPv6 tapestry that we choose to isolate for attention. There are serious problems with the way that IPv4 is managed today in enterprises, and IPv6 has the potential to fix those problems. Potential, mind you; no one is pretending that immediate benefits will accrue to any organization implementing IPv6 right now. We shall explain more about this later.

The second aspect of optimization in IPv6’s design is to simplify the mechanisms on which IP is built; for example, the basic IP headers have all been slimmed down to the necessary minimum. This should, in theory, lead to higher performance and lower cost routers, since less processing needs to be done to forward an IPv6 packet than an IPv4 packet. This should also help in areas such as header compression.

Overall IPv6 actually simplifies the basic header, by including only the information needed for forwarding a packet. This results in a fixed-length header, unlike IPv4. Fixed-length headers are important for router designers and for coders, because it allows more efficient memory allocation strategies and algorithm implementation. Other information, which might traditionally have been stored in the IPv4 header or as IPv4 options, is now stored within a chain of subsequent headers, identified by the next header field. The final header will usually be a TCP, UDP or ICMPv6 header. This way the task of forwarding can be accomplished by dealing with the first few bits of the packet that you have received. Figure 3-2 compares IPv4 and IPv6 headers.

Many familiar fields have equivalents in IPv6: Version, ToS/Traffic Class, Total Length/Payload Length, Time to Live/Hop Limit, Protocol/Next Header, source address and destination addresses. Note the removal of IPv4 fragmentation fields (ID, Flags, Offset), and header checksum. The Traffic Class field is also augmented by the presence of Flow Label field, both used for quality of service, discussed in the Section 3.10 section later in this chapter.

Figure 3-2. IPv4 versus IPv6 packet header

TCP and UDP remain unchanged from IPv4, although individual application protocols that hard-code address sizes may have unpleasant surprises waiting for them in the new world. (We deal with that specific topic in Chapters Chapter 7 and Chapter 8.)

The use of IPv6 addresses is covered in RFC 3513. To begin with, you need to know that IPv6 addresses come in different types (Unicast, multicast, anycast) and different scopes (link, global, and so on). The type of the address determines if packets are destined for one or for many machines. The scope of the address determines which contexts the address makes sense in. We’ll explain more about types and scopes shortly.

RFC 3513 also makes the point that IPv6 addresses are assigned to interfaces on nodes, not to the nodes themselves. This is a big change from IPv4, where very often the address associated with a machine’s interface is that machine. Instead, IPv6 interfaces commonly and usefully have more than one IPv6 address.

In fact, IPv6 allows scoped addresses, which only have meaning within a certain context. For example, most interfaces have a link-local address which is only unique on that specific link. This means that two interfaces on a node could have the same link-local address if they were attached to different links! If all of this seems confusing, just think of the IPv4 loopback address. It is an example of a scoped address because 127.0.0.1 indicates a different destination on each host.

Another important concept in IPv6, covered in the RFC, is that of an interface identifier. In the IPv4 world, we split addresses into a network part and a host part; an example in CIDR notation is 137.43.0.0/16. In the IPv6 world the host part is now called the interface ID, and is used to pick out a particular interface within the specified network, in the same way that the host part of an IPv4 address picks out that host on a particular subnet.

The separation has a number of useful properties. Perhaps the most interesting is the potential for automatic assignment of interface IDs. This is one of the nicer features of IPv6, discussed in the Section 3.4.2 later in this chapter. Naturally, manually configuring interface IDs and addresses or using DHCPv6 is still an option, and indeed might be preferable for certain kinds of services.^[3]

RFC 3513 also covers the notation used for IPv6 addresses, which we’ll now explain.

The notation for IPv6 addresses has changed greatly from IPv4. Given a greatly enlarged address space, using or describing IPv6 addresses efficiently becomes much more important than in IPv4, where you are never more than 16 keystrokes from the end of an address. The main differences are outlined below.

#!/usr/local/bin/perl

while(<>) { print &expandv6($_), "
"; }

sub expandv6 {
        local ($_) = @_;
        local (@parts, @newparts, $part);

        s/s+//g; # Get rid of white space.
        s/%.*//g; # Get rid of MS/KAME scope ID, if there is one.
        if (/:(d+).(d+).(d+).(d+)$/) { # Expand trailing IPv4 address.
                $part = sprintf ":%02x%02x:%02x%02x", $1, $2, $3, $4;
                s/:d+.d+.d+.d+$/$part/;
        }

        @parts = split(/:/, $_, -1);
        $short = 8 - $#parts;
        @newparts = ( );

        foreach $part (@parts) {
                if ($part eq "" && $short >; 0) {
                        while ($short-- >; 0) { push @newparts, "0000"; }
                } else {
                        push @newparts, (sprintf "%04x", hex($part));
                }
        }

        return join ":", @newparts;
}

1;

::
237:0:ABCD::10
::137.43.4.16
2001:770:10::
::0
::ffff:0.0.0.0
200::
2000::
fe80::
fec0::
ff00::
2001:1200::
ff05::1:3
ff02::1:ffab:cdef
ff02::2
fe80::134.226.81.10
2001:770:10:300::134.226.81.11

0000:0000:0000:0000:0000:0000:0000:0000
0237:0000:abcd:0000:0000:0000:0000:0010
0000:0000:0000:0000:0000:0000:892b:0410
2001:0770:0010:0000:0000:0000:0000:0000
0000:0000:0000:0000:0000:0000:0000:0000
0000:0000:0000:0000:0000:ffff:0000:0000
0200:0000:0000:0000:0000:0000:0000:0000
2000:0000:0000:0000:0000:0000:0000:0000
fe80:0000:0000:0000:0000:0000:0000:0000
fec0:0000:0000:0000:0000:0000:0000:0000
ff00:0000:0000:0000:0000:0000:0000:0000
2001:1200:0000:0000:0000:0000:0000:0000
ff05:0000:0000:0000:0000:0000:0001:0003
ff02:0000:0000:0000:0000:0001:ffab:cdef
ff02:0000:0000:0000:0000:0000:0000:0002
fe80:0000:0000:0000:0000:0000:86e2:510a
2001:0770:0010:0300:0000:0000:86e2:510b

In IPv4, subnetting allows you to take pieces of your existing address space and divide it, to provide either more networks or to make more addresses available to certain people. One common example of using subnetting to provide more networks is an ISP assigning a subnet of their address space to a customer. An example of using subnetting to make more addresses available is when a company finds that its sales team have run out of addresses, but R&D have some spare. If R&D are using less than half of the 256 addresses in their /24 say, then a /25 could be reclaimed and assigned to sales.

IPv6 can subnet too. It uses the CIDR notation developed for IPv4 as well, which is a way of specifying the size of a network in addition to the actual network number. An example from IPv4 is 137.43.0.0/16, which is the old “class B” network of University College Dublin. Similarly, 2001:770:10::/48 is the IPv6 network of Trinity College Dublin. In IPv6 these blocks of addresses are often referred to as prefixes. Single hosts in IPv4 are called /32’s, and consequently single hosts in IPv6 are /128’s. (A calculator that can do CIDR calculations on IPv4 and IPv6 addresses is available at http://www.routemeister.net/projects/sipcalc/; you might find it useful for getting up to speed on IPv6 network numbering.)

In IPv6, subnets are supposed to be at least 64 bits wide, even for point-to-point links. Since an individual /64 has space for over a billion hosts, it is expected that re-subnetting to provide more addresses for an individual network will no longer be necessary. This is an important point: possibly the best way to understand it is to take the example of an IPv4 server farm that has outgrown the 256 addresses (only 254 of them being usable of course) in its /24. With IPv4 you have no choice but to subnet, creating another piece of network either contiguous or discontiguous to the original addresses, and add your new servers there, with consequent impact on the routing within your organization. In contrast, with IPv6, since the servers can all have a different interface ID, they can all live in the same subnet. This would allow large groups of machines, say Beowulf clusters, to happily fit within any subnet.

Therefore, the main reason for subnetting becomes the assignment of networks for different administrative or technical purposes, such as security or routing. To try to simplify this process, it is expected that organizations requiring internal subnetting will always be assigned a /48.^[4] This means that everyone has 16 “network” bits to work with, or 65536 different subnets. This should be enough for anybody.^[5]

These addresses are the analogue of the normal public IPv4 address space. Most of these addresses are still reserved, but the allocation of this space to users has begun. The blocks that have been allocated are listed in Table 3-2.

Some of the production address space is being allocated to Regional Internet Registries^[6] in large chunks. The RIRs are in turn then responsible for allocating smaller blocks to Local Internet Registries, who are usually Internet Service Providers. Finally, ISPs assign addresses directly to their customers.

This hierarchical address allocation scheme is expected to be the normal way that end users get IPv6 addresses.

The link-local prefix contains addresses that are only meaningful on a single link. In fact, this prefix is used for on almost every link that IPv6 is configured on. This means the link-local address fe80::feed will refer to a different computer depending on which network you are using, much like 127.0.0.1 refers to a different computer depending on which one you’re using.

In this context, a link is a group of machines who may communicate directly without requiring an IPv6 router. This link may be a point-to-point, a broadcast link or something more esoteric, but packets addressed using link-local addressing will never pass through a router.^[7] Addresses that are only valid on the local link may not seem very useful, but they form a part of the IPv6 autoconfiguration process.

It’s important to note that hosts generate link-local addresses by virtue of being connected to a link; no router or involvement by any outside agency is necessary for these addresses to be generated and used. So, a small office with one switch and a few computers connected can use link-local addressing for simple networking.^[8] This is one of the major contributions of IPv6 to ease of management, especially for small organizations. (We’ll get to how link-local addresses are actually generated in a moment.)

It is also possible to use link-local addresses when “real” addresses are not strictly required. For example, a point-to-point link between two routers could operate with only link-local addresses, without having to allocate any global Unicast addresses. However, IPv6 has been designed so that there should be no shortage of addresses and this sort of address conservation should be unnecessary. Also, routers may require real addresses for sending ICMP error messages or for remote management.

Automatically configured link-local addresses are in some ways quite similar to the IPv4 169.254.0.0/16 addresses that are sometimes used if no DHCP server is available or if only link-local communication is required. IPv6 autoconfigured addresses differ here in that they are intended to be unique and constant, whereas the IPv4 addresses are prone to collision and may vary as a consequence of collision resolution.

Site-local addressing is an interesting idea somewhat reminiscent of the IPv4 private address spaces discussed above. These addresses are meant to be used within a site,^[9] but are not necessarily routable or valid outside of your organization. Opinions vary as to the definition of a site, but think of it as being an organization to which an address space allocation might be made. The reason for this is that as the use of site-local addressing mirrors the use of global addressing, it should simplify management of addresses and encourage sensible use of both.

Unlike link-local addresses, which are only required to be unique on a link, these site-local addresses require a router to be configured to avoid duplication of site-local addresses within a site.

At the moment the practical details of if and how site-local addressing should be deployed are still being discussed. There is a general wish to avoid the sort of problems associated with merging private networks (as discussed in “NAT” in Chapter 1). What this probably means is that there will be “site-local” addresses that are globally unique. However, it seems that site-local addresses, as originally considered for IPv6, have been abandoned and the details of this new “unique local IPv6 Unicast addressing” are being finalized. Given the clear need for stable in-site addressing in the face of provider allocated global addresses, considerable effort is being invested in getting the replacement for site-local addresses right. (We’ll comment more on the future of site-local addresses in Chapter 9.)

Enough address space has actually been dedicated to site-local and unique local addressing to assign unique addresses to most organizations in the world. Thus it is possible that these addresses could actually end up being globally valid and routable! The main problem with this is that it is not clear how to solve the technical problems associated with routing such a large, unstructured address space.

For now, the best thing to do with local addressing is to ignore it. Once its future is clearer it may be useful to some people, but for now most people can survive with a combination of link-local and global addressing.

Let’s consider applications where conversing with many hosts at once is the norm. How can you make this happen as efficiently as possible? Unicasting data to many hosts is inefficient, because you have to send the data once for each host. Broadcasting to many hosts is also inefficient, because many hosts will not be interested in the data you are sending, and will waste resources processing the packet. Multicast is the solution allowing you to send a packet efficiently to an arbitrary collection of machines. It aims to be a compromise between Unicast and broadcast; hosts can sign up to receive messages destined to specific groups, and these multicast groups are identified by multicast addresses.

The usual example of a multicast application is streaming multimedia; lots of end stations need to receive the same rock video/party political broadcast from a single source. From an application point of view you send packets to a single group address, but everyone who has registered as being in that group receives the data. Naturally this requires the cooperation of routers and switches within the network.

Multicast exists in the IPv4 world; IGMP, defined in RFC 3376, is used to manage IPv4 multicast groups. However, multicast, although useful, has never really had wide deployment. By contrast, in IPv6, multicast is compulsory. Indeed, multicast is central to the operation of IPv6; IGMP has been merged into ICMPv6 (RFC 2710) and multicast is used to implement IPv6’s equivalent of ARP. We talk more about this in the Section 3.4 section later in this chapter.

Multicast requires no configuration if it is confined to a single network (i.e., a single link). However, for multicast traffic to cross routers a multicast routing daemon must be configured. For now we’ll concentrate on link-local multicast.

An anycast address is an address half way between a Unicast address and a multicast address. Unicast addresses are assigned to one machine and each packet is delivered to that machine. Multicast addresses are assigned to many machines and each packet is delivered to all such machines. Anycast addresses are assigned to many machines, but each packet is delivered to only one of these machines. The use of anycast is still settling down, so we discuss it in Chapter 9.

RFC 2463 covers the part of ICMPv6 that is most similar to the familiar parts of ICMPv4. It covers ICMP Echo Requests and Replies, which are used to implement the well-known ping program. It also covers ICMP errors, which are returned when there is a problem with a packet: Destination Unreachable (because of routing, packet filtering or other unavailability), Packet Too Big, Time Exceeded (when the packet has travelled too many hops) and Parameter Problem (unknown or bad headers).

ICMP messages have often been filtered out in the IPv4 world, which usually results in the failure of tools such as ping and traceroute or delays while waiting for the arrival of discarded “destination unreachable” messages. IPv6 will be even less forgiving in this respect, as correctly operating ICMP is absolutely essential to the protocol. In particular, Packet Too Big messages are now necessary for the valid operation of TCP and UDP because IPv6 routers are not permitted to fragment packets. Nodes need to be told to reduce the size of a packet if it will not fit within the MTU of a link. The process of figuring out the largest packet that can be sent to a particular destination is called path MTU discovery. IPv6 path MTU discovery is described in RFC 1981. IPv6 nodes are not required to use path MTU discovery, but if they don’t, they must not send packets larger than 1280 bytes, the minimum permitted IPv6 MTU.

ICMP error messages are also explicitly rate-limited by the stack. This will usually restrict the number of error messages sent either per-period-of-time or to a fraction of link bandwidth (there are details of some suggested schemes in RFC 2463). This avoids repeating some mistakes IPv4 made with respect to overzealous, or overly-compliant, ICMP message generation.

Address resolution in IPv4 uses ARP, but in IPv6 a mechanism known as neighbor discovery is used. Neighbor discovery also provides additional features that are not provided in IPv4. Neighbor discovery is defined in RFC 2461.

Unlike ARP, ICMP neighbor discovery is an IP protocol, which means that it can be secured with IPsec (the Section 3.9 later in this chapter introduces IPsec). As a precaution, most neighbor discovery packets are also only acted on if they have not been forwarded by a router. This is achieved by checking the hop-limit field has its maximum value and makes it difficult to inject them into remote networks.

Like ARP, neighbor discovery explicitly includes the link-layer addresses within the body of messages, rather than peeking at the packet’s link-layer header. This makes for easier implementation and also leaves the option of proxy neighbor discovery open for situations such as Mobile IP.

Address resolution

Neighbor Solicitation and Neighbor Advertisement are two types of ICMPv6 neighbor discovery packets. They have several uses, but the one that we will mention here is the equivalent of ARP in IPv4.

A neighbor solicitation packet is very similar to an ARP request packet. It is sent when a node wants to translate a target IPv6 Unicast address into a link-layer address. Basically it says, “Can the owner of this IPv6 address please get in touch?” Since we don’t actually know the link-layer address of the target host, the neighbor solicitation packet is sent to the solicited-node multicast address^[11] corresponding to the target address, and the target address is included in the ICMP message. The sending node will also usually include its link-layer address, to make replying easier.

A neighbor advertisement packet is the logical response to these solicitations. It is sent back to the requesting system, including the source address of the solicitation, the link-layer address of the target system and some flags.

An example of neighbor solicitation between two hosts is shown in Figure 3-3. Host 1 wants to talk to address 2001:db8::a00:2 on host 2, so it calculates the solicited node multicast address ff02::1:ff00:2 and sends the packet to the corresponding Ethernet multicast address. It includes its own Ethernet address in the packet. Host 2 responds with a neighbor advertisement sent directly to host 1’s Ethernet address.

Figure 3-3. Example of neighbor solicitation

In the same way that hosts had an ARP table in IPv4, there is a table of neighbors maintained on a node in IPv6 called the neighbor cache. This cache manages the results of previous queries to avoid repeating requests too often.

Unlike ARP, ICMPv6 avoids broadcasts. The use of a whole range of solicited node multicast addresses means that nodes will usually only have to process Neighbor Solicitation packets that are actually of interest to them. This means that the interrupt load on IPv6 hosts should be much lower than on the equivalent IPv4 network.

Stateless autoconfiguration

Stateless autoconfiguration is a long name for an extremely desirable thing: being able to get devices working—hence, configuration—without any manual intervention—hence, auto—and without requiring server infrastructure to support it—hence, stateless.

This is to contrast it with stateful autoconfiguration, exemplified by protocols such as DHCP. DHCP is extremely useful and is very flexible about delivering information that a host requires to use network resources, but it requires a server and someone to maintain it, and these are not things that every deployment of computers can expect to have—or indeed should need to have.

In stateless autoconfiguration on Ethernet, a host uses the following pieces of information:

1. MAC addresses

2. Network prefixes

in order to generate valid addresses.

To form the complete set of addresses, a host first applies a rule, which we describe below, to the MAC address of each of the network interfaces it has. MAC addresses are of course, unique, and it is this property which makes autoconfiguration as practical as it is. (If the uniqueness of the addresses were in question, then a host could just randomly formulate an address, but the lack of a tight coupling between node and address would create havoc for network managers. In fact, the use of the MAC address, which may be tied to a removable Ethernet card rather than the node itself, is one of the downsides of the scheme.)

The rule that is applied transforms the MAC address into an interface ID is shown in Figure 3-4. It works in the following way. Suppose you have a MAC address on your Ethernet card of 00:50:8B:C8:E6:76. First, the seventh bit of the address (which is defined by the Ethernet standard to be the “universal/local” bit), is set giving 02:50:8B:C8:E6:76. Then this is split into two halves, 02:50:8B and C8:E6:76. Finally, FF:FE is inserted between them. In this case it would form 02:50:8B:FF:FE:C8:E6:76.

Figure 3-4. Automatic generation of host identifiers

These 64 bits are called an EUI-64 identifier, after the globally unique IEEE identifier, and are used as the interface identifier in stateless autoconfiguration. Initially, the link-local prefix fe80:: will have these 64 bits appended to form a tentative link-local address.

These newly-formed addresses, once they are tested for duplication via DAD, can thereafter be used for network communication with the node’s neighbors. When router advertisements are received, the host can perform the process of concatenating the advertised prefixes with the interface identifier to produce other addresses. Thus link-local addresses can be generated without any connection to the outside world—perfect for an accountant’s office, or other small-office/home-office scenario where internal network resources are more important. In this situation, name resolution can be done via broadcasts or similar mechanisms that do not require Internet access or a server. (Addressing in networks containing more than one link is more complex and really requires either global addresses or unique local addressing.)

The advertisements of prefixes also include information to say how long the prefix is valid for. As long as the router continues to re-advertise the prefix, then the address will remain valid. If a router stops advertising a prefix then the address can become deprecated after the prefix’s valid lifetime elapses. Deprecated addresses can still be used, but other addresses are preferred for new communication. For this reason, addresses that have not been deprecated are sometimes called preferred addresses.

It is important to understand that the address generation ability of stateless autoconfiguration does not have to be invoked unless the administrator, should there be one, decides so. Some people, upon hearing of the mechanism, imagine it being applied to their servers and firewalls and so on, and the thought of them changing addresses arbitrarily if a network card fails and has to be replaced is unsettling. Thankfully, addresses in IPv6 can be statically defined just as IPv4 addresses are today, and neighbor discovery will take care of everything.

Privacy is another concern raised by autoconfiguration. If a laptop moves from network to network, using autoconfigured addresses, it will use the same interface ID on each network. This could allow the tracking of that laptop as its owner moves from work, to home, to the airport and so on. RFC 3041 proposes a extension to autoconfiguration where extra temporary addresses are generated, which can be used for outgoing connections to preserve the users privacy. These addresses are generated using MD5 and some random data associated with the node, and are disposed of periodically to make tracking impractical.

Autoconfiguration of IPv6 addresses makes it relatively simple to change the addresses assigned to groups of machines, by changing the prefixes advertised by routers. This reassignment of address is commonly referred to as renumbering. Hosts are easy, but what about routers themselves? An automatic way to renumber these also is required, since otherwise large networks^[13] would require significant manual intervention to renumber anyway. Thankfully RFC 2894 provides a solution to the problem.

RFC 2894 defines a router renumbering ICMP message. These messages act like a search-and-replace operation on the existing prefixes used by the router, and can also change parameters like the prefix lifetime. The three operations that can be performed are ADD (adds new prefixes based on matching existing prefixes), CHANGE (adds new prefixes, but also deletes existing matching prefixes) and SET-GLOBAL (like change, but removes all global scope addresses, rather than just matching ones). Each of these operations can match a single prefix and produce several new prefixes from it.

To take an example, suppose we are moving a customer from the prefix 2001:db8:dead:/48 to 2001:db8:babe:/48, but otherwise want to leave the structure of their network intact. We first send a message to all routers, telling them that if the router has a prefix 2001:db8:dead:XXXX/64, then to add a new prefix 2001:db8:babe:XXXX/64, where the XXXX bits are copied from the old prefix to the new one. Then we can send a message to shrink the lifetime associated with prefixes under 2001:db8:dead:/48, so deprecation will occur more quickly. Finally, we can send out another change request to remove all prefixes under 2001:db8:dead:/48.

Router renumbering has serious implications for security, so updates need to be authenticated with IPsec. Furthermore, for ease of operation it would be desirable to have the site-local all-routers address listening for updates. Of course, while router renumbering provides a good way to renumber the routing infrastructure, it doesn’t obviously extend to renumbering servers that may have manually configured IPv6 addresses on interfaces or stored in configuration files. These factors mean that renumbering is not as simple as one would like in the IPv6 world.

Most of the aspects of multicast that we have discussed in this section relate to link-local multicast, which doesn’t involve the forwarding of packets across networks. When multicast groupings organizations, or the whole Internet, routers need to be involved. One of the basic things a router needs to know is the list of multicast groups in which the nodes it routes for are interested. This is where Multicast Listener Discovery (MLD) is used.

MLD (RFC 2710) has three message types. The first, Multicast Listener Query, allows a router to find a specific multicast address or all that nodes have joined. The second, Multicast Listener Report, announces that someone is listening on a specific group. The final, Multicast Listener Done, lets a router know that all the listeners on an address may be finished and it should send a query to make sure. The specifics of the protocol ensure that only a small number of these messages need to be sent to keep the local routers up to date.

Routers will usually use multicast promiscuous mode for MLD (see the Section 3.3.4 earlier in this chapter). The routing of multicast traffic between routers is a more complex issue, addressed by protocols such as PIM. There are two types of PIM, sparse mode and dense mode. Sparse mode was described in RFC 2362, but http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-v2-new-11.txt is the draft that describes the current state of sparse mode PIM. Likewise, http://www.ietf.org/internet-drafts/draft-ietf-pim-dm-new-v2-05.txt describes dense mode PIM.

Figure 3-1 shows the ICMPv6 message types that have been formalized by IANA. We’ve ordered these messages by the value of the ICMPv6 type field, and grouped them by function.

In Section 3.2.1 earlier in this chapter, we observed that the IPv4 notion of including options directly within the main header had been abandoned. However, IP options did serve a purpose, and that purpose is now achieved in IPv6 using extension headers. These headers are chained together. Within the IPv6 header the Next Header field tells you the type of the next extension header, which in turn has a Next Header and so on. The basic types of header discussed in RFC 2460 are the Hop-by-Hop Options header (type 0), the Routing header (type 43), the Fragment header (type 44), and the Destination Options header (type 60).

To make sure this process of chaining headers together terminates, there are a few special types of Next Header that do not themselves have a Next Header field. These include 6 = TCP, 17 = UDP, 58 = ICMPv6 and the rather odd 59, which means “there is no next header.”

For example, Figure 3-5 shows an IPv6 packet containing an IPv6 header, followed by a routing header, followed by TCP header and data.

Figure 3-5. Use of the Next Header field

Aside from the Hop-by-Hop header, none of these headers are processed by a node simply forwarding a packet. If there is a Hop-by-Hop Options header, it must be immediately after the IPv6 header. This means that in the usual case a router won’t have to look beyond the IPv6 header and doesn’t have to go far to analyze the Hop-by-Hop header.

Another feature of extension headers is that although they can be variable sized, they must be a multiple of eight bytes in length, and fields within them must be suitably aligned for efficient access.

All IPv6 nodes should understand the extension headers discussed in RFC 2460, and also the authentication and ESP headers related to IPsec. If a node comes across a header it does not understand, then the packet will be dropped and an ICMPv6 parameter problem message will be generated. Note that since intermediate routers do not look beyond the Hop-by-Hop header they don’t have to understand all the headers that they forward.

What happens if you want to send some option, and it doesn’t matter if the node processing it understands it? This is provided for in the Hop-by-Hop and Destination Options headers. The options included within these headers fall into different four classes, according to what happens if they are not understood. The actions corresponding to these classes are “skip me and keep processing,” “drop the packet,” “drop the packet and send a ICMPv6 parameter problem message,” and “drop the packet and send a ICMPv6 parameter problem message providing the packet is not a multicast packet.” This provides enough flexibility to allow options to be either hints that can be ignored or made essential to the correct processing of the packet. In the latter case you can test if the option is supported by sending it and waiting for an ICMP response.

So, what can we actually do with these extension headers and the options they may contain? Table 3-7 shows a summary, but let us run through them briefly.

Probably the most exciting of the Hop-by-Hop options is the Jumbo Payload option defined in RFC 2675. This implements one of the oft-hailed improvements of IPv6 over IPv4; to wit, more efficient handling of high-speed data. Usually IP packets are limited in size to 64KB, but this option permits the sending of IP packets of potentially up to 4GB in size! By sending larger packets, you reduce the fraction of the time sending header information. Naturally, this option will be most useful in networks where the maximum physical packet size is bigger than the old limit of 64KB.^[15]

The other important Hop-by-Hop option is the Router alert option, which means a router should process this packet as well as forwarding it, and might be used in a multicast packet. The least interesting of the Hop-by-Hop and Destination options are the padding options, which allow the options header to be padded to the right size and the options therein to be aligned correctly. The other destination options relate to IPv6 mobility, which we describe in Section 3.7 later in this chapter.

The IPv6 routing header can specify variants of the usual routing procedure. The type 0 variant of this implements source routing, in the sense that the packets must go via a number of prescribed intermediate routers. In the IPv4 world, this would be described as loose source routing.^[16]

The Fragmentation header allows a source node to fragment packets, fulfilling much the same role as, and containing similar fields to the IPv4 header. This means it is still possible to send IP packets larger than the MTU of a link, but that the hard work must be done by end-nodes rather than the routers.

The authentication and ESP headers relate to IPsec, which we discuss in Section 3.9 later in this chapter.

With no checksum in the IPv6 header, catching errors in transit is left to upper layer checksums in IPv6. Also, extension headers mean that between the IPv6 header and the TCP/UDP/ICMPv6 header there may be arbitrary data. Consequently, upper layer checksums, that would have traditionally included the IP header, are instead defined to be calculated using a pseudo-header, which includes the source address, final destination address, the length of the upper-layer packet and the type of upper-layer packet. This is to avoid any confusion that might arise from Routing headers or Hop-by-Hop options which might change in transit.

The basic IPv6 header is quite a bit larger than the IPv4 header,^[17] and with extension headers could add up to a significant portion of the MTU. Header compression is a technique already in use in the IPv4 world and has been extended to cover IPv6. In fact, header compression in IPv6 can actually reduce headers to an overall proportion of packet size smaller than IPv4, thanks to the removal of frequently changing fields such as the IPv4 header checksum. Hence this is an ideal mechanism for link-expensive hosts to use, such as dial-up hosts and cellular devices.

The basic idea in header compression is that the non-payload data in a given data flow generally don’t change very much. In other words, if you are downloading a large file using ftp for example, the packets that flow back and forth are mostly composed of application data (the contents of the file) and the bits of the headers that describe how much data must be acknowledged, and so on. Most of the header bits don’t change at all in a given communication, and hence we can optimize for the common case by sending full length headers at the start of packet exchanges, with periodic updates, and only send “the differences” in between.^[18]

There are two proposals on how to do header compression worth noting. First, there is a scheme defined in RFC 2507, published in February 1999, which has been around for a long time. Unfortunately it appears that this scheme does not deal tremendously well with high-loss links (as used by cellular/3Gdevices) so it, together with its supporting materials, are being reworked by the ROHC (RObust Header Compression) working group of the IETF. This work is taking place in a long series of RFCs, the most immediately relevant ones being RFC 3096 and RFC 3095. ROHC is not just addressing standard IP/TCP headers, they are also working on compressing headers for higher level application protocols like RTP^[19] that will find themselves running over wireless links more and more.

RIPng is defined in RFC 2080 and is very similar to its IPv4 forebear. It is designed for use in small to medium organizations that don’t have a complicated routing setup. How does it work?

Well, each router sends messages (in UDP packets, port 521) that tell its neighbors what prefixes it knows how to reach and the metric associated with each prefix. A router may see a prefix advertised with several different metrics, so to choose the best one it adds a link related cost to each and then chooses the smallest. The cost assigned to each link is usually 1, so that the metric is actually a count of the number of links you must cross to reach that prefix.

Once a router has calculated the best available prefix and metric, it then advertises these new metrics and on to its neighbors. It also advertises prefixes that it can reach directly.

To stop routes hanging around forever, RIP expires routes that it hasn’t seen advertised recently and also considers a metric of 16 to be so big that the route isn’t worth considering.

Furthermore, it includes mechanisms for reducing the chance of routing loops, to only advertise changes and to avoid flooding the network in the case of frequent updates.

So, other than allowing IPv6 addresses in the protocol, what are the IPv6 specific details in RIPng? Well, RIPng uses the link-scope multicast address FF02::9 when it wants to send a message to all its neighbors. Also, routers are expected to specify their addresses as link-local addresses in RIP packets. Link-local addresses are good (in this case) for routing because you know they won’t change if the network is renumbered.

With RIP, all you learn about a prefix is its metric, which tells you how many hops away it is. For this reason RIP is sometimes called a distance vector protocol. Sometimes the distance to a prefix isn’t enough to make a good routing decision.

OSPF has a different take on the problem. Rather than transmitting a prefix and a metric, each router transmits the information about the links attached to it, making it a link state protocol. This information is propagated through the network (in other words, routers pass this information on) and means that all routers have a full picture of the network. Then each router can make a decision based on the global situation about what routes it should use. The rule used is to choose the shortest path, where shortest is defined in terms of a combination of weights associated with each link.

Since OSPF routers have a full picture of the network, they don’t have the same problems with loops or maximum hop counts that RIP has. However, there is a significant amount of complexity required to make OSPF practical and stable, and much of the OSPF protocol deals with this. To understand the details of OSPF takes more space than we have here, and for more details we refer you to John Moy’s books on the protocol: OSPF: Anatomy of an Internet Routing Protocol and OSPF Complete Implementation (both published by Addison-Wesley).

OSPF for IPv6 is defined in RFC 2740, and it basically operates like a fully-featured IPv4 OSPF that understands IPv6 addresses instead of IPv4 addresses. Section 2 of the RFC is dedicated to describing the differences between OSPFv2 (RFC 2328) and and OSPF for IPv6. Perhaps the most interesting of these from an operational point of view are:

IS-IS is a routing protocol very similar in idea to OSPF: it is also a link-state protocol and uses shortest-path routing, again based on metrics assigned to links. The main difference between IS-IS and OSPF is that IS-IS is part of the OSI protocol suite and turns out to be slightly more protocol agnostic than OSPF. The original additions to IS-IS for routing IPv4 are described in RFC 1195 and the minor extras for IPv6 are now being finalized at the IETF.

IS-IS, when used to route IP, is sometimes referred to as integrated IS-IS. Here “integrated” refers to the fact that you could run a single IS-IS instance on a router to route IP and ISO protocols. The advantages of this include reduced processing overhead on routers, and also a single routing protocol for network management staff to worry about.

With the appearance of IPv6, a single IS-IS instance can now route IPv4, IPv6 and ISO protocols. This has appeal for some network operators, and they have moved to IS-IS so that they can route their IPv4 and IPv6 traffic with a single protocol. Others have chosen IS-IS just for IPv6, so that they have a degree of protocol redundancy within their network (or maybe just to get a feel for a different IGP). Possibly for these reasons, it seems that IS-IS may end up being the most popular IGP for IPv6.

Interestingly, from a protocol point of view, IS-IS doesn’t use TCP, UDP, IPv4 or IPv6, but instead uses its own ISO protocol for the exchange of routing information. This means that configuring IS-IS involves assigning ISO addresses to the routers in your network that will speak IS-IS.

The BGP protocol is different from the previous routing protocols we’ve discussed for a few reasons. First, it is designed for routing between many independent networks, rather than routing within an organization. It is the protocol that determines the routes between all the networks in the Internet. To make things manageable, each network is treated as a black box: BGP can see where the networks connect to each other, but it can’t see inside the networks. These black boxes are called autonomous systems (ASs).

Even still, the number of networks that BGP has to deal with is large and the number of links even larger. For this reason, using a link-state protocol isn’t feasible. A distance-vector protocol isn’t practical either because there are just too many hops and loops in the Internet.

BGP operates in a hybrid area between distance-vector and link-state. As in distance-vector, a router only tells its neighbors about the best route it has to a network, but rather than just telling them the metric of this route, it also communicates other information, including the list of ASs the best route goes through. This means that BGP may not know the state of all the links in the Internet, but it does at least know the hops along the routes it wants to use. This information can be used to avoid routing loops by discarding routes that would go through an AS twice.

As well as this AS path information, a BGP router also communicates a selection of information about how desirable various routes are. There are a dizzying array of rules and configuration knobs that can be used to get BGP to route traffic in particular ways. A lot of the operational complexity of BGP arises from these parameters.

In terms of low-level details, BGP-4 (RFC 1771) has a set of extensions to deal routing information for arbitrary protocols (RFC 2858). The details for IPv6 are made explicit in RFC 2545.

BGP actually runs over TCP (port 179), which means it can use IPv4 or IPv6 for transport. However, the address of the remote router can be important for calculating next hops, so if you are transporting IPv6 routing information over an IPv4 TCP session you may need to explicitly configure information about the next hop. (Typically, one would bring up two BGP sessions in parallel—one over IPv4, one over IPv6—and over each session one would exchange only the routing information specific to that protocol.)

Like OSPF, BGP also uses a router ID in the protocol, which remains a 32-bit number. For routers with IPv4 addresses, this ID is usually one of those addresses. If you have an IPv6-only router, the Router ID has to be configured manually.

BGP does have limitations that may become a problem as time progresses. For example, ASs are identified by 16 bit numbers, so some day we’ll run out of AS numbers, just like IPv4 addresses. A protocol called IDRPv2 was supposed to address these, and other more complex issues. Today, however, BGP remains the routing protocol of the IPv6 backbone.

IPv6’s scalability, the darling of many press releases, is perhaps best broken into two capabilities. First, the capability of the protocol to rise to the task of addressing and routing both the existing and the future Internet. We think everyone can agree that IPv6 has been engineered with this in mind, by allowing lots of address space for hosts and countering the routing problems with a more hierarchical address space, while being flexible enough for future developments. Second, the ability of the protocol to be extended naturally to meet future, as yet unknown, requirements. A very important component of this is the Extension Headers facility.

IPv6 offers significant mobility and security features which, unfortunately, by their nature, are not as simple as might be desired. While support for IPsec is widely available, configuring for interoperability can be tricky. Mobility is at an earlier stage of development, and while implementations are available, full implementations are not yet widely shipped.