becarpenter-book6/2. IPv6 Basic Technology/Auto-configuration.md

## Auto-configuration

One design goal for IPv6 was that it could be used "out of the box" in an isolated network (referred to in the early 1990s as a "dentist's office" network). Today, of course, this is a less likely scenario if taken literally, but all the same, isolated network segments do indeed arise. For this scenario, IPv6 has an elegant solution: when an IPv6 node first detects an active network interface, it will automatically configure a link local address on that interface, such as ```fe80::a1b3:6d7a:3f65:dd13```. The interface identifier is a pseudo-random 64-bit number, normally fixed for a given interface. (In legacy implementations, it may be derived from the interface's IEEE MAC address, but this method is now deprecated.)

Link local addresses are usable only for operations on the same link. The most common case is for traffic between a host and its first-hop router. Another likely case is traffic between a host and local printer. There is nothing to stop them being used for any other type of traffic between local nodes, but they are useless *off* the given link and should definitely never appear in DNS.

Further details are given in [RFC4862](https://www.rfc-editor.org/info/rfc4862). Also, we have skipped an important issue that will be discussed later: duplicate address detection.

When a node has configured a link local address, it then continues a process known as SLAAC (pronounced 'slack') -- StateLess Address AutoConfiguration -- in order to configure at least one routeable address \[[RFC4862](https://www.rfc-editor.org/info/rfc4862)]. Naturally, this can only happen on a link with an IPv6 router connected to it. If there is no such router, only link local IPv6 operation is possible. The first step, therefore, is router discovery. IPv6 routers supporting SLAAC **MUST** listen to the link local all-routers multicast address, defined as ```ff02::2```. The new node will send a Router Solicitation ICMPv6 message to that address. Each SLAAC router will respond with a Router Advertisement (RA) ICMPv6 message to the new node at its link local address. (RA messages are also sent periodically to ```ff02::1```, the link local all-nodes multicast address. This is important to refresh information in all nodes.)

RA messages are quite complex and are defined in detail in [RFC4861](https://www.rfc-editor.org/info/rfc4861). They contain one Prefix Information Option (PIO) for each routeable IPv6 prefix that they can handle. A PIO naturally contains the prefix itself (theoretically of any length; in practice normally 64 bits), some lifetime information, and two flag bits known as L and A. L=1 signifies that the prefix is indeed supported on the link concerned -- this is needed for on-link determination as mentioned in the previous section. A=1 signifies that the prefix may indeed be used for stateless address auto-configuration. A PIO with A=L=0 signifies only that the router can act as the first hop router for the prefix concerned \[[RFC8028](https://www.rfc-editor.org/info/rfc8028)]. For auto-configuration, when a node receives a typical RA/PIO with A=L=1, it configures an address for itself, and also records the fact the the announced prefix is on-link. For example, if the prefix announced in the PIO is ```2001:db8:4006:80b::/64```, and the pre-defined interface identifier for the interface concerned is ```a1b3:6d7a:3f65:dd13```, the node will configure the interface's new address as ```2001:db8:4006:80b:a1b3:6d7a:3f65:dd13```.

As mentioned in [2. Addresses](../2.%20IPv6%20Basic%20Technology/Addresses.md), the interface identifier should be pseudo-random to enhance privacy, except in the case of public servers (thus a certain large company uses identifiers like ```face:b00c:0:25de```). For practical reasons, stable identifiers are often preferred \[[RFC8064](https://www.rfc-editor.org/info/rfc8064)]
but privacy is better protected by temporary identifiers \[[RFC8981](https://www.rfc-editor.org/info/rfc8981)].

An important step in configuring either a link local address or a routeable address is *Duplicate Address Detection* (DAD). Before a new address is safe to use, the node first sends out a Neighbor Solicitation for this address, as described in the previous section. If it receives a Neighbor Advertisement in reply, there's a duplicate, and the new address must be abandoned. The Neighbor Solicitations sent for DAD add to the multicast scaling issues mentioned above.

It's worth underlining a couple of IPv6 features here:

1. Several subnet prefixes can be active on the same physical link. Therefore, a host may receive several different PIO messages and configure several routeable addresses per interface. Also, for example when using temporary addresses \[[RFC8981](https://www.rfc-editor.org/info/rfc8981)], a host may have several simultaneous addresses *under the same prefix*. This is not an error; it's normal IPv6 behavior.

2. Both GUA and ULA addresses (see [2. Addresses](../2.%20IPv6%20Basic%20Technology/Addresses.md)) are routeable, even though the ULA is only routeable within an administrative boundary. Having both a GUA and a ULA simultaneously is also normal IPv6 behavior.

All IPv6 nodes **MUST** support SLAAC as described above, in case they find themselves on a network where it is the only method of acquiring addresses. However, some network operators prefer to manage addressing using DHCPv6, as discussed in the next section. There is a global flag for this in the RA message format known as the M bit (see [RFC4861](https://www.rfc-editor.org/info/rfc4861) for details). If M=1, DHCPv6 is in use for address assignment. However, PIOs are still needed to allow on-link determination, and link-local addresses are still needed.

*More details*: This section and the previous one have summarized a complex topic. Apart from the basic specifications [RFC4861](https://www.rfc-editor.org/info/rfc4861) and [RFC4862](https://www.rfc-editor.org/info/rfc4862), many other RFCs exist on this topic, including for example:

- Enhanced Duplicate Address Detection, [RFC7527](https://www.rfc-editor.org/info/rfc7527)

- IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes, [RFC5942](https://www.rfc-editor.org/info/rfc5942)

The numerous options allowed in RA messages, and the other ICMPv6 messages used for address resolution and SLAAC, are documented in IANA's [IPv6 Neighbor Discovery Option Formats registry](https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-5).

A simple network can operate with SLAAC as the only way to configure host IPv6 connections. DNS parameters can be configured using RA options (Recursive DNS Server Option and DNS Search List Option) \[[RFC8106](https://www.rfc-editor.org/info/rfc8106)]. 

However, as noted in the previous section, the dependency of neighbor discovery and SLAAC on link-layer multicast does not scale well, particularly on wireless networks. Also, the ability of SLAAC to assign multiple addresses per host, especially dynamic temporary addresses \[[RFC8981](https://www.rfc-editor.org/info/rfc8981)], can create scaling problems for routers. 

When preferred by an operator, managed configuration, especially for large networks, can be achieved using DHCPv6, as described in the next section.

<!-- Link lines generated automatically; do not delete -->
### [<ins>Previous</ins>](Address%20resolution.md) [<ins>Next</ins>](Managed%20configuration.md) [<ins>Chapter Contents</ins>](2.%20IPv6%20Basic%20Technology.md)