by François Donzé, HP

Since 1993 the Dynamic Host Configuration Protocol (DHCP) [1] has allowed systems to obtain an IPv4 address as well as other information such as the default router or Domain Name System (DNS) server. A similar protocol called DHCPv6 [2] has been published for IPv6, the next version of the IP protocol. However, IPv6 also has a stateless autoconfiguration protocol [3], which has no equivalent in IPv4.

DHCP and DHCPv6 are known as stateful protocols because they maintain tables within dedicated servers. However, the stateless autoconfiguration protocol does not need any server or relay because there is no state to maintain.

This article explains the IPv6 stateless autoconfiguration mechanism and depicts its different phases.

Scope of IPv6 Addresses
Every IPv6 system (other than routers) is able to build its own unicast global address. A unicast address refers to a unique interface. A packet sent to such an address is treated by the corresponding interface—and only by this interface. This type of address is directly opposed to the multicast address type that designates a group of interfaces. Most of this article deals with unicast addresses. For simplicity, we will omit the unicast qualifier when there is no ambiguity.

Address types have well-defined destination scopes: global, site-local and link-local. Packets with a link-local destination must stay on the link where they have been generated. Routers that could forward them to other links are not allowed to do so because there has been no verification of uniqueness outside the context of the origin link.

Similarly, border-site routers cannot forward packets containing site-local addresses to other sites or other organizations. The IETF is currently working on a way to remove or replace site-local addresses. Hence, this article will refrain from any other reference to this address type. Finally, a global address has an unlimited scope on the worldwide Internet. In other words, packets with global source and destination addresses are routed to their target destination by the routers on the Internet. A fundamental feature of IPv6 is that all Network Interface Cards (NICs) can be associated with several addresses.

At minimum, a NIC is associated with a single link-local address. But in the most common case a NIC is assigned a link-local and at least one global address. The following command displays the configuration of network interface eth1 on a Red Hat system. This interface is associated with two IPv6 addresses. One of them starts with fe80:: and the other with 3ffe:. The scope of the first one is the link and the second has a global scope.

root# ip address list eth1
3: eth0: <broadcast,multicast,up mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:0c:29:c2:52:ff brd ff:ff:ff:ff:ff:ff
inet6 fe80::20c:29ff:fec2:52ff/10 scope link
inet6 3ffe:1200:4260:f:20c:29ff:fec2:52ff/64 scope global

Creation of the Link-Local Address
An IPv6 address is 128 bits long. It has two parts: a subnet prefix representing the network to which the interface is connected and a local identifier, sometimes called token. In the simple case of an Ethernet medium, this identifier is usually derived from the EUI-48 Media Access Control (MAC) address using an algorithm described later in this article. The subnet prefix is a fixed 64-bit length for all current definitions. Because IPv4 manual configuration is a well-known pain, one could hardly imagine manipulating IPv6 addresses that are four times longer. Moreover, a DHCP server is not always necessary or desired; in the case of a remote control finding the DVD player, a DHCP environment is not always suitable.

Because the prefix length is fixed and well-known, during the initialization phase of IPv6 NICs, the system builds automatically a link-local address. After a uniqueness verification, this system can communicate with other IPv6 hosts on that link without any other manual operation.

For a system connected to an Ethernet link, the build and the validation of the link-local address is the following:

1.	An identifier is generated, supposedly unique on the link.
2.	A tentative address is built.
3.	The uniqueness of this address on the link is verified.
4.	If unique, the address from phase 2 is assigned to the interface. If not unique, a manual operation is necessary.

Although a local policy can decide to use a specific token, the most common method to obtain a unique identifier on an Ethernet link is by using the EUI-48 MAC address and applying the modified IEEE EUI-64 standard algorithm. A MAC address (IEEE 802) is 48 bits long. The space for the local identifier in an IPv6 address is 64 bits. The EUI-64 standard explains how to stretch IEEE 802 addresses from 48 to 64 bits, by inserting the 16 bits 0xFFFE at the 24th bit of the IEEE 802.

By doing so, transforming MAC address 00-0C-29-C2-52-FF using the EUI-64 standards leads to 00-0C-29-FF-FE-C2-52-FF. Using IPv6 notation, we get 000C:29FF:FEC2:52FF. Recall that the notation of IPv6 addresses requires 16-bit pieces to be separated by the character ":". Then, it is necessary (RFC 3513) to invert the universal bit ("u" bit) in the 6th position of the first octet. Thus the result is: 020c:29ff:fec2:52ff.

Universal uniqueness of IEEE 802 and EUI-64 is given by a "u" bit set to 0. This global uniqueness is assured by IEEE, which delivers those addresses for the entire planet. Inverting the "u" bit allows ignoring it for short values in the manual configuration case, as explained in paragraph 2.5.1 of RFC 3513 [4].

The second phase of creating automatically a link-local address is to prepend the well-known prefix fe80::/64 to the identifier resulting from phase one. In our case we obtain fe80::20c:29ff:fec2:52ff. This address is associated with the interface and tagged "tentative." Before final association, it is necessary to verify its uniqueness on the link. The probability of having a duplicate address on the same link is not null, because it is recognized that some vendors have shipped batches of cards with the same MAC addresses.

This is the goal of the third phase, called Duplicate Address Detection (DAD). The system sends ICMPv6 packets on the link where this detection has to occur. Those packets contain Neighbor Solicitation messages. Their source address is the undefined address "::" and the target address is the tentative address. A node already using this tentative address replies with a Neighbor Advertisement message. In that case, the address cannot be assigned to the interface. If there is no response, it is assumed that the address is unique and can be assigned to the interface.

We are reaching the last step of the automatic generation of a link-local address. This phase removes the "tentative" tag and formally assigns the address to the network interface. The system can now communicate with its neighbors on the link.

Global Prefixes
In order to exchange information with arbitrary systems on the global Internet, it is necessary to obtain a global prefix. Usually (but not necessarily), the identifier built during the first step of the automatic link-local autoconfiguration process is appended to this global prefix.

However, before assigning this global address, the system verifies again that no duplicate address exists on the link. DAD is performed for all addresses before they are assigned to an interface, because uniqueness in one prefix does not automatically assure uniqueness in any other available prefixes.

Generally, global prefixes are distributed to the companies or to end users by Internet Service Providers (ISPs).

Random Identifiers
The EUI-48-to-EUI-64 transform process is attractive because it is simple to implement. However, it generates a privacy problem. Global unicast as well as link-local addresses may be built with an identifier derived from the MAC address. A Website tracking where a node frequently attaches can collect private information such as the time spent by employees in the enterprise or at home.

Because a MAC address follows the interface it is attached to, the identifier of an IPv6 address does not change with the physical location of the Internet connection. Hence it is possible to trace the movements of a portable laptop or Personal Digital Assistant (PDA) or other mobile IPv6 device.

RFC 3041 [5] allows the generation of a random identifier with a limited lifetime. Because IPv6 architecture permits multiple suffixes per interface, a single network interface is assigned two global addresses, one derived from the MAC address and one from a random identifier. A typical policy for use of these two addresses would be to keep the MAC-derived global address for inbound connections and the random address for outbound connections. A reason for not using it for inbound connections is the need to update the DNS just as frequently as it is changes.

Such a system, with two different global addresses—one of which changes regularly—becomes very difficult to trace.

By default, Microsoft enables this feature on Windows XP and Windows Server 2003. The random-identifier-based global addresses of Microsoft systems have the address type "temporary." EUI-64 global addresses have type "public." Those types as well as other information can be displayed in a cmd.exe DOS-box with the command line:
netsh interface ipv6 show address

IPv6 Routers
By definition, a router is a node that forwards IP packets not explicitly addressed to it. IPv6 routers are certainly compliant with this definition but, in addition, they regularly advertise information on the links to which they are connected—1provided they are configured to do so. These advertisements are Internet Control Message Protocol Version 6 (ICMPv6) Router Advertisement (RA) messages, sent to the multicast group ff02::1. All the systems on a link must belong to this group, and nodes configured for autoconfiguration, among other things, analyze the option(s) of those messages. They might contain any routing prefix(es) for this segment.

Router Solicitation
Upon reception of one of those RA messages and according to local algorithm policy, an autoconfiguring node not already configured with the corresponding global address will prepend the advertised prefix to the unique identifier built previously.

However, the advertisement frequency, which is usually about ten seconds or more, may seem too long for the end user. In order to reduce this potential wait time, nodes can send Router Solicitation (RS) messages to all the routers on the link. Nodes that have not configured an address yet use the unspecified address "::". In response, the routers must answer immediately with a RA message containing a global prefix. This router solicitation corresponds to ICMPv6 messages of type RS, sent to the all-router multicast group: ff02::2. All routers on the link must join this group.

Thus, a node soliciting on-link routers in such a way is able to extract a prefix and build its global address. Note that this method using an advertised prefix is possible only for end nodes. Today IPv6 routers are usually manually configured. The reason is obvious: a stateless automatic configuration requires the advertisement of a prefix. This prefix is sent by a router. The router sending the prefix must be fully configured to do so. The easiest way to break this seemingly unsolvable problem is to manually configure IPv6 routers. However, some automatic methods are being developed [6].

Conclusion
Stateless address autoconfiguration is a new concept with IPv6. It gives an intermediate alternative between a purely manual configuration and stateful autoconfiguration. In addition to ease of use with no dedicated server or relay, this mechanism removes problems that have not been discussed here, such as the mismatch between the DCHP server and the router (prefix topology) or the IPv4 need to readdress subnets that have outgrown their prefix. Moreover, automatic renumbering (prefix change) is also possible on nodes using stateless autoconfiguration.

References
[1] Droms, R., "Dynamic Host Configuration Protocol," RFC 1531, October 1993.

[2] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., Carney, M., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)," RFC 3315, July 2003.

[3] Thomson, S., Narten, T., "IPv6 Stateless Address Autoconfiguration," RFC 2462, December 1998.

[4] Hinden, R., Deering, S., "Internet Protocol Version 6 (IPv6) Addressing Architecture," RFC 3513, April 2003.

[5] Narten, T., Draves, R., "Privacy Extensions for Stateless Address Autoconfiguration in IPv6," RFC 3041, January 2001.

FRANÇOIS DONZÉ studied at the University of Utah in Salt Lake City. In 1989 he joined Digital Equipment Corporation as a UNIX and network teacher. He is now a technical consultant at HP, based in Sophia-Antipolis, France, promoting IPv6 and other leading-edge technologies. The author of several internal articles, he also publishes in French magazines. E-mail: francois.donze@hp.com