Internet Engineering Task Force (IETF) J. Laganier
Request for Comments: 8004 Luminate Wireless, Inc.
Obsoletes: 5204 L. Eggert
Category: Standards Track NetApp
ISSN: 2070-1721 October 2016
Internet Engineering Task Force (IETF) J. Laganier
Request for Comments: 8004 Luminate Wireless, Inc.
Obsoletes: 5204 L. Eggert
Category: Standards Track NetApp
ISSN: 2070-1721 October 2016
Host Identity Protocol (HIP) Rendezvous Extension
主机身份协议（HIP）集合扩展
Abstract
摘要
This document defines a rendezvous extension for the Host Identity Protocol (HIP). The rendezvous extension extends HIP and the HIP Registration Extension for initiating communication between HIP nodes via HIP rendezvous servers. Rendezvous servers improve reachability and operation when HIP nodes are multihomed or mobile. This document obsoletes RFC 5204.
本文档定义了主机标识协议（HIP）的会合扩展。会合扩展扩展扩展HIP和HIP注册扩展，用于通过HIP会合服务器启动HIP节点之间的通信。当HIP节点是多宿节点或移动节点时，集合服务器可以提高可达性和操作性。本文件淘汰了RFC 5204。
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/rfc8004.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8004.
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Rendezvous Server Operation . . . . . . . . . . . 3
3.1. Diagram Notation . . . . . . . . . . . . . . . . . . . . 5
3.2. Rendezvous Client Registration . . . . . . . . . . . . . 5
3.3. Relaying the Base Exchange . . . . . . . . . . . . . . . 6
4. Rendezvous Server Extensions . . . . . . . . . . . . . . . . 7
4.1. RENDEZVOUS Registration Type . . . . . . . . . . . . . . 7
4.2. Parameter Formats and Processing . . . . . . . . . . . . 7
4.2.1. RVS_HMAC Parameter . . . . . . . . . . . . . . . . . 7
4.2.2. FROM Parameter . . . . . . . . . . . . . . . . . . . 8
4.2.3. VIA_RVS Parameter . . . . . . . . . . . . . . . . . . 9
4.3. Modified Packets Processing . . . . . . . . . . . . . . . 9
4.3.1. Processing Outgoing I1 Packets . . . . . . . . . . . 9
4.3.2. Processing Incoming I1 Packets . . . . . . . . . . . 10
4.3.3. Processing Outgoing R1 Packets . . . . . . . . . . . 10
4.3.4. Processing Incoming R1 Packets . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Changes from RFC 5204 . . . . . . . . . . . . . . . 14
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Rendezvous Server Operation . . . . . . . . . . . 3
3.1. Diagram Notation . . . . . . . . . . . . . . . . . . . . 5
3.2. Rendezvous Client Registration . . . . . . . . . . . . . 5
3.3. Relaying the Base Exchange . . . . . . . . . . . . . . . 6
4. Rendezvous Server Extensions . . . . . . . . . . . . . . . . 7
4.1. RENDEZVOUS Registration Type . . . . . . . . . . . . . . 7
4.2. Parameter Formats and Processing . . . . . . . . . . . . 7
4.2.1. RVS_HMAC Parameter . . . . . . . . . . . . . . . . . 7
4.2.2. FROM Parameter . . . . . . . . . . . . . . . . . . . 8
4.2.3. VIA_RVS Parameter . . . . . . . . . . . . . . . . . . 9
4.3. Modified Packets Processing . . . . . . . . . . . . . . . 9
4.3.1. Processing Outgoing I1 Packets . . . . . . . . . . . 9
4.3.2. Processing Incoming I1 Packets . . . . . . . . . . . 10
4.3.3. Processing Outgoing R1 Packets . . . . . . . . . . . 10
4.3.4. Processing Incoming R1 Packets . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Changes from RFC 5204 . . . . . . . . . . . . . . . 14
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
"The Host Identity Protocol (HIP) Architecture" [HIP-ARCH] introduces the rendezvous mechanism to help a HIP node to contact a frequently moving HIP node. The rendezvous mechanism involves a third party, the rendezvous server (RVS), which serves as an initial contact point ("rendezvous point") for its clients. The clients of an RVS are HIP nodes that use the HIP Registration Extension [RFC8003] to register their HIT->IP address mappings with the RVS. After this registration, other HIP nodes can initiate a base exchange using the IP address of the RVS instead of the current IP address of the node they attempt to contact. Essentially, the clients of an RVS become reachable at the RVS's IP address. Peers can initiate a HIP base exchange with the IP address of the RVS, which will relay this initial communication such that the base exchange may successfully complete.
“主机身份协议（HIP）体系结构”[HIP-ARCH]引入了会合机制，以帮助HIP节点接触频繁移动的HIP节点。会合机制涉及第三方，即会合服务器（RVS），它充当其客户端的初始接触点（“会合点”）。RVS的客户端是HIP节点，使用HIP注册扩展[RFC8003]向RVS注册HIT->IP地址映射。在该注册之后，其他HIP节点可以使用RVS的IP地址而不是他们试图联系的节点的当前IP地址来启动基本交换。从本质上讲，RVS的客户端可以通过RVS的IP地址访问。对等方可以使用RVS的IP地址发起HIP基站交换，这将中继该初始通信，以便基站交换可以成功完成。
This section defines terms used throughout the remainder of this specification.
本节定义了本规范其余部分中使用的术语。
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 addition to the terminology defined in the HIP specification [RFC7401] and the HIP Registration Extension [RFC8003], this document defines and uses the following terms:
除HIP规范[RFC7401]和HIP注册扩展[RFC8003]中定义的术语外，本文件定义并使用以下术语：
Rendezvous Service A HIP service provided by an RVS to its rendezvous clients. The RVS offers to relay some of the arriving base exchange packets between the Initiator and Responder.
会合服务RVS向其会合客户提供的髋关节服务。RVS提供在发起方和响应方之间中继一些到达的基本交换数据包。
Rendezvous Server (RVS) A HIP registrar providing rendezvous service.
会合服务器（RVS）提供会合服务的HIP注册器。
Rendezvous Client A HIP requester that has registered for rendezvous service at an RVS.
会合客户端已在RVS注册会合服务的HIP请求者。
Rendezvous Registration A HIP registration for rendezvous service, established between an RVS and a rendezvous client.
会合登记会合服务的髋关节登记，在RVS和会合客户之间建立。
Figure 1 shows a simple HIP base exchange without an RVS, in which the Initiator initiates the exchange directly with the Responder by sending an I1 packet to the Responder's IP address, as per the HIP specification [RFC7401].
图1显示了一个没有RVS的简单HIP基址交换，其中启动器通过向响应者的IP地址发送I1数据包直接与响应者发起交换，符合HIP规范[RFC7401]。
+-----+ +-----+
| |-------I1------>| |
| I |<------R1-------| R |
| |-------I2------>| |
| |<------R2-------| |
+-----+ +-----+
+-----+ +-----+
| |-------I1------>| |
| I |<------R1-------| R |
| |-------I2------>| |
| |<------R2-------| |
+-----+ +-----+
Figure 1: HIP Base Exchange without a Rendezvous Server
图1：没有集合服务器的HIP Base Exchange
The End-Host Mobility and Multihoming with the HIP specification [HIP-HOST-MOB] allows a HIP node to notify its peers about changes in its set of IP addresses. This specification presumes initial reachability of the two nodes with respect to each other.
具有HIP规范[HIP-Host-MOB]的终端主机移动性和多归属允许HIP节点将其IP地址集的更改通知其对等方。本规范假定两个节点相对彼此的初始可达性。
However, such a HIP node MAY also want to be reachable to other future correspondent peers that are unaware of its location change. The HIP Architecture [HIP-ARCH] introduces RVSs with whom a HIP node MAY register its Host Identity Tags (HITs) and current IP addresses. An RVS relays HIP packets arriving for these HITs to the node's registered IP addresses. When a HIP node has registered with an RVS, it SHOULD record the IP address of its RVS in its DNS record, using the HIP DNS resource record type defined in the HIP DNS Extension [RFC8005].
然而，这样的髋关节节点也可能希望能够与其他不知道其位置变化的未来通信对等方连接。HIP体系结构[HIP-ARCH]引入RVS，HIP节点可向其注册主机标识标签（HITs）和当前IP地址。RVS将这些命中到达的HIP数据包中继到节点的注册IP地址。当HIP节点已向RVS注册时，应使用HIP DNS扩展[RFC8005]中定义的HIP DNS资源记录类型，在其DNS记录中记录其RVS的IP地址。
+-----+
+--I1--->| RVS |---I1--+
| +-----+ |
| v
+-----+ +-----+
| |<------R1-------| |
| I |-------I2------>| R |
| |<------R2-------| |
+-----+ +-----+
+-----+
+--I1--->| RVS |---I1--+
| +-----+ |
| v
+-----+ +-----+
| |<------R1-------| |
| I |-------I2------>| R |
| |<------R2-------| |
+-----+ +-----+
Figure 2: HIP Base Exchange with a Rendezvous Server
图2：带会合服务器的HIP Base Exchange
Figure 2 shows a HIP base exchange involving an RVS. It is assumed that HIP node R previously registered its HITs and current IP addresses with the RVS, using the HIP Registration Extension [RFC8003]. When the Initiator I tries to establish contact with the Responder R, it must send the I1 of the base exchange either to one of R's IP addresses (if known via DNS or other means) or to one of R's RVSs. Here, I obtains the IP address of R's RVS from R's DNS record and then sends the I1 packet of the HIP base exchange to RVS. RVS, noticing that the HIT contained in the arriving I1 packet is not one of its own, MUST check its current registrations to determine if it needs to relay the packets. Here, it determines that the HIT belongs to R and then relays the I1 packet to the registered IP address. R then completes the base exchange without further assistance from RVS by sending an R1 directly to the I's IP address, as obtained from the I1 packet. In this specification, the client of the RVS is always the Responder. However, there might be reasons (such as NAT and firewall traversal) to allow a client to initiate a base exchange through its own RVS. This specification does not address such scenarios, which should be specified in other documents.
图2显示了涉及RVS的髋关节基底置换。假设HIP节点R先前使用HIP注册扩展[RFC8003]向RVS注册了其点击次数和当前IP地址。当发起方I尝试与响应方R建立联系时，它必须将基本交换机的I1发送到R的一个IP地址（如果通过DNS或其他方式知道）或R的一个RVS。这里，我从R的DNS记录中获得R的RVS的IP地址，然后将HIP base exchange的I1数据包发送到RVS。RVS注意到到达的I1数据包中包含的HIT不是自己的，必须检查其当前注册，以确定是否需要中继数据包。这里，它确定HIT属于R，然后将I1分组中继到注册的IP地址。然后，通过将R1直接发送到I的IP地址（从I1数据包获得），R在不需要RVS进一步协助的情况下完成基本交换。在本规范中，RVS的客户始终是响应者。但是，可能有一些原因（例如NAT和防火墙穿越）允许客户端通过其自己的RVS启动基本交换。本规范不涉及此类场景，应在其他文件中指定。
Notation Significance
-------- ------------
Notation Significance
-------- ------------
I, R I and R are the respective source and destination IP addresses in the IP header.
一、 ri和R是IP报头中各自的源和目标IP地址。
HIT-I, HIT-R HIT-I and HIT-R are the Initiator's and the Responder's HITs in the packet, respectively.
HIT-I、HIT-R HIT-I和HIT-R分别是发起方和响应方在数据包中的命中。
REG_REQ A REG_REQUEST parameter is present in the HIP header.
REG_REQ REG_请求参数存在于HIP标头中。
REG_RES A REG_RESPONSE parameter is present in the HIP header.
REG_RES REG_响应参数出现在HIP标题中。
FROM:I A FROM parameter containing the IP address I is present in the HIP header.
FROM:I包含IP地址I的FROM参数出现在HIP头中。
RVS_HMAC An RVS_HMAC parameter containing an Hashed Message Authentication Code (HMAC) keyed with the appropriate registration key is present in the HIP header.
RVS_HMAC包含哈希消息身份验证码（HMAC）的RVS_HMAC参数（HMAC）由适当的注册密钥键入，该参数存在于HIP标头中。
VIA:RVS A VIA_RVS parameter containing the IP address RVS of a rendezvous server is present in the HIP header.
VIA:RVS包含会合服务器IP地址RVS的VIA_RVS参数存在于HIP标头中。
Before an RVS starts to relay HIP packets to a rendezvous client, the rendezvous client needs to register with the RVS to receive rendezvous service by using the HIP Registration Extension [RFC8003] as illustrated in the following schema:
在RVS开始将HIP数据包中继到会合客户端之前，会合客户端需要使用HIP注册扩展[RFC8003]向RVS注册以接收会合服务，如下图所示：
+-----+ +-----+
| | I1 | |
| |--------------------------->| |
| |<---------------------------| |
| I | R1(REG_INFO) | RVS |
| | I2(REG_REQ) | |
| |--------------------------->| |
| |<---------------------------| |
| | R2(REG_RES) | |
+-----+ +-----+
+-----+ +-----+
| | I1 | |
| |--------------------------->| |
| |<---------------------------| |
| I | R1(REG_INFO) | RVS |
| | I2(REG_REQ) | |
| |--------------------------->| |
| |<---------------------------| |
| | R2(REG_RES) | |
+-----+ +-----+
Rendezvous Client Registering with a Rendezvous Server
向集合服务器注册集合客户端
If a HIP node and one of its RVSs have a rendezvous registration, the RVSs relay inbound I1 packets (that contain one of the client's HITs) by rewriting the IP header. They replace the destination IP address of the I1 packet with one of the IP addresses of the owner of the HIT, i.e., the rendezvous client. They MUST also recompute the IP checksum accordingly.
如果HIP节点及其一个RVS具有会合注册，RVS将通过重写IP报头来中继入站I1数据包（其中包含客户端的一个点击）。它们将I1数据包的目标IP地址替换为HIT所有者（即集合客户端）的IP地址之一。他们还必须相应地重新计算IP校验和。
Because of ingress filtering on the path from the RVS to the client [RFC2827] [RFC3013], a HIP RVS SHOULD replace the source IP address, i.e., the IP address of I, with one of its own IP addresses. The replacement IP address SHOULD be chosen according to relevant IPv4 and IPv6 specifications [RFC1122] [RFC6724]. Because this replacement conceals the Initiator's IP address, the RVS MUST append a FROM parameter containing the original source IP address of the packet. This FROM parameter MUST be integrity protected by an RVS_HMAC keyed with the corresponding rendezvous registration integrity key [RFC8003].
由于在从RVS到客户端[RFC2827][RFC3013]的路径上进行入口过滤，HIP RVS应将源IP地址（即i的IP地址）替换为其自己的IP地址之一。应根据相关IPv4和IPv6规范[RFC1122][RFC6724]选择替换IP地址。由于此替换隐藏了启动器的IP地址，因此RVS必须附加一个FROM参数，该参数包含数据包的原始源IP地址。此FROM参数必须由一个RVS_HMAC完整性保护，该RVS_HMAC使用相应的会合注册完整性密钥[RFC8003]进行加密。
I1(RVS, R, HIT-I, HIT-R
I1(I, RVS, HIT-I, HIT-R) +---------+ FROM:I, RVS_HMAC)
+----------------------->| |--------------------+
| | RVS | |
| | | |
| +---------+ |
| V
+-----+ R1(R, I, HIT-R, HIT-I, VIA:RVS) +-----+
| |<---------------------------------------------| |
| | | |
| I | I2(I, R, HIT-I, HIT-R) | R |
| |--------------------------------------------->| |
| |<---------------------------------------------| |
+-----+ R2(R, I, HIT-R, HIT-I) +-----+
I1(RVS, R, HIT-I, HIT-R
I1(I, RVS, HIT-I, HIT-R) +---------+ FROM:I, RVS_HMAC)
+----------------------->| |--------------------+
| | RVS | |
| | | |
| +---------+ |
| V
+-----+ R1(R, I, HIT-R, HIT-I, VIA:RVS) +-----+
| |<---------------------------------------------| |
| | | |
| I | I2(I, R, HIT-I, HIT-R) | R |
| |--------------------------------------------->| |
| |<---------------------------------------------| |
+-----+ R2(R, I, HIT-R, HIT-I) +-----+
Rendezvous Server Rewriting IP Addresses
集合服务器重写IP地址
This modification of HIP packets at an RVS can be problematic because HIP uses integrity checks. Because the I1 does not include HMAC or SIGNATURE parameters, these two end-to-end integrity checks are unaffected by the operation of RVSs.
由于HIP使用完整性检查，因此在RVS对HIP数据包的这种修改可能存在问题。由于I1不包括HMAC或签名参数，因此这两个端到端完整性检查不受RVSs操作的影响。
The RVS SHOULD verify the checksum field of an I1 packet before doing any modifications. After modification, it MUST recompute the checksum field using the updated HIP header, which possibly included new FROM and RVS_HMAC parameters, and a pseudo-header containing the
在进行任何修改之前，RVS应验证I1数据包的校验和字段。修改后，必须使用更新的HIP标头（可能包括新的FROM和RVS_HMAC参数）和包含
updated source and destination IP addresses. This enables the Responder to validate the checksum of the I1 packet "as is", without having to parse any FROM parameters.
更新的源和目标IP地址。这使响应程序能够“按原样”验证I1数据包的校验和，而无需解析任何FROM参数。
This section describes extensions to the HIP Registration Extension [RFC8003], allowing a HIP node to register with an RVS for rendezvous service and to notify the RVS aware of changes to its current location. It also describes an extension to the HIP specification [RFC7401] itself, allowing establishment of HIP associations via one or more HIP RVSs.
本节描述了HIP注册扩展[RFC8003]的扩展，允许HIP节点向RVS注册会合服务，并通知RVS其当前位置的变化。它还描述了髋关节规范[RFC7401]本身的扩展，允许通过一个或多个髋关节RVS建立髋关节关联。
This specification defines an additional registration for the HIP Registration Extension [RFC8003] that allows registering with an RVS for rendezvous service.
本规范规定了髋关节注册扩展[RFC8003]的附加注册，允许注册RVS进行会合服务。
Number Registration Type
------ -----------------
1 RENDEZVOUS
Number Registration Type
------ -----------------
1 RENDEZVOUS
The RVS_HMAC is a non-critical parameter whose only difference with the HMAC parameter defined in the HIP specification [RFC7401] is its "type" code. This change causes it to be located after the FROM parameter (as opposed to the HMAC):
RVS_HMAC是一个非关键参数，其与HIP规范[RFC7401]中定义的HMAC参数的唯一区别在于其“类型”代码。此更改导致其位于FROM参数之后（与HMAC相反）：
Type 65500 Length Variable. Length in octets, excluding Type, Length, and Padding.
键入65500长度变量。长度（以八位字节为单位），不包括类型、长度和填充。
HMAC HMAC computed over the HIP packet, excluding the RVS_HMAC parameter and any following parameters. The HMAC is keyed with the appropriate HIP integrity key (HIP-lg or HIP-gl) established when rendezvous registration happened. The HIP "checksum" field MUST be set to zero, and the HIP header length in the HIP common header MUST be calculated not to cover any excluded parameter when the HMAC is calculated. The size of the HMAC is the natural size of the hash computation output depending on the used hash function.
HMAC HMAC通过HIP数据包计算，不包括RVS_HMAC参数和任何以下参数。HMAC由会合登记发生时建立的适当髋关节完整性钥匙（髋关节lg或髋关节gl）输入。HIP“校验和”字段必须设置为零，并且在计算HMAC时，必须计算HIP公用标头中的HIP标头长度，以不覆盖任何排除的参数。HMAC的大小是散列计算输出的自然大小，具体取决于所使用的散列函数。
To allow a rendezvous client and its RVS to verify the integrity of packets flowing between them, both SHOULD protect packets with an added RVS_HMAC parameter keyed with the HIP-lg or HIP-gl integrity key established while registration occurred. A valid RVS_HMAC SHOULD be present on every packet flowing between a client and a server and MUST be present when a FROM parameter is processed.
为了允许会合客户端及其RVS验证在它们之间流动的数据包的完整性，两者都应使用注册时建立的HIP lg或HIP gl完整性密钥键入的附加RVS_HMAC参数来保护数据包。有效的RVS_HMAC应该出现在客户端和服务器之间的每个数据包上，并且在处理FROM参数时必须出现。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 65498 Length 16 Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address.
键入65498长度16地址IPv6地址或IPv4-in-IPv6格式IPv4地址。
An RVS MUST add a FROM parameter containing the original source IP address of a HIP packet whenever the source IP address in the IP header is rewritten. If one or more FROM parameters are already present, the new FROM parameter MUST be appended after the existing ones.
每当IP报头中的源IP地址被重写时，RVS必须添加包含HIP数据包原始源IP地址的FROM参数。如果已经存在一个或多个FROM参数，则必须在现有参数之后追加新FROM参数。
Whenever an RVS inserts a FROM parameter, it MUST insert an RVS_HMAC protecting the packet integrity, especially the IP address included in the FROM parameter.
每当RVS插入FROM参数时，它必须插入一个RVS_HMAC，以保护数据包的完整性，特别是FROM参数中包含的IP地址。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . .
. . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . .
. . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 65502 Length Variable Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address.
键入65502长度可变地址IPv6地址或IPv6格式的IPv4地址。
After the Responder receives a relayed I1 packet, it can begin to send HIP packets addressed to the Initiator's IP address, without further assistance from an RVS. For debugging purposes, it MUST append a newly created VIA_RVS parameter at the end of the R1 packet that contains the IP address of the RVS that relayed the I1 packet. Including more than one IP address in the VIA_RVS parameter is outside the scope of this specification. The main goal of using the VIA_RVS parameter is to allow operators to diagnose possible issues encountered while establishing a HIP association via an RVS.
在应答器接收到中继的I1数据包后，它可以开始发送地址为启动器IP地址的HIP数据包，而无需RVS的进一步协助。出于调试目的，它必须在R1数据包末尾附加一个新创建的VIA_RVS参数，该数据包包含中继I1数据包的RVS的IP地址。在VIA_RVS参数中包含多个IP地址不在本规范范围内。使用VIA_RVS参数的主要目的是允许操作员诊断通过RVS建立髋关节关联时可能遇到的问题。
The following subsections describe the differences of the processing of I1 and R1 while an RVS is involved in the base exchange.
以下小节描述了RVS参与基本交换时I1和R1处理的差异。
An Initiator SHOULD NOT send an opportunistic I1 with a NULL destination HIT to an IP address that is known to be a rendezvous server address, unless it wants to establish a HIP association with the RVS itself and does not know its HIT.
发起者不应将目标命中为空的机会主义I1发送到已知为会合服务器地址的IP地址，除非发起者希望与RVS本身建立HIP关联且不知道其命中。
When an RVS rewrites the source IP address of an I1 packet due to egress filtering, it MUST add a FROM parameter to the I1 that contains the Initiator's source IP address. This FROM parameter MUST be protected by an RVS_HMAC keyed with the integrity key established at rendezvous registration.
当RVS由于出口过滤而重写I1数据包的源IP地址时，它必须向包含启动器源IP地址的I1添加FROM参数。这个FROM参数必须由一个RVS_HMAC保护，该RVS_HMAC使用在会合注册时建立的完整性密钥进行加密。
When an RVS receives an I1 whose destination HIT is not its own, it consults its registration database to find a registration for the rendezvous service established by the HIT owner. If it finds an appropriate registration, it relays the packet to the registered IP address. If it does not find an appropriate registration, it drops the packet.
当RVS收到目的地命中不是其自己的I1时，它会查阅其注册数据库，以查找命中所有者建立的会合服务的注册。如果找到合适的注册，它会将数据包转发到注册的IP地址。如果没有找到合适的注册，它将丢弃数据包。
An RVS SHOULD interpret any incoming opportunistic I1 (i.e., an I1 with a NULL destination HIT) as an I1 addressed to itself and SHOULD NOT attempt to relay it to one of its clients.
RVS应将任何传入的机会主义I1（即，目标命中为空的I1）解释为寻址到自身的I1，并且不应尝试将其中继到其客户机之一。
When a rendezvous client receives an I1, it MUST validate any present RVS_HMAC parameter. If the RVS_HMAC cannot be verified, the packet SHOULD be dropped. If the RVS_HMAC cannot be verified and a FROM parameter is present, the packet MUST be dropped.
当集合客户端接收到I1时，它必须验证任何现有的RVS_HMAC参数。如果无法验证RVS_HMAC，则应丢弃数据包。如果无法验证RVS_HMAC且存在FROM参数，则必须丢弃数据包。
A rendezvous client acting as Responder SHOULD drop opportunistic I1s that include a FROM parameter, because this indicates that the I1 has been relayed.
充当响应者的会合客户端应丢弃包含FROM参数的机会主义I1，因为这表明I1已被中继。
When a Responder replies to an I1 relayed via an RVS, it MUST append to the regular R1 header a VIA_RVS parameter containing the IP addresses of the traversed RVSs.
当响应者回复通过RVS中继的I1时，它必须向常规R1报头附加一个via_RVS参数，该参数包含被穿越RVS的IP地址。
The HIP specification [RFC7401] mandates that a system receiving an R1 MUST first check to see if it has sent an I1 to the originator of the R1 (i.e., the system is in state I1-SENT). When the R1 is replying to a relayed I1, this check SHOULD be based on HITs only. In case the IP addresses are also checked, then the source IP address MUST be checked against the IP address included in the VIA_RVS parameter.
HIP规范[RFC7401]规定，接收R1的系统必须首先检查是否已将I1发送给R1的发起人（即，系统处于I1-sent状态）。当R1回复中继I1时，该检查应仅基于点击。如果还检查了IP地址，则必须对照VIA_RVS参数中包含的IP地址检查源IP地址。
This section discusses the known threats introduced by these HIP extensions and the implications on the overall security of HIP. In particular, it argues that the extensions described in this document do not introduce additional threats to HIP.
本节讨论了这些髋关节延长带来的已知威胁以及对髋关节整体安全性的影响。特别是，它认为本文件中描述的扩展不会给HIP带来额外的威胁。
It is difficult to encompass the whole scope of threats introduced by RVSs because their presence has implications both at the IP and HIP layers. In particular, these extensions might allow for redirection, amplification, and reflection attacks at the IP layer, as well as attacks on the HIP layer itself, for example, man-in-the-middle attacks against the HIP base exchange.
很难涵盖RVSs引入的所有威胁，因为它们的存在对IP和HIP层都有影响。特别是，这些扩展可能允许在IP层进行重定向、放大和反射攻击，以及对HIP层本身的攻击，例如，针对HIP base exchange的中间人攻击。
If an Initiator has a priori knowledge of the Responder's host identity when it first contacts the Responder via an RVS, it has a means to verify the signatures in the HIP base exchange, which protects against man-in-the-middle attacks.
如果发起者在第一次通过RVS与响应者联系时对响应者的主机身份有先验知识，则发起者有办法验证HIP base exchange中的签名，从而防止中间人攻击。
If an Initiator does not have a priori knowledge of the Responder's host identity (so-called "opportunistic Initiators"), it is almost impossible to defend the HIP exchange against these attacks, because the public keys exchanged cannot be authenticated. The only approach would be to mitigate hijacking threats on HIP state by requiring an R1 answering an opportunistic I1 to come from the same IP address that originally sent the I1. This procedure retains a level of security that is equivalent to what exists in the Internet today.
如果发起者对响应者的主机身份（所谓的“机会主义发起者”）没有先验知识，则几乎不可能保护HIP交换免受这些攻击，因为交换的公钥无法进行身份验证。唯一的方法是通过要求应答机会主义I1的R1来自最初发送I1的相同IP地址来缓解HIP state上的劫持威胁。此过程保留的安全级别相当于当今互联网中的安全级别。
However, for reasons of simplicity, this specification does not allow the establishment of a HIP association via an RVS in an opportunistic manner.
然而，为简单起见，本规范不允许以机会主义方式通过RVS建立髋关节联合。
[RFC5204], obsoleted by this document, made the following definitions and reservations in the "Parameter Types" subregistry under "Host Identity Protocol (HIP) Parameters":
[RFC5204]已被本文件废除，在“主机标识协议（HIP）参数”下的“参数类型”子区域中做出以下定义和保留：
Value Parameter Type Length
----- -------------- --------
65498 FROM 16
65500 RVS_HMAC variable
65502 VIA_RVS variable
Value Parameter Type Length
----- -------------- --------
65498 FROM 16
65500 RVS_HMAC variable
65502 VIA_RVS variable
In the "Parameter Types" subregistry under "Host Identity Protocol (HIP) Parameters", references to [RFC5204] have been replaced by references to this document.
在“主机标识协议（HIP）参数”下的“参数类型”子区域中，对[RFC5204]的引用已替换为对本文件的引用。
[RFC5204], obsoleted by this document, made the following definition and reservation in the "Registration Types" subregistry under "Host Identity Protocol (HIP) Parameters":
[RFC5204]已被本文件废除，在“主机标识协议（HIP）参数”下的“注册类型”子区域中作出以下定义和保留：
Value Registration Type
----- -----------------
1 RENDEZVOUS
Value Registration Type
----- -----------------
1 RENDEZVOUS
In the "Registration Types" subregistry under "Host Identity Protocol (HIP) Parameters", references to [RFC5204] have been replaced by references to this document.
在“主机标识协议（HIP）参数”下的“注册类型”子区域中，对[RFC5204]的引用已替换为对本文件的引用。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <http://www.rfc-editor.org/info/rfc1122>.
[RFC1122]Braden，R.，Ed.“互联网主机的要求-通信层”，STD 3，RFC 1122，DOI 10.17487/RFC1122，1989年10月<http://www.rfc-editor.org/info/rfc1122>.
[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>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, <http://www.rfc-editor.org/info/rfc6724>.
[RFC6724]Thaler，D.，Ed.，Draves，R.，Matsumoto，A.，和T.Chown，“互联网协议版本6（IPv6）的默认地址选择”，RFC 6724，DOI 10.17487/RFC67242012年9月<http://www.rfc-editor.org/info/rfc6724>.
[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>.
[RFC8003] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Registration Extension", RFC 8003, DOI 10.17487/RFC8003, October 2016, <http://www.rfc-editor.org/info/rfc8003>.
[RFC8003]Laganier，J.和L.Eggert，“主机身份协议（HIP）注册扩展”，RFC 8003，DOI 10.17487/RFC8003，2016年10月<http://www.rfc-editor.org/info/rfc8003>.
[RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, October 2016, <http://www.rfc-editor.org/info/rfc8005>.
[RFC8005]Laganier，J.，“主机身份协议（HIP）域名系统（DNS）扩展”，RFC 8005，DOI 10.17487/RFC8005，2016年10月<http://www.rfc-editor.org/info/rfc8005>.
[HIP-ARCH] Moskowitz, R. and M. Komu, "Host Identity Protocol Architecture", Work in Progress, draft-ietf-hip-rfc4423- bis-14, June 2016.
[HIP-ARCH]Moskowitz，R.和M.Komu，“主机身份协议体系结构”，正在进行的工作，草案-ietf-HIP-rfc4423-bis-142016年6月。
[HIP-HOST-MOB] Henderson, T., Vogt, C., and J. Arkko, "Host Mobility with the Host Identity Protocol", Work in Progress, draft-ietf-hip-rfc5206-bis-14, October 2016.
[HIP-HOST-MOB]Henderson，T.，Vogt，C.，和J.Arkko，“使用主机身份协议的主机移动性”，正在进行的工作，草稿-ietf-HIP-rfc5206-bis-14，2016年10月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, <http://www.rfc-editor.org/info/rfc2827>.
[RFC2827]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，DOI 10.17487/RFC2827，2000年5月<http://www.rfc-editor.org/info/rfc2827>.
[RFC3013] Killalea, T., "Recommended Internet Service Provider Security Services and Procedures", BCP 46, RFC 3013, DOI 10.17487/RFC3013, November 2000, <http://www.rfc-editor.org/info/rfc3013>.
[RFC3013]Killalea，T.，“推荐的互联网服务提供商安全服务和程序”，BCP 46，RFC 3013，DOI 10.17487/RFC3013，2000年11月<http://www.rfc-editor.org/info/rfc3013>.
[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", RFC 5204, DOI 10.17487/RFC5204, April 2008, <http://www.rfc-editor.org/info/rfc5204>.
[RFC5204]Laganier，J.和L.Eggert，“主机身份协议（HIP）会合扩展”，RFC 5204，DOI 10.17487/RFC5204，2008年4月<http://www.rfc-editor.org/info/rfc5204>.
o Updated HIP references to revised HIP specifications.
o 更新髋关节参考，以修订髋关节规范。
Acknowledgments
致谢
The following people have provided thoughtful and helpful discussions and/or suggestions that have improved this document: Marcus Brunner, Tom Henderson, Miika Komu, Mika Kousa, Pekka Nikander, Juergen Quittek, Justino Santos, Simon Schuetz, Tim Shepard, Kristian Slavov, and Martin Stiemerling.
以下人员提供了有助于改进本文件的深思熟虑的讨论和/或建议：Marcus Brunner、Tom Henderson、Miika Komu、Mika Kousa、Pekka Nikander、Juergen Quitek、Justino Santos、Simon Schuetz、Tim Shepard、Kristian Slavov和Martin Stiemering。
Lars Eggert has received funding from the European Union's Horizon 2020 research and innovation program 2014-2018 under grant agreement No. 644866. This document reflects only the authors' views, and the European Commission is not responsible for any use that may be made of the information it contains.
Lars Eggert已收到欧盟地平线2020研究与创新计划2014-2018的资助，资助协议编号为644866。本文件仅反映了作者的观点，欧盟委员会不对其所含信息的任何使用负责。
Thanks to Joel M. Halpern for performing the Gen-ART review of this document as part of the publication process.
感谢Joel M.Halpern在出版过程中对本文件进行了Gen ART审查。
Authors' Addresses
作者地址
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
Lars Eggert NetApp Sonnenallee 1 Kirchheim 85551 Germany
德国基尔希海姆1号拉尔斯·埃格特·内塔普·索内纳利85551
Phone: +49 151 12055791
Email: lars@netapp.com
URI: http://eggert.org
Phone: +49 151 12055791
Email: lars@netapp.com
URI: http://eggert.org