Network Working Group J. Loughney, Ed.
Request for Comments: 4294 Nokia
Category: Informational April 2006
Network Working Group J. Loughney, Ed.
Request for Comments: 4294 Nokia
Category: Informational April 2006
IPv6 Node Requirements
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 (2006).
版权所有（C）互联网协会（2006年）。
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可以在大量情况和部署中正常运行和互操作。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Requirement Language .......................................3
1.2. Scope of This Document .....................................3
1.3. Description of IPv6 Nodes ..................................3
2. Abbreviations Used in This Document .............................3
3. Sub-IP Layer ....................................................4
3.1. Transmission of IPv6 Packets over Ethernet Networks
- RFC 2464 .................................................4
3.2. IP version 6 over PPP - RFC 2472 ...........................4
3.3. IPv6 over ATM Networks - RFC 2492 ..........................4
4. IP Layer ........................................................5
4.1. Internet Protocol Version 6 - RFC 2460 .....................5
4.2. Neighbor Discovery for IPv6 - RFC 2461 .....................5
4.3. Path MTU Discovery and Packet Size .........................6
4.4. ICMP for the Internet Protocol Version 6 (IPv6) -
RFC 2463 ...................................................7
4.5. Addressing .................................................7
4.6. Multicast Listener Discovery (MLD) for IPv6 - RFC 2710 .....8
5. DNS and DHCP ....................................................8
5.1. DNS ........................................................8
1. Introduction ....................................................2
1.1. Requirement Language .......................................3
1.2. Scope of This Document .....................................3
1.3. Description of IPv6 Nodes ..................................3
2. Abbreviations Used in This Document .............................3
3. Sub-IP Layer ....................................................4
3.1. Transmission of IPv6 Packets over Ethernet Networks
- RFC 2464 .................................................4
3.2. IP version 6 over PPP - RFC 2472 ...........................4
3.3. IPv6 over ATM Networks - RFC 2492 ..........................4
4. IP Layer ........................................................5
4.1. Internet Protocol Version 6 - RFC 2460 .....................5
4.2. Neighbor Discovery for IPv6 - RFC 2461 .....................5
4.3. Path MTU Discovery and Packet Size .........................6
4.4. ICMP for the Internet Protocol Version 6 (IPv6) -
RFC 2463 ...................................................7
4.5. Addressing .................................................7
4.6. Multicast Listener Discovery (MLD) for IPv6 - RFC 2710 .....8
5. DNS and DHCP ....................................................8
5.1. DNS ........................................................8
5.2. Dynamic Host Configuration Protocol for IPv6
(DHCPv6) - RFC 3315 ........................................9
6. IPv4 Support and Transition ....................................10
6.1. Transition Mechanisms .....................................10
7. Mobile IP ......................................................10
8. Security .......................................................10
8.1. Basic Architecture ........................................10
8.2. Security Protocols ........................................11
8.3. Transforms and Algorithms .................................11
8.4. Key Management Methods ....................................12
9. Router-Specific Functionality ..................................12
9.1. General ...................................................12
10. Network Management ............................................12
10.1. Management Information Base Modules (MIBs) ...............12
11. Security Considerations .......................................13
12. References ....................................................13
12.1. Normative References .....................................13
12.2. Informative References ...................................16
13. Authors and Acknowledgements ..................................18
5.2. Dynamic Host Configuration Protocol for IPv6
(DHCPv6) - RFC 3315 ........................................9
6. IPv4 Support and Transition ....................................10
6.1. Transition Mechanisms .....................................10
7. Mobile IP ......................................................10
8. Security .......................................................10
8.1. Basic Architecture ........................................10
8.2. Security Protocols ........................................11
8.3. Transforms and Algorithms .................................11
8.4. Key Management Methods ....................................12
9. Router-Specific Functionality ..................................12
9.1. General ...................................................12
10. Network Management ............................................12
10.1. Management Information Base Modules (MIBs) ...............12
11. Security Considerations .......................................13
12. References ....................................................13
12.1. Normative References .....................................13
12.2. Informative References ...................................16
13. Authors and Acknowledgements ..................................18
The goal of this document is to define the common functionality required from both IPv6 hosts and routers. Many IPv6 nodes will implement optional or additional features, but this document 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 informational in nature and does not update Standards Track RFCs.
本文件试图避免讨论协议细节，并为此参考RFC。本文件为信息性文件，不更新标准跟踪RFC。
Although the document points to different specifications, it should be noted that in most cases, the granularity of requirements are smaller than a single specification, as many specifications define multiple, independent pieces, some of which may not be mandatory.
尽管本文件指向不同的规范，但应注意的是，在大多数情况下，需求的粒度小于单个规范，因为许多规范定义了多个独立的部分，其中一些可能不是强制性的。
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:
由于实施者并不总是可能知道IPv6在节点中的确切用法，因此IPv6节点的首要要求是它们应遵守Jon Postel的健壮性原则：
Be conservative in what you do, be liberal in what you accept from others [RFC-793].
在你做的事情上要保守，在你接受别人的事情上要自由[RFC-793]。
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 [RFC-2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC-2119]中的说明进行解释。
IPv6 covers many specifications. It is intended that IPv6 will be deployed in many different situations and environments. Therefore, it is important to develop the 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 [RFC-2460], we have the following definitions:
根据互联网协议第6版（IPv6）规范[RFC-2460]，我们有以下定义：
Description of an IPv6 Node
IPv6节点的说明
- a device that implements IPv6.
- 实现IPv6的设备。
Description of an IPv6 router
IPv6路由器的描述
- a node that forwards IPv6 packets not explicitly addressed to itself.
- 转发未显式寻址到自身的IPv6数据包的节点。
Description of an IPv6 Host
IPv6主机的说明
- any node that is not a router.
- 不是路由器的任何节点。
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 Transfer 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
点对点协议
PVC Permanent Virtual Circuit
永久虚拟电路
SVC Switched Virtual Circuit
SVC交换虚拟电路
An IPv6 node must include support for one or more IPv6 link-layer specifications. Which link-layer specifications are included 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. This section highlights some major layer 2 technologies and is not intended to be complete.
由于IPv6在新的第2层技术上运行，预计将发布新的规范。本节重点介绍了一些主要的第2层技术，并不打算完整介绍。
Nodes supporting IPv6 over Ethernet interfaces MUST implement Transmission of IPv6 Packets over Ethernet Networks [RFC-2464].
支持以太网上IPv6接口的节点必须实现以太网上IPv6数据包的传输[RFC-2464]。
Nodes supporting IPv6 over PPP MUST implement IPv6 over PPP [RFC-2472].
支持IPv6 over PPP的节点必须实现IPv6 over PPP[RFC-2472]。
Nodes supporting IPv6 over ATM Networks MUST implement IPv6 over ATM Networks [RFC-2492]. Additionally, RFC 2492 states:
支持ATM网络上IPv6的节点必须在ATM网络上实现IPv6[RFC-2492]。此外，RFC 2492规定：
A minimally conforming IPv6/ATM driver SHALL support the PVC mode of operation. An IPv6/ATM driver that supports the full SVC mode SHALL also support PVC mode of operation.
符合最低要求的IPv6/ATM驱动程序应支持PVC操作模式。支持全SVC模式的IPv6/ATM驱动程序也应支持PVC操作模式。
The Internet Protocol Version 6 is specified in [RFC-2460]. This specification MUST be supported.
[RFC-2460]中规定了互联网协议版本6。必须支持此规范。
Unrecognized options in Hop-by-Hop Options or Destination Options extensions 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.
节点必须始终能够发送、接收和处理片段头。所有一致的IPv6实现必须能够发送和接收IPv6数据包；可能支持转发功能。
RFC 2460 specifies extension headers and the processing for these headers.
RFC2460指定扩展头和对这些头的处理。
A full implementation of IPv6 includes implementation of the following extension headers: Hop-by-Hop Options, Routing (Type 0), Fragment, Destination Options, Authentication and Encapsulating Security Payload [RFC-2460].
IPv6的完整实现包括以下扩展头的实现：逐跳选项、路由（类型0）、片段、目标选项、身份验证和封装安全负载[RFC-2460]。
An IPv6 node MUST be able to process these headers. It should be noted that there is some discussion about the use of Routing Headers and possible security threats [IPv6-RH] that they cause.
IPv6节点必须能够处理这些标头。应该注意的是，对于路由头的使用以及它们可能导致的安全威胁[IPv6 RH]进行了一些讨论。
Neighbor Discovery SHOULD be supported. [RFC-2461] states:
应支持邻居发现。[RFC-2461]指出：
"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., 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
“除非另有规定（在涉及通过特定链路类型操作IP的文档中），否则本文档适用于所有链路类型。但是，由于ND对其某些服务使用链路层多播，因此在某些链路类型（例如NBMA链路）上可能会出现以下情况：将指定实现这些服务的替代协议或机制（在涵盖特定链路类型上的IP操作的适当文件中）.本文档中描述的不直接依赖于多播的服务，如重定向、下一跳确定、邻居不可达性检测等，预计将作为
specified in this document. The details of how one uses ND on NBMA links is an area for further study."
在本文件中指定。如何在NBMA链接上使用ND的详细信息有待进一步研究。”
Some detailed analysis of Neighbor Discovery follows:
邻居发现的一些详细分析如下：
Router Discovery is how hosts locate routers that reside on an attached link. Router Discovery MUST be supported for implementations.
路由器发现是主机如何定位驻留在连接链路上的路由器。实施时必须支持路由器发现。
Prefix Discovery is how hosts discover the set of address prefixes that define which destinations are on-link for an attached link. Prefix discovery MUST be supported for implementations. Neighbor Unreachability Detection (NUD) MUST be supported for all paths between hosts and neighboring nodes. It is not required for paths between routers. However, when a node receives a unicast Neighbor Solicitation (NS) message (that may be a NUD's NS), the node MUST respond to it (i.e., send a unicast Neighbor Advertisement).
前缀发现是主机如何发现一组地址前缀，这些地址前缀定义了连接的链路上的目的地。实现必须支持前缀发现。主机和相邻节点之间的所有路径都必须支持邻居不可达性检测（NUD）。路由器之间的路径不需要它。然而，当节点接收到单播邻居请求（NS）消息（可能是NUD的NS）时，该节点必须响应该消息（即，发送单播邻居公告）。
Duplicate Address Detection MUST be supported on all links supporting link-layer multicast (RFC 2462, Section 5.4, specifies DAD MUST take place on all unicast addresses).
在支持链路层多播的所有链路上必须支持重复地址检测（RFC 2462，第5.4节，指定必须在所有单播地址上进行DAD）。
A host implementation MUST support sending Router Solicitations.
主机实现必须支持发送路由器请求。
Receiving and processing Router Advertisements MUST be supported for host implementations. The ability to understand specific Router Advertisement options is dependent on supporting the specification where the RA is specified.
主机实现必须支持接收和处理路由器播发。理解特定路由器广告选项的能力取决于支持指定RA的规范。
Sending and Receiving Neighbor Solicitation (NS) and Neighbor Advertisement (NA) MUST be supported. NS and NA messages are required for Duplicate Address Detection (DAD).
必须支持发送和接收邻居请求（NS）和邻居公告（NA）。重复地址检测（DAD）需要NS和NA消息。
Redirect functionality SHOULD be supported. If the node is a router, Redirect functionality MUST be supported.
应该支持重定向功能。如果节点是路由器，则必须支持重定向功能。
Path MTU Discovery [RFC-1981] SHOULD be supported, though minimal implementations MAY choose to not support it and avoid large packets. The rules in RFC 2460 MUST be followed for packet fragmentation and reassembly.
应该支持路径MTU发现[RFC-1981]，尽管最低限度的实现可能会选择不支持它并避免大数据包。必须遵循RFC 2460中的规则进行数据包分段和重新组装。
IPv6 Jumbograms [RFC-2675] MAY be supported.
可能支持IPv6巨型程序[RFC-2675]。
ICMPv6 [RFC-2463] MUST be supported.
必须支持ICMPv6[RFC-2463]。
The IPv6 Addressing Architecture [RFC-3513] MUST be supported as updated by [RFC-3879].
IPv6寻址体系结构[RFC-3513]必须得到[RFC-3879]更新的支持。
IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462]. This specification MUST be supported for nodes that are hosts. Static address can be supported as well.
[RFC-2462]中定义了IPv6无状态地址自动配置。作为主机的节点必须支持此规范。也可以支持静态地址。
Nodes that are routers MUST be able to generate link local addresses as described in RFC 2462 [RFC-2462].
作为路由器的节点必须能够生成RFC 2462[RFC-2462]中所述的链路本地地址。
From 2462:
从2462年起：
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.
本文档中指定的自动配置过程仅适用于主机，而不适用于路由器。由于主机自动配置使用路由器公布的信息，因此需要通过其他方式配置路由器。然而，预计路由器将使用本文档中描述的机制生成链路本地地址。此外，在将路由器分配给接口之前，路由器应成功通过本文档中描述的所有地址的重复地址检测程序。
Duplicate Address Detection (DAD) MUST be supported.
必须支持重复地址检测（DAD）。
Privacy Extensions for Stateless Address Autoconfiguration [RFC-3041] SHOULD be supported. It is recommended that this behavior be configurable on a connection basis within each application when available. It is noted that a number of applications do not work with addresses generated with this method, while other applications work quite well with them.
应支持无状态地址自动配置的隐私扩展[RFC-3041]。建议在可用的情况下，在每个应用程序中可以基于连接配置此行为。需要注意的是，许多应用程序不能使用此方法生成的地址，而其他应用程序可以很好地使用它们。
The rules specified in the Default Address Selection for IPv6 [RFC-3484] document MUST be implemented. It is expected that IPv6 nodes will need to deal with multiple addresses.
必须执行IPv6[RFC-3484]文档的默认地址选择中指定的规则。预计IPv6节点将需要处理多个地址。
Stateful Address Autoconfiguration MAY be supported. DHCPv6 [RFC-3315] is the standard stateful address configuration protocol; see Section 5.3 for DHCPv6 support.
可能支持有状态地址自动配置。DHCPv6[RFC-3315]是标准的有状态地址配置协议；有关DHCPv6的支持，请参见第5.3节。
Nodes which do not support Stateful Address Autoconfiguration may be unable to obtain any IPv6 addresses, aside from link-local addresses, when it receives a router advertisement with the 'M' flag (Managed address configuration) set and that contains no prefixes advertised for Stateless Address Autoconfiguration (see Section 4.5.2). Additionally, such nodes will be unable to obtain other configuration information, such as the addresses of DNS servers when it is connected to a link over which the node receives a router advertisement in which the 'O' flag ("Other stateful configuration") is set.
当不支持有状态地址自动配置的节点接收到设置了“M”标志（托管地址配置）且不包含为无状态地址自动配置播发的前缀的路由器播发时，除链路本地地址外，可能无法获取任何IPv6地址（见第4.5.2节）。此外，此类节点将无法获得其他配置信息，例如当其连接到链路时DNS服务器的地址，节点通过该链路接收设置了“O”标志（“其他有状态配置”）的路由器公告。
Nodes that need to join multicast groups SHOULD implement MLDv2 [RFC-3810]. However, if the node has applications that only need support for Any-Source Multicast [RFC-3569], the node MAY implement MLDv1 [RFC-2710] instead. If the node has applications that need support for Source-Specific Multicast [RFC-3569, SSM-ARCH], the node MUST support MLDv2 [RFC-3810].
需要加入多播组的节点应实现MLDv2[RFC-3810]。然而，如果节点具有只需要支持任何源多播[RFC-3569]的应用程序，则节点可以实现MLDv1[RFC-2710]。如果节点具有需要支持源特定多播的应用程序[RFC-3569，SSM-ARCH]，则节点必须支持MLDv2[RFC-3810]。
When MLD is used, the rules in the "Source Address Selection for the Multicast Listener Discovery (MLD) Protocol" [RFC-3590] MUST be followed.
使用MLD时，必须遵循“多播侦听器发现（MLD）协议的源地址选择”[RFC-3590]中的规则。
DNS is described in [RFC-1034], [RFC-1035], [RFC-3152], [RFC-3363], and [RFC-3596]. 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 that applications rely on and generally needs to be supported. All nodes that need to resolve names SHOULD implement stub-resolver [RFC-1034] functionality, as in RFC 1034, Section 5.3.1, with support for:
DNS描述见[RFC-1034]、[RFC-1035]、[RFC-3152]、[RFC-3363]和[RFC-3596]。并非所有节点都需要解析名称；那些永远不需要解析DNS名称的服务器不需要实现解析程序功能。但是，解析名称的能力是应用程序所依赖并通常需要支持的一项基本基础设施能力。需要解析名称的所有节点应实现存根解析器[RFC-1034]功能，如RFC 1034第5.3.1节所述，并支持：
- AAAA type Resource Records [RFC-3596];
- AAAA型资源记录[RFC-3596]；
- reverse addressing in ip6.arpa using PTR records [RFC-3152];
- ip6.arpa中使用PTR记录的反向寻址[RFC-3152]；
- EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512 octets.
- EDNS0[RFC-2671]允许DNS数据包大小大于512个八位字节。
Those nodes are RECOMMENDED to support DNS security extensions [RFC-4033], [RFC-4034], and [RFC-4035].
建议这些节点支持DNS安全扩展[RFC-4033]、[RFC-4034]和[RFC-4035]。
Those nodes are NOT RECOMMENDED to support the experimental A6 and DNAME Resource Records [RFC-3363].
不建议这些节点支持实验性A6和DNAME资源记录[RFC-3363]。
The method by which IPv6 nodes that use DHCP for address assignment can obtain IPv6 addresses and other configuration information upon receipt of a Router Advertisement with the 'M' flag set is described in Section 5.5.3 of RFC 2462.
RFC 2462第5.5.3节描述了使用DHCP进行地址分配的IPv6节点在接收到带有“M”标志集的路由器公告时可以获取IPv6地址和其他配置信息的方法。
In addition, in the absence of a router, those IPv6 nodes that use DHCP for address assignment MUST initiate DHCP to obtain IPv6 addresses and other configuration information, as described in Section 5.5.2 of RFC 2462. Those IPv6 nodes that do not use DHCP for address assignment can ignore the 'M' flag in Router Advertisements.
此外，在没有路由器的情况下，使用DHCP进行地址分配的IPv6节点必须启动DHCP以获取IPv6地址和其他配置信息，如RFC 2462第5.5.2节所述。那些不使用DHCP进行地址分配的IPv6节点可以忽略路由器播发中的“M”标志。
The method by which IPv6 nodes that use DHCP to obtain other configuration information can obtain other configuration information upon receipt of a Router Advertisement with the 'O' flag set is described in Section 5.5.3 of RFC 2462.
RFC 2462第5.5.3节描述了使用DHCP获取其他配置信息的IPv6节点在接收到带有“O”标志集的路由器公告时可以获取其他配置信息的方法。
Those IPv6 nodes that use DHCP to obtain other configuration information initiate DHCP for other configuration information upon receipt of a Router Advertisement with the 'O' flag set, as described in Section 5.5.3 of RFC 2462. Those IPv6 nodes that do not use DHCP for other configuration information can ignore the 'O' flag in Router Advertisements.
如RFC 2462第5.5.3节所述，使用DHCP获取其他配置信息的IPv6节点在接收到设置了“O”标志的路由器公告时，为其他配置信息启动DHCP。那些不将DHCP用于其他配置信息的IPv6节点可以忽略路由器播发中的“O”标志。
An IPv6 node can use the subset of DHCP (described in [RFC-3736]) to obtain other configuration information.
IPv6节点可以使用DHCP子集（如[RFC-3736]所述）来获取其他配置信息。
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）的节点需要从收到的路由器广告中确定其默认路由器信息和链路上前缀信息。
IPv6 nodes MAY support IPv4.
IPv6节点可能支持IPv4。
If an IPv6 node implements dual stack and tunneling, then [RFC-4213] MUST be supported.
如果IPv6节点实现双堆栈和隧道，则必须支持[RFC-4213]。
The Mobile IPv6 [RFC-3775] specification defines requirements for the following types of nodes:
移动IPv6[RFC-3775]规范定义了以下类型节点的要求：
- mobile nodes
- 移动节点
- correspondent nodes with support for route optimization
- 支持路由优化的对应节点
- home agents
- 国内代理
- all IPv6 routers
- 所有IPv6路由器
Hosts MAY support mobile node functionality described in Section 8.5 of [RFC-3775], including support of generic packet tunneling [RFC-2473] and secure home agent communications [RFC-3776].
主机可支持[RFC-3775]第8.5节所述的移动节点功能，包括支持通用分组隧道[RFC-2473]和安全归属代理通信[RFC-3776]。
Hosts SHOULD support route optimization requirements for correspondent nodes described in Section 8.2 of [RFC-3775].
主机应支持[RFC-3775]第8.2节所述对应节点的路由优化要求。
Routers SHOULD support the generic mobility-related requirements for all IPv6 routers described in Section 8.3 of [RFC-3775]. Routers MAY support the home agent functionality described in Section 8.4 of [RFC-3775], including support of [RFC-2473] and [RFC-3776].
路由器应支持[RFC-3775]第8.3节中描述的所有IPv6路由器的通用移动性相关要求。路由器可支持[RFC-3775]第8.4节所述的归属代理功能，包括对[RFC-2473]和[RFC-3776]的支持。
This section describes the specification of IPsec for the IPv6 node.
本节介绍IPv6节点的IPsec规范。
Security Architecture for the Internet Protocol [RFC-4301] MUST be supported.
必须支持互联网协议[RFC-4301]的安全体系结构。
ESP [RFC-4303] MUST be supported. AH [RFC-4302] MUST be supported.
必须支持ESP[RFC-4303]。必须支持AH[RFC-4302]。
Current IPsec RFCs specify the support of transforms and algorithms for use with AH and ESP: NULL encryption, DES-CBC, HMAC-SHA-1-96, and HMAC-MD5-96. However, "Cryptographic Algorithm Implementation Requirements For ESP And AH" [RFC-4305] contains the current set of mandatory to implement algorithms for ESP and AH. It also specifies algorithms that should be implemented because they are likely to be promoted to mandatory at some future time. IPv6 nodes SHOULD conform to the requirements in [RFC-4305], as well as the requirements specified below.
当前的IPsec RFC指定了对用于AH和ESP的转换和算法的支持：空加密、DES-CBC、HMAC-SHA-1-96和HMAC-MD5-96。但是，“ESP和AH的加密算法实施要求”[RFC-4305]包含当前一组强制要求，以实施ESP和AH的算法。它还指定了应该实现的算法，因为这些算法可能在将来某个时候升级为强制算法。IPv6节点应符合[RFC-4305]中的要求，以及以下规定的要求。
Since ESP encryption and authentication are both optional, support for the NULL encryption algorithm [RFC-2410] and the NULL authentication algorithm [RFC-4303] MUST be provided to maintain consistency with the way these services are negotiated. However, while authentication and encryption can each be NULL, they MUST NOT both be NULL. The NULL encryption algorithm is also useful for debugging.
由于ESP加密和身份验证都是可选的，因此必须提供对空加密算法[RFC-2410]和空身份验证算法[RFC-4303]的支持，以保持与这些服务协商方式的一致性。但是，虽然身份验证和加密都可以为NULL，但它们不能同时为NULL。空加密算法对于调试也很有用。
The DES-CBC encryption algorithm [RFC-2405] SHOULD NOT be supported within ESP. Security issues related to the use of DES are discussed in [DESDIFF], [DESINT], and [DESCRACK]. DES-CBC is still listed as required by the existing IPsec RFCs, but updates to these RFCs will be published in the near future. DES provides 56 bits of protection, which is no longer considered sufficient.
ESP中不应支持DES-CBC加密算法[RFC-2405]。与DES使用相关的安全问题在[DESDIFF]、[DESINT]和[DESCRACK]中讨论。DES-CBC仍然按照现有IPsec RFC的要求列出，但这些RFC的更新将在不久的将来发布。DES提供56位的保护，这不再被认为是足够的。
The use of the HMAC-SHA-1-96 algorithm [RFC-2404] within AH and ESP MUST be supported. The use of the HMAC-MD5-96 algorithm [RFC-2403] within AH and ESP MAY also be supported.
必须支持在AH和ESP中使用HMAC-SHA-1-96算法[RFC-2404]。也可支持在AH和ESP中使用HMAC-MD5-96算法[RFC-2403]。
The 3DES-CBC encryption algorithm [RFC-2451] does not suffer from the same security issues as DES-CBC, and the 3DES-CBC algorithm within ESP MUST be supported to ensure interoperability.
3DES-CBC加密算法[RFC-2451]不存在与DES-CBC相同的安全问题，必须支持ESP中的3DES-CBC算法以确保互操作性。
The AES-128-CBC algorithm [RFC-3602] MUST also be supported within ESP. AES-128 is expected to be a widely available, secure, and efficient algorithm. While AES-128-CBC is not required by the current IPsec RFCs, it is expected to become required in the future.
ESP中还必须支持AES-128-CBC算法[RFC-3602]。AES-128有望成为一种广泛可用、安全且高效的算法。虽然当前IPsec RFC不需要AES-128-CBC，但预计将来会需要它。
An implementation MUST support the manual configuration of the security key and SPI. The SPI configuration is needed in order to delineate between multiple keys.
实现必须支持安全密钥和SPI的手动配置。需要SPI配置来描述多个键之间的关系。
Key management SHOULD be supported. Examples of key management systems include IKEv2 [RFC-4306] and Kerberos; S/MIME and TLS include key management functions.
应该支持密钥管理。密钥管理系统的示例包括IKEv2[RFC-4306]和Kerberos；S/MIME和TLS包括密钥管理功能。
Where key refresh, anti-replay features of AH and ESP, or on-demand creation of Security Associations (SAs) is required, automated keying MUST be supported.
如果需要密钥刷新、AH和ESP的反重放功能或按需创建安全关联（SA），则必须支持自动密钥设置。
Key management methods for multicast traffic are also being worked on by the MSEC WG.
MSEC工作组也正在研究多播流量的密钥管理方法。
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 [RFC-2711] is an optional IPv6 Hop-by-Hop Header that is used in conjunction with some protocols (e.g., RSVP [RFC-2205] or MLD [RFC-2710]). The Router Alert option will need to be implemented whenever protocols that mandate its usage are implemented. See Section 4.6.
IPv6路由器警报选项[RFC-2711]是可选的IPv6逐跳报头，与某些协议（例如，RSVP[RFC-2205]或MLD[RFC-2710]）一起使用。路由器警报选项将需要在执行要求使用它的协议时执行。见第4.6节。
Sending Router Advertisements and processing Router Solicitation MUST be supported.
必须支持发送路由器广告和处理路由器请求。
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 MIBs SHOULD be supported by nodes that support an SNMP agent.
支持SNMP代理的节点应支持以下两个MIB。
IP Forwarding Table MIB [RFC-4292] SHOULD be supported by nodes that support an SNMP agent.
支持SNMP代理的节点应支持IP转发表MIB[RFC-4292]。
IP MIB [RFC-4293] SHOULD be supported by nodes that support an SNMP agent.
支持SNMP代理的节点应支持IP MIB[RFC-4293]。
This document does not affect the security of the Internet, but implementations of IPv6 are expected to support a minimum set of security features to ensure security on the Internet. "IP Security Document Roadmap" [RFC-2411] is important for everyone to read.
本文档不会影响Internet的安全性，但IPv6的实施预计将支持一组最低限度的安全功能，以确保Internet的安全性。“IP安全文档路线图”[RFC-2411]对每个人来说都很重要。
The security considerations in RFC 2460 state the following:
RFC 2460中的安全注意事项说明如下：
The security features of IPv6 are described in the Security Architecture for the Internet Protocol [RFC-2401].
互联网协议的安全体系结构[RFC-2401]中描述了IPv6的安全特性。
RFC 2401 has been obsoleted by RFC 4301, therefore refer RFC 4301 for the security features of IPv6.
RFC 2401已被RFC 4301淘汰，因此有关IPv6的安全功能，请参阅RFC 4301。
[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-1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC-1981]McCann，J.，Deering，S.，和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，1996年8月。
[RFC-2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC-2104]Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC-2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.
[RFC-2403]Madson，C.和R.Glenn，“HMAC-MD5-96在ESP和AH中的使用”，RFC 2403，1998年11月。
[RFC-2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[RFC-2404]Madson，C.和R.Glenn，“在ESP和AH中使用HMAC-SHA-1-96”，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-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-2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[RFC-2411]Thayer，R.，Doraswamy，N.，和R.Glenn，“IP安全文档路线图”，RFC 2411，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, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998.
[RFC-2463]Conta，A.和S.Deering，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 2463，1998年12月。
[RFC-2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998.
[RFC-2472]Haskin，D.和E.Allen，“PPP上的IP版本6”，RFC 2472，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-2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC-2671]Vixie，P.，“DNS的扩展机制（EDNS0）”，RFC 2671，1999年8月。
[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-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-3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC-3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC 3315，2003年7月。
[RFC-3363] 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.
[RFC-3363]Bush，R.，Durand，A.，Fink，B.，Gudmundsson，O.，和T.Hain，“代表域名系统（DNS）中的互联网协议版本6（IPv6）地址”，RFC 3363，2002年8月。
[RFC-3484] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", BCP 74, RFC 3584, August 2003.
[RFC-3484]Frye，R.，Levi，D.，Routhier，S.，和B.Wijnen，“互联网标准网络管理框架版本1，版本2和版本3之间的共存”，BCP 74，RFC 3584，2003年8月。
[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月。
[RFC-3590] Haberman, B., "Source Address Selection for the Multicast Listener Discovery (MLD) Protocol", RFC 3590, September 2003.
[RFC-3590]Haberman，B.，“多播侦听器发现（MLD）协议的源地址选择”，RFC 3590，2003年9月。
[RFC-3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.
[RFC-3596]Thomson，S.，Huitema，C.，Ksinant，V.，和M.Souissi，“支持IP版本6的DNS扩展”，RFC 3596，2003年10月。
[RFC-3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.
[RFC-3602]Frankel，S.，Glenn，R.，和S.Kelly，“AES-CBC密码算法及其在IPsec中的使用”，RFC 3602，2003年9月。
[RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC-3775]Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 3775，2004年6月。
[RFC-3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004.
[RFC-3776]Arkko，J.，Devarapalli，V.，和F.Dupont，“使用IPsec保护移动节点和家庭代理之间的移动IPv6信令”，RFC 3776，2004年6月。
[RFC-3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC-3810]Vida，R.和L.Costa，“IPv6多播侦听器发现版本2（MLDv2）”，RFC 3810，2004年6月。
[RFC-3879] Huitema, C. and B. Carpenter, "Deprecating Site Local Addresses", RFC 3879, September 2004.
[RFC-3879]Huitema，C.和B.Carpenter，“不推荐现场本地地址”，RFC 3879，2004年9月。
[RFC-4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, April 2006.
[RFC-4292]Haberman，B.，“IP转发表MIB”，RFC 4292，2006年4月。
[RFC-4293] Routhier, S., Ed., "Management Information Base for the Internet Protocol (IP)", RFC 4293, April 2006.
[RFC-4293]Routhier，S.，Ed.“互联网协议（IP）的管理信息库”，RFC 4293，2006年4月。
[RFC-4301] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC-4301]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 4301，2005年12月。
[RFC-4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC-4302]Kent，S.，“IP认证头”，RFC 43022005年12月。
[RFC-4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC-4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC-4305] Eastlake 3rd, D., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4305, December 2005.
[RFC-4305]Eastlake 3rd，D.，“封装安全有效载荷（ESP）和认证头（AH）的密码算法实现要求”，RFC 4305，2005年12月。
[DESDIFF] Biham, E., Shamir, A., "Differential Cryptanalysis of DES-like cryptosystems", Journal of Cryptology Vol 4, Jan 1991.
[DESDIFF]Biham，E.，Shamir，A.，“类DES密码系统的差分密码分析”，《密码学杂志》第4卷，1991年1月。
[DESCRACK] Cracking DES, O'Reilly & Associates, Sebastapol, CA 2000.
[描述]加利福尼亚州塞巴斯塔波尔市奥雷利联合公司Cracking DES，O'Reilly&Associates，2000年。
[DESINT] Bellovin, S., "An Issue With DES-CBC When Used Without Strong Integrity", Proceedings of the 32nd IETF, Danvers, MA, April 1995.
[设计]Bellovin，S.，“DES-CBC在使用时不具有强完整性的问题”，第32届IETF会议记录，马萨诸塞州丹弗斯，1995年4月。
[IPv6-RH] P. Savola, "Security of IPv6 Routing Header and Home Address Options", Work in Progress.
[IPv6 RH]P.Savola，“IPv6路由头和家庭地址选项的安全”，正在进行中。
[RFC-793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC-793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[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-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-2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[RFC-2464]克劳福德，M.，“通过以太网传输IPv6数据包”，RFC 2464，1998年12月。
[RFC-2492] Armitage, G., Schulter, P., and M. Jork, "IPv6 over ATM Networks", RFC 2492, January 1999.
[RFC-2492]Armitage，G.，Schulter，P.，和M.Jork，“ATM网络上的IPv6”，RFC 2492，1999年1月。
[RFC-2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, August 1999.
[RFC-2675]Borman，D.，Deering，S.，和R.Hinden，“IPv6巨型程序”，RFC 2675，1999年8月。
[RFC-4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC-4213]Nordmark，E.和R.Gilligan，“IPv6主机和路由器的基本转换机制”，RFC 4213，2005年10月。
[RFC-3569] Bhattacharyya, S., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003.
[RFC-3569]Bhattacharyya，S.，“源特定多播（SSM）概述”，RFC 3569，2003年7月。
[RFC-3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC-3736]Droms，R.，“IPv6的无状态动态主机配置协议（DHCP）服务”，RFC 3736，2004年4月。
[RFC-4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005.
[RFC-4001]Daniele，M.，Haberman，B.，Routhier，S.，和J.Schoenwaeld，“互联网网络地址的文本约定”，RFC 4001，2005年2月。
[RFC-4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC-4033]R.阿伦兹、R.奥斯汀、M.拉森、D.马西和S.罗斯，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[RFC-4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC-4034]R.阿伦兹、R.奥斯汀、M.拉森、M.马西和S.罗斯，“DNS安全扩展的资源记录”，RFC 4034，2005年3月。
[RFC-4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC-4035]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，2005年3月。
[RFC-4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC-4306]考夫曼，C.，编辑，“互联网密钥交换（IKEv2）协议”，RFC 4306，2005年12月。
[SSM-ARCH] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", Work in Progress.
[SSM-ARCH]H.Holbrook，B.Cain，“IP的源特定多播”，工作正在进行中。
This document was written by the IPv6 Node Requirements design team:
本文档由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]
井上Atsushi[inoue@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.
作者要感谢Ran Atkinson、Jim Bound、Brian Carpenter、Ralph Droms、Christian Huitema、Adam Machalek、Thomas Narten、Juha Ollila和Pekka Savola的评论。
Editor's Contact Information
编辑联系方式
Comments or questions regarding this document should be sent to the IPv6 Working Group mailing list (ipv6@ietf.org) or to:
有关本文档的评论或问题应发送至IPv6工作组邮件列表(ipv6@ietf.org)或：
John Loughney Nokia Research Center Itamerenkatu 11-13 00180 Helsinki Finland
芬兰赫尔辛基诺基亚研究中心11-13 00180
Phone: +358 50 483 6242
EMail: John.Loughney@Nokia.com
Phone: +358 50 483 6242
EMail: John.Loughney@Nokia.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。