[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
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
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------