<div dir="ltr">A Windows 8 client appears to keep the last IP in the registry in:<div><div>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{...<Network Adapter>...}\DhcpIPAddress</div></div><div><br></div><div>Although many years ago I remember having clients that remembered the last 5 or 10 IP's (in different subnets).</div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><br>-- <br>Bob Harold<br>hostmaster, UMnet, ITcom<br>Information and Technology Services (ITS)<br><a href="mailto:rharolde@umich.edu" target="_blank">rharolde@umich.edu</a><br>734-647-6524 desk<br></div></div>
<br><div class="gmail_quote">On Mon, Jun 8, 2015 at 9:11 AM, Glenn Satchell <span dir="ltr"><<a href="mailto:glenn.satchell@uniq.com.au" target="_blank">glenn.satchell@uniq.com.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
On Mon, June 8, 2015 7:29 pm, Arne Baeumler wrote:<br>
> Hi Simon,<br>
><br>
> thank you for your reply.<br>
><br>
> On 2015-06-05 15:05, Simon Hobson wrote:<br>
>> Hmm, that's a variation I don't think we've seen before ;-)<br>
>> What you are seeing is correct operation according to the RFCs - the<br>
>> server is required to keep the address stable as far as is possible, and<br>
>> that means the client can come back after an arbitrary length of time<br>
>> and as long as the address has not been re-used then the client *must*<br>
>> get the same address.<br>
><br>
> Would you please point me to the RFC you are referring to?<br>
> Can't find any requirements for the server to maintain some kind of IP<br>
> history in RFC2131.<br>
><br>
<br>
</span>I'm looking at <a href="https://www.ietf.org/rfc/rfc2131.txt" target="_blank">https://www.ietf.org/rfc/rfc2131.txt</a>, there are several<br>
references to this feature within the document. Section 4.3.1 is the<br>
clearest on this, even though it says it "SHOULD" rather than "MUST" be<br>
done this way.<br>
<br>
1.6 Design goals<br>
<br>
      o Retain DHCP client configuration across DHCP client reboot.  A<br>
        DHCP client should, whenever possible, be assigned the same<br>
        configuration parameters (e.g., network address) in response<br>
        to each request,<br>
<br>
      o Retain DHCP client configuration across server reboots, and,<br>
        whenever possible, a DHCP client should be assigned the same<br>
        configuration parameters despite restarts of the DHCP mechanism,<br>
<br>
2.2 Dynamic allocation of network addresses<br>
<br>
   The<br>
   allocation mechanism (the collection of DHCP servers) guarantees not<br>
   to reallocate that address within the requested time and attempts to<br>
   return the same network address each time the client requests an<br>
   address.<br>
<br>
4.3.1 DHCPDISCOVER message<br>
<br>
   When a server receives a DHCPDISCOVER message from a client, the<br>
   server chooses a network address for the requesting client.  If no<br>
   address is available, the server may choose to report the problem to<br>
   the system administrator. If an address is available, the new address<br>
   SHOULD be chosen as follows:<br>
<br>
      o The client's current address as recorded in the client's current<br>
        binding, ELSE<br>
<br>
      o The client's previous address as recorded in the client's (now<br>
        expired or released) binding, if that address is in the server's<br>
        pool of available addresses and not already allocated, ELSE<br>
<br>
      o The address requested in the 'Requested IP Address' option, if that<br>
        address is valid and not already allocated, ELSE<br>
<br>
      o A new address allocated from the server's pool of available<br>
        addresses; the address is selected based on the subnet from which<br>
        the message was received (if 'giaddr' is 0) or on the address of<br>
        the relay agent that forwarded the message ('giaddr' when not 0).<br>
<br>
I hope this helps.<br>
<br>
I realise this doesn't help with your original question :) In terms of<br>
privacy there is an IPV6 feature that assigns a new IP address each day.<br>
This is part of the client functionality defined in RFC 4941 "Privacy<br>
Extensions for Stateless Address Autoconfiguration in IPv6" but doesn't<br>
help with your current IPv4 issue.<br>
<br>
regards,<br>
-glenn<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
dhcp-users mailing list<br>
<a href="mailto:dhcp-users@lists.isc.org">dhcp-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/dhcp-users" target="_blank">https://lists.isc.org/mailman/listinfo/dhcp-users</a><br>
</div></div></blockquote></div><br></div>