Autoconfiguration Process

The address autoconfiguration process defined in RFC 2462 for the physical interface of an IPv6 node is the following:

  1. A tentative link-local address is derived based on the link-local prefix of FE80::/64 and a EUI-64-derived interface identifier.
  2. Using duplicate address detection to verify the uniqueness of the tentative link-local address, a Neighbor Solicitation message is sent with the Target Address field that is set to the tentative link-local address.
  3. If a Neighbor Advertisement message (sent in response to the Neighbor Solicitation message) is received, this indicates that another node on the local link is using the tentative link-local address and address autoconfiguration stops. At this point, manual configuration must be performed on the node.
  4. If no Neighbor Advertisement message (sent in response to the Neighbor Solicitation message) is received, the tentative link-local address is assumed to be unique and valid. The link-local address is initialized for the interface. The link-layer multicast address of the solicited-node address corresponding to the link-local address is registered with the network adapter.

For an IPv6 host, the address autoconfiguration continues as follows:

  1. The host sends a Router Solicitation message. While routers pseudo-periodically send router advertisements, the host sends a Router Solicitation message to request an immediate router advertisement, rather than waiting until the next router advertisement. By default, up to three Router Solicitation messages are sent.
  2. If no Router Advertisement messages are received, the host uses a stateful address autoconfiguration protocol to obtain addresses and other configuration parameters.
  3. If a Router Advertisement message is received, the hop limit, reachable time, retransmission timer, and the MTU (if the MTU option is present) are set.
  4. For each Prefix Information option present:

    If the On-Link flag is set to 1, the prefix is added to the prefix list.

    If the Autonomous flag is set to 1, the prefix and an appropriate interface identifier are used to derive a tentative address.

    Duplicate address detection is used to verify the uniqueness of the tentative address.

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

    If the tentative address is not in use, the address is initialized. This includes setting the valid and preferred lifetimes based on the Valid Lifetime and Preferred Lifetime fields in the Prefix Information option. If needed, it also includes registering the link-layer multicast address of the solicited-node address corresponding to the new address with the network adapter.

  5. If the Managed Address Configuration flag in the Router Advertisement message is set to 1, a stateful address autoconfiguration protocol is used to obtain additional addresses.
  6. If the Other Stateful Configuration flag in the Router Advertisement message is set to 1, a stateful address autoconfiguration protocol is used to obtain additional configuration parameters.

Figures 8-2 and 8-3 show the address autoconfiguration process for a host.

Figure 8-2. The address autoconfiguration process for a host (Part 1)

Figure 8-3. The address autoconfiguration process for a host (Part 2)

IPv6 Protocol for the Windows .NET Server 2003 Family and Windows XP Autoconfiguration Specifics

RFC 2462 does not require a specific order for sending the initial router solicitation and performing duplicate address detection for the derived link-local address. The IPv6 protocol for the Windows .NET Server 2003 family and Windows XP sends the Router Solicitation message before performing duplicate address detection on the EUI-64-derived link-local address. In this way, duplicate address detection and router discovery are done in parallel to save time during the physical interface initialization process.

If the EUI-64-derived link-local address is a duplicate, stateless address autoconfiguration for the IPv6 protocol for the Windows .NET Server 2003 family and Windows XP can continue with the receipt of a multicast Router Advertisement message containing site-local or global prefixes. The attempted link-local address is shown with a "Duplicate" state in the display of the netsh interface ipv6 show address command and a site-local or global address—rather than the duplicate link-local address—is used for neighbor discovery processes.

The IPv6 protocol for the Windows .NET Server 2003 family and Windows XP does not support stateful address autoconfiguration or DHCPv6.

Autoconfigured Addresses for the IPv6 Protocol for the Windows .NET Server 2003 Family and Windows XP

By default, the following IPv6 addresses are automatically configured for the IPv6 protocol for the Windows .NET Server 2003 family and Windows XP:

  • Link-local addresses using EUI-64-derived interface identifiers are assigned to all LAN interfaces.
  • If included as a site-local prefix in a Prefix Information option of a router advertisement, a site-local address using an EUI-64-derived interface identifier is assigned to the LAN interface that received the router advertisement.
  • If included as a global prefix in a Prefix Information option of a router advertisement, a global address using an EUI-64-derived interface identifier is assigned to the LAN interface that received the router advertisement.
  • If included as a global prefix in a Prefix Information option of a router advertisement, a global address using a randomly derived temporary interface identifier is assigned to the LAN interface that received the router advertisement.
  • If public IPv4 addresses are assigned to interfaces of the computer and there are no global autoconfiguration prefixes received in Router Advertisement messages, corresponding 6to4 addresses using 6to4-derived interface identifiers are assigned to the 6to4 Tunneling Pseudo Interface. 6to4 is described in RFC 3056.
  • For all IPv4 addresses that are assigned to interfaces of the computer, corresponding link-local addresses using Intra-site Automatic Tunnel Addressing Protocol (ISATAP)-derived interface identifiers are assigned to the Automatic Tunneling Pseudo-Interface. ISATAP is described in the Internet draft "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)".
  • If included as a site-local prefix in a Prefix Information option of a router advertisement received on the Automatic Tunneling Pseudo-Interface, a site local address using the ISATAP-derived interface identifier corresponding to the IPv4 address that is the best source to use to reach the ISATAP router is assigned to the Automatic Tunneling Pseudo-Interface.
  • If included as a global prefix in a Prefix Information option of a router advertisement received on the Automatic Tunneling Pseudo-Interface, a global address using the ISATAP-derived interface identifier corresponding to the IPv4 address that is the best source to use to reach the ISATAP router is assigned to the Automatic Tunneling Pseudo-Interface.
  • The loopback address (::1) and the link-local address FE80::1 are assigned to the Loopback Pseudo-Interface.

In order to receive a Router Advertisement message on the Automatic Tunneling Pseudo-Interface, the host must be able to resolve the name "isatap" to an IPv4 address. This is done through normal name resolution mechanisms including DNS and NetBIOS name queries. Once resolved, the host sends a Router Solicitation message encapsulated in an IPv4 header to the ISATAP router. The ISATAP router then sends a Router Advertisement message encapsulated in an IPv4 header to the host.

For more information about ISATAP and 6to4, see Chapter 11, "Coexistence and Migration."

The following is an example of the display of the netsh interface ipv6 show address command for a host running Windows .NET Standard Server that received a Router Advertisement message containing the prefixes FEC0:0:0:
F282::/64 and 3FFE:2900:D005:F282::/64 on its LAN interface (interface index 3):

 Interface 3: Local Area Connection Addr Type  DAD State  Valid Life Pref. Life Address ---------  ---------  ---------- ---------- ---------------------------------------- Public     Preferred     2591813     604613 fec0::f282:201:2ff:fe44:87d1 Anonymous  Preferred      604613      86046 3ffe:2900:d005:f282:ed46:5dd4:5439:2e1c Public     Preferred     2591813     604613 3ffe:2900:d005:f282:201:2ff:fe44:87d1 Link       Preferred  4294967295 4294967295 fe80::201:2ff:fe44:87d1 Interface 2: Automatic Tunneling Pseudo-Interface Addr Type  DAD State  Valid Life Pref. Life Address ---------  ---------  ---------- ---------- ---------------------------------------- Link       Preferred  4294967295 4294967295 fe80::5efe:157.54.138.19 Interface 1: Loopback Pseudo-Interface Addr Type  DAD State  Valid Life Pref. Life Address ---------  ---------  ---------- ---------- ---------------------------------------- Loopback   Preferred  4294967295 4294967295 ::1 Link       Preferred  4294967295 4294967295 fe80::1 

Network Monitor Capture

The following Network Monitor capture summary (capture 08_01 in the \NetworkMonitorCaptures folder on the companion CD-ROM) shows the IPv6 traffic for an example interface startup process for a computer running Windows XP.

 Frame  Time         Source            Destination     Protocol/Desc 1      15.671975    HOST              3333FF234733    ICMP6
Multicast Listener Report 2 15.671975 HOST 333300000002 ICMP6
Router Solicitation 3 15.671975 HOST 3333FF234733 ICMP6
Neighbor Solicitation; Target = fe80::2b0:d0ff:fe23:4733 4 15.671975 ROUTER 333300000001 ICMP6
Router Advertisement 5 16.171979 HOST 3333FF972C32 ICMP6
Multicast Listener Report 6 16.171979 HOST 3333FF234733 ICMP6
Neighbor Solicitation; Target = fec0::f282:2b0:d0ff:fe23:4733 7 16.171979 HOST 3333FF972C32 ICMP6
Neighbor Solicitation;
Target = 3ffe:2900:d005:f282:1cfc:d6c6:8897:2c32 8 16.171979 HOST 3333FF234733 ICMP6
Neighbor Solicitation;
Target = 3ffe:2900:d005:f282:2b0:d0ff:fe23:4733 9 17.187610 HOST 3333FF234733 ICMP6
Multicast Listener Report 10 21.672014 HOST 3333FF972C32 ICMP6
Multicast Listener Report

The interface startup process is the following:

  • Frame 1 is an MLD Multicast Listener Report message for the solicited-node multicast address FF02::1:FF23:4733. This solicited-node multicast address is used for all IPv6 addresses that are derived from the EUI-64 address of the network adapter.
  • Frame 2 is the initial router solicitation.
  • Frame 3 is duplicate address detection on the EUI-64-derived link-local address FE80::2B0:D0FF:FE23:4733.
  • Frame 4 is the router advertisement sent in response to the router solicitation (Frame 2). The router advertisement is sent to the link-local scope all-nodes multicast address because the router solicitation (Frame 2) was sent from the unspecified address (::). This router advertisement contains two Prefix Information options—one for the global prefix 3FFE:2900:D005:F282::/64 and one for the site-local prefix FEC0:0:0:F282::/64.
  • Frame 5 is an MLD Multicast Listener Report message for the solicited-node multicast address FF02::1:FF97:2C32. This solicited-node multicast address is used for all temporary IPv6 addresses that are randomly derived.
  • Frame 6 is duplicate address detection on the EUI-64-derived site-local address FEC0::F282:2B0:D0FF:FE23:4733.
  • Frame 7 is duplicate address detection on the randomly derived temporary global address 3FFE:2900:D005:F282:1CFC:D6C6:8897:
    2C32.
  • Frame 8 is duplicate address detection on the EUI-64-derived global address 3FFE:2900:D005:F282:2B0:D0FF:FE23:4733.
  • Frame 9 is an additional MLD Multicast Listener Report message for the solicited-node multicast address FF02::1:FF23:4733.
  • Frame 10 is an additional MLD Multicast Listener Report message for the solicited-node multicast address FF02::1:FF97:2C32.

In addition to autoconfigured addresses, the IPv6 protocol for the Windows .NET Server 2003 family and Windows XP also supports the manual configuration of IPv6 addresses using the netsh interface ipv6 set address command.



Understanding IPv6
Understanding Ipv6
ISBN: 0735612455
EAN: 2147483647
Year: 2005
Pages: 124
Authors: Joseph Davies

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net