Network Working Group B. Aboba
Request for Comments: 3715 W. Dixon
Category: Informational Microsoft
March 2004
Network Working Group B. Aboba
Request for Comments: 3715 W. Dixon
Category: Informational Microsoft
March 2004
IPsec-Network Address Translation (NAT) Compatibility Requirements
IPsec网络地址转换（NAT）兼容性要求
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
Abstract
摘要
This document describes known incompatibilities between Network Address Translation (NAT) and IPsec, and describes the requirements for addressing them. Perhaps the most common use of IPsec is in providing virtual private networking capabilities. One very popular use of Virtual Private Networks (VPNs) is to provide telecommuter access to the corporate Intranet. Today, NATs are widely deployed in home gateways, as well as in other locations likely to be used by telecommuters, such as hotels. The result is that IPsec-NAT incompatibilities have become a major barrier in the deployment of IPsec in one of its principal uses.
本文档描述了网络地址转换（NAT）和IPsec之间已知的不兼容，并描述了解决这些不兼容的要求。IPsec最常见的用途可能是提供虚拟专用网络功能。虚拟专用网络（VPN）的一个非常流行的用途是为远程工作者提供对公司内部网的访问。如今，NAT被广泛部署在家庭网关以及其他可能被远程工作者使用的位置，如酒店。其结果是，IPsec NAT不兼容已成为IPsec在其主要用途之一中部署的主要障碍。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language. . . . . . . . . . . . . . . . . . 2
2. Known Incompatibilities between NA(P)T and IPsec . . . . . . . 3
2.1. Intrinsic NA(P)T Issues. . . . . . . . . . . . . . . . . 3
2.2. NA(P)T Implementation Weaknesses . . . . . . . . . . . . 7
2.3. Helper Incompatibilities . . . . . . . . . . . . . . . . 8
3. Requirements for IPsec-NAT Compatibility . . . . . . . . . . . 8
4. Existing Solutions . . . . . . . . . . . . . . . . . . . . . . 12
4.1. IPsec Tunnel Mode. . . . . . . . . . . . . . . . . . . . 12
4.2. RSIP . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3. 6to4 . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 14
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Normative References . . . . . . . . . . . . . . . . . . 15
6.2. Informative References . . . . . . . . . . . . . . . . . 16
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
9 . Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language. . . . . . . . . . . . . . . . . . 2
2. Known Incompatibilities between NA(P)T and IPsec . . . . . . . 3
2.1. Intrinsic NA(P)T Issues. . . . . . . . . . . . . . . . . 3
2.2. NA(P)T Implementation Weaknesses . . . . . . . . . . . . 7
2.3. Helper Incompatibilities . . . . . . . . . . . . . . . . 8
3. Requirements for IPsec-NAT Compatibility . . . . . . . . . . . 8
4. Existing Solutions . . . . . . . . . . . . . . . . . . . . . . 12
4.1. IPsec Tunnel Mode. . . . . . . . . . . . . . . . . . . . 12
4.2. RSIP . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3. 6to4 . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 14
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Normative References . . . . . . . . . . . . . . . . . . 15
6.2. Informative References . . . . . . . . . . . . . . . . . 16
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
9 . Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18
Perhaps the most common use of IPsec [RFC2401] is in providing virtual private networking (VPN) capabilities. One very popular use of VPNs is to provide telecommuter access to the corporate Intranet. Today, Network Address Translations (NATs) as described in [RFC3022] and [RFC2663], are widely deployed in home gateways, as well as in other locations likely to be used by telecommuters, such as hotels. The result is that IPsec-NAT incompatibilities have become a major barrier in the deployment of IPsec in one of its principal uses. This document describes known incompatibilities between NAT and IPsec, and describes the requirements for addressing them.
IPsec[RFC2401]最常见的用途可能是提供虚拟专用网络（VPN）功能。VPN的一个非常流行的用途是为远程工作者提供对公司内部网的访问。如今，[RFC3022]和[RFC2663]中描述的网络地址转换（NAT）被广泛部署在家庭网关中，以及远程工作者可能使用的其他位置，如酒店。其结果是，IPsec NAT不兼容已成为IPsec在其主要用途之一中部署的主要障碍。本文档描述了NAT和IPsec之间已知的不兼容，并描述了解决这些不兼容的要求。
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC2119].
在本文件中，关键词“可能”、“必须”、“不得”、“可选”、“建议”、“应该”和“不应该”应按照[RFC2119]中所述进行解释。
Please note that the requirements specified in this document are to be used in evaluating protocol submissions. As such, the requirements language refers to capabilities of these protocols; the protocol documents will specify whether these features are required, recommended, or optional. For example, requiring that a protocol support confidentiality is not the same thing as requiring that all protocol traffic be encrypted.
请注意，本文件中规定的要求将用于评估协议提交。因此，需求语言指的是这些协议的能力；协议文件将指定这些功能是必需的、推荐的还是可选的。例如，要求协议支持保密性与要求对所有协议通信量进行加密不同。
A protocol submission is not compliant if it fails to satisfy one or more of the MUST or MUST NOT requirements for the capabilities that it implements. A protocol submission that satisfies all the MUST, MUST NOT, SHOULD, and SHOULD NOT requirements for its capabilities is said to be "unconditionally compliant"; one that satisfies all the MUST and MUST NOT requirements, but not all the SHOULD or SHOULD NOT requirements for its protocols is said to be "conditionally compliant."
如果协议提交未能满足其实现的功能的一个或多个必须或不得要求，则该协议提交不符合要求。满足其能力的所有必须、不得、应该和不应该要求的协议提交称为“无条件符合”；一个满足所有必须和不必须要求，但并非所有协议应该或不应该要求的协议称为“有条件兼容”
The incompatibilities between NA(P)T and IPsec can be divided into three categories:
NA（P）T和IPsec之间的不兼容可分为三类：
1) Intrinsic NA(P)T issues. These incompatibilities derive directly from the NA(P)T functionality described in [RFC3022]. These incompatibilities will therefore be present in any NA(P)T device.
1) 固有的NA（P）T问题。这些不兼容性直接源自[RFC3022]中描述的NA（P）T功能。因此，任何NA（P）T设备中都会存在这些不兼容性。
2) NA(P)T implementation weaknesses. These incompatibilities are not intrinsic to NA(P)T, but are present in many NA(P)T implementations. Included in this category are problems in handling inbound or outbound fragments. Since these issues are not intrinsic to NA(P)T, they can, in principle, be addressed in future NA(P)T implementations. However, since the implementation problems appear to be wide spread, they need to be taken into account in a NA(P)T traversal solution.
2) NA（P）T实施缺陷。这些不兼容性不是NA（P）T固有的，而是存在于许多NA（P）T实现中。此类别中包括处理入站或出站片段的问题。由于这些问题不是NA（P）T固有的，因此原则上，它们可以在将来的NA（P）T实现中解决。然而，由于实现问题似乎广泛存在，因此在NA（P）T遍历解决方案中需要考虑这些问题。
3) Helper issues. These incompatibilities are present in NA(P)T devices which attempt to provide for IPsec NA(P)T traversal. Ironically, this "helper" functionality creates further incompatibilities, making an already difficult problem harder to solve. While IPsec traversal "helper" functionality is not present in all NA(P)Ts, these features are becoming sufficiently popular that they also need to be taken into account in a NA(P)T traversal solution.
3) 助手问题。这些不兼容存在于尝试提供IPsec NA（P）T遍历的NA（P）T设备中。具有讽刺意味的是，这种“助手”功能造成了进一步的不兼容性，使得已经很难解决的问题变得更难解决。虽然IPsec遍历“helper”功能并不存在于所有NA（P）T中，但这些功能正变得非常流行，因此在NA（P）T遍历解决方案中也需要考虑这些功能。
Incompatibilities that are intrinsic to NA(P)T include:
NA（P）T固有的不兼容性包括：
a) Incompatibility between IPsec AH [RFC2402] and NAT. Since the AH header incorporates the IP source and destination addresses in the keyed message integrity check, NAT or reverse NAT devices making changes to address fields will invalidate the message integrity check. Since IPsec ESP [RFC2406] does not incorporate the IP source and destination addresses in its keyed message integrity check, this issue does not arise for ESP.
a) IPsec AH[RFC2402]和NAT之间不兼容。由于AH报头在密钥消息完整性检查中包含IP源地址和目标地址，因此更改地址字段的NAT或反向NAT设备将使消息完整性检查无效。由于IPsec ESP[RFC2406]未在其密钥消息完整性检查中包含IP源地址和目标地址，因此ESP不会出现此问题。
b) Incompatibility between checksums and NAT. TCP and UDP checksums have a dependency on the IP source and destination addresses through inclusion of the "pseudo-header" in the calculation. As a result, where checksums are calculated and checked upon receipt, they will be invalidated by passage through a NAT or reverse NAT device.
b) 校验和与NAT之间不兼容。TCP和UDP校验和通过在计算中包含“伪头”而依赖于IP源地址和目标地址。因此，如果在接收时计算并检查校验和，则通过NAT或反向NAT设备，校验和将无效。
As a result, IPsec Encapsulating Security Payload (ESP) will only pass through a NAT unimpeded if TCP/UDP protocols are not involved (as in IPsec tunnel mode or IPsec protected GRE), or checksums are not calculated (as is possible with IPv4 UDP). As described in [RFC793], TCP checksum calculation and verification is required in IPv4. UDP/TCP checksum calculation and verification is required in IPv6.
因此，如果不涉及TCP/UDP协议（如在IPsec隧道模式或IPsec保护的GRE中），或者未计算校验和（如在IPv4 UDP中可能），IPsec封装安全有效负载（ESP）将只会不受阻碍地通过NAT。如[RFC793]所述，IPv4中需要TCP校验和计算和验证。IPv6中需要UDP/TCP校验和计算和验证。
Stream Control Transmission Protocol (SCTP), as defined in [RFC2960] and [RFC3309], uses a CRC32C algorithm calculated only on the SCTP packet (common header + chunks), so that the IP header is not covered. As a result, NATs do not invalidate the SCTP CRC, and the problem does not arise.
[RFC2960]和[RFC3309]中定义的流控制传输协议（SCTP）使用仅在SCTP数据包（公共报头+数据块）上计算的CRC32C算法，因此不覆盖IP报头。因此，NAT不会使SCTP CRC无效，也不会出现问题。
Note that since transport mode IPsec traffic is integrity protected and authenticated using strong cryptography, modifications to the packet can be detected prior to checking UDP/TCP checksums. Thus, checksum verification only provides assurance against errors made in internal processing.
请注意，由于传输模式IPsec通信是使用强加密技术进行完整性保护和身份验证的，因此可以在检查UDP/TCP校验和之前检测到对数据包的修改。因此，校验和验证只能保证内部处理中不会出现错误。
c) Incompatibility between IKE address identifiers and NAT. Where IP addresses are used as identifiers in Internet Key Exchange Protocol (IKE) Phase 1 [RFC2409] or Phase 2, modification of the IP source or destination addresses by NATs or reverse NATs will result in a mismatch between the identifiers and the addresses in the IP header. As described in [RFC2409], IKE implementations are required to discard such packets.
c) IKE地址标识符和NAT之间不兼容。当IP地址用作Internet密钥交换协议（IKE）第1阶段[RFC2409]或第2阶段中的标识符时，通过NAT或反向NAT修改IP源地址或目标地址将导致标识符与IP报头中的地址不匹配。如[RFC2409]中所述，需要IKE实现来丢弃此类数据包。
In order to avoid use of IP addresses as IKE Phase 1 and Phase 2 identifiers, userIDs and FQDNs can be used instead. Where user authentication is desired, an ID type of ID_USER_FQDN can be used, as described in [RFC2407]. Where machine authentication is desired, an ID type of ID_FQDN can be used. In either case, it is necessary to verify that the proposed identifier is authenticated as a result of processing an end-entity certificate, if certificates are exchanged in Phase 1. While use of USER_FQDN or FQDN identity types is possible within IKE, there are usage scenarios (e.g. Security Policy Database (SPD) entries describing subnets) that cannot be accommodated this way.
为了避免将IP地址用作IKE阶段1和阶段2标识符，可以使用用户ID和FQDN。在需要用户身份验证的情况下，可以使用ID_user_FQDN的ID类型，如[RFC2407]中所述。如果需要机器身份验证，可以使用ID_FQDN的ID类型。在任何一种情况下，如果在阶段1中交换了证书，则有必要验证提议的标识符是否作为处理最终实体证书的结果进行了身份验证。虽然可以在IKE中使用用户FQDN或FQDN标识类型，但存在无法以这种方式适应的使用场景（例如，描述子网的安全策略数据库（SPD）条目）。
Since the source address in the Phase 2 identifier is often used to form a full 5-tuple inbound SA selector, the destination address, protocol, source port and destination port can be used in the selector so as not to weaken inbound SA processing.
由于阶段2标识符中的源地址通常用于形成完整的5元组入站SA选择器，因此可以在选择器中使用目标地址、协议、源端口和目标端口，以免削弱入站SA处理。
d) Incompatibility between fixed IKE source ports and NAPT. Where multiple hosts behind the NAPT initiate IKE SAs to the same responder, a mechanism is needed to allow the NAPT to demultiplex the incoming IKE packets from the responder. This is typically accomplished by translating the IKE UDP source port on outbound packets from the initiator. Thus responders must be able to accept IKE traffic from a UDP source port other than 500, and must reply to that port. Care must be taken to avoid unpredictable behavior during re-keys. If the floated source port is not used as the destination port for the re-key, the NAT may not be able to send the re-key packets to the correct destination.
d) 固定IKE源端口和NAPT之间不兼容。如果NAPT后面的多个主机向同一响应程序发起IKE SA，则需要一种机制来允许NAPT对来自响应程序的传入IKE数据包进行解复用。这通常通过转换来自启动器的出站数据包上的IKE UDP源端口来实现。因此，响应者必须能够接受来自UDP源端口（而非500）的IKE通信，并且必须回复该端口。在重新设置密钥期间，必须注意避免出现不可预知的行为。如果浮动源端口未用作重设密钥的目标端口，NAT可能无法将重设密钥数据包发送到正确的目标。
e) Incompatibilities between overlapping SPD entries and NAT. Where initiating hosts behind a NAT use their source IP addresses in Phase 2 identifiers, they can negotiate overlapping SPD entries with the same responder IP address. The responder could then send packets down the wrong IPsec SA. This occurs because to the responder, the IPsec SAs appear to be equivalent, since they exist between the same endpoints and can be used to pass the same traffic.
e) 重叠的SPD条目和NAT之间不兼容。当NAT后面的发起主机在第2阶段标识符中使用其源IP地址时，它们可以使用相同的响应方IP地址协商重叠的SPD条目。然后，响应程序可能会将数据包发送到错误的IPsec SA。发生这种情况的原因是，对于响应者来说，IPsec SA似乎是等效的，因为它们存在于相同的端点之间，可以用于传递相同的通信量。
f) Incompatibilities between IPsec SPI selection and NAT. Since IPsec ESP traffic is encrypted and thus opaque to the NAT, the NAT must use elements of the IP and IPsec header to demultiplex incoming IPsec traffic. The combination of the destination IP address, security protocol (AH/ESP), and IPsec SPI is typically used for this purpose.
f) IPsec SPI选择和NAT之间不兼容。由于IPsec ESP通信是加密的，因此对NAT是不透明的，所以NAT必须使用IP和IPsec报头的元素来解复用传入的IPsec通信。目标IP地址、安全协议（AH/ESP）和IPsec SPI的组合通常用于此目的。
However, since the outgoing and incoming SPIs are chosen independently, there is no way for the NAT to determine what incoming SPI corresponds to what destination host merely by inspecting outgoing traffic. Thus, were two hosts behind the NAT to attempt to create IPsec SAs at the same destination simultaneously, it is possible that the NAT will deliver the incoming IPsec packets to the wrong destination.
然而，由于出站和入站SPI是独立选择的，因此NAT无法仅仅通过检查出站流量来确定哪个入站SPI对应于哪个目的主机。因此，如果NAT后面的两台主机试图同时在同一个目的地创建IPsec SAs，则NAT可能会将传入的IPsec数据包传递到错误的目的地。
Note that this is not an incompatibility with IPsec per se, but rather with the way it is typically implemented. With both AH and ESP, the receiving host specifies the SPI to use for a given SA, a choice which is significant only to the receiver. At present, the combination of Destination IP, SPI, and Security Protocol (AH, ESP) uniquely identifies a Security Association. Also, SPI values in the range 1-255 are reserved to IANA and may be used in the
请注意，这并非与IPsec本身不兼容，而是与IPsec通常的实现方式不兼容。对于AH和ESP，接收主机指定要用于给定SA的SPI，该选择仅对接收器有效。目前，目标IP、SPI和安全协议（AH、ESP）的组合唯一地标识安全关联。此外，范围为1-255的SPI值保留给IANA，可用于
future. This means that, when negotiating with the same external host or gateway, the internal hosts behind the same NAPT can select the same SPI value, such that one host inbound SA is (SPI=470, Internal Dest IP=192.168.0.4) and a different host inbound SA is (SPI=470, Internal Dest IP=192.168.0.5). The receiving NAPT will not be able to determine which internal host an inbound IPsec packet with SPI=470 should be forwarded to.
将来这意味着，当与同一外部主机或网关协商时，同一NAPT后面的内部主机可以选择相同的SPI值，这样一个主机入站SA为（SPI=470，内部目的地IP=192.168.0.4），另一个主机入站SA为（SPI=470，内部目的地IP=192.168.0.5）。接收NAPT将无法确定SPI=470的入站IPsec数据包应转发到哪个内部主机。
It is also possible for the receiving host to allocate a unique SPI to each unicast Security Association. In this case, the Destination IP Address need only be checked to see if it is "any valid unicast IP for this host", not checked to see if it is the specific Destination IP address used by the sending host. Using this technique, the NA(P)T can be assured of a low but non-zero chance of forwarding packets to the wrong internal host, even when two or more hosts establish SAs with the same external host.
接收主机也可以为每个单播安全关联分配唯一的SPI。在这种情况下，只需检查目标IP地址是否为“此主机的任何有效单播IP”，而不检查它是否为发送主机使用的特定目标IP地址。使用此技术，即使两个或多个主机与同一外部主机建立sa，NA（P）T也可以确保将数据包转发到错误的内部主机的机会很低但非零。
This approach is completely backwards compatible, and only requires the particular receiving host to make a change to its SPI allocation and IPsec_esp_input() code. However, NA(P)T devices may not be able to detect this behavior without problems associated with parsing IKE payloads. And a host may still be required to use a SPI in the IANA reserved range for the assigned purpose.
这种方法完全向后兼容，只需要特定的接收主机对其SPI分配和IPsec_esp_input（）代码进行更改。但是，如果没有与解析IKE有效负载相关的问题，NA（P）T设备可能无法检测到这种行为。并且主机可能仍然需要为指定目的使用IANA保留范围内的SPI。
g) Incompatibilities between embedded IP addresses and NAT. Since the payload is integrity protected, any IP addresses enclosed within IPsec packets will not be translatable by a NAT. This renders ineffective Application Layer Gateways (ALGs) implemented within NATs. Protocols that utilize embedded IP addresses include FTP, IRC, SNMP, LDAP, H.323, SIP, SCTP (optionally), and many games. To address this issue, it is necessary to install ALGs on the host or security gateway that can operate on application traffic prior to IPsec encapsulation and after IPsec decapsulation.
g) 嵌入式IP地址和NAT之间不兼容。由于有效负载受完整性保护，因此包含在IPsec数据包中的任何IP地址都不能被NAT转换。这使得NAT中实现的应用层网关（ALG）无效。利用嵌入式IP地址的协议包括FTP、IRC、SNMP、LDAP、H.323、SIP、SCTP（可选）和许多游戏。要解决此问题，必须在主机或安全网关上安装ALG，以便在IPsec封装之前和IPsec解除封装之后对应用程序流量进行操作。
h) Implicit directionality of NA(P)T. NA(P)Ts often require an initial outbound packet to flow through them in order to create an inbound mapping state. Directionality prohibits unsolicited establishment of IPsec SAs to hosts behind the NA(P)T.
h) NA（P）T的隐式方向性。NA（P）T通常需要一个初始出站数据包流经它们，以创建入站映射状态。方向性禁止主动向NA（P）T后面的主机建立IPsec sa。
i) Inbound SA selector verification. Assuming IKE negotiates phase 2 selectors, inbound SA processing will drop the decapsulated packet, since [RFC2401] requires a packet's source address match the SA selector value, which NA(P)T processing of an ESP packet would change.
i) 入站SA选择器验证。假设IKE协商第2阶段选择器，入站SA处理将丢弃未封装的数据包，因为[RFC2401]要求数据包的源地址与SA选择器值匹配，ESP数据包的NA（P）T处理将改变该值。
Implementation problems present in many NA(P)Ts include:
许多NA（P）Ts中存在的实施问题包括：
j) Inability to handle non-UDP/TCP traffic. Some NA(P)Ts discard non-UDP/TCP traffic or perform address-only translation when only one host is behind the NAT. Such NAPTs are unable to enable SCTP, ESP (protocol 50), or AH (protocol 51) traffic.
j) 无法处理非UDP/TCP流量。当只有一个主机位于NAT后面时，一些NA（P）T丢弃非UDP/TCP通信或执行仅地址转换。此类NAPT无法启用SCTP、ESP（协议50）或AH（协议51）通信。
k) NAT mapping timeouts. NA(P)Ts vary in the time for which a UDP mapping will be maintained in the absence of traffic. Thus, even where IKE packets can be correctly translated, the translation state may be removed prematurely.
k) NAT映射超时。NA（P）Ts在没有流量的情况下保持UDP映射的时间不同。因此，即使在可以正确翻译IKE分组的情况下，也可能过早地移除翻译状态。
l) Inability to handle outgoing fragments. Most NA(P)Ts can properly fragment outgoing IP packets in the case where the IP packet size exceeds the MTU on the outgoing interface. However, proper translation of outgoing packets that are already fragmented is difficult and most NAPTs do not handle this correctly. As noted in Section 6.3 of [RFC3022], where two hosts originate fragmented packets to the same destination, the fragment identifiers can overlap. Since the destination host relies on the fragmentation identifier and fragment offset for reassembly, the result will be data corruption. Few NA(P)Ts protect against identifier collisions by supporting identifier translation. Identifier collisions are not an issue when NATs perform the fragmentation, since the fragment identifier need only be unique within a source/destination IP address pair.
l) 无法处理传出片段。大多数NA（P）Ts可以在IP包大小超过传出接口上的MTU的情况下正确地分割传出IP包。然而，对已经支离破碎的传出数据包进行正确的翻译是困难的，大多数NAPT不能正确地处理这一点。如[RFC3022]第6.3节所述，当两台主机向同一目的地发起碎片数据包时，碎片标识符可能重叠。由于目标主机依赖碎片标识符和碎片偏移量进行重新组装，因此结果将是数据损坏。很少有NA（P）T通过支持标识符转换来防止标识符冲突。当NAT执行分段时，标识符冲突不是问题，因为分段标识符只需要在源/目标IP地址对中是唯一的。
Since a fragment can be as small as 68 octets [RFC791], there is no guarantee that the first fragment will contain a complete TCP header. Thus, a NA(P)T looking to recalculate the TCP checksum may need to modify a subsequent fragment. Since fragments can be reordered, and IP addresses can be embedded and possibly even split between fragments, the NA(P)T will need to perform reassembly prior to completing the translation. Few NA(P)Ts support this.
由于片段可以小到68个八位字节[RFC791]，因此无法保证第一个片段将包含完整的TCP头。因此，希望重新计算TCP校验和的NA（P）T可能需要修改后续片段。由于片段可以重新排序，IP地址可以嵌入，甚至可以在片段之间分割，NA（P）T需要在完成翻译之前执行重新组装。很少有NA（P）T支持这一点。
m) Inability to handle incoming fragments. Since only the first fragment will typically contain a complete IP/UDP/SCTP/TCP header, NAPTs need to be able to perform the translation based on the source/dest IP address and fragment identifier alone. Since fragments can be reordered, the headers to a given fragment identifier may not be known if a subsequent fragment arrives prior to the initial one, and the headers may be split between fragments. As a result, the NAPT may need to perform reassembly prior to completing the translation. Few NAPTs support this. Note that with NAT, the source/dest IP address is enough to
m) 无法处理传入的片段。由于通常只有第一个片段包含完整的IP/UDP/SCTP/TCP头，NAPTs需要能够仅基于源/目的IP地址和片段标识符执行转换。由于片段可以重新排序，如果后续片段在初始片段之前到达，则给定片段标识符的头可能不知道，并且头可能在片段之间分割。因此，NAPT可能需要在完成翻译之前重新组装。很少有国家行动方案支持这一点。注意，对于NAT，源/目的IP地址足以
determine the translation so that this does not arise. However, it is possible for the IPsec or IKE headers to be split between fragments, so that reassembly may still be required.
确定翻译，以免出现这种情况。但是，IPsec或IKE头可能在片段之间拆分，因此可能仍然需要重新组装。
Incompatibilities between IPsec and NAT "helper" functionality include:
IPsec和NAT“helper”功能之间的不兼容包括：
n) Internet Security Association and Key Management Protocol (ISAKMP) header inspection. Today some NAT implementations attempt to use IKE cookies to de-multiplex incoming IKE traffic. As with source-port de-multiplexing, IKE cookie de-multiplexing results in problems with re-keying, since Phase 1 re-keys typically will not use the same cookies as the earlier traffic.
n) Internet安全关联和密钥管理协议（ISAKMP）标头检查。今天，一些NAT实现尝试使用IKE cookie来解复用传入的IKE流量。与源端口解复用一样，IKE cookie解复用会导致密钥重设问题，因为阶段1重设密钥通常不会使用与早期流量相同的cookie。
o) Special treatment of port 500. Since some IKE implementations are unable to handle non-500 UDP source ports, some NATs do not translate packets with a UDP source port of 500. This means that these NATs are limited to one IPsec client per destination gateway, unless they inspect details of the ISAKMP header to examine cookies which creates the problem noted above.
o) 港口500的特殊处理。由于某些IKE实现无法处理非500 UDP源端口，因此某些NAT不会转换UDP源端口为500的数据包。这意味着这些NAT仅限于每个目标网关一个IPsec客户端，除非它们检查ISAKMP头的详细信息以检查导致上述问题的Cookie。
p) ISAKMP payload inspection. NA(P)T implementations that attempt to parse ISAKMP payloads may not handle all payload ordering combinations, or support vendor_id payloads for IKE option negotiation.
p) ISAKMP有效载荷检查。尝试解析ISAKMP有效载荷的NA（P）T实现可能无法处理所有有效载荷排序组合，或者不支持IKE选项协商的供应商id有效载荷。
The goal of an IPsec-NAT compatibility solution is to expand the range of usable IPsec functionality beyond that available in the NAT-compatible IPsec tunnel mode solution described in Section 2.3.
IPsec NAT兼容性解决方案的目标是将可用IPsec功能的范围扩展到第2.3节所述的NAT兼容IPsec隧道模式解决方案中的范围之外。
In evaluating a solution to IPsec-NAT incompatibility, the following criteria should be kept in mind:
在评估IPsec NAT不兼容的解决方案时，应记住以下标准：
Deployment
部署
Since IPv6 will address the address scarcity issues that frequently lead to use of NA(P)Ts with IPv4, the IPsec-NAT compatibility issue is a transitional problem that needs to be solved in the time frame prior to widespread deployment of IPv6. Therefore, to be useful, an IPsec-NAT compatibility solution MUST be deployable on a shorter time scale than IPv6.
由于IPv6将解决经常导致在IPv4中使用NA（P）Ts的地址不足问题，因此IPsec NAT兼容性问题是一个过渡问题，需要在IPv6广泛部署之前的时间范围内解决。因此，要发挥作用，IPsec NAT兼容性解决方案必须能够在比IPv6更短的时间范围内部署。
Since IPv6 deployment requires changes to routers as well as hosts, a potential IPsec-NAT compatibility solution, which requires changes to both routers and hosts, will be deployable on approximately the same time scale as IPv6. Thus, an IPsec-NAT compatibility solution SHOULD require changes only to hosts, and not to routers.
由于IPv6部署需要更改路由器和主机，因此需要更改路由器和主机的潜在IPsec NAT兼容性解决方案将可在与IPv6大致相同的时间尺度上部署。因此，IPsec NAT兼容性解决方案应该只需要更改主机，而不需要更改路由器。
Among other things, this implies that communication between the host and the NA(P)T SHOULD NOT be required by an IPsec-NAT compatibility solution, since that would require changes to the NA(P)Ts, and interoperability testing between the host and NA(P)T implementations. In order to enable deployment in the short term, it is necessary for the solution to work with existing router and NA(P)T products within the deployed infrastructure.
除其他事项外，这意味着IPsec NAT兼容性解决方案不需要主机和NA（P）T之间的通信，因为这将需要更改NA（P）T，以及主机和NA（P）T实现之间的互操作性测试。为了在短期内实现部署，解决方案必须与部署的基础架构中的现有路由器和NA（P）T产品配合使用。
Protocol Compatibility
协议兼容性
An IPsec NAT traversal solution is not expected to resolve issues with protocols that cannot traverse NA(P)T when unsecured with IPsec. Therefore, ALGs may still be needed for some protocols, even when an IPsec NAT traversal solution is available.
IPsec NAT穿越解决方案不应解决在IPsec不安全时无法穿越NA（P）T的协议的问题。因此，某些协议可能仍然需要ALG，即使IPsec NAT穿越解决方案可用。
Security
安全
Since NA(P)T directionality serves a security function, IPsec NA(P)T traversal solutions should not allow arbitrary incoming IPsec or IKE traffic from any IP address to be received by a host behind the NA(P)T, although mapping state should be maintained once bidirectional IKE and IPsec communication is established.
由于NA（P）T方向性服务于安全功能，因此IPsec NA（P）T遍历解决方案不应允许NA（P）T后面的主机接收来自任何IP地址的任意传入IPsec或IKE通信，尽管在建立双向IKE和IPsec通信后应保持映射状态。
Telecommuter Scenario
远程办公情景
Since one of the primary uses of IPsec is remote access to corporate Intranets, a NA(P)T traversal solution MUST support NA(P)T traversal, via either IPsec tunnel mode or L2TP over IPsec transport mode [RFC3193]. This includes support for traversal of more than one NA(P)T between the remote client and the VPN gateway.
由于IPsec的主要用途之一是远程访问公司内部网，因此NA（P）T遍历解决方案必须支持NA（P）T遍历，通过IPsec隧道模式或L2TP over IPsec传输模式[RFC3193]。这包括支持在远程客户端和VPN网关之间遍历多个NA（P）T。
The client may have a routable address and the VPN gateway may be behind at least one NA(P)T, or alternatively, both the client and the VPN gateway may be behind one or more NA(P)Ts. Telecommuters may use the same private IP address, each behind their own NA(P)T, or many telecommuters may reside on a private network behind the same NA(P)T, each with their own unique private address, connecting to the same VPN gateway. Since IKE uses UDP port 500 as the destination, it is not necessary to enable multiple VPN gateways operating behind the same external IP address.
客户端可以具有可路由地址，并且VPN网关可以位于至少一个NA（P）T之后，或者可选地，客户端和VPN网关都可以位于一个或多个NA（P）T之后。远程工作者可以使用相同的私有IP地址，每一个都位于他们自己的NA（P）T之后，或者许多远程工作者可以位于相同NA（P）T之后的私有网络上，每个都有自己独特的专用地址，连接到同一VPN网关。由于IKE使用UDP端口500作为目的地，因此无需启用在同一外部IP地址后面运行的多个VPN网关。
Gateway-to-Gateway Scenario
网关到网关场景
In a gateway-gateway scenario, a privately addressed network (DMZ) may be inserted between the corporate network and the Internet. In this design, IPsec security gateways connecting portions of the corporate network may be resident in the DMZ and have private addresses on their external (DMZ) interfaces. A NA(P)T connects the DMZ network to the Internet.
在网关场景中，可以在公司网络和互联网之间插入专用寻址网络（DMZ）。在该设计中，连接公司网络部分的IPsec安全网关可以驻留在DMZ中，并且在其外部（DMZ）接口上具有专用地址。NA（P）T将DMZ网络连接到Internet。
End-to-End Scenario
端到端场景
A NAT-IPsec solution MUST enable secure host-host TCP/IP communication via IPsec, as well as host-gateway communications. A host on a private network MUST be able to bring up one or multiple IPsec-protected TCP connections or UDP sessions to another host with one or more NA(P)Ts between them. For example, NA(P)Ts may be deployed within branch offices connecting to the corporate network, with an additional NA(P)T connecting the corporate network to the Internet. Likewise, NA(P)Ts may be deployed within a corporate network LAN or WAN to connect wireless or remote location clients to the corporate network. This may require special processing of TCP and UDP traffic on the host.
NAT IPsec解决方案必须能够通过IPsec实现安全的主机TCP/IP通信以及主机网关通信。专用网络上的主机必须能够将一个或多个受IPsec保护的TCP连接或UDP会话连接到另一个主机，并且在它们之间有一个或多个NA（P）Ts。例如，NA（P）Ts可以部署在连接到公司网络的分支办公室内，另外的NA（P）Ts将公司网络连接到因特网。类似地，NA（P）Ts可部署在公司网络LAN或WAN内，以将无线或远程位置客户端连接到公司网络。这可能需要在主机上对TCP和UDP通信进行特殊处理。
Bringing up SCTP connections to another host with one or more NA(P)Ts between them may present special challenges. SCTP supports multi-homing. If more than one IP address is used, these addresses are transported as part of the SCTP packet during the association setup (in the INIT and INIT-ACK chunks). If only single homed SCTP end-points are used, [RFC2960] section 3.3.2.1 states:
将SCTP连接带到另一台主机（它们之间有一个或多个NA（P）T），可能会带来特殊的挑战。SCTP支持多归宿。如果使用了多个IP地址，则在关联设置期间（在INIT和INIT-ACK块中），这些地址将作为SCTP数据包的一部分传输。如果仅使用单宿SCTP端点，[RFC2960]第3.3.2.1节规定：
Note that not using any IP address parameters in the INIT and INIT-ACK is an alternative to make an association more likely to work across a NAT box.
请注意，在INIT和INIT-ACK中不使用任何IP地址参数是使关联更有可能跨NAT盒工作的替代方法。
This implies that IP addresses should not be put into the SCTP packet unless necessary. If NATs are present and IP addresses are included, then association setup will fail. Recently [AddIP] has been proposed which allows the modification of the IP address once an association is established. The modification messages have also IP addresses in the SCTP packet, and so will be adversely affected by NATs.
这意味着除非必要，否则不应将IP地址放入SCTP数据包中。如果存在NAT且包含IP地址，则关联设置将失败。最近提出了[AddIP]，允许在建立关联后修改IP地址。修改消息在SCTP数据包中也有IP地址，因此会受到NAT的不利影响。
Firewall Compatibility
防火墙兼容性
Since firewalls are widely deployed, a NAT-IPsec compatibility solution MUST enable a firewall administrator to create simple, static access rule(s) to permit or deny IKE and IPsec NA(P)T traversal traffic. This implies, for example, that dynamic allocation of IKE or IPsec destination ports is to be avoided.
由于防火墙被广泛部署，NAT IPsec兼容性解决方案必须使防火墙管理员能够创建简单的静态访问规则，以允许或拒绝IKE和IPsec NA（P）T穿越流量。例如，这意味着要避免动态分配IKE或IPsec目标端口。
Scaling
缩放比例
An IPsec-NAT compatibility solution should be capable of being deployed within an installation consisting of thousands of telecommuters. In this situation, it is not possible to assume that only a single host is communicating with a given destination at a time. Thus, an IPsec-NAT compatibility solution MUST address the issue of overlapping SPD entries and de-multiplexing of incoming packets.
IPsec NAT兼容性解决方案应该能够部署在由数千名远程工作者组成的安装中。在这种情况下，不可能假设一次只有一台主机与给定的目的地通信。因此，IPsec NAT兼容性解决方案必须解决SPD条目重叠和传入数据包解复用的问题。
Mode Support
模式支持
At a minimum, an IPsec-NAT compatibility solution MUST support traversal of the IKE and IPsec modes required for support within [RFC2409] and [RFC2401]. For example, an IPsec gateway MUST support ESP tunnel mode NA(P)T traversal, and an IPsec host MUST support IPsec transport mode NA(P)T traversal. The purpose of AH is to protect immutable fields within the IP header (including addresses), and NA(P)T translates addresses, invalidating the AH integrity check. As a result, NA(P)T and AH are fundamentally incompatible and there is no requirement that an IPsec-NAT compatibility solution support AH transport or tunnel mode.
IPsec NAT兼容性解决方案至少必须支持遍历[RFC2409]和[RFC2401]中支持所需的IKE和IPsec模式。例如，IPsec网关必须支持ESP隧道模式NA（P）T遍历，IPsec主机必须支持IPsec传输模式NA（P）T遍历。AH的目的是保护IP报头中的不可变字段（包括地址），NA（P）T转换地址，从而使AH完整性检查无效。因此，NA（P）T和AH基本上是不兼容的，并且不要求IPsec NAT兼容解决方案支持AH传输或隧道模式。
Backward Compatibility and Interoperability
向后兼容性和互操作性
An IPsec-NAT compatibility solution MUST be interoperable with existing IKE/IPsec implementations, so that they can communicate where no NA(P)T is present. This implies that an IPsec-NAT compatibility solution MUST be backwards-compatible with IPsec as defined in [RFC2401] and IKE as defined in [RFC2409]. In addition, it SHOULD be able to detect the presence of a NA(P)T, so that NA(P)T traversal support is only used when necessary. This implies that it MUST be possible to determine that an existing IKE implementation does not support NA(P)T traversal, so that a standard IKE conversation can occur, as described in [RFC2407], [RFC2408], and [RFC2409]. Note that while this implies initiation of IKE to port 500, there is no requirement for a specific source port, so that UDP source port 500 may or may not be used.
IPsec NAT兼容性解决方案必须与现有IKE/IPsec实现互操作，以便它们能够在不存在NA（P）T的地方进行通信。这意味着IPsec NAT兼容性解决方案必须与[RFC2401]中定义的IPsec和[RFC2409]中定义的IKE向后兼容。此外，它应该能够检测NA（P）T的存在，以便仅在必要时使用NA（P）T遍历支持。这意味着必须能够确定现有IKE实现不支持NA（P）T遍历，以便可以发生标准IKE会话，如[RFC2407]、[RFC2408]和[RFC2409]中所述。请注意，虽然这意味着启动端口500的IKE，但不需要特定的源端口，因此可以使用也可以不使用UDP源端口500。
Security
安全
An IPsec-NAT compatibility solution MUST NOT introduce additional IKE or IPsec security vulnerabilities. For example, an acceptable solution must demonstrate that it introduces no new denial of service or spoofing vulnerabilities. IKE MUST be allowed to re-key in a bi-directional manner as described in [RFC2408].
IPsec NAT兼容性解决方案不得引入额外的IKE或IPsec安全漏洞。例如，一个可接受的解决方案必须证明它不会引入新的拒绝服务或欺骗漏洞。必须允许IKE以双向方式重新设置密钥，如[RFC2408]中所述。
In a limited set of circumstances, it is possible for an IPsec tunnel mode implementation, such as that described in [DHCP], to traverse NA(P)T successfully. However, the requirements for successful traversal are sufficiently limited so that a more general solution is needed:
在一组有限的情况下，IPsec隧道模式实现（如[DHCP]中所述）有可能成功地遍历NA（P）T。但是，成功遍历的要求受到足够的限制，因此需要一个更通用的解决方案：
1) IPsec ESP. IPsec ESP tunnels do not cover the outer IP header within the message integrity check, and so will not suffer Authentication Data invalidation due to address translation. IPsec tunnels also need not be concerned about checksum invalidation.
1) IPsec ESP。IPsec ESP隧道不会覆盖消息完整性检查中的外部IP头，因此不会因地址转换而导致身份验证数据无效。IPsec隧道也不需要担心校验和失效。
2) No address validation. Most current IPsec tunnel mode implementations do not perform source address validation so that incompatibilities between IKE identifiers and source addresses will not be detected. This introduces security vulnerabilities as described in Section 5.
2) 没有地址验证。大多数当前的IPsec隧道模式实现不执行源地址验证，因此不会检测到IKE标识符和源地址之间的不兼容。这引入了第5节中描述的安全漏洞。
3) "Any to Any" SPD entries. IPsec tunnel mode clients can negotiate "any to any" SPDs, which are not invalidated by address translation. This effectively precludes use of SPDs for the filtering of allowed tunnel traffic.
3) “任意对任意”SPD条目。IPsec隧道模式客户端可以协商“任意对任意”SPD，这些SPD不会因地址转换而失效。这有效地排除了使用SPD过滤允许的隧道流量。
4) Single client operation. With only a single client behind a NAT, there is no risk of overlapping SPDs. Since the NAT will not need to arbitrate between competing clients, there is also no risk of re-key mis-translation, or improper incoming SPI or cookie de-multiplexing.
4) 单客户端操作。由于NAT后面只有一个客户端，因此不存在SPD重叠的风险。由于NAT将不需要在竞争客户机之间进行仲裁，因此也不存在重新设置密钥的错误翻译，或不正确的传入SPI或cookie解复用的风险。
5) No fragmentation. When certificate authentication is used, IKE fragmentation can be encountered. This can occur when certificate chains are used, or even when exchanging a single certificate if the key size, or the size of other certificate fields (such as the distinguished name and other extensions), is large enough. However, when pre-shared keys are used for authentication, fragmentation is less likely.
5) 没有碎片。使用证书身份验证时，可能会遇到IKE碎片。当使用证书链时，或者如果密钥大小或其他证书字段（如可分辨名称和其他扩展名）的大小足够大，甚至在交换单个证书时，都可能发生这种情况。然而，当预共享密钥用于身份验证时，碎片化的可能性较小。
6) Active sessions. Most VPN sessions typically maintain ongoing traffic flow during their lifetime so that UDP port mappings are less likely be removed due to inactivity.
6) 活动会话。大多数VPN会话通常在其生存期内保持持续的通信流，因此UDP端口映射不太可能由于不活动而被删除。
RSIP, described in [RSIP] and [RSIPFrame], includes mechanisms for IPsec traversal, as described in [RSIPsec]. By enabling host-NA(P)T communication, RSIP addresses issues of IPsec SPI de-multiplexing, as well as SPD overlap. It is thus suitable for use in enterprises, as well as home networking scenarios. By enabling hosts behind a NAT to share the external IP address of the NA(P)T (the RSIP gateway), this approach is compatible with protocols including embedded IP addresses.
[RSIP]和[RSIPFrame]中描述的RSIP包括[RSIPsec]中描述的IPsec遍历机制。通过启用主机NA（P）T通信，RSIP解决了IPsec SPI解复用以及SPD重叠的问题。因此，它适用于企业以及家庭网络场景。通过使NAT后面的主机能够共享NA（P）T（RSIP网关）的外部IP地址，这种方法与包括嵌入式IP地址在内的协议兼容。
By tunneling IKE and IPsec packets, RSIP avoids changes to the IKE and IPsec protocols, although major changes are required to host IKE and IPsec implementations to retrofit them for RSIP-compatibility. It is thus compatible with all existing protocols (AH/ESP) and modes (transport and tunnel).
通过隧道传输IKE和IPsec数据包，RSIP避免了对IKE和IPsec协议的更改，尽管托管IKE和IPsec实现需要进行重大更改，以便对其进行改装以实现RSIP兼容性。因此，它与所有现有协议（AH/ESP）和模式（传输和隧道）兼容。
In order to handle de-multiplexing of IKE re-keys, RSIP requires floating of the IKE source port, as well as re-keying to the floated port. As a result, interoperability with existing IPsec implementations is not assured.
为了处理IKE重密钥的解复用，RSIP需要浮动IKE源端口，以及重新设置浮动端口的密钥。因此，无法确保与现有IPsec实现的互操作性。
RSIP does not satisfy the deployment requirements for an IPsec-NAT compatibility solution because an RSIP-enabled host requires a corresponding RSIP-enabled gateway in order to establish an IPsec SA with another host. Since RSIP requires changes only to clients and routers and not to servers, it is less difficult to deploy than IPv6. However, for vendors, implementation of RSIP requires a substantial fraction of the resources required for IPv6 support. Thus, RSIP solves a "transitional" problem on a long-term time scale, which is not useful.
RSIP不满足IPsec NAT兼容性解决方案的部署要求，因为启用RSIP的主机需要相应的启用RSIP的网关才能与其他主机建立IPsec SA。由于RSIP只需要对客户端和路由器进行更改，而不需要对服务器进行更改，因此它比IPv6更易于部署。然而，对于供应商来说，RSIP的实现需要IPv6支持所需资源的一大部分。因此，RSIP在长期时间尺度上解决了一个“过渡”问题，这是没有用的。
6to4, as described in [RFC3056] can form the basis for an IPsec-NAT traversal solution. In this approach, the NAT provides IPv6 hosts with an IPv6 prefix derived from the NAT external IPv4 address, and encapsulates IPv6 packets in IPv4 for transmission to other 6to4 hosts or 6to4 relays. This enables an IPv6 host using IPsec to communicate freely to other hosts within the IPv6 or 6to4 clouds.
[RFC3056]中所述的6to4可以构成IPsec NAT穿越解决方案的基础。在这种方法中，NAT为IPv6主机提供从NAT外部IPv4地址派生的IPv6前缀，并将IPv6数据包封装在IPv4中，以便传输到其他6to4主机或6to4中继。这使使用IPsec的IPv6主机能够与IPv6或6to4云中的其他主机自由通信。
While 6to4 is an elegant and robust solution where a single NA(P)T separates a client and VPN gateway, it is not universally applicable. Since 6to4 requires the assignment of a routable IPv4 address to the NA(P)T in order to allow formation of an IPv6 prefix, it is not usable where multiple NA(P)Ts exist between the client and VPN
虽然6to4是一个优雅而健壮的解决方案，其中一个NA（P）T将客户端和VPN网关分隔开，但它并不普遍适用。由于6to4需要向NA（P）T分配可路由的IPv4地址以允许形成IPv6前缀，因此当客户端和VPN之间存在多个NA（P）T时，它不可用
gateway. For example, an NA(P)T with a private address on its external interface cannot be used by clients behind it to obtain an IPv6 prefix via 6to4.
网关。例如，在其外部接口上具有私有地址的NA（P）T不能被其后面的客户端用于通过6to4获得IPv6前缀。
While 6to4 requires little additional support from hosts that already support IPv6, it does require changes to NATs, which need to be upgraded to support 6to4. As a result, 6to4 may not be suitable for deployment in the short term.
虽然6to4几乎不需要已经支持IPv6的主机提供额外的支持，但它确实需要更改NAT，而NAT需要升级以支持6to4。因此，6to4在短期内可能不适合部署。
By definition, IPsec-NAT compatibility requires that hosts and routers implementing IPsec be capable of securely processing packets whose IP headers are not cryptographically protected. A number of issues arise from this that are worth discussing.
根据定义，IPsec NAT兼容性要求实现IPsec的主机和路由器能够安全地处理IP头不受加密保护的数据包。由此产生了许多值得讨论的问题。
Since IPsec AH cannot pass through a NAT, one of the side effects of providing an IPsec-NAT compatibility solution may be for IPsec ESP with null encryption to be used in place of AH where a NAT exists between the source and destination. However, it should be noted that ESP with null encryption does not provide the same security properties as AH. For example, there are security risks relating to IPv6 source routing that are precluded by AH, but not by ESP with null encryption.
由于IPsec AH无法通过NAT，因此提供IPsec NAT兼容性解决方案的一个副作用可能是在源和目标之间存在NAT的情况下，使用带有空加密的IPsec ESP代替AH。但是，应该注意，使用空加密的ESP不提供与AH相同的安全属性。例如，存在与IPv6源路由相关的安全风险，AH排除了这些风险，而ESP使用空加密则不排除这些风险。
In addition, since ESP with any transform does not protect against source address spoofing, some sort of source IP address sanity checking needs to be performed. The importance of the anti-spoofing check is not widely understood. There is normally an anti-spoofing check on the Source IP Address as part of IPsec_{esp,ah}_input(). This ensures that the packet originates from the same address as that claimed within the original IKE Phase 1 and Phase 2 security associations. When a receiving host is behind a NAT, this check might not strictly be meaningful for unicast sessions, whereas in the Global Internet this check is important for tunnel-mode unicast sessions to prevent a spoofing attack described in [AuthSource], which can occur when access controls on the receiver depend upon the source IP address of verified ESP packets after decapsulation. IPsec-NAT compatibility schemes should provide anti-spoofing protection if it uses source addresses for access controls.
此外，由于带有任何转换的ESP不能防止源地址欺骗，因此需要执行某种源IP地址健全性检查。反欺骗检查的重要性尚未得到广泛理解。作为IPsec_{esp，ah}_input（）的一部分，通常会对源IP地址进行反欺骗检查。这确保数据包来自与原始IKE阶段1和阶段2安全关联中声明的地址相同的地址。当接收主机位于NAT后面时，此检查对于单播会话可能没有严格意义，而在全局Internet中，此检查对于隧道模式单播会话非常重要，以防止[AuthSource]中描述的欺骗攻击，当接收器上的访问控制取决于解除封装后已验证ESP数据包的源IP地址时，可能会发生这种情况。如果IPsec NAT兼容方案使用源地址进行访问控制，则应提供防欺骗保护。
Let us consider two hosts, A and C, both behind (different) NATs, who negotiate IPsec tunnel mode SAs to router B. Hosts A and C may have different privileges; for example, host A might belong to an employee trusted to access much of the corporate Intranet, while C might be a contractor only authorized to access a specific web site.
让我们考虑两个主机，A和C，后面（不同）NATS，谁协商IPSec隧道模式SAS到路由器B。主机A和C可能有不同的特权；例如，主机A可能属于被信任可以访问大部分公司内部网的员工，而C可能是仅被授权访问特定网站的承包商。
If host C sends a tunnel mode packet spoofing A's IP address as the source, it is important that this packet not be accorded the privileges corresponding to A. If authentication and integrity checking is performed, but no anti-spoofing check (verifying that the originating IP address corresponds to the SPI) then host C may be allowed to reach parts of the network that are off limits. As a result, an IPsec-NAT compatibility scheme MUST provide some degree of anti-spoofing protection.
如果主机C发送一个隧道模式数据包，欺骗a的IP地址作为源，则该数据包不得被授予与a相对应的特权。如果执行了身份验证和完整性检查，但未进行反欺骗检查（验证原始IP地址是否与SPI相对应）然后，可以允许主机C访问网络中禁止访问的部分。因此，IPsec NAT兼容性方案必须提供一定程度的防欺骗保护。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，“互联网协议”，标准5，RFC7911981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[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] Atkinson, R. and S. Kent, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]Atkinson，R.和S.Kent，“互联网协议的安全架构”，RFC 2401，1998年11月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC2402]Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，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月。
[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月。
[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月。
[RFC2663] Srisuresh, P. and M. Holdredge, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663]Srisuresh，P.和M.Holdredge，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，1999年8月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022]Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 3022，2001年1月。
[RFC2408] Maughan, D., Schertler, M., Schneider, M. and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[RFC2408]Maughan，D.，Schertler，M.，Schneider，M.和J.Turner，“互联网安全协会和密钥管理协议（ISAKMP）”，RFC 2408，1998年11月。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, M. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2960]Stewart，R.，Xie，Q.，Morneault，K.，Sharp，C.，Schwarzbauer，H.，Taylor，T.，Rytina，I.，Kalla，M.，Zhang，M.和V.Paxson，“流控制传输协议”，RFC 29602000年10月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]Carpenter，B.和K.Moore，“通过IPv4云连接IPv6域”，RFC 3056，2001年2月。
[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月。
[RFC3309] Stone, J., Stewart, R. and D. Otis, "Stream Control Transmission Protocol (SCTP) Checksum Change", RFC 3309, September 2002.
[RFC3309]Stone，J.，Stewart，R.和D.Otis，“流控制传输协议（SCTP）校验和更改”，RFC 33092002年9月。
[RSIPFrame] Borella, M., Lo, J., Grabelsky, D. and G. Montenegro, "Realm Specific IP: Framework", RFC 3102, October 2001.
[RSIPFrame]Borella，M.，Lo，J.，Grabelsky，D.和G.黑山，“特定领域知识产权：框架”，RFC 3102，2001年10月。
[RSIP] Borella, M., Grabelsky, D., Lo, J. and K. Taniguchi, "Realm Specific IP: Protocol Specification", RFC 3103, October 2001.
[RSIP]Borella，M.，Grabelsky，D.，Lo，J.和K.Taniguchi，“领域特定IP：协议规范”，RFC 3103，2001年10月。
[RSIPsec] Montenegro, G. and M. Borella, "RSIP Support for End-to-End IPsec", RFC 3104, October 2001.
[RSIPsec]黑山，G.和M.Borella，“RSIP对端到端IPsec的支持”，RFC 3104，2001年10月。
[DHCP] Patel, B., Aboba, B., Kelly, S. and V. Gupta, "Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode", RFC 3456, January 2003.
[DHCP]Patel，B.，Aboba，B.，Kelly，S.和V.Gupta，“IPsec隧道模式的动态主机配置协议（DHCPv4）配置”，RFC 3456，2003年1月。
[AuthSource] Kent, S., "Authenticated Source Addresses", IPsec WG Archive (ftp://ftp.ans.net/pub/archive/IPsec), Message-Id: <v02130517ad121773c8ed@[128.89.0.110]>, January 5, 1996.
[AuthSource]Kent，S.，“已验证的源地址”，IPsec WG存档(ftp://ftp.ans.net/pub/archive/IPsec)，消息Id:<v02130517ad121773c8ed@[128.89.0.110]>，1996年1月5日。
[AddIP] Stewart, R., et al., "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", Work in Progress.
[AddIP]Stewart，R.，等人，“流控制传输协议（SCTP）动态地址重新配置”，正在进行中。
Thanks to Steve Bellovin of AT&T Research, Michael Tuexen of Siemens, Peter Ford of Microsoft, Ran Atkinson of Extreme Networks, and Daniel Senie for useful discussions of this problem space.
感谢AT&T Research的Steve Bellovin、西门子的Michael Tuexen、微软的Peter Ford、Extreme Networks的Atkinson和Daniel Senie对这个问题空间进行了有益的讨论。
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
伯纳德·阿博巴（Bernard Aboba）微软公司华盛顿州雷德蒙微软大道一号，邮编：98052
Phone: +1 425 706 6605
Fax: +1 425 936 7329
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329
EMail: bernarda@microsoft.com
William Dixon V6 Security, Inc. 601 Union Square, Suite #4200-300 Seattle, WA 98101
William Dixon V6安全公司，地址：华盛顿州西雅图联合广场601号4200-300室，邮编：98101
EMail: ietf-wd@v6security.com
EMail: ietf-wd@v6security.com
Copyright (C) The Internet Society (2004). 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.
版权所有（C）互联网协会（2004年）。本文件受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 currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。