Tatuya, Have you tested BSD by sending it an RA with no PIO and M and O bits set so that BSD initiates DHCPv6 ? Once BSD host is online with DHCPv6 completed, issue a ping from BSD machine to another IPv6 machine on the same link. BSD should send this ping to the default router and NOT issue any NS to try and resolve the ping destination. Since RA did not advertise any PIO, BSD host has no means to make an on-link determination and thus not issue any NS because issuing an NS just told us BSD assumed the ping destination in on-link - that is wrong behavior.
Do also test the converse thing. A host could be incorrectly implemented by always sending all traffic to default router and not issuing any NS. Send an RA with PIO to BSD DHCPv6 host advertising a prefix as on-link. Then issue a ping to another host on the same link for which the prefix was advertised as on-link. If BSD sent the ping to default router that is wrong. BSD has to issue an NS to resolve the destination of the ping. Thanks. Hemant -----Original Message----- From: JINMEI Tatuya / ???? [mailto:[EMAIL PROTECTED] Sent: Thursday, July 05, 2007 1:16 AM To: Hemant Singh (shemant) Cc: Ole Troan (otroan); Vlad Yasevich; ipv6@ietf.org Subject: Re: Sending traffic to default router when RA has no PIO At Tue, 3 Jul 2007 10:56:32 -0400, "Hemant Singh (shemant)" <[EMAIL PROTECTED]> wrote: > In this regard, bullets 2 and 3 in Section 2 of our I-D show the issue > hosts have when hosts incorrectly always add a directly connected > route to the /64 prefix from an address assigned to an interface, even > if the prefix is advertised as "not on link" or is not advertised at > all. That incorrectly added route causes the host to try to use direct > delivery (without sending traffic to the default router) and, > therefore, use NS/NA to resolve addresses from the same prefix. > > We are prepared in this discussion that no host implementers will > reply to our thread. I already explained the BSD implementation correctly handles a prefix advertised via an RA with the L bit being off. Out of curiosity, which host implementation are you specifically talking about? You have repeatedly stated something like "an implementer of a popular IPv6 host [...] missed this behavior", but I don't think I've heard which implementation it is. Is there any reason for not being specific? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
