Cox Communication (NOT) using IPv6 transition mechanism 6to4 Relay anycast prefix

This is how Cox is providing us with IPv6 today.

(2/16 UPDATE – I WAS WRONG, MORE DETAILS OF CORRECTION AT BOTTOM OF POST. I AM GETTING IPV6 THROUGH 6TO4 ANYCAST RELAY, BUT NOT PROVIDED BY COX. THIS ARTICLE IS STILL VALID, JUST THAT IT’S NOT COX SUPPLYING IT)

http://www.ietf.org/rfc/rfc3068.txt

Check the comments out on this:
http://whois.arin.net/rest/net/NET-192-88-99-0-1

And what happens when I traceroute to 192.88.99.1 from home:

bash-3.2# traceroute 192.88.99.1
traceroute to 192.88.99.1 (192.88.99.1), 64 hops max, 52 byte packets
1 192.168.1.1 (192.168.1.1) 9.293 ms 1.226 ms 1.377 ms
2 * * *
3 ip68-2-6-13.ph.ph.cox.net (68.2.6.13) 11.628 ms 21.922 ms 20.776 ms
4 mcdlcorc01-pos-0-7-0-0.ph.ph.cox.net (70.169.72.72) 14.446 ms 13.268 ms 12.821 ms
5 mcdldsrj01-ae2.0.rd.ph.cox.net (70.169.76.225) 11.153 ms 13.696 ms 11.566 ms
6 langbprj01-ae0.0.rd.la.cox.net (68.1.0.232) 62.351 ms 62.540 ms 25.255 ms
7 192.88.99.1 (192.88.99.1) 33.012 ms 26.051 ms 34.163 ms

And on my mac, this file already existed:

bash-3.2# cat /etc/6to4.conf
# 6to4.conf
# Configuration file for 6to4 tunnel
#

$in_if=""; # Inside (usually ethernet) interface - for local network

$v6_net="1"; # 2002:x:x:v6_net::
$v6_innernet="2"; # 2002:x:x:v6_innernet::
$v6_prefixlen=16; # Change for more
$hostbits6=":1"; # should be determined via MAC of $in_if

# Possible remote 6to4 routers:
# Anycast is default per RFC 3068, but can select another if desired

$peer="6to4-anycast"; # RFC 3068 magic value
#$peer="6to4.ipv6.fh-regensburg.de"; # Germany, Europe
#$peer="asterix.ipv6.bt.com"; # Great Britain, Europe
#$peer="6to4.kfu.com"; # USA, West coast
#$peer="6to4.ipv6.microsoft.com"; # USA, West coast
#$peer="ipv6-router.cisco.com"; # USA, West coast; register at http://www.cisco.com/ipv6/

IN OTHER WORDS:
My mac was configured already for 6to4-anycast. So, it would automatically try to find a 6to4 relay router at 192.88.99.1. When Cox (2/16 DISCOVERY – IT’S REALLY SOMEONE ELSE) spun up theirs, my MacBook found it, ’cause it’s been looking for it since the day I got my MacBook.

SCARY:
This 6to4-anycast comes with a security consideration. From the RFC:

The generic security risks of 6to4 tunneling and the appropriate protections are discussed in [RFC3056]. The anycast technique introduces an additional risk, that a rogue router or a rogue AS would introduce a bogus route to the 6to4 anycast prefix, and thus divert the traffic. IPv4 network managers have to guarantee the integrity of their routing to the 6to4 anycast prefix in much the same way that they guarantee the integrity of the generic v4 routing.

Well, Cox Communications , I gotta hand it to you, you’re ahead of the curve, and I thank you for providing me with IPv6 well before the industry demands it. You’re a leader in the IPv6 revolution. (2/16 UPDATE – I STILL THINK COX COMMUNICATIONS IS AHEAD OF THE CURVE, BUT THIS 6TO4 ANYCAST RELAY IS NOT PROVIDED BY COX)

Dave.

(2/16 CORRECTION: QUOTE FROM CREDITABLE SOURCE: “…from this trace that it looks like you are heading toward a peering center. And without reverse dns on the RFC3068 anycast address it is very possible that the 6to4 relay you are seeing is indeed hanging off another provider’s peering router. This is one of the joyous side effects of an interprovider announced anycast address especially for ops teams that have to troubleshoot this nightmare.” THIS IS INDEED SCARY, BECAUSE I HAVE NO IDEA WHO IS PROVIDING ME WITH THIS 6TO4 RELAY SERVICE. GRANTED, I LOVE IT, BUT IT’S KIND OF WEIRD THAT MY MACBOOK WILL JUST REACH OUT AND ATTACH TO WHATEVER 6TO4 RELAY IT CAN FIND. I THINK I CAN DO A TRACEROUTE6 TO AN IPV6 SITE AND FROM THAT DETERMINE THE PATH AND POSSIBLY THE PROVIDER OF THIS 6TO4 RELAY FOR ME. I’LL DO THAT TONIGHT WHEN I GET HOME AND ADD COMMENT TO CLARIFY)