Re: DHCP and secondaries

"Edie E. Gunter" <edie@watson.ibm.com> Fri, 17 May 1996 15:16 UTC

Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15893; 17 May 96 11:16 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15889; 17 May 96 11:16 EDT
Received: from reef.bucknell.edu by CNRI.Reston.VA.US id aa09085; 17 May 96 11:16 EDT
Received: from localhost by reef.bucknell.edu with SMTP (5.65/IDA-1.2.8) id AA11762; Fri, 17 May 1996 11:09:17 -0400
Date: Fri, 17 May 1996 11:09:17 -0400
Message-Id: <9605171452.AA17734@edisto.watson.ibm.com>
Errors-To: droms@bucknell.edu
Reply-To: dhcp-v4@bucknell.edu
Originator: dhcp-v4@bucknell.edu
X-Orig-Sender: dhcp-v4@bucknell.edu
Precedence: bulk
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Edie E. Gunter" <edie@watson.ibm.com>
To: Multiple recipients of list <dhcp-v4@bucknell.edu>
Subject: Re: DHCP and secondaries
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: Discussion of DHCP for IPv4

>  I would like to require that the
> users of our dhcp service register the hardware addresses
> of their NIC cards before the server allows the client to
> be services from either an automatic or dynamic pool.

I'd be curious to know why.  The authentication proposal
you mention allows clients to be assured that the DHCP
responses are from legitimate servers.  However, if a 
server refuses to serve a particular client, that client
can still commandeer an IP address that the server "owns."
If a rogue client has physical access to the lan, there's 
really no way to prevent it from claiming addresses from
either one of your address pools.  (Oh, perhaps with a sniffer 
or similar tool you can detect the rogue and on TR send it 
KILL frames or some such.  There's also been talk
about how to manage this problem with internal fire walls,
but those are all ways to react to the problem, not how
to prevent it.)

Are you assuming a physically secure lan, and a group of
users who all "play nice" together?  If so, I can see how
the registration might be useful for accounting and other
administrivia.

Edie