> > 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 [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
