Internet Engineering Task Force (IETF) E. Jankiewicz
Request for Comments: 6434 SRI International, Inc.
Obsoletes: 4294 J. Loughney
Category: Informational Nokia
ISSN: 2070-1721 T. Narten
IBM Corporation
December 2011
Internet Engineering Task Force (IETF) E. Jankiewicz
Request for Comments: 6434 SRI International, Inc.
Obsoletes: 4294 J. Loughney
Category: Informational Nokia
ISSN: 2070-1721 T. Narten
IBM Corporation
December 2011
IPv6 Node Requirements
IPv6节点要求
Abstract
摘要
This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments.
本文档定义了IPv6节点的要求。预计IPv6将在各种设备和情况下部署。通过指定IPv6节点的要求，IPv6可以在大量情况和部署中正常运行和互操作。
This document obsoletes RFC 4294.
本文件淘汰了RFC 4294。
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/rfc6434.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6434.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从该文档中提取的代码组件必须
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.
包括信托法律条款第4.e节中所述的简化BSD许可证文本，且不提供简化BSD许可证中所述的担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Scope of This Document . . . . . . . . . . . . . . . . . . 5
1.2. Description of IPv6 Nodes . . . . . . . . . . . . . . . . 5
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Abbreviations Used in This Document . . . . . . . . . . . . . 5
4. Sub-IP Layer . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. IP Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Internet Protocol Version 6 - RFC 2460 . . . . . . . . . . 7
5.2. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . . . 8
5.3. Default Router Preferences and More-Specific Routes -
RFC 4191 . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.4. SEcure Neighbor Discovery (SEND) - RFC 3971 . . . . . . . 9
5.5. IPv6 Router Advertisement Flags Option - RFC 5175 . . . . 9
5.6. Path MTU Discovery and Packet Size . . . . . . . . . . . . 10
5.6.1. Path MTU Discovery - RFC 1981 . . . . . . . . . . . . 10
5.7. IPv6 Jumbograms - RFC 2675 . . . . . . . . . . . . . . . . 10
5.8. ICMP for the Internet Protocol Version 6 (IPv6) - RFC
4443 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.9. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 11
5.9.1. IP Version 6 Addressing Architecture - RFC 4291 . . . 11
5.9.2. IPv6 Stateless Address Autoconfiguration - RFC 4862 . 11
5.9.3. Privacy Extensions for Address Configuration in
IPv6 - RFC 4941 . . . . . . . . . . . . . . . . . . . 12
5.9.4. Default Address Selection for IPv6 - RFC 3484 . . . . 12
5.9.5. Stateful Address Autoconfiguration (DHCPv6) - RFC
3315 . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.10. Multicast Listener Discovery (MLD) for IPv6 . . . . . . . 13
6. DHCP versus Router Advertisement Options for Host
Configuration . . . . . . . . . . . . . . . . . . . . . . . . 13
7. DNS and DHCP . . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Scope of This Document . . . . . . . . . . . . . . . . . . 5
1.2. Description of IPv6 Nodes . . . . . . . . . . . . . . . . 5
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Abbreviations Used in This Document . . . . . . . . . . . . . 5
4. Sub-IP Layer . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. IP Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Internet Protocol Version 6 - RFC 2460 . . . . . . . . . . 7
5.2. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . . . 8
5.3. Default Router Preferences and More-Specific Routes -
RFC 4191 . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.4. SEcure Neighbor Discovery (SEND) - RFC 3971 . . . . . . . 9
5.5. IPv6 Router Advertisement Flags Option - RFC 5175 . . . . 9
5.6. Path MTU Discovery and Packet Size . . . . . . . . . . . . 10
5.6.1. Path MTU Discovery - RFC 1981 . . . . . . . . . . . . 10
5.7. IPv6 Jumbograms - RFC 2675 . . . . . . . . . . . . . . . . 10
5.8. ICMP for the Internet Protocol Version 6 (IPv6) - RFC
4443 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.9. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 11
5.9.1. IP Version 6 Addressing Architecture - RFC 4291 . . . 11
5.9.2. IPv6 Stateless Address Autoconfiguration - RFC 4862 . 11
5.9.3. Privacy Extensions for Address Configuration in
IPv6 - RFC 4941 . . . . . . . . . . . . . . . . . . . 12
5.9.4. Default Address Selection for IPv6 - RFC 3484 . . . . 12
5.9.5. Stateful Address Autoconfiguration (DHCPv6) - RFC
3315 . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.10. Multicast Listener Discovery (MLD) for IPv6 . . . . . . . 13
6. DHCP versus Router Advertisement Options for Host
Configuration . . . . . . . . . . . . . . . . . . . . . . . . 13
7. DNS and DHCP . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.2. Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
- RFC 3315 . . . . . . . . . . . . . . . . . . . . . . . . 15
7.2.1. Other Configuration Information . . . . . . . . . . . 15
7.2.2. Use of Router Advertisements in Managed
Environments . . . . . . . . . . . . . . . . . . . . . 15
7.3. IPv6 Router Advertisement Options for DNS
Configuration - RFC 6106 . . . . . . . . . . . . . . . . . 15
8. IPv4 Support and Transition . . . . . . . . . . . . . . . . . 16
8.1. Transition Mechanisms . . . . . . . . . . . . . . . . . . 16
8.1.1. Basic Transition Mechanisms for IPv6 Hosts and
Routers - RFC 4213 . . . . . . . . . . . . . . . . . . 16
9. Application Support . . . . . . . . . . . . . . . . . . . . . 16
9.1. Textual Representation of IPv6 Addresses - RFC 5952 . . . 16
9.2. Application Programming Interfaces (APIs) . . . . . . . . 16
10. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 18
11.2. Transforms and Algorithms . . . . . . . . . . . . . . . . 19
12. Router-Specific Functionality . . . . . . . . . . . . . . . . 19
12.1. IPv6 Router Alert Option - RFC 2711 . . . . . . . . . . . 19
12.2. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . . . 19
12.3. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315 . . 19
13. Network Management . . . . . . . . . . . . . . . . . . . . . . 20
13.1. Management Information Base (MIB) Modules . . . . . . . . 20
13.1.1. IP Forwarding Table MIB . . . . . . . . . . . . . . . 20
13.1.2. Management Information Base for the Internet
Protocol (IP) . . . . . . . . . . . . . . . . . . . . 20
14. Security Considerations . . . . . . . . . . . . . . . . . . . 20
15. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 21
15.1. Authors and Acknowledgments (Current Document) . . . . . . 21
15.2. Authors and Acknowledgments from RFC 4279 . . . . . . . . 21
16. Appendix: Changes from RFC 4294 . . . . . . . . . . . . . . . 22
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
17.1. Normative References . . . . . . . . . . . . . . . . . . . 23
17.2. Informative References . . . . . . . . . . . . . . . . . . 26
7.1. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.2. Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
- RFC 3315 . . . . . . . . . . . . . . . . . . . . . . . . 15
7.2.1. Other Configuration Information . . . . . . . . . . . 15
7.2.2. Use of Router Advertisements in Managed
Environments . . . . . . . . . . . . . . . . . . . . . 15
7.3. IPv6 Router Advertisement Options for DNS
Configuration - RFC 6106 . . . . . . . . . . . . . . . . . 15
8. IPv4 Support and Transition . . . . . . . . . . . . . . . . . 16
8.1. Transition Mechanisms . . . . . . . . . . . . . . . . . . 16
8.1.1. Basic Transition Mechanisms for IPv6 Hosts and
Routers - RFC 4213 . . . . . . . . . . . . . . . . . . 16
9. Application Support . . . . . . . . . . . . . . . . . . . . . 16
9.1. Textual Representation of IPv6 Addresses - RFC 5952 . . . 16
9.2. Application Programming Interfaces (APIs) . . . . . . . . 16
10. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 18
11.2. Transforms and Algorithms . . . . . . . . . . . . . . . . 19
12. Router-Specific Functionality . . . . . . . . . . . . . . . . 19
12.1. IPv6 Router Alert Option - RFC 2711 . . . . . . . . . . . 19
12.2. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . . . 19
12.3. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315 . . 19
13. Network Management . . . . . . . . . . . . . . . . . . . . . . 20
13.1. Management Information Base (MIB) Modules . . . . . . . . 20
13.1.1. IP Forwarding Table MIB . . . . . . . . . . . . . . . 20
13.1.2. Management Information Base for the Internet
Protocol (IP) . . . . . . . . . . . . . . . . . . . . 20
14. Security Considerations . . . . . . . . . . . . . . . . . . . 20
15. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 21
15.1. Authors and Acknowledgments (Current Document) . . . . . . 21
15.2. Authors and Acknowledgments from RFC 4279 . . . . . . . . 21
16. Appendix: Changes from RFC 4294 . . . . . . . . . . . . . . . 22
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
17.1. Normative References . . . . . . . . . . . . . . . . . . . 23
17.2. Informative References . . . . . . . . . . . . . . . . . . 26
This document defines common functionality required from both IPv6 hosts and routers. Many IPv6 nodes will implement optional or additional features, but this document collects and summarizes requirements from other published Standards Track documents in one place.
本文档定义了IPv6主机和路由器所需的通用功能。许多IPv6节点将实现可选或附加功能，但本文档将从一个地方的其他已发布标准跟踪文档中收集和总结需求。
This document tries to avoid discussion of protocol details and references RFCs for this purpose. This document is intended to be an applicability statement and to provide guidance as to which IPv6 specifications should be implemented in the general case and which specifications may be of interest to specific deployment scenarios. This document does not update any individual protocol document RFCs.
本文件试图避免讨论协议细节和参考RFC。本文档旨在作为适用性声明，并就一般情况下应实施哪些IPv6规范以及特定部署场景可能感兴趣的规范提供指导。本文件不更新任何单独的协议文件RFC。
Although this document points to different specifications, it should be noted that in many cases, the granularity of a particular requirement will be smaller than a single specification, as many specifications define multiple, independent pieces, some of which may not be mandatory. In addition, most specifications define both client and server behavior in the same specification, while many implementations will be focused on only one of those roles.
尽管本文件指向不同的规范，但应注意，在许多情况下，特定需求的粒度将小于单个规范，因为许多规范定义了多个独立的部分，其中一些可能不是强制性的。此外，大多数规范在同一规范中定义了客户机和服务器行为，而许多实现只关注其中一个角色。
This document defines a minimal level of requirement needed for a device to provide useful internet service and considers a broad range of device types and deployment scenarios. Because of the wide range of deployment scenarios, the minimal requirements specified in this document may not be sufficient for all deployment scenarios. It is perfectly reasonable (and indeed expected) for other profiles to define additional or stricter requirements appropriate for specific usage and deployment environments. For example, this document does not mandate that all clients support DHCP, but some deployment scenarios may deem it appropriate to make such a requirement. For example, government agencies in the USA have defined profiles for specialized requirements for IPv6 in target environments (see [DODv6] and [USGv6]).
本文档定义了设备提供有用互联网服务所需的最低要求，并考虑了广泛的设备类型和部署场景。由于部署场景范围广泛，本文档中指定的最低要求可能不足以满足所有部署场景。对于其他概要文件来说，定义适用于特定使用和部署环境的附加或更严格的要求是完全合理的（事实上也是预期的）。例如，本文档并不强制要求所有客户端都支持DHCP，但某些部署场景可能认为提出这样的要求是合适的。例如，美国政府机构为目标环境中IPv6的特殊要求定义了配置文件（请参见[DODv6]和[USGv6]）。
As it is not always possible for an implementer to know the exact usage of IPv6 in a node, an overriding requirement for IPv6 nodes is that they should adhere to Jon Postel's Robustness Principle: "Be conservative in what you do, be liberal in what you accept from others" [RFC0793].
由于实施者并不总是可能知道IPv6在节点中的确切用法，因此IPv6节点的首要要求是，它们应该遵守Jon Postel的健壮性原则：“做事要保守，接受别人的意见要自由”[RFC0793]。
IPv6 covers many specifications. It is intended that IPv6 will be deployed in many different situations and environments. Therefore, it is important to develop requirements for IPv6 nodes to ensure interoperability.
IPv6涵盖了许多规范。IPv6将被部署在许多不同的情况和环境中。因此，制定IPv6节点需求以确保互操作性非常重要。
This document assumes that all IPv6 nodes meet the minimum requirements specified here.
本文档假设所有IPv6节点都满足此处指定的最低要求。
From the Internet Protocol, Version 6 (IPv6) Specification [RFC2460], we have the following definitions:
根据互联网协议第6版（IPv6）规范[RFC2460]，我们有以下定义：
IPv6 node - a device that implements IPv6.
IPv6节点—实现IPv6的设备。
IPv6 router - a node that forwards IPv6 packets not explicitly addressed to itself.
IPv6路由器-转发未显式寻址到自身的IPv6数据包的节点。
IPv6 host - any node that is not a router.
IPv6主机-不是路由器的任何节点。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
ATM Asynchronous Transfer Mode
异步传输模式
AH Authentication Header
AH认证头
DAD Duplicate Address Detection
重复地址检测
ESP Encapsulating Security Payload
封装安全有效载荷的ESP
ICMP Internet Control Message Protocol
网际控制信息协议
IKE Internet Key Exchange
因特网密钥交换
MIB Management Information Base
MIB管理信息库
MLD Multicast Listener Discovery
多播侦听器发现
MTU Maximum Transmission Unit
最大传输单元
NA Neighbor Advertisement
邻居广告
NBMA Non-Broadcast Multiple Access
非广播多址
ND Neighbor Discovery
第二邻居发现
NS Neighbor Solicitation
邻居邀请
NUD Neighbor Unreachability Detection
NUD邻居不可达性检测
PPP Point-to-Point Protocol
点对点协议
An IPv6 node must include support for one or more IPv6 link-layer specifications. Which link-layer specifications an implementation should include will depend upon what link-layers are supported by the hardware available on the system. It is possible for a conformant IPv6 node to support IPv6 on some of its interfaces and not on others.
IPv6节点必须支持一个或多个IPv6链路层规范。实现应包括哪些链路层规范将取决于系统上可用硬件支持哪些链路层。一致性IPv6节点可以在其某些接口上而不是在其他接口上支持IPv6。
As IPv6 is run over new layer 2 technologies, it is expected that new specifications will be issued. In the following, we list some of the layer 2 technologies for which an IPv6 specification has been developed. It is provided for informational purposes only and may not be complete.
由于IPv6在新的第2层技术上运行，预计将发布新的规范。在下文中，我们列出了一些已经制定了IPv6规范的第2层技术。本文件仅供参考，可能不完整。
- Transmission of IPv6 Packets over Ethernet Networks [RFC2464]
- 通过以太网传输IPv6数据包[RFC2464]
- IPv6 over ATM Networks [RFC2492]
- ATM网络上的IPv6[RFC2492]
- Transmission of IPv6 Packets over Frame Relay Networks Specification [RFC2590]
- 通过帧中继网络传输IPv6数据包规范[RFC2590]
- Transmission of IPv6 Packets over IEEE 1394 Networks [RFC3146]
- 通过IEEE 1394网络传输IPv6数据包[RFC3146]
- Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) Packets over Fibre Channel [RFC4338]
- 通过光纤通道传输IPv6、IPv4和地址解析协议（ARP）数据包[RFC4338]
- Transmission of IPv6 Packets over IEEE 802.15.4 Networks [RFC4944]
- 通过IEEE 802.15.4网络传输IPv6数据包[RFC4944]
- Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks [RFC5121]
- 通过IEEE 802.16网络上的IPv6汇聚子层传输IPv6[RFC5121]
- IP version 6 over PPP [RFC5072]
- PPP上的IP版本6[RFC5072]
In addition to traditional physical link-layers, it is also possible to tunnel IPv6 over other protocols. Examples include:
除了传统的物理链路层之外，还可以通过其他协议对IPv6进行隧道传输。例子包括：
- Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs) [RFC4380]
- Teredo：通过网络地址转换（NAT）在UDP上隧道IPv6[RFC4380]
- Section 3 of "Basic Transition Mechanisms for IPv6 Hosts and Routers" [RFC4213]
- “IPv6主机和路由器的基本转换机制”第3节[RFC4213]
The Internet Protocol Version 6 is specified in [RFC2460]. This specification MUST be supported.
[RFC2460]中规定了互联网协议版本6。必须支持此规范。
Any unrecognized extension headers or options MUST be processed as described in RFC 2460.
必须按照RFC 2460中的说明处理任何无法识别的扩展标题或选项。
The node MUST follow the packet transmission rules in RFC 2460.
节点必须遵循RFC 2460中的数据包传输规则。
Nodes MUST always be able to send, receive, and process fragment headers. All conformant IPv6 implementations MUST be capable of sending and receiving IPv6 packets; the forwarding functionality MAY be supported. Overlapping fragments MUST be handled as described in [RFC5722].
节点必须始终能够发送、接收和处理片段头。所有一致的IPv6实现必须能够发送和接收IPv6数据包；可能支持转发功能。重叠片段必须按照[RFC5722]中所述进行处理。
RFC 2460 specifies extension headers and the processing for these headers.
RFC2460指定扩展头和对这些头的处理。
An IPv6 node MUST be able to process these headers. An exception is Routing Header type 0 (RH0), which was deprecated by [RFC5095] due to security concerns and which MUST be treated as an unrecognized routing type.
IPv6节点必须能够处理这些标头。路由头类型0（RH0）是一个例外，出于安全考虑，[RFC5095]不推荐该类型，必须将其视为无法识别的路由类型。
All nodes SHOULD support the setting and use of the IPv6 Flow Label field as defined in the IPv6 Flow Label specification [RFC6437]. Forwarding nodes such as routers and load distributors MUST NOT depend only on Flow Label values being uniformly distributed. It is RECOMMENDED that source hosts support the flow label by setting the Flow Label field for all packets of a given flow to the same value chosen from an approximation to a discrete uniform distribution.
所有节点都应支持IPv6流标签规范[RFC6437]中定义的IPv6流标签字段的设置和使用。转发节点（如路由器和负载分配器）不能仅依赖于均匀分布的流标签值。建议源主机通过将给定流的所有数据包的流标签字段设置为从离散均匀分布近似值中选择的相同值来支持流标签。
Neighbor Discovery is defined in [RFC4861]; the definition was updated by [RFC5942]. Neighbor Discovery SHOULD be supported. RFC 4861 states:
[RFC4861]中定义了邻居发现；定义由[RFC5942]更新。应支持邻居发现。RFC 4861指出：
Unless specified otherwise (in a document that covers operating IP over a particular link type) this document applies to all link types. However, because ND uses link-layer multicast for some of its services, it is possible that on some link types (e.g., Non-Broadcast Multi-Access (NBMA) links), alternative protocols or mechanisms to implement those services will be specified (in the appropriate document covering the operation of IP over a particular link type). The services described in this document that are not directly dependent on multicast, such as Redirects, next-hop determination, Neighbor Unreachability Detection, etc., are expected to be provided as specified in this document. The details of how one uses ND on NBMA links are addressed in [RFC2491].
除非另有规定（在涉及特定链路类型上的操作IP的文件中），否则本文件适用于所有链路类型。然而，由于ND对其某些服务使用链路层多播，因此在某些链路类型（例如，非广播多址（NBMA）链路）上，可能会指定实现这些服务的替代协议或机制（在涵盖特定链路类型上的IP操作的适当文档中）。本文档中描述的不直接依赖于多播的服务，例如重定向、下一跳确定、邻居不可达性检测等，预期将按照本文档中的规定提供。关于如何在NBMA链路上使用ND的详细信息，请参见[RFC2491]。
Some detailed analysis of Neighbor Discovery follows:
邻居发现的一些详细分析如下：
Router Discovery is how hosts locate routers that reside on an attached link. Hosts MUST support Router Discovery functionality.
路由器发现是主机如何定位驻留在连接链路上的路由器。主机必须支持路由器发现功能。
Prefix Discovery is how hosts discover the set of address prefixes that define which destinations are on-link for an attached link. Hosts MUST support Prefix Discovery.
前缀发现是主机如何发现一组地址前缀，这些地址前缀定义了连接的链路上的目的地。主机必须支持前缀发现。
Hosts MUST also implement Neighbor Unreachability Detection (NUD) for all paths between hosts and neighboring nodes. NUD is not required for paths between routers. However, all nodes MUST respond to unicast Neighbor Solicitation (NS) messages.
主机还必须对主机和相邻节点之间的所有路径实施邻居不可达性检测（NUD）。路由器之间的路径不需要NUD。但是，所有节点都必须响应单播邻居请求（NS）消息。
Hosts MUST support the sending of Router Solicitations and the receiving of Router Advertisements. The ability to understand individual Router Advertisement options is dependent on supporting the functionality making use of the particular option.
主机必须支持发送路由器请求和接收路由器广告。理解单个路由器广告选项的能力取决于支持使用特定选项的功能。
All nodes MUST support the sending and receiving of Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages. NS and NA messages are required for Duplicate Address Detection (DAD).
所有节点必须支持邻居请求（NS）和邻居公告（NA）消息的发送和接收。重复地址检测（DAD）需要NS和NA消息。
Hosts SHOULD support the processing of Redirect functionality. Routers MUST support the sending of Redirects, though not necessarily for every individual packet (e.g., due to rate limiting). Redirects are only useful on networks supporting hosts. In core networks dominated by routers, Redirects are typically disabled. The sending
主机应支持重定向功能的处理。路由器必须支持发送重定向，但不一定针对每个数据包（例如，由于速率限制）。重定向仅在支持主机的网络上有用。在由路由器主导的核心网络中，重定向通常被禁用。派遣
of Redirects SHOULD be disabled by default on backbone routers. They MAY be enabled by default on routers intended to support hosts on edge networks.
在主干路由器上，默认情况下应禁用重定向。默认情况下，它们可以在用于支持边缘网络上主机的路由器上启用。
"IPv6 Host-to-Router Load Sharing" [RFC4311] includes additional recommendations on how to select from a set of available routers. [RFC4311] SHOULD be supported.
“IPv6主机到路由器负载共享”[RFC4311]包括关于如何从一组可用路由器中进行选择的其他建议。应支持[RFC4311]。
"Default Router Preferences and More-Specific Routes" [RFC4191] provides support for nodes attached to multiple (different) networks, each providing routers that advertise themselves as default routers via Router Advertisements. In some scenarios, one router may provide connectivity to destinations the other router does not, and choosing the "wrong" default router can result in reachability failures. In such cases, RFC 4191 can help.
“默认路由器首选项和更具体的路由”[RFC4191]为连接到多个（不同）网络的节点提供支持，每个节点都提供通过路由器广告作为默认路由器进行广告的路由器。在某些情况下，一个路由器可能提供到另一个路由器不提供的目的地的连接，并且选择“错误”的默认路由器可能导致可达性故障。在这种情况下，RFC4191可以提供帮助。
Small Office/Home Office (SOHO) deployments supported by routers adhering to [RFC6204] use RFC 4191 to advertise routes to certain local destinations. Consequently, nodes that will be deployed in SOHO environments SHOULD implement RFC 4191.
由遵守[RFC6204]的路由器支持的小型办公室/家庭办公室（SOHO）部署使用RFC 4191公布到某些本地目的地的路由。因此，将部署在SOHO环境中的节点应实现RFC4191。
SEND [RFC3971] and Cryptographically Generated Address (CGA) [RFC3972] provide a way to secure the message exchanges of Neighbor Discovery. SEND is a new technology in that it has no IPv4 counterpart, but it has significant potential to address certain classes of spoofing attacks. While there have been some implementations of SEND, there has been only limited deployment experience to date in using the technology. In addition, the IETF working group Cga & Send maIntenance (csi) is currently working on additional extensions intended to make SEND more attractive for deployment.
SEND[RFC3971]和加密生成地址（CGA）[RFC3972]提供了一种保护邻居发现的消息交换的方法。SEND是一种新技术，因为它没有IPv4对应物，但它在解决某些类型的欺骗攻击方面具有巨大的潜力。虽然已经有一些SEND的实现，但迄今为止在使用该技术方面只有有限的部署经验。此外，IETF工作组Cga&Send maIntenance（csi）目前正在进行额外的扩展，旨在使Send对部署更具吸引力。
At this time, SEND is considered optional, and IPv6 nodes MAY provide SEND functionality.
此时，发送被认为是可选的，IPv6节点可以提供发送功能。
Router Advertisements include an 8-bit field of single-bit Router Advertisement flags. The Router Advertisement Flags Option extends the number of available flag bits by 48 bits. At the time of this writing, 6 of the original 8 single-bit flags have been assigned, while 2 remain available for future assignment. No flags have been defined that make use of the new option, and thus, strictly speaking, there is no requirement to implement the option today. However,
路由器广告包括一个8位的单位路由器广告标志字段。路由器广告标志选项将可用标志位的数量扩展48位。在撰写本文时，原始8个单位标志中的6个已分配，而2个仍可用于将来的分配。没有定义使用新选项的标志，因此，严格地说，目前没有实施该选项的要求。然而
implementations that are able to pass unrecognized options to a higher-level entity that may be able to understand them (e.g., a user-level process using a "raw socket" facility) MAY take steps to handle the option in anticipation of a future usage.
能够将无法识别的选项传递给能够理解它们的更高级别实体（例如，使用“原始套接字”功能的用户级进程）的实现可能会采取步骤来处理该选项，以预测未来的使用情况。
"Path MTU Discovery for IP version 6" [RFC1981] SHOULD be supported. From [RFC2460]:
应支持“IP版本6的路径MTU发现”[RFC1981]。从[RFC2460]：
It is strongly recommended that IPv6 nodes implement Path MTU Discovery [RFC1981], in order to discover and take advantage of path MTUs greater than 1280 octets. However, 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节点实现路径MTU发现[RFC1981]，以便发现并利用大于1280个八位字节的路径MTU。然而，最小IPv6实现（例如，在引导ROM中）可能仅限于发送不大于1280个八位字节的数据包，而忽略路径MTU发现的实现。
The rules in [RFC2460] and [RFC5722] MUST be followed for packet fragmentation and reassembly.
必须遵循[RFC2460]和[RFC5722]中的规则进行数据包分段和重新组装。
One operational issue with Path MTU Discovery occurs when firewalls block ICMP Packet Too Big messages. Path MTU Discovery relies on such messages to determine what size messages can be successfully sent. "Packetization Layer Path MTU Discovery" [RFC4821] avoids having a dependency on Packet Too Big messages.
当防火墙阻止ICMP数据包过大消息时，路径MTU发现会出现一个操作问题。路径MTU发现依赖于此类消息来确定可以成功发送的消息大小。“分组化层路径MTU发现”[RFC4821]避免了对数据包过大消息的依赖。
IPv6 Jumbograms [RFC2675] are an optional extension that allow the sending of IP datagrams larger than 65.535 bytes. IPv6 Jumbograms make use of IPv6 hop-by-hop options and are only suitable on paths in which every hop and link are capable of supporting Jumbograms (e.g., within a campus or datacenter). To date, few implementations exist, and there is essentially no reported experience from usage.
IPv6巨型程序[RFC2675]是一个可选扩展，允许发送大于65.535字节的IP数据报。IPv6巨型程序使用IPv6逐跳选项，仅适用于每个跃点和链路都能够支持巨型程序的路径（例如，在校园或数据中心内）。到目前为止，几乎没有实现，而且基本上没有报告使用经验。
Consequently, IPv6 Jumbograms [RFC2675] remain optional at this time.
因此，IPv6巨型程序[RFC2675]此时仍然是可选的。
ICMPv6 [RFC4443] MUST be supported. "Extended ICMP to Support Multi-Part Messages" [RFC4884] MAY be supported.
必须支持ICMPv6[RFC4443]。可能支持“支持多部分消息的扩展ICMP”[RFC4884]。
The IPv6 Addressing Architecture [RFC4291] MUST be supported.
必须支持IPv6寻址体系结构[RFC4291]。
Hosts MUST support IPv6 Stateless Address Autoconfiguration as defined in [RFC4862]. Configuration of static address(es) may be supported as well.
主机必须支持[RFC4862]中定义的IPv6无状态地址自动配置。也可以支持静态地址的配置。
Nodes that are routers MUST be able to generate link-local addresses as described in [RFC4862].
作为路由器的节点必须能够生成[RFC4862]中所述的链路本地地址。
From RFC 4862:
从RFC 4862：
The autoconfiguration process specified in this document applies only to hosts and not routers. Since host autoconfiguration uses information advertised by routers, routers will need to be configured by some other means. However, it is expected that routers will generate link-local addresses using the mechanism described in this document. In addition, routers are expected to successfully pass the Duplicate Address Detection procedure described in this document on all addresses prior to assigning them to an interface.
本文档中指定的自动配置过程仅适用于主机，而不适用于路由器。由于主机自动配置使用路由器公布的信息，因此需要通过其他方式配置路由器。然而，预计路由器将使用本文档中描述的机制生成链路本地地址。此外，在将路由器分配给接口之前，路由器应成功通过本文档中描述的所有地址的重复地址检测程序。
All nodes MUST implement Duplicate Address Detection. Quoting from Section 5.4 of RFC 4862:
所有节点都必须实现重复地址检测。引用RFC 4862第5.4节：
Duplicate Address Detection MUST be performed on all unicast addresses prior to assigning them to an interface, regardless of whether they are obtained through stateless autoconfiguration, DHCPv6, or manual configuration, with the following [exceptions noted therein].
在将所有单播地址分配给接口之前，必须对其执行重复地址检测，无论这些地址是通过无状态自动配置、DHCPv6还是手动配置获得的，但以下情况除外[此处注明的例外情况]。
"Optimistic Duplicate Address Detection (DAD) for IPv6" [RFC4429] specifies a mechanism to reduce delays associated with generating addresses via Stateless Address Autoconfiguration [RFC4862]. RFC 4429 was developed in conjunction with Mobile IPv6 in order to reduce the time needed to acquire and configure addresses as devices quickly move from one network to another, and it is desirable to minimize transition delays. For general purpose devices, RFC 4429 remains optional at this time.
“IPv6的乐观重复地址检测（DAD）”[RFC4429]指定了一种机制，用于减少与通过无状态地址自动配置生成地址相关的延迟[RFC4862]。RFC 4429是与移动IPv6一起开发的，目的是在设备从一个网络快速移动到另一个网络时，减少获取和配置地址所需的时间，并尽可能减少转换延迟。对于通用设备，RFC 4429此时仍然是可选的。
Privacy Extensions for Stateless Address Autoconfiguration [RFC4941] addresses a specific problem involving a client device whose user is concerned about its activity or location being tracked. The problem arises both for a static client and for one that regularly changes its point of attachment to the Internet. When using Stateless Address Autoconfiguration [RFC4862], the Interface Identifier portion of formed addresses stays constant and is globally unique. Thus, although a node's global IPv6 address will change if it changes its point of attachment, the Interface Identifier portion of those addresses remains the same, making it possible for servers to track the location of an individual device as it moves around or its pattern of activity if it remains in one place. This may raise privacy concerns as described in [RFC4862].
无状态地址自动配置的隐私扩展[RFC4941]解决了一个特定的问题，该问题涉及一个客户机设备，该设备的用户关心其被跟踪的活动或位置。对于静态客户端和定期更改其与Internet的连接点的客户端，都会出现此问题。使用无状态地址自动配置[RFC4862]时，形成的地址的接口标识符部分保持不变，并且全局唯一。因此，尽管节点的全局IPv6地址在其连接点发生变化时会发生变化，但这些地址的接口标识符部分保持不变，这使得服务器能够在单个设备移动时跟踪其位置，或者在其保持在一个位置时跟踪其活动模式。这可能会引起[RFC4862]中所述的隐私问题。
In such situations, RFC 4941 SHOULD be implemented. In other cases, such as with dedicated servers in a data center, RFC 4941 provides limited or no benefit.
在这种情况下，应实施RFC 4941。在其他情况下，例如数据中心中的专用服务器，RFC 4941提供的好处有限或没有。
Implementers of RFC 4941 should be aware that certain addresses are reserved and should not be chosen for use as temporary addresses. Consult "Reserved IPv6 Interface Identifiers" [RFC5453] for more details.
RFC4941的实现者应该知道某些地址是保留的，不应该被选为临时地址。有关更多详细信息，请参阅“保留IPv6接口标识符”[RFC5453]。
The rules specified in the Default Address Selection for IPv6 [RFC3484] document MUST be implemented. IPv6 nodes will need to deal with multiple addresses configured simultaneously.
必须执行IPv6[RFC3484]文档的默认地址选择中指定的规则。IPv6节点将需要处理同时配置的多个地址。
DHCPv6 [RFC3315] can be used to obtain and configure addresses. In general, a network may provide for the configuration of addresses through Router Advertisements, DHCPv6, or both. There will be a wide range of IPv6 deployment models and differences in address assignment requirements, some of which may require DHCPv6 for address assignment. Consequently, all hosts SHOULD implement address configuration via DHCPv6.
DHCPv6[RFC3315]可用于获取和配置地址。通常，网络可以通过路由器广告、DHCPv6或两者提供地址配置。IPv6部署模型范围广泛，地址分配要求也存在差异，其中一些可能需要DHCPv6进行地址分配。因此，所有主机都应该通过DHCPv6实现地址配置。
In the absence of a router, IPv6 nodes using DHCP for address assignment MAY initiate DHCP to obtain IPv6 addresses and other configuration information, as described in Section 5.5.2 of [RFC4862].
在没有路由器的情况下，使用DHCP进行地址分配的IPv6节点可以启动DHCP以获取IPv6地址和其他配置信息，如[RFC4862]第5.5.2节所述。
Nodes that need to join multicast groups MUST support MLDv1 [RFC2710]. MLDv1 is needed by any node that is expected to receive and process multicast traffic. Note that Neighbor Discovery (as used on most link types -- see Section 5.2) depends on multicast and requires that nodes join Solicited Node multicast addresses.
需要加入多播组的节点必须支持MLDv1[RFC2710]。任何预期接收和处理多播流量的节点都需要MLDv1。请注意，邻居发现（在大多数链路类型上使用——请参见第5.2节）依赖于多播，并要求节点加入请求的节点多播地址。
MLDv2 [RFC3810] extends the functionality of MLDv1 by supporting Source-Specific Multicast. The original MLDv2 protocol [RFC3810] supporting Source-Specific Multicast [RFC4607] supports two types of "filter modes". Using an INCLUDE filter, a node indicates a multicast group along with a list of senders for the group from which it wishes to receive traffic. Using an EXCLUDE filter, a node indicates a multicast group along with a list of senders from which it wishes to exclude receiving traffic. In practice, operations to block source(s) using EXCLUDE mode are rarely used but add considerable implementation complexity to MLDv2. Lightweight MLDv2 [RFC5790] is a simplified subset of the original MLDv2 specification that omits EXCLUDE filter mode to specify undesired source(s).
MLDv2[RFC3810]通过支持特定于源的多播扩展了MLDv1的功能。原始MLDv2协议[RFC3810]支持源特定多播[RFC4607]支持两种类型的“过滤模式”。使用包含筛选器，节点指示一个多播组以及它希望从中接收流量的组的发送者列表。使用排除筛选器，节点指示一个多播组以及它希望从中排除接收流量的发送方列表。实际上，很少使用使用排除模式阻止源的操作，但会给MLDv2增加相当大的实现复杂性。轻型MLDv2[RFC5790]是原始MLDv2规范的简化子集，它省略了排除过滤器模式以指定不需要的源。
Nodes SHOULD implement either MLDv2 [RFC3810] or Lightweight MLDv2 [RFC5790]. Specifically, nodes supporting applications using Source-Specific Multicast that expect to take advantage of MLDv2's EXCLUDE functionality [RFC3810] MUST support MLDv2 as defined in [RFC3810], [RFC4604], and [RFC4607]. Nodes supporting applications that expect to only take advantage of MLDv2's INCLUDE functionality as well as Any-Source Multicast will find it sufficient to support MLDv2 as defined in [RFC5790].
节点应实现MLDv2[RFC3810]或轻型MLDv2[RFC5790]。具体而言，支持使用源特定多播的应用程序的节点（期望利用MLDv2的排除功能[RFC3810]）必须支持[RFC3810]、[RFC4604]和[RFC4607]中定义的MLDv2。支持仅利用MLDv2 INCLUDE功能以及任何源多播的应用程序的节点将发现其足以支持[RFC5790]中定义的MLDv2。
If a node only supports applications that use Any-Source Multicast (i.e, they do not use Source-Specific Multicast), implementing MLDv1 [RFC2710] is sufficient. In all cases, however, nodes are strongly encouraged to implement MLDv2 or Lightweight MLDv2 rather than MLDv1, as the presence of a single MLDv1 participant on a link requires that all other nodes on the link operate in version 1 compatibility mode.
如果节点仅支持使用任何源多播的应用程序（即，它们不使用特定于源的多播），那么实现MLDv1[RFC2710]就足够了。然而，在所有情况下，强烈鼓励节点实现MLDv2或轻型MLDv2，而不是MLDv1，因为链路上存在单个MLDv1参与者要求链路上的所有其他节点在版本1兼容模式下运行。
When MLDv1 is used, the rules in the Source Address Selection for the Multicast Listener Discovery (MLD) Protocol [RFC3590] MUST be followed.
使用MLDv1时，必须遵循多播侦听器发现（MLD）协议[RFC3590]的源地址选择中的规则。
In IPv6, there are two main protocol mechanisms for propagating configuration information to hosts: Router Advertisements (RAs) and DHCP. Historically, RA options have been restricted to those deemed essential for basic network functioning and for which all nodes are configured with exactly the same information. Examples include the
在IPv6中，有两种主要的协议机制用于向主机传播配置信息：路由器广告（RAs）和DHCP。历史上，RA选项仅限于那些被认为对基本网络功能至关重要的选项，并且所有节点都配置了完全相同的信息。例子包括
Prefix Information Options, the MTU option, etc. On the other hand, DHCP has generally been preferred for configuration of more general parameters and for parameters that may be client-specific. That said, identifying the exact line on whether a particular option should be configured via DHCP versus an RA option has not always been easy. Generally speaking, however, there has been a desire to define only one mechanism for configuring a given option, rather than defining multiple (different) ways of configuring the same information.
前缀信息选项、MTU选项等。另一方面，DHCP通常优先用于配置更通用的参数和特定于客户端的参数。也就是说，确定是否应该通过DHCP配置特定选项与通过RA选项配置特定选项的确切界限并不总是那么容易。但是，一般来说，人们希望只定义一种配置给定选项的机制，而不是定义配置相同信息的多种（不同）方式。
One issue with having multiple ways of configuring the same information is that interoperability suffers if a host chooses one mechanism but the network operator chooses a different mechanism. For "closed" environments, where the network operator has significant influence over what devices connect to the network and thus what configuration mechanisms they support, the operator may be able to ensure that a particular mechanism is supported by all connected hosts. In more open environments, however, where arbitrary devices may connect (e.g., a WIFI hotspot), problems can arise. To maximize interoperability in such environments, hosts would need to implement multiple configuration mechanisms to ensure interoperability.
使用多种方式配置相同信息的一个问题是，如果主机选择一种机制，而网络运营商选择另一种机制，则互操作性会受到影响。对于“封闭”环境，网络运营商对连接到网络的设备以及它们支持的配置机制具有重大影响，运营商可以确保所有连接的主机都支持特定机制。但是，在更开放的环境中，任意设备可能连接（例如WIFI热点），可能会出现问题。为了最大限度地提高此类环境中的互操作性，主机需要实现多种配置机制以确保互操作性。
Originally, in IPv6, configuring information about DNS servers was performed exclusively via DHCP. In 2007, an RA option was defined but was published as Experimental [RFC5006]. In 2010, "IPv6 Router Advertisement Options for DNS Configuration" [RFC6106] was published as a Standards Track document. Consequently, DNS configuration information can now be learned either through DHCP or through RAs. Hosts will need to decide which mechanism (or whether both) should be implemented. Specific guidance regarding DNS server discovery is discussed in Section 7.
最初，在IPv6中，仅通过DHCP执行有关DNS服务器的配置信息。2007年，定义了RA选项，但发布为实验[RFC5006]。2010年，“用于DNS配置的IPv6路由器广告选项”[RFC6106]作为标准跟踪文件发布。因此，现在可以通过DHCP或RAs学习DNS配置信息。主机将需要决定应该实现哪种机制（或者两者都实现）。第7节讨论了有关DNS服务器发现的具体指导。
DNS is described in [RFC1034], [RFC1035], [RFC3363], and [RFC3596]. Not all nodes will need to resolve names; those that will never need to resolve DNS names do not need to implement resolver functionality. However, the ability to resolve names is a basic infrastructure capability on which applications rely, and most nodes will need to provide support. All nodes SHOULD implement stub-resolver [RFC1034] functionality, as in [RFC1034], Section 5.3.1, with support for:
DNS在[RFC1034]、[RFC1035]、[RFC3363]和[RFC3596]中进行了描述。并非所有节点都需要解析名称；那些永远不需要解析DNS名称的服务器不需要实现解析程序功能。但是，解析名称的能力是应用程序所依赖的一项基本基础设施能力，大多数节点都需要提供支持。所有节点应实现存根解析器[RFC1034]功能，如[RFC1034]第5.3.1节所述，并支持：
- AAAA type Resource Records [RFC3596];
- AAAA型资源记录[RFC3596]；
- reverse addressing in ip6.arpa using PTR records [RFC3596];
- ip6.arpa中使用PTR记录的反向寻址[RFC3596]；
- Extension Mechanisms for DNS (EDNS0) [RFC2671] to allow for DNS packet sizes larger than 512 octets.
- DNS（EDNS0）[RFC2671]的扩展机制，允许DNS数据包大小大于512个八位字节。
Those nodes are RECOMMENDED to support DNS security extensions [RFC4033] [RFC4034] [RFC4035].
建议这些节点支持DNS安全扩展[RFC4033][RFC4034][RFC4035]。
Those nodes are NOT RECOMMENDED to support the experimental A6 Resource Records [RFC3363].
不建议这些节点支持实验性A6资源记录[RFC3363]。
IPv6 nodes use DHCP [RFC3315] to obtain address configuration information (see Section 5.9.5) and to obtain additional (non-address) configuration. If a host implementation supports applications or other protocols that require configuration that is only available via DHCP, hosts SHOULD implement DHCP. For specialized devices on which no such configuration need is present, DHCP may not be necessary.
IPv6节点使用DHCP[RFC3315]获取地址配置信息（参见第5.9.5节）并获取附加（非地址）配置。如果主机实现支持需要仅通过DHCP进行配置的应用程序或其他协议，则主机应实现DHCP。对于不需要此类配置的专用设备，可能不需要DHCP。
An IPv6 node can use the subset of DHCP (described in [RFC3736]) to obtain other configuration information.
IPv6节点可以使用DHCP的子集（如[RFC3736]所述）来获取其他配置信息。
Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) are expected to determine their default router information and on-link prefix information from received Router Advertisements.
使用IPv6动态主机配置协议（DHCPv6）的节点需要从收到的路由器广告中确定其默认路由器信息和链路上前缀信息。
Router Advertisements have historically limited options to those that are critical to basic IPv6 functioning. Originally, DNS configuration was not included as an RA option, and DHCP was the recommended way to obtain DNS configuration information. Over time, the thinking surrounding such an option has evolved. It is now generally recognized that few nodes can function adequately without having access to a working DNS resolver. [RFC5006] was published as an Experimental document in 2007, and recently, a revised version was placed on the Standards Track [RFC6106].
路由器广告在历史上限制了对基本IPv6功能至关重要的选项。最初，DNS配置不包括在RA选项中，建议使用DHCP获取DNS配置信息。随着时间的推移，围绕这一选择的思维已经演变。现在人们普遍认为，很少有节点能够在没有访问工作DNS解析器的情况下充分发挥作用。[RFC5006]于2007年作为实验性文件发布，最近，修订版被纳入标准轨道[RFC6106]。
Implementations SHOULD implement the DNS RA option [RFC6106].
实现应实现DNS RA选项[RFC6106]。
IPv6 nodes MAY support IPv4.
IPv6节点可能支持IPv4。
8.1.1. Basic Transition Mechanisms for IPv6 Hosts and Routers - RFC 4213
8.1.1. IPv6主机和路由器的基本转换机制-RFC 4213
If an IPv6 node implements dual stack and tunneling, then [RFC4213] MUST be supported.
如果IPv6节点实现双堆栈和隧道，则必须支持[RFC4213]。
Software that allows users and operators to input IPv6 addresses in text form SHOULD support "A Recommendation for IPv6 Address Text Representation" [RFC5952].
允许用户和运营商以文本形式输入IPv6地址的软件应支持“IPv6地址文本表示建议”[RFC5952]。
There are a number of IPv6-related APIs. This document does not mandate the use of any, because the choice of API does not directly relate to on-the-wire behavior of protocols. Implementers, however, would be advised to consider providing a common API or reviewing existing APIs for the type of functionality they provide to applications.
有许多与IPv6相关的API。本文档不强制使用任何API，因为API的选择与协议的在线行为没有直接关系。然而，实施者将被建议考虑提供一个通用API或审查现有API以提供给应用程序的功能类型。
"Basic Socket Interface Extensions for IPv6" [RFC3493] provides IPv6 functionality used by typical applications. Implementers should note that RFC3493 has been picked up and further standardized by the Portable Operating System Interface (POSIX) [POSIX].
“IPv6基本套接字接口扩展”[RFC3493]提供典型应用程序使用的IPv6功能。实施者应该注意，RFC3493已经被便携式操作系统接口（POSIX）[POSIX]接受并进一步标准化。
"Advanced Sockets Application Program Interface (API) for IPv6" [RFC3542] provides access to advanced IPv6 features needed by diagnostic and other more specialized applications.
“用于IPv6的高级套接字应用程序编程接口（API）”[RFC3542]提供对诊断和其他更专业应用程序所需的高级IPv6功能的访问。
"IPv6 Socket API for Source Address Selection" [RFC5014] provides facilities that allow an application to override the default Source Address Selection rules of [RFC3484].
“用于源地址选择的IPv6套接字API”[RFC5014]提供了允许应用程序覆盖[RFC3484]的默认源地址选择规则的功能。
"Socket Interface Extensions for Multicast Source Filters" [RFC3678] provides support for expressing source filters on multicast group memberships.
“多播源筛选器的套接字接口扩展”[RFC3678]支持在多播组成员身份上表示源筛选器。
"Extension to Sockets API for Mobile IPv6" [RFC4584] provides application support for accessing and enabling Mobile IPv6 [RFC6275] features.
“移动IPv6套接字API扩展”[RFC4584]为访问和启用移动IPv6[RFC6275]功能提供应用程序支持。
Mobile IPv6 [RFC6275] and associated specifications [RFC3776] [RFC4877] allow a node to change its point of attachment within the Internet, while maintaining (and using) a permanent address. All communication using the permanent address continues to proceed as expected even as the node moves around. The definition of Mobile IP includes requirements for the following types of nodes:
移动IPv6[RFC6275]和相关规范[RFC3776][RFC4877]允许节点在保持（和使用）永久地址的同时更改其在Internet内的连接点。即使节点四处移动，使用永久地址的所有通信也会继续按预期进行。移动IP的定义包括对以下类型节点的要求：
- mobile nodes
- 移动节点
- correspondent nodes with support for route optimization
- 支持路由优化的对应节点
- home agents
- 国内代理
- all IPv6 routers
- 所有IPv6路由器
At the present time, Mobile IP has seen only limited implementation and no significant deployment, partly because it originally assumed an IPv6-only environment rather than a mixed IPv4/IPv6 Internet. Recently, additional work has been done to support mobility in mixed-mode IPv4 and IPv6 networks [RFC5555].
目前，移动IP的实施有限，部署也不重要，部分原因是它最初假定的环境仅为IPv6，而不是IPv4/IPv6混合互联网。最近，为支持混合模式IPv4和IPv6网络中的移动性做了额外的工作[RFC5555]。
More usage and deployment experience is needed with mobility before any specific approach can be recommended for broad implementation in all hosts and routers. Consequently, [RFC6275], [RFC5555], and associated standards such as [RFC4877] are considered a MAY at this time.
在建议在所有主机和路由器中广泛实施任何特定方法之前，需要更多的移动性使用和部署经验。因此，[RFC6275]、[RFC5555]和相关标准（如[RFC4877]）此时被视为可能。
This section describes the specification for security for IPv6 nodes.
本节介绍IPv6节点的安全规范。
Achieving security in practice is a complex undertaking. Operational procedures, protocols, key distribution mechanisms, certificate management approaches, etc., are all components that impact the level of security actually achieved in practice. More importantly, deficiencies or a poor fit in any one individual component can significantly reduce the overall effectiveness of a particular security approach.
在实践中实现安全是一项复杂的任务。操作过程、协议、密钥分发机制、证书管理方法等都是影响实际实现的安全级别的组件。更重要的是，任何单个组件中的缺陷或不匹配都会显著降低特定安全方法的总体有效性。
IPsec provides channel security at the Internet layer, making it possible to provide secure communication for all (or a subset of) communication flows at the IP layer between pairs of internet nodes. IPsec provides sufficient flexibility and granularity that individual TCP connections can (selectively) be protected, etc.
IPsec在Internet层提供通道安全性，使之能够在对Internet节点之间的IP层为所有（或部分）通信流提供安全通信。IPsec提供了足够的灵活性和粒度，可以（有选择地）保护单个TCP连接等。
Although IPsec can be used with manual keying in some cases, such usage has limited applicability and is not recommended.
虽然在某些情况下，IPsec可以与手动键控一起使用，但这种用法的适用性有限，不推荐使用。
A range of security technologies and approaches proliferate today (e.g., IPsec, Transport Layer Security (TLS), Secure SHell (SSH), etc.) No one approach has emerged as an ideal technology for all needs and environments. Moreover, IPsec is not viewed as the ideal security technology in all cases and is unlikely to displace the others.
如今，一系列安全技术和方法层出不穷（例如，IPsec、传输层安全（TLS）、Secure SHell（SSH）等）。没有一种方法能够成为满足所有需求和环境的理想技术。此外，IPsec并非在所有情况下都被视为理想的安全技术，也不太可能取代其他安全技术。
Previously, IPv6 mandated implementation of IPsec and recommended the key management approach of IKE. This document updates that recommendation by making support of the IPsec Architecture [RFC4301] a SHOULD for all IPv6 nodes. Note that the IPsec Architecture requires (e.g., Section 4.5 of RFC 4301) the implementation of both manual and automatic key management. Currently, the default automated key management protocol to implement is IKEv2 [RFC5996].
以前，IPv6强制实施IPsec，并推荐IKE的密钥管理方法。本文档更新了该建议，为所有IPv6节点提供IPsec体系结构[RFC4301]支持。请注意，IPsec体系结构要求（如RFC 4301第4.5节）实现手动和自动密钥管理。目前，要实现的默认自动密钥管理协议是IKEv2[RFC5996]。
This document recognizes that there exists a range of device types and environments where approaches to security other than IPsec can be justified. For example, special-purpose devices may support only a very limited number or type of applications, and an application-specific security approach may be sufficient for limited management or configuration capabilities. Alternatively, some devices may run on extremely constrained hardware (e.g., sensors) where the full IPsec Architecture is not justified.
本文档认识到存在一系列设备类型和环境，在这些设备类型和环境中，除IPsec之外的安全方法是合理的。例如，专用设备可能只支持数量或类型非常有限的应用程序，并且特定于应用程序的安全方法可能足以满足有限的管理或配置能力。或者，一些设备可能运行在极度受限的硬件（例如，传感器）上，其中完整的IPsec架构是不合理的。
"Security Architecture for the Internet Protocol" [RFC4301] SHOULD be supported by all IPv6 nodes. Note that the IPsec Architecture requires (e.g., Section 4.5 of [RFC4301]) the implementation of both manual and automatic key management. Currently, the default automated key management protocol to implement is IKEv2. As required in [RFC4301], IPv6 nodes implementing the IPsec Architecture MUST implement ESP [RFC4303] and MAY implement AH [RFC4302].
所有IPv6节点都应支持“Internet协议的安全体系结构”[RFC4301]。请注意，IPsec体系结构要求（例如，[RFC4301]第4.5节）实现手动和自动密钥管理。目前，要实现的默认自动密钥管理协议是IKEv2。按照[RFC4301]中的要求，实现IPsec体系结构的IPv6节点必须实现ESP[RFC4303]，并且可以实现AH[RFC4302]。
The current set of mandatory-to-implement algorithms for the IPsec Architecture are defined in "Cryptographic Algorithm Implementation Requirements For ESP and AH" [RFC4835]. IPv6 nodes implementing the IPsec Architecture MUST conform to the requirements in [RFC4835]. Preferred cryptographic algorithms often change more frequently than security protocols. Therefore, implementations MUST allow for migration to new algorithms, as RFC 4835 is replaced or updated in the future.
“ESP和AH的加密算法实现要求”[RFC4835]中定义了IPsec体系结构的当前强制算法集。实现IPsec体系结构的IPv6节点必须符合[RFC4835]中的要求。首选加密算法的更改频率通常高于安全协议。因此，实现必须允许迁移到新算法，因为RFC4835将在将来被替换或更新。
The current set of mandatory-to-implement algorithms for IKEv2 are defined in "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)" [RFC4307]. IPv6 nodes implementing IKEv2 MUST conform to the requirements in [RFC4307] and/or any future updates or replacements to [RFC4307].
IKEv2的当前强制实现算法集在“互联网密钥交换版本2（IKEv2）中使用的加密算法”中定义[RFC4307]。实现IKEv2的IPv6节点必须符合[RFC4307]中的要求和/或[RFC4307]的任何未来更新或替换。
This section defines general host considerations for IPv6 nodes that act as routers. Currently, this section does not discuss routing-specific requirements.
本节定义了充当路由器的IPv6节点的一般主机注意事项。目前，本节不讨论路由特定要求。
The IPv6 Router Alert Option [RFC2711] is an optional IPv6 Hop-by-Hop Header that is used in conjunction with some protocols (e.g., RSVP [RFC2205] or Multicast Listener Discovery (MLD) [RFC2710]). The Router Alert option will need to be implemented whenever protocols that mandate its usage (e.g., MLD) are implemented. See Section 5.10.
IPv6路由器警报选项[RFC2711]是可选的IPv6逐跳报头，与某些协议（例如，RSVP[RFC2205]或多播侦听器发现（MLD）[RFC2710]）一起使用。路由器警报选项将需要在执行强制使用它的协议（如MLD）时执行。见第5.10节。
Sending Router Advertisements and processing Router Solicitations MUST be supported.
必须支持发送路由器广告和处理路由器请求。
Section 7 of [RFC6275] includes some mobility-specific extensions to Neighbor Discovery. Routers SHOULD implement Sections 7.3 and 7.5, even if they do not implement Home Agent functionality.
[RFC6275]的第7节包括对邻居发现的一些特定于移动性的扩展。路由器应实现第7.3节和第7.5节，即使它们没有实现归属代理功能。
A single DHCP server ([RFC3315] or [RFC4862]) can provide configuration information to devices directly attached to a shared link, as well as to devices located elsewhere within a site. Communication between a client and a DHCP server located on different links requires the use of DHCP relay agents on routers.
单个DHCP服务器（[RFC3315]或[RFC4862]）可以向直接连接到共享链路的设备以及位于站点内其他位置的设备提供配置信息。客户端和位于不同链路上的DHCP服务器之间的通信需要在路由器上使用DHCP中继代理。
In simple deployments, consisting of a single router and either a single LAN or multiple LANs attached to the single router, together with a WAN connection, a DHCP server embedded within the router is one common deployment scenario (e.g., [RFC6204]). However, there is no need for relay agents in such scenarios.
在由单个路由器和连接到单个路由器的单个LAN或多个LAN以及WAN连接组成的简单部署中，嵌入在路由器中的DHCP服务器是一种常见的部署场景（例如，[RFC6204]）。但是，在这种情况下不需要中继代理。
In more complex deployment scenarios, such as within enterprise or service provider networks, the use of DHCP requires some level of configuration, in order to configure relay agents, DHCP servers, etc. In such environments, the DHCP server might even be run on a traditional server, rather than as part of a router.
在更复杂的部署场景中，例如在企业或服务提供商网络中，DHCP的使用需要某种级别的配置，以便配置中继代理、DHCP服务器等。在这种环境中，DHCP服务器甚至可能在传统服务器上运行，而不是作为路由器的一部分。
Because of the wide range of deployment scenarios, support for DHCP server functionality on routers is optional. However, routers targeted for deployment within more complex scenarios (as described above) SHOULD support relay agent functionality. Note that "Basic Requirements for IPv6 Customer Edge Routers" [RFC6204] requires implementation of a DHCPv6 server function in IPv6 Customer Edge (CE) routers.
由于部署场景的广泛性，在路由器上支持DHCP服务器功能是可选的。但是，针对更复杂场景（如上所述）部署的路由器应支持中继代理功能。请注意，“IPv6客户边缘路由器的基本要求”[RFC6204]要求在IPv6客户边缘（CE）路由器中实现DHCPv6服务器功能。
Network management MAY be supported by IPv6 nodes. However, for IPv6 nodes that are embedded devices, network management may be the only possible way of controlling these nodes.
IPv6节点可能支持网络管理。但是，对于作为嵌入式设备的IPv6节点，网络管理可能是控制这些节点的唯一可能方式。
The following two MIB modules SHOULD be supported by nodes that support a Simple Network Management Protocol (SNMP) agent.
支持简单网络管理协议（SNMP）代理的节点应支持以下两个MIB模块。
The IP Forwarding Table MIB [RFC4292] SHOULD be supported by nodes that support an SNMP agent.
支持SNMP代理的节点应支持IP转发表MIB[RFC4292]。
The IP MIB [RFC4293] SHOULD be supported by nodes that support an SNMP agent.
支持SNMP代理的节点应支持IP MIB[RFC4293]。
This document does not directly affect the security of the Internet, beyond the security considerations associated with the individual protocols.
除了与各个协议相关的安全考虑因素外，本文件不会直接影响互联网的安全性。
Security is also discussed in Section 11 above.
上文第11节也讨论了安全问题。
For this version of the IPv6 Node Requirements document, the authors would like to thank Hitoshi Asaeda, Brian Carpenter, Tim Chown, Ralph Droms, Sheila Frankel, Sam Hartman, Bob Hinden, Paul Hoffman, Pekka Savola, Yaron Sheffer, and Dave Thaler for their comments.
对于这个版本的IPv6节点需求文档，作者要感谢Asaeda Hitoshi、Brian Carpenter、Tim Chown、Ralph Droms、Sheila Frankel、Sam Hartman、Bob Hinden、Paul Hoffman、Pekka Savola、Yaron Sheffer和Dave Thaler的评论。
The original version of this document (RFC 4279) was written by the IPv6 Node Requirements design team:
本文档的原始版本（RFC 4279）由IPv6节点需求设计团队编写：
Jari Arkko jari.arkko@ericsson.com
雅丽雅可雅丽。arkko@ericsson.com
Marc Blanchet marc.blanchet@viagenie.qc.ca
马克·布兰切特·马克。blanchet@viagenie.qc.ca
Samita Chakrabarti samita.chakrabarti@eng.sun.com
萨米塔查克拉巴蒂萨米塔。chakrabarti@eng.sun.com
Alain Durand alain.durand@sun.com
阿兰·杜兰和阿兰。durand@sun.com
Gerard Gastaud gerard.gastaud@alcatel.fr
杰拉德·加斯托德·杰拉德。gastaud@alcatel.fr
Jun-ichiro Itojun Hagino itojun@iijlab.net
伊藤俊一郎itojun@iijlab.net
Atsushi Inoue inoue@isl.rdc.toshiba.co.jp
井上Atsushiinoue@isl.rdc.toshiba.co.jp
Masahiro Ishiyama masahiro@isl.rdc.toshiba.co.jp
石山正彦masahiro@isl.rdc.toshiba.co.jp
John Loughney john.loughney@nokia.com
约翰·拉夫尼·约翰。loughney@nokia.com
Rajiv Raghunarayan raraghun@cisco.com
拉吉夫·拉古纳拉扬raraghun@cisco.com
Shoichi Sakane shouichi.sakane@jp.yokogawa.com
佐根守一昭一。sakane@jp.yokogawa.com
Dave Thaler dthaler@windows.microsoft.com
戴夫·泰勒dthaler@windows.microsoft.com
Juha Wiljakka juha.wiljakka@Nokia.com
Juha Wiljakka Juha。wiljakka@Nokia.com
The authors would like to thank Ran Atkinson, Jim Bound, Brian Carpenter, Ralph Droms, Christian Huitema, Adam Machalek, Thomas Narten, Juha Ollila, and Pekka Savola for their comments. Thanks to Mark Andrews for comments and corrections on DNS text. Thanks to Alfred Hoenes for tracking the updates to various RFCs.
作者要感谢Ran Atkinson、Jim Bound、Brian Carpenter、Ralph Droms、Christian Huitema、Adam Machalek、Thomas Narten、Juha Ollila和Pekka Savola的评论。感谢Mark Andrews对DNS文本的评论和更正。感谢Alfred Hoenes跟踪各种RFC的更新。
There have been many editorial clarifications as well as significant additions and updates. While this section highlights some of the changes, readers should not rely on this section for a comprehensive list of all changes.
有许多编辑澄清，以及重要的补充和更新。虽然本节重点介绍了一些更改，但读者不应依赖本节获取所有更改的综合列表。
1. Updated the Introduction to indicate that this document is an applicability statement and is aimed at general nodes.
1. 更新了简介，表明本文件是适用性声明，针对一般节点。
2. Significantly updated the section on Mobility protocols, adding references and downgrading previous SHOULDs to MAYs.
2. 显著地更新了关于移动协议的部分，添加了参考资料，并降低了MAYs之前的应做事项。
3. Changed Sub-IP Layer section to just list relevant RFCs, and added some more RFCs.
3. 将子IP层部分更改为仅列出相关的RFC，并添加了更多的RFC。
4. Added section on SEND (it is a MAY).
4. 增加了发送部分（这是一个五月）。
5. Revised section on Privacy Extensions [RFC4941] to add more nuance to recommendation.
5. 修改了隐私扩展部分[RFC4941]，增加了建议的细微差别。
6. Completely revised IPsec/IKEv2 section, downgrading overall recommendation to a SHOULD.
6. 完全修订了IPsec/IKEv2部分，将总体建议降级为“应”。
7. Upgraded recommendation of DHCPv6 to SHOULD.
7. 将DHCPv6的建议升级为应。
8. Added background section on DHCP versus RA options, added SHOULD recommendation for DNS configuration via RAs [RFC6106], and cleaned up DHCP recommendations.
8. 添加了关于DHCP与RA选项的背景部分，添加了通过RAs[RFC6106]进行DNS配置的建议，并清理了DHCP建议。
9. Added recommendation that routers implement Sections 7.3 and 7.5 of [RFC6275].
9. 增加了路由器执行[RFC6275]第7.3节和第7.5节的建议。
10. Added pointer to subnet clarification document [RFC5942].
10. 添加了指向子网澄清文件[RFC5942]的指针。
11. Added text that "IPv6 Host-to-Router Load Sharing" [RFC4311] SHOULD be implemented.
11. 添加了应实现“IPv6主机到路由器负载共享”[RFC4311]的文本。
12. Added reference to [RFC5722] (Overlapping Fragments), and made it a MUST to implement.
12. 添加了对[RFC5722]（重叠片段）的引用，并使其成为必须实现的。
13. Made "A Recommendation for IPv6 Address Text Representation" [RFC5952] a SHOULD.
13. 提出了“IPv6地址文本表示的建议”[RFC5952]A。
14. Removed mention of "DNAME" from the discussion about [RFC3363].
14. 从[RFC3363]的讨论中删除了对“DNAME”的提及。
15. Numerous updates to reflect newer versions of IPv6 documents, including [RFC4443], [RFC4291], [RFC3596], and [RFC4213].
15. 大量更新以反映IPv6文档的更新版本，包括[RFC4443]、[RFC4291]、[RFC3596]和[RFC4213]。
16. Removed discussion of "Managed" and "Other" flags in RAs. There is no consensus at present on how to process these flags, and discussion of their semantics was removed in the most recent update of Stateless Address Autoconfiguration [RFC4862].
16. 删除了对RAs中“托管”和“其他”标志的讨论。目前还没有关于如何处理这些标志的共识，在最近更新的无状态地址自动配置[RFC4862]中删除了对其语义的讨论。
17. Added many more references to optional IPv6 documents.
17. 添加了更多对可选IPv6文档的引用。
18. Made "A Recommendation for IPv6 Address Text Representation" [RFC5952] a SHOULD.
18. 提出了“IPv6地址文本表示的建议”[RFC5952]A。
19. Added reference to [RFC5722] (Overlapping Fragments), and made it a MUST to implement.
19. 添加了对[RFC5722]（重叠片段）的引用，并使其成为必须实现的。
20. Updated MLD section to include reference to Lightweight MLD [RFC5790].
20. 更新了MLD部分，包括对轻型MLD[RFC5790]的参考。
21. Added SHOULD recommendation for "Default Router Preferences and More-Specific Routes" [RFC4191].
21. 增加了“默认路由器首选项和更具体路由”的建议[RFC4191]。
22. Made "IPv6 Flow Label Specification" [RFC6437] a SHOULD.
22. 应制定“IPv6流标签规范”[RFC6437]a。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981]McCann，J.，Deering，S.，和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，1996年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671]Vixie，P.，“DNS的扩展机制（EDNS0）”，RFC 26711999年8月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710]Deering，S.，Fenner，W.，和B.Haberman，“IPv6的多播侦听器发现（MLD）”，RFC 2710，1999年10月。
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[RFC2711]帕特里奇，C.和A.杰克逊，“IPv6路由器警报选项”，RFC27111999年10月。
[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月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484]Draves，R.，“互联网协议版本6（IPv6）的默认地址选择”，RFC 3484，2003年2月。
[RFC3590] Haberman, B., "Source Address Selection for the Multicast Listener Discovery (MLD) Protocol", RFC 3590, September 2003.
[RFC3590]Haberman，B.，“多播侦听器发现（MLD）协议的源地址选择”，RFC 35902003年9月。
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.
[RFC3596]Thomson，S.，Huitema，C.，Ksinant，V.，和M.Souissi，“支持IP版本6的DNS扩展”，RFC 3596，2003年10月。
[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月。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810]Vida，R.和L.Costa，“IPv6多播侦听器发现版本2（MLDv2）”，RFC 3810，2004年6月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 40342005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，2005年3月。
[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月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[RFC4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, April 2006.
[RFC4292]Haberman，B.，“IP转发表MIB”，RFC 42922006年4月。
[RFC4293] Routhier, S., "Management Information Base for the Internet Protocol (IP)", RFC 4293, April 2006.
[RFC4293]Routhier，S.，“互联网协议（IP）的管理信息库”，RFC 4293，2006年4月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005.
[RFC4307]Schiller，J.“互联网密钥交换版本2（IKEv2）中使用的加密算法”，RFC 4307，2005年12月。
[RFC4311] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load Sharing", RFC 4311, November 2005.
[RFC4311]Hinden，R.和D.Thaler，“IPv6主机到路由器负载共享”，RFC 4311，2005年11月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]Conta，A.，Deering，S.和M.Gupta，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 4443，2006年3月。
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast", RFC 4604, August 2006.
[RFC4604]Holbrook，H.，Cain，B.，和B.Haberman，“为源特定多播使用Internet组管理协议版本3（IGMPv3）和多播侦听器发现协议版本2（MLDv2）”，RFC 4604，2006年8月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607]Holbrook，H.和B.Cain，“IP的源特定多播”，RFC4607，2006年8月。
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4835, April 2007.
[RFC4835]Manral，V.“封装安全有效载荷（ESP）和身份验证头（AH）的密码算法实现要求”，RFC 4835，2007年4月。
[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月。
[RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", RFC 5453, February 2009.
[RFC5453]Krishnan，S.，“保留IPv6接口标识符”，RFC 5453，2009年2月。
[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", RFC 5722, December 2009.
[RFC5722]Krishnan，S.，“重叠IPv6片段的处理”，RFC 5722，2009年12月。
[RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, February 2010.
[RFC5790]Liu，H.，Cao，W.，和H.Asaeda，“轻量级Internet组管理协议版本3（IGMPv3）和多播侦听器发现版本2（MLDv2）协议”，RFC 57902010年2月。
[RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes", RFC 5942, July 2010.
[RFC5942]Singh，H.，Beebee，W.和E.Nordmark，“IPv6子网模型：链路和子网前缀之间的关系”，RFC 59422010年7月。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010.
[RFC5952]Kawamura，S.和M.Kawashima，“IPv6地址文本表示的建议”，RFC 59522010年8月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]Kaufman，C.，Hoffman，P.，Nir，Y.，和P.Eronen，“互联网密钥交换协议版本2（IKEv2）”，RFC 59962010年9月。
[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月。
[RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. Troan, "Basic Requirements for IPv6 Customer Edge Routers", RFC 6204, April 2011.
[RFC6204]Singh，H.，Beebee，W.，Donley，C.，Stark，B.，和O.Troan，“IPv6客户边缘路由器的基本要求”，RFC 62042011年4月。
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, November 2011.
[RFC6437]Amante，S.，Carpenter，B.，Jiang，S.，和J.Rajahalme，“IPv6流标签规范”，RFC 6437，2011年11月。
[DODv6] DISR IPv6 Standards Technical Working Group, "DoD IPv6 Standard Profiles For IPv6 Capable Products Version 5.0", July 2010, <http://jitc.fhu.disa.mil/apl/ipv6/pdf/disr_ipv6_50.pdf>.
[DODv6]DISR IPv6标准技术工作组，“国防部支持IPv6产品的IPv6标准配置文件5.0版”，2010年7月<http://jitc.fhu.disa.mil/apl/ipv6/pdf/disr_ipv6_50.pdf>.
[POSIX] IEEE, "IEEE Std. 1003.1-2008 Standard for Information Technology -- Portable Operating System Interface (POSIX), ISO/IEC 9945:2009", <http://www.ieee.org>.
[POSIX]IEEE，“IEEE标准1003.1-2008信息技术标准——便携式操作系统接口（POSIX），ISO/IEC 9945:2009”<http://www.ieee.org>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，B.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年9月。
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[RFC2464]克劳福德，M.，“通过以太网传输IPv6数据包”，RFC2464，1998年12月。
[RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 over Non-Broadcast Multiple Access (NBMA) networks", RFC 2491, January 1999.
[RFC2491]Armitage，G.，Schulter，P.，Jork，M.，和G.Harter，“非广播多址（NBMA）网络上的IPv6”，RFC 2491，1999年1月。
[RFC2492] Armitage, G., Schulter, P., and M. Jork, "IPv6 over ATM Networks", RFC 2492, January 1999.
[RFC2492]Armitage，G.，Schulter，P.，和M.Jork，“ATM网络上的IPv6”，RFC 2492，1999年1月。
[RFC2590] Conta, A., Malis, A., and M. Mueller, "Transmission of IPv6 Packets over Frame Relay Networks Specification", RFC 2590, May 1999.
[RFC2590]Conta，A.，Malis，A.，和M.Mueller，“通过帧中继网络传输IPv6数据包规范”，RFC 25901999年5月。
[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, August 1999.
[RFC2675]Borman，D.，Deering，S.，和R.Hinden，“IPv6巨型程序”，RFC 26751999年8月。
[RFC3146] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets over IEEE 1394 Networks", RFC 3146, October 2001.
[RFC3146]Fujisawa，K.和A.Onoe，“通过IEEE 1394网络传输IPv6数据包”，RFC 3146，2001年10月。
[RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)", RFC 3363, August 2002.
[RFC3363]Bush，R.，Durand，A.，Fink，B.，Gudmundsson，O.，和T.Hain，“代表域名系统（DNS）中的互联网协议版本6（IPv6）地址”，RFC 33632002年8月。
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003.
[RFC3493]Gilligan，R.，Thomson，S.，Bound，J.，McCann，J.，和W.Stevens，“IPv6的基本套接字接口扩展”，RFC 3493，2003年2月。
[RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced Sockets Application Program Interface (API) for IPv6", RFC 3542, May 2003.
[RFC3542]Stevens，W.，Thomas，M.，Nordmark，E.，和T.Jinmei，“IPv6的高级套接字应用程序接口（API）”，RFC 3542，2003年5月。
[RFC3678] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface Extensions for Multicast Source Filters", RFC 3678, January 2004.
[RFC3678]Thaler，D.，Fenner，B.，和B.Quinn，“多播源过滤器的套接字接口扩展”，RFC 3678，2004年1月。
[RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004.
[RFC3776]Arkko，J.，Devarapalli，V.，和F.Dupont，“使用IPsec保护移动节点和家庭代理之间的移动IPv6信令”，RFC 37762004年6月。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971]Arkko，J.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[RFC3972]Aura，T.，“加密生成地址（CGA）”，RFC 39722005年3月。
[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月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。
[RFC4338] DeSanti, C., Carlson, C., and R. Nixon, "Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) Packets over Fibre Channel", RFC 4338, January 2006.
[RFC4338]DeSanti，C.，Carlson，C.，和R.Nixon，“通过光纤通道传输IPv6，IPv4和地址解析协议（ARP）数据包”，RFC 4338，2006年1月。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380]Huitema，C.，“Teredo：通过网络地址转换（NAT）通过UDP传输IPv6”，RFC 43802006年2月。
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, April 2006.
[RFC4429]Moore，N.，“IPv6的乐观重复地址检测（DAD）”，RFC4429，2006年4月。
[RFC4584] Chakrabarti, S. and E. Nordmark, "Extension to Sockets API for Mobile IPv6", RFC 4584, July 2006.
[RFC4584]Chakrabarti，S.和E.Nordmark，“移动IPv6套接字API的扩展”，RFC 4584，2006年7月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821]Mathis，M.和J.Heffner，“打包层路径MTU发现”，RFC 48212007年3月。
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007.
[RFC4877]Devarapalli，V.和F.Dupont，“使用IKEv2的移动IPv6操作和修订的IPsec架构”，RFC 4877，2007年4月。
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended ICMP to Support Multi-Part Messages", RFC 4884, April 2007.
[RFC4884]Bonica，R.，Gan，D.，Tappan，D.，和C.Pignataro，“支持多部分消息的扩展ICMP”，RFC 4884，2007年4月。
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007.
[RFC4944]黑山，G.，Kushalnagar，N.，Hui，J.，和D.Culler，“通过IEEE 802.15.4网络传输IPv6数据包”，RFC 49442007年9月。
[RFC5006] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Option for DNS Configuration", RFC 5006, September 2007.
[RFC5006]Jeong，J.，Park，S.，Beloeil，L.，和S.Madanapalli，“DNS配置的IPv6路由器广告选项”，RFC 5006，2007年9月。
[RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 Socket API for Source Address Selection", RFC 5014, September 2007.
[RFC5014]Nordmark，E.，Chakrabarti，S.，和J.Laganier，“用于源地址选择的IPv6套接字API”，RFC 50142007年9月。
[RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over PPP", RFC 5072, September 2007.
[RFC5072]S.Varada，Haskins，D.和E.Allen，“PPP上的IP版本6”，RFC 5072，2007年9月。
[RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. Madanapalli, "Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, February 2008.
[RFC5121]Patil，B.，Xia，F.，Sarikaya，B.，Choi，JH.，和S.Madanapalli，“通过IEEE 802.16网络上的IPv6聚合子层传输IPv6”，RFC 51212008年2月。
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009.
[RFC5555]Soliman，H.，“双栈主机和路由器的移动IPv6支持”，RFC 55552009年6月。
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[RFC6275]Perkins，C.，Johnson，D.，和J.Arkko，“IPv6中的移动支持”，RFC 62752011年7月。
[USGv6] National Institute of Standards and Technology, "A Profile for IPv6 in the U.S. Government - Version 1.0", July 2008, <http://www.antd.nist.gov/usgv6/usgv6-v1.pdf>.
[USGv6]美国国家标准与技术研究所，“美国政府IPv6概况-1.0版”，2008年7月<http://www.antd.nist.gov/usgv6/usgv6-v1.pdf>.
Authors' Addresses
作者地址
Ed Jankiewicz SRI International, Inc. 333 Ravenswood Ave. Menlo Park, CA 94025 USA
Ed Jankiewicz SRI International，Inc.美国加利福尼亚州门罗公园瑞文斯伍德大道333号，邮编94025
Phone: +1 443 502 5815
EMail: edward.jankiewicz@sri.com
Phone: +1 443 502 5815
EMail: edward.jankiewicz@sri.com
John Loughney Nokia 200 South Mathilda Ave. Sunnyvale, CA 94086 USA
美国加利福尼亚州桑尼维尔南玛蒂尔达大道200号诺基亚约翰·洛尼94086
Phone: +1 650 283 8068
EMail: john.loughney@nokia.com
Phone: +1 650 283 8068
EMail: john.loughney@nokia.com
Thomas Narten IBM Corporation 3039 Cornwallis Ave. PO Box 12195 Research Triangle Park, NC 27709-2195 USA
Thomas Narten IBM Corporation美国北卡罗来纳州研究三角公园康沃利斯大道3039号邮政信箱12195号，邮编27709-2195
Phone: +1 919 254 7798
EMail: narten@us.ibm.com
Phone: +1 919 254 7798
EMail: narten@us.ibm.com