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)
Check the comments out on this:
And what happens when I traceroute to 22.214.171.124 from home:
bash-3.2# traceroute 126.96.36.199 traceroute to 188.8.131.52 (184.108.40.206), 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 (220.127.116.11) 11.628 ms 21.922 ms 20.776 ms 4 mcdlcorc01-pos-0-7-0-0.ph.ph.cox.net (18.104.22.168) 14.446 ms 13.268 ms 12.821 ms 5 mcdldsrj01-ae2.0.rd.ph.cox.net (22.214.171.124) 11.153 ms 13.696 ms 11.566 ms 6 langbprj01-ae0.0.rd.la.cox.net (126.96.36.199) 62.351 ms 62.540 ms 25.255 ms 7 188.8.131.52 (184.108.40.206) 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 220.127.116.11. 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.
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)
(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)
545 thoughts on “Cox Communication (NOT) using IPv6 transition mechanism 6to4 Relay anycast prefix”
And from what I can gather, it’s Jason Weil, principal architect at Cox Communication, that’s making this happen, from the fragments of messages I can find on this topic online. To date, I haven’t found any statement from Cox that explains what they’re doing exactly, just generic statements about IPv6 trials underway, and Jason Weil is often quoted. Thank you Jason, for your valor in this revolution.
s1mait-dkoop:~ dkoopman$ traceroute6 ipv6.netflix.com
traceroute6 to ipv6.netflix.com (2620:0:ef0:13::20) from 2002:48de:d30c::226:bbff:fe08:456c, 64 hops max, 12 byte packets
1 * * *
2 2002:c058:6301::1 28.610 ms 32.066 ms 31.056 ms
3 gige-g4-12.core1.lax1.he.net 42.371 ms 37.917 ms 49.380 ms
4 laiix.fr3.lax.llnw.net.net 97.092 ms 97.853 ms 97.686 ms
5 2607:f4e8:1:6::2 112.460 ms 115.751 ms 137.240 ms
6 2607:f4e8:1:7c::2 117.193 ms
tge1-1.fr4.lax.ipv6.llnw.net 173.787 ms
2607:f4e8:1:7c::2 113.307 ms
7 2607:f4e8:1160::2 33.169 ms 47.899 ms 40.783 ms
* * *
* * *
everything times out after that, but the point is he.net. That’s Hurricane Electric. From there it goes right into Limelight. Interesting. Anyway, HE, they’re the ones really providing the 6to4 anycast relay.
Comments are closed.