Internet Engineering Task Force (IETF) J. Laganier
Request for Comments: 8003 Luminate Wireless, Inc.
Obsoletes: 5203 L. Eggert
Category: Standards Track NetApp
ISSN: 2070-1721 October 2016
Internet Engineering Task Force (IETF) J. Laganier
Request for Comments: 8003 Luminate Wireless, Inc.
Obsoletes: 5203 L. Eggert
Category: Standards Track NetApp
ISSN: 2070-1721 October 2016
Host Identity Protocol (HIP) Registration Extension
主机标识协议（HIP）注册扩展
Abstract
摘要
This document specifies a registration mechanism for the Host Identity Protocol (HIP) that allows hosts to register with services, such as HIP rendezvous servers or middleboxes. This document obsoletes RFC 5203.
本文档指定了主机标识协议（HIP）的注册机制，该机制允许主机向服务（如HIP会合服务器或中间盒）注册。本文件淘汰了RFC 5203。
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/rfc8003.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8003.
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. HIP Registration Extension Overview . . . . . . . . . . . . . 3
3.1. Registrar Announcing Its Ability . . . . . . . . . . . . 4
3.2. Requester Requesting Registration . . . . . . . . . . . . 4
3.3. Registrar Granting or Refusing Service(s) Registration . 4
4. Parameter Formats and Processing . . . . . . . . . . . . . . 7
4.1. Encoding Registration Lifetimes with Exponents . . . . . 7
4.2. REG_INFO . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. REG_REQUEST . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. REG_RESPONSE . . . . . . . . . . . . . . . . . . . . . . 9
4.5. REG_FAILED . . . . . . . . . . . . . . . . . . . . . . . 10
5. Establishing and Maintaining Registrations . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Changes from RFC 5203 . . . . . . . . . . . . . . . 15
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. HIP Registration Extension Overview . . . . . . . . . . . . . 3
3.1. Registrar Announcing Its Ability . . . . . . . . . . . . 4
3.2. Requester Requesting Registration . . . . . . . . . . . . 4
3.3. Registrar Granting or Refusing Service(s) Registration . 4
4. Parameter Formats and Processing . . . . . . . . . . . . . . 7
4.1. Encoding Registration Lifetimes with Exponents . . . . . 7
4.2. REG_INFO . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. REG_REQUEST . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. REG_RESPONSE . . . . . . . . . . . . . . . . . . . . . . 9
4.5. REG_FAILED . . . . . . . . . . . . . . . . . . . . . . . 10
5. Establishing and Maintaining Registrations . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Changes from RFC 5203 . . . . . . . . . . . . . . . 15
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
This document specifies an extension to the Host Identity Protocol (HIP) [RFC7401]. The extension provides a generic means for a host to register with a service. The service may, for example, be a HIP rendezvous server [RFC8004] or a middlebox [RFC3234].
本文档指定了主机标识协议（HIP）[RFC7401]的扩展。扩展为主机注册服务提供了一种通用方法。例如，该服务可以是髋关节会合服务器[RFC8004]或中间盒[RFC3234]。
This document makes no further assumptions about the exact type of service. Likewise, this document does not specify any mechanisms to discover the presence of specific services or means to interact with them after registration. Future documents may describe those operations.
本文件对服务的确切类型不作进一步假设。同样，本文档没有指定任何机制来发现特定服务的存在，也没有指定注册后与这些服务交互的方法。未来的文件可能会描述这些操作。
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 Architecture [HIP-ARCH], the HIP specification [RFC7401], and the HIP Rendezvous Extension [RFC8004], this document defines and uses the following terms:
除了髋关节体系结构[HIP-ARCH]、髋关节规范[RFC7401]和髋关节会合扩展[RFC8004]中定义的术语外，本文件定义并使用以下术语：
Requester: a HIP node registering with a HIP registrar to request registration for a service.
请求者：向HIP注册器注册以请求服务注册的HIP节点。
Registrar: a HIP node offering registration for one or more services.
注册器：为一个或多个服务提供注册的髋关节节点。
Service: a facility that provides requesters with new capabilities or functionalities operating at the HIP layer. Examples include firewalls that support HIP traversal or HIP rendezvous servers.
服务：为请求者提供在HIP层操作的新功能的设施。示例包括支持髋关节穿越或髋关节会合服务器的防火墙。
Registration: shared state stored by a requester and a registrar, allowing the requester to benefit from one or more HIP services offered by the registrar. Each registration has an associated finite lifetime. Requesters can extend established registrations through re-registration (i.e., perform a refresh).
注册：由请求者和注册者存储的共享状态，允许请求者从注册者提供的一个或多个HIP服务中受益。每个注册都有一个相关的有限生存期。请求者可以通过重新注册（即执行刷新）来扩展已建立的注册。
Registration Type: an 8-bit identifier for a given service in the registration protocol. For example, the rendezvous service is identified by a specific registration type.
注册类型：注册协议中给定服务的8位标识符。例如，会合服务由特定的注册类型标识。
This document does not specify the means by which a requester discovers the availability of a service or how a requester locates a registrar. After a requester has discovered a registrar, it either initiates HIP base exchange or uses an existing HIP association with the registrar. In both cases, registrars use additional parameters, which the remainder of this document defines, to announce their quality and grant or refuse registration. Requesters use corresponding parameters to register with the service. Both the registrar and the requester MAY also include in the messages exchanged additional HIP parameters specific to the registration type requested. Other documents will define parameters and how they shall be used.
本文档未指定请求者发现服务可用性的方法，也未指定请求者如何查找注册器。在请求者发现注册器后，它要么启动HIP-base交换，要么使用与注册器的现有HIP关联。在这两种情况下，注册人使用本文件其余部分定义的其他参数来宣布其质量并授予或拒绝注册。请求者使用相应的参数向服务注册。注册者和请求者还可以在交换的消息中包括特定于所请求的注册类型的附加HIP参数。其他文件将定义参数及其使用方式。
The HIP base exchange, including the definition of the HIP I1, R1, I2, and R2 packets, is defined in [RFC7401]. The following sections describe the differences between this registration handshake and the standard HIP base exchange [RFC7401].
HIP-base交换，包括HIP I1、R1、I2和R2数据包的定义，在[RFC7401]中定义。以下各节描述了此注册握手与标准髋关节基底交换[RFC7401]之间的差异。
A host that is capable and willing to act as a registrar vis-a-vis a specific requester SHOULD include a REG_INFO parameter in the R1 packets it sends during all base exchanges with that requester. If it is currently unable to provide services due to transient conditions, it SHOULD include an empty REG_INFO, i.e., one with no services listed. If services can be provided later, it SHOULD send UPDATE packets indicating the current set of services available in a new REG_INFO parameter to all hosts it is associated with.
能够并愿意充当针对特定请求者的注册器的主机应在其与该请求者的所有基本交换期间发送的R1数据包中包含REG_INFO参数。如果由于瞬态条件，当前无法提供服务，则应包含空的注册信息，即未列出任何服务。如果以后可以提供服务，它应该向与其关联的所有主机发送更新数据包，该数据包在新的REG_INFO参数中指示当前可用的服务集。
To request registration with a service, a requester constructs and includes a corresponding REG_REQUEST parameter in an I2 or UPDATE packet it sends to the registrar.
为了向服务请求注册，请求者在发送给注册者的I2或更新包中构造并包括相应的REG_请求参数。
If the requester has no HIP association established with the registrar, it SHOULD send the REG_REQUEST at the earliest possibility, i.e., in the I2 packet. This minimizes the number of packets that need to be exchanged with the registrar. A registrar MAY end a HIP association that does not carry a REG_REQUEST by including a NOTIFY with the type REG_REQUIRED in the R2. In this case, no HIP association is created between the hosts. The REG_REQUIRED notification error type is 51.
如果请求者未与注册者建立HIP关联，则应尽早发送REG_请求，即在I2数据包中发送。这将最小化需要与注册器交换的数据包的数量。注册官可以通过包含R2中要求的REG_类型的通知来结束未携带REG_请求的HIP协会。在这种情况下，不会在主机之间创建髋部关联。REG_必需的通知错误类型为51。
Once registration has been requested, the registrar is able to authenticate the requester based on the host identity included in I2.
一旦请求了注册，注册器就能够根据I2中包含的主机标识对请求者进行身份验证。
If the registrar knows the Host Identities (HIs) of all the hosts that are allowed to register for service(s), it SHOULD reject registrations from unknown hosts. However, since it may be infeasible to preconfigure the registrar with all the HIs, the registrar SHOULD also support HIP certificates [RFC8002] to allow for certificate-based authentication.
如果注册器知道允许注册服务的所有主机的主机标识（HI），则应拒绝来自未知主机的注册。然而，由于不可能预先配置注册器和所有HI，注册器还应该支持HIP证书[RFC8002]，以允许基于证书的身份验证。
When a requester wants to register with a registrar, it SHOULD check if it has a suitable certificate for authenticating with the registrar. How the suitability is determined and how the certificates are obtained is out of scope for this document. If the requester has one or more suitable certificates, the host SHOULD
当请求者想要向注册者注册时，它应该检查是否有合适的证书来向注册者进行认证。如何确定适用性以及如何获得证书超出了本文件的范围。如果请求者有一个或多个合适的证书，则主机应
include them (or just the most suitable one) in a CERT parameter to the HIP packet along with the REG_REQUEST parameter. If the requester does not have any suitable certificates, it SHOULD send the registration request without the CERT parameter to test whether the registrar accepts the request based on the host's identity.
将它们（或最合适的一个）与REG_请求参数一起包含在HIP数据包的CERT参数中。如果请求者没有任何合适的证书，则应发送不带CERT参数的注册请求，以测试注册者是否基于主机的身份接受请求。
When a registrar receives a HIP packet with a REG_REQUEST parameter, and it requires authentication for at least one of the registration types listed in the REG_REQUEST parameter, it MUST first check whether the HI of the requester is in the allowed list for all the registration types in the REG_REQUEST parameter. If the requester is in the allowed list (or the registrar does not require any authentication), the registrar MUST proceed with the registration.
当注册器接收到带有REG_请求参数的HIP数据包，并且它要求对REG_请求参数中列出的至少一种注册类型进行身份验证时，它必须首先检查请求者的HI是否在REG_请求参数中所有注册类型的允许列表中。如果请求者在允许名单中（或注册官不要求任何认证），注册官必须继续进行注册。
If the requester was not in the allowed list and the registrar requires the requester to authenticate, the registrar MUST check whether the packet also contains a CERT parameter. If the packet does not contain a CERT parameter, the registrar MUST reject the registrations requiring authentication with Failure Type 0 (zero) (registration requires additional credentials). If the certificate is valid and accepted (issued for the requester and signed by a trusted issuer), the registrar MUST proceed with the registration. If the certificate in the parameter is not accepted, the registrar MUST reject the corresponding registrations with the appropriate Failure Type:
如果请求者不在允许列表中，并且注册官要求请求者进行身份验证，则注册官必须检查数据包是否还包含CERT参数。如果数据包不包含CERT参数，则注册器必须拒绝需要验证且失败类型为0（零）的注册（注册需要其他凭据）。如果证书有效且被接受（为请求者颁发并由受信任的颁发者签署），则注册官必须继续进行注册。如果参数中的证书不被接受，则注册机构必须拒绝相应故障类型的注册：
4 (Bad certificate): The certificate is corrupt, contains invalid signatures, etc.
4（坏证书）：证书已损坏，包含无效签名等。
5 (Unsupported certificate): The certificate is of an unsupported type.
5（不支持的证书）：证书的类型不受支持。
6 (Certificate expired): The certificate is no longer valid.
6（证书过期）：证书不再有效。
7 (Certificate other): The certificate could not be validated for some unspecified reason.
7（证书其他）：由于某些未指定的原因，无法验证证书。
8 (Unknown CA): The issuing certification authority (CA) certificate could not be located or is not trusted.
8（未知CA）：无法找到颁发证书颁发机构（CA）证书或证书不受信任。
After successful authorization, the registrar includes a REG_RESPONSE parameter in its response, which contains the service type(s) for which it has authorized registration, and zero or more REG_FAILED parameters containing the service type(s) for which it has not authorized registration or registration has failed for other reasons. This response can be either an R2 or an UPDATE message, respectively, depending on whether the registration was requested during the base
成功授权后，注册器在其响应中包含一个REG_响应参数，该参数包含其已授权注册的服务类型，以及零个或多个REG_失败参数，该参数包含其未授权注册或因其他原因注册失败的服务类型。此响应可以是R2消息，也可以是更新消息，具体取决于注册是否在基本过程中请求
exchange or using an existing association. In particular, REG_FAILED with a Failure Type of zero indicates the service type(s) that requires further credentials for registration.
交换或使用现有关联。特别是，REG_FAILED（失败类型为零）表示需要更多凭据才能注册的服务类型。
If the registrar requires further authorization and the requester has additional credentials available, the requester SHOULD try to register again with the service after the HIP association has been established.
如果注册者需要进一步授权，并且请求者具有其他可用凭据，则请求者应在HIP关联建立后尝试再次向服务注册。
Successful processing of a REG_RESPONSE parameter creates registration state at the requester. In a similar manner, successful processing of a REG_REQUEST parameter creates registration state at the registrar and possibly at the service. Both the requester and registrar can cancel a registration before it expires, if the services afforded by a registration are no longer needed by the requester or cannot be provided any longer by the registrar (for instance, because its configuration has changed).
成功处理REG_响应参数将在请求者处创建注册状态。以类似的方式，成功处理REG_请求参数会在注册器和服务上创建注册状态。如果请求者不再需要注册提供的服务，或者注册者无法再提供注册提供的服务（例如，因为注册的配置已更改），则请求者和注册者都可以在注册到期之前取消注册。
+-----+ I1 +-----+-----+
| |--------------------->| | S1 |
| |<---------------------| | |
| | R1(REG_INFO:S1,S2,S3)| +-----+
| RQ | | R | S2 |
| | I2(REG_REQ:S1) | | |
| |--------------------->| +-----+
| |<---------------------| | S3 |
| | R2(REG_RESP:S1) | | |
+-----+ +-----+-----+
+-----+ I1 +-----+-----+
| |--------------------->| | S1 |
| |<---------------------| | |
| | R1(REG_INFO:S1,S2,S3)| +-----+
| RQ | | R | S2 |
| | I2(REG_REQ:S1) | | |
| |--------------------->| +-----+
| |<---------------------| | S3 |
| | R2(REG_RESP:S1) | | |
+-----+ +-----+-----+
A requester (RQ) registers for service (S1) with a registrar (R) of services (S1), (S2), and (S3) with which it has no current HIP association
请求者（RQ）向服务（S1）、（S2）和（S3）的注册者（R）注册服务（S1），而其当前与服务（S1）、（S2）和（S3）没有关联
+-----+ +-----+-----+
| | UPDATE(REG_INFO:S) | | |
| |<---------------------| | |
| RQ |--------------------->| R | S |
| | UPDATE(REG_REQ:S) | | |
| | UPDATE(REG_RESP:S) | | |
| |<---------------------| | |
+-----+ +-----+-----+
+-----+ +-----+-----+
| | UPDATE(REG_INFO:S) | | |
| |<---------------------| | |
| RQ |--------------------->| R | S |
| | UPDATE(REG_REQ:S) | | |
| | UPDATE(REG_RESP:S) | | |
| |<---------------------| | |
+-----+ +-----+-----+
A requester (RQ) registers for service (S) with a registrar (R) of services (S) with which it currently has a HIP association established
请求者（RQ）向其当前已建立HIP关联的服务注册者（R）注册服务
This section describes the format and processing of the new parameters introduced by the HIP Registration Extension. The encoding of these new parameters conforms to the HIPv2 TLV format described in Section 5.2.1 of RFC7401 [RFC7401].
本节介绍髋部注册扩展引入的新参数的格式和处理。这些新参数的编码符合RFC7401[RFC7401]第5.2.1节所述的HIPv2 TLV格式。
The HIP registration uses an exponential encoding of registration lifetimes.
髋部注册使用注册生存期的指数编码。
The special value 0 (zero) of the lifetime field MUST be interpreted as representing a special lifetime duration of 0 (zero) seconds and is used to request and grant cancellation of a registration.
生存期字段的特殊值0（零）必须解释为表示0（零）秒的特殊生存期持续时间，并用于请求和授予取消注册。
The non-zero values of the lifetime field used throughout this document MUST be interpreted as an exponent value representing a lifetime duration of 2^((lifetime - 64)/8) seconds.
本文档中使用的生存期字段的非零值必须解释为表示2^（（生存期-64）/8）秒生存期持续时间的指数值。
This allows a compact encoding of 255 different lifetime durations (in addition to the special lifetime duration of zero seconds) ranging from 2^(63/8) seconds (i.e., ~4 ms) to 2^(191/8) seconds (i.e., ~178 days) into an 8-bit integer field.
这允许将255个不同的生存期（除了特殊的零秒生存期）压缩编码到8位整数字段中，范围从2^（63/8）秒（即~4毫秒）到2^（191/8）秒（即~178天）。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min Lifetime | Max Lifetime | Reg Type #1 | Reg Type #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... | Reg Type #n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min Lifetime | Max Lifetime | Reg Type #1 | Reg Type #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... | Reg Type #n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 930 Length Length in octets, excluding Type, Length, and Padding. Min Lifetime Minimum registration lifetime. Max Lifetime Maximum registration lifetime. Reg Type The registration types offered by the registrar.
类型930长度八位字节，不包括类型、长度和填充。最小生存期最小注册生存期。最大生存期最大注册生存期。注册类型注册商提供的注册类型。
Other documents will define specific values for registration types. See Section 7 for more information.
其他文档将定义注册类型的特定值。更多信息请参见第7节。
Registrars include the parameter in R1 packets in order to announce their registration capabilities. The registrar SHOULD include the parameter in UPDATE packets when its service offering has changed. HIP_SIGNATURE_2 protects the parameter within the R1 packets.
注册器在R1数据包中包含该参数，以便宣布其注册功能。当注册器的服务产品发生变化时，注册器应在更新包中包含该参数。HIP_签名_2保护R1数据包内的参数。
The registrar indicates the minimum and maximum registration lifetime that it is willing to offer to a requester. A requester SHOULD NOT request registration with a lifetime greater than the maximum registration lifetime or smaller than the minimum registration lifetime.
注册官指出其愿意向请求者提供的最短和最长注册期限。请求者不应以大于最大注册生存期或小于最小注册生存期的生存期请求注册。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Reg Type #1 | Reg Type #2 | Reg Type #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... | Reg Type #n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Reg Type #1 | Reg Type #2 | Reg Type #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... | Reg Type #n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 932 Length Length in octets, excluding Type, Length, and Padding. Lifetime Requested registration lifetime. Reg Type The preferred registration types in order of preference.
932型长度八位字节，不包括类型、长度和填充。生存期请求的注册生存期。Reg Type按优先顺序选择优先注册类型。
Other documents will define specific values for registration types. See Section 7 for more information.
其他文档将定义注册类型的特定值。更多信息请参见第7节。
A requester includes the REG_REQUEST parameter in I2 or UPDATE packets to register with a registrar's service(s). If the REG_REQUEST parameter is in an UPDATE packet, the registrar MUST NOT modify the registrations of registration types that are not listed in the parameter. Moreover, the requester MUST NOT include the parameter unless the registrar's R1 packet or latest received UPDATE packet has contained a REG_INFO parameter with the requested registration types.
请求者在I2中包含REG_请求参数，或更新数据包以向注册器的服务注册。如果REG_请求参数在更新数据包中，注册员不得修改参数中未列出的注册类型的注册。此外，请求者不得包含该参数，除非注册器的R1数据包或最新收到的更新数据包包含具有请求的注册类型的REG_INFO参数。
The requester MUST NOT include more than one REG_REQUEST parameter in its I2 or UPDATE packets, while the registrar MUST be able to process one or more REG_REQUEST parameters in received I2 or UPDATE packets.
请求者不得在其I2或更新数据包中包含多个REG_请求参数，而注册者必须能够处理接收到的I2或更新数据包中的一个或多个REG_请求参数。
When the registrar receives a registration with a lifetime that is either smaller or greater than the minimum or maximum lifetime, respectively, then it SHOULD grant the registration for the minimum or maximum lifetime, respectively.
当注册官收到的注册有效期分别小于或大于最小或最大有效期时，则注册官应分别授予最小或最大有效期的注册。
HIP_SIGNATURE protects the parameter within the I2 and UPDATE packets.
HIP_签名保护I2和更新数据包中的参数。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Reg Type #1 | Reg Type #2 | Reg Type #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... | Reg Type #n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Reg Type #1 | Reg Type #2 | Reg Type #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... | Reg Type #n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 934 Length Length in octets, excluding Type, Length, and Padding. Lifetime Granted registration lifetime. Reg Type The granted registration types in order of preference.
934类型长度八位字节，不包括类型、长度和填充。终身授予注册终身。Reg Type按优先顺序指定已授予的注册类型。
Other documents will define specific values for registration types. See Section 7 for more information.
其他文档将定义注册类型的特定值。更多信息请参见第7节。
The registrar SHOULD include a REG_RESPONSE parameter in its R2 or UPDATE packet only if a registration has successfully completed.
仅当注册成功完成时，注册器才应在其R2或更新数据包中包含REG_响应参数。
The registrar MUST NOT include more than one REG_RESPONSE parameter in its R2 or UPDATE packets, while the requester MUST be able to process one or more REG_RESPONSE parameters in received R2 or UPDATE packets.
注册器不得在其R2或更新数据包中包含多个REG_响应参数，而请求者必须能够处理接收到的R2或更新数据包中的一个或多个REG_响应参数。
The requester MUST be prepared to receive any registration lifetime, including ones beyond the minimum and maximum lifetime indicated in the REG_INFO parameter. It MUST NOT expect that the returned lifetime will be the requested one, even when the requested lifetime falls within the announced minimum and maximum.
请求者必须准备好接收任何注册生存期，包括超出REG_INFO参数中指示的最小和最大生存期的注册生存期。它不能期望返回的生存期将是请求的生存期，即使请求的生存期在宣布的最小值和最大值范围内。
HIP_SIGNATURE protects the parameter within the R2 and UPDATE packets.
HIP_签名保护R2和更新数据包中的参数。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Failure Type | Reg Type #1 | Reg Type #2 | Reg Type #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... | Reg Type #n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Failure Type | Reg Type #1 | Reg Type #2 | Reg Type #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... | Reg Type #n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 936 Length Length in octets, excluding Type, Length, and Padding. Failure Type Reason for failure. Reg Type The registration types that failed with the specified reason.
936型长度八位字节，不包括类型、长度和填充。故障类型故障原因。Reg Type由于指定原因失败的注册类型。
Value Registration Failure Type
---------- --------------------------------------------
0 Registration requires additional credentials
1 Registration type unavailable
2 Insufficient resources
3 Invalid certificate
9-200 Unassigned
201-255 Reserved for Private Use
Value Registration Failure Type
---------- --------------------------------------------
0 Registration requires additional credentials
1 Registration type unavailable
2 Insufficient resources
3 Invalid certificate
9-200 Unassigned
201-255 Reserved for Private Use
Other documents will define specific values for registration types. See Section 7 for more information.
其他文档将定义注册类型的特定值。更多信息请参见第7节。
Failure Type 0 (zero) indicates that the registrar requires additional credentials to authorize a requester to register with the registration types listed in the parameter. Failure Type 1 (one) indicates that the requested service type is unavailable at the registrar. Failure Type 2 indicates that the registrar does not currently have enough resources to register the requester for the service(s); when that is the case, the requester MUST NOT reattempt immediately to register for the same service(s) and MAY attempt to contact another registrar to register for the service(s). Failure Type 3 indicates that the registrar could not validate the certificate provided by the requester to register for the service(s); when that is the case, the requester MUST NOT reattempt to register for the same set of services while providing the same certificate and MAY attempt to register for the same set of services with a different certificate, or with a different set of services with the same certificate.
故障类型0（零）表示注册器需要其他凭据来授权请求者使用参数中列出的注册类型注册。故障类型1（一）表示请求的服务类型在注册中心不可用。故障类型2表示注册器当前没有足够的资源来注册服务的请求者；在这种情况下，请求者不得立即重新尝试注册相同的服务，并可尝试联系其他注册者以注册该服务。故障类型3表示注册官无法验证请求者提供的证书以注册服务；在这种情况下，请求者不得在提供相同证书的同时重新尝试注册相同的服务集，并且可以尝试使用不同的证书注册相同的服务集，或者使用相同证书注册不同的服务集。
The registrar SHOULD include a REG_FAILED parameter in its R2 or UPDATE packet, if registration with the registration types listed has not completed successfully, and a requester is asked to try again with additional credentials.
如果使用列出的注册类型注册未成功完成，并且请求者被要求使用其他凭据重试，则注册器应在其R2或更新数据包中包含REG_FAILED参数。
HIP_SIGNATURE protects the parameter within the R2 and UPDATE packets.
HIP_签名保护R2和更新数据包中的参数。
Establishing and/or maintaining a registration may require additional information not available in the transmitted REG_REQUEST or REG_RESPONSE parameters. Therefore, registration type definitions MAY define dependencies for HIP parameters that are not defined in this document. Their semantics are subject to the specific registration type specifications.
建立和/或维护注册可能需要传输的注册请求或注册响应参数中不可用的附加信息。因此，注册类型定义可能会定义本文档中未定义的HIP参数的相关性。它们的语义受特定注册类型规范的约束。
The minimum lifetime both registrars and requesters MUST support is 10 seconds, while they SHOULD support a maximum lifetime of 120 seconds, at least. These values define a baseline for the specification of services based on the registration system. They were chosen to be neither too short nor too long, and to accommodate for existing timeouts of state established in middleboxes (e.g., NATs and firewalls.)
注册者和请求者必须支持的最短生存期为10秒，而他们应该支持的最长生存期至少为120秒。这些值定义了基于注册系统的服务规范基线。它们被选择为既不太短也不太长，并适应在中间盒（如NAT和防火墙）中建立的现有状态超时
A zero lifetime is reserved for canceling purposes. Requesting a zero lifetime for a registration type is equal to canceling the registration of that type. A requester MAY cancel a registration before it expires by sending a REG_REQ to the registrar with a zero lifetime. A registrar SHOULD respond and grant a registration with a zero lifetime. A registrar (and an attached service) MAY cancel a registration before it expires, at its own discretion. However, if it does so, it SHOULD send a REG_RESPONSE with a zero lifetime to all registered requesters.
保留零生存期用于取消目的。为注册类型请求零生存期等于取消该类型的注册。请求者可以在注册到期之前通过向注册者发送一个生命周期为零的REG_REQ来取消注册。注册员应响应并授予零生存期的注册。注册官（及随附服务）可自行决定在注册到期前取消注册。但是，如果它这样做，它应该向所有注册的请求者发送一个生存期为零的REG_响应。
This section discusses the threats on the HIP registration protocol and their 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注册协议面临的威胁及其对HIP整体安全性的影响。特别是，它认为本文件中描述的扩展不会给HIP带来额外的威胁。
The extensions described in this document rely on the HIP base exchange and do not modify its security characteristics, e.g., digital signatures or Hashed Message Authentication Code (HMAC). Hence, the only threat introduced by these extensions is related to the creation of soft registration state at the registrar.
本文档中描述的扩展依赖于HIP-base exchange，不修改其安全特性，例如数字签名或哈希消息认证码（HMAC）。因此，这些扩展带来的唯一威胁与在注册处创建软注册状态有关。
Registrars act on a voluntary basis and are willing to accept being a Responder and then to create HIP associations with a number of potentially unknown hosts. Because they have to store HIP association state anyway, adding a certain amount of time-limited HIP registration states should not introduce any serious additional threats, especially because HIP registrars may cancel registrations at any time at their own discretion, e.g., because of resource constraints during an attack.
登记员在自愿的基础上行动，并愿意接受作为响应者，然后与一些可能未知的宿主建立髋关节协会。由于他们无论如何都必须存储髋部关联状态，因此添加一定数量的有时间限制的髋部注册状态不应带来任何严重的额外威胁，特别是因为髋部注册者可能随时自行决定取消注册，例如，由于攻击期间的资源限制。
This section is to be interpreted according to "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC5226].
本节将根据“在RFCs中编写IANA注意事项部分的指南”[RFC5226]进行解释。
[RFC5203], obsoleted by this document, made the following definitions and reservations in the "Parameter Types" subregistry under "Host Identity Protocol (HIP) Parameters":
[RFC5203]已被本文件废除，在“主机标识协议（HIP）参数”下的“参数类型”子区域中做出以下定义和保留：
Value Parameter Type Length
----- -------------- --------
930 REG_INFO variable
932 REG_REQUEST variable
934 REG_RESPONSE variable
936 REG_FAILED variable
Value Parameter Type Length
----- -------------- --------
930 REG_INFO variable
932 REG_REQUEST variable
934 REG_RESPONSE variable
936 REG_FAILED variable
In the "Parameter Types" subregistry under "Host Identity Protocol (HIP) Parameters", the references to the obsoleted [RFC5203] have been replaced with references to this document.
在“主机标识协议（HIP）参数”下的“参数类型”子区域中，对废弃[RFC5203]的引用已替换为对本文件的引用。
[RFC5203], obsoleted by this document, requested the opening of the "Registration Types" subregistry under "Host Identity Protocol (HIP) Parameters", defined no registration types, but made the following reservations in that subregistry:
[RFC5203]已被本文件废除，请求在“主机身份协议（HIP）参数”下打开“注册类型”子区，未定义任何注册类型，但在该子区作出以下保留：
Reg Type Service
-------- --------------------------------
201-255 Reserved by IANA for private use
Reg Type Service
-------- --------------------------------
201-255 Reserved by IANA for private use
Adding a new type requires new IETF specifications.
添加新类型需要新的IETF规范。
In the "Registration Types" subregistry under "Host Identity Protocol (HIP) Parameters", references to the obsoleted [RFC5203] have been replaced with references to this document.
在“主机标识协议（HIP）参数”下的“注册类型”子区域中，对废弃[RFC5203]的引用已替换为对本文件的引用。
[RFC5203], obsoleted by this document, requested the opening of the "Registration Failure Types" subregistry under "Host Identity Protocol (HIP) Parameters" and made the following definitions and reservations in that subregistry:
[RFC5203]已被本文件废除，请求在“主机标识协议（HIP）参数”下打开“注册失败类型”子区域，并在该子区域中做出以下定义和保留：
Failure Type Reason
------------ --------------------------------------------
0 Registration requires additional credentials
1 Registration type unavailable
201-255 Reserved by IANA for private use
Failure Type Reason
------------ --------------------------------------------
0 Registration requires additional credentials
1 Registration type unavailable
201-255 Reserved by IANA for private use
Adding a new type requires new IETF specifications.
添加新类型需要新的IETF规范。
In the "Registration Failure Types" subregistry under "Host Identity Protocol (HIP) Parameters", references to the obsoleted [RFC5203] have been replaced with references to this document, and the following HIP Registration Failure Types have been added:
在“主机标识协议（HIP）参数”下的“注册失败类型”子区域中，已将对废弃[RFC5203]的引用替换为对本文件的引用，并添加了以下HIP注册失败类型：
Value Registration Failure Type
------------ --------------------------------------------
2 Insufficient resources
3 Invalid certificate
4 Bad certificate
5 Unsupported certificate
6 Certificate expired
7 Certificate other
8 Unknown CA
201-255 Reserved for Private Use
Value Registration Failure Type
------------ --------------------------------------------
2 Insufficient resources
3 Invalid certificate
4 Bad certificate
5 Unsupported certificate
6 Certificate expired
7 Certificate other
8 Unknown CA
201-255 Reserved for Private Use
[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>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[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>.
[RFC8002] Heer, T. and S. Varjonen, "Host Identity Protocol Certificates", RFC 8002, DOI 10.17487/RFC8002, October 2016, <http://www.rfc-editor.org/info/rfc8002>.
[RFC8002]Heer，T.和S.Varjonen，“主机身份协议证书”，RFC 8002，DOI 10.17487/RFC8002，2016年10月<http://www.rfc-editor.org/info/rfc8002>.
[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>.
[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-NAT] Keranen, A., Melen, J., and M. Komu, "Native NAT Traversal Mode for the Host Identity Protocol", Work in Progress, draft-ietf-hip-native-nat-traversal-13, July 2016.
[HIP-NAT]Keranen，A.，Melen，J.，和M.Komu，“主机标识协议的本机NAT遍历模式”，正在进行的工作，草稿-ietf-HIP-Native-NAT-Traversal-132016年7月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, <http://www.rfc-editor.org/info/rfc3234>.
[RFC3234]Carpenter，B.和S.Brim，“中间盒：分类和问题”，RFC 3234，DOI 10.17487/RFC3234，2002年2月<http://www.rfc-editor.org/info/rfc3234>.
[RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity Protocol (HIP) Registration Extension", RFC 5203, DOI 10.17487/RFC5203, April 2008, <http://www.rfc-editor.org/info/rfc5203>.
[RFC5203]Laganier，J.，Koponen，T.，和L.Eggert，“主机身份协议（HIP）注册扩展”，RFC 5203，DOI 10.17487/RFC5203，2008年4月<http://www.rfc-editor.org/info/rfc5203>.
o Updated references to revised HIP specifications.
o 修订后的髋关节规范的更新参考。
o Added a new registration Failure Type for use in case of insufficient resources available at the HIP registrar.
o 添加了一个新的注册失败类型，以便在HIP注册中心可用资源不足时使用。
o Added requester authorization based on certificates and new registration Failure Types for invalid certificates.
o 添加了基于证书的请求者授权和无效证书的新注册失败类型。
Acknowledgments
致谢
The following people (in alphabetical order) have provided thoughtful and helpful discussions and/or suggestions that have helped to improve this document: Jeffrey Ahrenholz, Miriam Esteban, Ari Keranen, Mika Kousa, Pekka Nikander, and Hannes Tschofenig.
以下人员（按字母顺序）提供了有助于改进本文件的深思熟虑和有益的讨论和/或建议：Jeffrey Ahrenholz、Miriam Esteban、Ari Keranen、Mika Kousa、Pekka Nikander和Hannes Tschofenig。
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。本文件仅反映了作者的观点，欧盟委员会不对其所含信息的任何使用负责。
Ari Keranen suggested inclusion of the text specifying requester authorization based on certificates as a direct adaption of text found in the HIP native NAT traversal specification [HIP-NAT].
Ari Keranen建议将指定基于证书的请求者授权的文本作为HIP原生NAT遍历规范[HIP-NAT]中文本的直接改编。
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审查。
Contributors
贡献者
Teemu Koponen coauthored an earlier, experimental version of this specification [RFC5203].
蒂姆·科波宁（Teemu Koponen）与他人共同编写了本规范的早期实验版本[RFC5203]。
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