You are viewing mmol_6453

 
 
30 January 2011 @ 07:43 pm
IPv6 tunnel reliability, and testing aspects of 6to4 without touching IPv6  
As I've been poking at IPv6 more (and considering SBC doesn't offer native IPv6, this means some kind of tunneling), I've been discovering I know folks who have experience using some kind of IPv6 tunneling mechanism. As with any additional technical layer, IPv6 tunneling comes with its own areas of limitations.

First, there's going to be added latency; your packets almost certainly aren't going to take the shortest possible path between your machine and their ultimate destination. For an analogy, imagine your packet as a hard drive you want to send to your friend across the state. You're can't drive it there yourself, but you've got a friend across town who'll drive it there for you. It's not going to get there as quickly as if you'd been able to drive it there yourself.

Bandwidth limitations. Your tunnel endpoint is almost certainly serving more clients than just you, and you're consuming its bandwidth twice! (Your packet goes into their network, and then it goes back out.) There's some amazing charity[1] in play when you consider that when you get a tunnel via 6to4, SixXS or Hurricane Electric, you're not being charged usage fees for those service.

Reliability. It's an added layer of complexity to your network, which makes it one more thing that might break.

First, 6to4 tunnels are set up automatically by your local network's 6to4 gateway, between that gateway machine and whatever machine is at 192.88.99.1. That IP address is an anycast address which is automatically routed to the nearest 6to4 relay router (from where your IPv6 packets would get dropped into the open Internet).

The chief complaint I've heard about 6to4 (over other tunnel options) is its reliability. Because 6to4 is dependent on using anycast to find the nearest 6to4 relay, its reliability is going to be largely dependent on that of the 6to4 relay router nearest your network, which is going to be chiefly dependent on where your network is.

So if you want to ask how reliable 6to4 is going to be, for you, the answer is chiefly dependent on where you are.

I run a few servers. Because they're located at prgmr.com and at Linode, I have public IPv4 addresses to go with them. I'd like to be able to make those machines accessible via IPv6. I have public IPv4 addresses, 6to4 converts those to IPv6 addresses in a fairly straightforward manner. 6to4 would seem the simplest option.

To test it, I used mtr, a traceroute program. If you're familiar with using ping for testing connection reliability, then you'll understand the inherent limits of how useful this information is. If you're not familiar with using ping for testing connection reliability, then don't read too much into it; the packet loss numbers are probably the most useful, and the rest is latency details. (None of this tests bandwidth)

This kind of testing is extremely simple to do. Honestly, I spent more time editing the plain-English portions of this post than it took me to set up collecting this data.

Testing from home (I have plain 6Mbit ADSL through SBC):
                                                     Packets               Pings
 Host                                              Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 99-27-175-254.lightspeed.cicril.sbcglobal.net   0.0% 30217    7.4   7.1   7.0 119.2   1.7
 2. dist2-vlan60.klmzmi.ameritech.net               0.1% 30217    7.9   7.2   7.1 129.9   4.3
 3. bb2-10g4-0.klmzmi.sbcglobal.net                 0.0% 30216    8.4   7.1   6.9 120.6   1.8
 4. 151.164.99.169                                  0.0% 30216   16.4  12.5  12.1 153.6  10.6
 5. gige-g2-7.core1.chi1.he.net                     0.0% 30216   13.0  12.5  12.2 187.3   3.7
 6. 192.88.99.1                                     0.0% 30216   12.9  12.4  12.2  83.5   1.4
    10gigabitethernet1-1.core1.mci1.he.net
    10gigabitethernet2-4.core1.nyc4.he.net


Testing from my VPS at prgmr.com:

                                                     Packets               Pings
 Host                                              Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. baraki-prgmr10.prgmr.com                        2.0%   196    0.6   1.6   0.6  52.2   5.1
 2. 72.13.80.25                                     0.0%   196    1.2   4.0   1.1  26.0   4.0
 3. 10gigabitethernet2-1.core1.fmt1.he.net          0.0%   195    1.5   5.7   1.3  21.9   4.8
 4. 10gigabitethernet1-1.core1.pao1.he.net          0.5%   195    1.8   4.4   1.7  12.7   3.5
 5. 192.88.99.1                                     4.6%   195    1.6   1.9   1.6  29.4   2.1



Testing from my VPS at Linode:

                                                     Packets               Pings
 Host                                              Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 63.247.74.43                                    0.0%   183    0.3   0.4   0.3   8.4   0.7
 2. 63.247.64.153                                   0.0%   183    0.4  11.5   0.3 175.2  34.0
 3. 209.51.130.209                                  0.0%   183    0.4   8.4   0.3 214.4  32.5
 4. 198.32.132.75                                   0.0%   182    0.4   3.1   0.4  15.2   3.6
 5. 10gigabitethernet7-1.core1.ash1.he.net          0.0%   182   13.5  17.6  13.4  41.4   5.5
 6. 192.88.99.1                                     0.0%   182   13.2  14.1  13.2  24.0   1.7