Automatic configuration overview
Common standard protocols involved in IPv4 and IPv6 automatic configuration:
- DHCPv4 protocol
- IPv4CP
- IPv6 NDP router discovery
- DHCPv6 protocol
- IPv6CP
IPv4 and IPv6 configuration typically occurs simultaneously but separately. The two streams of configuration are then combined, especially those parameters that are used together for both protocols like recursive DNS server addresses.
IPv4 configuration procedure
Dynamic configuration procedure:
- DHCP exchange
- Address configuration (from DHCP, optional fallback to IPv4LL)
- DNS configuration (from DHCP)
- Other configuration (NTP servers, ...)
IPv6 configuration procedure
Dynamic address configuration procedure:
- IPv6LL configuration and DAD
- Router discovery (solicitation and advertisement)
- SLAAC (using data from rdisc
- Optional DHCP (based on router discovery)
- Stateful address configuration (with lease from DHCP)
- DNS configuration (from rdisc and DHCP)
- Other configuration (NTP servers, ...)
Interface identifier
Link-local IPv6 addresses and SLAAC addresses are built using an interface identifier. The interface identifier can be build from the MAC address (the classic way), using original temporary addresses (privacy extensions) or using stable private addresses. Most often a single interface identifier is used to generate all client-generated IPv6 addresses, sometimes there are different identifiers for link-local and global addresses.
Addresses and their interface identifiers should at least be stable during a single physical connection. Temporary addresses are an exception and as such causes problems to long running connections.
DUID assignment and stability
A common problem with both IPv4 and IPv6 protocols is the assignment of a stable DUID. In theory, DUID was expected to be a fixed hardware parameter built into the hardware host. In practice DUID is most often just a number generated by software.
Requirements on DUID stability:
- DUID must be stable during a single run of a system for a single configuration service
- DUID should be stable across full reboots
- DUID would better be shared across all configuration services and DHCP clients
(TODO: Revise the requirements above and back them up with some sources or use cases.)
Known bugs:
- NetworkManager: DUID isn't stable across service restarts for generated ethernet connections
- dhclient: DHCPv4 DUID is sometimes incorrectly interpreted by servers
- dhclient: DUID in an installed system is often not the same as in the installer
Sharing DUID across configuration services
NetworkManager already uses /etc/machine-id to generate the DUID. Other services typically don't use any system wide identifier and most of them generate their own DUID using the current time at the time of DUID generation. It would be nice if all services could use a common DUID.
Rationale: When the administrator switches from one configuration service to another or chooses to experiment with a DHCP client directly, the system should present itself to the DHCP server using the same identification.