Internet Engineering Task Force (IETF) A. Keranen
Request for Comments: 7086 G. Camarillo
Category: Experimental J. Maenpaa
ISSN: 2070-1721 Ericsson
January 2014
Internet Engineering Task Force (IETF) A. Keranen
Request for Comments: 7086 G. Camarillo
Category: Experimental J. Maenpaa
ISSN: 2070-1721 Ericsson
January 2014
Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD)
基于主机身份协议的覆盖网络环境（HIP-BONE）实例规范，用于资源定位和发现（重新加载）
Abstract
摘要
This document is the HIP-Based Overlay Networking Environment (HIP BONE) instance specification for the REsource LOcation And Discovery (RELOAD) protocol. The document provides the details needed to build a RELOAD-based overlay that uses HIP.
本文档是资源位置和发现（重新加载）协议的基于HIP的覆盖网络环境（HIP-BONE）实例规范。该文档提供了构建使用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/rfc7086.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7086.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Peer Protocol . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Node ID Generation . . . . . . . . . . . . . . . . . . . . . 3
5. Mapping between Protocol Primitives and HIP Messages . . . . 3
5.1. Forwarding Header . . . . . . . . . . . . . . . . . . . . 4
5.2. Security Block . . . . . . . . . . . . . . . . . . . . . 4
5.3. Replaced RELOAD Messages . . . . . . . . . . . . . . . . 5
6. Securing Communication . . . . . . . . . . . . . . . . . . . 5
7. Routing HIP Messages via the Overlay . . . . . . . . . . . . 5
8. Enrollment and Bootstrapping . . . . . . . . . . . . . . . . 6
9. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 7
10. RELOAD Overlay Configuration Document Extension . . . . . . . 7
11. Security Considerations . . . . . . . . . . . . . . . . . . . 8
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
14.1. Normative References . . . . . . . . . . . . . . . . . . 8
14.2. Informative References . . . . . . . . . . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Peer Protocol . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Node ID Generation . . . . . . . . . . . . . . . . . . . . . 3
5. Mapping between Protocol Primitives and HIP Messages . . . . 3
5.1. Forwarding Header . . . . . . . . . . . . . . . . . . . . 4
5.2. Security Block . . . . . . . . . . . . . . . . . . . . . 4
5.3. Replaced RELOAD Messages . . . . . . . . . . . . . . . . 5
6. Securing Communication . . . . . . . . . . . . . . . . . . . 5
7. Routing HIP Messages via the Overlay . . . . . . . . . . . . 5
8. Enrollment and Bootstrapping . . . . . . . . . . . . . . . . 6
9. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 7
10. RELOAD Overlay Configuration Document Extension . . . . . . . 7
11. Security Considerations . . . . . . . . . . . . . . . . . . . 8
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
14.1. Normative References . . . . . . . . . . . . . . . . . . 8
14.2. Informative References . . . . . . . . . . . . . . . . . 9
The HIP-Based Overlay Networking Environment (HIP BONE) specification [RFC6079] provides a high-level framework for building HIP-based [RFC5201] overlays. The HIP BONE framework does not address the specification of the details on how to combine a particular peer protocol with HIP to build an overlay. It leaves this up to documents referred to as HIP BONE instance specifications. As discussed in [RFC6079], a HIP BONE instance specification needs to define, minimally:
基于HIP的覆盖网络环境（HIP-BONE）规范[RFC6079]为构建基于HIP的[RFC5201]覆盖提供了一个高级框架。HIP-BONE框架没有详细说明如何将特定对等协议与HIP相结合以构建覆盖。这取决于称为髋骨实例规范的文档。如[RFC6079]中所述，髋骨实例规范至少需要定义：
o the peer protocol to be used.
o 要使用的对等协议。
o what kind of Node IDs are used and how they are derived.
o 使用什么类型的节点ID以及如何派生它们。
o which peer protocol primitives trigger HIP messages.
o 哪些对等协议原语触发HIP消息。
o how the overlay identifier is generated.
o 如何生成覆盖标识符。
This document addresses all the previous items and provides additional details needed to build RELOAD-based HIP BONEs, referred to here as RELOAD HIP BONEs. The details on how different RELOAD modules would be integrated to a HIP implementation and what kind of APIs are used between them are left as implementation details or to be defined by other documents.
本文档介绍了前面的所有项目，并提供了构建基于重载的髋部骨骼（此处称为重载髋部骨骼）所需的其他详细信息。关于如何将不同的重新加载模块集成到HIP实现中以及在它们之间使用何种API的详细信息保留为实现细节或由其他文档定义。
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 [RFC2119]. In addition, this document uses the terms defined in [RFC5201], [RFC6079], [RFC6028], and [RFC6940].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。此外，本文件使用了[RFC5201]、[RFC6079]、[RFC6028]和[RFC6940]中定义的术语。
The peer protocol to be used is REsource LOcation And Discovery (RELOAD) [RFC6940]. When used with RELOAD, HIP replaces the RELOAD's Forwarding and Link Management Layer (described in Section 6.5 of [RFC6940]).
要使用的对等协议是资源定位和发现（重新加载）[RFC6940]。当与重新加载一起使用时，HIP取代了重新加载的转发和链路管理层（如[RFC6940]第6.5节所述）。
This document specifies two modes for generating Node and Resource IDs. Which mode is used in an actual overlay is defined by the overlay configuration. Both of the modes are based on 16-byte ID mode of RELOAD; hence, only 16-byte RELOAD Node and Resource IDs MUST be used in a RELOAD HIP BONE.
本文档指定了生成节点和资源ID的两种模式。实际覆盖中使用的模式由覆盖配置定义。两种模式均基于16字节ID的重新加载模式；因此，在重新加载髋骨中只能使用16字节的重新加载节点和资源ID。
HIP uses 128-bit Overlay Routable Cryptographic Hash Identifiers (ORCHIDs) [RFC4843] as identifiers. In a RELOAD HIP BONE, a peer's ORCHID can be used as a RELOAD Node ID (the "ORCHID" mode). In this mode, all the RELOAD IDs, including Resource IDs, are prefixed with the ORCHID prefix, and the lower 100 bits of the IDs defined by RELOAD usage documents are used after the prefix.
HIP使用128位覆盖可路由加密哈希标识符（RAYTS）[RFC4843]作为标识符。在重新加载髋骨中，对等方的兰花可以用作重新加载节点ID（“兰花”模式）。在此模式下，所有重新加载ID（包括资源ID）都以兰花前缀作为前缀，并且在前缀之后使用重新加载使用文档定义的ID的较低100位。
In the other Node ID mode, namely "RELOAD", all 128 bits are generated as defined in [RFC6940]. This results in a larger usable address space than using the ORCHID mode, but the resulting Node IDs cannot be used with legacy applications and APIs, as discussed in Section 5.1 of [RFC6079].
在另一个节点ID模式下，即“重新加载”，所有128位都按照[RFC6940]中的定义生成。这会比使用兰花模式产生更大的可用地址空间，但由此产生的节点ID不能用于遗留应用程序和API，如[RFC6079]第5.1节所述。
RELOAD HIP BONE replaces the RELOAD protocol primitives taking care of connection establishment with the HIP base exchange, whereas the rest of the RELOAD messages are conveyed within HIP messages. The Forwarding and Link Management Layer functionality of RELOAD, including all the NAT traversal functionality, is replaced by HIP, existing extensions of HIP, and the extensions defined in this document.
重新加载髋部骨骼将替换重新加载协议原语，负责与髋部基础交换建立连接，而其余的重新加载消息将在髋部消息中传递。RELOAD的转发和链路管理层功能（包括所有NAT遍历功能）被HIP、HIP的现有扩展以及本文档中定义的扩展所取代。
The standard RELOAD messages consist of three parts: the forwarding header, the message contents, and the security block. When RELOAD messages are sent in a RELOAD HIP BONE overlay, the RELOAD message contents are used as such within HIP DATA [RFC6078] messages, but the functionality of the forwarding header and security block are replaced with the HIP header, HIP Destination and Via lists [RFC6028], CERT [RFC6253], TRANSACTION_ID [RFC6078], and the OVERLAY_ID and OVERLAY_TTL [RFC6079] parameters, as defined in the following sections.
标准的重新加载消息由三部分组成：转发头、消息内容和安全块。当在重新加载髋骨覆盖中发送重新加载消息时，重新加载消息内容在HIP数据[RFC6078]消息中使用，但转发头和安全块的功能被替换为HIP头、HIP目的地和Via列表[RFC6028]、证书[RFC6253]、事务ID[RFC6078]，以及OVERLAY_ID和OVERLAY_TTL[RFC6079]参数，如以下各节所定义。
The RELOAD forwarding header is used for forwarding messages between peers and to their final destination. The forwarding header's overlay field value MUST be used as such in an OVERLAY_ID parameter and the transaction_id field in a TRANSACTION_ID parameter. That is, all RELOAD HIP BONE messages MUST contain these parameters; and, the length of the OVERLAY_ID parameter's identifier field is 4, and the length of the TRANSACTION_ID parameter is 8 octets. HIP Destination and Via lists are used for the same purpose as the destination_list and via_list in the forwarding header, with the exception that all Resource IDs MUST be of the same length as Node IDs, and compressed IDs MUST NOT be used. The Time to Live (TTL) value in the OVERLAY_TTL parameter is used like the ttl field in the forwarding header.
重载转发头用于在对等方之间转发消息并将其转发到最终目的地。转发头的overlay字段值必须在overlay_ID参数和transaction_ID参数中的transaction_ID字段中使用。也就是说，所有重载髋骨消息必须包含这些参数；并且，OVERLAY_ID参数的标识符字段的长度为4，事务_ID参数的长度为8个八位字节。HIP目的地和通过列表与转发头中的目的地列表和通过列表的用途相同，但所有资源ID必须与节点ID具有相同的长度，并且不得使用压缩ID。OVERLAY_TTL参数中的生存时间（TTL）值与转发头中的TTL字段类似。
The functionality of the fragment and length fields are provided by the HIP headers. The relo_token, version, and max_response_length are not needed with HIP. The forwarding header's options field, if needed eventually for some extensions, can be substituted with additional HIP parameters.
片段和长度字段的功能由HIP标题提供。HIP不需要relo_标记、版本和最大响应长度。如果某些扩展最终需要转发标头的选项字段，则可以用其他HIP参数替换。
The RELOAD security block contains certificates and digital signatures of the message. All the HIP DATA messages are digitally signed by the originator of the message and contain the HOST_ID parameter with the identifier that can be used for verifying the signature. Certificates are delivered in a HIP CERT parameter as defined in [RFC6253] or stored to the overlay using the RELOAD Certificate Storage Usage.
重新加载安全块包含消息的证书和数字签名。所有HIP数据消息均由消息的发起人进行数字签名，并包含HOST_ID参数和可用于验证签名的标识符。证书以[RFC6253]中定义的HIP CERT参数传递，或使用重新加载证书存储用法存储到覆盖层。
Note that when the RELOAD mode for Node ID generation is used, the certificate certifying that a host is allowed to use a certain Node ID MUST contain the host's Node ID instead of the Host Identity Tag (HIT) in the "subjectAltName" field of the certificate as described in Section 11.3 of [RFC6940], while the "Subject" field contains the HIT calculated from the Host Identity.
请注意，当使用节点ID生成的重新加载模式时，证明允许主机使用特定节点ID的证书必须包含主机的节点ID，而不是[RFC6940]第11.3节所述的证书“subjectAltName”字段中的主机标识（HIT），而“Subject”字段包含根据主机标识计算的命中率。
The Attach procedure in RELOAD establishes a connection between two peers. This procedure is performed using the AttachReq and AttachAns messages. When HIP is used, the Attach procedure is performed by using a HIP base exchange. That is, peers send HIP first Initiator (I1) messages instead of RELOAD AttachReq messages. This behavior replaces the one described in Section 6.5 of [RFC6940].
重新加载中的附加过程在两个对等节点之间建立连接。使用AttachReq和AttachAns消息执行此过程。当使用髋关节时，通过髋关节基底交换来执行连接程序。也就是说，对等方发送HIP第一启动器（I1）消息，而不是重新加载AttachReq消息。此行为取代[RFC6940]第6.5节中描述的行为。
The AppAttach procedure in RELOAD is used for creating a connection for other applications than RELOAD. Also, the AppAttach procedure is replaced with the HIP base exchange, and after the base exchange, peers can exchange any application layer data using the normal transport layer ports over the NAT traversing IPsec connection.
RELOAD中的AppAttach过程用于为RELOAD以外的其他应用程序创建连接。此外，AppAttach过程被HIP基本交换所取代，在基本交换之后，对等方可以使用NAT穿越IPsec连接的正常传输层端口交换任何应用层数据。
This specification does not support flooding of configuration files, so ConfigUpdate requests and responses (Section 6.5.4 of [RFC6940]) MUST NOT be sent in the overlay. RELOAD Ping messages (Section 6.5.3 of [RFC6940]) MAY be used.
本规范不支持配置文件的泛洪，因此不得在覆盖中发送ConfigUpdate请求和响应（RFC6940第6.5.4节）。可以使用重新加载Ping消息（RFC6940第6.5.3节）。
For all other RELOAD messages, the message contents are used as such within HIP DATA messages.
对于所有其他重新加载消息，消息内容在HIP数据消息中使用。
RELOAD uses Transport Layer Security (TLS) [RFC5246] connections for securing the hop-by-hop messaging and certificates and signatures for providing integrity protection for the overlay messages and for the data stored in the overlay.
RELOAD使用传输层安全性（TLS）[RFC5246]连接来保护逐跳消息以及证书和签名的安全，从而为覆盖消息和存储在覆盖中的数据提供完整性保护。
With a RELOAD HIP BONE, instead of using TLS connections as defined in [RFC6940], all HIP overlay messages MUST be sent using encrypted connections [RFC6261].
使用重新加载髋骨，而不是使用[RFC6940]中定义的TLS连接，所有髋部覆盖消息必须使用加密连接[RFC6261]发送。
The data objects stored in the RELOAD HIP BONE overlay are signed, and the signatures are stored as defined in [RFC6940] with the exception that SignerIdentity is carried in the HIP DATA message's HOST_ID parameter instead of using the RELOAD security block. Where certificates are needed, they are sent using the HIP CERT parameter.
重新加载髋部骨骼覆盖中存储的数据对象进行签名，并且按照[RFC6940]中的定义存储签名，但HIP数据消息的HOST_ID参数中包含SignerIdentity，而不是使用重新加载安全块。如果需要证书，则使用HIP CERT参数发送证书。
If a host has no valid locator for the receiver of a new HIP packet, and the receiver is part of a RELOAD HIP BONE overlay the host is participating in, the host can send the HIP packet to the receiver using the overlay routing.
如果主机没有用于新HIP数据包接收器的有效定位器，并且接收器是主机参与的重新加载髋骨覆盖的一部分，则主机可以使用覆盖路由将HIP数据包发送给接收器。
When sending a HIP packet via the overlay, the host MUST add an empty ROUTE_VIA parameter [RFC6028] to the packet with the SYMMETRIC and MUST_FOLLOW flags set and an OVERLAY_ID parameter containing the identifier of the right overlay network. The host consults the RELOAD Topology Plugin for the next hop and sends the HIP packet to that host.
当通过覆盖发送HIP数据包时，主机必须通过参数[RFC6028]将空路由添加到设置了对称和必须遵循标志的数据包中，并添加包含正确覆盖网络标识符的覆盖ID参数。主机为下一跳查询重新加载拓扑插件，并将HIP数据包发送到该主机。
An intermediate host receiving a HIP packet with the OVERLAY_ID parameter checks if it is participating in that overlay and SHOULD drop packets sent to unknown overlays. If the host is not the final destination of the packet (i.e., the Receiver HIT in the HIP header does not match to any of its HITs), it checks if the packet contains a ROUTE_DST parameter. Such packets are forwarded to the next hop as specified in [RFC6028]. If the packet does not contain a ROUTE_DST parameter, the host finds the next hop from the RELOAD Topology Plugin and forwards the packet there. As specified in [RFC6028], the host adds the HIT it uses on the HIP association with the next-hop host to the end of the ROUTE_VIA parameter, if present.
接收带有OVERLAY_ID参数的HIP数据包的中间主机将检查它是否参与该覆盖，并应丢弃发送到未知覆盖的数据包。如果主机不是数据包的最终目的地（即HIP报头中的接收器命中与它的任何命中不匹配），它将检查数据包是否包含ROUTE_DST参数。按照[RFC6028]中的规定，这些数据包被转发到下一跳。如果数据包不包含RouteDST参数，主机将从重新加载拓扑插件中找到下一个跃点，并将数据包转发到该跃点。按照[RFC6028]中的规定，主机通过参数（如果存在）将其在与下一跳主机的HIP关联上使用的HIT添加到路由_的末尾。
When the final destination host receives the HIP packet, the host processes it as specified in [RFC5201]; and, if the packet is a HIP DATA packet, the contents are processed as specified in [RFC6940]. If the HIP packet generates a response, the response is routed back on the same path using the ROUTE_DST parameter as specified in [RFC6028].
当最终目的地主机接收到HIP数据包时，主机按照[RFC5201]中的规定对其进行处理；并且，如果包是HIP数据包，则按照[RFC6940]中的规定处理内容。如果HIP数据包生成响应，则使用[RFC6028]中指定的RouteDST参数将响应路由回同一路径。
The RELOAD HIP BONE instance uses the enrollment and bootstrap procedure defined by RELOAD [RFC6940] with the exceptions listed below.
重新加载髋骨实例使用重新加载[RFC6940]定义的注册和引导过程，以下列出的例外情况除外。
o In RELOAD, a node wishing to enroll in an overlay starts with obtaining a configuration document as explained in [RFC6940]. This specification extends the RELOAD overlay configuration document as defined in Section 10.
o 在重新加载中，希望注册覆盖的节点首先获取配置文档，如[RFC6940]中所述。本规范扩展了第10节中定义的重新加载覆盖配置文件。
o The X.509 certificates used by the RELOAD HIP BONE instance are similar to those of RELOAD except that they contain HITs instead of RELOAD URIs. The HITs are included in the SubjectAltName field of the certificate as described in [RFC6253].
o RELOAD HIP BONE实例使用的X.509证书与RELOAD的证书类似，只是它们包含命中而不是重新加载URI。点击包括在证书的SubjectAltName字段中，如[RFC6253]所述。
o When contacting a bootstrap node, instead of forming a Datagram Transport Layer Security (DTLS) or TLS connection, the host MUST perform a HIP base exchange with the bootstrap node. The base exchange MAY be performed using a HIP rendezvous or relay server.
o 当联系引导节点时，主机必须与引导节点执行HIP-base交换，而不是形成数据报传输层安全性（DTLS）或TLS连接。基站交换可以使用髋关节会合或中继服务器来执行。
RELOAD relies on the Forwarding and Link Management Layer providing NAT traversal capabilities. Thus, the RELOAD HIP BONE instance implementations MUST implement some reliable NAT traversal mechanism. To maximize interoperability, all implementations SHOULD implement at least [RFC5770].
重新加载依赖于提供NAT遍历功能的转发和链路管理层。因此，重载髋骨实例实现必须实现一些可靠的NAT遍历机制。为了最大限度地提高互操作性，所有实现至少应实现[RFC5770]。
HIP relay servers are not necessarily needed with this HIP BONE instance since the overlay network can be used for relaying the base exchange, and further HIP signaling can be done directly between the peers. However, if it is possible that a bootstrap peer is behind a NAT, it MUST register with a HIP relay so that there is a reliable way to connect to it.
这个HIP-BONE实例不一定需要HIP中继服务器，因为覆盖网络可以用于中继基本交换，并且进一步的HIP信令可以在对等方之间直接完成。然而，如果引导对等机可能位于NAT后面，则它必须向HIP中继注册，以便有可靠的方式连接到它。
This document modifies the bootstrap-node element of the RELOAD overlay configuration document. The modified bootstrap-node element contains the following attributes:
本文档修改重新加载覆盖配置文档的引导节点元素。修改后的引导节点元素包含以下属性：
address: The locator of the bootstrap node.
地址：引导节点的定位器。
port: The HIP port of the bootstrap node.
端口：引导节点的HIP端口。
hit: The HIT of the bootstrap node.
命中：引导节点的命中。
If the bootstrap-node element does not contain a HIT, the opportunistic mode (as specified in [RFC5201]) SHOULD be used for contacting the bootstrap node. If the element does not contain a port number, the bootstrap node SHOULD be contacted by starting the base exchange as defined in [RFC5201]. Otherwise, the base exchange MUST be started with UDP encapsulation, as defined in [RFC5770], using the given port as the destination port number.
如果引导节点元素不包含命中，则应使用机会主义模式（如[RFC5201]中所述）联系引导节点。如果元素不包含端口号，则应通过启动[RFC5201]中定义的基本交换来联系引导节点。否则，必须按照[RFC5770]中的定义，使用给定端口作为目标端口号，通过UDP封装启动基本交换。
A RELOAD HIP BONE overlay MUST use the Overlay Link Protocol type "HIP" in the configuration document's overlay-link-protocol element. The enrolling node MUST check the overlay-link-protocol element and proceed with procedures defined in this document only if the "HIP" link type is found.
重新加载髋骨覆盖必须使用配置文档覆盖链接协议元素中的覆盖链接协议类型“HIP”。注册节点必须检查覆盖链路协议元素，只有在找到“HIP”链路类型时，才能继续执行本文档中定义的过程。
This document also adds a new element inside the configuration element that defines which mode (see Section 4) is used for generating the Node and Resource IDs. The name of the element is "hipbone-id-mode" and the content is the identifier of the mode: "ORCHID" for the ORCHID prefixed IDs and "RELOAD" for the IDs that use the whole 128 bits as defined by the RELOAD specification. The NodeIdLength MUST be set to 16 in the configuration document, and the 16 bytes are used, depending on the generation mode, as defined in Section 4.
本文档还在configuration元素中添加了一个新元素，用于定义用于生成节点和资源ID的模式（参见第4节）。元素的名称是“hipbone id mode”，内容是模式的标识符：“兰花”表示带有兰花前缀的id，而“重载”表示使用重载规范定义的全部128位的id。在配置文档中，NodeIdLength必须设置为16，并根据第4节中定义的生成模式使用16个字节。
The security considerations of RELOAD (Section 13 of [RFC6940]), with the exception of TLS-specific features, also apply to RELOAD HIP BONE instances.
重新加载的安全注意事项（RFC6940第13节）除TLS特定功能外，也适用于重新加载髋骨实例。
Limiting the Node ID and Resource ID space into 128 bits (or 100 bits with ORCHID prefixes) results in a higher probability for ID collisions, both unintentional and intentional, than using larger address spaces.
与使用较大的地址空间相比，将节点ID和资源ID空间限制为128位（或100位，带兰花前缀）会导致更高的ID冲突概率（包括无意和有意）。
This section is to be interpreted according to [RFC5226].
本节将根据[RFC5226]进行解释。
IANA has updated the "RELOAD Overlay Link Protocol Registry" [RFC6940] by assigning the new Overlay Link Protocol type "HIP" (see Section 10).
IANA已通过分配新的覆盖链路协议类型“HIP”（参见第10节）更新了“重新加载覆盖链路协议注册表”[RFC6940]。
Tom Henderson, Spencer Dawkins, and Christer Holmberg have provided valuable reviews and comments on the document.
Tom Henderson、Spencer Dawkins和Christer Holmberg对该文件提供了宝贵的评论和意见。
[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., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201]Moskowitz，R.，Nikander，P.，Jokela，P.，和T.Henderson，“主机身份协议”，RFC 52012008年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月。
[RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. Keranen, "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，“用于遍历网络地址转换器的基本主机身份协议（HIP）扩展”，RFC 57702010年4月。
[RFC6028] Camarillo, G. and A. Keranen, "Host Identity Protocol (HIP) Multi-Hop Routing Extension", RFC 6028, October 2010.
[RFC6028]Camarillo，G.和A.Keranen，“主机身份协议（HIP）多跳路由扩展”，RFC 6028，2010年10月。
[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月。
[RFC6079] Camarillo, G., Nikander, P., Hautakorpi, J., Keranen, A., and A. Johnston, "HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment (BONE)", RFC 6079, January 2011.
[RFC6079]Camarillo，G.，Nikander，P.，Hautakorpi，J.，Keranen，A.，和A.Johnston，“HIP-BONE：基于主机身份协议（HIP）的覆盖网络环境（BONE）”，RFC 6079，2011年1月。
[RFC6253] Heer, T. and S. Varjonen, "Host Identity Protocol Certificates", RFC 6253, May 2011.
[RFC6253]Heer，T.和S.Varjonen，“主机身份协议证书”，RFC 6253，2011年5月。
[RFC6261] Keranen, A., "Encrypted Signaling Transport Modes for the Host Identity Protocol", RFC 6261, May 2011.
[RFC6261]Keranen，A.“主机标识协议的加密信令传输模式”，RFC 6261，2011年5月。
[RFC6940] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", January 2014.
[RFC6940]Jennings，C.，Lowekamp，B.，Rescorla，E.，Baset，S.，和H.Schulzrinne，“资源定位和发现（重新加载）基本协议”，2014年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
Authors' Addresses
作者地址
Ari Keranen Ericsson Hirsalantie 11 02420 Jorvas Finland
Ari Keranen Ericsson Hirsalantie 11 02420 Jorvas Finland
EMail: Ari.Keranen@ericsson.com
EMail: Ari.Keranen@ericsson.com
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
Jouni Maenpaa Ericsson Hirsalantie 11 Jorvas 02420 Finland
Jouni Maenpaa Ericsson Hirsalantie 11 Jorvas 02420芬兰
EMail: Jouni.Maenpaa@ericsson.com
EMail: Jouni.Maenpaa@ericsson.com