[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
- AW: [dhcwg] Updated Draft "DHCP Discovery Extensi… Rentschler, Markus
- [dhcwg] DHCP server supports BOOTP client Shirley Ma
- RE: [dhcwg] DHCP server supports BOOTP client Kevin A. Noll
- Re: [dhcwg] DHCP server supports BOOTP client Ralph Droms
- [dhcwg] Client behavior with Parameter Request Li… Kevin A. Noll
- Re: [dhcwg] Client behavior with Parameter Reques… Ted Lemon
- RE: [dhcwg] Client behavior with Parameter Reques… Kevin A. Noll
- Re: [dhcwg] Client behavior with Parameter Reques… Ted Lemon
- RE: [dhcwg] Client behavior with Parameter Reques… Richard Barr Hibbs
- Re: [dhcwg] Client behavior with Parameter Reques… Ted Lemon
- [dhcwg] Parameter list from multiple servers? Kevin A. Noll
- RE: [dhcwg] Parameter list from multiple servers? Richard Barr Hibbs
- RE: [dhcwg] Parameter list from multiple servers? Kevin A. Noll