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
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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
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ランデブーサーバやミドルボックスなどのサービス、に登録することを可能にするホスト識別プロトコル（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].
この文書では、ホスト識別プロトコル（HIP）[RFC5201]に拡張子を指定します。拡張機能は、ホストがサービスに登録するための汎用的な手段を提供します。サービスは、例えば、HIPランデブーサーバ[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:
HIPアーキテクチャ[RFC4423]、HIP仕様[RFC5201]、およびHIPランデブー拡張[RFC5204]で定義された用語に加えて、この文書を定義し、以下の用語を使用します。
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 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].
この文書では、要求者は、サービスの可用性を発見、あるいは要求者がレジストラを検索する方法する手段を指定しません。依頼者は、レジストラを発見した後、いずれかのHIP基本交換を開始またはレジストラで既存のHIPの関連付けを使用しています。両方の場合において、レジストラは、本文書の残りの部分がその品質とグラントを発表するか、登録を拒否するために、定義の追加パラメータを使用します。リクエスタはサービスに登録して、対応するパラメータを使用します。メッセージが関与登録タイプに固有の追加のHIPパラメータを交換して登録し、依頼者の両方も含むかもしれません。他の文書はパラメータを定義し、それらがどのように使用されなければなりません。以下のセクションでは、この登録ハンドシェーク標準HIP基本交換[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パラメータで利用可能なサービスの現在のセットを示すUPDATEパケットを送信すべきです。
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またはUPDATEパケット内の対応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.
依頼者は、レジストラに確立されたHIPの関連性を持っていない場合、それはすなわち、I2パケットで、最も初期の可能性でREG_REQUESTを送るべきです。これは、レジストラと交換する必要のあるパケットの数を最小限に抑えることができます。レジストラはR2にREG_REQUIREDタイプとNOTIFYなどによってREG_REQUESTを運ばないHIPの関連付けを終了してもよいです。この場合、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. 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_FAILEDパラメータは、それが登録または登録を承認しなかったため、サービスタイプ（複数可）を含有するその応答でREG_RESPONSEパラメータを含みます他の理由のために失敗しました。この応答は、登録が既存のアソシエーションを使用して、塩基交換の際に要求された、またはされたかどうかに応じて、それぞれ、R2又はUPDATEメッセージのいずれかであり得ます。特に、ゼロの故障タイプとREG_FAILEDは、登録のためにさらに資格を必要とするサービス（S）タイプ（複数可）を示しています。
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.
レジストラは、さらに、許可を必要とし、要求者が利用可能な追加の資格情報を持っている場合、依頼者は、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) | +-----+
| 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）は、それが現在のHIPアソシエーションを有していないれるサービス（S1）及び（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）は、現在HIPアソシエーションが確立しているサービスの登録（R）（S）に登録します。
This section describes the format and processing of the new parameters introduced by the HIP registration extension.
このセクションでは、HIP登録伸長により導入された新しいパラメータのフォーマットおよび処理について説明します。
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.
HIP登録は、登録寿命の指数エンコーディングを使用しています。これは、8ビット整数フィールドに4ミリ秒から178日までの範囲の255個の異なるライフタイム値のコンパクトな符号化を可能にします。秒 - この文書全体を通して使用寿命指数フィールドは、ライフタイム値2 ^（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パケット内のパラメータが含まれています。そのサービスの提供が変更されたときレジストラはUPDATEパケットのパラメータを含むべきです。 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またはUPDATEパケット内REG_REQUESTパラメータを含みます。 REG_REQUESTパラメータはUPDATEパケットである場合、レジストラは、パラメータに記載されていない登録タイプの登録を変更してはいけません。レジストラのR1パケットまたは最新の受信UPDATEパケットが要求され、登録の種類と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またはUPDATEパケット内の1つまたは複数のREG_REQUESTパラメータを処理することができなければならないが、要求者は、そのI2またはUPDATEパケットで複数の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と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 includes an REG_RESPONSE parameter in its R2 or UPDATE packet only if a registration has successfully completed.
レジストラSHOULDは登録が正常に完了した場合にのみ、そのR2またはUPDATEパケット内の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または更新パケット内の1つまたは複数のREG_RESPONSEパラメータを処理できなければならないがレジストラは、そのR2または更新パケットで複数の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.
リクエスタはREG_INFOパラメータで示される最小値と最大寿命を超えたものを含む、任意の登録寿命を受信するように準備しなければなりません。これは、返された寿命が要求された寿命が発表された最小値と最大値に収まる場合でも、要求されたものになることを予想してはいけません。
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が指定された理由で失敗した登録タイプを入力します。
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）以外の障害の種類（1）定義されていません。
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.
記載された登録タイプの登録が正常に完了していないと、依頼者が追加の資格情報を使用して再び試してみるようにお願いした場合、レジストラは、そのR2またはUPDATEパケットにREG_FAILEDパラメータを含むべきです。
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.)
彼らは、少なくとも、120秒の最大寿命をサポートするべきであるが、両方のレジストラとリクエスタがサポートしなければならない最小の寿命は、10秒です。これらの値は、登録制度に基づくサービスの仕様のベースラインを定義します。これらはどちらも短すぎても長すぎること、そしてミドルボックスに設立された状態の既存のタイムアウトのために対応するために選ばれた（例えば、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.
このセクションでは、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 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 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.
レジストラは、自主的に行動し、応答者であること受け入れて、その後、以前に未知のホストの数とHIPの関連付けを作成するために喜んでいます。彼らはHIPレジストラリソース制約が理由で、例えば、自らの裁量でいつでも登録を取り消すことがあり、特にので、期間限定のHIP登録状態の一定量が重大な追加の脅威を導入してはならない追加、とにかくHIPの会合状態を保存する必要があるため攻撃中。
This section is to be interpreted according to the Guidelines for Writing an IANA Considerations Section in RFCs [RFC2434].
このセクションでは、RFCに[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:
この文書は、本文書に定義された新しいHIPパラメータのための新しいHIPパラメータタイプ値を割り当てることによって、HIPパラメータタイプのIANAレジストリを更新します。
o REG_INFO (defined in Section 4.2)
REG_INFO O（セクション4.2で定義されます）
o REG_REQUEST (defined in Section 4.3)
REG_REQUEST O（4.3節で定義されています）
o REG_RESPONSE (defined in Section 4.4)
（セクション4.4で定義された）O REG_RESPONSE
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は、通知メッセージタイプレジストリ内REG_REQUIRED通知エラー・タイプの通知メッセージタイプコード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.
ジェフリーAhrenholz、ミリアム・エステバン、ミカKousa、ペッカNikander、およびハンネスTschofenig：（アルファベット順）次の人は、この文書を改善するために役立っている思慮深く、有用な議論、および/または提案を提供しています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]モスコウィッツ、R.、Nikander、P.、Jokela、P.、エド。、およびT.ヘンダーソン、 "ホストアイデンティティプロトコル"、RFC 5201、2008年4月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC3234]大工、B.とS.つば、 "のMiddleboxes：分類と課題"、RFC 3234、2002年2月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4423]モスコウィッツ、R.とP. Nikander、 "ホストアイデンティティプロトコル（HIP）アーキテクチャ"、RFC 4423、2006年5月。
[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", RFC 5204, April 2008.
[RFC5204] Laganier、J.とL.エッゲルト、 "ホストアイデンティティプロトコル（HIP）ランデブー拡張"、RFC 5204、2008年4月。
Authors' Addresses
著者のアドレス
Julien Laganier DoCoMo Communications Laboratories Europe GmbH Landsberger Strasse 312 Munich 80687 Germany
ジュリアンLAGANIERドコモコミュニケーション研究所ヨーロッパ社ランデスシュトラーセ312 80687ミュンヘンドイツ
Phone: +49 89 56824 231 EMail: julien.ietf@laposte.net URI: http://www.docomolab-euro.com/
電話：+49 89 56824 231 Eメール：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
情報技術高等研究ユニットのテームKoponenヘルシンキ研究所（ARU）P。ボックス9800 FIN-02015ヘルシンキ、フィンランドHUT
Phone: +358 9 45 1 EMail: teemu.koponen@iki.fi URI: http://www.hiit.fi/
電話：+358 9 45 1 Eメール：teemu.koponen@iki.fi URI：http://www.hiit.fi/
Lars Eggert Nokia Research Center P.O. Box 407 Nokia Group 00045 Finland
ラースEggertのノキア・リサーチセンター私書箱ボックス407ノキアグループ00045フィンランド
Phone: +358 50 48 24461 EMail: lars.eggert@nokia.com URI: http://research.nokia.com/people/lars_eggert/
電話番号：+358 50 48 24461電子メール：lars.eggert@nokia.com URI：http://research.nokia.com/people/lars_eggert/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。