Hi Ralph.
[ietf list dropped]
> Substantive/editorial: I'm confused by the statements in section 3.2,
> Supported Link Types: "Neighbor Discovery should be implemented
> as described in this document." What is the intent of the
> statement - advice about whether to implement or how to
> implement? Under what circumstances would a node not implement
> Neighbor Discovery as described in the document.
I think this is general advice to people thinking about how ND applies
to link layers other than, say, ethernet. Clearly, ND applies to all
specs, unless superceded by another spec for a particular link
layer. That is all that this section is (IMO) trying to say. I.e., to
suggest when another spec might be needed and where not.
> Substantive: From section 4.6, Option Formats:
> Options should
> be padded when necessary to ensure that they end on their natural 64-
> bit boundaries.
> How, exactly, is this padding encoded? And, why bother?
See the length field:
Length 8-bit unsigned integer. The length of the option
(including the type and length fields) in units of
8 octets. The value 0 is invalid. Nodes MUST
silently discard an ND packet that contains an
option with length zero.
You have to pad options to fill them out to 8 octets.
> Substantive: The definition of the L bit, from the Prefix Information
> option, includes:
> When
> not set the advertisement makes no statement about
> on-link or off-link properties of the prefix.
> This point about "no statement about on-link or
> off-link..." is made other places, as well. I don't think
> I see any indication of the consequences of this
> definition; that is, what should the implementor be aware
> of as a consequence of the lack of knowledge about whether
> a prefix is on-link or off-link? If those consequences are
> subtle, perhaps they should be explained?
Well, I seem to recall that exact wording was the result of a lot of
discussion at the time. :-)
What this is really trying to say is that if you receive an RA with a
prefix information option in which the on-link bit is not set, you
cannot conclude from that that the prefix is not on link. From section
6.3.4:
Prefix Information options that have the "on-link" (L) flag set
indicate a prefix identifying a range of addresses that should be
considered on-link. Note, however, that a Prefix Information option
with the on-link flag set to zero conveys no information concerning
on-link determination and MUST NOT be interpreted to mean that
addresses covered by the prefix are off-link. The only way to cancel
a previous on-link indication is to advertise that prefix with the
L-bit set and the Lifetime set to zero.
The last sentence explains why "when not set the advertisment makes no
statement about on-link or off-link properties of the prefix".
> Editorial/substantive: From section 5.1, Conceptual Data Structures:
> Default Router List
> - A list of routers to which packets may be sent.
> Is it possible for a host to send packets to routers that
> are not on the Default Router list?
sure, but that is outside the scope of this spec. The only routers
covered by the ND spec are those learned via ND.
> Editorial: Seems "autonomous address configuration" and "stateless
> address configuration" (and some variants like "autonomous
> address-configuration", "stateless address
> autoconfiguration" and "address autoconfiguration") are
> used interchangeably throughout the document; it would
> improve clarity to pick one phrase and use it uniformly
> throughout the document
Agreed. I suggest dropping autonomous, since that term is less well
known.
> Editorial: The definition for Prefix Information option in section 4.2
> includes the text "specify the prefixes that are on-link
> and/or are used for address autoconfiguration". Is it the
> case that a Prefix Information option will only appear for
> on-link and/or address autoconfiguration; i.e., at least
> one of the L and A bits will always be set in Prefix
> Information option?
Not necessarily. See RFC RFC3775.
Thomas
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
