10.1 IPv6 Addressing and types
Because of the length of IPv6 addresses, it is impractical to represent them the same way as IPv4 addresses. At 128 bits, IPv6 addresses are four times the length of IPv4 addresses, so a more efficient way of representing them is called for. As a result, each of the eight groups of 16 bits in an IPv6 address is represented in hex, and these groups are separated by colons, as follows: 1234:5678:9ACB:DEF0:1234:5678:9ABC:DEF0
In IPv6, as in IPv4, unicast addresses have a two-level network:host hierarchy (known in IPv6 as the prefix and interface ID) that can be separated into these two parts on any bit boundary in the address. The prefix portion of the address includes a couple of components, including a global routing prefix and a subnet. However, the two-level hierarchy separates the prefix from the interface ID much like it divides the network and host portions of an IPv4 address. Instead of using a decimal or hex subnet mask, though, IPv6 subnets use slash notation to signify the network portion of the address, as follows:
1234:5678:9ABC:DEF0:1234:5678:9ABC:DEF0/64
An IPv6 address with a prefix length of 64 bits, commonly called a /64 address in this context, sets aside the first half of the address space for the prefix and the last half for the interface ID.
IPv6 Header Overview
The IPv6 header is 40 bytes long and contains fields pertaining to version, traffic class, flow label, payload length, next header, hop limit, source address, and destination address. The figure below depicts the IPv6 header as expressed in Request for Comments (RFC) 2460 (www.ietf.org/rfc/rfc2460.txt).
Version Field
The version field in the IPv6 header is so that Internet mechanisms that know how to route, or even speak routing protocols, will know what type of routing protocol they are about to deal with. Notice the similarities to IPv4. In the case of IPv6, the Version field is a 4-bit integer, with the value of 6 (0110 in binary), to designate this packet as an IP version 6 packet.
Traffic Class Field
The traffic class field is an 8-bit field in which some sort of traffic differentiation identifier can be placed. Currently, in the IETF, many working groups are dedicated to coming up with the best way to utilize this type of differentiation mechanism (though they mostly concentrate on IPv4 today). One example of such a group is the DiffServ (Differentiated Services). The members of DiffServ are trying to come up with a way to give more important traffic a higher priority for routing on the Internet today. This field was designed for things such as IP Precedence bits (giving certain values of this field higher priority, and then using differentiated queuing strategies in the router to tell "who goes first").
Flow Label Field
The flow label field is a 20-bit field used when special handling of a packet is needed. Common interpretation of this field at the time of this writing is that the field will assign flow labels in order to engineer different traffic patterns in an IPv6 network. The major player in this (though for mostly IPv4 at this time) is the Multi-Protocol Label Switching (MPLS) working group. This group's main intention is to come up with an efficient way to assign labels to flows, and to come up with an efficient and scalable way to route based on these flows. A flow can be defined as any class of traffic going from one point to anther, whether point-to-point traffic, or a TCP flow from one end-station at a given port to a destination end-station on a given port. The possibility of assigning flows opens up many interesting options for deployment. Perhaps QoS (quite a buzzword in the field today) can be deployed with scalability this way. Many Internet providers are keeping their eyes wide open as this working group develops, because advanced services that the MPLS working group sees as feasible could lead to groundbreaking new developments in the Internet industry as a whole.
Payload Length Field
The payload length field is a 16-bit integer used to designate the length of the payload (the data) in the IPv6 packet, in octets. Notice this field is 16 bits long (2 raised to the power 16), which gives us more than 64,000 different possibilities, enabling IPv6 to have fairly big packets (more than 64,000 bytes). The capability to make big packets can increase the efficiency of the Internet as a whole. When your packets are bigger, the number of packets needed to send a given amount of data becomes smaller for a given flow. When a router has fewer packets to route, it has more time to route other packets, or to perform other tasks (routing table maintenance, cache aging, and so on.). You can see how this can help to increase Internet efficiency altogether. Note that any extension headers outside this header are included in the total packet length in this case. Compare this with the IPv4 case (RFC 791) where the total length field includes the IPv4 main header.
Next Header Field
The next header field is designated to tell routers if any other headers need to be looked at for the packet to route according to instruction. This feature differs drastically from the IPv4 case, where only one header has a fixed length. The IPv6 main header has a fixed length as well (enabling routers to know beforehand how much of the packet they need to read), but has built-in functionality to stack other headers that provide other value-added services on top of the main header. This field is 8 bits in length, allowing for up to 255 types of
Next-Headers. Currently, only a finite amount of Next-Headers are developed. Here is a list of the ones currently on the plate:
Hop by Hop Options Header
Destination Options Header I
Routing Header
Fragment Header
Authentication Header
Encapsulating Security Payload Header
Destination Options Header II
The preceding list shows the selection of Next-Header fields that can occur in an IPv6 packet. These headers are listed in order of the appearance they would make in an IPv6 packet utilizing this extra functionality. All these headers will be discussed in detail in the previous chapter.
10.1.1 Address Abbreviation Rules
Even in the relatively efficient format shown earlier, the previous IPv6 addresses can be cumbersome because of their sheer length. As a result, a couple of abbreviation methods are used to make it easier for us to work with them. These methods include the following:
Whenever one or more successive 16-bit groups in an IPv6 address consist of all 0s, that portion of the address can be omitted and represented by two colons (::). The two-colon abbreviation can be used only once in an address, to eliminate ambiguity.
When a 16-bit group in an IPv6 address begins with one or more 0s, the leading 0s can be omitted. This option applies regardless of whether the double-colon abbreviation method is used anywhere in the address.
Here are some examples of the preceding techniques, given an IPv6 address of 2001:0001:0000:0000:00A1:0CC0:01AB:397A. Valid ways of shortening this address using the preceding rules include these:
2001:1:0:0:A1:CC0:1AB:397A
2001:0001::00A1:0CC0:0174AB:397A
2001:1::A1:CC0:1AB:397A
All of these abbreviated examples unambiguously represent the given address and can be independently interpreted by any IPv6 host as the same address.
10.1.2 IPv6 Address Types
Like IPv4 addresses, several types of IPv6 addresses are required for the various applications of IPv6 as a Layer 3 protocol. In IPv4, the address types are unicast, multicast, and broadcast. IPv6 differs slightly in that broadcast addressing is not used; special multicast addresses take the place of IPv4 broadcast addresses. However, three address types remain in IPv6: unicast, multicast, and anycast.
IPv6 Address Types
Address Type |
Range |
Application |
|---|---|---|
|
Aggregatable global unicast |
2000::/3 |
Host-to-host communication; same as IPv4 unicast. |
|
Multicast |
FF00::/8 |
One-to-many and many-to-many communication; same as IPv4 multicast. |
|
Anycast |
Same as Unicast |
Application-based, including load balancing, optimizing traffic for a particular service, and redundancy. Relies on routing metrics to determine the best destination for a particular host. |
|
Link-local unicast |
FE80::/10 |
Connected-link communications. |
|
Solicited-node multicast |
FF02::1:FF00:0/104 |
Neighbor solicitation. |
Many of the terms in this Table are exclusive to IPv6. The following sections examine each of the address types listed in the table.
10.1.2.1 Unicast
Unicast IPv6 addresses have much the same functionality as unicast IPv4 addresses, but because IPv6's 128-bit address space provides so many more addresses to use, we have much more flexibility in assigning them globally. Because one of the intents for IPv6 addressing in public networks is to allow wide use of globally unique addresses, aggregatable global unicast IPv6 addresses are allocated in a way in which they can be easily summarized to reasonably contain the size of global IPv6 routing tables in service provider networks. In addition to aggregatable global unicast addresses, several other aspects of IPv6 unicast addressing deserve mention here and follow in the next few sections.
10.1.2.2 Aggregatable Global Addresses
In current usage, aggregatable global addresses are assigned from the IPv6 addresses that begin with binary 001. This value can be written in prefix notation as 2000::/3, which means "all IPv6 addresses whose first 3 bits are equal to the first 3 bits of hex 2000." In practice, this includes IPv6 addresses that begin with hex 2 or 3. To ensure that IPv6 addresses can be summarized efficiently when advertised toward Internet routers, several global organizations allocate these addresses to service providers and other users. See RFC 3587 and RFC 3177 for more details.
Aggregatable global address prefixes are structured so that they can be strictly summarized and aggregated through a hierarchy consisting of a private network and a series of service providers. Here is how that works, based on RFC 3177, starting after the first 3 bits in the prefix:
The next 45 bits represent the global routing prefix.
The last 16 bits in the prefix, immediately preceding the Interface ID portion of the address, are Site Level Aggregator (SLA), bits. These bits are used by an organization for its own internal addressing hierarchy. This field is also known as the Subnet ID.
The last 64 bits make up the interface ID.
The interface ID portion of an aggregatable global IPv6 address can be explicitly assigned in Cisco IOS or derived using a number of different methods. These addresses should use an Interface ID in the modified EUI-64 format. Depending on how these addresses are assigned, however, the Universal/Local bit, which is the 7th bit in the Interface ID field of an IPv6 address, can be set to 0 (locally administered) or 1 (globally unique) to indicate the nature of the Interface ID portion of the address.
10.1.2.3 Link-Local Addresses
As the term implies, link-local addresses are used on a data link or multiaccess network, such as a serial link or an Ethernet network. Because these addresses are link-local in scope, they are guaranteed to be unique only on that link or multiaccess network. Each interface type, regardless of whether it is serial, PPP, ATM, Frame Relay, Ethernet, or something else, gets a link-local address when IPv6 is enabled on that interface. Link-local addresses always begin with FE80::/10. The Interface ID portion of the address is derived using the modified EUI-64 format. The remaining 54 bits of the prefix are always set to 0.
On Ethernet interfaces, the IEEE 802 MAC address is the basis for the Interface ID. For other interface types, routers draw from a pool of virtual MAC addresses to generate the Interface IDs. An example of a fully formed link-local address follows:
FE80::207:85FF:FE80:71B8
As you might gather from the name, link-local addresses are used for communication between hosts that do not need to leave the local segment. By definition, routers do not forward link-local traffic to other segments. Link-local addresses are used for operations such as routing protocol neighbor communications, which are by their nature link-local.
10.1.2.4 IPv6 Multicast
Multicast for IPv6 functions much like IPv4 multicast. It allows multiple hosts to become members of (that is, receive traffic sent to) a multicast group without regard to their location or number. A multicast receiver is known as a group member, because it joins the multicast group to receive traffic. Multicast addresses in IPv6 have a specific format, which is covered in the next section.
Because IPv6 has no broadcast addressing concept, multicast takes the place of all functions that would use broadcast in an IPv4 network. For example, the IPv6 DHCP process uses multicast for sending traffic to an unknown host on a local network.
As in IPv4, IPv6 multicast addresses are always destinations; a multicast address cannot be used as a source of any IPv6 traffic.
Multicast addresses in IPv6 always begin with FF as the first octet in the address, or FF00::/8. The second octet specifies the lifetime and scope of the multicast group. Lifetime can be permanent or temporary. Scope can be local to any of the following:
Node
Link
Site
Organization
Global
The table below shows several well-known IPv6 multicast group addresses and their functions.
IPv6 Multicast Well-Known Addresses
| Function | Multicast Group | IPv4 Equivalent |
|---|---|---|
| All hosts | FF02::1 | Subnet broadcast address |
| All Routers | FF02::2 | 224.0.0.2 |
| OSPFv3 routers | FF02::5 | 224.0.0.5 |
| OSPFv3 designated routers | FF02::6 | 224.0.0.6 |
| EIGRP routers | FF02::A | 224.0.0.10 |
| PIM routers | FF02::D | 224.0.0.13 |
10.1.2.5 Anycast
In some applications, particularly server farms or provider environments, it may be desirable to pool a number of servers to provide redundancy, load balancing, or both. Several protocols can provide this functionality in IPv4 networks.
IPv6 has built-in support for this application in the form of anycast addressing. Anycast addresses can be assigned to any number of hosts that provide the same service; when other hosts access this service, the specific server they hit is determined by the unicast routing metrics on the path to that particular group of servers. This provides geographic differentiation, enhanced availability, and load balancing for the service.
Anycast addresses are drawn from the IPv6 unicast address pool and, therefore, are not distinguishable from unicast addresses. RFC 2526 recommends a range of addresses for use by anycast applications. Once an address is assigned to more than one host, it becomes an anycast address by definition. Because anycast addresses cannot be used to source traffic, however, a router must know if one of its interface IPv6 addresses is an anycast address. Therefore, Cisco IOS Software requires the anycast keyword to be applied when an anycast address is configured, as in this example:
TestKing1(config-if)# ipv6 address 2002:ffee::102/64 anycast
All IPv6 routers additionally must support the subnet router anycast address. This anycast address is a prefix followed by all 0s in the interface ID portion of the address. Hosts can use a subnet router anycast address to reach a particular router on the link identified by the prefix given in the subnet router anycast address.
10.1.2.6 The Unspecified Address
One additional type of IPv6 address deserves mention in this section, as it is used for a number of functions in IPv6 communications. This address is represented simply by ::. The unspecified address is always a source address used by an interface that has not yet learned its unicast address. The unspecified address cannot be assigned to an interface, and it cannot be used as a destination address.
10.1.3 IPv6 Address Autoconfiguration
One of the goals of IPv6 is to make life easier for network administrators, especially in dealing with the almost unimaginably vast address space that IPv6 provides compared to IPv4. Automatic address configuration, or simply autoconfiguration, was created to meet that need.
An IPv6 host can automatically configure its complete address, or just the interface ID portion of its address, depending on which of the several methods for autoconfiguration it uses. Those methods include
Stateful autoconfiguration
Stateless autoconfiguration
EUI-64
One method, stateful autoconfiguration, assigns a host or router its entire 128-bit IPv6 address using DHCP. Another method, stateless autoconfiguration, dynamically assigns the host or router interface a 64-bit prefix, and then the host or router derives the last 64 bits of its address using the EUI-64 process.