Subject: [dhcwg] Clarification about receipt of DHCPv6 Reconfigure message

From: Ralph Droms <[email-masked]>
Date: Mon, 12 Feb 2007 12:15:56 -0500

As part of our work on the CableLabs DOCSIS 3.0 spec, Margo asked about
clarifying the times at which a Reconfigure message must be processed (as
opposed to discarded) by a DHCPv6 client.

The first clarification is how a client should respond to Reconfigure
messages before the initial message exchange is complete.  RFC 3315 includes
the following text:

19.4. Client Behavior

   A client receives Reconfigure messages sent to the UDP port 546 on
   interfaces for which it has acquired configuration information
   through DHCP.  These messages may be sent at any time.

In the abstract, it doesn/t make much sense for the client to respond to a
reeconfigure message before it has completed the initial message exchange,
and, as a practical matter, the client can't respond until it reFrom [email-masked] Mon Feb 12 14:38:32 2007
Date: Mon, 12 Feb 2007 12:15:56 -0500
From: Ralph Droms <[email-masked]>
To: dhcwg <[email-masked]>
Cc: Margo Dolas <[email-masked]>, 'John McQueen' <[email-masked]>
Subject: [dhcwg] Clarification about receipt of DHCPv6 Reconfigure message

As part of our work on the CableLabs DOCSIS 3.0 spec, Margo asked about
clarifying the times at which a Reconfigure message must be processed (as
opposed to discarded) by a DHCPv6 client.

The first clarification is how a client should respond to Reconfigure
messages before the initial message exchange is complete.  RFC 3315 includes
the following text:

19.4. Client Behavior

   A client receives Reconfigure messages sent to the UDP port 546 on
   interfaces for which it has acquired configuration information
   through DHCP.  These messages may be sent at any time.

In the abstract, it doesn/t make much sense for the client to respond to a
reeconfigure message before it has completed the initial message exchange,
and, as a practical matter, the client can't respond until it receives a
Reply with the key information.  I think the desired behavior would be for
the client to discard any Reconfigure messages received before the initial
message excahgne is complete.

The second clarification is about client behavior if it receives a
Reconfigure message after T1 and the client has already initiated but not
completed a Renew message exchange.  Because of the parameters for the Renew
message exchange after T1, the client will continue to retransmit the Renew
message until either it receives a Reply or time T2.  Does it make sense for
the client to initiate a parallel Renew message exchange when it is already
waiting for a Reply?  I think the desired behavior would be for the client
to discard any Reconfigure messages it receives if it already has a Renew
message exchange in progress (i.e., any time after T1).  (Note that the
comments above generalize to time T2 and Rebind.)

- Ralph

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 12 Feb 2007 13:31:07 -0800

> The first clarification is how a client should respond to Reconfigure

I agree.

> completed a Renew message exchange.  Because of the parameters for the Renew

At first blush, I would expect this to be the same as the behaviour
described in section 19.4.1 for multiple Reconfigures.

> comments above generalize to time T2 and Rebind.)

A client might have been trying to Renew or Rebind for many
iterations already, and consequently its RT may have reached
MRT (10 minutes!).

I would suggest that receiving a reconfigure message in this case
should reset the retransmission state to message-appropriate
settings (be they renew, rebind, or information-request), and the
IRT timeout be scheduled per the transmission time of the previous
packet (immediately if already elapsed).

The server is soliciting traffic, so congestion-avoidance backoffs
are worth resetting, I think, considering the alternative is
waiting up to ten minutes.

But this would only be true of the first Reconfigure message
received since the last Reply.  Section 19.4.1 indicates that
duplicate Reconfigure messages are to be discarded, so it's
important that implementors don't make this a general behaviour.

It may be less effort for a client implementation to simply discard
the Reconfigure than to keep track of wether the current exchange
was Reconfigure-inspired or converted, and that should be allowed.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Mon, 12 Feb 2007 19:59:43 -0500

There are also other interesting questions, such as what should a server
do if it has sent a Reconfigure and receives a Solicit from the client?
RFC 3315 says that only receipt of the message in the
Reconfigure-Message option "cancels" the Reconfigure.

The client/server transactions get very messy because it depends a lot
on which IAs or other options are in each message.

And, it gets more complicated because the Reconfigure isn't clear about
which server the client is to communicate with. Should it communicate
with the server that gave it the information? Or should it communicate
with the server that sent it the Reconfigure (for now, they are most
likely to be the same, but that may not always be the case).
draft-ietf-dhc-dhcpv6-reconfigure-rebind-01 tries to address this.

My own feeling is that the client can discard Reconfigure messages if it
is already doing transactions with the (or a) server on that interface.
If the server continues to retransmit the Reconfigure, eventually the
client will act on it (or the server will give up). And, worst case, the
client and server will do a few extra message exchanges. Not the end of
the world.

This also follows the keep it simple approach?

- Bernie

-----Original Message-----
From: Ralph Droms (rdroms) 
Sent: Monday, February 12, 2007 12:16 PM
To: dhcwg
Cc: Margo Dolas; 'John McQueen'
Subject: [dhcwg] Clarification about receipt of DHCPv6 Reconfigure
message

As part of our work on the CableLabs DOCSIS 3.0 spec, Margo asked about
clarifying the times at which a Reconfigure message must be processed
(as
opposed to discarded) by a DHCPv6 client.

The first clarification is how a client should respond to Reconfigure
messages before the initial message exchange is complete.  RFC 3315
includes
the following text:

19.4. Client Behavior

In the abstract, it doesn/t make much sense for the client to respond to
a
reeconfigure message before it has completed the initial message
exchange,
and, as a practical matter, the client can't respond until it receives a
Reply with the key information.  I think the desired behavior would be
for
the client to discard any Reconfigure messages received before the
initial
message excahgne is complete.

The second clarification is about client behavior if it receives a
Reconfigure message after T1 and the client has already initiated but
not
completed a Renew message exchange.  Because of the parameters for the
Renew
message exchange after T1, the client will continue to retransmit the
Renew
message until either it receives a Reply or time T2.  Does it make sense
for
the client to initiate a parallel Renew message exchange when it is
already
waiting for a Reply?  I think the desired behavior would be for the
client
to discard any Reconfigure messages it receives if it already has a
Renew
message exchange in progress (i.e., any time after T1).  (Note that the
comments above generalize to time T2 and Rebind.)

- Ralph

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 13 Feb 2007 10:21:52 -0800

> Reconfigure-Message option "cancels" the Reconfigure.

I think 3315 does touch on this actually and expresses that this is
"not optimal, but not broken, and highly unlikely."  Something to
that affect.  I got the distinct impression this was left as-is
intentionally.

> which server the client is to communicate with. Should it communicate

I think 3315 is clear on this subject.  It says to follow 18.1.3
precisely except to copy any IA option contents from the IA given
in the Reconfigure (eg any IAADDRs).

This means it would use the previous server's DUID in the global
packet space, any unicast options, etc.

I think with a reconfigure-rebind, we'd want to shift that
a bit, but the existing text is clear.

> This also follows the keep it simple approach?

I'm not sure it's beneficial to adopt "keep it simple" when that
means "it may take 10 minutes to converge."

So for Ralph's first case, yes, for Ralph's second case, I think
we need to do better than that, or to at least allow clients the
option to do better than that.