The most obvious and recognizable difference between IPv4 and IPv6 is the IPv6 address. An IPv4 address is 32 bits and expressed in dotted-decimal notation, whereas an IPv6 address is 128 bits in length and written in hexadecimal. However, there are many other differences between the two protocol addresses. IPv6 includes new address types as well as changes to familiar address types.
In this chapter, you will become familiar with reading IPv6 addresses. You will also learn how to represent many IPv6 addresses with fewer digits, using two simple rules.
This chapter examines all the different types of IPv6 addresses in the unicast, multicast, and anycast categories. Some addresses, such as global unicast, link-local unicast, and multicast addresses, have more significance in IPv6. These addresses are examined more closely in Chapter 5, “Global Unicast Address,” Chapter 6, “Link-Local Unicast Address,” and Chapter 7, “Multicast Addresses.”
Representation of IPv6 Addresses
IPv6 addresses are 128 bits in length and written as a string of hexadecimal digits. Every 4 bits can be represented by a single hexadecimal digit, for a total of 32 hexadecimal values (016  through f16 ). You will see later in this section how to possibly reduce the number of digits required to represent an IPv6 address. The alphanumeric characters used in hexadecimal are not case sensitive; therefore, uppercase and lowercase characters are equivalent. Although IPv6 address can be written in lowercase or uppercase, RFC 5952, A Recommendation for IPv6 Address Text Representation, recommends that IPv6 addresses be represented in lowercase.
As described in RFC 4291, the preferred form is x:x:x:x:x:x:x:x. Each x is a 16-bit section that can be represented using up to four hexadecimal digits, with the sections separated by colons. The result is eight 16-bit sections, or hextets, for a total of 128 bits in the address, as shown in Figure 4-1. Figure 4-1 also shows an example of IPv6 addresses on a Windows host and a Mac OS host. These addresses and the format of these addresses will be explained in this chapter.
Figure 4-1 Preferred Form of IPv6 Address
The longest representation of the preferred form includes a total of 32 hexadecimal values. Colons separate the groups of 4-bit hexadecimal digits.
The unofficial term for a section of four hexadecimal values is a hextet, similar to the term octet used in IPv4 addressing. An IPv6 address consists of eight hextets separated by colons. As Figure 4-1 illustrates, each hextet, with its four hexadecimal digits, is equivalent to 16 bits. For clarity, the term hextet is used throughout this book when referring to individual 16-bit segments. The following list shows several examples of IPv6 addresses using the longest representation of the preferred form:
0000:0000:0000:0000:0000:0000:0000:0000 0000:0000:0000:0000:0000:0000:0000:0001 ff02:0000:0000:0000:0000:0000:0000:0001 fe80:0000:0000:0000:a299:9bff:fe18:50d1 2001:0db8:1111:000a:00b0:0000:9000:0200 2001:0db8:0000:0000:abcd:0000:0000:1234 2001:0db8:cafe:0001:0000:0000:0000:0100 2001:0db8:cafe:0001:0000:0000:0000:0200
At first glance, these addresses can look overwhelming. Don’t worry, though. Later in this chapter, you will learn a technique that helps in reading and using IPv6 addresses. RFC 2373 and RFC 5952 provide two helpful rules for reducing the notation involved in the preferred format, which will be discussed next.
Rule 1: Omit Leading 0s
One way to shorten IPv6 addresses is to omit leading 0s in any hextet (that is, 16-bit section). This rule applies only to leading 0s and not to trailing 0s; being able to omit both leading and trailing 0s would cause the address to be ambiguous. Table 4-1 shows a list of preferred IPv6 addresses and how the leading 0s can be removed. The preferred form shows the address using 32 hexadecimal digits.
Table 4-1 Examples of Omitting Leading 0s in a Hextet*
|Leading 0s omitted|| 0: 0: 0: 0: 0: 0: 0: 0
|Leading 0s omitted|| 0: 0: 0: 0: 0: 0: 0: 1
|Leading 0s omitted||ff02: 0: 0: 0: 0: 0: 0: 1
|Preferred||fe80: 0000: 0000: 0000:a299:9bff:fe18:50d1|
|Leading 0s omitted||fe80: 0 : 0: 0:a299:9bff:fe18:50d1
|Preferred||2001: 0db8: 1111:000a:00b0:0000:9000:0200|
|Leading 0s omitted||2001: db8: 1111: a: b0: 0:9000: 200
|Preferred||2001: 0db8: 0000: 0000:abcd:0000:0000:1234|
|Leading 0s omitted||2001: db8: 0: 0:abcd: 0: 0:1234
|Preferred||2001: 0db8: aaaa: 0001:0000:0000:0000:0100|
|Leading 0s omitted||2001: db8: aaaa: 1: 0: 0: 0: 100
|Preferred||2001: 0db8: aaaa: 0001:0000:0000:0000:0200|
|Leading 0s omitted||2001: db8: aaaa: 1: 0: 0: 0: 200
|* In this table, the 0s to be omitted are in bold. Spaces are retained so you can better visualize where the 0s were removed.|
It is important to remember that only leading 0s can be removed; if you deleted trailing 0s the address would be incorrect. To ensure that there is only one correct interpretation of an address, only leading 0s can be omitted, as shown in the following example:
Incorrect (trailing 0s):
Correct (leading 0s):
Rule 2: Omit All-0s Hextets
The second rule for shortening IPv6 addresses is that you can use a double colon (::) to represent any single, contiguous string of two or more hextets (16-bit segments) consisting of all 0s. Table 4-2 illustrates the use of the double colon.
Table 4-2 Examples of Omitting a Single Contiguous String of All-0s Hextets*
|(::) All-0s segments||::|
|(::) All-0s segments||::0001|
|(::) All-0s segments||ff02::0001|
|(::) All-0s segments||fe80::a299:9bff:fe18:50d1|
|(::) All-0s segments||2001:0db8:1111:000a:00b0::0200|
|(::) All-0s segments||2001:0db8::abcd:0000:0000:1234|
|(::) All-0s segments||2001:0db8:aaaa:0001::0100|
|(::) All-0s segments||2001:0db8:aaaa:0001::0200|
|* In this table, the 0s in bold in the preferred address are replaced by the double colon.|
Only a single contiguous string of all-0s segments can be represented with a double colon; otherwise, the address would be ambiguous, as shown in this example:
Incorrect address using two double colons:
Possible ambiguous choices:
2001:0000:0000:0000:0000:abcd:0000:1234 2001:0000:0000:0000:abcd:0000:0000:1234 2001:0000:0000:abcd:0000:0000:0000:1234 2001:0000:abcd:0000:0000:0000:0000:1234
As you can see, if two double colons are used, there are multiple possible interpretations, and you don’t know which address is the correct one.
What happens if you have an address with more than one contiguous string of all-0s hextets—for example, 2001:0db8:0000:0000:abcd:0000:0000:1234? In that case, where should you use the single double colon (::)?
RFC 5952 states that the double colon should represent:
The longest string of all-0s hextets.
If the strings are of equal length, the first string should use the double colon (::) notation.
Therefore, 2001:0db8:0000:0000:abcd:0000:0000:1234 would be written 2001:0db8:: abcd:0000:0000:1234. Applying both Rules 1 and 2, the address would be written 2001:db8::abcd:0:0:1234.
Combining Rule 1 and Rule 2
You can combine the two rules just discussed to reduce an address even further. Table 4-3 illustrates how this works, showing the preferred address, application of rule 1, and application of rule 2. Again, spaces are left so you can better visualize where the 0s have been removed.
Table 4-3 Examples of Applying Both Rule 1 and Rule 2
|Leading 0s omitted||0: 0: 0: 0: 0: 0: 0: 0|
|(::) All-0s segments||::|
|Leading 0s omitted||0: 0: 0: 0: 0: 0: 0: 1|
|(::) All-0s segments||::1|
|Leading 0s omitted||ff02: 0: 0: 0: 0: 0: 0: 1|
|(::) All-0s segments||ff02::1|
|Leading 0s omitted||fe80: 0: 0: 0:a299:9bff:fe18:50d1|
|(::) All-0s segments||fe80::a299:9bff:fe18:50d1|
|Leading 0s omitted||2001: db8:1111: a: b0: 0:9000: 200|
|(::) All-0s segments||2001:db8:1111:a:b0::9000:200|
|Leading 0s omitted||2001: db8: 0: 0:abcd: 0: 0:1234|
|(::) All-0s segments||2001:db8::abcd:0:0:1234|
|Leading 0s omitted||2001: db8:aaaa: 1: 0: 0: 0: 100|
|(::) All-0s segments||2001:db8:aaaa:1::100|
|Leading 0s omitted||2001: db8:aaaa: 1: 0: 0: 0: 200|
|(::) All-0s segments||2001:db8:aaaa:1::200|
Table 4-4 shows the same examples as in Table 4-3, this time showing just the longest preferred form and the final compressed format after implementing both rules.
Table 4-4 IPv6 Address Preferred and Compressed Formats
|Preferred Format||Compressed Format|
Even after applying the two rules to compress the format, an IPv6 address can still look unwieldy. Don’t worry! Chapter 5, “Global Unicast Address,” shows a technique that I call the 3–1–4 rule. Using that rule makes IPv6 global unicast addresses (GUAs) easier to read than an IPv4 address and helps you recognize the parts of a GUA address.