RE: [dhcwg] Two message transaction in DHCPv6

Ralph:

This sounds OK to me though:

- You say "only one server will respond to the client Solicit" yet then you later state in the proposal "(and may ignore any received Advertise messages)". Did you perhaps mean respond with a Reply (not just respond - with an Advertise) in the requirements.

- What should a client do if it receives multiple Reply's. Should it perhaps be required to Release those addresses? At least then the resources other servers that also Reply have allocated are released. This would require the client to "wait around" for a short period of time for other Reply's.

Otherwise, this procedure seems fine to me. Even if a client receives multiple Reply's and doesn't Release, IPv6 addresses shouldn't be a scarce resource.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Friday, April 05, 2002 2:32 PM
To: dhcwg@ietf.org
Subject: [dhcwg] Two message transaction in DHCPv6

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