Problems under test of IPv6 Ready Logo Program Phase-2

[SUZUKI Shinsuke]

Hello,

Here's my comment based on my IPv6Ready Logo(Ph.2) work in KAME
Project.

>>>>> On Wed, 18 Oct 2006 15:52:48 -0700
>>>>> gnn at freebsd.org said:

> Though some of us are using TAHI I do not believe the project itself
> is going for the Logo Program.
TAHI Project is one of the major member of the Logo program.
(TAHI provides a automatic testing tool for the Logo program)
Please see the following pages for further detail.
	http://www.ipv6ready.org/about_logo_program.html	


> > 1. Section 5: RFC 2463 - ICMPv6 
> >    "case 11 Part B: Multicast Destination"  ---  fail
> >    After TN send Echo Request to global multicast
> >    address(ff1e::1:2), the following words appear on NUT's
> >    screen-----rl1:discard oversize frame (ether type 86dd flags 3
> >    len 1514 > max 1294 )
> >    However, "case 10 Part A: Unicast Destination" passes.

Judging from the above message and the source code, it seems like
you've configured rl1's MTU as 1280 and send a 1500-byte packet on
rl1.  You should send the packet on rl0 (where its MTU is 1500).


> > 2. Section 2: RFC 2461 - Neighbor Discovery for IPv6
> >    "127 Part C: Sending Unsolicited RA (Min Values)"  --- fail
> >    After NUT excutes rtadvd, TN says "Could't observe RA".
#This is a test item to see the interval of the RA messages.  So NUT
#must run rtadvd (by hand or automatic operation by TAHI-tool)

This message appears even when TN receives an RA (with an unexpected
parameter).  You should carefully check the log of the self-test tool
to see what is an unexpected parameter.


> > 3. Section 3: RFC 2462 - IPv6 Stateless Address Autoconfiguration 
> >    All cases fail
> >    Reason----TN can't observe DAD process. 
> >    I can't capture DAD packages by Ethereal in the network start process.
(snip)
> I have not heard of this and don't have that hardware so can't check it.

I've encountered the same phenomenon sometimes.

It seems like there's a short amount of time where IFF_UP bit changes
from off to on, but the hardware is not ready to send a packet.
(appears like an ethernet auto-negotiation has not been completely
finished)

Since DAD process is kicked just after link-local address
configuration (normally when IFF_UP bit changes from OFF to ON), it is
inevitable in such drivers.

My recommendation is either of the following two.
   (only to pass the IPv6-Ready Logo testing)
   - set net.inet6.ip6.auto_linklocal to 0
   - manually configures a link-local address after the auto-negotiation
     has been completely finished
or
   - disable auto-negotiation
or
   (to make all the freebsd users happy:-))
   - hack the device driver to make IFF_UP on after the hardware is
     ready to send a packet

Thanks,
----
SUZUKI, Shinsuke @ KAME Project