Re: NT 3.51 dhcp client and server ip address

Shawn Mamros <mamros@ftp.com> Mon, 09 December 1996 22:30 UTC

Received: from cnri by ietf.org id aa18550; 9 Dec 96 17:30 EST
Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa21194; 9 Dec 96 17:30 EST
Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AB27686; Mon, 9 Dec 1996 17:18:59 -0500
Date: Mon, 9 Dec 1996 17:18:59 -0500
Message-Id: <199612041927.OAA10823@MAILSERV-2HIGH.FTP.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: Shawn Mamros <mamros@ftp.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

>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.

"Fixing" it also means breaking thousands upon thousands of client
implementations already out there (not just Redmond's, either...).

>  * Leaving it leaves the problem with multiple identifiers for a single
>    server - as pointed out by Ted - unfixed.

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...

-Shawn Mamros
E-mail to: mamros@ftp.com