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
_______________________________________________
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
Kea-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-users
