Dual Stack and Paint By Numbers [Archived]

By Barry Bahrami

Commercial Network Services IPv6 Case Study

I am the CEO of Commercial Network Services.  We are an online service provider, mostly focusing on the algorithmic traders who require low latency and high uptime.  I’ve been building computer networks since before there was an “Internet” as we know it and sort of evolved into where I am now. If you haven’t already started your IPv6 deployment, you are very late, and you need to get on it right now. Most of the financial services industry is behind on IPv6, yet it’s so simple, and IPv6 can only benefit you.

Why deploy?

With IPv4 running out, sometimes the only way to directly connect to a host is with IPv6. Our subscribers are not all concentrated in the USA.  They are all over the world and they are reaching sites all over the world from our network too.  IPv6 gives them greater connectivity to reach the entire Internet, not just the IPv4 Internet.  It also sets us out as a leader.  A great network has always been our thing, and I don’t believe any of our competitors have deployed IPv6 yet.

As subscribers come in over shared IPv4, many are using carrier grade network address translation (CG NAT), which is an extra layer of something that could go down.  NAT doesn’t always permit using a dedicated port on the client side because the IPv4 address is shared.   Native six to six, end to end, is only way to minimize any possible points of failure and connect without CG NAT getting in the way. Performance-wise, IPv6 allows the remote customers to our network to travel over less infrastructure. To tell the truth, it’s not much of a difference –maybe milliseconds from their hosted service to their broker – but every little bit counts in the trading world.

With CG NAT, data is flowing through extra layers in a patchwork design that wasn’t originally planned. Shared IPs are ugly for any application that might require a dedicated IP or port. If you want tidy, you need to go IPv6, end to end. It would be a lot easier for everybody if every network would get on board with IPv6. It’s really not much trouble, and the benefits greatly outweigh the time it takes to deploy it. For anyone who can get themselves around an IPv4 network, IPv6 is not really much of an extra step.

Where do you start?

For networks already on IPv4 wondering where to start, it’s easy – dual stack, dual stack, dual stack. Get your IPv6 space. You can mirror your subnetting scheme to that of IPv4 like we did. Just plan out your subnetting before diving in.  It will resemble IPv4 only you have many more IP addresses to work with.  It’s real nice to have space.  After subnetting is done, setup a dual stack and paint by numbers.  It’s really very easy.

Where are we?

Our network is fully deployed and supports both IPv4 and IPv6. We operate in both US and UK, and so we needed to first obtain IP space from both ARIN and RIPE.  In the US, we operate on both coasts and so we had to split the IP assignment from ARIN into two networks for routing purposes.  Our network is setup as a confederated AS, with each location assigned a private (internal) AS and each location also sharing routing information from peers with the entire network for optimized routing.  Each datacenter is assigned a pool of IPv6 addresses for subscriber use.  From there, it is fairly simple to assign IP addresses to our subscribers, who from that point forward can natively reach both the IPv4 and IPv6 Internet. All of our services are reachable via IPv4 and IPv6.  This is mostly virtual and dedicated servers in any of our datacenters in the US and UK.

Painting by numbers

We didn’t have any real serious obstacles deploying IPv6.  It was fairly straight forward.  Probably the biggest ‘change’ for our subscribers was using a host name instead of an IP address to reach their server(s).  Previously most were by default using the static IPv4 address assigned, but that limits them to the IPv4 Internet even though they may have IPv6 support locally.  So, we setup a DNS host name with both an A and AAAA record and encouraged subscribers to use the host name.  The result is native IPv6 networks tend to connect via IPv6 and IPv4 networks use IPv4.  All in all, it was fairly painless.

$0 IPv6 transit bill

Our subscribers have benefitted from the increased connectivity native dual stack IPv4/IPv6 provides. We have also benefited from IPv6 because our IPv6 transit has been free thanks to our peering relationships. We literally have zero IPv6 transit cost, because it seems like everyone wants to peer their v6 network.  Peering is great for everyone. Sometimes people are paying for that 95th percentile on their IPv4 traffic, but if you have IPv6 on the end, it will lower your traffic bill, and reduce how much you are spending, because you can get IPv6 for free. I noticed that wireless companies are assigning IPv6 to mobile to devices as well, so we can deliver them high quality video, unlike in IPv4 where we deliver a degraded video stream to any network that doesn’t peer with us, because they tend to ride congested transit into the end users’ ISP.  Many US ISPs will peer if you pay them enough, but any company that delivers connectivity as a service should be going out of their way to peer with everyone anyway.  IPv6 gives us an added benefit of getting around these gatekeeper peering policies, at least to their consumers with IPv6 connectivity.  This will only improve as IPv6 becomes more widely deployed.

IPv4 will no longer directly connect you to the entire Internet

If you have not already at least started to deploy IPv6 then you are behind, far behind.  And if it takes you too long to deploy, then you’re doing something wrong. It’s very easy.  It should not be difficult.  Do it today, and reconnect your network to the entire Internet.

Any views, positions, statements or opinions of a guest blog post are those of the author alone and do not represent those of ARIN. ARIN does not guarantee the accuracy, completeness or validity of any claims or statements, nor shall ARIN be liable for any representations, omissions or errors contained in a guest blog post.