Network Working Group J. Arkko
Request for Comments: 3316 G. Kuijpers
Category: Informational H. Soliman
Ericsson
J. Loughney
J. Wiljakka
Nokia
April 2003
Network Working Group J. Arkko
Request for Comments: 3316 G. Kuijpers
Category: Informational H. Soliman
Ericsson
J. Loughney
J. Wiljakka
Nokia
April 2003
Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts
某些第二代和第三代蜂窝式主机的Internet协议版本6（IPv6）
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
As the deployment of second and third generation cellular networks progresses, a large number of cellular hosts are being connected to the Internet. Standardization organizations are making 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), or Universal Mobile Telecommunications System (UMTS) networks. This document also lists basic components of IPv6 functionality and discusses some issues relating to the use of these components when operating in these networks.
随着第二代和第三代蜂窝网络部署的进展，大量蜂窝主机正在连接到互联网。标准化组织正在其规范中强制规定Internet协议版本6（IPv6）。然而，IPv6的概念涵盖了许多方面和许多规范。此外，蜂窝链路在带宽、成本和延迟方面的特性对如何使用IPv6提出了特殊要求。本文档考虑连接到通用分组无线业务（GPRS）或通用移动通信系统（UMTS）网络的蜂窝主机的IPv6。本文档还列出了IPv6功能的基本组件，并讨论了在这些网络中操作时与使用这些组件相关的一些问题。
Table of Contents
目录
1. Introduction.....................................................3
1.1 Scope of this Document......................................3
1.2 Abbreviations...............................................4
1.3 Cellular Host IPv6 Features.................................5
2. Basic IP.........................................................5
2.1 RFC1981 - Path MTU Discovery for IP Version 6...............5
2.2 RFC3513 - IP Version 6 Addressing Architecture..............6
2.3 RFC2460 - Internet Protocol Version 6.......................6
2.4 RFC2461 - Neighbor Discovery for IPv6.......................7
2.5 RFC2462 - IPv6 Stateless Address Autoconfiguration..........8
2.6 RFC2463 - Internet Control Message Protocol for the IPv6....8
2.7 RFC2472 - IP version 6 over PPP.............................9
2.8 RFC2473 - Generic Packet Tunneling in IPv6 Specification....9
2.9 RFC2710 - Multicast Listener Discovery (MLD) for IPv6.......9
2.10 RFC2711 - IPv6 Router Alert Option.........................10
2.11 RFC3041 - Privacy Extensions for Address Configuration
in IPv6 .........................................10
2.12 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)......10
2.13 RFC3484 - Default Address Selection for IPv6...............11
2.14 DNS........................................................11
3. IP Security.....................................................11
3.1 RFC2104 - HMAC: Keyed-Hashing for Message Authentication...12
3.2 RFC2401 - Security Architecture for the Internet Protocol..12
3.3 RFC2402 - IP Authentication Header.........................12
3.4 RFC2403 - The Use of HMAC-MD5-96 within ESP and AH.........12
3.5 RFC2404 - The Use of HMAC-SHA-96 within ESP and AH.........12
3.6 RFC2405 - The ESP DES-CBC Cipher Algorithm With
Explicit IV......................................12
3.7 RFC2406 - IP Encapsulating Security Payload (ESP)..........12
3.8 RFC2407 - The Internet IP Security DoI for ISAKMP..........12
3.9 RFC2408 - The Internet Security Association and Key
Management Protocol..............................13
3.10 RFC2409 - The Internet Key Exchange (IKE)..................13
3.11 RFC2410 - The NULL Encryption Algorithm & its Use
With IPsec.......................................14
3.12 RFC2451 - The ESP CBC-Mode Cipher Algorithms...............14
4. Mobility........................................................14
5. Security Considerations.........................................14
6. References......................................................16
6.1 Normative..................................................16
6.2 Informative................................................18
7. Contributors....................................................19
8. Acknowledgements................................................19
Appendix A - Cellular Host IPv6 Addressing in the 3GPP Model.......20
Authors' Addresses.................................................21
Full Copyright Statement...........................................22
1. Introduction.....................................................3
1.1 Scope of this Document......................................3
1.2 Abbreviations...............................................4
1.3 Cellular Host IPv6 Features.................................5
2. Basic IP.........................................................5
2.1 RFC1981 - Path MTU Discovery for IP Version 6...............5
2.2 RFC3513 - IP Version 6 Addressing Architecture..............6
2.3 RFC2460 - Internet Protocol Version 6.......................6
2.4 RFC2461 - Neighbor Discovery for IPv6.......................7
2.5 RFC2462 - IPv6 Stateless Address Autoconfiguration..........8
2.6 RFC2463 - Internet Control Message Protocol for the IPv6....8
2.7 RFC2472 - IP version 6 over PPP.............................9
2.8 RFC2473 - Generic Packet Tunneling in IPv6 Specification....9
2.9 RFC2710 - Multicast Listener Discovery (MLD) for IPv6.......9
2.10 RFC2711 - IPv6 Router Alert Option.........................10
2.11 RFC3041 - Privacy Extensions for Address Configuration
in IPv6 .........................................10
2.12 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)......10
2.13 RFC3484 - Default Address Selection for IPv6...............11
2.14 DNS........................................................11
3. IP Security.....................................................11
3.1 RFC2104 - HMAC: Keyed-Hashing for Message Authentication...12
3.2 RFC2401 - Security Architecture for the Internet Protocol..12
3.3 RFC2402 - IP Authentication Header.........................12
3.4 RFC2403 - The Use of HMAC-MD5-96 within ESP and AH.........12
3.5 RFC2404 - The Use of HMAC-SHA-96 within ESP and AH.........12
3.6 RFC2405 - The ESP DES-CBC Cipher Algorithm With
Explicit IV......................................12
3.7 RFC2406 - IP Encapsulating Security Payload (ESP)..........12
3.8 RFC2407 - The Internet IP Security DoI for ISAKMP..........12
3.9 RFC2408 - The Internet Security Association and Key
Management Protocol..............................13
3.10 RFC2409 - The Internet Key Exchange (IKE)..................13
3.11 RFC2410 - The NULL Encryption Algorithm & its Use
With IPsec.......................................14
3.12 RFC2451 - The ESP CBC-Mode Cipher Algorithms...............14
4. Mobility........................................................14
5. Security Considerations.........................................14
6. References......................................................16
6.1 Normative..................................................16
6.2 Informative................................................18
7. Contributors....................................................19
8. Acknowledgements................................................19
Appendix A - Cellular Host IPv6 Addressing in the 3GPP Model.......20
Authors' Addresses.................................................21
Full Copyright Statement...........................................22
1 Introduction
1导言
Technologies such as GPRS (General Packet Radio Service), UMTS (Universal Mobile Telecommunications System) and CDMA2000 (Code Division Multiple Access 2000) are making it possible for cellular hosts to have an always-on connection to the Internet. IPv6 becomes necessary, as it is expected that the number of such cellular hosts will increase rapidly. Standardization organizations working with cellular technologies have recognized this and are making IPv6 mandatory in their specifications.
GPRS（通用分组无线业务）、UMTS（通用移动通信系统）和CDMA2000（码分多址2000）等技术使蜂窝主机能够始终连接到互联网。IPv6变得十分必要，因为预计此类蜂窝主机的数量将迅速增加。从事蜂窝技术工作的标准化组织已经认识到这一点，并在其规范中强制实施IPv6。
Support for IPv6 and the introduction of UMTS starts with 3GPP Release 99 networks and hosts. IPv6 is specified as the only IP version supported for IP Multimedia Subsystem (IMS) starting from Release 5.
对IPv6的支持和UMTS的引入始于3GPP Release 99网络和主机。IPv6被指定为IP多媒体子系统（IMS）从第5版开始支持的唯一IP版本。
For the purposes 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, Release 4, Release 5, as well as future UMTS releases. A cellular host is considered to be a host with such a cellular interface.
在本文档中，蜂窝接口被视为基于以下标准的蜂窝接入网络接口：3GPP GPRS和UMTS第99版、第4版、第5版以及未来的UMTS版本。蜂窝主机被认为是具有这种蜂窝接口的主机。
This document lists IPv6 specifications with discussion on the use of these specifications when operating over cellular interfaces. Such a specification is necessary in order for the optimal use of IPv6 in a cellular environment. The description is made from a cellular host point of view. Important considerations are given in order to eliminate unnecessary user confusion over configuration options, ensure interoperability and to provide an easy reference for those implementing IPv6 in a cellular host. It is necessary to ensure that cellular hosts are good citizens of the Internet.
本文档列出了IPv6规范，并讨论了在蜂窝接口上操作时这些规范的使用。为了在蜂窝环境中优化使用IPv6，这样的规范是必要的。从蜂窝主机的角度进行描述。为了消除不必要的用户对配置选项的混淆，确保互操作性，并为在蜂窝主机中实施IPv6的用户提供一个简单的参考，本文给出了一些重要的注意事项。有必要确保手机主机是互联网的好公民。
This document is informational in nature, and it is not intended to replace, update, or contradict any IPv6 standards documents [RFC-2026].
本文件为信息性文件，无意取代、更新或与任何IPv6标准文件相抵触[RFC-2026]。
The main audience of this document are: the implementers of cellular hosts that will be used with GPRS, 3GPP UMTS Release 99, Release 4, Release 5, or future releases of UMTS. The document provides guidance on which parts of IPv6 to implement in such cellular hosts. Parts of this document may also apply to other cellular link types, but no such detailed analysis has been done yet and is a topic of future work. This document should not be used as a definitive list
本文档的主要受众是：将与GPRS、3GPP UMTS Release 99、Release 4、Release 5或UMTS未来版本一起使用的蜂窝主机的实施者。该文档提供了有关在此类蜂窝主机中实施IPv6的哪些部分的指导。本文档的部分内容可能也适用于其他蜂窝链路类型，但尚未进行此类详细分析，这是未来工作的主题。本文件不应用作最终清单
of IPv6 functionality for cellular links other than those listed above. Future changes in 3GPP networks that require changes in host implementations may result in updates to this document.
以上列出的蜂窝链路以外的其他蜂窝链路的IPv6功能。3GPP网络中需要更改主机实现的未来更改可能会导致本文档的更新。
There are different ways to implement cellular hosts:
有不同的方式来实现蜂窝主机：
- The host can be a "closed 2G or 3G host" with a very compact size and optimized 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.
- 主机可以是“封闭式2G或3G主机”，具有非常紧凑的尺寸和优化的应用程序，不可能添加或下载具有IP通信的应用程序。这种主机的一个例子是一种非常简单的移动电话。
- The host can be an "open 2G or 3G host" with a compact size, but where it is possible to download applications; such as a PDA-type of phone.
- 主机可以是小型的“开放2G或3G主机”，但可以下载应用程序；例如PDA类型的电话。
If a cellular host has additional interfaces on which IP is used, (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 a PC card, other than recommending link specific behavior on the cellular link.
如果蜂窝式主机具有使用IP的附加接口（如以太网、WLAN、蓝牙等），则除本文档中讨论的内容外，设备可能还有其他要求。此外，除了建议蜂窝链路上的链路特定行为外，本文档不对具有蜂窝接口（如PC卡）的笔记本电脑所需的功能提出任何建议。
This document discusses IPv6 functionality as specified when this document has been written. Ongoing work on IPv6 may affect what is needed from future hosts. The reader should also be advised other relevant work exists for various other layers. Examples of this include the header compression work done in the IETF ROHC group, the analysis of the effects of error-prone links to performance in [RFC-3155], or the TCP work in [RFC-3481].
本文档讨论编写本文档时指定的IPv6功能。正在进行的IPv6工作可能会影响未来主机的需求。读者还应该被告知，其他各层存在其他相关工作。这方面的例子包括在IETF ROHC组中完成的头压缩工作，[RFC-3155]中对易出错链接对性能的影响的分析，或[RFC-3481]中的TCP工作。
Transition mechanisms used by cellular hosts are not described in this document and are left for further study.
本文档中未描述蜂窝主机使用的转换机制，留待进一步研究。
2G Second Generation Mobile Telecommunications, such as GSM and GPRS technologies. 3G Third Generation Mobile Telecommunications, such as UMTS technology. 3GPP 3rd Generation Partnership Project. Throughout the document, the term 3GPP (3rd Generation Partnership Project) networks refers to architectures standardized by 3GPP, in Second and Third Generation releases: 99, 4, and 5, as well as future releases. AH Authentication Header APN Access Point Name. The APN is a logical name referring to a GGSN and an external network.
2G第二代移动通信，如GSM和GPRS技术。3G第三代移动通信，如UMTS技术。3GPP第三代合作伙伴项目。在整个文档中，术语3GPP（第三代合作伙伴关系项目）网络指的是第二代和第三代版本（99、4和5）以及未来版本中由3GPP标准化的体系结构。AH身份验证头APN访问点名称。APN是指GGSN和外部网络的逻辑名称。
ESP Encapsulating Security Payload ETSI European Telecommunications Standards Institute IMS IP Multimedia Subsystem GGSN Gateway GPRS Support Node (a default router for 3GPP IPv6 cellular hosts) GPRS General Packet Radio Service GSM Global System for Mobile Communications IKE Internet Key Exchange ISAKMP Internet Security Association and Key Management Protocol MT Mobile Terminal, for example, a mobile phone handset. MTU Maximum Transmission Unit PDP Packet Data Protocol SGSN Serving GPRS Support Node TE Terminal Equipment, for example, a laptop attached through a 3GPP handset. UMTS Universal Mobile Telecommunications System WLAN Wireless Local Area Network
ESP封装安全有效载荷ETSI欧洲电信标准协会IMS IP多媒体子系统GGSN网关GPRS支持节点（3GPP IPv6蜂窝主机的默认路由器）GPRS通用分组无线业务GSM全球移动通信系统IKE互联网密钥交换ISAKMP互联网安全协会和密钥管理协议MT移动终端，例如，移动电话。MTU最大传输单元PDP分组数据协议SGSN服务于GPRS支持节点TE终端设备，例如，通过3GPP手持机连接的笔记本电脑。UMTS通用移动通信系统WLAN无线局域网
This specification defines IPv6 features for cellular hosts in three groups.
本规范定义了三组蜂窝主机的IPv6功能。
Basic IP
Basic IPtranslate error, please retry
In this group, basic parts of IPv6 are described.
本组介绍了IPv6的基本部分。
IP Security
IP安全
In this group, the IP Security parts are described.
在此组中，描述了IP安全部分。
Mobility
流动性
In this group, IP layer mobility issues are described.
在本组中，描述了IP层移动性问题。
2 Basic IP
2基本知识产权
Path MTU Discovery [RFC-1981] may be used. Cellular hosts with a link MTU larger than the minimum IPv6 link MTU (1280 octets) can use Path MTU Discovery in order to discover the real path MTU. The relative overhead of IPv6 headers is minimized through the use of longer packets, thus making better use of the available bandwidth.
可使用MTU发现路径[RFC-1981]。链路MTU大于最小IPv6链路MTU（1280个八位字节）的蜂窝主机可以使用路径MTU发现来发现实际路径MTU。通过使用更长的数据包，IPv6报头的相对开销最小化，从而更好地利用可用带宽。
The IPv6 specification [RFC-2460] states in Section 5 that "a minimal IPv6 implementation (e.g., in a boot ROM) may simply restrict itself to sending packets no larger than 1280 octets, and omit implementation of Path MTU Discovery."
IPv6规范[RFC-2460]在第5节中指出，“最小IPv6实现（例如，在引导ROM中）可能仅限于发送不大于1280个八位字节的数据包，而忽略路径MTU发现的实现。”
If Path MTU Discovery is not implemented then the sending packet size is limited to 1280 octets (standard limit in [RFC-2460]). However, if this is done, the cellular host must be able to receive packets with size up to the link MTU before reassembly. This is because the node at the other side of the link has no way of knowing less than the MTU is accepted.
如果未实现路径MTU发现，则发送数据包大小限制为1280个八位字节（RFC-2460中的标准限制）。然而，如果这样做了，蜂窝主机必须能够在重新组装之前接收大小达到链路MTU的数据包。这是因为链路另一端的节点无法知道MTU是否被接受。
The IPv6 Addressing Architecture [RFC-3513] is a mandatory part of IPv6.
IPv6寻址体系结构[RFC-3513]是IPv6的必备部分。
The Internet Protocol Version 6 is specified in [RFC-2460]. This specification is a mandatory part of IPv6.
[RFC-2460]中规定了互联网协议版本6。本规范是IPv6的强制性部分。
By definition, a cellular host acts as a host, not as a router. Implementation requirements for a cellular router are not defined in this document.
根据定义，蜂窝主机充当主机，而不是路由器。本文件未定义蜂窝路由器的实施要求。
Consequently, the cellular host must implement all non-router packet receive processing as described in RFC 2460. This includes the generation of ICMPv6 error reports, and the processing of at least the following extension headers:
因此，蜂窝主机必须实现RFC 2460中描述的所有非路由器分组接收处理。这包括生成ICMPv6错误报告，以及至少处理以下扩展标头：
- Hop-by-Hop Options header: at least the Pad1 and PadN options
- 逐跳选项标题：至少包含Pad1和PadN选项
- Destination Options header: at least the Pad1 and PadN options
- 目标选项标题：至少包含Pad1和PadN选项
- Routing (Type 0) header: final destination (host) processing only
- 路由（类型0）标头：仅限最终目标（主机）处理
- Fragment header
- 分段报头
- AH and ESP headers (see also a discussion on the use of IPsec for various purposes in Section 3)
- AH和ESP头（另请参见第3节中有关IPsec用于各种目的的讨论）
- The No Next Header value
- 无下一个标题值
Unrecognized options in Hop-by-Hop Options or Destination Options extensions must be processed as described in RFC 2460.
必须按照RFC 2460中的说明处理逐跳选项或目标选项扩展中无法识别的选项。
The cellular host must follow the packet transmission rules in RFC 2460.
蜂窝主机必须遵守RFC 2460中的数据包传输规则。
The cellular host must always be able to receive and reassemble fragment headers. It will also need to be able to send a fragment header in cases where it communicates with an IPv4 host through a translator (see Section 5 of RFC2460).
蜂窝主机必须始终能够接收和重新组装片段头。在通过转换器与IPv4主机通信的情况下，它还需要能够发送片段头（请参阅RFC2460的第5节）。
Cellular hosts should only process routing headers when they are the final destination and return errors if the processing of the routing header requires them to forward the packet to another node. This will also ensure that the cellular hosts will not be inappropriately used as relays or components in Denial-of-Service (DoS) attacks. Acting as the destination involves the following: the cellular hosts must check the Segments Left field in the header, and proceed if it is zero or one and the next address is one of the host's addresses. If not, however, the host must implement error checks as specified in Section 4.4 of RFC 2460. There is no need for the host to send Routing Headers.
蜂窝主机应仅在其为最终目的地时处理路由报头，并且如果路由报头的处理要求其将数据包转发到另一个节点，则应返回错误。这还将确保蜂窝主机不会被不当地用作拒绝服务（DoS）攻击中的中继或组件。充当目的地涉及以下内容：蜂窝主机必须检查报头中的Segments Left字段，如果它是零或一，并且下一个地址是主机的地址之一，则继续。但是，如果没有，主机必须按照RFC 2460第4.4节的规定执行错误检查。主机不需要发送路由头。
Neighbor Discovery is described in [RFC-2461]. This specification is a mandatory part of IPv6.
[RFC-2461]中描述了邻居发现。本规范是IPv6的强制性部分。
A cellular host must support Neighbor Solicitation and Advertisement messages.
蜂窝主机必须支持邻居请求和广告消息。
In GPRS and UMTS networks, some Neighbor Discovery messages can be unnecessary in certain cases. GPRS and UMTS 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. There are no link layer addresses. Therefore, address resolution and next-hop determination are not needed.
在GPRS和UMTS网络中，某些情况下可能不需要邻居发现消息。GPRS和UMTS链路类似于点对点链路；因此，蜂窝主机在蜂窝链路上的唯一邻居是通过路由器发现已知的默认路由器。没有链接层地址。因此，不需要地址解析和下一跳确定。
The cellular host must support neighbor unreachability detection as specified in [RFC-2461].
蜂窝主机必须支持[RFC-2461]中规定的邻居不可达性检测。
In GPRS and UMTS networks, it is very desirable to conserve bandwidth. Therefore, the cellular host should include a mechanism in upper layer protocols to provide reachability confirmation when two-way IP layer reachability can be confirmed (see RFC-2461, Section 7.3.1). These confirmations will allow the suppression of most NUD-related messages in most cases.
在GPRS和UMTS网络中，节省带宽是非常可取的。因此，蜂窝式主机应在上层协议中包含一种机制，以便在双向IP层可达性得到确认时提供可达性确认（参见RFC-2461，第7.3.1节）。这些确认将允许在大多数情况下抑制大多数与NUD相关的消息。
Host TCP implementation should provide reachability confirmation in the manner explained in RFC 2461, Section 7.3.1.
主机TCP实现应按照RFC 2461第7.3.1节中说明的方式提供可达性确认。
The common use of UDP in 3GPP networks poses a problem for providing reachability confirmation. UDP itself is unable to provide such confirmation. Applications running over UDP should provide the confirmation where possible. In particular, when UDP is used for transporting RTP, the RTCP protocol 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用于传输RTP时，RTCP协议反馈应作为可达性确认的基础。如果接收到RTCP数据包时，接收报告块指示某些数据包已通过，则数据包正在到达对等方。如果他们已经到达了对等者，那么他们也已经到达了邻居。
When UDP is used for transporting SIP, 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时，对SIP请求的响应应作为发送给对等方的数据包正在到达它的确认。当蜂窝主机充当服务器端SIP节点时，通常不提供此类确认。然而，主机可以将SIP ACK请求的接收解释为确认先前发送的对SIP INVITE请求的响应已经到达对等方。
IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462]. This specification is a mandatory part of IPv6.
[RFC-2462]中定义了IPv6无状态地址自动配置。本规范是IPv6的强制性部分。
A cellular host in a 3GPP network must process a Router Advertisement as stated in Section 2.4.
3GPP网络中的蜂窝主机必须按照第2.4节的规定处理路由器广告。
Hosts in 3GPP networks can set DupAddrDetectTransmits equal to zero, as each delegated prefix is unique within its scope when allocated using the 3GPP IPv6 Stateless Address Autoconfiguration. In addition, the default router (GGSN) will not configure or assign to its interfaces, any addresses based on prefixes delegated to IPv6 hosts. Thus, the host is not required to perform Duplicate Address Detection on the cellular interface.
3GPP网络中的主机可以将DupAddrDetectTransmissions设置为零，因为当使用3GPP IPv6无状态地址自动配置进行分配时，每个委派前缀在其作用域内都是唯一的。此外，默认路由器（GGSN）不会根据委派给IPv6主机的前缀配置或向其接口分配任何地址。因此，主机不需要在蜂窝接口上执行重复地址检测。
See Appendix A for more details on 3GPP IPv6 Stateless Address Autoconfiguration.
有关3GPP IPv6无状态地址自动配置的更多详细信息，请参阅附录A。
The Internet Control Message Protocol for the IPv6 is defined [RFC-2463]. This specification is a mandatory part of IPv6. Currently, this work is being updated.
定义了IPv6的Internet控制消息协议[RFC-2463]。本规范是IPv6的强制性部分。目前，这项工作正在更新中。
As per RFC 2463 Section 2, ICMPv6 requirements must be fully implemented by every IPv6 node. See also Section 3 for an explanation of the use of IPsec for protecting ICMPv6 communications.
根据RFC 2463第2节，每个IPv6节点必须完全实现ICMPv6要求。有关使用IPsec保护ICMPv6通信的说明，请参见第3节。
IPv6 over PPP [RFC-2472] must be supported for cellular hosts that implement PPP.
实施PPP的蜂窝主机必须支持IPv6 over PPP[RFC-2472]。
A cellular host in a 3GPP network must support the IPv6CP 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) 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 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, 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 for its link-local address.
3GPP网络中的蜂窝主机必须支持IPv6CP接口标识符选项。该选项需要能够使用蜂窝设备（MT）和其他设备（例如笔记本电脑）之间的PPP链路将其他设备连接到互联网。MT根据来自TE的请求执行PDP上下文激活。这导致MT使用IPv6CP选项向TE建议接口标识符。为了避免TE和GGSN之间链路本地地址的任何重复，MT必须始终拒绝TE建议的其他接口标识符。这导致TE始终使用GGSN建议的接口标识符作为其链路本地地址。
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 [RFC-3041] for site-local and global addresses is not affected by the above procedure. The above procedure is only concerned with assigning the interface identifier used for forming link-local addresses, and does not preclude TE from using other interface identifiers for addresses with larger scopes (i.e., site-local and global).
根据3GPP规范，TE建议的接口标识符的拒绝仅用于创建链路本地地址。对站点本地和全局地址使用隐私地址[RFC-3041]不受上述程序的影响。上述程序仅涉及分配用于形成链路本地地址的接口标识符，并不排除TE对具有较大范围（即站点本地和全局）的地址使用其他接口标识符。
Generic Packet Tunneling [RFC-2473] may be supported if needed for transition mechanisms.
如果转换机制需要，可以支持通用数据包隧道[RFC-2473]。
Multicast Listener Discovery [RFC-2710] must be supported by cellular hosts.
蜂窝主机必须支持多播侦听器发现[RFC-2710]。
MLD requires that MLD messages be sent for link-local multicast addresses (excluding the all-nodes address). The requirement that MLD be run even for link-local addresses aids layer-two devices (e.g., Ethernet bridges) that attempt to suppress the forwarding of link-layer multicast packets to portions of the layer-two network where there are no listeners. If MLD is used to announce the
MLD要求为链路本地多播地址（不包括所有节点地址）发送MLD消息。即使对于链路本地地址也要运行MLD的要求有助于第二层设备（例如，以太网网桥），这些设备试图抑制链路层多播数据包转发到第二层网络中没有侦听器的部分。如果使用MLD来宣布
presence of listeners for all IP multicast addresses (including link-local multicast addresses), layer 2 devices can snoop MLD messages to reliably determine which portions of a network IP multicast messages need to be forwarded to.
如果存在所有IP多播地址（包括链路本地多播地址）的侦听器，则第2层设备可以嗅探MLD消息，以可靠地确定网络IP多播消息需要转发到的部分。
Within 3GPP networks, hosts connect to their default routers (GGSN) 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 may not always be necessary.
在3GPP网络中，主机通过点对点链路连接到其默认路由器（GGSN）。此外，正好有两个IP设备连接到点到点链路，并且没有尝试（在链路层）抑制多播流量的转发。因此，在3GPP环境中发送链路本地地址的MLD报告可能并不总是必要的。
MLD is needed for multicast group knowledge that is not link-local.
对于非本地链路的多播组知识，需要MLD。
The Router Alert Option [RFC-2711] must be supported, and its use is required when MLD is used (see Section 2.9) or when RSVP [RFC-2205] is used.
必须支持路由器警报选项[RFC-2711]，当使用MLD（见第2.9节）或使用RSVP[RFC-2205]时，需要使用该选项。
Privacy Extensions for Stateless Address Autoconfiguration [RFC-3041] should be supported. RFC 3041, and privacy in general, is important for the Internet. Cellular hosts may use the temporary addresses as described in RFC 3041. However, the use of the Privacy Extension in an environment where IPv6 addresses are short-lived may not be necessary. At the time this document has been written, there is no experience on how long-lived cellular network address assignments (i.e., attachments to the network) are. The length of the address assignments depends upon many factors such as radio coverage, device status and user preferences. Additionally, the use of temporary address with IPsec may lead to more frequent renegotiation for the Security Associations.
应支持无状态地址自动配置的隐私扩展[RFC-3041]。RFC3041，以及一般的隐私，对互联网很重要。蜂窝主机可使用RFC 3041中所述的临时地址。但是，在IPv6地址寿命较短的环境中，可能没有必要使用隐私扩展。在编写本文档时，还没有关于蜂窝网络地址分配（即网络附件）寿命的经验。地址分配的长度取决于许多因素，如无线电覆盖范围、设备状态和用户偏好。此外，在IPsec中使用临时地址可能会导致更频繁地重新协商安全关联。
Refer to Section 5 for a discussion of the benefits of privacy extensions in a 3GPP network.
有关3GPP网络中隐私扩展的好处的讨论，请参阅第5节。
The Dynamic Host Configuration Protocol for IPv6 [DHCPv6] may be used. DHCPv6 is not required for address autoconfiguration when IPv6 stateless autoconfiguration is used. However, DHCPv6 may be useful for other configuration needs on a cellular host.
可以使用IPv6的动态主机配置协议[DHCPv6]。使用IPv6无状态自动配置时，地址自动配置不需要DHCPv6。然而，DHCPv6对于蜂窝主机上的其他配置需求可能有用。
Default Address Selection [RFC-3484] is needed for cellular hosts.
蜂窝式主机需要默认地址选择[RFC-3484]。
Cellular hosts should support DNS, as described in [RFC-1034], [RFC-1035], [RFC-1886], and [RFC-3152].
蜂窝主机应支持DNS，如[RFC-1034]、[RFC-1035]、[RFC-1886]和[RFC-3152]中所述。
If DNS is used, a cellular host can perform DNS requests in the recursive mode, to limit signaling over the air interface. Both the iterative and the recursive approach should be supported, however, as the specifications require implementation of the iterative approach, and allow the recursive approach as an option. Furthermore, all DNS servers may not support recursive queries, and the security benefits of DNS Security cannot always be achieved with them.
如果使用DNS，蜂窝主机可以在递归模式下执行DNS请求，以限制空中接口上的信令。但是，应该支持迭代和递归方法，因为规范要求实现迭代方法，并允许将递归方法作为选项。此外，所有DNS服务器可能都不支持递归查询，并且DNS安全性的安全优势不能总是通过它们来实现。
3 IP Security
3 IP安全
IPsec [RFC-2401] is a fundamental part of IPv6, and support for AH and ESP is described as mandatory in the specifications.
IPsec[RFC-2401]是IPv6的基本组成部分，规范中规定必须支持AH和ESP。
The first part of this section discusses the applicability of IP Security and other security mechanisms for common tasks in cellular hosts. The second part, Sections 3.1 to 3.13, lists the specifications related to IPsec and discusses the use of these parts of IPsec in a cellular context.
本节的第一部分讨论了IP安全和其他安全机制对蜂窝主机中常见任务的适用性。第二部分第3.1至3.13节列出了与IPsec相关的规范，并讨论了IPsec这些部分在蜂窝环境中的使用。
In general, the need to use a security mechanism depends on the intended application for it. Different security mechanisms are useful in different contexts, and have different limitations. Some applications require the use of TLS [RFC-2246], in some situations IPsec is used.
通常，使用安全机制的需要取决于它的预期应用程序。不同的安全机制在不同的上下文中是有用的，并且有不同的限制。某些应用程序需要使用TLS[RFC-2246]，在某些情况下使用IPsec。
It is not realistic to list all possible services here, and it is expected that application protocol specifications have requirements on what security services they require. Note that cellular hosts able to download applications must be prepared to offer sufficient security services for these applications regardless of the needs of the initial set of applications in those hosts.
在这里列出所有可能的服务是不现实的，并且应用程序协议规范对它们需要的安全服务有要求。请注意，能够下载应用程序的蜂窝主机必须准备好为这些应用程序提供足够的安全服务，而不管这些主机中的初始应用程序集的需求如何。
The following sections list specifications related to the IPsec functionality, and discuss their applicability in a cellular context. This discussion focuses on the use of IPsec. In some applications, a different set of protocols may need to be employed. In particular, the below discussion is not relevant for applications that use other security services than IPsec.
以下各节列出了与IPsec功能相关的规范，并讨论了它们在蜂窝环境中的适用性。本讨论的重点是IPsec的使用。在某些应用中，可能需要采用一组不同的协议。特别是，以下讨论与使用IPsec以外的其他安全服务的应用程序无关。
This specification [RFC-2104] must be supported. It is referenced by RFC 2403 that describes how IPsec protects the integrity of packets.
必须支持本规范[RFC-2104]。RFC 2403引用了它，它描述了IPsec如何保护数据包的完整性。
This specification [RFC-2401] must be supported.
必须支持本规范[RFC-2401]。
This specification [RFC-2402] must be supported.
必须支持本规范[RFC-2402]。
This specification [RFC-2403] must be supported.
必须支持本规范[RFC-2403]。
This specification [RFC-2404] must be supported.
必须支持本规范[RFC-2404]。
This specification [RFC-2405] may be supported. It is, however, recommended that stronger algorithms than DES be used. Algorithms, such as AES, are undergoing work in the IPsec working group. These new algorithms are useful, and should be supported as soon as their standardization is ready.
可能支持本规范[RFC-2405]。然而，建议使用比DES更强的算法。诸如AES之类的算法正在IPsec工作组中进行工作。这些新算法是有用的，一旦标准化工作就绪，就应该得到支持。
This specification [RFC-2406] must be supported.
必须支持本规范[RFC-2406]。
Automatic key management, [RFC-2408] and [RFC-2409], is not a mandatory part of the IP Security Architecture. Note, however, that in the cellular environment the IP addresses of a host may change dynamically. For this reason the use of manually configured Security Associations is not practical, as the newest host address would have to be updated to the SA database of the peer as well.
自动密钥管理[RFC-2408]和[RFC-2409]不是IP安全体系结构的强制性部分。然而，请注意，在蜂窝环境中，主机的IP地址可能会动态变化。因此，使用手动配置的安全关联是不实际的，因为最新的主机地址也必须更新到对等方的SA数据库。
Even so, it is not clear that all applications would use IKE for key management. For instance, hosts may use IPsec ESP [RFC-2406] for protecting SIP signaling in the IMS [3GPP-ACC] but provide authentication and key management through another mechanism such as UMTS AKA (Authentication and Key Agreement) [UMTS-AKA].
即便如此，并不清楚所有应用程序是否都会使用IKE进行密钥管理。例如，主机可以使用IPsec ESP[RFC-2406]来保护IMS[3GPP-ACC]中的SIP信令，但是通过诸如UMTS AKA（认证和密钥协议）[UMTS-AKA]的另一机制来提供认证和密钥管理。
It is likely that several simplifying assumptions can be made in the cellular environment, with respect to the mandated parts of the IP Security DoI, ISAKMP, and IKE. Work on such simplifications would be useful, but is outside the scope of this document.
有可能在蜂窝环境中，就IP安全DoI、ISAKMP和IKE的授权部分，可以做出一些简化假设。关于这些简化的工作将是有益的，但不在本文件的范围之内。
3.9 RFC2408 - The Internet Security Association and Key Management Protocol
3.9 RFC2408-互联网安全关联和密钥管理协议
This specification [RFC-2408] is optional according to the IPv6 specifications, but may be necessary in some applications, as described in Section 3.8.
根据IPv6规范，本规范[RFC-2408]是可选的，但在某些应用中可能是必要的，如第3.8节所述。
This specification [RFC-2409] is optional according to the IPv6 specifications, but may be necessary in some applications, as described in Section 3.8.
根据IPv6规范，本规范[RFC-2409]是可选的，但在某些应用中可能是必要的，如第3.8节所述。
Interactions with the ICMPv6 packets and IPsec policies may cause unexpected behavior for IKE-based SA negotiation unless some special handling is performed in the implementations.
与ICMPv6数据包和IPsec策略的交互可能会导致基于IKE的SA协商出现意外行为，除非在实现中执行某些特殊处理。
The ICMPv6 protocol provides many functions, which in IPv4 were either non-existent or provided by lower layers. For instance, IPv6 implements address resolution using an IP packet, ICMPv6 Neighbor Solicitation message. In contrast, IPv4 uses an ARP message at a lower layer.
ICMPv6协议提供了许多功能，在IPv4中这些功能要么不存在，要么由较低的层提供。例如，IPv6使用IP数据包ICMPv6邻居请求消息实现地址解析。相反，IPv4在较低层使用ARP消息。
The IPsec architecture has a Security Policy Database that specifies which traffic is protected, and how. It turns out that the specification of policies in the presence of ICMPv6 traffic is not easy. For instance, a simple policy of protecting all traffic between two hosts on the same network would trap even address resolution messages, leading to a situation where IKE can't establish a Security Association since in order to send the IKE UDP packets one would have had to send the Neighbor Solicitation Message, which would have required an SA.
IPsec体系结构有一个安全策略数据库，该数据库指定保护哪些通信以及如何保护。事实证明，在存在ICMPv6通信量的情况下规范策略并不容易。例如，保护同一网络上两台主机之间的所有通信的简单策略甚至会捕获地址解析消息，导致IKE无法建立安全关联的情况，因为为了发送IKE UDP数据包，必须发送邻居请求消息，这需要SA。
In order to avoid this problem, Neighbor Solicitation, Neighbor Advertisement, Router Solicitation, and Router Advertisement messages must not lead to the use of IKE-based SA negotiation. The Redirect message should not lead to the use of IKE-based SA negotiation. Other ICMPv6 messages may use IKE-based SA negotiation as is desired in the Security Policy Data Base.
为了避免此问题，邻居请求、邻居公告、路由器请求和路由器公告消息不得导致使用基于IKE的SA协商。重定向消息不应导致使用基于IKE的SA协商。根据安全策略数据库中的需要，其他ICMPv6消息可以使用基于IKE的SA协商。
Note that the above limits the usefulness of IPsec in protecting all ICMPv6 communications. For instance, it may not be possible to protect the ICMPv6 traffic between a cellular host and its next hop
请注意，以上限制了IPsec在保护所有ICMPv6通信方面的用途。例如，可能无法保护蜂窝主机与其下一跳之间的ICMPv6流量
router. (Which may be hard in any case due to the need to establish a suitable public key infrastructure. Since roaming is allowed, this infrastructure would have to authenticate all hosts to all routers.)
路由器。（由于需要建立合适的公钥基础设施，这在任何情况下都可能很困难。由于允许漫游，此基础设施必须对所有路由器的所有主机进行身份验证。）
This specification [RFC-2410] must be supported.
必须支持本规范[RFC-2410]。
This specification [RFC-2451] must be supported if encryption algorithms other than DES are implemented, e.g., CAST-128, RC5, IDEA, Blowfish, 3DES.
如果实施DES以外的加密算法，如CAST-128、RC5、IDEA、河豚、3DES，则必须支持本规范[RFC-2451]。
For the purposes of this document, IP mobility is not relevant. When Mobile IPv6 specification is approved, a future update to this document may address these issues, as there may be some effects on all IPv6 hosts due to Mobile IP. The movement of cellular hosts within 3GPP networks is handled by link layer mechanisms.
就本文件而言，IP移动性不相关。当移动IPv6规范获得批准后，本文档的未来更新可能会解决这些问题，因为移动IP可能会对所有IPv6主机产生一些影响。3GPP网络中蜂窝主机的移动由链路层机制处理。
This document does not specify any new protocols or functionality, 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功能的特定配置文件，漏洞可能会打开或关闭，具体取决于包含哪些功能和不包含哪些功能。蜂窝环境的某些方面也使某些类型的漏洞更加严重。讨论了以下问题：
- The suggested limitations (Section 2.3) in the processing of routing headers limits also exposure to DoS attacks through cellular hosts.
- 路由头处理中的建议限制（第2.3节）也限制了通过蜂窝主机受到DoS攻击的风险。
- IPv6 addressing privacy [RFC3041] may be used in cellular hosts. However, it should be noted that in the 3GPP model, the network would assign new addresses, in most cases, to hosts in roaming situations and typically, also when the cellular hosts activate a PDP context. 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's coverage area is expected to be very large when compared to currently deployed default routers (no handovers between GGSNs are possible), a cellular host can keep an address 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
- IPv6寻址隐私[RFC3041]可用于蜂窝主机。然而，应当注意，在3GPP模型中，在大多数情况下，网络将在漫游情况下，并且通常在蜂窝主机激活PDP上下文时，向主机分配新地址。这意味着3GPP网络将提供有限形式的隐私寻址，并且不可能通过其地址对单个主机进行全局跟踪。另一方面，由于与当前部署的默认路由器相比，GGSN的覆盖区域预计非常大（GGSN之间不可能进行切换），因此蜂窝主机可以长时间保留地址。因此，IPv6寻址隐私可用于在主机开启期间以及在同一时间内提供额外的隐私
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.
地区隐私功能也可用于，例如，使不同的传输会话看起来来自不同的IP地址。然而，不清楚这些额外的努力是否会进一步混淆潜在的观察者，因为他们只能监视网络前缀部分。
- The use of various security services such as IPsec or TLS in the connection of typical applications in cellular hosts is discussed in Section 3 and recommendations are given there.
- 第3节讨论了在蜂窝主机的典型应用程序连接中使用各种安全服务，如IPsec或TLS，并给出了建议。
- Section 3 also discusses under what conditions it is possible to provide IPsec protection of e.g., ICMPv6 communications.
- 第3节还讨论了在什么条件下可以提供IPsec保护，例如ICMPv6通信。
- 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 of further study. It is also often easy to fill the cellular link and queues on both sides with additional or large packets.
- 蜂窝主机使用的广播时间很昂贵。在某些情况下，用户将根据其与主机之间传输的数据量计费。对于网络和用户来说，正确使用广播时间是至关重要的，并且不会因为第三方行为不端而向用户收取额外费用。蜂窝链路也具有有限的容量，这意味着它们不一定能够容纳比用户选择的更多的流量，例如多媒体呼叫。额外的流量可能会干扰用户体验的服务级别。虽然服务质量机制在一定程度上缓解了这些问题，但很明显，DoS方面可能会在蜂窝环境中突出显示。在这种环境下，使用例如数据包放大的现有DoS攻击可能会造成更大的破坏。如何防范这些攻击仍然是一个有待进一步研究的领域。用额外的或大的数据包填充蜂窝链路和两侧的队列通常也很容易。
- 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.
- 在一些服务提供商网络中，可以在不出示个人身份证明的情况下购买预付费手机订阅。希望保持身份不明的攻击者可以利用这一点。请注意，虽然用户尚未确定，但设备仍在使用中；操作员可以跟踪设备的标识并阻止其进一步使用。运营商必须制定适当的程序，以注意第三方对其客户设备使用的投诉。运营商可能还需要具备攻击检测工具，使其能够有效检测从蜂窝主机发起的攻击。
- Cellular devices that have local network interfaces (such as IrDA 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.
- 具有本地网络接口（如IrDA或蓝牙）的蜂窝设备可用于通过它们发起攻击，除非本地接口以适当的方式得到保护。因此，本地网络接口应具有访问控制，以防止其他人将蜂窝主机用作中介。
[RFC-1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC-1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC-1886] Thomson, S. and C. Huitema, "DNS Extensions to support IP version 6, RFC 1886, December 1995.
[RFC-1886]Thomson，S.和C.Huitema，“支持IP版本6的DNS扩展，RFC 1886，1995年12月。
[RFC-1981] McCann, J., Mogul, J. and S. Deering, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC-1981]McCann，J.，Mogul，J.和S.Deering，“IP版本6的路径MTU发现”，RFC 1981，1996年8月。
[RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC-2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[RFC-2104] Krawczyk, K., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC-2104]Krawczyk，K.，Bellare，M.和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[RFC-2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC-2246]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC 2246，1999年1月。
[RFC-2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC-2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[RFC-2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC-2402]Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[RFC-2403] Madson, C., and R. Glenn, "The Use of HMAC-MD5 within ESP and AH", RFC 2403, November 1998.
[RFC-2403]Madson，C.和R.Glenn，“HMAC-MD5在ESP和AH中的使用”，RFC 2403，1998年11月。
[RFC-2404] Madson, C., and R. Glenn, "The Use of HMAC-SHA-1 within ESP and AH", RFC 2404, November 1998.
[RFC-2404]Madson，C.和R.Glenn，“HMAC-SHA-1在ESP和AH中的使用”，RFC 2404，1998年11月。
[RFC-2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998.
[RFC-2405]Madson，C.和N.Doraswamy，“带显式IV的ESP DES-CBC密码算法”，RFC 2405，1998年11月。
[RFC-2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Protocol (ESP)", RFC 2406, November 1998.
[RFC-2406]Kent，S.和R.Atkinson，“IP封装安全协议（ESP）”，RFC 2406，1998年11月。
[RFC-2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC-2407]Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[RFC-2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[RFC-2408]Maughan，D.，Schertler，M.，Schneider，M.，和J.Turner，“互联网安全协会和密钥管理协议（ISAKMP）”，RFC 2408，1998年11月。
[RFC-2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC-2409]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[RFC-2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.
[RFC-2410]Glenn，R.和S.Kent，“空加密算法及其在IPsec中的使用”，RFC 2410，1998年11月。
[RFC-2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[RFC-2451]Pereira，R.和R.Adams，“ESP CBC模式密码算法”，RFC 2451，1998年11月。
[RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC-2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC-2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC-2461]Narten，T.，Nordmark，E.和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC 2461，1998年12月。
[RFC-2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC-2462]Thomson，S.和T.Narten，“IPv6无状态地址自动配置”，RFC 2462，1998年12月。
[RFC-2463] Conta, A. and S. Deering, "ICMP for the Internet Protocol Version 6 (IPv6)", RFC 2463, December 1998.
[RFC-2463]Conta，A.和S.Deering，“互联网协议版本6（IPv6）的ICMP”，RFC 2463，1998年12月。
[RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC-2473]Conta，A.和S.Deering，“IPv6规范中的通用数据包隧道”，RFC 2473，1998年12月。
[RFC-2710] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC-2710]Deering，S.，Fenner，W.和B.Haberman，“IPv6的多播侦听器发现（MLD）”，RFC 2710，1999年10月。
[RFC-2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[RFC-2711]帕特里奇，C.和A.杰克逊，“IPv6路由器警报选项”，RFC 27111999年10月。
[RFC-2874] Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000.
[RFC-2874]Crawford，M.和C.Huitema，“支持IPv6地址聚合和重新编号的DNS扩展”，RFC 2874，2000年7月。
[RFC-3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[RFC-3041]Narten，T.和R.Draves，“IPv6中无状态地址自动配置的隐私扩展”，RFC 3041，2001年1月。
[RFC-3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, August 2001.
[RFC-3152]布什，R.，“IP6.ARPA的授权”，BCP 49，RFC 3152，2001年8月。
[RFC-3155] Dawkins, S., Montenegro, G., Kojo, M., Magret, V. and N. Vaidya, "End-to-end Performance Implications of Links with Errors", BCP 50, RFC 3155, August 2001.
[RFC-3155]道金斯，S.，黑山，G.，科乔，M.，马格里特，V.和N.瓦迪亚，“有错误链接的端到端性能影响”，BCP 50，RFC 3155，2001年8月。
[RFC-3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC-3484]Draves，R.，“互联网协议版本6（IPv6）的默认地址选择”，RFC 3484，2003年2月。
[RFC-3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC-3513]Hinden，R.和S.Deering，“互联网协议版本6（IPv6）寻址体系结构”，RFC 3513，2003年4月。
[3GPP-ACC] 3GPP Technical Specification 3GPP TS 33.203, "Technical Specification Group Services and System Aspects; 3G Security; Access security for IP-based services (Release 5)", 3rd Generation Partnership Project, March 2002.
[3GPP-ACC]3GPP技术规范3GPP TS 33.203，“技术规范组服务和系统方面；3G安全；基于IP的服务的访问安全（第5版）”，第三代合作伙伴项目，2002年3月。
[3GPP-IMS] 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IP Multimedia (IM) Subsystem - Stage 2; (3G TS 23.228)
[3GPP-IMS]第三代合作伙伴项目；技术规范组服务和系统方面；IP多媒体（IM）子系统-第2阶段；（3G TS 23.228）
[3GPP-IPv6] 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects "Architectural requirements" (TS 23.221)
[3GPP-IPv6]第三代合作伙伴项目；技术规范组服务和系统方面“架构要求”（TS 23.221）
[DHCPv6] Bound, J., et al., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", Work in progress.
[DHCPv6]Bound，J.，等人，“IPv6的动态主机配置协议（DHCPv6）”，正在进行中。
[RFC-1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC-1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC-2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999.
[RFC-2529]Carpenter，B.和C.Jung，“在没有明确隧道的IPv4域上传输IPv6”，RFC 2529，1999年3月。
[RFC-2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC-2205]Braden，R.，Zhang，L.，Berson，S.，Herzog，S.和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 2205，1997年9月。
[RFC-3314] Wasserman, M., Editor, "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards, RFC 3314, September 2002.
[RFC-3314]Wasserman，M.，编辑，“第三代合作伙伴关系项目（3GPP）标准中IPv6的建议”，RFC 3314，2002年9月。
[RFC-3481] Inamura, H., Montenegro, G., Ludwig, R., Gurtov, A. and F. Khafizov, "TCP over Second (2.5G) and Third (3G) Generation Wireless Networks", BCP 71, RFC 3481, February 2003.
[RFC-3481]Inamura，H.，黑山，G.，路德维希，R.，Gurtov，A.和F.Khafizov，“第二代（2.5G）和第三代（3G）无线网络上的TCP”，BCP 71，RFC 3481，2003年2月。
[UMTS-AKA] 3GPP Technical Specification 3GPP TS 33.102, "Technical Specification Group Services and System Aspects; 3G Security; Security Architecture (Release 4)", 3rd Generation Partnership Project, December 2001.
[UMTS-AKA]3GPP技术规范3GPP TS 33.102，“技术规范组服务和系统方面；3G安全；安全架构（版本4）”，第三代合作伙伴项目，2001年12月。
This document is 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.
本文件基于一个团队的结果，该团队除作者外还包括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 at the IPv6 WG mailing list for their comments and input.
作者要感谢IPv6工作组邮件列表中的Jim Bond、Brian Carpenter、Steve Deering、Bob Hinden、Keith Moore、Thomas Narten、Erik Nordmark、Michael Thomas、Margaret Wasserman和其他人的评论和意见。
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在编写本文件过程中提出的意见和投入。
Appendix A - Cellular Host IPv6 Addressing in the 3GPP Model
附录A-3GPP型号中的蜂窝主机IPv6寻址
The appendix aims to very briefly describe the 3GPP IPv6 addressing model for 2G (GPRS) and 3G (UMTS) cellular networks from Release 99 onwards. More information can be found from 3GPP Technical Specification 23.060.
本附录旨在非常简要地描述从第99版起针对2G（GPRS）和3G（UMTS）蜂窝网络的3GPP IPv6寻址模型。更多信息可从3GPP技术规范23.060中找到。
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 autoconfiguration procedure does not need any external entity involved in the address autoconfiguration (apart from the GGSN).
有两种可能为IPv6节点分配地址：无状态和有状态自动配置。有状态地址分配机制需要DHCP服务器为IPv6节点分配地址。另一方面，无状态自动配置过程不需要地址自动配置中涉及的任何外部实体（除了GGSN）。
In order to support the standard IPv6 stateless address autoconfiguration mechanism, as recommended by the IETF, the GGSN shall assign a prefix that is unique within its scope to each primary PDP context that uses IPv6 stateless address autoconfiguration. This avoids the necessity to perform Duplicate Address Detection at the network level for every address built by the mobile host. The GGSN always provides an Interface Identifier to the mobile host. The Mobile host uses the interface identifier provided by the GGSN to generate its link-local address. The GGSN provides the cellular host with the interface identifier, usually in a random manner. It must ensure the uniqueness of such identifier on the link (i.e., no collisions between its own link-local address and the cellular host's).
为了支持IETF建议的标准IPv6无状态地址自动配置机制，GGSN应为使用IPv6无状态地址自动配置的每个主PDP上下文分配一个在其范围内唯一的前缀。这避免了对移动主机构建的每个地址在网络级别执行重复地址检测的必要性。GGSN始终向移动主机提供接口标识符。移动主机使用GGSN提供的接口标识符来生成其链路本地地址。GGSN通常以随机方式向蜂窝主机提供接口标识符。它必须确保这种标识符在链路上的唯一性（即，它自己的链路本地地址和蜂窝主机的本地地址之间没有冲突）。
In addition, the GGSN 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 is allocated a unique prefix, will eliminate the need for DAD messages over the air interface, and consequently allows an efficient use of bandwidth. Furthermore, the allocation of a prefix to each PDP context will allow hosts to implement the privacy extensions in RFC 3041 without the need for further DAD messages.
此外，GGSN不会使用分配给蜂窝主机的任何前缀来生成其自己的任何地址。这种接口标识符的使用，再加上每个PDP上下文都分配了一个唯一前缀的事实，将消除空中接口上对DAD消息的需要，从而允许有效地使用带宽。此外，为每个PDP上下文分配前缀将允许主机实现RFC 3041中的隐私扩展，而无需进一步的DAD消息。
Authors' Addresses
作者地址
Jari Arkko Ericsson 02420 Jorvas Finland
雅丽阿尔科爱立信02420 Jorvas芬兰
EMail: jari.arkko@ericsson.com
EMail: jari.arkko@ericsson.com
Gerben Kuijpers Ericsson Skanderborgvej 232 DK-8260 Viby J Denmark
Gerben Kuijpers Ericsson Skanderborgvej 232 DK-8260 Viby J丹麦
EMail: gerben.a.kuijpers@ted.ericsson.se
EMail: gerben.a.kuijpers@ted.ericsson.se
John Loughney Nokia Research Center Itamerenkatu 11 - 13 FIN-00180 HELSINKI Finland
John Loughney诺基亚研究中心Itamerenkatu 11-13 FIN-00180芬兰赫尔辛基
EMail: john.loughney@nokia.com
EMail: john.loughney@nokia.com
Hesham Soliman Ericsson Radio Systems AB Torshamnsgatan 23, Kista, Stockholm Sweden
Hesham Soliman Ericsson Radio Systems AB Torshamnsgatan 23，瑞典斯德哥尔摩基斯塔
EMail: hesham.soliman@era.ericsson.se
EMail: hesham.soliman@era.ericsson.se
Juha Wiljakka Nokia Mobile Phones Sinitaival 5 FIN-33720 TAMPERE Finland
Juha Wiljakka诺基亚手机Sinitaival 5 FIN-33720坦佩雷芬兰
EMail: juha.wiljakka@nokia.com
EMail: juha.wiljakka@nokia.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。