randomly(!) assign ip's from dynamic address range

[Bob Harold]

A Windows 8 client appears to keep the last IP in the registry in:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{...<Network
Adapter>...}\DhcpIPAddress

Although many years ago I remember having clients that remembered the last
5 or 10 IP's (in different subnets).



-- 
Bob Harold
hostmaster, UMnet, ITcom
Information and Technology Services (ITS)
rharolde at umich.edu
734-647-6524 desk

On Mon, Jun 8, 2015 at 9:11 AM, Glenn Satchell <glenn.satchell at uniq.com.au>
wrote:

>
> On Mon, June 8, 2015 7:29 pm, Arne Baeumler wrote:
> > Hi Simon,
> >
> > thank you for your reply.
> >
> > On 2015-06-05 15:05, Simon Hobson wrote:
> >> Hmm, that's a variation I don't think we've seen before ;-)
> >> What you are seeing is correct operation according to the RFCs - the
> >> server is required to keep the address stable as far as is possible, and
> >> that means the client can come back after an arbitrary length of time
> >> and as long as the address has not been re-used then the client *must*
> >> get the same address.
> >
> > Would you please point me to the RFC you are referring to?
> > Can't find any requirements for the server to maintain some kind of IP
> > history in RFC2131.
> >
>
> I'm looking at https://www.ietf.org/rfc/rfc2131.txt, there are several
> references to this feature within the document. Section 4.3.1 is the
> clearest on this, even though it says it "SHOULD" rather than "MUST" be
> done this way.
>
> 1.6 Design goals
>
>       o Retain DHCP client configuration across DHCP client reboot.  A
>         DHCP client should, whenever possible, be assigned the same
>         configuration parameters (e.g., network address) in response
>         to each request,
>
>       o Retain DHCP client configuration across server reboots, and,
>         whenever possible, a DHCP client should be assigned the same
>         configuration parameters despite restarts of the DHCP mechanism,
>
> 2.2 Dynamic allocation of network addresses
>
>    The
>    allocation mechanism (the collection of DHCP servers) guarantees not
>    to reallocate that address within the requested time and attempts to
>    return the same network address each time the client requests an
>    address.
>
> 4.3.1 DHCPDISCOVER message
>
>    When a server receives a DHCPDISCOVER message from a client, the
>    server chooses a network address for the requesting client.  If no
>    address is available, the server may choose to report the problem to
>    the system administrator. If an address is available, the new address
>    SHOULD be chosen as follows:
>
>       o The client's current address as recorded in the client's current
>         binding, ELSE
>
>       o The client's previous address as recorded in the client's (now
>         expired or released) binding, if that address is in the server's
>         pool of available addresses and not already allocated, ELSE
>
>       o The address requested in the 'Requested IP Address' option, if that
>         address is valid and not already allocated, ELSE
>
>       o A new address allocated from the server's pool of available
>         addresses; the address is selected based on the subnet from which
>         the message was received (if 'giaddr' is 0) or on the address of
>         the relay agent that forwarded the message ('giaddr' when not 0).
>
> I hope this helps.
>
> I realise this doesn't help with your original question :) In terms of
> privacy there is an IPV6 feature that assigns a new IP address each day.
> This is part of the client functionality defined in RFC 4941 "Privacy
> Extensions for Stateless Address Autoconfiguration in IPv6" but doesn't
> help with your current IPv4 issue.
>
> regards,
> -glenn
>
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20150608/c287106f/attachment.html>