Subject: RE: A proposal for DHCPv6 reconfiguration

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 1 Mar 2001 08:46:04 -0600

Ralph:

What are the requirements on the client as to how long it must retain the XID (and server address) for RECONFIGURE-INIT messages that it receives? Must it just keep one per server? Or? For how long must these be retained (5 minutes, until reboot)?

I also agree with Erik that the delay parameter should be required, not optional.

>As an aside, the behavior of a client that receives a
>Reconfigure-init while expecting an Advertise or Reply
>is not currently defined and is TBD.

Regarding this issue, are you referring to whether the client sends a Reply to the Reconfigure-Init or whether the client does the reconfiguration? I do think it should send a Reply (that way, if the server is keeping track of the clients, it can know that this client responded). Whether the client does the reconfigure depends on whether it has already obtained any configuration information or not. If it is waiting for an Advertise (and has no configuration data), it should just continue. If waiting for a Reply, I would think it best to continue waiting for that Reply and reconfiguring afterwards?

- Bernie Volz
  Ericsson

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Tuesday, February 27, 2001 6:14 PM
To: DHCPv6 discussion list
Subject: A proposal for DHCPv6 reconfiguration

Jim and I are finishing up the -17 rev of the DHCPv6 spec.  I never saw any 
response to the following message.  Unless I hear something different, this 
is what will go in the spec.

- Ralph

Assuming I got the list of multicast reconfigure issues from San Diego 
right, here is a list of goals for server-initiated configuration:

* When the server has a complete list of the clients to be
   reconfigured, the server will know reliably that each
   client has either been reconfigured exactly once or has
   not responded to the server's reconfiguration request
* When the server does not have a complete list of clients,
   the server will have some assurance that each client has
   received at least one Reconfigure-init message
* Wherever possible, redundant or gratuitous reconfiguration
   of clients will be avoided (even though reconfiguring
   more than once should not affect correct client operation)
* Clients and servers must be able to authenticate
   Reconfigure-init messages, to avoid denial-of-service
   attacks

Here's my proposal for server-initiated configuration, intended
to meet the listed goals (except for multicast authentication,
which I don't have a solution for):

Reliable unicast transmission can be managed through the use of the
transaction-id.  The server includes a unique transaction ID in each
unicast Reconfigure-init message.  The client responds to the first
Reconfigure-init message it receives, copying the transaction ID into
the Reply message the client sends to the server, and ignores all
subsequent Reconfigure-init messages with the same transaction ID.
This behavior causes the client to ignore duplicate copies of a single
Reconfigure-init message.  If the server does not receive a Reply to
the Reconfigure-init with a matching transaction ID, the server can
try again by transmitting a new Reconfigure-init with a new
transaction ID.  The new transaction ID will cause the client to start
the reconfiguration process again, in case the client did not receive
earlier Reconfigure-init messages or the server did not receive the
client's Reply.  The delay before a server retries with a new
Reconfigure-init, the number of times the server should retry before
giving up and the server's action when it can't reach a client are
TBD.

As an aside, the behavior of a client that receives a
Reconfigure-init while expecting an Advertise or Reply
is not currently defined and is TBD.

For reconfiguration using multicast, the server multicasts an initial
message Reconfigure-init several times with the same transaction ID.
The number of retransmissions and the delay between retransmissions is
TBD.  The client behavior is the same as in the unicast
Reocnfigure-inti message: each client in the multicast group to which
the Reconfigure-init message was transmitted responds to first message
it receives (not necessarily the first message transmitted by the
server) and ignores all other Reconfigure-init messages with the same
transaction ID.  The server maintains a list of those clients that
have responded to the multicast Reconfigure-init message.  After the
multicast Reconfigure-init messages have been transmitted, the server
reverts to unicast with new transaction ID for clients that have not
responded respond.

To reduce the number of simultaneous Replies recieved by a server,
the server can include a delay parameter in the Reconfigure-init
message.  Clients then choose random time between 0 and the
delay parameter to respond with a Reply message.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 01 Mar 2001 10:20:45 -0500

At 08:46 AM 3/1/2001 -0600, you wrote:
>What are the requirements on the client as to how long it must retain the 
>XID (and server address) for RECONFIGURE-INIT messages that it receives? 
>Must it just keep one per server? Or? For how long must these be retained 
>(5 minutes, until reboot)?

I don't know - TBD.  Off the top of my head, I'd say keep info on all 
messages for twice the maximum retransmission duration (i.e., time over 
which a server will retransmit) for a multicast message.  I compute the 
total server retransmission time to be 2047 seconds (about 35 minutes) 
using the numbers in the current draft, so I would suggest we have the 
client hold on to the Reconfigure-init message information for an hour.

>I also agree with Erik that the delay parameter should be required, not 

Suppose we define a mandatory default that can be optionally modified?

>Regarding this issue, are you referring to whether the client sends a 
>Reply to the Reconfigure-Init or whether the client does the 
>reconfiguration? I do think it should send a Reply (that way, if the 
>server is keeping track of the clients, it can know that this client 
>responded). Whether the client does the reconfigure depends on whether it 
>has already obtained any configuration information or not. If it is 
>waiting for an Advertise (and has no configuration data), it should just 
>continue. If waiting for a Reply, I would think it best to continue 
>waiting for that Reply and reconfiguring afterwards?

In the current spec, clients respond to a Reconfigure-init with a Request 
message (this is the "reconfigure as trigger" model). Only servers send 
Reply messages in the current spec.

We could specify that the client always initiates a Request-Reply 
transaction when it receives a Reconfigure-init, regardless of the client's 
current state.  Here are the two cases:

* Sent Solicit, waiting for Advertise - client is
   looking for a server.  It can use the server in
   the Reconfigure-init and send a Request to that
   server

* Sent Request/Renew/Rebind, waiting for Reply - info
   in Reply after Reconfigure-init is likely to be more
   current than in Reply to previous message, so send
   new Request and ignore Reply to earlier message

- Ralph

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 1 Mar 2001 09:43:11 -0600

See below (prefixed by BV>).

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Thursday, March 01, 2001 10:21 AM
To: DHCPv6 discussion list
Subject: RE: A proposal for DHCPv6 reconfiguration

BV> That would also work. But, it means another client side configuration parameter
BV> and specifying a default value. I'd prefer to have to set it in ONE place
BV> and so I'd prefer to make it mandatory on the server. Of course, it would be
BV> sent as an option, so the question is what is a client to do if there is no
BV> option - I'd say IGNORE the Reconfigure-Init as it is a bogus request.

BV> I was using terminology from your original message. Such as:
BV> "If the server does not receive a Reply to the Reconfigure-init
BV> with a matching transaction ID ...". So, hopefully that text did not
BV> come from the draft.

* Sent Solicit, waiting for Advertise - client is
   looking for a server.  It can use the server in
   the Reconfigure-init and send a Request to that
   server
BV> In this case, it seems better to ignore the Reconfigure-Init unless the
BV> client already has addresses and then it should do the Request to the
BV> server.

BV> That sounds OK.

- Ralph

BV> Another issue, if the Reconfigure-Init causes a Request, the Transaction-ID
BV> for the Request can't really be copied from the Reconfigure-Init as that
BV> would mix two transaction-Id number spaces (one from the client and one from
BV> the server). Did we solve this by having a "Reconfigure-XID" option that is
BV> used by the client to specify that the Request is in response to a
BV> Reconfigure-Init with the transaction ID in the message? Or am I confused.

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 1 Mar 2001 17:55:51 +0100 (CET)

>  How does the client differentiate between an intentional retransmission and 
> a duplicated Reconfigure-init?  The client should remain silent when it  >
receives a duplicated Reconfigure-init.

Exactly the same way TCP does. By NOT differentiating.
Duplication by the network is rare so this doesn't normally cause
a problem for TCP, except lowered performance for the TCP connection
due to more ACKs being sent.

But in any case, the proposed design looks reasonable now that I understand
it a bit more.

  Erik

---

From: Ralph Droms <[email-masked]>
Date: Wed, 07 Mar 2001 06:34:38 -0500

At 09:43 AM 3/1/2001 -0600, Bernie Volz (EUD) wrote:

>From: Ralph Droms [<mailto:[email-masked]>mailto:[email-masked]]

OK.  This issue should be on our design team teleconference agenda next week.

>BV> with a matching transaction ID ...". So, hopefully that text did not

Oops.  Thanks for catching that goof on my part.  The draft reads (correctly):

    If the server does not receive a Request message from the client
    in RECREP_MSG_TIMEOUT milliseconds, the server retransmits
    the Reconfigure-init message, doubles the RECREP_MSG_TIMEOUT
    value and waits again.

>BV> client already has addresses and then it should do the Request to the

Hm.  I don't see why the client's behavior would change if it has
addresses.

Sounds like another issues for design team teleconference.

>BV> Reconfigure-Init with the transaction ID in the message? Or am I 

No - there is no mechanism to disambiguate client-initiated and
server-initiated Request messages.  Thus, a transaction-ID
from a server could collide with a client-selected transaction-ID.
I like your Reconfigure-XID option.

- Ralph

---

From: Thomas Narten <[email-masked]>
Date: Fri, 09 Mar 2001 09:19:16 -0500

> subsequent Reconfigure-init messages with the same transaction ID.

Unless I'm misunderstanding something basic, I don't think you want to
do this. If the client's reply is lost, a simple server retransmission
of the RI (request init) won't force the client to retransmit. I.e.,
the client has to wait much longer before being allowed to retransmit
its Request. This isn't good protocol design.

> transaction ID.

Why can't a client retransmit its request? What breaks? Indeed, the
normal behavior is for clients to retransmit request messages. What is
different here?

The way I had been thinking about this is as follows:

1) Server sends a reconfigure with ID x.

2) Whenever a client gets a reconfigure for x, it records that and
   goes into a the state (sorry jim!) that means "time to contact the
   server again". In this state, the client retransmits the Request
   until it gets a RESPONSE. Note: this would seem to me to be exactly
   the same state as already exists in the DHCPv6 protocol as part of
   normal interactions with the server, so no new code
   
3) Client ignores all retransmissions of RECONFIG that have an id x
   that they already know about. But because step 2) includes
   retransmissions, ignoring retransmissions works fine.

4) The server doesn't need to see a Request with a particular XID
   (e.g., the one in the RI); what it looks for is a Request message
   from the client that was received more recently than when the first
   RI was sent.

Does this make sense?

Thomas

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Sun, 11 Mar 2001 22:41:19 -0600

Thomas ... I think it does. It also gets rid of the nasty problem with having clients pick up and use the server's transaction-id, which could collide with one of the client's own choosing (I had suggested we use a RECONFIG-XID option to communicate that in the Request but no need now).

I was reading the -18 draft and re-read this and I think this does solve the problem nicely. Who cares why the Request came in is correct - it really doesn't matter (as long as the request happened after the Reconfigure-Init, as you say).

Now I have to go change my comments on the -18 draft to reflect this.

There is, however, one minor issue we probably should discuss. By using the Request message type, we're really overloading this to mean "Give me (new) addresses" and "Reconfigure requested, what's new?". (We unloaded it from meaning Renew, Rebind, & Confirm). Perhaps we should not use the Request message and instead define a new one - Reconfigure-Request or some such name. This would essentially be identical to how the Request is used now for Reconfigure-Init, but would be clear to the server that the client has receive the Reconfigure-Init request. (The server SHOULD also consider any Request messages received from clients that arrive after the Reconfigure-Init to flag that client as having responded to the Reconfigure-Init; whether it actually did or not, is immaterial.)

- Bernie Volz

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]]
Sent: Friday, March 09, 2001 9:19 AM
To: DHCPv6 discussion list
Subject: Re: A proposal for DHCPv6 reconfiguration 

   

Does this make sense?

Thomas