Subject: RE: Reconfigure-init message in DHCPv6

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

Ralph:

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. 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.

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.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Thursday, May 31, 2001 10:08 AM
To: DHCPv6 discussion list
Subject: RE: Reconfigure-init message in DHCPv6

Oops, sorry.  I responded without thinking all the way through Thomas' 
suggested mechanism for Reconfigure-init - in fact, I think it actually 
does solve the transaction ID problem...

As I understand it, the Reconfigure-init message acts as a trigger that 
signals the client to complete a successful Request/Reply message 
exchange.  Once the client has received a Recongfigure-init, the client 
proceeds with the Request/Reply message exchange (retransmitting the 
Request if necessary); the client ignores any additional Reconfigure-init 
messages (regardless of the transaction ID in the Reconfigure-init message) 
until the Request/Reply exchange is complete.  Subsequent Reconfigure-init 
messages (again independent of the transaction ID) cause the client to 
initiate a new Request/Reply exchange.

OK, so how does this mechanism work in the face of duplicated or 
retransmitted Reconfigure-init messages?  Duplicate messages will be 
ignored because the client will begin the Request/Reply exchange after the 
receipt of the first Reconfigure-init.  Retransmitted messages will either 
trigger the Request/Reply exchange (if the first Reconfigure-init was not 
received by the client) or will be ignored.  The server can discontinue 
retransmission of Reconfigure-init messages to the client once the server 
receives the client's Request.

It might be possible for a duplicate or retransmitted Reconfigure-init to 
be sufficiently delayed (and delivered out of order) to arrive at the 
client after the Request/Reply exchange (initiated by the original 
Reconfigure-init) has been completed.  In this case, the client would 
initiate a redundant Request/Reply exchange.  I think (although I could be 
convinced otherwise) that the likelihood of delayed and out of order 
delivery is small enough to be ignored.  Also, the consequence of the 
redundant exchange is inefficiency rather than incorrect operation.

I'll write up this new mechanism in the next draft of the spec.

- Ralph

At 06:21 AM 5/31/2001 -0400, Ralph Droms wrote:
>I agree with Bernie that the mechanisms for sending Reconfigure-init to 
>multiple clients is an implementation issue and shouldn't be specified in 
>the spec.
>
>The next draft will use a slightly different strategy for the transaction 
>ID.  As suggested by Thomas Narten, the transaction ID in the client's 
>Request message can be independent of the transaction ID in the 
>Reconfigure-init message.
>
>However, we still have an issue with the transaction ID in retransmitted 
>Reconfigure-init messages.  If the server uses the same transaction ID in 
>a retransmitted message, how does the client differentiate retransmission 
>from duplicate messages?
>
>- Ralph
>
>At 04:40 AM 5/31/2001 -0500, Bernie Volz (EUD) wrote:
>
>>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]>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
>>
>>
>> >>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
>>
>>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: "Ralph E. Droms" <[email-masked]>
Date: Thu, 31 May 2001 12:24:13 -0400 (EDT)

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