On Tuesday 11 March 2003 09:54 pm, -ray wrote: > 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 amazing how this procedure happens. I still believe that management is a little loose. > 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) my implementation huh? > > 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. What I think is that there is nothing to decide. All is required is an IP and they are all made the same within the bounds of a network. "first offer, or choose one at random". Does the client actually hangs around after receiving the first offer? This is what I am talking about. Until when does this happen? I do not believe that there is an option here, you get it you use it, or by what you are saying later, try to use it. > > 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!). If a server make an offer it should await for a time out just in the event that the client does not want any IP at all and I mean logs out, or connection drops, not by choice. If the standart dictates that the first offer should be used the DHCP server assumes it will be taken unless a particular period of time has elapsed, during this time the IP should become unavailable. Like I said before, I do not know any of these and there are probably hundreds of reasons to be the way it is. However, with my limited knowledge I cannot see a more logical way. > > 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. I will check that out for sure because now I am really curious, however, I mentioned about DNS in my previous messages and I think I am going to occupy my self with that for a bit, again. Take care Ray > > later! > Ray > > > > _______________________________________________ > General mailing list > [email protected] > http://oxygen.nocdirect.com/mailman/listinfo/general_brlug.net
