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