Hi Francis, > => 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. >
So let me ask a question. If you believe optimized DAD is a half baked solution then why isn't DAD also a half baked solution? The reason I ask this is because both don't really do anything to get rid of address collisons, they just provide a procedure for detecting them. The difference is that optimized DAD is intended to fail more quickly and allow a node to use the address while it is tentative. Now it is possible that the protocol described in Nick's draft has some flaws that would cause problems for detection, but I don't think that should stop us from trying to figure out some way of improving DAD so it functions better for mobile nodes. > => the problem is the goal of optimistic/optimized DAD has no interest. > Well, that certainly isn't the case for me, and I will take the liberty of saying that I believe most mobile wireless service providers interested in IPv6 would agree. >> => what we need is collision avoidance, no collision detection after > damage. > Ah, now I believe I understand your objections better. I agree this would be ideal, as this could replace DAD as well. Perhaps you'd like to make a proposal? It seems like it might be difficult to provably prevent collisions though. > 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) As I believe Nick mentions in the draft, this doesn't guarantee uniqueness because mistakes sometimes occur in manufacturer assignment of addresses, and there is also the possibility of attacks. > - 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... > What about DHCP? Perhaps you believe that DHCP will never be used in IPv6 networks, but there are some people who believe it will still be important. jak -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
