The IPv4 world as we know it is coming to an end. IPv6 is the only perennial solution to global IPv4 address depletion, but transition will take several years, if not decades.
As a consequence, service providers have to deal with two distinct issues:
- The need to face the forthcoming global IPv4 address depletion, which means the introduction of IPv6 capabilities into network and service infrastructures
- The need to guarantee IPv4 service continuity during the transition period when global IPv4 addresses will become even more scarce: that is, make sure customers can still access IPv4 content from an IPv4 terminal despite the scarcity of public IPv4 addresses.
The Need for IPv4 Service Continuity
The current thinking is that IPv4 service continuity can be addressed by introducing network address translation (NAT) capabilities into networks (also known as carrier-grade NAT or CGN) so that a global IPv4 address can be shared among several customers. But doing so may not be a good solution. While address-sharing issues and NAT hurdles have been extensively documented within the IETF, most service providers see them as little more than a necessary evil.
CGN Taxonomy
There are generally two kinds of CGN technologies: those that are used in addition to existing NAT capabilities and that are activated by customer-premises-equipment (CPE) devices, also known as double NAT, and those that rely on a single NAT.
Double NAT
Simply put, utilizing double NAT technology means that privately addressed IPv4 traffic that is sent by terminals located on the customer’s premises will first go through one level of NAT (embedded in the CPE) and then go through another level of NAT (embedded in the CGN). This approach has the advantage of not requiring customers or service providers to upgrade existing CPE devices. This is an especially attractive option for service providers that do not manage CPE equipment.
There are, however, drawbacks to the double-NAT approach. First, in the double NAT design it is assumed that the regions of the network where CGN capabilities are activated enforce an IPv4 forwarding scheme based on the use of private IPv4 addresses. However, it is being done so at the cost of being exposed to the (complex) management of overlapping private addressing schemes in the network. That means the private addressing scheme enforced by the service provider in its network must not conflict with the customers’ own private addressing scheme; it assumes an agreement between the service provider and its customers that the customers are not using private IPv4 addresses that are assigned to the portion of the service provider’s network that is conveying privately addressed IPv4 traffic towards one of the available CGN capabilities.
Second, double NAT designs assume that the CPE devices that are serviced by the same CGN are not communicating with each other by default, because incoming privately addressed traffic is usually discarded by the firewall embedded in the CPE. Therefore, such traffic needs to cross the CGN so that the initial private-source address can be translated into a global IPv4 address, which is what hairpinning is all about.
Single-level NAT
The IETF currently standardizes one version of the single-level-NAT approach, which is called dual stack-lite or DS-lite. Within the context of a DS-lite design, privately addressed traffic sent by terminals located on the customer’s premises is first encapsulated by the CPE into IPv6 datagrams, which are then forwarded to one of the available CGN capabilities.
The DS-lite CGN will then, in turn, decapsulate the privately addressed IPv4 traffic and perform the usual NAT operation. Entries maintained by a DS-lite CGN device in its BIB (binding information base) assume the manipulation of a specific parameter that will unambiguously identify the CPE to which return traffic will be forwarded. Typically this parameter is the IPv6 source address used by the CPE to forward privately addressed IPv4 traffic toward one of the available CGN capabilities that are deployed in the network.
Obviously, DS-lite designs assume an upgrade of the existing CPE so that it can support an IPv4-in-IPv6 encapsulation scheme. In addition, CPE devices need to be provisioned with the IPv6 reachability information of the CGN.
Some might object to this kind of approach, arguing that it sustains the use of IPv4 instead of moving toward IPv6. In reality, DS-lite CGN technology can be seen as a true catalyst of IPv6 deployment because it requires that at least the access infrastructure is IPv6-enabled, which is not true of a double-NAT approach.
The Impacts of CGN
The introduction of CGN capabilities into networks raises a number of issues, the most important of which is the handling of user-generated content (UGC), meaning content that is provided and maintained by customers and that need to be accessed from the Internet. A UGC context assumes the ability to assign a specific port number to the device that supports such contents within the customer premises (for example, Port #80 for a website).
This is currently handled in some environments by means of an Internet gateway device (IGD) protocol machinery specified by the UPnP (Universal Plug and Play) forum, where the terminal that maintains the contents will send a port number allocation request to the CPE, which will, in turn, manage the corresponding pinhole.
In a DS-lite CGN environment, there is no NAT capability activated in the CPE anymore, hence raising an important UGC-inferred issue. From this perspective, the IETF has recently chartered a working group to specify the port control protocol (PCP) that aims to control a CGN (or a firewall) for port-number-management purposes.
The PCP protocol relies upon a simple, client/server architecture. The PCP client can be embedded in the CPE, which, in this case, acts on behalf of the terminals connected to the CPE. This assumes the availability of an interworking function that, for instance, will convert IGD-formatted port number allocation requests into PCP-formatted messages that can be sent to a PCP server.
Upon receipt of a PCP request message, the PCP server will then solicit the CGN to make sure the request can be satisfied (such as by allocating several port numbers to a given customer during a limited period of time). The base PCP protocol specification is expected to be published as a Standards Track RFC before H2 2011 and is seen as a key asset by some service providers for consolidating CGN design.
CGN designs are not solutions to the global IPv4 address depletion; rather, they are meant to rationalize global IPv4 address usage during the transition period. They should not be regarded as alternatives to the deployment of IPv6; they should, in fact, encourage it.
France Telecom and IPv6
In 2008, France Telecom launched the IPv6 group-wise programme after more than 10 years of expertise in IPv6. The purpose of the programme is to define the group’s IPv6 strategy and support enforcement of this strategy by contributing to country-specific IPv6 projects being developed by the group’s affiliates.
The programme covers both residential and corporate markets and encompasses both fixed and mobile environments. It is organized into three major phases:
- Phase 1 (2008–2010) focused on introducing elementary IPv6 capabilities into networks (including management of IPv6 addressing schemes, IPv6 forwarding and routing policies, IPv6-inferred devices, and customer management policies) and restricting the scope of the service to Internet access alone.
- Phase 2 (2009–2012) focuses on IPv6 instantiation of the whole range of service offerings provided by France Telecom, including advanced IP services, such as voice-over-Internet-Protocol (VoIP) and Internet Protocol television (IPTV) as well as emerging services, such as machine-to-machine communication,
- Phase 3 (2012 and beyond) will mean the introduction of IPv6 customers, networks, and services, yielding the design and the deployment of IPv6-only access and backbone infrastructures according to the revisited Pv4 address-depletion forecasts.
Service-wise, the group’s IPv6 strategy relies on a dual-stack architecture. Figure 1 offers a high-level, networking overview of this approach for fixed environments.
In this architecture, CPE devices become dual-stack routers that are dynamically assigned an IPv6 prefix by means of DHCPv6 (dynamic host configuration protocol for IPv6).
Both corporate and residential CPE devices are assigned a /56 prefix by default (in RIPE-dependent regions), but corporate customers can request the assignment of /48 prefixes as an option of the IPv6 virtual-private-network service offering that was launched in May 2009 (see here for example).
For fixed environments, this design will inevitably include DS-lite CGN capabilities for the reasons that have been discussed earlier.
The corresponding design depends on the distribution of DS-lite CGN capabilities that are, from an IP-forwarding standpoint, as close to the customer as possible. This is for several reasons, including performance (efficiency of the forwarding policy, time to access the service) and scalability (the number of customers to be serviced by a given DS-lite CGN capability will be equivalent to the number of customers who are currently connected to a given digital subscriber line access multiplexer, or DSLAM, device.
Mobile Services
The release 9 of the 3rd Generation Partnership Project specifications allows access to IPv4- and IPv6-formatted content using a single packet-data-protocol (PDP) context, hence an optimization of bandwidth resources. Applications should be address-family independent, meaning they should be used indifferently over an IPv4 or IPv6 stack so as to avoid any extra mobile handset complexity or cost for the customer while migrating towards IPv6. Within this context, IPv6-only PDP contexts will be established and access to IPv4-formatted content will rely on NAT64 capabilities to be deployed in the network (such as at the GGSN, or gateway GPRS support-node, level in 3G environments).
VoIP Services
Migration of VoIP services towards IPv6 will be gradual: IPv6 capabilities will first be introduced in the access-network infrastructure, meaning that access-session-border-controller devices become dual stack while the core of the network will remain IPv4.
CPE devices also embed an IPv6 session-initiation-protocol user agent.
IPTV Services
Very often, existing IPTV services rely on a walled-garden design, wherein private IPv4 addressing schemes are used in overwhelming numbers, hence lowering the pressure to move towards IPv6. However, the simplification of access network infrastructures assumes the allocation of a unique, global IPv4 address to the CPE in order to access the network. As a consequence, IPTV services will be impacted by the global IPv4 address depletion. Similarly, as IPTV services evolve, they will likely include access to content located on the Internet. In that case, IPTV services would encompass so-called Web TV services, which naturally assumes a global IP addressing scheme, which will encourage the use of IPv6.
Finally, we can expect homogenization of the IP interface through which a whole range of services can be accessed. As Internet services move toward a progressive introduction of IPv6 capabilities in network and service infrastructures (which it will need to do in order to access and deliver content), access to IPv6-formatted IPTV content becomes straightforward. And since multiprotocol label switching contributes to the overall QoS enhancement, it will become the primary forwarding scheme for conveying both IPv4- and IPv6-formatted content.
The introduction of IPv6 in set-top boxes will primarily impact applications that solicit the network layer, such as when selecting a television programme or conducting a personal videoconference.
Current Status
Twelve country-specific IPv6 projects have been initiated since 2010, yielding IPv6 pilot deployments in Belgium, France, Moldova, Poland, Romania, and Senegal.
Additional field trials will begin in 2011 while commercial IPv6 connectivity service will be available as early as 2012 for some country affiliates. These field trials will cover the scope of the migration phase of the programme, meaning some of the group’s affiliates will experiment with IPv6-enabled VoIP and IPTV services.
Lessons Learned
The IPv6 projects that were launched back in 2009 demonstrated that evangelization is key: decision makers need to thoroughly understand that there is no way but the IPv6 way if we are to sustain existing business and develop new markets.
We have also learned that IPv6 deployment should not be presented as a tedious and complex set of isotropous operations (while major technological locks reside in the CPE devices and the IT infrastructure, there are not many in the network itself).
Rather, IPv6 evangelists should promote the tremendous opportunities in terms of business development as well as cleaning up network designs that have proven to be inefficient, particularly when it comes time to forward VoIP or IPTV traffic.
The forthcoming transition period will undoubtedly bring some difficulties, including the need for service providers to guarantee IPv4 service continuity when it will not be possible to assign a global IPv4 address to each and every (new) customer, which is likely to degrade the quality of service, particularly for those customers who will be serviced by a CGN. Even so, this does not mean we should not be encouraging, if not accelerating, migration toward IPv6.
Last, but not least, there are still some vendors (mostly in the CPE and set-top box areas) who are not yet IPv6-minded. The oft-repeated “lack-of-business drivers” argument is no longer convincing thanks to a set of consolidated positions from the service and content providers’ communities.
From that standpoint, standard bodies (and especially the IETF) have a key role to play in the promotion of IPv6: it is not only a matter of making sure the voice of service and content providers can be heard (by vendors), but also making sure that the standardization effort remains focused on IPv6 deployment issues.
The clock is ticking, and we must be on IPv6 time.