On Mon, Jul 29, 2002 at 10:24:12 -0400, John D Smerdon wrote:

> It appears that packets are received, and are held for up to 1000ms
> before being delivered.

Looks strange indeed. This code originated from the KAME project.
Maybe you could resend your findings to snap-users@kame.net.
Maybe they have seen this before.

> Without tcpdump running and no other IPv6 traffic, every other
> packet is delay 1000ms.
> 
>   $ping6 -c 6 sup.netbsd.org
>   PING6(56=40+8+8 bytes) 2002::1 --> 3ffe::6563
>   16 bytes from 3ffe::6563, icmp_seq=0 hlim=60 time=1227.88 ms
>   16 bytes from 3ffe::6563, icmp_seq=1 hlim=60 time=226.348 ms
>   16 bytes from 3ffe::6563, icmp_seq=2 hlim=60 time=1223.86 ms
>   16 bytes from 3ffe::6563, icmp_seq=3 hlim=60 time=224.311 ms

This could happen is there are two paths to the destination. Do
the v4 packets to the 6to4 relay and v6 packets to the sup server
follow the same path when traceroute(6)ing several times? But, I
agree, tcpdump shows packets are arriving with equal time distances
between them. If you haven't done so, maybe you could tcpdump on
another machine on the network. Just to make sure you are not effected
by some networking bug on mac netbsd.

	rvdp