Subject: Reconfigure-init message in DHCPv6

From: [email-masked]
Date: Thu, 17 May 2001 10:24:17 +0530

I have a few doubts in draft-ietf-dhc-dhcpv6-18 reconfigure-init messages,
draft18 says, "server may unicat a reconfigure-init messages directly to a
single client or use a multicast....",

If the server wants to multicast the message,
      Do we need to have a predefined 'All DHCP Clients' multicast address
( which is put under discussion in draft) so that the server send the
reconfigure-init message to that multicast address, If so, what should be
the scope of the address? If it is site-local (as put under discussion),
how can a server send a reconfigure-init message to specific subnet (asume
that there is a single server for more than one subnet).

thanks and regards
   Suresh Kodati

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 17 May 2001 08:51:52 -0500

Per discussions during a design team meeting and at the March IETF, we hope to punt on the multicast reconfigure-init support for now. The problem is that security is difficult to do in this situation and making sure that a client doesn't reconfigure multiple times in case the message is sent several times is tricky (and unicast might be needed anyway if only a few clients don't response to the multicast).

See http://www.listproc.bucknell.edu/archives/dhcp-v6/200104/msg00003.html. www.dhcp.org also has some other notes.

- Bernie Volz

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, May 17, 2001 12:54 AM
To: DHCPv6 discussion list
Subject: Reconfigure-init message in DHCPv6

thanks and regards
   Suresh Kodati

---

From: Ralph Droms <[email-masked]>
Date: Wed, 30 May 2001 15:20:48 -0400

At 08:51 AM 5/17/2001 -0500, Bernie Volz (EUD) wrote:

>Per discussions during a design team meeting and at the March IETF, we 
>hope to punt on the multicast reconfigure-init support for now.

Yes, Reconfigure-init will *not* have multicast as an option in the next 
DHCP spec draft.

- Ralph

---

From: [email-masked]
Date: Thu, 31 May 2001 11:41:52 +0530

>Yes, Reconfigure-init will *not* have multicast as an option in the next

I have doubt on how does a server send RECONFIG message If it tries to
reconfigure a network. Does it send
     1) RECONFIG to all the clients once, and waits for REQUEST from
clients.
     (Or)
     2)  it sends RECONFIG messages one by one to all clients and ensures
that all clients gets reconfigured. In that case the server should wait for
RECCREP_MSG_TIMEOUT ( default 2000 ms) for REC_MSG_ATTEMPTS ( default 10)
times, which means it has to wait for 20 seconds for a node, and it may
take too long to configure whole network.

Is the transaction id is going to be same for all messages or different in
both the cases.....

suresh.

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 31 May 2001 04:40:50 -0500

I would think that how a server deals with this is an implementation issue and should not be covered by the protocol. The protocol can accommodate either mode - it really is up to the server to deal with this. I would suspect that (1) is more likely. Perhaps the most typically implementation may be to send requests to <N> clients and then wait for the clients to respond (or timeout) and as they do, send additional requests. This avoids flooding the network with packets and also staggers client responses some. Approach (2) is likely not very good as it would, as you point out, take a very long time if there are a lot of clients.

I don't believe there is any need for the transaction id to be the same for all clients (retransmitted requests to a particular client should use the same id). Note though that there is little reason why the server would necessarily need a new transaction id for each client - it could use the same for all clients if it wanted to. Again, I think this is an implementation issue.

- Bernie Volz

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, May 31, 2001 2:12 AM
To: DHCPv6 discussion list
Cc: [email-masked]; [email-masked]
Subject: RE: Reconfigure-init message in DHCPv6

suresh.

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 31 May 2001 11:34:38 -0500

Ralph:

>How is this, then, different from my proposal?

I don't recall your detailed proposal, so perhaps it is the same? I thought that this was a bit different since it basically incorporates Thomas's proposal for dealing with normal retransmissions (or new reconfigure-inits) in that *ALL* of these are ignored until the client completes the reconfiguration process. The transaction id/time check is ONLY done on reconfigure-inits received AFTER the client has completed the reconfiguration process.

---

I have no major issue if we just say that the transaction id in the reconfigure-init is useless and should be ignored by the client (and the server may supply any value it desires). I think this means that the server never needs to generate transaction ids that have any meaning and that might simplify their implementation.

- Bernie

-----Original Message-----
From: Ralph E. Droms [mailto:[email-masked]]
Sent: Thursday, May 31, 2001 12:24 PM
To: DHCPv6 discussion list
Subject: RE: Reconfigure-init message in DHCPv6

On Thu, 31 May 2001, Bernie Volz (EUD) wrote:
> Why not require that a new transaction id is used for subsequent
> reconfigure-inits? The reason is that this would solve the last problem
> - if a retransmitted or duplicated reconfigure-init is received by the
> client after the Request/Reply exchange has occurred. The only
> additional issue with this is that the server does need to generate
> unique transaction-ids, otherwise it is possible that a transaction id
> is duplicated if a server restarts.

Another issue is that the client will need to remember previous
transaction IDs for some period of time.

> However, this is fairly easy to
> solve at the client by simply adding a time check - ie, if the
> transaction id of a reconfigure-init is the same as the last
> reconfigure-init from that server and was received within <n> seconds of
> the Reply to the Request, treat this as a duplicate; otherwise it is a
> new request.          

How is this, then, different from my proposal?

> I guess if you wanted to go with your proposal, then the transaction id
> in the reconfigure-init is really a don't care field (at least to the
> client) and it can ignore it completely. So, perhaps to make this clear
> it would be good to have the server not supply one or document that it
> is useless. 

Yeah, I agree...

- Ralph