Network Working Group T. Kivinen
Request for Comments: 3947 SafeNet
Category: Standards Track B. Swander
Microsoft
A. Huttunen
F-Secure Corporation
V. Volpe
Cisco Systems
January 2005
Network Working Group T. Kivinen
Request for Comments: 3947 SafeNet
Category: Standards Track B. Swander
Microsoft
A. Huttunen
F-Secure Corporation
V. Volpe
Cisco Systems
January 2005
Negotiation of NAT-Traversal in the IKE
IKE中NAT穿越的协商
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document describes how to detect one or more network address translation devices (NATs) between IPsec hosts, and how to negotiate the use of UDP encapsulation of IPsec packets through NAT boxes in Internet Key Exchange (IKE).
本文档描述了如何在IPsec主机之间检测一个或多个网络地址转换设备（NAT），以及如何通过Internet密钥交换（IKE）中的NAT盒协商使用UDP封装IPsec数据包。
Table of Contents
目录
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Specification of Requirements . . . . . . . . . . . . . . . . . 3
3. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Detecting Support of NAT-Traversal. . . . . . . . . . . . 4
3.2. Detecting the Presence of NAT . . . . . . . . . . . . . . 4
4. Changing to New Ports . . . . . . . . . . . . . . . . . . . . . 6
5. Quick Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Negotiation of the NAT-Traversal Encapsulation. . . . . . 9
5.2. Sending the Original Source and Destination Addresses . . 9
6. Initial Contact Notifications. . . . . . . . . . . . . . . . . 11
7. Recovering from the Expiring NAT Mappings. . . . . . . . . . . 11
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 13
10. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 14
11. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.1. Normative References . . . . . . . . . . . . . . . . . . 14
12.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Specification of Requirements . . . . . . . . . . . . . . . . . 3
3. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Detecting Support of NAT-Traversal. . . . . . . . . . . . 4
3.2. Detecting the Presence of NAT . . . . . . . . . . . . . . 4
4. Changing to New Ports . . . . . . . . . . . . . . . . . . . . . 6
5. Quick Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Negotiation of the NAT-Traversal Encapsulation. . . . . . 9
5.2. Sending the Original Source and Destination Addresses . . 9
6. Initial Contact Notifications. . . . . . . . . . . . . . . . . 11
7. Recovering from the Expiring NAT Mappings. . . . . . . . . . . 11
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 13
10. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 14
11. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.1. Normative References . . . . . . . . . . . . . . . . . . 14
12.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 16
This document is split into two parts. The first describes what is needed in IKE Phase 1 for NAT-Traversal support. This includes detecting whether the other end supports NAT-Traversal, and detecting whether there is one or more NATs between the peers.
本文件分为两部分。第一个描述了IKE阶段1中NAT遍历支持所需的内容。这包括检测另一端是否支持NAT遍历，以及检测对等端之间是否存在一个或多个NAT。
The second part describes how to negotiate the use of UDP encapsulated IPsec packets in IKE's Quick Mode. It also describes how to transmit the original source and destination addresses to the peer, if required. These addresses are used in transport mode to update the TCP/IP checksums incrementally so that they will match after the NAT transform. (The NAT cannot do this, because the TCP/IP checksum is inside the UDP encapsulated IPsec packet.)
第二部分描述了如何在IKE的快速模式下协商使用UDP封装的IPsec数据包。它还描述了如何将原始源地址和目标地址传输到对等方（如果需要）。这些地址在传输模式下用于增量更新TCP/IP校验和，以便它们在NAT转换后匹配。（NAT无法执行此操作，因为TCP/IP校验和在UDP封装的IPsec数据包内。）
The document [RFC3948] describes the details of UDP encapsulation, and [RFC3715] provides background information and motivation of NAT-Traversal in general. In combination with [RFC3948], this document represents an "unconditionally compliant" solution to the requirements as defined by [RFC3715].
文档[RFC3948]描述了UDP封装的细节，[RFC3715]提供了NAT遍历的背景信息和动机。结合[RFC3948]，本文件代表了对[RFC3715]所定义要求的“无条件符合”解决方案。
In the basic scenario for this document, the initiator is behind NA(P)T, and the responder has a fixed static IP address.
在本文档的基本场景中，发起方位于NA（P）T之后，响应方具有固定的静态IP地址。
This document defines a protocol that will work even if both ends are behind NAT, but the process of how to locate the other end is out of the scope of this document. In one scenario, the responder is behind a static host NAT (only one responder per IP, as there is no way to use any destination ports other than 500/4500). That is, it is known by the configuration.
本文档定义了一个协议，即使两端都在NAT后面也可以工作，但是如何定位另一端的过程超出了本文档的范围。在一个场景中，响应程序位于静态主机NAT后面（每个IP只有一个响应程序，因为除了500/4500之外，没有其他方法使用任何目标端口）。也就是说，它是由配置所知的。
This document shall use the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED, "MAY", and "OPTIONAL" to describe requirements. They are to be interpreted as described in [RFC2119].
本文件应使用关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”来描述要求。它们应按照[RFC2119]中的描述进行解释。
The detection of support for NAT-Traversal and detection of NAT along the path between the two IKE peers occurs in IKE [RFC2409] Phase 1.
在IKE[RFC2409]阶段1中检测对NAT遍历的支持以及沿两个IKE对等点之间的路径检测NAT。
The NAT may change the IKE UDP source port, and recipients MUST be able to process IKE packets whose source port is different from 500. The NAT does not have to change the source port if:
NAT可以更改IKE UDP源端口，并且接收方必须能够处理源端口不同于500的IKE数据包。在以下情况下，NAT不必更改源端口：
o only one IPsec host is behind the NAT, or
o NAT后面只有一个IPsec主机，或
o for the first IPsec host, the NAT can keep the port 500, and the NAT will only change the port number for later connections.
o 对于第一个IPsec主机，NAT可以保留端口500，并且NAT只会更改端口号以用于以后的连接。
Recipients MUST reply back to the source address from the packet (see [RFC3715], section 2.1, case d). This means that when the original responder is doing rekeying or sending notifications to the original initiator, it MUST send the packets using the same set of port and IP numbers used when the IKE SA was last used.
收件人必须从数据包回复源地址（参见[RFC3715]，第2.1节，案例d）。这意味着，当原始响应程序进行密钥更新或向原始启动器发送通知时，它必须使用上次使用IKE SA时使用的相同端口和IP号集发送数据包。
For example, when the initiator sends a packet with source and destination port 500, the NAT may change it to a packet with source port 12312 and destination port 500. The responder must be able to process the packet whose source port is 12312. It must reply back with a packet whose source port is 500 and destination port is 12312. The NAT will then translate this packet to source port 500 and destination port 500.
例如，当发起方发送具有源端口和目的端口500的分组时，NAT可以将其更改为具有源端口12312和目的端口500的分组。响应程序必须能够处理源端口为12312的数据包。它必须使用源端口为500、目标端口为12312的数据包进行回复。NAT随后将该分组转换为源端口500和目的端口500。
The NAT-Traversal capability of the remote host is determined by an exchange of vendor ID payloads. In the first two messages of Phase 1, the vendor id payload for this specification MUST be sent if supported (and it MUST be received by both sides) for the NAT-Traversal probe to continue. The content of the payload is the MD5 hash of
远程主机的NAT穿越能力由供应商ID有效负载的交换决定。在阶段1的前两条消息中，如果支持，则必须发送此规范的供应商id有效负载（并且必须由双方接收），以使NAT遍历探测继续。有效负载的内容是
RFC 3947
RFC 3947
The exact content in hex for the payload is
有效负载的确切内容（十六进制）为
4a131c81070358455c5728f20e95452f
4a131c81070358455c5728f20e95452f
The NAT-D payload not only detects the presence of NAT between the two IKE peers, but also detects where the NAT is. The location of the NAT device is important, as the keepalives have to initiate from the peer "behind" the NAT.
NAT-D有效载荷不仅检测两个IKE对等方之间是否存在NAT，而且还检测NAT所在的位置。NAT设备的位置很重要，因为keepalive必须从NAT后面的对等方发起。
To detect NAT between the two hosts, we have to detect whether the IP address or the port changes along the path. This is done by sending the hashes of the IP addresses and ports of both IKE peers from each end to the other. If both ends calculate those hashes and get same result, they know there is no NAT between. If the hashes do not match, somebody has translated the address or port. This means that we have to do NAT-Traversal to get IPsec packets through.
要检测两台主机之间的NAT，我们必须检测IP地址或端口是否沿路径变化。这是通过将两个IKE对等方的IP地址和端口的哈希值从一端发送到另一端来完成的。如果两端计算这些散列并得到相同的结果，它们就知道这两者之间没有NAT。如果散列不匹配，则表示有人已转换了地址或端口。这意味着我们必须进行NAT遍历才能使IPsec数据包通过。
If the sender of the packet does not know his own IP address (in case of multiple interfaces, and the implementation does not know which IP address is used to route the packet out), the sender can include multiple local hashes to the packet (as separate NAT-D payloads). In this case, NAT is detected if and only if none of the hashes match.
如果包的发送者不知道他自己的IP地址（在多个接口的情况下，并且实现不知道使用哪个IP地址来路由包），发送者可以将多个本地哈希包括到包中（作为单独的NAT-D有效负载）。在这种情况下，当且仅当所有哈希都不匹配时才检测NAT。
The hashes are sent as a series of NAT-D (NAT discovery) payloads. Each payload contains one hash, so in case of multiple hashes, multiple NAT-D payloads are sent. In the normal case there are only two NAT-D payloads.
散列作为一系列NAT-D（NAT发现）有效负载发送。每个有效负载包含一个哈希，因此在多个哈希的情况下，会发送多个NAT-D有效负载。在正常情况下，只有两个NAT-D有效载荷。
The NAT-D payloads are included in the third and fourth packets of Main Mode, and in the second and third packets in the Aggressive Mode.
NAT-D有效载荷包括在主模式的第三和第四分组中，以及在攻击模式的第二和第三分组中。
The format of the NAT-D packet is
NAT-D数据包的格式为
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload length |
+---------------+---------------+---------------+---------------+
~ HASH of the address and port ~
+---------------+---------------+---------------+---------------+
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload length |
+---------------+---------------+---------------+---------------+
~ HASH of the address and port ~
+---------------+---------------+---------------+---------------+
The payload type for the NAT discovery payload is 20.
NAT发现有效负载的有效负载类型为20。
The HASH is calculated as follows:
散列计算如下：
HASH = HASH(CKY-I | CKY-R | IP | Port)
哈希=哈希（CKY-I | CKY-R | IP |端口）
This uses the negotiated HASH algorithm. All data inside the HASH is in the network byte-order. The IP is 4 octets for an IPv4 address and 16 octets for an IPv6 address. The port number is encoded as a 2 octet number in network byte-order. The first NAT-D payload contains the remote end's IP address and port (i.e., the destination address of the UDP packet). The remaining NAT-D payloads contain possible local-end IP addresses and ports (i.e., all possible source addresses of the UDP packet).
这使用协商哈希算法。散列中的所有数据都是按网络字节顺序排列的。IPv4地址的IP为4个八位字节，IPv6地址的IP为16个八位字节。端口号按网络字节顺序编码为2个八位字节。第一个NAT-D有效负载包含远程端的IP地址和端口（即UDP数据包的目标地址）。其余NAT-D有效负载包含可能的本地端IP地址和端口（即UDP数据包的所有可能源地址）。
If there is no NAT between the peers, the first NAT-D payload received should match one of the local NAT-D payloads (i.e., the local NAT-D payloads this host is sending out), and one of the other NAT-D payloads must match the remote end's IP address and port. If the first check fails (i.e., first NAT-D payload does not match any of the local IP addresses and ports), it means that there is dynamic NAT between the peers, and this end should start sending keepalives as defined in the [RFC3948] (this end is behind the NAT).
如果对等方之间没有NAT，则接收到的第一个NAT-D有效负载应与一个本地NAT-D有效负载（即，此主机正在发送的本地NAT-D有效负载）匹配，而另一个NAT-D有效负载必须与远程端的IP地址和端口匹配。如果第一次检查失败（即，第一个NAT-D有效负载与任何本地IP地址和端口都不匹配），这意味着对等方之间存在动态NAT，并且该端应开始发送[RFC3948]中定义的keepalives（该端位于NAT后面）。
The CKY-I and CKY-R are the initiator and responder cookies. They are added to the hash to make precomputation attacks for the IP address and port impossible.
CKY-I和CKY-R是发起方和响应方cookie。它们被添加到哈希中，以使IP地址和端口的预计算攻击不可能发生。
The following example is of a Phase 1 exchange using NAT-Traversal in Main Mode (authentication with signatures):
以下示例是在主模式下使用NAT遍历的第1阶段交换（使用签名进行身份验证）：
Initiator Responder
------------ ------------
HDR, SA, VID -->
<-- HDR, SA, VID
HDR, KE, Ni, NAT-D, NAT-D -->
<-- HDR, KE, Nr, NAT-D, NAT-D
HDR*#, IDii, [CERT, ] SIG_I -->
<-- HDR*#, IDir, [CERT, ], SIG_R
Initiator Responder
------------ ------------
HDR, SA, VID -->
<-- HDR, SA, VID
HDR, KE, Ni, NAT-D, NAT-D -->
<-- HDR, KE, Nr, NAT-D, NAT-D
HDR*#, IDii, [CERT, ] SIG_I -->
<-- HDR*#, IDir, [CERT, ], SIG_R
The following example is of Phase 1 exchange using NAT-Traversal in Aggressive Mode (authentication with signatures):
以下示例是在攻击模式下使用NAT遍历的第1阶段交换（使用签名进行身份验证）：
Initiator Responder
------------ ------------
HDR, SA, KE, Ni, IDii, VID -->
<-- HDR, SA, KE, Nr, IDir,
[CERT, ], VID, NAT-D,
NAT-D, SIG_R
HDR*#, [CERT, ], NAT-D, NAT-D,
SIG_I -->
Initiator Responder
------------ ------------
HDR, SA, KE, Ni, IDii, VID -->
<-- HDR, SA, KE, Nr, IDir,
[CERT, ], VID, NAT-D,
NAT-D, SIG_R
HDR*#, [CERT, ], NAT-D, NAT-D,
SIG_I -->
The # sign indicates that those packets are sent to the changed port if NAT is detected.
#符号表示如果检测到NAT，这些数据包将被发送到更改的端口。
IPsec-aware NATs can cause problems (See [RFC3715], section 2.3). Some NATs will not change IKE source port 500 even if there are multiple clients behind the NAT (See [RFC3715], section 2.3, case n). They can also use IKE cookies to demultiplex traffic instead of using the source port (See [RFC3715], section 2.3, case m). Both of these are problematic for generic NAT transparency, as it is difficult for IKE to discover the capabilities of the NAT. The best approach is simply to move the IKE traffic off port 500 as soon as possible to avoid any IPsec-aware NAT special casing.
支持IPsec的NAT可能会导致问题（请参阅[RFC3715]，第2.3节）。即使NAT后面有多个客户端，一些NAT也不会更改IKE源端口500（请参阅[RFC3715]，第2.3节，案例n）。他们也可以使用IKE Cookie来解复用通信量，而不是使用源端口（参见[RFC3715]，第2.3节，案例m）。这两个问题对于通用NAT透明性都是有问题的，因为IKE很难发现NAT的功能。最好的方法是尽快将IKE通信量移出端口500，以避免任何IPsec感知的NAT特殊情况。
Take the common case of the initiator behind the NAT. The initiator must quickly change to port 4500 once the NAT has been detected to minimize the window of IPsec-aware NAT problems.
以NAT后面的启动器为例。一旦检测到NAT，启动器必须快速切换到端口4500，以最小化IPsec感知NAT问题的窗口。
In Main Mode, the initiator MUST change ports when sending the ID payload if there is NAT between the hosts. The initiator MUST set both UDP source and destination ports to 4500. All subsequent packets sent to this peer (including informational notifications) MUST be sent on port 4500. In addition, the IKE data MUST be prepended with a non-ESP marker allowing for demultiplexing of traffic, as defined in [RFC3948].
在主模式下，如果主机之间存在NAT，则启动器在发送ID有效负载时必须更改端口。启动器必须将UDP源端口和目标端口都设置为4500。发送到此对等方的所有后续数据包（包括信息通知）必须在端口4500上发送。此外，如[RFC3948]中所定义，IKE数据必须以非ESP标记为前缀，以允许通信量的解复用。
Thus, the IKE packet now looks like this:
因此，IKE数据包现在看起来如下所示：
IP UDP(4500,4500) <non-ESP marker> HDR*, IDii, [CERT, ] SIG_I
IP UDP(4500,4500) <non-ESP marker> HDR*, IDii, [CERT, ] SIG_I
This assumes authentication using signatures. The 4 bytes of non-ESP marker are defined in the [RFC3948].
这假设使用签名进行身份验证。[RFC3948]中定义了非ESP标记的4个字节。
When the responder gets this packet, the usual decryption and processing of the various payloads is performed. If these are successful, the responder MUST update local state so that all subsequent packets (including informational notifications) to the peer use the new port, and possibly the new IP address obtained from the incoming valid packet. The port will generally be different, as the NAT will map UDP(500,500) to UDP(X,500), and UDP(4500,4500) to UDP(Y,4500). The IP address will seldom be different from the pre-changed IP address. The responder MUST respond with all subsequent IKE packets to this peer by using UDP(4500,Y).
当响应者获得此数据包时，将执行各种有效载荷的常规解密和处理。如果这些操作成功，响应程序必须更新本地状态，以便发送给对等方的所有后续数据包（包括信息通知）使用新端口，以及可能从传入的有效数据包获得的新IP地址。端口通常会有所不同，因为NAT会将UDP（500500）映射到UDP（X，500），并将UDP（4500）映射到UDP（Y，4500）。IP地址很少与预先更改的IP地址不同。响应者必须使用UDP（4500，Y）将所有后续IKE数据包响应到此对等方。
Similarly, if the responder has to rekey the Phase 1 SA, then the rekey negotiation MUST be started by using UDP(4500,Y). Any implementation that supports NAT traversal MUST support negotiations that begin on port 4500. If a negotiation starts on port 4500, then it doesn't need to change anywhere else in the exchange.
类似地，如果响应者必须为阶段1 SA重新设置密钥，则必须使用UDP（4500，Y）启动重新设置密钥协商。任何支持NAT遍历的实现都必须支持从端口4500开始的协商。如果协商在端口4500上开始，则不需要在交换中的任何其他位置进行更改。
Once port change has occurred, if a packet is received on port 500, that packet is old. If the packet is an informational packet, it MAY be processed if local policy allows this. If the packet is a Main Mode or an Aggressive Mode packet (with the same cookies as previous packets), it SHOULD be discarded. If the packet is a new Main Mode or Aggressive exchange, then it is processed normally (the other end might have rebooted, and this is starting new exchange).
一旦发生端口更改，如果在端口500上接收到数据包，则该数据包为旧数据包。如果数据包是一个信息数据包，如果本地策略允许，可以对其进行处理。如果该数据包是主模式或攻击模式数据包（与以前的数据包具有相同的cookie），则应丢弃该数据包。如果数据包是新的主模式或主动交换，则它将正常处理（另一端可能已重新启动，这将启动新的交换）。
Here is an example of a Phase 1 exchange using NAT-Traversal in Main Mode (authentication with signatures) with changing port:
下面是一个第1阶段交换的示例，在主模式下使用NAT遍历（使用签名进行身份验证），并更改端口：
Initiator Responder
------------ ------------
UDP(500,500) HDR, SA, VID -->
<-- UDP(500,X) HDR, SA, VID
UDP(500,500) HDR, KE, Ni,
NAT-D, NAT-D -->
<-- UDP(500,X) HDR, KE, Nr,
NAT-D, NAT-D
UDP(4500,4500) HDR*#, IDii,
[CERT, ]SIG_I -->
<-- UDP(4500,Y) HDR*#, IDir,
[ CERT, ], SIG_R
Initiator Responder
------------ ------------
UDP(500,500) HDR, SA, VID -->
<-- UDP(500,X) HDR, SA, VID
UDP(500,500) HDR, KE, Ni,
NAT-D, NAT-D -->
<-- UDP(500,X) HDR, KE, Nr,
NAT-D, NAT-D
UDP(4500,4500) HDR*#, IDii,
[CERT, ]SIG_I -->
<-- UDP(4500,Y) HDR*#, IDir,
[ CERT, ], SIG_R
The procedure for Aggressive Mode is very similar. After the NAT has been detected, the initiator sends IP UDP(4500,4500) <4 bytes of non-ESP marker> HDR*, [CERT, ], NAT-D, NAT-D, and SIG_I. The responder does similar processing to the above, and if successful, MUST update it's internal IKE ports. The responder MUST respond with all subsequent IKE packets to this peer by using UDP(4500,Y).
攻击模式的程序非常相似。检测到NAT后，启动器发送IP UDP（45004500）<4字节的非ESP标记>HDR*、[CERT、]、NAT-D、NAT-D和SIG_I。响应程序执行与上述类似的处理，如果成功，则必须更新其内部IKE端口。响应者必须使用UDP（4500，Y）将所有后续IKE数据包响应到此对等方。
Initiator Responder
------------ ------------
UDP(500,500) HDR, SA, KE,
Ni, IDii, VID -->
<-- UDP(500,X) HDR, SA, KE,
Nr, IDir, [CERT, ],
VID, NAT-D, NAT-D,
SIG_R
UDP(4500,4500) HDR*#, [CERT, ],
NAT-D, NAT-D,
SIG_I -->
<-- UDP(4500, Y) HDR*#, ...
Initiator Responder
------------ ------------
UDP(500,500) HDR, SA, KE,
Ni, IDii, VID -->
<-- UDP(500,X) HDR, SA, KE,
Nr, IDir, [CERT, ],
VID, NAT-D, NAT-D,
SIG_R
UDP(4500,4500) HDR*#, [CERT, ],
NAT-D, NAT-D,
SIG_I -->
<-- UDP(4500, Y) HDR*#, ...
If the support of the NAT-Traversal is enabled, the port in the ID payload in Main Mode/Aggressive Mode MUST be set to 0.
如果启用NAT穿越支持，则主模式/攻击模式下ID有效负载中的端口必须设置为0。
The most common case for the responder behind the NAT is if the NAT is simply doing 1:1 address translation. In this case, the initiator still changes both ports to 4500. The responder uses an algorithm identical to that above, although in this case Y will equal 4500, as no port translation is happening.
NAT后面的响应程序最常见的情况是NAT只是进行1:1地址转换。在这种情况下，启动器仍将两个端口更改为4500。响应者使用与上面相同的算法，尽管在这种情况下Y将等于4500，因为没有发生端口转换。
A different port change case involves out-of-band discovery of the ports to use. Those discovery methods are out of the scope of this document. For instance, if the responder is behind a port translating NAT, and the initiator needs to contact it first, then the initiator will have to determine which ports to use, usually by contacting some other server. Once the initiator knows which ports to use to traverse the NAT, generally something like UDP(Z,4500), it initiates using these ports. This is similar to the responder rekey case above in that the ports to use are already known up front, and no additional change has to take place. Also, the first keepalive timer starts after the change to the new port, and no keepalives are sent to the port 500.
不同的端口更改案例涉及要使用的端口的带外发现。这些发现方法不在本文档的范围内。例如，如果响应程序位于端口转换NAT之后，并且启动器需要首先联系它，那么启动器必须确定要使用哪些端口，通常是通过联系其他服务器。一旦启动器知道要使用哪些端口来遍历NAT，通常是UDP（Z，4500）之类的端口，它就会使用这些端口进行初始化。这类似于上面的响应程序重新设置密钥的情况，因为要使用的端口已经预先知道，并且不需要进行额外的更改。此外，第一个keepalive计时器在更改到新端口后启动，并且不向端口500发送keepalive。
After Phase 1, both ends know whether there is a NAT present between them. The final decision of using NAT-Traversal is left to Quick Mode. The use of NAT-Traversal is negotiated inside the SA payloads of Quick Mode. In Quick Mode, both ends can also send the original addresses of the IPsec packets (in case of the transport mode) to the other end so that each can fix the TCP/IP checksum field after the NAT transformation.
在阶段1之后，两端都知道它们之间是否存在NAT。使用NAT遍历的最终决定权留给Quick模式。NAT遍历的使用在快速模式的SA有效负载内协商。在快速模式下，两端还可以将IPsec数据包的原始地址（在传输模式下）发送到另一端，以便在NAT转换后，每个端都可以修复TCP/IP校验和字段。
The negotiation of the NAT-Traversal happens by adding two new encapsulation modes. These encapsulation modes are
NAT遍历的协商通过添加两种新的封装模式来实现。这些封装模式是
UDP-Encapsulated-Tunnel 3 UDP-Encapsulated-Transport 4
UDP封装隧道3 UDP封装传输4
It is not normally useful to propose both normal tunnel or transport mode and UDP-Encapsulated modes. UDP encapsulation is required to fix the inability to handle non-UDP/TCP traffic by NATs (see [RFC3715], section 2.2, case i).
通常，建议使用普通隧道或传输模式以及UDP封装模式是没有用的。需要UDP封装来修复NAT无法处理非UDP/TCP流量的问题（请参见[RFC3715]，第2.2节，案例一）。
If there is a NAT box between hosts, normal tunnel or transport encapsulations may not work. In this case, UDP-Encapsulation SHOULD be used.
如果主机之间存在NAT盒，则正常的隧道或传输封装可能无法工作。在这种情况下，应该使用UDP封装。
If there is no NAT box between, there is no point in wasting bandwidth by adding UDP encapsulation of packets. Thus, UDP-Encapsulation SHOULD NOT be used.
如果两者之间没有NAT框，那么通过添加数据包的UDP封装来浪费带宽是没有意义的。因此，不应使用UDP封装。
Also, the initiator SHOULD NOT include both normal tunnel or transport mode and UDP-Encapsulated-Tunnel or UDP-Encapsulated-Transport in its proposals.
此外，发起人不应在其提案中同时包括正常隧道或传输模式以及UDP封装隧道或UDP封装传输。
To perform incremental TCP checksum updates, both peers may need to know the original IP addresses used by their peers when those peers constructed the packet (see [RFC3715], section 2.1, case b). For the initiator, the original Initiator address is defined to be the Initiator's IP address. The original Responder address is defined to be the perceived peer's IP address. For the responder, the original Initiator address is defined to be the perceived peer's address. The original Responder address is defined to be the Responder's IP address.
要执行增量TCP校验和更新，两个对等方可能需要知道其对等方在构建数据包时使用的原始IP地址（请参阅[RFC3715]，第2.1节，案例b）。对于启动器，原始启动器地址定义为启动器的IP地址。原始响应者地址被定义为感知对等方的IP地址。对于响应者，原始发起方地址被定义为感知对等方的地址。原始响应程序地址定义为响应程序的IP地址。
The original addresses are sent by using NAT-OA (NAT Original Address) payloads.
原始地址通过使用NAT-OA（NAT原始地址）有效负载发送。
The Initiator NAT-OA payload is first. The Responder NAT-OA payload is second.
启动器NAT-OA有效负载是第一个。响应者NAT-OA有效载荷是第二个。
Example 1:
例1：
Initiator <---------> NAT <---------> Responder
^ ^ ^
Iaddr NatPub Raddr
Initiator <---------> NAT <---------> Responder
^ ^ ^
Iaddr NatPub Raddr
The initiator is behind a NAT talking to the publicly available responder. Initiator and Responder have the IP addresses Iaddr and Raddr. NAT has public IP address NatPub.
发起者在NAT后面与公开的响应者对话。发起方和响应方具有Iaddr和Raddr的IP地址。NAT具有公共IP地址NatPub。
Initiator:
发起人：
NAT-OAi = Iaddr NAT-OAr = Raddr
NAT OAi=Iaddr NAT OAr=Raddr
Responder: NAT-OAi = NATPub NAT-OAr = Raddr
响应者：NAT OAi=NATPub NAT OAr=Raddr
Example 2:
例2：
Initiator <------> NAT1 <---------> NAT2 <-------> Responder
^ ^ ^ ^
Iaddr Nat1Pub Nat2Pub Raddr
Initiator <------> NAT1 <---------> NAT2 <-------> Responder
^ ^ ^ ^
Iaddr Nat1Pub Nat2Pub Raddr
Here, NAT2 "publishes" Nat2Pub for Responder and forwards all traffic to that address to Responder.
在这里，NAT2为响应者“发布”Nat2Pub，并将所有流量转发到该地址给响应者。
Initiator: NAT-OAi = Iaddr NAT-OAr = Nat2Pub
发起人：NAT OAi=Iaddr NAT OAr=Nat2Pub
Responder: NAT-OAi = Nat1Pub NAT-OAr = Raddr
响应者：NAT OAi=Nat1Pub NAT OAr=Raddr
In the case of transport mode, both ends MUST send both original Initiator and Responder addresses to the other end. For tunnel mode, both ends SHOULD NOT send original addresses to the other end.
在传输模式的情况下，两端必须向另一端发送原始发起方和响应方地址。对于隧道模式，两端不应向另一端发送原始地址。
The NAT-OA payloads are sent inside the first and second packets of Quick Mode. The initiator MUST send the payloads if it proposes any UDP-Encapsulated-Transport mode, and the responder MUST send the payload only if it selected UDP-Encapsulated-Transport mode. It is possible that the initiator sends the NAT-OA payload but proposes both UDP-Encapsulated transport and tunnel mode. Then the responder selects the UDP-Encapsulated tunnel mode and does not send the NAT-OA payload back.
NAT-OA有效载荷在快速模式的第一和第二数据包内发送。如果发起方提出任何UDP封装传输模式，则必须发送有效负载，而响应方必须仅在选择UDP封装传输模式时发送有效负载。发起方可能发送NAT-OA有效负载，但同时提出UDP封装传输和隧道模式。然后，响应者选择UDP封装的隧道模式，并且不将NAT-OA有效负载发送回。
The format of the NAT-OA packet is
NAT-OA数据包的格式为
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload length |
+---------------+---------------+---------------+---------------+
| ID Type | RESERVED | RESERVED |
+---------------+---------------+---------------+---------------+
| IPv4 (4 octets) or IPv6 address (16 octets) |
+---------------+---------------+---------------+---------------+
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload length |
+---------------+---------------+---------------+---------------+
| ID Type | RESERVED | RESERVED |
+---------------+---------------+---------------+---------------+
| IPv4 (4 octets) or IPv6 address (16 octets) |
+---------------+---------------+---------------+---------------+
The payload type for the NAT original address payload is 21.
NAT原始地址有效负载的有效负载类型为21。
The ID type is defined in the [RFC2407]. Only ID_IPV4_ADDR and ID_IPV6_ADDR types are allowed. The two reserved fields after the ID Type must be zero.
ID类型在[RFC2407]中定义。只允许ID_IPV4_ADDR和ID_IPV6_ADDR类型。ID类型后的两个保留字段必须为零。
The following example is of Quick Mode using NAT-OA payloads:
以下示例是使用NAT-OA有效载荷的快速模式：
Initiator Responder
------------ ------------
HDR*, HASH(1), SA, Ni, [, KE]
[, IDci, IDcr ]
[, NAT-OAi, NAT-OAr] -->
<-- HDR*, HASH(2), SA, Nr, [, KE]
[, IDci, IDcr ]
[, NAT-OAi, NAT-OAr]
HDR*, HASH(3) -->
Initiator Responder
------------ ------------
HDR*, HASH(1), SA, Ni, [, KE]
[, IDci, IDcr ]
[, NAT-OAi, NAT-OAr] -->
<-- HDR*, HASH(2), SA, Nr, [, KE]
[, IDci, IDcr ]
[, NAT-OAi, NAT-OAr]
HDR*, HASH(3) -->
The source IP and port address of the INITIAL-CONTACT notification for the host behind NAT are not meaningful (as NAT can change them), so the IP and port numbers MUST NOT be used to determine which IKE/IPsec SAs to remove (see [RFC3715], section 2.1, case c). The ID payload sent from the other end SHOULD be used instead; i.e., when an INITIAL-CONTACT notification is received from the other end, the receiving end SHOULD remove all the SAs associated with the same ID payload.
NAT后主机的初始联系通知的源IP和端口地址没有意义（因为NAT可以更改它们），因此IP和端口号不得用于确定要删除的IKE/IPsec SA（请参阅[RFC3715]，第2.1节，案例c）。应该使用从另一端发送的ID有效载荷；i、 例如，当从另一端接收到初始联系人通知时，接收端应移除与相同ID有效负载相关联的所有SA。
There are cases where NAT box decides to remove mappings that are still alive (for example, when the keepalive interval is too long, or when the NAT box is rebooted). To recover from this, ends that are NOT behind NAT SHOULD use the last valid UDP encapsulated IKE or IPsec packet from the other end to determine which IP and port addresses should be used. The host behind dynamic NAT MUST NOT do
在某些情况下，NAT盒决定删除仍处于活动状态的映射（例如，当keepalive间隔太长时，或者当NAT盒重新启动时）。要从中恢复，不在NAT后面的端应使用来自另一端的最后一个有效UDP封装IKE或IPsec数据包来确定应使用哪些IP和端口地址。动态NAT后面的主机不能执行以下操作
this, as otherwise it opens a DoS attack possibility because the IP address or port of the other host will not change (it is not behind NAT).
否则，由于另一台主机的IP地址或端口不会更改（它不在NAT后面），因此可能会导致DoS攻击。
Keepalives cannot be used for these purposes, as they are not authenticated, but any IKE authenticated IKE packet or ESP packet can be used to detect whether the IP address or the port has changed.
Keepalives不能用于这些目的，因为它们没有经过身份验证，但是任何经过IKE身份验证的IKE数据包或ESP数据包都可以用于检测IP地址或端口是否已更改。
Whenever changes to some fundamental parts of a security protocol are proposed, the examination of security implications cannot be skipped. Therefore, here are some observations about the effects, and about whether or not these effects matter.
每当提议对安全协议的某些基本部分进行更改时，都不能跳过对安全含义的检查。因此，这里有一些关于影响的观察，以及这些影响是否重要。
o IKE probes reveal NAT-Traversal support to anyone watching the traffic. Disclosing that NAT-Traversal is supported does not introduce new vulnerabilities.
o IKE探测器向任何关注流量的人显示NAT遍历支持。披露支持NAT遍历不会引入新的漏洞。
o The value of authentication mechanisms based on IP addresses disappears once NATs are in the picture. That is not necessarily a bad thing (for any real security, authentication measures other than IP addresses should be used). This means that authentication with pre-shared keys cannot be used in Main Mode without using group-shared keys for everybody behind the NAT box. Using group shared keys is a huge risk because it allows anyone in the group to authenticate to any other party and claim to be anybody in the group; e.g., a normal user could impersonate a vpn-gateway and act as a man in the middle, and read/modify all traffic to/from others in the group. Use of group-shared keys is NOT RECOMMENDED.
o 一旦NAT出现，基于IP地址的身份验证机制的价值就会消失。这不一定是坏事（对于任何真正的安全性，应该使用IP地址以外的身份验证措施）。这意味着，在主模式下，如果不为NAT箱后面的每个人使用组共享密钥，则无法使用带有预共享密钥的身份验证。使用组共享密钥是一个巨大的风险，因为它允许组中的任何人向任何其他方进行身份验证，并声称自己是组中的任何人；例如，正常用户可以模拟VPN网关并充当中间人，并读取/修改组中的所有通信量。不建议使用组共享密钥。
o As the internal address space is only 32 bits and is usually very sparse, it might be possible for the attacker to find out the internal address used behind the NAT box by trying all possible IP-addresses to find the matching hash. The port numbers are normally fixed to 500, and the cookies can be extracted from the packet. This limits the hash calculations to 2^32. If an educated guess of the private address space is made, then the number of hash calculations needed to find out the internal IP address goes down to 2^24 + 2 * (2^16).
o 由于内部地址空间只有32位，而且通常非常稀疏，攻击者可以通过尝试所有可能的IP地址来查找匹配的哈希，从而找出NAT框后面使用的内部地址。端口号通常固定为500，并且可以从数据包中提取cookie。这将哈希计算限制为2^32。如果对私有地址空间进行了有根据的猜测，那么查找内部IP地址所需的哈希计算数量将减少到2^24+2*（2^16）。
o Neither NAT-D payloads nor Vendor ID payloads are authenticated in Main Mode nor in Aggressive Mode. This means that attacker can remove those payloads, modify them, or add them. By removing or adding them, the attacker can cause Denial of Service attacks. By modifying the NAT-D packets, the attacker can cause both ends to use UDP-Encapsulated modes instead of directly using tunnel or transport mode, thus wasting some bandwidth.
o NAT-D有效载荷和供应商ID有效载荷均未在主模式和攻击模式下进行身份验证。这意味着攻击者可以删除、修改或添加这些有效负载。通过删除或添加它们，攻击者可以导致拒绝服务攻击。通过修改NAT-D数据包，攻击者可以使两端使用UDP封装模式，而不是直接使用隧道或传输模式，从而浪费一些带宽。
o Sending the original source address in the Quick Mode reveals the internal IP address behind the NAT to the other end. In this case we have already authenticated the other end, and sending the original source address is only needed in transport mode.
o 以快速模式发送原始源地址会将NAT后面的内部IP地址显示给另一端。在这种情况下，我们已经对另一端进行了身份验证，并且只需要在传输模式下发送原始源地址。
o Updating the IKE SA/ESP UDP encapsulation IP addresses and ports for each valid authenticated packet can cause DoS if an attacker can listen to all traffic in the network, change the order of the packets, and inject new packets before the packet he has already seen. In other words, the attacker can take an authenticated packet from the host behind NAT, change the packet UDP source or destination ports or IP addresses and send it out to the other end before the real packet reaches it. The host not behind the NAT will update its IP address and port mapping and send further traffic to the wrong host or port. This situation is fixed immediately when the attacker stops modifying the packets, as the first real packet will fix the situation. Implementations SHOULD AUDIT the event every time the mapping is changed, as it should not happen that often.
o 如果攻击者能够监听网络中的所有流量，更改数据包的顺序，并在看到数据包之前注入新数据包，则为每个有效的经过身份验证的数据包更新IKE SA/ESP UDP封装IP地址和端口会导致拒绝服务。换句话说，攻击者可以从NAT后面的主机获取经过身份验证的数据包，更改数据包UDP源或目标端口或IP地址，并在实际数据包到达另一端之前将其发送到另一端。不在NAT后面的主机将更新其IP地址和端口映射，并向错误的主机或端口发送更多流量。当攻击者停止修改数据包时，这种情况会立即得到修复，因为第一个真正的数据包将修复这种情况。实现应该在每次更改映射时审核事件，因为它不应该经常发生。
This document contains two new "magic numbers" allocated from the existing IANA registry for IPsec and renames existing registered port 4500. This document also defines 2 new payload types for IKE.
本文档包含从现有IANA注册表中为IPsec分配的两个新“幻数”，并重命名现有注册端口4500。本文档还为IKE定义了2种新的有效负载类型。
The following are new items that have been added in the "Internet Security Association and Key Management Protocol (ISAKMP) Identifiers" Encapsulation Mode registry:
以下是在“Internet安全关联和密钥管理协议（ISAKMP）标识符”封装模式注册表中添加的新项：
Name Value Reference
---- ----- ---------
UDP-Encapsulated-Tunnel 3 [RFC3947]
UDP-Encapsulated-Transport 4 [RFC3947]
Name Value Reference
---- ----- ---------
UDP-Encapsulated-Tunnel 3 [RFC3947]
UDP-Encapsulated-Transport 4 [RFC3947]
Change in the registered port registry:
注册端口注册表中的更改：
Keyword Decimal Description Reference
------- ------- ----------- ---------
ipsec-nat-t 4500/tcp IPsec NAT-Traversal [RFC3947]
ipsec-nat-t 4500/udp IPsec NAT-Traversal [RFC3947]
Keyword Decimal Description Reference
------- ------- ----------- ---------
ipsec-nat-t 4500/tcp IPsec NAT-Traversal [RFC3947]
ipsec-nat-t 4500/udp IPsec NAT-Traversal [RFC3947]
New IKE payload numbers need to be added to the Next Payload Types registry:
需要将新的IKE有效负载编号添加到下一个有效负载类型注册表：
NAT-D 20 NAT Discovery Payload NAT-OA 21 NAT Original Address Payload
NAT-D 20 NAT发现有效负载NAT-OA 21 NAT原始地址有效负载
The UNSAF [RFC3424] questions are addressed by the IPsec-NAT compatibility requirements document [RFC3715].
UNSAF[RFC3424]问题由IPsec NAT兼容性要求文件[RFC3715]解决。
Thanks to Markus Stenberg, Larry DiBurro, and William Dixon, who contributed actively to this document.
感谢Markus Stenberg、Larry DiBurro和William Dixon，他们对本文件做出了积极贡献。
Thanks to Tatu Ylonen, Santeri Paavolainen, and Joern Sierwald, who contributed to the document used as the base for this document.
感谢Tatu Ylonen、Santeri Paavolainen和Joern Sierwald，他们对作为本文档基础的文档做出了贡献。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2407]Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec Packets", RFC 3948, January 2005.
[RFC3948]Huttunen，A.，Swander，B.，Volpe，V.，DiBurro，L.，和M.Stenberg，“IPsec数据包的UDP封装”，RFC 3948，2005年1月。
[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月。
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC3715]Aboba，B.和W.Dixon，“IPsec网络地址转换（NAT）兼容性要求”，RFC 3715，2004年3月。
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
[RFC3424]Daigle，L.和IAB，“网络地址转换中单边自地址固定（UNSAF）的IAB考虑”，RFC 34242002年11月。
Authors' Addresses
作者地址
Tero Kivinen SafeNet, Inc. Fredrikinkatu 47 FIN-00100 HELSINKI Finland
Tero Kivinen SafeNet，Inc.Fredrikinkatu 47 FIN-00100芬兰赫尔辛基
EMail: kivinen@safenet-inc.com
EMail: kivinen@safenet-inc.com
Ari Huttunen F-Secure Corporation Tammasaarenkatu 7, FIN-00181 HELSINKI Finland
Ari Huttunen F-Secure Corporation Tammasaarenkatu 7，FIN-00181芬兰赫尔辛基
EMail: Ari.Huttunen@F-Secure.com
EMail: Ari.Huttunen@F-Secure.com
Brian Swander Microsoft One Microsoft Way Redmond, WA 98052 USA
Brian Swander微软一路微软雷德蒙德，华盛顿州98052美国
EMail: briansw@microsoft.com
EMail: briansw@microsoft.com
Victor Volpe Cisco Systems 124 Grove Street Suite 205 Franklin, MA 02038 USA
美国马萨诸塞州富兰克林市格罗夫街124号205室维克多·沃尔普思科系统公司02038
EMail: vvolpe@cisco.com
EMail: vvolpe@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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 IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息，请参见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 currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。