Drivers for IPv6 deployment - pool of network addresses near ...

yummypineappleΛογισμικό & κατασκευή λογ/κού

30 Ιουν 2012 (πριν από 4 χρόνια και 9 μήνες)

243 εμφανίσεις


ericsson white paper
284 23-3151 Uen | January 2011
Drivers for IPv6

deployment – pool of
network addresses
near exhaustion
The internet, the number of internet users, the
volume of mobile devices, and the number of
constantly connected devices have been growing at
a tremendous rate, a trend which is set to continue
far beyond the original growth expectations for
which the network is designed.

Drivers for iPv6 DePloymenT

emPTy Pool of neTwork aDDresses
The continued adoption of mobile broadband and increase in the number of internet users, as well
as the amount of devices per user, are hastening the exhaustion of internet Protocol version 4 (iPv4)
addresses. version 6 (iPv6) was designed by the internet engineering Task force (ieTf) to use a much
larger address space (2^128 addresses), in addition to providing other benefits. These benefits include
simpler packet forwarding in routers, increased security and auto-configuration. The financial and
business impact of address exhaustion will affect telecom operators and service providers.
The current version of the internet protocol (iPv4) is based on 32-bit addresses that allow unique
identification for a maximum of 4 billion nodes. Based on current projections, the internet assigned
numbers authority (iana) free pool of network addresses will be exhausted very soon, perhaps in
the first half of 2011. The absence of available iPv4 addresses will prevent subscriber growth and will
become a threat to business continuity. in short, migration to iPv6 is vital.
pool of network
addresses near
Drivers for iPv6 DePloymenT

Drivers for DePloymenT
Business growth
if we run out of unique iP addresses, new customers can no longer be added to the network. To continue
growing and adding new customers, more addresses are needed. The adoption of iPv6, with its support for
2^128 addresses, will ensure that businesses can continue to grow without facing address shortages.
Lower capitaL expenditure
To add new customers without additional iP addresses, operators need to resort to drastic address-sharing
measures, such as Carrier Grade network address translation (naT), or CGn. operators need to acquire
new network nodes or upgrade their current nodes to support this functionality, resulting in higher capital
expenditure and higher operational expenditure due to the complexity of handling these nodes, as well as
associated legal interception requirements that need to be met.
Lower operationaL expenditure
as we run out of iPv4 addresses, the cost of acquiring new ones will rise drastically. adding additional
subscribers will result in substantially increased operational costs. Deploying iPv6 will keep address-
acquisition costs low and avoid running and management costs associated with the additional nodes/
functions required to support iPv4-address sharing.
government reguLations
The governments of several countries have started to encourage the deployment of iPv6 and seem to be
following a multi-pronged strategy:
• Incentivizing the deployment of IPv6
• Drafting laws to ensure IPv6 availability
• Making IPv6 mandatory for government service providers.
as a result of the incentives, operators may find that supporting iPv6 is profitable. Conversely, not
supporting iPv6 may be costly due to possible penalties and loss of business. in spite of these efforts, the
progress of government-driven iPv6 deployment has been relatively slow.
government initiatives around the worLd
on June 13, 2003, the Us Department of Defense issued a press release stating it was mandating that
vendors providing iP services or hardware for any project starting after october 2003 support iPv6. on
august 2, 2006, the office of management and Budget issued a memorandum calling for all Us federal
Government agencies to plan for iPv6 transition, with all agencies instructed to support iPv6 on their
backbone networks by June 30, 2008.
in a communication dated may 27, 2008, the european Commission urged the european Parliament to
act quickly in order to speed up iPv6 deployment. The Commission said europe should set itself the objective
to widely implement iPv6 by 2010. it set a concrete goal that at least 25 percent of users should be able
to connect to the iPv6 internet and to access their most important content and service providers without
noticing a major difference compared with iPv4.
The China next Generation internet project is a five-year plan initiated by the government with the
purpose of gaining a significant position in the future development of the internet through the early adoption
of iPv6. China showcased its iPv6 infrastructure at the 2008 summer olympic Games in Beijing, where all
network operations were conducted using the new protocol. This event was reported at the time to be the
largest iPv6 showcase since the development of the protocol.


Drivers for iPv6 DePloymenT

Drivers for DePloymenT
Japan: the Japanese government was one of the first to have a policy on deploying iPv6. The protocol is an
integral part of the e-Japan strategy outlined by the country’s prime minister in 2000, and is also part of the
u-Japan strategy that aims to develop a ubiquitous network society.
new Business streams
The migration to iPv6 allows operators to expand into a potentially large base of connected devices that
will use the protocol exclusively, especially in iPv4-address-starved regions such as asia. Due to its end-
to-end reachability, iPv6 will also enable applications whose users are not just consumers, but also content
some applications, such as networked sensors, require iPv6 due to the sheer number of nodes. These
applications will provide new revenue streams for operators.
roaming reLationships
operators who have transitioned their networks to iPv6 may be reluctant to enter into business relationships
with other operators who rely on IPv4 only, as doing so would necessitate the use of specialized infrastructure.
such a business relationship would also require iPv4 addresses to be allocated to roaming users, and such
addresses may not be available.
Drivers for iPv6 DePloymenT

PhaseD aPProaCh To iPTv miGraTion
a phased approach to iPv6 migration is recommended, in which some aspects of the networks are migrated
to the new protocol before others. Each aspect can be individually deployed and tested to minimize disruption.
an example plan for iPv6 migration is provided in the appendix.
ipv6 user connectivity
as providing iPv6 connectivity to the user is the most important and most visible aspect of migration, it makes
sense to perform this step first. at the end of this phase, the network may not be fully migrated. one of the
mechanisms described below may be used to tunnel iPv6 traffic over the iPv4-only parts of the network.
ipv6-enaBLed operator services
after providing iPv6 connectivity to the user, the operator can migrate operator-provided services such as
ims and operator-provided content. This will result in a significant amount of traffic moving to iPv6 and will
reduce the demand for iPv4 addresses. This will also allow the deployment of iPv6-only terminals that can
access a limited set of services. operators could also use iPv4-to-iPv6 application layer gateways and
protocol converters to ease this phase of migration.
ipv6-enaBLed transport network
The next phase is to migrate the transport network. The main goal of this phase is to provide native dual
stack connectivity to avoid the tunneling overhead on the transport network and the processing overhead
at the tunnel end points.
ipv6-enaBLed o&m
The final phase migrates operations and management (o&m) systems. some aspects of o&m – such as
billing systems, legal interception systems and provisioning systems – need to be migrated early into iPv6,
but most other aspects can move over to iPv6 in a gradual way.
compLeting the transition
at the end of the migration process, the network is ready to complete the transition to iPv6. The final step
in the transition is the gradual termination of widely available iPv4 connectivity. This phase will take several
years to achieve as a significant amount of content may be iPv4-only for years to come.
Phased approach
to IPv6 migration

Drivers for iPv6 DePloymenT

imPaCTs of TransiTion
while investigating the transition to iPv6 the impact of deploying iPv6 on the various parts of the
operator’s network have to be studied. iPv6 can be deployed incrementally on particular aspects of
the network before others. for example, o&m and user traffic can be transitioned to iPv6 at different
times. The transition plan for one organization may differ significantly from that of another, as it depends
heavily on the organization’s goals.
impact on access networks
access networks that provide a pure layer-2 service are not affected by iPv6 transition. This is true
for both fixed and cellular radio access networks (rans). some nodes in the access network – such
as Digital subscriber line access multiplexers (Dslams), which manage a specific subset of layer-3
packets for enabling functions such as anti-spoofing and multicast – need to be updated to support
iPv6. Depending on the network security setup, iPv6 access control list (aCl) support may be needed
in some layer-2 access network nodes.
impact on transport networks
iPv6 is not expected to have any impact on transport networks operating below layer 3. These networks
are expected to be agnostic to the protocol that is being carried over the transport network. This
means that iPv6 can be provided to the user even if the underlying transport networks are not iPv6-
impact on moBiLe core networks
nodes in the mobile core networks will be impacted substantially by the transition to iPv6. even though
all ericsson mobile core network nodes support iPv6, other nodes that do not support iPv6 may
exist in the network – such as site routers, firewalls and layer-3 switches – that need to be updated
to support dual stack. a subset of these nodes needs to include support for iPv6 controls such as
neighbor Discovery Protocol (nDP) and Dynamic host Configuration Protocol version 6 (DChPv6), so
that iPv6-enabled terminals can successfully connect to the network.
impact on ims
ims-signaling protocols must run over iPv6 and hence ims nodes handling these messages need to
be iPv6-enabled. additionally, these nodes need to provide session descriptors, describing the iPv6
and iPv4 nodes. all session initiation Protocol (siP) signaling to or from an ims user agent or terminal
is always proxied by the ims network border element Proxy Call session Control function (P-CsCf),
to which the siP agent or terminal sends its siP reGisTer message. The P-CsCf will then, on a
per-call basis, convey information to the end-user terminal about which iP address port combination
call-associated media flow should be sent.
The P-CsCf siP proxy needs to support dual stack to handle siP-signaling to and from terminals
using either iPv4 or iPv6. it also needs to be able to forward received siP messages, from terminals
as well as from nodes in the ims network. it has to be able to do this using either the iP version the
message arrived on, or another iP version, depending on the version supported by the next hop siP
entity the message is forwarded to (either a user terminal or siP node in the ims core network). no
iP-version translation is required, since the P-CsCf proxies siP messages on the siP-application
level and the next-hop transport used can be completely decoupled from the transport on which the
siP message was received.
in order to handle cases where siP end points, using different iP-versions, wish to send media
to each other, the P-CsCf needs to include siP application layer Gateway (alG) functionality that
decides whether address and port translation is required on the media level between iPv6 and iPv4.
if so, it controls a media proxy to allocate an address to translate the media flow. The alG function
then rewrites the address and port information in the corresponding session description in the

Impacts of
Drivers for iPv6 DePloymenT

imPaCTs of TransiTion
siP-signaling messages, so that the respective endpoint will send the media to the respective iPv4 and iPv6
addresses and ports that have been allocated on the media proxy for the flow.
impact on o&m
all o&m systems need to be updated to support iPv6 nodes, including configuration, fault management
and charging systems. in addition, legal interception systems need to be aware of the relationship between
subscribers and iPv6 addresses.
impact on terminaLs
The iP stacks on the terminals need to be updated to support iPv6. Traditional address-acquisition methods
(such as DhCP) have been extended to support iPv6 addresses and this extension needs to be implemented
on the terminal. new address-acquisition methods such as stateless address auto-configuration (slaaC)
also need to be supported. This also affects mobile broadband modules and sensors used in machine-to-
machine (m2m) applications.
impact on appLications
applications running on terminals need to be iP-version agnostic. several terminals include abstraction
layers – software development kits (sDks) – that insulate applications from participating in the lower layers
of the iP stack. hence, for well-written applications, this transition will be fairly smooth. however, since the
terminal will have several addresses, multiple iPv6 and at least one iPv4, proper address selection might
be difficult.

Drivers for iPv6 DePloymenT

TransiTion aPProaChes To iPv6
The transition to iPv6 is expected to be a gradual and phased process that will take several years.
several techniques can aid in the transition and can be classified into three major categories:
• Dual stack
• Tunneling
• Translation.
duaL stack
Dual stack is a transition mechanism that requires each user device to have a network stack that
supports iPv4 and iPv6 and to have assigned addresses for both protocols. for nodes in the network,
dual stacking the network infrastructure should be the chosen method for transitioning to iPv6. almost
all network nodes available today support iPv6. a pre-requisite for this approach is that the network
owner must have a sufficient pool of addresses to sustain the iPv4 traffic initiated by end nodes.
Dual stack is the recommended
transition mechanism for the vast
majority of networks. it has been widely
deployed, is well understood and does
not entail the addition of new network
nodes for transition or single points
of failure. The dual-stack transition
mechanism by itself cannot prevent the
exhaustion of iPv4 addresses. however,
there are several techniques that can be
used in conjunction with dual stack that
can support the preservation of iPv4
addresses. for example:
• Dual stack can be run with private IPv4 addresses that are translated on a network-based
naT node. iPv4 connectivity is degraded due to the presence of naT. iPv6 connectivity, on
the other hand, is not affected.
• Dual stack can be run with deferred IPv4 address allocation. Initially, the user device is only
allocated an iPv6 address. when an application on the device requires iPv4 connectivity, an
iPv4 address is allocated on demand.
native dual-stack connectivity avoids maximum transmission unit (mTU) problems associated
with tunneling mechanisms and does not need alGs. This results in dual-stack networks being more
robust and reliable.
tunneLing mechanisms
Tunneling mechanisms work by encapsulating one version of iP (the payload version) into another (the
transport version) to traverse a network that does not “understand” the payload iP version. Tunneling
mechanisms can provide both iPv6 access over iPv4 networks and iPv4 access over iPv6 networks.
The former is more common today, but the latter will become more popular as iPv6 becomes more
widely deployed.

to IPv6
IPv4 and IPv6
figure 1: Dual stack
Drivers for iPv6 DePloymenT

TransiTion aPProaChes To iPv6
tunneLing ipv6 over ipv4
This tunneling mechanism helps
when communicating peers are
iPv6-enabled but transit networks
have not yet transitioned to iPv6.
Commonly used mechanisms are
6to4, Teredo, intra-site automatic
Tunnel addressing Protocol (isaTaP)
and 6rd.

tunneLing ipv4 over ipv6
This tunneling mechanism is useful
when a network has transitioned
to iPv6 but still needs to provide
services to iPv4-only subscribers.
The most popular mechanisms in
this category are Dual stack lite (Ds-
lite) and iPv4-over-iPv6 softwires
with layer Two Tunneling Protocol
version 2 (l2TPv2). some solutions
in this category, such as Ds-lite, aid
iPv4 address preservation by reusing
iPv4 addresses across multiple iPv6
tunnel endpoints and using a CGn to
share one public iP address among
multiple subscribers.
end point
IPv4 only
IPv4 and IPv6
end point
figure 2: Tunneling iPv6 over iPv4
This tunneling mechanism may be used to rapidly deploy iPv6 user service even when
the core networks have not been upgraded. 6to4 is an internet-transition mechanism
for migrating from iPv4 to iPv6. Teredo is a platform-independent tunneling protocol
developed by microsoft. isaTaP is an iPv6-transition mechanism meant to transmit iPv6
packets between dual-stack nodes on top of an iPv4 network. 6rd is a mechanism to
facilitate iPv6 rapid deployment across iPv4 infrastructures of internet service providers
end point
IPv6 only
IPv4 and IPv6
end point
figure 3: Tunneling iPv4 over iPv6
This mechanism can be used to provide dual stack connectivity over iPv6-only access
networks. They can also be used in cases where iPv4 addresses are in short supply
and are being shared through the use of a network address translator (naT) inside the
operator’s network – in other words, a CGn. The iPv4 packets between the CGn and
user equipment (Ue) are tunneled over iPv6 in order to provide traffic separation.

Drivers for iPv6 DePloymenT

TransiTion aPProaChes To iPv6
tunneLing ipv6 over muLti-
protocoL LaBeL switching
(mpLs) networks
This tunneling mechanism can help
to interconnect iPv6 islands over an
mPls-enabled iPv4 network cloud.
one such approach relies on iPv6
Provider edge (6Pe) routers, which
are dual-stack in order to connect
to the iPv6 islands and the mPls
transLation mechanisms
Translation mechanisms work by deploying an interworking function at the edge of the network
between the iPv4 and iPv6 networks. Translation mechanisms can be implemented in the application
layer (proxies) or in the network layer. Translation mechanisms work by intercepting packets sent
with one version of iP and converting the packets into the other version of iP. naT64 is a packet-
translation mechanism currently under development that will probably be widely used for iPv6-only
network deployments. naT64 works in conjunction with another closely associated mechanism called
why is ipv6 Better than cgn?
CGn can be used as an intermediate step to extend the life of the available iPv4 addresses and delay
the transition to iPv6. This will only work in the short term, due to the increasing number of ports
being used by applications. CGns also require significant investment in the form of the development
of alGs for popular applications to pass through. They do not provide a graceful exit strategy and will
hence be difficult to remove. one strategy would be to use CGns in conjunction with iPv6 to enable
the provider to move to dual stack even with a lack of iPv4 addresses. in this case, the use of the CGn
continually decreases in line with the availability of iPv6 content and peers. The CGn can eventually
be removed once the operator deems that iPv4 traffic falls below a set level.
why is duaL stack Better?
native dual-stack connectivity avoids mTU problems associated with tunneling mechanisms and does
not need alGs that are required by translation mechanisms. This results in dual-stack networks being
more robust and reliable.
even though translation mechanisms are not the best possible solution, they may be necessary due
to iPv4 address exhaustion before widespread iPv6 deployment. Translation mechanisms may cause
issues with applications that embed iP addresses in their payloads – such as fTP, BitTorrent, siP and
real Time streaming Protocol (rTsP). To resolve these issues, the translation mechanism needs to
implement an alG for each such application.
IPv6 only IPv4 only
figure 4: Tunneling iPv6 over mPls networks
This tunneling mechanism helps when transport networks are already mPls-enabled
and the edge routers can be easily modified to support iPv6 and the required Border
Gateway Protocol (BGP) changes.
Drivers for iPv6 DePloymenT
immediate deployment of iPv6 is recommended, starting with the evaluation of the impact of deploying
the protocol. The move to iPv6 will be gradual, and co-existence with iPv4 will be necessary. The
primary means to transition to iPv6 from iPv4 is the dual-stack transition mechanism. The introduction
of IPv6 will enable several new business streams that utilize the resulting end-to-end addressing and
reach of the terminals. iPv6 will reduce costs for acquiring address space since iPv6 addresses are
far more abundant than iPv4 addresses. it will also lead to simpler network nodes because there will
be no need for CGns, and hence lower capital expenditure.

Drivers for iPv6 DePloymenT

checkList for migration to ipv6
identification of strategic business objectives – roi
identification of transition priorities
identification of transition activities
Transition milestones
Transition criteria for legacy, upgraded and new capabilities
means for adjudicating claims that an asset should not transition in prescribed timeframes
Technical strategy and selection of transition mechanisms to support iPv4/iPv6 interoperability
management and assignment of resources for transition
maintenance of interoperability and security during transition
Use of iPv6 standards and products
support for iPv4 infrastructure during and after iPv6 network backbone deployment
application migration (if required to support backbone transition)
Costs not covered by technology refresh
Transition governance
roles and responsibilities
management structure
Performance measurement
acquisition and procurement
Drivers for iPv6 DePloymenT
iPv6 Provider edge
access control list
application layer Gateway
Border Gateway Protocol
peer-to-peer communications protocol for file sharing
Carrier Grade naT
dchpv6 dynamic host configuration protocol version 6
Digital subscriber line access multiplexer
Dual stack lite
file Transfer Protocol
internet assigned numbers authority
internet engineering Task force
iP multimedia subsystem
internet Protocol version 4
internet Protocol version 6
intra-site automatic Tunnel addressing Protocol
isp internet service provider
layer Two Tunneling Protocol version 2
multiprotocol label switching
mtu maximum transmission unit
network address translation
neighbor Discovery Protocol
operations and management
Proxy Call session Control function
radio access network
real Time streaming Protocol
software development kit
session initiation Protocol
stateless address auto-configuration
user equipment