[要約] 要約：RFC 5203は、Host Identity Protocol（HIP）の登録拡張機能に関する仕様です。HIPは、ネットワーク上のホストの識別とセキュリティを向上させるためのプロトコルです。目的：この拡張機能は、HIPホストの登録と管理を容易にすることを目的としています。これにより、ネットワーク上のホストの識別とセキュリティの管理が効率的に行われます。
Network Working Group J. Laganier
Request for Comments: 5203 DoCoMo Euro-Labs
Category: Experimental T. Koponen
HIIT
L. Eggert
Nokia
April 2008
Host Identity Protocol (HIP) Registration Extension
ホストIDプロトコル（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 specifies a registration mechanism for the Host Identity Protocol (HIP) that allows hosts to register with services, such as HIP rendezvous servers or middleboxes.
このドキュメントは、ホストがHIPランデブーサーバーやミドルボックスなどのサービスに登録できるようにするホストIDプロトコル（HIP）の登録メカニズムを指定します。
This document specifies an extension to the Host Identity Protocol (HIP) [RFC5201]. The extension provides a generic means for a host to register with a service. The service may, for example, be a HIP rendezvous server [RFC5204] or a middlebox [RFC3234].
このドキュメントは、ホストIDプロトコル（HIP）[RFC5201]の拡張機能を指定します。拡張機能は、ホストがサービスに登録するための一般的な手段を提供します。たとえば、このサービスは、股関節ランデブーサーバー[RFC5204]またはミドルボックス[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 [RFC4423], the HIP specification [RFC5201], and the HIP Rendezvous Extension [RFC5204], this document defines and uses the following terms:
股関節アーキテクチャ[RFC4423]で定義されている用語に加えて、股関節仕様[RFC5201]、および股関節ランデブーエクステンション[RFC5204]、このドキュメントは、次の用語を定義および使用します。
Requester: a HIP node registering with a HIP registrar to request registration for a service.
リクエスター：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.
サービス：リクエスターに、股関節層で動作する新しい機能または機能を提供する施設。例には、股関節トラバーサルまたは股関節ランデブーサーバーをサポートするファイアウォールが含まれます。
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つ以上の股関節サービスの恩恵を受けることができます。各登録には、関連する有限寿命があります。要求者は、再登録を通じて確立された登録を拡張できます（つまり、更新を実行します）。
Registration Type: an identifier for a given service in the registration protocol. For example, the rendezvous service is identified by a specific registration type.
登録タイプ：登録プロトコルの特定のサービスの識別子。たとえば、ランデブーサービスは、特定の登録タイプによって識別されます。
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 implicated. Other documents will define parameters and how they shall be used. The following sections describe the differences between this registration handshake and the standard HIP base exchange [RFC5201].
このドキュメントでは、リクエスターがサービスの可用性を発見する手段や、リクエスターがレジストラを見つける方法を指定しません。リクエスターがレジストラを発見した後、ヒップベース交換を開始するか、レジストラとの既存の股関節関連を使用します。どちらの場合も、レジストラは追加のパラメーターを使用します。このドキュメントの残りの部分で定義されているため、品質を発表し、登録を付与または拒否します。リクエスターは、対応するパラメーターを使用してサービスに登録します。レジストラとリクエスターの両方が、登録タイプに固有の追加の股関節パラメーターを交換したメッセージに含めることもできます。他のドキュメントは、パラメーターとそれらの使用方法を定義します。次のセクションでは、この登録の握手と標準の股関節ベース交換[RFC5201]の違いについて説明します。
A host that is capable and willing to act as a registrar SHOULD include a REG_INFO parameter in the R1 packets it sends during all base exchanges. 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、つまりサービスがリストされていないものを含める必要があります。後でサービスを提供できる場合は、新しい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_requestパラメーターを含むか、レジストラに送信する更新パケットを含みます。
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.
要求者がレジストラとの股関節の関連性がない場合、reg_requestを最も早い可能性、つまりi2パケットで送信する必要があります。これにより、レジストラと交換する必要があるパケットの数が最小限に抑えられます。レジストラは、R2に型reg_requiredに通知を含めることにより、reg_requestを運ぶことのない股関節関連を終了する場合があります。この場合、ホスト間に股関節関連は作成されません。reg_required通知エラータイプは51です。
Once registration has been requested, the registrar is able to authenticate the requester based on the host identity included in I2. It then verifies that the host identity is authorized to register with the requested service(s), based on local policies. The details of this authorization procedure depend on the type of requested service(s) and on the local policies of the registrar, and are therefore not further specified in this document.
登録が要求されると、レジストラはi2に含まれるホストIDに基づいてリクエスターを認証できます。次に、ローカルポリシーに基づいて、ホストIDが要求されたサービスに登録する権限があることを確認します。この承認手順の詳細は、要求されたサービスのタイプとレジストラのローカルポリシーに依存するため、このドキュメントではこれ以上指定されていません。
After 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(s) type(s) that require further credentials for registration.
承認後、レジストラはその応答にreg_responseパラメーターを含みます。これには、登録を承認したサービスタイプ、および登録または登録を承認していないサービスタイプを含むゼロ以上のreg_failedパラメーターが含まれています他の理由で失敗しました。この応答は、登録が基本交換中に要求されたか、既存の関連付けを使用したかどうかに応じて、それぞれR2または更新メッセージのいずれかです。特に、ゼロの故障タイプで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. The precise means of establishing and verifying credentials are beyond the scope of this document and are expected to be defined in other documents.
レジストラがさらなる承認を必要とし、リクエスターに追加の資格情報が利用可能な場合、リクエスターは、股関節協会が確立された後、サービスに再度登録しようとする必要があります。資格情報を確立および検証する正確な手段は、このドキュメントの範囲を超えており、他のドキュメントで定義されると予想されます。
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) | +-----+
| RQ | | R | S2 |
| | I2(REG_REQ:S1) | | |
| |--------------------->| +-----+
| |<---------------------| | S3 |
| | R2(REG_RESP:S1) | | |
+-----+ +-----+-----+
A requester (RQ) registers with a registrar (R) of services (S1) and (S2), with which it has no current HIP association.
リクエスター（RQ）は、サービス（S1）および（S2）のレジストラ（R）と（S2）のレジストラ（R）を登録しますが、現在の股関節関連はありません。
+-----+ +-----+-----+
| | UPDATE(REG_INFO:S) | | |
| |<---------------------| | |
| RQ |--------------------->| R | S |
| | UPDATE(REG_REQ:S) | | |
| | UPDATE(REG_RESP:S) | | |
| |<---------------------| | |
+-----+ +-----+-----+
A requester (RQ) registers with a registrar (R) of services (S), with which it currently has a HIP association established.
リクエスター（RQ）がサービスのレジストラ（R）を登録し、現在股関節関連が確立されています。
This section describes the format and processing of the new parameters introduced by the HIP registration extension.
このセクションでは、股関節登録拡張機能によって導入された新しいパラメーターの形式と処理について説明します。
The HIP registration uses an exponential encoding of registration lifetimes. This allows compact encoding of 255 different lifetime values ranging from 4 ms to 178 days into an 8-bit integer field. The lifetime exponent field used throughout this document MUST be interpreted as representing the lifetime value 2^((lifetime - 64)/8) seconds.
股関節登録は、登録寿命の指数エンコードを使用します。これにより、4ミリ秒から178日間の8ビット整数フィールドまでの範囲の255の異なる寿命値のコンパクトエンコードが可能になります。このドキュメント全体で使用される生涯指数フィールドは、生涯値2^（（lifetime -64）/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タイプレジストラが提供する登録タイプ。
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_signature_2 R1パケット内のパラメーターを保護します。
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タイプ優先順序で優先登録タイプを入力します。
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_requestパラメーターを含むか、レジストラのサービスに登録するパケットを更新します。reg_requestパラメーターが更新パケットにある場合、レジストラはパラメーターにリストされていない登録タイプの登録を変更してはなりません。さらに、レジストラの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_requestパラメーターを含めることはできませんが、レジストラは受信したi2または更新パケットで1つ以上のreg_requestパラメーターを処理できる必要があります。
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内のパラメーターを保護し、パケットを更新します。
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タイプは、優先順位で付与された登録タイプを入力します。
Other documents will define specific values for registration types. See Section 7 for more information.
他のドキュメントでは、登録タイプの特定の値を定義します。詳細については、セクション7を参照してください。
The registrar SHOULD includes an REG_RESPONSE parameter in its R2 or UPDATE packet only if a registration has successfully completed.
レジストラには、登録が正常に完了した場合にのみ、R2または更新パケットにREG_RESPONSEパラメーターを含める必要があります。
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_responseパラメーターを含めるべきではありませんが、リクエスタは受信したR2または更新パケットで1つ以上のreg_responseパラメーターを処理できる必要があります。
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.
requesterは、REG_INFOパラメーターに示されている最小および最大寿命を超えるものを含む、登録寿命を受け取る準備をする必要があります。要求された寿命が発表された最低と最大値内にある場合でも、返された生涯が要求されたものになることを期待してはなりません。
HIP_SIGNATURE protects the parameter within the R2 and UPDATE packets.
hip_signatureは、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 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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タイプ指定された理由で失敗した登録タイプ。
Failure Type Reason
------------ --------------------------------------------
0 Registration requires additional credentials
1 Registration type unavailable
2-200 Unassigned
201-255 Reserved by IANA for private use
Other documents will define specific values for registration types. See Section 7 for more information.
他のドキュメントでは、登録タイプの特定の値を定義します。詳細については、セクション7を参照してください。
A failure type of zero means a registrar requires additional credentials to authorize a requester to register with the registration types listed in the parameter. A failure type of one means that the requested service type is unavailable at the registrar. Failure types other than zero (0) and one (1) have not been defined.
ゼロの障害タイプは、レジストラがパラメーターにリストされている登録タイプに登録することを要求者に承認するために追加の資格情報を必要とすることを意味します。1つの障害タイプは、要求されたサービスタイプがレジストラで利用できないことを意味します。ゼロ（0）以外の障害タイプは定義されていません。
The registrar SHOULD include the 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.
レジストラには、リストされた登録タイプに登録されている登録が正常に完了しておらず、リクエスターが追加の資格情報で再試行するように求められた場合、REG_FAILEDパラメーターをR2または更新パケットに含める必要があります。
HIP_SIGNATURE protects the parameter within the R2 and UPDATE packets.
hip_signatureは、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.
登録を確立および/または維持するには、送信されたreg_requestまたはreg_responseパラメーターで利用できない追加情報が必要になる場合があります。したがって、登録タイプの定義は、このドキュメントで定義されていない股関節パラメーターの依存関係を定義する場合があります。それらのセマンティクスは、特定の登録タイプの仕様の対象となります。
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_responseを送信する必要があります。
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.
このセクションでは、股関節登録プロトコルの脅威と、股関節の全体的なセキュリティに対するそれらの影響について説明します。特に、このドキュメントで説明されている拡張機能は、股関節に追加の脅威をもたらさないと主張しています。
The extensions described in this document rely on the HIP base exchange and do not modify its security characteristics, e.g., digital signatures or HMAC. Hence, the only threat introduced by these extensions is related to the creation of soft registration state at the registrar.
このドキュメントで説明されている拡張機能は、股関節ベース交換に依存しており、デジタル署名や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 previously unknown hosts. Because they have to store HIP association state anyway, adding a certain amount of time-limited HIP registration state 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 the Guidelines for Writing an IANA Considerations Section in RFCs [RFC2434].
このセクションは、RFCS [RFC2434]にIANA考慮事項セクションを作成するためのガイドラインに従って解釈されます。
This document updates the IANA Registry for HIP Parameter Types by assigning new HIP Parameter Types values for the new HIP Parameters defined in this document:
このドキュメントは、このドキュメントで定義されている新しい股関節パラメーターの新しい股関節パラメータータイプの値を割り当てることにより、股関節パラメータータイプのIANAレジストリを更新します。
o REG_INFO (defined in Section 4.2)
o reg_info（セクション4.2で定義）
o REG_REQUEST (defined in Section 4.3)
o reg_request（セクション4.3で定義）
o REG_RESPONSE (defined in Section 4.4)
o reg_response（セクション4.4で定義）
o REG_FAILED (defined in Section 4.5)
o reg_failed（セクション4.5で定義）
IANA has allocated the Notify Message Type code 51 for the REG_REQUIRED notification error type in the Notify Message Type registry.
IANAは、notifyメッセージタイプレジストリのreg_required通知エラータイプにnotifyメッセージタイプコード51を割り当てました。
IANA has opened a new registry for registration types. This document does not define registration types but makes the following reservations:
IANAは、登録タイプの新しいレジストリを開設しました。このドキュメントでは、登録タイプを定義しませんが、次の予約を作成します。
Reg Type Service
-------- -------
0-200 Unassigned
201-255 Reserved by IANA for private use
Adding a new type requires new IETF specifications.
新しいタイプを追加するには、新しいIETF仕様が必要です。
IANA has opened a new registry for registration failure types. This document makes the following failure type definitions and reservations:
IANAは、登録障害タイプの新しいレジストリを開設しました。このドキュメントは、次の障害タイプの定義と予約を作成します。
Failure Type Reason
------------ --------------------------------------------
0 Registration requires additional credentials
1 Registration type unavailable
2-200 Unassigned
201-255 Reserved by IANA for private use
Adding a new type requires new IETF specifications.
新しいタイプを追加するには、新しいIETF仕様が必要です。
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, Mika Kousa, Pekka Nikander, and Hannes Tschofenig.
次の人々（アルファベット順）は、この文書の改善に役立った思慮深く有益な議論や提案を提供しています：ジェフリー・アフレンホルツ、ミリアム・エステバン、ミカ・クーサ、ペッカ・ニカンダー、ハンネス・ツェフェニグ。
[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月。
[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、「Host Identity Protocol」、RFC 5201、2008年4月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC3234]大工、B。およびS.ブリム、「ミドルボックス：分類法と問題」、RFC 3234、2002年2月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4423] Moskowitz、R。およびP. Nikander、「Host Identity Protocol（HIP）Architecture」、RFC 4423、2006年5月。
[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", RFC 5204, April 2008.
[RFC5204] Laganier、J。およびL. Eggert、「ホストIDプロトコル（HIP）Rendezvous Extension」、RFC 5204、2008年4月。
Authors' Addresses
著者のアドレス
Julien Laganier DoCoMo Communications Laboratories Europe GmbH Landsberger Strasse 312 Munich 80687 Germany
Julien Laganier Docomo Communications Laboratories Europe GmbH Landsberger Strasse 312 Munich 80687ドイツ
Phone: +49 89 56824 231
EMail: julien.ietf@laposte.net
URI: http://www.docomolab-euro.com/
Teemu Koponen Helsinki Institute for Information Technology Advanced Research Unit (ARU) P.O. Box 9800 Helsinki FIN-02015-HUT Finland
Teemu Koponen Helsinki Institute for Information Technology Advanced Research Unit（ARU）P.O。Box 9800 Helsinki Fin-02015-HUTフィンランド
Phone: +358 9 45 1
EMail: teemu.koponen@iki.fi
URI: http://www.hiit.fi/
Lars Eggert Nokia Research Center P.O. Box 407 Nokia Group 00045 Finland
Lars Eggert Nokia Research Center P.O.Box 407 Nokia Group 00045フィンランド
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）The IETF Trust（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。