<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 18, 2016 at 1:22 PM, Bjørn Mork <span dir="ltr"><<a href="mailto:bjorn@mork.no" target="_blank">bjorn@mork.no</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hans Dedecker <<a href="mailto:dedeckeh@gmail.com">dedeckeh@gmail.com</a>> writes:<br>
> On Sun, Apr 17, 2016 at 2:07 PM, Hauke Mehrtens <<a href="mailto:hauke@hauke-m.de">hauke@hauke-m.de</a>> wrote:<br>
><br>
>> <a href="https://www.ietf.org/rfc/rfc2131.txt" rel="noreferrer" target="_blank">https://www.ietf.org/rfc/rfc2131.txt</a> says in section 3.2 part 4.:<br>
>> Note that in this case, where the client retains its network<br>
>> address locally, the client will not normally relinquish its<br>
>> lease during a graceful shutdown. Only in the case where the<br>
>> client explicitly needs to relinquish its lease, e.g., the client<br>
>> is about to be moved to a different subnet, will the client send<br>
>> a DHCPRELEASE message.<br>
>><br>
> It's a bit ambiguous to interprete (like so many statements in rfc2131 :) )<br>
> as we don't keep the IP address locally when the udhcpc client is shutdown.<br>
<br>
I don't read it as ambigious at all.<br>
<br>
RFC2131 clearly states that the client need not send DHCPRELEASE on<br>
shutdown. The exact wording is (twice - both in section 3.1 and 3.2):<br>
<br>
The client may choose to relinquish its lease on a network address<br>
by sending a DHCPRELEASE message to the server.<br>
<br>
The "may choose" is hard to interprete in any other way than being<br>
entirely optional. There is nothing ambigious about that.<br>
<br>
So the question boils down to whether automatically sending DHCPRELEASE<br>
is an advantage or not. I guess this might depend on your use case, but<br>
IMHO it is definitely not. Why would anyone want their address to<br>
change every time they reboot the system? They don't.<br></blockquote><div> As you mention this depends on the use case and has to be seen in a more broader network scope; devices in networks which snoop DHCP messages can hold mac/IP address state info. If the IP address is not being used anymore by a gateway on a wan interface they want to be informed about this by a release message so the mac/IP address state can be removed.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I understand that there might be situations where you do want to send<br>
DHCPRELEASE. But that is more suitable for an explicit command. It is<br>
not something you want to do automatically without having precise<br>
instructions to do so from the user.<br>
<br>
Please do not add this bug to the DHCP client. Thanks.<br></blockquote><div>Making it configurable via UCI and keeping the default behavior will not introduce a bug</div><div><br></div><div>Hans</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
Bjørn<br>
</font></span></blockquote></div><br></div></div>