Why is solving the problems with a DAD change not a perfect solution ?
The problems are serious enough for deployed codebase to change. It's
not like we are asking to replace IPv6 hardware. It's a software change
for deployed code base. Anyhow, Tatuya has already said most hosts he
has tested with do not skip DAD. We have also tested hosts that do not
skip DAD. So what codebase and what specific hosts/nodes are you talking
about ?

Thanks.

Hemant

-----Original Message-----
From: Jun-ichiro itojun Hagino [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, June 26, 2007 10:16 AM
To: Hemant Singh (shemant)
Cc: [EMAIL PROTECTED]; ipv6@ietf.org;
[EMAIL PROTECTED]; Fred Baker (fred)
Subject: RE: draft-wbeebee-nd-implementation-pitfalls-00 with urgent
changessuggested to 2462bis-08

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

Reply via email to