Re: NT 3.51 dhcp client and server ip address

Ted Lemon <mellon@fugue.com> Tue, 10 December 1996 00:50 UTC

Received: from cnri by ietf.org id aa22010; 9 Dec 96 19:50 EST
Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa23693; 9 Dec 96 19:50 EST
Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AA16821; Mon, 9 Dec 1996 19:33:45 -0500
Date: Mon, 9 Dec 1996 19:33:45 -0500
Message-Id: <199612092316.PAA06409@toccata.fugue.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: Ted Lemon <mellon@fugue.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

> How much of a problem is this really?  The server implementation I was
> responsible for had to handle multiple interfaces, and it did so just
> fine.  The server kept a list of all of its own IP addresses.  When a
> DHCPREQUEST comes in with a Server Identifier option specified, we ran
> down the list and compared it - if it was on the list, it's ours; if
> not, it isn't.  Unless there's a DHCP server with hundreds of interfaces
> out there, running down the list shouldn't take all that long...

Actually, now that I think about it, the reason I didn't want to do
this is that I didn't want dhcpd to fail to recognize a lease as its
own if some of the server's interface addresses changed.   By
requiring the user to pick one server identifier address, and
documenting the importance of choosing a reasonably permanent address,
rather than assigning these addresses automatically, I felt I was
minimizing the chances of something like this happening.

Nonetheless, I think this is a moot point for reasons we have already
discussed.  Sigh.

			       _MelloN_