[Bug 3553] Retain lease information for udhcpc across restarts
bugzilla at busybox.net
bugzilla at busybox.net
Mon May 9 02:57:38 UTC 2011
Philip Prindeville <philipp at redfish-solutions.com> changed:
What |Removed |Added
--- Comment #8 from Philip Prindeville <philipp at redfish-solutions.com> ---
(In reply to comment #7)
> I tend to not implement this in udhcpc, for the reasons described above.
> If you disagree, please reopen and explain your position.
Ok, I thought I already did that, but here goes again.
Your argument is predicated on the assumption that the server is correctly
implemented, and that the network operator is motivated to have their server
behave in the way that's least disruptive to clients:
> Server should be ready for such common use case anyway, because this
> happens all the time when clients are rebooted.
This might be the case in a LAN environment where the customer and the network
operator are in the same organization and reporting structure. It is not the
case in a WAN environment.
Respectfully, I don't think you understand how ISPs work. I'll give you the
benefit of having worked for France Telecom for 5 years, Erol's Internet,
Bellcore and Metricom for another 3 total.
The laws of economics being what they are, an ISP wants to spend the least
amount of operating costs on provisioning bandwidth for their network, while at
the same time extracting the most revenue they can without forcing their
customers into mass exodus.
Hopefully this is something we can both agree on.
Allowing a customer to have a stable IP address, even if it's dynamically
allocated, allows him to operate services on a semi-permanent basis that
consume large amounts of bandwidth (such as file sharing, video conferencing,
and other server operation).
More consuming large amounts of bandwidth means that the network operator needs
to spend more money over-engineering their network, which cuts into their
It is not in an ISP's interest to strictly follow the specification and renew
an unexpired lease if it can be avoided.
My own experience dogfooding UBR-925s at Cisco Systems was that TCI and Comcast
would issue a *new* IP address if a new negotiation cycle was initiated with a
DISCOVERY packet. Conversely, they would honor an lease renewal cycle starting
with a REQUEST and containing the same parameters as present in the last OFFER.
(There was a period when even with a REQUEST to extend a lease, Comcast would
NAK it and issue a new address; the speculative reason for doing this was to
stop customers from using 3rd party VoIP services. This behavior has since
Bottom line: if you're counting on ISPs to follow the letter of the
specification religiously server-side, you're going to be disappointed.
Anyway, Postel's adage was "be conservative in what you send".
In this scenario, the conservative thing to send would be a request for the
same lease, not a new one, since that leaves the fewest IP addresses in a
possibly unused state while the server keeps them tied up waiting for the
leases to expire (even if this is unlikely, the entire point of Postel's adage
was that the sender can never and should never count on the receiver doing the
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
More information about the busybox-cvs