Network Working Group D. Thaler
Request for Comments: 4389 M. Talwar
Category: Experimental Microsoft
C. Patel
All Play, No Work
April 2006
Network Working Group D. Thaler
Request for Comments: 4389 M. Talwar
Category: Experimental Microsoft
C. Patel
All Play, No Work
April 2006
Neighbor Discovery Proxies (ND Proxy)
邻居发现代理（ND代理）
Status of This Memo
关于下段备忘
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
Bridging multiple links into a single entity has several operational advantages. A single subnet prefix is sufficient to support multiple physical links. There is no need to allocate subnet numbers to the different networks, simplifying management. Bridging some types of media requires network-layer support, however. This document describes these cases and specifies the IP-layer support that enables bridging under these circumstances.
将多个链路桥接成单个实体具有若干操作优势。单个子网前缀足以支持多个物理链路。无需为不同的网络分配子网编号，从而简化了管理。但是，桥接某些类型的媒体需要网络层支持。本文档描述了这些情况，并指定了在这些情况下启用桥接的IP层支持。
Table of Contents
目录
1. Introduction ....................................................3
1.1. SCENARIO 1: Wireless Upstream ..............................3
1.2. SCENARIO 2: PPP Upstream ...................................4
1.3. Inapplicable Scenarios .....................................5
2. Terminology .....................................................5
3. Requirements ....................................................5
3.1. Non-requirements ...........................................6
4. Proxy Behavior ..................................................7
4.1. Forwarding Packets .........................................7
4.1.1. Sending Packet Too Big Messages .....................8
4.1.2. Proxying Packets with Link-Layer Addresses ..........8
4.1.3. IPv6 ND Proxying ....................................9
4.1.3.1. ICMPv6 Neighbor Solicitations ..............9
4.1.3.2. ICMPv6 Neighbor Advertisements .............9
4.1.3.3. ICMPv6 Router Advertisements ...............9
4.1.3.4. ICMPv6 Redirects ..........................10
4.2. Originating Packets .......................................10
5. Example ........................................................11
6. Loop Prevention ................................................12
7. Guidelines to Proxy Developers .................................12
8. IANA Considerations ............................................13
9. Security Considerations ........................................13
10. Acknowledgements ..............................................14
11. Normative References ..........................................14
12. Informative References ........................................15
Appendix A: Comparison with Naive RA Proxy ........................16
1. Introduction ....................................................3
1.1. SCENARIO 1: Wireless Upstream ..............................3
1.2. SCENARIO 2: PPP Upstream ...................................4
1.3. Inapplicable Scenarios .....................................5
2. Terminology .....................................................5
3. Requirements ....................................................5
3.1. Non-requirements ...........................................6
4. Proxy Behavior ..................................................7
4.1. Forwarding Packets .........................................7
4.1.1. Sending Packet Too Big Messages .....................8
4.1.2. Proxying Packets with Link-Layer Addresses ..........8
4.1.3. IPv6 ND Proxying ....................................9
4.1.3.1. ICMPv6 Neighbor Solicitations ..............9
4.1.3.2. ICMPv6 Neighbor Advertisements .............9
4.1.3.3. ICMPv6 Router Advertisements ...............9
4.1.3.4. ICMPv6 Redirects ..........................10
4.2. Originating Packets .......................................10
5. Example ........................................................11
6. Loop Prevention ................................................12
7. Guidelines to Proxy Developers .................................12
8. IANA Considerations ............................................13
9. Security Considerations ........................................13
10. Acknowledgements ..............................................14
11. Normative References ..........................................14
12. Informative References ........................................15
Appendix A: Comparison with Naive RA Proxy ........................16
In the IPv4 Internet today, it is common for Network Address Translators (NATs) [NAT] to be used to easily connect one or more leaf links to an existing network without requiring any coordination with the network service provider. Since NATs modify IP addresses in packets, they are problematic for many IP applications. As a result, it is desirable to address the problem (for both IPv4 and IPv6) without the need for NATs, while still maintaining the property that no explicit cooperation from the router is needed.
在今天的IPv4互联网中，通常使用网络地址转换器（NAT）[NAT]轻松地将一个或多个叶链接连接到现有网络，而无需与网络服务提供商进行任何协调。由于NAT修改数据包中的IP地址，因此对于许多IP应用程序来说，NAT都是有问题的。因此，在不需要NAT的情况下解决问题（IPv4和IPv6）是可取的，同时仍然保持不需要来自路由器的明确合作的属性。
One common solution is IEEE 802 bridging, as specified in [BRIDGE]. It is expected that whenever possible links will be bridged at the link layer using classic bridge technology [BRIDGE] as opposed to using the mechanisms herein. However, classic bridging at the data-link layer has the following limitations (among others):
一种常见的解决方案是IEEE 802桥接，如[BRIDGE]中所述。预计只要有可能，将使用经典桥接技术[桥接]在链路层桥接链路，而不是使用本文中的机制。但是，在经典数据链路层有以下限制：
o It requires the ports to support promiscuous mode.
o 它要求端口支持混杂模式。
o It requires all ports to support the same type of link-layer addressing (in particular, IEEE 802 addressing).
o 它要求所有端口支持相同类型的链路层寻址（特别是IEEE 802寻址）。
As a result, two common scenarios, described below, are not solved, and it is these two scenarios we specifically target in this document. While the mechanism described herein may apply to other scenarios as well, we will concentrate our discussion on these two scenarios.
因此，下面描述的两种常见场景没有得到解决，我们在本文档中专门针对这两种场景。虽然本文描述的机制也适用于其他场景，但我们将集中讨论这两种场景。
The following figure illustrates a likely example:
下图说明了一个可能的示例：
| +-------+ +--------+
local |Ethernet | | Wireless | Access |
+---------+ A +-))) (((-+ +--> rest of network
hosts | | | link | Point |
| +-------+ +--------+
| +-------+ +--------+
local |Ethernet | | Wireless | Access |
+---------+ A +-))) (((-+ +--> rest of network
hosts | | | link | Point |
| +-------+ +--------+
In this scenario, the access point has assigned an IPv6 subnet prefix to the wireless link, and uses link-layer encryption so that wireless clients may not see each other's data.
在这种情况下，接入点已将IPv6子网前缀分配给无线链路，并使用链路层加密，以便无线客户端可能看不到彼此的数据。
Classic bridging requires the bridge (node A in the above diagram) to be in promiscuous mode. In this wireless scenario, A cannot put its wireless interface into promiscuous mode, since one wireless node cannot see traffic to/from other wireless nodes.
经典桥接要求桥接器（上图中的节点A）处于混杂模式。在此无线场景中，A无法将其无线接口置于混杂模式，因为一个无线节点无法看到与其他无线节点之间的通信量。
IPv4 Address Resolution Protocol (ARP) proxying has been used for some years to solve this problem without involving NAT or requiring any change to the access point or router. In this document, we describe equivalent functionality for IPv6 to remove this incentive to deploy NATs in IPv6.
IPv4地址解析协议（ARP）代理多年来一直用于解决此问题，而不涉及NAT或要求对接入点或路由器进行任何更改。在本文档中，我们描述了IPv6的等效功能，以消除在IPv6中部署NAT的动机。
We also note that Prefix Delegation [PD] could also be used to solve this scenario. There are, however, two disadvantages to this. First, if an implementation already supports IPv4 ARP proxying (which is indeed the case in a number of implementations today), then IPv6 Prefix Delegation would result in separate IPv6 subnets on either side of the device, while a single IPv4 subnet would span both segments. This topological discrepancy can complicate applications and protocols that use the concept of a local subnet. Second, the extent to which Prefix Delegation is supported for any particular subscriber class is up to the service provider. Hence, there is no guarantee that Prefix Delegation will work without explicit configuration or additional charge. Bridging, on the other hand, allows the device to work with zero configuration, regardless of the service provider's policies, just as a NAT does. Hence bridging avoids the incentive to NAT IPv6 just to avoid paying for, or requiring configuration to get, another prefix.
我们还注意到，前缀委托[PD]也可用于解决此场景。然而，这有两个缺点。首先，如果一个实现已经支持IPv4 ARP代理（这在今天的许多实现中确实是如此），那么IPv6前缀委派将在设备的任一侧产生单独的IPv6子网，而单个IPv4子网将跨越两个网段。这种拓扑差异会使使用本地子网概念的应用程序和协议复杂化。其次，对任何特定订户类支持前缀委托的程度取决于服务提供商。因此，不能保证前缀委托在没有明确配置或额外收费的情况下工作。另一方面，桥接允许设备以零配置工作，而不管服务提供商的策略如何，就像NAT一样。因此，桥接避免了NAT IPv6的动机，仅仅是为了避免支付费用或要求配置获得另一个前缀。
The following figure illustrates another likely example:
下图说明了另一个可能的示例：
| +-------+ +--------+
local |Ethernet | | PPP link | |
+---------+ A +-----------+ Router +--> rest of network
hosts | | | | |
| +-------+ +--------+
| +-------+ +--------+
local |Ethernet | | PPP link | |
+---------+ A +-----------+ Router +--> rest of network
hosts | | | | |
| +-------+ +--------+
In this scenario, the router has assigned a /64 to the PPP link and advertises it in an IPv6 Router Advertisement.
在这种情况下，路由器已将a/64分配给PPP链路，并在IPv6路由器播发中播发。
Classic bridging does not support non-802 media. The PPP Bridging Control Protocol [BCP] defines a mechanism for supporting bridging over PPP, but it requires both ends to be configured to support it. Hence IPv4 connectivity is often solved by making the proxy (node A in the above diagram) be a NAT or an IPv4 ARP proxy. This document specifies a solution for IPv6 that does not involve NAT or require any change to the router.
经典桥接不支持非802媒体。PPP桥接控制协议[BCP]定义了一种支持PPP桥接的机制，但它需要配置两端以支持它。因此，IPv4连接通常通过将代理（上图中的节点A）设置为NAT或IPv4 ARP代理来解决。本文档指定了一种不涉及NAT或不需要对路由器进行任何更改的IPv6解决方案。
This document is not applicable to scenarios with loops in the physical topology, or where routers exist on multiple segments. These cases are detected and proxying is disabled (see Section 6).
本文档不适用于物理拓扑中存在环路或路由器位于多个网段上的场景。检测到这些情况并禁用代理（参见第6节）。
In addition, this document is not appropriate for scenarios where classic bridging can be applied, or when configuration of the router can be done.
此外，本文档不适用于可以应用经典桥接的场景，或者可以完成路由器配置的场景。
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 BCP 14, RFC 2119 [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[关键词]中的描述进行解释。
The term "proxy interface" will be used to refer to an interface (which could itself be a bridge interface) over which network-layer proxying is done as defined herein.
术语“代理接口”将用于指按照本文定义在其上进行网络层代理的接口（其本身可以是网桥接口）。
In this document, we make no distinction between a "link" (in the classic IPv6 sense) and a "subnet". We use the term "segment" to apply to a bridged component of the link.
在本文档中，我们不区分“链路”（在经典IPv6意义上）和“子网”。我们使用术语“段”来应用于链路的桥接组件。
Finally, while it is possible that functionality equivalent to that described herein may be achieved by nodes that do not fulfill all the requirements in [NODEREQ], in the remainder of this document we will describe behavior in terms of an IPv6 node as defined in that document.
最后，虽然不满足[NODEREQ]中所有要求的节点可能实现与本文所述功能等效的功能，但在本文档的其余部分中，我们将描述该文档中定义的IPv6节点的行为。
Proxy behavior is designed with the following requirements in mind:
代理行为的设计考虑了以下要求：
o Support connecting multiple segments with a single subnet prefix.
o 支持使用单个子网前缀连接多个网段。
o Support media that cannot be bridged at the link layer.
o 支持无法在链路层桥接的介质。
o Do not require any changes to existing routers. That is, routers on the subnet may be unaware that the subnet is being bridged.
o 不需要对现有路由器进行任何更改。也就是说，子网上的路由器可能不知道子网正在桥接。
o Provide full connectivity between all nodes in the subnet. For example, if there are existing nodes (such as any routers on the subnet) that have addresses in the subnet prefix, adding a proxy must allow bridged nodes to have full connectivity with existing nodes on the subnet.
o 在子网中的所有节点之间提供完全连接。例如，如果存在子网前缀中包含地址的现有节点（如子网上的任何路由器），则添加代理必须允许桥接节点与子网上的现有节点完全连接。
o Prevent loops.
o 防止循环。
o Also work in the absence of any routers.
o 也可以在没有任何路由器的情况下工作。
o Support nodes moving between segments. For example, a node should be able to keep its address without seeing its address as a duplicate due to any cache maintained at the proxy.
o 支持节点在线段之间移动。例如，节点应该能够保留其地址，而不会因为代理服务器上维护的任何缓存而将其地址视为重复地址。
o Allow dynamic addition of a proxy without adversely disrupting the network.
o 允许动态添加代理，而不会对网络造成负面影响。
o The proxy behavior should not break any existing classic bridges in use on a network segment.
o 代理行为不应破坏网段上使用的任何现有经典网桥。
The following items are not considered requirements, as they are not met by classic bridges:
以下项目不被视为要求，因为经典桥梁不满足这些要求：
o Show up as a hop in a traceroute.
o 在追踪路线中显示为跳跃。
o Use the shortest path between two nodes on different segments.
o 使用不同线段上两个节点之间的最短路径。
o Be able to use all available interfaces simultaneously. Instead, bridging technology relies on disabling redundant interfaces to prevent loops.
o 能够同时使用所有可用接口。相反，桥接技术依靠禁用冗余接口来防止循环。
o Support connecting media on which Neighbor Discovery is not possible. For example, some technologies such as [6TO4] use an algorithmic mapping from IPv6 address to the underlying link-layer (IPv4 in this case) address, and hence cannot support bridging arbitrary IP addresses.
o 支持连接无法发现邻居的媒体。例如，[6TO4]等一些技术使用从IPv6地址到底层链路层（本例中为IPv4）地址的算法映射，因此无法支持桥接任意IP地址。
The following additional items are not considered requirements for this document:
以下附加项目不视为本文件的要求：
o Support network-layer protocols other than IPv6. We do not preclude such support, but it is not specified in this document.
o 支持IPv6以外的网络层协议。我们不排除此类支持，但本文件中未规定。
o Support Redirects for off-subnet destinations that point to a router on a different segment from the redirected host. While this scenario may be desirable, no solution is currently known that does not have undesirable side effects outside the subnet. As a result, this scenario is outside the scope of this document.
o 支持指向与重定向主机位于不同网段上的路由器的子网外目标的重定向。虽然这种情况可能是可取的，但目前还没有一种解决方案在子网之外不会产生不良副作用。因此，此场景超出了本文档的范围。
Network-layer support for proxying between multiple interfaces SHOULD be used only when classic bridging is not possible.
仅当无法实现经典桥接时，才应使用多个接口之间代理的网络层支持。
When a proxy interface comes up, the node puts it in "all-multicast" mode so that it will receive all multicast packets. It is common for interfaces not to support full promiscuous mode (e.g., on a wireless client), but all-multicast mode is generally still supported.
当代理接口出现时，节点将其置于“所有多播”模式，以便接收所有多播数据包。接口通常不支持完全混杂模式（例如，在无线客户端上），但通常仍然支持所有多播模式。
As with all other interfaces, IPv6 maintains a neighbor cache for each proxy interface, which will be used as described below.
与所有其他接口一样，IPv6为每个代理接口维护一个邻居缓存，如下所述使用。
When a packet from any IPv6 source address other than the unspecified address is received on a proxy interface, the neighbor cache of that interface SHOULD be consulted to find an entry for the source IPv6 address. If no entry exists, one is created in the STALE state.
当在代理接口上接收到来自除未指定地址以外的任何IPv6源地址的数据包时，应咨询该接口的邻居缓存以查找源IPv6地址的条目。如果不存在条目，则会在过时状态下创建一个条目。
When any IPv6 packet is received on a proxy interface, it must be parsed to see whether it is known to be of a type that negotiates link-layer addresses. This document covers the following types: Neighbor Solicitations, Neighbor Advertisements, Router Advertisements, and Redirects. These packets are ones that can carry link-layer addresses, and hence must be proxied (as described below) so that packets between nodes on different segments can be received by the proxy and have the correct link-layer address type on each segment.
当在代理接口上接收到任何IPv6数据包时，必须对其进行解析，以查看它是否属于协商链路层地址的类型。本文档涵盖以下类型：邻居请求、邻居播发、路由器播发和重定向。这些数据包可以携带链路层地址，因此必须进行代理（如下所述），以便代理可以接收不同网段上节点之间的数据包，并在每个网段上具有正确的链路层地址类型。
When any other IPv6 multicast packet is received on a proxy interface, in addition to any normal IPv6 behavior such as being delivered locally, it is forwarded unchanged (other than using a new link-layer header) out all other proxy interfaces on the same link. (As specified in [BRIDGE], the proxy may instead support multicast learning and filtering, but this is OPTIONAL.) In particular, the IPv6 Hop Limit is not updated, and no ICMP errors (except as noted in Section 4.1.1 below) are sent as a result of attempting this forwarding.
当在代理接口上接收到任何其他IPv6多播数据包时，除了任何正常的IPv6行为（如在本地传送）外，该数据包将在同一链路上的所有其他代理接口上进行转发（使用新的链路层报头除外）。（如[BRIDGE]中所述，代理可以支持多播学习和过滤，但这是可选的。）特别是，IPv6跃点限制不会更新，并且不会因尝试此转发而发送ICMP错误（以下第4.1.1节中所述除外）。
When any other IPv6 unicast packet is received on a proxy interface, if it is not locally destined then it is forwarded unchanged (other than using a new link-layer header) to the proxy interface for which the next hop address appears in the neighbor cache. Again the IPv6 Hop Limit is not updated, and no ICMP errors (except as noted in Section 4.1.1 below) are sent as a result of attempting this forwarding. To choose a proxy interface to forward to, the neighbor cache is consulted, and the interface with the neighbor entry in the "best" state is used. In order of least to most preferred, the states (per [ND]) are INCOMPLETE, STALE, DELAY, PROBE, REACHABLE. A packet is never forwarded back out the same interface on which it arrived; such a packet is instead silently dropped.
当在代理接口上接收到任何其他IPv6单播数据包时，如果该数据包不是以本地为目的地，则该数据包将被不加更改地转发（使用新的链路层报头除外）到代理接口，该代理接口的下一跳地址将显示在邻居缓存中。同样，不会更新IPv6跃点限制，并且不会因尝试此转发而发送ICMP错误（以下第4.1.1节中指出的除外）。要选择要转发到的代理接口，请查阅邻居缓存，并使用邻居条目处于“最佳”状态的接口。按照从最小到最优选的顺序，状态（per[ND]）是不完整、过时、延迟、探测、可到达的。数据包永远不会被转发回它到达的同一接口；这样的数据包会被悄悄地丢弃。
If no cache entry exists (as may happen if the proxy has previously evicted the cache entry or if the proxy is restarted), the proxy SHOULD queue the packet and initiate Neighbor Discovery as if the packet were being locally generated. The proxy MAY instead silently drop the packet. In this case, the entry will eventually be re-created when the sender re-attempts Neighbor Discovery.
如果不存在缓存项（如果代理先前已退出缓存项或代理重新启动，则可能发生这种情况），则代理应将数据包排队并启动邻居发现，就像数据包是本地生成的一样。代理可以改为静默地丢弃数据包。在这种情况下，当发送方重新尝试邻居发现时，最终将重新创建条目。
The link-layer header and the link-layer address within the payload for each forwarded packet will be modified as follows:
每个转发包的有效载荷内的链路层报头和链路层地址将修改如下：
1) The source address will be the address of the outgoing interface.
1) 源地址将是传出接口的地址。
2) The destination address will be the address in the neighbor entry corresponding to the destination IPv6 address.
2) 目标条目中的IPv6地址将与目标地址中的地址相对应。
3) The link-layer address within the payload is substituted with the address of the outgoing interface.
3) 有效负载内的链路层地址被传出接口的地址替换。
Whenever any IPv6 packet is to be forwarded out an interface whose MTU is smaller than the size of the packet, the ND proxy drops the packet and sends a Packet Too Big message back to the source, as described in [ICMPv6].
每当任何IPv6数据包被转发出MTU小于数据包大小的接口时，ND代理就会丢弃该数据包，并将数据包过大的消息发送回源，如[ICMPv6]中所述。
Once it is determined that the packet is either multicast or else is not locally destined (if unicast), the special types enumerated above (ARP, etc.) that carry link-layer addresses are handled by generating a proxy packet that contains the proxy's link-layer address on the outgoing interface instead. Such link-layer addresses occur in the
一旦确定包是多播的或不是本地目的地的（如果是单播的），则通过在传出接口上生成包含代理的链路层地址的代理包来处理上面列举的携带链路层地址的特殊类型（ARP等）。这样的链路层地址出现在
link-layer header itself, as well as in the payloads of some protocols. As with all forwarded packets, the link-layer header is new.
链路层报头本身，以及某些协议的有效负载。与所有转发的数据包一样，链路层报头是新的。
Section 4.1.3 enumerates the currently known cases where link-layer addresses must be changed in payloads. For guidance on handling future protocols, Section 7, "Guidelines to Proxy Developers", describes the scenarios in which the link-layer address substitution in the payload should be performed. Note that any change to the length of a proxied packet, such as when the link-layer address length changes, will require a corresponding change to the IPv6 Payload Length field.
第4.1.3节列举了当前已知的有效载荷中必须更改链路层地址的情况。关于处理未来协议的指南，第7节“代理开发人员指南”描述了应在有效负载中执行链路层地址替换的场景。请注意，对代理数据包长度的任何更改（例如当链路层地址长度更改时）都需要对IPv6有效负载长度字段进行相应更改。
When any IPv6 packet is received on a proxy interface, it must be parsed to see whether it is known to be one of the following types: Neighbor Solicitation, Neighbor Advertisement, Router Advertisement, or Redirect.
当在代理接口上接收到任何IPv6数据包时，必须对其进行分析，以确定其是否为以下类型之一：邻居请求、邻居播发、路由器播发或重定向。
If the received packet is an ICMPv6 Neighbor Solicitation (NS), the NS is processed locally as described in Section 7.2.3 of [ND] but no NA is generated immediately. Instead the NS is proxied as described above and the NA will be proxied when it is received. This ensures that the proxy does not interfere with hosts moving from one segment to another since it never responds to an NS based on its own cache.
如果接收到的数据包是ICMPv6邻居请求（NS），则按照[ND]第7.2.3节所述在本地处理NS，但不会立即生成NA。相反，如上所述代理NS，并且当接收到NA时代理NA。这确保了代理不会干扰主机从一个网段移动到另一个网段，因为它从不基于自己的缓存响应NS。
If the received packet is an ICMPv6 Neighbor Advertisement (NA), the neighbor cache on the receiving interface is first updated as if the NA were locally destined, and then the NA is proxied as described in 4.1.2 above.
如果接收到的数据包是ICMPv6邻居播发（NA），则首先更新接收接口上的邻居缓存，如同NA是本地目的地一样，然后按照上述4.1.2所述代理NA。
The following special processing is done for IPv6 Router Advertisements (RAs).
对IPv6路由器广告（RAs）执行以下特殊处理。
A new "Proxy" bit is defined in the existing Router Advertisement flags field as follows:
在现有路由器广告标志字段中定义了一个新的“代理”位，如下所示：
+-+-+-+-+-+-+-+-+
|M|O|H|Prf|P|Rsv|
+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
|M|O|H|Prf|P|Rsv|
+-+-+-+-+-+-+-+-+
where "P" indicates the location of the Proxy bit, and "Rsv" indicates the remaining reserved bits.
其中，“P”表示代理位的位置，“Rsv”表示剩余的保留位。
The proxy determines an "upstream" proxy interface, typically through a (zero-configuration) physical choice dictated by the scenario (see Scenarios 1 and 2 above), or through manual configuration.
代理通常通过场景指定的（零配置）物理选择（参见上面的场景1和场景2）或手动配置来确定“上游”代理接口。
When an RA with the P bit clear arrives on the upstream interface, the P bit is set when the RA is proxied out all other ("downstream") proxy interfaces (see Section 6).
当具有P位清除的RA到达上游接口时，当RA被代理出所有其他（“下游”）代理接口时，P位被设置（见第6节）。
If an RA with the P bit set has arrived on a given interface (including the upstream interface) within the last 60 minutes, that interface MUST NOT be used as a proxy interface; i.e., proxy functionality is disabled on that interface.
如果具有P位集的RA在过去60分钟内到达给定接口（包括上游接口），则该接口不得用作代理接口；i、 例如，在该接口上禁用代理功能。
Furthermore, if any RA (regardless of the value of the P bit) has arrived on a "downstream" proxy interface within the last 60 minutes, that interface MUST NOT be used as a proxy interface.
此外，如果任何RA（无论P位的值如何）在过去60分钟内到达“下游”代理接口，则该接口不得用作代理接口。
The RA is processed locally as well as proxied as described in Section 4.1.2, unless such proxying is disabled as noted above.
RA按照第4.1.2节所述进行本地处理和代理，除非如上所述禁用代理。
If the received packet is an ICMPv6 Redirect message, then the proxied packet should be modified as follows. If the proxy has a valid (i.e., not INCOMPLETE) neighbor entry for the target address on the same interface as the redirected host, then the Target Link-Layer Address (TLLA) option in the proxied Redirect simply contains the link-layer address of the target as found in the proxy's neighbor entry, since the redirected host may reach the target address directly. Otherwise, if the proxy has a valid neighbor entry for the target address on some other interface, then the TLLA option in the proxied packet contains the link-layer address of the proxy on the sending interface, since the redirected host must reach the target address through the proxy. Otherwise, the proxy has no valid neighbor entry for the target address, and the proxied packet contains no TLLA option, which will cause the redirected host to perform Neighbor Discovery for the target address.
如果接收到的数据包是ICMPv6重定向消息，则应按如下方式修改代理数据包。如果代理在与重定向主机相同的接口上具有目标地址的有效（即不完整）邻居条目，则代理重定向中的目标链路层地址（TLLA）选项仅包含在代理的邻居条目中找到的目标链路层地址，因为重定向的主机可能直接到达目标地址。否则，如果代理在某些其他接口上具有目标地址的有效邻居条目，则代理数据包中的TLLA选项包含发送接口上代理的链路层地址，因为重定向主机必须通过代理到达目标地址。否则，代理没有目标地址的有效邻居条目，并且代理的数据包不包含TLLA选项，这将导致重定向的主机对目标地址执行邻居发现。
Locally originated packets that are sent on a proxy interface also follow the same rules as packets received on a proxy interface. If no neighbor entry exists when a unicast packet is to be locally originated, an interface can be chosen in any implementation-specific fashion. Once the neighbor is resolved, the actual interface will be
在代理接口上发送的来自本地的数据包也遵循与在代理接口上接收的数据包相同的规则。如果在本地发起单播数据包时不存在邻居条目，则可以以任何特定于实现的方式选择接口。一旦解析了邻居，实际接口将被删除
discovered and the packet will be sent on that interface. When a multicast packet is to be locally originated, an interface can be chosen in any implementation-specific fashion, and the packet will then be forwarded out other proxy interfaces on the same link as described in Section 4.1 above.
发现并在该接口上发送数据包。当一个多播数据包在本地发起时，可以以任何特定于实现的方式选择一个接口，然后该数据包将被转发到同一链路上的其他代理接口，如上文第4.1节所述。
Consider the following topology, where A and B are nodes on separate segments which are connected by a proxy P:
考虑下面的拓扑结构，其中A和B是由代理P连接的单独的段上的节点：
A---|---P---|---B
a p1 p2 b
A---|---P---|---B
a p1 p2 b
A and B have link-layer addresses a and b, respectively. P has link-layer addresses p1 and p2 on the two segments. We now walk through the actions that happen when A attempts to send an initial IPv6 packet to B.
A和B分别具有链路层地址A和B。P在两个段上具有链路层地址p1和p2。现在，我们将介绍A尝试向B发送初始IPv6数据包时发生的操作。
A first does a route lookup on the destination address B. This matches the on-link subnet prefix, and a destination cache entry is created as well as a neighbor cache entry in the INCOMPLETE state. Before the packet can be sent, A needs to resolve B's link-layer address and sends a Neighbor Solicitation (NS) to the solicited-node multicast address for B. The Source Link-Layer Address (SLLA) option in the solicitation contains A's link-layer address.
A首先在目标地址B上执行路由查找。这与链路子网前缀匹配，并创建目标缓存项以及处于不完整状态的邻居缓存项。在发送数据包之前，A需要解析B的链路层地址，并向B的请求节点多播地址发送邻居请求（NS）。请求中的源链路层地址（SLLA）选项包含A的链路层地址。
P receives the solicitation (since it is receiving all link-layer multicast packets) and processes it as it would any multicast packet by forwarding it out to other segments on the link. However, before actually sending the packet, it determines if the packet being sent is one that requires proxying. Since it is an NS, it creates a neighbor entry for A on interface 1 and records its link-layer address. It also creates a neighbor entry for B (on an arbitrary proxy interface) in the INCOMPLETE state. Since the packet is multicast, P then needs to proxy the NS out all other proxy interfaces on the subnet. Before sending the packet out interface 2, it replaces the link-layer address in the SLLA option with its own link-layer address, p2.
P接收请求（因为它正在接收所有链路层多播数据包），并通过将其转发到链路上的其他段来像处理任何多播数据包一样对其进行处理。但是，在实际发送数据包之前，它会确定所发送的数据包是否需要代理。由于它是一个NS，它为接口1上的创建一个邻居条目，并记录其链路层地址。它还为处于未完成状态的B（在任意代理接口上）创建一个邻居条目。由于数据包是多播的，因此P需要将NS代理出子网上的所有其他代理接口。在发送数据包出接口2之前，它用自己的链路层地址p2替换SLLA选项中的链路层地址。
B receives this NS, processing it as usual. Hence it creates a neighbor entry for A mapping it to the link-layer address p2. It responds with a Neighbor Advertisement (NA) sent to A containing B's link-layer address b. The NA is sent using A's neighbor entry, i.e., to the link-layer address p2.
B收到这个NS，像往常一样处理它。因此，它创建一个邻居条目，用于将其映射到链路层地址p2。它用发送到a的邻居公告（NA）进行响应，其中包含B的链路层地址B。NA使用A的邻居条目发送，即发送到链路层地址p2。
The NA is received by P, which then processes it as it would any unicast packet; i.e., it forwards this out interface 1, based on the neighbor cache. However, before actually sending the packet out, it inspects it to determine if the packet being sent is one that requires proxying. Since it is an NA, it updates its neighbor entry for B to be REACHABLE and records the link-layer address b. P then replaces the link-layer address in the TLLA option with its own link-layer address on the outgoing interface, p1. The packet is then sent out interface 1.
NA由P接收，然后P像处理任何单播分组一样对其进行处理；i、 例如，它根据邻居缓存转发该输出接口1。但是，在实际发送数据包之前，它会检查数据包以确定发送的数据包是否需要代理。由于它是一个NA，它会更新其邻居条目以使B可访问，并记录链路层地址B。然后，P将TLLA选项中的链路层地址替换为传出接口p1上自己的链路层地址。然后，数据包被发送到接口1。
A receives this NA, processing it as usual. Hence it creates a neighbor entry for B on interface 2 in the REACHABLE state and records the link-layer address p1.
A接收此NA，并像往常一样处理它。因此，它在可到达状态下为接口2上的B创建一个邻居条目，并记录链路层地址p1。
An implementation MUST ensure that loops are prevented by using the P bit in RAs as follows. The proxy determines an "upstream" proxy interface, typically through a (zero-configuration) physical choice dictated by the scenario (see Scenarios 1 and 2 above), or through manual configuration. As described in Section 4.1.3.3, only the upstream interface is allowed to receive RAs, and never from other proxies. Proxy functionality is disabled on an interface otherwise. Finally, a proxy MUST wait until it has sent two P bit RAs on a given "downstream" interface before it enables forwarding on that interface.
实现必须确保通过使用RAs中的P位来防止循环，如下所示。代理通常通过场景指定的（零配置）物理选择（参见上面的场景1和场景2）或手动配置来确定“上游”代理接口。如第4.1.3.3节所述，仅允许上游接口接收RAs，不得从其他代理接收RAs。否则，将在接口上禁用代理功能。最后，代理必须等到在给定的“下游”接口上发送了两个P位RAs之后，才能在该接口上启用转发。
Proxy developers will have to accommodate protocols or protocol options (for example, new ICMP messages) that are developed in the future, or protocols that are not mentioned in this document (for example, proprietary protocols). This section prescribes guidelines that can be used by proxy developers to accommodate protocols that are not mentioned herein.
代理开发人员必须适应未来开发的协议或协议选项（例如，新的ICMP消息），或本文档中未提及的协议（例如，专有协议）。本节规定了代理开发人员可用于适应本文未提及的协议的指南。
1) If a link-layer address carried in the payload of the protocol can be used in the link-layer header of future messages, then the proxy should substitute it with its own address. For example, the link-layer address in NA messages is used in the link-layer header for future messages, and, hence, the proxy substitutes it with its own address.
1) 如果协议有效负载中携带的链路层地址可用于未来消息的链路层报头，则代理应将其替换为自己的地址。例如，NA消息中的链路层地址用于将来消息的链路层报头中，因此，代理将其替换为自己的地址。
For multicast packets, the link-layer address substituted within the payload will be different for each outgoing interface.
对于多播数据包，有效负载内替换的链路层地址对于每个传出接口都是不同的。
2) If the link-layer address in the payload of the protocol will never be used in any link-layer header, then the proxy should not substitute it with its own address. No special actions are required for supporting these protocols. For example, [DHCPv6] is in this category.
2) 如果协议有效负载中的链路层地址永远不会在任何链路层头中使用，则代理不应将其替换为自己的地址。支持这些协议不需要采取特殊行动。例如，[DHCPv6]属于此类。
This document defines a new bit in the RA flags (the P bit). There is currently no registration procedure for such bits, so IANA should not take any action.
本文档在RA标志中定义了一个新位（P位）。目前没有此类BIT的注册程序，因此IANA不应采取任何行动。
Unsecured Neighbor Discovery has a number of security issues, which are discussed in detail in [PSREQ]. RFC 3971 [SEND] defines security mechanisms that can protect Neighbor Discovery.
不安全的邻居发现有许多安全问题，这些问题将在[PSREQ]中详细讨论。RFC 3971[SEND]定义了可以保护邻居发现的安全机制。
Proxies are susceptible to the same kind of security issues that plague hosts using unsecured Neighbor Discovery. These issues include hijacking traffic and denial-of-service within the subnet. Malicious nodes within the subnet can take advantage of this property, and hijack traffic. In addition, a Neighbor Discovery proxy is essentially a legitimate man-in-the-middle, which implies that there is a need to distinguish proxies from unwanted man-in-the-middle attackers.
代理易受使用不安全邻居发现的主机所面临的相同类型的安全问题的影响。这些问题包括子网内的劫持流量和拒绝服务。子网内的恶意节点可以利用此属性劫持流量。此外，邻居发现代理本质上是一个合法的中间人，这意味着需要区分代理和不需要的中间人攻击者。
This document does not introduce any new mechanisms for the protection of proxy Neighbor Discovery. That is, it does not provide a mechanism from authorizing certain devices to act as proxies, and it does not provide extensions to SEND to make it possible to use both SEND and proxies at the same time. We note that RFC 2461 [ND] already defines the ability to proxy Neighbor Advertisements, and extensions to SEND are already needed to cover that case, independent of this document.
本文档不介绍任何新的代理邻居发现保护机制。也就是说，它不提供授权某些设备作为代理的机制，也不提供发送扩展以使同时使用发送和代理成为可能。我们注意到RFC2461[ND]已经定义了代理邻居广告的能力，并且已经需要发送扩展来覆盖这种情况，这与本文档无关。
Note also that the use of proxy Neighbor Discovery may render it impossible to use SEND both on the leaf subnet and on the external subnet. This is because the modifications performed by the proxy will invalidate the RSA Signature Option in a secured Neighbor Discovery message, and cause SEND-capable nodes to either discard the messages or treat them as unsecured. The latter is the desired operation when SEND is used together with this specification, and it ensures that SEND nodes within this environment can selectively downgrade themselves to unsecure Neighbor Discovery when proxies are present.
还请注意，使用代理邻居发现可能会导致无法在叶子网和外部子网上同时使用SEND。这是因为代理执行的修改将使安全邻居发现消息中的RSA签名选项无效，并导致支持发送的节点放弃消息或将其视为不安全消息。当SEND与此规范一起使用时，后者是所需的操作，它确保此环境中的SEND节点可以在存在代理时选择性地将自己降级为不安全的邻居发现。
In the following, we outline some potential paths to follow when defining a secure proxy mechanism.
在下文中，我们概述了定义安全代理机制时要遵循的一些潜在路径。
It is reasonable for nodes on the leaf subnet to have a secure relationship with the proxy and to accept ND packets either from the owner of a specific address (normal SEND) or from a trusted proxy that it can verify (see below).
叶子网上的节点与代理具有安全关系，并接受来自特定地址所有者（正常发送）或可验证的可信代理（见下文）的ND数据包是合理的。
For nodes on the external subnet, there is a trade-off between security (where all nodes have a secure relationship with the proxy) and privacy (where no nodes are aware that the proxy is a proxy). In the case of a point-to-point external link (Scenario 2), however, SEND may not be a requirement on that link.
对于外部子网上的节点，在安全性（所有节点都与代理具有安全关系）和隐私性（没有节点知道代理是代理）之间存在权衡。但是，在点对点外部链路（场景2）的情况下，该链路上可能不需要发送。
Verifying that ND packets come from a trusted proxy requires an extension to the SEND protocol and is left for future work [SPND], but is similar to the problem of securing Router Advertisements that is supported today. For example, a rogue node can send a Router Advertisement to cause a proxy to disable its proxy behavior, and hence cause denial-of-service to other nodes; this threat is covered in Section 4.2.1 of [PSREQ].
验证ND数据包是否来自受信任的代理需要对发送协议进行扩展，并留作将来的工作[SPND]，但类似于目前支持的保护路由器广告的问题。例如，流氓节点可以发送路由器公告，以使代理禁用其代理行为，从而导致对其他节点的拒绝服务；[PSREQ]第4.2.1节涵盖了该威胁。
Alternative designs might involve schemes where the right for representing a particular host is delegated to the proxy, or where multiple nodes can make statements on behalf of one address [RINGSIG].
替代设计可能涉及这样的方案：代表特定主机的权利被委托给代理，或者多个节点可以代表一个地址[RINGSIG]进行声明。
The authors wish to thank Jari Arkko for contributing portions of the Security Considerations text.
作者希望感谢Jari Arkko提供了部分安全注意事项文本。
[BRIDGE] T. Jeffree, editor, "Media Access Control (MAC) Bridges", ANSI/IEEE Std 802.1D, 2004, http://standards.ieee.org/ getieee802/download/802.1D-2004.pdf.
[BRIDGE]T.Jeffree，编辑，“媒体访问控制（MAC）网桥”，ANSI/IEEE标准802.1D，2004年，http://standards.ieee.org/ getieee802/download/802.1D-2004.pdf。
[ICMPv6] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998.
[ICMPv6]Conta，A.和S.Deering，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 2463，1998年12月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[ND] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[ND]Narten，T.，Nordmark，E.，和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC 2461，1998年12月。
[NODEREQ] Loughney, J., Ed., "IPv6 Node Requirements", RFC 4294, April 2006.
[NODEREQ]Loughney，J.，编辑，“IPv6节点要求”，RFC 42942006年4月。
[6TO4] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[6TO4]Carpenter，B.和K.Moore，“通过IPv4云连接IPv6域”，RFC 3056，2001年2月。
[BCP] Higashiyama, M., Baker, F., and T. Liao, "Point-to-Point Protocol (PPP) Bridging Control Protocol (BCP)", RFC 3518, April 2003.
[BCP]Higashiyama，M.，Baker，F.，和T.Liao，“点对点协议（PPP）桥接控制协议（BCP）”，RFC 3518，2003年4月。
[DHCPv6] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[DHCPv6]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC 33151003年7月。
[NAT] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[NAT]Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 30222001年1月。
[PD] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[PD]Troan，O.和R.Droms，“动态主机配置协议（DHCP）版本6的IPv6前缀选项”，RFC 3633，2003年12月。
[PSREQ] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[PSREQ]Nikander，P.，Kempf，J.和E.Nordmark，“IPv6邻居发现（ND）信任模型和威胁”，RFC 3756，2004年5月。
[RINGSIG] Kempf, J. and C. Gentry, "Secure IPv6 Address Proxying using Multi-Key Cryptographically Generated Addresses (MCGAs)", Work in Progress, August 2005.
[RINGSIG]Kempf，J.和C.Gentry，“使用多密钥加密生成地址（MCGA）的安全IPv6地址代理”，正在进行的工作，2005年8月。
[SEND] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[发送]Arkko，J.，Ed.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（发送）”，RFC 39712005年3月。
[SPND] Daley, G., "Securing Proxy Neighbour Discovery Problem Statement", Work in Progress, February 2005.
[SPND]Daley，G.，“保护代理邻居发现问题声明”，正在进行的工作，2005年2月。
Appendix A: Comparison with Naive RA Proxy
附录A：与Naive RA代理的比较
It has been suggested that a simple Router Advertisement (RA) proxy would be sufficient, where the subnet prefix in an RA is "stolen" by the proxy and applied to a downstream link instead of an upstream link. Other ND messages are not proxied.
有人建议，简单路由器广告（RA）代理就足够了，其中RA中的子网前缀被代理“窃取”，并应用于下游链路而不是上游链路。未代理其他ND消息。
There are many problems with this approach. First, it requires cooperation from all nodes on the upstream link. No node (including the router sending the RA) can have an address in the subnet or it will not have connectivity with nodes on the downstream link. This is because when a node on a downstream link tries to do Neighbor Discovery, and the proxy does not send the NS on the upstream link, it will never discover the neighbor on the upstream link. Similarly, if messages are not proxied during Duplicate Address Detection (DAD), conflicts can occur.
这种方法有很多问题。首先，它需要上游链路上所有节点的合作。任何节点（包括发送RA的路由器）都不能在子网中有地址，否则它将无法与下游链路上的节点连接。这是因为，当下游链路上的节点尝试执行邻居发现时，而代理不在上游链路上发送NS，它将永远不会在上游链路上发现邻居。类似地，如果在重复地址检测（DAD）期间未代理消息，则可能发生冲突。
Second, if the proxy assumes that no nodes on the upstream link have addresses in the prefix, such a proxy could not be safely deployed without cooperation from the network administrator since it introduces a requirement that the router itself not have an address in the prefix. This rules out use in situations where bridges and Network Address Translators (NATs) are used today, which is the problem this document is directly addressing. Instead, where a prefix is desired for use on one or more downstream links in cooperation with the network administrator, Prefix Delegation [PD] should be used instead.
其次，如果代理假定上游链路上没有节点在前缀中有地址，那么如果没有网络管理员的合作，这样的代理无法安全部署，因为它引入了路由器本身在前缀中没有地址的要求。这排除了在今天使用网桥和网络地址转换器（NAT）的情况下使用，这正是本文档直接解决的问题。相反，如果需要与网络管理员合作在一个或多个下游链路上使用前缀，则应使用前缀委派[PD]。
Authors' Addresses
作者地址
Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
Dave Thaler微软公司华盛顿州雷德蒙微软大道一号98052-6399
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Mohit Talwar Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
Mohit Talwar微软公司华盛顿州雷德蒙微软大道一号，邮编：98052-6399
Phone: +1 425 705 3131
EMail: mohitt@microsoft.com
Phone: +1 425 705 3131
EMail: mohitt@microsoft.com
Chirayu Patel All Play, No Work Bangalore, Karnataka 560038
奇拉尤·帕特尔全场比赛，无工作班加罗尔，卡纳塔克邦560038
Phone: +91-98452-88078
EMail: chirayu@chirayu.org
Phone: +91-98452-88078
EMail: chirayu@chirayu.org
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）提供。