At Thu, 2 Oct 2008 07:32:19 -0400, "Hemant Singh (shemant)" <[EMAIL PROTECTED]> wrote:
> For the record, in private email discussions on this issue, Jinmei has > been the only one who has not reached consensus with us who are myself, > Wes Beebee, Erik Nordmark, Thomas Narten, and David Miles. In fact, > Thomas proposed new text to be added to our IPv6 Subnet Model draft to > address this very problem but Jinmei didn't bother to reply to that new > text since August 20, 2008. It's time to open this discussion to 6man. > We propose the following text be added to the IPv6 Subnet Model draft. I > will forward one email from our private thread to the mailer as well. A > pointer to the IPv6 Subnet Model draft is below. I'm really sorry for not being responsive about the proposed text. I didn't mean to be a showstopper in the process, but I was clearly guilty for the delay. 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. 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). 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. 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. 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. Another minor point: I do not actually think the third bullet of the current on-link definition has a security issue: > - a Neighbor Advertisement message is received for > the (target) address, or because even if the target address of NA is bogus, it won't automatically cause creation of a corresponding neighbor cache: the receiving node will ignore the NA (under a "SHOULD") unless it already has a neighbor cache entry for that node. Still, this third bullet may be a redundant as part of definition, so I don't oppose to removing it this time. But doing so in the context of a security concern may be misleading. --- JINMEI, Tatuya Internet Systems Consortium, Inc. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
