GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6342

Internet Engineering Task Force (IETF) R. Koodli Request for Comments: 6342 Cisco Systems Obsoletes: 6312 August 2011 Category: Informational ISSN: 2070-1721

         Mobile Networks Considerations for IPv6 Deployment

Abstract

 Mobile Internet access from smartphones and other mobile devices is
 accelerating the exhaustion of IPv4 addresses.  IPv6 is widely seen
 as crucial for the continued operation and growth of the Internet,
 and in particular, it is critical in mobile networks.  This document
 discusses the issues that arise when deploying IPv6 in mobile
 networks.  Hence, this document can be a useful reference for service
 providers and network designers.

RFC Editor Note

 This document obsoletes RFC 6312.
 Due to a publishing error, RFC 6312 contains the incorrect RFC number
 in its header.  This document corrects that error with a new RFC
 number.  The specification herein is otherwise unchanged with respect
 to RFC 6312.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Not all documents
 approved by the IESG are a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6342.

Koodli Informational [Page 1] RFC 6342 IPv6 in Mobile Networks August 2011

Copyright Notice

 Copyright (c) 2011 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1. Introduction ....................................................2
 2. Reference Architecture and Terminology ..........................3
 3. IPv6 Considerations .............................................4
    3.1. IPv4 Address Exhaustion ....................................4
    3.2. NAT Placement in Mobile Networks ...........................7
    3.3. IPv6-Only Deployment Considerations .......................10
    3.4. Fixed-Mobile Convergence ..................................13
 4. Summary and Conclusion .........................................14
 5. Security Considerations ........................................16
 6. Acknowledgements ...............................................16
 7. Informative References .........................................16

1. Introduction

 The dramatic growth of the Mobile Internet is accelerating the
 exhaustion of the available IPv4 addresses.  It is widely accepted
 that IPv6 is necessary for the continued operation and growth of the
 Internet in general and of the Mobile Internet in particular.  While
 IPv6 brings many benefits, certain unique challenges arise when
 deploying it in mobile networks.  This document describes such
 challenges and outlines the applicability of the existing IPv6
 deployment solutions.  As such, it can be a useful reference document
 for service providers as well as network designers.  This document
 does not propose any new protocols or suggest new protocol
 specification work.
 The primary considerations that we address in this document on IPv6
 deployment in mobile networks are:
 o  Public and Private IPv4 address exhaustion and implications to
    mobile network deployment architecture;

Koodli Informational [Page 2] RFC 6342 IPv6 in Mobile Networks August 2011

 o  Placement of Network Address Translation (NAT) functionality and
    its implications;
 o  IPv6-only deployment considerations and roaming implications; and
 o  Fixed-Mobile Convergence and implications to overall architecture.
 In the following sections, we discuss each of these in detail.
 For the most part, we assume the Third Generation Partnership Project
 (3GPP) 3G and 4G network architectures specified in [3GPP.3G] and
 [3GPP.4G].  However, the considerations are general enough for other
 mobile network architectures as well [3GPP2.EHRPD].

2. Reference Architecture and Terminology

 The following is a reference architecture of a mobile network.
                              +-----+    +-----+
                              | AAA |    | PCRF|
                              +-----+    +-----+
            Home Network         \          /
                                  \        /                       /-
                                   \      /                       / I
MN     BS                           \    /                       /  n
 |     /\    +-----+ /-----------\ +-----+ /-----------\ +----+ /   t

+-+ /_ \—| ANG |/ Operator's \| MNG |/ Operator's \| BR |/ e | |—/ \ +—–+\ IP Network /+—–+\ IP Network /+—-+\ r +-+ \———–/ / \———–/ \ n

  1. —————/—— \ e

Visited Network / \ t

                                   /                               \-
       +-----+ /------------------\
       | ANG |/ Visited Operator's \
       +-----+\     IP Network     /
               \------------------/
                Figure 1: Mobile Network Architecture
 A Mobile Node (MN) connects to the mobile network either via its Home
 Network or via a Visited Network when the user is roaming outside of
 the Home Network.  In the 3GPP network architecture, an MN accesses
 the network by connecting to an Access Point Name (APN), which maps
 to a mobile gateway.  Roughly speaking, an APN is similar to a
 Service Set Identifier (SSID) in wireless LAN.  An APN is a logical
 concept that can be used to specify what kinds of services, such as
 Internet access, high-definition video streaming, content-rich
 gaming, and so on, that an MN is entitled to.  Each APN can specify

Koodli Informational [Page 3] RFC 6342 IPv6 in Mobile Networks August 2011

 what type of IP connectivity (i.e., IPv4, IPv6, IPv4v6) is enabled on
 that particular APN.
 While an APN directs an MN to an appropriate gateway, the MN needs an
 end-to-end "link" to that gateway.  In the Long-Term Evolution (LTE)
 networks, this link is realized through an Evolved Packet System
 (EPS) bearer.  In the 3G Universal Mobile Telecommunications System
 (UMTS) networks, such a link is realized through a Packet Data
 Protocol (PDP) context.  The end-to-end link traverses multiple
 nodes, which are defined below:
 o  Base Station (BS): The radio Base Station provides wireless
    connectivity to the MN.
 o  Access Network Gateway (ANG): The ANG forwards 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 and management for
    the mobile nodes.  The ANG is located either in the Home Network
    or in the Visited Network.
 o  The Mobile Network Gateway (MNG): The MNG is the MN's default
    router, which provides IP address management.  The MNG performs
    functions such as offering Quality of Service (QoS), applying
    subscriber-specific policy, and enabling billing and accounting;
    these functions are sometimes collectively referred to as
    "subscriber-management" operations.  The mobile network
    architecture, as shown in Figure 1, defines the necessary protocol
    interfaces to enable subscriber-management operations.  The MNG is
    typically located in the Home Network.
 o  Border Router (BR): As the name implies, a BR borders the Internet
    for the mobile network.  The BR does not perform subscriber
    management for the mobile network.
 o  Authentication, Authorization, and Accounting (AAA): The general
    functionality of AAA is used for subscriber authentication and
    authorization for services as well as for generating billing and
    accounting information.
    In 3GPP network environments, the subscriber authentication and
    the subsequent authorization for connectivity and services is
    provided using the "Home Location Register" (HLR) / "Home
    Subscriber Server" (HSS) functionality.
 o  Policy and Charging Rule Function (PCRF): The PCRF enables
    applying policy and charging rules at the MNG.

Koodli Informational [Page 4] RFC 6342 IPv6 in Mobile Networks August 2011

 In the rest of this document, we use the terms "operator", "service
 provider", and "provider" interchangeably.

3. IPv6 Considerations

3.1. IPv4 Address Exhaustion

 It is generally agreed that the pool of public IPv4 addresses is
 nearing its exhaustion.  The IANA has exhausted the available '/8'
 blocks for allocation to the Regional Internet Registries (RIRs).
 The RIRs themselves have either "run out" of their blocks or are
 projected to exhaust them in the near future.  This has led to a
 heightened awareness among service providers to consider introducing
 technologies to keep the Internet operational.  For providers, there
 are two simultaneous approaches to addressing the run-out problem:
 delaying the IPv4 address pool exhaustion (i.e., conserving their
 existing pool) and introducing IPv6 in operational networks.  We
 consider both in the following.
 Delaying public IPv4 address exhaustion for providers involves
 assigning private IPv4 addressing for end-users or extending an IPv4
 address with the use of port ranges, which requires tunneling and
 additional signaling.  A mechanism such as the Network Address
 Translator (NAT) is used at the provider premises (as opposed to
 customer premises) to manage the private IP address assignment and
 access to the Internet.  In the following, we primarily focus on
 translation-based mechanisms such as NAT44 (i.e., translation from
 public IPv4 to private IPv4 and vice versa) and NAT64 (i.e.,
 translation from public IPv6 to public IPv4 and vice versa).  We do
 this because the 3GPP architecture already defines a tunneling
 infrastructure with the General Packet Radio Service (GPRS) Tunneling
 Protocol (GTP), and the architecture allows for dual-stack and
 IPv6-only deployments.
 In a mobile network, the IPv4 address assignment for an MN is
 performed by the MNG.  In the 3GPP network architecture, this
 assignment is performed in conjunction with the Packet Data Network
 (PDN) connectivity establishment.  A PDN connection implies an end-
 end link (i.e., an 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 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 only one of the two traffic types (as in
 the existing 3G UMTS networks).  The IPv4 address is assigned at the
 time of PDN connectivity establishment or is assigned using DHCP
 after the PDN connectivity is established.  In order to delay the
 exhaustion of public IPv4 addresses, this IP address needs to be a
 private IPv4 address that is translated into a shared public IPv4

Koodli Informational [Page 5] RFC 6342 IPv6 in Mobile Networks August 2011

 address.  Hence, there is a need for a private-public IPv4
 translation mechanism in the mobile network.
 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
 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
 attaches to the network.  This could significantly affect the
 availability and usage of private IPv4 addresses.  One way to address
 this is by making the always-on PDN (that requires voice service) to
 be IPv6.  The IPv4 PDN is only established when the user needs it.
 The 3GPP standards also specify a deferred IPv4 address allocation on
 a dual-stack IPv4v6 PDN at the time of connection establishment.
 This has the advantage of a single PDN for IPv6 and IPv4 along with
 deferring IPv4 address allocation until an application needs it.  The
 deferred address allocation requires support for a dynamic
 configuration protocol such as DHCP as well as appropriate triggers
 to invoke the protocol.  Such a support does not exist today in
 mobile phones.  The newer iterations of smartphones could provide
 such support.  Also, the tethering of smartphones to laptops (which
 typically support DHCP) could use deferred allocation depending on
 when a laptop attaches to the smartphone.  Until appropriate triggers
 and host stack support is available, the applicability of the
 address-deferring option may be limited.
 On the other hand, in the existing 3G UMTS networks, there is no
 requirement for an always-on connection even though many smartphones
 seldom relinquish an established PDP context.  The existing so-called
 pre-Release-8 deployments do not support the dual-stack PDP
 connection.  Hence, two separate PDP connections are necessary to
 support IPv4 and IPv6 traffic.  Even though some MNs, especially the
 smartphones, in use today may have IPv6 stack, there are two
 remaining considerations.  First, there is little operational
 experience and compliance testing with these existing stacks.  Hence,
 it is expected that their use in large deployments may uncover
 software errors and interoperability problems that inhibit providing
 services based on IPv6 for such hosts.  Second, only a fraction of
 current phones in use have such a stack.  As a result, providers need
 to test, deploy, and operationalize IPv6 as they introduce new
 handsets, which also continue to need access to the predominantly
 IPv4 Internet.
 The considerations from the preceeding paragraphs lead to the
 following observations.  First, there is an increasing need to
 support private IPv4 addressing in mobile networks because of the

Koodli Informational [Page 6] RFC 6342 IPv6 in Mobile Networks August 2011

 public IPv4 address run-out problem.  Correspondingly, there is a
 greater need for private-public IPv4 translation in mobile networks.
 Second, there is support for IPv6 in both 3G and 4G LTE networks
 already in the form of PDP context and PDN connections.  To begin
 with, operators can introduce IPv6 for their own applications and
 services.  In other words, the IETF's recommended model of dual-stack
 IPv6 and IPv4 networks is readily applicable to mobile networks with
 the support for distinct APNs and the ability to carry IPv6 traffic
 on PDP/PDN connections.  The IETF dual-stack model can be applied
 using a single IPv4v6 PDN connection in Release-8 and onwards but
 requires separate PDP contexts in the earlier releases.  Finally,
 operators can make IPv6 the default for always-on mobile connections
 using either the IPv4v6 PDN or the IPv6 PDN and use IPv4 PDNs as
 necessary.

3.2. NAT Placement in Mobile Networks

 In the previous section, we observed that NAT44 functionality is
 needed in order to conserve the available pool and delay public IPv4
 address exhaustion.  However, the available private IPv4 pool itself
 is not abundant for large networks such as mobile networks.  For
 instance, the so-called NET10 block [RFC1918] has approximately 16.7
 million private IPv4 addresses starting with 10.0.0.0.  A large
 mobile service provider network can easily have more than 16.7
 million subscribers attached to the network at a given time.  Hence,
 the private IPv4 address pool management and the placement of NAT44
 functionality becomes important.
 In addition to the developments cited above, NAT placement is
 important for other reasons as well.  Access networks generally need
 to produce network and service usage records for billing and
 accounting.  This is true also for mobile networks where "subscriber
 management" features (i.e., QoS, Policy, and Billing and Accounting)
 can be fairly detailed.  Since a NAT introduces a binding between two
 addresses, the bindings themselves become necessary information for
 subscriber management.  For instance, the offered QoS on private IPv4
 address and the (shared) public IPv4 address may need to be
 correlated for accounting purposes.  As another example, the
 Application Servers within the provider network may need to treat
 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
 to inspect the NAT binding to disambiguate among the individual MNs.
 The subscriber session management information and the service usage
 information also need to be correlated in order to produce harmonized
 records.  Furthermore, there may be legal requirements for storing
 the NAT binding records.  Indeed, these problems disappear with the

Koodli Informational [Page 7] RFC 6342 IPv6 in Mobile Networks August 2011

 transition to IPv6.  For now, it suffices to assert that NAT
 introduces state, which needs to be correlated and possibly stored
 with other routine subscriber information.
 Mobile network deployments vary in their allocation of IP address
 pools.  Some network deployments use the "centralized model" where
 the pool is managed by a common node, such as the PDN's BR, and the
 pool shared by multiple MNGs all attached to the same BR.  This model
 has served well in the pre-3G deployments where the number of
 subscribers accessing the Mobile Internet at any given time has not
 exceeded the available address pool.  However, with the advent of 3G
 networks and the subsequent dramatic growth in the number of users on
 the Mobile Internet, service providers are increasingly forced to
 consider their existing network design and choices.  Specifically,
 providers are forced to address private IPv4 pool exhaustion as well
 as scalable NAT solutions.
 In order to tackle the private IPv4 exhaustion in the centralized
 model, there would be a need to support overlapped private IPv4
 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
 (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.
 Tunneling mechanisms such as Generic Routing Encapsulation (GRE)
 [RFC2784] [RFC2890], MPLS [RFC3031] VPN tunnels, or even IP-in-IP
 encapsulation [RFC2003] that can provide a unique identifier for a
 NAT session can be used to separate overlapping private IPv4 traffic
 as described in [GI-DS-LITE].  An advantage of centralizing the NAT
 and using the overlapped private IPv4 addressing is conserving the
 limited private IPv4 pool.  It also enables the operator's enterprise
 network to use IPv6 from the MNG to the BR; this (i.e., the need for
 an IPv6-routed enterprise network) may be viewed as an additional
 requirement by some providers.  The disadvantages include the need
 for additional protocols to correlate the NAT state (at the common
 node) with subscriber session information (at each of the gateways),
 suboptimal MN-MN communication, absence of subscriber-aware NAT (and
 policy) function, and, of course, the need for a protocol from the
 MNG to BR itself.  Also, if the NAT function were to experience
 failure, all the connected gateway service will be affected.  These
 drawbacks are not present in the "distributed" model, which we
 discuss in the following.
 In a distributed model, the private IPv4 address management is
 performed by the MNG, which also performs the NAT functionality.  In
 this model, each MNG has a block of 16.7 million unique addresses,
 which is sufficient compared to the number of mobile subscribers
 active on each MNG.  By distributing the NAT functionality to the
 edge of the network, each MNG is allowed to reuse the available NET10

Koodli Informational [Page 8] RFC 6342 IPv6 in Mobile Networks August 2011

 block, which avoids the problem of overlapped private IPv4 addressing
 at the network core.  In addition, since the MNG is where subscriber
 management functions are located, the NAT state correlation is
 readily enabled.  Furthermore, an MNG already has existing interfaces
 to functions such as AAA and PCRF, which allows it to perform
 subscriber management functions with the unique private IPv4
 addresses.  Finally, the MNG can also pass-through certain traffic
 types without performing NAT to the Application Servers located
 within the service provider's domain, which allows the servers to
 also identify subscriber sessions with unique private IPv4 addresses.
 The disadvantages of the "distributed model" include the absence of
 centralized addressing and centralized management of NAT.
 In addition to the two models described above, a hybrid model is to
 locate NAT in a dedicated device other than the MNG or the BR.  Such
 a model would be similar to the distributed model if the IP pool
 supports unique private addressing for the mobile nodes, or it would
 be similar to the centralized model if it supports overlapped private
 IP addresses.  In any case, the NAT device has to be able to provide
 the necessary NAT session binding information to an external entity
 (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.
 The foregoing discussion can be summarized as follows.  First, the
 management of the available private IPv4 pool has become important
 given the increase in Mobile Internet users.  Mechanisms that enable
 reuse of the available pool are required.  Second, in the context of
 private IPv4 pool management, the placement of NAT functionality has
 implications to the network deployment and operations.  The
 centralized models with a common NAT have the advantages of
 continuing their legacy deployments and the reuse of private IPv4
 addressing.  However, they need additional functions to enable
 traffic differentiation and NAT state correlation with subscriber
 state management at the MNG.  The distributed models also achieve
 private IPv4 address reuse and avoid overlapping private IPv4 traffic
 in the operator's core, but without the need for additional
 mechanisms.  Since the MNG performs (unique) IPv4 address assignment
 and has standard interfaces to AAA and PCRF, the distributed model
 also enables a single point for subscriber and NAT state reporting as
 well as policy application.  In summary, providers interested in
 readily integrating NAT with other subscriber management functions,
 as well as conserving and reusing their private IPv4 pool, may find
 the distributed model compelling.  On the other hand, those providers
 interested in common management of NAT may find the centralized model
 more compelling.

Koodli Informational [Page 9] RFC 6342 IPv6 in Mobile Networks August 2011

3.3. IPv6-Only Deployment Considerations

 As we observed in the previous section, the presence of NAT
 functionality in the network brings up multiple issues that would
 otherwise be absent.  NAT should be viewed as an interim solution
 until IPv6 is widely available, i.e., IPv6 is available for mobile
 users for all (or most) practical purposes.  Whereas NATs at provider
 premises may slow down the exhaustion of public IPv4 addresses,
 expeditious and simultaneous introduction of IPv6 in the operational
 networks is necessary to keep the Internet "going and growing".
 Towards this goal, it is important to understand the considerations
 in deploying IPv6-only networks.
 There are three dimensions to IPv6-only deployments: the network
 itself, the mobile nodes, and the applications, represented by the
 3-tuple {nw, mn, ap}.  The goal is to reach the coordinate {IPv6,
 IPv6, IPv6} from {IPv4, IPv4, IPv4}.  However, there are multiple
 paths to arrive at this goal.  The classic dual-stack model would
 traverse the coordinate {IPv4v6, IPv4v6, IPv4v6}, where each
 dimension supports co-existence of IPv4 and IPv6.  This appears to be
 the path of least disruption, although we are faced with the
 implications of supporting large-scale NAT in the network.  There is
 also the cost of supporting separate PDP contexts in the existing 3G
 UMTS networks.  The other intermediate coordinate of interest is
 {IPv6, IPv6, IPv4}, where the network and the MN are IPv6-only, and
 the Internet applications are recognized to be predominantly IPv4.
 This transition path would, ironically, require interworking between
 IPv6 and IPv4 in order for the IPv6-only MNs to be able to access
 IPv4 services and applications on the Internet.  In other words, in
 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
 the placement of NAT for IPv6-IPv4 interworking.  There is no
 overlapping private IPv4 address problem because each IPv6 address is
 unique and there are plenty of them available.  Hence, there is also
 no requirement for (IPv6) address reuse, which means no protocol is
 necessary in the centralized model to disambiguate NAT sessions.
 However, there is an additional requirement of DNS64 [RFC6147]
 functionality for IPv6-IPv4 translation.  This DNS64 functionality
 must ensure that the synthesized AAAA record correctly maps to the
 IPv6-IPv4 translator.
 IPv6-only deployments in mobile networks need to reckon with the
 following considerations.  First, both the network and the MNs need
 to be IPv6 capable.  Expedited network upgrades as well as rollout of
 MNs with IPv6 would greatly facilitate this.  Fortunately, the 3GPP
 network design for LTE already requires the network nodes and the

Koodli Informational [Page 10] RFC 6342 IPv6 in Mobile Networks August 2011

 mobile nodes to support IPv6.  Even though there are no requirements
 for the transport network to be IPv6, an operational IPv6
 connectivity service can be deployed with appropriate existing
 tunneling mechanisms in the IPv4-only transport network.  Hence, a
 service provider may choose to enforce IPv6-only PDN and address
 assignment for their own subscribers in their Home Networks (see
 Figure 1).  This is feasible for the newer MNs when the mobile
 network is able to provide IPv6-only PDN support and IPv6-IPv4
 interworking for Internet access.  For the existing MNs, however, the
 provider still needs to be able to support IPv4-only PDP/PDN
 connectivity.
 Migration of applications to IPv6 in MNs with IPv6-only PDN
 connectivity brings challenges.  The applications and services
 offered by the provider obviously need to be IPv6-capable.  However,
 an MN may host other applications, which also need to be IPv6-capable
 in IPv6-only deployments.  This can be a "long-tail" phenomenon;
 however, when a few prominent applications start offering IPv6, there
 can be a strong incentive to provide application-layer (e.g., socket
 interface) upgrades to IPv6.  Also, some IPv4-only applications may
 be able to make use of alternative access such as WiFi when
 available.  A related challenge in the migration of applications is
 the use of IPv4 literals in application layer protocols (such as
 XMPP) or content (as in HTML or XML).  Some Internet applications
 expect their clients to supply IPv4 addresses as literals, and this
 will not be possible with IPv6-only deployments.  Some of these
 experiences and the related considerations in deploying an IPv6-only
 network are documented in [ARKKO-V6].  In summary, migration of
 applications to IPv6 needs to be done, and such a migration is not
 expected to be uniform across all subsets of existing applications.
 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 on its
 duration.  Such a separation of signaling and the payload is unique
 to voice, whereas an Internet connection is accounted without
 specifically considering application signaling and payload traffic.
 This model is expected to be supported even during roaming.
 Furthermore, providers and users generally require voice service
 regardless of roaming, whereas Internet usage is subject to
 subscriber preferences and roaming agreements.  This requirement to
 ubiquitously support voice service while providing the flexibility
 for Internet usage exacerbates the addressing problem and may hasten
 provisioning of VoLTE using the IPv6-only PDN.
 As seen earlier, roaming is unique to mobile networks, and it
 introduces new challenges.  Service providers can control their own
 network design but not their peers' networks, which they rely on for

Koodli Informational [Page 11] RFC 6342 IPv6 in Mobile Networks August 2011

 roaming.  Users expect uniformity in experience even when they are
 roaming.  This imposes a constraint on providers interested in
 IPv6-only deployments to also support IPv4 addressing when their own
 (outbound) subscribers roam to networks that do not offer IPv6.  For
 instance, when an LTE deployment is IPv6-only, a roamed 3G network
 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
 not be possible to enable IPv6 PDN connectivity without roamed
 network support.  These considerations also apply when the visited
 network is used for offering services such as VoLTE in the so-called
 Local Breakout model; the roaming MN's capability as well as the
 roamed network capability to support VoLTE using IPv6 determine
 whether fallback to IPv4 would be necessary.  Similarly, there are
 inbound roamers to an IPv6-ready provider network whose MNs are not
 capable of IPv6.  The IPv6-ready provider network has to be able to
 support IPv4 PDN connectivity for such inbound roamers.  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 and offer it as a ubiquitous service that can be
 accounted for.
 In summary, IPv6-only deployments should be encouraged alongside the
 dual-stack model, which is the recommended IETF approach.  This is
 relatively straightforward for an operator's own services and
 applications, provisioned through an appropriate APN and the
 corresponding IPv6-only PDP or EPS bearer.  Some providers may
 consider IPv6-only deployment for Internet access as well, and this
 would require IPv6-IPv4 interworking.  When the IPv6-IPv4 translation
 mechanisms are used in IPv6-only deployments, the protocols and the
 associated considerations specified in [RFC6146] and [RFC6145] apply.
 Finally, such IPv6-only deployments can be phased-in for newer mobile
 nodes, while the existing ones continue to demand IPv4-only
 connectivity.
 Roaming is important in mobile networks, and roaming introduces
 diversity in network deployments.  Until IPv6 connectivity is
 available in all mobile networks, IPv6-only mobile network
 deployments need to be prepared to support IPv4 connectivity (and
 NAT44) for their own outbound roaming users as well as for inbound
 roaming users.  However, by taking the initiative to introduce IPv6-
 only for the newer MNs, the mobile networks can significantly reduce
 the demand for private IPv4 addresses.

Koodli Informational [Page 12] RFC 6342 IPv6 in Mobile Networks August 2011

3.4. Fixed-Mobile Convergence

 Many service providers have both fixed broadband and mobile networks.
 Access networks are generally disparate, with some common
 characteristics but with enough differences to make it challenging to
 achieve "convergence".  For instance, roaming is not a consideration
 in fixed access networks.  An All-IP mobile network service provider
 is required to provide voice service, whereas this is not required
 for a fixed network provider.  A "link" in fixed networks is
 generally capable of carrying IPv6 and IPv4 traffic, whereas not all
 mobile networks have "links" (i.e., PDP/PDN connections) capable of
 supporting IPv6 and IPv4.  Indeed, roaming makes this problem worse
 when a portion of the link (i.e., the Home Network in Figure 1) is
 capable of supporting IPv6 and the other portion of the link (i.e.,
 the Visited Network in Figure 1) is not.  Such architectural
 differences, as well as policy and business model differences make
 convergence challenging.
 Nevertheless, within the same provider's space, some common
 considerations may apply.  For instance, IPv4 address management is a
 common concern for both of the access networks.  This implies that
 the same mechanisms discussed earlier, i.e., delaying IPv4 address
 exhaustion and introducing IPv6 in operational networks, apply for
 the converged networks as well.  However, the exact solutions
 deployed for each access network can vary for a variety of reasons,
 such as:
 o  Tunneling of private IPv4 packets within IPv6 is feasible in fixed
    networks where the endpoint is often a cable or DSL modem.  This
    is not the case in mobile networks where the endpoint is an MN
    itself.
 o  Encapsulation-based mechanisms such as 6rd [RFC5969] are useful
    where the operator is unable to provide native or direct IPv6
    connectivity and a residential gateway can become a tunnel
    endpoint for providing this service.  In mobile networks, the
    operator could provide IPv6 connectivity using the existing mobile
    network tunneling mechanisms without introducing an additional
    layer of tunneling.
 o  A mobile network provider may have Application Servers (e.g., an
    email server) in its network that require unique private IPv4
    addresses for MN identification, whereas a fixed network provider
    may not have such a requirement or the service itself.
 These examples illustrate that the actual solutions used in an access
 network are largely determined by the requirements specific to that
 access network.  Nevertheless, some sharing between an access and

Koodli Informational [Page 13] RFC 6342 IPv6 in Mobile Networks August 2011

 core network may be possible depending on the nature of the
 requirement and the functionality itself.  For example, when a fixed
 network does 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
 common core network.  Hence, common solutions can be more easily
 applied in the core network.  For instance, configured tunnels or
 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
 network is IPv6-enabled.
 There can also be considerations due to the use of NAT in access
 networks.  Solutions such as Femto Networks rely on a fixed Internet
 connection being available for the Femto Base Station to communicate
 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
 mobile network access through the Femto Base Station will be subject
 to NAT policy administration including periodic cleanup and purge of
 NAT state.  Such policies affect the usability of the Femto Network
 and have implications to the mobile network provider.  Using IPv6 for
 the Femto (or any other access technology) could alleviate some of
 these concerns if the IPv6 communication could bypass the NAT.
 In summary, there is interest in Fixed-Mobile Convergence, at least
 among some providers.  While there are benefits to harmonizing the
 network as much as possible, there are also idiosyncrasies of
 disparate access networks that influence the convergence.  Perhaps
 greater harmonization is feasible at the higher service layers, e.g.,
 in terms of offering unified user experience for services and
 applications.  Some harmonization of functions across access networks
 into the core network may be feasible.  A provider's core network
 appears to be the place where most convergence is feasible.

4. Summary and Conclusion

 IPv6 deployment in mobile networks is crucial for the Mobile
 Internet.  In this document, we discussed the considerations in
 deploying IPv6 in mobile networks.  We summarize the discussion in
 the following:

Koodli Informational [Page 14] RFC 6342 IPv6 in Mobile Networks August 2011

 o  IPv4 address exhaustion and its implications to mobile networks:
    As mobile service providers begin to deploy IPv6, conserving their
    available IPv4 pool implies the need for network address
    translation in mobile networks.  At the same time, providers can
    make use of the 3GPP architecture constructs such as APN and PDN
    connectivity to introduce IPv6 without affecting the predominantly
    IPv4 Internet access.  The IETF dual-stack model [RFC4213] can be
    applied to the mobile networks readily.
 o  The placement of NAT functionality in mobile networks: Both the
    centralized and distributed models of private IPv4 address pool
    management have their relative merits.  By enabling each MNG to
    manage its own NET10 pool, the distributed model achieves reuse of
    the available private IPv4 pool and avoids the problems associated
    with the non-unique private IPv4 addresses for the MNs without
    additional protocol mechanisms.  The distributed model also
    augments the "subscriber management" functions at an MNG, such as
    readily enabling NAT session correlation with the rest of the
    subscriber session state.  On the other hand, existing deployments
    that have used the centralized IP address management can continue
    their legacy architecture by placing the NAT at a common node.
    The centralized model also achieves private IPv4 address reuse but
    needs additional protocol extensions to differentiate overlapping
    addresses at the common NAT as well as to integrate with policy
    and billing infrastructure.
 o  IPv6-only mobile network deployments: This deployment model is
    feasible in the LTE architecture for an operator's own services
    and applications.  The existing MNs still expect IPv4 address
    assignment.  Furthermore, roaming, which is unique to mobile
    networks, requires that a provider support IPv4 connectivity when
    its (outbound) users roam into a mobile network that is not IPv6-
    enabled.  Similarly, a provider needs to support IPv4 connectivity
    for (inbound) users whose MNs are not IPv6-capable.  The IPv6-IPv4
    interworking is necessary for IPv6-only MNs to access the IPv4
    Internet.
 o  Fixed-Mobile Convergence: The examples discussed illustrate the
    differences in the requirements of fixed and mobile networks.
    While some harmonization of functions may be possible across the
    access networks, the service provider's core network is perhaps
    better-suited for converged network architecture.  Similar gains
    in convergence are feasible in the service and application layers.

Koodli Informational [Page 15] RFC 6342 IPv6 in Mobile Networks August 2011

5. Security Considerations

 This document does not introduce any new security vulnerabilities.

6. Acknowledgements

 This document has benefitted from discussions with and reviews from
 Cameron Byrne, David Crowe, Hui Deng, Remi Despres, Fredrik Garneij,
 Jouni Korhonen, Teemu Savolainen, and Dan Wing.  Thanks to all of
 them.  Many thanks to Mohamed Boucadair for providing an extensive
 review of a draft version of this document.  Cameron Byrne, Kent
 Leung, Kathleen Moriarty, and Jari Arkko provided reviews that helped
 improve this document.  Thanks to Nick Heatley for providing valuable
 review and input on VoLTE.

7. Informative References

 [3GPP.3G]     "General Packet Radio Service (GPRS); Service
               description; Stage 2, 3GPP TS 23.060, December 2006".
 [3GPP.4G]     "General Packet Radio Service (GPRS) enhancements for
               Evolved Universal Terrestrial Radio Access Network
               (E-UTRAN) access", 3GPP TS 23.401 8.8.0, December 2009.
 [3GPP2.EHRPD] "E-UTRAN - eHRPD Connectivity and Interworking: Core
               Network Aspects", http://www.3gpp2.org/public_html/
               Specs/X.S0057-0_v1.0_090406.pdf.
 [RFC1918]     Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,
               G., and E. Lear, "Address Allocation for Private
               Internets", 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.

Koodli Informational [Page 16] RFC 6342 IPv6 in Mobile Networks August 2011

 [RFC4213]     Nordmark, E. and R. Gilligan, "Basic Transition
               Mechanisms for IPv6 Hosts and Routers", RFC 4213,
               October 2005.
 [RFC5969]     Townsley, W. and O. Troan, "IPv6 Rapid Deployment on
               IPv4 Infrastructures (6rd) -- Protocol Specification",
               RFC 5969, August 2010.
 [RFC6145]     Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
               Algorithm", RFC 6145, April 2011.
 [RFC6146]     Bagnulo, M., Matthews, P., and I. van Beijnum,
               "Stateful NAT64: Network Address and Protocol
               Translation from IPv6 Clients to IPv4 Servers", RFC
               6146, April 2011.
 [RFC6147]     Bagnulo, M., Sullivan, A., Matthews, P., and I. van
               Beijnum, "DNS64: DNS Extensions for Network Address
               Translation from IPv6 Clients to IPv4 Servers", RFC
               6147, April 2011.
 [ARKKO-V6]    Arkko, J. and A. Keranen, "Experiences from an
               IPv6-Only Network", Work in Progress, April 2011.
 [GI-DS-LITE]  Brockners, F., Gundavelli, S., Speicher, S., and D.
               Ward, "Gateway Initiated Dual-Stack Lite Deployment",
               Work in Progress, July 2011.

Author's Address

 Rajeev Koodli
 Cisco Systems
 USA
 EMail: rkoodli@cisco.com

Koodli Informational [Page 17]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6342.txt · Last modified: 2011/08/01 15:45 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki