<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 7 Aug 2017, at 07:34, Ola Thoresen <<a href="mailto:ola@nlogic.no" class="">ola@nlogic.no</a>> wrote:</div><div class=""><div class=""><div style="font-family:Calibri, Arial, Helvetica, sans-serif; font-size:12.0pt; line-height:1.3; color:#0F77C2" class="">
<br class="">
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.
<br class="">
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.
<br class="">
<br class="">
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.
<br class="">
The client should probably send a release both for v4 and v6 at the same time. <br class="">
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.
<br class=""></div></div></div></blockquote><div><br class=""></div><div><br class=""></div>Yes, option 5 might be “2+4”. In options 2 & 5 to avoid a change in service level for IPv4 the DHCP server would also need to remember the IPv4 lease for a period long enough to keep the address the same after the Release followed shortly afterwards by a Discover. That is a configuration option at my DHCP server. The IPv4 pools, unlike the large IPv6 prefix pools, are run pretty hot close to capacity to maximise the v4 pool utilisation. </div><div><br class=""></div><div>Ross </div><br class=""></body></html>