Subject: A proposal for DHCPv6 reconfiguration

From: Ralph Droms <[email-masked]>
Date: Tue, 06 Feb 2001 18:00:00 -0500

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 server 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: "Thirumalesh Bhat" <[email-masked]>
Date: Tue, 27 Feb 2001 17:21:29 -0800

Ralph, thanks for driving this draft. I have a couple of questions
regarding the paragraphs below:

First:

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.

What is meant by "complete list of clients to be reconfigured?". Is this
something that is implementation specific? For example, the system
administrator might want to specify that clients in subnet should be
reconfigured. Or is this all the clients that are present in the DHCP
Server database?

Second:

 Clients and servers must be able to authenticate
   Reconfigure-init messages, to avoid denial-of-service
   attacks

 How do the clients and servers authenticate reconfigure-init messages?
Is this based on XID? If this is not based on XID, we need a scheme
where there is no user interaction at all.

thx

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Tuesday, February 27, 2001 3: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

This behavior causes the client to ignore duplicate copies of a single

---

From: Ralph Droms <[email-masked]>
Date: Wed, 28 Feb 2001 07:45:18 -0500

At 05:21 PM 2/27/2001 -0800, Thirumalesh Bhat wrote:
>What is meant by "complete list of clients to be reconfigured?".

In the most general sense, the list of clients is completely specified.  It 
may be all of the clients the server has a record of, an administrator 
specified list of clients, all clients that are attached to a link or ???

>  Is this
>something that is implementation specific?

No.

>  For example, the system

Either.

In contrast, if the server is handing out configuration parameters without 
assigning addresses, it may not have a complete list of the clients to be 
reconfigured.

>where there is no user interaction at all.

The clients and servers will use some form of DHCPv6 authentication (the 
mechanism for DHCPv6 authentication is TBD).

- Ralph