(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. Rgds Ola (T) ________________________________ 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
