Network Working Group M. Stiemerling
Request for Comments: 5207 J. Quittek
Category: Informational NEC
L. Eggert
Nokia
April 2008
Network Working Group M. Stiemerling
Request for Comments: 5207 J. Quittek
Category: Informational NEC
L. Eggert
Nokia
April 2008
NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication
主机身份协议（HIP）通信中的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.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
IESG Note
IESG注释
This RFC is a product of the Internet Research Task Force and is not a candidate for any level of Internet Standard. The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment.
本RFC是互联网研究工作组的产品，不适用于任何级别的互联网标准。IRTF发布互联网相关研究和开发活动的结果。这些结果可能不适合部署。
Abstract
摘要
The Host Identity Protocol (HIP) changes the way in which two Internet hosts communicate. One key advantage over other schemes is that HIP does not require modifications to the traditional network-layer functionality of the Internet, i.e., its routers. In the current Internet, however, many devices other than routers modify the traditional network-layer behavior of the Internet. These "middleboxes" are intermediary devices that perform functions other than the standard functions of an IP router on the datagram path between source and destination hosts. Whereas some types of middleboxes may not interfere with HIP at all, others can affect some aspects of HIP communication, and others can render HIP communication impossible. This document discusses the problems associated with HIP communication across network paths that include specific types of middleboxes, namely, network address translators and firewalls. It identifies and discusses issues in the current HIP specifications that affect communication across these types of middleboxes. This document is a product of the IRTF HIP Research Group.
主机标识协议（HIP）改变了两台Internet主机的通信方式。与其他方案相比，HIP的一个关键优势是不需要修改互联网的传统网络层功能，即其路由器。然而，在当前的互联网中，除路由器以外的许多设备改变了互联网的传统网络层行为。这些“中间盒”是在源主机和目标主机之间的数据报路径上执行IP路由器标准功能以外的功能的中间设备。尽管某些类型的中间包可能根本不会干扰HIP，但其他类型的中间包可能会影响HIP通信的某些方面，而其他类型的中间包可能会使HIP通信变得不可能。本文档讨论与跨网络路径HIP通信相关的问题，这些网络路径包括特定类型的中间盒，即网络地址转换器和防火墙。它确定并讨论了当前HIP规范中影响这些类型的中间盒之间通信的问题。本文件是IRTF HIP研究小组的产品。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. HIP across NATs . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Phase 1: HIP Base Exchange . . . . . . . . . . . . . . . . 4
2.1.1. IPv4 HIP Base Exchange . . . . . . . . . . . . . . . . 4
2.1.2. IPv6 HIP Base Exchange . . . . . . . . . . . . . . . . 5
2.2. Phase 2: ESP Data Exchange . . . . . . . . . . . . . . . . 5
3. HIP Across Firewalls . . . . . . . . . . . . . . . . . . . . . 6
3.1. Phase 1: HIP Base Exchange . . . . . . . . . . . . . . . . 6
3.1.1. IPv4 HIP Base Exchange . . . . . . . . . . . . . . . . 6
3.1.2. IPv6 HIP Base Exchange . . . . . . . . . . . . . . . . 6
3.2. Phase 2: ESP Data Exchange . . . . . . . . . . . . . . . . 7
4. HIP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 7
5. NAT Extensions . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Legacy NAT and Firewall Traversal . . . . . . . . . . . . . . 8
7. HIP across Other Middleboxes . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . . 10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. HIP across NATs . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Phase 1: HIP Base Exchange . . . . . . . . . . . . . . . . 4
2.1.1. IPv4 HIP Base Exchange . . . . . . . . . . . . . . . . 4
2.1.2. IPv6 HIP Base Exchange . . . . . . . . . . . . . . . . 5
2.2. Phase 2: ESP Data Exchange . . . . . . . . . . . . . . . . 5
3. HIP Across Firewalls . . . . . . . . . . . . . . . . . . . . . 6
3.1. Phase 1: HIP Base Exchange . . . . . . . . . . . . . . . . 6
3.1.1. IPv4 HIP Base Exchange . . . . . . . . . . . . . . . . 6
3.1.2. IPv6 HIP Base Exchange . . . . . . . . . . . . . . . . 6
3.2. Phase 2: ESP Data Exchange . . . . . . . . . . . . . . . . 7
4. HIP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 7
5. NAT Extensions . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Legacy NAT and Firewall Traversal . . . . . . . . . . . . . . 8
7. HIP across Other Middleboxes . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . . 10
The current specification of the Host Identity Protocol (HIP) [RFC4423] assumes simple Internet paths, where routers forward globally routable IP packets based on their destination address alone.
当前的主机标识协议（HIP）[RFC4423]规范假定了简单的Internet路径，其中路由器仅根据其目的地地址转发全局可路由的IP数据包。
In the current Internet, such pure paths are becoming increasingly rare. For a number of reasons, several types of devices modify or extend the pure forwarding functionality the Internet's network layer used to deliver. [RFC3234] coins the term middleboxes for such devices: "A middlebox is (...) any intermediary device performing functions other than the normal, standard functions of an IP router on the datagram path between a source host and destination host".
在当前的互联网中，这种纯粹的路径正变得越来越少。出于许多原因，有几种类型的设备修改或扩展了互联网网络层用于传输的纯转发功能。[RFC3234]为此类设备创造了术语“中间盒”：“中间盒是（…）在源主机和目标主机之间的数据报路径上执行IP路由器的正常标准功能以外的任何中间设备”。
Middleboxes affect communication in a number of ways. For example, they may inspect the flows of some transport protocols, such as TCP, and selectively drop, insert, or modify packets. If such devices encounter a higher-layer protocol they do not support, or even a variant of a supported protocol that they do not know how to handle, communication across the middlebox may become impossible for these kinds of traffic.
中间盒以多种方式影响通信。例如，他们可以检查某些传输协议（如TCP）的流，并有选择地丢弃、插入或修改数据包。如果这些设备遇到它们不支持的更高层协议，或者甚至遇到它们不知道如何处理的受支持协议的变体，那么对于这些类型的通信来说，通过中间件的通信可能变得不可能。
There are many different variants of middleboxes. The most common ones are network address translators and firewalls. [RFC3234] identifies many other types of middleboxes. One broad way of classifying them is by behavior. The first group operates on packets, does not modify application-layer payloads, and does not insert additional packets. This group includes NAT, NAT-PT, SOCKS gateways, IP tunnel endpoints, packet classifiers, markers, schedulers, transport relays, IP firewalls, application firewalls, involuntary packet redirectors, and anonymizers.
中间盒有许多不同的变体。最常见的是网络地址转换器和防火墙。[RFC3234]识别许多其他类型的中间盒。一种广泛的分类方法是通过行为。第一组对数据包进行操作，不修改应用层有效负载，也不插入额外的数据包。该组包括NAT、NAT-PT、SOCKS网关、IP隧道端点、数据包分类器、标记、调度程序、传输中继、IP防火墙、应用程序防火墙、非自愿数据包重定向器和匿名器。
Other middleboxes exist (such as TCP performance-enhancing proxies, application-level gateways, gatekeepers, session control boxes, transcoders, proxies, caches, modified DNS servers, content and applications distribution boxes, and load balancers) that divert or modify URLs, application-level interceptors, and application-level multicast systems. However, NATs and firewalls are the most frequent middleboxes that HIP traffic can encounter in the Internet. Consequently, this memo focuses on how NAT and firewall middleboxes can interfere with HIP traffic.
存在其他中间盒（如TCP性能增强代理、应用程序级网关、网关守护者、会话控制盒、转码器、代理、缓存、修改后的DNS服务器、内容和应用程序分发盒以及负载平衡器），用于转移或修改URL、应用程序级拦截器、，和应用层多播系统。然而，NAT和防火墙是HIP流量在Internet上可能遇到的最常见的中间包。因此，本备忘录重点关注NAT和防火墙中间盒如何干扰HIP流量。
Middleboxes can cause two different kinds of communication problems for HIP. They can interfere with the transmission of HIP control traffic or with the transmission of the HIP data traffic carried within the Encapsulating Security Payload (ESP) [RFC4303].
中间盒可能会导致HIP出现两种不同的通信问题。它们可能会干扰HIP控制流量的传输或封装安全有效载荷（ESP）中携带的HIP数据流量的传输[RFC4303]。
This document serves mainly as a problem description that solution proposals can reference. But it also discusses known approaches to solving the problem and gives recommendations for certain approaches depending on the specific scenario. It does not promote the use of any of the discussed types of middleboxes.
本文件主要作为问题描述，解决方案建议可供参考。但它也讨论了解决问题的已知方法，并根据具体场景给出了某些方法的建议。它不提倡使用所讨论的任何类型的中间盒。
This memo was discussed and modified in the Host Identity Protocol Research Group, was reviewed by the Internet Research Steering Group (IRSG), and represents a consensus view of the research group at the time of its submission for publication.
本备忘录在主机身份协议研究小组中进行了讨论和修改，并由互联网研究指导小组（IRSG）审查，代表了研究小组在提交出版时的共识。
This section focuses on the traversal of HIP across network address translator (NAT) middleboxes. This document uses the term NAT for a basic translation of IP addresses, whereas it uses the term NAPT for NATs that additionally perform port translation [RFC2663], if a differentiation between the two is important.
本节重点介绍跨网络地址转换器（NAT）中间盒的HIP遍历。本文档使用术语NAT来表示IP地址的基本转换，而使用术语NAPT来表示另外执行端口转换的NAT[RFC2663]，前提是两者之间的区别很重要。
HIP operates in two phases. It first performs a HIP "base exchange" handshake before starting to exchange application data in the second phase. This section describes the problems that occur in each of the two phases when NATs are present along the path from the HIP initiator to the responder.
HIP分两个阶段运行。在第二阶段开始交换应用程序数据之前，它首先执行HIP“基本交换”握手。本节描述了当NAT沿HIP启动器到响应程序的路径存在时，在两个阶段中的每个阶段中出现的问题。
The HIP base exchange uses different transport mechanisms for IPv6 and IPv4. With IPv6, it uses a HIP-specific IPv6 extension header, whereas it uses the IP payload with IPv4 [RFC5201].
HIP base exchange对IPv6和IPv4使用不同的传输机制。在IPv6中，它使用特定于HIP的IPv6扩展头，而在IPv4中使用IP有效负载[RFC5201]。
The HIP protocol specification [RFC5201] suggests encapsulating the IPv4 HIP base exchange in a new IP payload type. The chances of NAT traversal for this traffic are different, depending on the type of NAT in the path. The IPv4 HIP base exchange traverses basic NATs (that translate IP addresses only) without problems, if the NAT only interprets and modifies the IP header, i.e., it does not inspect the IP payload.
HIP协议规范[RFC5201]建议将IPv4 HIP base exchange封装在新的IP有效负载类型中。根据路径中NAT的类型，此流量穿越NAT的机会不同。如果NAT仅解释和修改IP报头，即它不检查IP有效负载，则IPv4 HIP base exchange将毫无问题地遍历基本NAT（仅转换IP地址）。
However, basic NATs are rare. NAPT devices that inspect and translate transport-layer port numbers are much more common. Because the IP payload used for the IPv4 base exchange does not contain port numbers or other demultiplexing fields, NAPTs cannot relay it.
然而，基本的NAT很少见。检查和转换传输层端口号的NAPT设备更为常见。因为用于IPv4基本交换的IP有效负载不包含端口号或其他解复用字段，所以NAPTs无法对其进行中继。
A second issue is the well-known "data receiver behind a NAT" problem. HIP nodes behind a NAT are not reachable unless they initiate the communication themselves, because the necessary translation state is otherwise not present at the NAT.
第二个问题是众所周知的“NAT背后的数据接收器”问题。NAT后面的HIP节点不可访问，除非它们自己启动通信，因为NAT不存在必要的转换状态。
The IPv6 HIP base exchange uses empty IPv6 packets (without a payload). New HIP extension headers carry the base exchange information. This approach can cause problems if NAT middleboxes translate or multiplex IP addresses.
IPv6 HIP base exchange使用空IPv6数据包（无有效负载）。新的髋关节延长头携带基本交换信息。如果NAT中间件转换或多路传输IP地址，这种方法可能会导致问题。
At this time, IPv6 NATs are rare. However, when they exist, IPv6 NATs operate similarly to IPv4 NATs. Consequently, they will likely block IP payloads other than the "well-known" transport protocols. This includes the IPv6 HIP base exchange, which does not contain any IP payload.
目前，IPv6 NAT非常罕见。但是，当它们存在时，IPv6 NAT的操作与IPv4 NAT类似。因此，它们可能会阻止“众所周知”传输协议以外的IP有效负载。这包括IPv6 HIP base exchange，它不包含任何IP负载。
HIP uses ESP to secure the data transmission between two HIP nodes after the base exchange completes. Thus, HIP faces the same challenges as IPsec with regard to NAT traversal. [RFC3715] discusses these issues for IPsec and describes three distinct problem categories: NAT-intrinsic issues, NAT implementation issues, and helper incompatibilities.
HIP使用ESP在基本交换完成后保护两个HIP节点之间的数据传输。因此，HIP在NAT穿越方面面临与IPsec相同的挑战。[RFC3715]讨论了IPsec的这些问题，并描述了三种不同的问题类别：NAT固有问题、NAT实现问题和帮助程序不兼容。
This section focuses on the first category, i.e., NAT-intrinsic issues. The two other problem categories are out of this document's scope. They are addressed in the BEHAVE working group or in [RFC3489].
本节重点讨论第一类问题，即NAT固有问题。其他两个问题类别不在本文档的范围内。这些问题在工作组或[RFC3489]中讨论。
With ESP-encrypted data traffic, all upper-layer headers are invisible to a NAT. Thus, changes of the IP header during NAT traversal can invalidate upper-layer checksums contained within the ESP-protected payload. HIP hosts already avoid this problem by substituting Host Identity Tags (HITs) for IP addresses during checksum calculations [RFC5201].
对于ESP加密的数据流量，所有上层头对NAT都是不可见的。因此，NAT遍历期间IP报头的更改可能会使ESP保护负载中包含的上层校验和无效。HIP主机已经通过在校验和计算期间用主机标识标签（HITs）替换IP地址来避免这个问题[RFC5201]。
Although the traversal of ESP-encrypted packets across NATs is possible, [RFC3715] notes that the Security Parameter Index (SPI) values of such traffic have only one-way significance. NATs can use SPI values to demultiplex different IPsec flows, similar to how they use port number pairs to demultiplex unencrypted transport flows. Furthermore, NATs may modify the SPIs, similar to how they modify port numbers, when multiple IPsec nodes behind them happen to choose
尽管可以跨NAT遍历ESP加密的数据包，[RFC3715]注意到此类流量的安全参数索引（SPI）值只有单向意义。NAT可以使用SPI值来解复用不同的IPsec流，类似于使用端口号对来解复用未加密的传输流。此外，当NAT后面的多个IPsec节点碰巧进行选择时，NAT可能会修改SPI，类似于它们修改端口号的方式
identical SPIs. However, NATs can only observe the SPIs of outgoing IPsec flows and cannot determine the SPIs of the corresponding return traffic.
相同的SPI。但是，NAT只能观察传出IPsec流的SPI，无法确定相应返回流量的SPI。
This section focuses on the traversal of HIP across IP firewalls and packet filters. These types of middleboxes inspect individual packets and decide whether to forward, discard, or process them in some special way, based on a set of filter rules and associated actions.
本节重点介绍跨IP防火墙和数据包过滤器的HIP遍历。这些类型的中间盒检查单个数据包，并根据一组筛选规则和相关操作决定是否转发、丢弃或以某种特殊方式处理它们。
Firewalls are not inherently problematic for HIP, as long as their policy rules permit HIP base exchange and IPsec traffic to traverse. The next sections discuss specific issues for HIP in typical firewall configurations.
防火墙对于HIP本身并没有问题，只要它们的策略规则允许HIP基本交换和IPsec通信量通过。下一节将讨论典型防火墙配置中HIP的具体问题。
A common and recommended configuration for IPv4 firewalls is to block all unknown traffic by default and to allow well-known transport protocols only and often just on specific ports and with specific characteristics ("scrubbed" traffic). This common configuration blocks the HIP base exchange.
IPv4防火墙的一种常见且推荐的配置是，默认情况下阻止所有未知流量，并且只允许在特定端口和具有特定特征的端口上使用已知传输协议（“清除”流量）。这种常见的配置会阻止髋关节基座交换。
The configuration of IPv6 firewalls is similar to IPv4 firewalls. Many IPv4 firewalls discard any IP packet that includes an IP option. With IPv6, the expectation is that firewalls will block IPv6 extension headers in general or will at least block unknown extension headers. Furthermore, payloads other than specific, well-known transport protocols are likely to be blocked as well. Like IPv4, this behavior blocks the HIP base exchange.
IPv6防火墙的配置类似于IPv4防火墙。许多IPv4防火墙丢弃任何包含IP选项的IP数据包。在IPv6中，防火墙通常会阻止IPv6扩展头，或者至少会阻止未知的扩展头。此外，除特定的、众所周知的传输协议之外的有效负载也可能被阻塞。与IPv4一样，此行为会阻止HIP base exchange。
A problem similar to the "data receiver behind a NAT" issue (see Section 2.1.1) applies to both IPv4 and IPv6 firewalls. Typically, firewalls block all traffic into the protected network that is not identifiable return traffic of a prior outbound communication. This means that HIP peers are not reachable outside the protected network, because firewalls block base exchange attempts from outside peers.
类似于“NAT背后的数据接收器”问题（参见第2.1.1节）的问题适用于IPv4和IPv6防火墙。通常，防火墙会阻止进入受保护网络的所有流量，这些流量无法识别先前出站通信的返回流量。这意味着在受保护的网络之外无法访问HIP对等点，因为防火墙会阻止来自外部对等点的基本交换尝试。
Firewalls are less problematic than NATs with regard to passing ESP traffic. The largest concern is commonly used firewall configurations that block ESP traffic, because it is not a well-known transport protocol and ports cannot be used to identify return flows. However, firewalls could use mechanisms similar to Security Parameter Index (SPI) multiplexed NAT (SPINAT) to use SPIs as flow identifiers [YLITALO].
就通过ESP流量而言，防火墙的问题比NAT小。最大的问题是阻止ESP通信的常用防火墙配置，因为它不是众所周知的传输协议，端口不能用于识别返回流。然而，防火墙可以使用类似于安全参数索引（SPI）复用NAT（SPINAT）的机制来使用SPI作为流标识符[YLITALO]。
This section identifies possible changes to HIP that attempt to improve NAT and firewall traversal, specifically, the reachability of HIP peers behind those middleboxes and traversal of the HIP base exchange. Sections 2 and 3 describe several problems related to encapsulation schemes for the HIP base exchange in IPv4 and IPv6.
本节确定了可能对HIP进行的更改，这些更改试图改进NAT和防火墙遍历，特别是那些中间盒后面的HIP对等方的可达性和HIP基本交换的遍历。第2节和第3节描述了与IPv4和IPv6中HIP-base exchange的封装方案相关的几个问题。
UDP may improve HIP operation in the presence of NATs and firewalls. It may also aid traversal of other middleboxes. For example, load balancers that use IP- and transport-layer information can correctly operate with UDP-encapsulated HIP traffic.
UDP可以改善NAT和防火墙存在时的HIP操作。它还可以帮助遍历其他中间盒。例如，使用IP和传输层信息的负载平衡器可以正确地处理UDP封装的HIP流量。
HIP nodes located behind a NAT must notify their communication peers about the contact information. The contact information is the NAT's public IP address and a specific UDP port number. This measure enables the peers to send return traffic to HIP nodes behind the NAT. This would require a new HIP mechanism.
位于NAT后面的HIP节点必须将联系信息通知其通信对等方。联系信息是NAT的公共IP地址和特定的UDP端口号。此度量使对等方能够向NAT后面的HIP节点发送返回流量。这需要一种新的髋关节机制。
To be reachable behind a NAT, a rendezvous point is required that lets HIP nodes behind a NAT register an IP address and port number that can be used to contact them. Depending on the type of NAT, use of this rendezvous point may be required only during the base exchange or throughout the duration of a communication instance. A rendezvous point is also useful for HIP nodes behind firewalls, because they suffer from an analogous problem, as described in Section 3.
为了能够在NAT后面到达，需要一个集合点，让NAT后面的HIP节点注册一个IP地址和端口号，可以用来联系他们。根据NAT的类型，可能仅在基站交换期间或整个通信实例期间需要使用此集合点。集合点对于防火墙后面的HIP节点也很有用，因为它们会遇到类似的问题，如第3节所述。
The proposed mobility management packet exchange [RFC5206] [NIKANDER] can support this method of NAT traversal. The original intention of this extension is to support host mobility and multihoming. This mechanism is similar to the Alternate Network Address Types (ANAT) described in [RFC4091]. However, HIP peers use mobility management messages to notify peers about rendezvous points, similar to [RFC4091]. HIP peers must determine their contact address before they can announce it to their peers.
提议的移动性管理分组交换[RFC5206][NIKANDER]可以支持这种NAT穿越方法。这个扩展的初衷是支持主机移动性和多宿。该机制类似于[RFC4091]中描述的备用网络地址类型（ANAT）。然而，HIP对等方使用移动性管理消息通知对等方集合点，类似于[RFC4091]。HIP同龄人必须先确定他们的联系地址，然后才能向同龄人宣布。
IPsec SPIs have only one-way significance, as described in Section 2.2. Consequently, NATs and firewalls can observe the SPI values of outgoing packets, but they cannot learn the SPI values of the corresponding inbound return traffic in the same way. Two methods exist:
IPsec SPI只有单向意义，如第2.2节所述。因此，NAT和防火墙可以观察传出数据包的SPI值，但不能以相同的方式了解相应入站返回流量的SPI值。存在两种方法：
First, NATs can observe the HIP base exchange and learn the SPI values that HIP peers agree to use. Afterwards, NATs can map outgoing and incoming IPsec flows accordingly. This approach is called architectured NAT, or SPINAT [YLITALO], and can be used by firewalls as well. It requires HIP-specific NAT modifications.
首先，NAT可以观察髋关节基底交换，并了解髋关节同伴同意使用的SPI值。之后，NAT可以相应地映射传出和传入的IPsec流。这种方法称为体系结构NAT，或SPINAT[YLITALO]，也可用于防火墙。它需要髋关节特定的NAT修改。
Second, HIP peers can use a generic NAT or firewall signaling protocol to explicitly signal appropriate SPI values to their NATs and firewalls. This approach does not require HIP-specific changes at the middlebox, but does require integration of HIP with the signaling protocol at the end systems.
第二，HIP对等方可以使用通用NAT或防火墙信令协议来显式地向其NAT和防火墙发送适当的SPI值信号。这种方法不需要在中间盒处进行特定于HIP的更改，但需要在终端系统处将HIP与信令协议集成。
Possible solutions for signaling SPI values are the mechanisms proposed in the IETF NSIS WG (NATFW NSLP) and MIDCOM MIB module [RFC5190]. Using MIDCOM in the context of HIP requires additional knowledge about network topology. For example, in multihomed environments with different border NATs or firewalls, a host must know which of the multiple NATs/firewalls to signal. Therefore, this solution can be problematic.
发送SPI值的可能解决方案是IETF NSIS WG（NATFW NSLP）和MIDCOM MIB模块[RFC5190]中提出的机制。在HIP环境中使用MIDCOM需要更多关于网络拓扑的知识。例如，在具有不同边界NAT或防火墙的多宿主环境中，主机必须知道向多个NAT/防火墙中的哪一个发送信号。因此，此解决方案可能存在问题。
By using the NSIS NAT/FW traversal (NATFW NSLP) mechanism HIP nodes can signal the used SPI values for both directions. NATFW NSLP ensures that signaling messages will reach all NATs and firewalls along the data path (path-coupled signaling). Although NSIS is generally supported at both peers, the NATFW NSLP offers a "proxy mode" for scenarios where only one end supports NSIS. This has deployment advantages.
通过使用NSIS NAT/FW遍历（NATFW NSLP）机制，HIP节点可以向两个方向发送所用SPI值的信号。NATFW NSLP确保信令消息将沿着数据路径（路径耦合信令）到达所有NAT和防火墙。虽然NSIS通常在两个对等点都受支持，但NATFW NSLP为只有一端支持NSI的场景提供了“代理模式”。这具有部署优势。
The solutions outlined in Section 5 require that NATs and firewalls are updated to support new functions, such as HIP itself or NSIS NATFW signaling. NATs and firewalls are already widely deployed. It will be impossible to upgrade or replace all such middleboxes with HIP support. This section explores how HIP operates in the presence of legacy NATs and firewalls that are not HIP-aware. Because the vast majority of deployed NATs currently support IPv4 only, this section focuses on them.
第5节中概述的解决方案要求更新NAT和防火墙以支持新功能，如HIP本身或NSIS NATFW信令。NAT和防火墙已经广泛部署。不可能升级或更换所有具有臀部支撑的此类中间盒。本节探讨HIP如何在存在不支持HIP的传统NAT和防火墙的情况下运行。由于绝大多数已部署的NAT目前仅支持IPv4，因此本节将重点介绍它们。
For HIP over IPv4, UDP encapsulation of HIP traffic already solves some NAT traversal issues. Usually, UDP packets can traverse NATs and firewalls when communication was initiated from the inside. However, traffic initiated outside a NAT is typically dropped, because it cannot be demultiplexed to the final destination (for NATs) or is prohibited by policy (for firewalls).
对于IPv4上的HIP，HIP流量的UDP封装已经解决了一些NAT穿越问题。通常，当从内部启动通信时，UDP数据包可以穿越NAT和防火墙。但是，在NAT之外发起的流量通常会被丢弃，因为它不能被解复用到最终目的地（对于NAT）或被策略禁止（对于防火墙）。
Even when UDP encapsulation enables the HIP base exchange to succeed, ESP still causes problems [RFC3715]. Some NAT implementations offer "VPN pass-through", where the NAT learns about IPsec flows and tries to correlate outgoing and incoming SPI values. This often works reliably only for a small number of nodes behind a single NAT, due to the possibility of SPI collisions.
即使UDP封装使HIP-base交换成功，ESP仍然会导致问题[RFC3715]。一些NAT实现提供“VPN直通”，其中NAT了解IPsec流并尝试关联传出和传入的SPI值。由于SPI冲突的可能性，这通常只对单个NAT后面的少量节点可靠工作。
A better solution may be to use UDP encapsulation for ESP [RFC3948], enabled through a new parameter in the base exchange. It is for further study whether to mandate UDP encapsulation for all HIP traffic to reduce the complexity of the protocol.
更好的解决方案可能是对ESP[RFC3948]使用UDP封装，通过基本交换中的新参数启用。是否对所有HIP流量强制进行UDP封装以降低协议的复杂性还有待进一步研究。
HIP may also consider other NAT/firewall traversal mechanisms, such as the widely deployed Universal Plug and Play (UPNP) [UPNP]. UPNP can be used to configure middleboxes on the same link as a HIP node.
HIP还可以考虑其他NAT /防火墙遍历机制，例如广泛部署的通用即插即用（UPnP）[UPnP]。UPNP可用于在与HIP节点相同的链路上配置中间盒。
This document focuses on NAT and firewall middleboxes and does not discuss other types identified in [RFC3234]. NATs and firewalls are the most frequently deployed middleboxes at the time of writing. However, future versions of this document may describe how HIP interacts with other types of middleboxes.
本文档重点介绍NAT和防火墙中间盒，不讨论[RFC3234]中确定的其他类型。在撰写本文时，NAT和防火墙是部署最频繁的中间包。然而，本文档的未来版本可能会描述HIP如何与其他类型的中间盒交互。
Opening pinholes in firewalls (i.e., loading firewall rules allowing packets to traverse) and creating NAT bindings are highly security-sensitive actions. Any mechanism that does so in order to support HIP traversal across middleboxes should be well protected. Detailed discussion of the related security issues can be found in the security considerations sections of the corresponding standards documents, such as [RFC3715] and [RFC5190].
在防火墙中打开针孔（即加载允许数据包遍历的防火墙规则）和创建NAT绑定是高度安全敏感的操作。任何这样做的机制都应该得到很好的保护，以支持跨中间盒的髋部横向移动。相关安全问题的详细讨论见相应标准文件的安全注意事项部分，如[RFC3715]和[RFC5190]。
This document has not considered whether some of the options listed above pose additional threats to security of the HIP protocol itself.
本文件未考虑上述某些选项是否对HIP协议本身的安全构成额外威胁。
The following people have helped to improve this document through thoughtful suggestions and feedback: Pekka Nikander, Tom Henderson, and the HIP research group. The authors would like to thank the final reviewers, Kevin Fall, Mark Allman, and Karen Sollins.
以下人员通过深思熟虑的建议和反馈帮助改进了本文件：Pekka Nikander、Tom Henderson和HIP研究小组。作者要感谢最终的评论员凯文·法尔、马克·奥尔曼和凯伦·索林斯。
Lars Eggert and Martin Stiemerling are partly funded by Ambient Networks, a research project supported by the European Commission under its Sixth Framework Program. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the Ambient Networks project or the European Commission.
拉尔斯·艾格特（Lars Eggert）和马丁·斯蒂梅林（Martin Stiemerling）的部分资金来自Ambient Networks，这是一个由欧盟委员会根据其第六个框架计划支持的研究项目。本文中包含的观点和结论是作者的观点和结论，不应被解释为必然代表Ambient Networks项目或欧盟委员会的官方政策或认可（无论明示或暗示）。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663]Srisuresh，P.和M.Holdrege，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，1999年8月。
[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月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4423]Moskowitz，R.和P.Nikander，“主机身份协议（HIP）体系结构”，RFC 4423，2006年5月。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201]Moskowitz，R.，Nikander，P.，Jokela，P.，Ed.，和T.Henderson，“主机身份协议”，RFC 52012008年4月。
[NIKANDER] Nikander, P., Ylitalo, J., and J. Wall, "Integrating Security, Mobility, and Multi-Homing in a HIP Way", Proc. Network and Distributed Systems Security Symposium (NDSS) 2003, February 2003.
[NIKANDER]NIKANDER，P.，Ylitalo，J.，和J.Wall，“以一种时髦的方式集成安全性、移动性和多主”，Proc。2003年网络和分布式系统安全研讨会（NDSS），2003年2月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC3234]Carpenter，B.和S.Brim，“中间盒：分类和问题”，RFC 32342002年2月。
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003.
[RFC3489]Rosenberg，J.，Weinberger，J.，Huitema，C.，和R.Mahy，“STUN-通过网络地址转换器（NAT）简单遍历用户数据报协议（UDP）”，RFC 3489，2003年3月。
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC3715]Aboba，B.和W.Dixon，“IPsec网络地址转换（NAT）兼容性要求”，RFC 3715，2004年3月。
[RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework", RFC 4091, June 2005.
[RFC4091]Camarillo，G.和J.Rosenberg，“会话描述协议（SDP）分组框架的替代网络地址类型（ANAT）语义”，RFC 4091，2005年6月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC5190] Quittek, J., Stiemerling, M., and P. Srisuresh, "Definitions of Managed Objects for Middlebox Communication", RFC 5190, March 2008.
[RFC5190]Quitek，J.，Stieemering，M.，和P.Srisuresh，“用于中间箱通信的托管对象的定义”，RFC 51902008年3月。
[RFC5206] Henderson, T., Ed., "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008.
[RFC5206]Henderson，T.，Ed.“终端主机移动性和主机身份协议的多宿”，RFC 5206，2008年4月。
[UPNP] UPNP Web Site, "Universal Plug and Play Web Site", Web Site http://www.upnp.org/, July 2005.
[UPNP]UPNP网站，“通用即插即用网站”，网站http://www.upnp.org/，2005年7月。
[YLITALO] Ylitalo, J., Melen, J., Nikander, P., and V. Torvinen, "Re-Thinking Security in IP-Based Micro-Mobility", Proc. 7th Information Security Conference (ISC) 2004, September 2004.
[YLITALO]YLITALO，J.，Melen，J.，Nikander，P.，和V.Torvinen，“重新思考基于IP的微移动中的安全”，Proc。2004年第七届信息安全会议（ISC），2004年9月。
Authors' Addresses
作者地址
Martin Stiemerling NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany
Martin Stieemerling NEC欧洲有限公司Kurfuersten Anlage 36德国海德堡69115
Phone: +49 6221 4342 113
Fax: +49 6221 4342 155
EMail: stiemerling@nw.neclab.eu
URI: http://www.nw.neclab.eu/
Phone: +49 6221 4342 113
Fax: +49 6221 4342 155
EMail: stiemerling@nw.neclab.eu
URI: http://www.nw.neclab.eu/
Juergen Quittek NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany
Juergen Quittek NEC欧洲有限公司Kurfuersten Anlage 36德国海德堡69115
Phone: +49 6221 4342 115
Fax: +49 6221 4342 155
EMail: quittek@nw.neclab.eu
URI: http://www.nw.neclab.eu/
Phone: +49 6221 4342 115
Fax: +49 6221 4342 155
EMail: quittek@nw.neclab.eu
URI: http://www.nw.neclab.eu/
Lars Eggert Nokia Research Center P.O. Box 407 Nokia Group 00045 Finland
芬兰诺基亚集团00045诺基亚研究中心邮政信箱407
Phone: +358 50 48 24461
EMail: lars.eggert@nokia.com
URI: http://research.nokia.com/people/lars_eggert/
Phone: +358 50 48 24461
EMail: lars.eggert@nokia.com
URI: http://research.nokia.com/people/lars_eggert/
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at http://www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78和http://www.rfc-editor.org/copyright.html，除本协议另有规定外，提交人保留其所有权利。
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.