Re: comments on draft-ietf-zeroconf-ipv4-linklocal-08.txt

Mika Liljeberg <[email protected]>
Newsgroups gmane.ietf.zeroconf
Message-ID <1059752099.718.13.camel@hades>
On Fri, 2003-08-01 at 15:25, Erik Guttman wrote:
> > c) I conclude:  If the applicability of this protocol includes
> >    networks for which a  1 second round-trip latency can exist, it is
> >    quite possible that all the probes will be answered by the host
> >    sending the probes will ignore the replies.
> 
> it is quite possible for that all the probes will be answered, but the
> host sending the probes will ignore the replies.

Aagh, let's stop turning the knob and put the knob in the specification
instead. Here's IPv6 DAD for comparison [rfc2462]:

   "To check an address, a node sends DupAddrDetectTransmits Neighbor
   Solicitations, each separated by RetransTimer milliseconds. The
   solicitation's Target Address is set to the address being checked,
   the IP source is set to the unspecified address and the IP
   destination is set to the solicited-node multicast address of the
   target address.

   If the Neighbor Solicitation is the first message to be sent from an
   interface after interface (re)initialization, the node should delay
   sending the message by a random delay between 0 and
   MAX_RTR_SOLICITATION_DELAY as specified in [DISCOVERY].  This serves
   to alleviate congestion when many nodes start up on the link at the
   same time, such as after a power failure, and may help to avoid race
   conditions when more than one node is trying to solicit for the same
   address at the same time. In order to improve the robustness of the
   Duplicate Address Detection algorithm, an interface MUST receive and
   process datagrams sent to the all-nodes multicast address or
   solicited-node multicast address of the tentative address while
   delaying transmission of the initial Neighbor Solicitation."

Default values:
	DupAddrDetectTransmits 		1
	RetransTime			1 second
	MAX_RTR_SOLICITATION_DELAY	1 second

IPv6 DAD takes 1..2 seconds with default parameters. I see absolutely no
reason to reinvent the wheel for v4LL. Retransmissions only make sense
for reducing failure probability in case there is an address collission
(implies picking a new LL for the retransmit). I would allow up to 4
retries. If there is no address collision, retransmitting DAD is a waste
of time. The parameters can always be tuned for unusual environments.

10 seconds is way too slow.

	MikaL
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.