Blog Posts tagged ‘drac’

The focus for this post is obviously about our IPv6 deployment plans, but I’d like to take a small detour through our US presence on the way there.

Anchor’s networking and automation gurus have been hard at work preparing our new kit over in the US, and the day we go live is fast approaching. In the process we’ve had literally zero personal presence over there, not one plane ticket was bought. That we can get away with this is mostly thanks to two things: Equinix and DRACs (Dell’s remote-management interface).

Equinix

One of the reasons we went with Equinix is their high level of support, which goes nicely with Anchor’s approach to business.

The servers were dropshipped direct to the LA3 datacentre where staff unpacked them and racked them up according to our instructions. Once the DRACs were plugged in it was our turn to get excited.

DRACs

DRACs let you do stuff remotely, pretty much anything short of implementing a big red self destruct button. Wanna boot an OS install image from 12,000km away? You can do that.

With a little bit of shuffling, we’ve bootstrapped a new environment over there, ready to build high-availability VMs and servers.

The core of Anchor's LAX1 presence, all gigabit and redundant up the wazoo

IPv6

Which brings us to the fun stuff. The question of offering IPv6 has been on the cards for four or five years now, but to date there hadn’t been enough of a business case for us to commit to. The LAX1 POP changes this.

Anchor’s initial offerings will be focused on our VPS product, which will have full dual-stack connectivity from day 0. For those customers with IPv6 aspirations, we’re ready for you. For everyone else, we hope its enabled-by-default status will drive some interest.

As a small mark of this commitment, we’ve given our DRACs IPv6 addresses only. The practical upshot of this is that it forces us to ensure that all our infrastructure supports IPv6 – routing, switching, DNS, the works. This is popularly called “eating your own dogfood”, we wouldn’t sell something that we don’t use ourselves.

Why IPv6?

For those who don’t follow the IPv4 to IPv6 transition, the rest of this post will summarise Anchor’s perspective specifically.

It’s generally agreed that we’re going to run out of the IPv4 addresses that we know and love, and quite soon. Estimates vary, but unless there’s a revolutionary change in our use of addresses it looks like we’ll hit the wall within about three years.

IPv6 support in the backbone of the internet is already well established, but the real challenge is pushing it all the way to end-users. IPv6 requires big changes through the entire technology stack: routers, switches, firewalls, DNS, servers, operating systems, application configurations and more, it’s all there.

This makes it extremely costly to retrofit existing systems. ISPs have a nasty chicken-and-egg problem because of that – given that demand will only be driven by availability, it’s much easier to do nothing instead of committing to big spending with uncertain returns.

Even assuming that an ISP wanted to sell IPv6 to their consumers, there’s very few content providers doing IPv6. Due to aforementioned lack of demand, content providers would be crazy to present IPv6-only content and lose the whole IPv4 market. Given this, it ultimately looks like the shift to IPv6 will be driven by “external” forces.

As an example, big companies like Google are in a position to push for adoption (try visiting http://ipv6.google.com/), and in theory even offer IPv6-only content that enough users would hassle their ISP for. On the other end of the hypothetical stick, if hosting providers increase the cost (technical and monetary) of IPv4 hosting, it could push enough content to IPv6 to grind through a transition.

These are just two examples, but hopefully they illustrate the difficulty and significance of the problem.