Network Working Group A. Huttunen
Request for Comments: 3948 F-Secure Corporation
Category: Standards Track B. Swander
Microsoft
V. Volpe
Cisco Systems
L. DiBurro
Nortel Networks
M. Stenberg
January 2005
Network Working Group A. Huttunen
Request for Comments: 3948 F-Secure Corporation
Category: Standards Track B. Swander
Microsoft
V. Volpe
Cisco Systems
L. DiBurro
Nortel Networks
M. Stenberg
January 2005
UDP Encapsulation of IPsec ESP Packets
IPsec-ESP数据包的UDP封装
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 protocol specification defines methods to encapsulate and decapsulate IP Encapsulating Security Payload (ESP) packets inside UDP packets for traversing Network Address Translators. ESP encapsulation, as defined in this document, can be used in both IPv4 and IPv6 scenarios. Whenever negotiated, encapsulation is used with Internet Key Exchange (IKE).
本协议规范定义了在UDP数据包中封装和解封IP封装安全有效负载（ESP）数据包的方法，用于遍历网络地址转换器。本文档中定义的ESP封装可用于IPv4和IPv6方案。无论何时协商，封装都与Internet密钥交换（IKE）一起使用。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. UDP-Encapsulated ESP Header Format . . . . . . . . . . . 3
2.2. IKE Header Format for Port 4500 . . . . . . . . . . . . 4
2.3. NAT-Keepalive Packet Format . . . . . . . . . . . . . . 4
3. Encapsulation and Decapsulation Procedures . . . . . . . . . . 5
3.1. Auxiliary Procedures . . . . . . . . . . . . . . . . . . 5
3.1.1. Tunnel Mode Decapsulation NAT Procedure . . . . 5
3.1.2. Transport Mode Decapsulation NAT Procedure . . . 5
3.2. Transport Mode ESP Encapsulation . . . . . . . . . . . . 6
3.3. Transport Mode ESP Decapsulation . . . . . . . . . . . . 6
3.4. Tunnel Mode ESP Encapsulation . . . . . . . . . . . . . 7
3.5. Tunnel Mode ESP Decapsulation . . . . . . . . . . . . . 7
4. NAT Keepalive Procedure . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5.1. Tunnel Mode Conflict . . . . . . . . . . . . . . . . . . 8
5.2. Transport Mode Conflict . . . . . . . . . . . . . . . . 9
6. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 11
A. Clarification of Potential NAT Multiple Client Solutions . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. UDP-Encapsulated ESP Header Format . . . . . . . . . . . 3
2.2. IKE Header Format for Port 4500 . . . . . . . . . . . . 4
2.3. NAT-Keepalive Packet Format . . . . . . . . . . . . . . 4
3. Encapsulation and Decapsulation Procedures . . . . . . . . . . 5
3.1. Auxiliary Procedures . . . . . . . . . . . . . . . . . . 5
3.1.1. Tunnel Mode Decapsulation NAT Procedure . . . . 5
3.1.2. Transport Mode Decapsulation NAT Procedure . . . 5
3.2. Transport Mode ESP Encapsulation . . . . . . . . . . . . 6
3.3. Transport Mode ESP Decapsulation . . . . . . . . . . . . 6
3.4. Tunnel Mode ESP Encapsulation . . . . . . . . . . . . . 7
3.5. Tunnel Mode ESP Decapsulation . . . . . . . . . . . . . 7
4. NAT Keepalive Procedure . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5.1. Tunnel Mode Conflict . . . . . . . . . . . . . . . . . . 8
5.2. Transport Mode Conflict . . . . . . . . . . . . . . . . 9
6. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 11
A. Clarification of Potential NAT Multiple Client Solutions . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15
This protocol specification defines methods to encapsulate and decapsulate ESP packets inside UDP packets for traversing Network Address Translators (NATs) (see [RFC3715], section 2.2, case i). The UDP port numbers are the same as those used by IKE traffic, as defined in [RFC3947].
本协议规范定义了在UDP数据包内封装和解封ESP数据包的方法，以通过网络地址转换器（NAT）（见[RFC3715]，第2.2节，案例一）。UDP端口号与[RFC3947]中定义的IKE通信使用的端口号相同。
The sharing of the port numbers for both IKE and UDP encapsulated ESP traffic was selected because it offers better scaling (only one NAT mapping in the NAT; no need to send separate IKE keepalives), easier configuration (only one port to be configured in firewalls), and easier implementation.
选择IKE和UDP封装ESP通信的端口号共享是因为它提供了更好的扩展性（NAT中只有一个NAT映射；无需发送单独的IKE keepalives）、更容易的配置（在防火墙中只配置一个端口）和更容易的实现。
A client's needs should determine whether transport mode or tunnel mode is to be supported (see [RFC3715], Section 3, "Telecommuter scenario"). L2TP/IPsec clients MUST support the modes as defined in [RFC3193]. IPsec tunnel mode clients MUST support tunnel mode.
客户的需求应决定是否支持传输模式或隧道模式（见[RFC3715]，第3节，“远程办公场景”）。L2TP/IPsec客户端必须支持[RFC3193]中定义的模式。IPsec隧道模式客户端必须支持隧道模式。
An IKE implementation supporting this protocol specification MUST NOT use the ESP SPI field zero for ESP packets. This ensures that IKE packets and ESP packets can be distinguished from each other.
支持此协议规范的IKE实现不得对ESP数据包使用ESP SPI字段零。这确保了IKE数据包和ESP数据包可以相互区分。
As defined in this document, UDP encapsulation of ESP packets is written in terms of IPv4 headers. There is no technical reason why an IPv6 header could not be used as the outer header and/or as the inner header.
如本文档中所定义，ESP数据包的UDP封装是根据IPv4报头编写的。IPv6标头不能用作外部标头和/或内部标头没有任何技术原因。
Because the protection of the outer IP addresses in IPsec AH is inherently incompatible with NAT, the IPsec AH was left out of the scope of this protocol specification. This protocol also assumes that IKE (IKEv1 [RFC2401] or IKEv2 [IKEv2]) is used to negotiate the IPsec SAs. Manual keying is not supported.
由于IPsec AH中对外部IP地址的保护本质上与NAT不兼容，因此IPsec AH不在本协议规范的范围内。该协议还假设IKE（IKEv1[RFC2401]或IKEv2[IKEv2]）用于协商IPsec SAs。不支持手动键控。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ESP header [RFC2406] |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ESP header [RFC2406] |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The UDP header is a standard [RFC0768] header, where
UDP报头是标准[RFC0768]报头，其中
o the Source Port and Destination Port MUST be the same as that used by IKE traffic, o the IPv4 UDP Checksum SHOULD be transmitted as a zero value, and o receivers MUST NOT depend on the UDP checksum being a zero value.
o 源端口和目标端口必须与IKE通信使用的端口相同，o IPv4 UDP校验和应作为零值传输，o接收器不得依赖于UDP校验和为零值。
The SPI field in the ESP header MUST NOT be a zero value.
ESP标题中的SPI字段不得为零值。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Non-ESP Marker |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IKE header [RFC2409] |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Non-ESP Marker |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IKE header [RFC2409] |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The UDP header is a standard [RFC0768] header and is used as defined in [RFC3947]. This document does not set any new requirements for the checksum handling of an IKE packet.
UDP报头是标准[RFC0768]报头，按照[RFC3947]中的定义使用。本文件未对IKE数据包的校验和处理提出任何新要求。
A Non-ESP Marker is 4 zero-valued bytes aligning with the SPI field of an ESP packet.
非ESP标记是与ESP数据包的SPI字段对齐的4个零值字节。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xFF |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xFF |
+-+-+-+-+-+-+-+-+
The UDP header is a standard [RFC0768] header, where
UDP报头是标准[RFC0768]报头，其中
o the Source Port and Destination Port MUST be the same as used by UDP-ESP encapsulation of Section 2.1, o the IPv4 UDP Checksum SHOULD be transmitted as a zero value, and o receivers MUST NOT depend upon the UDP checksum being a zero value.
o 源端口和目标端口必须与第2.1节UDP-ESP封装使用的端口相同，o IPv4 UDP校验和应作为零值传输，o接收器不得依赖于UDP校验和为零值。
The sender MUST use a one-octet-long payload with the value 0xFF. The receiver SHOULD ignore a received NAT-keepalive packet.
发送方必须使用值为0xFF的一个八位字节长的有效负载。接收方应忽略接收到的NAT keepalive数据包。
When a tunnel mode has been used to transmit packets (see [RFC3715], section 3, criteria "Mode support" and "Telecommuter scenario"), the inner IP header can contain addresses that are not suitable for the current network. This procedure defines how these addresses are to be converted to suitable addresses for the current network.
当使用隧道模式传输数据包时（参见[RFC3715]，第3节，标准“模式支持”和“远程办公场景”），内部IP报头可能包含不适合当前网络的地址。此过程定义如何将这些地址转换为当前网络的合适地址。
Depending on local policy, one of the following MUST be done:
根据当地政策，必须执行以下操作之一：
1. If a valid source IP address space has been defined in the policy for the encapsulated packets from the peer, check that the source IP address of the inner packet is valid according to the policy. 2. If an address has been assigned for the remote peer, check that the source IP address used in the inner packet is the assigned IP address. 3. NAT is performed for the packet, making it suitable for transport in the local network.
1. 如果在策略中为来自对等方的封装数据包定义了有效的源IP地址空间，请根据策略检查内部数据包的源IP地址是否有效。2.如果已为远程对等方分配了地址，请检查内部数据包中使用的源IP地址是否为分配的IP地址。3.对数据包执行NAT，使其适合在本地网络中传输。
When a transport mode has been used to transmit packets, contained TCP or UDP headers will have incorrect checksums due to the change of parts of the IP header during transit. This procedure defines how to fix these checksums (see [RFC3715], section 2.1, case b).
当使用传输模式传输数据包时，由于传输过程中IP报头部分的更改，包含的TCP或UDP报头将具有不正确的校验和。本程序定义了如何修复这些校验和（见[RFC3715]，第2.1节，案例b）。
Depending on local policy, one of the following MUST be done:
根据当地政策，必须执行以下操作之一：
1. If the protocol header after the ESP header is a TCP/UDP header and the peer's real source and destination IP address have been received according to [RFC3947], incrementally recompute the TCP/UDP checksum:
1. 如果ESP报头后的协议报头是TCP/UDP报头，并且已根据[RFC3947]接收到对等方的真实源和目标IP地址，则增量重新计算TCP/UDP校验和：
* Subtract the IP source address in the received packet from the checksum. * Add the real IP source address received via IKE to the checksum (obtained from the NAT-OA) * Subtract the IP destination address in the received packet from the checksum. * Add the real IP destination address received via IKE to the checksum (obtained from the NAT-OA). Note: If the received and real address are the same for a given address (e.g., say the source address), the operations cancel and don't need to be performed.
* 从校验和中减去接收数据包中的IP源地址。*将通过IKE接收的真实IP源地址添加到校验和（从NAT-OA获得）*从校验和中减去接收数据包中的IP目标地址。*将通过IKE接收的真实IP目标地址添加到校验和（从NAT-OA获得）。注意：如果给定地址（例如，源地址）的接收地址和实际地址相同，则操作取消，无需执行。
2. If the protocol header after the ESP header is a TCP/UDP header, recompute the checksum field in the TCP/UDP header.
2. 如果ESP标头之后的协议标头是TCP/UDP标头，请重新计算TCP/UDP标头中的校验和字段。
3. If the protocol header after the ESP header is a UDP header, set the checksum field to zero in the UDP header. If the protocol after the ESP header is a TCP header, and if there is an option to flag to the stack that the TCP checksum does not need to be computed, then that flag MAY be used. This SHOULD only be done for transport mode, and if the packet is integrity protected. Tunnel mode TCP checksums MUST be verified. (This is not a violation to the spirit of section 4.2.2.7 in [RFC1122] because a checksum is being generated by the sender and verified by the receiver. That checksum is the integrity over the packet performed by IPsec.)
3. 如果ESP头之后的协议头是UDP头，请在UDP头中将校验和字段设置为零。如果ESP报头之后的协议是TCP报头，并且如果有选项向堆栈标记不需要计算TCP校验和，则可以使用该标记。这应该只在传输模式下进行，并且如果数据包是完整性保护的。必须验证隧道模式TCP校验和。（这并不违反[RFC1122]第4.2.2.7节的精神，因为发送方正在生成校验和，接收方正在验证校验和。该校验和是IPsec执行的数据包完整性。）
In addition an implementation MAY fix any contained protocols that have been broken by NAT (see [RFC3715], section 2.1, case g).
此外，实现可以修复NAT破坏的任何包含的协议（参见[RFC3715]，第2.1节，案例g）。
BEFORE APPLYING ESP/UDP
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
BEFORE APPLYING ESP/UDP
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
AFTER APPLYING ESP/UDP
-------------------------------------------------------
IPv4 |orig IP hdr | UDP | ESP | | | ESP | ESP|
|(any options)| Hdr | Hdr | TCP | Data | Trailer |Auth|
-------------------------------------------------------
|<----- encrypted ---->|
|<------ authenticated ----->|
AFTER APPLYING ESP/UDP
-------------------------------------------------------
IPv4 |orig IP hdr | UDP | ESP | | | ESP | ESP|
|(any options)| Hdr | Hdr | TCP | Data | Trailer |Auth|
-------------------------------------------------------
|<----- encrypted ---->|
|<------ authenticated ----->|
1. Ordinary ESP encapsulation procedure is used. 2. A properly formatted UDP header is inserted where shown. 3. The Total Length, Protocol, and Header Checksum (for IPv4) fields in the IP header are edited to match the resulting IP packet.
1. 使用普通ESP封装程序。2.在显示的位置插入格式正确的UDP标头。3.将编辑IP报头中的总长度、协议和报头校验和（对于IPv4）字段，以匹配生成的IP数据包。
1. The UDP header is removed from the packet. 2. The Total Length, Protocol, and Header Checksum (for IPv4) fields in the new IP header are edited to match the resulting IP packet. 3. Ordinary ESP decapsulation procedure is used. 4. Transport mode decapsulation NAT procedure is used.
1. UDP标头将从数据包中删除。2.编辑新IP报头中的总长度、协议和报头校验和（IPv4）字段，以匹配生成的IP数据包。3.采用普通ESP脱胶程序。4.使用传输模式去封装NAT程序。
BEFORE APPLYING ESP/UDP
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
BEFORE APPLYING ESP/UDP
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
AFTER APPLYING ESP/UDP
--------------------------------------------------------------
IPv4 |new h.| UDP | ESP |orig IP hdr | | | ESP | ESP|
|(opts)| Hdr | Hdr |(any options)| TCP | Data | Trailer |Auth|
--------------------------------------------------------------
|<------------ encrypted ----------->|
|<------------- authenticated ------------>|
AFTER APPLYING ESP/UDP
--------------------------------------------------------------
IPv4 |new h.| UDP | ESP |orig IP hdr | | | ESP | ESP|
|(opts)| Hdr | Hdr |(any options)| TCP | Data | Trailer |Auth|
--------------------------------------------------------------
|<------------ encrypted ----------->|
|<------------- authenticated ------------>|
1. Ordinary ESP encapsulation procedure is used. 2. A properly formatted UDP header is inserted where shown. 3. The Total Length, Protocol, and Header Checksum (for IPv4) fields in the new IP header are edited to match the resulting IP packet.
1. 使用普通ESP封装程序。2.在显示的位置插入格式正确的UDP标头。3.编辑新IP报头中的总长度、协议和报头校验和（IPv4）字段，以匹配生成的IP数据包。
1. The UDP header is removed from the packet. 2. The Total Length, Protocol, and Header Checksum (for IPv4) fields in the new IP header are edited to match the resulting IP packet. 3. Ordinary ESP decapsulation procedure is used. 4. Tunnel mode decapsulation NAT procedure is used.
1. UDP标头将从数据包中删除。2.编辑新IP报头中的总长度、协议和报头校验和（IPv4）字段，以匹配生成的IP数据包。3.采用普通ESP脱胶程序。4.采用隧道模式去封装NAT程序。
The sole purpose of sending NAT-keepalive packets is to keep NAT mappings alive for the duration of a connection between the peers (see [RFC3715], Section 2.2, case j). Reception of NAT-keepalive packets MUST NOT be used to detect whether a connection is live.
发送NAT keepalive数据包的唯一目的是在对等方之间的连接期间保持NAT映射活动（参见[RFC3715]，第2.2节，案例j）。NAT keepalive数据包的接收不得用于检测连接是否处于活动状态。
A peer MAY send a NAT-keepalive packet if one or more phase I or phase II SAs exist between the peers, or if such an SA has existed at most N minutes earlier. N is a locally configurable parameter with a default value of 5 minutes.
如果对等方之间存在一个或多个阶段I或阶段II SA，或者如果这样的SA在最多N分钟之前已经存在，则对等方可以发送NAT keepalive分组。N是一个本地可配置参数，默认值为5分钟。
A peer SHOULD send a NAT-keepalive packet if a need for it is detected according to [RFC3947] and if no other packet to the peer has been sent in M seconds. M is a locally configurable parameter with a default value of 20 seconds.
如果根据[RFC3947]检测到需要NAT keepalive数据包，并且在M秒内没有向对等方发送其他数据包，则对等方应发送NAT keepalive数据包。M是一个本地可配置参数，默认值为20秒。
Implementors are warned that it is possible for remote peers to negotiate entries that overlap in an SGW (security gateway), an issue affecting tunnel mode (see [RFC3715], section 2.1, case e).
警告实施者，远程对等方可能协商SGW（安全网关）中重叠的条目，这是一个影响隧道模式的问题（请参阅[RFC3715]，第2.1节，案例e）。
+----+ \ /
| |-------------|----\
+----+ / \ \
Ari's NAT 1 \
Laptop \
10.1.2.3 \
+----+ \ / \ +----+ +----+
| |-------------|----------+------| |----------| |
+----+ / \ +----+ +----+
Bob's NAT 2 SGW Suzy's
Laptop Server
10.1.2.3
+----+ \ /
| |-------------|----\
+----+ / \ \
Ari's NAT 1 \
Laptop \
10.1.2.3 \
+----+ \ / \ +----+ +----+
| |-------------|----------+------| |----------| |
+----+ / \ +----+ +----+
Bob's NAT 2 SGW Suzy's
Laptop Server
10.1.2.3
Because SGW will now see two possible SAs that lead to 10.1.2.3, it can become confused about where to send packets coming from Suzy's server. Implementors MUST devise ways of preventing this from occurring.
因为SGW现在将看到两个可能的SA，它们将导致10.1.2.3，所以它可能会对从Suzy的服务器发送数据包的位置感到困惑。实施者必须设计防止这种情况发生的方法。
It is RECOMMENDED that SGW either assign locally unique IP addresses to Ari's and Bob's laptop (by using a protocol such as DHCP over IPsec) or use NAT to change Ari's and Bob's laptop source IP addresses to these locally unique addresses before sending packets forward to Suzy's server. This covers the "Scaling" criteria of section 3 in [RFC3715].
建议SGW为Ari和Bob的笔记本电脑分配本地唯一的IP地址（通过使用协议，如通过IPsec的DHCP），或使用NAT将Ari和Bob的笔记本电脑源IP地址更改为这些本地唯一地址，然后再将数据包转发给Suzy的服务器。这涵盖了[RFC3715]第3节中的“缩放”标准。
Please see Appendix A.
请参见附录A。
Another similar issue may occur in transport mode, with 2 clients, Ari and Bob, behind the same NAT talking securely to the same server (see [RFC3715], Section 2.1, case e).
另一个类似的问题可能发生在传输模式中，同一NAT后面的两个客户端Ari和Bob安全地与同一服务器通信（请参见[RFC3715]，第2.1节，案例e）。
Cliff wants to talk in the clear to the same server.
克里夫想和同一个服务器说清楚。
+----+
| |
+----+ \
Ari's \
Laptop \
10.1.2.3 \
+----+ \ / +----+
| |-----+-----------------| |
+----+ / \ +----+
Bob's NAT Server
Laptop /
10.1.2.4 /
/
+----+ /
| |/
+----+
Cliff's
Laptop
10.1.2.5
+----+
| |
+----+ \
Ari's \
Laptop \
10.1.2.3 \
+----+ \ / +----+
| |-----+-----------------| |
+----+ / \ +----+
Bob's NAT Server
Laptop /
10.1.2.4 /
/
+----+ /
| |/
+----+
Cliff's
Laptop
10.1.2.5
Now, transport SAs on the server will look like this:
现在，服务器上的传输SAs将如下所示：
To Ari: Server to NAT, <traffic desc1>, UDP encap <4500, Y>
To Ari: Server to NAT, <traffic desc1>, UDP encap <4500, Y>
To Bob: Server to NAT, <traffic desc2>, UDP encap <4500, Z>
To Bob: Server to NAT, <traffic desc2>, UDP encap <4500, Z>
Cliff's traffic is in the clear, so there is no SA.
克里夫的交通是畅通的，所以没有SA。
<traffic desc> is the protocol and port information. The UDP encap ports are the ports used in UDP-encapsulated ESP format of section 2.1. Y,Z are the dynamic ports assigned by the NAT during the IKE negotiation. So IKE traffic from Ari's laptop goes out on UDP <4500,4500>. It reaches the server as UDP <Y,4500>, where Y is the dynamically assigned port.
<traffic desc>是协议和端口信息。UDP encap端口是第2.1节UDP封装ESP格式中使用的端口。Y、 Z是NAT在IKE协商期间分配的动态端口。所以来自Ari笔记本电脑的IKE流量通过UDP<4500>传输。它以UDP<Y，4500>的形式到达服务器，其中Y是动态分配的端口。
If the <traffic desc1> overlaps <traffic desc2>, then simple filter lookups may not be sufficient to determine which SA has to be used to send traffic. Implementations MUST handle this situation, either by disallowing conflicting connections, or by other means.
如果<traffic desc1>与<traffic desc2>重叠，则简单的筛选器查找可能不足以确定必须使用哪个SA发送流量。实现必须通过禁止冲突连接或其他方式来处理这种情况。
Assume now that Cliff wants to connect to the server in the clear. This is going to be difficult to configure, as the server already has a policy (from Server to the NAT's external address) for securing <traffic desc>. For totally non-overlapping traffic descriptions, this is possible.
现在假设Cliff想要连接到服务器。这将很难配置，因为服务器已经有一个策略（从服务器到NAT的外部地址）用于保护<traffic desc>。对于完全不重叠的流量描述，这是可能的。
Sample server policy could be as follows:
示例服务器策略可以如下所示：
To Ari: Server to NAT, All UDP, secure
到Ari：服务器到NAT，所有UDP，安全
To Bob: Server to NAT, All TCP, secure
到Bob：服务器到NAT，所有TCP，安全
To Cliff: Server to NAT, ALL ICMP, clear text
到悬崖：服务器到NAT，所有ICMP，明文
Note that this policy also lets Ari and Bob send cleartext ICMP to the server.
注意，此策略还允许Ari和Bob向服务器发送明文ICMP。
The server sees all clients behind the NAT as the same IP address, so setting up different policies for the same traffic descriptor is in principle impossible.
服务器将NAT后面的所有客户端视为相同的IP地址，因此原则上不可能为相同的流量描述符设置不同的策略。
A problematic example of configuration on the server is as follows:
服务器上的一个有问题的配置示例如下：
Server to NAT, TCP, secure (for Ari and Bob)
服务器到NAT、TCP、安全（用于Ari和Bob）
Server to NAT, TCP, clear (for Cliff)
服务器到NAT、TCP、清除（用于Cliff）
The server cannot enforce his policy, as it is possible that misbehaving Bob sends traffic in the clear. This is indistinguishable from when Cliff sends traffic in the clear. So it is impossible to guarantee security from some clients behind a NAT, while allowing clear text from different clients behind the SAME NAT. If the server's security policy allows this, however, it can do best-effort security: If the client from behind the NAT initiates security, his connection will be secured. If he sends in the clear, the server will still accept that clear text.
服务器无法强制执行其策略，因为行为不端的Bob可能会以明文形式发送流量。这和克利夫在晴朗的天气里送出交通是无法区分的。因此，不可能保证NAT后面的某些客户端的安全性，同时允许同一NAT后面的不同客户端发送明文。但是，如果服务器的安全策略允许这样做，它可以尽最大努力实现安全性：如果NAT后面的客户端启动安全性，他的连接将得到保护。如果他发送明文，服务器仍然会接受明文。
For security guarantees, the above problematic scenario MUST NOT be allowed on servers. For best effort security, this scenario MAY be used.
为了保证安全，服务器上不允许出现上述有问题的情况。为了尽最大努力确保安全性，可以使用此场景。
Please see Appendix A.
请参见附录A。
The UNSAF [RFC3424] questions are addressed by the IPsec-NAT compatibility requirements document [RFC3715].
UNSAF[RFC3424]问题由IPsec NAT兼容性要求文件[RFC3715]解决。
Thanks to Tero Kivinen and William Dixon, who contributed actively to this document.
感谢Tero Kivinen和William Dixon，他们对本文件做出了积极贡献。
Thanks to Joern Sierwald, Tamir Zegman, Tatu Ylonen, and Santeri Paavolainen, who contributed to the early documents about NAT traversal.
感谢Joern Sierwald、Tamir Zegman、Tatu Ylonen和Santeri Paavolainen，他们对有关NAT穿越的早期文件做出了贡献。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[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月。
[RFC3947] Kivinen, T., "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005.
[RFC3947]Kivinen，T.，“IKE中NAT穿越的协商”，RFC 3947，2005年1月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, "Securing L2TP using IPsec", RFC 3193, November 2001.
[RFC3193]Patel，B.，Aboba，B.，Dixon，W.，Zorn，G.，和S.Booth，“使用IPsec保护L2TP”，RFC 3193，2001年11月。
[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月。
[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月。
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", Work in Progress, October 2004.
[IKEv2]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，正在进行的工作，2004年10月。
This appendix provides clarification about potential solutions to the problem of multiple clients behind the same NAT simultaneously connecting to the same destination IP address.
本附录对同一NAT后面的多个客户端同时连接到同一目标IP地址的问题的潜在解决方案进行了说明。
Sections 5.1 and 5.2 say that you MUST avoid this problem. As this is not a matter of wire protocol, but a matter local implementation, the mechanisms do not belong in the protocol specification itself. They are instead listed in this appendix.
第5.1节和第5.2节指出，您必须避免此问题。由于这不是有线协议的问题，而是本地实现的问题，因此这些机制不属于协议规范本身。它们在本附录中列出。
Choosing an option will likely depend on the scenarios for which one uses/supports IPsec NAT-T. This list is not meant to be exhaustive, so other solutions may exist. We first describe the generic choices that solve the problem for all upper-layer protocols.
选择选项可能取决于使用/支持IPsec NAT-T的场景。此列表并不详尽，因此可能存在其他解决方案。我们首先描述解决所有上层协议问题的通用选择。
Generic choices for ESP transport mode:
ESP传输模式的一般选择：
Tr1) Implement a built-in NAT (network address translation) above IPsec decapsulation.
Tr1）在IPsec解除封装之上实现内置NAT（网络地址转换）。
Tr2) Implement a built-in NAPT (network address port translation) above IPsec decapsulation.
Tr2）在IPsec解除封装之上实现内置NAPT（网络地址端口转换）。
Tr3) An initiator may decide not to request transport mode once NAT is detected and may instead request a tunnel-mode SA. This may be a retry after transport mode is denied by the responder, or the initiator may choose to propose a tunnel SA initially. This is no more difficult than knowing whether to propose transport mode or tunnel mode without NAT. If for some reason the responder prefers or requires tunnel mode for NAT traversal, it must reject the quick mode SA proposal for transport mode.
Tr3）一旦检测到NAT，发起方可以决定不请求传输模式，而是请求隧道模式SA。这可能是在传输模式被响应方拒绝后的重试，或者发起方可以选择最初提出隧道SA。这并不比知道是否提出无NAT的传输模式或隧道模式更困难。如果出于某种原因，响应者更喜欢或需要NAT穿越的隧道模式，则必须拒绝传输模式的快速模式SA建议。
Generic choices for ESP tunnel mode:
ESP隧道模式的一般选择：
Tn1) Same as Tr1.
Tn1）与Tr1相同。
Tn2) Same as Tr2.
Tn2）与Tr2相同。
Tn3) This option is possible if an initiator can be assigned an address through its tunnel SA, with the responder using DHCP. The initiator may initially request an internal address via the DHCP-IPsec method, regardless of whether it knows it is behind a NAT. It may re-initiate an IKE quick mode negotiation for DHCP tunnel SA after the responder fails the quick mode SA transport mode proposal. This happens either when a NAT-OA payload is sent or because it
Tn3）如果启动器可以通过其通道SA分配地址，且响应程序使用DHCP，则此选项是可能的。发起者最初可以通过DHCP IPsec方法请求内部地址，而不管它是否知道它在NAT后面。在响应者未能通过快速模式SA传输模式建议后，它可能会重新启动DHCP隧道SA的IKE快速模式协商。这发生在NAT-OA有效负载被发送时，或者是因为
discovers from NAT-D that the initiator is behind a NAT and its local configuration/policy will only accept a NAT connection when being assigned an address through DHCP-IPsec.
从NAT-D发现发起程序位于NAT后面，且其本地配置/策略仅在通过DHCP IPsec分配地址时才接受NAT连接。
There are also implementation choices that offer limited interoperability. Implementors should specify which applications or protocols should work if these options are selected. Note that neither Tr4 nor Tn4, as described below, are expected to work with TCP traffic.
还有一些实现选项提供有限的互操作性。如果选择了这些选项，实现者应该指定哪些应用程序或协议应该工作。请注意，Tr4和Tn4（如下所述）均不适用于TCP流量。
Limited interoperability choices for ESP transport mode:
ESP传输模式的有限互操作性选择：
Tr4) Implement upper-layer protocol awareness of the inbound and outbound IPsec SA so that it doesn't use the source IP and the source port as the session identifier (e.g., an L2TP session ID mapped to the IPsec SA pair that doesn't use the UDP source port or the source IP address for peer uniqueness).
Tr4）实现入站和出站IPsec SA的上层协议感知，使其不使用源IP和源端口作为会话标识符（例如，映射到IPsec SA对的L2TP会话ID不使用UDP源端口或源IP地址实现对等唯一性）。
Tr5) Implement application integration with IKE initiation so that it can rebind to a different source port if the IKE quick mode SA proposal is rejected by the responder; then it can repropose the new QM selector.
Tr5）实现与IKE启动的应用程序集成，以便在IKE快速模式SA建议被响应者拒绝时，可以重新绑定到不同的源端口；然后它可以重新设置新的QM选择器。
Limited interoperability choices for ESP tunnel mode:
ESP隧道模式的有限互操作性选择：
Tn4) Same as Tr4.
Tn4）与Tr4相同。
Authors' Addresses
作者地址
Ari Huttunen F-Secure Corporation Tammasaarenkatu 7 HELSINKI FIN-00181 FI
Ari Huttunen F-Secure Corporation Tammasaarenkatu 7赫尔辛基FIN-00181 FI
EMail: Ari.Huttunen@F-Secure.com
EMail: Ari.Huttunen@F-Secure.com
Brian Swander Microsoft One Microsoft Way Redmond, WA 98052 US
Brian Swander美国华盛顿州雷德蒙德微软One Microsoft Way Redmond 98052
EMail: briansw@microsoft.com
EMail: briansw@microsoft.com
Victor Volpe Cisco Systems 124 Grove Street Suite 205 Franklin, MA 02038 US
美国马萨诸塞州富兰克林市格罗夫街124号205室维克多·沃尔普思科系统公司02038
EMail: vvolpe@cisco.com
EMail: vvolpe@cisco.com
Larry DiBurro Nortel Networks 80 Central Street Boxborough, MA 01719 US
美国马萨诸塞州Boxborough中央大街80号Larry DiBurro Nortel Networks 01719
EMail: ldiburro@nortelnetworks.com
EMail: ldiburro@nortelnetworks.com
Markus Stenberg FI
马库斯·斯滕伯格·菲
EMail: markus.stenberg@iki.fi
EMail: markus.stenberg@iki.fi
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编辑功能的资金目前由互联网协会提供。