draft-ietf-v6ops-v6-in-mobile-networks-04.txt   draft-ietf-v6ops-v6-in-mobile-networks-05.txt 
v6ops Working Group Rajeev. Koodli v6ops Working Group Rajeev. Koodli
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Informational April 25, 2011 Intended status: Informational May 19, 2011
Expires: October 27, 2011 Expires: November 20, 2011
Mobile Networks Considerations for IPv6 Deployment Mobile Networks Considerations for IPv6 Deployment
draft-ietf-v6ops-v6-in-mobile-networks-04.txt draft-ietf-v6ops-v6-in-mobile-networks-05.txt
Abstract Abstract
Mobile Internet access from smartphones and other mobile devices is Mobile Internet access from smartphones and other mobile devices is
accelerating the exhaustion of IPv4 addresses. IPv6 is widely seen accelerating the exhaustion of IPv4 addresses. IPv6 is widely seen
as crucial for the continued operation and growth of the Internet, as crucial for the continued operation and growth of the Internet,
and in particular, it is critical in mobile networks. This document and in particular, it is critical in mobile networks. This document
discusses the issues that arise when deploying IPv6 in mobile discusses the issues that arise when deploying IPv6 in mobile
networks. Hence, this document can be a useful reference for service networks. Hence, this document can be a useful reference for service
providers and network designers. providers and network designers.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 28, 2011. This Internet-Draft will expire on November 20, 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 7, line 18 skipping to change at page 7, line 18
when a laptop attaches to the Smartphone. Until appropriate triggers when a laptop attaches to the Smartphone. Until appropriate triggers
and host stack support is available, the applicability of the address and host stack support is available, the applicability of the address
deferring option may be limited. deferring option may be limited.
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. The existing so-called seldom relinquish an established PDP context. The existing so-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, there are two
not tested for compliance and deployment in operational networks. remaining considerations. First, there is little operational
Without compliance to network requirements, providers cannot reliably experience and compliance testing with these existing stacks. Hence,
provision services. Given these considerations, it is reasonable to it is expected that their use in large deployments may uncover
expect that the providers can offer connectivity and services based software errors and interoperability problems which inhibit providing
on IPv6 in the MNs which are not already in use today. And, such services based on IPv6 for such hosts. Second, only a fraction of
newer MNs still need to be able to access the predominantly IPv4 current phones in use have such a stack. As a result, providers need
Internet. 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 The considerations from the preceeding paragraphs lead to the
following observations. First, there is an increasing need to following observations. First, there is an increasing need to
support private IPv4 addressing in mobile networks because of the support private IPv4 addressing in mobile networks because of the
public IPv4 address run-out problem. Correspondingly, there is a public IPv4 address run-out problem. Correspondingly, there is a
greater need for private - public IPv4 translation in the mobile greater need for private - public IPv4 translation in the mobile
networks. Second, there is support for IPv6 in both 3G and 4G LTE 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 networks already in the form of PDP context and PDN connections. To
begin with, the operators can introduce IPv6 for their own begin with, the operators can introduce IPv6 for their own
applications and services. In other words, the IETF's recommended applications and services. In other words, the IETF's recommended
skipping to change at page 9, line 4 skipping to change at page 9, line 6
the providers are forced to address private IPv4 pool exhaustion as the providers are forced to address private IPv4 pool exhaustion as
well as scalable NAT solutions. well as scalable NAT solutions.
In order to tackle 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.
Tunneling mechanisms such as Generic Routing Encapsulation (GRE) Tunneling mechanisms such as Generic Routing Encapsulation (GRE)
[RFC2784], [RFC2890], MPLS [RFC3031] VPN tunnels or even IP-in-IP [RFC2784], [RFC2890], MPLS [RFC3031] VPN tunnels or even IP-in-IP
encapsulation [RFC2003] which can provide a unique identifier for a encapsulation [RFC2003] which can provide a unique identifier for a
NAT session can be used to separate overlapping private IPv4 traffic NAT session can be used to separate overlapping private IPv4 traffic
as described in [gi-ds-lite]. An obvious advantage of centralizing as described in [gi-ds-lite]. An advantage of centralizing the NAT
the NAT and using overlapped private IPv4 addressing is that a large and using the overlapped private IPv4 addressing is conserving the
number of mobile subscribers can be supported with a common limited limited private IPv4 pool. It also enables the operator's enterprise
pool at the BR. It also enables the operator's enterprise network to network to use IPv6 from the MNG to the BR; this (i.e., the need for
use IPv6 from the MNG to the BR; this (i.e., the need for an IPv6- an IPv6-routed enterprise network) may be viewed as an additional
routed enterprise network) may be viewed as an additional requirement requirement by some providers. The disadvantages include the need
by some providers. The disadvantages include the need for additional for additional protocol to correlate the NAT state (at the common
protocol to correlate the NAT state (at the common node) with node) with subscriber session information (at each of the gateways),
subscriber session information (at each of the gateways), suboptimal suboptimal MN - MN communication, absence of subscriber-aware NAT
MN - MN communication, absence of subscriber-aware NAT (and policy) (and policy) function, and of course the need for a protocol from the
function, and of course the need for a protocol from the MNG to BR MNG to BR itself. Also, if the NAT function were to experience
itself. Also, if the NAT function were to experience failure, all failure, all the connected gateway service will be affected. These
the connected gateway service will be affected. These drawbacks are drawbacks are not present in the "distributed" model which we discuss
not present in the "distributed" model which we discuss in the in the following.
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
skipping to change at page 14, line 10 skipping to change at page 14, line 10
exhaustion and introducing IPv6 in operational networks, apply for exhaustion and introducing IPv6 in operational networks, apply for
the converged networks as well. However, the exact solutions the converged networks as well. However, the exact solutions
deployed for each access network can vary for a variety of reasons. deployed for each access network can vary for a variety of reasons.
For instance: For instance:
o Tunneling of private IPv4 packets within IPv6 is feasible in o Tunneling of private IPv4 packets within IPv6 is feasible in
fixed networks where the end-point is often a cable or DSL modem. fixed 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 This is not the case in mobile networks where the end-point is a
MN itself. MN itself.
o Encapsulation-based mechanisms such as 6rd [RFC5969] are o Encapsulation-based mechanisms such as 6rd [RFC5969] are useful
feasible where a residential gateway can become a tunnel end-point where the operator is unable to provide native or direct IPv6
for connecting subscribers to IPv6-only networks, whereas connectivity and a residential gateway can become a tunnel end-
translation is perhaps necessary for IPv6-only mobile networks. point 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 o A mobile network provider may have application servers (e.g., an
email server) in its network that require unique private IPv4 email server) in its network that require unique private IPv4
addresses for MN identification, whereas a fixed network provider addresses for MN identification, whereas a fixed network provider
may not have such a requirement or the service itself. may not have such a requirement or the service itself.
These examples illustrate that the actual solutions used in an access These examples illustrate that the actual solutions used in an access
network are largely determined by the requirements specific to that network are largely determined by the requirements specific to that
access network. Nevertheless, some sharing between access and core access network. Nevertheless, some sharing between access and core
network may be possible depending on the nature of the requirement network may be possible depending on the nature of the requirement
skipping to change at page 18, line 14 skipping to change at page 18, line 19
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: More IESG reviews
o: Addressed IESG reviews o: Addressed IESG reviews
o: VoLTE related text
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.
 End of changes. 9 change blocks. 
32 lines changed or deleted 39 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/