draft-ietf-v6ops-v6-in-mobile-networks-03.txt   draft-ietf-v6ops-v6-in-mobile-networks-04.txt 
v6ops Working Group Rajeev Koodli v6ops Working Group Rajeev. Koodli
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Informational January 4, 2011 Intended status: Informational April 25, 2011
Expires: July 8, 2011 Expires: October 27, 2011
Mobile Networks Considerations for IPv6 Deployment Mobile Networks Considerations for IPv6 Deployment
draft-ietf-v6ops-v6-in-mobile-networks-03.txt draft-ietf-v6ops-v6-in-mobile-networks-04.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 July 8, 2011. This Internet-Draft will expire on October 28, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 21 skipping to change at page 2, line 21
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 . . . . . . . . . . . 10 3.3. IPv6-only Deployment Considerations . . . . . . . . . . . 10
3.4. Fixed - Mobile Convergence . . . . . . . . . . . . . . . . 13 3.4. Fixed - Mobile Convergence . . . . . . . . . . . . . . . . 13
4. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 15 4. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16
8. Informative References . . . . . . . . . . . . . . . . . . . . 16 8. Informative References . . . . . . . . . . . . . . . . . . . . 16
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 17 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
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 the available IPv4 addresses. 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.
While IPv6 brings many benefits, certain unique challenges arise when While IPv6 brings many benefits, certain unique challenges arise when
deploying it in mobile networks. This document describes such deploying it in mobile networks. This document describes such
challenges, and outlines the applicability of the existing IPv6 challenges and outlines the applicability of the existing IPv6
deployment solutions. As such, it can be a useful reference document deployment solutions. As such, it can be a useful reference document
for service providers as well as network designers. This document for service providers as well as network designers. This document
does not propose any new protocols or suggest new protocol does not propose any new protocols or suggest new protocol
specification work. specification work.
The primary considerations that we address in this document on IPv6 The primary considerations that we address in this document on IPv6
deployment in mobile networks are: deployment in mobile networks are:
o Public and Private IPv4 address exhaustion and implications to o Public and Private IPv4 address exhaustion and implications to
mobile network deployment architecture; mobile network deployment architecture;
skipping to change at page 4, line 27 skipping to change at page 4, line 27
Visited Network / Visited Network /
/ /
+-----+ /------------------\ +-----+ /------------------\
|ANG |/ Visited Operator's \ |ANG |/ Visited Operator's \
+-----+\ IP Network / +-----+\ IP Network /
\------------------/ \------------------/
Figure 1: Mobile Network Architecture Figure 1: Mobile Network Architecture
A Mobile Node (MN) connects to the mobile network either via its Home A Mobile Node (MN) connects to the mobile network either via its Home
Network or via a Visited Network when roaming. In the 3GPP network Network or via a Visited Network when the user is roaming outside of
architecture, a MN accesses the network by connecting to an Access the Home Network. In the 3GPP network architecture, a MN accesses
Point Name (APN), which maps to a mobile gateway. Roughly speaking, the network by connecting to an Access Point Name (APN), which maps
an APN is similar to an SSID in wireless LAN. An APN is a logical to a mobile gateway. Roughly speaking, an APN is similar to an SSID
concept which can be used to specify what kinds of services, such as in wireless LAN. An APN is a logical concept which can be used to
Internet access, high-definition video streaming, content-rich specify what kinds of services, such as Internet access, high-
gaming, and so on, a MN is entitled to. And, each APN can specify definition video streaming, content-rich gaming, and so on, a MN is
what type of IP connectivity (i.e., IPv4, IPv6, IPv4v6) is enabled on entitled to. Each APN can specify what type of IP connectivity
that particular APN. (i.e., IPv4, IPv6, IPv4v6) is enabled on that particular APN.
Whereas an APN directs a MN to an appropriate gateway, the MN needs While an APN directs a MN to an appropriate gateway, the MN needs an
(an end-to-end) 'link' to the gateway, which is realized through an end-to-end "link" to that gateway. In the Long-Term Evolution (LTE)
Evolved Packet System (EPS) bearer in the Long-term Evolution (LTE) networks, this link is realized through an Evolved Packet System
networks, and through a Packet Data Protocol (PDP) Context in the 3G (EPS) bearer. In the 3G UMTS networks, such a link is realized
UMTS networks. The different nodes in the figure are defined below: through a Packet Data Protocol (PDP) Context. The end-to-end link
traverses multiple nodes which are defined below:
o BS: The radio Base Station which provides wireless connectivity o Base Station (BS): The radio Base Station provides wireless
to the MN. connectivity to the MN.
o ANG: The Access Network Gateway. This is a node that forwards o Access Network Gateway (ANG): The ANG forwards IP packets to and
IP packets to and from the MN. Typically, this is not the MN's from the MN. Typically, this is not the MN's default router, and
default router, and the ANG does not perform IP address allocation the ANG does not perform IP address allocation and management for
and management for the mobile nodes. The ANG is located either in the mobile nodes. The ANG is located either in the Home Network
the Home Network or in the Visited Network. or in the Visited Network.
o MNG: The Mobile Network Gateway is the MN's default router which o The Mobile Network Gateway (MNG): The MNG is the MN's default
provides IP address management. The MNG performs functions such router which provides IP address management. The MNG performs
as offering Quality of Service (QoS), applying subscriber-specific functions such as offering Quality of Service (QoS), applying
policy, and enabling billing and accounting; these functions are subscriber-specific policy, and enabling billing and accounting;
sometimes collectively referred to as "subscriber-management" these functions are sometimes collectively referred to as
operations. The mobile network architecture, as shown in the "subscriber-management" operations. The mobile network
figure, defines the necessary protocol interfaces to enable architecture, as shown in the figure, defines the necessary
subscriber management operations. The MNG is typically located in protocol interfaces to enable subscriber management operations.
the Home Network. The MNG is typically located in the Home Network.
o BR: The Border Router, as the name implies, borders the Internet o Border Router (BR): As the name implies, a BR borders the
for the mobile network. The BR does not perform subscriber Internet for the mobile network. The BR does not perform
management for the mobile network. subscriber management for the mobile network.
o AAA: Authentication, Authorization and Accounting. The general o Authentication, Authorization and Accounting (AAA): The general
functionality of AAA is used for subscriber authentication and functionality of AAA is used for subscriber authentication and
authorization for services, as well as for generating billing and authorization for services, as well as for generating billing and
accounting information. accounting information.
In 3GPP network environments, the subscriber authentication and In the 3GPP network environments, the subscriber authentication
the subsequent authorization for connectivity and services is and the subsequent authorization for connectivity and services is
provided using the "Home Location Register" (HLR)/"Home Subscriber provided using the "Home Location Register" (HLR)/"Home Subscriber
Server" (HSS) functionality. Server" (HSS) functionality.
o PCRF: Policy and Charging Rule Function enables applying policy o Policy and Charging Rule Function (PCRF): The PCRF enables
and charging rules at the MNG. applying policy and charging rules at the MNG.
In the rest of this document, we use the terms operator, service In the rest of this document, we use the terms operator, service
provider or provider interchangeably. provider or provider interchangeably.
3. IPv6 Considerations 3. IPv6 Considerations
3.1. IPv4 Address Exhaustion 3.1. IPv4 Address Exhaustion
It is generally agreed that the pool of public IPv4 addressing is It is generally agreed that the pool of public IPv4 addresses is
nearing its exhaustion. The '/8' IANA blocks for Regional Internet nearing its exhaustion. The IANA has exhausted the available '/8'
Registries (RIRs) are projected to 'run-out' soon. Subsequently, the blocks for allocation to the Regional Internet Registries (RIRs).
addressing pool available to RIRs for assignment to Internet Service The RIRs themselves have either "run-out" of their blocks or are
Providers is anticipated to run-out in the following 2-3 years. This projected to exhaust them in the near future. This has led to a
has led to a heightened awareness among the providers to consider heightened awareness among the service providers to consider
introducing technologies to keep the Internet operational. There are introducing technologies to keep the Internet operational. For
two simultaneous approaches to addressing the run-out problem: providers, there are two simultaneous approaches to addressing the
delaying the IPv4 address exhaustion, and introducing IPv6 in run-out problem: delaying the IPv4 address pool exhaustion (i.e.,
operational networks. We consider both in the following. conserving their existing pool) and introducing IPv6 in operational
networks. We consider both in the following.
Delaying the public IPv4 address exhaustion involves assigning Delaying the public IPv4 address exhaustion for providers involves
private IPv4 addressing for end-users, as well as extending an IPv4 assigning private IPv4 addressing for end-users, or extending an IPv4
address (with the use of extended port ranges). A mechanism such as address with the use of port ranges which requires tunneling and
the Network Address Translator (NAT) is used at the provider premises additional signaling. A mechanism such as the Network Address
(as opposed to customer premises in the existing deployments) to Translator (NAT) is used at the provider premises (as opposed to
manage IP address assignment and access to the Internet. In the customer premises) to manage the private IP address assignment and
following, we primarily focus on translation based mechanisms such as access to the Internet. In the following, we primarily focus on
NAT44 (i.e., translation from public IPv4 to private IPv4 and vice translation based mechanisms such as NAT44 (i.e., translation from
versa) and NAT64 (i.e., translation from public IPv6 to public IPv4 public IPv4 to private IPv4 and vice versa) and NAT64 (i.e.,
and vice versa); we do this because the 3GPP architecture already translation from public IPv6 to public IPv4 and vice versa). We do
defines a tunneling infrastructure with the GPRS Tunneling Protocol this because the 3GPP architecture already defines a tunneling
(GTP), and the architecture allows for dual-stack and IPv6-only infrastructure with the GPRS Tunneling Protocol (GTP), and the
deployments. architecture allows for dual-stack and IPv6-only deployments.
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. A PDN connection implies an end-end link (i.e., an establishment. A PDN connection implies an end-end link (i.e., an
EPS bearer in 4G LTE and a PDP context in 3G UMTS) from the MN to the EPS bearer in 4G LTE or a PDP context in 3G UMTS) from the MN to the
MNG. There can be one or more PDN connections active at any given MNG. There can be one or more PDN connections active at any given
time for each MN. A PDN connection may support both IPv4 and IPv6 time for each MN. A PDN connection may support both IPv4 and IPv6
traffic (as in a dual-stack PDN in 4G LTE networks) or it may support traffic (as in a dual-stack PDN in 4G LTE networks) or it may support
either one only (as in the existing 3G UMTS networks). The IPv4 only one of the two traffic types (as in the existing 3G UMTS
address is assigned at the time of PDN connectivity establishment, or networks). The IPv4 address is assigned at the time of PDN
is assigned using the DHCP protocol after the PDN connectivity is connectivity establishment, or is assigned using the DHCP protocol
established. In order to delay the exhaustion of public IPv4 after the PDN connectivity is established. In order to delay the
addresses, this IP address needs to be a private IPv4 address which exhaustion of public IPv4 addresses, this IP address needs to be a
is translated into a shared public IPv4 address. Hence, there is a private IPv4 address which is translated into a shared public IPv4
need for private - public IPv4 translation mechanism in the mobile address. Hence, there is a need for private - public IPv4
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. This requirement is due to the need for user in the All-IP network. This requirement is due to the need for
supporting Voice over IP service in LTE which does not have circuit- supporting Voice over IP service in LTE which does not have circuit-
based infrastructure. If this PDN connection were to use IPv4 based infrastructure. 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. An approach to availability and usage of private IPv4 addresses. One way to address
address this problem is to make the always-on PDN to be IPv6, and this is by making the always-on PDN (that requires voice service) to
enable IPv4 PDN on-demand, e.g., when an application binds to an IPv4 be IPv6. The IPv4 PDN is only established when the user needs it.
socket interface. This ensures that an IPv4 address is not assigned
for every attached MN, but only to those attempting to use the The 3GPP standards also specify a deferred IPv4 address allocation on
traffic. The IPv4 PDN may be subject to session idle timers upon the a dual-stack IPv4v6 PDN at the time of connection establishment.
expiry of which, the PDN (and the assigned IPv4 address) may be This has the advantage of a single PDN for IPv6 and IPv4 along with
deleted. Another option specified in the 3GPP standards is to defer deferring IPv4 address allocation until an application needs it. The
the allocation of IPv4 address on a dual-stack IPv4v6 PDN at the time deferred address allocation requires support for a dyncamic
of connection establishment. This has the advantage of a single PDN configuration protocol such as DHCP as well as appropriate triggers
for IPv6 and IPv4, along with deferring IPv4 address allocation until to invoke the protocol. Such a support does not exist today in
an application needs it. However, this requires support for a mobile phones. The newer iterations of Smartphones could provide
dynamic configuration protocol such as DHCP, which many cellular MNs such support. Also, the tethering of Smartphones to laptops (which
do not support today for use over the cellular radio. This is typically support DHCP) could use deferred allocation depending on
changing with complementary access technologies, with many when a laptop attaches to the Smartphone. Until appropriate triggers
Smartphones already supporting DHCP for user over WiFi. Besides, and host stack support is available, the applicability of the address
laptops using the network interface cards (such as USB dongles) to deferring option may be limited.
connect to the cellular network typically support the DHCP protocol.
In any case, there need to be appropriate triggers to initiate DHCP
based on the application and interface usage, as well as DHCP lease
management based on appropriate address management policies. These
considerations may limit the applicability of the address deferring
option.
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 even though many SmartPhones requirement for an always-on connection even though many SmartPhones
seldom relinquish an established PDP context. And, the existing so- seldom relinquish an established PDP context. The existing so-called
called pre-Release-8 deployments do not support the dual-stack PDP pre-Release-8 deployments do not support the dual-stack PDP
connection. Hence two separate PDP connections are necessary to connection. Hence, two separate PDP connections are necessary to
support IPv4 and IPv6 traffic. Even though some MNs, especially the support IPv4 and IPv6 traffic. Even though some MNs, especially the
SmartPhones, in use today may have IPv6 stack, such a capability is SmartPhones, in use today may have IPv6 stack, such a capability is
not tested (if any at all) extensively and deployed in operational not tested for compliance and deployment in operational networks.
networks. Given this, it is reasonable to expect that IPv6 can only Without compliance to network requirements, providers cannot reliably
be introduced in the newer MNs, and that such newer MNs still need to provision services. Given these considerations, it is reasonable to
be able to access the (predominantly IPv4) Internet. expect that the providers can offer connectivity and services based
on IPv6 in the MNs which are not already in use today. And, such
newer MNs still need to be able to access 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 an increasing need to
IPv4 addressing in mobile networks in order to address the public support private IPv4 addressing in mobile networks because of the
IPv4 run-out problem. This means there is a need for private - public IPv4 address run-out problem. Correspondingly, there is a
public IPv4 translation in the mobile network. Second, there is greater need for private - public IPv4 translation in the mobile
support for IPv6 in both 3G and 4G LTE networks already in the form networks. Second, there is support for IPv6 in both 3G and 4G LTE
of PDP context and PDN connections. Operators can introduce IPv6 in networks already in the form of PDP context and PDN connections. To
their networks, perhaps to access operator's own applications and begin with, the operators can introduce IPv6 for their own
services to begin with. In other words, the IETF's recommended model applications and services. In other words, the IETF's recommended
of dual-stack IPv6 and IPv4 networks is readily applicable to mobile model of dual-stack IPv6 and IPv4 networks is readily applicable to
networks with the support for distinct APNs and the ability to carry mobile networks with the support for distinct APNs and the ability to
IPv6 traffic on PDP/PDN connections. The IETF dual-stack model can carry IPv6 traffic on PDP/PDN connections. The IETF dual-stack model
be applied using a single IPv4v6 PDN connection in Release-8 and can be applied using a single IPv4v6 PDN connection in Release-8 and
onwards, but requires separate PDP contexts in the earlier releases. onwards, but requires separate PDP contexts in the earlier releases.
Finally, operators can make IPv6 as the default for always-on mobile Finally, operators can make IPv6 as the default for always-on mobile
connections, and investigate on-demand PDN and (private) address connections using either the IPv4v6 PDN or the IPv6 PDN, and use IPv4
assignment for IPv4. PDNs as necessary.
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
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 as well. Access networks generally need
produce network and service usage records for billing and accounting. to produce network and service usage records for billing and
This is true for mobile networks as well where "subscriber accounting. This is true also for mobile networks 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 for accounting purposes. As another example, the correlated for accounting purposes. As another example, the
Application Servers within the provider network may need to treat Application Servers within the provider network may need to treat
traffic based on policy provided by the PCRF. If the IP address seen traffic based on policy provided by the PCRF. If the IP address seen
by these Application Servers is not unique, the PCRF needs to be able by these Application Servers is not unique, the PCRF needs to be able
to inspect the NAT binding to disambiguate among the individual MNs. to inspect the NAT binding to disambiguate among the individual MNs.
And, the subscriber session management information and the service And, the subscriber session management information and the service
usage information also need to be correlated in order to produce usage information also need to be correlated in order to produce
harmonized records. Furthermore, there may be legal requirements for harmonized records. Furthermore, there may be legal requirements for
storing the NAT binding records. Indeed, these problems disappear storing the NAT binding records. Indeed, these problems disappear
with the transition to IPv6. For now, it suffices to state that NAT with the transition to IPv6. For now, it suffices to state that NAT
introduces state which needs to be correlated and possibly stored introduces state which needs to be correlated and possibly stored
with other routine subscriber information. 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 BR, and the
Router, and the pool shared by multiple gateways all attached to the pool shared by multiple MNGs all attached to the same BR. This model
same BR. This model has served well in the pre-3G deployments where has served well in the pre-3G deployments where the number of
the number of subscribers accessing the mobile Internet at any given subscribers accessing the mobile Internet at any given time has not
time, perhaps, has not exceeded the available address pool. However, exceeded the available address pool. However, with the advent of 3G
with the advent of 3G networks and the subsequent dramatic growth in networks and the subsequent dramatic growth in the number of users on
the number of users on the mobile Internet, the service providers are the mobile Internet, the service providers are increasingly forced to
increasingly forced to consider their existing network design and consider their existing network design and choices. Specifically,
choices. Specifically, the providers are forced to address private the providers are forced to address private IPv4 pool exhaustion as
IPv4 pool exhaustion as well as scalable NAT solutions. well as scalable NAT solutions.
In order to address the private IPv4 exhaustion in the centralized In order to tackle the private IPv4 exhaustion in the centralized
model, there would be a need to support overlapped private IPv4 model, there would be a need to support overlapped private IPv4
addresses in the common NAT functionality as well as in each of the addresses in the common NAT functionality as well as in each of the
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 Tunneling mechanisms such as Generic Routing Encapsulation (GRE)
separation for overlapping private IPv4; the others include MPLS VPN
tunnels or any tunneling mechanism with a unique identifier for the [RFC2784], [RFC2890], MPLS [RFC3031] VPN tunnels or even IP-in-IP
session. An obvious advantage of centralizing the NAT and using encapsulation [RFC2003] which can provide a unique identifier for a
overlapped private IPv4 addressing is that a large number of mobile NAT session can be used to separate overlapping private IPv4 traffic
subscribers can be supported with a common limited pool at the BR. as described in [gi-ds-lite]. An obvious advantage of centralizing
It also enables the operator's enterprise network to use IPv6 from the NAT and using overlapped private IPv4 addressing is that a large
the MNG to the BR; this (i.e., the need for an IPv6-routed enterprise number of mobile subscribers can be supported with a common limited
network) may be viewed as an additional requirement by some pool at the BR. It also enables the operator's enterprise network to
providers. The disadvantages include diminished subscriber use IPv6 from the MNG to the BR; this (i.e., the need for an IPv6-
management (compared to a subscriber-aware NAT), need for additional routed enterprise network) may be viewed as an additional requirement
by some providers. The disadvantages include the need for additional
protocol to correlate the NAT state (at the common node) with protocol to correlate the NAT state (at the common node) with
subscriber session information (at each of the gateways), suboptimal subscriber session information (at each of the gateways), suboptimal
MN - MN communication, and of course the need for a protocol from the MN - MN communication, absence of subscriber-aware NAT (and policy)
MNG to BR itself. Also, if the NAT function were to experience function, and of course the need for a protocol from the MNG to BR
failure, all the connected gateway service will be affected. These itself. Also, if the NAT function were to experience failure, all
drawbacks are not present in the "distributed" model which we discuss the connected gateway service will be affected. These drawbacks are
in the following. not present in the "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
this model, each MNG has a block of 16.7 million unique addresses, this model, each MNG has a block of 16.7 million unique addresses,
which is sufficient compared to the number of mobile subscribers which is sufficient compared to the number of mobile subscribers
active on each MNG. By distributing the NAT functionality to the active on each MNG. By distributing the NAT functionality to the
edge of the network, each MNG is allowed to re-use the available edge of the network, each MNG is allowed to re-use the available
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. The disadvantages of the "distributed model" include the addresses. The disadvantages of the "distributed model" include the
skipping to change at page 10, line 10 skipping to change at page 10, line 10
IP addresses. In any case, the NAT device has to be able to provide IP addresses. In any case, the NAT device has to be able to provide
the necessary NAT session binding information to an external entity the necessary NAT session binding information to an external entity
(such as AAA or PCRF) which then needs to be able to correlate those (such as AAA or PCRF) which then needs to be able to correlate those
records with the user's session state present at the MNG. records with the user's session state present at the MNG.
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. 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 and the re-use of private IPv4
addressing, and centralized NAT, they need additional functions to addressing. However, they need additional functions to enable
enable traffic differentiation, and NAT state correlation with traffic differentiation and NAT state correlation with subscriber
subscriber state management at the MNG. The distributed models also state management at the MNG. The distributed models also achieve
achieve private IPv4 address re-use, and avoid overlapping private private IPv4 address re-use and avoid overlapping private IPv4
IPv4 traffic in the operator's core, but without the need for traffic in the operator's core, but without the need for additional
additional mechanisms. Since the MNG performs (unique) IPv4 address mechanisms. Since the MNG performs (unique) IPv4 address assignment
assignment and has standard interfaces to AAA and PCRF, the and has standard interfaces to AAA and PCRF, the distributed model
distributed model also enables a single point for subscriber and NAT also enables a single point for subscriber and NAT state reporting as
state reporting as well as policy application. In summary, providers well as policy application. In summary, providers interested in
interested in readily integrating NAT with other subscriber readily integrating NAT with other subscriber management functions,
management functions, as well as conserving and re-using their as well as conserving and re-using their private IPv4 pool, may find
private IPv4 pool, may find the distributed model compelling, while the distributed model compelling. On the other hand, those providers
those interested in common management of NAT may find the cetralized interested in common management of NAT may find the cetralized model
model more compelling. more 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 presence of NAT
network brings multiple issues which would otherwise be not present functionality in the network brings multiple issues which would
with the end-to-end access. NAT should be viewed as an interim otherwise be absent. NAT should be viewed as an interim solution
solution until IPv6 is widely available, i.e., IPv6 is available for until IPv6 is widely available, i.e., IPv6 is available for mobile
mobile users for all (or most) practical purposes. Whereas NATs at users for all (or most) practical purposes. Whereas NATs at provider
provider premises may slow down the exhaustion of public IPv4 premises may slow down the exhaustion of public IPv4 addresses,
addresses, expeditious and simultaneous introduction of IPv6 in the expeditious and simultaneous introduction of IPv6 in the operational
operational networks is necessary to keep the "Internet going and networks is necessary to keep the "Internet going and growing".
growing". Towards this goal, it is important to understand the Towards this goal, it is important to understand the considerations
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
3-tuple {nw, mn, ap}. The goal is to reach the co-ordinate {IPv6, 3-tuple {nw, mn, ap}. The goal is to reach the co-ordinate {IPv6,
IPv6, IPv6} from {IPv4, IPv4, IPv4}. However, there are multiple IPv6, IPv6} from {IPv4, IPv4, IPv4}. However, there are multiple
paths to arrive at the goal. The classic dual-stack model would paths to arrive at the goal. The classic dual-stack model would
traverse the co-ordinate {IPv4v6, IPv4v6, IPv4v6}, where each traverse the co-ordinate {IPv4v6, IPv4v6, IPv4v6}, where each
dimension supports co-existence of IPv4 and IPv6. This appears to be dimension supports co-existence of IPv4 and IPv6. This appears to be
the path of least disruption, although we are faced with the the path of least disruption, although we are faced with the
implications of supoorting large-scale NAT in the network. There is implications of supoorting large-scale NAT in the network. There is
skipping to change at page 11, line 30 skipping to change at page 11, line 30
must ensure that the synthesized AAAA record correctly maps to the must ensure that the synthesized AAAA record correctly maps to the
IPv6 - IPv4 translator. IPv6 - IPv4 translator.
The IPv6-only deployments in mobile networks need to reckon with the The IPv6-only deployments in mobile networks need to reckon with the
following considerations. First, both the network and the MNs need following considerations. First, both the network and the MNs need
to be IPv6-capable. Expedited network upgrades as well as roll-out to be IPv6-capable. Expedited network upgrades as well as roll-out
of MNs with IPv6 would greatly facilitate this. Fortunately, the of MNs with IPv6 would greatly facilitate this. Fortunately, the
3GPP network design for LTE already requires the network nodes and 3GPP network design for LTE already requires the network nodes and
the mobile nodes to support IPv6. Even though there are no the mobile nodes to support IPv6. Even though there are no
requirements for the transport network to be IPv6, an operational requirements for the transport network to be IPv6, an operational
IPv6 network can be deployed with configured tunneling between the IPv6 connectivity service can be deployed with appropriate existing
network nodes with IPv4-only transport. Hence a service provider may tunneling mechanisms in the IPv4-only transport network. Hence a
choose to enforce IPv6-only PDN and address assignment for their own service provider may choose to enforce IPv6-only PDN and address
subscribers in their Home Networks, see Figure 1. This is feasible assignment for their own subscribers in their Home Networks, see
for the newer MNs when the provider's network is "IPv6-ready", which Figure 1. This is feasible for the newer MNs when the mobile network
means the network is able to provide IPv6-only PDN support and IPv6 - is able to provide IPv6-only PDN support and IPv6 - IPv4 interworking
IPv4 interworking for Internet access. For the existing MNs however, for Internet access. For the existing MNs however, the provider
the provider still needs to be able to support IPv4-only PDP/PDN 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 host other applications which also need to be IPv6-capable a MN may host other applications which also need to be IPv6-capable
in IPv6-only deployments. This can be a "long-tail" phenomenon; in IPv6-only deployments. This can be a "long-tail" phenomenon;
however, when a few prominant applications start offering IPv6, there however, when a few prominant applications start offering IPv6, there
can be a strong incentive to provide application layer (e.g., socket can be a strong incentive to provide application layer (e.g., socket
interface) upgrades to IPv6. Also, some IPv4-only applications may interface) upgrades to IPv6. Also, some IPv4-only applications may
be able to make use of alternative access such as WiFi when be able to make use of alternative access such as WiFi when
available. A related challenge in the migration of applications is available. A related challenge in the migration of applications is
the use of IPv4 literals in application layer protocols (such as the use of IPv4 literals in application layer protocols (such as
XMPP) or content (as in html or xml). Some Internet applications XMPP) or content (as in html or xml). Some Internet applications
expect their clients to supply IPv4 addresses as literals, and this expect their clients to supply IPv4 addresses as literals, and this
will not be possible with IPv6-only deployments. These experiences will not be possible with IPv6-only deployments. Some of these
and the related considerations in deploying IPv6-only network are experiences and the related considerations in deploying IPv6-only
documented in [arkko-v6]. In summary, application migration to IPv6 network are documented in [arkko-v6]. In summary, migration of
needs to be done even though it is anticipated to take a while before applications to IPv6 needs to be done, and such a migration is not
all applications migrate to IPv6. expected to be uniform across all subsets of existing applications.
Voice over LTE (VoLTE) also brings some unique challenges. The Voice over LTE (VoLTE) also brings some unique challenges. The
signaling for voice is generally expected to be available for free signaling for voice is generally expected to be available for free
while the actual voice call itself is typically charged based on its while the actual voice call itself is typically charged on its
duration. Such a separation of signaling and the call is unique to duration. Such a separation of signaling and the payload is unique
voice, whereas an Internet connection is simply accounted without to voice, whereas an Internet connection is accounted without
specifically considering application signaling and payload traffic, specifically considering application signaling and payload traffic.
e.g., based on overall byte usage. This model is expected to be This model is expected to be supported even during roaming.
supported even during roaming. Furthermore, providers and users Furthermore, the providers and the users generally require the voice
generally require the ability to provide voice service regardless of service regardless of roaming whereas the Internet usage is subject
roaming whereas the Internet usage may be based on subscriber to subscriber preferences and roaming agreements. This requirement
preferences and roaming agreements. The requirement to always to ubiquitously support voice service while providing the flexibility
support voice service while providing the flexibility to use the for Internet usage exacerbates the addressing problem, and may hasten
Internet based on user's preference and roaming agreements provisioning of VoLTE using the IPv6-only PDN.
exacerbates the addressing problem, and may hasten provisioning of
VoLTE using the IPv6-only PDN.
An important consideration in mobile networks is roaming, where users As seen earlier, roaming is unique to mobile networks and it
may roam to networks operated by providers other than their own. The introduces new challenges. The service providers can control their
service providers can control their own network design but not their own network design but not their peer's networks which they rely on
peer's networks which they rely on for roaming. Perhaps more for roaming. The users expect uniformity in experience even when
importantly, the users expect uniformity in experience even when they they are roaming. This imposes a constraint on providers interested
are roaming. This imposes a constraint on providers interested in in IPv6-only deployments to also support IPv4 addressing when their
IPv6-only deployments to also support IPv4 addressing when their own own (outbound) subscribers roam to networks which do not offer IPv6.
(outbound) subscribers roam to networks which do not offer IPv6. For For instance, when an LTE deployment is IPv6-only, a roamed 3G
instance, when an LTE deployment is IPv6-only, a roamed 3G network network may not offer IPv6 PDN connectivity. Since a PDN connection
may not offer IPv6 PDN connectivity. Since a PDN connection involves involves the radio base station, the ANG and the MNG (See Figure 1),
the radio base station, the ANG and the MNG (See Figure 1), it would it would not be possible to enable IPv6 PDN connectivity without the
not be possible to enable IPv6 PDN connectivity without the roamed roamed network support. These considerations also apply when the
network support. These considerations apply even when the visited visited network is used for offering services such as VoLTE in the
network is used for offering services such as VoLTE in the so-called so-called Local Breakout model; the roaming MN's capability as well
Local Breakout model; the roaming MN's capability as well as the as the roamed network capability to support VoLTE using IPv6
roamed network capability to support services using IPv6 determine determine whether fallback to IPv4 would be necessary. Similarly,
whether fallback to IPv4 would be necessary. Similarly, there are there are inbound roamers to an IPv6-ready provider network whose
inbound roamers to an IPv6-ready provider network whose MN's are not MN's are not capable of IPv6. The IPv6-ready provider network has to
capable of IPv6. The IPv6-ready provider network has to be able to be able to support IPv4 PDN connectivity for such inbound roamers.
support IPv4 PDN connectivity for such inbound roamers as well.
There are encouraging signs that the existing deployed network nodes There are encouraging signs that the existing deployed network nodes
in the 3GPP architecture already provide support for IPv6 PDP in the 3GPP architecture already provide support for IPv6 PDP
context. It would be necessary to scale this support for a (very) context. It would be necessary to scale this support for a (very)
large number of mobile users. large number of mobile users and offer it as a ubiquitous service
which can be accounted for.
In summary, IPv6-only deployments should be encouraged along-side the In summary, IPv6-only deployments should be encouraged along-side the
dual-stack model, which is the recommended IETF approach. This is 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 the
PDP/PDN). Some providers may consider IPv6-only deployment for corresponding IPv6-only PDP or EPS bearer. Some providers may
Internet access as well, and this would require IPv6 - IPv4 consider IPv6-only deployment for Internet access as well, and this
interworking. When the IPv6 - IPv4 translation mechanisms are used would require IPv6 - IPv4 interworking. When the IPv6 - IPv4
in IPv6-only deployments, the protocols and the associated translation mechanisms are used in IPv6-only deployments, the
considerations specified in [xlate-stateful] and [xlate-stateless] protocols and the associated considerations specified in
apply. Finally, such IPv6-only deployments can be phased-in for [xlate-stateful] and [xlate-stateless] apply. Finally, such IPv6-
newer mobile nodes, while the existing ones continue to demand IPv4- only deployments can be phased-in for newer mobile nodes, while the
only connectivity. 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. Until IPv6 connectivity is
network deployments need to support IPv4 connectivity (and NAT44) for available in all mobile networks, IPv6-only mobile network
their own users who roam into peer provider networks, and also for deployments need to be prepared to support IPv4 connectivity (and
inbound roaming users with no IPv6 capability. However, by taking NAT44) for their own outbound roaming users as well as for inbound
the initiative to introduce IPv6-only for the newer MNs, the mobile roaming users. However, by taking the initiative to introduce IPv6-
networks can significantly reduce the demand for private IPv4 only for the newer MNs, the mobile networks can significantly reduce
addresses. the demand for private IPv4 addresses.
3.4. Fixed - Mobile Convergence 3.4. Fixed - Mobile Convergence
Many service providers have both fixed broadband and mobile networks. Many service providers have both fixed broadband and mobile networks.
Access networks are generally disparate, with some common Access networks are generally disparate, with some common
characteristics but with enough differences to make it challenging to characteristics but with enough differences to make it challenging to
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. An All-IP mobile network service provider
provider is required to provide voice service as well, whereas a is required to provide voice service, whereas this is not required
fixed network provider is not required to. A "link" in fixed for a fixed network provider. A "link" in fixed networks is
networks is generally capable of carrying IPv6 and IPv4 traffic, generally capable of carrying IPv6 and IPv4 traffic, whereas not all
whereas not all mobile networks have "links" (i.e., PDP/PDN mobile networks have "links" (i.e., PDP/PDN connections) capable of
connections) capable of supporting IPv6 and IPv4; indeed roaming supporting IPv6 and IPv4. Indeed roaming makes this problem worse
makes this problem worse when a "portion" of the link (i.e., the Home when a portion of the link (i.e., the Home Network in Figure 1) is
Network in Figure 1) is capable of supporting IPv6 and the other capable of supporting IPv6 and the other portion of the link (i.e.,
"portion" of the link (i.e., the Visited Network in Figure 1) is not. the Visited Network in Figure 1) is not. Such architectural
Such architectural differences, as well as policy and business model differences, as well as policy and business model differences make
differences, make convergence challenging. 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 of the access networks. This implies that
mechanisms discussed earlier, i.e., delaying IPv4 address exhaustion the same mechanisms discussed earlier, i.e., delaying IPv4 address
and introducing IPv6 in operational networks, apply for the converged exhaustion and introducing IPv6 in operational networks, apply for
networks as well. However, the exact solutions deployed for each the converged networks as well. However, the exact solutions
access network can vary for a variety of reasons. Tunneling of deployed for each access network can vary for a variety of reasons.
private IPv4 packets within IPv6, for example, is feasible in fixed For instance:
networks where the end-point is often a cable or DSL modem. This is
not the case in mobile networks where the end-point is a MN itself. o Tunneling of private IPv4 packets within IPv6 is feasible in
Similarly, encapsulation-based mechanisms such as 6rd [RFC5969] are fixed networks where the end-point is often a cable or DSL modem.
feasible where a residential gateway can become a tunnel end-point This is not the case in mobile networks where the end-point is a
for connecting subscribers to IPv6-only networks, whereas translation MN itself.
is perhaps necessary for IPv6-only mobile networks. A mobile network
provider may have application servers (e.g., an email server) in its o Encapsulation-based mechanisms such as 6rd [RFC5969] are
network that require unique private IPv4 addresses for MN feasible where a residential gateway can become a tunnel end-point
identification, whereas a fixed network provider may not have such a for connecting subscribers to IPv6-only networks, whereas
requirement or the service itself. These examples illustrate that translation is perhaps necessary for IPv6-only mobile networks.
the actual solutions used in an access network are largely determined
by the requirements specific to that access network. However, some o A mobile network provider may have application servers (e.g., an
sharing between access and core network may be possible depending on email server) in its network that require unique private IPv4
the nature of the requirement and the functionality itself: for addresses for MN identification, whereas a fixed network provider
example, when a fixed network does not require a subscriber-aware may not have such a requirement or the service itself.
feature such as NAT, the functionality may be provided at a core
router while the mobile access network continues to provide the NAT These examples illustrate that the actual solutions used in an access
functionality at the mobile gateway. In addition, if a provider network are largely determined by the requirements specific to that
chooses to offer common subscriber management at the MNG for both access network. Nevertheless, some sharing between access and core
fixed and wireless networks, the MNG itself becomes a convergence network may be possible depending on the nature of the requirement
node that needs to support the applicable transition mechanisms for and the functionality itself. For example, when a fixed network does
both fixed and wireless access networks. not require a subscriber-aware feature such as NAT, the functionality
may be provided at a core router while the mobile access network
continues to provide the NAT functionality at the mobile gateway. If
a provider chooses to offer common subscriber management at the MNG
for both fixed and wireless networks, the MNG itself becomes a
convergence node that needs to support the applicable transition
mechanisms for both fixed and wireless access networks.
Different access networks of a provider are more likely to share a Different access networks of a provider are more likely to share a
common core network. Hence, common solutions can be more easily common core network. Hence, common solutions can be more easily
applied in the core network. For instance, configured tunnels or applied in the core network. For instance, configured tunnels or
MPLS VPNs from the gateways from both mobile and fixed networks can MPLS VPNs from the gateways from both mobile and fixed networks can
be used to carry traffic to the core routers, until the entire core be used to carry traffic to the core routers, until the entire core
network is IPv6-enabled. network is IPv6-enabled.
There can also be considerations due to the use of NAT in access There can also be considerations due to the use of NAT in access
networks. Solutions such as Femto Networks rely on a fixed Internet networks. Solutions such as Femto Networks rely on a fixed Internet
connection being available for the Femto Base Station to communicate connection being available for the Femto Base Station to communicate
with its peer on the mobile network, typically via an IPsec tunnel. with its peer on the mobile network, typically via an IPsec tunnel.
When the Femto Base Station needs to use a private IPv4 address, the When the Femto Base Station needs to use a private IPv4 address, the
mobile network access through it is subject to NAT policy mobile network access through the Femto Base Station will be subject
administration, which could include periodic clean-up and purge of to NAT policy administration including periodic clean-up and purge of
NAT state. Such policies affect the usability of the Femto Network, NAT state. Such policies affect the usability of the Femto Network,
and has implications to the mobile network provider. Using IPv6 for and has implications to the mobile network provider. Using IPv6 for
the Femto (or any other access technology), on the other hand, could the Femto (or any other access technology) could alleviate some of
alleviate some of these concerns if the IPv6 communication could these concerns if the IPv6 communication could bypass the NAT.
bypass the NAT.
In summary, there is clear interest in fixed-mobile convergence at In summary, there is interest in fixed-mobile convergence at least
least among some providers. While there are benefits from among some providers. While there are benefits from harmonizing the
harmonizing the network as much as possible, there are also network as much as possible, there are also idiosyncrasies of
idiosyncrasies of disparate access networks which influence the disparate access networks which influence the convergence. Perhaps
convergence. Perhaps greater harmonization is feasible at the higher greater harmonization is feasible at the higher service layers, e.g.,
service layers, e.g., in terms of offering unified user experience in terms of offering unified user experience for services and
for services and applications. Some harmonization of functions applications. Some harmonization of functions across access networks
across access networks into the core network may be feasible. A into the core network may be feasible. A provider's core network
provider's core network appears to the place where most convergence 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. In this document, we discussed the considerations in Internet. In this document, we discussed the considerations in
deploying IPv6 in mobile networks. Specifically, we discussed: deploying IPv6 in mobile networks. We summarize the discussion in
the following:
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, As the mobile service providers begin to deploy IPv6, conserving
conserving the available IPv4 pool and delaying its exhaustion their available IPv4 pool implies the need for network address
implies the need for network translation in mobile networks. At translation in mobile networks. At the same time, providers can
the same time, providers can make use of the 3GPP architecture make use of the 3GPP architecture constructs such as the APN and
constructs such as the APN and PDN connectivity to introduce IPv6 PDN connectivity to introduce IPv6 without affecting the
without affecting the (predominantly IPv4) Internet access. The predominantly IPv4 Internet access. The IETF dual-stack model
IETF dual-stack model [RFC4213] can be applied to the mobile [RFC4213] can be applied to the mobile networks readily.
networks readily.
o The placement of NAT functionality in mobile networks: we o The placement of NAT functionality in mobile networks: Both the
discussed the centralized and distributed models of private IPv4 centralized and distributed models of private IPv4 address pool
address pool management and their relative merits. We saw that by management have their relative merits. By enabling each MNG to
enabling each MNG to manage its own NET10 pool, the distributed manage its own NET10 pool, the distributed model achieves re-use
model achieves re-use of available private IPv4 pool, and avoids of available private IPv4 pool and avoids the problems associated
the problems associated with the non-unique private IPv4 addresses with the non-unique private IPv4 addresses for the MNs without
for the MNs without additional protocol mechanisms. The additional protocol mechanisms. The distributed model also
distributed model also augments the "subscriber management" augments the "subscriber management" functions at an MNG, such as
functions at an MNG, such as readily enabling NAT session readily enabling NAT session correlation with the rest of the
correlation with the rest of the subscriber session state. On the subscriber session state. On the other hand, the existing
other hand, the existing deployments which have used the deployments which have used the centralized IP address management
centralized IP address management can continue their legacy can continue their legacy architecture by placing the NAT at a
architecture by placing the NAT at a common node. The centralized common node. The centralized model also achieves private IPv4
model also achieves private IPv4 address re-use, but needs address re-use, but needs additional protocol extensions to
additional protocol extensions to differentiate overlapping differentiate overlapping addresses at the common NAT as well as
addresses at the common NAT, as well as to integrate with policy to integrate with policy and billing infrastructure.
and billing infrastructure.
o IPv6-only mobile network deployments: we saw that this is o IPv6-only mobile network deployments: This deployment model is
feasible in the LTE architecture for an operator's own services feasible in the LTE architecture for an operator's own services
and applications. We observed that the existing MNs still expect and applications. The existing MNs still expect IPv4 address
IPv4 address assignment. And, roaming, which is unique to mobile assignment. And, roaming which is unique to mobile networks,
networks, requires that a provider support IPv4 connectivity when requires that a provider support IPv4 connectivity when their
their (outbound) users roam into a mobile network that is not (outbound) users roam into a mobile network that is not IPv6-
IPv6-enabled. Similarly, a provider needs to support IPv4 enabled. Similarly, a provider needs to support IPv4 connectivity
connectivity for (inbound) users whose MNs are not IPv6-capable. for (inbound) users whose MNs are not IPv6-capable. The IPv6 -
And, we also observed that IPv6 - IPv4 interworking is necessary IPv4 interworking is necessary for IPv6-only MNs to access IPv4
for IPv6-only MNs to access IPv4 Internet. Internet.
o Fixed-Mobile Convergence: we discussed the examples illustrating o Fixed-Mobile Convergence: The examples discussed illustrate the
the differences in the requirements of fixed and mobile networks. differences in the requirements of fixed and mobile networks.
While some harmonization of functions may be possible across the While some harmonization of functions may be possible across the
access networks, the service provider's core network is perhaps access networks, the service provider's core network is perhaps
best-suited for converged network architecture. Perhaps even better-suited for converged network architecture. Similar gains
greater gains are feasible in the service and application layers. in convergence 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. IANA Considerations 6. IANA Considerations
This document does not require any actions from IANA. This document does not require any actions from IANA.
7. Acknowledgement 7. 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, Remi Despres, Fredrik Garneij, Cameron Byrne, David Crowe, Hui Deng, Remi Despres, Fredrik Garneij,
Jouni Korhonen, Teemu Savolainen and Dan Wing. Thanks to all of Jouni Korhonen, Teemu Savolainen and Dan Wing; thanks to all of them.
them. Mohamed Boucadair provided an extensive review of individual Mohamed Boucadair provided an extensive review of individual draft
draft version 01 of this document; many thanks Mohamed. Cameron version 01 of this document; many thanks Mohamed. Cameron Byrne,
Byrne and Kent Leung provided thorough reviews of v01, which have Kent Leung, Kathleen Moriarty and Jari Arkko provided reviews which
helped improve this document. Thanks to Nick Heatley for providing have helped improve this document. Thanks to Nick Heatley for
valuable review and input on VoLTE. providing valuable review and input on VoLTE.
8. Informative References 8. 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 17, line 11 skipping to change at page 17, line 15
[3gpp2.ehrpd] [3gpp2.ehrpd]
"E-UTRAN - eHRPD Connectivity and Interworking: Core "E-UTRAN - eHRPD Connectivity and Interworking: Core
Network Aspects", http://www.3gpp2.org/Public_html/Misc/ Network Aspects", http://www.3gpp2.org/Public_html/Misc/
X.P0057-0_v0.13_E-UTRAN- X.P0057-0_v0.13_E-UTRAN-
eHRPD_Interworking_VV_Due_5_December-2008.pdf. eHRPD_Interworking_VV_Due_5_December-2008.pdf.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000.
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
RFC 2890, September 2000.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[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.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd) -- Protocol Specification", Infrastructures (6rd) -- Protocol Specification",
RFC 5969, August 2010. RFC 5969, August 2010.
[arkko-v6] [arkko-v6]
Arkko, J. and A. Keranen, "Experiences from an IPv6-Only Arkko, J. and A. Keranen, "Experiences from an IPv6-Only
Network", draft-arkko-ipv6-only-experience-01, Jul 2010. Network", draft-arkko-ipv6-only-experience-01, Jul 2010.
[dns64] Bagnulo, M., Sullivan, A., Matthews, P., and I. van [dns64] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS extensions for Network Address Beijnum, "DNS64: DNS extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", Translation from IPv6 Clients to IPv4 Servers",
draft-ietf-behave-dns64-11, Mar 2010. draft-ietf-behave-dns64-11, Mar 2010.
[gi-ds-lite] [gi-ds-lite]
Brockners, F. and S. Gundavelli, "Gateway Initiated Dual- Brockners et al., F., "Gateway Initiated Dual-stack Lite
stack Lite Deployment", Deployment", draft-ietf-softwire-gateway-init-ds-lite,
draft-gundavelli-softwire-gateway-init-ds-lite-01.txt,
Oct 2009. Oct 2009.
[xlate-stateful] [xlate-stateful]
Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6 NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", Clients to IPv4 Servers",
draft-ietf-behave-v6v4-xlate-stateful-11, Mar 2010. draft-ietf-behave-v6v4-xlate-stateful-11, Mar 2010.
[xlate-stateless] [xlate-stateless]
Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", draft-ietf-behave-v6v4-xlate-20, May 2010. Algorithm", draft-ietf-behave-v6v4-xlate-20, May 2010.
Appendix A. Change Log Appendix A. Change Log
Revisions (from draft-koodli-**), descending chronological order Revisions (from draft-koodli-**), descending chronological order
o: Addressed IESG reviews
o: FMC, Femto Networks text o: FMC, Femto Networks text
o: Dedicated NAT device model (in addition to the centralized and o: Dedicated NAT device model (in addition to the centralized and
distributed models) distributed models)
o: IPv6-only deployment considerations: - IPv4 literals discussion o: IPv6-only deployment considerations: - IPv4 literals discussion
and reference, - IPv6 prefix assignment clarification, - DNS64 and reference, - IPv6 prefix assignment clarification, - DNS64
requirement and reference requirement and reference
o: Overall revisions based on comments from reviews (C. Byrne, K. o: Overall revisions based on comments from reviews (C. Byrne, K.
Leung) Leung)
 End of changes. 60 change blocks. 
348 lines changed or deleted 364 lines changed or added

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