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 PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
