IPv6 Deployment Strategy at Penn
Shumon Huque, Jorj Bauer, Mark Wehrle, Jeff Edwards
This document describes the need for Penn to aggressively deploy IPv6, the next generation Internet Protocol, in its network and applications. A fair amount of groundwork and initial deployment has already been done over the past few years, but wider scale deployment and ongoing support of this technology requires additional concerted effort. The paper will first discuss the current state of today's Internet Protocol (IPv4), and the impending exhaustion of its address pool. It will then describe the current state of IPv6 deployment at Penn, outline a possible strategy for wider scale deployment, and discuss some open areas of investigation.
The Need for IPv6
IPv4, the current version of the Internet Protocol, faces an impending exhaustion of addresses. Current projections are that IANA, the Internet Assigned Numbers Authority, will have handed out its remaining IPv4 address blocks to regional Internet registries by mid 2011. And by mid 2012 or so, it's expected that the regional registries (e.g. ARIN in North America) will have given out all those addresses to their customers (typically ISPs and large enterprises). After this time, no one will be able to obtain new IPv4 addresses, at least not in the normal manner. Yet Internet usage continues to grow at an aggressive rate. Currently connected organizations as well as new organizations and people connecting to the Internet will continue to place large demands on future address resources.
It is worth noting that the projected depletion date is based on the current rate of allocation of the remaining addresses. Some technology analysts think it is quite possible that an accelerated rate of depletion may start to happen as time passes.
IPv6, the next generation of the Internet Protocol, has been available for many years. It provides a greatly expanded address space which is expected to last into the foreseeable future. Yet, its uptake has been poor, and IPv6 still remains largely undeployed in most parts of the Internet and its connected organizations.
The original expectation was that most computers and networks would already be dual-stack by this time. Dual-stack means that they would have both IPv4 and IPv6 capability and connectivity. And there were would be a fairly simple and gradual transition to IPv6 over the course of time.
It now seems likely that an orderly dual-stack transition will not occur in time. And a number of undesirable scenarios may develop. There could be a mad rush or panic by organizations to claim the remaining address space. There might develop a black market of IPv4 addresses, with companies buying and selling blocks of addresses to the highest bidder (although regional registries are already formulating policies allowing sanctioned IPv4 address transfers between agreeable parties). Service providers and enterprises may decide to deploy more and more layers of NAT (Network Address Translators), with their increasingly damaging impacts on a variety of applications. It is inevitable that many new organizations and services will come online using IPv6 only. And thus, there will likely be a balkanization of the Internet, i.e. the emergence of islands of IPv4-only systems, and IPv6-only systems, which will not be able to communicate with each other. Even organizations that think they have an adequate amount of existing IPv4 address space will face problems, because they may no longer be able to use the new class of emerging IPv6-only services.
We feel that IPv6 deployment is necessary for the continued growth of the Internet. And to preserve important architectural properties of the Internet that have made it successful in enabling new generations of applications and services (universal connectivity, end-to-end addressability etc). Furthermore, the scale of networking IPv6 enables is ideally geared to the Internet's future, where one might imagine Internet access is needed by all our home appliances, our ever growing set of consumer electronic gadgetry, or millions or even billions of wireless sensor devices. The IPv4 Internet cannot possibly accommodate the needs of this world.
Current State of IPv6 Deployment at Penn
Penn started investigating IPv6 quite early. Penn is a founding member of Internet2 (the foremost U.S. advanced networking consortium for the research and education community) and operates an Internet2 regional network called MAGPI. MAGPI has had IPv6 fully deployed throughout its network infrastructure since 2002. MAGPI in turn currently provides access to the global IPv6 network to three of its connected institutions: Penn, Princeton University and NJEdge (New Jersey Edge - the NJ state education network, which includes many NJ universities including Rutgers and NJIT).
IPv6 Deployment in the Penn campus network first began in 2005. The Penn border routers and campus core routers are IPv6 enabled. A selected number of end-user subnets (mostly in the offices of ISC Networking) are IPv6 enabled. And three major campus server subnets are also enabled. This has enabled us to gradually deploy a few IPv6 enabled application services and test them from client computers in the offices of ISC Networking. The School of Engineering and Applied Science has also deployed IPv6 throughout most of its network.
Some of the notable central application services that have been enabled for IPv6 include: DNS (Domain Name Service), NTP (Network Time), and Jabber. MAGPI's web server (but not Penn's) supports IPv6. Also SSH remote login to many of the servers also supports IPv6 for systems administration staff.
Next Steps in IPv6 Deployment
In terms of network infrastructure, the main task ahead is to extend IPv6 from the core of the campus network to the various campus building subnets. Penn is well positioned to do this since routing equipment deployed throughout the campus network already supports IPv6.
Penn will continue to extend IPv6 where requested by local support providers. In conjunction with a series of presentations and discussions to IT forums like SUG (Super User Group) and IT RoundTable, Penn is planning to gradually extend the deployment of IPv6 to the rest of the campus (precise timeframe to be determined). Basic IPv6 training may also be needed for IT support staff.
As these plans proceed, Penn should continue to enable or enhance IPv6 capability in its various network applications, like Web, E-mail, Authentication (Kerberos, RADIUS, etc), Directory (LDAP), etc. For centralized management of client addresses, Penn should also plan to deploy a DHCPv6 service.
Open Issues and Areas of Investigation
TunnelingA variety of tunneling mechanisms exist by which computers can use IPv6 without a working IPv6 network infrastructure. Two of the popular mechanisms are 6to4 and Teredo. IT staff should be aware that users on campus may already be using IPv6 via these mechanisms, and in doing so, perhaps evading filtering and monitoring infrastructure that may be oblivious to IPv6 (like many current varieties of firewalls, passive flow monitors, etc). This tunneled traffic is also possibly being relayed through a tunnel exit point in a distant part of the Internet (e.g. a Microsoft server in the case of Teredo), where that traffic could potentially be analyzed. Deploying native IPv6 infrastructure throughout the campus would eliminate the need for tunneling. It would prevent large portions of IPv6 traffic from being routed to a remote tunnel exit point and taking a suboptimal path through the network. It would provide better performance than tunneled infrastructure. And it would increase the visibility of traffic to network analysis systems. While it is possible to deploy 6to4 or Teredo relay routers in the campus infrastructure to optimize the tunnel transit paths, it would be a far better strategy to accelerate the deployment of native IPv6 campus wide.
Site MultihomingSite Multihoming is the process of establishing multiple connections to the Internet (e.g. via multiple Internet Service Providers) to increase the reliability and resiliency of external connectivity. The Internet community (and in particular the IETF) has not yet fully determined the best way to support scalable multi-homing in IPv6. In light of this fact, Penn has obtained its own Provider-Independent address space that can be advertised to multiple external peers. As standardized multihoming techniques and protocols are developed, Penn may have to revisit some aspects of its network configuration as it relates to external connections.
IPv6 Peering with the Commercial InternetVery few commercial ISPs have deployed IPv6 to date. Penn's sole connection to the IPv6 Internet today is via the MAGPI GigaPoP and Internet2, a research and education backbone network. Penn should continue to investigate the feasibility of IPv6 service from commercial ISPs, in order to increase the resiliency of its IPv6 connectivity. Allegedly, Level-3, one of its existing ISPs now offers a trial IPv6 service.
State of IPv6 Application SupportMost modern operating systems today offer a fairly complete IPv6 network stack. This includes Microsoft Windows, Apple's Mac OS X, Linux, various flavors of BSD, Sun Solaris, etc. Application support is a slightly more complicated. While many applications do support it, many others don't. There are also varying levels of maturity of software implementations. Fortunately, we are in the early stage of IPv6 adoption, so implementations of IPv6 are only expected to get better and more complete over time. Mac OS X does not yet support DHCPv6 for address configuration, as an example. Penn also has a variety of home grown network applications in use. They will need to be modified to incorporate IPv6 support. Any application that stores data about IP addresses, particularly in a database (e.g. for connection logging, access control lists, billing etc) will likely also need to be updated to support the storage of IPv6 addresses, which are four times as long as IPv4 addresses, and have a different textual presentation format.
IPv6 Support in MiddleboxesMiddleboxes are network devices like firewalls, NATs, VPN concentrators, server load balancers, etc that examine, block, modify, IP packets in flight. They have many and varying effects on the network, but will certainly need enhancements to support IPv6 packets. Many older versions of such devices do not support IPv6. And depending on how they are architected, they may allow all IPv6 traffic through unconditionally, block all IPv6 traffic unconditionally, or cause some effect intermediate between these two extremes. IT staff and users deploying these devices will need to take into account what IPv6 support is present in them.
6-4 TranslatorsIn large parts of the Internet, the dual-stack transition model has failed to materialize. In light of this fact, it is inevitable that IPv6-IPv4 translators will emerge. The IETF deprecated a previous standard called NAT-PT in this area for reasons of operational problems, but is now in the midst of standardizing replacement protocols, despite their various intrinsic limitations. Penn's strategy should remain focused on native IPv6 deployment as much as possible. It is likely that we will still need to support a class of older IPv4-only devices (e.g. specialized hardware appliances, critical applications and/or systems that have no recourse to code upgrades). So, NAT64 translators may also have a place in Penn's network for such specialized uses.
3rd-Party Service ProvidersCertain large services at Penn have components outsourced to commercial service providers. Two such examples are the campus web service, which utilizes a global content caching network from Akamai, and the central e-mail service, which utilizes virus and spam filtering service from Message Labs. In both these cases, neither outsourced provider (Akamai, Message Labs) supports IPv6. Since it is difficult to move these services in-house without losing important functionality, ongoing discussion with the providers is needed to establish a commitment and timeline for IPv6 support.
Implications for Security, Monitoring, Billing, etcThe IPv6 implications for security were already mentioned in the Middleboxes section of this paper. Any security device or application that relies on network layer address information needs to be enhanced to understand IPv6. Penn utilizes an extensive network flow monitoring system throughout the campus network for purposes of traffic characterization, peering analysis, attack detection, etc. While this system monitors IPv4 traffic flows only, plans exist to add IPv6 capability in the near future. In terms of billing, a part of the cost of operating the campus network infrastructure as well as many central network services is obtained from something called the "Central Service Fee". Part of this fee is based on IP address usage. How this fee structure can accommodate IPv6 addresses is unclear at this point. In IPv6, hosts can have many types and numbers of addresses simultaneously, e.g. link-local addresses, one or more global addresses, temporary addresses, cryptographically generated addresses etc. Many of these addresses may not be registered in the DNS or managed centrally via DHCP, so could not easily be used as the basis for billing. Investigation is needed to determine how the billing model will evolve to deal with IPv6. Note that at least for the foreseeable future, IPv4 and IPv6 are expected to co-exist. So at least initially, the billing model could remain tied to IPv4 addresses, under the assumption that there will be very few normal IPv6-only hosts on the Penn campus network.
The projected depletion of the IPv4 address pool is only 3 years away. Fairly soon, new Internet services will likely come online, accessible only via IPv6. New populations of users with IPv6 only connectivity will also emerge, who are potentially customers or consumers of Penn's Internet services. It is in Penn's best interests to adopt IPv6 as soon as possible. And to deploy IPv6 throughout its network infrastructure and develop IPv6 capability in all its applications and network services.
Information Systems and Computing
University of Pennsylvania
Comments & Questions