This article in Japanese, translated by Miyata Tomoki
The Internet faces a transition from its traditional IPv4 to IPv6, with a period of coexistence. Here is one technologist’s view of the road ahead for the Internet Protocol and IP networks from the perspective of work happening in the IETF.
The time is rapidly approaching when the last of the IPv4 address space will be allocated. Even though options are being considered that would enable the trading of IPv4 address space as a commodity (which has important implications for routing) as well as for sliding an ISP interconnection layer underneath the IP protocol, networks requiring new address space in large amounts will deploy IPv6. Therefore, some form of coexistence and, eventually, a transition are inevitable. To that end, the IETF has explored several transition mechanisms, most of which are described in RFC 4213.
According to thefreedictionary.com, a transition is a “Passage from one form, state, style, or place to another.”? As such, a protocol transition from IPv4 to IPv6 requires two events:
- IPv6 must be turned on in routing, on application servers and services, and on the peer or client systems that use or participate in those services
- IPv4 must be turned off-at least in the network.
Two serious questions arise from that observation.
- How long a time period should be allowed between those events? Does one turn IPv4 off and IPv6 on simultaneously, or does one turn on IPv6, allow a time interval to elapse, and turn IPv4 off later? If the latter, how long a time interval is rational?
- How are IPv6 datagrams carried in an IPv4 network before IPv6 is turned on? How are IPv4 datagrams carried in an IPv6 network after IPv4 is turned off? There are two broad categories of solutions: tunnelling solutions and translation solutions.
IPv4/IPv6 Coexistence
From the IETF’s perspective, the optimal approach for existing networks is to focus not on transition but on coexistence. Turn on IPv6 now and start using it; turn IPv4 off at some point in the future when it is no longer a business requirement. Therefore, in the opinion of the IETF, network administrators should:
- Turn on IPv6 routing in their existing IPv4 networks.
- Contract IPv6 service with their upstream, peer, and downstream neighbours.
- Use the IPv6 protocol in addition to IPv4 in their applications and services both on server equipment and on their clients.
In doing so, network administrators will likely find software and hardware that are old or for some reason cannot be upgraded. They should schedule those upgrades as their budget allows.
The reason to support coexistence of this type should be obvious: If IPv6 isn’t working or if another network does not yet support IPv6, the affected applications or services will remain available via IPv4.
Providing coexistence in network layer routing can be accomplished in any one of three ways:
- Enabling IPv6 on routers that carry IPv4
- Enabling IPv6 on other routers as a parallel network internal to the customer-perceived network
- Enabling IPv6 on a separate parallel network directly visible to neighbouring networks and customers
Building parallel networks is obviously far more expensive than turning on IPv6 on the existing equipment.
Overlay Networks
To date, before native IPv6 routing and applications were turned on, IPv6 has been in use via overlay networks that were built using tunnels or multiprotocol label switching. Initially, 6BONE and 6NET routed IPv6 through static tunnels. Dynamic approaches have since been developed, though, such as 6to4 (RFC 3056), Teredo (RFC 4380), and ISATAP (RFC 5214).
One solution that has been proposed for broadband access networks involves having the ISP continue to manage an IPv4 network, with IPv6 running as a tunnel overlay between the customer-provided-equipment (CPE) router and an ISP-identified tunnel endpoint. In this model the ISP does not offer native IPv6 service. As a transitional deployment step, the ISP indicates the IPv4 address of a tunnel endpoint to CPE routers when it configures them, and it includes an IPv6 prefix using DHCP-PD. This allows the ISP to traverse the parts of its network that are not yet ready to support native IPv6 forwarding.
The tunnelling of IPv4 through IPv6 is analogous to the tunnelling of IPv6 through IPv4, though only static tunnels are defined at this point.
Translation Technologies
Translation between IPv4 and IPv6 is not generally considered a viable long-term strategy, if only because it begs the question of the size of the address. If IPv6-to-IPv4 translation is sufficient to address the systems to which a user needs access, then one needs only to reallocate the existing IPv4 address space to solve the problem. Translation is, however, generally recognized as a necessity in certain cases to provide connectivity between IPv6-only and IPv4-only systems or networks. The issues that arise relate in part to path- MTU (maximum-transmission-unit) detection, which is often problematic in IPv4 networks but is required in IPv6 networks. Other issues involve supporting applications that are not designed on a client/server architecture or that require a sophisticated firewall traversal mechanism.
The Stateless IP/ICMP (Internet Control Message Protocol) Translation Algorithm (SIIT) (RFC 2765) is implemented in a translating router. The router advertises one or more IPv4 prefixes (perhaps host addresses) in IPv4 routing and a prefix in IPv6 routing. By defined transforms, it translates between IPv4 and IPv6 and between ICMP and ICMPv6.
NAT-PT (RFC 2766) extends the SIIT concept with a DNS application layer gateway. The gateway replicates A records from the IPv4 network as AAAA records carrying SIIT-compliant addresses in the IPv6 domain and advertises A records for the IPv6 hosts with SIIT addresses in the IPv4 domain. Doing this statelessly, however, implies either host routing in the IPv6 network, which has scaling issues, or a small IPv6 domain-nominally a single LAN-attached to a much larger IPv4 domain, because the upper 96 bits of the address in the IPv6 domain are static.
There is one problem with SIIT and NAT-PT: they are designed to enable small IPv6 islands to operate within a general IPv4 network, and they do not scale well in a more general deployment. Hence, the IETF is at this point working on next-generation translation technologies intended to support more general deployment, based on operational experience with SIIT, NAT-PT, and CERNET-CNGI’s (China Education and Research Network-China Next-Generation Internet’s) IVI prototype. This is expected to help larger networks deploy new services using IPv6-only networks before they become able to get all of their existing users to turn on IPv6. As IPv6 becomes generally deployed, the need for translation disappears and one can expect the technology to disappear, overtaken by events.
Issues and Objections
Specific objections surround the business issues associated with IPv4-to-IPv6 transition and coexistence, including the costs of transition, the readiness of the protocol and its implementations, and the larger problems of routing and addressing.
Business Matters
If, as forecasts project, it becomes necessary to deploy IPv6 in order to obtain large amounts of address space inexpensively, then a company that fails to deploy IPv6 fails to offer connectivity to those new markets. Geoff Huston and others project that instead of widescale IPv6 deployment, a market for IPv4 address space will develop, with providers leasing or selling address space among themselves. In short, IPv6 connectivity is likely to be cheaper to deploy than IPv4 connectivity in the long term, and the revenue that connectivity brings is likely to be the same regardless of protocol. With IPv6, longterm profit potential is likely to be greater.
Operational and Capital Costs
As previously noted, one way to minimize business risk when deploying IPv6 is to deploy it in a network separate from the one running user services for IPv4. Running IPv4 and IPv6 at the same time will cost more than running either one alone.
Once IPv6 usage gets widely deployed in the network and IPv6 has been shown to be sufficient for the purpose, it would be wise to start removing IPv4 A and MX records in the DNS. This will enhance the use of IPv6 by taking IPv4 usage out of service, but it will do so without actually taking the service offline. If issues arise, restoring the DNS records restores IPv4 service. At some point, it should become clear that there is no IPv4 usage of the affected services, and IPv4 support is no longer a business requirement.
Protocol Implementation and Readiness
No doubt, in the process of deployment, issues will arise, just as they do when deploying services using IPv4. Eventually, IPv6 deployment and coexistence implies a transition from IPv4 to IPv6; if there is reason to step into coexistence, eventually there will be users with only IPv6 service, and communicating with them will force other networks to follow. In time, the business case for maintaining IPv4 connectivity will become questionable.
The Way Forward
As stated earlier, this author believes that IPv6 deployment will help address problems that the Internet is starting to experience and will experience in detail in a few years. From this author’s perspective, the coexistence model is the least painful form of transition. It has monetary costs and other risks, but that is true of all transitions. This one also has a safety net built in, which more sudden approaches do not.