On 09/03/2009, at 1:44 PM, Jasper Bryant-Greene wrote:
How is that different from normal IP routing? The other end always decides which way to send packets back to you, and in the event that your customer is multihomed, the return path might not even transit your AS.
I control my outbound and inbound routing. People only send packets via routes I advertise and I can show a contractual relationship between me and my upstream or peer, my upstream and theirs or their peer and then to the far end etc. With using 6to4 the downside is that whilst I may have my own gateway, the FAR end could be using a 3rd party 6to4 gateway. This means that the return packets traverse links for which I have no contractual relationship. I guess in some way I'm agreeing with Joe that everyone SHOULD run their own, especially if they offer up content over IPv6. (I wonder if Google do with ipv6.google.com?). MMC -- Matthew Moyle-Croft Internode/Agile Peering and Core Networks Level 5, 162 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc(a)internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
On 8 Mar 2009, at 23:39, Matthew Moyle-Croft wrote:
On 09/03/2009, at 1:44 PM, Jasper Bryant-Greene wrote:
How is that different from normal IP routing? The other end always decides which way to send packets back to you, and in the event that your customer is multihomed, the return path might not even transit your AS.
I control my outbound and inbound routing.
Actually, you only control your outbound router. The best you can do with your inbound routing is to give other people hints as to how you'd prefer it to work.
People only send packets via routes I advertise
... as far as you know.
[...]
I guess in some way I'm agreeing with Joe that everyone SHOULD run their own, especially if they offer up content over IPv6. (I wonder if Google do with ipv6.google.com?).
That seems pretty easy to check. Look at the packets upstream of your local 6to4 relay when a 6to4-numbered host sends packets to ipv6.google.com. Joe
On 09/03/2009, at 2:14 PM, Joe Abley wrote:
That seems pretty easy to check. Look at the packets upstream of your local 6to4 relay when a 6to4-numbered host sends packets to ipv6.google.com.
Why would packets coming back from Google go through my 6to4 gateway? MMC -- Matthew Moyle-Croft Internode/Agile Peering and Core Networks Level 5, 162 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc(a)internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
On 8 Mar 2009, at 23:50, Matthew Moyle-Croft wrote:
On 09/03/2009, at 2:14 PM, Joe Abley wrote:
That seems pretty easy to check. Look at the packets upstream of your local 6to4 relay when a 6to4-numbered host sends packets to ipv6.google.com.
Why would packets coming back from Google go through my 6to4 gateway?
Yeah, that's a reasonable question. :-) Inbound v4 packets upstream of the 6to4-numbered host, then, except that they seem to be originated from the RFC3068 anycast relay router address, so that's not much help. Not so easy to check, then. Joe
On 9/03/2009, at 3:03 PM, Joe Abley wrote:
Inbound v4 packets upstream of the 6to4-numbered host, then, except that they seem to be originated from the RFC3068 anycast relay router address, so that's not much help. Not so easy to check, then.
Sometimes, but not always. -- Nathan Ward
On 9 Mar 2009, at 05:53, Nathan Ward wrote:
On 9/03/2009, at 3:03 PM, Joe Abley wrote:
Inbound v4 packets upstream of the 6to4-numbered host, then, except that they seem to be originated from the RFC3068 anycast relay router address, so that's not much help. Not so easy to check, then.
Sometimes, but not always.
I meant in the specific case of ipv6.google.com, as tested from my house :-) Joe
On 9/03/2009, at 10:47 PM, Joe Abley wrote:
On 9 Mar 2009, at 05:53, Nathan Ward wrote:
On 9/03/2009, at 3:03 PM, Joe Abley wrote:
Inbound v4 packets upstream of the 6to4-numbered host, then, except that they seem to be originated from the RFC3068 anycast relay router address, so that's not much help. Not so easy to check, then.
Sometimes, but not always.
I meant in the specific case of ipv6.google.com, as tested from my house :-)
Roger roger. 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. -- Nathan Ward
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. Joe
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
On Tue, 2009-03-10 at 22:59 +1300, TreeNet Admin wrote:
~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! :)
Just to point out, our international V6 transit is native thanks to Vocus, not just a tunnel :) -- -Michael Fincham System Administrator, Unleash www.unleash.co.nz Phone: 0800 750 250 DDI: 03 978 1223 Mobile: 027 666 4482
Hi, Does anyone have any old Cisco 3640/3660 or 7200VXR devices they are wanting to scrap or flick off cheap? Contact me off list if you have any. Thanks, Antonio
participants (6)
-
Antonio Pavletich -
Joe Abley -
Matthew Moyle-Croft -
Michael Fincham -
Nathan Ward -
TreeNet Admin