RFC3715：IPsec-Network Address Translation （NAT） Compatibility Requirements，March 2004
本备忘录的状态
本备忘录为 Internet 社区提供信息。它没有指定任何类型的 Internet 标准。本备忘录的分发不受限制。
版权声明
版权所有 （C） 互联网协会 （2004）。版权所有。
梗概
本文档描述了网络地址转换 （Network Address Translation，NAT） 和 IPsec 之间已知的不兼容性，并描述了对它们进行寻址的要求。也许 IPsec 最常见的用途是提供虚拟专用网络功能。虚拟专用网络 （Virtual Private Networks，VPN） 的一种非常流行的用途是为远程办公人员提供对公司内部网的访问。如今，NAT 广泛部署在家庭网关以及可能被远程办公人员使用的其他位置，例如酒店。结果是 IPsec-NAT 不兼容已成为 IPsec 在其主要用途之一的部署中的主要障碍。
1、 简介
也许 IPsec [RFC2401] 最常见的用途是提供虚拟专用网络 （virtual private networking，VPN） 功能。VPN 的一种非常流行的用途是为远程办公人员提供对公司 Intranet 的访问。今天，[RFC3022-Traditional IP Network Address Translator (Traditional NAT)] 和 [RFC2663-IP Network Address Translator (NAT) Terminology and Considerations] 中描述的网络地址转换 （Network Address Translations，NAT） 广泛部署在家庭网关以及可能被远程办公人员使用的其他位置，例如酒店。结果是 IPsec-NAT 不兼容已成为 IPsec 在其主要用途之一的部署中的主要障碍。本文档描述了 NAT 和 IPsec 之间已知的不兼容性，并描述了解决它们的要求。
1.1、 需求语言
在本文档中，关键词“MAY”、“MUST”、“MUST NOT”、“optional”、“recommended”、“SHOULD”和“SHOULD NOT”将按照[RFC2119]中的描述进行解释。
请注意，本文档中指定的要求将用于评估协议提交。因此，需求语言指的是这些协议的能力；协议文件将指定这些功能是必需的、推荐的还是可选的。例如，要求协议支持机密性与要求对所有协议流量进行加密不同。
如果协议提交未能满足其实现的功能的一项或多项“必须”或“不得”要求，则该协议提交是不合规的。满足所有必须、不得、应该和不应该对其能力的要求的协议提交被称为“无条件兼容”；一个满足所有 MUST 和 MUST NOT 要求，但不是所有 SHOULD 或 SHOULD NOT 要求的协议被称为“有条件地兼容”。
2、 NA(P)T和IPsec之间已知的不兼容性
NA(P)T与IPsec的不兼容可分为三类：
1） 内在 NA(P)T 问题。
这些不兼容性直接源自 [RFC3022] 中描述的 NA(P)T 功能。因此，任何 NA(P)T 设备中都会存在这些不兼容性。
2） NA(P)T 实施弱点。
这些不兼容性不是 NA(P)T 固有的，而是存在于许多 NA(P)T 实现中。此类别中包括处理入站或出站片段方面的问题。由于这些问题不是 NA(P)T 固有的，原则上可以在未来的 NA(P)T 实现中解决。但是，由于实现问题似乎很广泛，因此需要在 NA(P)T 遍历解决方案中考虑它们。
3）助手问题。
这些不兼容性存在于试图提供 IPsec NA(P)T 穿越的 NA(P)T 设备中。具有讽刺意味的是，这种“助手”功能造成了进一步的不兼容性，使已经很困难的问题更难解决。虽然并非所有 NA(P)T 中都存在 IPsec 遍历“助手”功能，但这些功能正变得非常流行，因此在 NA(P)T 遍历解决方案中也需要考虑这些功能。
2.1、 内在 NA(P)T 问题
NA(P)T 固有的不兼容性包括：
a） IPsec AH [RFC2402] 和 NAT 之间的不兼容。
由于 AH 报头在密钥消息完整性检查中包含 IP 源地址和目的地址，因此 NAT 或反向 NAT 设备更改地址字段将使消息完整性检查无效。由于 IPsec ESP [RFC2406] 未在其密钥消息完整性检查中包含 IP 源地址和目的地址，因此 ESP 不会出现此问题。
b） 校验和与 NAT 之间的不兼容。
TCP 和 UDP 校验和通过在计算中包含“伪报头”而依赖于 IP 源地址和目的地址。因此，在接收时计算和检查校验和的情况下，它们将因通过 NAT 或反向 NAT 设备而无效。
因此，如果不涉及 TCP/UDP 协议（如在 IPsec 隧道模式或 IPsec 保护的 GRE 中）或不计算校验和（如 IPv4 UDP ）。如 [RFC793] 中所述，IPv4 中需要计算和验证TCP 校验和。IPv6 中需要计算和验证UDP/TCP 校验和。
[RFC2960]和[RFC3309]中定义的流控制传输协议（Stream Control Transmission Protocol，SCTP）使用CRC32C算法，仅在SCTP数据包（公共头+块）上计算，因此不覆盖IP头。因此，NAT 不会使 SCTP CRC 无效，并且不会出现问题。
请注意，由于传输模式 IPsec 流量受到完整性保护并使用强密码进行身份验证，因此可以在检查 UDP/TCP 校验和之前检测到对数据包的修改。因此，校验和验证仅提供针对内部处理中发生的错误的保证。
c） IKE 地址标识符和 NAT 之间的不兼容。
在 Internet 密钥交换协议 （Internet Key Exchange Protocol，IKE） 第 1 阶段 [RFC2409] 或第 2 阶段中将 IP 地址用作标识符的情况下，NAT 或反向 NAT 对 IP 源或目的地址的修改将导致标识符与地址中的地址不匹配。IP 报头。如 [RFC2409] 中所述，IKE 实现需要丢弃此类数据包。
为了避免使用 IP 地址作为 IKE 阶段 1 和阶段 2 标识符，可以使用用户 ID 和 FQDN。如果需要用户身份验证，可以使用 ID_USER_FQDN 类型的 ID，如 [RFC2407] 中所述。在需要机器身份验证的地方，可以使用 ID_FQDN 的 ID 类型。在任何一种情况下，如果在阶段 1 中交换了证书，则有必要验证提议的标识符是否作为处理最终实体证书的结果进行了身份验证。虽然在 IKE 中可以使用 USER_FQDN 或 FQDN 身份类型，但有一些用法不能以这种方式适应的场景，例如描述子网的安全策略数据库 （Security Policy Database，SPD）条目。
由于阶段2标识符中的源地址经常被用来构成一个完整的5元组入站SA选择器，所以在选择器中可以使用目的地址、协议、源端口和目的端口，以免削弱入站SA处理。
d） 固定 IKE 源端口和 NAPT 之间的不兼容。
在 NAPT 后面的多个主机向同一个响应者发起 IKE SA 的情况下，需要一种机制来允许 NAPT 对来自响应者的传入 IKE 数据包进行多路分解。这通常是通过转换来自发起方的出站数据包上的 IKE UDP 源端口来实现的。因此，响应者必须能够接受来自 UDP 源端口而非 500 的 IKE 流量，并且必须回复该端口。必须小心避免在重新设置密钥期间出现不可预测的行为。如果浮动源端口不用作重新加密的目标端口，NAT 可能无法将重新加密的数据包发送到正确的目的地。
e） 重叠的 SPD 条目和 NAT 之间的不兼容。
在 NAT 后的发起主机使用其在阶段 2 标识符中的源 IP 地址的情况下，它们可以与相同的响应者 IP 地址协商重叠的 SPD 条目。然后，响应者可以通过错误的 IPsec SA 发送数据包。发生这种情况是因为对于响应者来说，IPsec SA 似乎是等效的，因为它们存在于相同的端点之间并且可用于传递相同的流量。
f） IPsec SPI 选择和 NAT 之间的不兼容性。
由于 IPsec ESP 流量是加密的，因此对 NAT 是不透明的，因此 NAT 必须使用 IP 和 IPsec 报头的元素来对传入的 IPsec 流量进行多路分解。目标 IP 地址、安全协议 （AH/ESP） 和 IPsec SPI 的组合通常用于此目的。
然而，由于出站和入站 SPI 是独立选择的，NAT 无法仅通过检查出站流量来确定哪个入站 SPI 对应于哪个目标主机。因此，如果 NAT 后面的两台主机试图同时在同一目的地创建 IPsec SA，则 NAT 可能会将传入的 IPsec 数据包传送到错误的目的地。
请注意，这并不是与 IPsec 本身不兼容，而是与它通常的实现方式不兼容。对于 AH 和 ESP，接收主机指定用于给定 SA 的 SPI，该选择仅对接收器有意义。目前，Destination IP、SPI 和安全协议（AH、ESP）的组合唯一标识了一个安全联盟。此外，1-255 范围内的 SPI 值保留给 IANA，将来可能会使用。这意味着，在与同一个外部主机或网关协商时，同一个NAPT后面的内部主机可以选择相同的SPI值，这样一个主机入站SA是
（SPI=470, Internal Dest IP=192.168.0.4）
另一个不同的主机入站 SA 是
（SPI=470, Internal Dest IP=192.168.0.5）.
接收 NAPT 将无法确定应将具有 SPI=470 的入站 IPsec 数据包转发到哪个内部主机。
接收主机也可以为每个单播安全联盟分配一个唯一的 SPI。在这种情况下，只需要检查目标 IP 地址是否是“此主机的任何有效单播 IP”，而不需要检查它是否是发送主机使用的特定目标 IP 地址。使用这种技术，即使两个或多个主机与同一外部主机建立 SA，NA(P)T 也可以确保将数据包转发到错误的内部主机的可能性很小但非零。
这种方法完全向后兼容，只需要特定的接收主机更改其 SPI 分配和 IPsec_esp_input（） 代码。但是，NA(P)T 设备可能无法在没有解析 IKE 负载相关问题的情况下检测到此行为。并且主机可能仍需要使用 IANA 保留范围内的 SPI 用于指定目的。
g） 嵌入式 IP 地址和 NAT 之间的不兼容性。
由于负载受到完整性保护，因此包含在 IPsec 数据包中的任何 IP 地址都不会被 NAT 转换。这导致在 NAT 中实施的应用层网关（Application Layer Gateways，ALG） 无效。使用嵌入式 IP 地址的协议包括 FTP、IRC、SNMP、LDAP、H.323、SIP、SCTP（可选）和许多游戏。为了解决这个问题，有必要在主机或安全网关上安装 ALG，这些 ALG 可以在 IPsec 封装之前和 IPsec 解封装之后对应用程序流量进行操作。
h） NA(P)T 的隐含方向性。
NA(P)T通常需要一个初始的出站数据包流过它们以创建入站映射状态。方向性禁止向 NA(P)T 后面的主机主动建立 IPsec SA。
i） 入站 SA 选择器验证。
假设 IKE 协商阶段 2 选择器，入站 SA 处理将丢弃解封装的数据包，因为 [RFC2401] 要求数据包的源地址与 SA 选择器值匹配，ESP 数据包的 NA(P)T 处理会改变该值。
2.2、 NA(P)T 实施弱点
许多 NA(P)T 中存在的实施问题包括：
j） 无法处理非 UDP/TCP 流量。
当只有一台主机在 NAT 后面时，一些 NA(P)T 会丢弃非 UDP/TCP 流量或执行仅地址转换。此类 NAPT 无法启用 SCTP、ESP（协议 50）或 AH（协议 51）流量。
k） NAT 映射超时。
NA(P)T 在没有流量的情况下保持 UDP 映射的时间会有所不同。因此，即使 IKE 数据包可以被正确转换，转换状态也可能过早地被删除。
l） 无法处理传出的片段。
大多数 NA(P)T 可以在 IP 数据包大小超过传出接口上的 MTU 的情况下正确地对传出 IP 数据包进行分段。然而，对已经分段的传出数据包进行正确的转换是很困难的，而且大多数 NAPT 不能正确处理这一点。如 [RFC3022] 的第 6.3 节所述，在两台主机向同一目的地发送分段数据包的情况下，分段标识符可以重叠。由于目标主机依赖碎片标识符和碎片偏移量进行重组，结果将是数据损坏。很少有 NA(P)T 通过支持标识符转换来防止标识符冲突。当 NAT 执行分段时，标识符冲突不是问题，因为分段标识符只需要在源/目标 IP 地址对中是唯一的。
由于片段可以小到 68 个八位字节 [RFC791]，因此不能保证第一个片段将包含完整的 TCP 报头。因此，希望重新计算 TCP 校验和的 NA(P)T 可能需要修改后续片段。由于片段可以重新排序，并且 IP 地址可以嵌入甚至可能在片段之间拆分，因此 NA(P)T 将需要在完成转换之前执行重组。很少有 NA(P)T 支持这一点。
m） 无法处理传入的片段。
由于通常只有第一个片段将包含完整的 IP/UDP/SCTP/TCP 报头，因此 NAPT 需要能够仅根据源/目标 IP 地址和片段标识符来执行转换。由于片段可以重新排序，如果后续片段在初始片段之前到达，则可能不知道给定片段标识符的报头，并且报头可以在片段之间拆分。因此，NAPT 可能需要在完成翻译之前执行重新组装。很少有 NAPT 支持这一点。请注意，对于 NAT，源/目标 IP 地址足以确定转换，因此不会出现这种情况。但是，IPsec 或 IKE 报头可能会在片段之间拆分，因此可能仍需要重新组装。
2.3、 助手不兼容
IPsec 和 NAT“助手”功能之间的不兼容性包括：
n） 互联网安全协商和密钥管理协议 （Internet Security Association and Key Management Protocol，ISAKMP） 报头检查。
今天，一些 NAT 实现尝试使用 IKE cookie 来解复用传入的 IKE 流量。与源端口解复用一样，IKE cookie 解复用会导致重新生成密钥问题，因为阶段 1 重新生成密钥通常不会使用与早期流量相同的 cookie。
o） 端口 500 的特殊处理。
由于某些 IKE 实现无法处理非 500 UDP 源端口，因此某些 NAT 不会转换 UDP 源端口为 500 的数据包。这意味着这些 NAT 仅限于每个目的地一个 IPsec 客户端网关，除非他们检查 ISAKMP 报头的详细信息以检查产生上述问题的 cookie。
p） ISAKMP 有效载荷检查。
尝试解析 ISAKMP 有效载荷的 NA(P)T 实现可能无法处理所有有效载荷排序组合，或者不支持用于 IKE 选项协商的 vendor_id 有效载荷。
3、 IPsec-NAT 兼容性要求
IPsec-NAT 兼容解决方案的目标是将可用 IPsec 功能的范围扩展到 2.3 节中描述的 NAT 兼容 IPsec 隧道模式解决方案中可用的范围之外。
在评估 IPsec-NAT 不兼容的解决方案时，应牢记以下标准：
部署/ Deployment
由于 IPv6 将解决经常导致在 IPv4 中使用 NA(P)Ts 的地址稀缺问题，因此 IPsec-NAT 兼容性问题是一个过渡问题，需要在 IPv6 广泛部署之前的时间范围内解决。因此，要发挥作用，IPsec-NAT 兼容性解决方案必须能够在比 IPv6 更短的时间范围内部署。
由于 IPv6 部署需要更改路由器和主机，因此需要更改路由器和主机的潜在 IPsec-NAT 兼容性解决方案将在与 IPv6 大致相同的时间尺度上部署。因此，IPsec-NAT 兼容性解决方案应该只需要更改主机，而不需要更改路由器。
除此之外，这意味着 IPsec-NAT 兼容性解决方案不应该要求主机和 NA(P)T 之间的通信，因为这将需要更改 NA(P)T，以及主机和主机之间的互操作性测试。NA(P)T 实现。为了在短期内实现部署，解决方案必须与部署的基础设施内的现有路由器和 NA(P)T 产品配合使用。
协议兼容性/ Protocol Compatibility
IPsec NAT 穿越解决方案预计不会解决在 IPsec 不安全时无法穿越 NA(P)T 的协议的问题。因此，即使有 IPsec NAT 穿越解决方案可用，某些协议仍可能需要 ALG。
安全/ Security
由于 NA(P)T 方向性提供安全功能，IPsec NA(P)T 遍历解决方案不应允许来自任何 IP 地址的任意传入 IPsec 或 IKE 流量被 NA(P)T 后面的主机接收，尽管映射状态一旦建立双向 IKE 和 IPsec 通信，就应该保持。
远程办公场景/ Telecommuter Scenario
由于 IPsec 的主要用途之一是远程访问公司内部网，因此 NA(P)T 穿越解决方案必须支持 NA(P)T 穿越，通过 IPsec 隧道模式或 L2TP over IPsec 传输模式 [RFC3193]。这包括支持在远程客户端和 VPN 网关之间穿越一个以上的 NA(P)T。
客户端可以具有可路由地址并且VPN网关可以在至少一个NA(P)T之后，或者替代地，客户端和VPN网关都可以在一个或多个NA(P)T之后。远程办公人员可能使用相同的私有 IP 地址，每个 IP 地址都在自己的 NA(P)T 后面，或者许多远程办公人员可能驻留在同一个 NA(P)T 后面的私有网络上，每个人都有自己唯一的私有地址，连接到同一个 VPN网关。由于 IKE 使用 UDP 端口 500 作为目的地，因此没有必要启用在同一外部 IP 地址后面运行的多个 VPN 网关。
网关到网关场景/ Gateway-to-Gateway Scenario
在网关-网关场景中，可以在公司网络和 Internet 之间插入专用寻址网络 （DMZ）。在此设计中，连接公司网络部分的 IPsec 安全网关可能驻留在 DMZ 中，并在其外部 （DMZ） 接口上具有专用地址。NA(P)T 将 DMZ 网络连接到 Internet。
端到端场景/ End-to-End Scenario
NAT-IPsec 解决方案必须通过 IPsec 启用安全的主机-主机 TCP/IP 通信，以及主机-网关通信。专用网络上的主机必须能够建立一个或多个 IPsec 保护的 TCP 连接或 UDP 会话到另一台主机，它们之间有一个或多个 NA(P)T。例如，NA(P)T 可以部署在连接到公司网络的分支机构内，另外还有一个 NA(P)T 将公司网络连接到 Internet。同样，NA(P)T 可以部署在公司网络 LAN 或 WAN 内，以将无线或远程位置客户端连接到公司网络。这可能需要对主机上的 TCP 和 UDP 流量进行特殊处理。
将 SCTP 连接建立到另一台主机之间，它们之间有一个或多个 NA(P)T 可能会带来特殊的挑战。SCTP 支持多归属。如果使用了多个 IP 地址，这些地址将在关联建立期间作为 SCTP 数据包的一部分进行传输（在 INIT 和 INIT-ACK 块中）。如果仅使用单宿主 SCTP 端点，[RFC2960] 部分 3.3.2.1 说明：
请注意，在 INIT 和 INIT-ACK 中不使用任何 IP 地址参数是使关联更有可能跨 NAT 设备工作的替代方法。
这意味着除非必要，否则不应将 IP 地址放入 SCTP 数据包中。如果存在 NAT 并且包含 IP 地址，则关联设置将失败。最近提出了 [AddIP]，它允许在建立关联后修改 IP 地址。修改消息在 SCTP 数据包中也有 IP 地址，因此会受到 NAT 的不利影响。
防火墙兼容性/ Firewall Compatibility
由于防火墙被广泛部署，NAT-IPsec 兼容性解决方案必须使防火墙管理员能够创建简单的静态访问规则来允许或拒绝 IKE 和 IPsec NA(P)T 穿越流量。例如，这意味着要避免动态分配 IKE 或 IPsec 目标端口。
规模化/ Scaling
IPsec-NAT 兼容性解决方案应该能够部署在由数千名远程办公人员组成的安装中。在这种情况下，不可能假设一次只有一台主机与给定的目的地进行通信。因此，IPsec-NAT 兼容性解决方案必须解决重叠 SPD 条目和传入数据包解复用的问题。
模式支持/ Mode Support
至少，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
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
IPsec-NAT 兼容性解决方案不得引入额外的 IKE 或 IPsec 安全漏洞。例如，一个可接受的解决方案必须证明它没有引入新的拒绝服务或欺骗漏洞。必须允许 IKE 以双向方式重新生成密钥，如 [RFC2408] 中所述。
4、 现有解决方案
4.1、 IPsec隧道模式
在有限的一组环境中，IPsec 隧道模式的实现，例如 [DHCP] 中描述的，有可能成功地穿越 NA(P)T。但是，成功遍历的要求非常有限，因此需要更通用的解决方案：
1） IPsec ESP。
IPsec ESP 隧道不覆盖消息完整性检查中的外部 IP 报头，因此不会因地址转换而导致身份验证数据失效。IPsec 隧道也不需要关心校验和失效。
2） 没有地址验证。
大多数当前的 IPsec 隧道模式实现不执行源地址验证，因此不会检测到 IKE 标识符和源地址之间的不兼容性。这引入了第 5 节中描述的安全漏洞。
3） “Any to Any”SPD 条目。
IPsec 隧道模式客户端可以协商“Any to Any”SPD，地址转换不会使这些 SPD 失效。这有效地排除了使用 SPD 来过滤允许的隧道流量。
4） 单客户端操作。
由于 NAT 后面只有一个客户端，因此不存在重叠 SPD 的风险。由于 NAT 不需要在竞争客户端之间进行仲裁，因此也不存在重新密钥错误转换或不正确的传入 SPI 或 cookie 解复用的风险。
5） 不分段。
使用证书身份验证时，可能会遇到 IKE 分段。这可能发生在使用证书链时，或者如果密钥大小或其他证书字段（例如专有名称和其他扩展名）的大小足够大，则甚至在交换单个证书时也会发生这种情况。但是，当使用预共享密钥进行身份验证时，分段的可能性较小。
6） 活动会话。
大多数 VPN 会话通常在其生命周期内保持持续的流量流，因此不太可能由于不活动而删除 UDP 端口映射。
4.2、 RSIP
[RSIP-Realm Specific IP: Protocol Specification] 和 [RSIPFrame] 中描述的 RSIP，包括 IPsec 穿越机制，如 [RSIPsec] 中所述。通过启用主机-NA(P)T 通信，RSIP 解决了 IPsec SPI 解复用问题以及 SPD 重叠问题。因此适用于企业以及家庭组网场景。通过使 NAT 后面的主机共享 NA(P)T（RSIP 网关）的外部 IP 地址，这种方法与包括嵌入式 IP 地址在内的协议兼容。
通过隧道传输 IKE 和 IPsec 数据包，RSIP 避免了对 IKE 和 IPsec 协议的更改，尽管需要对托管 IKE 和 IPsec 实现进行重大更改，以使其与 RSIP 兼容。因此，它与所有现有协议 （AH/ESP） 和模式（传输和隧道）兼容。
为了处理 IKE 重新密钥的解复用，RSIP 需要浮动 IKE 源端口，以及重新生成浮动端口的密钥。因此，无法保证与现有 IPsec 实现的互操作性。
RSIP 不满足 IPsec-NAT 兼容解决方案的部署要求，因为启用 RSIP 的主机需要相应的启用 RSIP 的网关才能与另一台主机建立 IPsec SA。由于 RSIP 只需要对客户端和路由器进行更改，而不需要对服务器进行更改，因此它的部署难度不如 IPv6。但是，对于供应商而言，RSIP 的实施需要 IPv6 支持所需资源的很大一部分。因此，RSIP 在长期时间尺度上解决了“过渡”问题，这是没有用的。
4.3、 6to4
[RFC3056] 中描述的 6to4 可以构成 IPsec-NAT 穿越解决方案的基础。在这种方法中，NAT 为 IPv6 主机提供从 NAT 外部 IPv4 地址派生的 IPv6 前缀，并将 IPv6 数据包封装在 IPv4 中以传输到其他 6to4 主机或 6to4 中继。这使使用 IPsec 的 IPv6 主机能够与 IPv6 或 6to4 云中的其他主机自由通信。
虽然 6to4 是一种优雅而强大的解决方案，其中单个 NA(P)T 将客户端和 VPN 网关分开，但它并不普遍适用。由于 6to4 需要将可路由的 IPv4 地址分配给 NA(P)T 以允许形成 IPv6 前缀，因此在客户端和 VPN 网关之间存在多个 NA(P)T 的情况下，它不可用。例如，在其外部接口上具有私有地址的 NA(P)T 不能被其后面的客户端用于通过 6to4 获取 IPv6 前缀。
虽然 6to4 几乎不需要来自已经支持 IPv6 的主机的额外支持，但它确实需要更改 NAT，需要升级以支持 6to4。因此，6to4 短期内可能不适合部署。
5、 安全考虑
根据定义，IPsec-NAT 兼容性要求实现 IPsec 的主机和路由器能够安全地处理 IP 报头未加密保护的数据包。由此产生了许多值得讨论的问题。
由于 IPsec AH 无法通过 NAT，因此提供 IPsec-NAT 兼容性解决方案的副作用之一可能是使用空加密的 IPsec ESP 代替 AH，其中源和目标之间存在 NAT。但是，应该注意的是，具有空加密的 ESP 不提供与 AH 相同的安全属性。例如，存在与 AH 排除的 IPv6 源路由相关的安全风险，但不通过空加密的 ESP。
此外，由于带有任何转换的 ESP 不能防止源地址欺骗，因此需要执行某种源 IP 地址健全性检查。反欺骗检查的重要性并未被广泛理解。作为 IPsec_{esp,ah}_input（） 的一部分，通常会对源 IP 地址进行反欺骗检查。这可确保数据包源自与原始 IKE 阶段 1 和阶段 2 安全联盟中声明的地址相同的地址。当接收主机位于 NAT 后面时，此检查对于单播会话可能没有严格意义，而在全球 Internet 中，此检查对于隧道模式单播会话很重要，以防止 [AuthSource] 中描述的欺骗攻击，这可能发生在接收方的访问控制取决于解封装后验证的 ESP 数据包的源 IP 地址。如果 IPsec-NAT 兼容方案使用源地址进行访问控制，则它应该提供反欺骗保护。
让我们考虑两个主机 A 和 C，它们都在（不同的）NAT 之后，它们协商到路由器 B 的 IPsec 隧道模式 SA。主机 A 和 C 可能具有不同的特权；例如，主机 A 可能属于受信任访问大部分公司 Intranet 的员工，而 C 可能是仅被授权访问特定网站的承包商。
如果主机 C 发送一个隧道模式的数据包欺骗 A 的 IP 地址作为源，重要的是这个数据包没有被赋予与 A 对应的权限。如果执行了身份验证和完整性检查，但没有反欺骗检查（验证原始IP 地址对应于 SPI），然后主机 C 可能会被允许访问网络中不受限制的部分。因此，IPsec-NAT 兼容方案必须提供一定程度的反欺骗保护。
6、 参考文献
6.1、 规范参考
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2401] Atkinson, R. and S. Kent, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [RFC2406] Kent,S. and R. Atkinson, "IP Encapsulating Security Payload （ESP）", RFC 2406, November 1998. [RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange （IKE）", RFC 2409, November 1998. [RFC2663] Srisuresh, P. and M. Holdredge, "IP Network Address Translator （NAT） Terminology and Considerations", RFC 2663, August 1999. [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator （Traditional NAT）", RFC 3022, January 2001.
6.2、 参考资料
[RFC2408] Maughan, D., Schertler, M., Schneider, M. and J. Turner, "Internet Security Association and Key Management Protocol （ISAKMP）", RFC 2408, November 1998. [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. [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G. and S. Booth, "Securing L2TP using IPsec", RFC 3193, November 2001. [RFC3309] Stone, J., Stewart, R. and D. Otis, "Stream Control Transmission Protocol （SCTP） Checksum Change", RFC 3309, September 2002. [RSIPFrame] Borella, M., Lo, J., Grabelsky, D. and G. Montenegro, "Realm Specific IP: Framework", RFC 3102, October 2001. [RSIP] Borella, M., Grabelsky, D., Lo, J. and K. Taniguchi, "Realm Specific IP: Protocol Specification", RFC 3103, October 2001. [RSIPsec] Montenegro, G. and M. Borella, "RSIP Support for End- to-End IPsec", RFC 3104, October 2001. [DHCP] Patel, B., Aboba, B., Kelly, S. and V. Gupta, "Dynamic Host Configuration Protocol （DHCPv4） Configuration of IPsec Tunnel Mode", RFC 3456, January 2003. [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. [AddIP] Stewart, R., et al., "Stream Control Transmission Protocol （SCTP） Dynamic Address Reconfiguration", Work in Progress.
7、 致谢
感谢 AT&T Research 的 Steve Bellovin、西门子的 Michael Tuexen、微软的 Peter Ford、Extreme Networks 的 Ran Atkinson 和 Daniel Senie 对这个问题空间的有益讨论。
8、 完整的版权声明
版权所有 （C） 互联网协会 （2004）。本文档受 BCP 78 中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
本文档和其中包含的信息按“原样”提供，贡献者、他/她所代表或赞助的组织（如果有）、互联网社会和互联网工程特别工作组不作任何明示或保证暗示，包括但不限于任何保证，即使用此处的信息不会侵犯任何权利或任何暗示的适销性或适用于特定目的的保证。
知识产权
对于可能声称与本文档中描述的技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或者此类权利下的任何许可可能会或可能不会的程度，IETF 不采取任何立场能得到的;也不代表它已作出任何独立努力来确定任何此类权利。可以在 BCP 78 和 BCP 79 中找到有关 RFC 文档中权利的程序的信息。
可以获取向 IETF 秘书处披露的 IPR 副本和任何可用许可的保证，或者可以获得本规范的实施者或用户使用此类专有权利的一般许可或许可的尝试结果来自 IETF 在线 IPR 存储库，网址为 http://www.ietf.org/ipr。
IETF 邀请任何相关方提请其注意可能涵盖实施本标准可能需要的技术的任何版权、专利或专利申请或其他专有权利。请将信息发送至 IETF ietf-ipr@ietf.org。
致谢
RFC 编辑器功能的资金目前由互联网协会提供。
