IPv6 Deployment at Penn
Shumon Huque, Jorj Bauer, Mark Wehrle, Jeff Edwards
Networking & Telecommunications, University of Pennsylvania
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
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, although it has deployed very few application services
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
A 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 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
IPv6 Peering with the Commercial Internet
Very 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 Support
Most 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
IPv6 Support in Middleboxes
Middleboxes 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.
In 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 Providers
Certain 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, ongoing discussion with the providers
is needed to establish a commitment and timeline for IPv6 support.
Implications for Security, Monitoring, Billing, etc
The 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.