Internet Engineering Task Force (IETF) R. Koodli
Request for Comments: 6342 Cisco Systems
Obsoletes: 6312 August 2011
Category: Informational
ISSN: 2070-1721
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
IPv6部署的移动网络注意事项
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.
智能手机和其他移动设备的移动互联网接入正在加速IPv4地址的耗尽。IPv6被广泛认为是互联网持续运行和增长的关键，尤其是在移动网络中。本文档讨论在移动网络中部署IPv6时出现的问题。因此，本文档可作为服务提供商和网络设计师的有用参考。
RFC Editor Note
RFC编辑说明
This document obsoletes RFC 6312.
本文件淘汰了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.
由于发布错误，RFC 6312的标题中包含不正确的RFC编号。本文档使用新的RFC编号更正该错误。本文中的规范在其他方面与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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6342.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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 ....................................................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
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.
移动互联网的迅猛发展加速了可用IPv4地址的耗尽。人们普遍认为，IPv6对于整个互联网，特别是移动互联网的持续运营和发展是必要的。虽然IPv6带来了许多好处，但在移动网络中部署它时会遇到一些独特的挑战。本文档描述了这些挑战，并概述了现有IPv6部署解决方案的适用性。因此，它可以成为服务提供商和网络设计师的有用参考文档。本文件未提出任何新协议或建议新协议规范工作。
The primary considerations that we address in this document on IPv6 deployment in mobile networks are:
我们在本文档中讨论的移动网络中IPv6部署的主要注意事项包括：
o Public and Private IPv4 address exhaustion and implications to mobile network deployment architecture;
o 公共和私有IPv4地址耗尽及其对移动网络部署架构的影响；
o Placement of Network Address Translation (NAT) functionality and its implications;
o 网络地址转换（NAT）功能的位置及其含义；
o IPv6-only deployment considerations and roaming implications; and
o 仅IPv6部署注意事项和漫游影响；和
o Fixed-Mobile Convergence and implications to overall architecture.
o 固定移动融合和对整体架构的影响。
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].
在大多数情况下，我们假设[3GPP.3G]和[3GPP.4G]中规定的第三代合作伙伴计划（3GPP）3G和4G网络架构。然而，对于其他移动网络架构来说，这些考虑也足够普遍[3GPP2.EHRPD]。
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
----------------/------ \ e
Visited Network / \ t
/ \-
+-----+ /------------------\
| ANG |/ Visited Operator's \
+-----+\ IP Network /
\------------------/
+-----+ +-----+
| AAA | | PCRF|
+-----+ +-----+
Home Network \ /
\ / /-
\ / / I
MN BS \ / / n
| /\ +-----+ /-----------\ +-----+ /-----------\ +----+ / t
+-+ /_ \---| ANG |/ Operator's \| MNG |/ Operator's \| BR |/ e
| |---/ \ +-----+\ IP Network /+-----+\ IP Network /+----+\ r
+-+ \-----------/ / \-----------/ \ n
----------------/------ \ e
Visited Network / \ t
/ \-
+-----+ /------------------\
| ANG |/ Visited Operator's \
+-----+\ IP Network /
\------------------/
Figure 1: Mobile Network Architecture
图1：移动网络架构
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
当用户在归属网络之外漫游时，移动节点（MN）经由其归属网络或经由到访网络连接到移动网络。在3GPP网络架构中，MN通过连接到映射到移动网关的接入点名称（APN）来访问网络。粗略地说，APN类似于无线LAN中的服务集标识符（SSID）。APN是一个逻辑概念，可用于指定MN有权使用的服务类型，如互联网接入、高清视频流、内容丰富的游戏等。每个APN可以指定
what type of IP connectivity (i.e., IPv4, IPv6, IPv4v6) is enabled on that particular APN.
在该特定APN上启用了哪种类型的IP连接（即IPv4、IPv6、IPv4v6）。
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:
当APN将MN定向到适当的网关时，MN需要到该网关的端到端“链路”。在长期演进（LTE）网络中，该链路通过演进分组系统（EPS）承载来实现。在3G通用移动通信系统（UMTS）网络中，这种链路通过分组数据协议（PDP）上下文实现。端到端链路穿越多个节点，定义如下：
o Base Station (BS): The radio Base Station provides wireless connectivity to the MN.
o 基站（BS）：无线基站向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 接入网网关（ANG）：ANG向MN转发IP数据包，并从MN转发IP数据包。通常，这不是MN的默认路由器，并且ANG不为移动节点执行IP地址分配和管理。ANG位于家庭网络或访问网络中。
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 移动网络网关（MNG）：MNG是MN的默认路由器，提供IP地址管理。MNG执行诸如提供服务质量（QoS）、应用特定于用户的策略以及启用计费和记帐等功能；这些功能有时统称为“订户管理”操作。如图1所示，移动网络体系结构定义了必要的协议接口，以支持用户管理操作。MNG通常位于家庭网络中。
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 边界路由器（BR）：顾名思义，BR为移动网络连接互联网。BR不执行移动网络的用户管理。
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.
o 身份验证、授权和记帐（AAA）：AAA的一般功能用于服务的订户身份验证和授权，以及生成计费和记帐信息。
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.
在3GPP网络环境中，使用“归属位置寄存器”（HLR）/“归属用户服务器”（HSS）功能来提供用户身份验证以及随后的连接和服务授权。
o Policy and Charging Rule Function (PCRF): The PCRF enables applying policy and charging rules at the MNG.
o 策略和计费规则功能（PCRF）：PCRF允许在MNG应用策略和计费规则。
In the rest of this document, we use the terms "operator", "service provider", and "provider" interchangeably.
在本文档的其余部分中，我们交替使用术语“运营商”、“服务提供商”和“提供商”。
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.
人们普遍认为，公共IPv4地址池即将耗尽。IANA已将可用的“/8”块分配给区域互联网注册中心（RIR）。RIR本身要么已经“耗尽”了它们的区块，要么预计在不久的将来将耗尽它们。这促使服务提供商意识到要引入技术来保持互联网的运行。对于提供商来说，有两种同时解决耗尽问题的方法：延迟IPv4地址池耗尽（即保存其现有池）和在运营网络中引入IPv6。我们在以下两方面考虑。
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.
延迟提供商的公共IPv4地址耗尽涉及为最终用户分配专用IPv4地址或使用端口范围扩展IPv4地址，这需要隧道和附加信令。诸如网络地址转换器（NAT）之类的机制在提供商场所（与客户场所相反）用于管理私有IP地址分配和对Internet的访问。在下文中，我们主要关注基于转换的机制，如NAT44（即从公共IPv4转换为私有IPv4，反之亦然）和NAT64（即从公共IPv6转换为公共IPv4，反之亦然）。我们这样做是因为3GPP体系结构已经使用通用分组无线业务（GPRS）隧道协议（GTP）定义了隧道基础设施，并且该体系结构允许双栈和仅IPv6部署。
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
在移动网络中，MN的IPv4地址分配由MNG执行。在3GPP网络架构中，该分配与分组数据网络（PDN）连接建立一起执行。PDN连接意味着从MN到MNG的终端链路（即，4G LTE中的EPS承载或3G UMTS中的PDP上下文）。对于每个MN，在任何给定时间都可以有一个或多个PDN连接处于活动状态。PDN连接可以同时支持IPv4和IPv6流量（如4G LTE网络中的双栈PDN），也可以仅支持这两种流量类型中的一种（如现有3G UMTS网络）。IPv4地址在建立PDN连接时分配，或在建立PDN连接后使用DHCP分配。为了延迟公共IPv4地址的耗尽，此IP地址需要是转换为共享公共IPv4的专用IPv4地址
address. Hence, there is a need for a private-public IPv4 translation mechanism in the mobile network.
住址因此，在移动网络中需要专用的公共IPv4转换机制。
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.
在长期演进（LTE）4G网络中，为了可靠地到达全IP网络中的移动用户，需要始终在线的PDN连接。这一要求是由于在LTE中需要支持IP语音服务，LTE没有基于电路的基础设施。如果此PDN连接使用IPv4寻址，则连接到网络的每个MN都需要一个专用IPv4地址。这可能会显著影响专用IPv4地址的可用性和使用率。解决这一问题的一种方法是将始终在线的PDN（需要语音服务）设置为IPv6。IPv4 PDN仅在用户需要时建立。
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.
3GPP标准还规定了在建立连接时在双栈IPv4v6 PDN上的延迟IPv4地址分配。这具有IPv6和IPv4的单个PDN的优势，同时可以将IPv4地址分配推迟到应用程序需要时。延迟地址分配需要支持动态配置协议（如DHCP）以及调用协议的适当触发器。这种支持在今天的手机中并不存在。新一代智能手机可以提供这样的支持。此外，智能手机与笔记本电脑的连接（通常支持DHCP）可能会使用延迟分配，具体取决于笔记本电脑与智能手机的连接时间。在适当的触发器和主机堆栈支持可用之前，地址延迟选项的适用性可能会受到限制。
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.
另一方面，在现有的3G UMTS网络中，即使许多智能手机很少放弃已建立的PDP上下文，也不需要始终在线的连接。现有所谓的pre-Release-8部署不支持双堆栈PDP连接。因此，需要两个独立的PDP连接来支持IPv4和IPv6流量。尽管目前使用的一些MN，特别是智能手机，可能有IPv6协议栈，但还有两个需要考虑的问题。首先，对于这些现有堆栈，几乎没有操作经验和法规遵从性测试。因此，预计它们在大型部署中的使用可能会发现软件错误和互操作性问题，这些问题阻碍了为此类主机提供基于IPv6的服务。其次，目前使用的手机中只有一小部分有这样的堆叠。因此，提供商需要在推出新手机时测试、部署和操作IPv6，而新手机也需要继续访问主要为IPv4的互联网。
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
上述各段的考虑导致以下意见。首先，移动网络中越来越需要支持专用IPv4寻址，因为
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.
公用IPv4地址耗尽问题。相应地，移动网络中更需要私有-公共IPv4转换。第二，在3G和4G LTE网络中，已经以PDP上下文和PDN连接的形式支持IPv6。首先，运营商可以为自己的应用程序和服务引入IPv6。换句话说，IETF推荐的双栈IPv6和IPv4网络模型很容易适用于支持不同APN的移动网络，并且能够在PDP/PDN连接上承载IPv6流量。IETF双栈模型可在第8版及以后版本中使用单个IPv4v6 PDN连接应用，但在早期版本中需要单独的PDP上下文。最后，运营商可以使用IPv4v6 PDN或IPv6 PDN将IPv6作为始终在线移动连接的默认设置，并根据需要使用IPv4 PDN。
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.
在上一节中，我们注意到需要NAT44功能，以节省可用池并延迟公共IPv4地址耗尽。但是，对于大型网络（如移动网络），可用的专用IPv4池本身并不丰富。例如，所谓的NET10块[RFC1918]大约有1670万个以10.0.0.0开始的专用IPv4地址。一个大型移动服务提供商网络在给定的时间内可以轻松地连接到网络上的用户超过1670万。因此，专用IPv4地址池管理和NAT44功能的放置变得非常重要。
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
除了上面提到的发展，NAT安置也出于其他原因很重要。接入网络通常需要生成用于计费和记帐的网络和服务使用记录。这同样适用于移动网络，“用户管理”功能（即QoS、策略以及计费和记帐）可以相当详细的情况。由于NAT在两个地址之间引入了绑定，绑定本身就成为订户管理的必要信息。例如，出于记帐目的，可能需要关联专用IPv4地址和（共享）公共IPv4地址上提供的QoS。作为另一示例，提供商网络内的应用服务器可能需要基于PCRF提供的策略来处理流量。如果这些应用服务器看到的IP地址不是唯一的，PCRF需要能够检查NAT绑定以消除各个MN之间的歧义。用户会话管理信息和服务使用信息也需要相互关联，以便生成协调的记录。此外，可能存在存储NAT绑定记录的法律要求。事实上，这些问题随着时间的推移而消失
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.
过渡到IPv6。现在，断言NAT引入状态就足够了，它需要与其他例程订户信息关联并可能存储。
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.
移动网络部署的IP地址池分配各不相同。某些网络部署使用“集中式模型”，其中池由公共节点（如PDN的BR）管理，池由多个MNG共享，所有MNG都连接到同一BR。这种模式在3G之前的部署中表现良好，在任何给定时间访问移动互联网的用户数量都没有超过可用的地址池。然而，随着3G网络的出现和随后的移动互联网用户数量的急剧增长，服务提供商越来越被迫考虑其现有的网络设计和选择。具体而言，提供商必须解决专用IPv4池耗尽问题以及可扩展NAT解决方案。
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.
为了解决集中式模型中的私有IPv4耗尽问题，需要在公共NAT功能以及每个网关中支持重叠的私有IPv4地址。换句话说，两个或多个MN（可能连接到同一MNG）使用的IP地址很可能在集中NAT处重叠，这需要能够区分流量。隧道机制，如通用路由封装（GRE）[RFC2784][RFC2890]、MPLS[RFC3031]VPN隧道，甚至可以为NAT会话提供唯一标识符的IP-in-IP封装[RFC2003]，可用于分离重叠的专用IPv4流量，如[GI-DS-LITE]中所述。集中NAT和使用重叠的专用IPv4寻址的一个优点是节省了有限的专用IPv4池。它还使运营商的企业网络能够从MNG到BR使用IPv6；这（即，需要IPv6路由企业网络）可能被某些提供商视为一项附加要求。缺点包括需要附加协议将NAT状态（在公共节点处）与订户会话信息（在每个网关处）相关联、次优的MN-MN通信、缺少订户感知NAT（和策略）功能，以及当然，需要从MNG到BR本身的协议。此外，如果NAT功能出现故障，则所有连接的网关服务都将受到影响。这些缺点在“分布式”模型中不存在，我们将在下面讨论。
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
在分布式模型中，私有IPv4地址管理由MNG执行，MNG还执行NAT功能。在该模型中，每个MNG都有一个包含1670万个唯一地址的块，与每个MNG上活跃的移动用户数量相比，这就足够了。通过将NAT功能分发到网络边缘，每个MNG都可以重用可用的网络10
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.
块，它避免了在网络核心处重叠专用IPv4寻址的问题。此外，由于MNG是订户管理功能所在的位置，因此容易启用NAT状态相关性。此外，MNG已经具有AAA和PCRF等功能的现有接口，这允许它使用唯一的专用IPv4地址执行订户管理功能。最后，MNG还可以通过某些通信量类型而不执行NAT到位于服务提供商的域内的应用服务器，这允许服务器还使用唯一的专用IPv4地址识别订户会话。“分布式模型”的缺点包括没有集中寻址和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.
除了上述两种模型外，混合模型用于将NAT定位在除MNG或BR之外的专用设备中。如果IP池支持移动节点的唯一专用寻址，则该模型将类似于分布式模型；如果它支持重叠的专用IP地址，则该模型将类似于集中式模型。在任何情况下，NAT设备必须能够向外部实体（例如AAA或PCRF）提供必要的NAT会话绑定信息，然后外部实体需要能够将这些记录与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.
上述讨论可总结如下。首先，鉴于移动互联网用户的增加，对可用的专用IPv4池的管理变得非常重要。需要能够重用可用池的机制。其次，在专用IPv4池管理的上下文中，NAT功能的放置对网络部署和操作有影响。具有公共NAT的集中式模型具有继续其传统部署和重用专用IPv4寻址的优势。然而，它们需要额外的功能来实现流量区分和NAT状态关联以及MNG的用户状态管理。分布式模型还实现了专用IPv4地址重用，避免了运营商核心中的重叠专用IPv4流量，但不需要额外的机制。由于MNG执行（唯一的）IPv4地址分配，并具有到AAA和PCRF的标准接口，因此分布式模型还支持用户和NAT状态报告以及策略应用的单点。总之，有兴趣随时将NAT与其他订户管理功能集成，以及保存和重用其专用IPv4池的提供商可能会发现分布式模型很有吸引力。另一方面，那些对NAT的公共管理感兴趣的提供商可能会发现集中式模型更具吸引力。
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.
正如我们在上一节中所观察到的，网络中NAT功能的存在带来了许多问题，否则这些问题将不存在。NAT应被视为一种临时解决方案，直到IPv6广泛可用，即IPv6可供移动用户用于所有（或大多数）实际用途。虽然提供商场所的NAT可能会减缓公共IPv4地址的耗尽，但在运营网络中快速同时引入IPv6是保持互联网“运行和增长”的必要条件。为了实现这一目标，了解部署仅IPv6网络时的注意事项非常重要。
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.
仅IPv6部署有三个维度：网络本身、移动节点和应用程序，由3元组{nw，mn，ap}表示。目标是从{IPv4，IPv4，IPv4}到达坐标{IPv6，IPv6，IPv6}。然而，实现这一目标有多种途径。经典的双栈模型将遍历坐标{IPv4v6，IPv4v6，IPv4v6}，其中每个维度都支持IPv4和IPv6共存。这似乎是中断最少的路径，尽管我们面临着在网络中支持大规模NAT的影响。在现有3G UMTS网络中支持单独的PDP上下文也有成本。另一个感兴趣的中间坐标是{IPv6，IPv6，IPv4}，其中网络和MN仅为IPv6，并且因特网应用程序被认为主要是IPv4。具有讽刺意味的是，这种过渡路径需要IPv6和IPv4之间的互通，以便仅IPv6的MN能够访问Internet上的IPv4服务和应用程序。换句话说，为了脱离NAT（对于IPv4-IPv4），我们需要引入另一种形式的NAT（即IPv6-IPv4），以加快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.
有趣的是，考虑前面的讨论围绕NAT对IPv6IPv4互通的放置。不存在重叠的专用IPv4地址问题，因为每个IPv6地址都是唯一的，并且有很多可用的地址。因此，也不需要（IPv6）地址重用，这意味着在集中式模型中不需要协议来消除NAT会话的歧义。但是，IPv6-IPv4转换还需要DNS64[RFC6147]功能。此DNS64功能必须确保合成的AAAA记录正确映射到IPv6-IPv4转换器。
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
移动网络中仅IPv6的部署需要考虑以下因素。首先，网络和MNs都需要支持IPv6。加快网络升级以及推出带有IPv6的MNs将极大地促进这一点。幸运的是，针对LTE的3GPP网络设计已经需要网络节点和
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.
支持IPv6的移动节点。即使不要求传输网络为IPv6，也可以在仅IPv4的传输网络中使用适当的现有隧道机制部署可运行的IPv6连接服务。因此，服务提供商可以选择在其家庭网络中为其自己的订户实施仅IPv6的PDN和地址分配（见图1）。当移动网络能够提供仅限IPv6的PDN支持和用于Internet访问的IPv6-IPv4互通时，这对于较新的MNs是可行的。但是，对于现有MNs，提供商仍然需要能够支持仅IPv4的PDP/PDN连接。
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.
在具有仅IPv6 PDN连接的MNs中将应用程序迁移到IPv6带来了挑战。提供商提供的应用程序和服务显然需要支持IPv6。但是，MN可能承载其他应用程序，这些应用程序在仅IPv6部署中也需要支持IPv6。这可能是一种“长尾”现象；但是，当一些著名的应用程序开始提供IPv6时，可能会有强烈的动机向IPv6提供应用层（例如套接字接口）升级。此外，一些仅限IPv4的应用程序可能能够在可用时使用替代接入，如WiFi。应用程序迁移中的一个相关挑战是在应用层协议（如XMPP）或内容（如HTML或XML）中使用IPv4文本。一些Internet应用程序希望其客户端以文本形式提供IPv4地址，而这在仅IPv6部署中是不可能的。[ARKKO-V6]中记录了部署纯IPv6网络的一些经验和相关注意事项。总之，需要将应用程序迁移到IPv6，并且这种迁移预计不会在现有应用程序的所有子集上都是统一的。
Voice over LTE (VoLTE) also brings some unique challenges. The signaling for voice is generally expected to be available for free while the actual voice call itself is typically charged 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.
LTE语音（VoLTE）也带来了一些独特的挑战。语音信号通常是免费的，而实际的语音呼叫本身通常根据其持续时间收费。信令和有效负载的这种分离对于语音来说是唯一的，而互联网连接是在没有特别考虑应用信令和有效负载流量的情况下进行的。即使在漫游期间，也应支持此模型。此外，无论漫游情况如何，提供商和用户通常都需要语音服务，而互联网的使用取决于用户偏好和漫游协议。这种在提供互联网使用灵活性的同时普遍支持语音服务的要求加剧了寻址问题，并可能加快使用仅IPv6 PDN的VoLTE的供应。
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
如前所述，漫游是移动网络所独有的，它带来了新的挑战。服务提供商可以控制他们自己的网络设计，但不能控制他们的对等网络，因为他们依赖于对等网络
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.
漫游。用户即使在漫游时也希望体验一致。这就限制了对仅IPv6部署感兴趣的提供商在其自身（出站）订户漫游到不提供IPv6的网络时也支持IPv4寻址。例如，当LTE部署仅为IPv6时，漫游3G网络可能不提供IPv6 PDN连接。由于PDN连接涉及无线基站、ANG和MNG（见图1），因此如果没有漫游网络支持，就不可能启用IPv6 PDN连接。当访问的网络用于提供服务时，这些考虑也适用，例如所谓的本地分支模型中的VoLTE；漫游MN的能力以及支持使用IPv6的VoLTE的漫游网络能力决定是否需要回退到IPv4。类似地，也有到IPv6就绪提供商网络的入站漫游者，其MN不支持IPv6。IPv6就绪提供商网络必须能够支持此类入站漫游者的IPv4 PDN连接。有令人鼓舞的迹象表明，3GPP体系结构中现有部署的网络节点已经提供了对IPv6-PDP上下文的支持。有必要将这种支持扩展到（非常）大量的移动用户，并将其作为一种无处不在的服务提供。
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.
总之，应鼓励在双栈模型的基础上进行仅IPv6的部署，这是推荐的IETF方法。这对于运营商自己的服务和应用程序来说相对简单，通过适当的APN和相应的仅IPv6的PDP或EPS承载提供。一些提供商可以考虑IPv6仅用于Internet接入，这将需要IPv6 IPv4互通。当IPv6-IPv4转换机制用于仅限IPv6的部署时，[RFC6146]和[RFC6145]中指定的协议和相关注意事项适用。最后，这种仅限IPv6的部署可以分阶段用于较新的移动节点，而现有的移动节点仍然需要仅限IPv4的连接。
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.
漫游在移动网络中非常重要，漫游在网络部署中引入了多样性。在所有移动网络都可以使用IPv6连接之前，只使用IPv6的移动网络部署需要做好准备，以便为其自己的出站漫游用户以及入站漫游用户支持IPv4连接（和NAT44）。然而，通过主动引入IPv6（仅适用于较新的MNs），移动网络可以显著减少对专用IPv4地址的需求。
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.
许多服务提供商同时拥有固定宽带和移动网络。接入网络通常是完全不同的，有一些共同的特征，但有足够的差异使得实现“融合”具有挑战性。例如，在固定接入网络中，漫游不是一个考虑因素。全IP移动网络服务提供商需要提供语音服务，而固定网络提供商则不需要提供语音服务。固定网络中的“链路”通常能够承载IPv6和IPv4流量，而并非所有移动网络都具有能够支持IPv6和IPv4的“链路”（即PDP/PDN连接）。实际上，当链路的一部分（即图1中的家庭网络）能够支持IPv6，而链路的另一部分（即图1中的访问网络）不能支持IPv6时，漫游会使这个问题变得更糟。这种体系结构的差异以及政策和业务模式的差异使得融合具有挑战性。
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:
然而，在同一提供商的空间内，可能会应用一些常见的注意事项。例如，IPv4地址管理是这两个接入网络共同关心的问题。这意味着前面讨论的相同机制，即延迟IPv4地址耗尽和在运营网络中引入IPv6，也适用于聚合网络。但是，为每个接入网络部署的确切解决方案可能因各种原因而有所不同，例如：
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 在固定网络中，IPv6内的专用IPv4数据包隧道是可行的，在固定网络中，端点通常是电缆或DSL调制解调器。在移动网络中，端点本身就是MN，但情况并非如此。
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 当运营商无法提供本机或直接IPv6连接，并且住宅网关可以成为提供此服务的隧道端点时，基于封装的机制（如6rd[RFC5969]）非常有用。在移动网络中，运营商可以使用现有的移动网络隧道机制提供IPv6连接，而无需引入额外的隧道层。
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.
o 移动网络提供商可能在其网络中具有需要用于MN标识的唯一专用IPv4地址的应用服务器（例如，电子邮件服务器），而固定网络提供商可能没有这样的要求或服务本身。
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
这些示例说明，接入网络中使用的实际解决方案在很大程度上取决于特定于该接入网络的需求。尽管如此，在访问和
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.
根据需求的性质和功能本身，核心网络是可能的。例如，当固定网络不需要诸如NAT之类的用户感知特性时，可以在核心路由器处提供该功能，而移动接入网络继续在移动网关处提供NAT功能。如果提供商选择在MNG为固定和无线网络提供公共用户管理，MNG本身将成为需要支持固定和无线接入网络的适用转换机制的汇聚节点。
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.
提供商的不同接入网络更可能共享一个共同的核心网络。因此，通用解决方案可以更容易地应用于核心网络。例如，来自移动和固定网络网关的配置隧道或MPLS VPN可用于将流量传输到核心路由器，直到整个核心网络启用IPv6。
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.
由于在接入网络中使用NAT，还可能存在一些考虑因素。诸如Femto网络的解决方案依赖于固定因特网连接，该固定因特网连接可供Femto基站与移动网络上的对等方通信，通常通过IPsec隧道。当Femto基站需要使用专用IPv4地址时，通过Femto基站的移动网络访问将接受NAT策略管理，包括定期清理和清除NAT状态。这些政策影响Femto网络的可用性，并对移动网络提供商产生影响。如果IPv6通信可以绕过NAT，那么将IPv6用于Femto（或任何其他接入技术）可以缓解一些问题。
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.
总之，至少在一些提供商中，人们对固定移动融合感兴趣。尽管尽可能地协调网络有好处，但不同接入网络的特性也会影响融合。也许在更高的服务层上更大程度的协调是可行的，例如，在为服务和应用程序提供统一的用户体验方面。将接入网络中的功能协调到核心网络中可能是可行的。提供商的核心网络似乎是最有可能实现融合的地方。
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:
在移动网络中部署IPv6对于移动互联网至关重要。在本文档中，我们讨论了在移动网络中部署IPv6的注意事项。我们将讨论总结如下：
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 IPv4地址耗尽及其对移动网络的影响：随着移动服务提供商开始部署IPv6，保护其可用IPv4池意味着需要在移动网络中进行网络地址转换。同时，提供商可以利用3GPP架构构造（如APN和PDN连接）来引入IPv6，而不影响主要的IPv4互联网接入。IETF双栈模型[RFC4213]可以很容易地应用于移动网络。
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 NAT功能在移动网络中的位置：私有IPv4地址池管理的集中式和分布式模型都有各自的优点。通过使每个MNG能够管理其自己的NET10池，分布式模型实现了对可用专用IPv4池的重用，并避免了与MNs的非唯一专用IPv4地址相关的问题，而无需额外的协议机制。分布式模型还增强了MNG上的“订户管理”功能，例如容易地启用NAT会话与订户会话状态的其余部分的关联。另一方面，使用集中式IP地址管理的现有部署可以通过将NAT放置在公共节点来继续其传统体系结构。集中式模型还实现了专用IPv4地址重用，但需要额外的协议扩展来区分公共NAT上的重叠地址，并与策略和计费基础设施集成。
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 仅限IPv6的移动网络部署：这种部署模式在LTE架构中对于运营商自己的服务和应用是可行的。现有MN仍然需要IPv4地址分配。此外，移动网络特有的漫游要求提供商在其（出站）用户漫游到未启用IPv6的移动网络时支持IPv4连接。类似地，提供商需要支持MNs不支持IPv6的（入站）用户的IPv4连接。IPv6-IPv4互通对于仅IPv6的MNs访问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.
o 固定-移动融合：讨论的示例说明了固定网络和移动网络需求的差异。虽然可以跨接入网络实现功能的某种协调，但服务提供商的核心网络可能更适合于融合网络体系结构。在服务层和应用层中，类似的收敛收益也是可行的。
This document does not introduce any new security vulnerabilities.
本文档未引入任何新的安全漏洞。
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.
本文件得益于与卡梅隆·伯恩、大卫·克罗、惠登、雷米·德斯普雷斯、弗雷德里克·加内伊、朱尼·科霍宁、蒂姆·萨沃莱宁和丹·温的讨论和评论。感谢他们所有人。非常感谢Mohamed Boucadair对本文件草案进行了广泛审查。Cameron Byrne、Kent Leung、Kathleen Moriarty和Jari Arkko提供了有助于改进本文件的评论。感谢Nick Heatley为VoLTE提供了宝贵的评论和意见。
[3GPP.3G] "General Packet Radio Service (GPRS); Service description; Stage 2, 3GPP TS 23.060, December 2006".
[3GPP.3G]“通用分组无线业务（GPRS）；业务描述；第2阶段，3GPP TS 23.06012006年12月”。
[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.
[3GPP.4G]“通用分组无线业务（GPRS）对演进型通用地面无线接入网（E-UTRAN）接入的增强”，3GPP TS 23.401 8.8.02009年12月。
[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.
[3GPP2.EHRPD]“E-UTRAN-EHRPD连接和互通：核心网络方面”，http://www.3gpp2.org/public_html/ 规范/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.
[RFC1918]Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003]Perkins，C.，“IP内的IP封装”，RFC 2003，1996年10月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784]Farinaci，D.，Li，T.，Hanks，S.，Meyer，D.，和P.Traina，“通用路由封装（GRE）”，RFC 27842000年3月。
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000.
[RFC2890]Dommety，G.“GRE的密钥和序列号扩展”，RFC 28902000年9月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213]Nordmark，E.和R.Gilligan，“IPv6主机和路由器的基本转换机制”，RFC 4213，2005年10月。
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010.
[RFC5969]Townsley，W.和O.Troan，“IPv4基础设施上的IPv6快速部署（第6条）——协议规范”，RFC 5969，2010年8月。
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
[RFC6145]Li，X.，Bao，C.，和F.Baker，“IP/ICMP翻译算法”，RFC 61452011年4月。
[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.
[RFC6146]Bagnulo，M.，Matthews，P.，和I.van Beijnum，“有状态NAT64：从IPv6客户端到IPv4服务器的网络地址和协议转换”，RFC 61462011年4月。
[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.
[RFC6147]Bagnulo，M.，Sullivan，A.，Matthews，P.，和I.van Beijnum，“DNS64：用于从IPv6客户端到IPv4服务器的网络地址转换的DNS扩展”，RFC 61472011年4月。
[ARKKO-V6] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only Network", Work in Progress, April 2011.
[ARKKO-V6]ARKKO，J.和A.Keranen，“仅IPv6网络的体验”，正在进行的工作，2011年4月。
[GI-DS-LITE] Brockners, F., Gundavelli, S., Speicher, S., and D. Ward, "Gateway Initiated Dual-Stack Lite Deployment", Work in Progress, July 2011.
[GI-DS-LITE]Brockners，F.，Gundavelli，S.，Speicher，S.，和D.Ward，“网关启动的双堆栈LITE部署”，正在进行的工作，2011年7月。
Author's Address
作者地址
Rajeev Koodli Cisco Systems USA
美国思科系统公司
EMail: rkoodli@cisco.com
EMail: rkoodli@cisco.com