154

IPv6

many of the protocols have been given different names, which can confuse the unwary (e.g. Address Resolution Protocol has been replaced by Neighbour Discovery). In many cases, these renamed protocols have also acquired extra functionality or have slightly modified behaviour. Other functions, previously in the realm of higher layer applications, have to a varying extent been subsumed into the base protocol (e.g. Stateless and Stateful autoconfiguration rather than DHCP).

11.2 IPv6 HEADERS

IPv6 dramatically changes the format of the header compared to that used in IPv4. Despite the extension of the address space from 32 to 128 bits (this obviously impacts the source address and destination address in the header), the basic IPv6 headers (40 bytes) are not proportionally larger than the IPv4 headers (24 bytes). This is achieved by creating many extension headers, none of which are mandatory. This provides a hugely flexible mechanism for efficiently adding extra functionality without increasing the overhead on the majority of packets.

11.3 IPv6 ADDRESSING

One of the first issues you will notice about IPv6 is the entirely unfamiliar addressing format. The IPv6 addressing architecture is defined in RFC 3513. Whereas IPv4 has 32-bit addresses presented as four decimal numbers separated by a dot with each decimal number representing 8 bits of address space, IPv6 has 128-bit addresses. These are represented as one to eight blocks of one to four hexadecimal digits. Each block of four digits is separated by a colon. This sounds slightly confusing but it is not so bad, really. Starting with the most basic example, the address is 32 hexadecimal digits in eight blocks of four:

1234:5678:9ABC:DEF0:0000:0000:0000:0001

Note that there are several blocks above in which some of the higher-order bits are zero. If there are leading zeroes in a block of four, they can be ignored so the above can become:

1234:5678:9ABC:DEF0:0000:0000:0000:1

Taking this a step further, if there is a 16-bit block that is entirely zero, the entire block can be reduced to two consecutive colons. This can be further compressed if there is more than one consecutive 16-bit block containing all zeroes. In this case, the entire string of zeroes can be compressed to two colons. Therefore, the address above can be reduced to

1234:5678:9ABC:DEF0::1

Note, the lower-order 0 in DEF0 cannot be removed. If it were removed, it would be equivalent to 0DEF, rather than DEF0.

11.3 IPv6 ADDRESSING

155

The double-colon notation can only be used once in an address. If there were two sets of double-colons, it would be impossible to say how may 16-bit blocks were associated with each. For example, 1234::5678::9ABC could be equivalent to any of the following:

1234:0000:5678:0000:0000:0000:0000:0000:9ABC

1234:0000:0000:5678:0000:0000:0000:0000:9ABC

1234:0000:0000:0000:5678:0000:0000:0000:9ABC

1234:0000:0000:0000:0000:5678:0000:0000:9ABC

1234:0000:0000:0000:0000:0000:5678:0000:9ABC

The addresses above all lack one final thing. As with IPv4, IPv6 addresses can be conceptually broken into a part representing the network and a part representing the host. The number of bits representing the network is known as the prefix length. In IPv4, this is represented either as a dotted quad subnet mask or as a /prefix length. IPv6 has no concept of a ‘dotted quad’ or colon separated mask for that matter. It only uses the /prefix length notation. The prefix length is a number from 0 to 128. So the address above could be represented as:

1234:5678:9ABC:DEF0::1/64

In this example, 1234:5678:9ABC:DEF0 represents the network portion of the address and ::1 represents the host portion.

11.3.1HIERARCHICAL ALLOCATIONS

Now you understand the way in which IPv6 addresses are represented, we should look at the way IPv6 addresses are hierarchically allocated to particular functions. The following are the main functional allocations, which have been created at the time of writing:

•0200::/7—NSAP allocation

•0400::/7—IPX allocation

•2000::/3—Aggregatable Global Unicast Addresses

•FE80::/10—Link Local Addresses

•FEC0::/10—Site Local Addresses (this class of addresses has been formally deprecated but IANA has been requested not the reallocate the address range)

•FF00::/8—Multicast Addresses

11.3.1.1 Format of Aggregatable Global Unicast Addresses

The Aggregatable Global Unicast Address space is where the majority of hosts will initially find their home. Initially, it was further subdivided to create a hierarchy of allocation. Those subdivisions are identified in Figure 11.1.

•Public Topology

•FP is the format prefix (always 001—i.e. 2000::/3).

•TLA ID is the Top Level Aggregator Identifier.

156						IPv6
3		13	8	24	16	64
	F	TLA ID	RES	NLA ID	SLA ID	Interface ID
	P

128 bits

Figure 11.1 Original format of the globally aggregatable unicast addressing scheme

•RES is reserved for future use (always zero).

•NLA ID is the Next Level Aggregator Identifier.

•Site Topology

•SLA ID is the Site Level Aggregator Identifier.

•Interface Identity

•Interface ID is the Interface identifier.

However, this degree of formality in the network portion of the address was deemed too restrictive. Therefore, the aggregatable global unicast address space, currently 2000::/3, is simply broken up as in Figure 11.2.

•Public Topology

•FP is the format prefix (currently 001—i.e. 2000::/3).

•Global Routing Prefix.

•Site Topology

•Subnet ID is allocatable by the holder of the /48 global prefix.

•Interface Identity

•Interface ID is the Interface identifier.

When the first allocation of IPv6 addresses was made by IANA to the Regional Internet Registries (RIRs), it allocated only a single TLA, 0x0001, from within the FP 0x2000

3		45	16			64
F		Global Routing Prefix	Subnet			Interface ID
P			ID
				128 bits

Figure 11.2 Newer format of the globally aggregatable unicast addressing scheme

11.3 IPv6 ADDRESSING

157

giving the prefix 2001::0/16 in order to encourage a cautious allocation policy (and avoid a ‘gold rush’ for IPv6 addresses). This was divided between the RIRs, with each receiving an initial allocation of a /23. These could be further subdivided by the RIRs for allocation to the Local Internet Registries (LIR). The very first allocations to LIRs were /35s, however, the RIRs were free to allocate from their allocations in the manner they saw fit.

Every site is allocated a /48 prefix from which it could allocate up to 65536 subnets (16 bits of Subnet ID) in whatever hierarchical fashion it requires. Each of these subnets could, in theory, sustain up to 264 hosts, although the problems associated with large flat subnets are just as valid with IPv6 as they are with IPv4. In terms of scaling, there is little justification for creating a single subnet with more than 64 bits allocated to the Interface ID. The main question about how to allocate the addresses relates to how multiple subnets might be aggregated at the numerous logical borders within the Internet. By carefully grouping the Subnet IDs, it is possible to significantly reduce the size of the routing table both globally and within the confines of your AS. This is a big issue with IPv4. With IPv6, it is going to be utterly essential to the successful growth of the Internet.

11.3.2ADDRESS CLASSES

In addition to the functional categories listed above, as with IPv4, there are three classes of address in IPv6. However, unlike IPv4, which has unicast, multicast and broadcast, in IPv6 broadcast is considered simply a special case of multicast (i.e. a group to which all hosts belong).

•Unicast Addresses. As with IPv4, the main form of communication in IPv6 is between two hosts, i.e. unicast. The global aggregatable unicast address format has already been discussed in this section. With the exception of the addresses specifically allocated to multicast (see below), all addresses are considered to be unicast addresses.

•Multicast Addresses. Again, in common with IPv4, a block of addresses has been set aside specifically for use as multicast group addresses. IANA has allocated FF00::/8 for IPv6 multicast. Within that block, some sub-assignments have been made. FF01::/16 is used for node local scope, FF02::/16 for link local scope and FF05::/16 for site local scope. In addition, there are some ‘well-known’ permanently assigned addresses, which are valid across all scopes. Unsurprisingly, these are known as all-scope addresses. These are described in some detail in RFC 2375.

•Anycast Addresses. Given that one class of addresses has been discarded, it is clear that a new class of address must have been defined. Anycast addresses are used where a single global unicast address is assigned to more than one host. Each of the hosts (or its adjacent gateway/router) announces its address into the global routing table. It is then simply a case of selecting the topologically nearest of the available hosts bearing the same address. An example of the benefit of this mechanism is the geographical distribution of identical content. If a single address is advertised in the global routing