Industry struggles to wind down IPv4

The next-generation Internet Protocol, IPv6, has experienced more growth in the last two years than in any other period in its 18-year existence.

 

While there are many challenges ahead in the deployment of IPv6, the protocol is a certain replacement for the currently dominant IPv4 protocol. As deployment of IPv6 gains momentum worldwide, the Internet Engineering Task Force (IETF) has begun examining how to accelerate it as the dominant IP version, and how to handle the scaling down of IPv4.

 

The IETF has made an important step forward by stating that IPv6 support is no longer optional in an IP- or internet-capable device. As envisioned by IETF RFC 6540, “IPv6 Support Required for IP Capable Nodes,” all such devices must support IPv6, and may optionally support IPv4.

 

In defining its guidance, RFC 6540 states that best practices should be:

 

• New IP implementations must support IPv6.

• Updates to current IP implementations should support IPv6.

• IPv6 support must be equivalent or better in quality and functionality when compared to IPv4 support in a new or updated IP implementation.

• New and updated IP networking implementations should support IPv4 and IPv6 coexistence (dual-stack), but must not require IPv4 for proper and complete function.

• Implementers are encouraged to update existing hardware and software to enable IPv6 wherever technically feasible.

 

It is hoped the RFC sends a strong message to the internet community that IPv4 support should now be considered optional and IPv6 support mandatory.

 

From a number of perspectives, it is easier to maintain a network based on a single version of the Internet Protocol. Running a network with only one IP version should be the end-goal of any IPv6 deployment effort. Although there are many similarities in how IPv4 and IPv6 are designed, in many cases the two Internet Protocol versions operate as “ships in the night.” That said, there are some situations where duplicity of efforts can be mitigated. For example, an IPv6 addressing plan could leverage an existing IPv4 address plan.

 

Infrastructure for the two IP versions must be mostly managed separately. Addressing for IPv4 must be managed separately than addressing for IPv6. Routing must generally be handled and managed separately for IPv4 and IPv6, even if the same team manages both IP versions and the routing occurs across the same physical network links.

 

Node connectivity must be assured separately for each IP version supported by the enterprise or service provider. Ensuring that a node is reachable via IPv6-transport does not confirm that it is also reachable via IPv4-transport. Security considerations must be made for both IPv4 and IPv6 networks; in some cases the security concerns will be similar between IP versions, and in other cases there will be security vulnerabilities unique to the IP version that must be evaluated.

 

To advance the ramp-down of IPv4 and to facilitate scenarios where IPv6 is the only IP version, the IETF has chartered the “Sun setting IPv4” (sunset4) working group to “standardize technologies that facilitate the graceful sun setting of the IPv4 internet in the context of the exhaustion of IPv4 address space while IPv6 is deployed.”

 

Marc Blanchet, network engineering consultant at Viagénie, co-chairs the Sun setting IPv4 working group. According to Marc, “One may be surprised how much IPv4 is so glued into our protocols, provisioning, applications, tools, products and networks, that it will require some work to remove it gracefully. In a nutshell, this is the mission of the IETF sunset4 working group.”

 

For example, with today’s desktop computers, it is common for the computer to keep asking the network (via DHCP for IPv4) for an IPv4 address, even after a perfectly acceptable, routable IPv6 address has been configured on the computer. While this behavior is a correct in a dual-stack IPv4/IPv6 network, how should the network or computer react in a network for which an IPv4 address will never be provided by a DHCP? 

 

In another example, the working group is pondering what to do in the case where IPv4 is not configured on the LAN. When a computer requests an address for a DNS name, an A record (containing the IPv4 address for the DNS name) is typically requested by default on a dual-stack host in addition to an AAAA record (containing the IPv6 address for the name). In an IPv6-only network, requesting the A record is simply unnecessary.

 

The IETF designed the eventual replacement for IPv4 in the mid-1990s when it became obvious that there weren’t sufficient addresses in the IPv4 design to support the global growth of the onetime research project called the internet. It is truly amazing that the internet continues to be a common communications link among the world’s cultures and nations. IPv6 ensures that the internet continues to scale internationally.

 

Like an airplane, the internet is hampered by the “drag” caused by network address translation (NAT) and conservative IPv4 address allocation. When IPv6 can be implemented and IPv4 “obsoleted”, the global community can realize the full efficiencies that the internet can offer.