Jinmei, Thanks very much for the review of this draft. Please see in line below for our responses that are preceded by "<hs>" and ended by "</hs>".
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, October 29, 2007 2:06 AM To: Hemant Singh (shemant); Wes Beebee (wbeebee) Cc: [email protected] Subject: comments on draft-wbeebee-nd-implementation-problems-00 I've read this draft. I don't have a particular opinion on it in general, but I have a couple of comments, so here they are. 1. Section 2.1 refers to RFC3756 (SEND), but I don't think it's an appropriate reference since this is not a security related issue. Also, while the draft states: Implications If the router and the destination host do not respond to the NS, the host layer 2 driver will hold the IPv6 packet, resulting in lack of IPv6 connectivity as per section 4.2.5 of RFC 3756 [SEND]. I'm not really sure how Section 4.2.5 of RFC3756 relates to the implication. <hs> The reason we mentioned SEND is because the net outcome of the problem described in our Section 2.1 is the same as when a DOS attack is mounted by a rouge router to confuse the host. The problem we describe could be a genuine mistake/bug in a host stack for IPv6 ND implementation that causes host to issue NS to resolve an address when the host was not supposed to perform any address resolution - a router may not respond to the NS and the host's L2 driver will stop transmitting IPv6 packets. The issue described in SEND RFC also causes the host to issue an NS and, therefore, lose network connectivity. </hs> 2. I'm not sure if the behavior shown in Section 2.2 is worth discussing: Description An IPv6 host was asked by the aggregation router to perform DHCPv6 (through setting the M bit in the RA). During the course of Link-local DAD and DHCPv6 DAD, the host sent 4 DADs for its link-local address and five DADs for its DHCPv6 acquired address. Even though there may be an implementation that behaves this way, this just seems to be a trivial bug; I cannot even imagine a mis-interpretation of an specification that leads to this behavior. <hs> Actually, the host sending nine DAD's through Link-local and DHCPv6 address acquisition is compliant with ND. We have confusion around number of DAD's because some folks think this host is not compliant with ND. Since RFC 4861 does not list default value for DupAddrDetectTransmits, a common question asked by new developers implementing RFC 4861 or its predecessors is where is this value defined. That is why we thought it made sense to bring out the fact in this section. </hs> Of course, this draft more or less talks about 'implementation bugs', but it doesn't make sense to describe all known bugs; we should concentrate on ones that can be a useful lesson for other implementors. We should simply report the bug to the vendor for other obvious bugs, and I think this is one such trivial case. <hs> Yes, that is what our intent is too. See above why we included this bug. </hs> Thanks. Hemant & Wes. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
