Subject: Re: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9, 18 o n Conference Call Agenda)

From: Jim Bound <[email-masked]>
Date: Wed, 20 Sep 2000 20:40:03 -0400

>You might also solve them by:
>- Having the client remember the "transaction id" / server source address
>and dropping any reconfigure messages with the same transaction id received
>within some time period (several minutes?). Of course, all subsequent
>retransmitted reconfigure messages MUST use the same "transaction id".
>- Having the client ignore additional multicast reconfigure messages (on the
>same interface) for some time period after receiving one (again, several
>minutes). This method has the added benefit that fake messages can't
>repeatedly trigger reconfigurations except at some reasonable slow rate. Of
>coures, it makes multiple renumbering events take longer (but that they'd
>occur within minutes of each other is rather unlikely anyway).

Yes this would work.  But I think the idea Ralph proposed by server does
multicast once for trigger reconfigure-init and then unicast for those
that did not respond is a simpler solution for now?  A more complex
solution later can be adapted or extended later from what Ralph
proposed pretty easily.  But I do think your idea has much merit.

>I do think the technique in 12.4.2 is somewhat flawed anyway since if one or
>more clients are down, the "expected" number of messages may never be
>returned.

That would need to be fixed I thought we put wording about this
elsewhere but I will check, it might be we only did it for the
reconfigure and not the reconfigure-reply.

>I think a better server strategy is to multicast several Reconfigure
>messages several seconds apart (this presumes that a client hopefully won't
>miss all if it is up and on the network). Then, if any clients fail to
>respond within the alloted time, those clients are sent unicast packets.
>(Perhaps the server can also make a determination of how many clients failed
>to response and if it exceeds some threshold (>50?), it MAY multicast again
>with the same transaction-id).

We did put threshold in there for reconfigure.  But I agree this can
work as you suggest.

Also I think we have to assume one multicast message normally works or
we are not really assuming multicast works.  There should be no reason
to send multiple multicast messages unless there is a network problem.
I suppose if no one responds and then unicasting a few to see if it
works would be a good way to implemement this (not saying put this in
the spec).

regards,
/jim