Hi Thomas,
Thomas Narten wrote:
[cut]
BTW, what I meant to say above was more like:
This document requires that an implementation do things that may
logically (if you follow the conceptual sending model) be hard to
do, because the information needed to do something may not be
available at that point in the algorithm (implementation). I.e., one
ends up having to have access to the ND cache info while doing steps
that (previously) were logically completely separate from the ND
cache. I wonder if in practice, these might be "difficult" for some
implementations.
I guess that's a fair comment. There's more required knowledge in order
to control operations within the NC.
Nick may have more comments implementation though.
[cut]
If you only do the MUST NOT, but not the SHOULDs, what is the point of
implementing the spec? You are allowing an upper layer to use a
tentative address, yet packets from that address presumably won't be
sent until (the normal) DAD has completed, in which case, you've paid
the price of the normal DAD delay... Right?
Yes, full DAD delay is incurred in that case (for on-link destinations).
As you mentioned below off-link destinations are a different case,
but I guess in scope. A lot of the interest was being driven
through path restoration mechanisms like MIPv6, SCTP, etc.
What's actually critical here is that NS's aren't sent to multicast
addresses. They contain SLLAOs which will overwrite a peer's NCE
destructively.
So my question is: Is your problem mainly with the SHOULDs or the
MUST NOT?
Am I understanding correctly that not implementing the SHOULD
effectively negates the benefits of implementing the spec?
It reduces the applicability to only off-link destinations available
through a discoverable router.
Do you think that the draft needs a statement about the effect of
not implementing the 'send to router' mechanism?
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. But it appears that at least when sending to
neighbors, not implementing the SHOULDs results in no reduction in
delay.
Since the implicit goal of Opti-DAD was not to create long-lasting state
on neighbours, I guess the idea of delaying was seen as preferable in
this case to destruction of existing NCEs. I guess that delay reduction
was the main reason for having these ideas as SHOULDs.
If there was a way of explicitly removing peer NCEs created during the
optimistic period, then it would be good to be able to send multicast
NS's, instead of forwarding to a router (or delaying).
This may be difficult in practice too though (more difficult than
forwarding to a router??).
Greg.
P.S.
Here's an example of the type of mechanism which may offer an
alternative and only needs to check the optimistic state from the
NCE during ND operations (rather than during packet delivery).
It's a lot more work than 'send to the router', though.
I'd guess one way to address resolution is to send multicast
NS's to neighbours, but to not reply to unicast/PROBE NS's
sent from these neighbours until the end of the optimistic period.
The NS created STALE entry transits immediately to DELAY upon
unicast NA transmission back to the Optimistic Node.
The DELAY of 5 seconds could potentially push the probe back until
the node was either finished being optimistic, or discovered
that it was a duplicate address. In the duplicate case, there would
be about 14 seconds of delay and probing before the NCEs were deleted,
along with any queued data (about 9 seconds of which would be lost?).
It would require further data (and perhaps upper layer timeout) to
reinitialize the NCE to the original owner's MAC address.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
