Re: [dhcwg] Comments on draft-ietf-dhc-3315id-for-v4-03

Ted Lemon <mellon@fugue.com> Thu, 12 August 2004 22:53 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15249; Thu, 12 Aug 2004 18:53:58 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvOJt-0003JA-Eh; Thu, 12 Aug 2004 18:45:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvOHo-0002Oq-De for dhcwg@megatron.ietf.org; Thu, 12 Aug 2004 18:43:04 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14535 for <dhcwg@ietf.org>; Thu, 12 Aug 2004 18:43:01 -0400 (EDT)
Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvOMp-0008W4-Ux for dhcwg@ietf.org; Thu, 12 Aug 2004 18:48:17 -0400
Received: from [10.0.2.3] (neubayern.net [66.93.162.100]) by toccata.fugue.com (Postfix) with ESMTP id 646A41B24C1; Thu, 12 Aug 2004 17:40:40 -0500 (CDT)
In-Reply-To: <20040812221024.GH38172@isc.org>
References: <20040812155100.GA38172@isc.org> <002b01c48087$cba0f480$d0412ca1@amer.cisco.com> <20040812171424.GF38172@isc.org> <6BB45DB0-EC8D-11D8-A2F0-000A95D9C74C@nominum.com> <20040812221024.GH38172@isc.org>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Message-Id: <F3A99A76-ECB0-11D8-B25B-000A95D9C74C@fugue.com>
Content-Transfer-Encoding: 7bit
From: Ted Lemon <mellon@fugue.com>
Subject: Re: [dhcwg] Comments on draft-ietf-dhc-3315id-for-v4-03
Date: Thu, 12 Aug 2004 15:42:55 -0700
To: "David W. Hankins" <David_Hankins@isc.org>
X-Mailer: Apple Mail (2.619)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Content-Transfer-Encoding: 7bit
Cc: dhcwg@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
Content-Transfer-Encoding: 7bit

In the case of a PXE boot like the one you describe, the right answer 
for the ISP is to configure the DHCP server to put PXE clients in a 
special class, and not offer service to clients in that class.   Then 
you don't have to worry about inappropriately responding to PXE clients 
that you can't actually configure.   This is really the same problem as 
the well-known RAS server problem.

One nice side effect of ignoring PXE clients is that since the boot now 
has to time out, the user will probably notice the incorrect boot 
order.   This probably goes unnoticed with the current configuration 
because PXE probably gives up immediately when it gets a response with 
no PXE boot information in it.   An additional advantage of PXE is that 
it gives up quickly, so you don't have to worry about endless 
DHCPDISCOVERs in your log files.

My experience over the years is that when customers feel they need to 
hack the DHCP server sources, it's usually because they aren't aware 
that it's already possible to configure the server to address the 
problem they're having.   I think this is true somewhat independently 
of the server implementation - it's certainly just as true of the 
Nominum DHCP server as it is of the ISC DHCP server, and I think it's 
also true of Cisco's DHCP server.


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg