IPv6 Essentials

4.7. Autoconfiguration

The autoconfiguration capability of IPv6 saves network administrators a lot of work. It has been designed to ensure that manually configuring hosts before connecting them to the network is not required. Even larger sites with multiple networks and routers should not need a DHCP server to configure hosts. The autoconfiguration features of IPv6 will be a key feature of the protocol when all sorts of devicessuch as televisions, refrigerators, DVD players, and mobile phonesuse IP addresses. You don't want to depend on a DHCP server to use your home devices.

IPv6 knows both Stateless and Stateful autoconfiguration. Stateful autoconfiguration is what we call DHCP in the IPv4 world; it is discussed in Chapter 9. What's really new with IPv6 is that hosts can autoconfigure their IPv6 addresses without any manual configuration of the host. Some configuration might be done on the routers, but no DHCP servers are required for this configuration mechanism. To generate its IP address, a host uses a combination of local information, such as its MAC address or a randomly chosen ID, and information received from routers. Routers can advertise multiple prefixes, and hosts determine prefix information from these advertisements. This allows for simple renumbering of a site: only the prefix information on the router has to be changed. For instance, if you change your ISP and the new ISP assigns a new IPv6 prefix, you can configure your routers to advertise this new prefix, keeping the subnet IDs that you used with the old prefix. All hosts attached to those routers will renumber themselves through the autoconfiguration mechanism. You can find more on renumbering networks later in this chapter. If there is no router present, a host can generate only a link-local address with the prefix FE80, but this address is sufficient for communication of nodes attached to the same link.

Stateless and Stateful autoconfiguration can also be combined. For instance, a host can use Stateless autoconfiguration to generate an IPv6 address but then use Stateful autoconfiguration for additional parameters.

An IPv6 address is leased to a node for a certain lifetime. When the lifetime expires, the address becomes invalid. To make sure an address is unique on a link, a node runs the Duplicate Address Detection (DAD) process. The DAD algorithm is defined in RFC 2462. An IPv6 address can have different states:

Tentative address

This is an address that has not yet been assigned. It is the state prior to the assignment, when uniqueness is being verified (during DAD). A node cannot communicate in the network using a tentative address. The only messages that can be processed with a tentative address are ND messages relating to the autoconfiguration process.

Preferred address

This is the address that has been assigned to an interface and can be used without any restrictions for the lifetime assigned.

Deprecated address

The use of this address is discouraged but not forbidden. A deprecated address might be one whose lifetime is about to expire. It can still be used to continue a communication that would disrupt a service if the address changed. It is no longer used as a Source address for newly established communications.

Valid address

This term is used for both the Preferred and Deprecated address.

Invalid address

An invalid address is not assigned to an interface. A valid address becomes invalid when its lifetime expires.

When a node is autoconfigured, the following steps are performed:

1. A link-local address is generated by using the link-local prefix of FE80 and appending the interface identifier. This address is a tentative address.

2. The node joins the following multicast groups: the all-nodes multicast group (FF02::1) and the solicited-node multicast group for the tentative address (from step 1).

3. A Neighbor Solicitation message is sent out with the tentative address as the target address. The IP Source address of this message is the all-zeros address; the IP Destination address is the solicited-node multicast address. This detects whether another node on the link already uses this address; i.e., this is DAD. If there is such a node, it replies with a Neighbor Advertisement message, and the autoconfiguration mechanism stops. In this case, manual reconfiguration of the host is required. If there is no answer to the Neighbor Solicitation, it is safe to use the address; the address is assigned to the interface and the state of the address changes to "preferred." IP connectivity on the local link is now established. So far, the process is the same for hosts and routers, but only hosts perform the next step.

4. In order to determine which routers are out there and what the prefix is, the host sends a Router Solicitation message to the all-routers multicast group of FF02::2.

5. All routers on the link reply with a Router Advertisement. For each prefix in Router Advertisements with the Autonomous Configuration flag set, an address is generated, combining the prefix with the interface identifier. These addresses are added to the list of assigned addresses for the interface.

All addresses must be verified with a Neighbor Solicitation message (DAD) before they are assigned. If the link-local address was generated through the autoconfiguration mechanism using the interface identifier, uniqueness has been verified in step 3 and may not need to be repeated for additional addresses that use the same interface identifier. All other addresses configured manually or through Stateful configuration need to be verified individually. Multihomed hosts perform autoconfiguration for each interface.

The trace shown in the screenshot in Figure 4-18 was taken during the autoconfiguration process of Marvin, our Windows host. Figure 4-18 shows some of the processes and message types discussed earlier, and the discussion of the trace summarizes the concepts in this section.

As long as the booting host does not have a valid IPv6 address it sends all packets from its unspecified all-zeros address, represented as ::0.0.0.0 in the trace file.

First packet

With the first packet, the booting host registers for its solicited node multicast address based on its MAC identifier. The packet contains a Hop-by-Hop Options header with option type 5 for MLD messages. The hop limit is set to 1.

Second packet

With the second packet, it sends a Router Solicitation message to the all-routers multicast address FF02::2.

Third packet

In packet three, it sends a Neighbor Solicitation to the solicited node address in order to perform DAD. The Target Address field of the ICMPv6 header contains the link local address of FE80::206:1BFF:FECC:1734. If another node on the link already used this address, it would reply with a Neighbor Advertisement message.

Fourth packet

The router sends a Router Advertisement to the all-nodes multicast address of FF02::1, because the host does not have a valid IPv6 address yet. This Router Advertisement has the Autonomous Address Configuration flag set to one and contains the prefix 2001:8E0:ABCD:E2::/64.

Fifth packet

With this packet, the host registers for the solicited node multicast address of FF02::1:FF5F:FA11. This is not the interface ID used in packet one. Microsoft has implemented the privacy option and it is enabled by default, so this is the randomly generated interface ID.

Sixth packet

The host performs the DAD test for the address formed by combining the prefix sent in the Router Advertisement (packet four) with the randomly generated interface ID. The packet is sent to the solicited node multicast address. The IPv6 address can be seen in the highlighted line in the detail window opened for packet six.

Seventh packet

The host performs the DAD test for the IPv6 address formed by combining the prefix learned from the Router Advertisement and the MAC identifier. The Target Address field contains the IPv6 address 2001:8E0:ABCD:E2:206:1BFF:FECC:1734.

Eighth and ninth packets

The host uses its MAC identifier based IPv6 address that is in preferred state to register for its two solicited node multicast addresses. Both packets contain the Hop-by-Hop Options header with option type 5 for MLD messages.

When you take your own traces to analyze a boot process and use different operating systems, you will also find differences in the process shown in the trace file. Figure 4-18 is what the boot process looks like with a Windows XP host with SP1 and the advanced networking pack. The differences come from the fact that the RFCs leave room for interpretation of the standard, which can be implemented slightly differently by different vendors. As long as the "must-use" rules in the RFCs are followed, compliance should not be an issue. Note the "should"; this is where your trace file analysis expertise will be helpful in case of failures. Another reason for differences is that the implementation behavior depends on what level and state of the standardization has been implemented. If Microsoft implements the privacy option, this stack will obviously behave differently from a stack that has not implemented the privacy option. So when you analyze processes of a specific operating system, get enough information from the vendor about which RFCs (and sometimes drafts) have been implemented. And if the vendor states that it implemented something, you can use your trace files to verify whether the stack works as it should.