[Kea-users] DHCPv6: Advertised and Assigned addresses are different

[Tomek Mrugalski]

On 15.07.2020 12:01, laaubert wrote:
> I’m currently using Kea 1.6.2  with an application acting as a DHCPv6 relay
> on behalf of the DHCPv6 clients.
> 
> I noticed that during each assignment cycle, the advertised address is not
> the same one as the actual assigned address. I don’t see any specific error
> in Kea debugs you can find below but Kea will assign a new address once it
> received the DHCP REQUEST packet. So my guess is there is something in the
> REQUEST that triggers it but I can’t figure out what exactly:
If more of what ISN'T there. Typically the clients copy IA_NA option 
from the Advertise to their Request messages. The IA_NA option sent in 
Advertise contains the address. That way the server doesn't have to keep 
state between Solicits and Requests. That's convenient, because there's 
no guarantee that the client will choose this server.

Anyway, this is a valid behavior. This was kind of assumed in RFC3315, 
but it was clarified more explicitly when RFC8415 came out. See here:
https://tools.ietf.org/html/rfc8415#section-18.3.2

    The server MAY assign different addresses and/or delegated prefixes
    to an IA than those included within the IA of the client's Request
    message.

When you think about it, your client sends a Request with IA_NA and no 
address. This means "give me an address". It could sent specific 
address, which would be interpreted as "can you give me this address?".

If you want Kea to assign the same address, try to make your client send 
the Request with an address that was offered in Advertise. Another 
option is to make a reservation for this client. Easy if you know the 
client up front, but impossible for open networks.

Note the ISC DHCP does things differently. It temporarily allocates a 
lease when sending an Advertise. Sadly, this complicates many things. 
There's no guarantee that the client will ever send a Request (may 
choose a different server or go away), so there has to be expiration of 
some sort. The server is not supposed to allocate a lease on Solicits, 
so adding a short lived lease would kind of be against
RFC. So there's a special state of a lease that's kept aside for a 
client that's expected to request it any second. That means that 
technically you can run out of addresses by receiving just Solicits.
Another problem is that when the client sends a Request without the 
address or prefix copied, then the server has to do an extra lookup.
This has measurable impact on performance.

Anyway, we've been thinking about an early allocation. The idea is to do 
full lease allocation on Solicit. It's kinda against RFCs, but it should
give a bit of a performance boost. No need to do costly lease selection
twice in case the client doesn't copy an address from Advertise to 
Request. This would be an optional knob and disabled by default.

Any thoughts on this?

Tomek