draft-ietf-v6ops-v6-in-mobile-networks-00.txt   draft-ietf-v6ops-v6-in-mobile-networks-01.txt 
v6ops Working Group Rajeev Koodli v6ops Working Group Rajeev. Koodli
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Informational April 17, 2010 Intended status: Informational July 12, 2010
Expires: October 19, 2010 Expires: January 13, 2011
Mobile Networks Considerations for IPv6 Deployment Mobile Networks Considerations for IPv6 Deployment
draft-ietf-v6ops-v6-in-mobile-networks-00.txt draft-ietf-v6ops-v6-in-mobile-networks-01.txt
Abstract Abstract
Mobile Internet access from smartphones and other mobile devices is Mobile Internet access from smartphones and other mobile devices is
accelerating the exhaustion of IPv4 addresses. IPv6 is widely seen accelerating the exhaustion of IPv4 addresses. IPv6 is widely seen
as crucial for the continued operation and growth of the Internet, as crucial for the continued operation and growth of the Internet,
and in particular, it is critical in mobile networks. This document and in particular, it is critical in mobile networks. This document
discusses the issues that arise when deploying IPv6 in mobile discusses the issues that arise when deploying IPv6 in mobile
networks. Hence, this document can be a useful reference for service networks. Hence, this document can be a useful reference for service
providers and network designers. providers and network designers.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 19, 2010. This Internet-Draft will expire on January 13, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 19 skipping to change at page 2, line 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Reference Architecture and Terminology . . . . . . . . . . . . 3 2. Reference Architecture and Terminology . . . . . . . . . . . . 3
3. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . 5 3. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . 5
3.1. IPv4 Address Exhaustion . . . . . . . . . . . . . . . . . 5 3.1. IPv4 Address Exhaustion . . . . . . . . . . . . . . . . . 5
3.2. NAT Placement in the mobile networks . . . . . . . . . . . 7 3.2. NAT Placement in the mobile networks . . . . . . . . . . . 7
3.3. IPv6-only Deployment Considerations . . . . . . . . . . . 9 3.3. IPv6-only Deployment Considerations . . . . . . . . . . . 9
3.4. Fixed - Mobile Convergence . . . . . . . . . . . . . . . . 12 3.4. Fixed - Mobile Convergence . . . . . . . . . . . . . . . . 12
4. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 13 4. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14
7. Informative References . . . . . . . . . . . . . . . . . . . . 14 7. Informative References . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
The dramatic growth of the Mobile Internet is accelerating the The dramatic growth of the Mobile Internet is accelerating the
exhaustion of available IPv4 addressing pool. It is widely accepted exhaustion of available IPv4 addressing pool. It is widely accepted
that IPv6 is necessary for the continued operation, and growth of the that IPv6 is necessary for the continued operation, and growth of the
Internet in general, and that of the Mobile Internet in particular. Internet in general, and that of the Mobile Internet in particular.
When deploying IPv6 in mobile networks, certain unique challenges When deploying IPv6 in mobile networks, certain unique challenges
arise. This document describes such challenges, and outlines the arise. This document describes such challenges, and outlines the
applicability of the existing IPv6 deployment solutions. As such, it applicability of the existing IPv6 deployment solutions. As such, it
skipping to change at page 6, line 22 skipping to change at page 6, line 22
In a mobile network, the IPv4 address assignment for a MN is In a mobile network, the IPv4 address assignment for a MN is
performed by the MNG. In the 3GPP network architecture, this performed by the MNG. In the 3GPP network architecture, this
assignment is performed in conjunction with the PDN connectivity assignment is performed in conjunction with the PDN connectivity
establishment. As mentioned earlier, a PDN can be understood to be establishment. As mentioned earlier, a PDN can be understood to be
the end-end link from the MN to the MNG. There can be one or more the end-end link from the MN to the MNG. There can be one or more
PDN connections active at any given time for each MN. A PDN PDN connections active at any given time for each MN. A PDN
connection may support both IPv4 and IPv6 traffic (as in a dual-stack connection may support both IPv4 and IPv6 traffic (as in a dual-stack
PDN in 4G LTE networks) or it may support either one only (as in the PDN in 4G LTE networks) or it may support either one only (as in the
existing 3G UMTS networks). The IPv4 address is assigned at the time existing 3G UMTS networks). The IPv4 address is assigned at the time
of PDN connectivity establishment, or is assigned using the DHCP of PDN connectivity establishment, or is assigned using the DHCP
protocol after the PDN connectivity is established. This IP address protocol after the PDN connectivity is established. In order to
needs to be a private IPv4 address which is translated into a shared delay the exhaustion of public IPv4 addresses, this IP address needs
public IPv4 address in order to delay the exhaustion of public IPv4 to be a private IPv4 address which is translated into a shared public
addresses as IPv6 is being deployed. Hence, there is a need for IPv4 address. Hence, there is a need for private - public IPv4
private - public IPv4 translation mechanism in the mobile network. translation mechanism in the mobile network.
In the Long-Term Evolution (LTE) 4G network, there is a requirement In the Long-Term Evolution (LTE) 4G network, there is a requirement
for an always-on PDN connection in order to reliably reach a mobile for an always-on PDN connection in order to reliably reach a mobile
user in the All-IP network. If this PDN connection were to use IPv4 user in the All-IP network. If this PDN connection were to use IPv4
addressing, a private IPv4 address is needed for every MN that addressing, a private IPv4 address is needed for every MN that
attaches to the network. This could significantly affect the attaches to the network. This could significantly affect the
availability and usage of private IPv4 addresses. Alternatively, the availability and usage of private IPv4 addresses. An approach to
always-on PDN connection may be assigned with an IPv6 prefix address this problem is to make the always-on PDN to be IPv6, and
(typically a /64) at the time of connection establishment, and an enable IPv4 PDN on-demand, e.g., when an application binds to an IPv4
IPv4 address is assigned only on-demand (e.g., when an application socket interface. This ensures that an IPv4 address is not assigned
binds to an IPv4 socket interface). This is feasible on the same for every attached MN, but only to those attempting to use the
(dual-stack) PDN in LTE networks (with short DHCP lease times), or traffic. The IPv4 PDN may be subject to session idle timers upon the
with on-demand IPv4 PDNs. On-demand IPv4 PDN and address management expiry of which, the PDN (and the assigned IPv4 address) may be
can be effective in conserving IPv4 addresses; however, such a deleted. Another approach is to defer the allocation of IPv4 address
management could have some implications to how the PDN and addresses on a dual-stack IPv4v6 PDN at the time of connection establishment.
are managed at the MN. This has the advantage of a single PDN for IPv6 and IPv4, along with
deferring IPv4 address allocation until an application needs it.
However, this requires support for a dynamic configuration protocol
such as DHCP, which many cellular MNs do not support today; this may
very well change in the future releases. Besides, laptops using the
network interface cards (such as USB dongles) to connect to the
cellular network typically support the DHCP protocol. In any case,
there need to be appropriate triggers to initiate DHCP based on
application usage, as well as DHCP lease management based on
appropriate address management policies. Both the approaches have
merits, and additional considerations, including the "keep alives"
that MNs may potentially send to keep their IPv4 addresses active.
On the other hand, in the existing 3G UMTS networks, there is no On the other hand, in the existing 3G UMTS networks, there is no
requirement for an always-on connection (a 'link' from the MN to the requirement for an always-on connection (a 'link' from the MN to the
MNG in 3G UMTS is referred to as a Packet Data Protocol (PDP) MNG in 3G UMTS is referred to as a Packet Data Protocol (PDP)
context/connection) even though many SmartPhones seldom relinquish an context/connection) even though many SmartPhones seldom relinquish an
established PDP context. And, the existing (so-called pre-Release-8) established PDP context. And, the existing (so-called pre-Release-8)
deployments do not support the dual-stack PDP connection. Hence two deployments do not support the dual-stack PDP connection. Hence two
separate PDP connections are necessary to support IPv4 and IPv6 separate PDP connections are necessary to support IPv4 and IPv6
traffic. Even though some MNs (especially the SmartPhones) in use traffic. Even though some MNs (especially the SmartPhones) in use
today may have IPv6 stack, such a capability is not tested (if any at today may have IPv6 stack, such a capability is not tested (if any at
skipping to change at page 7, line 18 skipping to change at page 7, line 29
the (predominantly IPv4) Internet. the (predominantly IPv4) Internet.
The considerations from the preceeding paragraphs lead to the The considerations from the preceeding paragraphs lead to the
following observations. First, there is a need to support private following observations. First, there is a need to support private
IPv4 addressing in mobile networks in order to address the public IPv4 addressing in mobile networks in order to address the public
IPv4 run-out problem. This means there is a need for private - IPv4 run-out problem. This means there is a need for private -
public IPv4 translation in the mobile network. Second, there is public IPv4 translation in the mobile network. Second, there is
support for IPv6 in both 3G and 4G LTE networks already in the form support for IPv6 in both 3G and 4G LTE networks already in the form
of PDP context and PDN connections. Operators can introduce IPv6 in of PDP context and PDN connections. Operators can introduce IPv6 in
their networks, perhaps to access operator's own applications and their networks, perhaps to access operator's own applications and
services to begin with. In other words, the IETF's dual-stack model services to begin with. In other words, the IETF's recommended model
of separate IPv6 and IPv4 networks is readily applicable to mobile of dual-stack IPv6 and IPv4 networks is readily applicable to mobile
networks with the support for distinct APNs and the ability to carry networks with the support for distinct APNs and the ability to carry
IPv6 traffic on PDP/PDN connections. Finally, operators can make IPv6 traffic on PDP/PDN connections. Finally, operators can make
IPv6 as the default for always-on mobile connections, and use IPv4 IPv6 as the default for always-on mobile connections, and investigate
(private) addressing only on-demand. on-demand PDN and (private) address assignment for IPv4.
3.2. NAT Placement in the mobile networks 3.2. NAT Placement in the mobile networks
In the previous section, we observed that the NAT44 functionality is In the previous section, we observed that the NAT44 functionality is
needed in order to conserve the available pool, and delay public IPv4 needed in order to conserve the available pool, and delay public IPv4
address exhaustion. However, the available private IPv4 pool itself address exhaustion. However, the available private IPv4 pool itself
is not abundant for large networks such as mobile networks. For is not abundant for large networks such as mobile networks. For
instance, the so-called NET10 block [RFC1918] has approximately 16.7 instance, the so-called NET10 block [RFC1918] has approximately 16.7
million private IPv4 addresses starting with 10.0.0.0. A large million private IPv4 addresses starting with 10.0.0.0. A large
mobile service provider network can easily have more than 16.7 mobile service provider network can easily have more than 16.7
skipping to change at page 7, line 41 skipping to change at page 8, line 4
instance, the so-called NET10 block [RFC1918] has approximately 16.7 instance, the so-called NET10 block [RFC1918] has approximately 16.7
million private IPv4 addresses starting with 10.0.0.0. A large million private IPv4 addresses starting with 10.0.0.0. A large
mobile service provider network can easily have more than 16.7 mobile service provider network can easily have more than 16.7
million subscribers attached to the network at a given time. Hence, million subscribers attached to the network at a given time. Hence,
the private IPv4 address pool management and the placement of NAT44 the private IPv4 address pool management and the placement of NAT44
functionality becomes important. functionality becomes important.
In addition to the developments cited above, NAT placement is In addition to the developments cited above, NAT placement is
important for other reasons. Access networks generally need to important for other reasons. Access networks generally need to
produce network and service usage records for billing and accounting. produce network and service usage records for billing and accounting.
This is true for mobile networks as well where "subscriber This is true for mobile networks as well where "subscriber
management" features (i.e., QoS, Policy, and Billing and Accounting) management" features (i.e., QoS, Policy, and Billing and Accounting)
can be fairly detailed. Since a NAT introduces a binding between two can be fairly detailed. Since a NAT introduces a binding between two
addresses, the bindings themselves become necessary information for addresses, the bindings themselves become necessary information for
subscriber management. For instance, the offered QoS on private IPv4 subscriber management. For instance, the offered QoS on private IPv4
address and the (shared) public IPv4 address may need to be address and the (shared) public IPv4 address may need to be
correlated. And, the subscriber session management information and correlated. And, the subscriber session management information and
the service usage information also need to be correlated in order to the service usage information also need to be correlated in order to
produce harmonized records. Furthermore, there may be legal produce harmonized records. Furthermore, there may be legal
requirements to store the NAT binding records. Indeed, these requirements for storing the NAT binding records. Indeed, these
problems disappear with the transition to IPv6. For now, it suffices problems disappear with the transition to IPv6. For now, it suffices
to state that NAT introduces state which needs to be correlated and to state that NAT introduces state which needs to be correlated and
possibly stored with other routine subscriber information. possibly stored with other routine subscriber information.
Mobile network deployments vary in their allocation of IP address Mobile network deployments vary in their allocation of IP address
pools. Some network deployments use the "centralized model" where pools. Some network deployments use the "centralized model" where
the pool is managed by a common node, such as the PDN's Border the pool is managed by a common node, such as the PDN's Border
Router, and the pool shared by multiple gateways all attached to the Router, and the pool shared by multiple gateways all attached to the
same BR. This model has served well in the pre-3G deployments where same BR. This model has served well in the pre-3G deployments where
the number of subscribers accessing the mobile Internet at any given the number of subscribers accessing the mobile Internet at any given
skipping to change at page 8, line 33 skipping to change at page 8, line 45
gateways. In other words, the IP addresses used by two or more MNs gateways. In other words, the IP addresses used by two or more MNs
(which may be attached to the same MNG) are very likely to overlap at (which may be attached to the same MNG) are very likely to overlap at
the centralized NAT, which needs to be able to differentiate traffic. the centralized NAT, which needs to be able to differentiate traffic.
The approach specified in [gi-ds-lite] is one way to achieve traffic The approach specified in [gi-ds-lite] is one way to achieve traffic
separation for overlapping private IPv4; the others include MPLS VPN separation for overlapping private IPv4; the others include MPLS VPN
tunnels or any tunneling mechanism with a unique identifier for the tunnels or any tunneling mechanism with a unique identifier for the
session. An obvious advantage of centralizing the NAT and using session. An obvious advantage of centralizing the NAT and using
overlapped private IPv4 addressing is that a large number of mobile overlapped private IPv4 addressing is that a large number of mobile
subscribers can be supported with a common limited pool at the BR. subscribers can be supported with a common limited pool at the BR.
It also enables the operator's enterprise network to use IPv6 from It also enables the operator's enterprise network to use IPv6 from
the MNG to the BR. The disadvantages include diminished subscriber the MNG to the BR; this (i.e., the need for an IPv6-routed enterprise
network) may be viewed as an additional requirement by some
providers. The disadvantages include diminished subscriber
management, need for additional protocol to correlate the NAT state management, need for additional protocol to correlate the NAT state
(at the common node) with subscriber session information (at each of (at the common node) with subscriber session information (at each of
the gateways), suboptimal MN - MN communication, and of course the the gateways), suboptimal MN - MN communication, and of course the
need for a protocol from the MNG to BR itself. Also, if the NAT need for a protocol from the MNG to BR itself. Also, if the NAT
function were to experience failure, all the connected gateway function were to experience failure, all the connected gateway
service will be affected. These drawbacks are not present in the service will be affected. These drawbacks are not present in the
"distributed" model which we discuss in the following. "distributed" model which we discuss in the following.
In a "distributed" model, the private IPv4 address management is In a "distributed" model, the private IPv4 address management is
performed by the MNG which also performs the NAT functionality. In performed by the MNG which also performs the NAT functionality. In
skipping to change at page 9, line 10 skipping to change at page 9, line 23
NET10 block, which avoids the problem of overlapped private IPv4 NET10 block, which avoids the problem of overlapped private IPv4
addressing at the network core. In addition, since the MNG is where addressing at the network core. In addition, since the MNG is where
subscriber management functions are located, the NAT state subscriber management functions are located, the NAT state
correlation is readily enabled. Furthermore, an MNG already has correlation is readily enabled. Furthermore, an MNG already has
existing interfaces to functions such as AAA and PCRF, which allows existing interfaces to functions such as AAA and PCRF, which allows
it to perform subscriber management functions with the unique private it to perform subscriber management functions with the unique private
IPv4 addresses. Finally, the MNG can also pass-through certain IPv4 addresses. Finally, the MNG can also pass-through certain
traffic types without performing NAT to the application servers traffic types without performing NAT to the application servers
located within the service provider's domain, which allows the located within the service provider's domain, which allows the
servers to also identify subscriber sessions with unique private IPv4 servers to also identify subscriber sessions with unique private IPv4
addresses. addresses. The disadvantages of the "distributed model" include the
absence of centralized addressing and centralized management of NAT.
The foregoing discussion can be summarized as follows: First, the The foregoing discussion can be summarized as follows: First, the
management of available private IPv4 pool has become important given management of available private IPv4 pool has become important given
the growth of the mobile Internet users. The mechanisms that enable the growth of the mobile Internet users. The mechanisms that enable
re-use of the available pool are required. Second, in the context of re-use of the available pool are required. Second, in the context of
private IPv4 pool management, the placement of NAT functionality has private IPv4 pool management, the placement of NAT functionality has
implications to the network deployment and operations. Whereas the implications to the network deployment and operations. Whereas the
"centralized" models with a common NAT have the advantages of "centralized" models with a common NAT have the advantages of
continuing their legacy deployments, re-use of private IPv4 continuing their legacy deployments, re-use of private IPv4
addressing, and centralized NAT, they need additional functions to addressing, and centralized NAT, they need additional functions to
skipping to change at page 9, line 37 skipping to change at page 9, line 51
which already has well-defined interfaces to AAA, and PCRF. In which already has well-defined interfaces to AAA, and PCRF. In
summary, providers interested in readily integrating NAT with other summary, providers interested in readily integrating NAT with other
subscriber management functions, as well as conserving and re-using subscriber management functions, as well as conserving and re-using
their private IPv4 pool, may find the distributed model compelling. their private IPv4 pool, may find the distributed model compelling.
3.3. IPv6-only Deployment Considerations 3.3. IPv6-only Deployment Considerations
As we observed in the previous section, the NAT functionality in the As we observed in the previous section, the NAT functionality in the
network brings multiple issues which would otherwise be not present network brings multiple issues which would otherwise be not present
with the end-end access. NAT should be viewed as an interim solution with the end-end access. NAT should be viewed as an interim solution
until IPv6 is widely available, i.e., it is available for mobile until IPv6 is widely available, i.e., IPv6 is available for mobile
users for all (or most) practical purposes. Whereas NATs at provider users for all (or most) practical purposes. Whereas NATs at provider
premises may slow down the exhaustion of public IPv4 addresses, premises may slow down the exhaustion of public IPv4 addresses,
expeditious and simultaneous introduction of IPv6 in the operational expeditious and simultaneous introduction of IPv6 in the operational
networks is necessary to keep the "Internet going and growing". networks is necessary to keep the "Internet going and growing".
Towards this goal, it is important to understand the considerations Towards this goal, it is important to understand the considerations
in deploying IPv6-only networks. in deploying IPv6-only networks.
There are three dimensions to IPv6-only deployments: the network There are three dimensions to IPv6-only deployments: the network
itself, the mobile nodes and the applications, represented by the itself, the mobile nodes and the applications, represented by the
tuple [nw, mn, ap]. The goal is to reach the co-ordinate [IPv6, tuple [nw, mn, ap]. The goal is to reach the co-ordinate [IPv6,
skipping to change at page 10, line 49 skipping to change at page 11, line 15
subscribers in their Home Networks, see Figure 1. This is feasible subscribers in their Home Networks, see Figure 1. This is feasible
for the newer MNs when the provider's network is "IPv6-ready", which for the newer MNs when the provider's network is "IPv6-ready", which
means the network is able to provide IPv6-only PDN support and IPv6 - means the network is able to provide IPv6-only PDN support and IPv6 -
IPv4 interworking for Internet access. For the existing MNs however, IPv4 interworking for Internet access. For the existing MNs however,
the provider still needs to be able to support IPv4-only PDP/PDN the provider still needs to be able to support IPv4-only PDP/PDN
connectivity. connectivity.
Migration of applications to IPv6 in MNs with IPv6-only PDN Migration of applications to IPv6 in MNs with IPv6-only PDN
connectivity brings challenges. The applications and services connectivity brings challenges. The applications and services
offered by the provider obviously need to be IPv6-capable. However, offered by the provider obviously need to be IPv6-capable. However,
a MN may be host other applications which also need to be IPv6- a MN may host other applications which also need to be IPv6-capable
capable in IPv6-only deployments. This can be a "long-tail" in IPv6-only deployments. This can be a "long-tail" phenomenon;
phenomenon; however, when a few prominant applications start offering however, when a few prominant applications start offering IPv6, there
IPv6, there can be a strong incentive to provide application layer can be a strong incentive to provide application layer (e.g., socket
(e.g., socket interface) upgrades to IPv6. Furthermore, some IPv4- interface) upgrades to IPv6. Furthermore, some IPv4-only
only applications may be able to make use of alternative access such applications may be able to make use of alternative access such as
as WiFi when available. In summary, application migration to IPv6 WiFi when available. In summary, application migration to IPv6 needs
needs to be done even though it is likely to take a while before all to be done even though it is likely to take a while before all
applications migrate to IPv6. applications migrate to IPv6.
An important consideration in mobile networks is roaming, where users An important consideration in mobile networks is roaming, where users
may roam to networks operated by providers other than their own. The may roam to networks operated by providers other than their own. The
service providers can control their own network design but not their service providers can control their own network design but not their
peer's networks which they rely on for roaming. Perhaps more peer's networks which they rely on for roaming. Perhaps more
importantly, the users expect similar experience even when they are importantly, the users expect uniformity in experience even when they
roaming. This imposes a constraint on providers interested in IPv6- are roaming. This imposes a constraint on providers interested in
only deployments to also support IPv4 addressing when their own IPv6-only deployments to also support IPv4 addressing when their own
(outbound) subscribers roam to networks which do not offer IPv6. (outbound) subscribers roam to networks which do not offer IPv6. For
This is a realistic scenario today where an LTE deployment may be instance, when an LTE deployment is IPv6-only, a roamed 3G network
IPv6-only, whereas a roamed 3G UMTS network may not offer IPv6 PDN may not offer IPv6 PDN connectivity. Since a PDN connection involves
connectivity service. Since a PDN connection involves the radio base the radio base station, the ANG and the MNG (See Figure 1), it would
station, the ANG and the MNG (See Figure 1), it would not be possible not be possible to enable IPv6 PDN connectivity without the roamed
to enable IPv6 PDN connectivity without the roamed network support. network support. Similarly, there are inbound roamers to an IPv6-
Similarly, there are inbound roamers to an IPv6-ready provider ready provider network whose MN's are not capable of IPv6. The IPv6-
network whose MN's are not capable of IPv6. The IPv6-ready provider ready provider network has to be able to support IPv4 PDN
network has to be able to support IPv4 PDN connectivity for such connectivity for such inbound roamers as well. There are encouraging
inbound roamers as well. There are encouraging signs that the signs that the existing deployed network nodes in the 3GPP
existing deployed network nodes in 3GPP architecture already provide architecture already provide support for IPv6 PDP context. It would
support for IPv6 PDP context. It would be necessary to scale this be necessary to scale this support for a (very) large number of
support for a (very) large number of mobile users. mobile users.
In summary, IPv6-only deployments should be encouraged. This is In summary, IPv6-only deployments should be encouraged along-side the
dual-stack model, which is the recommended IETF approach. This is
relatively straightforward for an operator's own services and relatively straightforward for an operator's own services and
applications, provisioned through an appropriate APN (and IPv6-only applications, provisioned through an appropriate APN (and IPv6-only
PDP/PDN). Some providers may consider IPv6-only deployment for PDP/PDN). Some providers may consider IPv6-only deployment for
Internet access as well, and this would require IPv6 - IPv4 Internet access as well, and this would require IPv6 - IPv4
interworking. Such IPv6-only deployments can be phased-in for newer interworking. When the IPv6 - IPv4 translation mechanisms are used
mobile nodes, while the existing ones continue to demand IPv4-only in IPv6-only deployments, the protocols and the associated
connectivity. considerations specified in [xlate-stateful] and [xlate-stateless]
apply. Finally, such IPv6-only deployments can be phased-in for
newer mobile nodes, while the existing ones continue to demand IPv4-
only connectivity.
Roaming is important in mobile networks and roaming introduces Roaming is important in mobile networks and roaming introduces
diversity in network deployments. This means IPv6-only mobile diversity in network deployments. This means IPv6-only mobile
network deployments need to support IPv4 connectivity (and NAT44) for network deployments need to support IPv4 connectivity (and NAT44) for
their own users who roam into peer provider networks, and also for their own users who roam into peer provider networks, and also for
inbound roaming users with no IPv6 capability. inbound roaming users with no IPv6 capability.
However, by taking the initiative to introduce IPv6-only for the However, by taking the initiative to introduce IPv6-only for the
newer MNs, the mobile networks can significantly reduce the demand newer MNs, the mobile networks can significantly reduce the demand
for private IPv4 addresses. for private IPv4 addresses.
skipping to change at page 12, line 20 skipping to change at page 12, line 36
achieve "convergence". For instance, roaming is not a consideration achieve "convergence". For instance, roaming is not a consideration
in fixed access networks. And, an All-IP mobile network service in fixed access networks. And, an All-IP mobile network service
provider is required to provide voice service as well, whereas a provider is required to provide voice service as well, whereas a
fixed network provider is not required to. A "link" in fixed fixed network provider is not required to. A "link" in fixed
networks is generally capable of carrying IPv6 and IPv4 traffic, networks is generally capable of carrying IPv6 and IPv4 traffic,
whereas not all mobile networks have "links" (i.e., PDP/PDN whereas not all mobile networks have "links" (i.e., PDP/PDN
connections) capable of supporting IPv6 and IPv4; indeed roaming connections) capable of supporting IPv6 and IPv4; indeed roaming
makes this problem worse when a "portion" of the link (i.e., the Home makes this problem worse when a "portion" of the link (i.e., the Home
Network in Figure 1) is capable of supporting IPv6 and the other Network in Figure 1) is capable of supporting IPv6 and the other
"portion" of the link (i.e., the Visited Network in Figure 1) is not. "portion" of the link (i.e., the Visited Network in Figure 1) is not.
Such architectural differences as well as policy and business model Such architectural differences, as well as policy and business model
differences make convergence challenging. differences, make convergence challenging.
Nevertheless, within the same provider's space, some common Nevertheless, within the same provider's space, some common
considerations may apply. For instance, IPv4 address management is a considerations may apply. For instance, IPv4 address management is a
common concern for both the access networks. This implies the same common concern for both the access networks. This implies the same
mechanisms discussed earlier, i.e., delaying IPv4 address exhaustion mechanisms discussed earlier, i.e., delaying IPv4 address exhaustion
and introducing IPv6 in operational networks, apply for the and introducing IPv6 in operational networks, apply for the converged
"converged" networks as well. However, the exact solutions deployed networks as well. However, the exact solutions deployed for each
for each access network can vary for a variety of reasons. Tunneling access network can vary for a variety of reasons. Tunneling of
of private IPv4 packets within IPv6, for example, is feasible in private IPv4 packets within IPv6, for example, is feasible in fixed
fixed networks where the end-point is often a cable or DSL modem. networks where the end-point is often a cable or DSL modem. This is
This is not the case in mobile networks where the end-point is a MN not the case in mobile networks where the end-point is a MN itself.
itself. Similarly, encapsulation-based mechanisms such as 6rd [6rd] Similarly, encapsulation-based mechanisms such as 6rd [6rd] are
are feasible where a residential gateway can become a tunnel end- feasible where a residential gateway can become a tunnel end-point
point for connecting subscribers to IPv6-only networks, whereas for connecting subscribers to IPv6-only networks, whereas translation
translation is perhaps necessary for IPv6-only mobile networks. A is perhaps necessary for IPv6-only mobile networks. A mobile network
mobile network provider may have application servers (e.g., an email provider may have application servers (e.g., an email server) in its
server) in its network that require unique private IPv4 addresses for network that require unique private IPv4 addresses for MN
MN identification, whereas a fixed network provider may not have such identification, whereas a fixed network provider may not have such a
a requirement or the service itself. These examples illustrate that requirement or the service itself. These examples illustrate that
the actual solutions used in an access network are largely determined the actual solutions used in an access network are largely determined
by the requirements specific to that access network. However, some by the requirements specific to that access network. However, some
sharing between access and core network may be possible depending on sharing between access and core network may be possible depending on
the nature of the requirement and the functionality itself: for the nature of the requirement and the functionality itself: for
example, when a fixed network does not require a subscriber-aware example, when a fixed network does not require a subscriber-aware
feature such as NAT, the functionality may be provided at a core feature such as NAT, the functionality may be provided at a core
router while the mobile access network continues to provide the NAT router while the mobile access network continues to provide the NAT
functionality at the mobile gateway. functionality at the mobile gateway.
Different access networks of a provider are more likely to share a Different access networks of a provider are more likely to share a
skipping to change at page 13, line 22 skipping to change at page 13, line 39
convergence. Perhaps greater harmonization is feasible at the higher convergence. Perhaps greater harmonization is feasible at the higher
service layers, e.g., in terms of offering unified user experience service layers, e.g., in terms of offering unified user experience
for services and applications. Some harmonization of functions for services and applications. Some harmonization of functions
across access networks into the core network may be feasible. A across access networks into the core network may be feasible. A
provider's core network appears to the place where most convergence provider's core network appears to the place where most convergence
is feasible. is feasible.
4. Summary and Conclusion 4. Summary and Conclusion
IPv6 deployment in mobile networks is crucial for the mobile IPv6 deployment in mobile networks is crucial for the mobile
Internet. The 3GPP and IETF are working on the necessary system Internet. In this document, we discussed the considerations in
architecture and protocol mechanisms respectively, in order to enable deploying IPv6 in mobile networks. Specifically, we discussed:
IPv6 operational networks. In this document, we discussed the
considerations in deploying IPv6 in mobile networks. Specifically,
we discussed:
o IPv4 address exhaustion and its implications to mobile networks: o IPv4 address exhaustion and its implications to mobile networks:
we saw that, as the mobile networks begin to deploy IPv6, we saw that, as the mobile networks begin to deploy IPv6,
conserving the available IPv4 pool and delaying its exhaustion conserving the available IPv4 pool and delaying its exhaustion
implies the need for network translation in mobile networks. At implies the need for network translation in mobile networks. At
the same time, providers can make use of the 3GPP architecture the same time, providers can make use of the 3GPP architecture
constructs such as the APN and PDN connectivity to introduce IPv6 constructs such as the APN and PDN connectivity to introduce IPv6
without affecting the (predominantly IPv4) Internet access. The without affecting the (predominantly IPv4) Internet access. The
IETF dual-stack model [RFC4213] can be applied to the mobile IETF dual-stack model [RFC4213] can be applied to the mobile
networks readily. networks readily.
skipping to change at page 14, line 34 skipping to change at page 14, line 48
best-suited for converged network architecture. Perhaps even best-suited for converged network architecture. Perhaps even
greater gains are feasible in the service and application layers. greater gains are feasible in the service and application layers.
5. Security Considerations 5. Security Considerations
This document does not introduce any new security vulnerabilities. This document does not introduce any new security vulnerabilities.
6. Acknowledgement 6. Acknowledgement
This document has benefitted from discussions with and reviews from This document has benefitted from discussions with and reviews from
Cameron Byrne, David Crowe, Hui Deng, Fredrik Garneij, Teemu Cameron Byrne, David Crowe, Hui Deng, Remi Despres, Fredrik Garneij,
Savolainen and Dan Wing. Thanks to all of them. Mohamed Boucadair Jouni Korhonen, Teemu Savolainen and Dan Wing. Thanks to all of
provided an extensive review of version 01; many thanks Mohamed. them. Mohamed Boucadair provided an extensive review of version 01;
many thanks Mohamed.
7. Informative References 7. Informative References
[3gpp.3g] "General Packet Radio Service (GPRS); Service description; [3gpp.3g] "General Packet Radio Service (GPRS); Service description;
Stage 2, 3GPP TS 23.060, December 2006", . Stage 2, 3GPP TS 23.060, December 2006", .
[3gpp.4g] "General Packet Radio Service (GPRS);enhancements for [3gpp.4g] "General Packet Radio Service (GPRS);enhancements for
Evolved Universal Terrestrial Radio Access Network Evolved Universal Terrestrial Radio Access Network
(E-UTRAN) access", 3GPP TS 23.401 8.8.0, December 2009.", (E-UTRAN) access", 3GPP TS 23.401 8.8.0, December 2009.",
. .
skipping to change at page 15, line 28 skipping to change at page 15, line 41
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005. for IPv6 Hosts and Routers", RFC 4213, October 2005.
[gi-ds-lite] [gi-ds-lite]
Brockners, F. and S. Gundavelli, "Gateway Initiated Dual- Brockners, F. and S. Gundavelli, "Gateway Initiated Dual-
stack Lite Deployment", stack Lite Deployment",
draft-gundavelli-softwire-gateway-init-ds-lite-01.txt, draft-gundavelli-softwire-gateway-init-ds-lite-01.txt,
Oct 2009. Oct 2009.
[xlate-stateful]
Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers",
draft-ietf-behave-v6v4-xlate-stateful-11, Mar 2010.
[xlate-stateless]
Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", draft-ietf-behave-v6v4-xlate-20, May 2010.
Appendix A. Change Log
From v00 to v01, the following changes were incorporated:
o: Dual-stack being the recommended model, while encouraging IPv6-
only deployments.
o: Clarifications on on-demand IPv4 PDN usage, DHCP usage and on-
demand IPv4 assignment.
o: Clarifications regarding IPv6-only deployment: Roaming and
Applications considerations.
Author's Address Author's Address
Rajeev Koodli Rajeev Koodli
Cisco Systems Cisco Systems
USA USA
Email: rkoodli@cisco.com Email: rkoodli@cisco.com
 End of changes. 23 change blocks. 
82 lines changed or deleted 123 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/