Due to the various limitations of stateless autoconfiguration, a new DHCP standard was produced to work with IPv6. The DHCPv6 RFC, submitted in July of 2003, proposes an (almost) entire rewrite of DHCPv4, complete with authentication and interoperability with stateless autoconfiguration. DHCPv6 is called ``stateful'' since there is bidirectional and (somewhat) reliable communication between the client and server.
As is similar in DHCPv4, DHCPv6 also uses UDP messages to communicate with clients and servers, claiming ports 546 and 547, respectively. Clients, instead of broadcasting, communicate with the DHCPv6 servers via reserved multicast addresses. ff02:1:2 is the link scoped address for All_DHCP_Relay_Agents_and_Servers and ff05::1:3 is the site scoped address for All_DHCP_Servers. This assumes each client has a working link-local address and has performed some address collision detection, usually DAD, prior to communicating with the DHCPv6 server.
In DHCPv4, clients are uniquely identified by their MAC address, a DHCP client identifier, or some other means. In certain environments DHCPv4 servers may randomly generate addresses for clients, not saving any identifiers. However, DHCPv6 is more stringent about such client identifiers. A DHCPv6 unique identifier (DUID) is required on the client side when negotiating options and addresses from a DHCPv6 server, and is passed to the server as a variable-length option. Being smaller than 128 octets, a DUID can be generated using a combination of the link-local address and a timestamp, a vendor-assigned unique ID based on some enterprise number, or solely from the link-local address if the client lacks stable storage.
DHCPv6 is capable of being used under two circumstances, with or without stateless autoconfiguration. If stateless autoconfiguration is already used on the link, a DHCPv6 client can be used to just obtain DHCPv6 options only, such as DNS and NTP servers. If DHCPv6 is used to obtain options, addresses, and routes, the process becomes slightly more complex, and uses link-local and well-known multicast addresses to communicate with the DHCPv6 servers.
All DHCPv6 messages are required to be either multicast or unicast. Clients send messages to All_DHCP_Relay_Agents_and_Servers and then can communicate to a specific server using unicast or continue using multicast. As in DHCPv4, the burden of retransmission is put on the client. To alleviate a possible denial of service of the DHCPv6 server in the case of a power failure where a large amount of hosts are powered up at the same time, messages from the client are delayed by a random time before being sent. All client and server messages use the same format, an 8-bit message type with a 24-bit transaction ID and a variable length of options. The transaction ID is used to synchronize server responses to client messages, and must be fairly unique to minimize security issues.
If DHCPv6 is to be used beside stateless autoconfiguration, only two messages (assuming a lossless link) are required. The messages originating from the client must use the link-local address instead of any other address obtained previously from stateless autoconfiguration. The client then sends an information request with its DUID to All_DHCP_Relay_Agents_and_Servers and gets a reply with the DHCPv6 options.
In the case where a client needs an address in addition to DHCPv6 options, four messages are required. A solicit message is sent to All_DHCP_Relay_Agents_and_Servers initially, and a DHCPv6 server should respond with an advertise message. Choosing a server, the client proceeds to send a request message, complete with a DUID and IA identifier, and the server replies with an IA (identity-association) and options. An IA contains IPv6 addresses for the client, and can be applied to exactly one interface. The client's IAID is required to be consistent across DHCPv6 client restarts.