Jinmei, Please see in line below between "<hs>" and "</hs>" for some more closure over what Wes closed in his email to you.
>-----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. <hs> We have discussed this issue again between myself and Wes and I see no reason to change or augment any text in our draft. Please read bullet 3 of Section 2 in our draft again including the Conceptual Sending Algorithm in RFC 4861. The ND-cache does not modify the data forwarding table of any ipv6 node and in light of this fact, there is nothing tricky we see if a host accepted an NS with a not on-link source and also replied to this NS as per RFC 4861 and the bullets 3 and 4 of on-link definition are deprecated. </hs> >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. <hs> The reason for accepting an NS message with not on-link source is to allow the Neighbor Cache's to be as full as possible to save having to do unnecessary address resolutions. This has been clarified in bullet 3 of section 2 in our draft - see specifically the paragraph in bullet 3 that begins with this sentence: "The intention of the above feature is to add an address...". This does not cause an on-link determination problem, since a host only performs address resolution for IPv6 addresses that are on-link. The reason that this works in practice is because RFC 4861-compliant implementations will have a separate Prefix List, Destination Cache, and Neighbor Cache. Further, the Prefix List and Destination Cache are used to determine on-link status before the Neighbor Cache is consulted. </hs> >Other technical comments: >- 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:-) <hs> I don't see anything tricky, nor do I see any reason for the statement above to not hold. One has to understand the Conceptual Sending Algorithm in RFC 4861. If a host is to send a packet out, the Destination Cache is looked up for the destination IPv6 addr. If the Destination Cache doesn't have the destination IPv6 addr, then the next-hop determination process is invoked that will first check the Prefix List for the destination IPv6 addr to map to any prefix in the Prefix List. If the destination addr matches a prefix in the Prefix List, then the destination is considered on-link. Once the destination has been deemed to be on-link, the ND-cache is looked up to see if a L2 to L3 mapping exists so that the packet can be sent out to the next hop. If the ND-cache doesn't have the destination address, then an address resolution is invoked. Therefore, according to the Conceptual Sending algorithm described above, when the address resolution is issued, it has been already esta blished the destination is on-link. The statement in the Introduction section is summarizing this fact. </hs> Thanks, Hemant -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
