Internet Engineering Task Force (IETF) G. Camarillo
Request for Comments: 6079 P. Nikander
Category: Experimental J. Hautakorpi
ISSN: 2070-1721 A. Keranen
Ericsson
A. Johnston
Avaya
January 2011
Internet Engineering Task Force (IETF) G. Camarillo
Request for Comments: 6079 P. Nikander
Category: Experimental J. Hautakorpi
ISSN: 2070-1721 A. Keranen
Ericsson
A. Johnston
Avaya
January 2011
HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment (BONE)
HIP-BONE：基于主机身份协议（HIP）的覆盖网络环境（BONE）
Abstract
摘要
This document specifies a framework to build HIP-based (Host Identity Protocol) overlay networks. This framework uses HIP to perform connection management. Other functions, such as data storage and retrieval or overlay maintenance, are implemented using protocols other than HIP. These protocols are loosely referred to as "peer protocols".
本文档指定了构建基于HIP（主机标识协议）的覆盖网络的框架。此框架使用HIP执行连接管理。其他功能，如数据存储和检索或覆盖维护，使用HIP以外的协议实现。这些协议松散地称为“对等协议”。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6079.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6079.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Background on HIP ...............................................4
3.1. ID/Locator Split ...........................................4
3.1.1. Identifier Format ...................................5
3.1.2. HIP Base Exchange ...................................5
3.1.3. Locator Management ..................................6
3.2. NAT Traversal ..............................................6
3.3. Security ...................................................7
3.3.1. DoS Protection ......................................7
3.3.2. Identifier Assignment and Authentication ............7
3.3.3. Connection Security .................................9
3.4. HIP Deployability and Legacy Applications ..................9
4. Framework Overview .............................................10
5. The HIP BONE Framework .........................................13
5.1. Node ID Assignment and Bootstrap ..........................13
5.2. Overlay Network Identification ............................14
5.3. Connection Establishment ..................................15
5.4. Lightweight Message Exchanges .............................15
5.5. HIP BONE Instantiation ....................................16
6. Overlay HIP Parameters .........................................17
6.1. Overlay Identifier ........................................17
6.2. Overlay TTL ...............................................17
7. Security Considerations ........................................18
8. Acknowledgements ...............................................19
9. IANA Considerations ............................................19
10. References ....................................................19
10.1. Normative References .....................................19
10.2. Informative References ...................................20
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Background on HIP ...............................................4
3.1. ID/Locator Split ...........................................4
3.1.1. Identifier Format ...................................5
3.1.2. HIP Base Exchange ...................................5
3.1.3. Locator Management ..................................6
3.2. NAT Traversal ..............................................6
3.3. Security ...................................................7
3.3.1. DoS Protection ......................................7
3.3.2. Identifier Assignment and Authentication ............7
3.3.3. Connection Security .................................9
3.4. HIP Deployability and Legacy Applications ..................9
4. Framework Overview .............................................10
5. The HIP BONE Framework .........................................13
5.1. Node ID Assignment and Bootstrap ..........................13
5.2. Overlay Network Identification ............................14
5.3. Connection Establishment ..................................15
5.4. Lightweight Message Exchanges .............................15
5.5. HIP BONE Instantiation ....................................16
6. Overlay HIP Parameters .........................................17
6.1. Overlay Identifier ........................................17
6.2. Overlay TTL ...............................................17
7. Security Considerations ........................................18
8. Acknowledgements ...............................................19
9. IANA Considerations ............................................19
10. References ....................................................19
10.1. Normative References .....................................19
10.2. Informative References ...................................20
The Host Identity Protocol (HIP) [RFC5201] defines a new name space between the network and transport layers. HIP provides upper layers with mobility, multihoming, NAT (Network Address Translation) traversal, and security functionality. HIP implements the so-called identifier/locator (ID/locator) split, which implies that IP addresses are only used as locators, not as host identifiers. This split makes HIP a suitable protocol to build overlay networks that implement identifier-based overlay routing over IP networks, which in turn implement locator-based routing.
主机标识协议（HIP）[RFC5201]在网络和传输层之间定义了一个新的名称空间。HIP为上层提供了移动性、多归属、NAT（网络地址转换）遍历和安全功能。HIP实现了所谓的标识符/定位器（ID/locator）拆分，这意味着IP地址仅用作定位器，而不是主机标识符。这种分离使HIP成为构建覆盖网络的合适协议，该覆盖网络在IP网络上实现基于标识符的覆盖路由，而IP网络又实现基于定位器的路由。
Using HIP-Based Overlay Networking Environment (HIP BONE), as opposed to a peer protocol, to perform connection management in an overlay has a set of advantages. HIP BONE can be used by any peer protocol. This keeps each peer protocol from defining primitives needed for connection management (e.g., primitives to establish connections and to tunnel messages through the overlay) and NAT traversal. Having this functionality at a lower layer allows multiple upper-layer protocols to take advantage of it.
使用基于HIP的覆盖网络环境（HIP-BONE）与对等协议相反，在覆盖中执行连接管理具有一系列优点。髋骨可由任何对等协议使用。这使得每个对等协议不必定义连接管理所需的原语（例如，用于建立连接和通过覆盖层隧道消息的原语）和NAT遍历。在较低层拥有此功能允许多个上层协议利用它。
Additionally, having a solution that integrates mobility and multihoming is useful in many scenarios. Peer protocols do not typically specify mobility and multihoming solutions. Combining a peer protocol including NAT traversal with a separate mobility mechanism and a separate multihoming mechanism can easily lead to unexpected (and unpleasant) interactions.
此外，拥有一个集成移动性和多宿的解决方案在许多场景中都很有用。对等协议通常不指定移动性和多归属解决方案。将包括NAT遍历的对等协议与单独的移动机制和单独的多主机制相结合，很容易导致意外（和不愉快）的交互。
The remainder of this document is organized as follows. Section 3 provides background information on HIP. Section 4 gives an overview of the HIP BONE (HIP-Based Overlay Networking Environment) framework and architecture and Section 5 describes the framework in more detail. Finally, Section 6 introduces new HIP parameters for overlay usage.
本文件的其余部分组织如下。第3节提供了HIP的背景信息。第4节概述了HIP-BONE（基于HIP的覆盖网络环境）框架和体系结构，第5节更详细地描述了该框架。最后，第6节介绍了叠加使用的新HIP参数。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The following terms are used in context of HIP BONEs:
以下术语用于髋骨的上下文：
Overlay network: A network built on top of another network. In case of HIP BONEs, the underlying network is an IP network and the overlay can be, e.g., a peer-to-peer (P2P) network.
覆盖网络：建立在另一个网络之上的网络。在髋骨的情况下，底层网络是IP网络，覆盖可以是，例如，对等（P2P）网络。
Peer protocol: A protocol used by nodes in an overlay network for performing, e.g., data storage and retrieval or overlay maintenance.
对等协议：覆盖网络中节点用于执行数据存储和检索或覆盖维护等操作的协议。
HIP BONE instance: A HIP-based overlay network that uses a particular peer protocol and is based on the framework presented in this document.
HIP-BONE实例：一个基于HIP的覆盖网络，使用特定的对等协议，并基于本文中介绍的框架。
Node ID: A value that uniquely identifies a node in an overlay network. The value is not usually human-friendly. As an example, it may be a hash of a public key.
节点ID：唯一标识覆盖网络中节点的值。这种价值观通常不利于人类。例如，它可以是公钥的散列。
HIP association: An IP-layer communications context created using the Host Identity Protocol.
HIP关联：使用主机标识协议创建的IP层通信上下文。
Valid locator: A locator (as defined in [RFC5206]; usually an IP address or an address and a port number) at which a host is known to be reachable, for example, because there is an active HIP association with the host.
有效定位器：一种定位器（如[RFC5206]中所定义；通常是IP地址或地址和端口号），在该定位器处可以访问主机，例如，因为主机存在活动的HIP关联。
Final recipient: A node is the final recipient of a HIP signaling packet if one of its Host Identity Tags (HITs) matches to the receiver's HIT in the HIP packet header.
最终接收者：如果某个节点的主机标识标签（HITs）与HIP数据包头中的接收者HIT匹配，则该节点是HIP信令数据包的最终接收者。
This section provides background on HIP. Given the tutorial nature of this section, readers that are familiar with what HIP provides and how HIP works may want to skip it. All descriptions contain references to the relevant HIP specifications where readers can find detailed explanations on the different topics discussed in this section.
本节提供有关HIP的背景知识。鉴于本节的教程性质，熟悉HIP提供了什么以及HIP如何工作的读者可能希望跳过本节。所有说明都包含相关HIP规范的参考，读者可以在其中找到本节中讨论的不同主题的详细说明。
In an IP network, IP addresses typically serve two roles: they are used as host identifiers and as host locators. IP addresses are locators because a given host's IP address indicates where in the network that host is located. IP networks route based on these locators. Additionally, IP addresses are used to identify remote hosts. The simultaneous use of IP addresses as host identifiers and locators makes mobility and multihoming complicated. For example, when a host opens a TCP connection, the host identifies the remote end of the connection by the remote IP address (plus port). If the remote host changes its IP address, the TCP connection will not survive, since the transport layer identifier of the remote end of the connection has changed.
在IP网络中，IP地址通常扮演两个角色：它们用作主机标识符和主机定位器。IP地址是定位器，因为给定主机的IP地址指示该主机在网络中的位置。IP网络基于这些定位器进行路由。此外，IP地址用于标识远程主机。同时使用IP地址作为主机标识符和定位器使得移动性和多归属变得复杂。例如，当主机打开TCP连接时，主机通过远程IP地址（加上端口）标识连接的远程端。如果远程主机更改其IP地址，TCP连接将无法继续，因为连接远程端的传输层标识符已更改。
Mobility solutions such as Mobile IP keep the remote IP address from changing so that it can still be used as an identifier. HIP, on the other hand, uses IP addresses only as locators and defines a new identifier space. This approach is referred to as the ID/locator split and makes the implementation of mobility and multihoming more natural. In the previous example, the TCP connection would be bound to the remote host's identifier, which would not change when the remote hosts moves to a new IP address (i.e., to a new locator). The TCP connection is able to survive locator changes because the remote host's identifier does not change.
移动IP等移动解决方案可防止远程IP地址发生变化，从而使其仍可用作标识符。另一方面，HIP仅将IP地址用作定位器，并定义新的标识符空间。这种方法被称为ID/定位器分离，使移动性和多宿的实现更加自然。在前面的示例中，TCP连接将绑定到远程主机的标识符，当远程主机移动到新的IP地址（即，移动到新的定位器）时，该标识符不会改变。由于远程主机的标识符没有更改，TCP连接能够在定位器更改后继续存在。
HIP uses 128-bit ORCHIDs (Overlay Routable Cryptographic Hash Identifiers) [RFC4843] as identifiers. ORCHIDs look like IPv6 addresses but cannot collide with regular IPv6 addresses because ORCHID spaces are registered with the IANA. That is, a portion of the IPv6 address space is reserved for ORCHIDs. The ORCHID specification allows the creation of multiple disjoint identifier spaces. Each such space is identified by a separate Context Identifier. The Context Identifier can be either drawn implicitly from the context the ORCHID is used in or carried explicitly in a protocol.
HIP使用128位兰花（覆盖可路由加密哈希标识符）[RFC4843]作为标识符。兰花看起来像IPv6地址，但不能与常规IPv6地址冲突，因为兰花空间是向IANA注册的。也就是说，IPv6地址空间的一部分是为兰花保留的。兰花规范允许创建多个不相交的标识符空间。每个这样的空间由单独的上下文标识符标识。上下文标识符可以从协议中使用的或显式携带的兰花上下文中隐式提取。
HIP defines a native socket API [HIP-NATIVE-API] that applications can use to establish and manage connections. Additionally, HIP can also be used through the traditional IPv4 and IPv6 TCP/IP socket APIs. Section 3.4 describes how an application using these traditional APIs can make use of HIP. Figure 1 shows all these APIs between the application and the transport layers.
HIP定义了一个本机套接字API[HIP-native-API]，应用程序可以使用它来建立和管理连接。此外，还可以通过传统的IPv4和IPv6 TCP/IP套接字API使用HIP。第3.4节描述了使用这些传统API的应用程序如何利用HIP。图1显示了应用程序和传输层之间的所有这些API。
+-----------------------------------------+
| Application |
+----------------+------------------------+
| HIP Native API | Traditional Socket API |
+----------------+------------------------+
| Transport Layer |
+-----------------------------------------+
+-----------------------------------------+
| Application |
+----------------+------------------------+
| HIP Native API | Traditional Socket API |
+----------------+------------------------+
| Transport Layer |
+-----------------------------------------+
Figure 1: HIP API
图1：HIP API
Typically, before two HIP hosts exchange upper-layer traffic, they perform a four-way handshake that is referred to as the HIP base exchange. Figure 2 illustrates the HIP base exchange. The initiator
通常，在两个HIP主机交换上层通信量之前，它们执行称为HIP基础交换的四向握手。图2显示了髋关节-基底的交换。发起者
sends an I1 packet and receives an R1 packet from the responder. After that, the initiator sends an I2 packet and receives an R2 packet from the responder.
发送I1数据包，并从响应程序接收R1数据包。之后，发起方发送I2数据包，并从响应方接收R2数据包。
Initiator Responder
发起者响应者
| I1 |
|-------------------------->|
| R1 |
|<--------------------------|
| I2 |
|-------------------------->|
| R2 |
|<--------------------------|
| I1 |
|-------------------------->|
| R1 |
|<--------------------------|
| I2 |
|-------------------------->|
| R2 |
|<--------------------------|
Figure 2: HIP Base Exchange
图2：髋关节置换
Of course, the initiator needs the responder's locator (or locators) in order to send its I1 packet. The initiator can obtain locators for the responder in multiple ways. For example, according to the current HIP specifications the initiator can get the locators directly from the DNS [RFC5205] or indirectly by sending packets through a HIP rendezvous server [RFC5204]. However, HIP is an open-ended architecture. The HIP architecture allows the locators to be obtained by any means (e.g., from packets traversing an overlay network or as part of the candidate address collection process in a NAT traversal scenario).
当然，发起者需要响应者的定位器才能发送其I1数据包。发起者可以通过多种方式获取响应者的定位器。例如，根据当前的HIP规范，发起方可以直接从DNS[RFC5205]获取定位器，或者通过HIP会合服务器[RFC5204]发送数据包间接获取定位器。然而，HIP是一种开放式架构。HIP体系结构允许通过任何方式获得定位器（例如，从穿越覆盖网络的分组或作为NAT穿越场景中的候选地址收集过程的一部分）。
Once a HIP connection between two hosts has been established with a HIP base exchange, the hosts can start exchanging higher-layer traffic. If any of the hosts changes its set of locators, it runs an update exchange [RFC5206], which consists of three messages. If a host is multihomed, it simply provides more than one locator in its exchanges. However, if both of the endpoints move at the same time, or through some other reason both lose track of the peers' currently active locators, they need to resort to using a rendezvous server or getting new peer locators by some other means.
一旦通过HIP-base交换在两台主机之间建立了HIP连接，主机就可以开始交换更高层的流量。如果任何主机更改其定位器集，它将运行更新交换[RFC5206]，其中包括三条消息。如果主机是多址的，它只需在其交换中提供多个定位器。但是，如果两个端点同时移动，或者由于某些其他原因都无法跟踪对等方当前活动的定位器，则它们需要使用集合服务器或通过其他方式获取新的对等方定位器。
HIP's NAT traversal mechanism [RFC5770] is based on ICE (Interactive Connectivity Establishment) [RFC5245]. Hosts gather address candidates and, as part of the HIP base exchange, hosts perform an ICE offer/answer exchange where they exchange their respective
HIP的NAT遍历机制[RFC5770]基于ICE（交互式连接建立）[RFC5245]。主持人收集候选地址，作为HIP base交换的一部分，主持人执行ICE提供/回答交换，在这里他们交换各自的地址
address candidates. Hosts perform end-to-end STUN-based [RFC5389] connectivity checks in order to discover which address candidate pairs yield connectivity.
向候选人讲话。主机执行端到端基于STUN的[RFC5389]连接检查，以发现哪些地址候选对产生连接。
Even though, architecturally, HIP lies below the transport layer (i.e., HIP packets are carried directly in IP packets), in the presence of NATs, HIP sometimes needs to be tunneled in a transport protocol (i.e., HIP packets are carried by a transport protocol such as UDP).
即使在体系结构上，HIP位于传输层之下（即，HIP数据包直接在IP数据包中承载），在存在NAT的情况下，HIP有时需要在传输协议中进行隧道传输（即，HIP数据包由传输协议（如UDP）承载）。
Security is an essential part of HIP. The following sections describe the security-related functionality provided by HIP.
安全是HIP的重要组成部分。以下各节介绍HIP提供的安全相关功能。
HIP provides protection against DoS (denial-of-service) attacks by having initiators resolve a cryptographic puzzle before the responder stores any state. On receiving an I1 packet, a responder sends a pre-generated R1 packet that contains a cryptographic puzzle and deletes all the state associated with the processing of this I1 packet. The initiator needs to resolve the puzzle in the R1 packet in order to generate an I2 packet. The difficulty of the puzzle can be adjusted so that, if a receiver is under a DoS attack, it can increase the difficulty of its puzzles.
HIP通过让发起方在响应方存储任何状态之前解决加密难题，从而提供针对DoS（拒绝服务）攻击的保护。在接收到I1数据包时，响应者发送预生成的R1数据包，该数据包包含加密谜题，并删除与处理该I1数据包相关的所有状态。发起方需要解决R1数据包中的难题，以便生成I2数据包。谜题的难度可以调整，因此，如果接收者受到拒绝服务攻击，它可以增加谜题的难度。
On receiving an I2 packet, a receiver checks that the solution in the packet corresponds to a puzzle generated by the receiver and that the solution is correct. If it is, the receiver processes the I2 packet. Otherwise, it silently discards it.
在接收到I2数据包时，接收器检查数据包中的解决方案是否对应于接收器生成的谜题，以及解决方案是否正确。如果是，则接收器处理I2分组。否则，它会默默地丢弃它。
In an overlay scenario, there are multiple ways in which this mechanism can be utilized within the overlay. One possibility is to cache the pre-generated R1 packets within the overlay and let the overlay directly respond with R1s to I1s. In that way, the responder is not bothered at all until the initiator sends an I2 packet, with the puzzle solution. Furthermore, a more sophisticated overlay could verify that an I2 packet has a correctly solved puzzle before forwarding the packet to the responder.
在覆盖场景中，可以通过多种方式在覆盖中使用此机制。一种可能性是在覆盖内缓存预生成的R1数据包，并让覆盖直接用R1s响应I1s。这样，在发起方发送I2数据包和谜题解决方案之前，响应方根本不会感到麻烦。此外，更复杂的覆盖可以在将数据包转发给响应者之前验证I2数据包是否具有正确解决的谜题。
As discussed earlier, HIP uses ORCHIDs [RFC4843] as the main representation for identifiers. Potentially, HIP can use different types of ORCHIDs as long as the probability of finding collisions (i.e., two nodes with the same ORCHID) is low enough. One way to completely avoid this type of collision is to have a central
如前所述，HIP使用兰花[RFC4843]作为标识符的主要表示形式。HIP可能会使用不同类型的兰花，只要发现碰撞的概率足够低（即，两个节点具有相同的兰花）。完全避免这种类型碰撞的一种方法是设置一个中心点
authority generate and assign ORCHIDs to nodes. To secure the binding between ORCHIDs and any higher-layer identifiers, every time the central authority assigns an ORCHID to a node, it also generates and signs a certificate stating who is the owner of the ORCHID. The owner of the ORCHID then includes the corresponding certificate in its R1 (when acting as responder) and I2 packets (when acting initiator) to prove that it is actually allowed to use the ORCHID and, implicitly, the associated public key.
权限生成兰花并将其分配给节点。为了确保兰花与任何更高层标识符之间的绑定，每次中央机构将兰花分配给节点时，它还生成并签署一份证书，说明谁是兰花的所有者。然后，兰花的所有者在其R1（当充当响应者时）和I2数据包（当充当发起者时）中包含相应的证书，以证明它实际上被允许使用兰花，并且隐式地使用相关的公钥。
Having a central authority works well to completely avoid collisions. However, having a central authority is impractical in some scenarios. As defined today, HIP systems generally use a self-certifying ORCHID type called HIT (Host Identity Tag) that does not require a central authority (but still allows one to be used).
有一个中央机构可以很好地避免冲突。然而，在某些情况下，拥有一个中央权力机构是不切实际的。正如今天所定义的，HIP系统通常使用一种称为HIT（主机标识标签）的自认证兰花类型，它不需要中央授权（但仍然允许使用）。
A HIT is the hash of a node's public key. A node proves that it has the right to use a HIT by showing its ability to sign data with its associated private key. This scheme is secure due to the so-called second-preimage resistance property of hash functions. That is, given a fixed public key K1, finding a different public key K2 such that hash(K1) = hash(K2) is computationally very hard. Optimally, a preimage attack on the 100-bit hash function used in ORCHIDs will take an order of 2^100 operations to be successful, and can be expected to take in the average 2^99 operations. Given that each operation requires the attacker to generate a new key pair, the attack is fully impractical with current technology and techniques (see [RFC4843]).
命中是节点公钥的散列。节点通过显示其使用相关私钥对数据签名的能力来证明其有权使用HIT。由于散列函数的所谓第二预映像抵抗特性，该方案是安全的。也就是说，给定固定公钥K1，查找不同的公钥K2使得散列（K1）=散列（K2）在计算上非常困难。最理想的情况是，对兰花中使用的100位哈希函数进行预映像攻击需要2^100次操作才能成功，并且平均需要2^99次操作。鉴于每个操作都需要攻击者生成一个新的密钥对，因此在当前的技术和技术中，这种攻击是完全不切实际的（请参见[RFC4843]）。
HIP nodes using HITs as ORCHIDs do not typically use certificates during their base exchanges. Instead, they use a leap-of-faith mechanism, similar to the Secure Shell (SSH) protocol [RFC4251], whereby a node somehow authenticates remote nodes the first time they connect to it and, then, remembers their public keys. While user-assisted leap-of-faith mechanism (such as in SSH) can be used to facilitate a human-operated offline path (such as a telephone call), automated leap-of-faith mechanisms can be combined with a reputation management system to create an incentive to behave. However, such considerations go well beyond the current HIP architecture and even beyond this proposal. For the purposes of the present document, we merely want to point out that, architecturally, HIP supports both self-generated opportunistic identifiers and administratively assigned ones.
HIP节点使用HITs作为兰花，在其基础交换期间通常不使用证书。相反，它们使用了一种信任跳跃机制，类似于安全外壳（SSH）协议[RFC4251]，节点在第一次连接到远程节点时以某种方式对其进行身份验证，然后记住它们的公钥。虽然用户辅助的信任跳跃机制（如SSH）可用于促进人工操作的离线路径（如电话），但自动化的信任跳跃机制可与声誉管理系统相结合，以产生行为激励。然而，这些考虑远远超出了当前的HIP架构，甚至超出了本提案的范围。为了本文件的目的，我们只想指出，在体系结构上，HIP支持自生成的机会主义标识符和管理分配的标识符。
Once two nodes complete a base exchange between them, the traffic they exchange is encrypted and integrity protected. The security mechanism used to protect the traffic is IPsec Encapsulating Security Payload (ESP) [RFC5202]. However, there is ongoing work to specify how to use other protection mechanisms.
一旦两个节点完成它们之间的基本交换，它们交换的流量将被加密并受到完整性保护。用于保护流量的安全机制是IPsec封装安全负载（ESP）[RFC5202]。然而，目前正在开展工作，以具体说明如何使用其他保护机制。
As discussed earlier, HIP defines a native socket API [HIP-NATIVE-API] that applications can use to establish and manage connections. New applications can implement this API to get full advantage of HIP. However, in most cases, legacy (i.e., non-HIP-aware) applications [RFC5338] can use HIP through the traditional IPv4 and IPv6 socket APIs.
如前所述，HIP定义了一个本机套接字API[HIP-native-API]，应用程序可以使用它来建立和管理连接。新的应用程序可以实现此API以充分利用HIP。然而，在大多数情况下，遗留（即，非HIP感知）应用程序[RFC5338]可以通过传统的IPv4和IPv6套接字API使用HIP。
The idea is that when a legacy IPv6 application tries to obtain a remote host's IP address (e.g., by querying the DNS), the DNS resolver passes the remote host's ORCHID (which was also stored in the DNS) to the legacy application. At the same time, the DNS resolver stores the remote host's IP address internally at the HIP module. Since the ORCHID looks like an IPv6 address, the legacy application treats it as such. It opens a connection (e.g., TCP) using the traditional IPv6 socket API. The HIP module running in the same host as the legacy application intercepts this call somehow (e.g., using an interception library or setting up the host's routing tables so that the HIP module receives the traffic) and runs HIP (on behalf of the legacy application) towards the IP address corresponding to the ORCHID. This mechanism works well in almost all cases. However, applications involving referrals (i.e., passing of IPv6 addresses between applications) present issues, which are discussed in Section 5 below. Additionally, management applications that care about the exact IP address format may not work well with such a straightforward approach.
其思想是，当传统IPv6应用程序尝试获取远程主机的IP地址（例如，通过查询DNS）时，DNS解析器将远程主机的兰花（也存储在DNS中）传递给传统应用程序。同时，DNS解析程序在HIP模块内部存储远程主机的IP地址。因为兰花看起来像一个IPv6地址，所以遗留应用程序将其视为IPv6地址。它使用传统的IPv6套接字API打开连接（例如TCP）。与遗留应用程序在同一主机上运行的HIP模块以某种方式截获该调用（例如，使用截取库或设置主机的路由表，以便HIP模块接收流量），并（代表遗留应用程序）向对应于兰花的IP地址运行HIP。这种机制在几乎所有情况下都很有效。但是，涉及转介的应用程序（即，在应用程序之间传递IPv6地址）存在问题，这些问题将在下面的第5节中讨论。此外，关心确切IP地址格式的管理应用程序可能无法很好地使用这种简单的方法。
In order to make HIP work through the traditional IPv4 socket API, the HIP module passes an LSI (Local Scope Identifier), instead of a regular IPv4 address, to the legacy IPv4 application. The LSI looks like an IPv4 address, but is locally bound to an ORCHID. That is, when the legacy application uses the LSI in a socket call, the HIP module intercepts it and replaces the LSI with its corresponding ORCHID. Therefore, LSIs always have local scope. They do not have any meaning outside the host running the application. The ORCHID is used on the wire; not the LSI. In the referral case, if it is not possible to rewrite the application level packets to use ORCHIDs
为了使HIP通过传统的IPv4套接字API工作，HIP模块将LSI（本地作用域标识符）而不是常规IPv4地址传递给传统IPv4应用程序。LSI看起来像一个IPv4地址，但在本地绑定到一个兰花。也就是说，当遗留应用程序在套接字调用中使用LSI时，HIP模块将截取该LSI，并用其相应的RAPID替换该LSI。因此，LSI总是具有局部范围。它们在运行应用程序的主机之外没有任何意义。兰花是用在电线上的；不是LSI。在转介情况下，如果无法将应用程序级数据包重写为使用兰花
instead of LSIs, it may be hard to make IPv4 referrals work in Internet-wide settings. IPv4 LSIs have been successfully used in existing HIP deployments within a single corporate network.
代替LSI，可能很难使IPv4引用在Internet范围的设置中工作。IPv4 LSI已成功用于单个公司网络中的现有HIP部署。
The HIP BONE framework combines HIP with different peer protocols to provide robust and secure overlay network solutions.
HIP-BONE框架将HIP与不同的对等协议相结合，以提供健壮和安全的覆盖网络解决方案。
Many overlays typically require three types of operations:
许多叠加通常需要三种类型的操作：
o overlay maintenance, o data storage and retrieval, and o connection management.
o 覆盖维护、o数据存储和检索以及o连接管理。
Overlay maintenance operations deal with nodes joining and leaving the overlay and with the maintenance of the overlay's routing tables. Data storage and retrieval operations deal with nodes storing, retrieving, and removing information in or from the overlay. Connection management operations deal with the establishment of connections and the exchange of lightweight messages among the nodes of the overlay, potentially in the presence of NATs.
覆盖层维护操作处理加入和离开覆盖层的节点，以及覆盖层路由表的维护。数据存储和检索操作处理在覆盖中存储、检索和删除信息的节点。连接管理操作处理连接的建立和覆盖层节点之间的轻量级消息交换，可能存在NAT。
The HIP BONE framework uses HIP to perform connection management. Data storage and retrieval and overlay maintenance are to be implemented using protocols other than HIP. For lack of a better name, these protocols are referred to as peer protocols.
髋骨框架使用髋部执行连接管理。数据存储、检索和覆盖维护将使用HIP以外的协议实现。由于没有更好的名称，这些协议被称为对等协议。
One way to depict the relationship between the peer protocol and HIP modules is shown in Figure 3. The peer protocol module implements the overlay construction and maintenance features, and possibly storage (if the particular protocol supports such a feature). The HIP module consults the peer protocol's overlay topology part to make routing decisions, and the peer protocol uses HIP for connection management and sending peer protocol messages to other hosts. The HIP BONE API that applications use is a combination of the HIP Native API and traditional socket API (as shown in Figure 1) with any additional API a particular instance implementation provides.
图3显示了描述对等协议和HIP模块之间关系的一种方法。对等协议模块实现覆盖构造和维护功能，以及可能的存储（如果特定协议支持此类功能）。HIP模块参考对等协议的覆盖拓扑部分来做出路由决策，对等协议使用HIP进行连接管理并向其他主机发送对等协议消息。应用程序使用的HIP-BONE API是HIP原生API和传统套接字API（如图1所示）与特定实例实现提供的任何附加API的组合。
Application
-------------------------------- HIP BONE API
+---+ +--------------------+
| | | Peer Protocol |
| | +--------+ +---------+
| |<->|Topology| |(Storage)|
| | +---------+----------+
| | ^
| | v
| +------------------------+
| HIP |
+----------------------------+
Application
-------------------------------- HIP BONE API
+---+ +--------------------+
| | | Peer Protocol |
| | +--------+ +---------+
| |<->|Topology| |(Storage)|
| | +---------+----------+
| | ^
| | v
| +------------------------+
| HIP |
+----------------------------+
Figure 3: HIP with Peer Protocol
图3：采用对等协议的HIP
Architecturally, HIP can be considered to create a new thin "waist" layer on top of the IPv4 and IPv6 networks; see Figure 4. The HIP layer itself consists of the HIP signaling protocol and one or more data transport protocols; see Figure 5. The HIP signaling packets and the data transport packets can take different routes. In the HIP BONE scenarios, the HIP signaling packets are typically first routed through the overlay and then directly (if possible), while the data transport packets are typically routed only directly between the endpoints.
在架构上，HIP可以考虑在IPv4和IPv6网络之上创建一个新的薄“腰”层；参见图4。HIP层本身由HIP信令协议和一个或多个数据传输协议组成；参见图5。HIP信令分组和数据传输分组可以采用不同的路由。在髋骨场景中，髋部信令分组通常首先通过覆盖层路由，然后直接（如果可能的话）路由，而数据传输分组通常仅在端点之间直接路由。
+--------------------------------------+
| Transport (using HITs or LSIs) |
+--------------------------------------+
| HIP |
+------------------+-------------------+
| IPv4 | IPv6 |
+------------------+-------------------+
+--------------------------------------+
| Transport (using HITs or LSIs) |
+--------------------------------------+
| HIP |
+------------------+-------------------+
| IPv4 | IPv6 |
+------------------+-------------------+
Figure 4: HIP as a Thin Waist
图4：臀部作为细腰
+------------------+-------------------+
| HIP signaling | data transports |
+------------------+-------------------+
+------------------+-------------------+
| HIP signaling | data transports |
+------------------+-------------------+
Figure 5: HIP Layer Structure
图5:HIP层结构
In HIP BONE, the peer protocol creates a new signaling layer on top of HIP. It is used to set up forwarding paths for HIP signaling messages. This is a similar relationship that an IP routing protocol, such as OSPF, has to the IP protocol itself. In the HIP BONE case, the peer protocol plays a role similar to OSPF, and HIP plays a role similar to IP. The ORCHIDs (or, in general, Node IDs if the ORCHID prefix is not used) are used for forwarding HIP packets
在HIP BONE中，对等协议在HIP之上创建了一个新的信号层。它用于为HIP信令消息设置转发路径。这是IP路由协议（如OSPF）与IP协议本身的类似关系。在HIP-BONE案例中，对等协议扮演着类似于OSPF的角色，而HIP扮演着类似于IP的角色。兰花（或者，通常，如果没有使用兰花前缀，则为节点ID）用于转发HIP数据包
according to the information in the routing tables. The peer protocols are used to exchange routing information based on Node IDs and to construct the routing tables.
根据路由表中的信息。对等协议用于根据节点ID交换路由信息和构造路由表。
Architecturally, routing tables are located between the peer protocol and HIP, as shown in Figure 6. The peer protocol constructs the routing table and keeps it updated. The HIP layer accesses the routing table in order to make routing decisions. The bootstrap of a HIP BONE overlay does not create circular dependencies between the peer protocol (which needs to use HIP to establish connections with other nodes) and HIP (which needs the peer protocol to know how to route messages to other nodes) for the same reasons as the bootstrap of an IP network does not create circular dependencies between OSPF and IP. The first connections established by the peer protocol are with nodes whose locators are known. HIP establishes those connections as any connection between two HIP nodes where no overlays are present. That is, there is no need for the overlay to provide a rendezvous service for those connections.
架构上，路由表位于对等协议和HIP之间，如图6所示。对等协议构造路由表并保持更新。HIP层访问路由表以做出路由决策。髋骨覆盖的引导不会在对等协议（需要使用HIP与其他节点建立连接）和HIP（需要对等协议知道如何将消息路由到其他节点）之间创建循环依赖关系与IP网络的引导不会在OSPF和IP之间创建循环依赖项的原因相同。对等协议建立的第一个连接是与定位器已知的节点的连接。HIP将这些连接建立为不存在重叠的两个HIP节点之间的任何连接。也就是说，覆盖层不需要为这些连接提供会合服务。
+--------------------------------------+
| Peer protocol |
+--------------------------------------+
| Routing table |
+--------------------------------------+
| HIP |
+--------------------------------------+
+--------------------------------------+
| Peer protocol |
+--------------------------------------+
| Routing table |
+--------------------------------------+
| HIP |
+--------------------------------------+
Figure 6: Routing Tables
图6：路由表
It is possible that different overlays use different routing table formats. For example, the structure of the routing tables of two overlays based on different DHTs (Distributed Hash Tables) may be very different. In order to make routing decisions, the HIP layer needs to convert the routing table generated by the peer protocol into a forwarding table that allows the HIP layer select a next hop for any packet being routed.
不同的覆盖可能使用不同的路由表格式。例如，基于不同dht（分布式哈希表）的两个覆盖的路由表的结构可能非常不同。为了做出路由决策，HIP层需要将对等协议生成的路由表转换为转发表，该转发表允许HIP层为任何正在路由的数据包选择下一跳。
In HIP BONE, the HIP usage of public keys and deriving ORCHIDs through a hash function can be utilized at the peer protocol side to better secure routing table maintenance and to protect against chosen-peer-ID attacks.
在HIP-BONE中，可以在对等协议端利用公钥的HIP使用和通过哈希函数派生兰花，以更好地保护路由表维护，并防止所选对等ID攻击。
HIP BONE provides quite a lot of flexibility with regards to how to arrange the different protocols in detail. Figure 7 shows one potential stack structure.
髋骨在如何详细安排不同的协议方面提供了相当大的灵活性。图7显示了一种潜在的堆栈结构。
+-----------------------+--------------+
| peer protocols | media |
+------------------+----+--------------+
| HIP signaling | data transport |
| |
+------------------+-------------------+
| NAT | non-NAT | |
| | |
| IPv4 | IPv6 |
+------------------+-------------------+
+-----------------------+--------------+
| peer protocols | media |
+------------------+----+--------------+
| HIP signaling | data transport |
| |
+------------------+-------------------+
| NAT | non-NAT | |
| | |
| IPv4 | IPv6 |
+------------------+-------------------+
Figure 7: Example HIP BONE Stack Structure
图7：髋骨堆叠结构示例
HIP BONE is a generic framework that allows the use of different peer protocols. A particular HIP BONE instance uses a particular peer protocol. The details on how to implement HIP BONE using a given peer protocol need to be specified in a, so-called, HIP BONE instance specification. Section 5.5 discusses what details need to be specified by HIP BONE instance specifications. For example, the HIP BONE instance specification for RELOAD [P2PSIP-BASE] is specified in [HIP-RELOAD-INSTANCE].
HIP-BONE是一个通用框架，允许使用不同的对等协议。特定髋骨实例使用特定的对等协议。关于如何使用给定对等协议实现髋骨的详细信息需要在所谓的髋骨实例规范中指定。第5.5节讨论了髋骨实例规范需要指定的细节。例如，重新加载[P2PSIP-BASE]的髋骨实例规范在[HIP-RELOAD-instance]中指定。
Nodes in an overlay are primarily identified by their Node IDs. Overlays typically have an enrollment server that can generate Node IDs, or at least some part of the Node ID, and sign certificates. A certificate generated by an enrollment server authorizes a particular user to use a particular Node ID in a particular overlay. The way users are identified is defined by the peer protocol and HIP BONE instance specification.
覆盖中的节点主要由其节点ID标识。覆盖通常有一个注册服务器，可以生成节点ID或至少部分节点ID，并签署证书。注册服务器生成的证书授权特定用户在特定覆盖中使用特定节点ID。识别用户的方式由对等协议和髋骨实例规范定义。
The enrollment server of an overlay using HITs derived from public keys as Node IDs could just authorize users to use the public keys and HITs associated to their nodes. Such a Node ID has the same self-certifying property as HITs and the Node ID can also be used in the HIP and legacy APIs as an ORCHID. This works well as long as the enrollment server is the one generating the public/private key pairs for all those nodes. If the enrollment server authorizes users to use HITs that are generated directly by the nodes themselves, the system is open to a type of chosen-peer-ID attack.
使用从公钥派生的点击作为节点ID的覆盖注册服务器可以授权用户使用与其节点关联的公钥和点击。这样的节点ID具有与HITs相同的自认证属性，并且该节点ID还可以在HIP和遗留API中作为兰花使用。只要注册服务器是为所有这些节点生成公钥/私钥对的服务器，这种方法就可以正常工作。如果注册服务器授权用户使用由节点本身直接生成的点击，则系统会受到某种类型的选定对等ID攻击。
If the overlay network or peer protocol has more specific requirements for the Node ID value that prevent using HITs derived from public keys, each host will need a certificate (e.g., in their HIP base exchanges) provided by the enrollment server to prove that
如果覆盖网络或对等协议对节点ID值有更具体的要求，从而阻止使用从公钥派生的命中，则每个主机都需要注册服务器提供的证书（例如，在其HIP base Exchange中）来证明
they are authorized to use a particular identifier in the overlay. Depending on how the certificates are constructed, they typically also need to contain the host's self-generated public key. Depending on how the Node IDs and public keys are attributed, different scenarios become possible. For example, the Node IDs may be attributed to users, there may be user public key identifiers, and there may be separate host public key identifiers. Authorization certificates can be used to bind the different types of identifiers together.
他们有权在覆盖中使用特定标识符。根据证书的构造方式，它们通常还需要包含主机的自生成公钥。根据节点ID和公钥的属性，可能会出现不同的情况。例如，节点id可以归属于用户，可以存在用户公钥标识符，并且可以存在单独的主机公钥标识符。授权证书可用于将不同类型的标识符绑定在一起。
HITs, as defined in [RFC5201], always start with the ORCHID prefix. Therefore, there are 100 bits left in the HIT for different Node ID values. If an overlay network requires a larger address space, it is also possible to use all the 128 bits of a HIT for addressing peer layer identifiers. The benefit of using ORCHID prefix for Node IDs is that it makes possible to use them with legacy socket APIs, but in this context, most of the applications are assumed to be HIP aware and able to use a more advanced API supporting full 128-bit identifiers. Even larger address spaces could be supported with an additional HIP parameter giving the source and destination Node IDs, but defining such a parameter, if needed, is left for future documents.
[RFC5201]中定义的点击总是以兰花前缀开头。因此，对于不同的节点ID值，HIT中还剩下100位。如果覆盖网络需要更大的地址空间，也可以使用HIT的所有128位来寻址对等层标识符。为节点ID使用兰花前缀的好处是，可以将它们与传统套接字API一起使用，但在这种情况下，大多数应用程序都被认为是HIP感知的，并且能够使用支持完整128位标识符的更高级API。甚至更大的地址空间也可以通过提供源节点和目标节点ID的附加HIP参数来支持，但是如果需要，定义这样的参数将留给将来的文档。
Bootstrap issues, such as how to locate an enrollment or a bootstrap server, belong to the peer protocol.
引导问题，例如如何定位注册或引导服务器，属于对等协议。
It is possible for a HIP host to participate simultaneously in multiple different overlay networks. It is also possible that some HIP traffic is not intended to be forwarded over an overlay. Therefore, a host needs to know to which overlay an incoming HIP message belongs and the outgoing HIP messages need to be labeled as belonging to a certain overlay. This document specifies a new generic HIP parameter (in Section 6.1) for the purpose of directing HIP messages to the right overlay.
HIP主机可以同时参与多个不同的覆盖网络。也有可能一些HIP流量不打算通过覆盖转发。因此，主机需要知道传入的HIP消息属于哪个覆盖，而传出的HIP消息需要标记为属于某个覆盖。本文件规定了一个新的通用HIP参数（见第6.1节），用于将HIP消息定向到右侧覆盖。
In addition, an application using HIP BONE needs to define, either implicitly or explicitly, the overlay to use for communication. Explicit configuration can happen, e.g., by configuring certain local HITs to be bound to certain overlays or by defining the overlay identifier using advanced HIP socket options or other suitable APIs. On the other hand, if no explicit configuration for a HIP association is used, a host may have a configured default overlay where all HIP messages without a valid locator are sent. The specification for how to implement this coordination for locally originated messages is out of scope for this document.
此外，使用髋骨的应用程序需要隐式或显式定义用于通信的覆盖。可以进行显式配置，例如，通过将某些本地点击配置为绑定到某些覆盖，或者通过使用高级HIP套接字选项或其他合适的API定义覆盖标识符。另一方面，如果没有使用HIP关联的显式配置，则主机可能具有配置的默认覆盖，其中发送所有没有有效定位器的HIP消息。如何为本地生成的消息实现这种协调的规范超出了本文档的范围。
Nodes in an overlay need to establish connections with other nodes in different cases. For example, a node typically has connections to the nodes in its forwarding table. Nodes also need to establish connections with other nodes in order to exchange application-layer messages.
覆盖中的节点需要在不同情况下与其他节点建立连接。例如，节点通常与其转发表中的节点有连接。节点还需要与其他节点建立连接，以便交换应用层消息。
As discussed earlier, HIP uses the base exchange to establish connections. A HIP endpoint (the initiator) initiates a HIP base exchange with a remote endpoint by sending an I1 packet. The initiator sends the I1 packet to the remote endpoint's locator. Initiators that do not have any locator for the remote endpoint need to use a rendezvous service. Traditionally, a HIP rendezvous server [RFC5204] has provided such a rendezvous service. In HIP BONE, the overlay itself provides the rendezvous service.
如前所述，HIP使用基本交换建立连接。HIP端点（发起方）通过发送I1数据包来发起与远程端点的HIP-base交换。启动器将I1数据包发送到远程端点的定位器。没有远程端点定位器的启动器需要使用集合服务。传统上，HIP会合服务器[RFC5204]提供这种会合服务。在髋骨中，覆盖层本身提供会合服务。
Therefore, in HIP BONE, a node uses an I1 packet (as usual) to establish a connection with another node in the overlay. Nodes in the overlay forward I1 packets in a hop-by-hop fashion according to the overlay's routing table towards its destination. This way, the overlay provides a rendezvous service between the nodes establishing the connection. If the overlay nodes have active connections with other nodes in their forwarding tables and if those connections are protected (typically with IPsec ESP), I1 packets may be sent over protected connections between nodes. Alternatively, if there is no such an active connection but the node forwarding the I1 packet has a valid locator for the next hop, the I1 packets may be forwarded directly, in a similar fashion to how I1 packets are today forwarded by a HIP rendezvous server.
因此，在髋骨中，节点使用I1数据包（通常）与覆盖中的另一个节点建立连接。覆盖中的节点根据覆盖的路由表以逐跳方式向其目的地转发I1数据包。这样，覆盖层在建立连接的节点之间提供会合服务。如果覆盖节点与其转发表中的其他节点具有活动连接，并且这些连接受到保护（通常使用IPsec ESP），则可以通过节点之间受保护的连接发送I1数据包。或者，如果不存在这样的活动连接，但是转发I1分组的节点具有用于下一跳的有效定位器，则可以直接转发I1分组，方式类似于目前由HIP会合服务器转发I1分组的方式。
Since HIP supports NAT traversal, a HIP base exchange over the overlay will perform an ICE [RFC5245] offer/answer exchange between the nodes that are establishing the connection. In order to perform this exchange, the nodes need to first gather candidate addresses. Which nodes can be used to obtain reflexive address candidates and which ones can be used to obtain relayed candidates is defined by the peer protocol.
由于HIP支持NAT穿越，覆盖上的HIP基础交换将在建立连接的节点之间执行ICE[RFC5245]提供/应答交换。为了执行此交换，节点需要首先收集候选地址。对等协议定义了哪些节点可用于获取自反地址候选，哪些节点可用于获取中继候选。
In some cases, nodes need to perform a lightweight query to another node (e.g., a request followed by a single response). In this situation, establishing a connection using the mechanisms in Section 5.3 for a simple query would be an overkill. A better solution is to forward a HIP message through the overlay with the query and another one with the response to the query. The payload of such HIP packets is integrity protected [RFC6078].
在某些情况下，节点需要对另一个节点执行轻量级查询（例如，一个请求后跟一个响应）。在这种情况下，使用第5.3节中针对简单查询的机制建立连接将是一种过分的做法。更好的解决方案是通过与查询的覆盖转发HIP消息，并通过对查询的响应转发另一条HIP消息。此类HIP数据包的有效载荷受完整性保护[RFC6078]。
Nodes in the overlay forward this HIP packet in a hop-by-hop fashion according to the overlay's routing table towards its destination, typically through the protected connections established between them. Again, the overlay acts as a rendezvous server between the nodes exchanging the messages.
覆盖层中的节点通常通过它们之间建立的受保护连接，根据覆盖层的路由表，以逐跳方式将该HIP数据包转发到其目的地。同样，覆盖层充当交换消息的节点之间的会合服务器。
As discussed in Section 5, HIP BONE is a generic framework that allows using different peer protocols. A particular HIP BONE instance uses a particular peer protocol. The details on how to implement a HIP BONE using a given peer protocol need to be specified in a, so-called, HIP BONE instance specification. A HIP BONE instance specification needs to define, minimally:
如第5节所述，髋骨是一个通用框架，允许使用不同的对等协议。特定髋骨实例使用特定的对等协议。关于如何使用给定对等协议实现髋骨的详细信息需要在所谓的髋骨实例规范中指定。髋骨实例规范至少需要定义：
o the peer protocol to be used, o what kind of Node IDs are used and how they are derived, o which peer protocol primitives trigger HIP messages, and o how the overlay identifier is generated.
o 要使用的对等协议，o使用什么类型的节点ID及其派生方式，o哪些对等协议原语触发HIP消息，以及o如何生成覆盖标识符。
Additionally, a HIP BONE instance specification may need to specify other details that are specific to the peer protocol used.
此外，髋骨实例规范可能需要指定特定于所用对等协议的其他详细信息。
As an example, the HIP BONE instance specification for RELOAD [P2PSIP-BASE] is specified in [HIP-RELOAD-INSTANCE].
例如，重新加载[P2PSIP-BASE]的髋骨实例规范在[HIP-RELOAD-instance]中指定。
The areas not covered by a particular HIP BONE instance specification are specified by the peer protocol or elsewhere. These areas include:
特定髋骨实例规范未涵盖的区域由对等协议或其他地方指定。这些领域包括：
o the algorithm to create the overlay (e.g., a DHT), o overlay maintenance functions, o data storage and retrieval functions, o the process for obtaining a Node ID, o bootstrap function, and o how to select STUN and TURN servers for the candidate address collection process in NAT traversal scenarios.
o 创建覆盖（例如DHT）的算法，o覆盖维护功能，o数据存储和检索功能，o获取节点ID的过程，o引导功能，以及o如何为NAT遍历场景中的候选地址收集过程选择STUN和TURN服务器。
Note that the border between a HIP BONE instance specification and a peer protocol specifications is fuzzy. Depending on how generic the specification of a given peer protocol is, its associated HIP BONE instance specification may need to specify more or less details. Also, a HIP BONE instance specification may leave certain areas unspecified in order to leave their configuration up to each particular overlay.
请注意，髋骨实例规范和对等协议规范之间的边界是模糊的。根据给定对等协议规范的通用性，其相关髋骨实例规范可能需要指定更多或更少的细节。此外，髋骨实例规范可能会保留某些未指定的区域，以便将其配置留给每个特定覆盖。
This section defines the generic format and protocol behavior for the Overlay Identifier and Overlay Time-to-Live (TTL) HIP parameters that can be used in HIP based overlay networks. HIP BONE instance specifications define the exact format and content of the Overlay Identifier parameter, the cases when the Overlay TTL parameter should be used, and any additional behavior for each packet.
本节定义了可用于基于HIP的覆盖网络的覆盖标识符和覆盖生存时间（TTL）HIP参数的通用格式和协议行为。髋骨实例规范定义覆盖标识符参数的确切格式和内容、应使用覆盖TTL参数的情况以及每个数据包的任何其他行为。
To identify to which overlay network a HIP message belongs, all HIP messages that are sent via an overlay, or as a part of operations specific to a certain overlay, MUST contain an OVERLAY_ID parameter with the identifier of the corresponding overlay network. Instance specifications define how the identifier is generated for different types of overlay networks. The generation mechanism MUST be such that it is unlikely to generate the same identifier for two different overlay instances and any other means possible for preventing collisions SHOULD be used.
要识别HIP消息所属的覆盖网络，通过覆盖发送的所有HIP消息，或作为特定覆盖操作的一部分，必须包含覆盖ID参数，并带有相应覆盖网络的标识符。实例规范定义了如何为不同类型的覆盖网络生成标识符。生成机制必须确保不可能为两个不同的覆盖实例生成相同的标识符，并且应使用任何其他可能防止冲突的方法。
The generic format of the OVERLAY_ID parameter is shown in Figure 8. Instance specifications define valid length for the parameter and how the identifier values are generated.
OVERLAY_ID参数的通用格式如图8所示。实例规范定义参数的有效长度以及标识符值的生成方式。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 4592 Length Length of the Identifier, in octets Identifier The identifier value Padding 0-7 bytes of padding if needed
键入4592长度标识符的长度，以八位字节为单位，标识符值填充0-7字节的填充（如果需要）
Figure 8: Format of the OVERLAY_ID Parameter
图8:OVERLAY_ID参数的格式
HIP packets sent in an overlay network MAY contain an Overlay Time-to-live (OVERLAY_TTL) parameter whose TTL value is decremented on each overlay network hop. When a HIP host receives a HIP packet with
在覆盖网络中发送的HIP数据包可能包含覆盖生存时间（overlay_TTL）参数，其TTL值在每个覆盖网络跃点上递减。当HIP主机接收到HIP数据包时
an OVERLAY_TTL parameter, and the host is not the final recipient of the packet, it MUST decrement the TTL value in the parameter by one before forwarding the packet.
一个OVERLAY_TTL参数，并且主机不是数据包的最终接收者，它必须在转发数据包之前将参数中的TTL值减少1。
If the TTL value in a received HIP packet is zero, and the receiving host is not the final recipient, the packet MUST be dropped and the host SHOULD send HIP Notify packet with NOTIFICATION error type OVERLAY_TTL_EXCEEDED (value 70) to the sender of the original HIP packet.
如果接收到的HIP数据包中的TTL值为零，且接收主机不是最终收件人，则必须丢弃该数据包，并且主机应向原始HIP数据包的发送方发送通知错误类型为OVERLAY_TTL_（值70）的HIP Notify数据包。
The Notification Data field for the OVERLAY_TTL_EXCEEDED notifications SHOULD contain the HIP header and the TRANSACTION_ID [RFC6078] parameter (if one exists) of the packet whose TTL was exceeded.
覆盖TTL超出通知的通知数据字段应包含超出TTL的数据包的HIP头和事务ID[RFC6078]参数（如果存在）。
Figure 9 shows the format of the OVERLAY_TTL parameter. The TTL value is given as the number of overlay hops this packet has left and it is encoded as an unsigned integer using network byte order.
图9显示了OVERLAY_TTL参数的格式。TTL值作为该数据包剩余的覆盖跃点数给出，并使用网络字节顺序将其编码为无符号整数。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 64011 Length 4 TTL The Time-to-Live value Reserved Reserved for future use
键入64011 Length 4 TTL生存时间值保留供将来使用
Figure 9: Format of the OVERLAY_TTL Parameter
图9:OVERLAY\u TTL参数的格式
The type of the OVERLAY_TTL parameter is critical (as defined in Section 5.2.1 of [RFC5201]) and therefore all the HIP nodes forwarding a packet with this parameter MUST support it. If the parameter is used in a scenario where the final recipient does not support the parameter, the parameter SHOULD be removed before forwarding the packet to the final recipient.
OVERLAY_TTL参数的类型是关键的（如[RFC5201]第5.2.1节中所定义），因此所有使用该参数转发数据包的HIP节点必须支持该参数。如果在最终收件人不支持该参数的情况下使用该参数，则应在将数据包转发给最终收件人之前删除该参数。
This document provides a high-level framework to build HIP-based overlays. The security properties of HIP and its extensions used in this framework are discussed in their respective specifications. Those security properties can be affected by the way HIP is used in a particular overlay. However, those properties are mostly affected by
本文档提供了构建基于HIP的覆盖的高级框架。此框架中使用的HIP及其扩展的安全属性在各自的规范中进行了讨论。这些安全属性可能会受到HIP在特定覆盖中使用方式的影响。然而，这些房地产主要受到以下因素的影响：
the design decisions made to build a particular overlay; not so much by the high-level framework specified in this document. Such design decisions are typically documented in a HIP BONE instance specification, which describes the security properties of the resulting overlay.
为建造特定覆盖层而做出的设计决策；本文件中规定的高级框架没有这么多。此类设计决策通常记录在髋骨实例规范中，该规范描述了生成覆盖的安全属性。
HIP BONE is based on ideas coming from conversations and discussions with a number of people in the HIP and P2PSIP communities. In particular, Philip Matthews, Eric Cooper, Joakim Koskela, Thomas Henderson, Bruce Lowekamp, and Miika Komu provided useful input on HIP BONE.
HIP BONE基于与HIP和P2PSIP社区中的许多人的对话和讨论中得出的想法。特别是，菲利普·马修斯、埃里克·库珀、约阿金·科斯卡拉、托马斯·亨德森、布鲁斯·洛坎普和米卡·科姆在髋骨方面提供了有用的信息。
This section is to be interpreted according to [RFC5226].
本节将根据[RFC5226]进行解释。
This document updates the IANA Registry for HIP Parameter Types [RFC5201] by assigning HIP Parameter Type values for the new HIP Parameters OVERLAY_ID (defined in Section 6.1) and OVERLAY_TTL (defined in Section 6.2). This document also defines a new HIP Notify Message Type [RFC5201], OVERLAY_TTL_EXCEEDED in Section 6.2. This value is allocated in the error range.
本文件通过为新的HIP参数重叠_ID（定义见第6.1节）和重叠_TTL（定义见第6.2节）分配HIP参数类型值，更新IANA HIP参数类型注册表[RFC5201]。本文件还定义了一种新的HIP通知消息类型[RFC5201]，超出了第6.2节中的覆盖。此值在错误范围内分配。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)", RFC 4843, April 2007.
[RFC4843]Nikander，P.，Laganier，J.，和F.Dupont，“覆盖可路由加密哈希标识符（RAYD）的IPv6前缀”，RFC 4843，2007年4月。
[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月。
[RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)", RFC 5202, April 2008.
[RFC5202]Jokela，P.，Moskowitz，R.，和P.Nikander，“将封装安全有效载荷（ESP）传输格式与主机标识协议（HIP）结合使用”，RFC 52022008年4月。
[RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. Keranen, Ed., "Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators", RFC 5770, April 2010.
[RFC5770]Komu，M.，Henderson，T.，Tschofenig，H.，Melen，J.，和A.Keranen，Ed.，“用于遍历网络地址转换器的基本主机身份协议（HIP）扩展”，RFC 57702010年4月。
[RFC6078] Camarillo, G. and J. Melen, "Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS)", RFC 6078, January 2011.
[RFC6078]Camarillo，G.和J.Melen，“主机身份协议（HIP）上层协议信令的即时传输（HICCup）”，RFC 6078，2011年1月。
[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[RFC4251]Ylonen，T.和C.Lonvick，编辑，“安全外壳（SSH）协议架构”，RFC 4251，2006年1月。
[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", RFC 5204, April 2008.
[RFC5204]Laganier，J.和L.Eggert，“主机身份协议（HIP）会合扩展”，RFC 52042008年4月。
[RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions", RFC 5205, April 2008.
[RFC5205]Nikander，P.和J.Laganier，“主机身份协议（HIP）域名系统（DNS）扩展”，RFC 52052008年4月。
[RFC5206] Nikander, P., Henderson, T., Ed., Vogt, C., and J. Arkko, "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008.
[RFC5206]Nikander，P.，Henderson，T.，Ed.，Vogt，C.，和J.Arkko，“使用主机身份协议的终端主机移动性和多址”，RFC 52062008年4月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host Identity Protocol with Legacy Applications", RFC 5338, September 2008.
[RFC5338]Henderson，T.，Nikander，P.，和M.Komu，“在遗留应用程序中使用主机身份协议”，RFC 5338，2008年9月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389]Rosenberg，J.，Mahy，R.，Matthews，P.，和D.Wing，“NAT的会话遍历实用程序（STUN）”，RFC 5389，2008年10月。
[HIP-NATIVE-API] Komu, M. and T. Henderson, "Basic Socket Interface Extensions for Host Identity Protocol (HIP)", Work in Progress, January 2010.
[HIP-NATIVE-API]Komu，M.和T.Henderson，“主机标识协议（HIP）的基本套接字接口扩展”，正在进行的工作，2010年1月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 52452010年4月。
[P2PSIP-BASE] Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", Work in Progress, November 2010.
[P2PSIP-BASE]Jennings，C.，Lowekamp，B.，Ed.，Rescorla，E.，Baset，S.，和H.Schulzrinne，“资源定位和发现（重新加载）基础协议”，正在进行的工作，2010年11月。
[HIP-RELOAD-INSTANCE] Keranen, A., Camarillo, G., and J. Maenpaa, "Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD)", Work in Progress, January 2011.
[HIP-RELOAD-INSTANCE]Keranen，A.，Camarillo，G.，和J.Maenpa，“基于主机身份协议的覆盖网络环境（HIP-BONE）资源定位和发现实例规范（RELOAD）”，正在进行的工作，2011年1月。
Authors' Addresses
作者地址
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420芬兰
EMail: Gonzalo.Camarillo@ericsson.com
EMail: Gonzalo.Camarillo@ericsson.com
Pekka Nikander Ericsson Hirsalantie 11 Jorvas 02420 Finland
Pekka Nikander Ericsson Hirsalantie 11 Jorvas 02420芬兰
EMail: Pekka.Nikander@ericsson.com
EMail: Pekka.Nikander@ericsson.com
Jani Hautakorpi Ericsson Hirsalantie 11 Jorvas 02420 Finland
Jani Hautakorpi Ericsson Hirsalantie 11 Jorvas 02420芬兰
EMail: Jani.Hautakorpi@ericsson.com
EMail: Jani.Hautakorpi@ericsson.com
Ari Keranen Ericsson Hirsalantie 11 Jorvas 02420 Finland
Ari Keranen Ericsson Hirsalantie 11 Jorvas 02420芬兰
EMail: Ari.Keranen@ericsson.com
EMail: Ari.Keranen@ericsson.com
Alan Johnston Avaya St. Louis, MO 63124
密苏里州圣路易斯市艾伦·约翰斯顿·阿瓦亚63124
EMail: alan.b.johnston@gmail.com
EMail: alan.b.johnston@gmail.com