| reply to ConstantineM
Re: When will AT&T U-verse have native IPv6 support? I just had a Motorola NVG510 installed at work yesterday when we upgraded from plain DSL. I was pretty surprised to see it had an IPv6 address assigned and was in fact handing v6 addresses out to the LAN.
As we have 2 networks, semi-public and private, and a /28 block of static v4 IPs with our own router managing everything, the single /64 the NVG was handing out was just not adequate. After poking a bit at the web interface of the NVG I realized it was not going to be of any help. After a bit more poking I realized AT&T is actually using 6RD and not dual stack! Hmmmmmm.... A quick kernel upgrade and the firewall now knows 6RD. Fortunately the NVG provides the tunnel endpoint v4 address and, with a bit of manual bitmasking, the v6 prefix. Now, the question is, will the 6RD endpoint accept my static IPs or is it locked to the address of the NVG? Only one way to find out! Punch everything in and... success! My firewall now has 4 bits worth of address space to hand out per static IP! (aka a /60 aka 16 /64's) This got me thinking - since all 32 bits of the v4 address are used in the 6RD prefix, can I punch in any old v4 address and use that 6RD endpoint? Sure enough, it seems that endpoint is open to anyone. Please, no one tell AT&T  It very well may be possible for people with "unsupported" modems to get v6 addresses if you have a firewall that knows about 6RD and either have static IPs or have the modem in PPP passthrough mode...
So yeah, the prefix they're using is 2602:300::/28, but a whois on that block shows that they have all of 2602:300::/24 set aside for 6RD ("NetName ATT-6RD").
/M |
|
|
|
| I had IPDSL installed a few months ago when it was first available here. They told me I could only get 6Mbit/s on a static IP package. After they installed it I called again to check on it and they kept telling me that. I asked for L2 support and they quickly bumped the speed to 18mbit/s and gave me a /28 of IPv4 addys. While I was poking around in the NVG it said unavailable on IPv6.
Now it shows IPv6 is available and had addresses populated. I'm super excited but I have to do a lot of research on v6 before I can play too much. I'm trying to achieve this topology:
... I want the NVG to sit as a bridge (which is proving tricky) and for the pfSense to handle everything.
How many actual IPv6 addresses are we getting? Mine says /64. A v6 CIDR table says 18446744073709551616 addresses. Are they really handing out that many? I knew IPv6 has MANY more addresses than v4 but jeez. |
|
cramer
join:2007-04-10
Raleigh, NC
kudos:5 | They're giving you a /64 prefix because that's a small as a LAN segment can be for everything (read: address autoconfig) to work. |
|
| reply to afd168
said by afd168 :I want the NVG to sit as a bridge (which is proving tricky) and for the pfSense to handle everything.
How many actual IPv6 addresses are we getting? Mine says /64. It was easy to set mine up. Remember, the first and last IPs in your /28 are reserved and cannot be used. Just give the NVG one of the remaining IPs in the "Public Subnet" config (the netmask is 255.255.255.240 for a /28) and assign the rest to the pfSense. Done.
And as for how many v6 IPs, if your pfSense can do 6RD, you actually have a /60 (which is 16 /64's) for each v4 address you have (so 2^68 per static IP or 2^72 addresses total with your /28).
/M |
|
Reviews:
 ·Google Voice
·Junction Networks
·Callcentric
 ·T-Mobile US
 ·AT&T U-Verse
| reply to mackey
any guesstimates on whether one has 6rd? Seems cool! I haven't heard of 6rd (last I really played with IPv6 was in 2004), but this looks too good to be true, coming from AT&T!
Not having any 6rd-ready boxes, is there a way to guesstimate whether my FTTH already has 6rd support?
I've tried the `printf "%02x%02x:%02x%02x\n" 99 124 xxx xxx` trick from »www.litech.org/6rd/, and appended that to "2602:300:" as if it was a /32 (although you mentioned /28 and it is indeed a /24, so how should I pre-pend/append with 6rd, then?), getting something like 2602:300:637c:yyyy::1, and trying to traceroute6 it from a remote location (say, Europe), to see if traceroute6 would be indicative of getting it to Santa Clara County, California. Apparently, it didn't — some routers within 10ms of NY seem to be the last routers reachable. :-( |
|
| Because it's a /28, the colons don't line up nice.
Say you're IP is 100.150.200.250. `printf` gives 6496:c8fa, so move the colon one place to the right and add another: 6:496c:8fa. Make sure the last part stays left-justified by padding with a 0: 6:496c:8fa0. Now, remove the last 0 off the prefix "2602:300::" and paste it all together: 2602:306:496c:8fa0:: You can now assign 2602:306:496c:8fa0::1/60 to the 6RD interface (heck, even assigning that to a 6to4 might work...) and it should work.
/M |
|
Reviews:
·Google Voice
·Junction Networks
·Callcentric
·T-Mobile US
·AT&T U-Verse
| Ha! Didn't know it was quite that straightforward! But if they leave 4 bits for your personal use, how come you mention you only get /64, instead of /60?
The traceroute6 route preview guesstimate totally works now! For both dynamic and static addresses that I have! The traceroute6 now definitely reaches Santa Clara, based on ping times!
printf "%02x%02x:%02x%02x\n" 76 220 xx xx ; printf "%02x%02x:%02x%02x\n" 99 124 xxx xxx
4cdc:20yy
637c:YYYY
From MSK.
# traceroute6 2602:304:cdc2:0yy0::1 ; traceroute6 2602:306:37cY:YYY0::1
traceroute6 to 2602:304:cdc2:0yy0::1 (2602:304:cdc2:yy0::1) from Z, 16 hops max, 12 byte packets
Skipping 2 intermediate hops
3 xe012-438.RT.MR.MSK.RU.retn.net 1.320 ms 1.191 ms 1.248 ms
4 RT.TLX.NYC.US.retn.net 124.866 ms 124.400 ms 125.080 ms
5 as7018-att.10gigabitethernet2-3.core1.nyc4.he.net 137.598 ms 179.680 ms 150.144 ms
6 * * *
7 * * *
8 2001:1890:ff:ffff:12:122:99:125 139.270 ms 138.714 ms 138.885 ms
9 2602:300:c533:1510::4 138.903 ms 138.695 ms 138.780 ms
10 2602:300:c533:1510::5 189.738 ms 189.757 ms 190.096 ms
11 * * *
12 * * *
13 * * *
14 2602:300:c533:1510::5 190.810 ms 190.647 ms 190.884 ms
traceroute6 to 2602:306:37cY:YYY0::1 (2602:306:37cY:YYY0::1) from Z, 16 hops max, 12 byte packets
Skipping 2 intermediate hops
3 xe012-438.RT.MR.MSK.RU.retn.net 1.245 ms 1.090 ms 1.112 ms
4 RT.TLX.NYC.US.retn.net 124.698 ms 124.320 ms 124.783 ms
5 as7018-att.10gigabitethernet2-3.core1.nyc4.he.net 137.132 ms 137.704 ms 138.025 ms
6 * * *
7 * * *
8 2001:1890:ff:ffff:12:122:99:125 139.692 ms 140.326 ms 139.774 ms
9 2602:300:c533:1510::4 138.898 ms 139.584 ms 145.563 ms
10 2602:300:c533:1510::5 189.704 ms 190.298 ms 190.905 ms
11 * * *
12 2602:300:c533:1510::5 194.267 ms 192.703 ms 191.208 ms
13 * * *
14 * * *
15 2602:300:c533:1510::5 191.379 ms * 190.522 ms
16 * * *
From FMT (at&t has a crappy route, but the routing definitely gets full trip to LA and safely back to the Bay Area).
# traceroute6 2602:304:cdc2:0yy0::1 ; traceroute6 2602:306:37cY:YYY0::1
traceroute to 2602:304:cdc2:0yy0::1 (2602:304:cdc2:yy0::1), 16 hops max, 80 byte packets
2 10gigabitethernet2-3.core1.fmt1.he.net (2001:470:1:1db::1) 8.677 ms 8.680 ms 8.721 ms
3 gige-g4-8.core1.fmt2.he.net (2001:470:0:2d::2) 0.376 ms 0.427 ms 0.416 ms
4 10gigabitethernet6-4.core1.lax1.he.net (2001:470:0:18d::2) 8.487 ms 8.496 ms 8.669 ms
5 10gigabitethernet1-3.core1.lax2.he.net (2001:470:0:72::2) 12.416 ms 12.880 ms 13.510 ms
6 att-internet4-as7018.10gigabitethernet5-2.core1.lax2.he.net (2001:470:0:1e6::2) 9.267 ms 9.335 ms 9.417 ms
7 * * *
8 * * *
9 2001:1890:ff:ffff:12:122:114:41 (2001:1890:ff:ffff:12:122:114:41) 21.074 ms 21.109 ms 21.086 ms
10 2602:300:c533:1510::5 (2602:300:c533:1510::5) 20.761 ms 20.756 ms 20.812 ms
11 2602:300:c533:1510::5 (2602:300:c533:1510::5) 22.213 ms 21.943 ms 22.371 ms
traceroute to 2602:306:37cY:YYY0::1 (2602:306:37cY:YYY0::1), 16 hops max, 80 byte packets
2 10gigabitethernet2-3.core1.fmt1.he.net (2001:470:1:1db::1) 0.536 ms 0.499 ms 0.443 ms
3 gige-g4-8.core1.fmt2.he.net (2001:470:0:2d::2) 4.335 ms 4.997 ms 4.995 ms
4 10gigabitethernet6-4.core1.lax1.he.net (2001:470:0:18d::2) 8.663 ms 8.649 ms 8.635 ms
5 10gigabitethernet1-3.core1.lax2.he.net (2001:470:0:72::2) 9.270 ms 9.617 ms 9.201 ms
6 att-internet4-as7018.10gigabitethernet5-2.core1.lax2.he.net (2001:470:0:1e6::2) 9.574 ms 9.549 ms 9.511 ms
7 * * *
8 * * *
9 2001:1890:ff:ffff:12:122:114:41 (2001:1890:ff:ffff:12:122:114:41) 21.208 ms 21.135 ms 21.165 ms
10 2602:300:c533:1510::5 (2602:300:c533:1510::5) 20.762 ms 20.773 ms 20.798 ms
11 * * *
12 * * *
13 * * *
14 * * *
15 2602:300:c533:1510::5 (2602:300:c533:1510::5) 22.326 ms 23.112 ms 22.765 ms
16 * * *
Wow... This is truly a surprise! Thanks a lot for sharing!
I guess I just have to find a router with 6RD support, and I might be all set, much earlier than expected? WOW. Is this for real? What's next? Finally the 40/10 HSI for BPON subscribers? :-) Or 200/100 HSI with a GPON upgrade? (-: |
|
| said by ConstantineM:Ha! Didn't know it was quite that straightforward! But if they leave 4 bits for your personal use, how come you mention you only get /64, instead of /60? While you get a /60 for each v4 IP you have, the NVG is only capable of advertising a single /64 to the LAN. To get the full /60 you'll need to use your own 6RD capable router.
/M |
|
| What 6rdBRIPv4Address do you use? I see that Comcast has 6rd.comcast.net that people seem to be using, what's at&t's?
Is there any quick way to test whether 6rd would actually indeed work on one's connection? |
|
| said by ConstantineM:Is there any quick way to test whether 6rd would actually indeed work on one's connection? Yes, it does work for everyone. I PM'd you the address.
/M |
|
Reviews:
·Google Voice
·Junction Networks
·Callcentric
·T-Mobile US
·AT&T U-Verse
| reply to ConstantineM
6rd is long as live on at&t!Nevermind. I think I found it, thanks to your pic, a simple »www.google.com/search?q=12.83+at···er+relay reveals »forums.att.com/t5/forums/forumto···e/page/1 — 12.83.49.81.
Let's see:
% ping -c4 12.83.49.81
PING 12.83.49.81 (12.83.49.81): 56 data bytes
64 bytes from 12.83.49.81: icmp_seq=0 ttl=59 time=1.774 ms
64 bytes from 12.83.49.81: icmp_seq=1 ttl=59 time=1.702 ms
64 bytes from 12.83.49.81: icmp_seq=2 ttl=59 time=1.626 ms
64 bytes from 12.83.49.81: icmp_seq=3 ttl=59 time=1.590 ms
--- 12.83.49.81 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.590/1.673/1.774/0.071 ms
% traceroute -I 12.83.49.81
traceroute to 12.83.49.81 (12.83.49.81), 32 hops max, 60 byte packets
5 12.83.39.137 (12.83.39.137) 2.334 ms 1.492 ms 1.963 ms
6 12.83.49.81 (12.83.49.81) 1.331 ms 1.250 ms 1.259 ms
Wow. I'm getting all excited! (-: |
|
| Wow at&t might fully deploy ipv6 before it upgrades speeds again |
|
| reply to ConstantineM
I can confirm this is working on a 2wire with a linux box plugged in on DMZ.
ip tunnel add 6rd mode sit local 99.52.xx.xx ttl 64
ip tunnel 6rd dev 6rd 6rd-prefix 2602:300::/32
ip addr add 2602:306:334b:xxxx::1/60 dev 6rd
ip link set 6rd up
ip route add ::/0 via ::12.83.49.81 dev 6rd
I'm able to pull down the full 24mbps over ipv6 so no more 64kbps 6to4 tunnels for me  |
|
| said by EZJohnson:ip tunnel 6rd dev 6rd 6rd-prefix 2602:300::/32 Hmmm, you may have some trouble if you try to access other sites also tunnelling. That line should be:
ip tunnel 6rd dev 6rd 6rd-prefix 2602:300::/28
What you have will work fine for accessing non-tunnelled sites though
/M |
|
| reply to EZJohnson
The 6rd (not 6RD BTW) settings are below:
• The 6rd service provider prefix is 2602:300::/28.
• The 6rd IPv4 mask length is 0.
• The 6rd border router (BR) IPv4 address is 12.83.49.81.
• The DNS IPv4 server addresses should be set to 99.99.99.53, 99.99.99.153.
• The DNS IPv6 server addresses should be set to 2001:1890:0FFF:0840::10, 2001:1890:0FFF:0841::10 (if needed)
• Enable sending all 6rd traffic to the 6rd BR |
|
1 edit | In other news, does anyone have this actually working? My setup is having issues and I'm not sure if it's my router or AT&T.
I can ping6 stuff just fine, ipv6.google.com loads just fine, but anything that actually transfers data doesn't work. hxxps:// hangs at 'connected', hxxp:// hangs at 'waiting for ...', all speedtests time out, and scp copies just hang. It looks like PMTU discovery is totally broken from the internet, and that's kinda important when tunnelling! Actually, it looks like ALL ICMP to/from the 6rd gateway is filtered...
I can run `ping6 -M do -c1 -s1440 2607:f878::xyz` from inside my network to my dedicated server and it correctly returns:
PING 2607:f878::xyz(2607:f878::xyz) 1440 data bytes
From 2602:306::zzz icmp_seq=1 Packet too big: mtu=1480
But when I run it from my server back to my network here, it simply times out (1 packets transmitted, 0 received, 100% packet loss, time 2873ms). It works fine as long as I use -s1432 or less.
Can anyone using 6rd post a IPv6 speedtest?
/M
Edit: found a ipv6-only site big enough to not load: »ipv6.bjornerback.com/ . I can `wget` it from my server just fine, but nada from AT&T's connection. Does it work for anyone else? |
|
ccjunk
join:2006-06-29
Austin, TX | said by mackey:In other news, does anyone have this actually working? My setup is having issues and I'm not sure if it's my router or AT&T.
...
But when I run it from my server back to my network here, it simply times out (1 packets transmitted, 0 received, 100% packet loss, time 2873ms). It works fine as long as I use -s1432 or less.
Are you running 6rd on the AT&T provided CPE or on your own router? If on your own router then you may need to set the MTU for the 6rd tunnel interface. 1472B should be safe (1500-20B 6rd header and 8B PPPoE header if on PPP based DSL; although PPP overhead should not present on U-Verse). |
|
| said by ccjunk:Are you running 6rd on the AT&T provided CPE or on your own router? If on your own router then you may need to set the MTU for the 6rd tunnel interface. 1472B should be safe (1500-20B 6rd header and 8B PPPoE header if on PPP based DSL; although PPP overhead should not present on U-Verse). Both actually. I mainly use my own router, but what you posted is irrelevant - outgoing (which is what is affected by the interfaces' MTU) works just fine for all packet sizes, it's the INCOMING that's failing. I can run tcpdump on the WAN interface and see the tunnelled smaller packets coming in, but the big ones never make it that far.
/M |
|
ccjunk
join:2006-06-29
Austin, TX | said by mackey:said by ccjunk:Are you running 6rd on the AT&T provided CPE or on your own router? If on your own router then you may need to set the MTU for the 6rd tunnel interface. 1472B should be safe (1500-20B 6rd header and 8B PPPoE header if on PPP based DSL; although PPP overhead should not present on U-Verse). Both actually. I mainly use my own router, but what you posted is irrelevant - outgoing (which is what is affected by the interfaces' MTU) works just fine for all packet sizes, it's the INCOMING that's failing. I can run tcpdump on the WAN interface and see the tunnelled smaller packets coming in, but the big ones never make it that far. /M While not relevant to your ping tests, the outbound IPv6 MTU is relevant for TCP because the client will use it for setting its advertised MSS value which in turn will limit the packet size the Internet server sends. The client in your home network will set the TCP MSS to MTU-60B (IPv6+TCP overhead).
I just did a capture on a PC connected to the NVG510. In the IPv6 router advertisement from the NVG510 the MTU option is set to 1472 and my PC set the MSS in its TCP handshake to 1412. That forced the Internet v6 server to limit the IPv6 packets it sent to 1472B in size.
If you are doing IPv6 TCP and are having a problem with packet size, maybe your non-NGV510 router is not setting the MTU option (or is setting a value too large) in its router advertisements? |
|
Reviews:
·Google Voice
·Junction Networks
·Callcentric
·T-Mobile US
·AT&T U-Verse
| reply to ConstantineM
6rd just works indeed! Even when your OS doesn't support it!Over at my FTTU and IPv4-wise, my ZyXEL router stopped working around midnight today (2012-02-15T00) for good, and the connexion seemed quite dead when trying to revive it directly at the ONT with an OpenBSD netbook, too. 2Wire PoS has been disconnected for several months, but I guess they do have that crappy authentication going on after all? Had to put the 2Wire PoS back into service, leaving no excuse not to try 6rd.
6rd is quite boring. It just works. :-)
This is on OS X 10.5 (yes, 10.5, which obviously has no 6rd support).
% printf "%02x%02x:%02x%02x\n" 99 124 xxx xxx
637c:YYYY
sudo ifconfig gif0 tunnel 99.124.xxx.xxx 12.83.49.81
sudo ifconfig gif0 inet6 2602:306:37cY:YYY0::1 prefixlen 60
sudo route add -inet6 default -interface gif0
% traceroute -I 12.83.49.81
traceroute to 12.83.49.81 (12.83.49.81), 32 hops max, 60 byte packets
5 12.83.39.137 (12.83.39.137) 3.583 ms 2.173 ms 1.882 ms
6 12.83.49.81 (12.83.49.81) 1.813 ms 1.518 ms 1.540 ms
% traceroute6 ns4.linode.com
traceroute6 to ns4.linode.com (2600:3c03::a) from 2602:306:37cY:YYY0::1, 30 hops max, 12 byte packets
1 2602:300:c533:1510::5 (2602:300:c533:1510::5) 2.209 ms 1.871 ms 1.815 ms
2 sfcca01jt.ip.att.net (2001:1890:ff:ffff:12:122:126:241) 3.612 ms 3.588 ms 3.687 ms
3 2001:1890:1fff:40d:192:205:33:50 (2001:1890:1fff:40d:192:205:33:50) 5.432 ms * 5.567 ms
4 nyk-b2-v6.telia.net (2001:2000:3018:39::1) 77.77 ms 78.044 ms 78.822 ms
5 nac-ic-114014-nyk-b2.c.telia.net (2001:2000:3080:46::2) 76.989 ms 77.049 ms 76.955 ms
6 e1.2.tbr2.mmu.nac.net (2001:518:1001:3::2) 77.676 ms 77.757 ms 77.78 ms
7 Vlan805.esd1.mmu.nac.net (2001:518:2001:5::2) 78.886 ms 80.195 ms 78.718 ms
8 2001:518:2800:3::2 (2001:518:2800:3::2) 78.69 ms 78.849 ms 78.725 ms
9 ns4.linode.com (2600:3c03::a) 78.33 ms 77.946 ms 77.767 ms
% traceroute ns4.linode.com
traceroute to ns4.linode.com (207.192.70.10), 32 hops max, 40 byte packets
5 12.83.39.137 (12.83.39.137) 3.591 ms 2.302 ms 2.418 ms
6 ppp-151-164-52-233.rcsntx.swbell.net (151.164.52.233) 4.896 ms 4.254 ms 4.098 ms
7 asn4436-nlayer.pxpaca.sbcglobal.net (151.164.46.70) 6.131 ms 6.476 ms 8.813 ms
8 ae0-80g.cr1.pao1.us.nlayer.net (69.22.153.18) 5.656 ms 4.189 ms 4.074 ms
9 ae1-60g.cr1.sfo1.us.nlayer.net (69.22.143.169) 5.371 ms 5.289 ms 5.062 ms
10 xe-1-2-0.cr1.slc1.us.nlayer.net (69.22.142.96) 22.531 ms 22.867 ms 22.016 ms
11 xe-0-3-0.cr1.ord1.us.nlayer.net (69.22.142.101) 56.448 ms 56.244 ms 55.929 ms
12 xe-9-2-0.cr1.ewr1.us.nlayer.net (69.22.142.75) 75.541 ms 75.642 ms 75.418 ms
13 ae1-70g.ar2.ewr1.us.nlayer.net (69.31.94.118) 80.255 ms 79.729 ms 76.732 ms
14 as8001.xe-3-0-6.ar2.ewr1.us.nlayer.net (69.31.95.130) 77.457 ms 76.987 ms 76.975 ms
15 0.e1-2.tbr1.mmu.nac.net (209.123.10.118) 78.117 ms 77.715 ms 78.437 ms
16 vlan803.esd2.mmu.nac.net (209.123.10.30) 78.247 ms 77.647 ms 77.971 ms
17 207.99.53.46 (207.99.53.46) 78.274 ms 77.553 ms 77.599 ms
18 ns4.linode.com (207.192.70.10) 78.482 ms 78.088 ms 78.224 ms
% traceroute ns2.linode.com
traceroute to ns2.linode.com (65.19.178.10), 32 hops max, 40 byte packets
5 12.83.39.137 (12.83.39.137) 3.102 ms 2.376 ms 2.672 ms
6 12.122.200.9 (12.122.200.9) 3.967 ms 3.606 ms 3.714 ms
7 dcr2-so-3-0-0.washington.savvis.net (192.205.32.46) 6.394 ms 192.205.32.50 (192.205.32.50) 5.996 ms 208.51.134.1 (208.51.134.1) 6.122 ms
8 po1-20G.ar3.SJC2.gblx.net (67.16.134.26) 5.954 ms 188.998 ms 200.258 ms
9 Hurrican-Electric-LLC.Port-channel100.ar3.SJC2.gblx.net (64.214.174.246) 6.361 ms 6.022 ms 5.615 ms
10 10gigabitethernet1-1.core1.fmt1.he.net (72.52.92.109) 9.235 ms 17.773 ms 6.752 ms
11 linode-llc.10gigabitethernet2-3.core1.fmt1.he.net (64.62.250.6) 10.632 ms 8.125 ms 7.812 ms
12 ns2.linode.com (65.19.178.10) 7.259 ms 6.758 ms 6.698 ms
% traceroute6 ns2.linode.com
traceroute6 to ns2.linode.com (2600:3c01::a) from 2602:306:37cY:YYY0::1, 30 hops max, 12 byte packets
1 2602:300:c533:1510::5 (2602:300:c533:1510::5) 2.729 ms 1.91 ms 1.766 ms
2 la2ca02jt.ip.att.net (2001:1890:ff:ffff:12:122:127:43) 14.564 ms 14.409 ms 14.385 ms
3 10gigabitethernet5-2.core1.lax2.he.net (2001:470:0:1e6::1) 14.458 ms 15.662 ms 24.833 ms
4 10gigabitethernet2-1.core1.lax1.he.net (2001:470:0:72::1) 14.206 ms 14.287 ms 14.391 ms
5 10gigabitethernet7-4.core1.fmt2.he.net (2001:470:0:18d::1) 22.733 ms 23.853 ms 25.081 ms
6 gige-g4-18.core1.fmt1.he.net (2001:470:0:2d::1) 22.758 ms 22.674 ms linode-llc.10gigabitethernet2-3.core1.fmt1.he.net (2001:470:1:1db::2) 23.296 ms
7 ns2.linode.com (2600:3c01::a) 22.903 ms 22.875 ms 22.795 ms
Routing to the first and second IPv6 hops is absolutely great, just as good as comparative IPv4 hops. (No bunch of useless hops anymore.)
However, AT&T's in-network IPv6 routing is oftentimes far from optimal: traffic from AT&T SJC to ISC PAO goes through Chicago, HE FMT — through LAX, but other routes are pretty decent.
Out of other possible problems, seems like dns6rd1.sbcglobal.net and dns6rd2.sbcglobal.net are not anycast, so, the unicast-based CDNs seem to suffer greatly from poor DNS resolution. But the 6rd gateway, 12.83.49.81, is definitely anycast, no questions there! I am still coloured impressed. :-) You don't get 1.5ms tunnel endpoints on residential connexions here and there. :) |
|
