> 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 ?
i'm very sorry, i think i did not do the homework hard enough.
i reread the whole thread and i think your abstract on the i-d is
a bit misleading. from the word "new requirement" i read that (i guess
between the line) there are code changes to the deployed codebase which
implements DAD correctly. the fact is that you are proposing changes
to make DAD a MUST instead of SHOULD (from section 5 of your draft).
jinmei (who is KAME colleague of mine as you know) is very careful guy
and he cares about other careless implementations which skips DAD :-)
i do not care about careless implementations unlike jinmei, however,
i still think that your security model with "DAD is a MUST" is not
perfect.
yes, which DAD being MUST it would be a better world order. however,
because this is based on the assumption that all of the implementations
would follow the RFC to secure the link, a clever attacker would get
a freely-available IPv6 implementation, "#if 0" the portion which does
DAD and steal traffic anyway (or implement something on BPF writes or
raw IPv6 sockets).
so, as i said, the only solution is either to pin-down MAC address
cache (L2) or do some cryptographic dance (L3). L3 stuff still require
every node to cooperate, i think the only solution is in L2.
CISCO can sell a lot of L2 devices with the feature :-P
itojun
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
