Re: Best way to retrieve DHCP vendor sp
"N. Balasubramania Pillai" <pillai@multitech.com> Tue, 24 December 1996 06:07 UTC
Received: from cnri by ietf.org id an16908; 24 Dec 96 1:07 EST
Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa00782;
23 Dec 96 23:45 EST
Received: from reef.bucknell.edu by mail.bucknell.edu;
(5.65v3.2/1.1.8.2/17Jul96-0109PM)
id AB14432; Mon, 23 Dec 1996 23:43:11 -0500
Date: Mon, 23 Dec 1996 23:43:11 -0500
Message-Id: <96Dec23.224347cst.20739@gateway.multitech.com>
Errors-To: droms@bucknell.edu
Reply-To: dhcp-v4@bucknell.edu
Originator: dhcp-v4@bucknell.edu
Sender: dhcp-v4@bucknell.edu
Precedence: bulk
From: "N. Balasubramania Pillai" <pillai@multitech.com>
To: Multiple recipients of list <dhcp-v4@bucknell.edu>
Subject: Re: Best way to retrieve DHCP vendor sp
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: Discussion of DHCP for IPv4
Mime-Version: 1.0
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
> I see a problem with this implementation. = > = > Let's call the DHCP server which has the required DHCP > options for my DHCP client as DHCP_OPTION server. > = > Let's consider the case: > ---------------------------------- > This DHCP_OPTION server has run out of IP addresses..i.e. it > can not allocate any more IP address but its the only DHCP > server which has specific options for my DHCP client. > = > In this case, DHCP negotiation is successful with another > DHCP server and my DHCP client obtained an IP address > successfully. > = > But my DHCP client can no way get those options information > as per the DHCP spec. > = > ( There are many other cases one can describe so that > getting option is not clean or not possible). > = > Isn't this is limitation of DHCP spec? > = > Isn't this possible to extend it such a way that: > = > 1. a DHCP server configured for some DHCP options can still > respond to DHCP clients request of "get parameter list"? > = > 2. <Some more> > = > = > thanks, som. > = > = > >>> Ted Lemon <mellon@fugue.com> 12/19/96 03:14pm >>> > = > The only time that the client is in a position to choose a server > based on what it offers is when it is in the SELECTING state, > after > having sent out a DHCPDISCOVER message. After it's got > an address, > it's stuck with what it got unless it gives up the address and > goes > back to the INIT-REBOOT state. > = > If it is important that a DHCP client receive vendor-specific > options, > > then it must request them in the DHCPDISCOVER broadcast, > wait around > for some reasonable period of time collecting DHCPOFFERs, > and take the > offer that most closely matches what it's looking for. If it > doesn't > get a DHCPOFFER with the appropriate vendor tags, it has a > choice of > either going back to INIT-REBOOT and trying again, or settling > for > what it got. > = > _MelloN_ > = Is it possible to use this scheme 1. The client gets the ip addres through the normal procedure from one = of the DHCP servers. 2. Then use DHCPINFORM message to get the required vender-specific = information from another server. One obevius problem I see is the client should somehow know the server's = = address from which it is to get vender-specific information. = Balu
- Re: Best way to retrieve DHCP vendor sp N. Balasubramania Pillai