> Tatuya,
>
> OK, it's alright to say an accident, but this accident caused the
> security problem because we still think if Host1 is receiving traffic
> that was meant to go to Host2, it's a security problem.
>
> You also described the other security problem case where you said, Host1
> is not compliant to IPv6 standards and deliberately malicious and we
> granted you the fact that Host1 being a rouge can decide to ignore the
> NS(DAD) from Host2. But even in this case the rtr will be able to detect
> the problem if our proposed solution is applied - the solution being
> Host2 will not skip DAD for GUA.
i fail to understand why this is a new problem for you. the problem
exists with ARP, and the only solution for the operator would be to
pin down MAC address caches on the ethernet switch (L2 solution), or
deploy secure neighbor discovery (L3 solution, which is very difficult,
RFC3971 sizes 123Kbytes!). why do you think we have to solve it with
DAD change, which is not a perfect solution and incompatible with the
deployed codebase?
[EMAIL PROTECTED] then spec
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
