Thomas Narten wrote:
>
> I've reviewed this document and on the whole think it's fine for PS.
Thanks. Sorry it's taken a little while for me to get back to you,
I had a couple of other things on. It looks like the IESG assessment
has been pretty positive, though.
[talking here about sect 2.3 / sect 3.2 rule 4.]
> Am I understanding correctly that not implementing the SHOULD
> effectively negates the benefits of implementing the spec?
Partly.
Optimistic DAD is very much a compromise. It's trying to be
backwards compatible with normal routers and hosts, and it's
trying not to be too slow, unsafe or complicated. If we could
have started again with a clean slate, we could have come
up with something much nicer. But it wouldn't have worked
with existing IPv6 infrastructure ...
The problem being that we've only got half of the NS/NA mechanism
available, because of the problem with sending LL address options
and overriding NC entries.
> Well, maybe it depends also on what one expects the first packets to
> be that a node sends. I.e., if they are for non-neighbors (i.e.,
> off-link) and would go through the router, then that traffic would get
> sent immediately.
In a lot of cases, a mobile node won't care who is on its local
net ... it's trying to quickly hand over from one net to another
so it can keep on talking to someone on a third net, far away.
So long as the new router broadcasts its LL address, OptiDAD works
fine in this case.
> But it appears that at least when sending to
> neighbors, not implementing the SHOULDs results in no reduction in
> delay.
That's true. The reasons why I left it a SHOULD:
a) it's not always necessary. Not all applications will care about
talking to neighbours quickly. Those that don't have no
need of this mechanism.
b) it's not always sufficient. The router only SHOULD behave that
way in a redirect. It might not, in which case we're back
to waiting 1000ms anyway.
c) it may be a pain to implement, and I'd rather that implementors
have something implementable, rather than just doing the
bits they need to do for their application and silently
dropping the rest.
Okay, so no points for dogma with that last one. But recognizing
that this is a compromise solution, an alternative to just
"set dad_transmits to zero", it seems okay to me.
(the rest of the comments which came out of the IESG review seem
pretty simple to address, to me. I think this means I need to
start firing up -06 ... sadly, it seems unlikely that I'll be able
to get funding to attend Paris, so it'll have to keep bouncing
around in email ...)
-----Nick
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
