[dhcwg] Two message transaction in DHCPv6
Ralph Droms <rdroms@cisco.com> Fri, 05 April 2002 19:34 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15137 for <dhcwg-archive@odin.ietf.org>; Fri, 5 Apr 2002 14:34:48 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA24446 for dhcwg-archive@odin.ietf.org; Fri, 5 Apr 2002 14:34:51 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24274; Fri, 5 Apr 2002 14:32:51 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24251 for <dhcwg@optimus.ietf.org>; Fri, 5 Apr 2002 14:32:49 -0500 (EST)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15035 for <dhcwg@ietf.org>; Fri, 5 Apr 2002 14:32:45 -0500 (EST)
Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-251.cisco.com [161.44.149.251]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA18017 for <dhcwg@ietf.org>; Fri, 5 Apr 2002 14:32:18 -0500 (EST)
Message-Id: <4.3.2.7.2.20020405141146.035ffe08@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 05 Apr 2002 14:32:15 -0500
To: dhcwg@ietf.org
From: Ralph Droms <rdroms@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Subject: [dhcwg] Two message transaction in DHCPv6
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org
Based on a conversation with Mark Stapp, here's a proposal for allowing a two message exchange for configuration. prefix and address assignment. The goal of this proposal is to allow, under certain circumstances, a client to complete its initial DHCPv6 transaction with two messages instead of the current four messages, Solicit-Advertise-Request-Reply. The circumstances under which this mechanism is designed to work are: only one server will respond to the client Solicit; the server will commit the prefixes and addresses to the client immediately. The proposed mechanism also allows a client to indicate whether it is willing to participate in a two message transaction, and allows a server to force a four message transaction (according to local policy). Here's the proposal... A new TMT option (two message transaction) is defined. The TMT option can only be included in a Solicit message. There is no data associated with the TMT option. The client includes a TMT option in its Solicit message, indicating its willingness to perform a two message transaction. If the server that receives a Solicit with a TMT option has a policy to perform the two message transaction, it determines the client configuration, commits the assignment of any prefixes or addresses, and sends the configuration to the client in a Reply message. If the server that receives a Solicit with a TMT option does not have a policy to perform the two message transaction, the server ignores the TMT option and responds with an Advertise. If the client receives a Reply, it records the configuration and is done (and may ignore any received Advertise messages). If the client receives one or more Advertise messages but not Reply message, the client sends a Request to continue the four message transaction. I intend to include this mechanism in the -24 rev of the DHCPv6 spec, which I'm working on now. Comments welcome... - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- RE: [dhcwg] Two message transaction in DHCPv6 Bernie Volz (EUD)
- RE: [dhcwg] Two message transaction in DHCPv6 Ralph Droms
- [dhcwg] Two message transaction in DHCPv6 Ralph Droms
- Re: [dhcwg] Two message transaction in DHCPv6 manmatd