On 2004-02-26, Markku Savela wrote:
>
> Yes, DIID probably (or something similar). I believe that simplest
> solution is that a specific ID value can be allowed only for single
> node on the link. Any use of same ID part with any prefix by another
> node should be viewed as an address collision.
I can see where you are coming from: for DAD to safely
interoperate with DIID it must send even more messages: wouldn't
it be nice to just send a single NS/NA pair? After all,
DIID is already compatible with DIID.
I'm convinced that a change needs to be made to the wording to
resolve this issue, but I'm not sure which is the better option.
I'm also dubious about relying on votes at IETF meetings for
technical issues ... because often an option which seems 'obvious'
at the time actually isn't once the drafts have been considered
in detail. And most of the WG attendees won't have considered
them in detail before the meeting. Sad but true.
Questions for the group:
* DIID offers less signalling. What advantages does DAD offer?
* Does DAD retain these advantages when made compatible with DIID?
(by testing/defending LL::X, as per my earlier suggestion)
* Can backwards compatibility be dispensed with?
(I'm going to be a hard sell on that one ...)
To be honest, unless there's some advantage to DAD which I
haven't thought of, I'm starting to lean back towards DIID ...
although since I'm keen on crypto and privacy addresses, I
guess that's really Duplicate Suffix Detection (DSD), eh?
-----Nick
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
