Understanding IPv6

by Joseph Davies

Overview

Your essential guide to deploying IPv6 on Windows networks

Get in-depth technical information to put IPv6 technology to work—including networks with hardware running Windows 8 and Windows Server 2012. Written by a networking expert, this reference explains IPv6 features and benefits, and provides detailed information to help you implement this protocol. You’ll learn best practices for using IPv6 services in your Windows network, whether you’re an IT professional, a network administrator, or an IT student.

Discover how to:

• Use Windows features and tools to implement IPv6 on your network
• Set up a test lab to experiment with IPv6 configuration and functionality
• Understand dynamic routing and the IPv6 routing protocols
• Use IPv6 transition technologies to support both IPv4 and IPv6 during deployment
• Implement IPv6 security features and measures
• Deploy native IPv6 connectivity to an IPv4-only intranet
• Apply best practices from the Microsoft corporate network case study
• Test your understanding of IPv6 concepts with end-of-chapter quizzes

Product Details

ISBN-13:	9780735675025
Publisher:	Pearson Education
Publication date:	06/15/2012
Sold by:	Barnes & Noble
Format:	eBook
Pages:	716
File size:	9 MB
Age Range:	18 Years

About the Author

Joseph Davies is an award-winning author and instructor with 18 years' experience in TCP/IP, networking, and security technologies. His books include Understanding IPV6, Second Edition and Windows Server 2008 TCP/IP Protocols and Services, and he writes the monthly column "The Cable Guy" for Microsoft TechNet.

Read an Excerpt

Chapter 3.

IPv6 Addressing

The IPv6 Address Space

Current Allocation

IPv6 Address Syntax

Compressing Zeros

IPv6 Prefixes

Types of IPv6 Addresses

Unicast IPv6 Addresses

Aggregatable Global Unicast Addresses

Topologies Within Global Addresses

Local-Use Unicast Addresses

Special IPv6 Addresses

Compatibility Addresses

NSAP Addresses

Multicast IPv6 Addresses

Recommended Multicast IPv6 Addresses

Solicited-Node Address

Anycast IPv6 Addresses

Subnet-Router Anycast Address

IPv6 Addresses for a Host

IPv6 Addresses for a Router

Subnetting the IPv6 Address Space

Subnetting for NLA IDs

Subnetting for SLA IDs/Subnet IDs

IPv6 Interface Identifiers

EUI-64 Address-based Interface Identifiers

Temporary Address Interface Identifiers

Mapping IPv6 Multicast Addresses to Ethernet Addresses

IPv4 Addresses and IPv6 Equivalents

References

Testing for Understanding

Chapter 3 IPv6 Addressing

At the end of this chapter, you should be able to:

Describe the IPv6 address space and state why the address length of 128 bits was chosen.

Describe IPv6 address syntax, including zero suppression and compression and prefixes.

Enumerate and describe the function of the different types of unicast IPv6 addresses.

Describe the format of multicast IPv6 addresses.

Describe the function of anycast IPv6 addresses.

Describe how IPv6 interface identifiers are derived.

List and compare the different addressing concepts between IPv4 addresses and IPv6 addresses.

The IPv6 Address Space

The most obvious distinguishing feature of IPv6 is its use of much larger addresses. The size of an address in IPv6 is 128 bits, a bit-string that is four times longer than the 32-bit IPv4 address. A 32-bit address space allows for 232, or 4,294,967,296, possible addresses. A 128-bit address space allows for 2128, or 340,282,366,920,938,463,463,374,607,431,768,211,456 (or 3.4 x 1038), possible addresses.

In the late 1970s, when the IPv4 address space was designed, it was unimaginable that it could ever be exhausted. However, due to changes in technology and an allocation practice that did not anticipate the recent explosion of hosts on the Internet, the IPv4 address space was consumed to the point that by 1992, it was clear a replacement would be necessary.

With IPv6, it is even harder to conceive that the IPv6 address space will ever be consumed. To help put this number in perspective, a 128-bit address space provides 665,570,793,348,866,943,898,599 (6.65 x 1023) addresses for every square meter of the Earth's surface.

It is important to remember that the decision to make the IPv6 address 128 bits in length was not so that every square meter of the Earth could have 6.65 x 1023 addresses. Rather, the relatively large size of the IPv6 address is designed to be divided into hierarchical routing domains that reflect the topology of the modern-day Internet. The use of 128 bits allows for multiple levels of hierarchy and flexibility in designing hierarchical addressing and routing that is currently lacking on the IPv4-based Internet.

Addresses Per Square Meter of the Earth:

The number of 6.65 x 1023 addresses for every square meter of the Earth's surface is derived from the fact that the surface of the Earth is approximately 197,399,019 square miles and there are 2.59 x 106 square meters per square mile. So, the Earth's surface is 197,399,019 x 2.59 x 106, or 511,263,971,197,990 square meters.

Therefore, there are 340,282,366,920,938,463,463,374,607,431,768, 211,456 / 511,263,971,197,990, or 665,570,793,348,866,943,898,599 (or 6.65 x 1023) addresses for each square meter of the Earth's surface.

It is easy to get lost in the vastness of the IPv6 address space. As we will discover, the unthinkably large 128-bit IPv6 address that is assigned to an interface on a typical IPv6 host is composed of a 64-bit subnet identifier and a 64-bit interface identifier (a 50-50 split between subnet space and interface space). The 64 bits of subnet identifier leave enough addressing room to satisfy the addressing requirements of three levels of Internet service providers (ISPs) between your organization and the backbone of the Internet and the addressing needs of your organization. The 64 bits of interface identifier accommodate the mapping of current and future link-layer media access control (MAC) addresses.

Current Allocation

Similar to the way in which the IPv4 address space was divided into unicast addresses (using Internet address classes) and multicast addresses, the IPv6 address space is divided on the basis of the value of high-order bits. The high-order bits and their fixed values are known as a Format Prefix (FP).

Table 3-1 lists the allocation of the IPv6 address space by FPs as defined in RFC 2373.

Table 3-1. Current Allocation of the IPv6 Address Space

Allocation Space Format Prefix (FP) Fraction of the Address

Reserved 0000 0000 1/256

Unassigned 0000 0001 1/256

Reserved for Network Service Access Point (NSAP) allocation 0000 001 1/128

Unassigned 0000 010 1/128

Unassigned 0000 011 1/128

Unassigned 0000 1 1/32

Unassigned 0001 1/16

Aggregatable global unicast addresses 001 1/8

Unassigned 010 1/8

Unassigned 011 1/8

Unassigned 100 1/8

Unassigned 101 1/8

Unassigned 110 1/8

Unassigned 1110 1/16

Unassigned 1111 0 1/32

Unassigned 1111 10 1/64

Unassigned 1111 110 1/128

Unassigned 1111 1110 0 1/512

Link-local unicast addresses 1111 1110 10 1/1024

Site-local unicast addresses 1111 1110 11 1/1024

Multicast addresses 1111 1111 1/256

The current set of unicast addresses that can be used with IPv6 nodes consists of aggregatable global unicast addresses, link-local unicast addresses, and site-local unicast addresses. These addresses represent only 12.7 percent of the entire IPv6 address space.

IPv6 Address Syntax

IPv4 addresses are represented in dotted-decimal format. The 32-bit IPv4 address is divided along 8-bit boundaries. Each set of 8 bits is converted to its decimal equivalent and separated by periods. For IPv6, the 128-bit address is divided along 16-bit boundaries, and each 16-bit block is converted to a 4-digit hexadecimal number and separated by colons. The resulting representation is called colon hexadecimal.

The following is an IPv6 address in binary form:

0010000111011010000000001101001100000000000000000010111100111011

0000001010101010000000001111111111111110001010001001110001011010

The 128-bit address is divided along 16-bit boundaries:

0010000111011010 0000000011010011 0000000000000000 0010111100111011

0000001010101010 0000000011111111 1111111000101000 1001110001011010

Each 16-bit block is converted to hexadecimal and delimited with colons. The result is:

21DA:00D3:0000:2F3B:02AA:00FF:FE28:9C5A

IPv6 address representation is further simplified by suppressing the leading zeros within each 16-bit block. However, each block must have at least a single digit. With leading zero suppression, the result is:

21DA:D3:0:2F3B:2AA:FF:FE28:9C5A

Number System Choice for IPv6:

Hexadecimal (the Base16 numbering system), rather than decimal (the Base10 numbering system), is used for IPv6 because it is easier to convert between hexadecimal and binary than it is to convert between decimal and binary. Each hexadecimal digit represents four binary digits.

With IPv4, decimal is used to make the IPv4 addresses more palatable for humans and a 32-bit address becomes 4 decimal numbers separated by the period (.) character. With IPv6, dotted decimal representation would result in 16 decimal numbers separated by the period (.) character. IPv6 addresses are so large that there is no attempt to make them palatable to most humans, with the exception of some types of IPv6 addresses that contain embedded IPv4 addresses. Configuration of typical end systems is automated and end users will almost always use names rather than IPv6 addresses. Therefore, the addresses are expressed in a way to make them more palatable to computers and IPv6 network administrators who understand the semantics and relationship of hexadecimal and binary numbers.

Table 3-2 lists the conversion between binary, hexadecimal, and decimal numbers.

Table 3-2. Converting Between Binary, Hexadecimal, and Decimal Numbers

Binary Hexadecimal Decimal

0000 0 0

0001 1 1

0010 2 2

0011 3 3

0100 4 4

0101 5 5

0110 6 6

0111 7 7

1000 8 8

1001 9 9

1010 A 10

1011 B 11

1100 C 12

1101 D 13

1110 E 14

1111 F 15

Compressing Zeros

Some types of IPv6 addresses contain long sequences of zeros. To further simplify the representation of IPv6 addresses, a single contiguous sequence of 16-bit blocks set to 0 in the colon hexadecimal format can be compressed to ::, known as a double colon.

For example, the link-local address of FE80:0:0:0:2AA:FF:FE9A:4CA2 can be compressed to FE80::2AA:FF:FE9A:4CA2. The multicast address FF02:0:0:0:0:0:0:2 can be compressed to FF02::2.

NOTE:

You cannot use zero compression to include part of a 16-bit block. For example, you cannot express FF02:30:0:0:0:0:0:5 as FF02:3::5, but FF02:30::5 is correct.

How Many Bits in ::?

To determine how many 0 bits are represented by the ::, you can count the number of blocks in the compressed address, subtract this number from 8, and then multiply the result by 16. For example, in the address FF02::2, there are two blocks (the "FF02" block and the "2" block.) The number of bits expressed by the :: is 96 (96 = (8–2) x 16). Zero compression can be used only once in a given address. Otherwise, you could not determine the number of 0 bits represented by each instance of ::.

IPv6 Prefixes

The prefix is the part of the address where the bits have fixed values or are the bits of a route or subnet identifier. Prefixes for IPv6 subnet identifiers and routes are expressed in the same way as Classless Inter-Domain Routing (CIDR) notation for IPv4. An IPv6 prefix is written in address/prefix-length notation.

For example, 21DA:D3::/48 is a route prefix and 21DA:D3:0:2F3B::/64 is a subnet prefix. As described earlier in this chapter, the 64-bit prefix is used for individual subnets to which nodes are attached. All subnets have a 64-bit prefix. Any prefix that is less than 64 bits is a route or address range that is summarizing a portion of the IPv6 address space.

NOTE:

IPv4 implementations commonly use a dotted decimal representation of the network prefix known as the subnet mask. A subnet mask is not used for IPv6. Only the prefix length notation is supported.

An IPv6 prefix is relevant only for routes or address ranges, not for individual unicast addresses. In IPv4, it is common to express an IPv4 address with its prefix length. For example, 192.168.29.7/24 (equivalent to 192.168.29.7 with the subnet mask 255.255.255.0) denotes the IPv4 address 192.168.29.7 with a 24-bit subnet mask. Because IPv4 addresses are no longer class-based, you cannot assume the class-based subnet mask based on the value of the leading octet. The prefix length is included so that you can determine which bits identify the subnet and which bits identify the host on the subnet. Because the number of bits used to identify the subnet in IPv4 is variable, the prefix length is needed to separate the subnet ID from the host ID.

In IPv6, however, there is no notion of a variable length subnet identifier. At the individual IPv6 subnet level for currently defined unicast IPv6 addresses, the number of bits used to identify the subnet is always 64 and the number of bits used to identify the host on the subnet is always 64. Therefore, while unicast IPv6 addresses written with their prefix lengths are permitted in RFC 2373, in practice their prefix lengths are always 64 and therefore do not need to be expressed. For example, there is no need to express the IPv6 unicast address FEC0::2AC4: 2AA:FF:FE9A:82D4 as FEC0::2AC4:2AA:FF:FE9A:82D4/64. Due to the 50-50 split of subnet and interface identifiers, the unicast IPv6 address FEC0::2AC4:2AA: FF:FE9A:82D4 implies that the subnet identifier is FEC0:0:0:2AC4::/64.

Types of IPv6 Addresses

There are three types of IPv6 addresses:

Unicast

A unicast address identifies a single interface within the scope of the type of address. The scope of an address is the region of the IPv6 network over which the address is unique. With the appropriate unicast routing topology, packets addressed to a unicast address are delivered to a single interface. To accommodate load-balancing systems, RFC 2373 allows for multiple interfaces to use the same address as long as they appear as a single interface to the IPv6 implementation on the host.

Multicast

A multicast address identifies zero or more interfaces. With the appropriate multicast routing topology, packets addressed to a multicast address are delivered to all interfaces identified by the address.

Anycast

An anycast address identifies multiple interfaces. With the appropriate unicast routing topology, packets addressed to an anycast address are delivered to a single interface—the nearest interface that is identified by the address. The nearest interface is defined as being the closest in terms of routing distance. A multicast address is used for one-to-many communication, with delivery to multiple interfaces. An anycast address is used for one-to-one-of-many communication, with delivery to a single interface.

In all cases, IPv6 addresses identify interfaces, not nodes. A node is identified by any unicast address assigned to any one of its interfaces.

NOTE:

RFC 2373 does not define a broadcast address. All types of IPv4 broadcast addressing are performed in IPv6 using multicast addresses. For example, the subnet and limited broadcast addresses from IPv4 are replaced with the link-local scope all-nodes multicast address of FF02::1.

Unicast IPv6 Addresses

The following types of addresses are unicast IPv6 addresses:

Aggregatable global unicast addresses

Link-local addresses

Site-local addresses

Special addresses

Compatibility addresses

NSAP addresses

Aggregatable Global Unicast Addresses

Aggregatable global unicast addresses, also known as global addresses, are identified by the FP of 001. IPv6 global addresses are equivalent to public IPv4 addresses. They are globally routable and reachable on the IPv6 portion of the Internet.

As the name implies, aggregatable global unicast addresses are designed to be aggregated or summarized to produce an efficient routing infrastructure. Unlike the current IPv4-based Internet, which is a mixture of both flat and hierarchical routing, the IPv6-based Internet has been designed from its foundation to support efficient, hierarchical addressing and routing. The scope of a global address is the entire IPv6 Internet.

Figure 3-1 shows the structure of an aggregatable global unicast address.

Figure 3-1. The structure of an aggregatable global unicast address (Image unavailable)

The fields in the aggregatable global unicast address are:

TLA ID — Top-Level Aggregation Identifier. The size of this field is 13 bits. The TLA ID identifies the highest level in the routing hierarchy. TLA IDs are administered by the Internet Assigned Numbers Authority (IANA) and allocated to local Internet registries that, in turn, allocate individual TLA IDs to large, long-haul ISPs. A 13-bit field allows up to 8,192 different TLA IDs. Routers in the highest level of the IPv6 Internet routing hierarchy (called default-free routers) do not have a default route—only routes with 16-bit prefixes corresponding to the allocated TLA IDs and additional entries for routes based on the TLA ID assigned to the routing region where the router is located.

Res — Bits that are reserved for future use in expanding the size of either the TLA ID or the NLA ID (defined next). The size of this field is 8 bits.

NLA ID — Next-Level Aggregation Identifier. The size of this field is 24 bits. The NLA ID allows an ISP to create multiple levels of addressing hierarchy within its network to both organize addressing and routing for downstream ISPs and identify organization sites. The structure of the ISP’s network is not visible to the default-free routers. The combination of the 001 FP, the TLA ID, the Res field, and the NLA ID form a 48-bit prefix that is assigned to an organization’s site that is connecting to the IPv6 portion of the Internet. A site is an organization network or portion of an organization’s network that has a defined geographical location (such as an office, an office complex, or a campus).

SLA ID — Site-Level Aggregation Identifier. The SLA ID is used by an individual organization to identify subnets within its site. The size of this field is 16 bits. The organization can use these 16 bits within its site to create 65,536 subnets or create multiple levels of addressing hierarchy and an efficient routing infrastructure. With 16 bits of subnetting flexibility, an aggregatable global unicast prefix assigned to an organization is equivalent to that organization being allocated an IPv4 Class A network ID (assuming that the last octet is used for identifying nodes on subnets). The structure of the organization’s network is not visible to the ISP.

Interface ID — Indicates the interface on a specific subnet. The size of this field is 64 bits. The interface ID in IPv6 is equivalent to the node ID or host ID in IPv4.

Billions of Sites:

Another way to gauge the practical size of the IPv6 address space is to examine the number of sites that can connect to the IPv6 Internet. With the current FP of 001 and the current definition of the TLA ID (13 bits long) and NLA ID (24 bits long), it is possible to define 237 or 137,438,953,472 possible 48-bit prefixes to assign to sites connected to the Internet. This large number of sites is possible even when we are using only 1/8th of the entire IPv6 address space.

By comparison, using the Internet address classes originally defined for IPv4, it was possible to assign 2,113,389 network IDs to organizations connected to the Internet. The number 2,113,389 is derived from adding up all the possible Class A, Class B, and Class C network IDs and then subtracting the network IDs used for the private address space. Even with the adoption of CIDR to make more efficient use of unassigned Class A and Class B network IDs, the number of possible sites connected to the Internet is not substantially increased nor does it approach the number of possible sites that can be connected to the IPv6 Internet.

Topologies Within Global Addresses

The fields within the global address create a three-level topological structure, as shown in Figure 3-2.

Figure 3-2. The topological structure of the global address (Image unavailable)

The public topology is the collection of larger and smaller ISPs that provide access to the IPv6 Internet. The site topology is the collection of subnets within an organization’s site. The interface identifier specifies a unique interface on a subnet within an organization’s site.

Local-Use Unicast Addresses

There are two types of local-use unicast addresses:

Link-local addresses are used between on-link neighbors and for Neighbor Discovery processes.

Site-local addresses are used between nodes communicating with other nodes in the same organization.

Link-Local Addresses

Link-local addresses, identified by the FP of 1111 1110 10, are used by nodes when communicating with neighboring nodes on the same link. For example, on a single link IPv6 network with no router, link-local addresses are used to communicate between hosts on the link. Link-local addresses are equivalent to Automatic Private IP Addressing (APIPA) IPv4 addresses autoconfigured on Microsoft Windows .NET Server 2003 family, Windows XP, Windows 2000, Windows Millennium Edition, and Windows 98 computers using the 169.254.0.0/16 prefix. The scope of a link-local address is the local link.

Figure 3-3 shows the structure of the link-local address.

Figure 3-3. The structure of the link-local address (Image unavailable)

A link-local address is required for Neighbor Discovery processes and is always automatically configured, even in the absence of all other unicast addresses. For more information about the address autoconfiguration process for link-local addresses, see Chapter 8, "Address Autoconfiguration."

Link-local addresses always begin with FE80. With the 64-bit interface identifier, the prefix for link-local addresses is always FE80::/64. An IPv6 router never forwards link-local traffic beyond the link.

Site-Local Addresses

Site-local addresses, identified by the FP of 1111 1110 11, are equivalent to the IPv4 private address space (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16). For example, private intranets that do not have a direct, routed connection to the IPv6 Internet can use site-local addresses without conflicting with global addresses. Site-local addresses are not reachable from other sites, and routers must not forward site-local traffic outside the site. Site-local addresses can be used in addition to global addresses. The scope of a site-local address is the site.

Figure 3-4 shows the structure of the site-local address.

Figure 3-4. The structure of the site-local address (Image unavailable)

Unlike link-local addresses, site-local addresses are not automatically configured and must be assigned either through stateless or stateful address autoconfiguration. For more information, see Chapter 8, "Address Autoconfiguration."

The first 48 bits are always fixed for site-local addresses, beginning with FEC0::/48. After the 48 fixed bits is a 16-bit subnet identifier (Subnet ID field) that provides 16 bits with which you can create subnets within your organization. With 16 bits, you can have up to 65,536 subnets in a flat subnet structure, or you can divide the high-order bits of the Subnet ID field to create a hierarchical and aggregatable routing infrastructure. After the Subnet ID field is a 64-bit Interface ID field that identifies a specific interface on a subnet.

The global address and site-local address share the same structure beyond the first 48 bits of the address. In global addresses, the SLA ID field identifies the subnet within an organization. For site-local addresses, the Subnet ID field performs the same function. Because of this, you can create a subnetted routing infrastructure that is used for both site-local and global addresses.

For example, a specific subnet of your organization can be assigned the global prefix 3FFE:FFFF:4D1C:221A::/64 and the site-local prefix FEC0:0:0: 221A::/64 where the subnet is effectively identified by the SLA ID/Subnet ID value of 221A. While the subnet identifier is the same for both prefixes, routes for both prefixes must still be propagated throughout the routing infrastructure so that addresses based on both prefixes are reachable.

Special IPv6 Addresses

The following are special IPv6 addresses:

Unspecified address

The unspecified address (0:0:0:0:0:0:0:0 or ::) is used only to indicate the absence of an address. It is equivalent to the IPv4 unspecified address of 0.0.0.0. The unspecified address is typically used as a source address when a unique address has not yet been determined. The unspecified address is never assigned to an interface or used as a destination address.

Loopback address

The loopback address (0:0:0:0:0:0:0:1 or ::1) is used to identify a loopback interface, enabling a node to send packets to itself. It is equivalent to the IPv4 loopback address of 127.0.0.1. Packets addressed to the loopback address must never be sent on a link or forwarded by an IPv6 router.

Compatibility Addresses

To aid in the migration from IPv4 to IPv6 and the coexistence of both types of hosts, the following addresses are defined:

IPv4-compatible address

The IPv4-compatible address, 0:0:0:0:0:0:w.x.y.z or ::w.x.y.z (where w.x.y.z is the dotted decimal representation of a public IPv4 address), is used by IPv6/IPv4 nodes that are communicating with IPv6 over an IPv4 infrastructure that uses public IPv4 addresses, such as the Internet.

IPv4-mapped address

The IPv4-mapped address, 0:0:0:0:0:FFFF:w.x.y.z or ::FFFF: w.x.y.z, is used to represent an IPv4-only node to an IPv6 node. Windows .NET Server 2003 family and Windows XP IPv6 do not support the use of IPv4-mapped addresses.

6over4 address

An address of the type [64-bit prefix]:0:0:WWXX:YYZZ, where WWXX: YYZZ is the colon hexadecimal representation of w.x.y.z (a public or private IPv4 address), is used to represent a host for the tunneling mechanism known as 6over4.

6to4 address

An address of the type 2002:WWXX:YYZZ:[SLA ID]:[Interface ID], where WWXX:YYZZ is the colon hexadecimal representation of w.x.y.z (a public IPv4 address), is used to represent a node for the tunneling mechanism known as 6to4.

ISATAP address

An address of the type [64-bit prefix]:0:5EFE:w.x.y.z, where w.x.y.z is a public or private IPv4 address, is used to represent a node for the address assignment mechanism known as Intra-Site Automatic Tunnel Addressing Protocol (ISATAP).

For more information about IPv6 compatibility addresses, see Chapter 11, "Coexistence and Migration."

NSAP Addresses

To provide a way of mapping Open Systems Interconnect (OSI) NSAP addresses to IPv6 addresses, NSAP addresses use the FP of 0000001 and map the last 121 bits of the NSAP address to an IPv6 address. For more information about the four types of NSAP address mappings, see RFC 1888. Figure 3-5 shows the structure of NSAP addresses for IPv6.

Figure 3-5. The structure of NSAP addresses for IPv6 (Image unavailable)

Multicast IPv6 Addresses

In IPv6, multicast traffic operates in the same way that it does in IPv4. Arbitrarily located IPv6 nodes can listen for multicast traffic on an arbitrary IPv6 multicast address. IPv6 nodes can listen to multiple multicast addresses at the same time. Nodes can join or leave a multicast group at any time.

IPv6 multicast addresses have the FP of 1111 1111. Therefore, an IPv6 multicast address always begins with FF. Multicast addresses cannot be used as source addresses or as intermediate destinations in a Routing header. Beyond the FP, multicast addresses include additional structure to identify flags, their scope, and the multicast group. Figure 3-6 shows the structure of the IPv6 multicast address.

Figure 3-6. The structure of the IPv6 multicast address (Image unavailable)

The fields in the multicast address are:

Flags — Indicates flags set on the multicast address. The size of this field is 4 bits. As of RFC 2373, the only flag defined is the Transient (T) flag, which uses the low-order bit of the Flags field. When set to 0, the T flag indicates that the multicast address is a permanently assigned (well-known) multicast address allocated by IANA. When set to 1, the T flag indicates that the multicast address is a transient (non-permanently-assigned) multicast address.

Scope — Indicates the scope of the IPv6 network for which the multicast traffic is intended to be delivered. The size of this field is 4 bits. In addition to information provided by multicast routing protocols, routers use the multicast scope to determine whether multicast traffic can be forwarded.

Table 3-3 lists the values for the Scope field assigned in RFC 2373.

Table 3-3. Defined Values for the Scope Field

Scope Field Value Scope

0 Reserved

1 Node-local scope

2 Link-local scope

5 Site-local scope

8 Organization-local scope

E Global scope

F Reserved

For example, traffic with the multicast address of FF02::2 has a link-local scope. An IPv6 router never forwards this traffic beyond the local link.

Group ID – Identifies the multicast group and is unique within the scope. The size of this field is 112 bits. Permanently assigned group IDs are in-dependent of the scope. Transient group IDs are relevant only to a specific scope. Multicast addresses from FF01:: through FF0F:: are reserved, well-known addresses.

To identify all nodes for the node-local and link-local scopes, the following addresses are defined:

FF01::1 (node-local scope all-nodes multicast address)

FF02::1 (link-local scope all-nodes multicast address)

To identify all routers for the node-local, link-local, and site-local scopes, the following addresses are defined:

FF01::2 (node-local scope all-routers multicast address)

FF02::2 (link-local scope all-routers multicast address)

FF05::2 (site-local scope all-routers multicast address)

For the current list of permanently assigned IPv6 multicast addresses, see http://www.iana.org/assignments/ipv6-multicast-addresses.

IPv6 multicast addresses replace all forms of IPv4 broadcast addresses. The IPv4 network broadcast (in which all host bits are set to 1 in a classful environment), subnet broadcast (in which all host bits are set to 1 in a non-classful environment), and limited broadcast (255.255.255.255) addresses are replaced by the link-local scope all-nodes multicast address (FF02:01) in IPv6.

Recommended Multicast IPv6 Addresses

With 112 bits in the Group ID field, it is possible to have 2112 group IDs. Because of the way in which IPv6 multicast addresses are mapped to Ethernet multicast MAC addresses, RFC 2373 recommends assigning the group ID from the low-order 32 bits of the IPv6 multicast address and setting the remaining original Group ID field bits to 0. By using only the low-order 32 bits, each group ID maps to a unique Ethernet multicast MAC address. Figure 3-7 shows the structure of the recommended IPv6 multicast address.

Figure 3-7. The structure of the recommended IPv6 multicast address (Image unavailable)

Solicited-Node Address

The solicited-node address facilitates the efficient querying of network nodes during link-layer address resolution—the resolving of a link-layer address of a known IPv6 address. In IPv4, the ARP Request frame is sent to the MAC-level broadcast, disturbing all nodes on the network segment, including those that are not running IPv4. IPv6 uses the Neighbor Solicitation message to perform link-layer address resolution. However, instead of using the local-link scope all-nodes multicast address as the Neighbor Solicitation message destination, which would disturb all IPv6 nodes on the local link, the solicited-node multicast address is used. The solicited-node multicast address is constructed from the prefix FF02::1:FF00:0/104 and the last 24 bits of a unicast IPv6 address.

For example, Node A is assigned the link-local address of FE80::2AA:FF: FE28:9C5A and is also listening on the corresponding solicited-node multicast address of FF02::1:FF28:9C5A. (An underline is used to highlight the correspondence of the last six hexadecimal digits.) Node B on the local link must resolve Node A’s link-local address FE80::2AA:FF:FE28:9C5A to its corresponding link-layer address. Node B sends a Neighbor Solicitation message to the solicited-node multicast address of FF02::1:FF28:9C5A. Because Node A is listening on this multicast address, it processes the Neighbor Solicitation message and sends a unicast Neighbor Advertisement message in reply.

The result of using the solicited-node multicast address is that link-layer address resolutions, a common occurrence on a link, are not using a mechanism that disturbs all network nodes. By using the solicited-node address, very few nodes are disturbed during address resolution. In practice, due to the relationship between the link-layer MAC address, the IPv6 interface ID, and the solicited-node address, the solicited-node address acts as a pseudo-unicast address for very efficient address resolution. For more information, see "IPv6 Interface Identifiers" in this chapter.

Anycast IPv6 Addresses

An anycast address is assigned to multiple interfaces. Packets addressed to an anycast address are forwarded by the routing infrastructure to the nearest interface to which the anycast address is assigned. In order to facilitate delivery, the routing infrastructure must be aware of the interfaces that have anycast addresses assigned to them and their distance in terms of routing metrics. This awareness is accomplished by the propagation of host routes throughout the routing infrastructure of the portion of the network that cannot summarize the anycast address using a route prefix.

For example, for the anycast address 3FFE:2900:D005:6187:2AA:FF:FE89: 6B9A, host routes for this address are propagated within the routing infrastructure of the organization assigned the 48-bit prefix 3FFE:2900:D005::/48. Because a node assigned this anycast address can be placed anywhere on the organization’s intranet, source routes for all nodes assigned this anycast address are needed in the routing tables of all routers within the organization. Outside the organization, this anycast address is summarized by the 3FFE:2900:D005::/48 prefix that is assigned to the organization. Therefore, the host routes needed to deliver IPv6 packets to the nearest anycast group member within an organization’s intranet are not needed in the routing infrastructure of the IPv6 Internet.

As of RFC 2373, anycast addresses are used only as destination addresses and are assigned only to routers. Anycast addresses are assigned out of the unicast address space and the scope of an anycast address is the scope of the type of unicast address from which the anycast address is assigned. It is not possible to determine if a given destination unicast address is also an anycast address. The only nodes that have this awareness are the routers that use host routes to forward the anycast traffic to the nearest anycast group member and the anycast group members themselves.

Subnet-Router Anycast Address

The Subnet-Router anycast address is defined in RFC 2373 and is required. It is created from the subnet prefix for a given interface. When the Subnet-Router anycast address is constructed, the bits in the subnet prefix are fixed at their appropriate values and the remaining bits are set to 0. Figure 3-8 shows the structure of the Subnet-Router anycast address.

Figure 3-8. The structure of the Subnet-Router anycast address (Image unavailable)

All router interfaces attached to a subnet are assigned the Subnet-Router anycast address for that subnet. The Subnet-Router anycast address is used to communicate with the nearest router connected to a specified subnet.

IPv6 Addresses for a Host

An IPv4 host with a single network adapter typically has a single IPv4 address assigned to that adapter. An IPv6 host, however, usually has multiple IPv6 addresses assigned to each adapter. The interfaces on a typical IPv6 host are assigned the following unicast addresses:

A link-local address for each interface

Additional unicast addresses for each interface (which could be a site-local address and one or multiple global addresses)

The loopback address (::1) for the loopback interface

Typical IPv6 hosts are always logically multihomed because they always have at least two addresses with which they can receive packets—a link-local address for local link traffic and a routable site-local or global address.

Additionally, each interface on an IPv6 host is listening for traffic on the following multicast addresses:

The node-local scope all-nodes multicast address (FF01::1)

The link-local scope all-nodes multicast address (FF02::1)

The solicited-node address for each unicast address

The multicast addresses of joined groups

IPv6 Addresses for a Router

The interfaces on an IPv6 router are assigned the following unicast addresses:

A link-local address for each interface

Additional unicast addresses for each interface (which could be a site-local address and one or multiple global addresses)

The loopback address (::1) for the loopback interface

Additionally, the interfaces of an IPv6 router are assigned the following anycast addresses:

A Subnet-Router anycast address for each subnet

Additional anycast addresses (optional)

Additionally, the interfaces of an IPv6 router are listening for traffic on the following multicast addresses:

The node-local scope all-nodes multicast address (FF01::1)

The node-local scope all-routers multicast address (FF01::2)

The link-local scope all-nodes multicast address (FF02::1)

The link-local scope all-routers multicast address (FF02::2)

The site-local scope all-routers multicast address (FF05::2)

The solicited-node address for each unicast address

The multicast addresses of joined groups

Subnetting the IPv6 Address Space

Just as in IPv4, the IPv6 address space can be divided by using high-order bits that do not already have fixed values to create subnetted network prefixes. These are used either to summarize a level in the routing or addressing hierarchy (with a prefix length less than 64), or to define a specific subnet or network segment (with a prefix length of 64). IPv4 subnetting differs from IPv6 subnetting in the definition of the host ID portion of the address. In IPv4, the host ID can be of varying length, depending on the subnetting scheme. For currently defined unicast IPv6 addresses, the host ID is the interface ID portion of the IPv6 unicast address and is always a fixed size of 64 bits.

Subnetting for NLA IDs

If you are an ISP, subnetting the IPv6 address space consists of using subnetting techniques to divide the NLA ID portion of a global address in a manner that allows for route summarization and delegation of the remaining address space for different portions of your network, for downstream providers, or for individual customers. The global address has a 24-bit NLA ID field to be used by the various layers of ISPs between a top-level aggregator (a global ISP identified by the TLA ID) and a customer site.

For a global address allocated to a top-level aggregator, the first 16 bits of the address are fixed and correspond to the FP (set to 001) and the TLA ID (13 bits in length). The TLA ID is followed by the Res portion, which consists of 8 reserved bits set to 0. Therefore, for subnetting of the NLA ID portion of a global address, the first 24 bits are fixed. In a global address, the Res bits are never shown due to the suppression of leading zeros in IPv6 colon hexadecimal notation.

Subnetting the NLA ID portion of a global address requires a two-step procedure:

Determine the number of bits to be used for the subnetting.

Enumerate the new subnetted network prefixes.

The subnetting technique described here assumes that subnetting is done by dividing the 24-bit address space of the NLA ID using the high-order bits in the NLA ID that do not already have fixed values. While this method promotes hierarchical addressing and routing, it is not required. For example, you can also create a flat addressing space for the NLA ID by numbering the subnets from 0 to 16,777,215.

Step 1: Determining the Number of Subnetting Bits

The number of bits being used for subnetting determines the possible number of new subnetted network prefixes that can be allocated to portions of your network based on geographical, customer segment, or other divisions. In a hierarchical routing infrastructure, you need to determine how many network prefixes, and therefore how many bits, you need at each level in the hierarchy. The more bits you choose for the various levels of the hierarchy, the fewer bits you will have available to enumerate individual subnets in the last level of the hierarchy. The last level in the hierarchy is used to assign 48-bit prefixes to customer sites.

For example, a network designer at a large ISP decides to implement a two-level hierarchy reflecting a geographical/customer segment structure and uses 8 bits for the geographical level and 8 bits for the customer segment level. This means that each customer segment in each geographical location has only 8 bits of subnetting space left (24 – 8 – 8), or only 256 (= 28) 48-bit prefixes per customer segment.

On any given level in the hierarchy, you will have a number of bits that are already fixed by the next level up in the hierarchy (f ), a number of bits used for subnetting at the current level in the hierarchy (s), and a number of bits remaining for the next level down in the hierarchy (r). At all times, f + s + r = 24. This relationship is shown in Figure 3-9.

Figure 3-9. The subnetting of an NLA ID (Image unavailable)

Step 2: Enumerating Subnetted Network Prefixes

Based on the number of bits used for subnetting, you must list the new subnetted network prefixes. There are two main approaches:

Hexadecimal — Enumerate new subnetted network prefixes by using hexadecimal representations of the NLA ID and increment.

Decimal — Enumerate new subnetted network prefixes by using decimal representations of the NLA ID and increment. The decimal subnetting technique is included here for those who are more comfortable dealing with decimal numbers (Base10).

Either method produces the same result: an enumerated list of subnetted network prefixes.

Creating the enumerated list of subnetted network prefixes by using the hexadecimal method

Based on s (the number of bits chosen for subnetting), and m (the prefix length of the network prefix being subnetted), calculate the following:

f = m - 24

f is the number of bits within the NLA ID that are already fixed.

n = 2s

n is the number of network prefixes that are obtained.

i = 224-(f+s)

i is the incremental value between each successive NLA ID expressed in hexadecimal form.

l = 24 + f + s

l is the prefix length of the new subnetted network prefixes.

Create a three-column table with n entries. The first column is the network prefix number (starting with 1), the second column is the value of F (the hexadecimal representation of the NLA ID), and the third column is the new subnetted network prefix.

In the first table entry, the entry for the NLA ID column is F and the subnetted network prefix is the original network prefix with the new prefix length. To obtain F, combine the last two hexadecimal digits of the second hexadecimal block with the four hexadecimal digits of the third hexadecimal block of the NLA ID being subnetted to form a 6-digit hexadecimal number. Remember to include zeros that may not be present due to leading zero suppression. For example, for the global address prefix 3000:4D:C00::/38, F is 0x4D0C00.

In the next table entry, for the NLA ID column, increase the value of F by i. For example, in the second table entry, the NLA ID is F + i.

For the subnetted network prefix column, convert the NLA ID into two separate 16-bit blocks in colon hexadecimal notation and place them after the 16-bit prefix to express the new subnetted network prefix. For example, for the second table entry, the subnetted network prefix is [16-bit prefix]:[F ? i (expressed in colon hexadecimal notation)]::/l.

Repeat steps 4 and 5 until the table is complete.

For example, to perform a 3-bit subnetting of the global network prefix 3000:4D:C00::/38, we first calculate the values of the number of prefixes, the increment, and the new prefix length. Our starting values are F = 0x4D0C00, s = 3, and f = 38 – 24 = 14. The number of prefixes is 8 (n = 23). The increment is 0x80 (i = 224-(14+3) = 128 = 0x80). The new prefix length is 41 (l = 38 + 3).

Next, we construct a table with 8 entries. The subnetted network prefix for network prefix 1 is 3000:4D:C00::/41. Additional entries in the table are successive increments of i in the NLA ID portion of the network prefix, as shown in Table 3-4.

Table 3-4. The Hexadecimal Subnetting Technique for Network Prefix 3000:4D:C00::/38

Network Prefix Number NLA ID (hexadecimal) Subnetted Network Prefix

1 4D0C00 3000:4D:C00::/41

2 4D0C80 3000:4D:C80::/41

3 4D0D00 3000:4D:D00::/41

4 4D0D80 3000:4D:D80::/41

5 4D0E00 3000:4D:E00::/41

6 4D0E80 3000:4D:E80::/41

7 4D0F00 3000:4D:F00::/41

8 4D0F80 3000:4D:F80::/41

NOTE:

RFC 2373 allows the use of subnetted network prefixes where the bits being used for subnetting are set to all zeros (the all-zeros subnetted network prefix) and all ones (the all-ones subnetted network prefix) for any portion of the IPv6 network prefix being subnetted.

Creating the enumerated list of subnetted network prefixes using the decimal method

Based on s (the number of bits chosen for subnetting), and m (the prefix length of the network prefix being subnetted), and F (the hexadecimal value of the NLA ID being subnetted), calculate the following:

f = m - 24

f is the number of bits within the NLA ID that are already fixed.

n = 2s

n is the number of network prefixes that are obtained.

i = 224-(f+s)

i is the incremental value between each successive NLA ID expressed in decimal form.

l = 24 + f + s

l is the prefix length of the new subnetted network prefixes.

D = decimal representation of F

Create a four-column table with n entries. The first column is the network prefix number (starting with 1), the second column is the decimal representation of the NLA ID portion of the new subnetted network prefix, the third column is the hexadecimal representation of the NLA ID portion of the new subnetted network prefix, and the fourth column is the new subnetted network prefix.

In the first table entry, the decimal representation of the NLA ID is D, the hexadecimal representation of the NLA ID is F, and the subnetted network prefix is the original network prefix with the new prefix length.

In the next table entry, for the second column, increase the value of the decimal representation of the NLA ID by i. For example, in the second table entry, the decimal representation of the subnet ID is D + i.

For the third column, convert the decimal representation of the NLA ID to hexadecimal.

For the fourth column, convert the NLA ID into two separate 16-bit blocks in colon hexadecimal notation and place them after the 16-bit prefix to express the new subnetted network prefix. For example, for the second table entry, the subnetted network prefix is [16-bit prefix]:[F + i (expressed in colon hexadecimal notation)]::/l.

Repeat steps 4 through 6 until the table is complete.

For example, to perform a 3-bit subnetting of the global network prefix 3000:4D:C00::/38, we first calculate the values of the number of prefixes, the increment, and the new prefix length. Our starting values are F = 0x4D0C00, s = 3, and f = 38 - 24 = 14. The number of prefixes is 8 (n = 23). The increment is 128 (i = 224-(14+3) = 128). The new prefix length is 41 (l = 38 + 3). The decimal representation of the starting NLA ID is 5049344 (D = 0x4D0C00 = 5049344).

Next, we construct a table with 8 entries. The subnetted network prefix for network prefix 1 is 3000:4D:C00::/41. Additional entries in the table are successive increments of i in the NLA ID portion of the network prefix, as shown in Table 3-5.

Table 3-5. The Decimal Subnetting Technique for Network Prefix 3000:4D:C00::/38

Network Prefix Number Decimal Representation of NLA ID Hexadecimal Representation of NLA ID Subnetted Network Prefix

1 5049344 4D0C00 3000:4D:C00::/41

2 5049472 4D0C80 3000:4D:C80::/41

3 5049600 4D0D00 3000:4D:D00::/41

4 5049728 4D0D80 3000:4D:D80::/41

5 5049856 4D0E00 3000:4D:E00::/41

6 5049984 4D0E80 3000:4D:E80::/41

7 5050112 4D0F00 3000:4D:F00::/41

8 5050240 4D0F80 3000:4D:F80::/41

Subnetting for SLA IDs/Subnet IDs

For most network administrators within an organization, subnetting the IPv6 address space consists of using subnetting techniques to divide the SLA ID portion of the global address or the Subnet ID portion of the site-local address in a manner that allows for route summarization and delegation of the remaining address space to different portions of an IPv6 intranet. The global address has a 16-bit SLA ID field to be used by organizations within their sites. The site-local address has a 16-bit Subnet ID field to be used by organizations within a site.

In both cases, the first 48 bits of the address are fixed. For the global address, the first 48 bits are fixed and allocated by an ISP and correspond to the TLA and NLA ID portions of the global address. For the site-local address, the first 48 bits are fixed at FEC0::/48. In the discussion that follows, the term subnet ID refers to either the SLA ID portion of the global address or the Subnet ID portion of a site-local address.

Subnetting the subnet ID portion of a global or site-local address space requires a two-step procedure:

Determine the number of bits to be used for the subnetting.

Enumerate the new subnetted network prefixes.

The subnetting technique described here assumes that subnetting is done by dividing the 16-bit address space of the subnet ID using the high-order bits in the subnet ID. While this method promotes hierarchical addressing and routing, it is not required. For example, in a small organization with a small number of subnets, you can also create a flat addressing space for the subnet ID by numbering the subnets starting at 0.

As described in the "Local-Use Unicast Addresses" section of this chapter, you can use the same subnetting scheme and use the same subnet ID for both site-local and global address network prefixes.

Step 1: Determining the Number of Subnetting Bits

The number of bits being used for subnetting determines the possible number of new subnetted network prefixes that can be allocated to portions of your network based on geographical or departmental divisions. In a hierarchical routing infrastructure, you need to determine how many network prefixes, and therefore how many bits, you need at each level in the hierarchy. The more bits you choose for the various levels of the hierarchy, the fewer bits you will have available to enumerate individual subnets in the last level of the hierarchy.

For example, a network administrator decides to implement a two-level hierarchy reflecting a geographical/departmental structure and uses 4 bits for the geographical level and 6 bits for the departmental level. This means that each department in each geographical location has only 6 bits of subnetting space left (16 - 6 - 4), or only 64 (= 26) subnets per department.

On any given level in the hierarchy, you will have a number of bits that are already fixed by the next level up in the hierarchy (f), a number of bits used for subnetting at the current level in the hierarchy (s), and a number of bits remaining for the next level down in the hierarchy (r). At all times, f + s + r = 16. This relationship is shown in Figure 3-10.

Figure 3-10. The subnetting of a Subnet ID (Image unavailable)

Step 2: Enumerating Subnetted Network Prefixes

Based on the number of bits used for subnetting, you must list the new subnetted network prefixes. There are two main approaches:

Hexadecimal — Enumerate new subnetted network prefixes by using hexadecimal representations of the subnet ID and increment.

Decimal — Enumerate new subnetted network prefixes by using decimal representations of the subnet ID and increment.

Either method produces the same result: an enumerated list of subnetted network prefixes.

Creating the enumerated list of subnetted network prefixes using the hexadecimal method

Based on s (the number of bits chosen for subnetting), m (the prefix length of the network prefix being subnetted), and F (the hexadecimal value of the subnet being subnetted), calculate the following:

f = m - 48

f is the number of bits within the subnet ID that are already fixed.

n = 2s

n is the number of network prefixes that are obtained.

i = 216-(f+s)

i is the incremental value between each successive subnet ID expressed in hexadecimal form.

l = 48 + f + s

l is the prefix length of the new subnetted network prefixes.

Create a two-column table with n entries. The first column is the network prefix number (starting with 1) and the second column is the new subnetted network prefix.

In the first table entry, based on F, the hexadecimal value of the subnet ID being subnetted, the subnetted network prefix is [48-bit prefix]:F::/l.

In the next table entry, increase the value within the subnet ID portion of the site-local or global address by i. For example, in the second table entry, the subnetted prefix is [48-bit prefix]:F + i::/l.

Repeat step 4 until the table is complete.

For example, to perform a 3-bit subnetting of the site-local network prefix FEC0:0:0:C000::/51, we first calculate the values of the number of prefixes, the increment, and the new prefix length. Our starting values are F = 0xC000, s = 3, and f = 51 - 48 = 3. The number of prefixes is 8 (n = 23). The increment is 0x400 (i = 216-(3+3) = 1024 = 0x400). The new prefix length is 54 (l = 48 + 3 + 3).

Next, we construct a table with 8 entries. The entry for the network prefix 1 is FEC0:0:0:C000::/54. Additional entries in the table are successive increments of i in the subnet ID portion of the network prefix, as shown in Table 3-6.

Table 3-6. The Hexadecimal Subnetting Technique for Network Prefix FEC0:0:0:C000::/51

Network Prefix Number Subnetted Network Prefix

1 FEC0:0:0:C000::/54

2 FEC0:0:0:C400::/54

3 FEC0:0:0:C800::/54

4 FEC0:0:0:CC00::/54

5 FEC0:0:0:D000::/54

6 FEC0:0:0:D400::/54

7 FEC0:0:0:D800::/54

8 FEC0:0:0:DC00::/54

Creating the enumerated list of subnetted network prefixes using the decimal method

Based on s (the number of bits chosen for subnetting), and m (the prefix length of the network prefix being subnetted), and F (the hexadecimal value of the subnet ID being subnetted), calculate the following:

f = m - 48

f is the number of bits within the subnet ID that are already fixed.

n = 2s

n is the number of network prefixes that are obtained.

i = 216-(f+s)

i is the incremental value between each successive subnet ID.

l = 48 + f + s

l is the prefix length of the new subnetted network prefixes.

D = decimal representation of F

Create a three-column table with n entries. The first column is the network prefix number (starting with 1), the second column is the decimal representation of the subnet ID portion of the new network prefix, and the third column is the new subnetted network prefix.

In the first table entry, the decimal representation of the subnet ID is D and the subnetted network prefix is [48-bit prefix]:F::/l.

In the next table entry, for the second column, increase the value of the decimal representation of the subnet ID by i. For example, in the second table entry, the decimal representation of the subnet ID is D + i.

For the third column, convert the decimal representation of the subnet ID to hexadecimal and construct the prefix from [48-bit prefix]:[subnet ID]::/l. For example, in the second table entry, the subnetted network prefix is [48-bit prefix]:[D + i (converted to hexadecimal)]::/l.

Repeat steps 4 and 5 until the table is complete.

For example, to perform a 3-bit subnetting of the site-local network prefix FEC0:0:0:C000::/51, we first calculate the values of the number of prefixes, the increment, the new prefix length, and the decimal representation of the starting subnet ID. Our starting values are F = 0xC000, s = 3, and f = 51 - 48 = 3. The number of prefixes is 8 (n = 23). The increment is 1024 (i = 216-(3+3)). The new prefix length is 54 (l = 48 + 3 + 3). The decimal representation of the starting subnet ID is 49152 (D = 0xC000 = 49152).

Next, we construct a table with 8 entries. The entry for the network prefix 1 is 49152 and FEC0:0:0:C000::/54. Additional entries in the table are successive increments of i in the subnet ID portion of the network prefix, as shown in Table 3-7.

Table 3-7. The Decimal Subnetting Technique for Network Prefix FEC0:0:0:C000::/51

Network Prefix Number Decimal Representation of Subnet ID Subnetted Network Prefix

1 49152 FEC0:0:0:C000::/54

2 50176 FEC0:0:0:C400::/54

3 51200 FEC0:0:0:C800::/54

4 52224 FEC0:0:0:CC00::/54

5 53248 FEC0:0:0:D000::/54

6 54272 FEC0:0:0:D400::/54

7 55296 FEC0:0:0:D800::/54

8 56320 FEC0:0:0:DC00::/54

IPv6 Interface Identifiers

In IPv6, the interface ID is of fixed length. This length was not fixed at 64 bits to allow up to 264 possible hosts on the same subnet. Rather, the IPv6 interface ID is 64 bits long to accommodate the mapping of current 48-bit MAC addresses used by most LAN technologies such as Ethernet and the mapping of 64-bit MAC addresses of IEEE 1394 (also known as FireWire) and future LAN technologies.

The ways in which an interface identifier is determined are the following:

As defined in RFC 2373, all unicast addresses that use the prefixes 001 through 111 must also use a 64-bit interface identifier that is derived from the Extended Unique Identifier (EUI)-64 address. The 64-bit EUI-64 address is defined by the Institute of Electrical and Electronic Engineers (IEEE). EUI-64 addresses are either assigned to a network adapter or derived from IEEE 802 addresses.

As defined in RFC 3041, it might have a temporarily assigned, randomly generated interface identifier to provide a level of anonymity.

It is assigned during stateful address autoconfiguration (for example, via Dynamic Host Configuration Protocol version 6 (DHCPv6)). Stateful address autoconfiguration standards and protocols are in progress.

As defined in RFC 2472, an interface identifier can be based on link-layer addresses or serial numbers, or randomly generated when configuring a Point-to-Point Protocol (PPP) interface and an EUI-64 address is not available.

It is assigned during manual address configuration.

EUI-64 Address-based Interface Identifiers

The most common way to derive an IPv6 interface identifier is through the EUI-64 address, a new type of MAC address for network adapters. To gain an understanding of EUI-64 addresses, it is useful to review the current MAC address format known as IEEE 802 addresses.

IEEE 802 Addresses

Network adapters for common LAN technologies such as Ethernet, Token Ring, and Fiber Data Distributed Interface (FDDI) use a 48-bit address called an IEEE 802 address. It consists of a 24-bit company ID (also called the manufacturer ID) and a 24-bit extension ID (also called the board ID). The combination of the company ID, which is uniquely assigned to each manufacturer of network adapters, and the extension ID, which is uniquely assigned to each network adapter at the time of manufacture, produces a globally unique 48-bit address. This 48-bit address is also called the physical, hardware, or media access control (MAC) address.

Figure 3-11 shows the structure of the 48-bit IEEE 802 address for Ethernet.

Figure 3-11. The structure of the 48-bit IEEE 802 address for Ethernet (Image unavailable)

Defined bits within the IEEE 802 address for Ethernet are:

Universal/Local (U/L) — The next-to-the low-order bit in the first byte is usedto indicate whether the address is universally or locally administered. If the U/L bit is set to 0, the IEEE (through the designation of a unique company ID) has administered the address. If the U/L bit is set to 1, the address is locally administered. In this case, the network administrator has overridden the manufactured address and specified a different address. The U/L bit is designated by the u in Figure 3-11.

Individual/Group (I/G) — The low-order bit of the first byte is used to indicate whether the address is an individual address (unicast) or a group address (multicast). When set to 0, the address is a unicast address. When set to 1, the address is a multicast address. The I/G bit is designated by the g in Figure 3-11.

For a typical 802.x network adapter address, both the U/L and I/G bits are set to 0, corresponding to a universally administered, unicast MAC address.

IEEE EUI-64 Addresses

The IEEE EUI-64 address represents a new standard for network interface addressing. The company ID is still 24-bits long, but the extension ID is 40 bits, creating a much larger address space for a network adapter manufacturer. The EUI-64 address uses the U/L and I/G bits in the same way as the IEEE 802 address.

Figure 3-12 shows the structure of the EUI-64 address.

Figure 3-12. The structure of the EUI-64 address (Image unavailable)

Mapping IEEE 802 Addresses to EUI-64 Addresses

To create an EUI-64 address from an IEEE 802 address, the 16 bits of 11111111 11111110 (0xFFFE) are inserted into the IEEE 802 address between the company ID and the extension ID, as shown in Figure 3-13.

Figure 3-13. The mapping of IEEE 802 addresses to EUI-64 addresses (Image unavailable)

Obtaining Interface Identifiers for IPv6 Addresses

To obtain the 64-bit interface identifier for IPv6 unicast addresses, the U/L bit in the EUI-64 address is complemented (if it is a 1 in the EUI-64 address, it is set to 0; and if it is a 0 in the EUI-64 address, it is set to 1).

The main reason for complementing the U/L bit is to provide greater compressibility of locally administered EUI-64 addresses. It is common practice when assigning locally administered addresses to number them in a simple way. For example, on a point-to-point link, you may assign one interface on the link the locally administered EUI-64 address of 02-00-00-00-00-00-00-01 and the other interface the locally administered EUI-64 address of 02-00-00-00-00-00-00-02. If the U/L bit is not complemented, the corresponding link-local addresses for these two interfaces become FE80::200:0:0:1 and FE80::200:0:0:2. By complementing the U/L bit, the corresponding link-local addresses for these two interfaces become FE80::1 and FE80::2.

Figure 3-14 shows the conversion of an EUI-64 address to an IPv6 interface identifier.

Figure 3-14. The conversion of an EUI-64 address to an IPv6 interface identifier (Image unavailable)

NOTE:

Because the U/L bit is complemented when converting an EUI-64 address to an IPv6 interface identifier, the resulting bit in the IPv6 interface identifier has the opposite interpretation of the IEEE-defined U/L bit. If the seventh bit of the IPv6 interface identifier is set to 0, it is locally administered. If the seventh bit of the IPv6 interface identifier is set to 1, it is universally administered.

Converting IEEE 802 Addresses to IPv6 Interface Identifiers

To obtain an IPv6 interface identifier from an IEEE 802 address, you must first map the IEEE 802 address to an EUI-64 address, and then complement the U/L bit. Figure 3-15 shows this conversion process for a universally administered, unicast IEEE 802 address.

Figure 3-15. The conversion of an IEEE 802 address to an IPv6 interface identifier (Image unavailable)

IEEE 802 Address Conversion Example

Host A has the Ethernet MAC address of 00-AA-00-3F-2A-1C. First, it is converted to EUI-64 format by inserting FF-FE between the third and fourth bytes, yielding 00-AA-00-FF-FE-3F-2A-1C. Then, the U/L bit, which is the seventh bit in the first byte, is complemented. The first byte in binary form is 00000000. When the seventh bit is complemented, it becomes 00000010 (0x02). The final result is 02-AA-00-FF-FE-3F-2A-1C which, when converted to colon hexadecimal notation, becomes the interface identifier 2AA:FF:FE3F: 2A1C. As a result, the link-local address that corresponds to the network adapter with the MAC address of 00-AA-00-3F-2A-1C is FE80::2AA:FF:FE3F:2A1C.

NOTE:

When complementing the U/L bit, add 0x2 to the first byte if the EUI-64 address is universally administered, and subtract 0x2 from the first byte if the EUI-64 address is locally administered.

Temporary Address Interface Identifiers

In today’s IPv4-based Internet, a typical Internet user dials an ISP and obtains an IPv4 address using PPP and the Internet Protocol Control Protocol (IPCP). Each time the user dials, a different IPv4 address might be obtained. Therefore, it is not easy to track a dial-up user’s traffic on the Internet based on the user’s IP address.

For IPv6-based dial-up connections, the user is assigned a 64-bit prefix, at the time of connection, by using router discovery, an exchange of Router Solicitation and Router Advertisement messages. If the interface identifier is always based on the EUI-64 address (as derived from the static IEEE 802 address), it is possible to identify the traffic of a specific node regardless of the prefix assigned at the time of connection. The use of the same 64-bit interface identifier allows identification of a user’s traffic whether they are accessing the Internet from home or from work. This makes it easy for Internet merchants and malicious users to track a specific user and their use of the Internet.

To address this concern to provide the same level of anonymity as that provided with IPv4, an alternative derivation of the IPv6 interface identifier that is randomly generated and changes over time is discussed in RFC 3041.

The initial interface identifier is generated using random number techniques. For IPv6 systems that do not have the ability to store any history information for generating future values of the interface identifier, a new random interface identifier is generated each time the IPv6 protocol is initialized. For IPv6 systems that do have storage capabilities, a history value is stored and when the IPv6 protocol is initialized, a new interface identifier is created through the following process:

Retrieve the history value from storage and append the interface identifier based on the EUI-64 address of the adapter.

Compute the Message Digest-5 (MD5) hash over the quantity in step 1. The MD5 hash computation will produce a 128-bit value.

Store the low-order 64 bits of the MD5 hash computed in step 2 as the history value for the next computation of the interface identifier.

Take the high-order 64 bits of the MD5 hash computed in step 2 and set the seventh bit to zero. The seventh bit corresponds to the U/L bit, which, when set to 0, indicates a locally administered interface identifier. The result is the interface identifier.

The resulting IPv6 address, based on this random interface identifier, is known as a temporary address. Temporary addresses are generated for public address prefixes that use stateless address autoconfiguration. Temporary addresses are used for the lower of the following values of the valid and preferred lifetimes:

The lifetimes included in the Prefix Information option in the received Router Advertisement message.

Local default values of 1 week for valid lifetime and 1 day for preferred lifetime.

After the temporary address valid lifetime expires, a new interface identifier and temporary address is generated. For more information about router discovery, see Chapter 6, "Neighbor Discovery." For more information about stateless address autoconfiguration and valid and preferred lifetimes, see Chapter 8, "Address Autoconfiguration."

Mapping IPv6 Multicast Addresses to Ethernet Addresses

When sending IPv6 multicast packets on an Ethernet link, the corresponding destination MAC address is 0x33-33-mm-mm-mm-mm, where mm-mm-mm-mm is a direct mapping of the last 32 bits of the IPv6 multicast address. Figure 3-16 shows the mapping of an IPv6 multicast address to an Ethernet multicast address.

Figure 3-16. The mapping of IPv6 multicast addresses to Ethernet multicast addresses (Image unavailable)

Ethernet network adapters maintain a table of interesting destination MAC addresses. If an Ethernet frame with an interesting destination MAC address is received, it is passed to upper layers for additional processing. By default, this table contains the MAC-level broadcast address (0xFF-FF-FF-FF-FF-FF) and the unicast MAC address assigned to the adapter. To facilitate efficient delivery of multicast traffic, additional multicast destination addresses can be added or removed from the table. For every multicast address being listened to by the host, there is a corresponding entry in the table of interesting MAC addresses.

For example, an IPv6 host with the Ethernet MAC address of 00-AA-00-3F-2A-1C (link-local address of FE80::2AA:FF:FE3F:2A1C) adds the following multicast MAC addresses to the table of interesting destination MAC addresses on the Ethernet adapter:

The address of 33-33-00-00-00-01, which corresponds to the link-local scope all-nodes multicast address of FF02::1.

The address of 33-33-FF-3F-2A-1C, which corresponds to the solicited-node address of FF02::1:FF3F:2A1C. Remember that the solicited-node address is the prefix FF02::1:FF00:0/104 and the last 24 bits of the unicast IPv6 address.

Additional multicast addresses on which the host is listening are added and removed from the table as needed.

IPv4 Addresses and IPv6 Equivalents

To summarize the relationships between IPv4 addressing and IPv6 addressing, Table 3-8 lists both IPv4 addresses and addressing concepts and their IPv6 equivalents.

Table 3-8. IPv4 Addressing Concepts and Their IPv6 Equivalents

IPv4 Address IPv6 Address

Internet address classes Not applicable in IPv6

Multicast addresses (224.0.0.0/4) IPv6 multicast addresses (FF00::/8)

Broadcast addresses Not applicable in IPv6

Unspecified address is 0.0.0.0 Unspecified address is ::

Loopback address is 127.0.0.1 Loopback address is ::1

Public IP addresses Aggregatable global unicast addresses

Private IP addresses (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16) Site-local addresses (FEC0::/48)

APIPA addresses (169.254.0.0/16) Link-local addresses (FE80::/64)

Text representation: Dotted decimal notation Text representation: Colon hexadecimal format with suppression of leading zeros and zero compression. IPv4-compatible addresses are expressed in dotted decimal notation.

Network bits representation: Subnet mask in dotted decimal notation or prefix length Network bits representation: Prefix length notation only

References

RFC 1888 — "OSI NSAPs and IPv6"

RFC 2373 — "IP Version 6 Addressing Architecture"

RFC 2472 — "IP Version 6 over PPP"

RFC 3041 — "Privacy Extensions for Stateless Address Autoconfiguration in IPv6"

Testing for Understanding

To test your understanding of IPv6 addressing, answer the following questions. See Appendix D, "Testing for Understanding Answers" to check your answers.

Why is the IPv6 address length 128 bits?

Define the Format Prefixes (FPs) for commonly used unicast addresses.

Express FEC0:0000:0000:0001:02AA:0000:0000:0007A more efficiently.

How many bits are expressed by "::" in the addresses 3341::1:2AA: 9FF:FE56:24DC and FF02::2?

Describe the difference between unicast, multicast, and anycast addresses in terms of a host sending packets to zero or more interfaces.

Why are no broadcast addresses defined for IPv6?

Define the structure, including field sizes, of the aggregatable global unicast address.

Define the scope for each of the different types of typically used unicast addresses.

Explain how global and site-local addressing can share the same subnetting infrastructure within an organization.

Define the structure, including field sizes, of the multicast address.

Why does RFC 2373 recommend using only the last 32 bits of the IPv6 multicast address for the multicast group ID?

Explain how the solicited-node multicast address acts as a pseudo-unicast address.

How do routers know the nearest location of an anycast group member?

Perform a 4-bit subnetting on the site-local prefix FEC0:0:0:3D80::/57.

What is the IPv6 interface identifier for the universally administered, unicast IEEE 802 address of 0C-1C-09-A8-F9-CE? What is the corresponding link-local address? What is the corresponding solicited-node multicast address?

What is the IPv6 interface identifier for the locally administered, unicast EUI-64 address of 02-00-00-00-00-00-00-09? What is the corresponding link-local address?

What is the site-local scope multicast address corresponding to the Ethernet multicast MAC address of 33-33-00-0A-4F-11?

For each type of address, identify how the address begins in colon hexadecimal notation.

Type of Address Begins with…

Link-local unicast address FE80

Site-local unicast address

Global address

Multicast address

Link-local scope multicast address

Site-local scope multicast address

Solicited-node multicast address

IPv4-compatible address

IPv4-mapped address

6to4 address

Table of Contents

• Foreword
• Preface
• Introduction
• Chapter 1: Introduction to IPv6
• Chapter 2: IPv6 Protocol for Windows
• Chapter 3: IPv6 Addressing
• Chapter 4: The IPv6 Header
• Chapter 5: ICMPv6
• Chapter 6: Neighbor Discovery
• Chapter 7: Multicast Listener Discovery and MLD Version 2
• Chapter 8: Address Autoconfiguration
• Chapter 9: IPv6 and Name Resolution
• Chapter 10: IPv6 Routing
• Chapter 11: IPv6 Transition Technologies
• Chapter 12: ISATAP
• Chapter 13: 6to4
• Chapter 14: Teredo
• Chapter 15: IP-HTTPS
• Chapter 16: NAT64/DNS64
• Chapter 17: IPv6 Security Considerations
• Chapter 18: DirectAccess
• Chapter 19: Deploying IPv6 on an Intranet
• Chapter 20: IPv6 on the Microsoft Corporate Network
• IPv6 RFC Index
• Testing for Understanding Answers
• Setting Up an IPv6 Test Lab
• IPv6 Reference Tables
• Link-Layer Support for IPv6
• Windows Sockets Changes for IPv6
• Mobile IPv6
• Teredo Protocol Processes
• Glossary