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

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Fri, 25 Oct 2002 07:26:31 -0500

This is implementation specific. It is important to respond.

Whether the server keeps an Transaction ID cache and responds from that or reprocesses the packet is really a server implementation issue.

- Bernie

-----Original Message-----
From: Raymond Jayaraj [mailto:[email-masked]]
Sent: Thursday, October 24, 2002 10:27 PM
To: [email-masked]
Cc: [email-masked]
Subject: [dhcwg] How should a DHCPv6 server respond to retransmitted
packets

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
[email-masked]         | 20 Science Park
Rd #02-34/37
Tel: +65 6870 9330                 | Singapore 117674
------------------------------------------------------------------------

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

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Sun, 27 Oct 2002 08:33:19 -0600

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:[email-masked]]
Sent: Friday, October 25, 2002 2:28 PM
To: [email-masked]
Cc: [email-masked]
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" <[email-masked]>
To: "Raymond Jayaraj" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
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,
> >