IPv6 Essentials

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 devices, such as TVs, refrigerators, DVD players, and mobile phones, use 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 address 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 their IP address, hosts use a combination of local information, such as their MAC address, 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 SLA that you used with the old prefix. All hosts attached to those routers will renumber themselves through the autoconfiguration mechanism. If there is no router present, a host can generate a link-local address only with the prefix FE80. But this address is sufficient for communication of nodes attached with 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 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.

Preferred address

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

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.

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 if 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 configuration 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. Only hosts perform the next step.

4. In order to determine what 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 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, before they are assigned, must be verified with a Neighbor Solicitation message (DAD). 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 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 screenshots in Figure 4-18 to Figure 4-20 was taken during the autoconfiguration process of Marvin, our Windows 2000 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.

Figure 4-18. Autoconfiguration in the trace file

The first two packets are sent out by the unspecified address because this host is just booting and does not yet have an IP address. The first packet is a Router Solicitation message and therefore sent out the the all-routers multicast address FF02::2. According to the autoconfiguration specification, we would expect to see the duplicate address detection described in Figure 4-19 first. It seems that this implementation is trying to expedite the learning of the prefix information. The detail window shows the ICMPv6 header with the type number 133 for Router Solicitation. There are no neighbor discovery options specified. The option could be the link-layer address of the sender, but in the case of a message sent from the unspecified address, this option is not used. Figure 4-19 shows the details of the second packet, the Neighbor Solicitation.

Figure 4-19. Neighbor Solicitation

The address is still in the tentative state, so the source address in the IPv6 header is the unspecified address again. The solicitation is sent out to the solicited-node multicast address. The important field here is the target address in the ICMPv6 header, which is highlighted. If a node already uses this address, it will already be a member of this solicited-node multicast address group and will reply with a Neighbor Advertisement. Then the autoconfiguration process will stop.

Now let’s get to the Router Advertisement. You saw a trace file earlier in this chapter, when we discussed the Options fields in the Router Advertisement message. To make this topic a little more interesting, we have changed the router configuration in the meantime. The new Router Advertisement message can be seen in Figure 4-20.

Figure 4-20. Router Advertisement

The message type for a Router Advertisement is 134. The first field that has changed is the current hop limit. It now has the value 32, the value we have configured on our router. All hosts configured with this Router Advertisement will now use a hop limit of 32 for their communication. (And yes, we have verified it; even Marvin now uses the new hop limit.) The next thing we changed is the O flag. Our router now configures all hosts on this link to use a stateful configuration server for non-address-related information. The remaining fields are the same as in Figure 4-16, shown earlier in the chapter. If the router were configured for more than one prefix, the additional prefixes would be listed consecutively with the same fields.