On Tue, 11 Mar 2003, Alvaro Zuniga wrote: > why should all DHCP servers need to be addressed? We are only looking for a > single IP which can be provided by any server. Seems like a waste of > bandwith, memory, and available IPs( I imagine IPs become temporarily > unavailable ).
Remember the client making the request knows absolutely nothing about the network. it doesn't have an ip, much less know where the dhcp servers are... so all it can do is broadcast a DHCPDISCOVER and hope someone comes to the rescue. It is somewhat of a waste. Now if all available dhcp servers could talk to each other and elect one server to answer the request, that would be cool. But nothing in the RFC defines the mechanism for this... then again nothing specifically prohibits it either. So your implementation could have this feature, and still meet the spec. I've found most RFCs to be like this.... flexible and extensible, which means some things can be a little vague. (there may be a later RFC that does define stuff like this) > What is the criterion of the client to determine which IP is good enough? > Does > it matter? I would imagine that unless a specific network is desired any IP > would do. If a particular network IP range is to be used ( is this possible? > ) there must or should be a mechanism to identify the DHCP server providing > that range of IPs. As far as the RFC, there is no criterion. It is totally up to the client developer to decide...i'm not sure what criterion Windows/Linux clients use. From what i can tell they either choose the first offer, or choose one at random. Check out the dhcpcd source maybe... :) Yes unless the network is *really* complicated, i would say it doesn't matter. There is a 'server id' field in the DHCP messages to identify the server. > Once again a waste of IP addresses. The DHCP server would have to have a time > out to determine when to make an IP address available to someone else. I > guess there could be a response stating I did not like your IP so keep it! > But once again, even more bandwith for what is needed. Should the server > approve or just make note of it, if it already offer the IP then it should > assume it is taken unless the time out is reached. Well it's been a while since i saw the RFC, so i looked this one up. The server is NOT obligated to reserve addresses if OFFERS... but the protocol might work better if it does (according to RFC2131). But, when the client chooses a server, it will broadcast the DHCPREQUEST and the 'server id' field is populated with its server choice. The other servers will also see this request, and assume the client is denying the OFFER it made...so that in effect is your 'i didn't like your IP so keep it' message. Conversely, after the client chooses, the server is also allowed to renig on its OFFER, and respond with a DHCPNAK, telling the client 'ps i changed my mind. kiss my a**, haha' (movie quote!). > Thanks for the info, I was just thinking about the process but I am certain > that if there was a better way it would have already been implemented. there's probably always a better way, otherwise we'd get bored, haha... for the rest of the nitty gritty details, see http://www.ietf.org/rfc/rfc2131.txt. This document is actually somewhat readable. later! Ray
