Share via


The Cable GuyIPv6 Autoconfiguration in Windows Vista

Joseph Davies

IPv6 is about more than extending the address space from 32 bits in IPv4 to 128 bits. IPv6 hosts can also automatically configure themselves, even without the use of an address configuration protocol such as DHCP for IPv6 (DHCPv6).

Based on RFC 2462, all IPv6 nodes automatically configure a link-local address for each interface. An IPv6 host also uses router discovery—an exchange of Router Solicitation and Router Advertisement messages—to determine additional addresses and configuration settings. Included in the Router Advertisement message sent by the router are the Managed Address Configuration (M) and Other Stateful Configuration (O) flags, which indicate whether the host should use DHCPv6 for additional addresses or configuration settings.

Types of IPv6 Autoconfiguration

Beyond the link-local address, hosts can also use stateless autoconfiguration to configure addresses and other settings based on the receipt of Router Advertisement messages. These messages can include one or more Prefix Information options, which the receiving host can use to derive stateless addresses.

Likewise, stateful autoconfiguration is the configuration of addresses and other settings based on the use of DHCPv6 to obtain addresses. A host uses stateful autoconfiguration when it receives a Router Advertisement message with the M flag set to 1.

Finally, a host can also use both stateless and stateful autoconfiguration, which is a combination of addresses included in the router advertisement and obtained from a DHCPv6 server.

Autoconfigured Address States

When an autoconfigured address is in the tentative state, it is in the process of being verified as unique through duplicate address detection (DAD). See the "RFC 2462 IPv6 Autoconfiguration Process" sidebar for information about how DAD is performed. An address in the valid state has been verified as unique and can be used for sending and receiving unicast traffic. The valid state includes both preferred and deprecated states. In the preferred state, the address can be used for unlimited communication. In the deprecated state, the address should not be used for new communication; however, existing communications using the address can continue.

RFC 2462 IPv6 Autoconfiguration Process

The following steps describe the autoconfiguration process for an IPv6 host as defined in RFC 2462:

  • Derive a tentative link-local address with an Extended Unique Identifier (EUI)-64 interface identifier (ID).
  • Perform DAD on the tentative link-local address by sending a Neighbor Solicitation message with the Target Address in the message set to the tentative link-local address.
  • If a Neighbor Advertisement message sent in response to the Neighbor Solicitation message is received, the tentative link-local address is a duplicate address. Stop address autoconfiguration. At this point, manual configuration must be performed on the host.
  • If no Neighbor Advertisement message (sent in response to the Neighbor Solicitation message) is received, the tentative link-local address is unique. Change the state of the address on the interface to preferred.
  • Send a Router Solicitation message.
  • If no Router Advertisement messages are received, use DHCPv6 to obtain addresses and other configuration parameters.
  • If a Router Advertisement message is received, configure tentative addresses for the included prefixes and perform duplicate address detection for each tentative address. If the addresses are unique, change the state of the addresses on the interface to preferred.
  • If the M flag in the Router Advertisement message is set to 1, use DHCPv6 to obtain additional stateful addresses.
  • If the M flag in the Router Advertisement message is set to 0 and the O flag is set to 1, use DHCPv6 to obtain additional configuration parameters.

An advertising router or DHCPv6 server specifies the valid and preferred lifetimes for an address prefix. An address enters the deprecated state after the preferred lifetime of the address has been exceeded. The preferred lifetime of an autoconfigured address is refreshed by receiving router advertisements or by renewing the DHCPv6 address configuration. Figure 1 shows the states of an autoconfigured address and their relationship to the preferred and valid lifetimes.

Figure 1 The states of an autoconfigured address

Figure 1** The states of an autoconfigured address **(Click the image for a larger view)

With the exception of autoconfiguration for link-local addresses, address autoconfiguration is specified only for IPv6 hosts. IPv6 routers must obtain address and configuration parameters through another means, such as manual configuration.

The "RFC 2462 IPv6 Autoconfiguration Process" sidebar describes the detailed IPv6 address autoconfiguration process for hosts that is defined in RFC 2462.

IPv6 Autoconfiguration Behavior for Windows Vista

Computers running Windows Vista® or Windows Server® 2008 by default generate random interface IDs for non-temporary autoconfigured IPv6 addresses, including public and link-local addresses, rather than EUI-64-based interface IDs. A public IPv6 address is a global address that is registered in DNS and is typically used by server applications for incoming connections, such as a Web server. You can disable this default behavior with the command:

netsh interface ipv6 set global randomize­identifiers=disabled 

When disabled, IPv6 uses EUI-64-based interface IDs.

With a randomly derived interface ID, the chance of duplicating the link-local address is very small. Therefore, computers running Windows Vista or Windows Server 2008 do not wait for DAD to complete before sending Router Solicitation messages using their derived link-local addresses. This is known as optimistic DAD; router discovery and DAD are performed in parallel to save time during the interface initialization process.

Computers running Windows Vista or Windows Server 2008 do not attempt stateful address autoconfiguration with DHCPv6 if no router advertisements are received.

Windows Vista IPv6 Autoconfiguration Process

The following steps describe the autoconfiguration process for an IPv6 host running Windows Vista:

  • Derive a tentative link-local address for the LAN interface with a randomly derived interface ID (the default setting).
  • Perform DAD for the derived link-local address of the LAN interface (send a Neighbor Solicitation message with the Target Address field that is set to the tentative link-local address).
  • Perform router discovery on the LAN interface (send a Router Solicitation message from the tentative link-local address).
  • If a Neighbor Advertisement message sent in response to the Neighbor Solicitation message sent in Step 2 is received, mark the link-local address as a duplicate.
  • If no Neighbor Advertisement messages in response to the Neighbor Solicitation message are received, change the state of the link-local address on the LAN interface to preferred.
  • If no router advertisements are received, stop IPv6 address autoconfiguration on the LAN interface. Go to Step 13.
  • If a router advertisement is received, create tentative public addresses corresponding to the global or unique local address prefixes in the message based on the random interface ID derived in Step 1, and perform DAD.
  • Create tentative temporary addresses corresponding to the global or unique local address prefixes in the message using new randomly derived random interface IDs, and perform DAD.
  • For each new address, if no Neighbor Advertisement messages in response to the Neighbor Solicitation message are received, change the state of the address on the LAN interface to preferred.
  • If the router advertisement has both the M and O flags set to 0, stop IPv6 autoconfiguration on the LAN interface. Go to Step 13.
  • If the router advertisement has the M flag set to 1, use DHCPv6 to obtain both stateful IPv6 addresses and additional configuration settings.
  • If the router advertisement has the M flag set to 0 and the O flag set to 1, use DHCPv6 to obtain additional configuration settings.
  • Derive link-local ISATAP addresses based on the IPv4 addresses of the LAN interface and assign them to the ISATAP tunneling interface.
  • Attempt to resolve the host name "ISATAP" to an IPv4 address.
  • If the host name "ISATAP" cannot be resolved, stop IPv6 configuration.
  • If the host name "ISATAP" is resolved to an IPv4 address, send an IPv4-encapsulated router solicitation to the ISATAP router.
  • If a router advertisement from the ISATAP router is received, create additional ISATAP addresses corresponding to the advertised global or unique local address prefixes and assign them to the ISATAP tunneling interface.

Autoconfigured Addresses for Windows Vista

As previously described, the IPv6 protocol for Windows Vista and Windows Server 2008 automatically configures link-local addresses using randomly derived interface identifiers for all LAN interfaces.

If a received router advertisement includes a global or unique local prefix, IPv6 configures global or unique local addresses using the same randomly derived interface ID and assigns them to the LAN interface that received the router advertisement. Such addresses are known as public addresses.

IPv6 in Windows Vista by default also configures temporary global or unique local addresses using different randomly derived interface IDs and assigns them to the LAN interface that received the router advertisement. Temporary addresses are defined in RFC 3041 and are used to provide a level of anonymity for client-initiated communications. In contrast, IPv6 in Windows Server 2008 does not create temporary addresses by default. You can enable temporary addresses by using the command:

netsh interface ipv6 set privacy=enabled

If the M flag is set to 1 in received Router Advertisement messages, IPv6 uses DHCPv6 to configure additional global or unique local addresses for the LAN interface.

IPv6 also creates an Intra-site Automatic Tunnel Addressing Protocol (ISATAP) tunneling interface for each LAN interface on the host. RFC 4214 describes the ISATAP IPv6 transition technology. With ISATAP, IPv6 hosts can communicate over an IPv4-only intranet by encapsulating an IPv6 packet with an IPv4 header. For more information about ISATAP, see the "IPv6 Transition Technologies".

For each ISATAP tunneling interface, IPv6 configures link-local ISATAP addresses for the IPv4 addresses that are assigned to its corresponding LAN interface. For example, for the ISATAP tunneling interface that corresponds to a LAN interface that is assigned the IPv4 address 192.168.91.211, IPv6 assigns the link-local ISATAP address of FE80::0:5EFE:192.168.91.211.

ISATAP hosts also perform ISATAP router discovery. To receive a router advertisement from an ISATAP router, IPv6 by default must be able to resolve the host name "ISATAP" to an IPv4 address. This is done through Windows-based host name resolution methods such as DNS. After the name is resolved, the host sends an IPv4-encapsulated router solicitation to the ISATAP router. The ISATAP router then sends an IPv4-encapsulated router advertisement to the host. Based on the contents of the received router advertisement, IPv6 also configures global or unique local ISATAP addresses on the ISATAP tunneling interfaces.

Windows Vista also supports the 6to4 and Teredo IPv6 transition technologies. To simplify matters, however, I will not discuss the autoconfiguration of the 6to4 and Teredo tunneling interfaces of a Windows Vista-based IPv6 host here.

The "Windows Vista IPv6 Autoconfiguration Process" sidebar describes the address autoconfiguration process for a Windows Vista-based IPv6 host with a single LAN interface that is configured with global or unique local address prefixes on either its LAN or ISATAP tunneling interfaces.

For example, a host running Windows Vista has a single LAN interface. The host receives a router advertisement on its LAN interface with both the M and O flags set to 0 and contains the prefixes 2001:DB8:D005:F282::/64 and FD4A:3A9:27A1:F282::/64. It does not receive a Router Advertisement message from an ISATAP router. Figure 2 is an example of the output resulting from the command

Figure 2 Output from netsh interface ipv6 show address

Interface 1: Loopback Pseudo-Interface 1

Addr Type DAD State Valid Life Pref. Life Address
--------- ----------- ---------- ---------- ------------------------
Other   Preferred  infinite infinite ::1

Interface 8: Local Area Connection

Addr Type DAD State Valid Life Pref. Life Address
--------- ----------- ---------- ---------- ------------------------
Temporary Preferred 6d19h37m21s 6d19h37m21s 2001:db8:d005:f282:ed46:5dd4:5439:2e1c
Public  Preferred  infinite infinite 2001:db8:d005:f282:3521:12fa:2c44:87d1
Temporary Preferred 6d19h37m21s 6d19h37m21s fd4a:3a9:27a1:f282:ed46:5dd4:5439:2e1c
Public   Preferred  infinite infinite fd4a:3a9:27a1:f282:3521:12fa:2c44:87d1
Other   Preferred  infinite infinite fe80::3521:12fa:2c44:87d1%8

Interface 17: Local Area Connection* 9

Addr Type DAD State Valid Life Pref. Life Address
--------- ----------- ---------- ---------- ------------------------
Other   Preferred  infinite infinite fe80::5efe:10.47.181.92%17

netsh interface ipv6 show address

for this example host. In the figure, the ISATAP tunneling interface corresponding to the LAN interface named Local Area Connection is named Local Area Connection* 9.

In addition to autoconfigured addresses, the IPv6 protocol for Windows Server 2008 and Windows Vista also supports manual configuration of static IPv6 addresses through the use of the following command

netsh interface ipv6 add address

or through the Internet Protocol Version 6 (TCP/IPv6) component from the properties of a connection in the Network Connections folder.

Throughout this month's column, I have assumed you already had a general foundation in IPv6 addressing and protocol operation. If you need more information on this topic, I suggest you begin with the whitepaper "Introduction to IPv6," which can be found at microsoft.com/technet/ network/ipv6/introipv6.mspx.

Joseph Davies is a technical writer with Microsoft and has been teaching and writing about Windows networking topics since 1992. He has written eight books for Microsoft Press and is the author of the monthly online TechNet Cable Guy column.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.