From Wikipedia, the free encyclopedia
Jump to navigation Jump to search

The Dynamic Host Configuration Protocol version 6 (DHCPv6) is a network protocol for configuring Internet Protocol version 6 (IPv6) hosts with IP addresses, IP prefixes and other configuration data required to operate in an IPv6 network. It is the IPv6 equivalent of the Dynamic Host Configuration Protocol for IPv4.

IPv6 hosts may automatically generate IP addresses internally using stateless address autoconfiguration (SLAAC), or they may be assigned configuration data with DHCPv6.

IPv6 hosts that use stateless autoconfiguration may require information other than an IP address or route. DHCPv6 can be used to acquire this information, even though it is not being used to configure IP addresses. DHCPv6 is not necessary for configuring hosts with the addresses of Domain Name System (DNS) servers, because they can be configured using Neighbor Discovery Protocol, which is also the mechanism for stateless autoconfiguration.[1]

Many IPv6 routers, such as routers for residential networks, must be configured automatically with no operator intervention. Such routers require not only an IPv6 address for use in communicating with upstream routers, but also an IPv6 prefix for use in configuring devices on the downstream side of the router. DHCPv6 prefix delegation provides a mechanism for configuring such routers.


Port numbers[edit]

DHCPv6 uses UDP port number 546 for clients and port number 547 for servers.


DHCP Unique Identifier[edit]

The DHCP Unique Identifier (DUID) is used by a client to get an IP address from a DHCPv6 server. It has a 2-byte DUID type field, and a variable-length identifier field up to 128 bytes. Its actual length depends on its type. The server compares the DUID with its database and delivers configuration data (address, lease times, DNS servers, etc.) to the client. The first 16 bits of a DUID contain the DUID type, of which there are four types. The meaning of the remaining DUID depends on the type.

Four types are identified in RFC 8415:

  1. Link-layer address plus time (DUID-LLT)
  2. Vendor-assigned unique ID based on Enterprise Number (DUID-EN)
  3. Link-layer address (DUID-LL)

RFC 6939 - Client Link-Layer Address Option[edit]

Due to the fact that it is difficult to manage multiple identifiers in a dual-stack environment, and the fact that DUID's are simply not optimal for some situations, RFC 6939 was released giving a way to identify a host based on its MAC address. It defines a way for a DHCPv6 relay to pass that information to a DHCPv6 server. This option on DHCPv6 relays is not yet widely supported but some Cisco and Brocade switches support this option.


In this example, without rapid-commit present, the server's link-local address is fe80::0011:22ff:fe33:5566 and the client's link-local address is fe80::aabb:ccff:fedd:eeff.

  • DHCPv6 client sends a Solicit from [fe80::aabb:ccff:fedd:eeff]:546 for [ff02::1:2]:547.
  • DHCPv6 server replies with an Advertise from [fe80::0011:22ff:fe33:5566]:547 for [fe80::aabb:ccff:fedd:eeff]:546.
  • DHCPv6 client replies with a Request from [fe80::aabb:ccff:fedd:eeff]:546 for [ff02::1:2]:547. (Client messages are sent to the multicast address, per section 14 of RFC 8415.)
  • DHCPv6 server finishes with a Reply from [fe80::0011:22ff:fe33:5566]:547 for [fe80::aabb:ccff:fedd:eeff]:546.


Lorenzo Colitti of Google has explained why DHCPv6 has not been implemented in Android.[2][3][4]

I think that that wide deployment of one-address-per-device IPv6 might actually do more harm than good, and I expect that many operators who are going to require stateful DHCPv6 addressing are going to use it for one-address-per-device IPv6. [...] [S]upporting DHCPv6-only networks will eventually force OS manufacturers to implement IPv6 NAT. This is because there are many features inside a mobile OS that require multiple IP addresses. One example is 464xlat. Another example is tethering. [...] In IPv4 we use NAT for all that, and that's unavoidable due to lack of IPv4 space. That reason does not apply in IPv6 though. With SLAAC or DHCPv6 PD, these functions can use their own IPv6 addresses. With stateful DHCPv6 addressing, we're back to using NAT again. That means application flakiness, battery impact due to NAT keepalives, and so on. It also means that things that don't work behind NAT (e.g., 464xlat, which requires its own IPv6 address) cannot be made to work at all. [...] If there were consensus that delegating a prefix of sufficient size via DHCPv6 PD of a sufficient size is an acceptable substitute for stateful IPv6 addressing in the environments that currently insist on stateful DHCPv6 addressing, then it would make sense to implement it. In that scenario, Android would still not implement DHCPv6 NA, but it would implement DHCPv6 PD.

— Lorenzo Colitti, "Android (lack of) support for DHCPv6", NANOG mailing list (June 2015)

IETF standards[edit]

  • RFC 3319, "Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers"
  • RFC 3646, "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"
  • RFC 4704, "The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option"
  • RFC 5007, "DHCPv6 Leasequery"
  • RFC 6221, "Lightweight DHCPv6 Relay Agent" (LDRA) - Updates RFC 3315, Errata
  • RFC 6355, "Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID)"
  • RFC 6939, "Client Link-Layer Address Option in DHCPv6"
  • RFC 8415, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" - Obsoletes RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083, RFC 7283, RFC 7550.

See also[edit]


External links[edit]