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

[Glenn Satchell]

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