Configuration and address leases

A host needs an address and related parameters to participate in IP communication. DHCP centralizes configuration; dynamic allocation assigns a lease that the client must renew for continued use.

RFC 2131 also distinguishes automatic and administrator-determined allocation. DHCP therefore does not imply a randomly changed address on every connection; assignment policy remains deployment-specific.

References: [1]

Discovery, selection and confirmation

An initially configuring IPv4 client typically sends DHCPDISCOVER, servers can return DHCPOFFER, and the client requests its selection with DHCPREQUEST before a DHCPACK confirms it. Failure and rejection have their own handling.

Lease records track assignments over time. Renewal and release continue that lifecycle; receiving one reply does not confer permanent ownership of an address.

References: [1]

Configuration beyond an address

Options can provide a subnet mask, routers and DNS servers, which other mechanisms then use. Receiving an address alone proves neither external reachability nor application-level authorization.

DHCPv6 has separate messages and identity-association rules and can include prefix delegation. Dual-stack configuration must identify its protocol version and configuration source rather than transplanting DHCPv4 fields directly.

IPv6 address configuration must be separated from default-router discovery. DHCPv6 can supply addresses, delegated prefixes or stateless parameters, while Neighbor Discovery Router Advertisements maintain the host’s default-router information. RFC 4861 uses the advertisement source and Router Lifetime to add, refresh or remove entries. Receiving DHCPv6 configuration does not replace checking Router Advertisements and actual routes, and DHCPv4’s router option cannot simply be transplanted into that flow.

References: [2] [3] [4] [5]