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

[Thomas Narten <narten at us.ibm.com>]

> > 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.

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.

> > 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).

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?

> 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?

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.

Thomas

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