Re: NT 3.51 dhcp client and server ip address

Mike Carney - SunSoft Internet Engineering <mwc@atlantic.east.sun.com> Wed, 04 December 1996 19:51 UTC

Received: from cnri by ietf.org id aa24470; 4 Dec 96 14:51 EST
Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa18595; 4 Dec 96 14:51 EST
Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AA00153; Wed, 4 Dec 1996 14:34:42 -0500
Date: Wed, 4 Dec 1996 14:34:42 -0500
Message-Id: <Roam 0.9.4.849723623.23249.mwc@atlantic.east>
Errors-To: droms@bucknell.edu
Reply-To: dhcp-v4@bucknell.edu
Originator: dhcp-v4@bucknell.edu
Sender: dhcp-v4@bucknell.edu
Precedence: bulk
From: Mike Carney - SunSoft Internet Engineering <mwc@atlantic.east.sun.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

> At 6:54 PM 12/3/96, Ted Lemon wrote:
> >In general, it just seems like a bad idea to
> >have multiple identifiers referring to the same object.
> 
> Yeah - looks like we blew it by overloading the "identifier" field to also
> act as the "return address" field.
> 
> We can either fix it or leave it:
> 
>   * Fixing will delay the advancement to Draft Standard, as it would
>     represent a fairly basic change to the behavior of clients and
>     servers.
> 
>   * Leaving it leaves the problem with multiple identifiers for a single
>     server - as pointed out by Ted - unfixed.

I propose we leave it. IMHO, it's been too long so far for the dhcp draft
(we're at 08). A clarifications draft may be the place to "fix" these kind of
things.

> 
> Discussion?
> 
> - Ralph
> 
> 
> 

BTW, the way I handled the multiple interface problem was to use the IP
address of the interface used to respond to the client as the server id. This
works even if the multihomed server isn't a router. Even if the request
happens to come in one of the other interfaces, the server needs to be smart
enough to recognize the request as one of its own.