Network Working Group J. Laganier
Request for Comments: 5204 DoCoMo Euro-Labs
Category: Experimental L. Eggert
Nokia
April 2008
Network Working Group J. Laganier
Request for Comments: 5204 DoCoMo Euro-Labs
Category: Experimental L. Eggert
Nokia
April 2008
Host Identity Protocol (HIP) Rendezvous Extension
主机身份协议（HIP）集合扩展
Status of This Memo
关于下段备忘
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
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 multi-homed or mobile.
本文档定义了主机标识协议（HIP）的会合扩展。会合扩展扩展扩展HIP和HIP注册扩展，用于通过HIP会合服务器启动HIP节点之间的通信。当HIP节点是多宿或移动的时，会合服务器提高了可达性和操作性。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Rendezvous Server Operation . . . . . . . . . . . 4
3.1. Diagram Notation . . . . . . . . . . . . . . . . . . . . . 5
3.2. Rendezvous Client Registration . . . . . . . . . . . . . . 6
3.3. Relaying the Base Exchange . . . . . . . . . . . . . . . . 6
4. Rendezvous Server Extensions . . . . . . . . . . . . . . . . . 7
4.1. RENDEZVOUS Registration Type . . . . . . . . . . . . . . . 7
4.2. Parameter Formats and Processing . . . . . . . . . . . . . 8
4.2.1. RVS_HMAC Parameter . . . . . . . . . . . . . . . . . . 8
4.2.2. FROM Parameter . . . . . . . . . . . . . . . . . . . . 9
4.2.3. VIA_RVS Parameter . . . . . . . . . . . . . . . . . . 10
4.3. Modified Packets Processing . . . . . . . . . . . . . . . 10
4.3.1. Processing Outgoing I1 Packets . . . . . . . . . . . . 10
4.3.2. Processing Incoming I1 Packets . . . . . . . . . . . . 11
4.3.3. Processing Outgoing R1 Packets . . . . . . . . . . . . 11
4.3.4. Processing Incoming R1 Packets . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 14
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Rendezvous Server Operation . . . . . . . . . . . 4
3.1. Diagram Notation . . . . . . . . . . . . . . . . . . . . . 5
3.2. Rendezvous Client Registration . . . . . . . . . . . . . . 6
3.3. Relaying the Base Exchange . . . . . . . . . . . . . . . . 6
4. Rendezvous Server Extensions . . . . . . . . . . . . . . . . . 7
4.1. RENDEZVOUS Registration Type . . . . . . . . . . . . . . . 7
4.2. Parameter Formats and Processing . . . . . . . . . . . . . 8
4.2.1. RVS_HMAC Parameter . . . . . . . . . . . . . . . . . . 8
4.2.2. FROM Parameter . . . . . . . . . . . . . . . . . . . . 9
4.2.3. VIA_RVS Parameter . . . . . . . . . . . . . . . . . . 10
4.3. Modified Packets Processing . . . . . . . . . . . . . . . 10
4.3.1. Processing Outgoing I1 Packets . . . . . . . . . . . . 10
4.3.2. Processing Incoming I1 Packets . . . . . . . . . . . . 11
4.3.3. Processing Outgoing R1 Packets . . . . . . . . . . . . 11
4.3.4. Processing Incoming R1 Packets . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 14
The Host Identity Protocol (HIP) Architecture [RFC4423] 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 [RFC5203] 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）体系结构[RFC4423]引入了会合机制，以帮助HIP节点联系频繁移动的HIP节点。会合机制涉及第三方，即会合服务器（RVS），它充当其客户端的初始接触点（“会合点”）。RVS的客户端是HIP节点，使用HIP注册扩展[RFC5203]向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 [RFC5201] and the HIP Registration Extension [RFC5203], this document defines and uses the following terms:
除HIP规范[RFC5201]和HIP注册扩展[RFC5203]中定义的术语外，本文件定义并使用以下术语：
Rendezvous Service A HIP service provided by a rendezvous server to its rendezvous clients. The rendezvous server offers to relay some of the arriving base exchange packets between the initiator and responder.
会合服务会合服务器向其会合客户端提供的HIP服务。集合服务器提供在发起方和响应方之间中继一些到达的基站交换数据包。
Rendezvous Server (RVS) A HIP registrar providing rendezvous service.
会合服务器（RVS）提供会合服务的HIP注册器。
Rendezvous Client A HIP requester that has registered for rendezvous service at a rendezvous server.
会合客户端已在会合服务器上注册会合服务的HIP请求者。
Rendezvous Registration A HIP registration for rendezvous service, established between a rendezvous server and a rendezvous client.
会合注册会合服务的HIP注册，在会合服务器和会合客户端之间建立。
Figure 1 shows a simple HIP base exchange without a rendezvous server, 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 [RFC5201].
图1显示了一个没有集合服务器的简单HIP基址交换，根据HIP规范[RFC5201]，启动器通过向响应者的IP地址发送I1数据包直接与响应者发起交换。
+-----+ +-----+
| |-------I1------>| |
| I |<------R1-------| R |
| |-------I2------>| |
| |<------R2-------| |
+-----+ +-----+
+-----+ +-----+
| |-------I1------>| |
| I |<------R1-------| R |
| |-------I2------>| |
| |<------R2-------| |
+-----+ +-----+
Figure 1: HIP base exchange without rendezvous server.
图1：没有集合服务器的HIP base exchange。
The End-Host Mobility and Multihoming with the Host Identity Protocol specification [RFC5206] 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.
主机身份协议规范[RFC5206]的终端主机移动性和多宿允许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 [RFC4423] introduces rendezvous servers 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 [RFC5205].
然而，这样的髋关节节点也可能希望能够与其他不知道其位置变化的未来通信对等方连接。HIP体系结构[RFC4423]引入了会合服务器，HIP节点可以向其注册主机标识标签（HITs）和当前IP地址。RVS将这些命中到达的HIP数据包中继到节点的注册IP地址。当HIP节点已向RVS注册时，应使用HIP DNS扩展[RFC5205]中定义的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 a rendezvous server. It is assumed that HIP node R previously registered its HITs and current IP addresses with the RVS, using the HIP Registration Extension [RFC5203]. When the initiator I tries to establish contact with the
图2显示了涉及会合服务器的HIP-base交换。假设HIP节点R先前使用HIP注册扩展[RFC5203]向RVS注册了其点击次数和当前IP地址。当启动器I尝试与
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 rendezvous servers. Here, I obtains the IP address of R's rendezvous server 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 to allow a client to initiate a base exchange through its own RVS, like NAT and firewall traversal. This specification does not address such scenarios, which should be specified in other documents.
响应者必须将基本交换的I1发送到R的一个IP地址（如果通过DNS或其他方式知道）或R的一个集合服务器。在这里，我从R的DNS记录中获得R的会合服务器的IP地址，然后将HIP base exchange的I1数据包发送到RVS。RVS注意到到达的I1数据包中包含的HIT不是自己的，必须检查其当前注册，以确定是否需要中继数据包。这里，它确定HIT属于R，然后将I1分组中继到注册的IP地址。然后，通过将R1直接发送到I的IP地址（从I1数据包获得），R在不需要RVS进一步协助的情况下完成基本交换。在本规范中，RVS的客户始终是响应者。然而，可能有理由允许客户端通过自己的RVS（如NAT和防火墙遍历）启动基本交换。本规范不涉及此类场景，应在其他文件中指定。
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 HMAC keyed with the appropriate registration key is present in the HIP header.
RVS_HMAC髋关节头中存在一个RVS_HMAC参数，该参数包含一个使用适当注册密钥键入的HMAC。
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 a rendezvous server starts to relay HIP packets to a rendezvous client, the rendezvous client needs to register with it to receive rendezvous service by using the HIP Registration Extension [RFC5203] as illustrated in the following schema:
在会合服务器开始将HIP数据包中继到会合客户端之前，会合客户端需要使用HIP注册扩展[RFC5203]向其注册以接收会合服务，如以下模式所示：
+-----+ +-----+
| | 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 rendezvous servers have a rendezvous registration, the rendezvous servers 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节点及其会合服务器之一具有会合注册，则会合服务器通过重写IP报头来中继入站I1数据包（其中包含客户端的一个点击）。它们将I1数据包的目标IP地址替换为HIT所有者（即集合客户端）的IP地址之一。他们还必须相应地重新计算IP校验和。
Because of egress filtering on the path from the RVS to the client [RFC2827][RFC3013], a HIP rendezvous server 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][RFC3484]. 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 [RFC5203].
由于在从RVS到客户端[RFC2827][RFC3013]的路径上进行出口过滤，HIP会合服务器应将源IP地址（即i的IP地址）替换为其自己的IP地址之一。应根据相关IPv4和IPv6规范[RFC1122][RFC3484]选择替换IP地址。由于此替换隐藏了启动器的IP地址，因此RVS必须附加一个FROM参数，该参数包含数据包的原始源IP地址。此FROM参数必须由一个RVS_HMAC完整性保护，该RVS_HMAC使用相应的会合注册完整性密钥[RFC5203]进行键控。
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 a rendezvous server can be problematic because the HIP protocol 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 rendezvous servers.
在会合服务器上修改HIP数据包可能会有问题，因为HIP协议使用完整性检查。由于I1不包括HMAC或签名参数，因此这两个端到端完整性检查不受会合服务器操作的影响。
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 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.
在进行任何修改之前，RVS应验证I1数据包的校验和字段。修改后，必须使用更新的HIP标头（可能包括新的FROM和RVS_HMAC参数）和包含更新的源和目标IP地址的伪标头重新计算校验和字段。这使响应程序能够“按原样”验证I1数据包的校验和，而无需解析任何FROM参数。
This section describes extensions to the HIP Registration Extension [RFC5203], allowing a HIP node to register with a rendezvous server for rendezvous service and notify the RVS aware of changes to its current location. It also describes an extension to the HIP specification [RFC5201] itself, allowing establishment of HIP associations via one or more HIP rendezvous server(s).
本节描述了HIP注册扩展[RFC5203]的扩展，允许HIP节点向集合服务器注册集合服务，并通知RVS其当前位置的更改。它还描述了HIP规范[RFC5201]本身的扩展，允许通过一个或多个HIP会合服务器建立HIP关联。
This specification defines an additional registration for the HIP Registration Extension [RFC5203] that allows registering with a rendezvous server for rendezvous service.
本规范定义了HIP注册扩展[RFC5203]的附加注册，该扩展允许向会合服务器注册会合服务。
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 [RFC5201] is its "type" code. This change causes it to be located after the FROM parameter (as opposed to the HMAC):
RVS_HMAC是一个非关键参数，其与HIP规范[RFC5201]中定义的HMAC参数的唯一区别在于其“类型”代码。此更改导致其位于FROM参数之后（与HMAC相反）：
Type 65500 Length Variable. Length in octets, excluding Type, Length, and Padding. 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.
键入65500长度变量。长度（以八位字节为单位），不包括类型、长度和填充。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地址。
A rendezvous server 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地址被重写时，集合服务器必须添加一个FROM参数，该参数包含HIP数据包的原始源IP地址。如果已经存在一个或多个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 MAY include a subset of the IP addresses of its RVSs in some of these packets. When a responder does so, it MUST append a newly created VIA_RVS parameter at the end of the HIP packet. 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的进一步协助。出于调试目的，它可以在其中一些数据包中包含其RVS的IP地址子集。当响应程序这样做时，它必须在HIP数据包的末尾附加一个新创建的VIA_RVS参数。使用VIA_RVS参数的主要目的是允许操作员诊断通过RVS建立髋关节关联时可能遇到的问题。
The following subsections describe the differences of processing of I1 and R1 while a rendezvous server is involved in the base exchange.
以下小节描述了在基础交换中涉及会合服务器时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 rendezvous server itself and does not know its HIT.
启动器不应将目标命中为空的机会主义I1发送到已知为集合服务器地址的IP地址，除非它希望与集合服务器本身建立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 a rendezvous server 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.
当会合服务器接收到目标命中不是其自己的I1时，它会查阅其注册数据库以查找由命中所有者建立的会合服务的注册。如果找到合适的注册，它会将数据包转发到注册的IP地址。如果没有找到合适的注册，它将丢弃数据包。
A rendezvous server 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.
集合服务器应将任何传入的机会主义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 [RFC5201] 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规范[RFC5201]规定，接收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 the Host Identity Protocol.
本节讨论了这些髋关节延长带来的已知威胁以及对髋关节整体安全性的影响。特别是，它认为本文档中描述的扩展不会给主机身份协议带来额外的威胁。
It is difficult to encompass the whole scope of threats introduced by rendezvous servers 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.
很难涵盖集合服务器引入的所有威胁，因为它们的存在对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 a rendezvous server in an opportunistic manner.
然而，出于简单的原因，本规范不允许以机会主义的方式通过集合服务器建立HIP关联。
This section is to be interpreted according to the Guidelines for Writing an IANA Considerations Section in RFCs [RFC2434].
本节将根据RFCs[RFC2434]中编写IANA注意事项部分的指南进行解释。
This document updates the IANA Registry for HIP Parameters Types by assigning new HIP Parameter Types values for the new HIP Parameters defined in Section 4.2:
本文件通过为第4.2节中定义的新髋关节参数分配新髋关节参数类型值，更新了髋关节参数类型的IANA注册表：
o RVS_HMAC (defined in Section 4.2.1)
o RVS_HMAC（定义见第4.2.1节）
o FROM (defined in Section 4.2.2)
o 起始（定义见第4.2.2节）
o VIA_RVS (defined in Section 4.2.3)
o 通过RVS（定义见第4.2.3节）
This document defines an additional registration for the HIP Registration Extension [RFC5203] that allows registering with a rendezvous server for rendezvous service.
本文档定义了HIP注册扩展[RFC5203]的附加注册，该扩展允许向会合服务器注册会合服务。
Number Registration Type
------ -----------------
1 RENDEZVOUS
Number Registration Type
------ -----------------
1 RENDEZVOUS
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, Justino Santos, Simon Schuetz, Tim Shepard, Kristian Slavov, Martin Stiemerling, and Juergen Quittek.
以下人员提供了有助于改进本文件的深思熟虑的讨论和/或建议：Marcus Brunner、Tom Henderson、Miika Komu、Mika Kousa、Pekka Nikander、Justino Santos、Simon Schuetz、Tim Shepard、Kristian Slavov、Martin Stiemering和Juergen Quitek。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[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月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484]Draves，R.，“互联网协议版本6（IPv6）的默认地址选择”，RFC 3484，2003年2月。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201]Moskowitz，R.，Nikander，P.，Jokela，P.，Ed.，和T.Henderson，“主机身份协议”，RFC 52012008年4月。
[RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity Protocol (HIP) Registration Extension", RFC 5203, April 2008.
[RFC5203]Laganier，J.，Koponen，T.，和L.Eggert，“主机身份协议（HIP）注册扩展”，RFC 52032008年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月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[RFC3013] Killalea, T., "Recommended Internet Service Provider Security Services and Procedures", BCP 46, RFC 3013, November 2000.
[RFC3013]Killalea，T.，“推荐的互联网服务提供商安全服务和程序”，BCP 46，RFC 3013，2000年11月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4423]Moskowitz，R.和P.Nikander，“主机身份协议（HIP）体系结构”，RFC 4423，2006年5月。
[RFC5206] Henderson, T., Ed., "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008.
[RFC5206]Henderson，T.，Ed.“终端主机移动性和主机身份协议的多宿”，RFC 5206，2008年4月。
Authors' Addresses
作者地址
Julien Laganier DoCoMo Communications Laboratories Europe GmbH Landsberger Strasse 312 Munich 80687 Germany
Julien Laganier DoCoMo通信实验室欧洲有限公司兰德斯伯格大街312慕尼黑80687德国
Phone: +49 89 56824 231
EMail: julien.ietf@laposte.net
URI: http://www.docomolab-euro.com/
Phone: +49 89 56824 231
EMail: julien.ietf@laposte.net
URI: http://www.docomolab-euro.com/
Lars Eggert Nokia Research Center P.O. Box 407 Nokia Group 00045 Finland
芬兰诺基亚集团00045诺基亚研究中心邮政信箱407
Phone: +358 50 48 24461
EMail: lars.eggert@nokia.com
URI: http://research.nokia.com/people/lars_eggert/
Phone: +358 50 48 24461
EMail: lars.eggert@nokia.com
URI: http://research.nokia.com/people/lars_eggert/
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.