JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
<[EMAIL PROTECTED]> writes:
> Hmm...good point. I've not realized for 10+ years that the conceptual
> sending algorithm doesn't really use the full definition of "on-link"
> (as defined in Section 2.1 of RFC2461/4861) to "determine whether the
> packet's destination is on- or off-link." That is, while the
> definition "on-link" per section 2.1 is as follows:
> 1. it is covered by one of the link's prefixes (e.g., as indicated by
> the on-link flag in the Prefix Information option), or
> 2. a neighboring router specifies the address as the target of a
> Redirect message, or
> 3. a Neighbor Advertisement message is received for the (target)
> address, or
> 4. any Neighbor Discovery message is received from the address.
> the conceptual sending algorithm doesn't mention bullets 3 or 4 at
> all.
Correct.
> If the original intent of the spec authors was to ignore these
> additional conditions in the conceptual sending algorithm, I'll more
> strongly agree that removing the third and fourth bullets is the right
> way to go.
At least this original author doesn't recall *intending* that the
additional bullets be ignored. That is, I don't recall that we
intentionally put bullets 3 and 4 into the document for a particular
reason. Rather, I think this is just a classic case of imprecise text
not being caught during earlier review cycles. :-(
Going back to an earlier message:
JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
<[EMAIL PROTECTED]> writes:
> I also admit that I was in a minority in the relatively small group of
> the discussion (i.e. 1 among 6), but I don't think that necessarily
> means we, as a wg, reach a clear consensus.
The WG clearly has to agree and sign off on any private discussions
that we (or others) have held. The private discussions that I've been
involved with were only intended to try and get a subset of us on the
same page before going back to the WG, in order to spare the WG too
much mail. :-)
> And, for that matter, I don't think I've opposed to revisiting or even
> removing the third and fourth bullets of the on-link definition of
> RFC4861 per se. My point was that since this change will make
> existing implementations that conform to published specifications
> non-compliant, the change should be done based on informed-consent,
> rather than a clarification document that just "spells out the most
> important (subtle) difference" (quoted from the abstract of the
> subnet-model draft).
Agreed.
> We might end up regarding no reaction from implementors as a
> "consensus", which is fine for me, but I'd at least request an
> explicit wg last call with a note that this document will invalidate
> existing implementations.
Invalidate is a strong word. I think we all agree that the issue that
has been raised can lead to to a security issue. I would assume that
implementations that suffer from this "feature" will want to fix their
code. I don't think we should be too worried about whether a spec
change to acheive this invalidates existing implementations! (But the
WG will decide that.)
> I'm okay with the proposed text from Thomas itself (with some
> supplemental comments - see below), but I'd also like the entire
> document will be adjusted so that this important change will be
> reflected. For example, the current abstract:
> IPv6 specifies a model of a subnet that is different than the IPv4
> subnet model. The subtlety of the differences has resulted in
> incorrect implementations that do not interoperate. This document
> spells out the most important difference; that an IPv6 address isn't
> automatically associated with an IPv6 on-link prefix.
> doesn't say anything about the change (understandably, because the
> issue was raised after this version of the draft). This should be
> amended like this:
> IPv6 specifies a model of a subnet that is different than the IPv4
> subnet model. The subtlety of the differences has resulted in
> incorrect implementations that do not interoperate. This document
> spells out the most important difference; that an IPv6 address isn't
> automatically associated with an IPv6 on-link prefix. This
> document also invalidates the definition of on-link prefixes
> currently defined in RFC4861 due to security concerns.
IMO, "invalidates" is too strong. I think "clarifies" or "updates" is
just fine. Invalidates suggests that we are making a change from
something that was originally done a certain way intentionally. I
don't think the current definition was done intentionally. It clearly
has a bug in it that we should have caught earlier.
> We should also note that invalidating the part of on-link definition
> affects other parts of RFC4861. For example, it will invalidate this
> point:
> If the Source Address is not the unspecified
> address and, on link layers that have addresses, the solicitation
> includes a Source Link-Layer Address option, then the recipient
> SHOULD create or update the Neighbor Cache entry for the IP Source
> Address of the solicitation.
> (section 7.2.3)
> we should also clearly state each affected part is invalidated;
> otherwise, the reader will be confused about the discrepancy.
Yes. This makes sense.
Thomas
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
