Internet Engineering Task Force (IETF) J. Laganier
Request for Comments: 8005 Luminate Wireless, Inc.
Obsoletes: 5205 October 2016
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) J. Laganier
Request for Comments: 8005 Luminate Wireless, Inc.
Obsoletes: 5205 October 2016
Category: Standards Track
ISSN: 2070-1721
Host Identity Protocol (HIP) Domain Name System (DNS) Extension
主机标识协议（HIP）域名系统（DNS）扩展
Abstract
摘要
This document specifies a resource record (RR) for the Domain Name System (DNS) and how to use it with the Host Identity Protocol (HIP). This RR allows a HIP node to store in the DNS its Host Identity (HI), the public component of the node public-private key pair; its Host Identity Tag (HIT), a truncated hash of its public key (PK); and the domain names of its rendezvous servers (RVSs). This document obsoletes RFC 5205.
本文档指定了域名系统（DNS）的资源记录（RR）以及如何将其与主机标识协议（HIP）一起使用。该RR允许HIP节点在DNS中存储其主机标识（HI），即节点公私密钥对的公共组件；其主机标识标签（HIT），其公钥（PK）的截断散列；以及其会合服务器（RVS）的域名。本文件淘汰了RFC 5205。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第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/rfc8005.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8005.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Simple Static Single-Homed End Host . . . . . . . . . . . 5
3.2. Mobile End Host . . . . . . . . . . . . . . . . . . . . . 6
4. Overview of Using the DNS with HIP . . . . . . . . . . . . . 7
4.1. Storing HI, HIT, and RVS in the DNS . . . . . . . . . . . 7
4.2. Initiating Connections Based on DNS Names . . . . . . . . 8
5. HIP RR Storage Format . . . . . . . . . . . . . . . . . . . . 9
5.1. HIT Length Format . . . . . . . . . . . . . . . . . . . . 9
5.2. PK Algorithm Format . . . . . . . . . . . . . . . . . . . 9
5.3. PK Length Format . . . . . . . . . . . . . . . . . . . . 10
5.4. HIT Format . . . . . . . . . . . . . . . . . . . . . . . 10
5.5. Public Key Format . . . . . . . . . . . . . . . . . . . . 10
5.6. Rendezvous Servers Format . . . . . . . . . . . . . . . . 10
6. HIP RR Presentation Format . . . . . . . . . . . . . . . . . 11
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8.1. Attacker Tampering with an Insecure HIP RR . . . . . . . 13
8.2. Hash and HITs Collisions . . . . . . . . . . . . . . . . 13
8.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Changes from RFC 5205 . . . . . . . . . . . . . . . 17
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Simple Static Single-Homed End Host . . . . . . . . . . . 5
3.2. Mobile End Host . . . . . . . . . . . . . . . . . . . . . 6
4. Overview of Using the DNS with HIP . . . . . . . . . . . . . 7
4.1. Storing HI, HIT, and RVS in the DNS . . . . . . . . . . . 7
4.2. Initiating Connections Based on DNS Names . . . . . . . . 8
5. HIP RR Storage Format . . . . . . . . . . . . . . . . . . . . 9
5.1. HIT Length Format . . . . . . . . . . . . . . . . . . . . 9
5.2. PK Algorithm Format . . . . . . . . . . . . . . . . . . . 9
5.3. PK Length Format . . . . . . . . . . . . . . . . . . . . 10
5.4. HIT Format . . . . . . . . . . . . . . . . . . . . . . . 10
5.5. Public Key Format . . . . . . . . . . . . . . . . . . . . 10
5.6. Rendezvous Servers Format . . . . . . . . . . . . . . . . 10
6. HIP RR Presentation Format . . . . . . . . . . . . . . . . . 11
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8.1. Attacker Tampering with an Insecure HIP RR . . . . . . . 13
8.2. Hash and HITs Collisions . . . . . . . . . . . . . . . . 13
8.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Changes from RFC 5205 . . . . . . . . . . . . . . . 17
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
This document specifies a resource record (RR) for the Domain Name System (DNS) [RFC1034] and how to use it with the Host Identity Protocol (HIP) [RFC7401]. This RR allows a HIP node to store in the DNS its Host Identity (HI), the public component of the node public-private key pair; its Host Identity Tag (HIT), a truncated hash of its HI; and the domain names of its rendezvous servers (RVSs) [RFC8004].
本文档指定了域名系统（DNS）[RFC1034]的资源记录（RR）以及如何将其与主机标识协议（HIP）[RFC7401]一起使用。该RR允许HIP节点在DNS中存储其主机标识（HI），即节点公私密钥对的公共组件；它的主机标识标签（HIT），HI的截断散列；以及其会合服务器（RVS）[RFC8004]的域名。
Currently, most of the Internet applications that need to communicate with a remote host first translate a domain name (often obtained via user input) into one or more IP addresses. This step occurs prior to communication with the remote host and relies on a DNS lookup.
目前，大多数需要与远程主机通信的Internet应用程序首先将域名（通常通过用户输入获得）转换为一个或多个IP地址。此步骤发生在与远程主机通信之前，并依赖DNS查找。
With HIP, IP addresses are intended to be used mostly for on-the-wire communication between end hosts, while most Upper Layer Protocols (ULPs) and applications use HIs or HITs instead (ICMP might be an example of a ULP not using them). Consequently, we need a means to translate a domain name into an HI. Using the DNS for this translation is pretty straightforward: We define a HIP RR. Upon query by an application or ULP for a name-to-IP-address lookup, the resolver would then additionally perform a name-to-HI lookup and use it to construct the resulting HI-to-IP-address mapping (which is internal to the HIP layer). The HIP layer uses the HI-to-IP-address mapping to translate HIs and HITs into IP addresses, and vice versa.
对于HIP，IP地址主要用于终端主机之间的有线通信，而大多数上层协议（ULP）和应用程序使用HIs或HITs（ICMP可能是ULP不使用HIs或HITs的一个示例）。因此，我们需要一种将域名转换为HI的方法。使用DNS进行此转换非常简单：我们定义HIP RR。当应用程序或ULP查询名称到IP地址的查找时，解析程序将另外执行名称到HI的查找，并使用它来构造生成的HI到IP地址映射（HIP层内部）。HIP层使用HI到IP地址映射将HI和HIT转换为IP地址，反之亦然。
The HIP specification [RFC7401] specifies the HIP base exchange between a HIP Initiator and a HIP Responder based on a four-way handshake involving a total of four HIP packets (I1, R1, I2, and R2). Since the HIP packets contain both the Initiator and the Responder HIT, the Initiator needs to have knowledge of the Responder's HI and HIT prior to initiating the base exchange by sending an I1 packet.
HIP规范[RFC7401]规定了基于四向握手的HIP启动器和HIP响应器之间的HIP基址交换，该握手涉及总共四个HIP数据包（I1、R1、I2和R2）。由于HIP数据包同时包含发起方和响应方HIT，发起方需要在通过发送I1数据包发起基本交换之前了解响应方的HI和HIT。
The HIP Rendezvous Extension [RFC8004] allows a HIP node to be reached via the IP address(es) of a third party, the node's RVS. An Initiator willing to establish a HIP association with a Responder served by an RVS would typically initiate a HIP base exchange by sending the I1 packet initiating the exchange towards the RVS IP address rather than towards the Responder IP address. Consequently, we need a means to find the name of an RVS for a given host name.
髋关节会合扩展[RFC8004]允许通过第三方（节点的RVS）的IP地址到达髋关节节点。愿意与RVS服务的响应者建立HIP关联的发起者通常将通过向RVS IP地址而不是向响应者IP地址发送发起交换的I1分组来发起HIP基交换。因此，我们需要一种方法来查找给定主机名的RVS名称。
This document introduces the HIP DNS RR to store the RVS, HI, and HIT information.
本文档介绍了HIP DNS RR以存储RVS、HI和HIT信息。
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]中所述进行解释。
In this section, we briefly introduce a number of usage scenarios where the DNS is useful with HIP.
在本节中，我们将简要介绍一些DNS与HIP结合使用的使用场景。
With HIP, most applications and ULPs are unaware of the IP addresses used to carry packets on the wire. Consequently, a HIP node could take advantage of having multiple IP addresses for failover, redundancy, mobility, or renumbering, in a manner that is transparent to most ULPs and applications (because they are bound to HIs; hence, they are agnostic to these IP address changes).
对于HIP，大多数应用程序和ULP不知道用于在线路上传输数据包的IP地址。因此，HIP节点可以以对大多数ULP和应用程序透明的方式利用多个IP地址进行故障切换、冗余、移动或重新编号（因为它们绑定到HIs；因此，它们对这些IP地址更改不可知）。
In these situations, for a node to be reachable by reference to its Fully Qualified Domain Name (FQDN), the following information should be stored in the DNS:
在这些情况下，要通过引用其完全限定域名（FQDN）来访问节点，DNS中应存储以下信息：
o A set of IP addresses via A [RFC1035] and AAAA [RFC3596] Resource Record Sets (RRSets) [RFC2181].
o 通过[RFC1035]和AAAA[RFC3596]资源记录集（RRSets）[RFC2181]的一组IP地址。
o An HI, a HIT, and possibly a set of RVSs through HIP RRs.
o HI，HIT，可能还有一组通过髋关节RRs的RVS。
The HIP RR is class independent.
HIP RR是独立于类的。
When a HIP node wants to initiate communication with another HIP node, it first needs to perform a HIP base exchange to set up a HIP association towards its peer. Although such an exchange can be initiated opportunistically, i.e., without prior knowledge of the Responder's HI, by doing so both nodes knowingly risk man-in-the-middle (MitM) attacks on the HIP exchange. To prevent these attacks, it is recommended that the Initiator first obtains the HI of the Responder and then initiates the exchange. This can be done, for example, through manual configuration or DNS lookups. Hence, a HIP RR is introduced.
当一个髋关节节点想要启动与另一个髋关节节点的通信时，它首先需要执行髋关节基础交换，以建立与对等节点的髋关节关联。尽管这样的交换可以机会主义地发起，即，在事先不知道响应者的HI的情况下，通过这样做，两个节点都有意地冒着中间人（MitM）攻击髋部交换的风险。为了防止这些攻击，建议发起方首先获取响应方的HI，然后发起交换。例如，可以通过手动配置或DNS查找来完成此操作。因此，引入了HIP RR。
When a HIP node is frequently changing its IP address(es), the natural DNS latency for propagating changes may prevent it from publishing its new IP address(es) in the DNS. For solving this problem, the HIP Architecture [RFC4423] introduces RVSs [RFC8004]. A HIP host uses an RVS as a rendezvous point to maintain reachability with possible HIP Initiators while moving [RFC5206]. Such a HIP node would publish in the DNS its RVS domain name(s) in a HIP RR, while keeping its RVS up-to-date with its current set of IP addresses.
当HIP节点频繁更改其IP地址时，传播更改的自然DNS延迟可能会阻止其在DNS中发布新的IP地址。为了解决这个问题，HIP体系结构[RFC4423]引入了RVSs[RFC8004]。HIP主机使用RVS作为会合点，以在移动时保持与可能的HIP启动器的可达性[RFC5206]。这样的HIP节点将在DNS中发布HIP RR中的RVS域名，同时保持其RVS与其当前IP地址集保持最新。
When a HIP node wants to initiate a HIP exchange with a Responder, it will perform a number of DNS lookups. Depending on the type of implementation, the order in which those lookups will be issued may vary. For instance, implementations using HIT in Application Programming Interfaces (APIs) may typically first query for HIP RRs at the Responder FQDN, while those using an IP address in APIs may typically first query for A and/or AAAA RRs.
当HIP节点想要启动与响应者的HIP交换时，它将执行大量DNS查找。根据实现的类型，发出这些查找的顺序可能会有所不同。例如，在应用程序编程接口（API）中使用HIT的实现通常可以首先在响应者FQDN处查询HIP RRs，而在API中使用IP地址的实现通常可以首先查询和/或AAAA RRs。
In the following, we assume that the Initiator first queries for HIP RRs at the Responder FQDN.
在下文中，我们假设发起者首先在响应者FQDN处查询HIP RRs。
If the query for the HIP type was responded to with a DNS answer with RCODE=3 (Name Error), then the Responder's information is not present in the DNS, and further queries for the same owner name SHOULD NOT be made.
如果对HIP类型的查询的响应是RCODE=3的DNS应答（名称错误），则DNS中不存在响应者的信息，不应进一步查询相同的所有者名称。
In case the query for the HIP records returned a DNS answer with RCODE=0 (No Error) and an empty answer section, it means that no HIP information is available at the Responder name. In such a case, if the Initiator has been configured with a policy to fall back to opportunistic HIP (initiating without knowing the Responder's HI) or plain IP, it would send out more queries for A and AAAA types at the Responder's FQDN.
如果对HIP记录的查询返回RCODE=0（无错误）的DNS应答和空应答部分，则表示在响应者名称处没有可用的HIP信息。在这种情况下，如果启动器配置了一个策略以退回到机会主义HIP（在不知道响应者的HI的情况下启动）或普通IP，则它将在响应者的FQDN处发送更多关于a和AAAA类型的查询。
Depending on the combinations of answers, the situations described in Sections 3.1 and 3.2 can occur.
根据答案的组合，可能出现第3.1节和第3.2节中描述的情况。
Note that storing HIP RR information in the DNS at an FQDN that is assigned to a non-HIP node might have ill effects on its reachability by HIP nodes.
请注意，在分配给非HIP节点的FQDN处的DNS中存储HIP RR信息可能会对HIP节点的可达性产生不良影响。
In addition to its IP address or addresses (IP-R), a HIP node (R) with a single static network attachment that wishes to be reachable by reference to its FQDN (www.example.com) to act as a Responder would store in the DNS a HIP RR containing its Host Identity (HI-R) and Host Identity Tag (HIT-R).
除了其IP地址（IP-R）之外，具有单个静态网络附件的HIP节点（R）希望通过引用其FQDN（www.example.com）来访问以充当响应者，该HIP节点（R）将在DNS中存储包含其主机标识（HI-R）和主机标识标签（HIT-R）的HIP RR。
An Initiator willing to associate with a node would typically issue the following queries:
愿意与节点关联的启动器通常会发出以下查询：
o Query #1: QNAME=www.example.com, QTYPE=HIP
o 查询#1:QNAME=www.example.com，QTYPE=HIP
(QCLASS=IN is assumed and omitted from the examples)
（假设QCLASS=IN，并从示例中省略）
Which returns a DNS packet with RCODE=0 and one or more HIP RRs with the HIT and HI (e.g., HIT-R and HI-R) of the Responder in the answer section, but no RVS.
它返回一个RCODE=0的DNS数据包和一个或多个HIP RRs，其中应答器的HIT和HI（例如HIT-R和HI-R）位于应答部分，但不返回RVS。
o Query #2: QNAME=www.example.com, QTYPE=A
o 查询#2:QNAME=www.example.com，QTYPE=A
o Query #3: QNAME=www.example.com, QTYPE=AAAA
o 查询#3:QNAME=www.example.com，QTYPE=AAAA
Which would return DNS packets with RCODE=0 and, respectively, one or more A or AAAA RRs containing the IP address(es) of the Responder (e.g., IP-R) in their answer sections.
它将返回RCODE=0的DNS数据包，并分别返回一个或多个A或AAAA RRs，其中包含应答器（例如，IP-R）在其应答部分中的IP地址。
Caption: In the remainder of this document, for the sake of keeping diagrams simple and concise, several DNS queries and answers are represented as one single transaction, while in fact there are several queries and answers flowing back and forth, as described in the textual examples.
标题：在本文档的其余部分中，为了保持图表的简单和简洁，多个DNS查询和答案表示为一个事务，而事实上，如文本示例中所述，有多个查询和答案来回流动。
[HIP? A? ]
[www.example.com] +-----+
+-------------------------------->| |
| | DNS |
| +-------------------------------| |
| | [HIP? A? ] +-----+
| | [www.example.com]
| | [HIP HIT-R HI-R ]
| | [A IP-R ]
| v
+-----+ +-----+
| |--------------I1------------->| |
| I |<-------------R1--------------| R |
| |--------------I2------------->| |
| |<-------------R2--------------| |
+-----+ +-----+
[HIP? A? ]
[www.example.com] +-----+
+-------------------------------->| |
| | DNS |
| +-------------------------------| |
| | [HIP? A? ] +-----+
| | [www.example.com]
| | [HIP HIT-R HI-R ]
| | [A IP-R ]
| v
+-----+ +-----+
| |--------------I1------------->| |
| I |<-------------R1--------------| R |
| |--------------I2------------->| |
| |<-------------R2--------------| |
+-----+ +-----+
Static Single-Homed Host
静态单宿主主机
The Initiator would then send an I1 to the Responder's IP addresses (IP-R).
然后，发起者将向响应者的IP地址（IP-R）发送I1。
A mobile HIP node (R) wishing to be reachable by reference to its FQDN (www.example.com) would store in the DNS, possibly in addition to its IP address or addresses (IP-R), its HI (HI-R), its HIT (HIT-R), and the domain name or names of its RVS or servers (e.g., rvs.example.com) in a HIP RR or records. The mobile HIP node also needs to notify its RVSs of any change in its set of IP addresses.
希望通过引用其FQDN（www.example.com）来访问的移动HIP节点（R）将可能除了其IP地址（IP-R）、HI（HI-R）、HIT（HIT-R）和其RVS或服务器（例如RVS.example.com）的域名或名称以外，还存储在HIP RR或记录中的DNS中。移动HIP节点还需要将其IP地址集的任何更改通知其RVS。
An Initiator willing to associate with such a mobile node would typically issue the following queries:
愿意与这样的移动节点关联的发起方通常会发出以下查询：
o Query #1: QNAME=www.example.com, QTYPE=HIP
o 查询#1:QNAME=www.example.com，QTYPE=HIP
Which returns a DNS packet with RCODE=0 and one or more HIP RRs with the HIT, HI, and RVS domain name or names (e.g., HIT-R, HI-R, and rvs.example.com) of the Responder in the answer section.
它返回一个RCODE=0的DNS数据包和一个或多个HIP RRs，其中包含应答器在应答部分的HIT、HI和RVS域名（例如HIT-R、HI-R和RVS.example.com）。
o Query #2: QNAME=rvs.example.com, QTYPE=A
o 查询#2:QNAME=rvs.example.com，QTYPE=A
o Query #3: QNAME=rvs.example.com, QTYPE=AAAA
o 查询#3:QNAME=rvs.example.com，QTYPE=AAAA
Which return DNS packets with RCODE=0 and, respectively, one or more A or AAAA RRs containing an IP address(es) of the Responder's RVS (e.g., IP-RVS) in their answer sections.
返回RCODE=0的DNS数据包，并分别返回一个或多个A或AAAA RRs，其中包含应答器RVS（例如IP-RVS）在其应答部分中的IP地址。
[HIP? ] [www.example.com]
[HIP？][www.example.com]
[A? ]
[rvs.example.com] +-----+
+----------------------------------------->| |
| | DNS |
| +----------------------------------------| |
| | [HIP? ] +-----+
| | [www.example.com ]
| | [HIP HIT-R HI-R rvs.example.com]
| |
| | [A? ]
| | [rvs.example.com]
| | [A IP-RVS ]
| |
| | +-----+
| | +------I1----->| RVS |-----I1------+
| | | +-----+ |
| | | |
| | | |
| v | v
+-----+ +-----+
| |<---------------R1------------| |
| I |----------------I2----------->| R |
| |<---------------R2------------| |
+-----+ +-----+
[A? ]
[rvs.example.com] +-----+
+----------------------------------------->| |
| | DNS |
| +----------------------------------------| |
| | [HIP? ] +-----+
| | [www.example.com ]
| | [HIP HIT-R HI-R rvs.example.com]
| |
| | [A? ]
| | [rvs.example.com]
| | [A IP-RVS ]
| |
| | +-----+
| | +------I1----->| RVS |-----I1------+
| | | +-----+ |
| | | |
| | | |
| v | v
+-----+ +-----+
| |<---------------R1------------| |
| I |----------------I2----------->| R |
| |<---------------R2------------| |
+-----+ +-----+
Mobile End Host
移动终端主机
The Initiator would then send an I1 to the RVS IP address (IP-RVS). Following, the RVS will relay the I1 up to the mobile node's IP address (IP-R), which will complete the HIP exchange.
然后，启动器将向RVS IP地址（IP-RVS）发送I1。随后，RVS将I1中继至移动节点的IP地址（IP-R），从而完成HIP交换。
For any HIP node, its HI, the associated HIT, and the FQDN of its possible RVSs can be stored in a DNS HIP RR. Any conforming implementation may store an HI and its associated HIT in a DNS HIP RDATA format. HI and HIT are defined in Section 3 of the HIP specification [RFC7401].
对于任何HIP节点，其HI、相关HIT及其可能RVS的FQDN都可以存储在DNS HIP RR中。任何符合要求的实现都可以以DNS HIP RDATA格式存储HI及其关联的HIT。HI和HIT在HIP规范[RFC7401]第3节中定义。
Upon return of a HIP RR, a host MUST always calculate the HI-derivative HIT to be used in the HIP exchange, as specified in Section 3 of the HIP specification [RFC7401], while the HIT included in the HIP RR SHOULD only be used as an optimization (e.g., table lookup).
返回HIP RR后，主机必须始终计算HIP交换中使用的HI衍生命中，如HIP规范[RFC7401]第3节中的规定，而HIP RR中包含的命中只能用作优化（例如，查表）。
The HIP RR may also contain one or more domain names of one or more RVSs towards which HIP I1 packets might be sent to trigger the establishment of an association with the entity named by this RR [RFC8004].
HIP-RR还可以包含一个或多个rvs的一个或多个域名，HIP-I1分组可以发送到该rvs以触发与该RR命名的实体建立关联[RFC8004]。
The Rendezvous Server field of the HIP RR stored at a given owner name MAY include the owner name itself. A semantically equivalent situation occurs if no RVS is present in the HIP RR stored at that owner name. Such situations occur in two cases:
以给定所有者名称存储的HIP RR的会合服务器字段可能包括所有者名称本身。如果以该所有者名称存储的HIP RR中不存在RVS，则会出现语义等效的情况。这种情况发生在两种情况下：
o The host is mobile, and the A and/or AAAA RR(s) stored at its host name contain the IP address(es) of its RVS rather than its own one.
o 主机是移动的，存储在主机名中的A和/或AAAA RR包含其RVS的IP地址，而不是其自己的IP地址。
o The host is stationary and can be reached directly at the IP address(es) contained in the A and/or AAAA RR(s) stored at its host name. This is a degenerate case of rendezvous service where the host somewhat acts as an RVS for itself.
o 主机是固定的，可以通过存储在主机名中的A和/或AAAA RR中包含的IP地址直接访问该主机。这是一个会合服务的退化案例，其中主机在某种程度上充当自己的RVS。
An RVS receiving such an I1 would then relay it to the appropriate Responder (the owner of the I1 receiver HIT). The Responder will then complete the exchange with the Initiator, typically without ongoing help from the RVS.
接收到这种I1的RVS随后会将其转发给相应的响应者（I1接收器命中的所有者）。然后，响应者将完成与发起人的交换，通常无需RVS的持续帮助。
On a HIP node, a HIP exchange SHOULD be initiated whenever a ULP attempts to communicate with an entity, and the DNS lookup returns HIP RRs.
在HIP节点上，当ULP尝试与实体通信时，应启动HIP交换，并且DNS查找返回HIP RRs。
HIP RRs have a Time To Live (TTL) associated with them. When the number of seconds that passed since the record was retrieved exceeds the record's TTL, the record MUST be considered no longer valid and deleted by the entity that retrieved it. If access to the record is necessary to initiate communication with the entity to which the record corresponds, a new query MUST be made to retrieve a fresh copy of the record.
HIP RRs有一个与之相关的生存时间（TTL）。当自检索记录以来经过的秒数超过记录的TTL时，必须认为该记录不再有效，并由检索该记录的实体将其删除。如果需要访问该记录以启动与该记录对应的实体的通信，则必须进行新的查询以检索该记录的新副本。
There may be multiple HIP RRs associated with a single name. It is outside the scope of this specification as to how a host chooses between multiple RRs when more than one is returned. The RVS
可能有多个HIP RRs与单个名称关联。当返回多个RRs时，主机如何在多个RRs之间进行选择超出了本规范的范围。房车
information may be copied and aligned across multiple RRs, or may be different for each one; a host MUST check that the RVS used is associated with the HI being used, when multiple choices are present.
信息可以跨多个RRs复制和对齐，或者每个RRs的信息可能不同；当存在多个选项时，主机必须检查所使用的RVS是否与所使用的HI相关联。
The RDATA for a HIP RR consists of a PK Algorithm Type, the HIT length, a HIT, a PK (i.e., an HI), and optionally one or more RVSs.
HIP RR的RDATA由PK算法类型、命中长度、命中、PK（即HI）和可选的一个或多个RVS组成。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HIT length | PK algorithm | PK length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ HIT ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+ +
| Public Key |
~ ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ Rendezvous Servers ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HIT length | PK algorithm | PK length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ HIT ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+ +
| Public Key |
~ ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ Rendezvous Servers ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+
The HIT length, PK algorithm, PK length, HIT, and Public Key fields are REQUIRED. The Rendezvous Server field is OPTIONAL.
命中长度、PK算法、PK长度、命中和公钥字段是必需的。会合服务器字段是可选的。
The HIT length indicates the length in bytes of the HIT field. This is an 8-bit unsigned integer.
命中长度表示命中字段的字节长度。这是一个8位无符号整数。
The PK algorithm field indicates the PK cryptographic algorithm and the implied Public Key field format. This is an 8-bit unsigned integer. This document reuses the values defined for the 'Algorithm Type' of the IPSECKEY RR [RFC4025].
PK算法字段表示PK加密算法和隐含公钥字段格式。这是一个8位无符号整数。本文档重用为IPSECKEY RR[RFC4025]的“算法类型”定义的值。
Presently defined values are listed in Section 9 for reference.
第9节列出了当前定义的值，以供参考。
The PK length indicates the length in bytes of the Public Key field. This is a 16-bit unsigned integer in network byte order.
PK长度表示公钥字段的字节长度。这是网络字节顺序的16位无符号整数。
The HIT is stored as a binary value in network byte order.
命中以网络字节顺序存储为二进制值。
Two of the PK types defined in this document (RSA and Digital Signature Algorithm (DSA)) reuse the PK formats defined for the IPSECKEY RR [RFC4025].
本文档中定义的两种PK类型（RSA和数字签名算法（DSA））重用为IPSECKEY RR[RFC4025]定义的PK格式。
The DSA key format is defined in RFC 2536 [RFC2536].
DSA密钥格式在RFC 2536[RFC2536]中定义。
The RSA key format is defined in RFC 3110 [RFC3110], and the RSA key size limit (4096 bits) is relaxed in the IPSECKEY RR [RFC4025] specification.
RSA密钥格式在RFC 3110[RFC3110]中定义，RSA密钥大小限制（4096位）在IPSECKEY RR[RFC4025]规范中放宽。
In addition, this document similarly defines the PK format of type Elliptic Curve Digital Signature Algorithm (ECDSA) as the algorithm-specific portion of the DNSKEY RR RDATA for ECDSA [RFC6605], i.e, all of the DNSKEY RR DATA after the first four octets, corresponding to the same portion of the DNSKEY RR that must be specified by documents that define a DNSSEC algorithm.
此外，本文件同样将PK格式的椭圆曲线数字签名算法（ECDSA）定义为ECDSA[RFC6605]的DNSKEY RR RDATA的算法特定部分，即前四个八位字节之后的所有DNSKEY RR数据，对应于必须由定义DNSSEC算法的文档指定的DNSKEY RR的相同部分。
The Rendezvous Server field indicates one or more variable length wire-encoded domain names of one or more RVSs, concatenated and encoded as described in Section 3.3 of RFC 1035 [RFC1035]: "<domain-name> is a domain name represented as a series of labels, and terminated by a label with zero length". Since the wire-encoded format is self-describing, the length of each domain name is implicit: The zero length label termination serves as a separator between multiple RVS domain names concatenated in the Rendezvous Server field of a same HIP RR. Since the length of the other portion of the RR's RRDATA is known, and the overall length of the RR's RDATA is also known (RDLENGTH), all the length information necessary to parse the HIP RR is available.
会合服务器字段表示一个或多个RVS的一个或多个可变长度有线编码域名，按照RFC 1035[RFC1035]第3.3节中的描述进行连接和编码：“<domain name>是一个域名，表示为一系列标签，以零长度标签终止”。由于有线编码格式是自描述的，因此每个域名的长度都是隐式的：零长度标签终止用作在同一HIP RR的会合服务器字段中连接的多个RVS域名之间的分隔符。由于RR的RRDATA的另一部分的长度是已知的，并且RR的RDATA的总长度也是已知的（RDLENGTH），因此解析HIP RR所需的所有长度信息都是可用的。
The domain names MUST NOT be compressed. The RVS or servers are listed in order of preference (i.e., the first RVS or servers are preferred), defining an implicit order amongst RVSs of a single RR.
不得压缩域名。RVS或服务器按优先顺序列出（即，首选第一个RVS或服务器），定义单个RR的RVS之间的隐含顺序。
When multiple HIP RRs are present at the same owner name, this implicit order of RVSs within an RR MUST NOT be used to infer a preference order between RVSs stored in different RRs.
当同一所有者姓名下存在多个HIP RRs时，不得使用RR中RVS的这一隐含顺序推断不同RRs中存储的RVS之间的偏好顺序。
This section specifies the representation of the HIP RR in a zone master file.
本节指定HIP RR在分区主文件中的表示形式。
The HIT length field is not represented, as it is implicitly known thanks to the HIT field representation.
未表示命中长度字段，因为由于命中字段表示，它是隐式已知的。
The PK algorithm field is represented as unsigned integers.
PK算法字段表示为无符号整数。
The HIT field is represented as the Base16 encoding [RFC4648] (a.k.a. hex or hexadecimal) of the HIT. The encoding MUST NOT contain whitespaces to distinguish it from the Public Key field.
命中字段表示为命中的Base16编码[RFC4648]（也称十六进制或十六进制）。编码不能包含空格，以将其与公钥字段区分开来。
The Public Key field is represented as the Base64 encoding of the PK, as defined in Section 4 of [RFC4648]. The encoding MUST NOT contain whitespace(s) to distinguish it from the Rendezvous Server field.
公钥字段表示为PK的Base64编码，如[RFC4648]第4节所定义。编码不能包含空格，以将其与集合服务器字段区分开来。
The PK length field is not represented, as it is implicitly known thanks to the Public Key field representation containing no whitespaces.
PK长度字段没有表示，因为公钥字段表示不包含空格，所以它是隐式表示的。
The Rendezvous Server field is represented by one or more domain names separated by whitespace(s). Such whitespace is only used in the HIP RR representation format and is not part of the HIP RR wire format.
集合服务器字段由一个或多个域名表示，域名之间用空格分隔。此类空白仅在HIP RR表示格式中使用，不属于HIP RR wire格式的一部分。
The complete representation of the HIP record is:
髋部记录的完整表示为：
IN HIP ( pk-algorithm base16-encoded-hit base64-encoded-public-key rendezvous-server[1] ... rendezvous-server[n] )
HIP中（pk算法base16编码hit base64编码公钥集合服务器[1]…集合服务器[n]）
When no RVSs are present, the representation of the HIP record is:
当不存在RVS时，髋关节记录的表示为：
IN HIP ( pk-algorithm base16-encoded-hit base64-encoded-public-key )
HIP中（pk算法base16编码hit base64编码公钥）
In the examples below, the Public Key field containing no whitespace is wrapped, since it does not fit in a single line of this document.
在下面的示例中，不包含空格的公钥字段被包装，因为它不适合本文档的一行。
Example of a node with an HI and a HIT but no RVS:
具有HI和HIT但没有RVS的节点示例：
www.example.com. IN HIP ( 2 200100107B1A74DF365639CC39F1D578 AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cI vM4p9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ry ra+bSRGQb1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXd XF5D )
www.example.com。HIP（2 200100107B1A74DF3639CC39F1D578 AWEABDXYHNUSUSC5EMZXTS9LBPCIKOFH8CI vM4p9+LrV4e19WzK00+CI6ZBCQTWTWSUXKBWIY87UOJTWKUS7LBU+Upr1gsNrut79ry ra+BSRGQB1SLIMA8YVJ7KWZG7JNERQNWXZ48AWKSKMDHAVDHBELRTI3RMXD XF5D）
Example of a node with an HI, a HIT, and one RVS:
具有HI、HIT和一个RVS的节点示例：
www.example.com. IN HIP ( 2 200100107B1A74DF365639CC39F1D578 AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cI vM4p9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ry ra+bSRGQb1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXd XF5D rvs.example.com. )
www.example.com。HIP中（2 200100107B1A74DF3639CC39F1D578 AWEABDXYHNUSUTC5EMZXTS9LBPCIKOFH8CI vM4p9+LrV4e19WzK00+CI6ZBCQTDTWSUXKBWIY87UOJTWKUS7LBU+Upr1gsNrut79ry ra+BSRGQB1SLIMA8YVJ7KWZG7JNERQNWXZ48AWKSKMDHAVDHAP4BCELRTI3RMXD XF5D rvs.example.com）
Example of a node with an HI, a HIT, and two RVSs:
具有HI、HIT和两个RVS的节点示例：
www.example.com. IN HIP ( 2 200100107B1A74DF365639CC39F1D578 AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cI vM4p9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ry ra+bSRGQb1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXd XF5D rvs1.example.com. rvs2.example.com. )
www.example.com。在HIP中（2 200100107B1A74DF3639CC39F1D578 AWEABDXYHNUSUTC5EMZXTS9LBPCIKOFH8CI vM4p9+LrV4e19WzK00+CI6ZBCQTDTWSUXKBWIY87UOJTWKUS7LBU+Upr1gsNrut79ry ra+BSRGQB1SLIMA8YVJ7KWZG7JNERNWXZ48AWKSKMDHAVDHP4BCELRTI3RMXD rvs1.example.com.rvs2.example.com）
This section contains a description of the known threats involved with the usage of the HIP DNS Extension.
本节包含使用HIP DNS扩展所涉及的已知威胁的描述。
In a manner similar to the IPSECKEY RR [RFC4025], the HIP DNS Extension allows for the provision of two HIP nodes with the public keying material (HI) of their peer. These HIs will be subsequently used in a key exchange between the peers. Hence, the HIP DNS Extension is subject, as the IPSECKEY RR, to threats stemming from attacks against unsecured HIP RRs, as described in the remainder of this section.
以类似于IPSECKEY RR[RFC4025]的方式，HIP DNS扩展允许提供两个HIP节点及其对等节点的公钥材料（HI）。这些HIs随后将用于对等方之间的密钥交换。因此，HIP DNS扩展作为IPSECKEY RR，受到来自对不安全HIP RRs的攻击的威胁，如本节其余部分所述。
A HIP node SHOULD obtain HIP RRs from a trusted party through a secure channel ensuring data integrity and authenticity of the RRs. DNSSEC [RFC4033] [RFC4034] [RFC4035] provides such a secure channel. However, it should be emphasized that DNSSEC only offers data integrity and authenticity guarantees to the channel between the DNS server publishing a zone and the HIP node. DNSSEC does not ensure that the entity publishing the zone is trusted. Therefore, the RRSIG of the HIP RRSet MUST NOT be misinterpreted as a certificate binding the HI and/or the HIT to the owner name.
HIP节点应通过安全通道从受信任方获取HIP RRs，确保RRs的数据完整性和真实性。DNSSEC[RFC4033][RFC4034][RFC4035]提供了这样一个安全通道。但是，应该强调的是，DNSSEC仅为发布区域的DNS服务器和HIP节点之间的通道提供数据完整性和真实性保证。DNSSEC不确保发布区域的实体受信任。因此，不得将HIP RRSet的RRSIG误解为将HI和/或HIT绑定到所有者名称的证书。
In the absence of a proper secure channel, both parties are vulnerable to MitM and Denial-of-Service (DoS) attacks, and unrelated parties might be subject to DoS attacks as well. These threats are described in the following sections.
在缺乏适当的安全通道的情况下，双方都容易受到MitM和拒绝服务（DoS）攻击，不相关方也可能受到DoS攻击。这些威胁将在以下章节中描述。
The HIP RR contains public keying material in the form of the named peer's PK (the HI) and its secure hash (the HIT). Both of these are not sensitive to attacks where an adversary gains knowledge of them. However, an attacker that is able to mount an active attack on the DNS, i.e., tampers with this HIP RR (e.g., using DNS spoofing), is able to mount MitM attacks on the cryptographic core of the eventual HIP exchange (Responder's HIP RR rewritten by the attacker).
HIP-RR包含以命名对等方的PK（HI）及其安全散列（HIT）形式存在的公钥材料。这两种方法对敌人知道的攻击都不敏感。但是，能够在DNS上发起主动攻击的攻击者，即篡改此HIP RR（例如，使用DNS欺骗），能够在最终HIP交换的加密核心上发起MitM攻击（响应者的HIP RR被攻击者重写）。
The HIP RR may contain an RVS domain name resolved into a destination IP address where the named peer is reachable by an I1, as per the HIP Rendezvous Extension [RFC8004]. Thus, an attacker that is able to tamper with this RR is able to redirect I1 packets sent to the named peer to a chosen IP address for DoS or MitM attacks. Note that this kind of attack is not specific to HIP and exists independently of whether or not HIP and the HIP RR are used. Such an attacker might tamper with A and AAAA RRs as well.
HIP RR可能包含一个RVS域名，该域名解析为目标IP地址，根据HIP会合扩展[RFC8004]，I1可以访问指定的对等方。因此，能够篡改此RR的攻击者能够将发送到指定对等方的I1数据包重定向到所选IP地址，以进行DoS或MitM攻击。请注意，这种攻击并不特定于髋关节，并且与是否使用髋关节和髋关节RR无关。这样的攻击者也可能篡改A和AAAA RRs。
An attacker might obviously use these two attacks in conjunction: It will replace the Responder's HI and RVS IP address by its own in a spoofed DNS packet sent to the Initiator HI, and then redirect all exchanged packets to him and mount a MitM on HIP. In this case, HIP won't provide confidentiality nor Initiator HI protection from eavesdroppers.
攻击者显然可能同时使用这两种攻击：它将在发送给启动器HI的伪造DNS数据包中用自己的IP地址替换响应者的HI和RVS IP地址，然后将所有交换的数据包重定向给他，并在HIP上安装MitM。在这种情况下，HIP既不提供机密性，也不提供防止窃听者的保护。
As with many cryptographic algorithms, some secure hashes (e.g., SHA1, used by HIP to generate a HIT from an HI) eventually become insecure, because an exploit has been found in which an attacker with reasonable computation power breaks one of the security features of the hash (e.g., its supposed collision resistance). This is why a
与许多加密算法一样，一些安全散列（例如SHA1，HIP用于从HI生成命中）最终变得不安全，因为发现了一个漏洞，具有合理计算能力的攻击者破坏了散列的一个安全特性（例如，其假定的抗冲突性）。这就是为什么
HIP end-node implementation SHOULD NOT authenticate its HIP peers based solely on a HIT retrieved from the DNS, but rather SHOULD use HI-based authentication.
HIP-end节点实现不应仅基于从DNS检索到的命中对其HIP对等方进行身份验证，而应使用基于HI的身份验证。
In the absence of DNSSEC, the HIP RR is subject to the threats described in RFC 3833 [RFC3833].
在没有DNSSEC的情况下，HIP RR受到RFC 3833[RFC3833]中所述的威胁。
[RFC5205], obsoleted by this document, made the following definition and reservation in the "Resource Record (RR) TYPEs" subregistry under "Domain Name System (DNS) Parameters":
[RFC5205]已被本文件废除，在“域名系统（DNS）参数”下的“资源记录（RR）类型”子区域中作出以下定义和保留：
Value Type
----- ----
55 HIP
Value Type
----- ----
55 HIP
In the "Resource Record (RR) TYPEs" subregistry under "Domain Name System (DNS) Parameters", references to [RFC5205] have been replaced by references to this document.
在“域名系统（DNS）参数”下的“资源记录（RR）类型”子区域中，对[RFC5205]的引用已替换为对本文件的引用。
As [RFC5205], this document reuses the Algorithm Types defined by [RFC4025] for the IPSEC KEY RR. Presently defined values are shown here for reference only:
与[RFC5205]一样，本文档重用[RFC4025]为IPSEC密钥RR定义的算法类型。此处显示的当前定义值仅供参考：
Value Description
----- --------------------------------------------------------
1 A DSA key is present, in the format defined in [RFC2536]
2 A RSA key is present, in the format defined in [RFC3110]
Value Description
----- --------------------------------------------------------
1 A DSA key is present, in the format defined in [RFC2536]
2 A RSA key is present, in the format defined in [RFC3110]
IANA has made the following assignment in the "Algorithm Type Field" subregistry under "IPSECKEY Resource Record Parameters" [RFC4025]:
IANA在“IPSECKEY资源记录参数”[RFC4025]下的“算法类型字段”子区域中进行了以下分配：
Value Description
----- -----------
3 An ECDSA key is present, in the format defined in [RFC6605]
Value Description
----- -----------
3 An ECDSA key is present, in the format defined in [RFC6605]
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <http://www.rfc-editor.org/info/rfc1034>.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，DOI 10.17487/RFC1034，1987年11月<http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，DOI 10.17487/RFC1035，1987年11月<http://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, <http://www.rfc-editor.org/info/rfc2181>.
[RFC2181]Elz，R.和R.Bush，“DNS规范的澄清”，RFC 2181，DOI 10.17487/RFC2181，1997年7月<http://www.rfc-editor.org/info/rfc2181>.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, DOI 10.17487/RFC3596, October 2003, <http://www.rfc-editor.org/info/rfc3596>.
[RFC3596]Thomson，S.，Huitema，C.，Ksinant，V.，和M.Souissi，“支持IP版本6的DNS扩展”，RFC 3596，DOI 10.17487/RFC3596，2003年10月<http://www.rfc-editor.org/info/rfc3596>.
[RFC4025] Richardson, M., "A Method for Storing IPsec Keying Material in DNS", RFC 4025, DOI 10.17487/RFC4025, March 2005, <http://www.rfc-editor.org/info/rfc4025>.
[RFC4025]Richardson，M.，“在DNS中存储IPsec密钥材料的方法”，RFC 4025，DOI 10.17487/RFC4025，2005年3月<http://www.rfc-editor.org/info/rfc4025>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，DOI 10.17487/RFC4033，2005年3月<http://www.rfc-editor.org/info/rfc4033>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, <http://www.rfc-editor.org/info/rfc4034>.
[RFC4034]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 4034，DOI 10.17487/RFC4034，2005年3月<http://www.rfc-editor.org/info/rfc4034>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, <http://www.rfc-editor.org/info/rfc4035>.
[RFC4035]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，DOI 10.17487/RFC4035，2005年3月<http://www.rfc-editor.org/info/rfc4035>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC 4648，DOI 10.17487/RFC4648，2006年10月<http://www.rfc-editor.org/info/rfc4648>.
[RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC", RFC 6605, DOI 10.17487/RFC6605, April 2012, <http://www.rfc-editor.org/info/rfc6605>.
[RFC6605]Hoffman，P.和W.Wijngaards，“DNSSEC的椭圆曲线数字签名算法（DSA）”，RFC 6605，DOI 10.17487/RFC6605，2012年4月<http://www.rfc-editor.org/info/rfc6605>.
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC 7401, DOI 10.17487/RFC7401, April 2015, <http://www.rfc-editor.org/info/rfc7401>.
[RFC7401]Moskowitz，R.，Ed.，Heer，T.，Jokela，P.，和T.Henderson，“主机身份协议版本2（HIPv2）”，RFC 7401，DOI 10.17487/RFC7401，2015年4月<http://www.rfc-editor.org/info/rfc7401>.
[RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, October 2016, <http://www.rfc-editor.org/info/rfc8004>.
[RFC8004]Laganier，J.和L.Eggert，“主机身份协议（HIP）会合扩展”，RFC 8004，DOI 10.17487/RFC8004，2016年10月<http://www.rfc-editor.org/info/rfc8004>.
[RFC2536] Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name System (DNS)", RFC 2536, DOI 10.17487/RFC2536, March 1999, <http://www.rfc-editor.org/info/rfc2536>.
[RFC2536]Eastlake 3rd，D.，“域名系统（DNS）中的DSA密钥和SIG”，RFC 2536，DOI 10.17487/RFC2536，1999年3月<http://www.rfc-editor.org/info/rfc2536>.
[RFC3110] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)", RFC 3110, DOI 10.17487/RFC3110, May 2001, <http://www.rfc-editor.org/info/rfc3110>.
[RFC3110]Eastlake 3rd，D.，“域名系统（DNS）中的RSA/SHA-1 SIGs和RSA密钥”，RFC 3110，DOI 10.17487/RFC3110，2001年5月<http://www.rfc-editor.org/info/rfc3110>.
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, DOI 10.17487/RFC3833, August 2004, <http://www.rfc-editor.org/info/rfc3833>.
[RFC3833]Atkins，D.和R.Austein，“域名系统（DNS）的威胁分析”，RFC 3833，DOI 10.17487/RFC3833，2004年8月<http://www.rfc-editor.org/info/rfc3833>.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, DOI 10.17487/RFC4423, May 2006, <http://www.rfc-editor.org/info/rfc4423>.
[RFC4423]Moskowitz，R.和P.Nikander，“主机身份协议（HIP）体系结构”，RFC 4423，DOI 10.17487/RFC4423，2006年5月<http://www.rfc-editor.org/info/rfc4423>.
[RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions", RFC 5205, DOI 10.17487/RFC5205, April 2008, <http://www.rfc-editor.org/info/rfc5205>.
[RFC5205]Nikander，P.和J.Laganier，“主机身份协议（HIP）域名系统（DNS）扩展”，RFC 5205，DOI 10.17487/RFC5205，2008年4月<http://www.rfc-editor.org/info/rfc5205>.
[RFC5206] Nikander, P., Henderson, T., Ed., Vogt, C., and J. Arkko, "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, DOI 10.17487/RFC5206, April 2008, <http://www.rfc-editor.org/info/rfc5206>.
[RFC5206]Nikander，P.，Henderson，T.，Ed.，Vogt，C.，和J.Arkko，“使用主机身份协议的终端主机移动性和多址”，RFC 5206，DOI 10.17487/RFC5206，2008年4月<http://www.rfc-editor.org/info/rfc5206>.
o Updated HIP references to revised HIP specifications.
o 更新髋关节参考，以修订髋关节规范。
o Extended DNS HIP RR to support for Host Identities based on ECDSA.
o 扩展DNS HIP RR以支持基于ECDSA的主机标识。
o Clarified that new query must be made when the time that passed since an RR was retrieved exceeds the TTL of the RR.
o 阐明了当检索RR后经过的时间超过RR的TTL时，必须进行新查询。
o Added considerations related to multiple HIP RRs being associated with a single name.
o 添加了与多个HIP RRs与单个名称关联相关的注意事项。
o Clarified that the Base64 encoding in use is as per Section 4 of [RFC4648].
o 阐明所使用的Base64编码符合[RFC4648]第4节的要求。
o Clarified the wire format when more than one RVS is defined in one RR.
o 阐明了在一个RR中定义多个RVS时的导线格式。
o Clarified that "whitespace" is used as the delimiter in the human-readable representation of the RR but is not part of the wire format.
o 澄清了“空白”在RR的可读表示中用作分隔符，但不是wire格式的一部分。
Acknowledgments
致谢
As usual in the IETF, this document is the result of a collaboration between many people. The authors would like to thank the author (Michael Richardson), contributors, and reviewers of the IPSECKEY RR [RFC4025] specification, after which this document was framed. The authors would also like to thank the following people, who have provided thoughtful and helpful discussions and/or suggestions, that have helped improve this document: Jeff Ahrenholz, Rob Austein, Hannu Flinck, Olafur Gudmundsson, Tom Henderson, Peter Koch, Olaf Kolkman, Miika Komu, Andrew McGregor, Gabriel Montenegro, and Erik Nordmark. Some parts of this document stem from the HIP specification [RFC7401]. Finally, thanks to Sheng Jiang for performing the Internet Area Directorate review of this document in the course of the publication process.
与IETF中的通常情况一样，本文档是许多人协作的结果。作者要感谢IPSECKEY RR[RFC4025]规范的作者（Michael Richardson）、贡献者和评审者，在此之后，本文档被框架化。作者还要感谢以下人士，他们提供了有助于改进本文件的深思熟虑和有益的讨论和/或建议：杰夫·阿伦霍尔茨、罗布·奥斯汀、汉努·弗林克、奥拉弗尔·古德蒙德森、汤姆·亨德森、彼得·科赫、奥拉夫·科尔克曼、米卡·科姆、安德鲁·麦格雷戈、加布里埃尔·黑山和埃里克·诺德马克。本文件的某些部分源自HIP规范[RFC7401]。最后，感谢盛江在出版过程中对本文件进行了互联网领域董事会审查。
Contributors
贡献者
Pekka Nikander coauthored an earlier, experimental version of this specification [RFC5205].
Pekka Nikander与他人合著了本规范的早期实验版本[RFC5205]。
Author's Address
作者地址
Julien Laganier Luminate Wireless, Inc. Cupertino, CA United States of America
Julien Laganier Luminate Wireless，Inc.美国加利福尼亚州库珀蒂诺市
Email: julien.ietf@gmail.com
Email: julien.ietf@gmail.com