Daniel Marks... Developer?

The Corporate Case for IPv6

·4 mins

Why does it really matter? #

Honestly, you may not have a good reason to implement IPv6. In fact, you probably have great reasons to avoid deploying IPv6, especially when it comes to security. Mom and Pop’s shop will never notice a difference with IPv6, and neither will a lot of companies that don’t revolve around providing services or technology.

I’m not going to rabble on about the regular benefits of using IPv6, you probably already know them. I want to talk about the benefits we directly noticed after we deployed IPv6, to build a business use case that isn’t just “because it’s the future”.

Deployment #

I should talk about how I deployed IPv6 in my corporate network. I’m the sole network administrator at an AV company that develops and deploys autonomous transportation solutions. As you can imagine, we have some pretty weird needs when it comes to networks, and it isn’t easy.

Diagram

As a network administrator, I wanted to achieve 3 main goals:

  • Give everyone enough IP space to develop and test without needing to NAT their delegated IP block
  • Avoid a single developer from triggering rate limits from Cloudflare or Google (They block per /64)
  • Pave the way for an IPv6-only network, with IPv4 only provided at the edge (NAT64).

With this setup, we are able to easily support 10x the amount of end users with absolutely no changes required. We also provide legacy IPv4 addresses along side our IPv6 block, so we have maximum compatibility.

In the future, we will be upgrading and deploying IPv6-only shuttles with dedicated space, so they can shuffle around the entire world and keep their IP space, using BGP. No more worrying about running out of RFC1918 IP space.

Hidden benefits #

So far our biggest benefits revolve around performance and the lack of NAT:

  • No NAT means our servers are able to have measurably faster data processing rates (when you go above 10Gbps, NAT can have a measurable impact on latency and throughput, Part 2 will include more of our testing data)
  • There are never IP conflicts within the internal or external network, because there is no distiction between internal and external.

There are also financial benefits to this as well

  • We are able to peer directly with many companies (including AWS) over IPv6 without needing to purchase IPv4 blocks. This also means we can run BGP directly from our FW without NAT, saving even more CPU cycles.
  • Everything happens over our owned IPv6 block, so abuse reports and such avoid any third party involvment. Abuse report from naughty end users can tarnish your reputation with IP block providers, and if you don’t own the IP space, potentially having your ISP crack down on you.

There are also some security benefits as well

  • We have total control over our IP space, we split and use our IPv6 space with our cloud providers and public sites, so we can tell our customers we will only provide services from our IPs. We utilize BYOIP with AWS, Cloudflare, and other hosted services that allow it. No more dealing with poor reputation IPs accidentally getting blocked by end user firewalls.
  • Even though I don’t believe in security by obscurity, the fact of the matter is that IPv6 space is huge and it’s very rare to see bots scanning every single IPv6 address you may have. This cuts down on fluff in logs and avoids the waste that our firewall may have to deal with.

Downsides #

There were also a few downsides that to this day still bite us, I’ll start with the biggest one:

  • IPv6 is unknown to the average tech and developer

By far the biggest downside is the lack of experience most people have working with IPv6. It’s a completely different thought process to IPv4 in many ways, that it’s too intimidating to many people. Searching for candidates that are willing to deep dive into IPv6 immediately is rare, and only a select few people at my company even feel comfortable messing with it.

  • Running 2 IP networks requires more effort and thought

When we deploy security rules and ACLs, we have to deploy them both in IPv4 and IPv6. Routing changes? Gotta do it twice. Allow-listing? Twice. It’s a pain, even with IaC and Ansible doing the work.

Conclusion #

All in all, this ended up being worth the effort as a business endeavor, and we are saving thousands per month in hardware and leasing costs, and we are able to extend the life of legacy hardware. It’s one of the many things I’m happy to stick my name next to, and I learned a lot as a network professional.

I’m also grateful my company May Mobility allows my team to go wild with somewhat crazy plans like these. If you’re really interested in more things like this, come join our team!