whI Popr

IPv6 for Mobile Networks: Time to Act Now!

Overview
Pv6 has become an nternet Request For Comment (RFC) in 1995 [1]. Pv6 was developed
to solve a number of problems associated with Pv4. Solving address space limitation and
lack of inherent security (authentication and integrity) of Pv4 were the primary motivators for
Pv6. Mobile communications industry saw Pv6 as an essential feature. Pv6 was defined as
the default P addressing scheme for Universal Mobile Telecommunications Service (UMTS)
release-99.
Adoption of Pv6 didn't follow the anticipated path. Among multiple reasons for this, probably
the primary was industry's ability to overcome limited Pv4 address space with Network
Address Translation (NAT). NAT has extended life-time of Pv4 substantially even though it
has introduced a significant number of problems; well documented in [2].
As of October 2010, Pv6 adoption is dismal [3]. Only 2% of the top 1000 websites have
WirelessE2E LLC October 2010 Page 1 oI 35
www.wirelesse2e.com
whI Popr
reachability over Pv6 [4]. On the other hand, common industry
consensus shows that last Pv4 address will be allocated to an end user
before the end of 2012 and nternet will officially run out of Pv4
addresses [5]. With this looming deadline, we anticipate Pv6 adoption
will pick up steam.
Unlike other nternet operators, Mobile Network Operators (MNOs) had
to adopt with address crunch early on. Early standardization activity
based on Pv6 in 1990s didn't lead to adoption. nstead MNOs had to rely
on NAT. This long term experience with NAT will allow MNOs to adopt
Pv6 much easier and faster than fixed network operators.
n this paper, we will review the status of nternet addressing, adoption of
Pv6, depletion of Pv4, multiple proposals for Pv6 transition. We will
identify specific transition methods for mobile networks and compare
their relative strengths. We will summarize our findings with a set of
recommendations for MNOs on how they can embark upon eliminating
this business risk.
Internet Addressing
Pv4 was published as an nternet Engineering Task Force (ETF) RFC
(RFC-791) in 1981 [6]. t used a 32-bit addressing scheme, potentially
allowing over 4 Billion addresses. Original design of Pv4 dating back to
1973-1974 assumed an 8-bit network and a 24-bit host address [7]. This
allowed only 256 networks but in 1973 this number looked perfectly fine
when there were a handful university and research facility sites
connected.
When the limitation of 256 was discovered to be too restrictive, class-
WirelessE2E LLC October 2010 Page 2 oI 35
www.wirelesse2e.com
Losr mojor nerwor|
rronsirion noppeneJ
on Jon. 1
sr
198S
wnen Nerwor|
Conrrol Prorocol
(NCP) wos snur-
Jown ro qive woy ro
TCP/IP.
whI Popr
based addressing schema was adopted. This allowed class A addresses
(8-bit network and 24-bit host address), class B addresses (16-bit
network and 16-bit host address) and class C addresses (24-bit network
and 8-bit host addresses). Based on this schema, the first half of Pv4
address space was identified as class A. Class B address space
occupied of the available address space whereas class C addresses
took 1/8. Class-based addressing schema led to a very sparse allocation.
A number of companies, universities, research and military organizations
jumped on the band-wagon and they obtained their class A address
space (providing 16M host addresses). Among the owners of class A
addresses, we can recognize some well known names of technology
industry such as General Electric, BM, Xerox, HP, Apple, AT&T. Some
other companies, not necessarily associated with networking technology
such as Prudential Securities, Eli Lilly, Halliburton are also among a
number of companies with their class A address spaces.
By 1993, inefficiencies of class based address allocation scheme were
obvious. Class B address space providing 65K hosts was too large for
many enterprises whereas class C address space containing only 256
addresses was found to be too restrictive. n order to overcome these
limitations Classless nter Domain Routing (CDR) was introduced [8].
CDR relied on Variable Length Subnet Masking (VLSM) and allowed
subnets of varying sizes in terms of host addresses.
Following figure from a dynamic webpage [5] for Pv4 address report
maintained by Geoff Huston (Asia Pacific Network nformation Center
(APNC)) summarizes the rate of Pv4 address allocation dating back to
1984.
WirelessE2E LLC October 2010 Page 3 oI 35
www.wirelesse2e.com
Sron[orJ Universiry
rnor nos o closs-A
ossiqnmenr
(S6.0.0.0/8)
rerurneJ ir boc| ro
ARIN ro ossisr wirn
IPv4 Jeplerion.
Un[orrunorely
Sron[orJ nos been
on exceprion.
whI Popr
Between 1988 and 1994-1995, class A address allocations resulted in a
significant expansion in allocated address space. With the introduction of
CDR, this trend slowed down between 1995 and 2002-2003. Since then
with the proliferation of nternet in every facet of daily life, expansion of
allocated address space accelerated.
As of October 2010, nternet Assigned Numbers Authority (ANA) has
only 14 /8 address spaces left at its disposal. [5] predicts that by June
12
th
2011, ANA will allocate last of its available /8 addresses to a
Regional nternet Registry (RR). Similarly, the same report predicts that
February 2
nd
2012 will be the first date for an RR to run out of its
available Pv4 address space.
Once the Pv4 address space is depleted, a new commercial
environment is expected to come to picture. Probably this would have
positive benefits such as reducing the inefficiencies in address allocation
within networks. On the flip side, it will also increase the cost of acquiring
addresses and in turn increase the cost of using nternet. This last point
WirelessE2E LLC October 2010 Page 4 oI 35
www.wirelesse2e.com
Anorner 16 /8
oJJress spoces were
iJenri[ieJ os closs L
oJJresses mor|eJ
[or [urure use. ILTF
nos been resisronr
ro re-ossiqn rnese
oJJresses [or public
or privore unicosr
oJJressinq. Usinq
rnem ro exponJ
privore oJJressinq
nos merirs.
whI Popr
and its unknown extent are the major motivations to migrate to Pv6.
IP Addressing in MobiIe Networks
Mobile communications industry identified the need for Pv6 as early as
1997-1998. Original Third Generation Partnership Program (3GPP)
UMTS standards (release-99) were written with the assumption of Pv6
as the default packet data protocol and address type.
Early enthusiasm of the mobile industry didn't translate into operational
deployments. Certainly prime reason for this was the lack of Pv6
content. Furthermore, factors such as longer P packet headers, lack of
suitable handset Operating System (OS), lack of Pv6 applications all
contributed to mobile industry's abandonment of Pv6 and adoption of
Pv4 with Network Address Port Translation (NAPT)
1
.
MNOs' adoption of NAT along with Pv4 addressing for customers was
mainly successful due to the following factors:
1. Data service adoption growth lagged the growth of mobile
networks. Until General Packet Radio Service (GPRS) and One
times Radio Transmission Technology (1xRTT) were introduced,
data service was limited to modem emulation over Circuit
Switched Data (CSD). Only after the introduction of 3G and more
recently with smart phones such as iPhone, Android, Blackberry
data service adoption accelerated.
2. nitially data services were primarily restricted to operator's walled
garden. Wireless Application Protocol (WAP) and operator value-
added services for content promoted this restriction. Handset to
1 We will reIer to NAPT as NAT in the rest oI the document unless we need to distinguish it Irom basic NAT.
WirelessE2E LLC October 2010 Page 5 oI 35
www.wirelesse2e.com
Oriqinolly UMTS
releose 99
sronJorJs mor|eJ
IPv4 os oprionol.
Loc| o[ ovoiloble
rerminol Jevices
wirn IPv6 convinceJ
SGPP ro cnonqe
rnor by releose 4.
whI Popr
servers within walled-garden communication didn't need NAT.
3. Traffic volume for data usage was miniscule compared to traffic
volumes operators started experiencing for the last 2-3 years
since the introduction of smartphones. Low traffic volume
lessened the impact on NAT devices.
4. nitial data devices were rarely always-on. That reduced the
impact on NAT platforms in terms of the number of translations
they needed to maintain. Few always-on devices like Blackberry
used their dedicated private address scheme that allowed
communication with cloud servers. Such communication didn't put
any burden on carrier's NAT platforms.
5. Handset-to--handset communication applications were typically
banned. nstead developers relied on application layer client-
server model as opposed to peer-to-peer communication.
6. Mobile devices were designed and promoted to be clients as
opposed to servers. For customers who need mobile servers,
custom solutions such as public P addressing or tunneling based
topologies were used.
Even though deployment of NAT was a success, it introduced numerous
compromises that resulted in various limitations in services provided to
customers:
1. Standard applications like Hyper Text Transfer Protocol (HTTP),
File Transfer Protocol (FTP), Simple Mail Transfer Protocol
(SMTP) worked well behind NATs. On the other hand, more
involved protocols like Real Time Streaming Protocol (RTSP),
WirelessE2E LLC October 2010 Page 6 oI 35
www.wirelesse2e.com
Unril recenrly
mobile nerwor|s
noJ very limireJ
uplin| bonJwiJrn.
Tnis reJuceJ rne
incenrives ro builJ
mobile servers or
usinq mobile
Jevices os conrenr
Jonors [or peer-ro-
peer opplicorions.
whI Popr
many Voice over P (VoP) flavors suffered even though NAT
vendors worked hard to provide updates to their Application Level
Gateway (ALG) functions. Many application developers migrated
towards http transport.
2. Consumer use of mobile data networks is defined to be mobile
client only model. Everything else was deemed to be vertical,
needing different Access Point Names (APNs), devices, etc.
3. Operators didn't have the level of granularity to record usage at
the network boundary and tie a particular session back to an
individual customer. This impacted their ability to handle
subpoena requests coming on behalf of other nternet providers
looking for abusers among MNO customers.
4. NAT platform became a weak point in the network that was at risk
to be attacked (denial-of-service) as well as impacting overall
service in case of platform failures.
5. NAT complicated network design; requiring either co-location with
gateway platforms or artificial routing methods in order to keep
session consistency.
6. Even with the use of private P addressing, MNOs ran out of Pv4
(private) addresses. This required replicating the same RFC-
1918 address space numerous times or using BOGON-space.
First option fragmented operator networks even more whereas
the second option resulted in frequent re-numbering every time a
previous BOGON was assigned.
With the impending Pv4 exhaustion date, it is quite imperative for MNOs
WirelessE2E LLC October 2010 Page 7 oI 35
www.wirelesse2e.com
As on exomple
Verizon re-uses rne
enrire RFC-1918
oJJress spoce in 40
locorions [or NAT.
whI Popr
to start the Pv6 deployment effort. Considering the lack of Pv6 content
and the established Pv4 legacy, Pv6 transition is a major effort that is
expected to take a long period of time. This long transition is expected to
require sizable capital and operational expenditure. Picking a wrong
choice for transition may lead an MNO to burn unnecessary capital and
lose valuable time.
IPv6 Transition Techniques
Pv6 transition has been in planning for the last 15 years. Throughout this
period, numerous proposals have been developed to resolve various
issues with transition. These proposals can be classified within three
major classes:
Dual-stack techniques are methods that rely on having both Pv4
and Pv6 capabilities in network nodes as well as hosts. This
provides the most flexible transition strategy since hosts pick the
right protocol stack based on the application requirements and
network treats Pv4 and Pv6 equally.
Tunneling techniques are methods that rely on encapsulating one
type of network traffic over the other during the transition period.
nitial motivation for tunneling techniques was to interconnect Pv6
islands through Pv4 networks.
Translation techniques are methods that rely on converting
protocol data units belonging to one protocol to another. Primarily
they will be useful when transition needs to take place with the
smallest impact to fewest number of nodes.
WirelessE2E LLC October 2010 Page 8 oI 35
www.wirelesse2e.com
whI Popr
Before we look at the mobile network specific transition strategies, let us
review the industry status, look at different classes of transition
techniques and identify trends.
DuaI Stack based Transition Methods
Dual stack based transition is described as the preferred path per RFC-
4213 [9]. Based on this model, all network operators as well as end users
that are currently running Pv4, must obtain an Pv6 prefix, enable Pv6
routing within their networks as well as interconnectivity with other
networks and enable it on hosts. While Pv6 is being turned up, they
should leave Pv4 stable until application quality and coverage parity is
obtained between these two versions of P networking. When parity is
achieved, economic justification for running Pv4 will disappear and Pv6
will become the sole networking protocol. Following figure shows the
dual protocol stack for a host.
Unfortunately the last 15 years have shown us that end users and
network operators couldn't be motivated to invest in this dual stack
strategy. Following figure from [5] shows the Autonomous Systems (AS)
WirelessE2E LLC October 2010 Page 9 oI 35
www.wirelesse2e.com
Lven rnouqn Juol-
sroc| is JeemeJ ro
be rne mosr [lexible
ir su[[ers [rom
per[ormonce
concerns especiolly
wnen IPv6 nerwor|
moy nor be os
relioble os IPv4
(simply Jue ro
lesser operorionol
orrenrion).
whI Popr
that are announcing their Pv6 prefixes on the nternet. t clearly identifies
lingering pace of Pv6 adoption until 2009.
Compared to AS that are advertising Pv6 prefixes, there are more than
35000 AS that are advertising Pv4 addresses as of October 2010.
Certainly in this unbalanced situation of adoption, it is hard to follow
through the original dual stack based transition plan since well before
there is enough interesting Pv6 content, registries will run out of Pv4
addresses. This will require either Pv6 only hosts or dual stack hosts
using private Pv4 addresses. A number of tunneling and translation
based transition strategies were designed to handle the impact of private
Pv4 addressing. We will review those in detail in the next two sections.
TunneIing based Transition Methods
During the last 15 years, many Pv6 transition methods using various
forms of tunneling were proposed. Following is a short summary of some
of these options:
4-in-6 was originally defined in RFC-2473 [10]. t assumes an
WirelessE2E LLC October 2010 Page 10 oI 35
www.wirelesse2e.com
Our o[ S500 or so
AS, Fronce Telecom
(FT) oJverrises rne
snorresr IPv6 pre[ix
(biqqesr oJJress
spoce), o /19. Tnor
equores ro 1/65000
o[ rne oJJress spoce
currenrly ollocoreJ
by IANA [or unicosr
rro[[ic.
whI Popr
Pv6 transport network allowing Pv4 only hosts to communicate.
As a transition method, it can be useful later stages of transition
effort when majority of networks support Pv6 while there are Pv4
islands left. Since it is primarily based on static configuration of
Pv6 tunnels and Pv6 only transport networks are not common, its
adoption was very limited. Following figure shows the 4-in-6
topology.
6-in-4 was defined in RFC-4213 [9]. t assumes an Pv4 transport
network allowing Pv6 only hosts to communicate. Tunnels are
pre-configured and Pv6 traffic is encapsulated over Pv4 using a
new protocol type (41). As a transition method, it is useful to
interconnect Pv6 islands to each other over Pv4 nternet. t
allows host-host, host-router and router-router configurations. Pre-
configured nature of tunnels limits the applicability of this solution
to router-router connections. Following figure shows the example
topology for 6-in-4.
WirelessE2E LLC October 2010 Page 11 oI 35
www.wirelesse2e.com
Number o[
orqonizorions
incluJinq Freener6,
Hurricone Llecrric,
SixXS operore
public no-cosr 6-in-
4 runnel bro|ers
ocross rne worlJ ro
ollow
experimenrorion.
whI Popr
6-over-4 was defined in RFC-2529 [11]. t assumes an Pv4
transport network allowing Pv6 only hosts to communicate. Unlike
6-in-4, 6-over-4 tunnels can be dynamic. Tunnel end points are
defined from Pv4 addresses by prepending a fixed pattern (fe80)
to generate a link local Pv6 address. Similar to 6-in-4, it uses
protocol type 41 for encapsulation. t is dependent on the use of
Pv4 and Pv6 multicast implementation. Since inter-domain Pv4
multicast implementations are so rare, it is primarily applicable for
allowing Pv6 hosts within a single domain.
6-to-4 was defined in RFC-3056 [12]. t assumes an Pv4
transport network allowing Pv6 islands to interconnect. Similar to
6-over-4, tunnels can be dynamic. Tunnel end points are defined
from Pv4 addresses by prepending a fixed pattern (2002::/16) to
generate a link local Pv6 address. Unlike 6-over-4, it doesn't
need Pv4 multicast capabilities. Similar to 6-in-4 and 6-over-4, 6-
to-4 is stymied with the lack of significant adoption of Pv6. 6-to-4
handles the shortage of Pv4 addresses well such that it needs
only a single public Pv4 address per network to generate Pv6
addresses and it allows the interworking with NAT. Following
diagram shows an example of 6-to-4 mechanism with relevant
Pv6 subnet addressing based on the site Pv4 address.
WirelessE2E LLC October 2010 Page 12 oI 35
www.wirelesse2e.com
Currenrly rnere ore
40-50 AS
onnouncinq 6ro4
pre[ix, proviJinq
6ro4 reloy service.
(nrrp://www.qeripv6.
in[o/inJex.pnp/Firsr
_Sreps_[or_ISPs) A
Since 6ro4 reloys
nove ro occepr
rro[[ic [rom ony
nosr, incenrive ro
moinroin quoliry
service is low. Tnis
leJ ro rne
Jevelopmenr o[ 6rJ.
whI Popr
6rd was defined in RFC-5969 [13]. t is an improvement of 6-to-4,
where an nternet Service Provider (SP) specific prefix for the
mapping between Pv4 and Pv6 local address can be used
instead of the fixed prefix. This increases the incentive to deploy
6rd since the SP controls the particular border router for its
customers. Furthermore, 6rd can be deployed when private Pv4
addresses are used within the SP domain. However, in this case
NAT44 at the network border is still essential for Pv4 content. 6rd
has received a lot of attention from SPs that are trying to jump-
start Pv6 deployment. Free in France, Softbank in Japan,
Comcast in the USA are among the pioneers of 6rd adopters. 6rd
can be used as complementary to a dual stack host
implementation. n this mode, it can be considered as an effective
transition strategy in networks where Pv6 network node
deployment is lagging. Following figure shows the potential
deployment scenario for 6rd within a wired SP environment.

DS-Iite is currently being defined in ETF [14]. DS-lite is
dependent on adoption of Pv6 as the networking technology
WirelessE2E LLC October 2010 Page 13 oI 35
www.wirelesse2e.com
Frencn ISP Free
nos JeployeJ 6rJ ro
proviJe IPv6 ro irs
cusromers in 5
wee|s. Tnis
exploins wny rJ
sronJs [or "ropiJ
Jeploymenr" os
well os rne iniriols
o[ irs creoror Remi
Despres.
whI Popr
within an SP domain and allowing Pv4 traffic between dual stack
hosts in customer premises and Carrier Grade NAT (CGN)
devices at the SP boundary over Pv6 tunnels. t has a further
refinement called gateway-initiated DS-lite [15] that allows various
types of tunneling technologies, such as Generic Routing
Encapsulation (GRE), Layer 2 Tunneling Protocol (L2TP), GPRS
Tunneling Protocol (GTP) to map DS-lite tunnels. DS-lite along
with a dual stack host implementation will reduce the need for
double-NATting while permitting the native Pv6 traffic to reduce
the overall load on the NAT44. n the original form of DS-lite,
home gateway device implementing Basic Bridging BroadBand
element (B4) function communicates with the NAT device
implementing Address Family Transition Router element (AFTR)
as shown in the following figure.
DSMIPv6 was defined in RFC-5555 [16]. Dual Stack Mobile Pv6
allows a host (Mobile Node (MN)) to communicate with a Home
Agent (HA) using MPv6 control protocol while allowing it to use
both Pv4 and Pv6 Home Address (HoA) as well as Pv4 and Pv6
WirelessE2E LLC October 2010 Page 14 oI 35
www.wirelesse2e.com
Anorner mojor
bene[ir o[ DSMIPv6
is irs obiliry ro
proviJe IP [low
mobiliry berween
WiFi onJ mocro
wireless nerwor|s.
whI Popr
Care of Address (CoA). Furthermore, it allows NAT traversal
capabilities in situations where MN is allocated a private Pv4
address. Primary penalty of DSMPv6 is the tunnel overhead for
both Pv4 and Pv6 traffic. Following figure shows a MN can have
either Pv4 or Pv6 tunnel back to its HA where the tunnel carries
Pv4 or Pv6 traffic.
There are a number of other methods that can be classified under
tunneling such as Teredo [17], SATAP [18], Multi Protocol Label
Switching (MPLS) Pv6 Provider Edge (6PE) [19]. Due to limited space of
this document, these will not be further discussed in detail. Teredo and
SATAP are methods that deal with Pv6 host-host (subnet-subnet)
between Pv6 islands. Teredo specifically deals with NAT traversal for
such tunnel traffic whereas SATAP handles dynamic tunnel
management capability. Both of these mechanisms have been deployed
in Microsoft OS but have seen limited adoption. MPLS 6PE solves the
inter Pv6 island communication based upon advertising Pv6 routes
learned from PE devices through MPLS. This reduces the impact on the
WirelessE2E LLC October 2010 Page 15 oI 35
www.wirelesse2e.com
Anorner MPLS
mecnonism, 6VPL
is Je[ineJ in RFC-
4659 j40]. Ir
Jescribes usinq
MPLS loyer S
Virruol Privore
Nerwor| (VPN)
concepr [or roure
Jisrriburion onJ ir
ollows novinq
virruol rourer
insronces on PL
rourers. Tnis woulJ
ollow mulri-
cusromer supporr
over o corrier
nerwor|.
whI Popr
rest of the core network elements.
TransIation based Transition Methods
Last group of transition methods are based upon the use of protocol
translation between Pv4 and Pv6. A number of early protocol translation
methods were developed within ETF around 1999-2000. Foundation for
this work was the Stateless P/CMP Translation (ST) Algorithm defined
in RFC-2765 [20]. ST was used as the basis for methods such as
Bump n the Stack (BS) defined in RFC-2767 [21], Network Address
Translation - Protocol Translation (NAT-PT) defined in RFC-2766 [22]
and Bump n the AP (BA) defined in RFC-3338 [23]. None of these
solutions have seen any significant deployment but NAT-PT was
identified as a potential mechanism for Pv6 transition for 3GPP networks
in RFC-4215 [24]. However, in 2007, ETF decided to deprecate NAT-PT
due to numerous problems that have been documented in RFC-4966
[25]. However, this didn't eliminate the need for a transition solution that
is using protocol translation. ETF formed a Working Group (WG),
"behave, to identify a number of transition methods. Following are three
of these that are refinements of the original NAT-PT method:
NAT64/DNS64 is defined in ETF WG drafts [26],[27]. t is
considered to be the stateful method of ETF protocol translation
framework defined in [28]. NAT64 provides a mechanism for Pv6
only hosts to communicate with Pv4 only servers. Unlike the
historical NAT-PT approach, it provides this by splitting NAT and
DNS ALG function. Similar to dual stack options (using tunneling)
like DS-lite, 6rd, it allows native Pv6 traffic from host to Pv6
server without any involvement of other network elements. Unlike
WirelessE2E LLC October 2010 Page 16 oI 35
www.wirelesse2e.com
ILTF nos olwoys
been very resisronr
ro usinq NAT. Mony
RFCs were wrirren
ro unJerline
problems o[ NAT.
One o[ rne mojor
bene[irs promoreJ
[or IPv6 wos rne
obiliry ro eliminore
NAT. Tnere[ore, ir is
rorner inreresrinq ro
see Inrerner
Arcnirecrure BoorJ
(IAB) ro semi-
enJorse NAT [or
IPv6 in RFC-5902
j41].
whI Popr
DS-lite or 6rd, it doesn't need any access site intelligence, i.e.,
host and Pv6 access network and Pv4 server are completely
unaffected by NAT64 functionality. Only devices that are needed
are a CGN platform that provides NAT64 translation and a DNS64
platform mapping Pv4 addresses to NAT64 platforms. Because of
this DNS flexibility, concerns with the historic NAT-PT solution
such as single point of failure and scaling are not applicable for
NAT64. Other major characteristic of NAT64 is it forces a clear
break with Pv4 at the host since there is no Pv4 stack unlike the
earlier dual stack solutions. This is an advantage to accelerate
Pv6 deployment but as of 2010, there are still a number of
applications that don't operate properly over Pv6. Some example
applications are communications applications such as Skype,
Gtalk, AM, multi-party games as well as websites that P address
literals [29]. Same reference reports that for the top 1000 websites
P address literal problem affects only 0.2% of the sites whereas
for the top 10000 sites the failure rate goes up to 2%. Following
diagram shows a mobile phone using an Pv6 address reaching to
www.wirelesse2e.com that is currently hosted on an Pv4 server.
Phone contacts the DNS64 for query. DNS64 reaches out to its
authoritative DNS and then appends the Pv4 address with an
Pv6 prefix associated with a particular NAT64 CGN device.
NAT64 device strips the Pv6 prefix (in this example
2001:db8:8000::/96) and then uses the rest for Pv4 destination
address. CGN's role on the Pv4 side is identical to a typical Port
Address Translation (PAT) device.
WirelessE2E LLC October 2010 Page 17 oI 35
www.wirelesse2e.com
whI Popr

PNAT (Prefix NAT) s defined in ETF WG draft [30]. t was
recently renamed as Bump n the Host (BH) method. As we
discussed NAT64 cannot solve the connectivity requirements for
Pv4 only applications since it doesn't have an Pv4 protocol stack.
BH closes this gap by providing a translation from Pv4 to Pv6
within the host. BH provides DNS64 functionality of the NAT64
method by implementing an extension name resolver software
module within the host. Similarly a NAT46 functional block
translating Pv4 traffic to Pv6 within the host is used. BH suffers
from the same problems NAT64 suffers when dealing with P
address literals in protocol payload.
IVI is an update of the ST RFC and defined in [31]. t is
considered to be the stateless method of ETF protocol translation
framework. Unlike the PAT method used in NAT64, V uses a
one-to-one NAT translation. Practical limitation of this method is
WirelessE2E LLC October 2010 Page 18 oI 35
www.wirelesse2e.com
IVI (sronJinq [or
IV: IPv4, VI: IPv6)
wos implemenreJ in
Cninese
LJucorionol IP
nerwor|.
whI Popr
the amount of public Pv4 addresses needed when the Pv4
addresses are near depletion. V is subject to same constraints
NAT64 has when dealing with Pv6 only networks and hosts.
Furthermore it suffers from the P literals similar to NAT64 and
PNAT. A variant of V called double-V can be used to overcome
the lack of Pv6 support for applications. n this mode, Pv4
Pv6 translation can be implemented in the host similar to what
PNAT does.
Proposed Methods for IPv6 Transition in MobiIe
Networks
3GPP and ETF have been looking at Pv6 migration for a long time. As
early as 2003, ETF has published informational RFC-3574 [32]
analyzing the Pv6 transition scenarios. RFC-3574 covered GPRS
transition as well as P Multimedia Subsystem (MS). t emphasized the
fact that MS was designed as Pv6 only as of 3GPP release 5. RFC-
3574 was quite sparse in terms of the transition techniques that are
applicable. nstead it enumerated all possible interworking needs and left
transition techniques for ETF and 3GPP to identify.
n 2005, ETF has developed informational RFC-4215 [24] mapping
possible transition techniques to transition scenarios identified in RFC-
3574. RFC-4215 analyzed five transition scenarios for GPRS and two for
MS. Let's look at the following two tables for GPRS and MS scenarios
where we can review the relative applicability of the transition technique.
WirelessE2E LLC October 2010 Page 19 oI 35
www.wirelesse2e.com
whI Popr
CPRS
1ransition
scenario
Proposed method Advantages Limitations
Dual stack User
Equipment (UE)
connecting to
IPv4 and IPv6
networks
Deploy dual stack
support in packet
core.
Use pre-conIigured
tunneling when
IPv6 Packet Data
Protocol (PDP)
context is not
supported (e.g.,
roaming).
It simpliIies
network design. It
doesn't impact IPv4
only applications.
It doesn't solve NAT
requirement
(problems) Ior IPv4.
It requires double
packet core
resources. It doesn't
recommend a widely
deployable solution
Ior IPv6 over IPv4
tunneling.
IPv6 UE
connecting to
IPv6 servers
through an IPv4
network
Use pre-conIigured
tunneling between
IPv6 islands over
IPv4.
It allows delaying
upgrade oI operator
backbone Ior IPv6
support.
Numerous problems
with managing
tunnels and security
issues associated
with preconIigured
tunnels.
IPv4 UE
connecting to
IPv4 servers
through an IPv6
network
Use pre-conIigured
tunneling between
IPv4 islands over
IPv6. This is not
considered to be a
likely scenario.
IPv6 UE
connecting to
IPv4 servers
Use NAT-PT in the
operator network.
Alternatively
implement
application level
proxy devices.
None. Better option
is to stay with dual
stack.
NAT-PT has been
deprecated.
Application level
proxies don't scale
Ior multiple
applications.
IPv4 UE
connecting to
IPv6 servers
Use application
level proxy devices
Ior limited number
oI applications. This
will happen when
IPv6 adoption has
taken place. Not an
immediate problem.
It allows mobile
operator to keep
IPv4 legacy without
changes.
Application level
proxies can be built
outside mobile
operator network.
Limited
applicability. It
doesn't solve the
NAT requirement
(problems) Ior IPv4.
WirelessE2E LLC October 2010 Page 20 oI 35
www.wirelesse2e.com
whI Popr
IMS 1ransition
scenario
Proposed method Advantages Limitations
UE connecting
to an IPv4 node
through IMS
Deploy Back-to-
Back User Agent
(B2BUA) such as a
Session Border
Controller (SBC)
between mobile
IMS network and
IPv4 network
It allows
interconnectivity to
Internet based IMS
hosts. Operator can
extend IMS cloud to
home, oIIice, etc.
where IPv6 support
doesn't exist.
It breaks the end-to-
end model. End-to-
end security is
broken.
Two IPv6 IMS
connected via an
IPv4 network
Use pre-conIigured
tunneling between
IPv6 islands over
IPv4.
It decouples
transport network
upgrades Irom IMS
introduction.
Numerous problems
with managing
tunnels and security
issues associated
with preconIigured
tunnels.

More recently, 3GPP took up the task of identifying Pv6 transition
scenarios. 3GPP TR 23.975 [33] describes a list of various scenarios
considered for Pv6 transition. Similar to the churn within ETF with
respect to Pv6 transition techniques, 3GPP seems to be struggling with
having a large number of options and focusing on the most likely strategy
to succeed. Considering many of the referenced ETF drafts have
expired or merged with other proposals, this list needs to be updated
once the official release 10 version of the TR becomes available. Most
recent version (1.1.1) of TR 23.975 outlines the following options:
A+P architecture is defined in an ETF draft [34]. Address+Port
architecture is based on the fundamental recognition of depleted
Pv4 address space and problems associated with port translation.
A+P proposes to extend the Pv4 address space by overloading
Transmission Control Protocol (TCP) or User Datagram Protocol
(UDP) port numbers to identify end devices. t allows multiple
WirelessE2E LLC October 2010 Page 21 oI 35
www.wirelesse2e.com
AP orcnirecrure
oJJresses on
essenriol irem: li[e-
spon onJ quoliry o[
NAT [or IPv4 neeJ
ro be exrenJeJ ro
compensore [or
Jeloys in IPv6
rronsirion.
whI Popr
users to share the same Pv4 address similar to port-translation
but without the need for a translation operation. Obviously this
requires restricting the allowed ports per user to a subset such
that the same P address can be multiplexed among multiple
users. Mobile networks such as GPRS can be quite suitable such
multiplexing since the logical tunnel end point device such as
Gateway GPRS Support Node (GGSN) can be tasked to provide
the Port Range Router (PRR) function. PRR provides routing
traffic to and from hosts based on the A+P functionality. A+P
architecture requires implementation in the UE and GGSN. t is
orthogonal to the deployment of Pv6. n other words, it extends
the lifespan of Pv4 for resolving NAT related problems and
increasing the number of devices that can share a public Pv4
address. Therefore, it can be deployed in a network with Pv4 only
PDP context. Following figure shows the use of A+P within a
mobile network.

DS-Iite where Pv4 is tunneled over Pv6 to a CGN for NAT44
while Pv6 is carried natively. This transition model is applicable
WirelessE2E LLC October 2010 Page 22 oI 35
www.wirelesse2e.com
whI Popr
for a UE with Pv6 PDP context only and both Pv4 and Pv6
protocol stacks.
IVI where Pv4 traffic is translated to Pv6 in the UE and
(stateless)-translated back to Pv4 at a CGN for Pv4 content while
Pv6 is carried natively for UE. This transition model is applicable
for a UE with Pv6 PDP context only and both Pv4 and Pv6
protocol stacks.
DuaI-stack where Pv4 traffic is (port)-translated at a CGN for
Pv4 content while Pv6 is carried natively for UE. This transition
model is applicable for a UE with either two PDP contexts (one for
Pv4 and another for Pv6) or an Pv4v6 PDP context and both
Pv4 and Pv6 protocol stacks.
PNAT/BIH where Pv4 traffic is translated to Pv6 in the UE and
(port)-translated back to Pv4 at a CGN for Pv4 content while
Pv6 is carried natively for UE. This transition model is applicable
for a UE with Pv6 PDP context only and both Pv4 and Pv6
protocol stacks.
NAT64/DNS64 where Pv6 traffic is (port)-translated to Pv4 at a
CGN for Pv4 content while Pv6 is carried natively for UE. This
transition model is applicable for a UE with Pv6 PDP context only
and an Pv6 only protocol stack.
Following table is a relative comparison of Pv6 transition strategies
under consideration at 3GPP.
WirelessE2E LLC October 2010 Page 23 oI 35
www.wirelesse2e.com
whI Popr
IPv
1ransition
method
Support for
applications
UE access UE capabilities Aetwork
capabilities
AP IPv4
applications
need to
accommodate
limited number
oI ports. Special
handling Ior
ICMP is
needed.
IPv4-only is
adequate until
IPv6
applications
become
essential.
Implementing
AP
Iunctionality.
AP PRR
Iunction is
needed in
GGSN or P-
GW. More
public IPv4
addresses are
needed
compared to
legacy port-
translation.
DS-lite IPv4
applications
continue to be
subject to
NAT44
restrictions. No
impact oI IP
address literals.
IPv6-only is
adequate.
Encapsulating
IPv4 traIIic over
IPv6.
Implementing
both IPv4 and
IPv6 protocol
stacks.
NAT44 CGN
and DS-lite
termination
capabilities. No
need Ior private
IPv4 address
space.
IVI IPv4
applications
continue to be
subject to
NAT44
restrictions.
Cannot handle
IP address
literals.
IPv6-only is
adequate.
Implementing
IVI
Iunctionality.
Implementing
both IPv4 and
IPv6 protocol
stacks.
NAT64
(stateless) CGN
capability. No
need Ior private
IPv4 address
space.
Dual stack IPv4
applications
continue to be
subject to
NAT44
restrictions. No
impact oI IP
address literals.
Either IPv4v6
PDP or dual
PDP (one Ior
IPv4 and
another Ior
IPv6)
Implementing
both IPv4 and
IPv6 protocol
stacks.
NAT44 CGN
capability. No
reduction in
private IPv4
address space
usage.
PNAT/BIH IPv4
applications
continue to be
IPv6-only is
adequate.
Implementing
PNAT/BIH
Iunctionality.
NAT64
(stateIul)
capability. No
WirelessE2E LLC October 2010 Page 24 oI 35
www.wirelesse2e.com
whI Popr
IPv
1ransition
method
Support for
applications
UE access UE capabilities Aetwork
capabilities
subject to
NAT44
restrictions.
Cannot handle
IP address
literals.
Implementing
both IPv4 and
IPv6 protocol
stacks.
need Ior private
IPv4 address
space.
NAT64/DNS
64
IPv4
applications
using literals
and some
speciIic apps
will Iail.
IPv6-only is
adequate.
Implementing
IPv6 protocol
stack.
NAT64
(stateIul) and
DNS64
capabilities. No
need Ior private
IPv4 address
space.
Looking at the Pv6 transition methods, few observations can be made:
Double-NAT is a more complex solution compared to single-NAT
from end-to-end perspective. That rules out PNAT and (double) V
methods. Since single V (NAT64 stateless) requires a public Pv4
address assignment for each mobile, it is not a realistic scenario.
A+P reduces the incentive to migrate to Pv6 while requiring a
significant capability upgrade in the UE. That substantial change
as well as special treatment for CMP and fragment handling
restrict the applicability of A+P.
DS-lite provides a benefit of needing only an Pv6 PDP context as
opposed to dual stack approach. Until release 8 upgrades take
place relying on PDP type Pv4v6 is not possible. Other major
benefit of DS-lite is the elimination for the private Pv4 address
space.
WirelessE2E LLC October 2010 Page 25 oI 35
www.wirelesse2e.com
whI Popr
For UE that doesn't have any Pv4 protocol stack, NAT64/DNS64
is the most viable option. t allows rapid transition to Pv6 while
maintaining connectivity to Pv4 content servers via port-
translation.
How are Others Doing Transition?
Mobile operators are not alone in being late for Pv6 transition. Across
the entire communications industry, the level of readiness is quite poor.
As we have demonstrated at the beginning of this paper, Pv6 adoption
among content owners is seriously lacking. SPs that provide nternet
service to large number of customers started sizable trials only in 2010.
Similarly US government along with many other governments and
organizations is quite late in completing meaningful Pv6 transition. Only
recently, a new target of October 1
st
2012 was selected for Federal
Agencies to have an Pv6 web presence. US government's efforts
started much earlier. n February 2006, IPv6 Transition Guidance [35]
was published by Federal CO Council Architecture and nfrastructure
Committee. This document described the inter-agency efforts to
accomplish the target of enabling network backbone Pv6 ready by June
2008. t provides a good blue-print for what needs to be included in a
transition plan, objective and performance indicator setting as well as a
governance structure to accomplish this transition.
After achieving the June 2008 target for Pv6 backbone readiness
demonstration, the Federal CO Council Architecture and nfrastructure
Committee prepared and published another document titled "PIanning
Guide/Roadmap Toward IPv6 Adoption within the US Government
in May 2009 [36]. This document specified aggressive deadlines for Pv6
WirelessE2E LLC October 2010 Page 26 oI 35
www.wirelesse2e.com
More criricol rorqer
[or FeJerol
Aqencies is
Seprember S0, 2014
wnen rneir enrire
inrernol
in[rosrrucrure musr
be upqroJeJ ro
norive IPv6.
whI Popr
adoption and identified 2010 as the deadline for external facing servers
to have Pv6 capability. The recent adoption of the new target date of
October 2012 for the same milestone shows that US government is at
least two years behind its original schedule.
Another useful document on Pv6 transition planning is "A ProfiIe for
IPv6 in the U.S. Government published by National nstitute of
Standards and Technology (NST) in July 2008 [37]. t covers a set of
general requirements that are applicable for all Pv6 nodes, as well as
specific requirements for routers, network protection devices (firewalls,
ntrusion Detection System (DS)/ntrusion Prevention System (PS)) and
hosts. The documents specifies the test cases, and methodology. NST
maintains an Pv6 validation program that uses accredited laboratories to
test and certify equipment complying with the national Pv6 profile.
Another major branch of US government taking a strong interest in Pv6
transition is the Department of Defense (DoD). DoD publishes "DoD IPv6
Standard ProfiIes for IPv6 CapabIe Products yearly. The most recent
version, version 5.0 was published in July 2010 [38]. DoD Pv6 profile
includes compliance requirements for all hosts, network appliances,
servers, routers, switches and information assurance devices (firewalls,
DS/PS, authentication servers, security gateways, Virtual Private
Network (VPN) gateways and encryption devices). Profiles include
mapping between various RFCs and listed equipment classes.
Review of mentioned documents as well as comparable documentation
from other bodies such as European Union, Australia, Canada show that
many countries are behind schedule in their efforts but they also realize
the need to accelerate them rapidly. Common industry target seems to
WirelessE2E LLC October 2010 Page 27 oI 35
www.wirelesse2e.com
As o[ Ocrober 2010,
ICSA Lobs o[
Verizon, Universiry
o[ New Hompsnire
InrerOperobiliry
Lob onJ Cnunq
Hwo Telecom IPv6
Tesrinq Lob
(Toiwon) ore rne
only occreJireJ resr
lobs [or equipmenr
resrinq unJer rne
NIST proqrom.
whI Popr
be 2012 for meaningful/sizable Pv6 adoption to occur.
Preparing MobiIe Operator for IPv6
So far we have reviewed details of Pv6 transition for mobile networks
from the perspective of methods and some of the technology changes in
the UE and the network. Certainly migration towards Pv6 has a much
bigger scope. n this section, we will highlight some of the other aspects
of this transition effort and how mobile operators must prepare
themselves. Transition planning documents prepared by organizations
such US government Federal CO, NST, DoD must be used in parallel
when mobile operators are going through their checklist for Pv6
transition planning.
Mobile operator Pv6 transition plan must be developed through a series
of steps that are relevant to operator's business priorities and objectives.
Following can be considered as a generic set of steps to develop that
transition plan:
1. Identifying business needs and objectives: For some
operators providing Pv6 can be a strategic objective (early
adaptor for differentiation, new machine-to-machine revenue
opportunity, etc.). For others this could be an operational
requirement (cost of NAT equipment, need for increases in
service quality, etc.).
2. Identifying IPv6 enabIed services: Operators must decide what
parts of their services will be Pv6 enabled. So far industry focus
on enabling Pv6 has been UE and relevant customer facing
applications. However, it might be possible to stretch this further
WirelessE2E LLC October 2010 Page 28 oI 35
www.wirelesse2e.com
whI Popr
to include the entire mobile network including core, Radio Access
Network (RAN), relevant transport nodes as well as enterprise
network elements serving customer care, retail, finance, etc.
applications for the operator. Obviously step 1 will determine the
scope and extent of step 2.
3. Identifying technoIogy components: This step will be the
foundational technology strategy development where particular
transition technologies, types of equipment, hardware and
software revisions, topology and configuration changes need to
be decided. We will enumerate this step in further detail below.
4. DeveIoping transition strategy pIan: Federal CO Council
document [36] provides an excellent blueprint for such a transition
document. We encourage our readers to obtain it and analyze it
in its entirety to develop their Pv6 transition plan. Borrowing from
the referenced document, a mobile operator Pv6 transition plan
must include priorities, activities, milestones, criteria for transition,
dependencies, risks/mitigations, interoperability and security
during the transition period, equipment Pv6 requirements, project
governance, training and testing. We can add budgeting,
procurement, field tests, friendly user trials to this list.
5. DeveIoping IPv6 market and enterprise introduction pIan: n
addition to the technology transition plan, mobile operator must
develop a customer (market) introduction and (if necessary) an
enterprise introduction plan. Customer introduction plan must
detail how Pv6 will be introduced to end users. Options include
hiding the Pv6 change from the user (treating it as a technology-
WirelessE2E LLC October 2010 Page 29 oI 35
www.wirelesse2e.com
whI Popr
driven event); promoting it for service differentiation; charging for
a reduced service price for Pv6 for promotion.
Technology components that need to be included in a mobile operator's
Pv6 transition strategy must include the following items:
Packet core changes: Based on the selected transition method,
packet core network nodes must be upgraded. This includes
release 8 support for GPRS nodes (Pv4v6 PDP context), any
new APN settings, related DNS-G changes, validating roaming
partner capabilities that support Pv6, any applicable GPRS
Roaming eXchange (GRX) changes. f NAT needs to be
integrated with GGSN or Long Term Evolution (LTE) P-GW due
to the selected transition method, they have to be defined as part
of the packet core changes.
Core IP network changes: ndependent of the transition
strategy, at least a portion of operator network must support Pv6.
This requires building Pv6 islands, connecting them to each
other via tunnels (such as MPLS 6PE or 6VPE), obtaining
commercial Pv6 SP service for Pv6 nternet connectivity, (if
necessary) establishing Border Gateway Protocol (BGP) peering
with other Pv6 carriers, upgrading/replacing routers, switches,
load balancers, upgrading NAT platforms for selected technology
choice, upgrading information assurance devices (firewalls,
DS/PS equipment, VPN), server platforms such as DNS
infrastructure.
Operator provided customer facing service changes: For
operator's own customer facing services such as web portals,
WirelessE2E LLC October 2010 Page 30 oI 35
www.wirelesse2e.com
whI Popr
content servers, self-help platforms, Multi-media Messaging
System (MMS), etc. a parallel Pv6 strategy must be developed.
Basic options include upgrading applications to a dual stack
environment or relying on translation services from an
intermediate platform such as load balancers. Strategy must also
include how to include new services as opposed to legacy Pv4
based services.
Upgrading other mobiIe network nodes: n order to support
providing customers with Pv6 PDP context, other mobile network
nodes such as Home Location Register (HLR), Policy Control
elements may have to be upgraded or re-configured. Furthermore
operator must decide what to do about MS, e.g., having a
permanent Pv6 PDP context for MS, Pv6 connectivity for MS
roaming, extending MS to nternet based clients using Pv4, etc.
Upgrading business systems/processes: Existing provisioning,
customer care, sales, and usage tracking systems may have
dependencies on the P version. Telia-Sonera's Pv6 trial was
reported to be blocked when problems with provisioning system
was found. Such back-office systems may not have been
designed parametrically and require upgrades beyond
configuration changes.
Integrating new IPv6 capabIe UE: Specification, validation,
approval, deployment, support cycle for new user equipment
must be executed numerous times.
WirelessE2E LLC October 2010 Page 31 oI 35
www.wirelesse2e.com
whI Popr
ConcIusions
Pv6 has been around for 15 years. However, its adoption in the nternet
has been quite limited so far. Primary reason for the lagging adoption is
the lack of economic incentive. Until now, end users or network operators
haven't seen any reason to migrate to Pv6 since Pv4 addresses have
been readily available. However, the situation is about to change. By
2012 the last Pv4 address will be assigned and possibly a new
marketplace will start dictating the rules of scarcity. We believe this
unpredictability will start driving Pv6 adoption quite rapidly in the next 2-
3 years. We are not as optimistic as American Registry for nternet
Numbers (ARN) that was foreseeing to complete majority of migrations
by 2012 [39]. Nevertheless, we expect sizable adoption (15-20% of
global nternet traffic) to occur by 2012. This will create the impetus to
drive even more migrations.
Mobile networks is one of the primary reasons for transition towards
Pv6. With over 4.6B customers, they will be by far the biggest
constituent of Pv6. Even though 3GPP standardization for Pv6 has
started long time ago, so far operational track record is non-existent. We
anticipate this will change with the introduction of LTE when operators,
especially those who are making a technology leap-frog, will grab the
chance to make architectural upgrades such as Pv6 transition. Verizon's
stance on making Pv6 mandatory LTE devices is a good example of this
change.
Mobile network operators must jump-start the Pv6 transition to be ready
for introducing Pv6 UE by 2012 timeframe. This requires them to make a
number of decisions rapidly.
WirelessE2E LLC October 2010 Page 32 oI 35
www.wirelesse2e.com
whI Popr
We recommend the following for the Pv6 transition strategy:
For service/UE introduction in 2011-2012 timeframe, rely on dual
stack while testing and potentially deploying DS-lite solutions.
This will avoid any impacts due to Pv4 only applications or P
address literals in web content.
For service/UE introduction beyond 2012, rely on single Pv6
stack while working with content and application providers to
migrate them to Pv6. This will require deployment of
NAT64/DNS64 solution for Pv4 content.
Develop an Pv6 transition plan that would span 24-36 months.
Start with small but quick wins such as building a test network,
obtaining an Pv6 prefix, choosing and enabling a tunneling
technology in the core P network, etc. in 4-6 months. Aim for a
commercial UE with Pv6 capability in 24 months after project
start.
Limit network changes to essentials. As an example, instead of
a dual-stack strategy for handset web portals (which are
declining in importance for mobile operator), use a load balancer
based translation method to reduce the amount of network and
host changes.
Upgrade packet core network to support release 8 as early as
feasible. This will provide option for Pv4v6 PDP context.
Evangelize change to your roaming partners, back-office,
enterprise system owners so that they start taking action.
WirelessE2E LLC October 2010 Page 33 oI 35
www.wirelesse2e.com
whI Popr
References
|1| RFC-1883, 'Internet Protocol, version 6 (IPv6), December 1995.
|2| RFC-2993, "Architectural Implications oI NAT", November 2000.
|3| http://bgp.he.net/ipv6-progress-report.cgi
|4| http://speedlab01.cmc.co.ndcwest.comcast.net:8088/monitor/
|5| IPv4 Address Report at http://www.potaroo.net/tools/ipv4/
|6| RFC-791, 'Internet Protocol, DARPA Internet Program Protocol
SpeciIication, September 1981.
|7| Vinton CerI, 'How the Internet Came to Be, as it appeared in "The Online
User's Encyclopedia," by Bernard Aboba, Addison-Wesley, November 1993,
ISBN 0-201-62214-9.
|8| RFC-1518, 'An Architecture Ior IP Address Allocation with CIDR,
September 1993.
|9| RFC-4213, 'Basic Transition Mechanisms Ior IPv6 Hosts and Routers,
October 2005.
|10| RFC-2473, 'Generic Packet Tunneling in IPv6 SpeciIication, December
1998.
|11| RFC-2529, 'Transmission oI IPv6 over IPv4 Domains without Explicit
Tunnels, March 1999.
|12| RFC-3056, 'Connection oI IPv6 Domains via IPv4 Clouds, February
2001.
|13| RFC-5969, 'IPv6 Rapid Deployment on IPv4 InIrastructures (6rd)-Protocol
SpeciIication, August 2010.
|14| draIt-ietI-soItwire-dual-stack-lite-06, 'Dual-Stack Lite Broadband
Deployments Following IPv4 Exhaustion, August 2010.
|15| draIt-ietI-soItwire-gateway-init-ds-lite-01, 'Gateway Initiated Dual-Stack
Lite Deployment, October 2010.
|16| RFC-5555, 'Mobile IPv6 Support Ior Dual Stack Hosts and Routers, June
2009.
|17| RFC-4380, 'Teredo: Tunneling IPv6 over UDP through Network Address
Translations (NATs), February 2006.
|18| RFC-5214, 'Intra-Site Automatic Tunnel Addressing Protocol (ISATAP),
March 2008.
|19| RFC-4798, 'Connecting IPv6 Islands over IPv4 MPLS Using IPv6
Provider Edge Routers (6PE), February 2007.
|20| RFC-2765, 'Stateless IP/ICMP Translation Algorithm (SIIT), February
2000.
|21| RFC-2767, 'Dual Stack Hosts using the "Bump-In-the-Stack" Technique
(BIS), February 2000.
|22| RFC-2766, 'Network Address Translation - Protocol Translation (NAT-
PT), February 2000.
WirelessE2E LLC October 2010 Page 34 oI 35
www.wirelesse2e.com
whI Popr
|23| RFC-3338, 'Dual Stack Hosts Using "Bump-in-the-API" (BIA), October
2002.
|24| RFC-4215, 'Analysis on IPv6 Transition in Third Generation Partnership
Project (3GPP) Networks, October 2005.
|25| RFC-4966, 'Reasons to Move the Network Address Translator - Protocol
Translator (NAT-PT) to Historic Status, July 2007.
|26| draIt-ietI-behave-v6v4-xlate-stateIul-12, 'StateIul NAT64: Network
Address and Protocol Translation Irom IPv6 Clients to IPv4 Servers, July 2010.
|27| draIt-ietI-behave-dns64-11, 'DNS64: DNS extensions Ior Network Address
Translation Irom IPv6 Clients to IPv4 Servers, October 2010.
|28| draIt-ietI-behave-v6v4-Iramework-10, 'Framework Ior IPv4/IPv6
Translation, August 2010.
|29| Jari Arkko, 'Experiences Irom an IPv6-Only World at Ericsson, Google
IPv6 Implementors ConIerence, June 10-11, 2010.
|30| draIt-ietI-behave-v4v6-bih-01, 'Dual Stack Hosts Using "Bump-in-the-
Host" (BIH), October 2010.
|31| draIt-ietI-behave-v6v4-xlate-23, 'IP/ICMP Translation Algorithm,
September 2010.
|32| RFC-3574, 'Transition Scenarios Ior 3GPP Networks, August 2003.
|33| 3GPP TR 23.975: 'IPv6 Migration Guidelines, v 1.1.1, May 2010.
|34| draIt-ymbk-aplusp-06, 'The AP Approach to the IPv4 Address Shortage,
October 2010.
|35| Federal CIO Council Architecture and InIrastructure Committee, 'IPv6
Transition Guidance, February 2006.
|36| Federal CIO Council Architecture and InIrastructure Committee, 'Planning
Guide/Roadmap Toward IPv6 Adoption within the US Government, May 2009.
|37| National Institute oI Standards and Technology (NIST) special publication
500-267, 'A ProIile Ior IPv6 in the U.S. Government-Version 1.0, July 2008.
|38| DoD InIormation Technology (IT) Standards Registry (DISR), 'DoD IPv6
Standard ProIiles Ior IPv6 Capable Products Version 5.0, July 2010.
|39| RFC-5211, 'An Internet Transition Plan, July 2008.
|40| RFC-4659, 'BGP-MPLS IP Virtual Private Network (VPN) Extension Ior
IPv6 VPN, September 2006.
|41| RFC-5902, 'IAB Thoughts on IPv6 Network Address Translation, July
2010.
WirelessE2E LLC October 2010 Page 35 oI 35
www.wirelesse2e.com