[dhcwg] Parameter list from multiple servers?

"Kevin A. Noll" <kevin.noll@perfectorder.com> Mon, 24 May 2004 22:59 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 SAA14598; Mon, 24 May 2004 18:59:17 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSOMG-0004p5-Te; Mon, 24 May 2004 18:55:48 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSODn-0004FW-Le for dhcwg@megatron.ietf.org; Mon, 24 May 2004 18:47:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14199 for <dhcwg@ietf.org>; Mon, 24 May 2004 18:47:00 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSODm-0004e0-61 for dhcwg@ietf.org; Mon, 24 May 2004 18:47:02 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSOCs-0004ai-00 for dhcwg@ietf.org; Mon, 24 May 2004 18:46:07 -0400
Received: from endeavor.poss.com ([198.70.184.137] helo=smtp.poss.com) by ietf-mx with esmtp (Exim 4.12) id 1BSOCA-0004TD-00 for dhcwg@ietf.org; Mon, 24 May 2004 18:45:22 -0400
Received: from conversion-daemon.endeavor.poss.com by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) id <0HY800C01POD40@endeavor.poss.com> for dhcwg@ietf.org; Mon, 24 May 2004 18:44:47 -0400 (EDT)
Received: from kan1 (user188.net390.oh.sprint-hsd.net [65.40.75.188]) by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0HY800D0SPUMN4@endeavor.poss.com> for dhcwg@ietf.org; Mon, 24 May 2004 18:44:47 -0400 (EDT)
Date: Mon, 24 May 2004 18:44:46 -0400
From: "Kevin A. Noll" <kevin.noll@perfectorder.com>
In-reply-to: <481EBF5A-AA8A-11D8-9337-000A95D9C74C@nominum.com>
To: Dhcwg <dhcwg@ietf.org>
Message-id: <PPEKLDPHBHOIHMHKFGLLAEANDBAA.kevin.noll@perfectorder.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Subject: [dhcwg] Parameter list from multiple servers?
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


Section 4.3.1 of RFC2131 states (from the paragraph just below 
Table 3):

"It is important for all DHCP servers to return the same parameters 
(with the possible exception of a newly allocated network address) 
to ensure predictable client behavior regardless of which server the 
client selects."


I understand the intent of the statement to assure that clients don't
get confused or what not. I would want to assume that it is referring 
to servers that are "cooperating" (this is not stated) to provide 
parameters to a specific client (or set of clients).

However, it seems to me that it could be clarified a bit, since it is 
entirely possible (and common practice in my experience) that different
servers can be configured to service different clients (or sets/types of 
clients) on the same network/segment. 

In the purest protocol sense, the only way for a client to select among 
them is based on the options being returned. In other words, one server
returns a set of options (set A) and another server returns a set of 
options (set B) in the DHCPOFFER. The client receives both and compares 
set A and B to find that one (A for example) contains the options that 
it requires and the other (B) does not, and therefore chooses the most 
preferred DHCPOFFER.

In the practical world, the servers should (and typically are) 
configured to only respond to specific sets of clients and remain silent 
when receiving messages from clients not matching the set the server is 
configured to service.

Perhaps the paragraph needs a small alteration to clarify this? Perhaps
Barr can include it in his next "implementation" draft?

--kan--




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