While most routers have their addresses configured manually, hosts can be assigned addresses manually, using an assignment protocol like DHCP, or auto- matically using some sort of algorithm. There are two forms of automatic assign- ment, depending on what type of address is being formed. For addresses that are to be used only on a single link (link-local addresses), a host need only find some appropriate address not already in use on the link. For addresses that are to be used for global connectivity, however, some portion of the address must generally be managed. There are mechanisms in both IPv4 and IPv6 for link-local address autoconfiguration, whereby a host determines its address(es) largely without help.
This is called stateless address autoconfiguration (SLAAC).
6.3.1 Dynamic Configuration of IPv4 Link-Local Addresses
In cases where a host without a manually configured address attaches to a network lacking a DHCP server, IP-based communication is unable to take place unless the host somehow generates an IP address to use. [RFC3927] describes a mecha- nism whereby a host can automatically generate its own IPv4 address from the link-local range 169.254.1.1 through 169.254.254.254 using the 16-bit subnet mask 255.255.0.0 (see [RFC5735]). This method is known as dynamic link-local address configuration or Automatic Private IP Addressing (APIPA). In essence, a host selects a random address in the range to use and checks to see if that address is already in use by some other system on the subnetwork. This check is implemented using IPv4 ACD (see Chapter 4).
6.3.2 IPv6 SLAAC for Link-Local Addresses
The goal of IPv6 SLAAC is to allow nodes to automatically (and autonomously) self-assign link-local IPv6 addresses. IPv6 SLAAC is described in [RFC4862]. It
ptg999 Section 6.3 Stateless Address Autoconfiguration (SLAAC) 277
involves three major steps: obtaining a link-local address, obtaining a global address using stateless autoconfiguration, and detecting whether the link-local address is already in use on the link. Stateless autoconfiguration can be used with- out routers, in which case only link-local addresses are assigned. When routers are present, a global address is formed using a combination of the prefix advertised by a router and locally generated information. SLAAC can also be used in con- junction with DHCPv6 (or manual address assignment) to allow a host to obtain information in addition to its address (called “stateless” DHCPv6). Hosts that per- form SLAAC can be used on the same network as those configured using stateful or stateless DHCPv6. Generally, stateful DHCPv6 is used when finer control is required in assigning address to hosts, but it is expected that stateless DHCPv6 in combination with SLAAC will be the most common deployment option.
In IPv6, tentative (or optimistic) link-local addresses are selected using proce- dures specified in [RFC4291] and [RFC4941]. They apply only to multicast-capable networks and are assigned infinite preferred and valid lifetimes once established.
To form the numeric address, a unique number is appended to the well-known link-local prefix fe80::0 (of appropriate length). This is accomplished by setting the right-most N bits of the address to be equal to the (N-bit-long) number, the left-most bits equal to the 10-bit link-local prefix 1111111010, and the rest to 0. The resulting address is placed into the tentative (or optimistic) state and checked for duplicates (see the next section).
6.3.2.1 IPv6 Duplicate Address Detection (DAD)
IPv6 DAD uses ICMPv6 Neighbor Solicitation and Neighbor Advertisement mes- sages (see Chapter 8) to determine if a particular (tentative or optimistic) IPv6 address is already in use on the attached link. For purposes of this discussion, we refer only to tentative addresses, but it is understood that DAD applies to opti- mistic addresses as well. DAD is specified in [RFC4862] and is recommended to be used every time an IPv6 address is assigned to an interface manually, using autoconfiguration, or using DHCPv6. If a duplicate address is discovered, the pro- cedure causes the tentative address to not be used. If DAD succeeds, the tentative address transitions to the preferred state and can be used without restriction.
DAD is performed as follows: A node first joins the All Nodes multicast address and the Solicited-Node multicast address of the tentative address (see Chapter 9).
To check for use of an address duplicate, a node sends one or more ICMPv6 Neigh- bor Solicitation messages. The source and destination IPv6 addresses of these mes- sages are the unspecified address and Solicited-Node address of the target address being checked, respectively. The Target Address field is set to the address being checked (the tentative address). If a Neighbor Advertisement message is received in response, DAD has failed, and the address being checked is abandoned.
ptg999 Note
As a consequence of joining multicast groups, MLD messages are sent (see Chapter 9), but their transmission is delayed by a random interval according to [RFC4862] to avoid congesting the network when many nodes simultaneously join the All Hosts group (e.g., after a restoration of power). For DAD, these MLD messages are used to inform MLD-snooping switches to forward multicast traffic as necessary.
When an address has not yet successfully completed DAD, any received neighbor solicitations for it are treated in a special way, as this is indicative of some other host’s intention to use the same address. If such messages are received, they are dropped, the current tentative address is abandoned, and DAD fails.
If DAD fails, by receiving a similar neighbor solicitation from another node or a neighbor advertisement for the target address, the address is not assigned to an interface and does not become a preferred address. If the address is a link-local address being configured based on an interface identifier derived from a local MAC address, it is unlikely that the same procedure will ultimately produce a nonconflicting address, so the use of this address is abandoned and administrator input is required. If the address is based on a different form of interface identi- fier, IPv6 operations may be retried using another address based on an alternative tentative address.
6.3.2.2 IPv6 SLAAC for Global Addresses
Once a node has acquired a link-local address, it is likely to require one or more global addresses as well. Global addresses are formed using a process similar to that for link-local SLAAC but using a prefix provided by a router. Such prefixes are carried in the Prefix option of a router advertisement (see Chapter 8), and a flag indicates whether the prefix should be used in forming global addresses with SLAAC. If so, the prefix is combined with an interface identifier (e.g., the same one used in forming a link-local address if the privacy extension is not being used) to form a global address. The preferred and valid lifetimes of such addresses are also determined by information present in the Prefix option.
6.3.2.3 Example
The trace in Figure 6-23 shows the series of events an IPv6 (Windows Vista/SP1) host uses when allocating its addresses with SLAAC. The system first selects a link-local address based on the link-local prefix of fe80::/64 and a random number.
This method is designed to enhance the privacy of a user by making the address of the host system change over time [RFC4941]. The other common method involves using the bits of the MAC address in forming the link-local address. It performs DAD on this address (fe80::fd26:de93:5ab7:405a) to look for conflicts.
ptg999
279
Figure 6-23 During SLAAC, a host begins by performing DAD on the tentative link-local address it wishes to use by sending an ICMPv6 Neighbor Solicita- tion message for this address from the unspecified address.
ptg999 Figure 6-23 shows the operation of DAD, which involves the host sending an
NS to see if its selected link-local address is in use. It then quickly performs an RS to determine how to proceed (see Figure 6-24).
Figure 6-24 The ICMPv6 RS message induces a nearby router to supply configuration information such as the global network prefix in use on the attached network.
The Router Solicitation message shown in Figure 6-24 is sent to the All Rout- ers multicast address (ff02::2) using the autoconfigured link-local IPv6 address as a source address. The response is given in an RA sent to the All Systems multicast address (ff02::1), so that all attached systems can see (see Figure 6-25).
The RA shown in Figure 6-25 is sent from fe80::204:5aff:fe9f:9e80, the link- local address of the router, to the All Systems multicast address ff02::1. The Flags field in the RA, which may contain several configuration options and extensions [RFC5175], is set to 0, indicating that addresses are not “managed” on this link by DHCPv6. The Prefix option indicates that the global prefix 2001:db8::/64 is in use on the link. The prefix length of 64 is not carried but is instead defined according to [RFC4291]. The Flags field value of 0xc0 associated with the Pre- fix option indicates that the prefix is on-link (can be use in conjunction with a router) and the auto flag is set, meaning that the prefix can be used by the host to configure other addresses automatically. It also includes the Recursive DNS Server (RDNSS) option [RFC6106], which indicates that a DNS server is available at the address 2001::db8::1. The SLLAO indicates that the router’s MAC address is 00:04:5a:9f:9e:80. This information is made available for any node to populate its neighbor cache (the IPv6 equivalent of the IPv4 ARP cache; Neighbor Discovery is discussed in Chapter 8).
ptg999 Section 6.3 Stateless Address Autoconfiguration (SLAAC) 281
After an exchange of Neighbor Solicitation and Neighbor Advertisement mes- sages between the client and the router, the client performs another DAD opera- tion on the new (global) address it selects (see Figure 6-26).
The address 2001:db8::fd26:de93:5ab7:405a has been chosen by the client based on the prefix 2001::db8 carried in the router advertisement it received ear- lier. The low-order bits of this address are based on the same random number as was used to configure its link-local address. As such, the Solicited-Node multicast address ff02::1:ffb7:405a is the same for DAD for both addresses. After this address has been tested for duplication, the client allocates another address and applies DAD to it (see Figure 6-27).
Figure 6-25 An ICMPv6 RA message provides the location and availability of a default router plus the global address prefix in use on the network. It also includes the location of a DNS server and indicates whether the router sending the advertisement can also act as a Mobile IPv6 home agent (no in this case). The client may use some or all of this information in configuring its operation.
ptg999
The DAD operation in Figure 6-27 is for the address 2001:db8::9cf4:f812:816d:
5c97. This address is a temporary IPv6 address, generated using a different ran- dom number for its lower-order bits for privacy reasons. The difference between
Figure 6-26 DAD for the global address derived from the prefix 2001:db8::/64 is sent to the same Solicited-Node multicast address as the first packet.
Figure 6-27 DAD for the address 2001:db8::9cf4:f812:816d:5c97.
ptg999 Section 6.3 Stateless Address Autoconfiguration (SLAAC) 283
the two global addresses here is that the temporary address has a shorter lifetime.
Lifetimes are computed as the lower (smaller) of the following two values: the life- times included in the Prefix Information option received in the RA and a local pair of defaults. In the case of Windows Vista, the default valid lifetime is one week and the default preferred lifetime is one day. Once this message has completed, the cli- ent has performed SLAAC for its link-local address, plus two global addresses.
This is enough addressing information to perform local or global communication.
The temporary address will change periodically to help enhance privacy. In cases where privacy protection is not desired, the following command can be employed to disable this feature in Windows:
C:\> netsh interface ipv6 set privacy state=disabled
In Linux, temporary addresses can be enabled using this set of commands:
Linux# sysctl –w net.ipv6.conf.all.use_tempaddr=2 Linux# sysctl –w net.ipv6.conf.default.use_tempaddr=2
and disabled using these commands:
Linux# sysctl –w net.ipv6.conf.all.use_tempaddr=0 Linux# sysctl –w net.ipv6.conf.default.use_tempaddr=0
6.3.2.4 Stateless DHCP
We have mentioned that DHCPv6 can be used in a “stateless” mode where the DHCPv6 server does not assign addresses (or keep any per-client state) but does provide other configuration information. Stateless DHCPv6 is specified in [RFC3736] and combines SLAAC with DHCPv6. It is believed that this combi- nation is an attractive deployment option because network administrators need not be directly concerned with address pools as they have been when deploying DHCPv4.
In a stateless DHCPv6 deployment, nodes are assumed to have obtained their addresses using some method other than DHCPv6. Thus, the DHCPv6 server does not need to handle any of the address management messages specified in Table 6-1. In addition, it does not need to handle any of the options required for estab- lishing IA bindings. This simplifies the server software and server configuration considerably. The operation of relay agents is unchanged.
Stateless DHCPv6 clients use the DHCPv6 INFORMATION-REQUEST mes- sage to request information that is provided in REPLY messages from servers. The INFORMATION-REQUEST message includes an Option Request option listing
ptg999 the options about which the client wishes to know more. The INFORMATION-
REQUEST may include a Client Identifier option, which allows answers to be cus- tomized for particular clients.
To be a compliant stateless DHCPv6 server, a system must implement the fol- lowing messages: INFORMATION-REQUEST, REPLY, RELAY-FORW, and RELAY- REPL. It also must implement the following options: Option Request, Status Code, Server Identifier, Client Message, Server Message, Interface-ID. The last three are used when relay agents are involved. To be a useful stateless DHCPv6 server, several other options will likely be necessary: DNS Server, DNS Search List, and possibly SIP Servers. Other potentially useful, but not required, options include Preference, Elapsed Time, User Class, Vendor Class, Vendor-Specific Information, Client Identifier, and Authentication.
6.3.2.5 The Utility of Address Autoconfiguration
The utility of address autoconfiguration for IP is typically limited because routers that may be on the same network as the client are configured with particular IP address ranges in use that differ from the addresses a client is likely to autoconfig- ure. This is especially true for the IPv4 (APIPA) case, as the private link-local prefix 169.254/16 is very unlikely to be used by a router. Therefore, the consequence of self-assigning an IP address is that local subnet access may work, but Internet routing and name services (DNS) are likely to fail. When DNS fails, much of the common Internet “experience” fails with it. Thus, it is often more useful to have a client fail to get an IP address (which is relatively easily detected) than to allow it to obtain one that cannot really be used effectively.
Note
There are name services other than conventional DNS that may be of use for link-local addressing, including Bonjour/ZeroConf (Apple), LLMNR, and NetBIOS (Microsoft). Because these have evolved over time from different vendors, and are not established IETF standards, the exact behavior involved when mapping names to addresses in the local environment varies considerably. See Chapter 11 for more details on local alternatives to DNS.
The use of APIPA can be disabled, which prevents a system from self-assign- ing an IP address. In Windows, this is accomplished by creating the following registry key (the key is a single line but is wrapped here for illustration):
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\
IPAutoconfigurationEnabled
This REG_DWORD value may be set to 0 to disable APIPA for all network inter- faces. In Linux, the file /etc/sysconfig/network can be modified to include the following directive:
NOZEROCONF=yes
ptg999 Section 6.4 DHCP and DNS Interaction 285
This disables the use of APIPA for all network interfaces. It is also possible to disable APIPA for specific interfaces by modifying the per-interface configura- tion files (e.g., /etc/sysconfig/network-scripts/ifcfg-eth0 for the first Ethernet device).
In the case of IPv6 SLAAC, it is relatively easy to obtain a global IPv6 address, but the relationship between a name and its address is not secured, leading to a potential set of unpleasant consequences (see Chapters 11 and 18). Thus, it may still be desirable to avoid SLAAC in deployments for the time being. To disable SLAAC for IPv6 global addresses, there are two methods. First, the Router Adver- tisement messages provided by the local router can be arranged to turn off the
“auto” flag in the Prefix option (or configure it to not provide a Prefix option, as illustrated in the preceding example). In addition, a local configuration setting causes a client to avoid autoconfiguration of global addresses.
To disable SLAAC in a Linux client, the following command may be given:
Linux# sysctl –w net.ipv6.conf.all.autoconf=0
To do so on a Mac OS or FreeBSD system, at least for link-local addresses, the fol- lowing command should be used:
FreeBSD# sysctl –w net.inet6.ip6.auto_linklocal=0
And, finally, for Windows:
C:\> netsh
netsh> interface ipv6
netsh interface ipv6> set interface {ifname} managedaddress=disabled
where {ifname} should be replaced with the appropriate interface name (in this example, “Wireless Network Connection”). Note that the behavior of these configuration commands sometimes changes over time. Please check the operat- ing system documentation for the current method if these changes do not perform as expected.