| (5 intermediate revisions by 2 users not shown) | |||
| Line 3: | Line 3: | ||
Common standard protocols involved in IPv4 and IPv6 automatic configuration: | Common standard protocols involved in IPv4 and IPv6 automatic configuration: | ||
* DHCPv4 protocol | * <abbr title="Dynamic Host Configuration Protocol for IPv4">DHCPv4</abbr> protocol | ||
* IPv4CP | * <abbr title="Internet Protocol Control Protocol for IPv4">IPv4CP</abbr> | ||
* IPv6 NDP router discovery | * IPv6 <abbr title="Neighbor Discovery Protocol">NDP</abbr> router discovery | ||
* DHCPv6 protocol | * <abbr title="Dynamic Host Configuration Protocol for IPv6">DHCPv6</abbr> protocol | ||
* IPv6CP | * <abbr title="IPv6 Control Protocol">IPv6CP</abbr> | ||
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 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 <abbr title="Domain Name System">DNS</abbr> server addresses. | ||
== IPv4 configuration procedure == | == IPv4 configuration procedure == | ||
| Line 16: | Line 16: | ||
* DHCP exchange | * DHCP exchange | ||
* Address configuration (from DHCP, optional fallback to IPv4LL) | * Address configuration (from DHCP, optional fallback to <abbr title="IPv4 link-local address">IPv4LL</abbr>) | ||
* DNS configuration (from DHCP) | * DNS configuration (from DHCP) | ||
* Other configuration (NTP servers, ...) | * Other configuration (<abbr title="Network Time Protocol">NTP</abbr> servers, ...) | ||
== IPv6 configuration procedure == | == IPv6 configuration procedure == | ||
| Line 24: | Line 24: | ||
Dynamic address configuration procedure: | Dynamic address configuration procedure: | ||
* IPv6LL configuration and <abbr title="Duplicate Address Detection">DAD</abbr> | * <abbr title="IPv6 link-local address">IPv6LL</abbr> configuration and <abbr title="Duplicate Address Detection">DAD</abbr> | ||
* Router discovery (solicitation and advertisement) | * Router discovery (solicitation and advertisement) | ||
* <abbr title="StateLess Address AutoConfiguration">SLAAC</abbr> | * <abbr title="StateLess Address AutoConfiguration">SLAAC</abbr> (using data from rdisc | ||
* Optional DHCP (based on router discovery) | * Optional DHCP (based on router discovery) | ||
* Stateful address configuration (with lease from DHCP) | * Stateful address configuration (with lease from DHCP) | ||
| Line 34: | Line 34: | ||
== Interface identifier == | == 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. | 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 == | == 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 | A common problem with both IPv4 and IPv6 protocols is the assignment of a stable <abbr title="DHCP Unique IDentifier">DUID</abbr>. 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: | Requirements on DUID stability: | ||
| Line 50: | Line 52: | ||
Known bugs: | Known bugs: | ||
* [https://bugzilla.redhat.com/show_bug.cgi?id=1269093 DUID isn't stable across | * [https://bugzilla.redhat.com/show_bug.cgi?id=1269093 NetworkManager: DUID isn't stable across service restarts for generated ethernet connections] | ||
* [https://bugzilla.redhat.com/show_bug.cgi?id=1154200#c25 dhclient: DHCPv4 DUID is sometimes incorrectly interpreted by servers] | |||
* [https://bugzilla.redhat.com/show_bug.cgi?id=1154200#c53 dhclient: DUID in an installed system is often not the same as in the installer] | |||
=== Sharing DUID across configuration services === | |||
NetworkManager already uses <code>/etc/machine-id</code> 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. | |||
Latest revision as of 08:50, 30 October 2015
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.