Prefix Delegation
One of the many benefits of IPv6 that with the vast address space, end-to-end connectivity is possible. There is no need for techniques like NAT. However, to fully unleash this potential for an ISP, that promise means not only to give a customer a unique address but a unique network. That is what the prefix delegation feature has been designed for.
The prefix delegation feature on the packet level is quite simple. A client willing to get a prefix is sending an Identity Association for Prefix Delegation Option.
However, the implementation among different software and hardware vendors varies. In the easy case, a client is sending one packet. This packet has an option for Identity Association for Non-temporary Addresses and the Identity Association for Prefix Delegation Option.
But, there are some other vendors where it seems like prefix delegation is an optional feature. These vendors are sending not one but two packets. Even the timing is not predictable. In some cases, the packet containing the Identity Association for Non-temporary Addresses is sent first. Sometimes the packet containing the Identity Association for Prefix Delegation Option is the first packet processed by DaAPI. Yet, the sequence matters for DaAPI's implementation of the prefix delegation feature explained in the next section.
DaAPI is not a general purpose DHCPv6 server. Some scenarios shorten the possibilities offered by the DHCPv6 RFC 8415. The prefix delegation feature is one example of this behavior.
Generally spoken, a client doesn't need to have a global unique unicast address to use prefix delegation. A local link address is enough to communicate with the next router as long as this router is aware of the connection binding the link-local address and the prefix.
DaAPI was constructed to be beneficial for (small) ISPs. The prefix delegation configuration is part of a scope. Furthermore, the actually assigned prefix is always bound to a lease. So, a client needs to request an address before it can request a prefix. A particular case is when an incoming packet has both a request for an address and prefix. In this situation, a new lease with a prefix is created.
There are use cases where this behavior seems odd. You could use stateless autoconfiguration to obtain an address and then prefix delegation to request a subnet. While sees behavior is okay with the standard. ISPs operate in sometimes highly regulated space. Often, they need to keep track of used IP addresses. Allowing a customer to receive an address by stateless autoconfiguration could violate this regulation. It could also be possible to use the local link address on the link and use DHCP prefix delegation to request a network. Again, this behavior is excellent from the standard point of view. However, there are some drawbacks. Mostly it is the implementation of DHCPv6 and IPv6 in general at the CPE level.
If clients send not one but two packets, one for an address request and one for a prefix request, the response flow gets a little bit more complicated.
There would be no issue if packets arrived within the right sequence: address request before prefix request. Upon the arrival of the address request, a lease with only an address is created. A reply is sent back. When the prefix request is processed, the prefix is added to the lease, and a response is sent back.
To prevent some messy situations, DaAPI has a "delay system" integrated when the sequence is reversed. If the Scope that receives a packet requesting only a prefix and a fitting lease hasn't been created yet, the packet is delayed for around 1.5 seconds. If a lease is formed in the meantime, a proper answer is sent back. If not, no response is sent. In case the client is sending more requests in this period - what they usually do because of their retransmit timers - those packets are delayed as well. Though the client may end up with as many identical responses as they have sent, luckily, this isn't a problem for a client.