Jinmei, I have fixed the sections numbers in the email reply below and responded to your comments. Please see in line below.
- Wes -----Original Message----- From: JINMEI Tatuya / 神明達哉 [mailto:jinmei_tat...@isc.org] Sent: Wednesday, April 29, 2009 8:10 PM To: Hemant Singh (shemant); Wes Beebee (wbeebee); erik.nordm...@sun.com Cc: ipv6@ietf.org Subject: comments on draft-ietf-6man-ipv6-subnet-model-03 Upon request from the author, I've reviewed the I-D, and here are my comments. I have one top level comment: I'm okay with removing the following two bullets from the original "on-link" definition of RFC4861 - a Neighbor Advertisement message is received for the (target) address, or - any Neighbor Discovery message is received from the address. to address security concerns. But then I'd like to further simplify the rule of processing incoming NSes by discarding ones if the source address is not on-link. Removing the above bullets while allowing accepting incoming NSes from a non-on-link address (and responding to them) could make implementation very tricky for very little benefit. WB> We need to discuss this further with Erik and Thomas. Some implementations have already adopted this "simplification" to address the security concern, and, realistically, I don't think we can convince the maintainer to cancel the change and introduce a trickier patch to support the very minor case. The end result would be the same: we'll lose interoperability. Of course, we could blame such implementations for being "non compliant", but IMO it's more productive to plug the tricky corner case as we'll probably never need it in practice. Other technical comments: - Section 1 doesn't explain the motivation of removing the last two bullets of on-link definition. I actually expected such incompleteness because it was not in the original goal of this draft. That's why I insisted that this part is in a separate document. WB> I suspect that if we put this in another document, then that document would not be progressed. We already have a vector to make this change - therefore, we can add the motivation to the introduction section for removing the last two bullets. After all, it does have to do with the topic of on-link determination. - Section 1: Due to the tricky implication on on-link vs being neighbor (see above), if we wanted to keep it (note that I'm against it) the following cannot hold: A host only performs address resolution for IPv6 addresses that are on-link. because the host would have to perform address resolution for a "neighbor" but not necessarily an on-link node. (if we also remove the tricky implication, this can be automatically solved:-) WB> I think the original intent is to remove the processing of NS for not on-link addresses (ie. I agree with you), but we would need to consult more members of the WG to see if that is backed by consensus.... - Section 2: the section title "Host Behavior" is not very indicative to me. WB> This section refers to host behavior of note with respect to on-link determination, but does not specify any rules that the host should follow (those are reserved for the Host Rules section). - Section 2: I simply didn't understand the following paragraph at all. Please elaborate (I guess I asked the same thing before and it hasn't improved) 2. Note that Redirects cannot signal that an address is off-link. [...] WB> The fact that Redirects cannot signal that an address is off-link derives from an extremely subtle and non-obvious consequence of the application of the Redirect message processing rules in section 8.1. It was so subtle, that we even missed it the first time until Thomas explained it to us. A Redirect message is silently discarded if it does not have an IP source address that is the same as the current first-hop router for the specified ICMP Destination address. This is the processing rule. Proof by contradiction: If you wanted to construct a Redirect to signal that a destination which the host believes is on-link is actually off-link, then you would have to select an IP source address that matches the current first-hop router for the destination (which the host believes is on-link). However, since the host believes the destination is on-link, the host will not forward the packet to any first-hop router (because it's on-link). Therefore, no valid IP source address can be chosen for the Redirect (because there is no first-hop router for the destination, because the host believes the destination is on-link). Contradiction! Therefore, the assumption, that you can construct a Redirect to signal that what a host believes is an on-link destination is actually off-link, is false. - Section 2, bullet 3. I disagree with this bullet as stated above. I won't go into further details on this at the moment because it's a rather meta level issue. - Section 2, bullet 6: I don't understand this at all. Why is this mentioned? Why only multicast? WB> This was mentioned because the all-nodes link-scope multicast address FF02::1 can be used to map out all the nodes that are accessable on a link, and thus be used to determine on-link. However, that is a different definition of on-link than RFC 4861 uses. It may be applicable to MANET and other groups at IETF. Therefore, for the sake of completeness on the topic of on-link determination, we chose to describe it here so that future IETF'ers who will expand Neighbor Discovery to include MANET may use it as reference. However, upon another read of the text, it's clear that any reception of a link-local packet will yield the same definition - so we can drop the word "multicast" from this bullet. - Section 2, bullet 7: this rule isn't enforceable. I thought I already pointed it out before (please google it). WB> Routers decrement the Hop Limit field. Therefore, there is a Hop Limit (255) that exists that can be used to indicate that packet has not crossed a router. Note, however, that ND Proxy explicitly keeps the Hop Limit the same, so this definition (especially in the presence of networks that use ND Proxy) yields a different notion of on-link than RFC 4861 and a different notion of on-link than reception of link-scoped packets. Also, this fact has been mentioned by the MANET team - and I expect that they can use this notion as they explore what a "link" means in the MANET world. Further, please note that this bullet is in the Host Behavior section and is treated as an observation for the benefit of those who will modify Neighbor Discovery in the future (the MANET/LOWPAN team), and is not an enforceable rule. The rules are laid out in the Host Rules section. - Section 3, last para: Using cached on-link determination information without first [...] This doesn't address my previous concern. Besides, this is not really a "rule" even if it's in the "host rules" section. WB> To make it a rule, how about we add the following text: WB> Hosts MUST verify that on-link information is still valid after IPv6 interface re-initialization before using cached on-link determination information. WB> What specifically is your previous concern? - Section 6: I guess there should be a reference to the security problem (cert advisory or something). WB> Sure - we can quote the CERT Advisory here - it'll help give people who read this document without having been involved in the previous conversations more context when reading the document. Editorial comments: - Section 1 first para s/a address/an address/ - Some of the acronyms should be expanded beforehand (ND, RA, etc) - there are some redundant white spaces, e.g. "on- link" (should be on-link) - Section 3, bullet 4, there seems to be an indentation problem: Similarly, the following text from section 6.2.5 of [RFC4861] I suspect it's not part of citation. WB> Agreed. We will fix all your editorial comments. --- JINMEI, Tatuya Internet Systems Consortium, Inc. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
