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