From owner-freebsd-questions@FreeBSD.ORG Sun Jun 1 06:31:32 2014 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4B3456EE for ; Sun, 1 Jun 2014 06:31:32 +0000 (UTC) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id 8A9F02B97 for ; Sun, 1 Jun 2014 06:31:31 +0000 (UTC) Received: (qmail 43464 invoked from network); 1 Jun 2014 06:24:48 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 1 Jun 2014 06:24:48 -0000 Date: Sun, 01 Jun 2014 08:24:48 +0200 (CEST) Message-Id: <20140601.082448.74710838.sthaug@nethelp.no> To: john@thehowies.com Subject: Re: Patches for BOOTP/DHCP code to support Windows Server DHCP From: sthaug@nethelp.no In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-arm@freebsd.org, freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 06:31:32 -0000 > Section 3.5 of RFC 2131 (the DHCP RFC) states that "...Second, in its > initial DHCPDISCOVER or DHCPREQUEST message, a client may provide the > server with a list of specific parameters the client is interested in" > and "...The client can inform the server which configuration parameters > the client is interested in by including the 'parameter request list' > option." The data portion of this option explicitly lists the options > requested by tag number. A DHCP Server is not required to return any > parameter that a client does not ask for. It appears that the ISC-DHCP > server, which is recommended by most, will return configured options > regardless of whether or not the client asks for them. As far as I know this is wrong. ISC DHCP does *not* behave this way. Do you have packet sniffer traces to indicate oterwise? In any case - yes, the client should absolutely request all the parameters it wants. Steinar Haug, Nethelp consulting, sthaug@nethelp.no