written for, and discussion at, http://www.tunnelbroker.net/forums/index.php?topic=2293.0

It would appear that AT&T has quietly added IPv6 support through 6rd for, seemingly, ALL of its customers without telling anyone (specifically, without telling any of the said customers).

All existing customers “are not affected” and don’t know about any such support, since it’s not actually supported by most CPE.

Details are here:

http://www.dslreports.com/forum/r26841639-

If you have Motorola NVG510, it’s enabled by default (yes, that’s how we, the customers, found out!). If you have 2Wire PoS, you can still play around and have it configured through your own equipment (and your equipment doesn’t even has to have 6rd support, e.g. OS X and OpenBSD would do just fine for basic 6rd IPv6 connectivity).

Basically, [b]2602:300::/28[/b] (6rdPrefix/6rdPrefixLen) and [b]12.83.49.81[/b] (6rdBRIPv4Address, which is an anycast) is all you need to get it running, IPv4MaskLen is 0 (use the whole IPv4 address within IPv6, but notice that due to 6rdPrefixLen being /28 (instead of the more conventional /32) you have to do some one-nibble shifting, but the plus side is that you do get a /60 in the end). Plus [b]74.82.42.42[/b] (ordns.he.net.), of course. :-) You can also try the standard dnsr{1,2}.sbcglobal.net, but they have a few problems: http://www.dslreports.com/forum/r26902814-IPv6-6rd-DNS-Cannot-resolve-IPv6-only-zones.

This 6rd from AT&T works great in the Bay Area, but I’ve heard that IPv4-wise, Los Angeles gets routed through San Jose, which is a bummer, since IPv6-wise, HE.net is routed through Los Angeles from San Jose AT&T, hence it would appear like people in LA would have to make three full roundtrips (LA -> SJ over IPv4 (1 round), then SJ -> LA -> SJ over IPv6 (2 rounds)) to reach HE’s FMT IPv6 resources over this 6rd. :-)

[b]This is a must-try if you’re on AT&T![/b]

Here’s a collection of my traceroute6’s:

http://www.dslreports.com/forum/r26907835-IPv6-latency-BayArea-Local-IPv6-around-San-Jose-

Just in case you don’t care for external links:
[code]
% traceroute6 www.google.com
Wed 22 Feb 2012 18:38:09 PST
traceroute6 to www.l.google.com (2001:4860:4001:801::1011) from 2602:306:37cY:YYY0::1, 30 hops max, 12 byte packets
1 2602:300:c533:1510::5 (2602:300:c533:1510::5) 1.579 ms 1.368 ms 1.309 ms
2 sj2ca404me3.ip.att.net (2001:1890:ff:ffff:12:122:119:192) 4.014 ms 4.042 ms 4.007 ms
3 2001:1890:c00:8c02::1116:e9cb (2001:1890:c00:8c02::1116:e9cb) 54.538 ms 55.262 ms 55.846 ms
4 2001:4860::1:0:21 (2001:4860::1:0:21) 5.572 ms 5.374 ms 5.154 ms
5 2001:4860:0:1::1af (2001:4860:0:1::1af) 5.425 ms 5.55 ms 5.343 ms
6 2001:4860:8000:e:92e6:baff:fe53:a202 (2001:4860:8000:e:92e6:baff:fe53:a202) 56.341 ms 57.198 ms 56.167 ms
[/code]

Here’s my traceroute / mtr to the 6rdBRIPv4Address:
[code]
% traceroute -I 12.83.49.81
Wed 22 Feb 2012 18:47:16 PST
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.581 ms 1.700 ms 1.568 ms
6 12.83.49.81 (12.83.49.81) 1.311 ms 1.310 ms 1.107 ms
% mtr -c60 —report{,-wide} 12.83.49.81
Wed 22 Feb 2012 18:49:30 PST
HOST: 99-124-xxx-xxx.uvs.sntcca.sbcglobal.net Loss% Snt Last Avg Best Wrst StDev
1.|— 99-124-xxx-xxx.uvs.sntcca.sbcglobal.net 0.0% 60 0.8 0.4 0.3 0.8 0.1
2.|— 76-220-32-3.lightspeed.sntcca.sbcglobal.net 76.7% 60 2.2 2.5 1.9 5.1 0.9
3.|— 71.145.0.104 98.3% 60 3.3 3.3 3.3 3.3 0.0
4.|— 71.145.0.80 96.7% 60 6.7 6.8 6.7 6.9 0.1
5.|— 12.83.39.137 0.0% 60 1.7 2.1 1.7 2.8 0.2
6.|— 12.83.49.81 0.0% 60 1.6 1.4 1.2 1.6 0.1
[/code]

Here’s traceroute6 to he.net and back (as I mentioned, it goes SJC -> LAX -> FMT, since LA is the closest point where HE and AT&T do IPv6 peering):

[code]
% traceroute6 ns2.linode.com
Wed 22 Feb 2012 19:07:19 PST
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) 1.579 ms 1.2 ms 1.315 ms
2 la2ca02jt.ip.att.net (2001:1890:ff:ffff:12:122:127:43) 129.526 ms 13.831 ms 24.7 ms
3 10gigabitethernet5-2.core1.lax2.he.net (2001:470:0:1e6::1) 13.755 ms 13.938 ms 13.77 ms
4 10gigabitethernet2-1.core1.lax1.he.net (2001:470:0:72::1) 13.843 ms 13.829 ms 13.787 ms
5 10gigabitethernet7-4.core1.fmt2.he.net (2001:470:0:18d::1) 24.908 ms 21.798 ms 21.9 ms
6 gige-g4-18.core1.fmt1.he.net (2001:470:0:2d::1) 22.01 ms 21.99 ms
linode-llc.10gigabitethernet2-3.core1.fmt1.he.net (2001:470:1:1db::2) 22.852 ms
7 ns2.linode.com (2600:3c01::a) 22.439 ms 22.319 ms 22.335 ms
[/code]

[code]
# traceroute6 2602:306:37cY:YYY0::1
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) [AS6939] 5.666 ms 5.782 ms 5.760 ms
3 gige-g4-8.core1.fmt2.he.net (2001:470:0:2d::2) [AS6939] 0.454 ms 0.443 ms 0.532 ms
4 10gigabitethernet6-4.core1.lax1.he.net (2001:470:0:18d::2) [AS6939] 8.514 ms 8.500 ms 8.474 ms
5 10gigabitethernet1-3.core1.lax2.he.net (2001:470:0:72::2) [AS6939] 15.265 ms 8.905 ms 14.903 ms
6 att-internet4-as7018.10gigabitethernet5-2.core1.lax2.he.net (2001:470:0:1e6::2) [AS6939] 8.915 ms 8.988 ms 9.052 ms
7 * * *
8 * * *
9 2001:1890:ff:ffff:12:122:114:41 (2001:1890:ff:ffff:12:122:114:41) [AS7018] 22.141 ms 22.114 ms 22.078 ms
10 2602:300:c533:1510::5 (2602:300:c533:1510::5) [*] 21.171 ms 21.174 ms 21.148 ms
11 * * *
12 * * *
13 * * *
14 2602:300:c533:1510::6 (2602:300:c533:1510::6) [*] 22.154 ms 22.425 ms 22.649 ms
15 2602:300:c533:1510::5 (2602:300:c533:1510::5) [*] 22.280 ms 22.709 ms 23.197 ms
16 2602:306:37cY:YYY0::1 (2602:306:37cY:YYY0::1) [*] 22.543 ms 22.710 ms 23.209 ms
[/code]

Try the following to get your IPv6 prefix from the IPv4 address:

[code]
% printf “%02x%02x%02x%02x” 99 124 xxx xxx | awk ‘{print “2602:30” substr($1,1,1) “:” substr($1,2,4) “:” substr($1,6) “0::/60”}’
2602:306:37cY:YYY0::/60
[/code]

What would be interesting to know are the locations of where 6rdBR’s have been deployed. So far, it’s known that LA uses the one in San Jose, so there doesn’t appear to be a 6rdBR in LA. You can guesstimate the location of your 6rdBR by doing `traceroute 12.83.49.81` from your local AT&T network, or by doing a traceroute6 of your 6rd IPv6 address from a remote network, seeing the latency of the last hop of the 2602:300:c533:1510::/60 origin (which is, you’ve guessed it, the anycast 6rd prefix of the 6rdBR’s 12.83.49.81). Your total latency for a given IPv6 resource over this 6rd would be the sum of these two latencies around the 6rdBR anycast (12.83.49.81 / 2602:300:c533:1510::/60).

Happy 6rd tunnelling!

P.S. I should warn you that this whole info is based solely on user-submitted “reverse-engineered” information. I should also warn you that if you ever decide to go to AT&T’s corporate IPv6 web-site (the link for which is very short and memorable, but is intentionally omitted from this post such as to not waste people’s time), that you will not find a single useful piece of information about anything whatsoever, and the time that you will lose you’ll never get back! (-:

I’m on AT&T’s IPv6 network in San Jose, CA, and I’m trying to find the best edge nodes latency-wise. Here’s what I have so far, California-wise.

% alias traceroute6 traceroute6 -w2 -l

% traceroute6 ipv6.akamai.com
traceroute6 to a152.i6g1.akamai.net (2600:5:3700:2::c703:730b) from 2602:306:37cY:YYY0::1, 30 hops max, 12 byte packets
 1  2602:300:c533:1510::5 (2602:300:c533:1510::5)  1.863 ms  1.149 ms  1.304 ms
 2  sfcca01jt.ip.att.net (2001:1890:ff:ffff:12:122:126:241)  8.013 ms  3.031 ms  3.605 ms
 3  2001:1890:1fff:404:192:205:35:18 (2001:1890:1fff:404:192:205:35:18)  5.989 ms  21.109 ms *
 4  2600:5:3700:2::c703:730b (2600:5:3700:2::c703:730b)  5.248 ms  7.884 ms  5.317 ms

% alias postcmd date

% traceroute6 ipv6.akamai.com
Fri 17 Feb 2012 12:13:45 PST
traceroute6 to a152.i6g1.akamai.net (2001:559:0:301::6011:6d48) from 2602:306:37cY:YYY0::1, 30 hops max, 12 byte packets
 1  2602:300:c533:1510::5 (2602:300:c533:1510::5)  1.701 ms  1.306 ms  1.336 ms
 2  sfcca03jt.ip.att.net (2001:1890:ff:ffff:12:122:126:243)  3.134 ms  2.941 ms  3.006 ms
 3  2001:1890:1fff:400:192:205:37:2 (2001:1890:1fff:400:192:205:37:2)  9.998 ms  7.029 ms  7.734 ms
 4  pos-2-2-0-0-cr01.sanjose.ca.ibone.comcast.net (2001:558:0:f58d::1)  10.499 ms  12.967 ms  10.206 ms
 5  pos-0-4-0-0-pe01.529bryant.ca.ibone.comcast.net (2001:558:0:f5e4::2)  9.635 ms  8.965 ms  8.941 ms
 6  2001:559::16 (2001:559::16)  11.532 ms  8.532 ms  8.35 ms
 7  2001:559:0:301::6011:6d48 (2001:559:0:301::6011:6d48)  8.428 ms  8.403 ms  8.437 ms

% traceroute6 www.limelight.com
Fri 17 Feb 2012 12:14:09 PST
traceroute6 to llnw.vo.llnwd.net (2607:f4e8:110:104:230:48ff:fe87:3054) from 2602:306:37cY:YYY0::1, 30 hops max, 12 byte packets
 1  2602:300:c533:1510::5 (2602:300:c533:1510::5)  1.613 ms  1.336 ms  1.281 ms
 2  sfcca01jt.ip.att.net (2001:1890:ff:ffff:12:122:126:241)  2.917 ms  3.037 ms  2.898 ms
 3  2001:450:2008:100::109 (2001:450:2008:100::109)  70.089 ms  70.23 ms  70.255 ms
 4  2001:450:2002:2c6::2 (2001:450:2002:2c6::2)  16.898 ms  24.493 ms  13.562 ms
 5  ve4.fr3.snv1.ipv6.llnw.net (2607:f4e8:1:a4::2)  14.659 ms  20.964 ms  14.185 ms
 6  cds205.sjc.llnw.net (2607:f4e8:110:104:230:48ff:fe87:3054)  15.343 ms  15.902 ms  16.278 ms

% traceroute6 ipv6.google.com
Fri 17 Feb 2012 12:14:35 PST
traceroute6 to ipv6.l.google.com (2001:4860:4001:800::1011) from 2602:306:37cY:YYY0::1, 30 hops max, 12 byte packets
 1  2602:300:c533:1510::5 (2602:300:c533:1510::5)  1.749 ms  1.173 ms  1.346 ms
 2  sj2ca404me3.ip.att.net (2001:1890:ff:ffff:12:122:119:192)  4.048 ms  3.999 ms  4.059 ms
 3  2001:1890:c00:8c02::1116:e9cb (2001:1890:c00:8c02::1116:e9cb)  50.029 ms  48.965 ms  47.51 ms
 4  2001:4860::1:0:21 (2001:4860::1:0:21)  5.225 ms  5.96 ms  5.481 ms
 5  2001:4860:0:1::1ab (2001:4860:0:1::1ab)  5.381 ms  5.204 ms  5.305 ms
 6  2001:4860:4001:800::17 (2001:4860:4001:800::17)  54.298 ms  53.502 ms  53.744 ms

% traceroute6 ns2.he.net
Fri 17 Feb 2012 12:15:46 PST
traceroute6 to ns2.he.net (2001:470:200::2) from 2602:306:37cY:YYY0::1, 30 hops max, 12 byte packets
 1  2602:300:c533:1510::5 (2602:300:c533:1510::5)  1.601 ms  1.266 ms  1.283 ms
 2  la2ca02jt.ip.att.net (2001:1890:ff:ffff:12:122:127:43)  13.73 ms  13.632 ms  13.996 ms
 3  10gigabitethernet5-2.core1.lax2.he.net (2001:470:0:1e6::1)  18.977 ms  13.617 ms  13.708 ms
 4  10gigabitethernet7-3.core1.sjc2.he.net (2001:470:0:16a::1)  22.056 ms  24.109 ms  24.928 ms
 5  ns2.he.net (2001:470:200::2)  22.112 ms  22.085 ms  21.968 ms

% traceroute6 www.ixsystems.com
Fri 17 Feb 2012 12:16:38 PST
traceroute6 to web.ixsystems.com (2607:fca8:2636:8001::4) from 2602:306:37cY:YYY0::1, 30 hops max, 12 byte packets
 1  2602:300:c533:1510::5 (2602:300:c533:1510::5)  1.629 ms  1.233 ms  1.183 ms
 2  la2ca02jt.ip.att.net (2001:1890:ff:ffff:12:122:127:43)  14.812 ms  13.473 ms  13.863 ms
 3  10gigabitethernet5-2.core1.lax2.he.net (2001:470:0:1e6::1)  14.281 ms  15.176 ms  13.682 ms
 4  10gigabitethernet2-1.core1.lax1.he.net (2001:470:0:72::1)  13.531 ms  18.466 ms  20.744 ms
 5  2607:fca8:1530::1 (2607:fca8:1530::1)  13.688 ms  13.865 ms  13.782 ms
 6  2607:fca8:2636:8001::4 (2607:fca8:2636:8001::4)  14.136 ms  14.481 ms  14.672 ms

% traceroute6 www.arpnetworks.com
Fri 17 Feb 2012 12:17:02 PST
traceroute6 to www.arpnetworks.com (2607:f2f8:0:102::3) from 2602:306:37cY:YYY0::1, 30 hops max, 12 byte packets
 1  2602:300:c533:1510::5 (2602:300:c533:1510::5)  1.74 ms  1.222 ms  1.182 ms
 2  sfcca01jt.ip.att.net (2001:1890:ff:ffff:12:122:126:241)  113.136 ms  3.134 ms  2.922 ms
 3  2001:450:2008:100::109 (2001:450:2008:100::109)  150.088 ms 2001:450:2008:100::c5 (2001:450:2008:100::c5)  69.797 ms  70.066 ms
 4  * * *
 5  2607:f2f8:100:105::1 (2607:f2f8:100:105::1)  14.123 ms  14.058 ms  14.096 ms
 6  www.arpnetworks.com (2607:f2f8:0:102::3)  14.616 ms  14.429 ms  14.47 ms

% traceroute6 obsd.isc.org
Fri 17 Feb 2012 12:20:22 PST
traceroute6 to obsd.isc.org (2001:4f8:3:36::217) from 2602:306:37cY:YYY0::1, 30 hops max, 12 byte packets
 1  2602:300:c533:1510::5 (2602:300:c533:1510::5)  1.753 ms  1.213 ms  1.905 ms
 2  sfcca01jt.ip.att.net (2001:1890:ff:ffff:12:122:126:241)  2.957 ms  4.544 ms  3.373 ms
 3  2001:1890:1fff:40d:192:205:33:50 (2001:1890:1fff:40d:192:205:33:50)  4.895 ms *  5.069 ms
 4  chi-bb1-v6.telia.net (2001:2000:3018:2c::1)  55.734 ms  55.583 ms  55.652 ms
 5  isc-ic-117366-chi-bb1.c.telia.net (2001:2000:3080:138::2)  55.852 ms  56.083 ms  56.078 ms
 6  int-0-0-1-8.r1.pao1.isc.org (2001:4f8:0:1::4a:1)  108.838 ms  108.864 ms  110.633 ms
 7  int-0-1-0-0.r1.sql1.isc.org (2001:4f8:1b:1::8:2)  112.205 ms  108.617 ms  109.507 ms
 8  2001:4f8:3:36::217 (2001:4f8:3:36::217)  108.234 ms  107.538 ms  108.512 ms

So far, the now-disappeared DNS resolution of ipv6.akamai.com over at Sprint seemed to have had the best latency earlier this morning, of only 5.3ms.

IPv4-wise, I can still get 3.7ms to some CDN host at nlayer.net (see http://www.dslreports.com/forum/remark,26669632 and the traceroute below), so, I’m thinking that something around 4ms should be entirely possible with IPv6, too.

% traceroute -I 69.22.162.122 
Fri 17 Feb 2012 12:41:33 PST
traceroute to 69.22.162.122 (69.22.162.122), 32 hops max, 60 byte packets
 5  12.83.39.145 (12.83.39.145)  16.198 ms  2.141 ms  1.800 ms
 6  ppp-151-164-52-233.rcsntx.swbell.net (151.164.52.233)  99.646 ms  207.202 ms  5.913 ms
 7  asn4436-nlayer.pxpaca.sbcglobal.net (151.164.46.70)  5.041 ms  4.636 ms  4.421 ms
 8  69.22.162.122 (69.22.162.122)  3.802 ms  3.792 ms  3.710 ms

Any ideas what other IPv6 hosts are in the Bay Area that could have good latency with AT&T’s IPv6 network?

written for, and discussion at, http://www.dslreports.com/forum/r26907835-IPv6-latency-BayArea-Local-IPv6-around-San-Jose-

There seems to be a bit of confusion over which DNS servers the IPv6-enabled customers are supposed to be using. I found that using the regular recursive DNS servers (-4 dnsr{1,2}) from the non-IPv6-enabled-2Wire directly on my OS X does work on resolving AAAA records, but ONLY if the auth NS servers for the domain zone in question are available over IPv4.

Please note that in the scope of this discussion, an “IPv6-only domain” is a domain name that can be resolved ONLY via an IPv6 network, since the NS servers of the zone in question are available ONLY via IPv6. A more correct term would probably be a “domain name within an IPv6-only domain zone”.

Surprisingly, using dns6rd{1,2} does NOT resolve IPv6-only domains, i.e. those that require IPv6 to access its auth NS servers. Making it pretty obvious that dns6rd{1,2} are NOT dual-stacked. WTF? So useless! What’s the purpose of the dns6rd servers if they can’t access IPv6-only domain zones, where the regular dnsr{1,2} already work for AAAA as is?

Seems like dns6rd{1,2} are already EOL at this point, as they offer no advantage whatsoever over -4 dnsr{1,2}, and there’s not even any -6 dns6rd{1,2}, plus they don’t seem to be much of anycast, either.

Using the -6 dnsr{1,2} does resolve IPv6-only domains, but the servers are very far away from me, so they’ll be breaking all those unicast DNS-based CDNs in a snap (e.g. Google, Akamai etc).

Is there an ETA on when either my -4 dnsr{1,2} anycast would be dual-stacked, or the -6 dnsr{1,2} would be anycast’ed locally, instead of going back to Texas or whatnot?

Here are my sample traceroute runs from San Jose, CA. (Note that there’s no -6 dns6rd{1,2}, as already mentioned above.)

[code]
% echo traceroute{\ -IM5,6\ -l}\ -w2\ dns{r,6rd}{1,2}.sbcglobal.net | xargs -n4 | sh
traceroute to dnsr1.sbcglobal.net (68.94.156.1), 64 hops max, 60 byte packets
5 12.83.39.137 (12.83.39.137) 3.464 ms 2.178 ms 1.997 ms
6 151.164.102.35 (151.164.102.35) 3.796 ms 3.268 ms 3.058 ms
7 dnsr1.sbcglobal.net (68.94.156.1) 3.347 ms 2.834 ms 3.005 ms
traceroute to dnsr2.sbcglobal.net (68.94.157.1), 64 hops max, 60 byte packets
5 12.83.39.137 (12.83.39.137) 3.155 ms 1.865 ms 1.857 ms
6 dist1-10g1-2.snfcca.sbcglobal.net (216.102.176.225) 3.463 ms 4.992 ms 3.052 ms
7 dnsr2.sbcglobal.net (68.94.157.1) 3.343 ms 3.147 ms 3.004 ms
traceroute to dns6rd1.sbcglobal.net (99.99.99.53), 64 hops max, 60 byte packets
5 12.83.39.137 (12.83.39.137) 3.051 ms 1.846 ms 1.838 ms
6 12.83.49.11 (12.83.49.11) 44.498 ms 44.029 ms 44.040 ms
7 ppp-151-164-39-47.rcsntx.swbell.net (151.164.39.47) 44.457 ms 43.917 ms 46.538 ms
8 dns6rd1.sbcglobal.net (99.99.99.53) 44.564 ms 44.067 ms 44.076 ms
traceroute to dns6rd2.sbcglobal.net (99.99.99.153), 64 hops max, 60 byte packets
5 12.83.39.137 (12.83.39.137) 3.059 ms 1.907 ms 1.769 ms
6 bb2-p2-0.snantx.sbcglobal.net (151.164.42.128) 44.352 ms 43.849 ms 43.905 ms
7 ppp-151-164-39-47.rcsntx.swbell.net (151.164.39.47) 43.946 ms 43.907 ms 43.753 ms
8 dns6rd2.sbcglobal.net (99.99.99.153) 43.984 ms 43.546 ms 43.679 ms
traceroute6 to dnsr1.sbcglobal.net (2001:1890:fff:840::10) from 2602:306:37cY:YYY0::1, 30 hops max, 12 byte packets
1 2602:300:c533:1510::5 (2602:300:c533:1510::5) 3.121 ms 2.098 ms 1.968 ms
2 2001:1890:ff:ffff:12:122:100:82 (2001:1890:ff:ffff:12:122:100:82) 47.929 ms 47.989 ms 47.585 ms
3 2001:1890:fff:820:12:122:243:1 (2001:1890:fff:820:12:122:243:1) 47.562 ms 47.671 ms 47.714 ms
4 dnsr1.sbcglobal.net (2001:1890:fff:840::10) 47.718 ms 47.714 ms 47.818 ms
traceroute6 to dnsr2.sbcglobal.net (2001:1890:fff:841::10) from 2602:306:37cY:YYY0::1, 30 hops max, 12 byte packets
1 2602:300:c533:1510::5 (2602:300:c533:1510::5) 2.224 ms 1.868 ms 2.016 ms
2 2001:1890:ff:ffff:12:122:100:82 (2001:1890:ff:ffff:12:122:100:82) 47.57 ms 47.429 ms 47.747 ms
3 2001:1890:fff:820:12:122:243:1 (2001:1890:fff:820:12:122:243:1) 47.372 ms 47.382 ms 47.31 ms
4 dnsr2.sbcglobal.net (2001:1890:fff:841::10) 47.834 ms 47.489 ms 47.508 ms
traceroute6: nodename nor servname provided, or not known
traceroute6: nodename nor servname provided, or not known
[/code]

[code]
% 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.015 ms 1.799 ms 1.976 ms
6 12.83.49.81 (12.83.49.81) 1.908 ms 1.682 ms 1.517 ms
[/code]

written for, and discussion at, http://www.dslreports.com/forum/r26902814-IPv6-6rd-DNS-Cannot-resolve-IPv6-only-zones.

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. :)

written for, and discussion at, http://www.dslreports.com/forum/r26898965-6rd-just-works-indeed-Even-when-your-OS-doesn-t-support-it-

http://www.dslreports.com/forum/remark,26841639 Is at&t for real?

printf "%02x%02x:%02x%02x\n" 76 220 xx xx ; printf "%02x%02x:%02x%02x\n" 99 124 xxx xxx
4cdc:20yy
637c:YYYY

# 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  * * *

# 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  * * *

Isn’t it surprisingly shocking that AT&T with all the same technologies as its competitors in other regions, delivers significantly lower speeds than the said competitors, roughly using about the exact same technologies as the competitors are using?

Right now:

BPON @ Verizon FiOS: 15/5, 25/25 and 50/20. (real speeds are actually higher than advertised)
BPON @ AT&T U-verse: …, 12/1.5 and 18/1.5. (yes, there’s no 24Mbps package on AT&T FTTH)

GPON @ Verizon FiOS: 150/35 in print, 150/75 in reality. :-)
GPON @ AT&T: trials? still 18/1.5?

VDSL2 @ CenturyLink: 40/20.
VDSL2 @ AT&T U-verse: 24/3 for single pair, or 18/1.5 for bonded pair (yes, in that order).

Threads about future plans:

CenturyLink:
http://www.dslreports.com/forum/r26533877-CenturyLink-offers-100mpbs-
http://www.dslreports.com/forum/r26643724-Qwest-Pictures-of-100MBps-and-PRICES-Look-Here
Summary: 100Mbps at rather affordable prices (competitive with FiOS), coming soon, official prices and materials leaked from multiple sources.

AT&T U-verse:
http://www.dslreports.com/forum/r26433752-45-MB-internet-service
Summary: 30/3 and 36/6 for FTTH customers only (http://www.dslreports.com/forum/r26644272-45-MB-internet-service). Still merely an unconfirmed rumour, replaced some other prior unconfirmed rumour about entirely different plans, no solid proof whatsoever for neither the old nor the new info.

Will AT&T ever catch up to its ILEC competitors? Why AT&T’s future plans are lower than the existing plans from its competition? Not even talking about Verizon FiOS 150/75, how could CenturyLink be delivering 40/20 over copper, whereas here in this forum it is claimed that AT&T would have problems with the 3.0 upstream on those bonded VDSL2 lines that are seemingly easily capable of much higher speeds than that?

For the record, although fibre is obviously the future, I think copper still has a lot of life in it left. Just one more proof that it’s not what you have, it’s how you use it, AT&T.

Written for, and discussion at, http://www.dslreports.com/forum/r26671109-How-does-CenturyLink-offer-40-20-when-AT-T-max-is-24-3-

I’m just trying to understand the phenomenon.

Here in the South Bay area, there are a very significant number of medium- and high-rise new apartment and condominium buildings, with 100+ units per building (i.e. per webpass.net’s pricing, they’d offer free building hookup), already having centralised Cat5e or even Cat6, yet there are basically no telecoms who’d steps up and offer any kind of VDSL or Ethernet connectivity at all. Why?

Heck, it seems like the community I’m in right now, is just about the only one that even has AT&T U-verse, thanks the building being pre-glassed with fibreoptics! Residents in most of these other new (2005+) and even newer (2010+) buildings would have to suffice themselves with either Comcast or xDSL from the CO! Seriously? Even AT&T can’t seem to collect their guts and put up a node within the 250 unit buildings, and offer outstanding VDSL2 experience. Why? Where if not within these high-rises (Skyline at Tamien Station, Axis San Jose, The 88 SJ, 360 Residences etc) could the population density be utilised to the fullest extent for the best VDSL results?

Why is noone stepping up? Webpass.net in San Francisco and Paxio.net in Santa Clara are about the only providers I have found so far that even offer this kind of service in principle (both happen to offer residential unlimited symmetric 100/100 under 100$, which is essentially what we’re after here). Both seem reasonably sound, stable and mature, yet there are still thousands of people in the Bay Area living in brand-new buildings with internet connections slower than you can have just about all across the world, including Eastern Europe and South Korea. What’s going on? Why’s noone stepping in? Why not even the most popular CLEC/DLEC in the area, Sonic.net?

In my search, I’m still yet to personally stumble across a building here in the South Bay that’d have Cat5e utilised! I mean, I do have the moral right, if not even an outright obligation, to be surprised here, right? (-:

http://www.dslreports.com/forum/r26345062-Cat5e-in-Bay-Area-large-new-res-buildings-left-unused-

Just filed a complaint with the FCC. Other people with the FTTP may wish to do the same.

If you didn’t have a 2-stage professional installation performed, with an Optical Network Terminal installed, and fibre terminated on your premises, then this does not apply to you. Distance is a reasonable excuse for AT&T not providing 24Mbps for some FTTN customers with copper.

http://esupport.fcc.gov/complaints.htm
«Broadband Service and VoIP»
«Deceptive or unlawful advertising or marketing by a communications company (does NOT include Telemarketing)»
Form 2000B

name + full street address + email

AT&T
telco+isp

====
«
Claims:

0. AT&T advertises that U-verse Internet has a 24Mbps option.

1. It is estimated that well under 10% of AT&T U-verse customers are serviced by a technology similar to Verizon FiOS, commonly called FTTP, where AT&T has fibre on customer’s premises, with an Optical Network Terminal (ONT) box on said premises, where the fibre is terminated and transformed into a Fast Ethernet connection.

2. FTTP technology is widely regarded as the future of the internet, and undisputedly offers speeds considerably higher than what could be achieved on the legacy copper lines through FTTN.

3. AT&T denies FTTP customers the ability to purchase advertised 24Mbps package, offering an 18Mbps package instead. However, 24Mbps speed is available to FTTN customers serviced by copper. There is no official, consistent or plausible explanation ever given, nor does it appear that AT&T officially acknowledges the fact.

I certify I have AT&T U-verse FTTP 18Mbps and I am denied 24Mbps package purchase.
»
(must be under 1000 chars)
====

I invite other FTTP customers to follow suit.

So… I was thinking about this whole AT&T U-verse profiles thing. People who live too far away from a VRAD can get pair bonding with an iNID such that they can still enjoy U-verse at full speed, right?

I can’t deny myself the pleasure to entertain the thought of AT&T doing line-bonding of fibre, since, apparently, their fibre-to-the-premises lines are limited to the 30/3.6 profile that doesn’t support their full 24/3.0 internet offering, whereas for copper customers such internet offering is readily available on a single xDSL line, isn’t it?

Please note that I think that the upload speed is important, and this line bonding would effectively double my speed (as any line bonding should), since I now only have 1.5Mbps, and I’d like to have the fastest-possible 3.0Mbps. I’m so happy AT&T offers 3.0 Mbps on U-verse, it’s my dream come true, I don’t even know what I’m going to do with so much bandwidth, LOL! Uploading a 7 megapixel picture from my Canon PowerShot ELPH 300 HS digital camera will only take like a blazing 5 seconds! It takes 10 seconds right now for each photo. Yeah, I know, 10 seconds is already so blazing fast (don’t even have the time to make the coffee while one picture is being uploaded), but I want the fastest possible of 5 seconds! AT&T is truly Rethink Possible if it can offer 3Mbps upload speeds to residential customers! It’s, like, higher speeds are simply not possible, are they? I mean, right?

For my part, I promise not to be a bandwidth hog; in fact, I hate those people who are hogging the internets! Pipes cannot sustain you guys, please stop and let other people enjoy the net, too! You’re not alone out here, lads and lasses, so please behave and don’t hog the pipes we all share!

As far as the incoming fibre is concerned, my apartment is pre-glassed as follows: the fibre cable comes very-very thick into my apartment, and then a fibre splitter is used to make the fibre cable very-very thin before the thin fibre cable reaches the ONT. So I think there should already be enough of the thick fibre reaching my place to support line splitting at the splitter and line bonding at the ONT, right?

Can I have the splitter split the thick fibre line into two thin ones, and then line bond the fibre at the ONT? (-: Does this make sense? (-: Would I have to have a new ONT that would support line bonding?

I trust this post is taken by AT&T with all seriousness that it deserves. AT&T customers entrust AT&T to deliver the top-notch competitive service at all levels and in all communities, and I hope this would be no exception. I live in San Jose, CA, 95126, and I trust that AT&T offers the fastest fibre internet that is theoretically possible for residential customers and with speed offerings on which anyone can always count. AT&T clearly defines the Rethink Possible motto, being such an innovator in the area, where people can finally have fibre reach out their homes ahead of the competition! I truly hope it’ll be possible to get the fastest 24/3 package with fibre line bonding!

Best regards and thanks in advance,
Constantine dba Vasily Pupkine.

http://www.dslreports.com/forum/r26298279-AT-T-U-verse-FTTP-line-bonding-with-fibre-for-24-3-tier-