Re: NT 3.51 dhcp client and server ip address

Tim Rowe <rowe@sequent.com> Tue, 03 December 1996 02:10 UTC

Received: from cnri by ietf.org id ab25145; 2 Dec 96 21:10 EST
Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa21624; 2 Dec 96 21:10 EST
Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AA14066; Mon, 2 Dec 1996 21:00:18 -0500
Date: Mon, 2 Dec 1996 21:00:18 -0500
Message-Id: <199612030120.RAA00727@eng4.sequent.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: Tim Rowe <rowe@sequent.com>
To: Multiple recipients of list <dhcp-v4@bucknell.edu>
Subject: Re: NT 3.51 dhcp client and server ip address
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: Discussion of DHCP for IPv4

The client doesn't need a bootp forwarding agent.  The server is a
multi-homed host.

Perhaps I didn't describe the situation completely enough.  The server
has two interfaces (in the simplest case).  The Server Identifier
value happens to be a valid IP address for the primary interface (say
138.95.105.6).  The client is connected to the server via the
secondary interface (say 138.95.84.6).  The client doesn't need any
relay agents, because the server will see the broadcast DHCPDISCOVER
sent by the client on the server's secondary interface.  There are no
routers or other intermediaries between the client and the server.

Everything procedes normally until the lease negotiation is complete.
When the Windows/NT 3.51 client attempts to renew, it tries to unicast
the DHCPREQUEST to 138.95.105.6, which isn't valid on this subnet.  It
should instead use 138.95.84.6, which was the source of all the
server's packets during the lease negotiation.  If it does, everything
works.  Otherwise, there needs to exist a route between the 138.95.84
and 138.95.105 subnets.

I agree that the server identifier is used by the client to identify
the DHCP server which extended the lease, but it shouldn't expect the
identifier to have any other meaning.  'Fred' should be a valid server
id as long as its unique among servers that may respond.

>The server identifier is used by the client to identify the DHCP
>server which extended the lease - not the BOOTP relay agent, or any
>other intermediary. Support of remote clients happen thru BOOTP relay
>agents. Such clients need their subnet mask and a least one default
>router in order to unicast DHCP traffic (renew). I suspect you're not
>configuring the a default router for the remote client(s).