As you can tell from the long list of events we’ve attended over the past few years, we like conferences. You might have met us at the WebExpo, mDevCamp, P2D2, and at some other conferences.
Showmax at DevOpsDays Prague
This year, we went to DevOpsDays Prague for the first time. We built a booth with a shiny neon Showmax sign to attract all the busy bees, offered popcorn and cold Kofola as usual, and spread the word about Showmax. If you were there too, you could have met several people from our Research & Development, Operations, and Content Delivery departments, all of whom were speaking about our infrastructure, the challenges of operating a platform in AWS, and migrating from dedicated hardware to the cloud.
As part of the conference, I also gave a short talk about The Tale of Two Internets and prepared a workshop on the first steps of deploying IPv6 in AWS.
I would like to share the Tale here as well.
The Tale of Two Internets
In 1974, the fathers of the Internet published research on what has become the Internet Protocol, forming what we know today as the Internet. It took another nine years to transform this research into the TCP/IP that most of you know. The switch to TCP/IP was completed in January 1983. In one single day the old protocol, NCP, was abandoned and TCP/IP was proclaimed to be the only protocol family of use. Everyone on the network at that time had to implement TCP/IP within 14 months.
This was a forced transition, and quite a painful ordeal, but the push was needed because without it the transition would have never happened. At that time, although it seemed difficult, the transition was still feasible as there were only a few hundred nodes connected to the network back then.
Later on, the number of connected devices was growing and the expansion of the Internet surprised everyone. In 1992, it was clear that the available IP addresses would soon be exhausted. So research on a new Internet Protocol began. In 1995 the new Internet protocol, Version 6, or IPv6, was published. It reused some principles of the existing TCP/IP suite but also introduced other new ones that were painful to use. Nevertheless, the issue of running out of IP addresses was resolved and the second internet started growing.
In the old IPv4 protocol, up to 4 billion addresses are available. In IPv6 you can have 18 quintillion computer networks, each connecting up to 18 quintillion devices. It will never run out of addresses, but there is a catch: IPv6 is not directly compatible with the old protocol. We were supposed to run both protocols on the same network and one day simply stop using the old one. As you might expect, this transition plan never really worked out. In 2008, almost nobody was accessing Google via IPv6. We were delaying the adoption of IPv6 while the old Internet exploded in size.
So, we had this newer internet, but almost nobody used it. If someone did, they were often using poorly-designed transitional mechanisms that were causing massive failures when loading IPv6-enabled sites. These failures were resolved by deploying Happy Eyeballs in 2011, which masked potential failures. The same year, major content providers enabled IPv6 on their web properties for a single day. One year later, they enabled it for good.
Since 2012, the IPv6 Internet has been steadily growing. Approximately 40% of Google’s visitors are coming from an IPv6-enabled network today. However, the content providers are slacking. Even large ones, like Github, aren’t there yet. The IPv4 addresses are already exhausted, old ones are traded for 50 dollars a piece. The old internet is full of NATs, which allows the dozens of billions of legacy devices to cope with the limited IPv4 address space.
Why is IPv6 Important?
It performs better than IPv4.
The removal of NATs can save you a lot of money in the cloud.
Each container can have its own globally routable IPv6 address.
Enabling IPv6 is sometimes just about flipping the switch. But some products, introduced long after the IPv4 address exhaustion became apparent, have failed to deliver IPv6 support in time: It took 8 years for proper IPv6 support in Kubernetes and 15 years for decent IPv6 services on AWS.
Compatibility Problem: Resolved
Thanks to NAT64/DNS64, the compatibility problem is resolved. It allows you to run services, like Kubernetes Pods, with no IPv4 addresses at all, while allowing them to connect to the IPv4-only world.
How does it work? If your IPv6-only service accesses an IPv4-only hostname, DNS64 fakes a response with an IPv6 address from the NAT64 address pool. Your service connects to the faked IPv6 address, and NAT64 translates the call to the IPv4 internet.
What about access networks? Let’s figure it out. Open www.kame.net - if you see a dancing turtle, you are IPv6-enabled. If not, ask your IT or ISP for IPv6. It‘s about time.
So, what should come next? Let’s connect to the IPv6 internet if you are not there yet, and IPv6-enable your webs and services. Then go and give IPv6-only a try in a sandbox — learn, experiment, test, and deploy. You will be rewarded with simpler network designs: never worry about how many nodes fit in a subnet again. One size fits all. No IP address collisions. No need to renumber your networks. No unnecessary NATs.
Now it’s time to deploy IPv6 to see the numbers grow!
IPv6 @ AWS Lab
This is a simple lab to set up an IPv6-enabled environment in AWS. It is in no way production-grade code, however, it does ease the initial set-up of a lab so that you don’t have to click around.
IPv6 is a second internet protocol, next to IPv4. It is not directly compatible with IPv4, so it’s kind of expected that you will run both at the same time.
AWS does not enable IPv6 in your environment by default. That means: VPCs, subnets, and services are mostly configured to be IPv4-only, and you need to flip the switches in the right locations.
This lab covers the following areas:
- Creating an IPv6-enabled VPC with dual-stacked and IPv6-only subnets
- Deploying an NAT44/NAT64 function in a VPC
- Deploying a managed NAT gateway
- Deploying a proprietary NAT44/NAT64 EC2 instance
- Deploying several EC2 instances in dual-stacked and IPv6-only subnets
- Deploying an EC2 instance with IPv6-enabled docker
- Deploying an EC2 instance with NginX and dual-stacked Application and Network Load Balancers
- Deploying an S3 bucket and test access from an IPv6 enabled environment
- Deploying a PostgreSQL RDS instance, switch it to dual-stack and test the access
This is indeed a very basic set of tasks, however, it helps kickstart the first proof of concepts and allows to have a working IPv6 AWS lab in a few dozen minutes. When you have the resources up and running, you can look around, test access to and from the IPv6 Internet, and investigate what benefits IPv6 can bring you in the cloud (for example, saving some costs for traffic going directly between the EC2 instances in the private subnets and the Internet, whereas in IPv4 it would have to pass the paid NAT gateway).
You can find the IPv6 @ AWS lab on Github and more details about IPv6 on the AWS website.
