Internet Engineering Task Force (IETF) J. Korhonen, Ed.
Request for Comments: 7066 Broadcom
Obsoletes: 3316 J. Arkko, Ed.
Category: Informational Ericsson
ISSN: 2070-1721 T. Savolainen
Nokia
S. Krishnan
Ericsson
November 2013
Internet Engineering Task Force (IETF) J. Korhonen, Ed.
Request for Comments: 7066 Broadcom
Obsoletes: 3316 J. Arkko, Ed.
Category: Informational Ericsson
ISSN: 2070-1721 T. Savolainen
Nokia
S. Krishnan
Ericsson
November 2013
IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts
第三代合作伙伴计划（3GPP）蜂窝主机的IPv6
Abstract
摘要
As the deployment of third and fourth generation cellular networks progresses, a large number of cellular hosts are being connected to the Internet. Standardization organizations have made the Internet Protocol version 6 (IPv6) mandatory in their specifications. However, the concept of IPv6 covers many aspects and numerous specifications. In addition, the characteristics of cellular links in terms of bandwidth, cost, and delay put special requirements on how IPv6 is used. This document considers IPv6 for cellular hosts that attach to the General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), or Evolved Packet System (EPS) networks (hereafter collectively referred to as Third Generation Partnership Project (3GPP) networks). This document also lists specific IPv6 functionalities that need to be implemented in addition to what is already prescribed in the IPv6 Node Requirements document (RFC 6434). It also discusses some issues related to the use of these components when operating in these networks. This document obsoletes RFC 3316.
随着第三代和第四代蜂窝网络部署的进展，大量蜂窝主机正在连接到互联网。标准化组织已在其规范中强制规定了Internet协议版本6（IPv6）。然而，IPv6的概念涵盖了许多方面和许多规范。此外，蜂窝链路在带宽、成本和延迟方面的特性对如何使用IPv6提出了特殊要求。本文档考虑连接到通用分组无线业务（GPRS）、通用移动通信系统（UMTS）或演进分组系统（EPS）网络（以下统称为第三代合作伙伴计划（3GPP）网络）的蜂窝主机的IPv6。本文档还列出了除IPv6节点需求文档（RFC 6434）中已经规定的功能外，还需要实现的特定IPv6功能。本文还讨论了在这些网络中运行时与这些组件的使用相关的一些问题。本文件废除了RFC 3316。
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/rfc7066.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7066.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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. Scope of This Document .....................................3
1.2. Abbreviations ..............................................5
1.3. Cellular Host IPv6 Features ................................6
2. Basic IP ........................................................6
2.1. Internet Protocol Version 6 ................................6
2.2. Neighbor Discovery in 3GPP Networks ........................6
2.3. Stateless Address Autoconfiguration ........................8
2.4. IP Version 6 over PPP ......................................8
2.5. Multicast Listener Discovery (MLD) for IPv6 ................9
2.6. Privacy Extensions for Address Configuration in IPv6 .......9
2.7. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) ......9
2.8. DHCPv6 Prefix Delegation ..................................10
2.9. Router Preferences and More-Specific Routes ...............10
2.10. Neighbor Discovery and Additional Host Configuration .....10
3. IP Security ....................................................11
3.1. Extension Header Considerations ...........................11
4. Mobility .......................................................11
5. Acknowledgements ...............................................11
6. Security Considerations ........................................12
7. References .....................................................14
7.1. Normative References ......................................14
7.2. Informative References ....................................15
Appendix A. Cellular Host IPv6 Addressing in the 3GPP Model .......17
Appendix B. Changes from RFC 3316 .................................18
1. Introduction ....................................................3
1.1. Scope of This Document .....................................3
1.2. Abbreviations ..............................................5
1.3. Cellular Host IPv6 Features ................................6
2. Basic IP ........................................................6
2.1. Internet Protocol Version 6 ................................6
2.2. Neighbor Discovery in 3GPP Networks ........................6
2.3. Stateless Address Autoconfiguration ........................8
2.4. IP Version 6 over PPP ......................................8
2.5. Multicast Listener Discovery (MLD) for IPv6 ................9
2.6. Privacy Extensions for Address Configuration in IPv6 .......9
2.7. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) ......9
2.8. DHCPv6 Prefix Delegation ..................................10
2.9. Router Preferences and More-Specific Routes ...............10
2.10. Neighbor Discovery and Additional Host Configuration .....10
3. IP Security ....................................................11
3.1. Extension Header Considerations ...........................11
4. Mobility .......................................................11
5. Acknowledgements ...............................................11
6. Security Considerations ........................................12
7. References .....................................................14
7.1. Normative References ......................................14
7.2. Informative References ....................................15
Appendix A. Cellular Host IPv6 Addressing in the 3GPP Model .......17
Appendix B. Changes from RFC 3316 .................................18
Technologies such as GPRS (General Packet Radio Service), UMTS (Universal Mobile Telecommunications System), Evolved Packet System (EPS), CDMA2000 (Code Division Multiple Access 2000), and eHRPD (Enhanced High Rate Packet Data) are making it possible for cellular hosts to have an always-on connection to the Internet. IPv6 [RFC2460] has become essential to such networks as the number of cellular hosts is increasing rapidly. Standardization organizations working with cellular technologies have recognized this and made IPv6 mandatory in their specifications.
GPRS（通用分组无线业务）、UMTS（通用移动通信系统）、演进分组系统（EPS）、CDMA2000（码分多址2000）和eHRPD（增强型高速分组数据）等技术使蜂窝主机能够始终连接到Internet。IPv6[RFC2460]已成为此类网络的关键，因为蜂窝主机的数量正在迅速增加。从事蜂窝技术工作的标准化组织已经认识到这一点，并在其规范中强制实施IPv6。
Support for IPv6 and the introduction of UMTS started with 3GPP Release-99 networks and hosts. For a detailed description of IPv6 in 3GPP networks, including the Evolved Packet System, see [RFC6459].
对IPv6的支持和UMTS的引入始于3GPP Release-99网络和主机。有关3GPP网络中IPv6的详细描述，包括演进的分组系统，请参阅[RFC6459]。
For the purpose of this document, a cellular interface is considered to be the interface to a cellular access network based on the following standards: 3GPP GPRS and UMTS Release-99 and Release-4 to Release-11; EPS Release-8 to Release-11; and future UMTS or EPS releases. A cellular host is considered to be a host with such a cellular interface.
在本文件中，蜂窝接口被视为基于以下标准的蜂窝接入网络接口：3GPP GPRS和UMTS Release-99和Release-4至Release-11；EPS释放-8至释放-11；以及未来的UMTS或EPS版本。蜂窝主机被认为是具有这种蜂窝接口的主机。
This document complements the IPv6 Node Requirements [RFC6434] in places where clarifications are needed with discussion on the use of these selected IPv6 specifications when operating over a cellular interface. Such a specification is necessary in order to enable the optimal use of IPv6 in a cellular network environment. The description is made from the point of view of a cellular host. Complementary access technologies may be supported by the cellular host, but those are not discussed in detail. Important considerations are given in order to eliminate unnecessary user confusion over configuration options, ensure interoperability, and provide an easy reference for those who are implementing IPv6 in a cellular host. It is necessary to ensure that cellular hosts are good citizens of the Internet.
在需要澄清的地方，本文件补充了IPv6节点要求[RFC6434]，并讨论了在蜂窝接口上运行时使用这些选定IPv6规范的问题。为了在蜂窝网络环境中实现IPv6的最佳使用，这样的规范是必要的。从蜂窝主机的角度进行描述。补充接入技术可由蜂窝主机支持，但未详细讨论这些技术。为了消除不必要的用户对配置选项的混淆，确保互操作性，并为在蜂窝主机中实施IPv6的用户提供简单的参考，本文给出了重要的注意事项。有必要确保手机主机是互联网的好公民。
This document is informational in its nature, and it is not intended to replace, update, or contradict any IPv6 standards documents or the IPv6 Node Requirements [RFC6434].
本文档本质上是信息性的，无意替换、更新或违背任何IPv6标准文档或IPv6节点要求[RFC6434]。
This document is primarily targeted to the implementers of cellular hosts that will be used with the cellular networks listed in this document. This document provides guidance on which IPv6-related specifications are to be implemented in such cellular hosts. Parts of this document may also apply to other cellular link types, but
本文档主要针对将与本文档中列出的蜂窝网络一起使用的蜂窝主机的实施者。本文档提供了在此类蜂窝式主机中实施哪些IPv6相关规范的指南。本文档的部分内容也可能适用于其他蜂窝链路类型，但
this document does not provide any detailed analysis on other link types. This document should not be used as a definitive list of IPv6 functionalities for cellular links other than those listed above. Future changes in 3GPP networks that impact host implementations may result in updates to this document.
本文档不提供关于其他链接类型的任何详细分析。除了上面列出的功能外，本文档不应用作蜂窝链路IPv6功能的最终列表。3GPP网络中影响主机实现的未来变化可能会导致本文档的更新。
There are different ways to implement cellular hosts:
有不同的方式来实现蜂窝主机：
o The host can be a "closed" device with optimized built-in applications, with no possibility to add or download applications that can have IP communications. An example of such a host is a very simple form of a mobile phone.
o 主机可以是具有优化内置应用程序的“封闭”设备，不可能添加或下载具有IP通信的应用程序。这种主机的一个例子是一种非常简单的移动电话。
o The host can be an open device, e.g., a "smart phone" where it is possible to download applications to expand the functionality of the device.
o 主机可以是开放式设备，例如“智能手机”，可以下载应用程序以扩展设备的功能。
o The cellular radio modem part can be separated from the host IP stack with an interface. One example of such a host is a laptop computer that uses a USB cellular modem for cellular access.
o 蜂窝无线电调制解调器部分可以通过接口与主机IP堆栈分离。这种主机的一个例子是使用USB蜂窝调制解调器进行蜂窝访问的笔记本电脑。
If a cellular host has additional IP-capable interfaces (such as Ethernet, WLAN, Bluetooth, etc.), then there may be additional requirements for the device, beyond what is discussed in this document. Additionally, this document does not make any recommendations on the functionality required on laptop computers having a cellular interface such as an embedded modem or a USB modem stick, other than recommending link-specific behavior on the cellular link.
如果蜂窝主机具有额外的支持IP的接口（如以太网、WLAN、蓝牙等），则除了本文档中讨论的内容外，可能还有其他设备要求。此外，除了建议蜂窝链路上的链路特定行为外，本文档不对具有蜂窝接口（如嵌入式调制解调器或USB调制解调器棒）的笔记本电脑所需的功能提出任何建议。
This document discusses IPv6 functionality as of the time when this document was written. Ongoing work on IPv6 may affect what is required of future hosts.
本文档讨论了编写本文档时的IPv6功能。正在进行的IPv6工作可能会影响未来主机的需求。
Transition mechanisms used by cellular hosts are not in the scope of this document and are left for further study. The primary transition mechanism supported by 3GPP is dual-stack [RFC4213]. Dual-stack-capable bearer support has been added to GPRS starting from 3GPP Release-9 and to EPS starting from Release-8 [RFC6459], whereas the earlier 3GPP releases required multiple single IP version bearers to support dual-stack.
蜂窝主机使用的转换机制不在本文档的范围内，有待进一步研究。3GPP支持的主要转换机制是双栈[RFC4213]。从3GPP Release-9开始，支持双栈的承载已添加到GPRS中，从Release-8开始，支持EPS[RFC6459]，而早期的3GPP版本需要多个单IP版本承载以支持双栈。
2G Second Generation Mobile Telecommunications, such as Global System for Mobile Communications (GSM) and GPRS technologies.
2G第二代移动通信，如全球移动通信系统（GSM）和GPRS技术。
3G Third Generation Mobile Telecommunications, such as UMTS technology.
3G第三代移动通信，如UMTS技术。
4G Fourth Generation Mobile Telecommunications, such as LTE technology.
4G第四代移动通信，如LTE技术。
3GPP Third Generation Partnership Project. Throughout the document, the term "3GPP networks" refers to architectures standardized by 3GPP, in Second, Third, and Fourth Generation releases: 99, 4, and 5, as well as future releases.
3GPP第三代合作伙伴项目。在整个文档中，术语“3GPP网络”指的是3GPP在第二、第三和第四代版本（99、4和5）以及未来版本中标准化的体系结构。
EPS Evolved Packet System.
EPS演进分组系统。
GGSN Gateway GPRS Support Node (a default router for 3GPP IPv6 cellular hosts in GPRS).
GGSN网关GPRS支持节点（GPRS中3GPP IPv6蜂窝主机的默认路由器）。
GPRS General Packet Radio Service.
GPRS通用分组无线业务。
LTE Long Term Evolution.
LTE长期演进。
MT Mobile Terminal, for example, a mobile phone handset.
MT移动终端，例如，移动电话手持机。
MTU Maximum Transmission Unit.
最大传输单位。
PDN Packet Data Network.
分组数据网络。
PDP Packet Data Protocol.
PDP包数据协议。
PGW Packet Data Network Gateway (the default router for 3GPP IPv6 cellular hosts in EPS).
PGW分组数据网络网关（EPS中3GPP IPv6蜂窝主机的默认路由器）。
SGW Serving Gateway (the user plane equivalent of a Serving GPRS Support Node (SGSN) in EPS (and the default router for 3GPP IPv6 cellular hosts when using Proxy Mobile IPv6 (PMIPv6))).
SGW服务网关（相当于EPS中服务GPRS支持节点（SGSN）的用户平面（以及使用代理移动IPv6（PMIPv6）时3GPP IPv6蜂窝主机的默认路由器））。
TE Terminal Equipment, for example, a laptop attached through a 3GPP handset.
终端设备，例如，通过3GPP手机连接的笔记本电脑。
UMTS Universal Mobile Telecommunications System.
UMTS通用移动通信系统。
WLAN Wireless Local Area Network.
无线局域网。
This document lists IPv6 features for cellular hosts; these features are split into three groups and are discussed below.
本文档列出了蜂窝主机的IPv6功能；这些功能分为三组，将在下面讨论。
Basic IP
基本知识产权
In this group, the basic IPv6 features essential for cellular hosts are listed and described.
在此组中，列出并描述了蜂窝主机所必需的基本IPv6功能。
IP Security
IP安全
In this group, the parts related to IP Security are described.
在本组中，描述了与IP安全相关的部分。
Mobility
流动性
In this group, IP-layer mobility issues are described.
在本组中，描述了IP层移动性问题。
For most parts, refer to the IPv6 Node Requirements document [RFC6434].
对于大多数部分，请参阅IPv6节点需求文档[RFC6434]。
The Internet Protocol version 6 (IPv6) is specified in [RFC2460]. This specification is a mandatory part of IPv6. A cellular host must conform to the generic IPv6 host requirements [RFC6434], unless specifically pointed out otherwise in this document.
[RFC2460]中规定了互联网协议版本6（IPv6）。本规范是IPv6的强制性部分。蜂窝式主机必须符合通用IPv6主机要求[RFC6434]，除非本文档中另有明确说明。
A cellular host must support Neighbor Solicitation and Neighbor Advertisement messages [RFC4861]. Some further notes on how Neighbor Discovery is applied in the particular type of an interface can be useful.
蜂窝主机必须支持邻居请求和邻居广告消息[RFC4861]。关于如何在特定类型的接口中应用邻居发现的进一步说明可能很有用。
In 3GPP networks, some Neighbor Discovery messages can be unnecessary in certain cases. GPRS, UMTS, and EPS links resemble a point-to-point link; hence, the cellular host's only neighbor on the cellular link is the default router that is already known through Router Discovery. The cellular host always solicits for routers when the cellular interface is brought up (as described in [RFC4861], Section 6.3.7).
在3GPP网络中，某些邻居发现消息在某些情况下可能是不必要的。GPRS、UMTS和EPS链路类似于点对点链路；因此，蜂窝主机在蜂窝链路上的唯一邻居是通过路由器发现已知的默认路由器。当启动蜂窝接口时，蜂窝主机总是请求路由器（如[RFC4861]第6.3.7节所述）。
There are no link-layer addresses on the 3GPP cellular link technology. Therefore, address resolution and next-hop determination are not needed. If the cellular host still attempts to do address
3GPP蜂窝链路技术上没有链路层地址。因此，不需要地址解析和下一跳确定。如果蜂窝式主机仍尝试执行此地址
resolution, e.g., for the default router, it must be understood that the GGSN/PGW may not even answer the address resolution Neighbor Solicitations. And even if it does, the Neighbor Advertisement is unlikely to contain the Target link-layer address option as there are no link-layer addresses on the 3GPP cellular link technology.
解析，例如，对于默认路由器，必须理解，GGSN/PGW甚至可能不回答地址解析邻居请求。而且即使它包含，邻居广告也不可能包含目标链路层地址选项，因为3GPP蜂窝链路技术上没有链路层地址。
The cellular host must support Neighbor Unreachability Detection (NUD) as specified in [RFC4861]. Note that the link-layer address considerations above also apply to NUD. The NUD-triggered Neighbor Advertisement is also unlikely to contain the Target link-layer address option as there are no link-layer addresses. The cellular host should also be prepared for NUD initiated by a router (i.e., GGSN/PGW). However, it is unlikely a router-to-host NUD would ever take place on GPRS, UMTS, or EPS links. See Appendix A for more discussion on the router-to-host NUD.
蜂窝主机必须支持[RFC4861]中规定的邻居不可达性检测（NUD）。请注意，上面的链路层地址注意事项也适用于NUD。NUD触发的邻居播发也不太可能包含目标链路层地址选项，因为没有链路层地址。蜂窝主机还应为路由器（即GGSN/PGW）发起的NUD做好准备。然而，在GPRS、UMTS或EPS链路上不太可能出现承载NUD的路由器。有关路由器到主机NUD的更多讨论，请参见附录A。
In 3GPP networks, it is desirable to reduce any additional periodic signaling. Therefore, the cellular host should include a mechanism in upper-layer protocols to provide reachability confirmations when two-way IP-layer reachability can be confirmed (see [RFC4861], Section 7.3.1). These confirmations would allow the suppression of NUD-related messages in most cases.
在3GPP网络中，希望减少任何额外的周期性信令。因此，蜂窝主机应在上层协议中包含一种机制，以便在双向IP层可达性得到确认时提供可达性确认（参见[RFC4861]，第7.3.1节）。这些确认将允许在大多数情况下抑制与NUD相关的消息。
Host TCP implementation should provide reachability confirmation in the manner explained in [RFC4861], Section 7.3.1.
主机TCP实现应按照[RFC4861]第7.3.1节中说明的方式提供可达性确认。
The widespread use of UDP in 3GPP networks poses a problem for providing reachability confirmation. As UDP itself is unable to provide such confirmation, applications running on top of UDP should provide the confirmation where possible. In particular, when UDP is used for transporting DNS, the DNS response should be used as a basis for reachability confirmation. Similarly, when UDP is used to transport RTP [RFC3550], the RTP Control Protocol (RTCP) [RFC3550] feedback should be used as a basis for the reachability confirmation. If an RTCP packet is received with a reception report block indicating some packets have gone through, then packets are reaching the peer. If they have reached the peer, they have also reached the neighbor.
UDP在3GPP网络中的广泛使用为提供可达性确认带来了问题。由于UDP本身无法提供此类确认，因此在UDP之上运行的应用程序应尽可能提供确认。特别是，当UDP用于传输DNS时，DNS响应应作为可达性确认的基础。类似地，当使用UDP传输RTP[RFC3550]时，RTP控制协议（RTCP）[RFC3550]反馈应作为可达性确认的基础。如果接收到RTCP数据包时，接收报告块指示某些数据包已通过，则数据包正在到达对等方。如果他们已经到达了对等者，那么他们也已经到达了邻居。
When UDP is used for transporting SIP [RFC3261], responses to SIP requests should be used as the confirmation that packets sent to the peer are reaching it. When the cellular host is acting as the server-side SIP node, no such confirmation is generally available. However, a host may interpret the receipt of a SIP ACK request as confirmation that the previously sent response to a SIP INVITE request has reached the peer.
当UDP用于传输SIP[RFC3261]时，对SIP请求的响应应被用作确认发送给对等方的数据包正在到达它。当蜂窝主机充当服务器端SIP节点时，通常不提供此类确认。然而，主机可以将SIP ACK请求的接收解释为确认先前发送的对SIP INVITE请求的响应已经到达对等方。
IPv6 Stateless Address Autoconfiguration is defined in [RFC4862]. This specification is a mandatory part of IPv6 and also the only mandatory method to configure an IPv6 address in a 3GPP cellular host.
[RFC4862]中定义了IPv6无状态地址自动配置。本规范是IPv6的强制性部分，也是在3GPP蜂窝主机中配置IPv6地址的唯一强制性方法。
A cellular host in a 3GPP network must process a Router Advertisement as stated in [RFC4862]. The Router Advertisement contains a maximum of one prefix information option with lifetimes set to infinite (both valid and preferred lifetimes). The advertised prefix cannot ever be used for on-link determination (see [RFC6459], Section 5.2), and the lifetime of the advertised prefix is tied to the PDP Context/PDN Connection lifetime. Keeping the forward compatibility in mind, there is no reason for the 3GPP cellular host to have 3GPP-specific handling of the prefix information option(s) although 3GPP specifications state that the Router Advertisement may contain a maximum of one prefix information option and the lifetimes are set to infinite.
3GPP网络中的蜂窝主机必须处理[RFC4862]中所述的路由器公告。路由器公告最多包含一个前缀信息选项，其生存时间设置为无限（有效和首选生存时间）。播发前缀永远不能用于链路上的确定（参见[RFC6459]，第5.2节），播发前缀的生存期与PDP上下文/PDN连接生存期相关联。牢记前向兼容性，3GPP蜂窝主机没有理由对前缀信息选项进行3GPP特定的处理，尽管3GPP规范声明路由器广告可以包含最多一个前缀信息选项，并且生存时间被设置为无限。
Hosts in 3GPP networks can set DupAddrDetectTransmits equal to zero, as each assigned prefix is unique within its scope when advertised using 3GPP IPv6 Stateless Address Autoconfiguration. In addition, the default router (GGSN/PGW) will not configure any addresses on its interfaces based on prefixes advertised to IPv6 cellular hosts on those interfaces. Thus, the host is not required to perform Duplicate Address Detection on the cellular interface.
3GPP网络中的主机可以将DupAddrDetectTransmissions设置为零，因为当使用3GPP IPv6无状态地址自动配置播发时，每个分配的前缀在其范围内都是唯一的。此外，默认路由器（GGSN/PGW）不会根据在接口上向IPv6蜂窝主机播发的前缀在其接口上配置任何地址。因此，主机不需要在蜂窝接口上执行重复地址检测。
Furthermore, the GGSN/PGW will provide the cellular host with an interface identifier that must be used for link-local address configuration. The link-local address configured from this interface identifier is guaranteed not to collide with the link-local address that the GGSN/PGW uses. Thus, the cellular host is not required to perform Duplicate Address Detection for the link-local address on the cellular interface.
此外，GGSN/PGW将向蜂窝主机提供必须用于链路本地地址配置的接口标识符。保证从此接口标识符配置的链路本地地址不会与GGSN/PGW使用的链路本地地址冲突。因此，蜂窝主机不需要对蜂窝接口上的链路本地地址执行重复地址检测。
See Appendix A for more details on 3GPP IPv6 Stateless Address Autoconfiguration.
有关3GPP IPv6无状态地址自动配置的更多详细信息，请参阅附录A。
A cellular host in a 3GPP network that supports PPP [RFC1661] on the interface between the MT and the TE must support the IPv6 Control Protocol (IPV6CP) [RFC5072] interface identifier option. This option is needed to be able to connect other devices to the Internet using a PPP link between the cellular device (MT, e.g., a USB dongle) and other devices (TE, e.g., a laptop). The MT performs the PDP Context activation based on a request from the TE. This results in an
3GPP网络中在MT和TE之间的接口上支持PPP[RFC1661]的蜂窝主机必须支持IPv6控制协议（IPV6CP）[RFC5072]接口标识符选项。该选项需要能够使用蜂窝设备（MT，例如USB加密狗）和其他设备（TE，例如笔记本电脑）之间的PPP链路将其他设备连接到互联网。MT根据来自TE的请求执行PDP上下文激活。这导致了
interface identifier being suggested by the MT to the TE, using the IPV6CP option. To avoid any duplication in link-local addresses between the TE and the GGSN/PGW, the MT must always reject other suggested interface identifiers by the TE. This results in the TE always using the interface identifier suggested by the GGSN/PGW for its link-local address.
MT使用IPV6CP选项向TE建议的接口标识符。为了避免TE和GGSN/PGW之间链路本地地址的任何重复，MT必须始终拒绝TE建议的其他接口标识符。这导致TE始终使用GGSN/PGW建议的接口标识符作为其链路本地地址。
The rejection of interface identifiers suggested by the TE is only done for creation of link-local addresses, according to 3GPP specifications. The use of privacy addresses [RFC4941] or similar technologies for unique local IPv6 unicast addresses [RFC4193] and global addresses is not affected by the above procedure.
根据3GPP规范，TE建议的接口标识符的拒绝仅用于创建链路本地地址。对唯一的本地IPv6单播地址[RFC4193]和全局地址使用隐私地址[RFC4941]或类似技术不受上述过程的影响。
Within 3GPP networks, hosts connect to their default routers (GGSN/PGW) via point-to-point links. Moreover, there are exactly two IP devices connected to the point-to-point link, and no attempt is made (at the link layer) to suppress the forwarding of multicast traffic. Consequently, sending MLD reports for link-local addresses in a 3GPP environment is not necessary, although sending them causes no harm or interoperability issues. Refer to Section 5.10 of [RFC6434] for MLD usage for multicast group knowledge that is not link-local.
在3GPP网络中，主机通过点对点链路连接到其默认路由器（GGSN/PGW）。此外，正好有两个IP设备连接到点到点链路，并且没有尝试（在链路层）抑制多播流量的转发。因此，在3GPP环境中发送链路本地地址的MLD报告是不必要的，尽管发送它们不会造成损害或互操作性问题。参考[RFC6434]第5.10节，了解非本地链路的多播组知识的MLD用法。
Privacy Extensions for Stateless Address Autoconfiguration [RFC4941] or other similar technologies may be supported by a cellular host. Privacy, in general, is important for the Internet. In 3GPP networks, the lifetime of an address assignment depends on many factors such as radio coverage, device status, and user preferences. As a result, the prefix the cellular host uses is also subject to frequent changes.
蜂窝主机可能支持无状态地址自动配置[RFC4941]或其他类似技术的隐私扩展。一般来说，隐私对互联网很重要。在3GPP网络中，地址分配的生存期取决于许多因素，例如无线电覆盖范围、设备状态和用户偏好。因此，蜂窝主机使用的前缀也会频繁更改。
Refer to Section 6 for a discussion of the benefits of Privacy Extensions in a 3GPP network.
有关3GPP网络中隐私扩展的好处的讨论，请参阅第6节。
As of 3GPP Release-11, the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] is neither required nor supported for address autoconfiguration. IPv6 Stateless Address Autoconfiguration still remains the only mandatory address configuration method. However, DHCPv6 may be useful for other configuration needs on a cellular host, e.g., Stateless DHCPv6 [RFC3736] may be used to configure DNS
自3GPP Release-11起，地址自动配置既不需要也不支持IPv6（DHCPv6）[RFC3315]的动态主机配置协议。IPv6无状态地址自动配置仍然是唯一的强制地址配置方法。然而，DHCPv6可用于蜂窝主机上的其他配置需求，例如，无状态DHCPv6[RFC3736]可用于配置DNS
and SIP server addresses, and DHCPv6 Prefix Delegation [RFC3633] may be used to delegate a prefix to the cellular host for use on its downstream non-cellular links.
和SIP服务器地址，并且DHCPv6前缀委派[RFC3633]可用于将前缀委派给蜂窝主机以在其下游非蜂窝链路上使用。
Starting from Release-10, DHCPv6 Prefix Delegation was added as an optional feature to the 3GPP system architecture [RFC3633]. The Prefix Delegation model defined for Release-10 requires that the /64 IPv6 prefix assigned to the cellular host on the 3GPP link must aggregate with the shorter delegated IPv6 prefix. The cellular host should implement the Prefix Exclude Option for DHCPv6 Prefix Delegation [RFC6603] (see [RFC6459], Section 5.3 for further discussion).
从Release-10开始，DHCPv6前缀委派作为可选功能添加到3GPP系统架构[RFC3633]。为Release-10定义的前缀委派模型要求在3GPP链路上分配给蜂窝主机的/64 IPv6前缀必须与较短的委派IPv6前缀聚合。蜂窝主机应为DHCPv6前缀委派[RFC6603]实现前缀排除选项（有关进一步讨论，请参阅[RFC6459]，第5.3节）。
The cellular host should implement the Default Router Preferences and More-Specific Routes extension to Router Advertisement messages [RFC4191]. These options may be useful for cellular hosts that also have additional interfaces on which IPv6 is used.
蜂窝主机应实现默认路由器首选项和路由器广告消息的更具体路由扩展[RFC4191]。这些选项对于具有使用IPv6的附加接口的蜂窝主机可能有用。
The DNS server configuration is learned from the 3GPP link-layer signaling. However, the cellular host should also implement the IPv6 Router Advertisement Options for DNS Configuration [RFC6106]. DHCPv6 is still optional for cellular hosts, and learning the DNS server addresses from the link-layer signaling can be cumbersome when the MT and the TE are separated using techniques other than the PPP interface.
DNS服务器配置从3GPP链路层信令学习。但是，蜂窝主机还应为DNS配置实现IPv6路由器播发选项[RFC6106]。DHCPv6对于蜂窝主机仍然是可选的，并且当使用PPP接口以外的技术分离MT和TE时，从链路层信令学习DNS服务器地址可能会很麻烦。
The cellular host should also honor the MTU option in the Router Advertisement (see [RFC4861], Section 4.6.4). The 3GPP system architecture uses extensive tunneling in its packet core network below the 3GPP link, and this may lead to packet fragmentation issues. Therefore, the GGSN/PGW may propose to the cellular host an MTU that takes the additional tunneling overhead into account.
蜂窝主机还应在路由器广告中遵守MTU选项（参见[RFC4861]，第4.6.4节）。3GPP系统架构在3GPP链路下方的分组核心网络中使用大量隧道，这可能导致分组分段问题。因此，GGSN/PGW可以向蜂窝主机建议考虑额外隧道开销的MTU。
IPsec [RFC4301] is a fundamental, but not mandatory, part of IPv6. Refer to the IPv6 Node Requirements (Section 11 of [RFC6434]) for the security requirements that also apply to cellular hosts.
IPsec[RFC4301]是IPv6的基本组成部分，但不是强制性的。有关同样适用于蜂窝式主机的安全要求，请参阅IPv6节点要求[RFC6434]第11节。
Support for the Routing Header Type 0 (RH0) has been deprecated [RFC5095]. Therefore, the cellular host should by default follow the RH0 processing described in Section 3 of [RFC5095].
不推荐使用对路由标头类型0（RH0）的支持[RFC5095]。因此，蜂窝主机默认情况下应遵循[RFC5095]第3节中描述的RH0处理。
IPv6 packet fragmentation has known security concerns. The cellular host must follow the handling of overlapping fragments as described in [RFC5722], and the cellular host must not fragment any Neighbor Discovery messages as described in [RFC6980].
IPv6数据包碎片具有已知的安全问题。蜂窝主机必须按照[RFC5722]中所述处理重叠片段，并且蜂窝主机不得按照[RFC6980]中所述分割任何邻居发现消息。
For the purposes of this document, IP mobility is not relevant. The movement of cellular hosts within 3GPP networks is handled by link-layer mechanisms in the majority of cases. 3GPP Release-8 introduced Dual-Stack Mobile IPv6 (DSMIPv6) for client-based mobility [RFC5555]. Client-based IP mobility is optional in the 3GPP architecture.
就本文件而言，IP移动性不相关。在大多数情况下，3GPP网络中蜂窝主机的移动由链路层机制处理。3GPP第8版为基于客户端的移动性引入了双栈移动IPv6（DSMPV6）[RFC5555]。基于客户端的IP移动性在3GPP架构中是可选的。
The authors would like to thank the original authors for their groundwork for this document: Gerben Kuijpers, John Loughney, Hesham Soliman, and Juha Wiljakka.
作者要感谢原始作者为本文件所做的基础工作：Gerben Kuijpers、John Loughney、Hesham Soliman和Juha Wiljakka。
The original [RFC3316] document was based on the results of a team that included Peter Hedman and Pertti Suomela in addition to the authors. Peter and Pertti have contributed both text and their IPv6 experience to this document.
原始[RFC3316]文件基于一个团队的结果，该团队除作者外，还包括Peter Hedman和Pertti Suomela。Peter和Pertti为本文档提供了文本和他们的IPv6经验。
The authors would like to thank Jim Bound, Brian Carpenter, Steve Deering, Bob Hinden, Keith Moore, Thomas Narten, Erik Nordmark, Michael Thomas, Margaret Wasserman, and others on the IPv6 WG mailing list for their comments and input.
作者要感谢Jim Bond、Brian Carpenter、Steve Deering、Bob Hinden、Keith Moore、Thomas Narten、Erik Nordmark、Michael Thomas、Margaret Wasserman以及IPv6工作组邮件列表上的其他人的评论和意见。
We would also like to thank David DeCamp, Karim El Malki, Markus Isomaki, Petter Johnsen, Janne Rinne, Jonne Soininen, Vlad Stirbu, and Shabnam Sultana for their comments and input in preparation of this document.
我们还要感谢David DeCamp、Karim El-Malki、Markus Isomaki、Petter Johnsen、Janne Rinne、Jonne Soininen、Vlad Stirbu和Shabnam Sultana在编写本文件过程中提出的意见和投入。
For this revised version of [RFC3316] the authors would like to thank Dave Thaler, Ales Vizdal, Gang Chen, Ray Hunter, Charlie Kaufman, Owen DeLong, and Alexey Melnikov for their comments, reviews, and input.
对于[RFC3316]的修订版，作者要感谢Dave Thaler、Ales Vizdal、Gang Chen、Ray Hunter、Charlie Kaufman、Owen DeLong和Alexey Melnikov的评论、评论和意见。
This document does not specify any new protocols or functionalities, and as such, it does not introduce any new security vulnerabilities. However, specific profiles of IPv6 functionality are proposed for different situations, and vulnerabilities may open or close depending on which functionality is included and what is not. There are also aspects of the cellular environment that make certain types of vulnerabilities more severe. The following issues are discussed:
本文件未规定任何新的协议或功能，因此也未引入任何新的安全漏洞。但是，针对不同的情况提出了IPv6功能的特定配置文件，漏洞可能会打开或关闭，具体取决于包含哪些功能和不包含哪些功能。蜂窝环境的某些方面也使某些类型的漏洞更加严重。讨论了以下问题：
o The suggested limitations (Section 3.1) in the processing of extension headers also limits exposure to Denial-of-Service (DoS) attacks through cellular hosts.
o 扩展头处理中的建议限制（第3.1节）也限制了通过蜂窝主机受到拒绝服务（DoS）攻击的风险。
o IPv6 addressing privacy [RFC4941] or similar technology may be used in cellular hosts. However, it should be noted that in the 3GPP model, the network would assign a new prefix, in most cases, to hosts in roaming situations; the network would also typically assign a new prefix when the cellular hosts activate a PDP Context or a PDN Connection. 3GPP devices must not use interface identifiers that are unique to the device, so the only difference in address between 3GPP devices using Stateless Address Autoconfiguration is in the prefix. This means that 3GPP networks will already provide a limited form of addressing privacy, and no global tracking of a single host is possible through its address. On the other hand, since a GGSN/PGW's coverage area is expected to be very large when compared to currently deployed default routers (no handovers between GGSN/PGWs are possible), a cellular host can keep a prefix for a long time. Hence, IPv6 addressing privacy can be used for additional privacy during the time the host is on and in the same area. The privacy features can also be used to, e.g., make different transport sessions appear to come from different IP addresses. However, it is not clear that these additional efforts confuse potential observers any further, as they could monitor only the network prefix part.
o IPv6寻址隐私[RFC4941]或类似技术可用于蜂窝主机。然而，应当注意的是，在3GPP模型中，在大多数情况下，网络将向漫游情况下的主机分配新前缀；当蜂窝主机激活PDP上下文或PDN连接时，网络通常也会分配新前缀。3GPP设备不得使用设备独有的接口标识符，因此使用无状态地址自动配置的3GPP设备之间地址的唯一区别在于前缀。这意味着3GPP网络将提供有限形式的隐私寻址，并且不可能通过其地址对单个主机进行全局跟踪。另一方面，由于与当前部署的默认路由器相比，GGSN/PGW的覆盖区域预计非常大（GGSN/PGW之间不可能进行切换），因此蜂窝主机可以长时间保留前缀。因此，IPv6寻址隐私可以在主机运行期间以及在同一区域内用于额外的隐私。隐私功能还可用于，例如，使不同的传输会话看起来来自不同的IP地址。然而，不清楚这些额外的努力是否会进一步混淆潜在的观察者，因为他们只能监视网络前缀部分。
o The use and recommendations of various security services such as IPsec or Transport Layer Security (TLS) [RFC5246] in the connection of typical applications that also apply to cellular hosts are discussed in Section 11 of [RFC6434].
o [RFC6434]第11节讨论了各种安全服务（如IPsec或传输层安全（TLS）[RFC5246]在连接也适用于蜂窝主机的典型应用中的使用和建议。
o The airtime used by cellular hosts is expensive. In some cases, users are billed according to the amount of data they transfer to and from their host. It is crucial for both the network and the users that the airtime is used correctly and no extra charges are applied to users due to misbehaving third parties. The cellular links also have a limited capacity, which means that they may not necessarily be able to accommodate more traffic than what the user selected, such as a multimedia call. Additional traffic might interfere with the service level experienced by the user. While Quality-of-Service mechanisms mitigate these problems to an extent, it is still apparent that DoS aspects may be highlighted in the cellular environment. It is possible for existing DoS attacks that use, for instance, packet amplification, to be substantially more damaging in this environment. How these attacks can be protected against is still an area for further study. It is also often easy to fill the cellular link and queues on both sides with additional or large packets.
o 蜂窝主机使用的广播时间很昂贵。在某些情况下，用户将根据其与主机之间传输的数据量计费。对于网络和用户来说，正确使用广播时间是至关重要的，并且不会因为第三方行为不端而向用户收取额外费用。蜂窝链路也具有有限的容量，这意味着它们不一定能够容纳比用户选择的更多的流量，例如多媒体呼叫。额外的流量可能会干扰用户体验的服务级别。虽然服务质量机制在一定程度上缓解了这些问题，但很明显，DoS方面可能会在蜂窝环境中突出显示。在这种环境下，使用（例如）数据包放大的现有DoS攻击可能会造成更大的破坏。如何防范这些攻击仍然是有待进一步研究的领域。用额外的或大的数据包填充蜂窝链路和两侧的队列通常也很容易。
o Within some service provider networks, it is possible to buy a prepaid cellular subscription without presenting personal identification. Attackers that wish to remain unidentified could leverage this. Note that while the user hasn't been identified, the equipment still is; the operators can follow the identity of the device and block it from further use. The operators must have procedures in place to take notice of third party complaints regarding the use of their customers' devices. It may also be necessary for the operators to have attack detection tools that enable them to efficiently detect attacks launched from the cellular hosts.
o 在一些服务提供商网络中，可以在不出示个人身份证明的情况下购买预付费手机订阅。希望保持身份不明的攻击者可以利用这一点。请注意，虽然用户尚未确定，但设备仍在使用中；操作员可以跟踪设备的标识并阻止其进一步使用。运营商必须制定适当的程序，以注意第三方对其客户设备使用的投诉。运营商可能还需要具备攻击检测工具，使其能够有效检测从蜂窝主机发起的攻击。
o Cellular devices that have local network interfaces (such as WLAN or Bluetooth) may be used to launch attacks through them, unless the local interfaces are secured in an appropriate manner. Therefore, local network interfaces should have access control to prevent others from using the cellular host as an intermediary.
o 具有本地网络接口（例如WLAN或蓝牙）的蜂窝设备可用于通过它们发起攻击，除非本地接口以适当的方式得到保护。因此，本地网络接口应具有访问控制，以防止其他人将蜂窝主机用作中介。
o The 3GPP link model mitigates most of the known IPv6 on-link and neighbor cache targeted attacks (see Section 2.2 and Appendix A).
o 3GPP链路模型缓解了大多数已知的针对链路和邻居缓存的IPv6攻击（参见第2.2节和附录A）。
o Advice for implementations in the face of Neighbor Discovery DoS attacks may be useful in some environments [RFC6583].
o 针对邻居发现DoS攻击的实施建议在某些环境中可能有用[RFC6583]。
o Section 9 of [RFC6459] further discusses some recent concerns related to the security of cellular hosts.
o [RFC6459]第9节进一步讨论了与蜂窝主机安全相关的一些最新问题。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[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月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]Thomson，S.，Narten，T.，和T.Jinmei，“IPv6无状态地址自动配置”，RFC 48622007年9月。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
[RFC4941]Narten，T.，Draves，R.，和S.Krishnan，“IPv6中无状态地址自动配置的隐私扩展”，RFC 49412007年9月。
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, December 2007.
[RFC5095]Abley，J.，Savola，P.，和G.Neville Neil，“IPv6中0型路由头的弃用”，RFC 5095，2007年12月。
[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", RFC 5722, December 2009.
[RFC5722]Krishnan，S.，“重叠IPv6片段的处理”，RFC 5722，2009年12月。
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node Requirements", RFC 6434, December 2011.
[RFC6434]Jankiewicz，E.，Loughney，J.和T.Narten，“IPv6节点要求”，RFC 64342011年12月。
[RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery", RFC 6980, August 2013.
[RFC6980]Gont，F.，“IPv6分段与IPv6邻居发现的安全影响”，RFC 69802013年8月。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]辛普森，W.“点对点协议（PPP）”，标准51，RFC1661，1994年7月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J. Wiljakka, "Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts", RFC 3316, April 2003.
[RFC3316]Arkko，J.，Kuijpers，G.，Soliman，H.，Loughney，J.，和J.Wiljakka，“一些第二代和第三代蜂窝主机的互联网协议版本6（IPv6）”，RFC 3316，2003年4月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[RFC3633]Troan，O.和R.Droms，“动态主机配置协议（DHCP）版本6的IPv6前缀选项”，RFC 3633，2003年12月。
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3736]Droms，R.，“IPv6的无状态动态主机配置协议（DHCP）服务”，RFC 3736，2004年4月。
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005.
[RFC4191]Draves，R.和D.Thaler，“默认路由器首选项和更具体的路由”，RFC 41912005年11月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 41932005年10月。
[RFC5072] Varada, S., Haskins, D., and E. Allen, "IP Version 6 over PPP", RFC 5072, September 2007.
[RFC5072]Varada，S.，Haskins，D.，和E.Allen，“PPP上的IP版本6”，RFC 5072，2007年9月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009.
[RFC5555]Soliman，H.，“双栈主机和路由器的移动IPv6支持”，RFC 55552009年6月。
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 6106, November 2010.
[RFC6106]Jeong，J.，Park，S.，Beloeil，L.，和S.Madanapalli，“DNS配置的IPv6路由器广告选项”，RFC 61062010年11月。
[RFC6459] Korhonen, J., 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.
[RFC6459]Korhonen，J.，Soininen，J.，Patil，B.，Savolainen，T.，Bajko，G.，和K.Iisakkila，“第三代合作伙伴关系项目（3GPP）中的IPv6演进包系统（EPS）”，RFC 6459，2012年1月。
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational Neighbor Discovery Problems", RFC 6583, March 2012.
[RFC6583]Gashinsky，I.，Jaeggli，J.，和W.Kumari，“操作邻居发现问题”，RFC 6583，2012年3月。
[RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, "Prefix Exclude Option for DHCPv6-based Prefix Delegation", RFC 6603, May 2012.
[RFC6603]Korhonen，J.，Savolainen，T.，Krishnan，S.，和O.Troan，“基于DHCPv6的前缀委托的前缀排除选项”，RFC 6603，2012年5月。
[TS.23060] 3GPP, "General Packet Radio Service (GPRS); Service description; Stage 2", 3GPP TS 23.060 11.5.0, March 2013.
[TS.23060]3GPP，“通用分组无线业务（GPRS）；业务描述；第2阶段”，3GPP TS 23.060 11.5.012013年3月。
[TS.23401] 3GPP, "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access", 3GPP TS 23.401 11.5.0, March 2013.
[TS.23401]3GPP，“通用分组无线业务（GPRS）对演进型通用地面无线接入网（E-UTRAN）接入的增强”，3GPP TS 23.40111.5.012013年3月。
[TS.23402] 3GPP, "Architectural enhancements for non-3GPP accesses", 3GPP TS 23.402 11.6.0, March 2013.
[TS.23402]3GPP，“非3GPP接入的架构增强”，3GPP TS 23.402 11.6.012013年3月。
[TS.29061] 3GPP, "Interworking between the Public Land Mobile Network (PLMN) supporting packet based services and Packet Data Networks (PDN)", 3GPP TS 29.061 11.4.0, March 2013.
[TS.29061]3GPP，“支持分组业务的公共陆地移动网络（PLMN）与分组数据网络（PDN）之间的互通”，3GPP TS 29.0611.4.012013年3月。
This appendix aims to very briefly describe the 3GPP IPv6 addressing model for 2G (GPRS), 3G (UMTS), and 4G (EPS) cellular networks from Release-99 onwards. More information for 2G and 3G can be found in 3GPP Technical Specifications [TS.23060] and [TS.29061]. The equivalent documentation for 4G can be found in 3GPP Technical Specifications [TS.23401], [TS.23402], and [TS.29061].
本附录旨在非常简要地描述从Release-99起针对2G（GPRS）、3G（UMTS）和4G（EPS）蜂窝网络的3GPP IPv6寻址模型。有关2G和3G的更多信息，请参见3GPP技术规范[TS.23060]和[TS.29061]。4G的等效文档可在3GPP技术规范[TS.23401]、[TS.23402]和[TS.29061]中找到。
There are two possibilities to allocate the address for an IPv6 node: stateless and stateful autoconfiguration. The stateful address allocation mechanism needs a DHCP server to allocate the address for the IPv6 node. On the other hand, the Stateless Address Autoconfiguration procedure does not need any external entity involved in the address autoconfiguration (apart from the GGSN/PGW). At the time of writing this document, the IPv6 Stateless Address Autoconfiguration mechanism is still the only mandatory and supported address configuration method for the cellular 3GPP link.
有两种可能为IPv6节点分配地址：无状态和有状态自动配置。有状态地址分配机制需要DHCP服务器为IPv6节点分配地址。另一方面，无状态地址自动配置过程不需要任何外部实体参与地址自动配置（除了GGSN/PGW）。在编写本文档时，IPv6无状态地址自动配置机制仍然是蜂窝3GPP链路的唯一强制性和受支持的地址配置方法。
In order to support the standard IPv6 Stateless Address Autoconfiguration mechanism as recommended by the IETF, the GGSN/PGW shall assign a single /64 IPv6 prefix that is unique within its scope to each primary PDP Context or PDN Connection that uses IPv6 Stateless Address Autoconfiguration. This avoids the necessity to perform Duplicate Address Detection (DAD) at the network level for any address built by the mobile host. The GGSN/PGW always provides an interface identifier to the mobile host. The mobile host uses the interface identifier provided by the GGSN/PGW to generate its link-local address. The GGSN/PGW provides the cellular host with the interface identifier, usually in a random manner. It must ensure the uniqueness of such an identifier on the link (i.e., no collisions between its own link-local address and the cellular host's).
为了支持IETF推荐的标准IPv6无状态地址自动配置机制，GGSN/PGW应为使用IPv6无状态地址自动配置的每个主PDP上下文或PDN连接分配一个在其范围内唯一的/64 IPv6前缀。这避免了在网络级别对移动主机构建的任何地址执行重复地址检测（DAD）的必要性。GGSN/PGW始终向移动主机提供接口标识符。移动主机使用GGSN/PGW提供的接口标识符来生成其链路本地地址。GGSN/PGW通常以随机方式向蜂窝主机提供接口标识符。它必须确保这种标识符在链路上的唯一性（即，它自己的链路本地地址和蜂窝主机的本地地址之间没有冲突）。
In addition, the GGSN/PGW will not use any of the prefixes assigned to cellular hosts to generate any of its own addresses. This use of the interface identifier, combined with the fact that each PDP Context or PDN Connection is allocated a unique prefix, will eliminate the need for DAD messages over the air interface and consequently reduces inefficient use of radio resources. Furthermore, the allocation of a prefix to each PDP Context or PDN Connection will allow hosts to implement the Privacy Extensions in [RFC4941] without the need for further DAD messages.
此外，GGSN/PGW不会使用分配给蜂窝主机的任何前缀来生成其自己的任何地址。接口标识符的这种使用，加上每个PDP上下文或PDN连接分配了唯一前缀的事实，将消除对空中接口DAD消息的需要，从而降低无线电资源的低效使用。此外，为每个PDP上下文或PDN连接分配前缀将允许主机实现[RFC4941]中的隐私扩展，而无需进一步的DAD消息。
In practice, the GGSN/PGW only needs to route all traffic destined to the cellular host that falls under the prefix assigned to it. This implies the GGSN/PGW may implement a minimal Neighbor Discovery protocol subset since, due to the point-to-point link model and the absence of link-layer addressing, the address resolution can be
在实践中，GGSN/PGW只需要路由到归属于其前缀的蜂窝主机的所有业务。这意味着GGSN/PGW可以实现最小的邻居发现协议子集，因为由于点到点链路模型和缺少链路层寻址，地址解析可以是
entirely statically configured per PDP Context or PDN Connection, and there is no need to defend any addresses other than the link-local addresses for very unlikely duplicates. This also has an additional effect on a router-to-host NUD. There is really no need for the NUD, since from the point of view of GGSN/PGW, GGSN/PGW does not need to care for a single address but just routes the whole prefix to the cellular host. However, the cellular host must be prepared for the unlikely event of receiving a NUD against its link-local address. It should be noted that the 3GPP specifications at the time of writing this document are silent about what should happen if the router-to-host NUD fails.
完全按照PDP上下文或PDN连接静态配置，不需要为极不可能重复的链接本地地址以外的任何地址进行保护。这对路由器到主机NUD也有额外的影响。实际上不需要NUD，因为从GGSN/PGW的角度来看，GGSN/PGW不需要关心单个地址，而只需要将整个前缀路由到蜂窝主机。然而，蜂窝主机必须准备好，以防收到针对其链路本地地址的NUD这一不太可能发生的事件。应该注意的是，在编写本文档时，3GPP规范没有说明如果路由器到主机NUD发生故障会发生什么。
See Section 5 of [RFC6459] for further discussion on 3GPP address allocation and the 3GPP link model.
有关3GPP地址分配和3GPP链路模型的进一步讨论，请参阅[RFC6459]的第5节。
o Clarified that [RFC4941] or similar technologies may be used for privacy purposes (as stated in [RFC6459]).
o 阐明[RFC4941]或类似技术可用于隐私目的（如[RFC6459]所述）。
o Clarified that MLD for link-local addresses is not necessary, but doing it causes no harm (instead of saying it may not be needed in some cases).
o 澄清链接本地地址的MLD是不必要的，但这样做不会造成伤害（而不是说在某些情况下可能不需要）。
o Clarified that a cellular host should not do any changes in its stack to meet the 3GPP link restriction on the Router Advertisement Prefix Information Options (PIOs).
o 阐明蜂窝主机不应在其堆栈中进行任何更改，以满足路由器广告前缀信息选项（PIO）上的3GPP链路限制。
o Clarified that a cellular host should not do any changes in its stack to meet the infinite prefix lifetime requirement the 3GPP link has.
o 阐明蜂窝主机不应在其堆栈中进行任何更改以满足3GPP链路的无限前缀生存期要求。
o Clarified that the prefix lifetime is tied to the PDP Context/PDN Connection lifetime.
o 阐明前缀生存期与PDP上下文/PDN连接生存期相关联。
o Clarified explicitly that a NUD from the gateway side to the User Equipment's link-local address is possible.
o 明确阐明了从网关侧到用户设备链路本地地址的NUD是可能的。
o Added references to 3GPP specifications.
o 增加了对3GPP规范的参考。
o Provided additional clarification on NUD on 3GPP cellular links.
o 提供了关于3GPP蜂窝链路上的NUD的补充说明。
o Added an explicit note that the prefix on the link is /64.
o 添加了一个明确的注释，即链接上的前缀是/64。
o Clarified that DHCPv6 ([RFC3315]) is not used at all for address autoconfiguration.
o 澄清了DHCPv6（[RFC3315]）根本不用于地址自动配置。
o Removed all sections that can be directly found in [RFC6434].
o 删除了可直接在[RFC6434]中找到的所有部分。
o Added clarifications to 3GPP link model and how Neighbor Discovery works on it.
o 对3GPP链路模型以及邻居发现如何在其上工作进行了澄清。
o Added [RFC4191] recommendations.
o 增加了[RFC4191]建议。
o Added DHCPv6-based Prefix Delegation recommendations.
o 添加了基于DHCPv6的前缀委派建议。
o Added [RFC6106] recommendations.
o 增加了[RFC6106]建议。
o Added reference to [RFC5555] regarding client-based mobility.
o 增加了对[RFC5555]关于基于客户端的移动性的参考。
o Added text regarding Router Advertisement MTU option handling.
o 添加了有关路由器广告MTU选项处理的文本。
o Added Evolved Packet System text.
o 添加了进化包系统文本。
o Added clarification on the primary 3GPP IPv6 transition mechanism.
o 增加了对主要3GPP IPv6转换机制的澄清。
o Added reference to [RFC5095], which deprecates the RH0.
o 增加了对[RFC5095]的引用，该引用不推荐RH0。
o Added references to [RFC5722] and [RFC6980] regarding IPv6 fragmentation handling.
o 增加了对[RFC5722]和[RFC6980]关于IPv6分段处理的参考。
o Added reference to [RFC6583] for Neighbor Discovery denial-of-service attack considerations.
o 增加了对[RFC6583]的参考，以了解邻居发现拒绝服务攻击的注意事项。
o Made the PPP IPV6CP [RFC5072] support text conditional.
o 使PPP IPV6CP[RFC5072]支持文本条件。
Authors' Addresses
作者地址
Jouni Korhonen (editor) Broadcom Porkkalankatu 24 FIN-00180 Helsinki Finland
Jouni Korhonen（编辑）Broadcom Porkkalankatu 24 FIN-00180芬兰赫尔辛基
EMail: jouni.nospam@gmail.com
EMail: jouni.nospam@gmail.com
Jari Arkko (editor) Ericsson Jorvas 02420 Finland
Jari Arkko（编辑）爱立信Jorvas 02420芬兰
EMail: jari.arkko@piuha.net
EMail: jari.arkko@piuha.net
Teemu Savolainen Nokia Hermiankatu 12 D FI-33720 Tampere Finland
Teemu Savolainen诺基亚Hermiankatu 12 D FI-33720坦佩雷芬兰
EMail: teemu.savolainen@nokia.com
EMail: teemu.savolainen@nokia.com
Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada
苏雷什·克里希南·爱立信德卡里大道8400号。加拿大皇家山镇
Phone: +1 514 345 7900 x42871
EMail: suresh.krishnan@ericsson.com
Phone: +1 514 345 7900 x42871
EMail: suresh.krishnan@ericsson.com