Hi Ralph and Thomas, Just updating the doc for final (hopefully!) submission. A couple of conclusions from the discussion below are unlear to me. So your responses will help me clarify the new document.
> >> 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. => Ok, does anyone object to removing that statement from the spec? The statemement I'm referring to is the one Ralph refers to above: "Neighbor Discovery should be implemented as described in this document." It seems superfluous anyway. > >> 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. => I believe RFC 2460 uses the same language. > 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? => Yes, that's my understanding. Hm, if that's the case, > then perhaps the > text I quoted is superfluous? => Maybe a healthy redundancy :) > > 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? => Sure. > >> 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? => If the L bit is not set a host cannot assume that an address is on-link, therefore it will send all packets to its Default router, unless a redirect is received for a particular address. > > >> 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? => I don't think your sentence above is related to being able to send packets to other routers. Learning about default routers is specified in this doc, but your original question was whether a host can send packets to other routers (not the default) and I agree with Thomas' answer. But I don't see how that means that a host can only learn about a DR from ND? Seems like a completely separate point. > > 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... => I agree. So how about we state in the document that the terms "stateless autoconfiguration" and "autonomous autoconfiguration" are used interchangeably? People are familiar with the meaning of the A flag and with the term "stateless autoconfig", removing either one is probably going to add more confusion than clarity. It might have to be one of those imperfections of a doc that developed over a long time. Is this ok? > > 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? => I can't think of a useful application that would benefit from this. Hesham 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 > [email protected] > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
