Thomas - thanks for the responses...
On 11/29/06 1:16 PM, "Thomas Narten" <[EMAIL PROTECTED]> wrote:
> 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.
I think I understand the meaning the text is supposed to convey. But the
text doesn't seem (to me, anyway) to convey that meaning very well; I note
your interpretation is qualified with "IMO" and perhaps another reader might
have a different opinion?
To be more concrete, it appears that the section is describing how or which
parts of ND should be implemented on links with certain attributes. But the
last several entries don't seem to be very clear or precise. For example,
from:
variable MTU - Neighbor Discovery allows routers to specify a MTU
for the link, which all nodes then use. All nodes
on a link must use the same MTU (or Maximum
Receive Unit) in order for multicast to work
properly. Otherwise when multicasting, a sender,
which can not know which nodes will receive the
packet, could not determine a minimum packet size
that all receivers can process (or Maximum Receive
Unit).
I guess I would infer that "variable MTU" is orthogonal to, say,
"multicast", and the only effect of "variable MTU" is that the network admin
has to pick MTU == min(MRU for each host on the link).
>> 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.
Oh, of course...
OK, so "natural 64-bit boundaries" is a little unclear. And, shouldn't it
be a MUST? Does each option describe how to pad; i.e., suppose an option
carries a single variable length value? Is it the responsibility of the
text defining the option to describe the format of the option so the option
is always a multiple of 8 octets? Hm, if that's the case, then perhaps the
text I quoted is superfluous?
Backtracking...I reviewed the options defined in this spec, and all except
the Redirected-header option are defined to be an integer multiple of 8
octets in length. So, is the "padded when necessary" advice for the
definition of future options?
I found another nit while exploring this text: there is at least one
instance each of "link layer address" and "link-layer address"; choose one
or the other for consistency.
>> 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".
Yeah, I agree the text means "don't draw any conclusions about on- or
off-link is L bit is not set". What are the ramifications of the L bit not
being set; what other parts of this or other protocols are affected?
>> 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.
So a host only learns about default routers through 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.
Except for its use in supplying the initial for the 'A' bit in prefix
options...
>> 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.
Ah, right, thanks for the pointer. Just for my own enlightenment, is there
a reason to advertise a prefix that has all three of L, A and R not set;
i.e., a prefix not used for IPv6 mobility, not used for SLAAC and not
on-link? And, I guess this follows up on my earlier question - if the L bit
is not set, I suppose it means the prefix is not added to the list of
on-link prefixes as a result of receiving the prefix option in an RA.
> Thomas
- Ralph
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
