Subject: sup go IPv6 or 6to4 1000ms bug?
To: Ronald van der Pol <Ronald.vanderPol@rvdp.org>
From: John D Smerdon <jds@smerdon.livonia.mi.us>
List: netbsd-users
Date: 07/29/2002 10:24:12
> Did you do a traceroute6 to see why the IPv6 connectivity is bad?
> Bugs (also routing bugs) won't get fixed if we don't investigate
> the problem.
> 
> 	rvdp

I am in Michigan in the US.  I just noticed that sup started to
take a long time and it was using IPv6.  I did a traceroute6 and
noticed that my first hop on ipv6 was in Switzerland.  For a chatty
protocol like sup, sending packets halfway around the world is not
efficient.

So either sup.netbsd.org just went IPv6, my ISP started using a
different AS for the 6to4 anycast network, or something else
happened.

I believe there is a problem with NetBSD 1.5.2/MacPPC when using
IPv6 and 6to4/stf.  I haven't been able to test it with 1.5.3 or
1.6, or with any other architecture than MacPPC.

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

(The following have been formatted to fit the screen)

  $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=853.398 ms
  16 bytes from 3ffe::6563, icmp_seq=1 hlim=60 time=750.759 ms
  16 bytes from 3ffe::6563, icmp_seq=2 hlim=60 time=759.437 ms
  16 bytes from 3ffe::6563, icmp_seq=3 hlim=60 time=754.328 ms
  16 bytes from 3ffe::6563, icmp_seq=4 hlim=60 time=855.184 ms
  16 bytes from 3ffe::6563, icmp_seq=5 hlim=60 time=756.863 ms

  --- sup.netbsd.org ping6 statistics ---
  6 packets transmitted, 6 packets received, 0% packet loss
  round-trip min/avg/max/std-dev = 750.759/788.328/855.184/46.719 ms

Below is a tcpdump on stf0 during the ping above.  Note the
differences of the timestamps are significantly shorter than the
ping times above.

  09:17:35.157016 sys2 > 3ffe::6563: icmp6: echo request
  09:17:35.384211 3ffe::6563 > sys2: icmp6: echo reply
  09:17:36.158474 sys2 > 3ffe::6563: icmp6: echo request
  09:17:36.381476 3ffe::6563 > sys2: icmp6: echo reply
  09:17:37.158478 sys2 > 3ffe::6563: icmp6: echo request
  09:17:37.381660 3ffe::6563 > sys2: icmp6: echo reply
  09:17:38.158468 sys2 > 3ffe::6563: icmp6: echo request
  09:17:38.379557 3ffe::6563 > sys2: icmp6: echo reply
  09:17:39.158489 sys2 > 3ffe::6563: icmp6: echo request
  09:17:39.382611 3ffe::6563 > sys2: icmp6: echo reply
  09:17:40.158461 sys2 > 3ffe::6563: icmp6: echo request
  09:17:40.379638 3ffe::6563 > sys2: icmp6: echo reply

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
  16 bytes from 3ffe::6563, icmp_seq=4 hlim=60 time=1223.27 ms
  16 bytes from 3ffe::6563, icmp_seq=5 hlim=60 time=223.713 ms

  --- sup.netbsd.org ping6 statistics ---
  6 packets transmitted, 6 packets received, 0% packet loss
  round-trip min/avg/max/std-dev = 223.713/724.895/1227.875/500.107 ms

-- 
John D. Smerdon;  Livonia, Michigan, USA;  Contents are my opinion.
Home: jds@smerdon.livonia.mi.us http://www.smerdon.org/