[要約] RFC 8003は、Host Identity Protocol (HIP)の登録拡張機能に関する規格です。その目的は、HIPベースのネットワークでのホストの登録と管理を容易にすることです。
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.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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]の拡張について説明します。拡張機能は、ホストがサービスに登録するための一般的な手段を提供します。サービスは、たとえば、HIPランデブーサーバー[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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 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アーキテクチャ[HIP-ARCH]、HIP仕様[RFC7401]、およびHIP Rendezvous Extension [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.
レジストラ：1つ以上のサービスの登録を提供するHIPノード。
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レイヤーで動作する新しい機能を提供する機能。例には、HIPトラバーサルまたは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).
登録：リクエスタとレジストラが保存した状態を共有し、リクエスタがレジストラが提供する1つ以上の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ベース交換を開始するか、レジストラとの既存のHIPアソシエーションを使用します。どちらの場合も、レジストラは、このドキュメントの残りの部分で定義されている追加のパラメータを使用して、品質を通知し、登録を許可または拒否します。リクエスターは、対応するパラメーターを使用してサービスに登録します。レジストラとリクエスタはどちらも、要求された登録タイプに固有の追加のHIPパラメータが交換されるメッセージに含めることができます（MAY）。他のドキュメントでは、パラメータとその使用方法を定義します。
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 I1、R1、I2、およびR2パケットの定義を含むHIPベース交換は、[RFC7401]で定義されています。次のセクションでは、この登録ハンドシェイクと標準のHIPベース交換[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パラメーターを含める必要があります（SHOULD）。一時的な状態が原因で現在サービスを提供できない場合は、空のREG_INFO、つまりサービスがリストされていないものを含める必要があります（SHOULD）。後でサービスを提供できる場合、サービスが関連付けられているすべてのホストに、新しいREG_INFOパラメータで利用可能なサービスの現在のセットを示すUPDATEパケットを送信する必要があります（SHOULD）。
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.
サービスへの登録を要求するために、リクエスターは対応するREG_REQUESTパラメーターを作成し、レジストラーに送信するI2またはUPDATEパケットに含めます。
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アソシエーションを確立していない場合は、できるだけ早く、つまりI2パケットでREG_REQUESTを送信する必要があります。これにより、レジストラと交換する必要のあるパケットの数が最小限になります。レジストラは、R2にタイプREG_REQUIREDのNOTIFYを含めることにより、REG_REQUESTを伝送しないHIPアソシエーションを終了してもよい（MAY）。この場合、ホスト間にHIPアソシエーションは作成されません。 REG_REQUIRED通知エラータイプは51です。
Once registration has been requested, the registrar is able to authenticate the requester based on the host identity included in I2.
登録が要求されると、レジストラはI2に含まれるホストIDに基づいて要求者を認証できます。
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.
レジストラは、サービスへの登録が許可されているすべてのホストのホストID（HI）を知っている場合、不明なホストからの登録を拒否する必要があります（SHOULD）。ただし、すべてのHIを使用してレジストラを事前構成することは不可能であるため、レジストラは、証明書ベースの認証を可能にするHIP証明書[RFC8002]もサポートする必要があります（SHOULD）。
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.
リクエスタがレジストラに登録する場合は、レジストラでの認証に適した証明書があるかどうかを確認する必要があります（SHOULD）。どのように適合性が決定され、どのように証明書が取得されるかは、このドキュメントの範囲外です。リクエスターが1つ以上の適切な証明書を持っている場合、ホストはそれらを（または最も適切なものを）CERTパラメーターにREG_REQUESTパラメーターと共にHIPパケットに含めるべきです（SHOULD）。リクエスターが適切な証明書を持っていない場合は、CERTパラメーターなしで登録要求を送信して、レジストラーがホストのIDに基づいて要求を受け入れるかどうかをテストする必要があります（SHOULD）。
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_REQUESTパラメータを含むHIPパケットを受信し、それがREG_REQUESTパラメータにリストされている登録タイプの少なくとも1つの認証を必要とする場合、最初に要求者のHIがすべての登録タイプの許可リストにあるかどうかを確認する必要がありますREG_REQUESTパラメータで。要求者が許可リストに含まれている場合（またはレジストラが認証を必要としない場合）、レジストラは登録を続行する必要があります。
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 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_RESPONSEパラメータを含めます。これには、登録を承認したサービスの種類と、登録を承認していないサービスの種類を含む0個以上のREG_FAILEDパラメータが含まれます。他の理由で登録が失敗しました。この応答は、ベース交換中に登録が要求されたか、既存の関連付けを使用して要求されたかに応じて、それぞれR2またはUPDATEメッセージのいずれかになります。特に、失敗タイプがゼロの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_RESPONSEパラメータの処理が成功すると、リクエスタで登録状態が作成されます。同様の方法で、REG_REQUESTパラメータの処理が成功すると、レジストラ、および場合によってはサービスで登録状態が作成されます。登録によって提供されたサービスがリクエスタで必要でなくなった場合、またはレジストラが提供できなくなった場合（たとえば、構成が変更されたため）、リクエスタとレジストラの両方が期限切れになる前に登録をキャンセルできます。
+-----+ 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）は、現在のHIPアソシエーションを持たないサービス（S1）、（S2）、および（S3）のレジストラー（R）にサービス（S1）を登録します。
+-----+ +-----+-----+
| | 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アソシエーションが確立されているサービス（S）のレジストラー（R）にサービス（S）を登録します。
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].
このセクションでは、HIP Registration Extensionによって導入された新しいパラメーターの形式と処理について説明します。これらの新しいパラメータのエンコーディングは、RFC7401 [RFC7401]のセクション5.2.1で説明されているHIPv2 TLV形式に準拠しています。
The HIP registration uses an exponential encoding of registration lifetimes.
HIP登録では、登録ライフタイムの指数エンコーディングを使用します。
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 ^（（lifetime-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.
これにより、2 ^（63/8）秒（つまり、〜4 ms）から2 ^（191/8）秒（つまり、0秒の特別な有効期間に加えて）の255の異なる有効期間をコンパクトにエンコードできます。 、〜178日）を8ビット整数フィールドに入力します。
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長さオクテット単位の長さ（タイプ、長さ、およびパディングを除く）。最小ライフタイム最小登録ライフタイム。最大ライフタイム登録の最大ライフタイム。 Reg Typeレジストラが提供する登録タイプ。
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パケットにパラメータを含めます。レジストラは、そのサービス提供が変更されたときに、UPDATEパケットにパラメータを含める必要があります（SHOULD）。 HIP_SIGNATURE_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.
レジストラは、リクエスタに提供する用意がある最小および最大の登録ライフタイムを示します。リクエスタは、最大登録存続期間よりも長い存続期間、または最小登録存続期間よりも短い存続期間で登録を要求してはなりません（SHOULD NOT）。
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長さオクテットの長さ（タイプ、長さ、およびパディングを除く）。ライフタイムリクエストされた登録ライフタイム。登録タイプ優先順位の高い優先登録タイプ。
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.
リクエスタは、レジストラのサービスに登録するために、REG_REQUESTパラメータをI2またはUPDATEパケットに含めます。 REG_REQUESTパラメータがUPDATEパケットにある場合、レジストラは、パラメータにリストされていない登録タイプの登録を変更してはなりません（MUST NOT）。さらに、レジストラのR1パケットまたは最後に受信したUPDATEパケットに、要求された登録タイプのREG_INFOパラメータが含まれていない限り、リクエスタはパラメータを含めてはなりません（MUST NOT）。
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またはUPDATEパケットに複数のREG_REQUESTパラメータを含めてはなりません（MUST NOT）。一方、レジストラは、受信したI2またはUPDATEパケットで1つ以上のREG_REQUESTパラメータを処理できなければなりません（MUST）。
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_SIGNATUREは、I2およびUPDATEパケット内のパラメーターを保護します。
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長さオクテット単位の長さ（タイプ、長さ、およびパディングを除く）。ライフタイム付与された登録のライフタイム。登録タイプ付与された登録タイプを優先順に並べます。
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またはUPDATEパケットにREG_RESPONSEパラメータを含める必要があります（SHOULD）。
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またはUPDATEパケットに複数のREG_RESPONSEパラメータを含めてはいけません（MUST NOT）。一方、リクエスタは受信したR2またはUPDATEパケットの1つ以上のREG_RESPONSEパラメータを処理できなければなりません（MUST）。
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パラメータで指定された最小および最大の有効期間を超えるものを含む、登録の有効期間を受信する準備をしなければなりません（MUST）。要求されたライフタイムが発表された最小値と最大値の範囲内であっても、返されたライフタイムが要求されたものであることを期待してはなりません。
HIP_SIGNATURE protects the parameter within the R2 and UPDATE packets.
HIP_SIGNATUREは、R2およびUPDATEパケット内のパラメーターを保護します。
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
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（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またはUPDATEパケットにREG_FAILEDパラメータを含める必要があります（SHOULD）。
HIP_SIGNATURE protects the parameter within the R2 and UPDATE packets.
HIP_SIGNATUREは、R2およびUPDATEパケット内のパラメーターを保護します。
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.
登録を確立および/または維持するには、送信されたREG_REQUESTまたはREG_RESPONSEパラメータで利用できない追加情報が必要になる場合があります。したがって、登録タイプ定義は、このドキュメントで定義されていない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秒の最大ライフタイムをサポートする必要があります（SHOULD）。これらの値は、登録システムに基づくサービスの仕様のベースラインを定義します。それらは、短すぎず長すぎず、ミドルボックス（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をレジストラに送信することにより、有効期限が切れる前に登録をキャンセルできます。レジストラは、応答して、ライフタイムがゼロの登録を許可する必要があります。レジストラ（および付随するサービス）は、独自の裁量で、有効期限が切れる前に登録をキャンセルできます（MAY）。ただし、そうする場合は、登録されているすべてのリクエスタに存続期間がゼロのREG_RESPONSEを送信する必要があります（SHOULD）。
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ベース交換に依存しており、デジタル署名やハッシュメッセージ認証コード（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.
レジストラは自発的に行動し、レスポンダーであることを受け入れてから、不明な可能性のある多数のホストとのHIPアソシエーションを作成します。いずれにしてもHIPアソシエーションの状態を保存する必要があるため、一定の時間制限のあるHIP登録状態を追加しても、特にリソースの制約などの理由でHIPレジストラが独自の裁量でいつでも登録をキャンセルできるため、深刻な脅威は発生しません。攻撃中。
This section is to be interpreted according to "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC5226].
このセクションは、「RFCの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]は、「Host Identity Protocol（HIP）Parameters」の「Parameter Types」サブレジストリで次の定義と予約を行いました。
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.
「Host Identity Protocol（HIP）Parameters」の「Parameter Types」サブレジストリで、廃止された[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]は、このドキュメントで廃止され、「ホストIDプロトコル（HIP）パラメータ」の下にある「登録タイプ」サブレジストリのオープンを要求し、登録タイプを定義していませんでしたが、そのサブレジストリで次の予約を行いました：
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.
「Host Identity Protocol（HIP）Parameters」の「Registration Types」サブレジストリで、廃止された[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:
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:
「Host Identity Protocol（HIP）Parameters」の「Registration Failure Types」サブレジストリで、廃止された[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
[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、「RFCで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。、編、Heer、T.、Jokela、P。、およびT. Henderson、「Host Identity Protocol Version 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、「Host Identity Protocol Certificates」、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、「Host Identity Protocol（HIP）Rendezvous Extension」、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、「Host Identity Protocol Architecture」、Work in Progress、draft-ietf-hip-rfc4423- bis-14、2016年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、「ホストIDプロトコルのネイティブNATトラバーサルモード」、作業中、draft-ietf-hip-native-nat-traversal-13、 2016年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]カーペンター、B。およびS.ブリム、「ミドルボックス：分類と問題」、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]ラガニア、J。、コポネン、T。、およびL.エガート、「Host Identity Protocol（HIP）Registration Extension」、RFC 5203、DOI 10.17487 / RFC5203、2008年4月、<http：//www.rfc-editor .org / info / rfc5203>。
o Updated references to revised HIP specifications.
o 改訂されたHIP仕様への参照を更新しました。
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.
次の人々（アルファベット順）は、このドキュメントの改善に役立つ思慮深く役立つディスカッションや提案を提供しました：ジェフリーアーレンホルツ、ミリアムエステバン、アリケラネン、ミカクーサ、ペッカニカンデル、およびハンネスショフェニッヒ。
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は、EUのHorizon 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.
出版プロセスの一環としてこのドキュメントのGen-ARTレビューを行ってくれたJoel M. Halpernに感謝します。
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
ジュリアンラガニアLuminate Wireless、Inc.クパチーノ、カリフォルニア州アメリカ合衆国
Email: julien.ietf@gmail.com
Lars Eggert NetApp Sonnenallee 1 Kirchheim 85551 Germany
Lars Eggert NetApp Sonnenallee 1キルヒハイム85551ドイツ
Phone: +49 151 12055791
Email: lars@netapp.com
URI: http://eggert.org