There seems to be some people who do have an interest in quick startup & movement times.
=> in this case they should use dedicated links where DAD is disabled, RAs are used at a silly high rate, etc.
I agree that DAD is not the only issue to look at here -- I once
calculated the number of messages that were required on a wireless
LAN for L2 & L3 network attachment if you needed access control, link layer
security, mobility, and so on. That number was pretty high, over a
dozen even in the most optimistic scenario, significantly worse in
others. And then there were multiple delay periods, all contributing
to the overall delay. DAD is one of these delay periods.
=> so you should agree that dedicated links are a good solution,
and no DAD is a part of the specific tuning.
Ok. I'm beginning to understand your point... Yes, disabling DAD is indeed possible today via setting DupAddrDetectTransmits to zero. And some important link layers are using this approach, typically combined with something else that ensures duplicates are not generated in the first place. For instance, RFC 3316 says what 3G mobile phones do in this respect. For these link layers optimistic DAD will not help, as there was no delay to begin with.
On the other hand, these link layers are not the only ones available. Ethernet-type link layers are important too, and there we don't have any convenient mechanism to avoid duplicates besides DAD; and I personally would say that I'd rather leave DAD turned on in my wireless LAN.
Now, from the point of view of an end user, this implies that there are the following choices:
1. Start using a link layer technology where dedicated links are possible and DAD disabling does not cause duplicates. No delays involved.
2. Use a link layer where dedicated links are not possible, and disable DAD, accept the risk of collisions. No delays involved here either.
3. Use a link layer where dedicated links are not possible, keep using DAD. Delay introduced into movements and attachments.
I think the desire to provide an optimized DAD procedure comes from the fact that people are stuck with a given link layer technology but are still uncomfortable with either option 2 or 3. That is, they would rather have
4. Use a link layer where dedicated links are not possible, keep using DAD to prevent collisions, but do this in a smarter way which avoids delays.
This would be the "eat the cake and save it too" option, which in this case is possible if new protocols are introduced.
--Jari
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
