It’s hard to believe that IPv6 has been around so long. Worrying about the potential for IPv4 address exhaustion, it became a draft standard in 1998 (although it wasn’t ratified until 2017). Despite its long existence, adoption has been slow. Many organizations still rely on IPv4, often using Network Address Translation (NAT) to manage the limited address space. In recent years, however, the push for IPv6 adoption has gained momentum, driven by the proliferation of internet-connected devices, more efficient routing needs, and the exhaustion of IPv4 address pools in several regional internet registries (RIRs).
What is IPv6
Internet Protocol version 6 (IPv6) is designed as a replacement for IPv4. It uses 128-bit addresses instead of the 32-bit addresses used by IPv4, allowing for a vastly larger number of unique IP addresses. You can recognize an IPv6 address by its hexadecimal format, which consists of eight groups of four hexadecimal digits separated by colons (for example, 2001:0db8:85a3:0000:0000:8a2e:0370:7334). You can shorten how these addresses are written by omitting leading zeros and using double colons to represent consecutive sections of zeros (for example, 2001:db8:85a3::8a2e:370:7334).
While many of us are used to IPv4 CIDR blocks being small – like /24 (256 addresses) – IPv6 blocks are typically much larger. A common allocation for end users is a /64 block, which provides 18,446,744,073,709,551,616 addresses (2^64). This is more than enough to assign a unique address to every device on the planet many times over! Your ISP likely assigned you something between a /56 and /64 block for your home network, giving you virtually unlimited subnets and devices without needing to reconfigure your network.
IPv6 also introduces the ability for addresses to be global (routable to/from the internet) and link-local (routable only within a local network segment). Why is this important? With IPv4, you used Network Address Translation (NAT) to allow multiple devices on a local network to share a single public IP address. Whenever you make an outbound request to the internet, the response has to be routed back so that you can receive it. NAT allows that public endpoint to receive the response and route it back to the correct internal device. With IPv6, every device can have its own unique global address, eliminating the need for NAT and simplifying network configurations. This is why you will often hear that IPv6 outperforms IPv4 in many scenarios. It allows direct routing for devices.
There are more features baked into the IPv6 specification, including native IPsec support (authentication, encryption, and data integrity), improved multicast support (which allows data to be sent to multiple destinations simultaneously, saving bandwidth), secure neighbor discovery, improved threat blocking, and simplified network configuration.
Interoperability between IPv4 and IPv6
Many networks support dual-stack operations, meaning they can handle both IPv4 and IPv6 traffic. This is particularly useful during the transition period, as it allows devices and services to communicate over either protocol depending on their capabilities. To make this work, they also need to support DNS records for both IPv4 (A records) and IPv6 (AAAA records). In fact, you can use these records to prioritize one protocol over the other. For example, if a device supports both IPv4 and IPv6, it might prefer to use IPv6 for communication if an AAAA record is available. In addition, there is a special group of addresses that are reserved for mapping to IPv4 addresses where the first 80 bits are set to zero, the next 16 bits are set to one, and the last 32 bits contain the IPv4 address. For example, you can represent the IPv4 address 192.168.15.2 in IPv6 format as ::ffff:192.168.15.2.
Additionally, NAT64 allows IPv6-only clients to communicate with IPv4 servers by translating IPv6 addresses to IPv4 addresses and vice versa. This is particularly useful in environments where IPv6 adoption is high, but some services are still only available over IPv4. A dual-stack gateway keeps a mapping of the IPv6 requestors, translates the requests to IPv4, and then translates the responses back to IPv6.
There’s one more important mechanism – “Happy Eyeballs” (also called Fast Fallback, or RFC 8305). For dual-stack environments, the system retrieves both IPv6 and IPv4 addresses in parallel. Using logical rules that include tracking expected round-trip times, translation requirements, and preference for IPv6, the system tries to connect to the preferred IP address. If that takes too long, it moves to the next most preferred address (interleaving IPv4 and IPv6 requests). This ensures users have the best possible network experience and handles situations where there may be translations, lack of IPv6 routing support, or other connection issues.
There’s a lot more to this topic, but the key point is that IPv4 and IPv6 can coexist and interoperate in various ways.
How this affects GitHub
GitHub publishes details about its IP address ranges to make it easier for companies to implement firewalls and other security measures. You can find these details (and more) by using the meta endpoint: https://api.github.com/meta. This returns a JSON document with several arrays, each containing details about the available address ranges.
For example, the web array contains these addresses (and more):
1 "web": [
2 "192.30.252.0/22",
3 "185.199.108.0/22",
4 "140.82.112.0/20",
5 "143.55.64.0/20",
6 "2a0a:a440::/29",
7 "2606:50c0::/32"
8 // ... more ...
9 ]If you query the DNS for
www.github.com, the A record (IPv4 address) may return 140.82.113.4, which is in the 140.82.112.0/20 range. At the moment, there is no AAAA record, so you cannot access that page using IPv6 only. That means reaching the site today with IPv6 requires NAT64 or some other translation mechanism. The site supports IPv4 natively and IPv6 via translation.
Notice the blocks with colons? Those are IPv6 address ranges. The systems themselves already have assigned IPv6 addresses, even if they are not published in DNS. That means that GitHub could enable IPv6 access at any time by simply adding the appropriate AAAA records to their DNS. They are letting you know in advance that if you need to create an allow list, these are the ranges you will need to include. If you have a firewall that only supports IPv4, it will eventually need to be updated to support IPv6 if you want to support the full range of access to GitHub services.
This is also true for GitHub’s web hooks. While it provides IPv4 and IPv6 ranges, the systems are currently sending requests using IPv4. This could change at any time, and you have some control over that through the DNS records you provide to GitHub.
This transition already happened several years ago with GitHub Pages. Looking at the IP addresses for GitHub Pages, you can see both IPv4 and IPv6 addresses:
1 "pages": [
2 "192.30.252.153/32",
3 "192.30.252.154/32",
4 "185.199.108.153/32",
5 "185.199.109.153/32",
6 "185.199.110.153/32",
7 "185.199.111.153/32",
8 "2606:50c0:8000::153/128",
9 "2606:50c0:8001::153/128",
10 "2606:50c0:8002::153/128",
11 "2606:50c0:8003::153/128"
12 ]Querying the DNS for pages.github.com returns both A and AAAA records. For example, if you use dig pages.github.com A pages.github.com AAAA (from the package dnsutils on Linux) to query the DNS, you get the following results:
1pages.github.com. 4502 IN CNAME github.github.io.
2github.github.io. 4502 IN A 185.199.111.153
3github.github.io. 4502 IN A 185.199.109.153
4github.github.io. 4502 IN A 185.199.108.153
5github.github.io. 4502 IN A 185.199.110.153
6pages.github.com. 4502 IN CNAME github.github.io.
7github.github.io. 4502 IN AAAA 2606:50c0:8002::153
8github.github.io. 4502 IN AAAA 2606:50c0:8000::153
9github.github.io. 4502 IN AAAA 2606:50c0:8003::153
10github.github.io. 4502 IN AAAA 2606:50c0:8001::153You’re being offered 4 different IPv4 addresses and 4 different IPv6 addresses that you can use to reach GitHub pages. Using the Happy Eyeballs approach, modern browsers and languages can pick the best option from these addresses based on performance and availability.
Using IPv6 with Docker
If you’re on a Linux machine, you’re in luck. Docker natively supports IPv4 and IPv6. If you’re using Docker Desktop and want IPv6 support for your containers, open Settings, then choose Resources > Network and change the Default networking mode to Dual IPv4/IPv6:
After restarting Docker, your containers can use both protocols.
Kubernetes, IPv6, and dual-stack networks
Kubernetes has supported dual-stack implementations since version 1.23. Consequently, most Container Network Interface (CNI) plugins support dual-stack IPv4 and IPv6, and a few now also support IPv6-only.
If you’re using Windows nodes, there is another limitation. Kubernetes on Windows does not support IPv6 single-stack networking. However, it fully supports dual-stack networking.
GitHub Actions Runner Controller (ARC)
As a Kubernetes operator, ARC benefits from the support Kubernetes (and Linux) provides for IPv6. That said, if you use Kubernetes mode, the story changes a bit. “Kubernetes mode” works by creating a separate pod from the runner that contains the runner job and any necessary services. It relies on an integration point in the Actions runner that lets you change how containers are handled. This integration is executed as a NodeJS script. All three languages – Go (used for the operator), NodeJS (used for the runner integration), and .NET (runner) – support IPv6. So, in theory, everything should work fine.
Until the recent release of ARC 0.13, there was a limitation. The hooks used an older Kubernetes client SDK that had limited support for IPv6. While it worked in many cases (including dual-stack), but it did not work correctly in IPv6-only clusters.
In ARC 0.13, the Kubernetes client SDK was updated to fix these problems. In theory, that means ARC should now support IPv6-only clusters. Of course, not all of the GitHub endpoints are enabled for IPv6 yet, so that means you will either need to rely on translation (such as NAT64) or use dual-stack cluster (with a NAT Gateway) for ARC to interact with the control plane.
Security considerations
When adopting IPv6, it’s important to consider security implications. While IPv6 has built-in security features, it also introduces new challenges. Some security tools and firewalls may not fully support IPv6, leading to potential vulnerabilities. Lack of experience with IPv6 can also lead to misconfigurations, such as not accounting for the multiple IPv6 addresses (global, link-local, temporary, etc.) that network interfaces often receive compared to a single IPv4 address.
IPv6 also uses some protocols differently. You often blocked Internet Control Message Protocol (ICMP) with IPv4, but it is fundamental to IPv6. This means you should reconsider any existing restrictions, and it can change how you think about firewalls, access controls, and network monitoring.
As with any significant change in a company, it’s essential to make sure teams are trained and prepared to handle the new technology. If they apply the same principles they used with IPv4 without understanding the differences, they may inadvertently create security gaps.
How it affects your applications
When building applications that communicate over the internet, it’s critical to ensure they can handle both IPv4 and IPv6 addresses. This includes properly resolving DNS records, managing socket connections, and handling any protocol-specific nuances. Most modern programming languages and frameworks have built-in support for IPv6, but you should still test your applications in dual-stack environments to ensure compatibility. You also must make sure you have the right systems in place to monitor, log, and secure your IPv6 traffic.
Give your developers access to build and test their code on systems that support IPv6 so they can catch issues early. Plan adequate time to test and validate how your systems handle IPv6. Deutsche Telekom found issues ranging from improper hardware settings and BIOS bugs to network device problems when implementing their massively scaled Kubernetes networking environment. While you’re unlikely to need that level of scale, this highlights why training and thorough testing are critical.
Cloud networking
If you’re using Azure, Microsoft provides a great article on IPv4/IPv6 workload communication patterns to help you understand how to manage communication between IPv4 and IPv6 workloads in Azure or hybrid environments. Amazon provides similar guidance in their IPv6 architectures documentation.
The future is IPv6
The transition to IPv6 is inevitable. As more devices connect to the internet and the limitations of IPv4 become more apparent, you need a more robust addressing system. You should start planning for IPv6 adoption now, including updating your infrastructure, applications, and security policies to support the new protocol. While the transition may take time, the benefits of IPv6 – including a larger address space, improved routing efficiency, and enhanced security features – make it a worthwhile investment for the future of networking. By starting now and being proactive, you can ensure a smooth transition to IPv6 and take advantage of the improved performance and scalability it offers.