Re: Last Call: 'Optimistic Duplicate Address Detection for IPv6' to Proposed Standard

[Greg Daley <greg.daley at eng.monash.edu.au>]

Hi Thomas.

Thomas Narten wrote:
> I've reviewed this document and on the whole think it's fine for PS.
>
> But I do have one general concern. This document requires that an
> implementation do what in practice, I think might be "difficult" for
> some implementations. While that is OK at one level, I fear that some
> implementors will do most of this spec, but not all of it. I wonder if
> that would be a good outcome.
>
> For example:
>
>
> >   * (modifies 7.2.2)  When a node has a unicast packet to send from an
> >        Optimistic Address to a neighbor, but does not know the
> >        neighbor's link-layer address, it MUST NOT perform Address
> >        Resolution. It SHOULD forward the packet to a default router on
> >        the link in the hope that the packet will be redirected.
> >        Otherwise it SHOULD buffer the packet until DAD is complete.
>
>
> will implementations really bother with this? Or will they be tempted
> to skip this because it is "too hard" for a particular implementation?


I guess that the forwarding to the router may be difficult as also may
the buffering of the packets (which I guess actually may be part
of the existing tentative address specification).

Neither is actually as important as the first instruction
(the MUST NOT).

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?

Greg

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------