Roller Network IPv6

Welcome to our IPv6 deployment information page. Roller Network has been IPv6 enabled since August 29, 2005 when we brought up our first IPv6 BGP session with Sprint. This site has concurrent A/AAAA records in DNS. You appear to be coming to us today using IPv4 from 38.107.191.96. If you experience any technical issues with our IPv6 service please contact us.

Although we run a dual-stack network and treat our IPv6 service with equal priority to IPv4, please remember that some providers and paths between our network and yours may still view IPv6 as experimental or lower priority. Let us know if you have trouble reaching us via IPv6; we will assist as much as possible.

2010-07-02 - We've turned off our supplimentary tunnels to Hurricane Electric and LavaNet, having been replaced by native connectivity from Global Crossing. We would like to thank them for their service during our issues with Verizon.
2010-06-10 - Our native IPv6 with Global Crossing will be turned up Monday at 12:00 local time.
2010-05-08 - Mail forwarding is now IPv6 enabled. If a forwarding destinaion is reachable via IPv6, we will attempt to use it.
2010-02-01 - Send Mail Using IPv6!
2009-11-06 - Outbound Mail Now IPv6 Enabled
2009-10-04 - We made Slashdot! Technology: Verizon Refuses To Provide Complete IPv6
2009-10-03 - Verizon Refuses to Provide Complete IPv6
2009-08-11 - A problem with our redundant mail hosting servers was discoverd in testing - the IPv6 address won't fail over quickly due to limitations in Linux libnet. Basically, our routers won't see the change in the IPv6 physical layer destination. We can execute a "clear ipv6 neighbors" to fix it, but it requires manual intervention and is not something we should have to do.
2009-07-27 - We may have a solution to the "IPv6 addresses in the logs" problem by storing them as DECIMAL(39). We store IP addresses in their interger value (as opposed to a string) to make searching by IP possible.
2009-06-06 - Our tunnel to Hurricane Electric was trapped by an OSPF bug; they fixed it by resetting the tunnel interface.
2009-06-04 - We discovered a routing black hole on IPv6 traffic coming to us through Hurricane Electric. We don't know how long it's been happening, but we shut off our BGP connection to them and restored connectivity. (Our inability to reach whois.arin.net via IPv6 tipped us off. Further testing revealed a SixXS traceroute died at HE.)
2009-05-06 - It's been a while since our last IPv6 update, but we haven't stopped working on it. We are attempting to acquire a dual-stack connection with Verizon as part of our move to a new facility.
2008-12-11 - Testing for enabling IPv6 for our mail services has begun.
2008-11-21 - We've added IPv6 access for our hosted mail boxes under "mailbox.ipv6.rollernet.us" and to webmail at "https://webmail.ipv6.rollernet.us".
2008-10-21 - A Treo 700wx on Sprint's network can access this site (and others) using 6to4.
2008-10-15 - So far there don't appear to be any adverse effects from using A/AAAA records on our ns2 and ns2-auth records.
2008-10-05 - We're going to try giving "ns2.rollernet.us" and "ns2-auth.rollernet.us" AAAA records. Since DNS lookups aren't interactive, broken IPv6 resolvers should fall back. (Some root servers have A and AAAA records as well. This is the same thing.)
2008-10-01 - Enabled IPv6 for our Primary DNS service.
2008-09-30 - Enabled IPv6 for our Secondary DNS service.
2008-09-02 - We have completely dual-stacked our network core.
2007-11-19 - First production IPv6 network under 2620:0:950::/48.
2005-08-26 - Early testing under 3FFE:2900:1118::/48 through Sprint.

A/AAAA Hostname	IPv6 Address	Service
smtpauth6.rollernet.us	2620:0:950:f000:213:72ff:fe4f:6a76	Outbound Mail (SMTP AUTH)
ns1.ipv6.rollernet.us	2620:0:950:f000:216:3eff:fe2f:8003	Secondary DNS
ns2.rollernet.us	2620:0:950:f100:216:3eff:fe2f:8004	Secondary DNS
ns1-auth.ipv6.rollernet.us	2620:0:950:f000:216:3eff:fe2f:8005	Primary DNS
ns2-auth.rollernet.us	2620:0:950:f100:216:3eff:fe2f:8006	Primary DNS
mailbox.ipv6.rollernet.us	2620:0:950:f000:213:72ff:fe58:d017	Hosted Mail Boxes

webmail.rollernet.us, www.rollernet.us, forums.rollernet.us, ipv6.rollernet.us

Roller Network currently has IPv6 connectivity through Sprint and Global Crossing.

Ultimately, we intend to offer IPv6 connectivity to all of our services. It is still unknown at this time whether or not that goal is attainable with the current state of IPv6 in the wild. We have two concerns with IPv6: one is that publishing concurrent A and AAAA records in DNS will expose broken IPv6 connectivity, and the second being the lack of IPv6 availability.

For the foreseeable future, we will only publish concurrent A/AAAA records under the *.ipv6.rollernet.us subdomain. Exposing broken dual-stack environments usually leads to long delays until the IPv6 attempt times out and retries using the IPv4 address. In tests loading this website from a broken IPv6 endpoint we found the delay can be upwards of 60 seconds per object (i.e. graphics), which led to waiting almost 5 minutes to load this simple page. (We "broke" the endpoint giving it a valid global IPv6 address with an unroutable intermediate hop. The endpoint thought it had IPv6 connectivity, but it really failed mid-traceroute.)

The second issue is something the rest of the world will have to work out. Native IPv6 connectivity is still relatively rare compared to IPv4. Although tunneled service is available for free, not everyone can readily access it, and configuring such a service is well outside the ability of common end-users. Methods like Teredo rely on relay servers that are currently few and far between. 6to4 will not work behind NAT or firewalls. For either relay server method the relay server can be a bottleneck if it's overloaded. Ideally, every ISP would have a Teredo server and 6to4 relay to eliminate the potential for substandard IPv6 throughput.

We have had great success with Teredo (and Miredo) and 6to4 on non-NAT endpoints. However, while we were testing Miredo for OSX, we found that traffic would be tunneled to Europe and back, leading to slower performance than a closer relay could offer. Should this single relay become overloaded or unavailable, the IPv6 experience suffers. If you can configure a tunnel, there are many to choose from. We use a tunnel from Hurricane Electric as one of our endpoints.

We welcome anyone interested to give IPv6 a shot. None of the issues we mentioned are a cause to treat IPv6 as a dead end - it's simply still an emerging technology. The more people that use it and report/solve problems, the more robust it will become. At some point it is expected that IPv6 will replace IPv4. While that day isn't here yet, Roller Network is ready. IPv6 suffers from the classic "chicken and the egg" problem. There's no demand because there's no content. But, there's no content because there's no demand. Here at the Roller Network, we will do our part by providing our services (the content) so that some day there will be enough demand for a robust IPv6 as much as IPv4 enjoys today.