Joe Abley wrote:
On 9 Mar 2009, at 07:50, Nathan Ward wrote:
What is the HLIM of the IPv6 packets? (not the IPv4 encapsulation, I mean the IPv6 packet carried inside the IPv4 packet)
That is usually a good indicator.
tcpdump: listening on en0, link-type EN10MB (Ethernet), capture size 96 bytes 08:14:43.978005 IP (tos 0x0, ttl 40, id 34166, offset 0, flags [none], proto IPv6 (41), length 76) 199.212.90.13 > 192.88.99.1: IP6 (hlim 64, next-header: ICMPv6 (58), length: 16) 2002:c7d4:5a0d:1::1 > 2001:4860:0:2001::68: [icmp6 sum ok] ICMP6, echo request, length 16, seq 33 08:14:44.106483 IP (tos 0x0, ttl 245, id 20518, offset 0, flags [none], proto IPv6 (41), length 76) 192.88.99.1 > 199.212.90.13: IP6 (hlim 57, next-header: ICMPv6 (58), length: 16) 2001:4860:0:2001::68 > 2002:c7d4:5a0d:1::1: [icmp6 sum ok] ICMP6, echo reply, length 16, seq 33 08:14:44.978054 IP (tos 0x0, ttl 40, id 61522, offset 0, flags [none], proto IPv6 (41), length 76) 199.212.90.13 > 192.88.99.1: IP6 (hlim 64, next-header: ICMPv6 (58), length: 16) 2002:c7d4:5a0d:1::1 > 2001:4860:0:2001::68: [icmp6 sum ok] ICMP6, echo request, length 16, seq 34 08:14:45.108964 IP (tos 0x0, ttl 245, id 53045, offset 0, flags [none], proto IPv6 (41), length 76) 192.88.99.1 > 199.212.90.13: IP6 (hlim 57, next-header: ICMPv6 (58), length: 16) 2001:4860:0:2001::68 > 2002:c7d4:5a0d:1::1: [icmp6 sum ok] ICMP6, echo reply, length 16, seq 34 08:14:45.978108 IP (tos 0x0, ttl 40, id 22305, offset 0, flags [none], proto IPv6 (41), length 76) 199.212.90.13 > 192.88.99.1: IP6 (hlim 64, next-header: ICMPv6 (58), length: 16) 2002:c7d4:5a0d:1::1 > 2001:4860:0:2001::68: [icmp6 sum ok] ICMP6, echo request, length 16, seq 35 08:14:46.106890 IP (tos 0x0, ttl 245, id 20747, offset 0, flags [none], proto IPv6 (41), length 76) 192.88.99.1 > 199.212.90.13: IP6 (hlim 57, next-header: ICMPv6 (58), length: 16) 2001:4860:0:2001::68 > 2002:c7d4:5a0d:1::1: [icmp6 sum ok] ICMP6, echo reply, length 16, seq 35
The observed latency seems quite different between v4 and v6 using a 6to4 source address:
--- ipv6.l.google.com ping6 statistics --- 100 packets transmitted, 100 packets received, 0% packet loss round-trip min/avg/max = 127.896/129.753/131.936 ms
--- www.l.google.com ping statistics --- 100 packets transmitted, 100 packets received, 0% packet loss round-trip min/avg/max/stddev = 13.179/14.467/16.221/0.640 ms
The 6to4 relay I'm using for outbound packets is local:
--- 192.88.99.1 ping statistics --- 100 packets transmitted, 100 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.850/1.127/9.522/1.178 ms
Using a non-6to4 source address, with native v6 and goog peering which matches v4:
--- ipv6.l.google.com ping6 statistics --- 100 packets transmitted, 100 packets received, 0% packet loss round-trip min/avg/max = 27.400/30.183/50.567 ms
I guess this suggests they are not using a local 6to4 relay, or at least not as local as they could.
Depends on what you mean by 'local'. Maybe the 6to4 is their local in-house one, or maybe not. (tracert -6 time). By my reading of your trace they are 7 hops from their nearest 6to4 gateway. Making it 17(?) total hops to you, vs how many in native v4. (assumed IPv4 ttl was 255 reduced to 245. IPv6 hlim 64 reduced to 57.) ~100ms lag time on an International v6 tunnel is only a little shabby, though it is more related to where the international site is located. (Thanks Unleash you cut the NZ hlim in half! :) AYJ