In your previous mail you wrote: > => just ask large network managers. Address duplication is a real > nightmare to fix in the real world. Sure. But aren't you assuming that they have to go in and manually recover?
=> it is the case for IPv4 because this kind of event is very rare so there is no need to add an automatic recover tool. But IMHO the real question is where are these problems for? They don't come from hazard but in 99.99% of cases from configuration errors. I believe what the optimistic or optimized DAD folks intend to do is to provide a *protocol* that allows both (a) faster operation and (b) recovery if a collision happens. => this is a half baked solution, i.e., either you don't want duplicates on your network and you enforce DAD, or you accept possible problems and you makes the live of mobile nodes (and of implementors) far easier. I am unable to say for sure if, say, draft-moore, accomplishes this goal. It probably needs more analysis before we can be certain. However, I do not see any obvious problems. => the problem is the goal of optimistic/optimized DAD has no interest. Note: In some cases the collisions is due to L2 address collision, which I agree is quite troublesome. => L2 address collisions are fatal. And IMHO we should not even try to solve them at L3 (:-). But optimistic DAD does not appear to change anything with regards to this. If you get a collision then you detect that with optimistic DAD as well, and then follow 2462bis rules to disable the interface, or whatever that was required. => what we need is collision avoidance, no collision detection after damage. And in many cases the address collision is not based on L2. => currently there are three common ways to assign addresses: - EUI64 based, i.e., relying on L2 address universal uniqueness (read my EMEI draft to use it on mobile phones too) - RFC 3401, i.e., relying on the "birthday" paradox - manual, i.e., relying on the care of node managers. Obviously only the last one is a real source of trouble. Unfortunately it is a common case for routers (EUI64 requires that you work only with a mouse and cut&paste), some servers (DNS servers for instance, when you look at http://www.root-servers.org/ you get no EUI64 based IID) and some other cases (multi-interface KAME hosts here). But this should be easy to avoid this case on a link dedicated to mobile nodes... Regards [EMAIL PROTECTED] -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
