Share via

IPv6 Addressing (TechRef)

  • Article

Applies To: Windows Server 2008

IPv6 Addressing

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

The IPv4 address space was designed in the late 1970s, and it seemed impossible to exhaust. However, addresses were not allocated in a way that anticipated changes in technology and an explosion in the number of hosts on the Internet. The IPv4 address space was consumed to the point that, by 1992, it clearly needed a replacement.

It is even harder to conceive that the IPv6 address space will be consumed. A 128-bit address space provides 655,570,793,348,866,943,898,599 (6.5×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 long was not so that every square meter of the Earth could have 6.5×1023 addresses. Rather, the relatively large size of the IPv6 address is designed to be subdivided into hierarchical routing domains that reflect the topology of the modern Internet. The use of 128 bits allows multiple levels of hierarchy and flexibility in designing hierarchical addressing and routing that is currently lacking in the IPv4-based Internet.

RFC 3513 describes the IPv6 addressing architecture.

IPv6 Address Syntax

IPv4 addresses are represented in dotted-decimal format. These 32-bit addresses are divided along 8-bit boundaries. Each set of 8 bits is converted to its decimal equivalent and separated from the other sets by periods. For IPv6, the 128-bit address is divided along 16-bit boundaries. Each 16-bit block is converted to a 4-digit hexadecimal number and separated by colons. The resulting representation is known as 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 representation can be further simplified by removing the leading zeros within each 16-bit block. However, each block must have at least a single digit. With leading zero suppression, the address representation becomes:

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

Compressing Zeros

Some types of addresses contain long sequences of zeros. To further simplify the representation of IPv6 addresses, a contiguous sequence of 16-bit blocks set to 0 in the colon-hexadecimal format can be compressed to “::,” known as 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.

Zero compression can be used to compress only a single contiguous series of 16-bit blocks expressed in colon-hexadecimal notation. 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.

To determine how many 0 bits are represented by the double colon, 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, the address FF02::2 has two blocks (the “FF02” block and the “2” block.) The number of 0 bits expressed by the double colon is 96 (96 = (8 – 2)×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 double colon.

IPv6 Prefixes

The prefix is the part of the address that indicates which bits have fixed values or reflect the subnet identifier. Prefixes for IPv6 subnet identifiers and routes are expressed in the same way as Classless Inter-Domain Routing (CIDR) notation for IPv4, that is, in address/prefix-length notation. For example, 21DA:D3::/48 is a route prefix and 21DA:D3:0:2F3B::/64 is a subnet prefix.

Note

  • IPv4 implementations commonly use a dotted decimal representation of the network prefix known as the subnet mask. IPv6 does not support subnet masks. IPv6 supports only the prefix-length notation.

    • Types of IPv6 Addresses

    IPv6 supports three types of addresses:

    • Unicast

      A unicast address identifies a single interface within the scope of the type of unicast address. With the appropriate unicast routing topology, packets addressed to a unicast address are delivered to a single interface. To accommodate load-balancing systems, RFC 3513 allows 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 multiple interfaces. With the appropriate multicast routing topology, packets addressed to a multicast address are delivered to all interfaces that are identified by the address. A multicast address is used for one-to-many communication, with delivery to multiple interfaces.

    • Anycast

      An anycast address identifies multiple interfaces. With the appropriate 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 closest in terms of routing distance. An anycast address is used for one-to-one-of-many communication, with delivery to a single interface.

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

    Note

  • RFC 3513 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

    Unicast IPv6 addresses fall into one of five types:

    • Global unicast addresses

    • Link-local addresses

    • Site-local addresses

    • Special addresses

    • Compatibility addresses

    Global unicast addresses

    Global unicast addresses are equivalent to public IPv4 addresses. They are globally routable and reachable on the IPv6 Internet.

    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 (that is, the region of the IPv6 internetwork over which the address is unique) of a global unicast address is the entire IPv6 Internet.

    The following figure shows the structure of a global unicast address as defined in RFC 3587.

    The Global Unicast Address

    Global unicast addresses contain four fields.

    • The three high-order bits are set to 001. The address prefix for currently assigned global addresses is 2000::/3.

    • The Global Routing Prefix indicates the global routing prefix for a specific organization’s site. The combination of the three fixed bits and the 45-bit Global Routing Prefix creates a 48-bit site prefix, which is assigned to an individual site of an organization. After this prefix is assigned, routers on the IPv6 Internet forward IPv6 traffic matching the 48-bit prefix to the routers of the organization’s site.

    • The Subnet ID is used within an organization’s site to identify subnets. This field is 16 bits long. The organization’s site can use these 16 bits within its site to create 65,536 subnets or multiple levels of addressing hierarchy and an efficient routing infrastructure.

    • The Interface ID indicates the interface on a specific subnet within the site. This field is 64 bits long.

    The following figure shows how fields within the global unicast address create a three-level structure.

    The Three-level Structure of the Global Unicast Address

    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 identifies a specific interface on a subnet within an organization’s site. For more information about global unicast addresses, see RFC 3587 in the IETF RFC Database.

    Local-use unicast addresses

    Local-use unicast addresses fall into one of two types:

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

    • Site-local addresses are used between nodes in the same site.

    Nodes use link-local addresses when communicating with neighboring nodes on the same link. For example, on a single-link IPv6 network with no router, hosts use link-local addresses to communicate with other hosts on the link. Link-local addresses are equivalent to Automatic Private IP Addressing (APIPA) IPv4 addresses autoconfigured on computers that are running Windows. APIPA addresses use the 169.254.0.0/16 prefix. The scope of a link-local address is the local link.

    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 how link-local addresses are configured, see “Address Autoconfiguration” later in this section.

    The following figure shows the structure of the link-local address.

    The Link-Local Address

    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 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 (the organization internetwork).

    Unlike link-local addresses, site-local addresses are not automatically configured and must be assigned through either stateless or stateful address configuration.

    The following figure shows the structure of the site-local address.

    The Site-Local Address

    The first 10 bits are always fixed for site-local addresses, beginning with FEC0::/10. After the 10 fixed bits is a 54-bit subnet identifier (Subnet ID field) that provides 54 bits with which you can create a hierarchical and summarizable routing infrastructure within the site. After the Subnet ID field is a 64-bit Interface ID field that identifies a specific interface on a subnet.

    Special IPv6 addresses

    The following are special IPv6 addresses:

    • Unspecified address

      The unspecified address (0:0:0:0:0:0:0:0 or ::) indicates 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 for packets attempting to verify the uniqueness of a tentative address. 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 a 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 using IPv6. IPv6/IPv4 nodes support both IPv4 and IPv6 protocols. When an IPv4-compatible address is used as an IPv6 destination, the IPv6 traffic is automatically encapsulated with an IPv4 header and sent to the destination using the IPv4 infrastructure.

    • 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. It is used only for internal representation. The IPv4-mapped address is never used as a source or destination address of an IPv6 packet.

    • 6to4 address

      The 6to4 address is used for communicating between two nodes running both IPv4 and IPv6 over an IPv4 routing infrastructure. The 6to4 address is formed by combining the prefix 2002::/16 with the 32 bits of a public IPv4 address of the node, forming a 48-bit prefix. 6to4 is a tunneling technique described in RFC 3056.

    • ISATAP address

      The Internet draft titled “Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)” defines ISATAP addresses used between two nodes running both IPv4 and IPv6 over an IPv4 routing infrastructure. ISATAP addresses use the locally administered interface ID ::0:5EFE:w.x.y.z where w.x.y.z is any unicast IPv4 address, which includes both public and private addresses.

      The ISATAP interface ID can be combined with any 64-bit prefix that is valid for IPv6 unicast addresses. This includes the link-local address prefix (FE80::/64), site-local prefixes, and global prefixes.

    • Teredo address

      Teredo addresses use the prefix 3FFE:831F::/32. Beyond the first 32 bits, Teredo addresses are used to encode the IPv4 address of a Teredo server, flags, and the encoded version of the external address and port of a Teredo client. An example of a Teredo address is 3FFE:831F:CE49:7601:8000:EFFF:62C3:FFFE. Teredo addresses are used to represent a host when using the automatic tunneling mechanism defined in the Internet draft titled “Teredo: Tunneling IPv6 over UDP through NATs.” For more information, see “Teredo” later in this section.

    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 arbitrary IPv6 multicast addresses. 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 first 8 bits set to 1111 1111. An IPv6 address is easy to classify as multicast because it always begins with “FF.” Multicast addresses cannot be used as source addresses or as intermediate destinations in a Routing header.

    Beyond the first 8 bits, multicast addresses include additional structure to identify their flags, scope, and multicast group. The following figure shows the structure of the IPv6 multicast address.

    The IPv6 Multicast Address

    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 3513, the only flag defined is the Transient (T) flag. The T flag uses the low-order bit of the Flags field. When set to 0, the T flag indicates that the multicast address is a well-known multicast address that has been permanently assigned by the Internet Assigned Numbers Authority (IANA). When set to 1, the T flag indicates that the multicast address is a transient multicast address that IANA has not permanently assigned.

    • Scope

      Indicates the scope of the IPv6 internetwork for which the multicast traffic is intended. The size of this field is 4 bits. In addition to using information provided by multicast routing protocols, routers use the multicast scope to determine whether they can forward multicast traffic. The most prevalent values for the Scope field are 1 (interface-local scope), 2 (link-local scope), and 5 (site-local scope).

      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 independent 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 interface-local and link-local scopes, the following addresses are defined:

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

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

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

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

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

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

    With 112 bits for the group ID, it is possible to have 2112 group IDs. However, because of the way in which IPv6 multicast addresses are mapped to Ethernet multicast media access control (MAC) addresses, RFC 3513 recommends assigning the group ID from the low-order 32 bits of the IPv6 multicast address and setting the remaining original group ID bits to 0. By using only the low-order 32 bits, each group ID maps to a unique Ethernet multicast MAC address. The following figure shows the recommended IPv6 multicast address.

    The Recommended IPv6 Multicast Address Using a 32-bit Group ID

    Solicited-node Address

    The solicited-node address facilitates the efficient querying of network nodes during address resolution. 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 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 following figure shows how the solicited-node multicast address comprises the prefix FF02::1:FF00:0/104 and the last 24-bits of the IPv6 address that is being resolved.

    Mapping Unicast IPv6 Addresses to Solicited Node IPv6 Addresses

    For example, for the node with the link-local IPv6 address of FE80::2AA:FF:FE28:9C5A, the corresponding solicited-node address is FF02::1:FF28:9C5A. This node is listening for multicast traffic at the solicited-node address of FF02::1:FF28:9C5A and, for interfaces that correspond to a physical network adapter, has registered the corresponding multicast address with the network adapter. To resolve the address of FE80::2AA:FF:FE28:9C5A to its link-layer address, a neighboring node sends a Neighbor Solicitation to the solicited-node address of FF02::1:FF28:9C5A.

    The result of using the solicited-node multicast address is that address resolutions, a common occurrence on a link, are not required to use a mechanism that disturbs all network nodes. By using the solicited-node address, address resolution disturbs very few nodes. In practice, due to the relationship between the Ethernet 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.

    Anycast IPv6 Addresses

    An anycast address is assigned to multiple interfaces. The routing infrastructure forwards packets that are addressed to an anycast address to the nearest interface to which the anycast address is assigned. To facilitate delivery, the routing infrastructure must track the interfaces that have been assigned anycast addresses and their distance in terms of routing metrics. At present, 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.

    The Subnet-Router anycast address is predefined and required. It is created from the subnet prefix for a given interface. To construct the Subnet-Router anycast address, the bits in the subnet prefix are fixed at their appropriate values, and the remaining bits are set to 0. 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 one of multiple routers attached to a remote 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 — even with a single interface. An IPv6 host is assigned the following unicast addresses:

    • A link-local address for each interface.

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

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

    Typical IPv6 hosts are logically multi-homed because they 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 host is listening for traffic on the following multicast addresses:

    • The interface-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 on each interface.

    • The multicast addresses of joined groups on each interface.

    IPv6 Addresses for a Router

    An IPv6 router is assigned the following unicast addresses:

    • A link-local address for each interface.

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

    • A Subnet-Router anycast address.

    • Additional anycast addresses (optional).

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

    Additionally, each router is listening for traffic on the following multicast addresses:

    • The interface-local scope all-nodes multicast address (FF01::1).

    • The interface-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 on each interface.

    • The multicast addresses of joined groups on each interface.

    IPv6 Interface Identifiers

    The last 64 bits of an IPv6 address are the interface identifier that is unique to the 64-bit prefix of the IPv6 address. IPv6 interface identifiers are determined as follows:

    • Derived from the Extended Unique Identifier (EUI)-64 address.

    • Generated randomly and changed over time to provide a level of anonymity.

    • Assigned during stateful address autoconfiguration (for example, through DHCPv6).

    EUI-64 Address-based Interface Identifiers

    RFC 3513 states that all unicast addresses that use the prefixes 001 through 111 must also use a 64-bit interface identifier derived from the EUI-64 address. EUI-64 addresses have 64-bits and are defined by the Institute of Electrical and Electronic Engineers (IEEE). EUI-64 addresses are either assigned to network adapters or derived from IEEE 802 addresses.

    IEEE 802 addresses

    Traditional interface identifiers for network adapters 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 board ID, which is uniquely assigned to each network adapter at the time of assembly, produces a globally unique 48-bit address. This 48-bit address is also called the physical, hardware, or media access control (MAC) address.

    The following figure shows the structure of the 48-bit IEEE 802 address.

    48-bit IEEE 802 Address

    The IEEE 802 address includes the following defined bits:

    • Universal/Local (U/L)

      The next-to-the-low order bit in the first byte indicates 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, which means that the network administrator has overridden the manufactured address and specified a different address.

    • Individual/Group (I/G)

      The low-order bit of the first byte indicates whether the address is an individual address (unicast) or a group address (multicast). If the I/G bit is set to 0, the address is a unicast address. If the I/G bit is set to 1, the address is a multicast address.

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

    IEEE EUI-64 addresses

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

    The following figure shows the structure of the EUI-64 address.

    EUI-64 Address

    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. The following figure shows an example of such a conversion.

    Conversion of an IEEE 802 Address to an EUI-64 Address

    Mapping EUI-64 addresses to IPv6 interface identifiers

    To obtain the 64-bit interface identifier for an IPv6 unicast address, the U/L bit in the EUI-64 address is complemented. (If it is set to 1, it is changed to 0, and if it is set to 0, it is changed to 1.) The following figure shows the conversion for a universally administered, unicast EUI-64 address.

    Conversion of a Universally Administered, Unicast EUI-64 Address to an IPv6 Interface Identifier

    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. The following figure shows this conversion process for a universally administered, unicast IEEE 802 address.

    Conversion of a Universally Administered, Unicast IEEE 802 Address to an IPv6 Interface Identifier

    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. The U/L bit, which is the seventh bit in the first byte, is then complemented. Before the conversion, 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-2A-1C is FE80::2AA:FF:FE3F:2A1C.

    Note

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

    • Temporary Address Interface Identifiers

    In today’s Internet, a typical Internet user connects to an Internet service provider (ISP) and obtains an IPv4 address using the Point-to-Point Protocol (PPP) and the Internet Protocol Control Protocol (IPCP). Each time the user connects, a different IPv4 address might be obtained. Because of this, it is difficult to track a dial-up user’s traffic on the Internet on the basis of IP address.

    For dial-up connections that are based on IPv6, the user is assigned a 64-bit prefix through router discovery and stateless address autoconfiguration after the connection is made. 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, making it easy to track a specific user and their use of the Internet. To address this concern and provide a level of anonymity, RFC 3041 describes an alternative IPv6 interface identifier that is randomly generated and changes over time.

    The initial interface identifier is generated by using random numbers. For computers that cannot store any historical information for generating future interface identifier values, a different random interface identifier is generated each time the IPv6 protocol is initialized. For IPv6 systems that have storage capabilities, a history value is stored. When the IPv6 protocol is initialized, a new interface identifier is generated through the following process:

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

    2. Compute a Message Digest-5 (MD5) one-way encryption hash over the quantity in step 1.

    3. Save the last 64 bits of the MD5 hash computed in step 2 as the history value for the next interface identifier computation.

    4. Take the first 64 bits of the MD5 hash computed in Step 2, and set the seventh bit to 0. The seventh bit corresponds to the U/L bit which, when set to 0, indicates a locally administered IPv6 interface identifier. The result is the IPv6 interface identifier.

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

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

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

    After the valid lifetime of the temporary address expires, a new interface identifier and temporary address is generated.

    Subnetting Global Address Prefixes

    For most users of IPv6, subnetting the IPv6 address space consists of using subnetting techniques to divide the Subnet ID portion of the global address. This approach allows for route summarization and delegation of the remaining address space to different portions of an IPv6 intranet.

    For the global address, the first 48 bits are fixed and allocated by an ISP.

    Subnetting the subnet ID portion of a global address space requires two steps:

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

    2. Enumerate the new subnetted network prefixes.

    You are not required to subnet in any specific fashion. 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. Although 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 from 0 to 65,535.

    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, are needed at each level in the hierarchy. The more bits you choose for the various levels of the hierarchy, the fewer bits you have to enumerate individual subnets in the last level of the hierarchy.

    For example, a network administrator can decide to implement a two-level hierarchy reflecting a geographical/departmental structure, use 4 bits for the geographical level, and use 6 bits for the departmental level. With this approach, 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, some number of bits is already fixed by the next level up in the hierarchy (f), some number of bits is used for subnetting at the current level in the hierarchy (s), and some number of bits remain for the next level down in the hierarchy (r). At all times, f+s+r = 16. The following figure shows this relationship.

    Subnetting a Subnet ID

    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.

    To create the enumerated list of subnetted network prefixes using the hexadecimal method

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

      f = m - 48

      f is the number of bits within the global address prefix 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.

      l = 48+f+s

      l is the length of the new subnetted network prefixes.

    2. 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.

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

    4. 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.

    5. Repeat step 4 until the table is complete.

    For example, to perform a 3-bit subnetting of the site-local network prefix 3FFE:FFFF:0:C000::/51, first calculate the values of the number of prefixes, the increment, and the new prefix length. The 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, construct a table with 8 entries. The entry for the network prefix 1 is 3FFE:FFFF: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 the following table.

    Hexadecimal Subnetting Technique for Network Prefix 3FFE:FFFF:0:C000::/51

    Network Prefix Subnetted Network Prefix

    1

    3FFE:FFFF:0:C000::/54

    2

    3FFE:FFFF:0:C400::/54

    3

    3FFE:FFFF:0:C800::/54

    4

    3FFE:FFFF:0:CC00::/54

    5

    3FFE:FFFF:0:D000::/54

    6

    3FFE:FFFF:0:D400::/54

    7

    3FFE:FFFF:0:D800::/54

    8

    3FFE:FFFF:0:DC00::/54

    To create the enumerated list of subnetted network prefixes using the decimal method

    1. Based on s, the number of bits chosen for subnetting, m, the 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 prefix 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 length of the new subnetted network prefixes.

      D = decimal representation of F

    2. 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 subnetted network prefix, and the third column is the new subnetted network prefix.

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

    4. In the second column of the first row, 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.

    5. In the third column of the first row, 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.

    6. Repeat steps 4 and 5 until the table is complete.

    For example, to perform a 3-bit subnetting of the site-local network prefix 3FFE:FFFF:0:C000::/51, first calculate the values of the number of prefixes, the increment, the new prefix length, and the decimal representation of the starting subnet ID. The 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, construct a table with 8 entries. The entry for the network prefix 1 is 49192 and 3FFE:FFFF: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 the following table.

    Decimal Subnetting for Network Prefix 3FFE:FFFF:0:C000::/51

    Network Prefix Decimal Representation of Subnet ID Subnetted Network Prefix

    1

    49192

    3FFE:FFFF:0:C000::/54

    2

    50176

    3FFE:FFFF:0:C400::/54

    3

    51200

    3FFE:FFFF:0:C800::/54

    4

    52224

    3FFE:FFFF:0:CC00::/54

    5

    53248

    3FFE:FFFF:0:D000::/54

    6

    54272

    3FFE:FFFF:0:D400::/54

    7

    55296

    3FFE:FFFF:0:D800::/54

    8

    56320

    3FFE:FFFF:0:DC00::/54

    Note

  • RFC 3513 allows the use of subnetted network prefixes where the bits being used for subnetting are set to all 0s (the all-zeros subnetted network prefix) and all 1s (the all-ones subnetted network prefix).

    • IPv6 and Name Resolution

    Resolving names to IPv6 addresses is supported if either the local Hosts file (stored in systemroot\System32\Drivers\Etc) contains entries for IPv6 addresses or the Domain Name System (DNS) infrastructure contains resource records for IPv6 addresses. RFC 1886 describes enhancements to DNS for IPv6, and the DNS name resolver and DNS Server service in Windows Server® 2008 support them.

    Note

  • NetBIOS over IPv6 is not supported. Therefore, NetBIOS name resolution techniques cannot be used to resolve names to IPv6 addresses.

    • In RFC 1886, a new DNS resource record type, AAAA (called quad A), is used for resolving a fully qualified domain name to an IPv6 address. It is comparable to the host address (A) resource record used with IPv4. The resource record type is named AAAA (Type value of 28) because IPv6 addresses are four times as large as IPv4 addresses. The following is an example of a AAAA resource record:

    host1.contoso.com    IN    AAAA   FEC0::2AA:FF:FE3F:2A1C

    A host must specify either a AAAA query or a general query for a specific host name to receive IPv6 address resolution data in the DNS query answer sections.

    RFC 1886 also describes the IP6.INT domain created for IPv6 reverse queries. However, according to RFC 3152, Internet Engineering Task Force (IETF) consensus has been reached that the IP6.ARPA domain be used instead of IP6.INT. Also called pointer queries, reverse queries determine a host name based on the IP address. To create the namespace for reverse queries, each hexadecimal digit in the fully expressed 32-digit IPv6 address becomes a separate level in inverse order in the reverse domain hierarchy.

    For example, the reverse lookup domain name for the address FEC0::2AA:FF:FE3F:2A1C (fully expressed as FEC0:0000:0000:0000:02AA: 00FF:FE3F:2A1C) is:

    C.1.A.2.F.3.E.F.F.F.0.0.A.A.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.C.E.F.IP6.ARPA.

    The DNS support that RFC 1886 describes represents a simple way to both map host names to IPv6 addresses and to provide reverse name resolution.

    IPv4 Addresses and IPv6 Equivalents

    The following table lists IPv4 addresses and concepts next to their IPv6 equivalents.

    IPv4 Addresses 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

    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::/10)

    Autoconfigured 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 notation.

    Network bits representation: Prefix length notation only.

    DNS name resolution: IPv4 host address (A) resource record.

    DNS name resolution: IPv6 host address AAAA resource records (RFC 1886) or A6 records (RFC 2874).

    DNS reverse resolution: IN-ADDR.ARPA domain.

    DNS reverse resolution: IP6.INT domain (RFC 1886) or IP6.ARPA domain (RFC 2874).

    Neighbor Discovery

    Neighbor Discovery uses ICMPv6 messages to manage neighboring node interaction. Neighbor Discovery replaces ARP, ICMP Router Discovery, and ICMP Redirect and provides additional functionality.

    Neighbor Discovery Messages

    All functions of Neighbor Discovery are performed with the following messages:

    • Router Solicitation

      IPv6 hosts send Router Solicitation messages to discover IPv6 routers present on the link. To prompt IPv6 routers to respond immediately, hosts send multicast Router Solicitation messages rather than waiting for a periodic Router Advertisement message.

    • Router Advertisement

      IPv6 routers send Router Advertisement messages either periodically or in response to the receipt of Router Solicitation messages. Router Advertisement messages contain the information required by hosts to determine what the link prefixes are, what the link MTU is, whether or not to use address autoconfiguration, and the duration for which addresses created through address autoconfiguration are both valid and preferred.

    • Neighbor Solicitation

      IPv6 hosts send Neighbor Solicitation messages to discover the link-layer addresses of on-link IPv6 nodes. Neighbor Solicitation messages include the link-layer address of the sender. Hosts send Neighbor Solicitation messages to multicast addresses to resolve addresses and to unicast addresses to verify the reachability of a neighboring node.

    • Neighbor Advertisement

      IPv6 nodes send Neighbor Advertisement messages in response to the receipt of Neighbor Solicitation messages. Nodes also send unsolicited Neighbor Advertisements to inform neighboring nodes of changes in link-layer addresses. Neighbor Advertisement messages contain information that nodes require to determine the type of Neighbor Advertisement message, the link-layer address of the sender, and the sender’s role on the network.

    • Redirect

      IPv6 routers send Redirect messages to inform an originating host of a better first-hop address for a specific destination. Routers send Redirect messages for unicast traffic only and only to originating hosts. Only hosts process Redirect messages.

    To ensure that all Neighbor Discovery messages were sent by a node on the local link, all Neighbor Discovery messages are sent with a hop limit of 255. When a Neighbor Discovery message is received, the Hop Limit field in the IPv6 header is checked. If the field is not set to 255, the message is silently discarded. Verifying that the Neighbor Discovery message has a hop limit of 255 provides protection from network attacks that are based on Neighbor Discovery and launched from off-link nodes. If a message has a hop limit of 255, a router could not have forwarded the message from an off-link node.

    Neighbor Discovery Options

    RFC 2461 defines the following Neighbor Discovery options:

    • Source Link-Layer Address Option

      The Source Link-Layer Address option indicates the link-layer address of the Neighbor Discovery message sender. Neighbor Solicitation, Router Solicitation, and Router Advertisement messages include this option. This option is not included when the source address of the Neighbor Discovery message is the unspecified address (::).

    • Target Link-Layer Address Option

      The Target Link-Layer Address option indicates the link-layer address of the neighboring node to which IPv6 packets should be directed. Neighbor Advertisement and Redirect messages include this option.

    • Prefix Information Option

      The Prefix Information option is sent in Router Advertisement messages to indicate both address prefixes and information about address autoconfiguration. Each Router Advertisement message can include multiple Prefix Information options, indicating multiple address prefixes.

    • Redirected Header Option

      The Redirected Header option is sent in Redirect messages to specify the IPv6 packet that caused the router to send a Redirect message. This option can contain all or part of the redirected IPv6 packet, depending on the size of the IPv6 packet that was initially sent.

    • MTU Option

      The MTU option is sent in Router Advertisement messages to indicate the IPv6 MTU of the link. This option can be used when the IPv6 MTU for a link is not well known or must reflect a translational or mixed-media bridging configuration. The MTU option overrides the IPv6 MTU that the interface hardware reports.

      In bridged or Layer-2 switched environments, different link-layer technologies with different link-layer MTUs can exist on the same network segment. In this case, differences in IPv6 MTUs between nodes on the same network are not discovered through Path MTU Discovery. The MTU option indicates the highest IPv6 MTU supported by all link-layer technologies on the network segment.

    Host Data Structures

    To facilitate interactions between neighboring nodes, RFC 2461 defines the following host data structures as examples of how to store information for Neighbor Discovery processes:

    • Neighbor cache

      Stores the on-link address of a neighbor, its corresponding link-layer address, and an indication of the neighbor’s reachability state. The neighbor cache is equivalent to the ARP cache in IPv4.

    • Destination cache

      Stores information about forwarding or next-hop addresses for destinations to which traffic has recently been sent. Entries in the destination cache contain the destination IP address (either local or remote), the previously resolved next-hop address, and the Path MTU for the destination.

    • Prefix list

      Lists on-link prefixes. Each entry defines a range of IP addresses for destinations that are directly reachable (neighbors). This list is populated from prefixes that routers advertise in Router Advertisement messages.

    • Default router list

      Lists IP addresses corresponding to on-link routers that send Router Advertisement messages and that are eligible to be default routers.

    RFC 2461 defines these structures as an example of an IPv6 host conceptual model. An IPv6 implementation is not required to create these exact data structures as long as the external behavior of the host is consistent with RFC 2461. For example, the IPv6 protocol for Windows Server 2008 uses a routing table rather than a prefix list and default router list. The routing table contains sufficient information to determine how to forward IPv6 packets. For more information, see IPv6 Routing (TechRef).

    Neighbor Discovery Message Exchanges

    The Neighbor Discovery protocol provides message exchanges for the following processes:

    • Address resolution

    • Duplicate address detection

    • Router discovery

    • Redirect function

    Address Resolution

    To resolve addresses, IPv6 nodes exchange Neighbor Solicitation and Neighbor Advertisement messages to resolve the link-layer address of the on-link next-hop address for a given destination. The sending host sends a multicast Neighbor Solicitation message on the appropriate interface. The multicast address of the Neighbor Solicitation message is the solicited-node multicast address derived from the target IP address. The Neighbor Solicitation message includes the link-layer address of the sending host in the Source Link-Layer Address option.

    When the target host receives the Neighbor Solicitation message, it updates its own neighbor cache based on the source address of the Neighbor Solicitation message and the link-layer address in the Source Link-Layer Address option. Next, the target host sends a unicast Neighbor Advertisement to the Neighbor Solicitation sender. The Neighbor Advertisement includes the Target Link-Layer Address option.

    After receiving the Neighbor Advertisement from the target host, the sending host updates its neighbor cache with an entry for the target host based on the information in the Target Link-Layer Address option. At this point, the sending host and the target host can send unicast IPv6 traffic to each other.

    As an example of this process, Host A has an Ethernet MAC address of 00-AA-00-11-11-11 and a corresponding link-local address of FE80::2AA:FF:FE11:1111. Host B has an Ethernet MAC address of 00-AA-00-22-22-22 and a corresponding link-local address of FE80::2AA:FF:FE22:2222. To send a packet to Host B, Host A must resolve Host B’s link-layer address.

    The following figure shows Host A sending a solicited-node multicast Neighbor Solicitation message (based on Host B’s IP address) to the address of FF02::1:FF22:2222.

    Multicast Neighbor Solicitation Message for Address Resolution

    Host B, having registered the solicited-node multicast address of 33-33-FF-22-22-22 with its Ethernet adapter, receives and processes the Neighbor Solicitation. The following figure shows Host B responding with a unicast Neighbor Advertisement message.

    Unicast Neighbor Advertisement Message for Address Resolution

    Duplicate Address Detection

    IPv4 nodes use ARP Request messages and a method called gratuitous ARP to detect duplicate IP addresses on their local links. Similarly, IPv6 nodes use the Neighbor Solicitation message to detect duplicate address use on their local links.

    With gratuitous ARP, the Source Protocol Address and Target Protocol Address fields in the ARP Request message header are set to the IPv4 address for which duplication is being detected. In IPv6 duplicate address detection, the Target Address field in the Neighbor Solicitation message is set to the IPv6 address for which duplication is being detected.

    Duplicate address detection differs from address resolution in these ways:

    • In a Neighbor Solicitation message for duplicate address detection, the Source Address field in the IPv6 header is set to the unspecified address (::). The address being queried for duplication cannot be used until it is determined that the address is not already in use.

    • In the Neighbor Advertisement reply to a Neighbor Solicitation message for duplicate address detection, the Destination Address in the IPv6 header is set to the link-local scope all-nodes multicast address (FF02::1). Because the sender of the Neighbor Solicitation message for duplicate address detection is not using the desired address, it cannot receive unicast Neighbor Advertisement messages. Therefore, the Neighbor Advertisement message is multicast.

    Upon receipt of the multicast Neighbor Advertisement message sent in response to the Neighbor Solicitation message, the node disables the use of the duplicate address on the interface. If the node does not receive a Neighbor Advertisement message that defends the use of the IPv6 address, it initializes the address on the interface.

    Router Discovery

    Router discovery is the process through which nodes attempt to discover the set of routers on the local link. Router discovery in IPv6 is similar to ICMP Router Discovery for IPv4 described in RFC 1256.

    An important difference between ICMPv4 Router Discovery and IPv6 router discovery is the mechanism through which the default router is changed when the current one becomes unavailable. In ICMPv4 Router Discovery, the Router Advertisement message includes an Advertisement Lifetime field. Advertisement Lifetime is the time after which the router, upon sending its last Router Advertisement message, can be considered unavailable. In the worst case, a router can become unavailable and hosts will not attempt to discover a new default router until the Advertisement Lifetime has elapsed.

    IPv6 has a Router Lifetime field in the Router Advertisement message. This field indicates the length of time that the router can be considered a default router. However, if the current default router becomes unavailable, the condition is detected through neighbor unreachability detection instead of the Router Lifetime field in the Router Advertisement message. Because neighbor unreachability detection determines that the router is no longer reachable, a new router is chosen immediately from the default router list. For more information, see “Neighbor Unreachability Detection” later in this section.

    In addition to configuring a default router, IPv6 router discovery also configures the following:

    • The default setting for the Hop Limit field in the IPv6 header.

    • A determination of whether the node should use a stateful address protocol, such as Dynamic Host Configuration Protocol for IPv6 (DHCPv6), for addresses and other configuration parameters.

    • The timers used in reachability detection and the retransmission of Neighbor Solicitation messages.

    • The list of network prefixes defined for the link. Each network prefix contains both the IPv6 network prefix and its valid and preferred lifetimes. If indicated, a network prefix combined with the interface identifier creates a stateless IP address configuration for the receiving interface. A network prefix also defines the range of addresses for nodes on the local link.

    • The MTU of the local link.

    The IPv6 router discovery processes are the following:

    • IPv6 routers periodically send Router Advertisement messages on the local link advertising their existence as routers. They also provide configuration parameters such as default hop limit, MTU, and prefixes.

    • Active IPv6 hosts on the local link receive the Router Advertisement messages and use the contents to maintain their default router lists, prefix lists, and other configuration parameters.

    • A host that is starting up sends a Router Solicitation message to the link-local scope all-routers multicast address (FF02::2). Upon receipt of a Router Solicitation message, each router on the local link send a unicast Router Advertisement message to the node that sent the Router Solicitation message. The node receives the Router Advertisement messages and uses their contents to build the default router and prefix lists and to set other configuration parameters.

    Redirect Function

    Routers use the redirect function to inform originating hosts of a better first-hop neighbor to which traffic should be forwarded for a specific destination. Routers use the redirect function for two purposes:

    • A router informs an originating host of the IP address of a router available on the local link that is closer to the destination. The term closer is a routing metric function used to reach the destination network segment. This condition can occur when multiple routers are on a network segment, the originating host chooses a default router, and it is not the best one to use to reach the destination.

    • A router informs an originating host that the destination is a neighbor (it is on the same link as the originating host). This condition can occur when the prefix list of a host does not include the prefix of the destination. Because the destination does not match a prefix in the list, the originating host forwards the packet to its default router.

    The following steps occur in the IPv6 redirect process:

    1. The originating host sends a unicast packet to its default router.

    2. The router processes the packet and notes that the address of the originating host is a neighbor. Additionally, the router notes that both the originating host and the next-hop are on the same link.

    3. The router forwards the packet to the appropriate next-hop address.

    4. The router sends the originating host a Redirect message. In the Target Address field of the Redirect message is the next-hop address of the node to which the originating host should send packets addressed to the destination.

      For packets redirected to a router, the Target Address field is set to the link-local address of the router. For packets redirected to a host, the Target Address field is set to the destination address of the packet originally sent.

      The Redirect message includes the Redirected Header option. The message might also include the Target Link-Layer Address option.

    5. Upon receiving the Redirect message, the originating host updates the destination address entry in the destination cache with the address in the Target Address field. If the Redirect message includes the Target Link-Layer Address option, its contents are used to create or update the corresponding entry in the neighbor cache.

    Only the first router in the path between the originating host and the destination sends redirect messages, and (like ICMPv6 error messages) they are rate limited. Hosts never send Redirect messages, and routers never update routing tables based on the receipt of a Redirect message.

    Neighbor Unreachability Detection

    Reachability is defined as the ability to send an IPv6 packet to a neighboring node and have the IPv6 layer of the neighbor receive and process that packet. When a node sends a packet to a router, the packet is delivered to the router’s IPv6 layer and then forwarded to the next hop. When a node sends a packet to a neighboring node, the packet is delivered to the node’s IPv6 layer. It is important to note that the definition of reachability does not require delivery to a remote node across a router — only to the neighboring router.

    When a neighbor becomes unreachable, IPv6 detects this condition and attempts to correct it. To determine whether a neighbor is reachable, IPv6 relies on either upper layer protocols that indicate communication progress or receipt of a Neighbor Advertisement message that has been sent in response to a unicast Neighbor Solicitation message.

    For TCP traffic, communication progress is indicated when new data or acknowledgement segments for sent data are received. For UDP traffic, a progress indication might not be present. In this case, the node sends unicast Neighbor Solicitation messages to the next-hop neighbor to monitor its ongoing reachability.

    Only the receipt of a solicited Neighbor Advertisement message is considered proof of reachability. A solicited Neighbor Advertisement message, which has its Solicited flag set to 1, is sent only in response to a Neighbor Solicitation message. Unsolicited Neighbor Advertisement or Router Advertisement messages are not considered proof of reachability.

    Neighbor unreachability detection detects symmetric reachability. In this instance, packets must be able to travel to and from the desired neighboring node. When a Neighbor Solicitation message is sent and a solicited Neighbor Advertisement message is received, the path between the nodes is confirmed. For an unsolicited Neighbor Advertisement or Router Advertisement message, only the path from the node sending the message is confirmed. This is called asymmetric reachability.

    For a specific local node, reachability is confirmed only by the node that sends the Neighbor Solicitation message and receives the Neighbor Advertisement message. The node sending the Neighbor Advertisement message receives no confirmation that the message reached the intended node. For two neighboring nodes to both determine reachability, each node must exchange Neighbor Solicitation and Neighbor Advertisement messages with the other.

    The reachability of a neighboring node is determined by monitoring the state of the neighboring node’s entry in the neighbor cache. RFC 2461 defines the following states for a neighbor cache entry:

    • INCOMPLETE

      IPv6 address resolution, which is using a solicited-node multicast Neighbor Solicitation message, is in progress. The INCOMPLETE state is entered when a neighbor cache entry is created but does not yet have the node’s corresponding link-layer address. RFC 2461 recommends that three successive multicast Neighbor Solicitation messages be sent.

    • REACHABLE

      Reachability has been confirmed by receipt of a solicited unicast Neighbor Advertisement message. The neighbor cache entry stays in the REACHABLE state until the number of milliseconds indicated in the Reachable Time field in the Router Advertisement message elapses. The entry stays in the REACHABLE state as long as upper layer protocols such as TCP indicate that communication is progressing. Each time that progress is indicated, the reachable time for the entry is refreshed.

    • STALE

      Reachable time (the duration since the last reachability confirmation was received) has elapsed. The neighbor cache entry enters the STALE state after the number of milliseconds in the Reachable Time field in the Router Advertisement message (or a host default value) elapses, and the entry remains in this state until a packet is sent to the neighbor. The entry also enters the STALE state when the host receives an unsolicited Neighbor Advertisement message that is advertising the link-layer address.

    • DELAY

      To allow time for upper layer protocols to provide reachability confirmation before sending Neighbor Solicitation messages, the neighbor cache entry enters the DELAY state and waits a configurable period of time after sending a packet. RFC 2461 recommends a value of 5 seconds. If reachability is not confirmed by the delay time, then the entry enters the PROBE state, and a unicast Neighbor Solicitation message is sent.

    • PROBE

      Reachability confirmation is in progress for a neighbor cache entry that was in the STALE or DELAY state. Unicast Neighbor Solicitation messages are sent at intervals corresponding to a retransmission timer field in the Router Advertisement message that this host received. A configurable variable determines the number of Neighbor Solicitation messages sent before the reachability detection process is abandoned and the neighbor cache entry is removed. RFC 2461 recommends sending three successive unicast Neighbor Solicitation messages.

    The following figure shows the state diagram of an entry in the neighbor cache.

    States of a Neighbor Cache Entry

    If the unreachable neighbor is a router, the host chooses another router from the default router list and performs both address resolution and unreachability detection on it.

    Address Autoconfiguration

    A highly useful aspect of IPv6 is its ability to automatically configure itself without the use of a stateful configuration protocol, such as Dynamic Host Configuration Protocol for IPv6 (DHCPv6). By default, an IPv6 host can configure a link-local address for each interface. By using router discovery, a host can also determine the addresses of routers, additional addresses, and other configuration parameters. The Router Advertisement message indicates whether a stateful address configuration protocol should be used.

    Address autoconfiguration can be performed only on multicast-capable interfaces. RFC 2462 describes address autoconfiguration.

    Autoconfigured Address States

    Autoconfigured addresses are in one or more of the following states:

    • Tentative

      The address is in the process of being verified as unique. Verification occurs through duplicate address detection.

    • Preferred

      An address for which uniqueness has been verified. A node can send and receive unicast traffic to and from a preferred address. Router Advertisement messages include the period of time that an address can remain in the tentative and preferred states.

    • Deprecated

      An address that is still valid but whose use is discouraged for new communication. Existing communication sessions can continue to use a deprecated address. Nodes can send and receive unicast traffic to and from deprecated addresses.

    • Valid

      An address from which unicast traffic can be sent and received. The valid state covers both the preferred and deprecated states. Router Advertisement messages include the amount of time that an address remains in the valid state. The valid lifetime must be longer than or equal to the preferred lifetime.

    • Invalid

      An address for which a node can no longer send or receive unicast traffic. An address enters the invalid state after the valid lifetime expires.

    The following figure shows the relationship between the states of an autoconfigured address and the preferred and valid lifetimes.

    States of an Autoconfigured Address

    With the exception of link-local addresses, address autoconfiguration is specified only for hosts. Routers must obtain address and configuration parameters through another means (for example, manual configuration).

    Types of Autoconfiguration

    Autoconfiguration falls into three types:

    1. Stateless

      Configuration is based on Router Advertisement messages. These messages include stateless address prefixes and require that hosts not use a stateful address configuration protocol.

    2. Stateful

      Configuration is based on a stateful address configuration protocol, such as DHCPv6, to obtain addresses and other configuration options. Hosts use stateful address configuration when they receive Router Advertisement messages that do not include address prefixes and that require the hosts to use a stateful address configuration protocol. A host will also use a stateful address configuration protocol when no routers are present on the local link.

    3. Both

      Configuration is based on Router Advertisement messages. These messages include stateless address prefixes but require hosts to use a stateful address configuration protocol.

    For all autoconfiguration types, a link-local address is always configured.

    Autoconfiguration Process

    Address autoconfiguration for an IPv6 node occurs as follows:

    1. A tentative link-local address is derived, based on the link-local prefix of FE80::/64 and the 64-bit interface identifier.

    2. Duplicate address detection is performed to verify the uniqueness of the tentative link-local address.

      If the address is already in use, the node must be configured manually.

      If the address is not already in use, the tentative link-local address is assumed to be unique and valid. The link-local address is initialized for the interface. The corresponding solicited-node multicast link-layer address is registered with the network adapter.

    3. The host sends a Router Solicitation message.

    4. If the host receives no Router Advertisement messages, then it uses a stateful address configuration protocol to obtain addresses and other configuration parameters.

    5. If the host receives a Router Advertisement message, the host is configured based on the information in the message

    6. For each stateless address prefix that the message includes:

      A tentative address is derived from the address prefix and the appropriate 64-bit interface identifier.

      The uniqueness of the tentative address is verified.

      If the tentative address is in use, the address is not initialized for the interface.

      If the tentative address is not in use, the address is initialized. Initialization includes setting the valid and preferred lifetimes based on information in the Router Advertisement message. Initialization also includes registering the corresponding solicited-node multicast link-layer address with the network adapter.

    7. If specified in the Router Advertisement message, the host uses a stateful address configuration protocol to obtain additional addresses or configuration parameters.