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

Arne Baeumler slobo at br0tkasten.de
Mon Jun 8 09:29:19 UTC 2015


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.

> With the ISC server, addresses are allocated in the following order :
> - The address the client had previously if it is still available
> - An address which has never been issued before
> - An expired lease, picking the least recently used one
> - If there are no free leases available, then any abandoned leases are recovered and tried
> - Else - there isn't one, log "no free leases"
> 
> 
> The usual question is along the lines of "I work for a small ISP and my boss has told me to make all addresses change periodically ... because he doesn't want customers running servers". The responses tend not to be very supportive of the boss, with suggestions to go and find a job at a proper ISP that values the customers. Hence my comment that your question is something different if the customers are asking for it.
> 
> Personally I'm not sure why people would ask for it - I'm considering switching ISPs at home because the one that came with the wife won't do static IPs.
The (few) clients requesting this for privacy reasons
("My IP has been blocked on xyz.org - make it work" or "I don't want to be tracked on abc.com" ).
We are now asked to reply regarding this "issue" to our Federal Network Agency.

> 
> But on the basis that some people do want it, how to achieve it.
> First question is - do you have a means of detecting when the customer "leaves" the network ?
No.

> 
> I assume not, but if you did (as would be the case with PPPo[AE] clients) then you could trigger a script at that point. I'll come to what that script might do in a minute ...
> 
> Without a means of detecting the customer leaving, then you would need to watch for the lease expiring - meaning the customer would need to be offline for up to the full lease time to trigger a new address. I can't recall whether there's an "on expiry" hook available - I'm sure one of the experts will come along with that one.
> 
> Next question is how you identify the clients ? I'm guessing just by their MAC address or Client-ID if provided ?
> Probably not very helpful, but if the client changes it's MAC address (if no Client-ID provided), or Client-ID if provided, then to the server it is a different client and will be given a new address. I don't suggest telling customers this since having duplicate MAC addresses and/or Client-IDs (I've seen both) is "not a good thing" ! I also assume you don't have control over the end user's equipment - what sort of service is this, 10k leases on a network that isn't using PPP or DOCSIS doesn't sound much like a regular ISP.
A city carrier's services which are provided via GPON (Gigabit Passive Optical Network).

> 
> 
> Now, about that script ...
> Once you detect that a client has left the network then you need to do two things :
> 1) Check if it one that wants a dynamic address.
> 2) If it is, somehow ensure that it gets a different address when it comes back.
> 
> I think you need to be working along the lines of :
> 
> A) Clobber the lease so it looks like it's assigned to a different (non-existant) device.
> This means remove or change any Client-ID and change the MAC address - are there any OUIs reserved for "internal" use like RFC1918 IP addresses ? When the client comes back, it doesn't have an existing lease, so the least recently used expired lease is re-used.
> 
> B) Remove the lease and make the IP address free (never before used).
> When the client comes back, it doesn't have an existing (expired or current) lease and so will be given an address from the free pool. However, if this is the only free address then it's guaranteed that the client will get it - so you would also need to ensure that you always had several free leases (by finding and removing old expired leases). Even then, due to the way addresses are allocated in a specific (internally defined, undocumented, and not guaranteed not to change without warning) order, the client may still get the same address back.
> I'd suggest option A would be easier to implement.
> 
> For both of these, you'll need to look into OMAPI and what operations it supports. That's the tool for dynamically interacting with the ISC DHCP server and it's lease database.
> 

We came up with such ideas ourself and refused them because of the risk to mess things up.

> There is one other thing to consider ...
> How dynamic is your user group ?
> If you have significant churn, with clients going away and new ones joining, then you'll get a turnover of leases. At the other extreme (and especially if most of them want/are happy with static addressing), you may find that you end up with a small pool of dynamic leases - so clients tend to get one of a small number of addresses each time they change.
Our user group is constantly growing (there are always a few customers leaving our network, too).

> 
> 
> Does that help ?
> 
> 
> PS - 10k leases, 20 minute lease time, one server ! I think someone likes living on the edge :-)
> If that server goes down for whatever reason, you have a maximum of about 10 minutes before clients start falling off the network and the phone starts ringing, and a maximum of 20 minutes before the network is dead and the phone is a melted blob on the desk.
> There are strategies you can use - from failover pairs to splitting the pool up and having several servers each manage part of the pool.
Thank you, I will think about such strategies. 
In my experience failover scenarios can cause some serious trouble on their own.
There are good reasons why we have chosen the configuration I described.

> 
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users

-- 
Mit freundlichen Grüßen / Kind regards
Arne Bäumler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20150608/2e5c89e3/attachment.bin>


More information about the dhcp-users mailing list