draft-ietf-v6ops-v6-in-mobile-networks-01.txt   draft-ietf-v6ops-v6-in-mobile-networks-02.txt 
v6ops Working Group Rajeev. Koodli v6ops Working Group Rajeev. Koodli
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Informational July 12, 2010 Intended status: Informational October 26, 2010
Expires: January 13, 2011 Expires: April 29, 2011
Mobile Networks Considerations for IPv6 Deployment Mobile Networks Considerations for IPv6 Deployment
draft-ietf-v6ops-v6-in-mobile-networks-01.txt draft-ietf-v6ops-v6-in-mobile-networks-02.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 January 13, 2011. This Internet-Draft will expire on April 29, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 14 skipping to change at page 2, line 14
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 . . . . . . . . . . . 9 3.3. IPv6-only Deployment Considerations . . . . . . . . . . . 10
3.4. Fixed - Mobile Convergence . . . . . . . . . . . . . . . . 12 3.4. Fixed - Mobile Convergence . . . . . . . . . . . . . . . . 12
4. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 13 4. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Informative References . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 16 8. Informative References . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
The dramatic growth of the Mobile Internet is accelerating the The dramatic growth of the Mobile Internet is accelerating the
exhaustion of available IPv4 addressing pool. It is widely accepted exhaustion of available IPv4 addressing pool. It is widely accepted
that IPv6 is necessary for the continued operation, and growth of the that IPv6 is necessary for the continued operation, and growth of the
Internet in general, and that of the Mobile Internet in particular. Internet in general, and that of the Mobile Internet in particular.
When deploying IPv6 in mobile networks, certain unique challenges While IPv6 brings many benefits, certain unique challenges arise when
arise. This document describes such challenges, and outlines the deploying it in mobile networks. This document describes such
applicability of the existing IPv6 deployment solutions. As such, it challenges, and outlines the applicability of the existing IPv6
can be a useful reference document for service providers as well as deployment solutions. As such, it can be a useful reference document
network designers. This document does not propose any new protocols for service providers as well as network designers. This document
or suggest new protocol specification work. does not propose any new protocols or suggest new protocol
specification work.
The primary considerations that we address in this document on IPv6 The primary considerations that we address in this document on IPv6
deployment in mobile networks are: deployment in mobile networks are:
o Public and Private IPv4 address exhaustion and implications to o Public and Private IPv4 address exhaustion and implications to
mobile network deployment architecture; mobile network deployment architecture;
o Placement of Network Address Translation (NAT) functionality and o Placement of Network Address Translation (NAT) functionality and
its implications; its implications;
o IPv6-only deployment considerations and roaming; o IPv6-only deployment considerations and roaming implications;
o Fixed-Mobile Convergence and implications to overall o Fixed-Mobile Convergence and implications to overall
architecture. architecture.
In the following sections, we discuss each of these in detail. In the following sections, we discuss each of these in detail.
For the most part, we assume the 3GPP 3G and 4G network architectures For the most part, we assume the 3GPP 3G and 4G network architectures
specified in [3gpp.3g] and [3gpp.4g]. However, the considerations specified in [3gpp.3g] and [3gpp.4g]. However, the considerations
are general enough for other mobile network architectures as well are general enough for other mobile network architectures as well
[3gpp2.ehrpd]. [3gpp2.ehrpd].
skipping to change at page 4, line 38 skipping to change at page 4, line 38
architecture, a MN accesses the network by connecting to an Access architecture, a MN accesses the network by connecting to an Access
Point Name (APN), which maps to a mobile gateway. Roughly speaking, Point Name (APN), which maps to a mobile gateway. Roughly speaking,
an APN is similar to an SSID in wireless LAN. An APN is a logical an APN is similar to an SSID in wireless LAN. An APN is a logical
concept which can be used to specify what kinds of services, such as concept which can be used to specify what kinds of services, such as
Internet access, high-definition video streaming, content-rich Internet access, high-definition video streaming, content-rich
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-end) 'link' to the gateway, which is realized through a (an end-to-end) 'link' to the gateway, which is realized through an
Packet Data Network (PDN) connection in the Long-term Evolution (LTE) Evolved Packet System (EPS) bearer in the Long-term Evolution (LTE)
networks, and through a Packet Data Protocol Context/connection in 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 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.
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
skipping to change at page 5, line 24 skipping to change at page 5, line 24
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
the subsequent authorization for connectivity and services is the subsequent authorization for connectivity and services is
provided using the "Home Subscriber Server" (HSS) functionality. provided using the "Home Location Register" (HLR)/"Home Subscriber
Server" (HSS) functionality.
o PCRF: Policy and Charging Rule Function enables applying policy o PCRF: Policy and Charging Rule Function enables applying policy
and charging rules at the MNG. and charging rules at the MNG.
In the rest of this document, we use the terms operator, service In the rest of this document, we use the terms operator, service
provider or provider interchangeably. provider or provider interchangeably.
3. IPv6 Considerations 3. IPv6 Considerations
3.1. IPv4 Address Exhaustion 3.1. IPv4 Address Exhaustion
It is generally agreed that the pool of public IPv4 addressing is It is generally agreed that the pool of public IPv4 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' towards the end of 2011.
Subsequently, the addressing pool available to RIRs for assignment to Subsequently, the addressing pool available to RIRs for assignment to
Internet Service Providers is anticipated to run-out in the following Internet Service Providers is anticipated to run-out in the following
2-3 years. This has led to a hightened awareness among the providers 2-3 years. This has led to a heightened awareness among the
to consider introducing technologies to keep the Internet providers to consider introducing technologies to keep the Internet
operational. There are two simultaneous approaches to addressing the operational. There are two simultaneous approaches to addressing the
run-out problem: delaying the IPv4 address exhaustion, and run-out problem: delaying the IPv4 address exhaustion, and
introducing IPv6 in operational networks. We consider both in the introducing IPv6 in 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). Mechanisms such as a address (with the use of extended port ranges). A mechanism such as
Network Address Translator (NAT) and "A+P" are used at the provider the Network Address Translator (NAT) is used at the provider premises
premises (as opposed to customer premises in the existing (as opposed to customer premises in the existing deployments) to
deployments) to manage IP address assignment and access to the manage IP address assignment and access to the Internet. In the
Internet. In the following, we primarily focus on translation based following, we primarily focus on translation based mechanisms such as
mechanisms such as NAT44 (i.e., translation from public IPv4 to NAT44 (i.e., translation from public IPv4 to private IPv4 and vice
private IPv4 and vice versa) and NAT64 (i.e., translation from public versa) and NAT64 (i.e., translation from public IPv6 to public IPv4
IPv6 to public IPv4 and vice versa). and vice versa); we do this because the 3GPP architecture already
defines a tunneling infrastructure with the GPRS Tunneling Protocol
(GTP), and the architecture allows for dual-stack and IPv6-only
deployments.
In a mobile network, the IPv4 address assignment for a MN is In a mobile network, the IPv4 address assignment for a MN is
performed by the MNG. In the 3GPP network architecture, this performed by the MNG. In the 3GPP network architecture, this
assignment is performed in conjunction with the PDN connectivity assignment is performed in conjunction with the PDN connectivity
establishment. As mentioned earlier, a PDN can be understood to be establishment. As mentioned earlier, a PDN can be understood to be
the end-end link from the MN to the MNG. There can be one or more the end-to-end link from the MN to the MNG. There can be one or more
PDN connections active at any given time for each MN. A PDN PDN connections active at any given time for each MN. A PDN
connection may support both IPv4 and IPv6 traffic (as in a dual-stack connection may support both IPv4 and IPv6 traffic (as in a dual-stack
PDN in 4G LTE networks) or it may support either one only (as in the PDN in 4G LTE networks) or it may support either one only (as in the
existing 3G UMTS networks). The IPv4 address is assigned at the time existing 3G UMTS networks). The IPv4 address is assigned at the time
of PDN connectivity establishment, or is assigned using the DHCP of PDN connectivity establishment, or is assigned using the DHCP
protocol after the PDN connectivity is established. In order to protocol after the PDN connectivity is established. In order to
delay the exhaustion of public IPv4 addresses, this IP address needs delay the exhaustion of public IPv4 addresses, this IP address needs
to be a private IPv4 address which is translated into a shared public to be a private IPv4 address which is translated into a shared public
IPv4 address. Hence, there is a need for private - public IPv4 IPv4 address. Hence, there is a need for private - public IPv4
translation mechanism in the mobile network. translation mechanism in the mobile network.
skipping to change at page 6, line 40 skipping to change at page 6, line 44
user in the All-IP network. If this PDN connection were to use IPv4 user in the All-IP network. If this PDN connection were to use IPv4
addressing, a private IPv4 address is needed for every MN that addressing, a private IPv4 address is needed for every MN that
attaches to the network. This could significantly affect the attaches to the network. This could significantly affect the
availability and usage of private IPv4 addresses. 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 approach is to defer the allocation of IPv4 address deleted. Another option (specified in the 3GPP standards) is to
on a dual-stack IPv4v6 PDN at the time of connection establishment. defer the allocation of IPv4 address on a dual-stack IPv4v6 PDN at
This has the advantage of a single PDN for IPv6 and IPv4, along with the time of connection establishment. This has the advantage of a
deferring IPv4 address allocation until an application needs it. single PDN for IPv6 and IPv4, along with deferring IPv4 address
However, this requires support for a dynamic configuration protocol allocation until an application needs it. However, this requires
such as DHCP, which many cellular MNs do not support today; this may support for a dynamic configuration protocol such as DHCP, which many
very well change in the future releases. Besides, laptops using the cellular MNs do not support today for use over the cellular radio.
network interface cards (such as USB dongles) to connect to the This is changing with complementary access technologies, with many
cellular network typically support the DHCP protocol. In any case, Smartphones already supporting DHCP for user over WiFi. Besides,
there need to be appropriate triggers to initiate DHCP based on laptops using the network interface cards (such as USB dongles) to
application usage, as well as DHCP lease management based on connect to the cellular network typically support the DHCP protocol.
appropriate address management policies. Both the approaches have In any case, there need to be appropriate triggers to initiate DHCP
merits, and additional considerations, including the "keep alives" based on the application and interface usage, as well as DHCP lease
that MNs may potentially send to keep their IPv4 addresses active. management based on appropriate address management policies. These
considerations may limit the applicability of the address deferring
option.
On the other hand, in the existing 3G UMTS networks, there is no On the other hand, in the existing 3G UMTS networks, there is no
requirement for an always-on connection (a 'link' from the MN to the requirement for an always-on connection (a 'link' from the MN to the
MNG in 3G UMTS is referred to as a Packet Data Protocol (PDP) MNG in 3G UMTS is referred to as a Packet Data Protocol (PDP)
context/connection) even though many SmartPhones seldom relinquish an context/connection) even though many SmartPhones seldom relinquish an
established PDP context. And, the existing (so-called pre-Release-8) established PDP context. And, the existing (so-called pre-Release-8)
deployments do not support the dual-stack PDP connection. Hence two deployments do not support the dual-stack PDP connection. Hence two
separate PDP connections are necessary to support IPv4 and IPv6 separate PDP connections are necessary to support IPv4 and IPv6
traffic. Even though some MNs (especially the SmartPhones) in use traffic. Even though some MNs (especially the SmartPhones) in use
today may have IPv6 stack, such a capability is not tested (if any at today may have IPv6 stack, such a capability is not tested (if any at
skipping to change at page 8, line 4 skipping to change at page 8, line 10
instance, the so-called NET10 block [RFC1918] has approximately 16.7 instance, the so-called NET10 block [RFC1918] has approximately 16.7
million private IPv4 addresses starting with 10.0.0.0. A large million private IPv4 addresses starting with 10.0.0.0. A large
mobile service provider network can easily have more than 16.7 mobile service provider network can easily have more than 16.7
million subscribers attached to the network at a given time. Hence, million subscribers attached to the network at a given time. Hence,
the private IPv4 address pool management and the placement of NAT44 the private IPv4 address pool management and the placement of NAT44
functionality becomes important. functionality becomes important.
In addition to the developments cited above, NAT placement is In addition to the developments cited above, NAT placement is
important for other reasons. Access networks generally need to important for other reasons. Access networks generally need to
produce network and service usage records for billing and accounting. produce network and service usage records for billing and accounting.
This is true for mobile networks as well where "subscriber This is true for mobile networks as well where "subscriber
management" features (i.e., QoS, Policy, and Billing and Accounting) management" features (i.e., QoS, Policy, and Billing and Accounting)
can be fairly detailed. Since a NAT introduces a binding between two can be fairly detailed. Since a NAT introduces a binding between two
addresses, the bindings themselves become necessary information for addresses, the bindings themselves become necessary information for
subscriber management. For instance, the offered QoS on private IPv4 subscriber management. For instance, the offered QoS on private IPv4
address and the (shared) public IPv4 address may need to be address and the (shared) public IPv4 address may need to be
correlated. And, the subscriber session management information and correlated for accounting purposes. As another example, the
the service usage information also need to be correlated in order to Application Servers within the provider network may need to treat
produce harmonized records. Furthermore, there may be legal traffic based on policy provided by the PCRF. If the IP address seen
requirements for storing the NAT binding records. Indeed, these by these Application Servers is not unique, the PCRF needs to be able
problems disappear with the transition to IPv6. For now, it suffices to inspect the NAT binding to disambiguate among the individual MNs.
to state that NAT introduces state which needs to be correlated and And, the subscriber session management information and the service
possibly stored with other routine subscriber information. 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 transition to IPv6. For now, it suffices to state 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 Mobile network deployments vary in their allocation of IP address
pools. Some network deployments use the "centralized model" where pools. Some network deployments use the "centralized model" where
the pool is managed by a common node, such as the PDN's Border the pool is managed by a common node, such as the PDN's Border
Router, and the pool shared by multiple gateways all attached to the Router, and the pool shared by multiple gateways all attached to the
same BR. This model has served well in the pre-3G deployments where same BR. This model has served well in the pre-3G deployments where
the number of subscribers accessing the mobile Internet at any given the number of subscribers accessing the mobile Internet at any given
time perhaps did not exceed the available address pool. However, time, perhaps, has not exceeded the available address pool. However,
with the advent of 3G networks and the subsequent dramatic growth in with the advent of 3G networks and the subsequent dramatic growth in
the number of users on the mobile Internet, the service providers are the number of users on the mobile Internet, the service providers are
increasingly forced to consider their existing network design and increasingly forced to consider their existing network design and
choices. Specifically, the providers are forced to address private choices. Specifically, the providers are forced to address private
IPv4 pool exhaustion as well as scalable NAT solutions. IPv4 pool exhaustion as well as scalable NAT solutions.
In order to address the private IPv4 exhaustion in the "centralized In order to address the private IPv4 exhaustion in the centralized
model", there would be a need to support overlapped private IPv4 model, there would be a need to support overlapped private IPv4
addresses in the common NAT functionality as well as in each of the addresses in the common NAT functionality as well as in each of the
gateways. In other words, the IP addresses used by two or more MNs gateways. In other words, the IP addresses used by two or more MNs
(which may be attached to the same MNG) are very likely to overlap at (which may be attached to the same MNG) are very likely to overlap at
the centralized NAT, which needs to be able to differentiate traffic. the centralized NAT, which needs to be able to differentiate traffic.
The approach specified in [gi-ds-lite] is one way to achieve traffic The approach specified in [gi-ds-lite] is one way to achieve traffic
separation for overlapping private IPv4; the others include MPLS VPN separation for overlapping private IPv4; the others include MPLS VPN
tunnels or any tunneling mechanism with a unique identifier for the tunnels or any tunneling mechanism with a unique identifier for the
session. An obvious advantage of centralizing the NAT and using session. An obvious advantage of centralizing the NAT and using
overlapped private IPv4 addressing is that a large number of mobile overlapped private IPv4 addressing is that a large number of mobile
subscribers can be supported with a common limited pool at the BR. subscribers can be supported with a common limited pool at the BR.
It also enables the operator's enterprise network to use IPv6 from It also enables the operator's enterprise network to use IPv6 from
the MNG to the BR; this (i.e., the need for an IPv6-routed enterprise 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 network) may be viewed as an additional requirement by some
providers. The disadvantages include diminished subscriber providers. The disadvantages include diminished subscriber
management, need for additional protocol to correlate the NAT state management (compared to a subscriber-aware NAT), need for additional
(at the common node) with subscriber session information (at each of protocol to correlate the NAT state (at the common node) with
the gateways), suboptimal MN - MN communication, and of course the subscriber session information (at each of the gateways), suboptimal
need for a protocol from the MNG to BR itself. Also, if the NAT MN - MN communication, and of course the need for a protocol from the
function were to experience failure, all the connected gateway MNG to BR itself. Also, if the NAT function were to experience
service will be affected. These drawbacks are not present in the failure, all the connected gateway service will be affected. These
"distributed" model which we discuss in the following. drawbacks are not present in the "distributed" model which we discuss
in the following.
In a "distributed" model, the private IPv4 address management is In a distributed model, the private IPv4 address management is
performed by the MNG which also performs the NAT functionality. In performed by the MNG which also performs the NAT functionality. In
this model, each MNG has a block of 16.7 million unique addresses, this model, each MNG has a block of 16.7 million unique addresses,
which is sufficient compared to the number of mobile subscribers which is sufficient compared to the number of mobile subscribers
active on each MNG. By distributing the NAT functionality to the active on each MNG. By distributing the NAT functionality to the
edge of the network, each MNG is allowed to re-use the available edge of the network, each MNG is allowed to re-use the available
NET10 block, which avoids the problem of overlapped private IPv4 NET10 block, which avoids the problem of overlapped private IPv4
addressing at the network core. In addition, since the MNG is where addressing at the network core. In addition, since the MNG is where
subscriber management functions are located, the NAT state subscriber management functions are located, the NAT state
correlation is readily enabled. Furthermore, an MNG already has correlation is readily enabled. Furthermore, an MNG already has
existing interfaces to functions such as AAA and PCRF, which allows existing interfaces to functions such as AAA and PCRF, which allows
it to perform subscriber management functions with the unique private it to perform subscriber management functions with the unique private
IPv4 addresses. Finally, the MNG can also pass-through certain IPv4 addresses. Finally, the MNG can also pass-through certain
traffic types without performing NAT to the application servers traffic types without performing NAT to the application servers
located within the service provider's domain, which allows the located within the service provider's domain, which allows the
servers to also identify subscriber sessions with unique private IPv4 servers to also identify subscriber sessions with unique private IPv4
addresses. The disadvantages of the "distributed model" include the addresses. The disadvantages of the "distributed model" include the
absence of centralized addressing and centralized management of NAT. 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 The foregoing discussion can be summarized as follows: First, the
management of available private IPv4 pool has become important given management of available private IPv4 pool has become important given
the growth of the mobile Internet users. The mechanisms that enable the growth of the mobile Internet users. The mechanisms that enable
re-use of the available pool are required. Second, in the context of re-use of the available pool are required. Second, in the context of
private IPv4 pool management, the placement of NAT functionality has private IPv4 pool management, the placement of NAT functionality has
implications to the network deployment and operations. Whereas the implications to the network deployment and operations. Whereas the
"centralized" models with a common NAT have the advantages of centralized models with a common NAT have the advantages of
continuing their legacy deployments, re-use of private IPv4 continuing their legacy deployments, re-use of private IPv4
addressing, and centralized NAT, they need additional functions to addressing, and centralized NAT, they need additional functions to
enable traffic differentiation, and NAT state correlation with enable traffic differentiation, and NAT state correlation with
subscriber state management at the MNG. The "distributed" models subscriber state management at the MNG. The distributed models also
also achieve private IPv4 address re-use, and avoid overlapping achieve private IPv4 address re-use, and avoid overlapping private
private IPv4 traffic in the operator's core, but without the need for IPv4 traffic in the operator's core, but without the need for
additional mechanisms. They also readily enable subscriber awareness additional mechanisms. Since the MNG performs (unique) IPv4 address
since the (unique) IPv4 address management is performed by the MNG, assignment and has standard interfaces to AAA and PCRF, the
which already has well-defined interfaces to AAA, and PCRF. In distributed model also enables a single point for subscriber and NAT
summary, providers interested in readily integrating NAT with other state reporting as well as policy application. In summary, providers
subscriber management functions, as well as conserving and re-using interested in readily integrating NAT with other subscriber
their private IPv4 pool, may find the distributed model compelling. management functions, as well as conserving and re-using their
private IPv4 pool, may find the distributed model compelling, while
those interested in common management of NAT may find the cetralized
model more compelling.
3.3. IPv6-only Deployment Considerations 3.3. IPv6-only Deployment Considerations
As we observed in the previous section, the NAT functionality in the As we observed in the previous section, the NAT functionality in the
network brings multiple issues which would otherwise be not present network brings multiple issues which would otherwise be not present
with the end-end access. NAT should be viewed as an interim solution with the end-to-end access. NAT should be viewed as an interim
until IPv6 is widely available, i.e., IPv6 is available for mobile solution until IPv6 is widely available, i.e., IPv6 is available for
users for all (or most) practical purposes. Whereas NATs at provider mobile users for all (or most) practical purposes. Whereas NATs at
premises may slow down the exhaustion of public IPv4 addresses, provider premises may slow down the exhaustion of public IPv4
expeditious and simultaneous introduction of IPv6 in the operational addresses, expeditious and simultaneous introduction of IPv6 in the
networks is necessary to keep the "Internet going and growing". operational networks is necessary to keep the "Internet going and
Towards this goal, it is important to understand the considerations growing". Towards this goal, it is important to understand the
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, 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. The other
skipping to change at page 10, line 34 skipping to change at page 11, line 11
the IPv6-only MNs to be able to access IPv4 services and applications 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 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) - IPv4), we need to introduce another form of NAT (i.e., IPv6 - IPv4)
to expedite the adoption of IPv6. 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 no requirement for (IPv6) address re-use, which means no also no requirement for (IPv6) address re-use, which means no
protocol is necessary in the "centralized model" to disambiguiate NAT protocol is necessary in the centralized model to disambiguiate NAT
sessions. However, an IPv6 prefix is managed and assigned by the MNG sessions. However, there is an additional requirement of DNS64
(unlike in the "centralized" NAT44 model where address pool [dns64] functionality for IPv6 - IPv4 translation. This DNS64
management is common for all the gateways). Hence, the subscriber functionality must ensure that the synthesized AAAA record correctly
management functions for the IPv6 prefix are vastly simplified. maps to the IPv6 - IPv4 translator.
Furthermore, for NAT binding correlation, billing and accounting, as
well as for subscriber management, it may be beneficial to locate the
IPv6 - IPv4 interworking function at the MNG.
The IPv6-only deployments in mobile networks need to recknon 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
choose to enforce IPv6-only PDN and address assignment for their own choose to enforce IPv6-only PDN and address assignment for their own
subscribers in their Home Networks, see Figure 1. This is feasible subscribers in their Home Networks, see Figure 1. This is feasible
skipping to change at page 11, line 19 skipping to change at page 11, line 41
the provider still needs to be able to support IPv4-only PDP/PDN the provider still needs to be able to support IPv4-only PDP/PDN
connectivity. connectivity.
Migration of applications to IPv6 in MNs with IPv6-only PDN Migration of applications to IPv6 in MNs with IPv6-only PDN
connectivity brings challenges. The applications and services connectivity brings challenges. The applications and services
offered by the provider obviously need to be IPv6-capable. However, offered by the provider obviously need to be IPv6-capable. However,
a MN may host other applications which also need to be IPv6-capable a MN may host other applications which also need to be IPv6-capable
in IPv6-only deployments. This can be a "long-tail" phenomenon; in IPv6-only deployments. This can be a "long-tail" phenomenon;
however, when a few prominant applications start offering IPv6, there however, when a few prominant applications start offering IPv6, there
can be a strong incentive to provide application layer (e.g., socket can be a strong incentive to provide application layer (e.g., socket
interface) upgrades to IPv6. Furthermore, some IPv4-only interface) upgrades to IPv6. Also, some IPv4-only applications may
applications may be able to make use of alternative access such as be able to make use of alternative access such as WiFi when
WiFi when available. In summary, application migration to IPv6 needs available. A related challenge in the migration of applications is
to be done even though it is likely to take a while before all the use of IPv4 literals in application layer protocols (such as
applications migrate to IPv6. 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. These experiences
and the related considerations in deploying IPv6-only network are
documented in [arkko-v6]. In summary, application migration to IPv6
needs to be done even though it is anticipated to take a while before
all applications migrate to IPv6.
An important consideration in mobile networks is roaming, where users An important consideration in mobile networks is roaming, where users
may roam to networks operated by providers other than their own. The may roam to networks operated by providers other than their own. The
service providers can control their own network design but not their service providers can control their own network design but not their
peer's networks which they rely on for roaming. Perhaps more peer's networks which they rely on for roaming. Perhaps more
importantly, the users expect 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
skipping to change at page 12, line 49 skipping to change at page 13, line 28
Nevertheless, within the same provider's space, some common Nevertheless, within the same provider's space, some common
considerations may apply. For instance, IPv4 address management is a considerations may apply. For instance, IPv4 address management is a
common concern for both the access networks. This implies the same common concern for both the access networks. This implies the same
mechanisms discussed earlier, i.e., delaying IPv4 address exhaustion mechanisms discussed earlier, i.e., delaying IPv4 address exhaustion
and introducing IPv6 in operational networks, apply for the converged and introducing IPv6 in operational networks, apply for the converged
networks as well. However, the exact solutions deployed for each networks as well. However, the exact solutions deployed for each
access network can vary for a variety of reasons. Tunneling of access network can vary for a variety of reasons. Tunneling of
private IPv4 packets within IPv6, for example, is feasible in fixed private IPv4 packets within IPv6, for example, is feasible in fixed
networks where the end-point is often a cable or DSL modem. This is networks where the end-point is often a cable or DSL modem. This is
not the case in mobile networks where the end-point is a MN itself. not the case in mobile networks where the end-point is a MN itself.
Similarly, encapsulation-based mechanisms such as 6rd [6rd] are Similarly, encapsulation-based mechanisms such as 6rd [RFC5969] are
feasible where a residential gateway can become a tunnel end-point feasible where a residential gateway can become a tunnel end-point
for connecting subscribers to IPv6-only networks, whereas translation for connecting subscribers to IPv6-only networks, whereas translation
is perhaps necessary for IPv6-only mobile networks. A mobile network is perhaps necessary for IPv6-only mobile networks. A mobile network
provider may have application servers (e.g., an email server) in its provider may have application servers (e.g., an email server) in its
network that require unique private IPv4 addresses for MN network that require unique private IPv4 addresses for MN
identification, whereas a fixed network provider may not have such a identification, whereas a fixed network provider may not have such a
requirement or the service itself. These examples illustrate that requirement or the service itself. These examples illustrate that
the actual solutions used in an access network are largely determined the actual solutions used in an access network are largely determined
by the requirements specific to that access network. However, some by the requirements specific to that access network. However, some
sharing between access and core network may be possible depending on sharing between access and core network may be possible depending on
the nature of the requirement and the functionality itself: for the nature of the requirement and the functionality itself: for
example, when a fixed network does not require a subscriber-aware example, when a fixed network does not require a subscriber-aware
feature such as NAT, the functionality may be provided at a core feature such as NAT, the functionality may be provided at a core
router while the mobile access network continues to provide the NAT router while the mobile access network continues to provide the NAT
functionality at the mobile gateway. functionality at the mobile gateway. In addition, if a provider
chooses to offer common subscriber management at the MNG for both
fixed and wireless networks, the MNG itself becomes a convergence
node that needs to support the applicable transition mechanisms for
both fixed and wireless access networks.
Different access networks of a provider are more likely to share a Different access networks of a provider are more likely to share a
common core network. Hence, common solutions can be more easily common core network. Hence, common solutions can be more easily
applied in the core network. For instance, configured tunnels or applied in the core network. For instance, configured tunnels or
MPLS VPNs from the gateways from both mobile and fixed networks can MPLS VPNs from the gateways from both mobile and fixed networks can
be used to carry traffic to the core routers, until the entire core be used to carry traffic to the core routers, until the entire core
network is IPv6-enabled. network is IPv6-enabled.
There can also be considerations due to the use of NAT in access
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 it is subject to NAT policy
administration, which could include periodic clean-up and purge of
NAT state. Such policies affect the usability of the Femto Network,
and has implications to the mobile network provider. Using IPv6 for
the Femto (or any other access technology), on the other hand, could
alleviate some of these concerns if the IPv6 communication could
bypass the NAT.
In summary, there is clear interest in fixed-mobile convergence at In summary, there is clear interest in fixed-mobile convergence at
least among some providers. While there are benefits from least among some providers. While there are benefits from
harmonizing the network as much as possible, there are also harmonizing the network as much as possible, there are also
idiosyncrasies of disparate access networks which influence the idiosyncrasies of disparate access networks which influence the
convergence. Perhaps greater harmonization is feasible at the higher convergence. Perhaps greater harmonization is feasible at the higher
service layers, e.g., in terms of offering unified user experience service layers, e.g., in terms of offering unified user experience
for services and applications. Some harmonization of functions for services and applications. Some harmonization of functions
across access networks into the core network may be feasible. A across access networks into the core network may be feasible. A
provider's core network appears to the place where most convergence provider's core network appears to the place where most convergence
is feasible. is feasible.
skipping to change at page 14, line 6 skipping to change at page 14, line 49
we saw that, as the mobile networks begin to deploy IPv6, we saw that, as the mobile networks begin to deploy IPv6,
conserving the available IPv4 pool and delaying its exhaustion conserving the available IPv4 pool and delaying its exhaustion
implies the need for network translation in mobile networks. At implies the need for network translation in mobile networks. At
the same time, providers can make use of the 3GPP architecture the same time, providers can make use of the 3GPP architecture
constructs such as the APN and PDN connectivity to introduce IPv6 constructs such as the APN and PDN connectivity to introduce IPv6
without affecting the (predominantly IPv4) Internet access. The without affecting the (predominantly IPv4) Internet access. The
IETF dual-stack model [RFC4213] can be applied to the mobile IETF dual-stack model [RFC4213] can be applied to the mobile
networks readily. networks readily.
o The placement of NAT functionality in mobile networks: we o The placement of NAT functionality in mobile networks: we
discussed the "centralized" and "distributed" models of private discussed the centralized and distributed models of private IPv4
IPv4 address pool management and their relative merits. We saw address pool management and their relative merits. We saw that by
that by enabling each MNG to manage its own NET10 pool, the enabling each MNG to manage its own NET10 pool, the distributed
distributed model achieves re-use of available private IPv4 pool, model achieves re-use of available private IPv4 pool, and avoids
and avoids the problems associated with the non-unique private the problems associated with the non-unique private IPv4 addresses
IPv4 addresses for the MNs without additional protocol mechanisms. for the MNs without additional protocol mechanisms. The
The distributed model also augments the "subscriber management" distributed model also augments the "subscriber management"
functions at an MNG, such as readily enabling NAT session functions at an MNG, such as readily enabling NAT session
correlation with the rest of the subscriber session state. On the correlation with the rest of the subscriber session state. On the
other hand, the existing deployments which have used the other hand, the existing deployments which have used the
"centralized" IP address management can continue their legacy centralized IP address management can continue their legacy
architecture by placing the NAT at a common node. The architecture by placing the NAT at a common node. The centralized
"centralized" model also achieves private IPv4 address re-use, but model also achieves private IPv4 address re-use, but needs
needs additional protocol extensions to differentiate overlapping additional protocol extensions to differentiate overlapping
addresses at the common NAT, as well as to integrate with policy addresses at the common NAT, as well as to integrate with policy
and billing infrastructure. and billing infrastructure.
o IPv6-only mobile network deployments: we saw that this is o IPv6-only mobile network deployments: we saw that this is
feasible in the LTE architecture for an operator's own services feasible in the LTE architecture for an operator's own services
and applications. We observed that the existing MNs still expect and applications. We observed that the existing MNs still expect
IPv4 address assignment. And, roaming, which is unique to mobile IPv4 address assignment. And, roaming, which is unique to mobile
networks, requires that a provider support IPv4 connectivity when networks, requires that a provider support IPv4 connectivity when
their (outbound) users roam into a mobile network that is not their (outbound) users roam into a mobile network that is not
IPv6-enabled. Similarly, a provider needs to support IPv4 IPv6-enabled. Similarly, a provider needs to support IPv4
skipping to change at page 14, line 45 skipping to change at page 15, line 41
the differences in the requirements of fixed and mobile networks. the differences in the requirements of fixed and mobile networks.
While some harmonization of functions may be possible across the While some harmonization of functions may be possible across the
access networks, the service provider's core network is perhaps access networks, the service provider's core network is perhaps
best-suited for converged network architecture. Perhaps even best-suited for converged network architecture. Perhaps even
greater gains are feasible in the service and application layers. greater gains are feasible in the service and application layers.
5. Security Considerations 5. Security Considerations
This document does not introduce any new security vulnerabilities. This document does not introduce any new security vulnerabilities.
6. Acknowledgement 6. IANA Considerations
This document does not require any actions from IANA.
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 version 01;
many thanks Mohamed. many thanks Mohamed. Cameron Byrne and Kent Leung provided thorough
reviews of v01, which have helped improve this document.
7. 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.",
. .
[3gpp2.ehrpd] [3gpp2.ehrpd]
"E-UTRAN - eHRPD Connectivity and Interworking: Core "E-UTRAN - eHRPD Connectivity and Interworking: Core
Network Aspects", http://www.3gpp2.org/Public_html/Misc/ Network Aspects", http://www.3gpp2.org/Public_html/Misc/
X.P0057-0_v0.13_E-UTRAN- X.P0057-0_v0.13_E-UTRAN-
eHRPD_Interworking_VV_Due_5_December-2008.pdf. eHRPD_Interworking_VV_Due_5_December-2008.pdf.
[6rd] Townsley, M. and O. Troan, "IPv6 via IPv4 Service Provider
Networks "6rd"", draft-ietf-softwire-ipv6-6rd-04.txt,
Feb 2010.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005. for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd) -- Protocol Specification",
RFC 5969, August 2010.
[arkko-v6]
Arkko, J. and A. Keranen, "Experiences from an IPv6-Only
Network", draft-arkko-ipv6-only-experience-01, Jul 2010.
[dns64] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers",
draft-ietf-behave-dns64-11, Mar 2010.
[gi-ds-lite] [gi-ds-lite]
Brockners, F. and S. Gundavelli, "Gateway Initiated Dual- Brockners, F. and S. Gundavelli, "Gateway Initiated Dual-
stack Lite Deployment", stack Lite Deployment",
draft-gundavelli-softwire-gateway-init-ds-lite-01.txt, draft-gundavelli-softwire-gateway-init-ds-lite-01.txt,
Oct 2009. Oct 2009.
[xlate-stateful] [xlate-stateful]
Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6 NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", Clients to IPv4 Servers",
draft-ietf-behave-v6v4-xlate-stateful-11, Mar 2010. draft-ietf-behave-v6v4-xlate-stateful-11, Mar 2010.
[xlate-stateless] [xlate-stateless]
Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", draft-ietf-behave-v6v4-xlate-20, May 2010. Algorithm", draft-ietf-behave-v6v4-xlate-20, May 2010.
Appendix A. Change Log Appendix A. Change Log
From v00 to v01, the following changes were incorporated: Revisions (from draft-koodli-**), descending chronological order
o: FMC, Femto Networks text
o: Dedicated NAT device model (in addition to the centralized and
distributed models)
o: IPv6-only deployment considerations: - IPv4 literals discussion
and reference, - IPv6 prefix assignment clarification, - DNS64
requirement and reference
o: Overall revisions based on comments from reviews (C. Byrne, K.
Leung)
o: Dual-stack being the recommended model, while encouraging IPv6- o: Dual-stack being the recommended model, while encouraging IPv6-
only deployments. only deployments.
o: Clarifications on on-demand IPv4 PDN usage, DHCP usage and on- o: Clarifications on on-demand IPv4 PDN usage, DHCP usage and on-
demand IPv4 assignment. demand IPv4 assignment.
o: Clarifications regarding IPv6-only deployment: Roaming and o: Clarifications regarding IPv6-only deployment: Roaming and
Applications considerations. Applications considerations.
 End of changes. 37 change blocks. 
119 lines changed or deleted 191 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/