Subject: comments on draft-wbeebee-nd-implementation-problems-00

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 29 Oct 2007 15:06:03 +0900

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.

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.
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.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 30 Oct 2007 12:16:45 -0400

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-masked] [mailto:[email-masked]]

Sent: Monday, October 29, 2007 2:06 AM
To: Hemant Singh (shemant); Wes Beebee (wbeebee)
Cc: [email-masked]
Subject: comments on draft-wbeebee-nd-implementation-problems-00

<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>

<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-masked]