Internet Research Task Force (IRTF) J. Ahrenholz
Request for Comments: 6537 The Boeing Company
Category: Experimental February 2012
ISSN: 2070-1721
Internet Research Task Force (IRTF) J. Ahrenholz
Request for Comments: 6537 The Boeing Company
Category: Experimental February 2012
ISSN: 2070-1721
Host Identity Protocol Distributed Hash Table Interface
主机标识协议分布式哈希表接口
Abstract
摘要
This document specifies a common interface for using the Host Identity Protocol (HIP) with a Distributed Hash Table (DHT) service to provide a name-to-Host-Identity-Tag lookup service and a Host-Identity-Tag-to-address lookup service.
本文档指定了一个通用接口，用于将主机标识协议（HIP）与分布式哈希表（DHT）服务一起使用，以提供“名称到主机”标识标记查找服务和“主机标识标记到地址”查找服务。
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 Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the HIP Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网研究工作组（IRTF）的产品。IRTF发布互联网相关研究和开发活动的结果。这些结果可能不适合部署。本RFC代表了互联网研究工作组（IRTF）HIP研究小组的共识。IRSG批准发布的文件不适用于任何级别的互联网标准；见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/rfc6537.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6537.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................2
2. The OpenDHT Interface ...........................................3
3. HDRR - The HIP DHT Resource Record ..............................6
4. HIP Lookup Services .............................................8
4.1. HIP Name to HIT Lookup .....................................9
4.2. HIP Address Lookup ........................................12
5. Use Cases ......................................................15
6. Issues with DHT Support ........................................16
7. Security Considerations ........................................17
8. IANA Considerations ............................................18
9. Acknowledgments ................................................18
10. References ....................................................19
10.1. Normative References .....................................19
10.2. Informative References ...................................19
1. Introduction ....................................................2
2. The OpenDHT Interface ...........................................3
3. HDRR - The HIP DHT Resource Record ..............................6
4. HIP Lookup Services .............................................8
4.1. HIP Name to HIT Lookup .....................................9
4.2. HIP Address Lookup ........................................12
5. Use Cases ......................................................15
6. Issues with DHT Support ........................................16
7. Security Considerations ........................................17
8. IANA Considerations ............................................18
9. Acknowledgments ................................................18
10. References ....................................................19
10.1. Normative References .....................................19
10.2. Informative References ...................................19
The Host Identity Protocol (HIP) [RFC5201] may benefit from a lookup service based on Distributed Hash Tables (DHTs). The Host Identity namespace is flat, consisting of public keys, in contrast to the hierarchical Domain Name System (DNS). These keys are hashed and prefixed to form Host Identity Tags (HITs), which appear as large random numbers. As the current DNS system has been heavily optimized for address lookup, it may be worthwhile to experiment with other services such as those defined here. DHTs manage such data well by applying a hash function that distributes data across a number of servers. DHTs are also designed to be updated more frequently than a DNS-based approach. For an alternative method of using HITs to look up IP addresses using DNS, see [HIT2IP].
主机标识协议（HIP）[RFC5201]可以受益于基于分布式哈希表（dht）的查找服务。与分层域名系统（DNS）相比，主机标识命名空间是扁平的，由公钥组成。这些键被散列并加上前缀以形成主机标识标记（HITs），它以大随机数的形式出现。由于当前的DNS系统已针对地址查找进行了大量优化，因此可能值得尝试其他服务，如此处定义的服务。DHT通过应用散列函数将数据分布在多个服务器上，从而很好地管理此类数据。DHT的更新频率也比基于DNS的方法更高。有关使用HITs使用DNS查找IP地址的替代方法，请参阅[HIT2IP]。
One freely available implementation of a DHT is the Bamboo DHT, which is Java-based software that has been deployed on PlanetLab servers to form a free service named OpenDHT. OpenDHT was available via the Internet for any program to store and retrieve arbitrary data. OpenDHT used a well-defined Extensible Markup Language-Remote Procedure Calling (XML-RPC) interface, featuring put, get, and remove operations. OpenLookup, while not implemented as a DHT, is another deployment of open source software compatible with this OpenDHT interface. This document discusses a common way for HIP to use this OpenDHT interface, so that various HIP experimenters may employ lookup services in an interoperable fashion.
DHT的一个免费实现是Bambol DHT，它是基于Java的软件，部署在PlanetLab服务器上，以形成一个名为OpenDHT的免费服务。OpenDHT可通过互联网供任何程序存储和检索任意数据。OpenDHT使用定义良好的可扩展标记语言远程过程调用（XML-RPC）接口，具有put、get和remove操作。OpenLookup虽然不是作为DHT实现的，但它是与此OpenDHT接口兼容的开源软件的另一种部署。本文档讨论了HIP使用此OpenDHT接口的一种常见方法，以便各种HIP实验者可以以可互操作的方式使用查找服务。
This document is a product of the HIP research group (RG) of the IRTF. The HIP research group reached consensus that this interface specification should be published as an Experimental RFC, based on
本文件是IRTF髋关节研究组（RG）的产品。HIP研究小组达成共识，该接口规范应作为实验RFC发布，基于
document review by at least six RG members including the chairs, and based on implementation experience. This document is not an IETF product and is not a standard.
由至少六名RG成员（包括主席）根据实施经验进行文件审查。本文件不是IETF产品，也不是标准。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
OpenDHT [OPENDHT] was a public deployment of Bamboo DHT servers that ran on about 150 PlanetLab nodes, and was retired in July 2009. While the Bamboo project provided the actual software running on the servers, here we will refer only to OpenDHT, which uses a certain defined interface for the XML-RPC calls. Another service compatible with this interface is OpenLookup. One can run their own Bamboo nodes to set up a private ring of servers.
OpenDHT[OpenDHT]是竹子DHT服务器的公共部署，运行在大约150个PlanetLab节点上，于2009年7月退役。虽然Bambol项目提供了在服务器上运行的实际软件，但这里我们将只参考OpenDHT，它使用特定定义的接口进行XML-RPC调用。与此接口兼容的另一个服务是OpenLookup。你可以运行自己的竹节点来建立一个专用的服务器环。
OpenDHT was chosen because it was a well-known, publicly available DHT used within the research community. Its interface features a simple, standards-based protocol that can be easily implemented by HIP developers. This document does not aim to dictate that only the services and servers described here should be used, but is rather meant to act as a starting point to gain experience with these services, choosing tools that are readily available.
选择OpenDHT是因为它是研究社区中使用的一种众所周知的、公开可用的DHT。它的接口具有一个简单的、基于标准的协议，可以由HIP开发人员轻松实现。本文档的目的不是规定只应使用此处描述的服务和服务器，而是作为获得这些服务经验的起点，选择现成的工具。
OpenDHT stores values and indexes those values by using (hash) keys. Keys are limited to 20 bytes in length, and values can be up to 1024 bytes. Values are stored for a certain number of seconds, up to a maximum of 604,800 seconds (one week.) For more information, see the OpenDHT website: <http://www.opendht.org/>.
OpenDHT使用（散列）键存储值并索引这些值。键的长度限制为20字节，值最多可以为1024字节。值的存储时间为特定的秒数，最长为604800秒（一周）。有关更多信息，请参阅OpenDHT网站：<http://www.opendht.org/>.
Three RPC operations are supported: put, get, and rm (remove). Put is called with key and value parameters, causing the value to be stored using the key as its hash index. Get is called with the key parameter, when you have a key and want to retrieve the value. Rm is called with a hash of the value to be removed along with a secret value, a hash of which was included in the put operation.
支持三个RPC操作：put、get和rm（remove）。使用键和值参数调用Put，从而使用键作为散列索引存储值。当您有一个键并希望检索该值时，将使用key参数调用Get。使用要删除的值的散列以及一个秘密值调用Rm，put操作中包括了该秘密值的散列。
The definitions below are taken from the OpenDHT users guide at <http://opendht.org/users-guide.html>.
以下定义摘自OpenDHT用户指南，网址为<http://opendht.org/users-guide.html>.
The put operation takes the following arguments:
put操作采用以下参数：
+----------------+--------------------------------------+
| field | type |
+----------------+--------------------------------------+
| application | string |
| | |
| client_library | string |
| | |
| key | byte array, 20 bytes max. |
| | |
| value | byte array, 1024 bytes max. |
| | |
| ttl_sec | four-byte integer, max. value 604800 |
| | |
| secret_hash | optional SHA-1 hash of secret value |
+----------------+--------------------------------------+
+----------------+--------------------------------------+
| field | type |
+----------------+--------------------------------------+
| application | string |
| | |
| client_library | string |
| | |
| key | byte array, 20 bytes max. |
| | |
| value | byte array, 1024 bytes max. |
| | |
| ttl_sec | four-byte integer, max. value 604800 |
| | |
| secret_hash | optional SHA-1 hash of secret value |
+----------------+--------------------------------------+
The server replies with an integer -- 0 for "success", 1 if it is "over capacity", and 2 indicating "try again". The return code 3 indicates "failure" and is used for a modified OpenDHT server that performs signature and HIT verification, see Section 3.
服务器用一个整数进行响应--0表示“成功”，1表示“容量过大”，2表示“重试”。返回代码3表示“失败”，用于执行签名和命中验证的修改后的OpenDHT服务器，请参见第3节。
The get operation takes the following arguments:
get操作采用以下参数：
+----------------+---------------------------------------------+
| field | type |
+----------------+---------------------------------------------+
| application | string |
| | |
| client_library | string |
| | |
| key | byte array, 20 bytes max. |
| | |
| maxvals | four-byte singed integer, max. value 2^31-1 |
| | |
| placemark | byte array, 100 bytes max. |
+----------------+---------------------------------------------+
+----------------+---------------------------------------------+
| field | type |
+----------------+---------------------------------------------+
| application | string |
| | |
| client_library | string |
| | |
| key | byte array, 20 bytes max. |
| | |
| maxvals | four-byte singed integer, max. value 2^31-1 |
| | |
| placemark | byte array, 100 bytes max. |
+----------------+---------------------------------------------+
The server replies with an array of values, and a placemark that can be used for fetching additional values.
服务器用一个值数组和一个可用于获取附加值的placemark进行响应。
The rm operation takes the following arguments:
rm操作采用以下参数：
+----------------+----------------------------------------------+
| field | type |
+----------------+----------------------------------------------+
| application | string |
| | |
| client_library | string |
| | |
| key | byte array, 20 bytes max. |
| | |
| value_hash | SHA-1 hash of value to remove |
| | |
| ttl_sec | four-byte integer, max. value 604800 |
| | |
| secret | secret value (SHA-1 of this was used in put) |
+----------------+----------------------------------------------+
+----------------+----------------------------------------------+
| field | type |
+----------------+----------------------------------------------+
| application | string |
| | |
| client_library | string |
| | |
| key | byte array, 20 bytes max. |
| | |
| value_hash | SHA-1 hash of value to remove |
| | |
| ttl_sec | four-byte integer, max. value 604800 |
| | |
| secret | secret value (SHA-1 of this was used in put) |
+----------------+----------------------------------------------+
The server replies with an integer -- 0 for "success", 1 if it is "over capacity", and 2 indicating "try again".
服务器用一个整数进行响应--0表示“成功”，1表示“容量过大”，2表示“重试”。
This is the basic XML-RPC interface provided by OpenDHT. Each "field" from the above tables are XML tags that enclose their corresponding values. The key is a byte array used to index the record for storage and retrieval from the DHT. The value is a byte array of the data being stored in the DHT. The application and client_library fields are metadata used only for logging purposes. The ttl_sec field specifies the number of seconds that the DHT should store the value. The secret_hash field allows values to be later removed from the DHT. The maxvals and placemark fields are for retrieving a maximum number of values and for iterating get results.
这是OpenDHT提供的基本XML-RPC接口。上表中的每个“字段”都是XML标记，包含相应的值。键是一个字节数组，用于索引记录，以便从DHT进行存储和检索。该值是存储在DHT中的数据的字节数组。应用程序和客户端库字段是仅用于日志记录目的的元数据。ttl_sec字段指定DHT应存储该值的秒数。secret_散列字段允许以后从DHT中删除值。maxvals和placemark字段用于检索最大数量的值和迭代get结果。
The return code of 0 "success" indicates a successful put or remove operation. The return code of 1 "over capacity" means that a client is using too much storage space on the server. The return value of 2 "try again" indicates that the client should retry the put operation because a temporary problem prevented the server from accepting the put.
返回代码0“success”表示放置或删除操作成功。返回代码1“over capacity”表示客户端在服务器上使用了太多的存储空间。返回值2“重试”表示客户端应重试put操作，因为临时问题阻止服务器接受put。
In the sections that follow, specific uses for these DHT operations and their XML fields are suggested for use with HIP.
在接下来的部分中，建议将这些DHT操作及其XML字段的具体用法用于HIP。
The two lookup services described in this document use a HIP DHT Resource Record (HDRR) defined in this section. This record is a wrapper around data contained in TLVs, similar to a HIP control packet. The data contained in each HDRR differs between the two services.
本文档中描述的两个查找服务使用本节中定义的HIP DHT资源记录（HDRR）。该记录是TLV中包含的数据的包装，类似于HIP控制数据包。每个HDRR中包含的数据在两个服务之间有所不同。
The HDRR uses the same binary format as HIP packets (defined in [RFC5201].) This packet encoding is used as a convenience, even though this data is actually a resource record stored and retrieved by the DHT servers, not a packet sent on the wire by a HIP protocol daemon. Note that this HDRR format is different than the HIP RR used by the Domain Name System as defined in [RFC5205]. The reason it is different is that it is a different record from a functional point of view: in DNS, the query key is a Fully Qualified Domain Name (FQDN), and the return value is a HIT, while here, the query key is a HIT.
HDRR使用与HIP数据包相同的二进制格式（在[RFC5201]中定义）。此数据包编码是为了方便起见，即使此数据实际上是由DHT服务器存储和检索的资源记录，而不是由HIP协议守护程序在线路上发送的数据包。请注意，此HDRR格式不同于[RFC5205]中定义的域名系统使用的HIP RR。它不同的原因是，从功能角度来看，它是不同的记录：在DNS中，查询键是完全限定域名（FQDN），返回值是命中，而在这里，查询键是命中。
HIP header values for the HDRR:
HDRR的髋部标头值：
HIP Header: Packet Type = 20 DHT Resource Record SRC HIT = Sender's HIT DST HIT = NULL
HIP头：数据包类型=20 DHT资源记录SRC HIT=发送方的HIT DST HIT=NULL
HDRR used with HIT lookup: HIP ( [CERT] )
与命中查找一起使用的HDRR:HIP（[CERT]）
HDRR used with address lookup: HIP ( LOCATOR, SEQ, HOST_ID, [CERT], HIP_SIGNATURE )
HDRR与地址查找一起使用：HIP（定位器、序列、主机ID、[证书]、HIP\U签名）
The Initiator HIT (Sender's HIT, SRC HIT) MUST be set to the HIT that the host wishes to make available using the lookup service. With the HIT lookup service, this is the main piece of information returned by a get operation. For the address lookup service, this HIT MUST be the same one used to derive the HIT_KEY used as the DHT key. The Responder HIT (Receiver's HIT, DST HIT) MUST be NULL (all zeroes) since the data is intended for any host.
启动器命中（发送方命中，SRC命中）必须设置为主机希望使用查找服务提供的命中。对于点击查找服务，这是get操作返回的主要信息。对于地址查找服务，此命中必须与派生用作DHT键的命中键相同。响应者命中（接收方命中，DST命中）必须为空（全零），因为数据用于任何主机。
The only other TLV used with the HIT lookup service is an optional CERT parameter containing a certificate for validating the name that is used as the DHT key. The CERT parameter is defined in [RFC6253]. The DHT server SHOULD use the certificate to verify that the client is authorized to use the name used for the DHT key, using the hash of the name found in the certificate. The Common Name (CN) field from the Distinguished Name (DN) of the X.509.v3 certificate MUST be used. Which certificates are considered trusted is a local policy issue.
与HIT lookup服务一起使用的另一个TLV是可选的CERT参数，该参数包含用于验证用作DHT密钥的名称的证书。证书参数在[RFC6253]中定义。DHT服务器应该使用证书来验证客户端是否有权使用用于DHT密钥的名称，使用证书中找到的名称的哈希值。必须使用X.509.v3证书的可分辨名称（DN）中的公共名称（CN）字段。哪些证书被认为是可信的是本地策略问题。
The remaining parameters described here are used with the address lookup service.
此处描述的其余参数与地址查找服务一起使用。
The LOCATOR parameter contains the addresses that the host wishes to make available using the lookup service. A host MAY publish its current preferred IPv4 and IPv6 locators, for example.
LOCATOR参数包含主机希望使用查找服务提供的地址。例如，主机可以发布其当前首选的IPv4和IPv6定位器。
The SEQ parameter contains an unsigned 32-bit sequence number, the Update ID. This is typically initialized to zero and incremented by one for each new HDRR that is published by the host. The host SHOULD retain the last Update ID value it used for each HIT across reboots, or perform a self lookup in the DHT. The Update ID value may be retained in the DHT records and will determine the preferred address used by peers.
SEQ参数包含一个无符号的32位序列号，即更新ID。该序列号通常初始化为零，并对主机发布的每个新HDRR递增一。主机应保留在重新启动期间每次命中时使用的上次更新ID值，或在DHT中执行自我查找。更新ID值可保留在DHT记录中，并将确定对等方使用的首选地址。
The HOST_ID parameter contains the Host Identity that corresponds with the Sender's HIT. (The encoding of this parameter is defined in Section 5.2.8 of [RFC5201].)
HOST_ID参数包含与发送者的点击相对应的主机标识。（该参数的编码在[RFC5201]第5.2.8节中定义。）
The HOST_ID parameter and HIP_SIGNATURE parameter MUST be used with the HDRR so that HIP clients receiving the record can validate the sender and the included LOCATOR parameter. The HIT_KEY used for the DHT key will also be verified against the Host Identity.
HOST_ID参数和HIP_SIGNATURE参数必须与HDRR一起使用，以便接收记录的HIP客户端可以验证发送方和包含的定位器参数。用于DHT密钥的HIT_密钥也将根据主机标识进行验证。
The client that receives the HDRR from the DHT response MUST perform the signature and HIT_KEY verification. If the signature is invalid for the given Host Identity or the HIT_KEY used to retrieve the record does not match the Host Identity, the DHT record retrieved MUST be ignored. Note that for client-only verification, the DHT server does not need to be modified.
从DHT响应接收HDRR的客户端必须执行签名和HIT_密钥验证。如果签名对于给定的主机标识无效，或者用于检索记录的HIT_键与主机标识不匹配，则必须忽略检索到的DHT记录。请注意，对于仅客户端验证，不需要修改DHT服务器。
The Sender's HIT in the HDRR MUST correspond with the key used for the lookup and Host Identity verification. The Receiver's HIT MUST be NULL (all zeroes) in the HDRR header.
发送方在HDRR中的命中必须与用于查找和主机身份验证的密钥相对应。在HDRR报头中，接收器的命中必须为NULL（全零）。
When several HDRR records are returned by the server, the client SHOULD pick the most recent record as indicated by the Update ID in the SEQ TLV of the HDRR and perform verification on that record. The order in which records are returned should not be considered.
当服务器返回多个HDRR记录时，客户端应根据HDRR的SEQ TLV中的更新ID选择最新记录，并对该记录执行验证。不应考虑返回记录的顺序。
The DHT server MAY also verify the SIGNATURE and HOST_ID, with some modifications to the Bamboo DHT software and a new return code with the OpenDHT interface. The signature in the put MUST be verified using the given Host Identity (public key), and the HIT_KEY provided as the lookup key MUST match this Host Identity according to the Overlay Routable Cryptographic Hash Identifiers (ORCHID) generation method defined by [RFC4843]. If either signature or HIT verification
DHT服务器还可以验证签名和主机ID，对Bamboo DHT软件进行一些修改，并使用OpenDHT接口提供一个新的返回代码。put中的签名必须使用给定的主机标识（公钥）进行验证，并且作为查找密钥提供的HIT_密钥必须根据[RFC4843]定义的覆盖可路由加密哈希标识符（RAYT）生成方法与该主机标识匹配。如果签名或命中验证
fails, the put MUST not be recorded into the DHT, and the server returns a failure code. The failure code is an additional return code not defined by OpenDHT, with a value of 3.
如果发生故障，则不能将put记录到DHT中，并且服务器返回故障代码。故障代码是OpenDHT未定义的附加返回代码，值为3。
This server-side verification of records could introduce a source of a denial-of-service attack. The server policy could require clients to have an active HIP association. See Section 7 for further discussion.
这种服务器端记录验证可能会导致拒绝服务攻击。服务器策略可能要求客户端具有活动的HIP关联。进一步讨论见第7节。
This document defines a HIT lookup and address lookup service for use with HIP. The HIT lookup uses a text name to discover a peer's HIT. The address lookup uses a peer's HIT to discover its current addresses.
本文档定义了用于HIP的点击查找和地址查找服务。点击查找使用文本名称来发现对等方的点击。地址查找使用对等方的点击来发现其当前地址。
The two lookups are defined below. The abbreviated notation refers to the HIP parameter types; for example, HIP_SIG is the HIP signature parameter defined by [RFC5201].
下面定义了两个查找。缩写符号是指髋关节参数类型；例如，HIP_SIG是由[RFC5201]定义的HIP签名参数。
HDRR([CERT]) = get(SHA-1("name"))
HDRR(LOCATOR, SEQ, HOST_ID, [CERT], HIP_SIG) = get(HIT_KEY)
HDRR([CERT]) = get(SHA-1("name"))
HDRR(LOCATOR, SEQ, HOST_ID, [CERT], HIP_SIG) = get(HIT_KEY)
The HIT lookup service returns the Host Identity Tag of a peer given a name. The name SHOULD be the FQDN, hostname, or some other alias. This HIT is found in the Sender's HIT field of the HDRR. The HIT is the hash of the public-key-based Host Identity as described in [RFC5201]. There are no security properties of the name, unlike the HIT. An optional certificate MAY be included in the record, for validating the name, providing some measure of security. Which certificates are considered trusted is a local policy issue. This service is intended for use when legacy DNS servers do not support HIP resource records, or when hosts do not have administrative access to publish their own DNS records. Such an unmanaged naming service may help facilitate experimentation.
命中查找服务返回给定名称的对等主机的主机标识标记。名称应为FQDN、主机名或其他某个别名。此命中在HDRR的发送方命中字段中找到。HIT是[RFC5201]中描述的基于公钥的主机标识的散列。与HIT不同，该名称没有安全属性。记录中可能包含一个可选证书，用于验证名称，提供某种安全措施。哪些证书被认为是可信的是本地策略问题。当传统DNS服务器不支持HIP资源记录时，或当主机没有发布自己的DNS记录的管理权限时，此服务将被使用。这种非托管命名服务可能有助于促进实验。
The address lookup returns a locator and other validation data in the HDRR for a given HIT. Before a HIP association can be initiated (not in opportunistic mode), a HIP host needs to know the peer's HIT and the current address at which the peer is reachable. Often the HIT will be pre-configured, available via DNS lookup using a hostname lookup [RFC5205], or retrieved using the HIT lookup service defined in this document. With HIP mobility [RFC5206], IP addresses may be used as locators and may often change. The Host Identity and the HIT remain relatively constant and can be used to securely identify a host, so the HIT serves as a suitable DHT key for storing and retrieving addresses.
地址查找在HDRR中返回给定命中的定位器和其他验证数据。在启动HIP关联（不是在机会主义模式下）之前，HIP主机需要知道对等方的HIT和可访问对等方的当前地址。通常，HIT将预先配置，可通过使用主机名查找[RFC5205]的DNS查找获得，或使用本文档中定义的HIT查找服务检索。对于HIP mobility[RFC5206]，IP地址可以用作定位器，并且可能经常更改。主机标识和HIT保持相对恒定，可用于安全地标识主机，因此HIT可用作存储和检索地址的合适DHT密钥。
The address lookup service includes the peer's Host Identity and a signature over the locators. This allows the DHT client or server to validate the address information stored in the DHT.
地址查找服务包括对等方的主机标识和定位器上的签名。这允许DHT客户端或服务器验证存储在DHT中的地址信息。
These two separate lookups are defined instead of one because the address record is expected to change more frequently, while the name-to-HIT binding should remain relatively constant. For example, local policy may specify checking the name-to-HIT binding on a daily basis, while the address record is updated hourly for active peers. Also, the client and server validation of the two records is different, with the HIT lookup using certificates verifying the name and the address lookup using a signature produced by the bearer of a particular Host Identity/HIT.
这两个单独的查找是定义的，而不是一个，因为地址记录的更改更频繁，而命中绑定的名称应该保持相对恒定。例如，本地策略可能指定每天检查名称以命中绑定，而活动对等方的地址记录每小时更新一次。此外，这两个记录的客户端和服务器验证是不同的，HIT查找使用证书验证名称，地址查找使用特定主机标识/HIT的承载者生成的签名。
These services reduce the amount of pre-configuration required at each HIP host. The address of each peer no longer needs to be known ahead of time, if peers also participate by publishing their addresses. If peers choose to publish their HITs with a name, peer HITs also no longer require pre-configuration. However, discovering an available DHT server for servicing these lookups will require some additional configuration.
这些服务减少了每个HIP主机所需的预配置量。如果对等方也通过发布其地址参与，则不再需要提前知道每个对等方的地址。如果对等点选择使用名称发布其点击，则对等点点击也不再需要预配置。但是，发现用于服务这些查找的可用DHT服务器将需要一些额外的配置。
Given the SHA-1 hash of a name, a lookup returns the HIT of the peer. The hash of a name is used because OpenDHT keys are limited to 20 bytes, so this allows for longer names. Publish, lookup, and remove operations are defined below.
给定名称的SHA-1散列，查找将返回对等方的命中率。使用名称的散列是因为OpenDHT密钥限制为20字节，因此允许使用更长的名称。发布、查找和删除操作定义如下。
HDRR([CERT]) = get(SHA-1("name"))
put(SHA-1("name"), HDRR([CERT]), [SHA-1(secret)])
rm(SHA-1("name"), SHA-1(HDRR), secret)
HDRR([CERT]) = get(SHA-1("name"))
put(SHA-1("name"), HDRR([CERT]), [SHA-1(secret)])
rm(SHA-1("name"), SHA-1(HDRR), secret)
HIT publish
点击发布
+----------------+----------------------------------------+---------+
| field | value | data |
| | | type |
+----------------+----------------------------------------+---------+
| application | "hip-name-hit" | string |
| | | |
| client_library | (implementation dependent) | string |
| | | |
| key | SHA-1 hash of a name | base64 |
| | | encoded |
| | | |
| value | HDRR([CERT]), with the HIT to be | base64 |
| | published contained in the Sender's | encoded |
| | HIT field of the HDRR, and an optional | |
| | certificate for validating the name | |
| | used as the key | |
| | | |
| ttl_sec | lifetime for this record, value from | numeric |
| | 0-604800 seconds | string |
| | | |
| secret_hash | optional SHA-1 hash of secret value | base64 |
| | | encoded |
+----------------+----------------------------------------+---------+
+----------------+----------------------------------------+---------+
| field | value | data |
| | | type |
+----------------+----------------------------------------+---------+
| application | "hip-name-hit" | string |
| | | |
| client_library | (implementation dependent) | string |
| | | |
| key | SHA-1 hash of a name | base64 |
| | | encoded |
| | | |
| value | HDRR([CERT]), with the HIT to be | base64 |
| | published contained in the Sender's | encoded |
| | HIT field of the HDRR, and an optional | |
| | certificate for validating the name | |
| | used as the key | |
| | | |
| ttl_sec | lifetime for this record, value from | numeric |
| | 0-604800 seconds | string |
| | | |
| secret_hash | optional SHA-1 hash of secret value | base64 |
| | | encoded |
+----------------+----------------------------------------+---------+
HIT lookup
点击查找
+----------------+---------------------------------+----------------+
| field | value | data type |
+----------------+---------------------------------+----------------+
| application | "hip-name-hit" | string |
| | | |
| client_library | (implementation dependent) | string |
| | | |
| key | SHA-1 hash of a name | base64 encoded |
| | | |
| maxvals | (implementation dependent) | numeric string |
| | | |
| placemark | (NULL, or used from server | base64 encoded |
| | reply) | |
+----------------+---------------------------------+----------------+
+----------------+---------------------------------+----------------+
| field | value | data type |
+----------------+---------------------------------+----------------+
| application | "hip-name-hit" | string |
| | | |
| client_library | (implementation dependent) | string |
| | | |
| key | SHA-1 hash of a name | base64 encoded |
| | | |
| maxvals | (implementation dependent) | numeric string |
| | | |
| placemark | (NULL, or used from server | base64 encoded |
| | reply) | |
+----------------+---------------------------------+----------------+
HIT remove (optional)
点击删除（可选）
+----------------+----------------------------------------+---------+
| field | value | data |
| | | type |
+----------------+----------------------------------------+---------+
| application | "hip-name-hit" | string |
| | | |
| client_library | (implementation dependent) | string |
| | | |
| key | SHA-1 hash of a name | base64 |
| | | encoded |
| | | |
| value_hash | SHA-1 hash of HDRR (value used during | base64 |
| | publish) to remove | encoded |
| | | |
| ttl_sec | lifetime for the remove should be | numeric |
| | greater than or equal to the amount of | string |
| | time remaining for the record | |
| | | |
| secret | secret value (SHA-1 of this was used | base64 |
| | in put) | encoded |
+----------------+----------------------------------------+---------+
+----------------+----------------------------------------+---------+
| field | value | data |
| | | type |
+----------------+----------------------------------------+---------+
| application | "hip-name-hit" | string |
| | | |
| client_library | (implementation dependent) | string |
| | | |
| key | SHA-1 hash of a name | base64 |
| | | encoded |
| | | |
| value_hash | SHA-1 hash of HDRR (value used during | base64 |
| | publish) to remove | encoded |
| | | |
| ttl_sec | lifetime for the remove should be | numeric |
| | greater than or equal to the amount of | string |
| | time remaining for the record | |
| | | |
| secret | secret value (SHA-1 of this was used | base64 |
| | in put) | encoded |
+----------------+----------------------------------------+---------+
The key for both HIT publish and lookup is the SHA-1 hash of the name. The name does not necessarily need to be associated with a valid DNS or host name. It does not need to be related to the Domain Identifier found in the HI TLV. OpenDHT limits the keys to 20 bytes in length, so the SHA-1 hash is used to allow arbitrary name lengths.
点击发布和查找的关键是名称的SHA-1哈希。该名称不一定需要与有效的DNS或主机名关联。它不需要与HI TLV中找到的域标识符相关。OpenDHT将密钥的长度限制为20字节，因此使用SHA-1哈希允许任意名称长度。
The value used in the publish and lookup response MUST be the base64- encoded HDRR containing the HIT, and MAY include an optional certificate. The HIT MUST be stored in the Sender's HIT field in the HDRR header and is a 128-bit value that can be identified as a HIT both by its length and by the ORCHID prefix [RFC4843] that it starts with.
发布和查找响应中使用的值必须是包含HIT的base64编码HDRR，并且可能包括可选证书。命中必须存储在HDRR报头中发送方的命中字段中，是一个128位的值，可以通过其长度和以其开头的兰花前缀[RFC4843]将其标识为命中。
If a certificate is included in this HIT record, the name used for the DHT key MUST be listed in the certificate. The CERT parameter is defined in [RFC6253]. The Common Name (CN) field from the Distinguished Name (DN) of the X.509.v3 certificate MUST be used. The server can hash this name to verify it matches the DHT key.
如果此命中记录中包含证书，则证书中必须列出用于DHT密钥的名称。证书参数在[RFC6253]中定义。必须使用X.509.v3证书的可分辨名称（DN）中的公共名称（CN）字段。服务器可以对此名称进行散列，以验证它是否与DHT密钥匹配。
The ttl_sec field specifies the number of seconds requested by the client that the entry should be stored by the DHT server, which is implementation or policy dependent.
ttl_sec字段指定客户端请求DHT服务器存储条目的秒数，该秒数取决于实现或策略。
The secret_hash is an optional field used with HIT publish if the value will later be removed with an rm operation. It is RECOMMENDED that clients support these rm operations for the values they publish. The secret_hash contains the base64-encoded SHA-1 hash of some secret value known only to the publishing host. A different secret value SHOULD be used for each put because rm requests are visible on the network. The max_vals and placemark fields used with the HIT lookup are defined by the get XML-RPC interface.
secret_散列是一个可选字段，如果稍后将通过rm操作删除该值，则与HIT publish一起使用。建议客户端为其发布的值支持这些rm操作。secret_散列包含仅发布主机知道的某个秘密值的base64编码SHA-1散列。每个put都应使用不同的机密值，因为rm请求在网络上可见。命中查找使用的max_vals和placemark字段由get XML-RPC接口定义。
Given a HIT, a lookup returns the IP address of the peer. The address is contained in a LOCATOR TLV inside the HDRR, along with other validation data. This interface has publish, lookup, and remove operations. A summary of these three operations is listed below. The abbreviated notation refers to the HIP parameter types; for example, HIP_SIG is the HIP signature parameter defined by [RFC5201]. The details of these DHT operations is then described in greater detail.
如果命中，查找将返回对等方的IP地址。地址与其他验证数据一起包含在HDRR内的定位器TLV中。此接口具有发布、查找和删除操作。下面列出了这三项操作的摘要。缩写符号是指髋关节参数类型；例如，HIP_SIG是由[RFC5201]定义的HIP签名参数。然后更详细地描述这些DHT操作的细节。
HDRR(LOCATOR, SEQ, HOST_ID, [CERT], HIP_SIG) = get(HIT_KEY)
put(HIT_KEY, HDRR(LOCATOR, SEQ, HOST_ID, [CERT], HIP_SIG),
[SHA-1(secret)])
rm(HIT_KEY, SHA-1(HDRR), secret)
HDRR(LOCATOR, SEQ, HOST_ID, [CERT], HIP_SIG) = get(HIT_KEY)
put(HIT_KEY, HDRR(LOCATOR, SEQ, HOST_ID, [CERT], HIP_SIG),
[SHA-1(secret)])
rm(HIT_KEY, SHA-1(HDRR), secret)
The HDRR is defined in Section 3. It contains one or more locators that the peer wants to publish, a sequence number, the peer's Host Identity, an optional certificate, and a signature over the contents.
HDRR的定义见第3节。它包含对等方想要发布的一个或多个定位器、序列号、对等方的主机标识、可选证书以及内容上的签名。
The HIT_KEY is comprised of the last 100 bits of the HIT appended with 60 zero bits. This is the portion of the HIT used as a DHT key. The last 100 bits are used to avoid uneven distribution of the stored values across the DHT servers. The HIT's ORCHID Prefix (defined by [RFC4843]) is comprised of the first 28 bits, and this prefix is dropped because it is the same for all HITs, which would cause this uneven distribution. Zero padding is appended to this 100-bit value to fill the length required by the DHT, 160 bits total.
HIT_键由HIT的最后100位加上60个零位组成。这是用作DHT键的命中部分。最后100位用于避免存储值在DHT服务器之间的不均匀分布。命中的兰花前缀（由[RFC4843]定义）由前28位组成，该前缀被删除，因为它对于所有命中都是相同的，这将导致这种不均匀分布。在这个100位值后面加上零填充，以填充DHT所需的长度，总共160位。
Address publish
地址发布
+----------------+----------------------------------------+---------+
| field | value | data |
| | | type |
+----------------+----------------------------------------+---------+
| application | "hip-addr" | string |
| | | |
| client_library | (implementation dependent) | string |
| | | |
| key | HIT_KEY | base64 |
| | | encoded |
| | | |
| value | HDRR(LOCATOR, SEQ, HOST_ID, [CERT], | base64 |
| | HIP_SIG), with the IP address to be | encoded |
| | published contained in the LOCATOR TLV | |
| | in the HDRR, along with other | |
| | validation data | |
| | | |
| ttl_sec | amount of time HDRR should be valid, | numeric |
| | or the lifetime of the preferred | string |
| | address, a value from 0-604800 seconds | |
| | | |
| secret_hash | optional SHA-1 hash of secret value | base64 |
| | | encoded |
+----------------+----------------------------------------+---------+
+----------------+----------------------------------------+---------+
| field | value | data |
| | | type |
+----------------+----------------------------------------+---------+
| application | "hip-addr" | string |
| | | |
| client_library | (implementation dependent) | string |
| | | |
| key | HIT_KEY | base64 |
| | | encoded |
| | | |
| value | HDRR(LOCATOR, SEQ, HOST_ID, [CERT], | base64 |
| | HIP_SIG), with the IP address to be | encoded |
| | published contained in the LOCATOR TLV | |
| | in the HDRR, along with other | |
| | validation data | |
| | | |
| ttl_sec | amount of time HDRR should be valid, | numeric |
| | or the lifetime of the preferred | string |
| | address, a value from 0-604800 seconds | |
| | | |
| secret_hash | optional SHA-1 hash of secret value | base64 |
| | | encoded |
+----------------+----------------------------------------+---------+
Address lookup
地址查找
+----------------+---------------------------------+----------------+
| field | value | data type |
+----------------+---------------------------------+----------------+
| application | "hip-addr" | string |
| | | |
| client_library | (implementation dependent) | string |
| | | |
| key | HIT_KEY | base64 encoded |
| | | |
| maxvals | (implementation dependent) | numeric string |
| | | |
| placemark | (NULL, or used from server | base64 encoded |
| | reply) | |
+----------------+---------------------------------+----------------+
+----------------+---------------------------------+----------------+
| field | value | data type |
+----------------+---------------------------------+----------------+
| application | "hip-addr" | string |
| | | |
| client_library | (implementation dependent) | string |
| | | |
| key | HIT_KEY | base64 encoded |
| | | |
| maxvals | (implementation dependent) | numeric string |
| | | |
| placemark | (NULL, or used from server | base64 encoded |
| | reply) | |
+----------------+---------------------------------+----------------+
Address remove (optional)
地址删除（可选）
+----------------+-------------------------------------+------------+
| field | value | data type |
+----------------+-------------------------------------+------------+
| application | "hip-addr" | string |
| | | |
| client_library | (implementation dependent) | string |
| | | |
| key | HIT_KEY | base64 |
| | | encoded |
| | | |
| value_hash | SHA-1 hash of HDRR (value used | base64 |
| | during publish) to remove | encoded |
| | | |
| ttl_sec | old address lifetime | numeric |
| | | string |
| | | |
| secret | secret value (SHA-1 of this was | base64 |
| | used in put) | encoded |
+----------------+-------------------------------------+------------+
+----------------+-------------------------------------+------------+
| field | value | data type |
+----------------+-------------------------------------+------------+
| application | "hip-addr" | string |
| | | |
| client_library | (implementation dependent) | string |
| | | |
| key | HIT_KEY | base64 |
| | | encoded |
| | | |
| value_hash | SHA-1 hash of HDRR (value used | base64 |
| | during publish) to remove | encoded |
| | | |
| ttl_sec | old address lifetime | numeric |
| | | string |
| | | |
| secret | secret value (SHA-1 of this was | base64 |
| | used in put) | encoded |
+----------------+-------------------------------------+------------+
The application and client_library fields are used for logging in OpenDHT. The client_library may vary between different implementations, specifying the name of the XML-RPC library used or the application that directly makes XML-RPC calls.
应用程序和客户端库字段用于登录OpenDHT。客户端库可能在不同的实现之间有所不同，指定所使用的XML-RPC库的名称或直接进行XML-RPC调用的应用程序的名称。
The key used with the address lookup and with publishing the address is the HIT_KEY as defined above, 160 bits base64 encoded [RFC2045]. The value used in the publish and lookup response is the base64- encoded HDRR containing one or more LOCATORs.
用于地址查找和发布地址的键是上面定义的HIT_键，160位base64编码[RFC2045]。发布和查找响应中使用的值是包含一个或多个定位器的base64编码HDRR。
The ttl_sec field used with address publish indicates the time-to-live (TTL). This is the number of seconds for which the entry will be stored by the DHT. The TTL SHOULD be set to the number of seconds remaining in the address lifetime.
与地址发布一起使用的ttl_sec字段表示生存时间（ttl）。这是DHT存储条目的秒数。TTL应设置为地址生存期内剩余的秒数。
The secret_hash is an optional field that MAY be used with address publish if the value will later be removed with an rm operation. The secret_hash contains the base64-encoded SHA-1 hash of some secret value that MUST be known only to the publishing host. Clients SHOULD include the secret_hash and remove outdated values to reduce the amount of data the peer needs to handle. A different secret value SHOULD be used for each put because rm requests are visible on the network.
secret_散列是一个可选字段，如果稍后将通过rm操作删除该值，则可与地址发布一起使用。secret_散列包含某个机密值的base64编码SHA-1散列，该值必须只有发布主机知道。客户端应该包含secret_散列并删除过时的值，以减少对等方需要处理的数据量。每个put都应使用不同的机密值，因为rm请求在网络上可见。
The max_vals and placemark fields used with address lookup are defined by the get XML-RPC interface. The get operation needs to know the maximum number of values to retrieve. The placemark is a value found in the server reply that causes the get to continue to retrieve values starting where it left off.
用于地址查找的max_vals和placemark字段由get XML-RPC接口定义。get操作需要知道要检索的最大值数。placemark是在服务器应答中找到的一个值，它使get从停止的位置继续检索值。
Below are some suggestions of when a HIP implementation MAY want to use the HIT and address lookup services.
以下是HIP实现何时需要使用HIT和地址查找服务的一些建议。
To learn of a peer's HIT, a host might first consult DNS using the peer's hostname if the DNS server supports the HIP resource record defined by [RFC5205]. Sometimes hosts do not have administrative authority over their DNS entries and/or the DNS server is not able to support HIP resource records. Hosts may want to associate other non-DNS names with their HITs. For these and other reasons, a host MAY use the HIT publish service defined in Section 4.1. The peer HIT may be learned by performing a DHT lookup of such a name.
如果DNS服务器支持[RFC5205]定义的HIP资源记录，则主机可能首先使用对等机的主机名查询DNS，以了解对等机的命中情况。有时主机对其DNS条目没有管理权限和/或DNS服务器无法支持HIP资源记录。主机可能希望将其他非DNS名称与其点击关联。出于这些和其他原因，主机可以使用第4.1节中定义的HIT发布服务。对等命中可以通过对这样的名称执行DHT查找来学习。
Once a peer HIT is learned or configured, an address lookup MAY be performed so that the LOCATORs can be cached and immediately available for when an association is requested. Implementations might load a list of peer HITs on startup, resulting in several lookups that can take some time to complete.
一旦识别或配置了对等命中，就可以执行地址查找，以便在请求关联时可以缓存和立即使用定位器。实现可能会在启动时加载一个对等点击列表，从而导致需要一些时间才能完成的几次查找。
However, cached LOCATORs may quickly become obsolete, depending on how often the peer changes its preferred address. Performing an address lookup before sending the I1 may be needed. At this time, the latency of a lookup may be intolerable, and a lookup could instead be performed after the I1 retransmission timer fires -- when no R1 reply has been received -- to detect any change in address.
但是，缓存的定位器可能很快就会过时，这取决于对等方更改其首选地址的频率。可能需要在发送I1之前执行地址查找。此时，查找的延迟可能无法忍受，可以在I1重传计时器触发后执行查找（当没有收到R1应答时），以检测地址的任何更改。
A HIP host SHOULD publish its preferred LOCATORs upon startup, so other hosts may determine where it is reachable. The host SHOULD periodically refresh its HDRR entry because each entry carries a TTL and will eventually expire. Also, when there is a change in the preferred address, usually associated with sending UPDATE packets with included locator parameters, the host SHOULD update its HDRR with the DHT. The old HDRR SHOULD be removed using the rm operation, if a secret value was used in the put.
HIP主机应在启动时发布其首选定位器，以便其他主机可以确定其可访问的位置。主机应定期刷新其HDRR条目，因为每个条目都带有TTL，并且最终将过期。此外，当首选地址发生变化时（通常与发送包含定位器参数的更新包相关），主机应使用DHT更新其HDRR。如果put中使用了秘密值，则应使用rm操作删除旧HDRR。
Addresses from the private address space SHOULD NOT be published to the DHT. If the host is located behind a NAT, for example, the host could publish the address of its Rendezvous Server (RVS, from [RFC5204]) to the DHT if that is how it is reachable. In this case, however, a peer could instead simply use the RVS field of the NATed host's HIP DNS record, which would eliminate a separate DHT lookup.
私人地址空间中的地址不应发布到DHT。例如，如果主机位于NAT后面，则主机可以将其会合服务器（RVS，从[RFC5204]）的地址发布到DHT（如果可以访问）。然而，在这种情况下，对等方可以只使用主机HIP DNS记录的RVS字段，这将消除单独的DHT查找。
A HIP host SHOULD also publish its HIT upon startup or whenever a new HIT is configured, for use with the HIT lookup service, if desired. The host SHOULD first check if the name already exists in the DHT by performing a lookup, to avoid interfering with an existing name-to-HIT mapping. The name-to-HIT binding needs to be refreshed periodically before the TTL expires.
HIP主机还应在启动时或配置新HIT时发布其HIT，以便在需要时与HIT查找服务一起使用。主机应该首先通过执行查找来检查名称是否已经存在于DHT中，以避免干扰现有的名称到命中的映射。要命中绑定的名称需要在TTL过期之前定期刷新。
When publishing data to the DHT server, care should be taken to check the response from the server. The server may respond with an "over capacity" code, indicating that its resources are too burdened to honor the given size and TTL. The host SHOULD then select another server for publishing or reduce the TTL and retry the put operation.
将数据发布到DHT服务器时，应注意检查服务器的响应。服务器可能会响应“容量过大”代码，表明其资源负担过重，无法满足给定的大小和TTL。然后，主机应选择另一台服务器进行发布或减少TTL，然后重试put操作。
The DHT put operation does not replace existing values. If a host does not remove its old HDRR before adding another, several entries may be present. A client performing a lookup SHOULD determine the most recent address based on the Update ID from the SEQ TLV of the HDRR. The order of values returned in the server's response may not be guaranteed. Before performing each put, a host SHOULD remove its old HDRR data using the rm operation.
DHT put操作不会替换现有值。如果主机在添加另一个HDRR之前未删除其旧HDRR，则可能存在多个条目。执行查找的客户端应根据HDRR的SEQ TLV中的更新ID确定最新地址。服务器响应中返回的值的顺序可能无法保证。在执行每个put之前，主机应使用rm操作删除其旧HDRR数据。
In the case of the HIT lookup service, there is nothing preventing different hosts from publishing the same name. A lookup performed on this name will return multiple HITs that belong to different devices. The server may enforce a policy that requires clients to include a certificate when publishing a HIT, and only store HITs with a name that has been authorized by some trusted certificate. Otherwise, this is an unmanaged free-for-all service, and it is RECOMMENDED that a host simply pick another name.
在HIT lookup服务的情况下，没有任何东西可以阻止不同的主机发布相同的名称。对该名称执行的查找将返回属于不同设备的多个点击。服务器可能强制执行一个策略，要求客户端在发布命中时包含证书，并且仅存储具有某个受信任证书授权名称的命中。否则，这是一个非托管的免费服务，建议主机选择另一个名称。
Selecting an appropriate DHT server to use is not covered here. If a particular server becomes unavailable, the connect will timeout and some server selection algorithm SHOULD be performed, such as trying the next server in a configured list. OpenDHT formerly provided a DNS-based anycast service; when one performed a lookup of "opendht.nyuld.net", it returned the two nearest OpenDHT servers.
这里不包括选择要使用的适当DHT服务器。如果特定服务器不可用，则连接将超时，并应执行某些服务器选择算法，例如尝试配置列表中的下一台服务器。OpenDHT以前提供了基于DNS的选播服务；当其中一个执行“opendht.nyuld.net”查找时，它返回两个最近的opendht服务器。
The latency involved with the DHT put and get operations should be considered when using these services with HIP. The calls rely on servers that may be located across the Internet and may trigger communications between servers that add delay. The DHT operations themselves may be slow to produce a response.
在将这些服务与HIP一起使用时，应考虑DHT put和get操作所涉及的延迟。这些呼叫依赖于可能位于Internet上的服务器，并可能触发服务器之间的通信，从而增加延迟。DHT操作本身可能反应缓慢。
The maximum size of 1024 bytes for the value field will limit the maximum size of the Host Identity and certificates that may be used within the HDRR.
值字段的最大大小为1024字节，这将限制HDRR中可能使用的主机标识和证书的最大大小。
There are two classes of attacks on this information exchange between the host and DHT server: attacks on the validity of the information provided by the DHT to the host (such as a spoofed DHT response) and attacks on the DHT records themselves (such as polluted records for a given key). Without the server performing some measure of verification, not much can be done to prevent these attacks.
主机和DHT服务器之间的信息交换存在两类攻击：对DHT提供给主机的信息的有效性的攻击（如伪造的DHT响应）和对DHT记录本身的攻击（如对给定密钥的污染记录）。如果服务器不执行某种程度的验证，就无法采取很多措施来防止这些攻击。
For the HIT lookup based on a name (Section 4.1), there are no guarantees on the validity of the HIT. Users concerned with the validity of HITs found in the DHT SHOULD simply exchange HITs out-of-band with peers. Including a signature will not help here because the HIT that identifies the Host Identity for signing is not known ahead of time. A certificate MAY be included with the HIT, which guarantees that the name used for the lookup has been authorized by some third-party authority. Which certificates are considered trusted is a local policy issue.
对于基于名称的命中查找（第4.1节），无法保证命中的有效性。关注DHT中点击有效性的用户只需在带外与同行交换点击即可。在这里包含签名没有帮助，因为标识要签名的主机标识的HIT在时间之前是未知的。HIT中可能包含一个证书，它保证用于查找的名称已获得某个第三方机构的授权。哪些证书被认为是可信的是本地策略问题。
For the address lookup based on HIT (Section 4.2), the validity of the DHT response MUST be checked with the HOST_ID and SIGNATURE parameters in the HDRR. A HIP initiating host SHOULD also validate the DHT response after the R1 message is received during a HIP exchange. The Host Identity provided in the R1 can be hashed to obtain a HIT that MUST be checked against the original HIT. However, a legacy OpenDHT service without server modifications does not prevent an attacker from polluting the DHT records for a known HIT, thereby causing a denial-of-service attack, since server validation is not performed.
对于基于HIT的地址查找（第4.2节），必须使用HDRR中的主机ID和签名参数检查DHT响应的有效性。HIP启动主机还应在HIP交换期间收到R1消息后验证DHT响应。R1中提供的主机标识可以散列以获得必须对照原始命中进行检查的命中。但是，未经服务器修改的传统OpenDHT服务无法防止攻击者污染DHT记录以获取已知命中，从而导致拒绝服务攻击，因为未执行服务器验证。
Relying solely on client validation may be harmful. An attacker can replay the put packets containing the signed HDRR, possibly causing stale or invalid information to exist in the DHT. If an attacker replays the signed put message and changes some aspect each time, and if the server is not performing signature and HIT validation, there could be a multitude of invalid entries stored in the DHT. When a client retrieves these records, it would need to perform signature and HIT verification on each one, which could cause unacceptable amounts of delay or computation.
仅仅依靠客户验证可能是有害的。攻击者可以重播包含签名HDRR的put数据包，可能导致DHT中存在过时或无效信息。如果攻击者重放已签名的put消息并每次更改某些方面，并且如果服务器未执行签名和命中验证，则DHT中可能会存储大量无效条目。当客户端检索这些记录时，它需要对每个记录执行签名和命中验证，这可能会导致不可接受的延迟或计算量。
To protect against this type of attack, the DHT server SHOULD perform signature and HIT verification of each put operation as described in Section 3. Another option would be the server running HIP itself and requiring client authentication with a HIP association before accepting HDRR puts. Further validation would be only accepting HIT and address records from the association bound to the same HIT.
为了防止这种类型的攻击，DHT服务器应该按照第3节所述对每个put操作执行签名和命中验证。另一个选项是服务器本身运行HIP，并且在接受HDRR puts之前需要使用HIP关联进行客户端身份验证。进一步的验证将只接受来自绑定到同一命中的关联的命中和地址记录。
Performing server-side verification adds to the processing burden of the DHT server and may be a source for a denial-of-service attack. Requiring a HIP association before accepting HDRR puts may help here. The HIT verification is less computationally intensive by design, using a hash algorithm. Certificate validation (for name lookups) and signature verification (for HDRRs) may cause unacceptable amounts of computation. A server may rate limit the number of puts that it allows.
执行服务器端验证会增加DHT服务器的处理负担，可能是拒绝服务攻击的来源。在接受HDRR puts之前需要髋关节联合可能会有所帮助。通过设计，使用哈希算法，命中验证的计算强度更小。证书验证（用于名称查找）和签名验证（用于HDRRs）可能会导致不可接受的计算量。服务器可能会限制其允许的put数量。
The SHA-1 message digest algorithm is used in two ways in this document, and the security of using this algorithm should be considered within the context of [RFC6194]. The first use is with the OpenDHT put and remove operations, described in Section 2, and the second is to reduce the size of the name string for the HIT lookup service in Section 4.1.
本文件以两种方式使用SHA-1消息摘要算法，应在[RFC6194]的上下文中考虑使用该算法的安全性。第一个用途是第2节中描述的OpenDHT put和remove操作，第二个用途是减少第4.1节中命中查找服务的名称字符串的大小。
The first use is intended to protect the secret values used to store records in the DHT as described by the OpenDHT interface. An attacker would be able to remove a record, after capturing the plaintext put, if a secret value could be found that produces the same secret hash. The purpose of this document is to maintain interoperable compatibility with that interface, which prescribes the use of SHA-1. Future revisions of that interface should consider hash algorithm agility. The OpenDHT FAQ states that future support for other hash algorithms is planned.
第一个用途旨在保护用于在DHT中存储记录的秘密值，如OpenDHT接口所述。在捕获明文put后，如果可以找到产生相同秘密哈希的秘密值，攻击者将能够删除记录。本文件的目的是保持与该接口的互操作兼容性，该接口规定了SHA-1的使用。该接口的未来修订应该考虑哈希算法敏捷性。OpenDHT FAQ声明，计划将来支持其他哈希算法。
The second use of the SHA-1 algorithm is to reduce the arbitrarily sized name strings to fit the fixed OpenDHT key size. No security properties of the SHA-1 algorithm are used in this context.
SHA-1算法的第二个用途是减少任意大小的名称字符串，以适应固定的OpenDHT密钥大小。在此上下文中未使用SHA-1算法的安全属性。
This document defines a new HIP Packet Type, the "HIP Distributed Hash Table Resource Record (HDRR)". This packet type is defined in Section 3 with a value of 20.
本文档定义了一种新的HIP数据包类型，即“HIP分布式哈希表资源记录（HDRR）”。该数据包类型在第3节中定义为值20。
Thanks to Tom Henderson, Samu Varjonen, Andrei Gurtov, Miika Komu, Kristian Slavov, Ken Rimey, Ari Keranen, and Martin Stiemerling for providing comments. Samu most notably contributed the resolver packet and its suggested parameters, which became the HDRR here.
感谢Tom Henderson、Samu Varjonen、Andrei Gurtov、Miika Komu、Kristian Slavov、Ken Rimey、Ari Keranen和Martin Stiemerling提供的评论。Samu最显著的贡献是解析器包及其建议的参数，在这里成为HDRR。
[OPENDHT] Rhea, S., Godfrey, B., Karp, B., Kubiatowicz, J., Ratnasamy, S., Shenker, S., Stocia, I., and H. Yu, "OpenDHT: A Public DHT Service and Its Uses", Proceedings of ACM SIGCOMM 2005, August 2005.
[OPENDHT]Rhea，S.，Godfrey，B.，Karp，B.，Kubiatowicz，J.，Ratnasamy，S.，Shenker，S.，Stocia，I.，和H.Yu，“OPENDHT：公共DHT服务及其使用”，《ACM SIGCOMM 2005年会议录》，2005年8月。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[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月。
[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月。
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms", RFC 6194, March 2011.
[RFC6194]Polk，T.，Chen，L.，Turner，S.，和P.Hoffman，“SHA-0和SHA-1消息摘要算法的安全考虑”，RFC 61942011年3月。
[RFC6253] Heer, T. and S. Varjonen, "Host Identity Protocol Certificates", RFC 6253, May 2011.
[RFC6253]Heer，T.和S.Varjonen，“主机身份协议证书”，RFC 6253，2011年5月。
[HIT2IP] Ponomarev, O. and A. Gurtov, "Embedding Host Identity Tags Data in DNS", Work in Progress, July 2009.
[HIT2IP]Ponomarev，O.和A.Gurtov，“在DNS中嵌入主机身份标签数据”，正在进行的工作，2009年7月。
[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月。
[RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008.
[RFC5206]Nikander，P.，Henderson，T.，Vogt，C.，和J.Arkko，“使用主机身份协议的终端主机移动性和多宿”，RFC 52062008年4月。
Author's Address
作者地址
Jeff Ahrenholz The Boeing Company P.O. Box 3707 Seattle, WA USA
Jeff Ahrenholz波音公司美国华盛顿州西雅图3707号邮政信箱
EMail: jeffrey.m.ahrenholz@boeing.com
EMail: jeffrey.m.ahrenholz@boeing.com