Subject: A proposal for DHCPv6 reconfiguration

From: Ralph Droms <[email-masked]>
Date: Tue, 27 Feb 2001 18:14:08 -0500

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: Erik Nordmark <[email-masked]>
Date: Wed, 28 Feb 2001 15:48:02 +0100 (CET)

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

I assume you mean "with the same transaction ID from the same DHCP server"
in the last sentence.

> giving up and the server's action when it can't reach a client are

This seems a bit strange (but I don't have an alternate proposal) - are
we really chartering new territory here?
The strange part is that the server needs on retransmit strategy for
a lost reconfigure-init (retransmit with same ID) and a different
retransmit strategy for a lost reply (retransmit with a new ID).
And of course the server can't tell which packet was lost.

Will the latter part (use a new transaction id) be limited to
unicast?

Assuming the above is limited to unicast, what is the harm in the client
keeping a copy of the last reply and retransmitting that reply
when it sees a reconfigure-init which matches the last transaction ID?
Then the server can have a simpler retransmit strategy for the unicast case.

> reverts to unicast with new transaction ID for clients that have not

That's fine.

> delay parameter to respond with a Reply message.

I think the delay parameter should be mandatory in the multicast case.
I wonder if we should suggest a default value for the delay the server
should send in this parameter (e.g. <number of members in group> * N 
milliseconds)

  Erik

---

From: Ralph Droms <[email-masked]>
Date: Wed, 28 Feb 2001 12:57:30 -0500

>I assume you mean "with the same transaction ID from the same DHCP server"

Yes.  I'll make that clear in the spec.

>And of course the server can't tell which packet was lost.

The server always uses a new transaction-ID when retransmitting a
unicast Reconfigure-init.  The client ignores Reconfigure-init
messages with the same transaction-ID to filter (unintentional;
i.e. spuriously generated by network elements) duplicates of
the original Reconfigure-init message.  This issue was raised
during the WG discussion in San Diego.

>Will the latter part (use a new transaction id) be limited to

No - it applies to both unicast and multicast.  When using multicast, the 
server transmits a some number of Reconfigure-init messages on a schedule 
that uses exponential backoff (this machinery is in the -17 rev of the 
spec).  From the WG discussion in San Diego, the motivation for using 
multicast is the case in which the server doesn't have a complete list of 
clients.  In this case, the server can't guarantee reliable delivery - so 
the suggestion was to provide some measure of reliability through 
retransmission of the same message in the multicast case.

One design goal here is to avoid the need for the client to differentiate 
between unicast and multicast Reconfigure-init messages.  After I thought 
about the problem for a while - considering both the retransmission and 
message duplication cases - this design seemed like an elegant way to

* avoid redundant receonfiguration triggered by
   duplicate Reconfigure-init messages
* allow reliable reconfiguration through retransmission
   of unicast Reconfigure-init messages
* allow for extra reliability through retransmission
   of multicast Reconfigure-init messages without
   causing some clients to reconfigure multiple times
* simplify the client by specifying the same behavior
   in response to both unicast and multicast
   Reconfigure-init messages

>Then the server can have a simpler retransmit strategy for the unicast case.

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.

> > Reocnfigure-init message: each client in the multicast group to which

OK, making the delay mandatory sounds sensible.

- Ralph