Internet Engineering Task Force (IETF) G. Chen
Request for Comments: 7445 H. Deng
Category: Informational China Mobile
ISSN: 2070-1721 D. Michaud
Rogers Communications
J. Korhonen
Broadcom Corporation
M. Boucadair
France Telecom
March 2015
Internet Engineering Task Force (IETF) G. Chen
Request for Comments: 7445 H. Deng
Category: Informational China Mobile
ISSN: 2070-1721 D. Michaud
Rogers Communications
J. Korhonen
Broadcom Corporation
M. Boucadair
France Telecom
March 2015
Analysis of Failure Cases in IPv6 Roaming Scenarios
IPv6漫游场景中的故障案例分析
Abstract
摘要
This document identifies a set of failure cases that may be encountered by IPv6-enabled mobile customers in roaming scenarios. The analysis reveals that the failure causes include improper configurations, incomplete functionality support in equipment, and inconsistent IPv6 deployment strategies between the home and the visited networks.
本文档确定了支持IPv6的移动客户在漫游场景中可能遇到的一组故障案例。分析表明，故障原因包括配置不当、设备功能支持不完整以及家庭和访问网络之间的IPv6部署策略不一致。
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/rfc7445.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7445.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Roaming Architecture: An Overview . . . . . . . . . . . . 4
2.1.1. Home Routed Mode . . . . . . . . . . . . . . . . . . 4
2.1.2. Local Breakout Mode . . . . . . . . . . . . . . . . . 5
2.2. Typical Roaming Scenarios . . . . . . . . . . . . . . . . 6
3. Failure Case in the Network Attachment . . . . . . . . . . . 7
4. Failure Cases in the PDP/PDN Creation . . . . . . . . . . . . 9
4.1. Case 1: Splitting Dual-Stack Bearer . . . . . . . . . . . 9
4.2. Case 2: IPv6 PDP/PDN Unsupported . . . . . . . . . . . . 11
4.3. Case 3: Inappropriate Roaming APN Set . . . . . . . . . . 11
4.4. Case 4: Fallback Failure . . . . . . . . . . . . . . . . 11
5. Failure Cases in the Service Requests . . . . . . . . . . . . 12
5.1. Lack of IPv6 Support in Applications . . . . . . . . . . 12
5.2. 464XLAT Support . . . . . . . . . . . . . . . . . . . . . 12
6. HLR/HSS User Profile Setting . . . . . . . . . . . . . . . . 13
7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Roaming Architecture: An Overview . . . . . . . . . . . . 4
2.1.1. Home Routed Mode . . . . . . . . . . . . . . . . . . 4
2.1.2. Local Breakout Mode . . . . . . . . . . . . . . . . . 5
2.2. Typical Roaming Scenarios . . . . . . . . . . . . . . . . 6
3. Failure Case in the Network Attachment . . . . . . . . . . . 7
4. Failure Cases in the PDP/PDN Creation . . . . . . . . . . . . 9
4.1. Case 1: Splitting Dual-Stack Bearer . . . . . . . . . . . 9
4.2. Case 2: IPv6 PDP/PDN Unsupported . . . . . . . . . . . . 11
4.3. Case 3: Inappropriate Roaming APN Set . . . . . . . . . . 11
4.4. Case 4: Fallback Failure . . . . . . . . . . . . . . . . 11
5. Failure Cases in the Service Requests . . . . . . . . . . . . 12
5.1. Lack of IPv6 Support in Applications . . . . . . . . . . 12
5.2. 464XLAT Support . . . . . . . . . . . . . . . . . . . . . 12
6. HLR/HSS User Profile Setting . . . . . . . . . . . . . . . . 13
7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
Many mobile operators have deployed IPv6, or are about to, in their operational networks. A customer in such a network can be provided IPv6 connectivity if their User Equipment (UE) is IPv6 compliant. Operators may adopt various approaches to deploy IPv6 in mobile networks, such as the solutions described in [TR23.975]. Depending on network conditions, either dual-stack or IPv6-only deployment schemes can be enabled.
许多移动运营商已经或即将在其运营网络中部署IPv6。如果用户设备（UE）符合IPv6，则可以向此类网络中的客户提供IPv6连接。运营商可以采用各种方法在移动网络中部署IPv6，如[TR23.975]中描述的解决方案。根据网络条件，可以启用双堆栈或仅IPv6部署方案。
A detailed overview of IPv6 support in 3GPP architectures is provided in [RFC6459].
[RFC6459]中提供了3GPP体系结构中IPv6支持的详细概述。
It has been observed and reported that a mobile subscriber roaming around a different operator's areas may experience service disruption due to inconsistent configurations and incomplete functionality of equipment in the network. This document focuses on these issues.
据观察和报告，由于网络中设备的配置不一致和功能不完整，漫游在不同运营商区域的移动用户可能会遇到服务中断。本文件侧重于这些问题。
This document makes use of these terms:
本文件使用了以下术语：
o Mobile networks refer to 3GPP mobile networks.
o 移动网络指3GPP移动网络。
o Mobile UE denotes a 3GPP device that can be connected to 3GPP mobile networks.
o 移动UE表示可以连接到3GPP移动网络的3GPP设备。
o The Public Land Mobile Network (PLMN) is a network that is operated by a single administrative entity. A PLMN (and therefore also an operator) is identified by the Mobile Country Code (MCC) and the Mobile Network Code (MNC). Each (telecommunications) operator providing mobile services has its own PLMN [RFC6459].
o 公共陆地移动网络（PLMN）是由单一行政实体运营的网络。PLMN（因此也是运营商）由移动国家代码（MCC）和移动网络代码（MNC）标识。提供移动服务的每个（电信）运营商都有自己的PLMN[RFC6459]。
o The Home Location Register (HLR) is a pre-Release 5 database (but is also used in real deployments of Release 5 and later) that contains subscriber data and information related to call routing. All subscribers of an operator and the subscribers' enabled services are provisioned in the HLR [RFC6459].
o 归属位置寄存器（HLR）是版本5之前的数据库（但也用于版本5及更高版本的实际部署），其中包含与呼叫路由相关的订户数据和信息。运营商的所有订户和订户启用的服务都在HLR[RFC6459]中提供。
o The Home Subscriber Server (HSS) is a database for a given subscriber and was introduced in 3GPP Release 5. It is the entity containing the subscription-related information to support the network entities actually handling calls/sessions [RFC6459].
o 家庭订户服务器（HSS）是给定订户的数据库，在3GPP版本5中引入。它是包含订阅相关信息的实体，用于支持实际处理呼叫/会话的网络实体[RFC6459]。
o "HLR/HSS" is used collectively for the subscriber database unless referring to the failure case related to General Packet Radio Service (GPRS) Subscriber data from the HLR.
o “HLR/HSS”用于用户数据库，除非涉及与来自HLR的通用分组无线业务（GPRS）用户数据相关的故障案例。
An overview of key 3GPP functional elements is documented in [RFC6459].
[RFC6459]中记录了关键3GPP功能元件的概述。
"Mobile device" and "mobile UE" are used interchangeably.
“移动设备”和“移动UE”可以互换使用。
Roaming occurs in two scenarios:
漫游发生在两种情况下：
o International roaming: a mobile UE enters a visited network operated by a different operator, where a different PLMN code is used. The UEs could, either in an automatic mode or in a manual mode, attach to the visited PLMN.
o 国际漫游：移动UE进入由不同运营商运营的到访网络，其中使用不同的PLMN代码。ue可以在自动模式或手动模式下连接到所访问的PLMN。
o Intra-PLMN mobility: an operator may have one or multiple PLMN codes. A mobile UE could pre-configure the codes to identify the Home PLMN (HPLMN) or Equivalent HPLMN (EHPLMN). Intra-PLMN mobility allows the UE to move to a different area of HPLMN and EHPLMN. When the subscriber profile is not stored in the visited area, HLR/HSS in the Home area will transmit the profile to the Serving GPRS Support Node (SGSN) / Mobility Management Entity (MME) in the visited area so as to complete network attachment.
o PLMN内移动性：操作员可以有一个或多个PLMN代码。移动UE可以预先配置代码以识别归属PLMN（HPLMN）或等效的HPLMN（EHPLMN）。PLMN内移动性允许UE移动到HPLMN和EHPLMN的不同区域。当用户简档未存储在访问区域中时，归属区域中的HLR/HSS将该简档发送到访问区域中的服务GPRS支持节点（SGSN）/移动管理实体（MME），以完成网络连接。
When a UE is turned on or is transferred via a handover to a visited network, the mobile device will scan all radio channels and find available PLMNs to attach to. The SGSN or the MME in the visited networks must contact the HLR or HSS to retrieve the subscriber profile.
当UE接通或通过切换传输到到访网络时，移动设备将扫描所有无线信道并查找可用的plmn以连接到。访问网络中的SGSN或MME必须联系HLR或HSS以检索用户配置文件。
Steering of roaming may also be used by the HPLMN to further restrict which of the available networks the UE may be attached to. Once the authentication and registration stage is completed, the Packet Data Protocol (PDP) or Packet Data Networks (PDN) activation and traffic flows may be operated differently according to the subscriber profile stored in the HLR or the HSS.
HPLMN还可以使用漫游的引导来进一步限制UE可以连接到哪些可用网络。一旦认证和注册阶段完成，分组数据协议（PDP）或分组数据网络（PDN）激活和业务流可根据存储在HLR或HSS中的订户简档以不同方式操作。
The following subsections describe two roaming modes: Home-routed traffic (Section 2.1.1) and Local breakout (Section 2.1.2).
以下小节描述了两种漫游模式：本地路由流量（第2.1.1节）和本地转接（第2.1.2节）。
In this mode, the subscriber's UE gets IP addresses from the home network. All traffic belonging to that UE is therefore routed to the home network (Figure 1).
在此模式下，用户的UE从家庭网络获取IP地址。因此，属于该UE的所有通信量被路由到归属网络（图1）。
GPRS roaming exchange (GRX) or Internetwork Packet Exchange (IPX) networks [IR.34] are likely to be invoked as the transit network to deliver the traffic. This is the main mode for international roaming of Internet data services to facilitate the charging process between the two involved operators.
GPRS漫游交换（GRX）或网络间分组交换（IPX）网络[IR.34]很可能被调用作为传输网络来传输流量。这是互联网数据服务国际漫游的主要模式，以方便两个相关运营商之间的收费流程。
+-----------------------------+ +------------------------+
|Visited Network | |Home Network |
| +----+ +----+---+ | (GRX/IPX) | +--------+ Traffic Flow
| | UE |=======>|SGSN/SGW|====================>|GGSN/PGW|============>
| +----+ +----+---+ | | +--------+ |
| |MME | | | |
| +----+ | Signaling | +--------+ |
| |-------------------------->|HLR/HSS | |
| | | +--------+ |
+-----------------------------+ +------------------------+
+-----------------------------+ +------------------------+
|Visited Network | |Home Network |
| +----+ +----+---+ | (GRX/IPX) | +--------+ Traffic Flow
| | UE |=======>|SGSN/SGW|====================>|GGSN/PGW|============>
| +----+ +----+---+ | | +--------+ |
| |MME | | | |
| +----+ | Signaling | +--------+ |
| |-------------------------->|HLR/HSS | |
| | | +--------+ |
+-----------------------------+ +------------------------+
Figure 1: Home Routed Traffic
图1：本地路由流量
In the local breakout mode, IP addresses are assigned by the visited network to a roaming mobile UE. Unlike the home routed mode, the traffic doesn't have to traverse GRX/IPX; it is offloaded locally at a network node close to that device's point of attachment in the visited network. This mode ensures a more optimized forwarding path for the delivery of packets belonging to a visiting UE (Figure 2).
在本地转接模式中，IP地址由到访网络分配给漫游移动UE。与主路由模式不同，流量不必穿过GRX/IPX；它在访问网络中靠近设备连接点的网络节点本地卸载。该模式确保了一个更优化的转发路径，用于传递属于访问UE的数据包（图2）。
+----------------------------+ +----------------+
|Visited Network | |Home Network |
| +----+ +--------+ | Signaling | +--------+ |
| | UE |=======>|SGSN/MME|------------------->|HLR/HSS | |
| +----+ +---+----+ | (GRX/IPX) | +--------+ |
| |SGW| | | |
| +---+ | | |
| || | | |
| +--------+ | | |
| |GGSN/PGW| | | |
| +--------+ | | |
| Traffic Flow || | | |
+------------------||--------+ +----------------+
\/
+----------------------------+ +----------------+
|Visited Network | |Home Network |
| +----+ +--------+ | Signaling | +--------+ |
| | UE |=======>|SGSN/MME|------------------->|HLR/HSS | |
| +----+ +---+----+ | (GRX/IPX) | +--------+ |
| |SGW| | | |
| +---+ | | |
| || | | |
| +--------+ | | |
| |GGSN/PGW| | | |
| +--------+ | | |
| Traffic Flow || | | |
+------------------||--------+ +----------------+
\/
Figure 2: Local Breakout
图2：局部突破
The international roaming of services based on the IP Multimedia Subsystem (IMS), e.g., Voice over LTE (VoLTE)[IR.92], is claimed to select the local breakout mode in [IR.65]. Data service roaming
基于IP多媒体子系统（IMS）的服务的国际漫游，例如，LTE上的语音（VoLTE）[IR.92]，声称在[IR.65]中选择本地转接模式。数据业务漫游
across different areas within an operator network might use local breakout mode in order to get more efficient traffic forwarding and also ease emergency services. The local breakout mode could also be applied to an operator's alliance for international roaming of data service.
跨运营商网络内的不同区域可能会使用本地转接模式，以获得更高效的流量转发，并简化紧急服务。本地突破模式也可应用于运营商的数据服务国际漫游联盟。
EU Roaming Regulation III [EU-Roaming-III] involves local breakout mode allowing European subscribers roaming in European 2G/3G networks to have their Internet data routed directly to the Internet from their current Visited Public Land Mobile Network (VPLMN).
欧盟漫游条例III【欧盟漫游III】涉及本地转接模式，允许在欧洲2G/3G网络中漫游的欧洲用户将其互联网数据从其当前访问的公共陆地移动网络（VPLMN）直接路由到互联网。
Specific local breakout-related configuration considerations are listed below:
以下列出了与本地断开相关的具体配置注意事项：
o Operators may add the APN-OI-Replacement flag defined in 3GPP [TS29.272] into the user's subscription data. The visited network indicates a local domain name to replace the user requested Access Point Name (APN). Consequently, the traffic would be steered to the visited network. Those functions are normally deployed for the intra-PLMN mobility cases.
o 运营商可以将3GPP[TS29.272]中定义的APN OI替换标志添加到用户的订阅数据中。访问的网络表示一个本地域名，以替换用户请求的接入点名称（APN）。因此，流量将被引导到访问的网络。这些功能通常用于PLMN内部移动情况。
o Operators may also configure the VPLMN-Dynamic-Address-Allowed flag [TS29.272] in the user's profile to enable local breakout mode in VPLMNs.
o 运营商还可以在用户配置文件中配置VPLMN动态地址允许标志[TS29.272]，以在VPLMN中启用本地转接模式。
o 3GPP specified the Selected IP Traffic Offload (SIPTO) function [TS23.401] since Release 10 in order to get efficient route paths. It enables an operator to offload a portion of the traffic at a network node close to the UE's point of attachment to the network.
o 3GPP自第10版起指定了所选IP流量卸载（SIPTO）功能[TS23.401]，以获得有效的路由路径。它使运营商能够在靠近UE的网络连接点的网络节点上卸载部分流量。
o The Global System for Mobile Communications Association (GSMA) has defined Roaming Architecture for Voice over LTE with Local Breakout (RAVEL) [IR.65] as the IMS international roaming architecture. Local breakout mode has been adopted for the IMS roaming architecture.
o 全球移动通信系统协会（GSMA）已将LTE语音漫游体系结构（带本地中断（RAVEL）[IR.65]定义为IMS国际漫游体系结构。IMS漫游架构采用了本地中断模式。
Three stages occur when a subscriber roams to a visited network and intends to invoke services:
当订户漫游到访问的网络并打算调用服务时，会发生三个阶段：
o Network attachment: this occurs when the UE enters a visited network. During the attachment phase, the visited network should authenticate the subscriber and make a location update to the HSS/HLR in the home network of the subscriber. Accordingly, the subscriber profile is offered from the HSS/HLR. The subscriber profile contains the allowed APNs, the allowed PDP/PDN Types, and rules regarding the routing of data sessions (i.e., home routed or
o 网络连接：当UE进入访问的网络时发生。在连接阶段，受访网络应验证用户身份，并对用户家庭网络中的HSS/HLR进行位置更新。因此，HSS/HLR提供了订户配置文件。订户配置文件包含允许的APN、允许的PDP/PDN类型以及有关数据会话路由的规则（即，主路由或
local breakout mode) [TS29.272]. The SGSN/MME in the visited network can use this information to facilitate the subsequent PDP/PDN session creation.
局部断开模式[TS29.272]。到访网络中的SGSN/MME可以使用该信息来促进随后的PDP/PDN会话创建。
o PDP/PDN context creation: this occurs after the subscriber's UE has been successfully attached to the network. This stage is integrated with the attachment stage in the case of 4G, but is a separate process in 2G/3G. 3GPP specifies three types of PDP/PDN to describe connections: PDP/PDN Type IPv4, PDP/PDN Type IPv6, and PDP/PDN Type IPv4v6. When a subscriber creates a data session, their device requests a particular PDP/PDN Type. The allowed PDP/PDN Types for that subscriber are learned in the attachment stage. Hence, the SGSN and MME via the Serving Gateway (SGW) could initiate a PDP/PDN request to Gateway GSN (GGSN) / Packet Data Network Gateway (PGW) modulo subscription grants.
o PDP/PDN上下文创建：这发生在用户的UE成功连接到网络之后。在4G情况下，此阶段与连接阶段集成，但在2G/3G中是一个单独的过程。3GPP指定了三种类型的PDP/PDN来描述连接：PDP/PDN类型IPv4、PDP/PDN类型IPv6和PDP/PDN类型IPv4v6。当订户创建数据会话时，其设备请求特定的PDP/PDN类型。该订阅服务器允许的PDP/PDN类型在附件阶段学习。因此，经由服务网关（SGW）的SGSN和MME可以向网关GSN（GGSN）/分组数据网络网关（PGW）模块订阅授权发起PDP/PDN请求。
o Service requests: when the PDP/PDN context is created successfully, UEs may launch applications and request services based on the allocated IP addresses. The service traffic will be transmitted via the visited network.
o 服务请求：当成功创建PDP/PDN上下文时，UE可以启动应用程序并基于分配的IP地址请求服务。服务流量将通过访问的网络传输。
Failures that occur at the attachment stage (Section 3) are independent of home routed and the local breakout modes. Most failure cases in the PDP/PDN context creation (Section 4) and in service requests (Section 5) occur in the local breakout mode.
在连接阶段（第3节）发生的故障独立于主路由和本地断开模式。PDP/PDN上下文创建（第4节）和服务请求（第5节）中的大多数故障情况都发生在本地断开模式中。
3GPP specified PDP/PDN Type IPv4v6 in order to allow a UE to get both an IPv4 address and an IPv6 prefix within a single PDP/PDN bearer. This option is stored as a part of subscription data for a subscriber in the HLR/HSS. PDP/PDN Type IPv4v6 has been introduced at the inception of the Evolved Packet System (EPS) in 4G networks.
3GPP指定了PDP/PDN类型IPv4v6，以便允许UE在单个PDP/PDN承载中获得IPv4地址和IPv6前缀。此选项作为订阅方订阅数据的一部分存储在HLR/HSS中。PDP/PDN型IPv4v6是在4G网络中的演进分组系统（EPS）开始时引入的。
The nodes in 4G networks should present no issues with the handling of this PDN Type. However, the level of support varies in 2G/3G networks depending on the SGSN software version. In theory, S4-SGSN (i.e., an SGSN with S4 interface) has supported the PDP/PDN Type IPv4v6 since Release 8, and Gn-SGSN (i.e., the SGSN with Gn interface) has supported it since Release 9. In most cases, operators normally use Gn-SGSN to connect either GGSN in 3G or Packet Data Network Gateway (PGW) in 4G.
4G网络中的节点在处理这种PDN类型时不应出现任何问题。但是，2G/3G网络中的支持级别因SGSN软件版本而异。理论上，S4-SGSN（即具有S4接口的SGSN）自第8版起支持PDP/PDN类型IPv4v6，Gn-SGSN（即具有Gn接口的SGSN）自第9版起支持。在大多数情况下，运营商通常使用Gn SGSN连接3G中的GGSN或4G中的分组数据网络网关（PGW）。
The MAP (Mobile Application Part) protocol, as defined in 3GPP [TS29.002], is used over the Gr interface between SGSN and HLR. The MAP Information Element (IE) "ext-pdp-Type" contains the IPv4v6 PDP Type that is conveyed to SGSN from the HLR within the Insert Subscriber Data (ISD) MAP operation. If the SGSN does not support
3GPP[TS29.002]中定义的MAP（移动应用程序部分）协议在SGSN和HLR之间的Gr接口上使用。映射信息元素（IE）“ext pdp Type”包含在插入用户数据（ISD）映射操作中从HLR传输到SGSN的IPv4v6 pdp类型。如果SGSN不支持
the IPv4v6 PDP Type, it will not support the "ext-pdp-Type" IE; consequently, it must silently discard that IE and continue processing the rest of the ISD MAP message. An issue that has been observed is that multiple SGSNs are unable to correctly process a subscriber's data received in the Insert Subscriber Data Procedure [TS23.060]. As a consequence, it will likely discard the subscriber attach request. This is erroneous behavior due to the equipment not being compliant with 3GPP Release 9.
IPv4v6 PDP类型，不支持“ext PDP类型”IE；因此，它必须悄悄地丢弃该IE并继续处理ISD MAP消息的其余部分。观察到的一个问题是，多个SGSN无法正确处理在插入订户数据过程[TS23.060]中接收到的订户数据。因此，它可能会放弃订户附加请求。这是错误的行为，因为设备不符合3GPP版本9。
In order to avoid encountering this attach problem at a visited SGSN, both operators should make a comprehensive roaming agreement to support IPv6 and ensure that it aligns with the GSMA documents, e.g., [IR.33], [IR.88], and [IR.21]. Such an agreement requires the visited operator to get the necessary patch on all its SGSN nodes to support the "ext-pdp-Type" MAP IE sent by the HLR. To ensure data-session continuity in Radio Access Technology (RAT) handovers, the PDN Type sent by the HSS to the MME should be consistent with the PDP Type sent by the HLR to the Gn-SGSN. Where roaming agreements and visited SGSN nodes have not been updated, the HPLMN also has to make use of specific implementations (not standardized by 3GPP, discussed further in Section 6) in the HLR/HSS of the home network. That is, when the HLR/HSS receives an Update Location message from a visited SGSN not known to support dual-stack in a single bearer, subscription data allowing only PDP/PDN Type IPv4 or IPv6 will be sent to that SGSN in the Insert Subscriber Data procedure. This guarantees that the user profile is compatible with the visited SGSN/MME capability. In addition, HSS may not have to change if the PGW is aware of the subscriber's roaming status and only restricts the accepted PDN Type consistent with PDP Type sent by the HLR. For example, a AAA server may coordinate with the PGW to decide the allowed PDN Type.
为了避免在访问的SGSN上遇到此连接问题，两个运营商都应签订全面的漫游协议以支持IPv6，并确保其与GSMA文档（例如，[IR.33]、[IR.88]和[IR.21]）保持一致。这种协议要求访问的运营商在其所有SGSN节点上获得必要的补丁，以支持HLR发送的“ext pdp类型”映射IE。为确保无线接入技术（RAT）切换中的数据会话连续性，HSS发送给MME的PDN类型应与HLR发送给Gn SGSN的PDP类型一致。在漫游协议和访问的SGSN节点尚未更新的情况下，HPLMN还必须利用归属网络的HLR/HSS中的特定实现（未被3GPP标准化，在第6节中进一步讨论）。也就是说，当HLR/HSS从访问的SGSN接收到更新位置消息时，在插入订户数据过程中，仅允许PDP/PDN类型IPv4或IPv6的订阅数据将被发送到该SGSN，该SGSN不知道在单个承载中支持双堆栈。这保证了用户配置文件与访问的SGSN/MME功能兼容。此外，如果PGW知道用户的漫游状态，并且仅限制与HLR发送的PDP类型一致的已接受PDN类型，则HSS可能不必更改。例如，AAA服务器可与PGW协调以确定允许的PDN类型。
Alternatively, HPLMNs without the non-standardized capability to suppress the sending of "ext-pdp-Type" by the HLR may have to remove this attribute from APNs with roaming service. PDN Type IPv4v6 must also be removed from the corresponding profile for the APN in the HSS. This will restrict their roaming UEs to only IPv4 or IPv6 PDP/PDN activation. This alternative has problems:
或者，没有抑制HLR发送“ext pdp Type”的非标准化能力的HPLMN可能必须从具有漫游服务的APN中删除该属性。还必须从HSS中APN的相应配置文件中删除PDN类型IPv4v6。这将限制其漫游UE仅用于IPv4或IPv6 PDP/PDN激活。这一备选方案存在以下问题：
o The HPLMN cannot support dual-stack in a single bearer at home where the APN profile in the HLR/HSS is also used for roaming.
o 当HLR/HSS中的APN配置文件也用于漫游时，HPLMN无法在家中的单个承载中支持双堆栈。
o The UE may set up separate parallel bearers for IPv4 and IPv6, where only single-stack IPv4 or IPv6 service is preferred by the operator.
o UE可以为IPv4和IPv6设置单独的并行承载，其中运营商只首选单栈IPv4或IPv6服务。
When a subscriber's UE succeeds in the attach stage, the IP allocation process takes place to retrieve IP addresses. In general, a PDP/PDN Type IPv4v6 request implicitly allows the network side to make several IP assignment options, including IPv4-only, IPv6-only, IPv4 and IPv6 in single PDP/PDN bearer, and IPv4 and IPv6 in separated PDP/PDN bearers.
当订户的UE在连接阶段成功时，将进行IP分配过程以检索IP地址。通常，PDP/PDN类型的IPv4v6请求隐式允许网络侧进行多个IP分配选项，包括单个PDP/PDN承载中的仅IPv4、仅IPv6、IPv4和IPv6，以及分离的PDP/PDN承载中的IPv4和IPv6。
A PDP/PDN Type IPv4 or IPv6 restricts the network side to only allocate the requested IP address family.
PDP/PDN类型IPv4或IPv6限制网络侧仅分配请求的IP地址族。
This section summarizes several failures in the Home Routed (HR) and Local Breakout (LBO) mode as shown in Table 1.
本节总结了主路由（HR）和本地转接（LBO）模式下的几种故障，如表1所示。
+-------+-------------+------------------------+---------+
| Case# | UE request | PDP/PDN IP Type | Mode |
| | | permitted on GGSN/PGW | |
+-------+-------------+------------------------+---------+
| | IPv4v6 | IPv4v6 | HR |
| #1 |-------------+------------------------+---------+
| | IPv4v6 | IPv4 or IPv6 | LBO |
+-------+-------------+------------------------+---------+
| #2 | IPv6 | IPv6 | HR |
+-------+-------------+------------------------+---------+
| #3 | IPv4 | IPv6 | HR |
+-------+-------------+------------------------+---------+
| #4 | IPv6 | IPv4 | LBO |
+-------+-------------+------------------------+---------+
+-------+-------------+------------------------+---------+
| Case# | UE request | PDP/PDN IP Type | Mode |
| | | permitted on GGSN/PGW | |
+-------+-------------+------------------------+---------+
| | IPv4v6 | IPv4v6 | HR |
| #1 |-------------+------------------------+---------+
| | IPv4v6 | IPv4 or IPv6 | LBO |
+-------+-------------+------------------------+---------+
| #2 | IPv6 | IPv6 | HR |
+-------+-------------+------------------------+---------+
| #3 | IPv4 | IPv6 | HR |
+-------+-------------+------------------------+---------+
| #4 | IPv6 | IPv4 | LBO |
+-------+-------------+------------------------+---------+
Table 1: Failure Cases in the PDP/PDN Creation
表1:PDP/PDN创建中的故障案例
Dual-stack capability is provided using separate PDP/PDN activation in the visited network that doesn't support PDP/PDN Type IPv4v6. That means only separate, parallel, single-stack IPv4 and IPv6 PDP/PDN connections are allowed to be initiated to separately allocate an IPv4 address and an IPv6 prefix. The SGSN does not support the Dual Address Bearer Flag (DAF) or does not set the DAF because the operator uses single addressing per bearer to support interworking with nodes of earlier releases. Regardless of home routed or local breakout mode, GGSN/PGW will change PDN/PDP Type to a single address PDP/PDN Type and return the Session Management (SM) Cause #52 "single address bearers only allowed" or SM Cause #28 "unknown PDP address or PDP type" as per [TS24.008] and [TS24.301] to
在不支持PDP/PDN类型IPv4v6的受访网络中，使用单独的PDP/PDN激活来提供双堆栈功能。这意味着只允许启动单独、并行、单堆栈IPv4和IPv6 PDP/PDN连接，以分别分配IPv4地址和IPv6前缀。SGSN不支持双地址承载标志（DAF）或不设置DAF，因为运营商使用每个承载的单地址来支持与早期版本节点的互通。无论主路由模式还是本地转接模式，GGSN/PGW都会将PDN/PDP类型更改为单地址PDP/PDN类型，并根据[TS24.008]和[TS24.301]将会话管理（SM）原因#52“仅允许单地址承载器”或SM原因#28“未知PDP地址或PDP类型”返回给
the UE. In this case, the UE may make another PDP/PDN request with a single address PDP Type (IPv4 or IPv6) other than the one already activated.
欧洲联盟。在这种情况下，UE可以发出具有单一地址PDP类型（IPv4或IPv6）的另一PDP/PDN请求，而不是已经激活的PDP类型。
This approach suffers from the following drawbacks:
这种方法有以下缺点：
o The parallel PDP/PDN activation would likely double PDP/PDN bearer resource on the network side and Radio Access Bearer (RAB) resource on the Radio Access Network (RAN) side. It also impacts the capacity of the GGSN/PGW, since only a certain amount of PDP/PDN activation is allowed on those nodes.
o 并行PDP/PDN激活可能使网络侧的PDP/PDN承载资源和无线接入网络（RAN）侧的无线接入承载（RAB）资源加倍。它还影响GGSN/PGW的容量，因为这些节点上只允许一定数量的PDP/PDN激活。
o Some networks may allow only one PDP/PDN to be alive for each subscriber. For example, an IPv6 PDP/PDN will be rejected if the subscriber has an active IPv4 PDP/PDN. Therefore, the subscriber would not be able to obtain the IPv6 connection in the visited network. It is even worse, as they may have a risk of losing all data connectivity if the IPv6 PDP gets rejected with a permanent error at the APN level and not an error specific to the PDP-Type IPv6 requested.
o 某些网络可能只允许每个订户有一个PDP/PDN处于活动状态。例如，如果订户具有活动的IPv4 PDP/PDN，则IPv6 PDP/PDN将被拒绝。因此，订户将无法在访问的网络中获得IPv6连接。更糟糕的是，如果IPv6 PDP因APN级别的永久性错误而被拒绝，而不是特定于请求的IPv6类型的错误，则它们可能有丢失所有数据连接的风险。
o Additional correlations between those two PDP/PDN contexts are required on the charging system.
o 充电系统需要这两个PDP/PDN上下文之间的额外相关性。
o Policy and Charging Rules Function (PCRF) [TS29.212] / Policy and Charging Enforcement Function (PCEF) treats the IPv4 and IPv6 sessions as independent and performs different quality-of-service (QoS) policies. The subscriber may have an unstable experience due to different behaviors on each IP version connection.
o 策略和计费规则功能（PCRF）[TS29.212]/策略和计费实施功能（PCEF）将IPv4和IPv6会话视为独立会话，并执行不同的服务质量（QoS）策略。由于每个IP版本连接上的行为不同，订户可能会有不稳定的体验。
o Mobile devices may have a limitation on the number of allowed simultaneous PDP/PDN contexts. Excessive PDP/PDN activations may result in service disruption.
o 移动设备可能对允许的同时PDP/PDN上下文的数量有限制。PDP/PDN过度激活可能导致服务中断。
In order to avoid the issue, the roaming agreement in the home routed mode should make sure the visited SGSN supports and sets the DAF. Since the PDP/PDN Type IPv4v6 is supported in the GGSN/PGW of the home network, it's expected that the visited SGSN/MME could create a dual-stack bearer as the UE requested.
为了避免该问题，在归属路由模式下的漫游协议应确保访问的SGSN支持并设置DAF。由于在家庭网络的GGSN/PGW中支持PDP/PDN类型IPv4v6，因此预计到访的SGSN/MME可以根据UE请求创建双栈承载。
In the local breakout mode, the visited SGSN may only allow single IP version addressing. In this case, the DAF on the visited SGSN/MME has to be unset. One approach is to set a dedicated APN [TS23.003] profile to only request PDP/PDN Type IPv4 in the roaming network. Some operators may also consider not adopting the local breakout mode to avoid the risks.
在本地断开模式下，访问的SGSN可能只允许单个IP版本寻址。在这种情况下，访问的SGSN/MME上的DAF必须取消设置。一种方法是将专用APN[TS23.003]配置文件设置为仅在漫游网络中请求PDP/PDN类型的IPv4。一些运营商也可以考虑不采用本地突破模式来规避风险。
PDP/PDN Type IPv6 has good compatibility to visited networks during the network attachment. In order to support the IPv6-only visitors, SGSN/MME in the visited network is required to accept IPv6-only PDP/PDN activation requests and enable IPv6 on the user plane in the direction of the home network.
PDP/PDN型IPv6在网络连接期间与访问的网络具有良好的兼容性。为了支持仅限IPv6的访问者，访问网络中的SGSN/MME需要接受仅限IPv6的PDP/PDN激活请求，并在家庭网络方向的用户平面上启用IPv6。
In some cases, IPv6-only visitors may still be subject to the SGSN capability in visited networks. This becomes especially risky if the home operator performs roaming steering targeted to an operator that doesn't allow IPv6. The visited SGSN may just directly reject the PDP context activation. Therefore, it's expected that the visited network is IPv6 roaming-friendly to enable the functions on SGSN/MME by default. Otherwise, operators may consider steering the roaming traffic to the IPv6-enabled visited network that has an IPv6 roaming agreement.
在某些情况下，仅限IPv6的访问者可能仍受访问网络中SGSN功能的约束。如果家庭运营商针对不允许IPv6的运营商执行漫游指导，这将变得特别危险。访问的SGSN可以直接拒绝PDP上下文激活。因此，预计访问的网络是IPv6漫游友好的，以在默认情况下启用SGSN/MME上的功能。否则，运营商可以考虑将漫游业务转向具有IPv6漫游协议的IPv6启用的访问网络。
If IPv6 single stack with the home routed mode is deployed, the requested PDP/PDN Type should also be IPv6. Some implementations that support the roaming APN profile may set IPv4 as the default PDP/PDN Type, since the visited network is incapable of supporting PDP/PDN Types IPv4v6 (Section 4.1) and IPv6 (Section 4.2). The PDP/PDN request will fail because the APN in the home network only allows IPv6. Therefore, the roaming APNs have to be compliant with the home network configuration when home routed mode is adopted.
如果部署了具有主路由模式的IPv6单堆栈，则请求的PDP/PDN类型也应为IPv6。支持漫游APN配置文件的一些实现可能将IPv4设置为默认PDP/PDN类型，因为访问的网络无法支持PDP/PDN类型IPv4v6（第4.1节）和IPv6（第4.2节）。PDP/PDN请求将失败，因为家庭网络中的APN仅允许IPv6。因此，当采用归属路由模式时，漫游APN必须符合归属网络配置。
In the local breakout mode, PDP/PDN Type IPv6 should have no issues to pass through the network attachment process, since 3GPP specified the PDP/PDN Type IPv6 as early as PDP/PDN Type IPv4. When a visitor requests PDP/PDN Type IPv6, the network should only return the expected IPv6 prefix. The UE may fail to get an IPv6 prefix if the visited network only allocates an IPv4 address. In this case, the visited network will reject the request and send the cause code to the UE.
在本地转接模式下，PDP/PDN类型IPv6应该没有问题通过网络连接过程，因为3GPP早在PDP/PDN类型IPv4之前就指定了PDP/PDN类型IPv6。当访问者请求PDP/PDN类型IPv6时，网络应仅返回预期的IPv6前缀。如果访问的网络仅分配IPv4地址，则UE可能无法获取IPv6前缀。在这种情况下，所访问的网络将拒绝该请求并向UE发送原因码。
A proper fallback scheme for PDP/PDN Type IPv6 is desirable; however, there is no standard way to specify this behavior. The roaming APN profile could help to address the issue by setting the PDP/PDN Type to IPv4. For instance, the Android system solves the issue by configuring the roaming protocol to IPv4 for the APN. It guarantees that UE will always initiate a PDP/PDN Type IPv4 in the roaming area.
对于PDP/PDN类型的IPv6，需要合适的回退方案；但是，没有指定此行为的标准方法。漫游APN配置文件可以通过将PDP/PDN类型设置为IPv4来帮助解决此问题。例如，Android系统通过将APN的漫游协议配置为IPv4解决了这个问题。它保证UE将始终在漫游区域中启动PDP/PDN类型的IPv4。
After the successful network attachment and IP address allocation, applications could start to request service based on the activated PDP/PDN context. The service request may depend on specific IP family or network collaboration. If traffic is offloaded locally (Section 2.1.2), the visited network may not be able to accommodate the UE's service requests. This section describes the failures.
成功连接网络和分配IP地址后，应用程序可以开始基于激活的PDP/PDN上下文请求服务。服务请求可能取决于特定的IP系列或网络协作。如果流量在本地卸载（第2.1.2节），则到访网络可能无法容纳UE的服务请求。本节介绍了故障。
Operators may only allow IPv6 in the IMS APN. VoLTE [IR.92] and Rich Communication Suite (RCS) [RCC.07] use the APN to offer voice service for visitors. The IMS roaming in RAVEL architecture [IR.65] offloads voice and video traffic in the visited network; therefore, a dual-stack visitor can only be assigned with an IPv6 prefix but no IPv4 address. If the applications can't support IPv6, the service is likely to fail.
运营商只能在IMS APN中使用IPv6。VoLTE[IR.92]和Rich Communication Suite（RCS）[RCC.07]使用APN为访客提供语音服务。RAVEL架构中的IMS漫游[IR.65]卸载访问网络中的语音和视频流量；因此，只能为双堆栈访问者分配IPv6前缀，而不能分配IPv4地址。如果应用程序不能支持IPv6，服务可能会失败。
Translation-based methods, for example, 464XLAT [RFC6877] or Bump-in-the-Host (BIH) [RFC6535], may help to address the issue if there are IPv6 compatibility problems. The translation function could be enabled in an IPv6-only network and disabled in a dual-stack or IPv4 network; therefore, the IPv4 applications only get the translation in the IPv6 network and they perform normally in an IPv4 or dual-stack network.
如果存在IPv6兼容性问题，基于转换的方法，例如464XLAT[RFC6877]或主机中的通气（BIH）[RFC6535]，可能有助于解决该问题。转换功能可在仅IPv6网络中启用，在双栈或IPv4网络中禁用；因此，IPv4应用程序仅在IPv6网络中获得转换，并且它们在IPv4或双堆栈网络中正常运行。
464XLAT [RFC6877] is proposed to address the IPv4 compatibility issue in an IPv6-only connectivity environment. The customer-side translator (CLAT) function on a mobile device is likely used in conjunction with a PDP/PDN IPv6 Type request and cooperates with a remote NAT64 [RFC6146] device.
464XLAT[RFC6877]旨在解决仅限IPv6连接环境中的IPv4兼容性问题。移动设备上的客户端转换器（CLAT）功能可能与PDP/PDN IPv6类型请求一起使用，并与远程NAT64[RFC6146]设备协作。
464XLAT may use the mechanism defined in [RFC7050] or [RFC7225] to detect the presence of NAT64 devices and to learn the IPv6 prefix used for protocol translation [RFC6052].
464XLAT可以使用[RFC7050]或[RFC7225]中定义的机制来检测NAT64设备的存在，并学习用于协议转换的IPv6前缀[RFC6052]。
In the local breakout approach, a UE with the 464XLAT function roaming on an IPv6 visited network may encounter various situations. For example, the visited network may not have deployed DNS64 [RFC6147] but only NAT64, or CLAT may not be able to discover the provider-side translator (PLAT) translation IPv6 prefix used as a destination of the PLAT. If the visited network doesn't have a NAT64 and DNS64 deployed, 464XLAT can't perform successfully due to the
在本地分支方法中，具有464XLAT功能的UE在IPv6访问的网络上漫游可能会遇到各种情况。例如，访问的网络可能没有部署DNS64[RFC6147]，但只有NAT64，或者CLAT可能无法发现用作平台目的地的提供商端转换器（PLAT）翻译IPv6前缀。如果访问的网络没有部署NAT64和DNS64，464XLAT将无法成功执行，因为
lack of PLAT collaboration. Even in the case of the presence of NAT64 and DNS64, a pre-configured PLAT IPv6 prefix in the CLAT may cause failure because it can't match the PLAT translation.
缺乏平台协作。即使在存在NAT64和DNS64的情况下，CLAT中预先配置的PLAT IPv6前缀也可能会导致失败，因为它与PLAT转换不匹配。
Considering the various network configurations, operators may turn off local breakout and use the home routed mode to perform 464XLAT. Alternatively, UE may support the different roaming profile configuration to adopt 464XLAT in the home network and use IPv4-only in the visited networks.
考虑到各种网络配置，运营商可能会关闭本地转接，并使用主路由模式执行464XLAT。或者，UE可以支持不同的漫游配置文件配置，以便在归属网络中采用464XLAT，并且仅在访问的网络中使用IPv4。
A proper user profile configuration would provide a deterministic outcome to the PDP/PDN creation stage where dual-stack, IPv4-only, and IPv6-only connectivity requests may come from devices. The HLR/HSS may have to apply extra logic (not standardized by 3GPP) to achieve this. It is also desirable that the network be able to set up connectivity of any requested PDP/PDN context type.
适当的用户配置文件配置将为PDP/PDN创建阶段提供确定性结果，其中双堆栈、仅IPv4和仅IPv6连接请求可能来自设备。HLR/HSS可能必须应用额外的逻辑（未被3GPP标准化）来实现这一点。还希望网络能够建立任何请求的PDP/PDN上下文类型的连接。
The following are examples to illustrate the settings for the scenarios and the decision criteria to be applied when returning user profile information from the HLR to the visited SGSN.
以下示例说明了场景设置和将用户配置文件信息从HLR返回到访问的SGSN时应用的决策标准。
user profile #1:
用户配置文件#1：
PDP-Context ::= SEQUENCE {
pdp-ContextId ContextId,
pdp-Type PDP-Type-IPv4
....
ext-pdp-Type PDP-Type-IPv4v6
...
}
PDP-Context ::= SEQUENCE {
pdp-ContextId ContextId,
pdp-Type PDP-Type-IPv4
....
ext-pdp-Type PDP-Type-IPv4v6
...
}
user profile #2:
用户配置文件#2：
PDP-Context ::= SEQUENCE {
pdp-ContextId ContextId,
pdp-Type PDP-Type-IPv6
....
}
PDP-Context ::= SEQUENCE {
pdp-ContextId ContextId,
pdp-Type PDP-Type-IPv6
....
}
Scenario 1: Support of IPv6-Only, IPv4-Only, and Dual-Stack Devices
场景1：仅支持IPv6、仅支持IPv4和双堆栈设备
The full PDP-context parameters are referred to Section 17.7.1 ("Mobile Service data types") of [TS29.002]. User profiles #1 and #2 share the same "ContextId". The setting of user profile #1 enables IPv4-only and dual-stack devices to work. User profile #2 fulfills the request if the device asks for IPv6-only PDP context.
完整的PDP上下文参数参考[TS29.002]第17.7.1节（“移动服务数据类型”）。用户配置文件#1和#2共享相同的“ContextId”。用户配置文件#1的设置允许仅IPv4和双堆栈设备工作。如果设备请求仅IPv6 PDP上下文，则用户配置文件#2满足请求。
user profile #1:
用户配置文件#1：
PDP-Context ::= SEQUENCE {
pdp-ContextId ContextId,
pdp-Type PDP-Type-IPv4
....
ext-pdp-Type PDP-Type-IPv4v6
...
}
PDP-Context ::= SEQUENCE {
pdp-ContextId ContextId,
pdp-Type PDP-Type-IPv4
....
ext-pdp-Type PDP-Type-IPv4v6
...
}
user profile #2:
用户配置文件#2：
PDP-Context ::= SEQUENCE {
pdp-ContextId ContextId,
pdp-Type PDP-Type-IPv4
....
}
PDP-Context ::= SEQUENCE {
pdp-ContextId ContextId,
pdp-Type PDP-Type-IPv4
....
}
Scenario 2: Support of Dual-Stack Devices with Pre-Release 9 Visited SGSN (vSGSN) Access
场景2：支持预发布9访问SGSN（vSGSN）访问的双栈设备
User profiles #1 and #2 share the same "ContextId". If a visited SGSN is identified as early as pre-Release 9, the HLR/HSS should only send user profile #2 to the visited SGSN.
用户配置文件#1和#2共享相同的“ContextId”。如果早在第9版之前就确定了访问过的SGSN，HLR/HSS应仅向访问过的SGSN发送用户配置文件#2。
Several failure cases have been discussed in this document. It has been illustrated that the major problems happen at three stages: the initial network attachment, the PDP/PDN creation, and service requests.
本文件讨论了几个故障案例。已经说明，主要问题发生在三个阶段：初始网络连接、PDP/PDN创建和服务请求。
In the network attachment stage, PDP/PDN Type IPv4v6 is the major concern to the visited pre-Release 9 SGSN. 3GPP didn't specify PDP/PDN Type IPv4v6 in the earlier releases. That PDP/PDN Type is supported in the newly built EPS network, but it isn't supported well in the third-generation network. Visited SGSNs may discard the subscriber's attach requests because the SGSN is unable to correctly process PDP/PDN Type IPv4v6. Operators may have to adopt temporary
在网络连接阶段，PDP/PDN类型IPv4v6是访问的预发布9 SGSN的主要关注点。3GPP在早期版本中没有指定PDP/PDN类型IPv4v6。这种PDP/PDN类型在新建的EPS网络中得到了支持，但在第三代网络中没有得到很好的支持。已访问的SGSN可能会放弃订阅者的附加请求，因为SGSN无法正确处理PDP/PDN类型IPv4v6。运营商可能必须采取临时措施
solutions unless all the interworking nodes (i.e., the SGSN) in the visited network have been upgraded to support the ext-PDP-Type feature.
解决方案，除非访问网络中的所有互通节点（即SGSN）已升级以支持ext PDP类型功能。
In the PDP/PDN creation stage, support of PDP/PDN Types IPv4v6 and IPv6 on the visited SGSN is the major concern. It has been observed that single-stack IPv6 in the home routed mode is a viable approach to deploy IPv6. It is desirable that the visited SGSN have the ability to enable IPv6 on the user plane by default. For support of the PDP/PDN Type IPv4v6, it is suggested to set the DAF. As a complementary function, the implementation of a roaming APN configuration is useful to accommodate the visited network. However, it should consider roaming architecture and the permitted PDP/PDN Type to properly set the UE. Roaming APN in the home routed mode is recommended to align with home network profile setting. In the local breakout case, PDP/PDN Type IPv4 could be selected as a safe way to initiate PDP/PDN activation.
在PDP/PDN创建阶段，主要关注在访问的SGSN上支持PDP/PDN类型IPv4v6和IPv6。据观察，主路由模式下的单栈IPv6是部署IPv6的可行方法。期望所访问的SGSN在默认情况下能够在用户平面上启用IPv6。为了支持PDP/PDN类型IPv4v6，建议设置DAF。作为一项补充功能，漫游APN配置的实现有助于适应访问的网络。但是，应该考虑漫游架构和允许的PDP／PDN类型来适当地设置UE。建议在主路由模式下漫游APN与主网络配置文件设置保持一致。在本地断开情况下，可以选择PDP/PDN类型IPv4作为启动PDP/PDN激活的安全方式。
In the service requests stage, the failure cases mostly occur in the local breakout case. The visited network may not be able to satisfy the requested capability from applications or UEs. Operators may consider using home routed mode to avoid these problems. Several solutions, in either the network side or mobile device side, can also help to address the issue. For example,
在服务请求阶段，故障案例大多发生在本地断开案例中。所访问的网络可能无法满足来自应用程序或ue的请求能力。运营商可以考虑使用家庭路由模式，以避免这些问题。网络端或移动设备端的几种解决方案也有助于解决该问题。例如
o 464XLAT could help IPv4 applications access IPv6 visited networks.
o 464XLAT可以帮助IPv4应用程序访问IPv6访问的网络。
o Networks can deploy a AAA server to coordinate the mobile device capability. Once the GGSN/PGW receives the session creation request, it will initiate a request to a AAA server in the home network via the RADIUS or Diameter protocol [TS29.061]. The request contains subscriber and visited network information, e.g., PDP/PDN Type, International Mobile Equipment Identity (IMEI), Software Version (SV) and visited SGSN/MME location code, etc. The AAA server could take mobile device capability and combine it with the visited network information to ultimately determine the type of session to be created, i.e., IPv4, IPv6, or IPv4v6.
o 网络可以部署AAA服务器来协调移动设备的功能。一旦GGSN/PGW收到会话创建请求，它将通过RADIUS或Diameter协议[TS29.061]向家庭网络中的AAA服务器发起请求。请求包含用户和访问的网络信息，例如PDP/PDN类型、国际移动设备标识（IMEI）、软件版本（SV）和访问的SGSN/MME位置码，AAA服务器可以获取移动设备功能，并将其与访问的网络信息相结合，以最终确定要创建的会话类型，即IPv4、IPv6或IPv4v6。
Although this document defines neither a new architecture nor a new protocol, the reader is encouraged to refer to [RFC6459] for a generic discussion on IPv6-related security considerations.
尽管本文档既没有定义新的体系结构，也没有定义新的协议，但鼓励读者参考[RFC6459]了解有关IPv6相关安全注意事项的一般性讨论。
[IR.21] Global System for Mobile Communications Association (GSMA), "Roaming Database, Structure and Updating Procedures", IR.21, Version 7.4, November 2013.
[IR.21]全球移动通信系统协会（GSMA），“漫游数据库、结构和更新程序”，IR.21，7.4版，2013年11月。
[IR.65] Global System for Mobile Communications Association (GSMA), "IMS Roaming and Interworking Guidelines", IR.65, Version 15.0, January 2015.
[IR.65]全球移动通信系统协会（GSMA），“IMS漫游和互通指南”，IR.65，版本15.0，2015年1月。
[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, <http://www.rfc-editor.org/info/rfc6146>.
[RFC6146]Bagnulo，M.，Matthews，P.，和I.van Beijnum，“有状态NAT64：从IPv6客户端到IPv4服务器的网络地址和协议转换”，RFC 61462011年4月<http://www.rfc-editor.org/info/rfc6146>.
[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, <http://www.rfc-editor.org/info/rfc6147>.
[RFC6147]Bagnulo，M.，Sullivan，A.，Matthews，P.，和I.van Beijnum，“DNS64：用于从IPv6客户端到IPv4服务器的网络地址转换的DNS扩展”，RFC 61472011年4月<http://www.rfc-editor.org/info/rfc6147>.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, April 2013, <http://www.rfc-editor.org/info/rfc6877>.
[RFC6877]Mawatari，M.，Kawashima，M.，和C.Byrne，“464XLAT：有状态和无状态翻译的组合”，RFC 6877，2013年4月<http://www.rfc-editor.org/info/rfc6877>.
[TS23.060] 3GPP, "General Packet Radio Service (GPRS); Service description; Stage 2 v9.00", TS 23.060, March 2009.
[TS23.060]3GPP，“通用分组无线业务（GPRS）；业务描述；第2阶段v9.00”，TS 23.060，2009年3月。
[TS23.401] 3GPP, "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access v9.00", TS 23.401, March 2009.
[TS23.401]3GPP，“通用分组无线业务（GPRS）增强，用于演进型通用地面无线接入网络（E-UTRAN）接入v9.00”，TS 23.401，2009年3月。
[TS29.002] 3GPP, "Mobile Application Part (MAP) specification v9.12.0", TS 29.002, December 2009.
[TS29.002]3GPP，“移动应用部分（MAP）规范v9.12.0”，TS 29.002，2009年12月。
[TS29.272] 3GPP, "Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol v9.00", TS 29.272, September 2009.
[TS29.272]3GPP，“基于Diameter协议v9.00的移动管理实体（MME）和服务GPRS支持节点（SGSN）相关接口”，TS 29.272，2009年9月。
[EU-Roaming-III] Amdocs Inc., "Amdocs 2014 EU Roaming Regulation III Solution", July 2013, <http://www.amdocs.com/Products/ Revenue-Management/Documents/ amdocs-eu-roaming-regulation-III-solution.pdf>.
[EU Roaming III]Amdocs Inc.，“Amdocs 2014 EU Roaming Regulation III解决方案”，2013年7月<http://www.amdocs.com/Products/ 收入管理/Documents/amdocs欧盟漫游条例III解决方案.pdf>。
[IR.33] Global System for Mobile Communications Association (GSMA), "GPRS Roaming Guidelines", IR.33, Version 7.0, June 2014.
[IR.33]全球移动通信系统协会（GSMA），“GPRS漫游指南”，IR.33，7.0版，2014年6月。
[IR.34] Global System for Mobile Communications Association (GSMA), "Guidelines for IPX Provider networks", IR.34 Version 11.0, January 2015.
[IR.34]全球移动通信系统协会（GSMA），“IPX提供商网络指南”，IR.34 11.0版，2015年1月。
[IR.88] Global System for Mobile Communications Association (GSMA), "LTE Roaming Guidelines", IR.88, Version 12.0, January 2015.
[IR.88]全球移动通信系统协会（GSMA），“LTE漫游指南”，IR.88，版本12.0，2015年1月。
[IR.92] Global System for Mobile Communications Association (GSMA), "IMS Profile for Voice and SMS", IR.92, Version 7.1, January 2015.
[IR.92]全球移动通信系统协会（GSMA），“语音和短信的IMS配置文件”，IR.92，7.1版，2015年1月。
[RCC.07] Global System for Mobile Communications Association (GSMA), "Rich Communication Suite 5.2 Advanced Communications Services and Client Specification", RCC.07, Version 5.0, May 2014.
[RCC.07]全球移动通信系统协会（GSMA），“富通信套件5.2高级通信服务和客户端规范”，RCC.07，版本5.0，2014年5月。
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010, <http://www.rfc-editor.org/info/rfc6052>.
[RFC6052]Bao，C.，Huitema，C.，Bagnulo，M.，Boucadair，M.，和X.Li，“IPv4/IPv6转换器的IPv6寻址”，RFC 6052010年10月<http://www.rfc-editor.org/info/rfc6052>.
[RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)", RFC 6459, January 2012, <http://www.rfc-editor.org/info/rfc6459>.
[RFC6459]Korhonen，J.，Ed.，Soininen，J.，Patil，B.，Savolainen，T.，Bajko，G.，和K.Iisakkila，“第三代合作伙伴关系项目（3GPP）中的IPv6演进包系统（EPS）”，RFC 6459，2012年1月<http://www.rfc-editor.org/info/rfc6459>.
[RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts Using "Bump-in-the-Host" (BIH)", RFC 6535, February 2012, <http://www.rfc-editor.org/info/rfc6535>.
[RFC6535]Huang，B.，Deng，H.，和T.Savolainen，“使用“主机中的凹凸”（BIH）的双堆栈主机”，RFC 65352012年2月<http://www.rfc-editor.org/info/rfc6535>.
[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 7050, November 2013, <http://www.rfc-editor.org/info/rfc7050>.
[RFC7050]Savolainen，T.，Korhonen，J.，和D.Wing，“用于IPv6地址合成的IPv6前缀的发现”，RFC 70502013年11月<http://www.rfc-editor.org/info/rfc7050>.
[RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP)", RFC 7225, May 2014, <http://www.rfc-editor.org/info/rfc7225>.
[RFC7225]Boucadair，M.，“使用端口控制协议（PCP）发现NAT64 IPv6前缀”，RFC 7225，2014年5月<http://www.rfc-editor.org/info/rfc7225>.
[TR23.975] 3GPP, "IPv6 migration guidelines", TR 23.975, June 2011.
[TR23.975]3GPP，“IPv6迁移指南”，TR 23.9752011年6月。
[TS23.003] 3GPP, "Numbering, addressing and identification v9.0.0", TS 23.003, September 2009.
[TS23.003]3GPP，“编号、寻址和标识v9.0.0”，TS 23.003，2009年9月。
[TS24.008] 3GPP, "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 v9.00", TS 24.008, September 2009.
[TS24.008]3GPP，“移动无线电接口第3层规范；核心网络协议；第3阶段v9.00”，TS 24.008，2009年9月。
[TS24.301] 3GPP, "Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS) ; Stage 3 v9.00", TS 24.301, September 2009.
[TS24.301]3GPP，“演进包系统（EPS）的非接入层（NAS）协议；阶段3 v9.00”，TS 24.301，2009年9月。
[TS29.061] 3GPP, "Interworking between the Public Land Mobile Network (PLMN) supporting packet based services and Packet Data Networks (PDN) v9.14.0", TS 29.061, January 2015.
[TS29.061]3GPP，“支持分组业务的公共陆地移动网络（PLMN）与分组数据网络（PDN）v9.14.0之间的互通”，TS 29.061，2015年1月。
[TS29.212] 3GPP, "Policy and Charging Control (PCC); Reference points v9.0.0", TS 29.212, September 2009.
[TS29.212]3GPP，“政策和收费控制（PCC）；参考点v9.0.0”，TS 29.212，2009年9月。
Acknowledgements
致谢
Many thanks to F. Baker and J. Brzozowski for their support.
非常感谢F.Baker和J.Brzowski的支持。
This document is the result of the IETF v6ops IPv6-Roaming design team effort.
本文档是IETF v6ops IPv6漫游设计团队努力的结果。
The authors would like to thank Mikael Abrahamsson, Victor Kuarsingh, Nick Heatley, Alexandru Petrescu, Tore Anderson, Cameron Byrne, Holger Metschulat, and Geir Egeland for their helpful discussions and comments.
作者要感谢米凯尔·阿布拉罕松、维克多·夸辛格、尼克·希特利、亚历山大·彼得雷斯库、托尔·安德森、卡梅隆·伯恩、霍尔格·梅特舒拉特和盖尔·埃格兰的讨论和评论。
The authors especially thank Fred Baker and Ross Chandler for their efforts and contributions that substantially improved the readability of the document.
作者特别感谢Fred Baker和Ross Chandler的努力和贡献，他们的努力和贡献大大提高了文档的可读性。
Contributors
贡献者
The following individual contributed to this document.
以下个人对本文件作出了贡献。
Vizdal Ales Deutsche Telekom AG Tomickova 2144/1 Prague 4, 149 00 Czech Republic
捷克共和国布拉格14900布拉格2144/1号德国电信公司
EMail: ales.vizdal@t-mobile.cz
EMail: ales.vizdal@t-mobile.cz
Authors' Addresses
作者地址
Gang Chen China Mobile 53A,Xibianmennei Ave., Xicheng District, Beijing 100053 China
陈刚中国移动北京市西城区西边门内大街53A，邮编100053
EMail: phdgang@gmail.com, chengang@chinamobile.com
EMail: phdgang@gmail.com, chengang@chinamobile.com
Hui Deng China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China
惠登中国移动北京市宣武区西边门内大街53A，邮编：100053
EMail: denghui@chinamobile.com
EMail: denghui@chinamobile.com
Dave Michaud Rogers Communications 8200 Dixie Rd. Brampton, ON L6T 0C1 Canada
戴夫·米肖德·罗杰斯通讯公司位于加拿大L6T 0C1的布兰顿迪克西路8200号
EMail: dave.michaud@rci.rogers.com
EMail: dave.michaud@rci.rogers.com
Jouni Korhonen Broadcom Corporation 3151 Zanker Rd. San Jose, CA 95134 United States
Jouni Korhonen Broadcom Corporation美国加利福尼亚州圣何塞市赞克路3151号，邮编95134
EMail: jouni.nospam@gmail.com
EMail: jouni.nospam@gmail.com
Mohamed Boucadair France Telecom Rennes, 35000 France
Mohamed Boucadair法国电信雷恩，35000法国
EMail: mohamed.boucadair@orange.com
EMail: mohamed.boucadair@orange.com