draft-ietf-v6ops-v6-in-mobile-networks-02.txt   draft-ietf-v6ops-v6-in-mobile-networks-03.txt 
v6ops Working Group Rajeev. Koodli v6ops Working Group Rajeev Koodli
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Informational October 26, 2010 Intended status: Informational January 4, 2011
Expires: April 29, 2011 Expires: July 8, 2011
Mobile Networks Considerations for IPv6 Deployment Mobile Networks Considerations for IPv6 Deployment
draft-ietf-v6ops-v6-in-mobile-networks-02.txt draft-ietf-v6ops-v6-in-mobile-networks-03.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 April 29, 2011. This Internet-Draft will expire on July 8, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
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 . . . . . . . . . . . 10 3.3. IPv6-only Deployment Considerations . . . . . . . . . . . 10
3.4. Fixed - Mobile Convergence . . . . . . . . . . . . . . . . 12 3.4. Fixed - Mobile Convergence . . . . . . . . . . . . . . . . 13
4. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 14 4. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16
8. Informative References . . . . . . . . . . . . . . . . . . . . 16 8. Informative References . . . . . . . . . . . . . . . . . . . . 16
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 17 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 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 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.
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
skipping to change at page 4, line 43 skipping to change at page 4, line 43
gaming, and so on, a MN is entitled to. And, each APN can specify gaming, and so on, a MN is entitled to. And, each APN can specify
what type of IP connectivity (i.e., IPv4, IPv6, IPv4v6) is enabled on what type of IP connectivity (i.e., IPv4, IPv6, IPv4v6) is enabled on
that particular APN. that particular APN.
Whereas an APN directs a MN to an appropriate gateway, the MN needs Whereas an APN directs a MN to an appropriate gateway, the MN needs
(an end-to-end) 'link' to the gateway, which is realized through an (an end-to-end) 'link' to the gateway, which is realized through an
Evolved Packet System (EPS) bearer in the Long-term Evolution (LTE) Evolved Packet System (EPS) bearer in the Long-term Evolution (LTE)
networks, and through a Packet Data Protocol (PDP) Context in the 3G networks, and through a Packet Data Protocol (PDP) Context in the 3G
UMTS networks. The different nodes in the figure are defined below: UMTS networks. The different nodes in the figure are defined below:
o BS: The radio Base Station which provides wireless connectivity
to the MN.
o ANG: The Access Network Gateway. This is a node that forwards o ANG: The Access Network Gateway. This is a node that forwards
IP packets to and from the MN. Typically, this is not the MN's IP packets to and from the MN. Typically, this is not the MN's
default router, and the ANG does not perform IP address allocation default router, and the ANG does not perform IP address allocation
and management for the mobile nodes. and management for the mobile nodes. The ANG is located either in
the Home Network or in the Visited Network.
o MNG: The Mobile Network Gateway is the MN's default router which o MNG: The Mobile Network Gateway is the MN's default router which
provides IP address management. The MNG performs functions such provides IP address management. The MNG performs functions such
as offering Quality of Service (QoS), applying subscriber-specific as offering Quality of Service (QoS), applying subscriber-specific
policy, and enabling billing and accounting; these functions are policy, and enabling billing and accounting; these functions are
sometimes collectively referred to as "subscriber-management" sometimes collectively referred to as "subscriber-management"
operations. The mobile network architecture, as shown in the operations. The mobile network architecture, as shown in the
figure, defines the necessary protocol interfaces to enable figure, defines the necessary protocol interfaces to enable
subscriber management operations. subscriber management operations. The MNG is typically located in
the Home Network.
o BR: The Border Router, as the name implies, borders the Internet o BR: The Border Router, as the name implies, borders the Internet
for the mobile network. The BR does not perform subscriber for the mobile network. The BR does not perform subscriber
management for the mobile network. management for the mobile network.
o AAA: Authentication, Authorization and Accounting. The general o AAA: Authentication, Authorization and Accounting. 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 3GPP network environments, the subscriber authentication and
skipping to change at page 5, line 39 skipping to change at page 5, line 40
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 addressing is
nearing its exhaustion. The '/8' IANA blocks for Regional Internet nearing its exhaustion. The '/8' IANA blocks for Regional Internet
Registries (RIRs) are projected to 'run-out' towards the end of 2011. Registries (RIRs) are projected to 'run-out' soon. Subsequently, the
Subsequently, the addressing pool available to RIRs for assignment to addressing pool available to RIRs for assignment to Internet Service
Internet Service Providers is anticipated to run-out in the following Providers is anticipated to run-out in the following 2-3 years. This
2-3 years. This has led to a heightened awareness among the has led to a heightened awareness among the providers to consider
providers to consider introducing technologies to keep the Internet introducing technologies to keep the Internet operational. There are
operational. There are two simultaneous approaches to addressing the two simultaneous approaches to addressing the run-out problem:
run-out problem: delaying the IPv4 address exhaustion, and delaying the IPv4 address exhaustion, and introducing IPv6 in
introducing IPv6 in operational networks. We consider both in the operational networks. We consider both in the following.
following.
Delaying the public IPv4 address exhaustion involves assigning Delaying the public IPv4 address exhaustion involves assigning
private IPv4 addressing for end-users, as well as extending an IPv4 private IPv4 addressing for end-users, as well as extending an IPv4
address (with the use of extended port ranges). A mechanism such as address (with the use of extended port ranges). A mechanism such as
the Network Address Translator (NAT) is used at the provider premises the Network Address Translator (NAT) is used at the provider premises
(as opposed to customer premises in the existing deployments) to (as opposed to customer premises in the existing deployments) to
manage IP address assignment and access to the Internet. In the manage IP address assignment and access to the Internet. In the
following, we primarily focus on translation based mechanisms such as following, we primarily focus on translation based mechanisms such as
NAT44 (i.e., translation from public IPv4 to private IPv4 and vice NAT44 (i.e., translation from public IPv4 to private IPv4 and vice
versa) and NAT64 (i.e., translation from public IPv6 to public IPv4 versa) and NAT64 (i.e., translation from public IPv6 to public IPv4
and vice versa); we do this because the 3GPP architecture already and vice versa); we do this because the 3GPP architecture already
defines a tunneling infrastructure with the GPRS Tunneling Protocol defines a tunneling infrastructure with the GPRS Tunneling Protocol
(GTP), and the architecture allows for dual-stack and IPv6-only (GTP), and the architecture allows for dual-stack and IPv6-only
deployments. 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. As mentioned earlier, a PDN can be understood to be establishment. A PDN connection implies an end-end link (i.e., an
the end-to-end link from the MN to the MNG. There can be one or more EPS bearer in 4G LTE and a PDP context in 3G UMTS) from the MN to the
PDN connections active at any given time for each MN. A PDN MNG. There can be one or more PDN connections active at any given
connection may support both IPv4 and IPv6 traffic (as in a dual-stack time for each MN. A PDN connection may support both IPv4 and IPv6
PDN in 4G LTE networks) or it may support either one only (as in the traffic (as in a dual-stack PDN in 4G LTE networks) or it may support
existing 3G UMTS networks). The IPv4 address is assigned at the time either one only (as in the existing 3G UMTS networks). The IPv4
of PDN connectivity establishment, or is assigned using the DHCP address is assigned at the time of PDN connectivity establishment, or
protocol after the PDN connectivity is established. In order to is assigned using the DHCP protocol after the PDN connectivity is
delay the exhaustion of public IPv4 addresses, this IP address needs established. In order to delay the exhaustion of public IPv4
to be a private IPv4 address which is translated into a shared public addresses, this IP address needs to be a private IPv4 address which
IPv4 address. Hence, there is a need for private - public IPv4 is translated into a shared public IPv4 address. Hence, there is a
translation mechanism in the mobile network. need for private - public IPv4 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. This requirement is due to the need for
supporting Voice over IP service in LTE which does not have circuit-
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. An approach to
address this problem is to make the always-on PDN to be IPv6, and address this problem is to make the always-on PDN to be IPv6, and
enable IPv4 PDN on-demand, e.g., when an application binds to an IPv4 enable IPv4 PDN on-demand, e.g., when an application binds to an IPv4
socket interface. This ensures that an IPv4 address is not assigned socket interface. This ensures that an IPv4 address is not assigned
for every attached MN, but only to those attempting to use the for every attached MN, but only to those attempting to use the
traffic. The IPv4 PDN may be subject to session idle timers upon the traffic. The IPv4 PDN may be subject to session idle timers upon the
expiry of which, the PDN (and the assigned IPv4 address) may be expiry of which, the PDN (and the assigned IPv4 address) may be
deleted. Another option (specified in the 3GPP standards) is to deleted. Another option specified in the 3GPP standards is to defer
defer the allocation of IPv4 address on a dual-stack IPv4v6 PDN at the allocation of IPv4 address on a dual-stack IPv4v6 PDN at the time
the time of connection establishment. This has the advantage of a of connection establishment. This has the advantage of a single PDN
single PDN for IPv6 and IPv4, along with deferring IPv4 address for IPv6 and IPv4, along with deferring IPv4 address allocation until
allocation until an application needs it. However, this requires an application needs it. However, this requires support for a
support for a dynamic configuration protocol such as DHCP, which many dynamic configuration protocol such as DHCP, which many cellular MNs
cellular MNs do not support today for use over the cellular radio. do not support today for use over the cellular radio. This is
This is changing with complementary access technologies, with many changing with complementary access technologies, with many
Smartphones already supporting DHCP for user over WiFi. Besides, Smartphones already supporting DHCP for user over WiFi. Besides,
laptops using the network interface cards (such as USB dongles) to laptops using the network interface cards (such as USB dongles) to
connect to the cellular network typically support the DHCP protocol. connect to the cellular network typically support the DHCP protocol.
In any case, there need to be appropriate triggers to initiate DHCP In any case, there need to be appropriate triggers to initiate DHCP
based on the application and interface usage, as well as DHCP lease based on the application and interface usage, as well as DHCP lease
management based on appropriate address management policies. These management based on appropriate address management policies. These
considerations may limit the applicability of the address deferring considerations may limit the applicability of the address deferring
option. 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 (a 'link' from the MN to the requirement for an always-on connection even though many SmartPhones
MNG in 3G UMTS is referred to as a Packet Data Protocol (PDP) seldom relinquish an established PDP context. And, the existing so-
context/connection) even though many SmartPhones seldom relinquish an called pre-Release-8 deployments do not support the dual-stack PDP
established PDP context. And, the existing (so-called pre-Release-8) connection. Hence two separate PDP connections are necessary to
deployments do not support the dual-stack PDP connection. Hence two support IPv4 and IPv6 traffic. Even though some MNs, especially the
separate PDP connections are necessary to support IPv4 and IPv6 SmartPhones, in use today may have IPv6 stack, such a capability is
traffic. Even though some MNs (especially the SmartPhones) in use not tested (if any at all) extensively and deployed in operational
today may have IPv6 stack, such a capability is not tested (if any at networks. Given this, it is reasonable to expect that IPv6 can only
all) extensively and deployed in operational networks. Given this, be introduced in the newer MNs, and that such newer MNs still need to
it is reasonable to expect that IPv6 can only be introduced in the be able to access the (predominantly IPv4) Internet.
newer MNs, and that 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 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 recommended model services to begin with. In other words, the IETF's recommended model
of dual-stack 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. The IETF dual-stack model can
IPv6 as the default for always-on mobile connections, and investigate be applied using a single IPv4v6 PDN connection in Release-8 and
on-demand PDN and (private) address assignment for IPv4. onwards, but requires separate PDP contexts in the earlier releases.
Finally, operators can make IPv6 as the default for always-on mobile
connections, and investigate 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 10, line 38 skipping to change at page 10, line 43
solution until IPv6 is widely available, i.e., IPv6 is available for solution until IPv6 is widely available, i.e., IPv6 is available for
mobile users for all (or most) practical purposes. Whereas NATs at mobile users for all (or most) practical purposes. Whereas NATs at
provider premises may slow down the exhaustion of public IPv4 provider premises may slow down the exhaustion of public IPv4
addresses, expeditious and simultaneous introduction of IPv6 in the addresses, expeditious and simultaneous introduction of IPv6 in the
operational networks is necessary to keep the "Internet going and operational networks is necessary to keep the "Internet going and
growing". Towards this goal, it is important to understand the growing". Towards this goal, it is important to understand the
considerations in deploying IPv6-only networks. considerations 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, 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. The other implications of supoorting large-scale NAT in the network. There is
intermediate co-ordinate of interest is [IPv6, IPv6, IPv4], where the also the cost of supporting separate PDP contexts in the existing 3G
network and the MN are IPv6-only, and the Internet applications are UMTS networks. The other intermediate co-ordinate of interest is
recognized to be predominantly IPv4. This transition path would, {IPv6, IPv6, IPv4}, where the network and the MN are IPv6-only, and
ironically, require interworking between IPv6 and IPv4 in order for the Internet applications are recognized to be predominantly IPv4.
the IPv6-only MNs to be able to access IPv4 services and applications This transition path would, ironically, require interworking between
on the Internet. In other words, in order to disengage NAT (for IPv4 IPv6 and IPv4 in order for the IPv6-only MNs to be able to access
- IPv4), we need to introduce another form of NAT (i.e., IPv6 - IPv4) IPv4 services and applications on the Internet. In other words, in
to expedite the adoption of IPv6. order to disengage NAT (for IPv4 - IPv4), we need to introduce
another form of NAT (i.e., IPv6 - IPv4) to expedite the adoption of
IPv6.
It is interesting to consider the preceeding discussion surrounding It is interesting to consider the preceeding discussion surrounding
the placement of NAT for IPv6 - IPv4 interworking. There is no the placement of NAT for IPv6 - IPv4 interworking. There is no
overlapping private IPv4 address problem because each IPv6 address is overlapping private IPv4 address problem because each IPv6 address is
unique (and there are plenty of them available!). Hence, there is unique and there are plenty of them available. Hence, there is also
also no requirement for (IPv6) address re-use, which means no no requirement for (IPv6) address re-use, which means no protocol is
protocol is necessary in the centralized model to disambiguiate NAT necessary in the centralized model to disambiguiate NAT sessions.
sessions. However, there is an additional requirement of DNS64 However, there is an additional requirement of DNS64 [dns64]
[dns64] functionality for IPv6 - IPv4 translation. This DNS64 functionality for IPv6 - IPv4 translation. This DNS64 functionality
functionality must ensure that the synthesized AAAA record correctly must ensure that the synthesized AAAA record correctly maps to the
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 network can be deployed with configured tunneling between the
network nodes with IPv4-only transport. Hence a service provider may network nodes with IPv4-only transport. Hence a service provider may
skipping to change at page 12, line 5 skipping to change at page 12, line 11
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. These experiences
and the related considerations in deploying IPv6-only network are and the related considerations in deploying IPv6-only network are
documented in [arkko-v6]. In summary, application migration to IPv6 documented in [arkko-v6]. In summary, application migration to IPv6
needs to be done even though it is anticipated to take a while before needs to be done even though it is anticipated to take a while before
all applications migrate to IPv6. all applications migrate to IPv6.
Voice over LTE (VoLTE) also brings some unique challenges. The
signaling for voice is generally expected to be available for free
while the actual voice call itself is typically charged based on its
duration. Such a separation of signaling and the call is unique to
voice, whereas an Internet connection is simply accounted without
specifically considering application signaling and payload traffic,
e.g., based on overall byte usage. This model is expected to be
supported even during roaming. Furthermore, providers and users
generally require the ability to provide voice service regardless of
roaming whereas the Internet usage may be based on subscriber
preferences and roaming agreements. The requirement to always
support voice service while providing the flexibility to use the
Internet based on user's preference and roaming agreements
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 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 uniformity in experience even when they importantly, the users expect uniformity in experience even when they
are roaming. This imposes a constraint on providers interested in are roaming. This imposes a constraint on providers interested in
IPv6-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. For (outbound) subscribers roam to networks which do not offer IPv6. For
instance, when an LTE deployment is IPv6-only, a roamed 3G network instance, when an LTE deployment is IPv6-only, a roamed 3G network
may not offer IPv6 PDN connectivity. Since a PDN connection involves may not offer IPv6 PDN connectivity. Since a PDN connection involves
the radio base station, the ANG and the MNG (See Figure 1), it would the radio base station, the ANG and the MNG (See Figure 1), it would
not be possible to enable IPv6 PDN connectivity without the roamed not be possible to enable IPv6 PDN connectivity without the roamed
network support. Similarly, there are inbound roamers to an IPv6- network support. These considerations apply even when the visited
ready provider network whose MN's are not capable of IPv6. The IPv6- network is used for offering services such as VoLTE in the so-called
ready provider network has to be able to support IPv4 PDN Local Breakout model; the roaming MN's capability as well as the
connectivity for such inbound roamers as well. There are encouraging roamed network capability to support services using IPv6 determine
signs that the existing deployed network nodes in the 3GPP whether fallback to IPv4 would be necessary. Similarly, there are
architecture already provide support for IPv6 PDP context. It would inbound roamers to an IPv6-ready provider network whose MN's are not
be necessary to scale this support for a (very) large number of capable of IPv6. The IPv6-ready provider network has to be able to
mobile users. support IPv4 PDN connectivity for such inbound roamers as well.
There are encouraging signs that the existing deployed network nodes
in the 3GPP architecture already provide support for IPv6 PDP
context. It would be necessary to scale this support for a (very)
large number of mobile users.
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 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. When the IPv6 - IPv4 translation mechanisms are used interworking. When the IPv6 - IPv4 translation mechanisms are used
in IPv6-only deployments, the protocols and the associated in IPv6-only deployments, the protocols and the associated
considerations specified in [xlate-stateful] and [xlate-stateless] considerations specified in [xlate-stateful] and [xlate-stateless]
apply. Finally, such IPv6-only deployments can be phased-in for apply. Finally, such IPv6-only deployments can be phased-in for
newer mobile nodes, while the existing ones continue to demand IPv4- newer mobile nodes, while the existing ones continue to demand IPv4-
only connectivity. 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 newer MNs, the mobile
However, by taking the initiative to introduce IPv6-only for the networks can significantly reduce the demand for private IPv4
newer MNs, the mobile networks can significantly reduce the demand addresses.
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. 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
skipping to change at page 16, line 6 skipping to change at page 16, line 28
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. Mohamed Boucadair provided an extensive review of version 01; them. Mohamed Boucadair provided an extensive review of individual
many thanks Mohamed. Cameron Byrne and Kent Leung provided thorough draft version 01 of this document; many thanks Mohamed. Cameron
reviews of v01, which have helped improve this document. Byrne and Kent Leung provided thorough reviews of v01, which have
helped improve this document. Thanks to Nick Heatley for 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.",
. .
 End of changes. 24 change blocks. 
94 lines changed or deleted 125 lines changed or added

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