Network Working Group R. Graveman
Request for Comments: 4891 RFG Security, LLC
Category: Informational M. Parthasarathy
Nokia
P. Savola
CSC/FUNET
H. Tschofenig
Nokia Siemens Networks
May 2007
Network Working Group R. Graveman
Request for Comments: 4891 RFG Security, LLC
Category: Informational M. Parthasarathy
Nokia
P. Savola
CSC/FUNET
H. Tschofenig
Nokia Siemens Networks
May 2007
Using IPsec to Secure IPv6-in-IPv4 Tunnels
使用IPsec保护IPv4隧道中的IPv6
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 IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document gives guidance on securing manually configured IPv6-in-IPv4 tunnels using IPsec in transport mode. No additional protocol extensions are described beyond those available with the IPsec framework.
本文档提供了在传输模式下使用IPsec保护手动配置的IPv6-in-IPv4隧道的指南。除了IPsec框架中可用的协议扩展之外，没有其他协议扩展。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Threats and the Use of IPsec . . . . . . . . . . . . . . . . . 3
2.1. IPsec in Transport Mode . . . . . . . . . . . . . . . . . 4
2.2. IPsec in Tunnel Mode . . . . . . . . . . . . . . . . . . . 5
3. Scenarios and Overview . . . . . . . . . . . . . . . . . . . . 5
3.1. Router-to-Router Tunnels . . . . . . . . . . . . . . . . . 6
3.2. Site-to-Router/Router-to-Site Tunnels . . . . . . . . . . 6
3.3. Host-to-Host Tunnels . . . . . . . . . . . . . . . . . . . 8
4. IKE and IPsec Versions . . . . . . . . . . . . . . . . . . . . 9
5. IPsec Configuration Details . . . . . . . . . . . . . . . . . 10
5.1. IPsec Transport Mode . . . . . . . . . . . . . . . . . . . 11
5.2. Peer Authorization Database and Identities . . . . . . . . 12
6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Using Tunnel Mode . . . . . . . . . . . . . . . . . . 17
A.1. Tunnel Mode Implementation Methods . . . . . . . . . . . . 17
A.2. Specific SPD for Host-to-Host Scenario . . . . . . . . . . 18
A.3. Specific SPD for Host-to-Router Scenario . . . . . . . . . 19
Appendix B. Optional Features . . . . . . . . . . . . . . . . . . 20
B.1. Dynamic Address Configuration . . . . . . . . . . . . . . 20
B.2. NAT Traversal and Mobility . . . . . . . . . . . . . . . . 20
B.3. Tunnel Endpoint Discovery . . . . . . . . . . . . . . . . 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Threats and the Use of IPsec . . . . . . . . . . . . . . . . . 3
2.1. IPsec in Transport Mode . . . . . . . . . . . . . . . . . 4
2.2. IPsec in Tunnel Mode . . . . . . . . . . . . . . . . . . . 5
3. Scenarios and Overview . . . . . . . . . . . . . . . . . . . . 5
3.1. Router-to-Router Tunnels . . . . . . . . . . . . . . . . . 6
3.2. Site-to-Router/Router-to-Site Tunnels . . . . . . . . . . 6
3.3. Host-to-Host Tunnels . . . . . . . . . . . . . . . . . . . 8
4. IKE and IPsec Versions . . . . . . . . . . . . . . . . . . . . 9
5. IPsec Configuration Details . . . . . . . . . . . . . . . . . 10
5.1. IPsec Transport Mode . . . . . . . . . . . . . . . . . . . 11
5.2. Peer Authorization Database and Identities . . . . . . . . 12
6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Using Tunnel Mode . . . . . . . . . . . . . . . . . . 17
A.1. Tunnel Mode Implementation Methods . . . . . . . . . . . . 17
A.2. Specific SPD for Host-to-Host Scenario . . . . . . . . . . 18
A.3. Specific SPD for Host-to-Router Scenario . . . . . . . . . 19
Appendix B. Optional Features . . . . . . . . . . . . . . . . . . 20
B.1. Dynamic Address Configuration . . . . . . . . . . . . . . 20
B.2. NAT Traversal and Mobility . . . . . . . . . . . . . . . . 20
B.3. Tunnel Endpoint Discovery . . . . . . . . . . . . . . . . 21
The IPv6 Operations (v6ops) working group has selected (manually configured) IPv6-in-IPv4 tunneling [RFC4213] as one of the IPv6 transition mechanisms for IPv6 deployment.
IPv6操作（v6ops）工作组已选择（手动配置）IPv4中的IPv6隧道[RFC4213]作为IPv6部署的IPv6转换机制之一。
[RFC4213] identified a number of threats that had not been adequately analyzed or addressed in its predecessor [RFC2893]. The most complete solution is to use IPsec to protect IPv6-in-IPv4 tunneling. The document was intentionally not expanded to include the details on how to set up an IPsec-protected tunnel in an interoperable manner, but instead the details were deferred to this memo.
[RFC4213]确定了许多在其前身[RFC2893]中未得到充分分析或解决的威胁。最完整的解决方案是使用IPsec保护IPv4隧道中的IPv6。该文档有意不进行扩展，以包括有关如何以互操作方式设置受IPsec保护的隧道的详细信息，而是将详细信息推迟到本备忘录中。
The first four sections of this document analyze the threats and scenarios that can be addressed by IPsec and assumptions made by this document for successful IPsec Security Association (SA) establishment. Section 5 gives the details of Internet Key Exchange (IKE) and IP security (IPsec) exchange with packet formats and Security Policy Database (SPD) entries. Section 6 gives recommendations. Appendices further discuss tunnel mode usage and optional extensions.
本文档的前四部分分析了IPsec可以解决的威胁和场景，以及本文档为成功建立IPsec安全关联（SA）所做的假设。第5节详细介绍了具有数据包格式和安全策略数据库（SPD）条目的Internet密钥交换（IKE）和IP安全（IPsec）交换。第6节提出了建议。附录进一步讨论了隧道模式的使用和可选扩展。
This document does not address the use of IPsec for tunnels that are not manually configured (e.g., 6to4 tunnels [RFC3056]). Presumably, some form of opportunistic encryption or "better-than-nothing security" might or might not be applicable. Similarly, propagating quality-of-service attributes (apart from Explicit Congestion Notification bits [RFC4213]) from the encapsulated packets to the tunnel path is out of scope.
本文档不涉及IPsec在非手动配置的隧道（例如6to4隧道[RFC3056]）中的使用。据推测，某种形式的机会主义加密或“比没有更好的安全性”可能适用，也可能不适用。类似地，将服务质量属性（除了显式拥塞通知位[RFC4213]）从封装的分组传播到隧道路径超出范围。
The use of the word "interface" or the phrase "IP interface" refers to the IPv6 interface that must be present on any IPv6 node to send or receive IPv6 packets. The use of the phrase "tunnel interface" refers to the interface that receives the IPv6-in-IPv4 tunneled packets over IPv4.
“接口”一词或短语“IP接口”的使用是指任何IPv6节点上必须存在的IPv6接口，以发送或接收IPv6数据包。短语“隧道接口”的使用是指通过IPv4接收IPv6-in-IPv4隧道数据包的接口。
[RFC4213] is mostly concerned about address spoofing threats:
[RFC4213]主要关注地址欺骗威胁：
1. The IPv4 source address of the encapsulating ("outer") packet can be spoofed.
1. 可以伪造封装（“外部”）数据包的IPv4源地址。
2. The IPv6 source address of the encapsulated ("inner") packet can be spoofed.
2. 可以伪造封装（“内部”）数据包的IPv6源地址。
The reason threat (1) exists is the lack of universal deployment of IPv4 ingress filtering [RFC3704]. The reason threat (2) exists is that the IPv6 packet is encapsulated in IPv4 and hence may escape IPv6 ingress filtering. [RFC4213] specifies the following strict address checks as mitigating measures:
威胁（1）存在的原因是缺少IPv4入口过滤的通用部署[RFC3704]。存在威胁（2）的原因是IPv6数据包封装在IPv4中，因此可能会逃避IPv6入口过滤。[RFC4213]指定以下严格的地址检查作为缓解措施：
o To mitigate threat (1), the decapsulator verifies that the IPv4 source address of the packet is the same as the address of the configured tunnel endpoint. The decapsulator may also implement IPv4 ingress filtering, i.e., check whether the packet is received on a legitimate interface.
o 为了缓解威胁（1），解封装器验证数据包的IPv4源地址是否与配置的隧道端点的地址相同。解封装器还可以实现IPv4入口过滤，即，检查分组是否在合法接口上接收。
o To mitigate threat (2), the decapsulator verifies whether the inner IPv6 address is a valid IPv6 address and also applies IPv6 ingress filtering before accepting the IPv6 packet.
o 为了缓解威胁（2），解封装器验证内部IPv6地址是否为有效的IPv6地址，并在接受IPv6数据包之前应用IPv6入口过滤。
This memo proposes using IPsec for providing stronger security in preventing these threats and additionally providing integrity, confidentiality, replay protection, and origin protection between tunnel endpoints.
本备忘录建议使用IPsec提供更强的安全性，以防止这些威胁，并在隧道端点之间提供完整性、机密性、重播保护和源保护。
IPsec can be used in two ways, in transport and tunnel mode; detailed discussion about applicability in this context is provided in Section 5.
IPsec可以以两种方式使用，即传输模式和隧道模式；第5节详细讨论了这种情况下的适用性。
In transport mode, the IPsec Encapsulating Security Payload (ESP) or Authentication Header (AH) security association (SA) is established to protect the traffic defined by (IPv4-source, IPv4-dest, protocol = 41). On receiving such an IPsec packet, the receiver first applies the IPsec transform (e.g., ESP) and then matches the packet against the Security Parameter Index (SPI) and the inbound selectors associated with the SA to verify that the packet is appropriate for the SA via which it was received. A successful verification implies that the packet came from the right IPv4 endpoint, because the SA is bound to the IPv4 source address.
在传输模式下，将建立IPsec封装安全有效负载（ESP）或身份验证头（AH）安全关联（SA），以保护（IPv4源、IPv4目标、协议=41）定义的流量。在接收到这样的IPsec分组时，接收机首先应用IPsec转换（例如，ESP），然后根据安全参数索引（SPI）和与SA相关联的入站选择器匹配该分组，以验证该分组是否适合通过其接收的SA。成功的验证意味着数据包来自正确的IPv4端点，因为SA绑定到IPv4源地址。
This prevents threat (1) but not threat (2). IPsec in transport mode does not verify the contents of the payload itself where the IPv6 addresses are carried. That is, two nodes using IPsec transport mode to secure the tunnel can spoof the inner payload. The packet will be decapsulated successfully and accepted.
这可以防止威胁（1），但不能防止威胁（2）。传输模式下的IPsec不会验证承载IPv6地址的有效负载本身的内容。也就是说，使用IPsec传输模式保护隧道的两个节点可以欺骗内部有效负载。数据包将成功解封并被接受。
This shortcoming can be partially mitigated by IPv6 ingress filtering, i.e., check that the packet is arriving from the interface in the direction of the route towards the tunnel endpoint, similar to a Strict Reverse Path Forwarding (RPF) check [RFC3704].
通过IPv6入口过滤可以部分缓解此缺点，即检查数据包是否从接口沿路由方向到达隧道端点，类似于严格的反向路径转发（RPF）检查[RFC3704]。
In most implementations, a transport mode SA is applied to a normal IPv6-in-IPv4 tunnel. Therefore, ingress filtering can be applied in the tunnel interface. (Transport mode is often also used in other kinds of tunnels such as Generic Routing Encapsulation (GRE) [RFC4023] and Layer 2 Tunneling Protocol (L2TP) [RFC3193].)
在大多数实现中，传输模式SA应用于IPv4隧道中的正常IPv6。因此，可以在隧道接口中应用入口过滤。（传输模式通常也用于其他类型的隧道，如通用路由封装（GRE）[RFC4023]和第2层隧道协议（L2TP）[RFC3193]。）
In tunnel mode, the IPsec SA is established to protect the traffic defined by (IPv6-source, IPv6-destination). On receiving such an IPsec packet, the receiver first applies the IPsec transform (e.g., ESP) and then matches the packet against the SPI and the inbound selectors associated with the SA to verify that the packet is appropriate for the SA via which it was received. The successful verification implies that the packet came from the right endpoint.
在隧道模式下，建立IPsec SA以保护（IPv6源、IPv6目标）定义的流量。在接收到这样的IPsec分组时，接收机首先应用IPsec转换（例如，ESP），然后将分组与SPI和与SA相关联的入站选择器相匹配，以验证该分组是否适合通过其接收的SA。成功的验证意味着数据包来自正确的端点。
The outer IPv4 addresses may be spoofed, and IPsec cannot detect this in tunnel mode; the packets will be demultiplexed based on the SPI and possibly the IPv6 address bound to the SA. Thus, the outer address spoofing is irrelevant as long as the decryption succeeds and the inner IPv6 packet can be verified to have come from the right tunnel endpoint.
外部IPv4地址可能被欺骗，IPsec无法在隧道模式下检测到这一点；数据包将根据SPI和绑定到SA的IPv6地址进行解复用。因此，只要解密成功并且可以验证内部IPv6数据包来自正确的隧道端点，外部地址欺骗就无关紧要。
As described in Section 5, using tunnel mode is more difficult than applying transport mode to a tunnel interface, and as a result this document recommends transport mode. Note that even though transport rather than tunnel mode is recommended, an IPv6-in-IPv4 tunnel specified by protocol 41 still exists [RFC4213].
如第5节所述，使用隧道模式比将传输模式应用于隧道接口更困难，因此，本文件建议使用传输模式。请注意，即使建议使用传输模式而不是隧道模式，协议41指定的IPv6-in-IPv4隧道仍然存在[RFC4213]。
There are roughly three scenarios:
大致有三种情况：
1. (Generic) router-to-router tunnels.
1. （通用）路由器到路由器隧道。
2. Site-to-router or router-to-site tunnels. These refer to tunnels between a site's IPv6 (border) device and an IPv6 upstream provider's router. A degenerate case of a site is a single host.
2. 站点到路由器或路由器到站点隧道。这些是指站点的IPv6（边界）设备和IPv6上游提供商的路由器之间的隧道。站点的退化情况是单个主机。
3. Host-to-host tunnels.
3. 主机对主机隧道。
IPv6/IPv4 hosts and routers can tunnel IPv6 datagrams over regions of IPv4 forwarding topology by encapsulating them within IPv4 packets. Tunneling can be used in a variety of ways.
IPv6/IPv4主机和路由器可以通过将IPv6数据报封装在IPv4数据包中，在IPv4转发拓扑的区域上对其进行隧道传输。隧道有多种用途。
.--------. _----_ .--------.
|v6-in-v4| _( IPv4 )_ |v6-in-v4|
| Router | <======( Internet )=====> | Router |
| A | (_ _) | B |
'--------' '----' '--------'
^ IPsec tunnel between ^
| Router A and Router B |
V V
.--------. _----_ .--------.
|v6-in-v4| _( IPv4 )_ |v6-in-v4|
| Router | <======( Internet )=====> | Router |
| A | (_ _) | B |
'--------' '----' '--------'
^ IPsec tunnel between ^
| Router A and Router B |
V V
Figure 1: Router-to-Router Scenario.
图1：路由器到路由器场景。
IPv6/IPv4 routers interconnected by an IPv4 infrastructure can tunnel IPv6 packets between themselves. In this case, the tunnel spans one segment of the end-to-end path that the IPv6 packet takes.
IPv4/IPv4路由器之间可以通过IPv4隧道相互连接。在这种情况下，隧道跨越IPv6数据包所采用的端到端路径的一段。
The source and destination addresses of the IPv6 packets traversing the tunnel could come from a wide range of IPv6 prefixes, so binding IPv6 addresses to be used to the SA is not generally feasible. IPv6 ingress filtering must be performed to mitigate the IPv6 address spoofing threat.
穿越隧道的IPv6数据包的源地址和目标地址可能来自广泛的IPv6前缀，因此将IPv6地址绑定到SA通常是不可行的。必须执行IPv6入口过滤以减轻IPv6地址欺骗威胁。
A specific case of router-to-router tunnels, when one router resides at an end site, is described in the next section.
下一节将介绍路由器到路由器隧道的一个具体情况，即一个路由器驻留在终端站点。
This is a generalization of host-to-router and router-to-host tunneling, because the issues when connecting a whole site (using a router) and connecting a single host are roughly equal.
这是主机到路由器和路由器到主机隧道的概括，因为连接整个站点（使用路由器）和连接单个主机时的问题大致相同。
_----_ .---------. IPsec _----_ IPsec .-------.
_( IPv6 )_ |v6-in-v4 | Tunnel _( IPv4 )_ Tunnel | V4/V6 |
( Internet )<--->| Router |<=======( Internet )=======>| Site B |
(_ _) | A | (_ _) '--------'
'----' '---------' '----'
^
|
V
.--------.
| Native |
| IPv6 |
| node |
'--------'
_----_ .---------. IPsec _----_ IPsec .-------.
_( IPv6 )_ |v6-in-v4 | Tunnel _( IPv4 )_ Tunnel | V4/V6 |
( Internet )<--->| Router |<=======( Internet )=======>| Site B |
(_ _) | A | (_ _) '--------'
'----' '---------' '----'
^
|
V
.--------.
| Native |
| IPv6 |
| node |
'--------'
Figure 2: Router-to-Site Scenario.
图2：路由器到站点场景。
IPv6/IPv4 routers can tunnel IPv6 packets to their final destination IPv6/IPv4 site. This tunnel spans only the last segment of the end-to-end path.
IPv6/IPv4路由器可以通过隧道将IPv6数据包传输到其最终目标IPv6/IPv4站点。此隧道仅跨越端到端路径的最后一段。
+---------------------+
| IPv6 Network |
| |
.--------. _----_ | .--------. |
| V6/V4 | _( IPv4 )_ | |v6-in-v4| |
| Site B |<====( Internet )==========>| Router | |
'--------' (_ _) | | A | |
'----' | '--------' |
IPsec tunnel between | ^ |
IPv6 Site and Router A | | |
| V |
| .-------. |
| | V6 | |
| | Hosts | |
| '--------' |
+---------------------+
+---------------------+
| IPv6 Network |
| |
.--------. _----_ | .--------. |
| V6/V4 | _( IPv4 )_ | |v6-in-v4| |
| Site B |<====( Internet )==========>| Router | |
'--------' (_ _) | | A | |
'----' | '--------' |
IPsec tunnel between | ^ |
IPv6 Site and Router A | | |
| V |
| .-------. |
| | V6 | |
| | Hosts | |
| '--------' |
+---------------------+
Figure 3: Site-to-Router Scenario.
图3：站点到路由器场景。
In the other direction, IPv6/IPv4 hosts can tunnel IPv6 packets to an intermediary IPv6/IPv4 router that is reachable via an IPv4 infrastructure. This type of tunnel spans the first segment of the packet's end-to-end path.
另一方面，IPv6/IPv4主机可以通过隧道将IPv6数据包传输到可通过IPv4基础结构访问的中间IPv6/IPv4路由器。这种类型的隧道跨越数据包端到端路径的第一段。
The hosts in the site originate the packets with IPv6 source addresses coming from a well-known prefix, whereas the destination addresses could be any nodes on the Internet.
站点中的主机使用来自已知前缀的IPv6源地址发起数据包，而目标地址可以是Internet上的任何节点。
In this case, an IPsec tunnel mode SA could be bound to the prefix that was allocated to the router at Site B, and Router A could verify that the source address of the packet matches the prefix. Site B will not be able to do a similar verification for the packets it receives. This may be quite reasonable for most of the deployment cases, for example, an Internet Service Provider (ISP) allocating a /48 to a customer. The Customer Premises Equipment (CPE) where the tunnel is terminated "trusts" (in a weak sense) the ISP's router, and the ISP's router can verify that Site B is the only one that can originate packets within the /48.
在这种情况下，IPsec隧道模式SA可以绑定到在站点B分配给路由器的前缀，路由器A可以验证数据包的源地址是否与前缀匹配。站点B将无法对其接收的数据包进行类似的验证。对于大多数部署情况，这可能是相当合理的，例如，Internet服务提供商（ISP）将a/48分配给客户。隧道终止的客户场所设备（CPE）“信任”（在弱意义上）ISP的路由器，并且ISP的路由器可以验证站点B是唯一可以在/48内发起数据包的站点。
IPv6 spoofing must be prevented, and setting up ingress filtering may require some amount of manual configuration; see more of these options in Section 5.
必须防止IPv6欺骗，设置入口过滤可能需要一些手动配置；更多这些选项见第5节。
.--------. _----_ .--------.
| V6/V4 | _( IPv4 )_ | V6/V4 |
| Host | <======( Internet )=====> | Host |
| A | (_ _) | B |
'--------' '----' '--------'
IPsec tunnel between
Host A and Host B
.--------. _----_ .--------.
| V6/V4 | _( IPv4 )_ | V6/V4 |
| Host | <======( Internet )=====> | Host |
| A | (_ _) | B |
'--------' '----' '--------'
IPsec tunnel between
Host A and Host B
Figure 4: Host-to-Host Scenario.
图4：主机到主机场景。
IPv6/IPv4 hosts interconnected by an IPv4 infrastructure can tunnel IPv6 packets between themselves. In this case, the tunnel spans the entire end-to-end path.
由IPv4基础结构互连的IPv6/IPv4主机可以在它们之间通过隧道传输IPv6数据包。在这种情况下，隧道跨越整个端到端路径。
In this case, the source and the destination IPv6 addresses are known a priori. A tunnel mode SA could be bound to these specific addresses. Address verification prevents IPv6 source address spoofing completely.
在这种情况下，源和目标IPv6地址是先验的。隧道模式SA可以绑定到这些特定地址。地址验证可完全防止IPv6源地址欺骗。
As noted in the Introduction, automatic host-to-host tunneling methods (e.g., 6to4) are out of scope for this memo.
如引言中所述，自动主机到主机隧道方法（如6to4）不在本备忘录的范围内。
This section discusses the different versions of the IKE and IPsec security architecture and their applicability to this document.
本节讨论IKE和IPsec安全体系结构的不同版本及其对本文档的适用性。
The IPsec security architecture was previously defined in [RFC2401] and is now superseded by [RFC4301]. IKE was originally defined in [RFC2409] (which is called IKEv1 in this document) and is now superseded by [RFC4306] (called IKEv2; see also [RFC4718]). There are several differences between them. The differences relevant to this document are discussed below.
IPsec安全体系结构以前在[RFC2401]中定义，现在被[RFC4301]取代。IKE最初在[RFC2409]（本文件中称为IKEv1）中定义，现在被[RFC4306]（称为IKEv2；另请参见[RFC4718]）取代。他们之间有几个不同之处。下文讨论了与本文件相关的差异。
1. [RFC2401] does not require allowing IP as the next layer protocol in traffic selectors when an IPsec SA is negotiated. In contrast, [RFC4301] requires supporting IP as the next layer protocol (like TCP or UDP) in traffic selectors.
1. [RFC2401]在协商IPsec SA时，不要求允许IP作为流量选择器中的下一层协议。相反，[RFC4301]需要支持IP作为流量选择器中的下一层协议（如TCP或UDP）。
2. [RFC4301] assumes IKEv2, as some of the new features cannot be negotiated using IKEv1. It is valid to negotiate multiple traffic selectors for a given IPsec SA in [RFC4301]. This is possible only with IKEv2. If IKEv1 is used, then multiple SAs need to be set up, one for each traffic selector.
2. [RFC4301]假设为IKEv2，因为某些新功能无法使用IKEv1协商。在[RFC4301]中为给定的IPsec SA协商多个流量选择器是有效的。只有使用IKEv2才能实现这一点。如果使用IKEv1，则需要设置多个SA，每个流量选择器一个。
Note that the existing implementations based on IKEv1 may already be able to support the [RFC4301] features described in (1) and (2). If appropriate, the deployment may choose to use either version of the security architecture.
注意，基于IKEv1的现有实现可能已经能够支持（1）和（2）中描述的[RFC4301]特性。如果合适，部署可以选择使用任一版本的安全体系结构。
IKEv2 supports features useful for configuring and securing tunnels not present with IKEv1.
IKEv2支持用于配置和保护IKEv1中不存在的隧道的功能。
1. IKEv2 supports legacy authentication methods by carrying them in Extensible Authentication Protocol (EAP) payloads. This can be used to authenticate hosts or sites to an ISP using EAP methods that support username and password.
1. IKEv2通过在可扩展身份验证协议（EAP）有效负载中携带传统身份验证方法来支持这些方法。这可用于使用支持用户名和密码的EAP方法向ISP验证主机或站点。
2. IKEv2 supports dynamic address configuration, which may be used to configure the IPv6 address of the host.
2. IKEv2支持动态地址配置，可用于配置主机的IPv6地址。
Network Address Translation (NAT) traversal works with both the old and revised IPsec architectures, but the negotiation is integrated with IKEv2.
网络地址转换（NAT）遍历适用于旧的和修订的IPsec体系结构，但协商与IKEv2集成。
For the purposes of this document, where the confidentiality of ESP [RFC4303] is not required, AH [RFC4302] can be used as an alternative to ESP. The main difference is that AH is able to provide integrity protection for certain fields in the outer IPv4 header and IPv4 options. However, as the outer IPv4 header will be discarded in any
在本文件中，如果不需要ESP[RFC4303]的保密性，AH[RFC4302]可以用作ESP的替代品。主要区别在于AH能够为外部IPv4报头和IPv4选项中的某些字段提供完整性保护。但是，由于在任何情况下都将丢弃外部IPv4标头
case, and those particular fields are not believed to be relevant in this particular application, there is no particular reason to use AH.
在这种情况下，这些特定的字段被认为与这个特定的应用程序无关，因此没有特别的理由使用AH。
This section describes the SPD entries for setting up the IPsec transport mode SA to protect the IPv6 traffic.
本节介绍用于设置IPsec传输模式SA以保护IPv6流量的SPD条目。
Several requirements arise when IPsec is used to protect the IPv6 traffic (inner header) for the scenarios listed in Section 3.
在第3节中列出的场景中，使用IPsec保护IPv6通信量（内部报头）时会产生一些要求。
1. All of IPv6 traffic should be protected, including link-local (e.g., Neighbor Discovery) and multicast traffic. Without this, an attacker can pollute the IPv6 neighbor cache causing disruption in communication between the two routers.
1. 应保护所有IPv6流量，包括本地链路（例如，邻居发现）和多播流量。否则，攻击者可能会污染IPv6邻居缓存，导致两个路由器之间的通信中断。
2. In router-to-router tunnels, the source and destination addresses of the traffic could come from a wide range of prefixes that are normally learned through routing. As routing can always learn a new prefix, one cannot assume that all the prefixes are known a priori [RFC3884]. This mainly affects scenario (1).
2. 在路由器到路由器隧道中，流量的源地址和目标地址可能来自通常通过路由学习的各种前缀。由于路由始终可以学习新的前缀，因此不能假定所有前缀都是先验的[RFC3884]。这主要影响场景（1）。
3. Source address selection depends on the notions of routes and interfaces. This implies that the reachability to the various IPv6 destinations appear as routes in the routing table. This affects scenarios (2) and (3).
3. 源地址的选择取决于路由和接口的概念。这意味着到各种IPv6目的地的可达性在路由表中显示为路由。这会影响场景（2）和（3）。
The IPv6 traffic can be protected using transport or tunnel mode. There are many problems when using tunnel mode as implementations may or may not model the IPsec tunnel mode SA as an interface as described in Appendix A.1.
可以使用传输或隧道模式保护IPv6流量。使用隧道模式时存在许多问题，因为实现可能会或可能不会将IPsec隧道模式SA建模为附录A.1中所述的接口。
If IPsec tunnel mode SA is not modeled as an interface (e.g., as of this writing, popular in many open source implementations), the SPD entries for protecting all traffic between the two endpoints must be described. Evaluating against the requirements above, all link-local traffic multicast traffic would need to be identified, possibly resulting in a long list of SPD entries. The second requirement is difficult to satisfy, because the traffic needing protection is not necessarily (e.g., router-to-router tunnel) known a priori [RFC3884]. The third requirement is also problematic, because almost all implementations assume addresses are assigned on interfaces (rather than configured in SPDs) for proper source address selection.
如果IPsec隧道模式SA未建模为接口（例如，在本文撰写时，在许多开放源代码实现中很流行），则必须描述用于保护两个端点之间所有通信量的SPD条目。根据上述要求进行评估，需要识别所有链路本地流量多播流量，这可能会导致一长串SPD条目。第二个要求很难满足，因为需要保护的流量不一定是先验已知的（例如，路由器到路由器隧道）[RFC3884]。第三个要求也是有问题的，因为几乎所有的实现都假定地址是在接口上分配的（而不是在SPD中配置的），以进行正确的源地址选择。
If the IPsec tunnel mode SA is modeled as interface, the traffic that needs protection can be modeled as routes pointing to the interface. But the second requirement is difficult to satisfy, because the traffic needing protection is not necessarily known a priori. The
如果将IPsec隧道模式SA建模为接口，则需要保护的流量可以建模为指向接口的路由。但是第二个要求很难满足，因为需要保护的流量不一定是先验的。这个
third requirement is easily solved, because IPsec is modeled as an interface.
第三个需求很容易解决，因为IPsec被建模为一个接口。
In practice, (2) has been solved by protecting all the traffic (::/0), but no interoperable implementations support this feature. For a detailed list of issues pertaining to this, see [VLINK].
实际上，（2）已通过保护所有通信量（：：/0）得到解决，但没有可互操作的实现支持此功能。有关此问题的详细列表，请参阅[VLINK]。
Because applying transport mode to protect a tunnel is a much simpler solution and also easily protects link-local and multicast traffic, we do not recommend using tunnel mode in this context. Tunnel mode is, however, discussed further in Appendix A.
由于应用传输模式来保护隧道是一个简单得多的解决方案，而且还可以轻松地保护链路本地和多播流量，因此我们不建议在此上下文中使用隧道模式。然而，附录A进一步讨论了隧道模式。
This document assumes that tunnels are manually configured on both sides and the ingress filtering is manually set up to discard spoofed packets.
本文档假设在两侧手动配置隧道，并且手动设置入口过滤以丢弃伪造的数据包。
Transport mode has typically been applied to L2TP, GRE, and other tunneling methods, especially when the user wants to tunnel non-IP traffic. [RFC3884], [RFC3193], and [RFC4023] provide examples of applying transport mode to protect tunnel traffic that spans only a part of an end-to-end path.
传输模式通常应用于L2TP、GRE和其他隧道方法，尤其是当用户希望隧道非IP流量时。[RFC3884]、[RFC3193]和[RFC4023]提供了应用传输模式保护仅跨越端到端路径一部分的隧道流量的示例。
IPv6 ingress filtering must be applied on the tunnel interface on all the packets that pass the inbound IPsec processing.
必须在通过入站IPsec处理的所有数据包的隧道接口上应用IPv6入口过滤。
The following SPD entries assume that there are two routers, Router1 and Router2, with tunnel endpoint IPv4 addresses denoted IPV4-TEP1 and IPV4-TEP2, respectively. (In other scenarios, the SPDs are set up similarly.)
以下SPD条目假设有两个路由器，路由器1和路由器2，隧道端点IPv4地址分别表示为IPv4-TEP1和IPv4-TEP2。（在其他情况下，SPD的设置类似。）
Router1's SPD:
Next Layer
Rule Local Remote Protocol Action
---- ----- ------ ---------- --------
1 IPV4-TEP1 IPV4-TEP2 ESP BYPASS
2 IPV4-TEP1 IPV4-TEP2 IKE BYPASS
3 IPv4-TEP1 IPV4-TEP2 41 PROTECT(ESP,transport)
Router1's SPD:
Next Layer
Rule Local Remote Protocol Action
---- ----- ------ ---------- --------
1 IPV4-TEP1 IPV4-TEP2 ESP BYPASS
2 IPV4-TEP1 IPV4-TEP2 IKE BYPASS
3 IPv4-TEP1 IPV4-TEP2 41 PROTECT(ESP,transport)
Router2's SPD:
Next Layer
Rule Local Remote Protocol Action
---- ----- ------ ---------- --------
1 IPV4-TEP2 IPV4-TEP1 ESP BYPASS
2 IPV4-TEP2 IPV4-TEP1 IKE BYPASS
3 IPv4-TEP2 IPV4-TEP1 41 PROTECT(ESP,transport)
Router2's SPD:
Next Layer
Rule Local Remote Protocol Action
---- ----- ------ ---------- --------
1 IPV4-TEP2 IPV4-TEP1 ESP BYPASS
2 IPV4-TEP2 IPV4-TEP1 IKE BYPASS
3 IPv4-TEP2 IPV4-TEP1 41 PROTECT(ESP,transport)
In both SPD entries, "IKE" refers to UDP destination port 500 and possibly also port 4500 if NAT traversal is used.
在两个SPD条目中，“IKE”表示UDP目标端口500，如果使用NAT遍历，还可能表示端口4500。
The packet format is as shown in Table 1.
数据包格式如表1所示。
+----------------------------+------------------------------------+
| Components (first to last) | Contains |
+----------------------------+------------------------------------+
| IPv4 header | (src = IPV4-TEP1, dst = IPV4-TEP2) |
| ESP header | |
| IPv6 header | (src = IPV6-EP1, dst = IPV6-EP2) |
| (payload) | |
+----------------------------+------------------------------------+
+----------------------------+------------------------------------+
| Components (first to last) | Contains |
+----------------------------+------------------------------------+
| IPv4 header | (src = IPV4-TEP1, dst = IPV4-TEP2) |
| ESP header | |
| IPv6 header | (src = IPV6-EP1, dst = IPV6-EP2) |
| (payload) | |
+----------------------------+------------------------------------+
Table 1: Packet Format for IPv6/IPv4 Tunnels.
表1:IPv6/IPv4隧道的数据包格式。
The IDci and IDcr payloads of IKEv1 carry the IPv4-TEP1, IPV4-TEP2, and protocol value 41 as phase 2 identities. With IKEv2, the traffic selectors are used to carry the same information.
IKEv1的IDci和IDcr有效负载携带IPv4-TEP1、IPv4-TEP2和协议值41作为阶段2标识。对于IKEv2，流量选择器用于承载相同的信息。
The Peer Authorization Database (PAD) provides the link between SPD and the key management daemon [RFC4306]. This is defined in [RFC4301] and hence relevant only when used with IKEv2.
对等授权数据库（PAD）提供SPD和密钥管理守护程序[RFC4306]之间的链接。这在[RFC4301]中定义，因此仅在与IKEv2一起使用时相关。
As there is currently no defined way to discover the PAD-related parameters dynamically, it is assumed that these are manually configured:
由于目前没有定义的方法动态发现PAD相关参数，因此假设这些参数是手动配置的：
o The Identity of the peer asserted in the IKEv2 exchange: Many different types of identities can be used. At least, the IPv4 address of the peer should be supported.
o IKEv2交换中断言的对等方身份：可以使用许多不同类型的身份。至少应该支持对等方的IPv4地址。
o IKEv2 can authenticate the peer by several methods. Pre-shared key and X.509 certificate-based authentication is required by [RFC4301]. At least, pre-shared key should be supported, because it interoperates with a larger number of implementations.
o IKEv2可以通过几种方法对对等方进行身份验证。[RFC4301]要求预共享密钥和基于X.509证书的身份验证。至少，应该支持预共享密钥，因为它可以与大量实现进行互操作。
o The child SA authorization data should contain the IPv4 address of the peer.
o 子SA授权数据应包含对等方的IPv4地址。
IPv4 address should be supported as Identity during the key exchange. As this does not provide Identity protection, main mode or aggressive mode can be used with IKEv1.
在密钥交换期间，应支持IPv4地址作为标识。由于这不提供身份保护，主模式或攻击模式可与IKEv1一起使用。
In Section 5, we examined the differences between setting up an IPsec IPv6-in-IPv4 tunnel using either transport or tunnel mode. We observe that applying transport mode to a tunnel interface is the simplest and therefore recommended solution.
在第5节中，我们研究了使用传输或隧道模式设置IPsec IPv6-In-IPv4隧道之间的差异。我们观察到，将传输模式应用于隧道接口是最简单的，因此是推荐的解决方案。
In Appendix A, we also explore what it would take to use so-called Specific SPD (SSPD) tunnel mode. Such usage is more complicated because IPv6 prefixes need to be known a priori, and multicast and link-local traffic do not work over such a tunnel. Fragment handling in tunnel mode is also more difficult. However, because the Mobility and Multihoming Protocol (MOBIKE) [RFC4555] supports only tunnel mode, when the IPv4 endpoints of a tunnel are dynamic and the other constraints are not applicable, using tunnel mode may be an acceptable solution.
在附录A中，我们还探讨了使用所谓的特定SPD（SSPD）隧道模式需要什么。这种用法更为复杂，因为IPv6前缀需要事先知道，并且多播和链路本地流量不能通过这样的隧道工作。隧道模式下的碎片处理也更加困难。然而，由于移动和多归属协议（MOBIKE）[RFC4555]仅支持隧道模式，当隧道的IPv4端点是动态的且其他约束不适用时，使用隧道模式可能是可接受的解决方案。
Therefore, our primary recommendation is to use transport mode applied to a tunnel interface. Source address spoofing can be limited by enabling ingress filtering on the tunnel interface.
因此，我们的主要建议是使用适用于隧道接口的传输模式。通过在隧道接口上启用入口过滤，可以限制源地址欺骗。
Manual keying must not be used as large amounts of IPv6 traffic may be carried over the tunnels and doing so would make it easier for an attacker to recover the keys. IKEv1 or IKEv2 must be used for establishing the IPsec SAs. IKEv2 should be used where supported and available; if not, IKEv1 may be used instead.
不得使用手动密钥，因为大量IPv6流量可能会通过隧道传输，这样做会使攻击者更容易恢复密钥。IKEv1或IKEv2必须用于建立IPsec SAs。在支持和可用的情况下，应使用IKEv2；如果不是，则可以使用IKEv1。
When running IPv6-in-IPv4 tunnels (unsecured) over the Internet, it is possible to "inject" packets into the tunnel by spoofing the source address (data plane security), or if the tunnel is signaled somehow (e.g., using authentication protocol and obtaining a static v6 prefix), someone might be able to spoof the signaling (control plane security).
在Internet上运行IPv6-in-IPv4隧道（不安全）时，可以通过欺骗源地址（数据平面安全）将数据包“注入”到隧道中，或者如果隧道以某种方式发出信号（例如，使用身份验证协议并获取静态v6前缀），则可能有人能够欺骗信号（控制平面安全）。
The IPsec framework plays an important role in adding security to both the protocol for tunnel setup and data traffic.
IPsec框架在为隧道设置和数据通信协议增加安全性方面起着重要作用。
Either IKEv1 or IKEv2 provides a secure signaling protocol for establishing, maintaining, and deleting an IPsec tunnel.
IKEv1或IKEv2都提供了用于建立、维护和删除IPsec隧道的安全信令协议。
IPsec, with ESP, offers integrity and data origin authentication, confidentiality, and optional (at the discretion of the receiver) anti-replay features. Using confidentiality without integrity is discouraged. ESP furthermore provides limited traffic flow confidentiality.
带有ESP的IPsec提供完整性和数据源身份验证、机密性以及可选（由接收方自行决定）反重播功能。不鼓励在没有完整性的情况下使用机密性。ESP还提供有限的流量机密性。
IPsec provides access control mechanisms through the distribution of keys and also through the application of policies dictated by the Security Policy Database (SPD).
IPsec通过密钥分发和安全策略数据库（SPD）指定的策略应用提供访问控制机制。
The NAT traversal mechanism provided by IKEv2 introduces some weaknesses into IKE and IPsec. These issues are discussed in more detail in [RFC4306].
IKEv2提供的NAT穿越机制在IKE和IPsec中引入了一些弱点。这些问题在[RFC4306]中有更详细的讨论。
Please note that using IPsec for the scenarios described in Figures 1, 2, and 3 does not aim to protect the end-to-end communication. It protects just the tunnel part. It is still possible for an IPv6 endpoint not attached to the IPsec tunnel to spoof packets.
请注意，在图1、2和3中描述的场景中使用IPsec并不是为了保护端到端通信。它只保护隧道的一部分。未连接到IPsec隧道的IPv6端点仍然可能伪造数据包。
The authors are listed in alphabetical order.
作者按字母顺序排列。
Suresh Satapati also participated in the initial discussions on this topic.
苏雷什·萨塔帕蒂也参加了关于这一主题的初步讨论。
The authors would like to thank Stephen Kent, Michael Richardson, Florian Weimer, Elwyn Davies, Eric Vyncke, Merike Kaeo, Alfred Hoenes, Francis Dupont, and David Black for their substantive feedback.
作者要感谢斯蒂芬·肯特、迈克尔·理查森、弗洛里安·魏默、埃尔温·戴维斯、埃里克·温克、梅里克·卡奥、阿尔弗雷德·霍恩斯、弗朗西斯·杜邦和大卫·布莱克的实质性反馈。
We would like to thank Pasi Eronen for his text contributions and suggestions for improvement.
我们要感谢Pasi Eronen的文本贡献和改进建议。
[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月。
[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月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]Baker，F.和P.Savola，“多宿网络的入口过滤”，BCP 84，RFC 37042004年3月。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005.
[RFC3948]Huttunen，A.，Swander，B.，Volpe，V.，DiBurro，L.，和M.Stenberg，“IPsec ESP数据包的UDP封装”，RFC 3948，2005年1月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213]Nordmark，E.和R.Gilligan，“IPv6主机和路由器的基本转换机制”，RFC 4213，2005年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC43062005年12月。
[RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000.
[RFC2893]Gilligan，R.和E.Nordmark，“IPv6主机和路由器的过渡机制”，RFC 2893，2000年8月。
[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月。
[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月。
[RFC3884] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec Transport Mode for Dynamic Routing", RFC 3884, September 2004.
[RFC3884]Touch，J.，Eggert，L.，和Y.Wang，“使用IPsec传输模式进行动态路由”，RFC 3884，2004年9月。
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005.
[RFC4023]Worster，T.，Rekhter，Y.，和E.Rosen，“在IP或通用路由封装（GRE）中封装MPLS”，RFC 4023，2005年3月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006.
[RFC4555]Eronen，P.，“IKEv2移动和多址协议（MOBIKE）”，RFC4555，2006年6月。
[RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and Implementation Guidelines", RFC 4718, October 2006.
[RFC4718]Erenen，P.和P.Hoffman，“IKEv2澄清和实施指南”，RFC 4718，2006年10月。
[TUNN-AD] Palet, J. and M. Diaz, "Analysis of IPv6 Tunnel End-point Discovery Mechanisms", Work in Progress, January 2005.
[TUNN-AD]Palet，J.和M.Diaz，“IPv6隧道端点发现机制的分析”，正在进行的工作，2005年1月。
[VLINK] Duffy, M., "Framework for IPsec Protected Virtual Links for PPVPNs", Work in Progress, October 2002.
[VLINK]Duffy，M.，“PPVPN的IPsec保护虚拟链路框架”，正在进行的工作，2002年10月。
First, we describe the different tunnel mode implementation methods. We note that, in this context, only the so-called Specific SPD (SSPD) model (without a tunnel interface) can be made to work, but it has reduced applicability, and the use of a transport mode tunnel is recommended instead. However, we will describe how the SSPD tunnel mode might look if one would like to use it in any case.
首先，我们描述了不同的隧道模式实现方法。我们注意到，在这种情况下，只有所谓的特定SPD（SSPD）模型（没有隧道接口）可以工作，但它的适用性降低，建议使用传输模式隧道。然而，我们将描述SSPD隧道模式在任何情况下使用时的外观。
Tunnel mode could (in theory) be deployed in two very different ways depending on the implementation:
隧道模式（理论上）可以通过两种非常不同的方式部署，具体取决于实现：
1. "Generic SPDs": some implementations model the tunnel mode SA as an IP interface. In this case, an IPsec tunnel interface is created and used with "any" addresses ("::/0 <-> ::/0" ) as IPsec traffic selectors while setting up the SA. Though this allows all traffic between the two nodes to be protected by IPsec, the routing table would decide what traffic gets sent over the tunnel. Ingress filtering must be separately applied on the tunnel interface as the IPsec policy checks do not check the IPv6 addresses at all. Routing protocols, multicast, etc. will work through this tunnel. This mode is similar to transport mode. The SPDs must be interface-specific. However, because IKE uses IPv4 but the tunnel is IPv6, there is no standard solution to map the IPv4 interface to IPv6 interface [VLINK] and this approach is not feasible.
1. “通用SPD”：一些实现将隧道模式SA建模为IP接口。在这种情况下，将创建一个IPsec隧道接口，并在设置SA时与“任意”地址（“：：/0<->：：/0”）一起用作IPsec流量选择器。虽然这允许两个节点之间的所有通信都受到IPsec的保护，但路由表将决定通过隧道发送的通信量。入口过滤必须单独应用于隧道接口，因为IPsec策略检查根本不检查IPv6地址。路由协议、多播等将通过此隧道工作。此模式类似于传输模式。SPD必须是特定于接口的。但是，由于IKE使用IPv4，但隧道是IPv6，因此没有将IPv4接口映射到IPv6接口[VLINK]的标准解决方案，这种方法不可行。
2. "Specific SPDs": some implementations do not model the tunnel mode SA as an IP interface. Traffic selection is based on specific SPD entries, e.g., "2001:db8:1::/48 <-> 2001:db8: 2::/48". As the IPsec session between two endpoints does not have an interface (though an implementation may have a common pseudo-interface for all IPsec traffic), there is no Duplicate Address Detection (DAD), Multicast Listener Discovery (MLD), or link-local traffic to protect; multicast is not possible over such a tunnel. Ingress filtering is performed automatically by the IPsec traffic selectors.
2. “特定SPD”：某些实现不将隧道模式SA建模为IP接口。流量选择基于特定的SPD条目，例如，“2001:db8:1:：/48<->2001:db8:2:：/48”。由于两个端点之间的IPsec会话没有接口（尽管一个实现可能对所有IPsec流量都有一个公共伪接口），因此不存在要保护的重复地址检测（DAD）、多播侦听器发现（MLD）或链路本地流量；在这样的隧道上不可能进行多播。入口过滤由IPsec流量选择器自动执行。
Ingress filtering is guaranteed by IPsec processing when option (2) is chosen, whereas the operator has to enable it explicitly when transport mode or option (1) is chosen.
当选择选项（2）时，IPsec处理保证了入口过滤，而当选择传输模式或选项（1）时，操作员必须显式启用入口过滤。
In summary, there does not appear to be a standard solution in this context for the first implementation approach.
总之，在这种情况下，第一种实现方法似乎没有标准的解决方案。
The second approach can be made to work, but is only applicable in host-to-host or site-to-router/router-to-site scenarios (i.e., when the IPv6 prefixes can be known a priori), and it offers only a limited set of features (e.g., no multicast) compared with a transport mode tunnel.
第二种方法可以工作，但仅适用于主机到主机或站点到路由器/路由器到站点的场景（即，当IPv6前缀可以事先知道时），与传输模式隧道相比，它只提供有限的一组功能（例如，无多播）。
When tunnel mode is used, fragment handling [RFC4301] may also be more difficult compared with transport mode and, depending on implementation, may need to be reflected in SPDs.
当使用隧道模式时，与传输模式相比，碎片处理[RFC4301]可能更加困难，并且根据实现情况，可能需要在SPD中反映出来。
The following SPD entries assume that there are two hosts, Host1 and Host2, whose IPv6 addresses are denoted IPV6-EP1 and IPV6-EP2 (global addresses), and the IPV4 addresses of the tunnel endpoints are denoted IPV4-TEP1 and IPV4-TEP2, respectively.
以下SPD条目假设有两台主机，主机1和主机2，其IPv6地址分别表示为IPv6-EP1和IPv6-EP2（全局地址），隧道端点的IPV4地址分别表示为IPV4-TEP1和IPV4-TEP2。
Host1's SPD:
Next Layer
Rule Local Remote Protocol Action
---- ----- ------ ---------- --------
1 IPV6-EP1 IPV6-EP2 ESP BYPASS
2 IPV6-EP1 IPV6-EP2 IKE BYPASS
3 IPv6-EP1 IPV6-EP2 41 PROTECT(ESP,
tunnel{IPV4-TEP1,IPV4-TEP2})
Host1's SPD:
Next Layer
Rule Local Remote Protocol Action
---- ----- ------ ---------- --------
1 IPV6-EP1 IPV6-EP2 ESP BYPASS
2 IPV6-EP1 IPV6-EP2 IKE BYPASS
3 IPv6-EP1 IPV6-EP2 41 PROTECT(ESP,
tunnel{IPV4-TEP1,IPV4-TEP2})
Host2's SPD:
Next Layer
Rule Local Remote Protocol Action
---- ----- ------ ---------- --------
1 IPV6-EP2 IPV6-EP1 ESP BYPASS
2 IPV6-EP2 IPV6-EP1 IKE BYPASS
3 IPv6-EP2 IPV6-EP1 41 PROTECT(ESP,
tunnel{IPV4-TEP2,IPV4-TEP1})
Host2's SPD:
Next Layer
Rule Local Remote Protocol Action
---- ----- ------ ---------- --------
1 IPV6-EP2 IPV6-EP1 ESP BYPASS
2 IPV6-EP2 IPV6-EP1 IKE BYPASS
3 IPv6-EP2 IPV6-EP1 41 PROTECT(ESP,
tunnel{IPV4-TEP2,IPV4-TEP1})
"IKE" refers to UDP destination port 500 and possibly also port 4500 if NAT traversal is used.
“IKE”指UDP目标端口500，如果使用NAT遍历，还可能指端口4500。
The IDci and IDcr payloads of IKEv1 carry the IPV6-EP1 and IPV6-TEP2 as phase 2 identities. With IKEv2, the traffic selectors are used to carry the same information.
IKEv1的IDci和IDcr有效载荷携带IPV6-EP1和IPV6-TEP2作为第2阶段标识。对于IKEv2，流量选择器用于承载相同的信息。
The following SPD entries assume that the host has the IPv6 address IPV6-EP1 and the tunnel endpoints of the host and router are IPV4- TEP1 and IPV4-TEP2, respectively. If the tunnel is between a router and a host where the router has allocated an IPV6-PREF/48 to the host, the corresponding SPD entries can be derived by replacing IPV6- EP1 with IPV6-PREF/48.
以下SPD条目假定主机具有IPv6地址IPv6-EP1，主机和路由器的隧道端点分别为IPV4-TEP1和IPV4-TEP2。如果隧道位于路由器和主机之间，且路由器已将IPV6-PREF/48分配给该主机，则可以通过将IPV6-EP1替换为IPV6-PREF/48来导出相应的SPD条目。
Please note the bypass entry for host's SPD, absent in router's SPD. While this might be an implementation matter for host-to-router tunneling, having a similar entry, "Local=IPV6-PREF/48 & Remote=IPV6- PREF/48", is critical for site-to-router tunneling.
请注意主机SPD的旁路条目，路由器SPD中没有。虽然这可能是主机到路由器隧道的实现问题，但具有类似的条目“Local=IPV6-PREF/48&Remote=IPV6-PREF/48”对于站点到路由器隧道至关重要。
Host's SPD:
Next Layer
Rule Local Remote Protocol Action
---- ----- ------ ---------- --------
1 IPV6-EP1 IPV6-EP2 ESP BYPASS
2 IPV6-EP1 IPV6-EP2 IKE BYPASS
3 IPV6-EP1 IPV6-EP1 ANY BYPASS
4 IPV6-EP1 ANY ANY PROTECT(ESP,
tunnel{IPV4-TEP1,IPV4-TEP2})
Host's SPD:
Next Layer
Rule Local Remote Protocol Action
---- ----- ------ ---------- --------
1 IPV6-EP1 IPV6-EP2 ESP BYPASS
2 IPV6-EP1 IPV6-EP2 IKE BYPASS
3 IPV6-EP1 IPV6-EP1 ANY BYPASS
4 IPV6-EP1 ANY ANY PROTECT(ESP,
tunnel{IPV4-TEP1,IPV4-TEP2})
Router's SPD:
Next Layer
Rule Local Remote Protocol Action
---- ----- ------ ---------- --------
1 IPV6-EP2 IPV6-EP1 ESP BYPASS
2 IPV6-EP2 IPV6-EP1 IKE BYPASS
3 ANY IPV6-EP1 ANY PROTECT(ESP,
tunnel{IPV4-TEP1,IPV4-TEP2})
Router's SPD:
Next Layer
Rule Local Remote Protocol Action
---- ----- ------ ---------- --------
1 IPV6-EP2 IPV6-EP1 ESP BYPASS
2 IPV6-EP2 IPV6-EP1 IKE BYPASS
3 ANY IPV6-EP1 ANY PROTECT(ESP,
tunnel{IPV4-TEP1,IPV4-TEP2})
The IDci and IDcr payloads of IKEv1 carry the IPV6-EP1 and ID_IPV6_ADDR_RANGE or ID_IPV6_ADDR_SUBNET as their phase 2 identities. The starting address is zero and the end address is all ones for ID_IPV6_ADDR_RANGE. The starting address is zero IP address and the end address is all zeroes for ID_IPV6_ADDR_SUBNET. With IKEv2, the traffic selectors are used to carry the same information.
IKEv1的IDci和IDcr有效负载携带IPV6-EP1和ID_IPV6_ADDR_范围或ID_IPV6_ADDR_子网作为其第2阶段标识。对于ID\u IPV6\u ADDR\u范围，起始地址为零，结束地址为全1。对于ID_IPV6_ADDR_子网，起始地址为零IP地址，结束地址为全零。对于IKEv2，流量选择器用于承载相同的信息。
With the exchange of protected configuration payloads, IKEv2 is able to provide the IKEv2 peer with Dynamic Host Configuration Protocol (DHCP)-like information payloads. These configuration payloads are exchanged between the IKEv2 initiator and responder.
通过交换受保护的配置有效载荷，IKEv2能够向IKEv2对等方提供类似于动态主机配置协议（DHCP）的信息有效载荷。这些配置有效载荷在IKEv2启动器和响应程序之间交换。
This could be used (for example) by the host in the host-to-router scenario to obtain an IPv6 address from the ISP as part of setting up the IPsec tunnel mode SA. The details of these procedures are out of scope for this memo.
作为设置IPsec隧道模式SA的一部分，主机可以（例如）在主机到路由器场景中使用此选项从ISP获取IPv6地址。这些程序的细节超出了本备忘录的范围。
Network address (and port) translation devices are commonly found in today's networks. A detailed description of the problem and requirements of IPsec-protected data traffic traversing a NAT is provided in [RFC3715].
网络地址（和端口）转换设备在当今的网络中很常见。[RFC3715]中详细描述了穿越NAT的受IPsec保护的数据通信的问题和要求。
IKEv2 can detect the presence of a NAT automatically by sending NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads in the initial IKE_SA_INIT exchange. Once a NAT is detected and both endpoints support IPsec NAT traversal extensions, UDP encapsulation can be enabled.
IKEv2可以通过在初始IKE_SA_INIT交换中发送NAT_检测源IP和NAT_检测目的IP有效负载来自动检测NAT的存在。一旦检测到NAT并且两个端点都支持IPsec NAT遍历扩展，就可以启用UDP封装。
More details about UDP encapsulation of IPsec-protected IP packets can be found in [RFC3948].
有关受IPsec保护的IP数据包的UDP封装的更多详细信息，请参见[RFC3948]。
For IPv6-in-IPv4 tunneling, NAT traversal is interesting for two reasons:
对于IPv6-in-IPv4隧道，NAT穿越之所以有趣，有两个原因：
1. One of the tunnel endpoints is often behind a NAT, and configured tunneling, using protocol 41, is not guaranteed to traverse the NAT. Hence, using IPsec tunnels would enable one to set up both a secure tunnel and a tunnel that might not always be possible without other tunneling mechanisms.
1. 其中一个隧道端点通常位于NAT后面，并且使用协议41配置的隧道不能保证穿越NAT。因此，使用IPsec隧道将使您能够同时设置安全隧道和隧道，如果没有其他隧道机制，这些隧道可能并不总是可行的。
2. Using NAT traversal allows the outer address to change without having to renegotiate the SAs. This could be beneficial for a crude form of mobility and in scenarios where the NAT changes the IP addresses frequently. However, as the outer address may change, this might introduce new security issues, and using tunnel mode would be most appropriate.
2. 使用NAT遍历允许更改外部地址，而无需重新协商SAs。这对于粗略的移动性形式和NAT频繁更改IP地址的场景可能是有益的。但是，由于外部地址可能会更改，这可能会带来新的安全问题，使用隧道模式将是最合适的。
When NAT is not applied, the second benefit would still be desirable. In particular, using manually configured tunneling is an operational challenge with dynamic IP addresses, because both ends need to be reconfigured if an address changes. Therefore, an easy and efficient way to re-establish the IPsec tunnel if the IP address changes would be desirable. MOBIKE [RFC4555] provides a solution when IKEv2 is used, but it only supports tunnel mode.
如果不采用NAT，第二个好处仍然是可取的。特别是，对于动态IP地址，使用手动配置的隧道是一个操作挑战，因为如果地址发生变化，两端都需要重新配置。因此，如果IP地址发生变化，则需要一种简单有效的方法来重新建立IPsec隧道。MOBIKE[RFC4555]在使用IKEv2时提供了一种解决方案，但它仅支持隧道模式。
The IKEv2 initiator needs to know the address of the IKEv2 responder to start IKEv2 signaling. A number of ways can be used to provide the initiator with this information, for example:
IKEv2启动器需要知道IKEv2响应程序的地址才能启动IKEv2信令。可以使用多种方式向启动器提供此信息，例如：
o Using out-of-band mechanisms, e.g., from the ISP's Web page.
o 使用带外机制，例如从ISP的网页。
o Using DNS to look up a service name by appending it to the DNS search path provided by DHCPv4 (e.g., "tunnel-service.example.com").
o 通过将服务名称附加到DHCPv4提供的DNS搜索路径（例如，“tunnel service.example.com”），使用DNS查找服务名称。
o Using a DHCP option.
o 使用DHCP选项。
o Using a pre-configured or pre-determined IPv4 anycast address.
o 使用预先配置或预先确定的IPv4选播地址。
o Using other, unspecified or proprietary methods.
o 使用其他未指定或专有的方法。
For the purpose of this document, it is assumed that this address can be obtained somehow. Once the address has been learned, it is configured as the tunnel endpoint for the configured IPv6-in-IPv4 tunnel.
就本文件而言，假设可以通过某种方式获得该地址。读入地址后，它将被配置为已配置的IPv6-in-IPv4隧道的隧道端点。
This problem is also discussed at more length in [TUNN-AD].
这个问题在[TUNN-AD]中也有详细讨论。
However, simply discovering the tunnel endpoint is not sufficient for establishing an IKE session with the peer. The PAD information (see Section 5.2) also needs to be learned dynamically. Hence, currently, automatic endpoint discovery provides benefit only if PAD information is chosen in such a manner that it is not IP-address specific.
然而，仅仅发现隧道端点并不足以与对等方建立IKE会话。PAD信息（见第5.2节）也需要动态学习。因此，目前，只有当PAD信息的选择方式不是特定于IP地址时，自动端点发现才会带来好处。
Authors' Addresses
作者地址
Richard Graveman RFG Security, LLC 15 Park Avenue Morristown, NJ 07960 USA
Richard Graveman RFG Security，LLC美国新泽西州莫里斯镇公园大道15号，邮编：07960
EMail: rfg@acm.org
EMail: rfg@acm.org
Mohan Parthasarathy Nokia 313 Fairchild Drive Mountain View, CA 94043 USA
Mohan Parthasarathy诺基亚313飞兆半导体山景大道，美国加利福尼亚州94043
EMail: mohanp@sbcglobal.net
EMail: mohanp@sbcglobal.net
Pekka Savola CSC/FUNET Espoo Finland
佩卡·萨沃拉CSC/芬兰福内·埃斯波
EMail: psavola@funet.fi
EMail: psavola@funet.fi
Hannes Tschofenig Nokia Siemens Networks Otto-Hahn-Ring 6 Munich, Bayern 81739 Germany
德国拜仁慕尼黑，诺基亚西门子网络奥托哈恩6环，邮编81739
EMail: Hannes.Tschofenig@nsn.com
EMail: Hannes.Tschofenig@nsn.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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编辑功能的资金目前由互联网协会提供。