Eventually, all internet devices will communicate via IPv6. Once everything is unified under IPv6, there will likely be fewer technical issues or concerns at the IP layer.
The challenge lies in the fact that we will have to support dual-stack configurations, where both IPv4 and IPv6 coexist, for an extended period.
The official declaration of IPv4 exhaustion began in 2011. As mobile internet continues to grow, the proportion of devices connecting via IPv6 will increase.
While the technical barriers to adopting IPv6 are actually quite low, most devices still default to IPv4 unless intentionally configured otherwise.
Since transitioning from IPv4 to IPv6 can cause more issues than the initial implementation, it’s preferable to choose IPv6 from the start whenever possible.
Switching to IPv6 in Access Network
The network for a site connecting to the internet is determined by the choice of access network services.
In Japan, NTT, which provides the connection between homes or offices and the network, started switching the network layer of its fiber optic access services to IPv6 around 2011. As a result, locations subscribing to these services are now using IPv6 access.
Japan’s broadband lines rapidly adopted
ADSL around 2002, and then began transitioning to fiber optics around 2005. For those who subscribed to these services from the beginning, the shift from IPv4 to IPv6 likely occurred during the 3rd generation of network upgrades.
A typical issue with access networks stems from the implementation of IPv4 over IPv6 tunnels.
Even when IPv4 and IPv6 coexist, they are completely independent networks, so when an access network becomes IPv6-native, it can no longer connect to IPv4 services.
Adding an IPv4 over IPv6 service allows access to IPv4 networks, but there are multiple methods, each adopted by different service providers. Ultimately, a router that supports the specific type of IPv4 over IPv6 tunnel associated with the contracted service is essential.
Many Wi-Fi access points now come with built-in internet router functionality, and it seems that consumer-grade Wi-Fi routers have increasingly begun supporting IPv4 over IPv6 tunnels.
Since Wi-Fi standards tend to update more frequently than fixed-line infrastructure, consumers who keep up with wireless technology and regularly replace their equipment are less likely to encounter issues during the IPv6 transition.
On the other hand, setting up networks in corporate offices can be more challenging.
Many routers do not support all types of IPv4 over IPv6 tunneling methods, and if the router does not match the contracted service type, it could hinder internet usage. Although service explanations often do not mention technical issues related to the IPv6 transition, if the router’s features can’t handle it, there are no alternative implementation methods available.
IPv4 over IPv6 is a relatively minor function among various network features, so it’s something that ideally wouldn’t be a critical selection criterion.
In the era of IPv4-only providers, only one router could be connected, but with IPv6, it is often possible to connect multiple routers through a switching hub. For our transition, a configuration was chosen where a network without IPv4 access was set up alongside a corporate router.
Multiple address assignment methods will coexist
In the IPv4 era, IP addresses were typically assigned using DHCP. In IPv6, it’s likely that DHCPv6 and SLAAC will coexist.
With SLAAC, which is part of the standard for IPv6, each device determines its own address, taking advantage of the abundant address space. DHCPv6, on the other hand, allows management devices like routers to assign and distribute addresses.
Platforms that favor DHCPv6 include Windows and VoIP devices. Essentially, in scenarios where a LAN administrator needs centralized management, it makes sense to generate and track addresses centrally. Conversely, for mobile devices that frequently move and cannot always be centrally managed by a single router, SLAAC is more appropriate.
As a result, the management methods for IPv6 networks are not likely to result in one standard dominating the other; both will likely survive. Network devices will need to support both methods simultaneously.
Building your own router might be a viable option
While it’s not the most common approach, you might consider building your own router to cover the necessary functions for access networks.
As mentioned later, setting up an IP network with Kubernetes is almost like building a router.
Additionally, the noticeable lack of functionality in commercial routers and the commoditization of hardware driven by ARM’s progress contribute to the relative obsolescence of off-the-shelf products.
In the past, buying dedicated network devices helped ensure security, but now there are significant concerns about the security quality of commercial products.
Many popular consumer-brand devices in Japan have software vulnerabilities, and there remains a possibility that these devices include chips with backdoor functions.
To ensure network security, it’s crucial to have clear hardware and a complete understanding of the routing configuration.
Switching data centers to IPv6
Many companies not only have office locations but also lease data centers.
As mentioned earlier, switching access networks to IPv6 can cause issues when trying to access IPv4 services.
If problems arise during the IPv6 transition, many people might mistakenly believe that there are technical issues with IPv6 itself. However, the real issue lies in the compatibility with IPv4 services, not in the communication between IPv6 peers.
For companies running systems in data centers, if the access network has switched to IPv6, the data center services should also be transitioned to IPv6.
Using some proxy software is likely the easiest way to ensure compatibility with IPv4.
Proxies are designed to work seamlessly whether the destination is IPv4 or IPv6, so the goal should be to replace internal communication with IPv6 only.
However, this change cannot be made all at once. In many cases, each individual service will need to be migrated to IPv6 one at a time. The more services there are, the more time-consuming the process will be.
For a smoother transition to IPv6, it’s helpful to have a high-functioning network that supports IPv4/IPv6 dual-stack as a prerequisite. If the network is single-stack, you’ll inevitably need to migrate to a different infrastructure, which broadens the scope of the switch.
The behavior of IPv6 can vary depending on the specific application, so it’s hard to generalize. There are CLI commands that might prevent IPv4 access simply because a route to the IPv6 network exists, potentially disrupting the planned pace of work.
It’s also possible that some software won’t function properly with IPv6.
As IPv4 becomes more costly over time and
NAT configurations might effectively become lost technologies, identifying software that is incompatible with IPv6 is crucial for long-term sustainability.
Unstable behavior of localhost
During the transition to IPv6, network-based services running on a single development machine are prone to frequent issues.
In most single-machine setups, various software components operate on the host localhost. Typically, localhost resolves to the IP 127.0.0.1 in IPv4 and ::1 in IPv6.
When software is started with default settings, it may only accept connections to 127.0.0.1, only to ::1, or behave differently in ways that aren’t always clear to users.
Moreover, when a client is configured to connect to localhost, there can be ambiguity about which IP address — 127.0.0.1 or ::1 — is being used.
If a service is listening on an IPv4 host but the client attempts to connect to an IPv6 host, the connection will fail even on the same machine.
In such cases, the failure at TCP connection often results in unfamiliar error messages and abnormal termination.
Specifying ::1 explicitly can eliminate routing ambiguity, but a challenge is that many software tools lack documentation on how to configure them to listen on ::1.
More expertise needed for building virtual networks
When it comes to development tools that include virtual networks, many existing setups are often IPv4 single-stack.
The de facto standard for clusters using virtual networks is Kubernetes, which already supports IPv4/IPv6 dual-stack functionality.
While the dual-stack functionality is likely at a level where it is practically problem-free, deploying it requires recreating the cluster.
As of 2024, it seems that only a small percentage of engineers are choosing IPv6 networks from the start. Consequently, pre-packaged solutions may not work out of the box, leading to a lot of trial and error in achieving the correct configuration.
I am running the same k3s configuration on three different hardware units, but only one of them is experiencing IPv6 communication errors. Since both inter-container communication and external requests result in errors, it’s likely a bug caused by a specific combination of the CPU and host kernel on that particular machine.
Virtual networks are significantly more complex than the network configurations of standalone operating systems. Additionally, given that Linux is currently transitioning away from the traditional iptables for network implementation, the initial setup will likely require considerable effort.
Over the past decade, the decline of published books has made it difficult to access comprehensive sources of information. This lack of collective knowledge has proven to be a significant obstacle, making troubleshooting in IPv6 network construction particularly challenging.
IPv4 has become a thing of the past
Even among software engineers, the percentage of those interested in IP networks is likely quite small, as most software targets higher-level protocols.
However, many systems likely use IPv4 at a lower layer without much thought, and if they plan to keep using these systems for more than a decade, they will eventually have to transition to IPv6.
Since migrating protocols that aren’t routinely managed isn’t straightforward, building new projects on IPv6 from the start can save considerable effort in the future.
For services that have already been established, the transition to IPv6 was always an anticipated event, and it will inevitably need to be addressed at some point.
