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?
> * Nodes implementing Optimistic DAD SHOULD additionally implement
> Secure Neighbor Discovery [SEND].
This seems like gratuitous recommendation. This either requires
justification, or removal. (I'd think the latter.)
> Tentative Address - an address for which a node has not yet completed
> DAD is regarded as Tentative: a single Neighbor Solicitation for
> this address or a single Neighbor Advertisement defending this
> address will cause the node to deconfigure the address and cease
> using it.
>
> Deprecated Address - an address which should not be used if an
> alternative is available.
>
Wouldn't it be better to just use the same definitions as appears in 2462?
Editorial/minor:
> Optimistic Address - an address which is available for use despite
> DAD not being fully complete. This memo places restrictions on
> the use of Optimistic Addresses.
>
s/which/that/
> Standard Node - A Standard Node is one which is compliant with RFCs
> 2461 and 2462.
>
s/standard/conventional/? (nodes implementing this spec will be
"standard" too)
> * (modifies 5.4.3) The node MUST NOT reply to a Neighbor Solicitation
> for an Optimistic Address from the unspecified address. This NS
> indicates that the address is a duplicate, and it MUST be
> deconfigured as per the behaviour specified in RFC2462 for
> Tentative addresses.
Suggested reword of second sentence::
Receipt of such an NS indicates that the address is ...
> The ON will immediately send out a Neighbor Solicitation to determine
> if its new address is already in use.
s/new/optimistic/
> router behaviour, eg: that the router includes SLLAOs in RAs, and
s/eg:/e.g.,/
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
