IPv6 support via Charter | Ideas on BGP Tunnel via HE

Hello,

Does anyone here has clues on IPv6 support via Charter? We recently got BGP
up on the connection and they denied for IPv6 support for now. Support
engineer gave expected time of something like end of year which seems very
late as per our plans.

Is situation same for everyone who sits in downstream of Charter?

Also, does it makes sense to go for BGP Tunnel for now? I just setup IPv6
Tunnel via Hurricane Electric. Latency seems pretty much OK ~ 10-15ms of
overhead. Yet to test other parameters. I heard Tunnels are usually bad.
Can someone tell how to test this tunnel setup to confirm if there is a
performance issue or not? I am thinking of writing a quick bash script and
run via cron to test latency, packet loss and bandwidth throughput for
couple of days. If anyone has better idea, please let me know.

Thanks.

Hurricane Electric have a presentation on testing their tunnels using Traceroute6, Tracepath6, and mtr:
http://ipv6.he.net/presentations/trace6.pdf

iperf now supports IPv6 and works well for testing tunnels as well.

I have previously gotten good results from Hurricane Electric tunnels.

Anurag,

We (Charter) are planning on starting early field trials with our business customers with IPv6 real soon (within Q2). We have a few customers already identified, but would you be interested in participating with us?

Jim Rampley | Principal Engineer | 314-543-2505
12405 Powerscourt Drive, St. Louis, MO 63131

Hi,

Also, does it makes sense to go for BGP Tunnel for now? I just setup IPv6
Tunnel via Hurricane Electric. Latency seems pretty much OK ~ 10-15ms of
overhead. Yet to test other parameters. I heard Tunnels are usually bad.
Can someone tell how to test this tunnel setup to confirm if there is a
performance issue or not? I am thinking of writing a quick bash script and
run via cron to test latency, packet loss and bandwidth throughput for
couple of days. If anyone has better idea, please let me know.

Also using a HE.net BGP tunnel for our IPv6, simply because having just 1 native provider with Ipv6 isn't redundant. That and it's 8mbit.

The v4 connection which the tunnel connects over is 90mbit, and the tunnel needs to travel from NL to DE for the FRA BGP peering.

I'm getting about 40mbit through the IPv6 tunnel, so i'd say it works well, although the throughput has slowly been dropping to the 30's range over the last 6 months. But that's probably because of the latency.

For something that is provided for free I'm really glad we have it.

I should have peered with their UK PoP as it's much closer by latency, thus faster.

Cheers,

Seth

HE does a fine job with their IPv6 tunnels. If they're you're only v6
connectivity or you need them to provide a backup IPv6 route for when
sole native v6 provider goes down, they're a superb choice.

However...

Do not, do not, do not, rig your system to prefer tunneled IPvanything
to native IPvanythingelse. For all of the obvious reasons.

If you publish an IPv6 address for www.anuragbhatia.com, clients with
IPv6 will use that IPv6 address in preference to the address published
for IPv4. If your sole IPv6 access is with a tunnel, don't publish an
IPv6 address for www. Publish the IPv6 address under
www6.anuragbhatia.com instead. And on your mail server, have the
second MX point to a name with a AAAA, and let the first MX stay on
v4.

Regards,
Bill Herrin

Hi Seth

I just did a test from Eu based server sitting below EU based HE Tunnel
node by downloading Ubuntu release file from US based server. This does not
tells about possible high speed but surely tells what is available atleast.
Server itself is sitting on M-Online with 100Mbps pipe.

IPv4:

traceroute to mirror.anl.gov (146.137.96.7), 30 hops max, 60 byte packets
1 gw.giga-dns.com (91.194.90.1) [AS51167] 16.876 ms 16.925 ms 16.915 ms
2 host-93-104-204-33.customer.m-online.net (93.104.204.33) [AS8767]
1.166 ms 1.449 ms 1.445 ms
3 xe-2-1-0.rt-decix-1.m-online.net (212.18.6.162) [AS8767] 8.889 ms
8.888 ms 8.880 ms
4 20gigabitethernet4-3.core1.fra1.he.net (80.81.192.172) [AS6695] 18.586
ms 19.831 ms 19.824 ms
5 10gigabitethernet1-4.core1.par2.he.net (184.105.213.162) [AS6939]
18.794 ms 18.789 ms 10gigabitethernet2-2.core1.par2.he.net (72.52.92.26)
[AS6939] 18.437 ms
6 10gigabitethernet1-1.core1.par2.he.net (184.105.213.90) [AS6939]
18.507 ms 10gigabitethernet7-1.core1.ash1.he.net (184.105.213.93) [AS6939]
96.880 ms 97.345 ms
7 esnet.gigabitethernet4-15.core1.ash1.he.net (216.66.70.18) [AS6939]
95.544 ms 10gigabitethernet7-1.core1.ash1.he.net (184.105.213.93) [AS6939]
97.616 ms esnet.gigabitethernet4-15.core1.ash1.he.net (216.66.70.18)
[AS6939] 95.354 ms
8 washcr1-te-eqxashrt1.es.net (134.55.221.145) [AS293] 97.835 ms
esnet.gigabitethernet4-15.core1.ash1.he.net (216.66.70.18) [AS6939] 95.727
ms washcr1-te-eqxashrt1.es.net (134.55.221.145) [AS293] 98.492 ms
9 washcr1-te-eqxashrt1.es.net (134.55.221.145) [AS293] 98.463 ms
washsdn1-sdn2-washcr1.es.net (134.55.220.54) [AS293] 110.668 ms 110.641 ms
10 starsdn1-ip-washsdn2.es.net (134.55.218.65) [AS293] 120.357 ms
120.844 ms washsdn1-sdn2-washcr1.es.net (134.55.220.54) [AS293] 110.834 ms
11 starcr1-ip-starsdn1.es.net (134.55.219.25) [AS293] 164.788 ms 164.548
ms 164.550 ms
12 starcr1-ip-starsdn1.es.net (134.55.219.25) [AS293] 164.758 ms
anlmr2-starcr1.es.net (134.55.219.53) [AS293] 128.288 ms 128.286 ms
13 guava-esnet.anchor.anl.gov (192.5.170.77) [AS683] 117.532 ms
anlmr2-starcr1.es.net (134.55.219.53) [AS293] 128.263 ms
guava-esnet.anchor.anl.gov (192.5.170.77) [AS683] 117.500 ms
14 * guava-esnet.anchor.anl.gov (192.5.170.77) [AS683] 117.687 ms
117.858 ms
15 * * *
16 * * *
17 * * *
18 * * *

root@server7:/home/anurag/tmp# wget -4
http://mirror.anl.gov/pub/ubuntu-iso/DVDs/ubuntu/12.04/beta-2/ubuntu-12.04-beta2-dvd-i386.iso
--2012-04-11 21:56:46--
http://mirror.anl.gov/pub/ubuntu-iso/DVDs/ubuntu/12.04/beta-2/ubuntu-12.04-beta2-dvd-i386.iso
Resolving mirror.anl.gov... 146.137.96.7
Connecting to mirror.anl.gov|146.137.96.7|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1644474368 (1.5G) [application/octet-stream]
Saving to: `ubuntu-12.04-beta2-dvd-i386.iso.1'

100%[============================================================================================================================>]
1,644,474,368 4.78M/s in 5m 38s

2012-04-11 22:02:25 (4.64 MB/s) - `ubuntu-12.04-beta2-dvd-i386.iso.1' saved
[1644474368/1644474368]

IPv6:

traceroute to mirror.anl.gov (2620:0:dc0:1800:214:4fff:fe7d:1b9), 30 hops
max, 80 byte packets
1 2001:470:25:78f::1 (2001:470:25:78f::1) [AS6939] 18.918 ms 21.147 ms
23.357 ms
2 gige-g2-20.core1.zrh1.he.net (2001:470:0:11d::1) [AS6939] 23.341 ms
23.324 ms 23.797 ms
3 10gigabitethernet5-1.core1.fra1.he.net (2001:470:0:21c::1) [AS6939]
29.781 ms 30.252 ms 23.671 ms
4 10gigabitethernet5-3.core1.lon1.he.net (2001:470:0:1d2::1) [AS6939]
37.897 ms 37.880 ms 43.095 ms
5 10gigabitethernet7-4.core1.nyc4.he.net (2001:470:0:128::1) [AS6939]
104.552 ms 105.763 ms 105.742 ms
6 10gigabitethernet2-3.core1.ash1.he.net (2001:470:0:36::1) [AS6939]
113.963 ms 114.467 ms 111.478 ms
7
lawrence-berkeley-national-laboratory.gigabitethernet4-15.core1.ash1.he.net(2001:470:1:27f::2)
[AS6939] 109.467 ms 109.452 ms 109.435 ms
8 washcr1-te-eqxashrt1.es.net (2001:400:0:15a::1) [AS293] 115.929 ms
113.625 ms 115.896 ms
9 washsdn1-sdn2-washcr1.es.net (2001:400:0:e0::2) [AS293] 114.606 ms
112.068 ms 112.045 ms
10 starsdn1-ip-washsdn2.es.net (2001:400:0:ab::1) [AS293] 126.783 ms
130.008 ms 126.747 ms
11 starcr1-ip-starsdn1.es.net (2001:400:0:a2::2) [AS293] 127.268 ms
124.223 ms 124.125 ms
12 anlmr2-starcr1.es.net (2001:400:0:c0::1) [AS293] 128.066 ms 130.529
ms 130.513 ms
13 2001:400:2202:8::2 (2001:400:2202:8::2) [AS293] 130.976 ms 128.915 ms
128.892 ms
14 * * *
15 * * *

root@server7:/home/anurag/tmp# wget -6
http://mirror.anl.gov/pub/ubuntu-iso/DVDs/ubuntu/12.04/beta-2/ubuntu-12.04-beta2-dvd-i386.iso
--2012-04-11 21:45:52--
http://mirror.anl.gov/pub/ubuntu-iso/DVDs/ubuntu/12.04/beta-2/ubuntu-12.04-beta2-dvd-i386.iso
Resolving mirror.anl.gov... 2620:0:dc0:1800:214:4fff:fe7d:1b9
Connecting to mirror.anl.gov|2620:0:dc0:1800:214:4fff:fe7d:1b9|:80...
connected.
HTTP request sent, awaiting response... 200 OK
Length: 1644474368 (1.5G) [application/octet-stream]
Saving to: `ubuntu-12.04-beta2-dvd-i386.iso'

100%[============================================================================================================================>]
1,644,474,368 *3.66M/s in 6m 11s*

2012-04-11 21:52:04 (4.22 MB/s) - `ubuntu-12.04-beta2-dvd-i386.iso' saved
[1644474368/1644474368]

I'm getting about 40mbit through the IPv6 tunnel, so i'd say it works well, although the throughput has slowly been dropping to the 30's range over the last 6 months. But that's probably because of the latency.

For something that is provided for free I'm really glad we have it.

Indeed. It's pretty amazing what HE has put together.

I should have peered with their UK PoP as it's much closer by latency, thus faster.

Why don't you? Can you setup more then one peering?

He.net tunnels are also good to have because depending on your provider,
there's still many with incomplete views of the ipv6 routing table and he
might have a path. This is a more prevalent issue with ipv6 than v4 at the
moment.

This is a big problem for the two providers involved in this "spat" having
inconsistent IPv4/IPv6 business relationships (peering, etc).

There are many professional service providers that will happily dual-stack
your internet port with consistent business relationships. Don't let these
two parties that so far have agreed to disagree prevent you from using IPv6
to its fullest. Select another carrier.

- Jared

Hi Jared,

Is it really fair to say there are "two" parties in a peering spat
when Cogent is one of them?

Regards,
Bill Herrin

I know that the following IPv4 as-paths appear to enumerate transit paths where the providers can do IPv6 transit as well.

If HE does not take advantage of those existing IP transit connections for whichever IP version I'm not sure where I would cast blame. Perhaps those ports don't have IPv6. I have my own opinions about peering disputes which you can obtain privately.

route-views>sh ip bgp 216.218.186.2
BGP routing table entry for 216.218.128.0/17, version 417045
Paths: (35 available, best #26, table Default-IP-Routing-Table)
...snip...
  1239 3549 6939 6939
    144.228.241.130 from 144.228.241.130 (144.228.241.130)
      Origin IGP, localpref 100, valid, external
  2914 1299 6939 6939
    129.250.0.11 from 129.250.0.11 (129.250.0.12)
      Origin IGP, metric 5, localpref 100, valid, external
      Community: 2914:420 2914:1008 2914:2000 2914:3000 65504:1299
  3356 3549 6939 6939
    4.69.184.193 from 4.69.184.193 (4.68.3.50)
      Origin IGP, metric 0, localpref 100, valid, external
      Community: 3356:3 3356:22 3356:86 3356:575 3356:666 3356:2012 3549:4143 3549:30840
  701 1299 6939 6939
    157.130.10.233 from 157.130.10.233 (137.39.3.60)
      Origin IGP, localpref 100, valid, external
  1668 3549 6939 6939
    66.185.128.48 from 66.185.128.48 (66.185.128.48)
      Origin IGP, metric 7, localpref 100, valid, external
  7018 1299 6939 6939
    12.0.1.63 from 12.0.1.63 (12.0.1.63)
      Origin IGP, localpref 100, valid, external
      Community: 7018:5000
  3257 1299 6939 6939
    89.149.178.10 from 89.149.178.10 (213.200.87.91)
      Origin IGP, metric 10, localpref 100, valid, external
      Community: 3257:8100 3257:30052 3257:50001 3257:54900 3257:54901
  3561 3549 6939 6939
    206.24.210.102 from 206.24.210.102 (206.24.210.102)
      Origin IGP, localpref 100, valid, external
  6453 3549 6939 6939
    66.110.0.86 from 66.110.0.86 (66.110.0.86)
      Origin IGP, localpref 100, valid, external

Yes... Many of our customers set up multiple peerings.

Owen