(Sorry for top posting, this client is a bit stupid)
Technically, the server is correct in that after a "release" is received, it is
free to assign the address to another client, and as such, the client should
not expect to receive the same address on the next assignment.
However, following the principle of least surprise, I agree that the user
probably expects to receive the same address, especially if they are just
changing some settings on the wan interface.
If you are free to change both server and client behavior, I believe a
combination of 2 and 4 is probably the "most correct" solution.
The client should probably send a release both for v4 and v6 at the same time.
But on the other hand, it would be nice if the server would remember the
previous lease, at least for a while, and reassign it to the client if another
request comes in within a reasonable time.
The last part should be configurable on the server side, as there are scenarios
where you want your clients to not have this kind of semi static assignment.
Also, the server should obviously be allowed to assign a cached lease to a
different client if the pool is otherwise empty.
Fra: Ross Chandler <r...@eircom.net>
Sendt: 7. aug. 2017 00:34
Til: IPv6 operators forum
Emne: DHCP versus DHCPv6 Release behaviour
The choices seem to be
1. Do nothing and accept dynamic IPv6 delegated prefixes changing more often
than the IPv4 address
2. Make the DHCP client send Releases when DHCPv6 sends them
3. Make the DHCPv6 client not send Releases under the same conditions DHCP
doesn’t send them
4. Remember the DHCPv6 lease for some duration after a Release comes in so that
it may be given out again