|
|
12
|
|
Hi dhcp users,
we are running a DHCP Server for about 10k customers with a single isc dhcpd (4.2.4p2) process running.
Our customers do almost ever get the same IP Address assigned when sending DHCPDISCOVER.
Lease time is 1200 sec. (20 minutes), pool is 95-97% in use all day. Even after 10h offline,
dhcpd will answer an DHCPDISCOVER with an DHCPOFFER for the same ip address as assigned 10h earlier.
Some of our customers would like their ip address to change from time to time (e.g. every 24h)
as they where used to when using PPP.
Is there any way to accomplish this using isc dhcpd?
--
Mit freundlichen Grüßen / Kind regards
Arne Bäumler
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
To the best of my understanding, no.
The system is doing exactly what it was designed to do. It's running a 2hr lease (per your
config). At the end of the 2hrs, if the device is not online anymore, it marks the lease as
expired and that IP as available for another customer. It does record who was last assigned to
it IIRC.
Later, 10hr later as per your example, a client comes back and requests an IP and is assigned a
vacant IP, which happens to be the same IP that was most recently assigned to that MAC address.
This is actually a good thing as there are several operating systems which will stubbornly cling
to the last IP they knew about even after lease expiration time. They don't behave well and can
get themselves into quite a state, sometimes refusing to believe that the IP is no longer
available.
If the prior IP wasn't available, the system would look for the oldest expired lease and assign
that one to the client.
Basically, it won't start recycling IPs until enough new MAC addresses are seen to use up enough
of the available unused IPs that the former customer's lease had already been assigned elsewhere.
Dave
On 6/5/15 08:10, Arne Baeumler wrote:
> Hi dhcp users,
>
> we are running a DHCP Server for about 10k customers with a single isc dhcpd (4.2.4p2) process running.
> Our customers do almost ever get the same IP Address assigned when sending DHCPDISCOVER.
>
> Lease time is 1200 sec. (20 minutes), pool is 95-97% in use all day. Even after 10h offline,
> dhcpd will answer an DHCPDISCOVER with an DHCPOFFER for the same ip address as assigned 10h earlier.
>
> Some of our customers would like their ip address to change from time to time (e.g. every 24h)
> as they where used to when using PPP.
>
> Is there any way to accomplish this using isc dhcpd?
>
>
>
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users>
--
Dave Calafrancesco
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Arne Baeumler < [hidden email]> wrote:
> we are running a DHCP Server for about 10k customers with a single isc dhcpd (4.2.4p2) process running.
> Our customers do almost ever get the same IP Address assigned when sending DHCPDISCOVER.
>
> Lease time is 1200 sec. (20 minutes), pool is 95-97% in use all day. Even after 10h offline,
> dhcpd will answer an DHCPDISCOVER with an DHCPOFFER for the same ip address as assigned 10h earlier.
>
> Some of our customers would like their ip address to change from time to time (e.g. every 24h)
> as they where used to when using PPP.
>
> Is there any way to accomplish this using isc dhcpd?
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.
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.
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 ?
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.
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.
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.
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.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
You could maintain two config files with pools that do not overlap
but are within the same subnet. Then you could cron a dhcpd restart
that alternates the config files every 24 hours.
On 06/05/2015 06:10 AM, Arne Baeumler
wrote:
Hi dhcp users,
we are running a DHCP Server for about 10k customers with a single isc dhcpd (4.2.4p2) process running.
Our customers do almost ever get the same IP Address assigned when sending DHCPDISCOVER.
Lease time is 1200 sec. (20 minutes), pool is 95-97% in use all day. Even after 10h offline,
dhcpd will answer an DHCPDISCOVER with an DHCPOFFER for the same ip address as assigned 10h earlier.
Some of our customers would like their ip address to change from time to time (e.g. every 24h)
as they where used to when using PPP.
Is there any way to accomplish this using isc dhcpd?
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Sean McMurray < [hidden email]> wrote:
> You could maintain two config files with pools that do not overlap but are within the same subnet. Then you could cron a dhcpd restart that alternates the config files every 24 hours.
That will do it - but it also means that clients will change address mid-session - breaking any existing connections. For all the reasons that get listed when the usual variation of this question comes up, that's a recipe for "unhappy customers".
On a more granular level (ie requiring less than double the required number of addresses), you could do it with several pools and have (say) 9 out of 10 pools active at any time - that would just need 11% extra addresses. It would still have the issue of killing active sessions when a client has it's address pulled from under it.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
However, there is a cleaner way to turn on pools in the system. You can use a cron job to add a
deny all clients; statement to one of the 10 pools (as suggested below) or to one of the two
pools as suggested by the prior responder. Then you aren't yanking the active leases away from
active users.
But, an interesting side effect will be that when the pool is made available again, customers
who previously had an IP will receive that original IP address if it's still available, which
seems to not be what the customers of the OP was asking for.
So instead, the only way I can see to do it is to stop dhcpd services, which forces the leases
file to be written from memory to disk as part of the shutdown, then use a script to remove all
expired lease info from the dhcpd.leases file.
This will force the system to not know about the prior lease allocation that has since expired,
removing the RFC required feature that says we must give back a prior IP address if it's available.
This is the only way I can think of to 'randomize' the IP given to previously expired customers.
But, like many have intimated, it's really working well against the purposes of the DHCP RFC
which seems to be: "Be consistent & Don't break people's stuff."
Dave
On 6/5/15 11:32, Simon Hobson wrote:
> Sean McMurray < [hidden email]> wrote:
>
>> You could maintain two config files with pools that do not overlap but are within the same
>> subnet. Then you could cron a dhcpd restart that alternates the config files every 24
>> hours.
>
> That will do it - but it also means that clients will change address mid-session - breaking
> any existing connections. For all the reasons that get listed when the usual variation of
> this question comes up, that's a recipe for "unhappy customers".
>
> On a more granular level (ie requiring less than double the required number of addresses),
> you could do it with several pools and have (say) 9 out of 10 pools active at any time - that
> would just need 11% extra addresses. It would still have the issue of killing active sessions
> when a client has it's address pulled from under it.
>
> _______________________________________________ dhcp-users mailing list
> [hidden email] https://lists.isc.org/mailman/listinfo/dhcp-users>
--
Dave Calafrancesco
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
On 6/5/15 9:44 AM, Bob Harold wrote:
> Interesting idea to remove expired lease information form the server.
> But I think that clients also remember their IP and request it the next
> time they connect. Is that true?
Yes, they will DHCPDISCOVER for the address they already had.
--
I am conducting an experiment in the efficacy of PGP/MIME signatures.
This message should be signed. If it is not, or the signature does not
validate, please let me know how you received this message (direct, or
to a list) and the mail software you use. Thanks!
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
> On Jun 5, 2015, at 12:02 PM, Doug Barton < [hidden email]> wrote:
>
>> On 6/5/15 9:44 AM, Bob Harold wrote:
>> Interesting idea to remove expired lease information form the server.
>> But I think that clients also remember their IP and request it the next
>> time they connect. Is that true?
>
> Yes, they will DHCPDISCOVER for the address they already had.
>
But if the client-to-IP address association
is not maintained, i.e., is immediately
scavenged, then there is more of a
possibility that the old IP will be given
out to some other client before the
previous owner requests it back, yes?
Mark
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
On 6/5/15 10:29 AM, Mark Sandrock wrote:
>
>> On Jun 5, 2015, at 12:02 PM, Doug Barton < [hidden email]> wrote:
>>
>>> On 6/5/15 9:44 AM, Bob Harold wrote:
>>> Interesting idea to remove expired lease information form the server.
>>> But I think that clients also remember their IP and request it the next
>>> time they connect. Is that true?
>>
>> Yes, they will DHCPDISCOVER for the address they already had.
>>
>
> But if the client-to-IP address association
> is not maintained, i.e., is immediately
> scavenged, then there is more of a
> possibility that the old IP will be given
> out to some other client before the
> previous owner requests it back, yes?
No, because all the other clients are going to DHCPDISCOVER for their
old addresses as well.
--
I am conducting an experiment in the efficacy of PGP/MIME signatures.
This message should be signed. If it is not, or the signature does not
validate, please let me know how you received this message (direct, or
to a list) and the mail software you use. Thanks!
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
> On Jun 5, 2015, at 12:47 PM, Doug Barton < [hidden email]> wrote:
>
>> On 6/5/15 10:29 AM, Mark Sandrock wrote:
>>
>>>> On Jun 5, 2015, at 12:02 PM, Doug Barton < [hidden email]> wrote:
>>>>
>>>> On 6/5/15 9:44 AM, Bob Harold wrote:
>>>> Interesting idea to remove expired lease information form the server.
>>>> But I think that clients also remember their IP and request it the next
>>>> time they connect. Is that true?
>>>
>>> Yes, they will DHCPDISCOVER for the address they already had.
>>
>> But if the client-to-IP address association
>> is not maintained, i.e., is immediately
>> scavenged, then there is more of a
>> possibility that the old IP will be given
>> out to some other client before the
>> previous owner requests it back, yes?
>
> No, because all the other clients are going to DHCPDISCOVER for their old addresses as well.
>
All the other old clients anyway.
Mark
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
dave c < [hidden email]> wrote:
> However, there is a cleaner way to turn on pools in the system. You can use a cron job to add a deny all clients; statement to one of the 10 pools (as suggested below) or to one of the two pools as suggested by the prior responder. Then you aren't yanking the active leases away from active users.
Yes you are - because when the client comes to renew, it'll be denied. When it's lease expires, it's no longer got that address so any sessions it has open will break.
That's going to be the case with any solution that doesn't allow all clients to keep their address for as long a they keep renewing it.
Until the OP comes back and gives a bit more information (such as whether they can detect clients leaving the network and the nature of the clients and how they work) then we can't really go much further.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
On 5 Jun 2015, at 15:05, Simon Hobson < [hidden email]> 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.
> 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"
In practice isn't the first address allocated the one the client asks for? IE normally the client is getting
the same address because the client requests it, and it's free.
--
Alex Bligh
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
> On Jun 5, 2015, at 2:28 PM, Alex Bligh < [hidden email]> wrote:
>
>
>> On 5 Jun 2015, at 15:05, Simon Hobson < [hidden email]> 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.
>> 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"
>
> In practice isn't the first address allocated the one the client asks for? IE normally the client is getting
> the same address because the client requests it, and it's free.
>
I'm not sure about the client, but the
DHCP server stores the last client
to have had each address, and will
hand back that same IP even if the
client doesn't request it.
Modulo lease scavenging on Infoblox,
which as far as I know is running stock
ISC DHCP 4.2.4.
The client is probably only going to know
the last IP it had, which well could be
on an entirely different subnet, right?
Mark
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
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
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users--
Mit freundlichen Grüßen / Kind regards
Arne Bäumler
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
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).
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Most dhcp clients also store the last address. So even if you configure
the server to offer different IPs to the client, the client could keep
asking for the old address and the server would accept that.
regards,
-glenn
On Tue, June 9, 2015 12:58 am, Bob Harold wrote:
> 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)
> [hidden email]
> 734-647-6524 desk
>
> On Mon, Jun 8, 2015 at 9:11 AM, Glenn Satchell
> < [hidden email]>
> 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
>> [hidden email]
>> https://lists.isc.org/mailman/listinfo/dhcp-users>>
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Arne Baeumler < [hidden email]> wrote:
>> 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.
As is the way of things, when you take a break sometimes fresh ideas pop up.
I think the "best" method of forcing an IP change is to "mangle" the expired lease so that next time the client comes to get a lease, it's old address is now in use. This can be done without OMAPI or interacting with the leases file.
Knock up a script which watches for a lease to expire, and checks each one against a list which require a change. Now, instead of using OMAPI, use a dummy DHCP client to request that address, thus getting a new lease on that address and making it "in use". When the client comes back online, as long as the dummy client still has an active lease, the other client won't be able to have it's old address and so will get a different one - the least recently used expired lease.
I see a few wrinkles to work out ...
The dummy lease needs to be active until the dynamic client comes back. One way of achieving this would be to simply give it a long lease (say a few days/weeks). This needs no further work, the dummy client simply gets the lease and the rest is automagic by the server which will expire it and return the address to the free pool. An alternative is that you need to track clients and spot when the dynamic client has had a new address and then release the dummy lease or stop renewing it (if using short leases). How many spare addresses you have would be a factor in deciding how to do this.
You might consider using a self service portal (which can get their current address from the connection to the web server) - the user signs in, requests an address change, the portal then tells them how long they need to turn off their kit for (to force the lease to expire) and then the timeframe for turning it back on (so they get a new address before their old one becomes free).
The dummy client needs a new ID for each lease it takes. It can use the same MAC address and change the Client-ID each time. It doesn't matter what the client-ID is, as long as it's unique within the service realm of the server - so you might use some unique string plus (say) a timestamp.
So in summary :
A process to add IPs to a list to be changed.
A process to monitor expiring leases and check them against the list.
A process to take matches from the previous step and take dummy leases to temporarily "lock" the address.
That would seem to a fairly safe set of operations.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
12
|
Locked
attachment0 (836 bytes)