RE: [dhcwg] How should a DHCPv6 server respond to retransmitted p ackets

["Bernie Volz (EUD)" <[e-mail]>]

The reply using (c) should generally be similar enough not to be a concern - but this is important for the server implementor to consider. In particular, Information-Request is likely not to generate any difference except of the configuration information of the server has changed OR it is doing some "round-robining" of parameters (such as the addresses of the DNS server) - even in this case, there is no problem.

For the case of Request/Renew/Release/Decline, this may indeed generate some differences but again this should not be an issue:
- For a Request, the server must take care to give the client addresses it has previously allocated for the IAID and IA type.
- For a Request/Renew, the lifetimes may have changed slightly (but as long as the server takes care not to reduce the lifetimes from what it sent earlier, this should not matter).
- For Release/Decline, the Reply to the retransmitted Release/Decline may indeed contain slightly different information as discussed in the draft:
   For each IA in the Release
   message for which the server has no binding information, the server
   adds an IA option using the IAID from the Release message and
   includes a Status Code option with the value NoBinding in the IA
   option.  No other options are included in the IA option.
But, as also mentioned in the draft, a Client should accept this status code.

- Bernie Volz

-----Original Message-----
From: Raymond J. Jayabal [mailto:[e-mail]]
Sent: Friday, October 25, 2002 2:28 PM
To: [e-mail]
Cc: [e-mail]
Subject: Re: [dhcwg] How should a DHCPv6 server respond to retransmitted
packets


Hi,

Stumbled upon what may or may not be a problem, given that (b) is an
acceptable alternative to (c), as follows.

                              *  *  *

Whether (b) or (c), the client will receive 2 or more REPLY packets.

As the client will leave its 'waiting-for-REPLY' state when it receives
REPLY #1, I assume it will drop REPLY #2 and subsequent REPLY packets
and configure itself based on REPLY #1.

Further assume that the server (or the network it serves, or the
information services it rely on to satisfy client requests) is in
State-1 when request #1 arrives, and State-2 when request #2 arrives.

If (b) is allowed, then the REPLY packets will differ in content. Since
REPLY #2 is last to leave the server, it would have committed to memory
that it sent State-2 data to the client, whereas the client would have
configured itself with State-1 data. This doesn't seem to be a good
situation in the general sense, even if it happens for a short while.

In case of (c), both client and server will always be synchronised.
When State-2 happens, server will know exactly which clients need
updating.

Does this disqualify (b) as an alternative? Or is it still an acceptable
implementation?

- Ray


----- Original Message -----
From: "Ralph Droms" <[e-mail]>
To: "Raymond Jayaraj" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Friday, October 25, 2002 8:41 PM
Subject: Re: [dhcwg] How should a DHCPv6 server respond to retransmitted
packets


> In the case of Information-request, the answer is (b) or (c), depending on
> the implementation.  The responses to retransmitted Informat-request
> messages are likely to be identical, so the use of a response cache
> shouldn't affect the results of the message exchange.
>
> - Ralph
>
> At 10:26 AM 10/25/2002 +0800, Raymond Jayaraj wrote:
> >Hi all,
> >
> >How should a server respond to retransmitted packets
> >received after a
> >REPLY packet is sent, e.g.:
> >
> >DHC6CLIENT      DHC6SERVER      INFOSERVER
> >|               |               (e.g. LDAP)
> >|               |               |
> >|1)INFO-REQ     |               |
> >|>>>            |               |
> >|   >>>         |               |
> >|      >>>      |               |
> >|         >>>   |               |
> >|            >>>|2)processing/retrieve info
> >|3)INFO-REQ     |>>>>>>>>>>>>>>>|
> >|>>>            |<<<<<<<<<<<<<<<|
> >|   >>>      <<<|               |
> >|      >>><<<   |               |
> >|      <<<>>>   |               |
> >|   <<<      >>>|               |
> >|<<< 4)REPLY    |5)???          |
> >
> >What should (5) be? Should the server:
> >
> >a) drop (3) and subsequent duplicates (base on
> >transaction id).
> >
> >b) reprocess the request and retransmit the reply,
> >i.e. do (2)&(4)
> >    again.
> >
> >c) retransmit the reply, i.e. do (4) again.
> >
> >d) do any of the above (implementation specific).
> >
> >No indication for the above could be found in the
> >draft. I suspect
> >it should be a) or d), but it'd be nice to know for
> >sure.
> >
> >------------------------------------------------------------------------
> >Raymond J. Jayabal                 | ICR, A-STAR
> >[e-mail]         | 20 Science Park
> >Rd #02-34/37
> >Tel: [phone]                 | Singapore 117674
> >------------------------------------------------------------------------
> >
> >
> >
> >
> >__________________________________________________
> >Do You Yahoo!?
> >Great flight deals, travel info and prizes!
> >http://sg.travel.yahoo.com
> >_______________________________________________
> >dhcwg mailing list
> >[e-mail]
> >https://www1.ietf.org/mailman/listinfo/dhcwg

__________________________________________________
Do You Yahoo!?
Great flight deals, travel info and prizes!
http://sg.travel.yahoo.com
_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg