[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rfc2462bis issue 275] DAD text inconsistencies

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

>    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.


IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6