RFC5203 日本語訳
5203 Host Identity Protocol (HIP) Registration Extension. J. Laganier,T. Koponen, L. Eggert. April 2008. (Format: TXT=26620 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Laganier
Request for Comments: 5203 DoCoMo Euro-Labs
Category: Experimental T. Koponen
HIIT
L. Eggert
Nokia
April 2008
Laganierがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 5203年のDoCoMoユーロ研究室カテゴリ: 実験的なT.Koponen HIIT L.エッゲルトノキア2008年4月
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.
このドキュメントはホストがサービスとともに記名することができるHost Identityプロトコル(HIP)に登録メカニズムを指定します、HIPランデブーのサーバやmiddleboxesのように。
1. Introduction
1. 序論
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].
このドキュメントはHost Identityプロトコル(HIP)[RFC5201]に拡大を指定します。 拡大はホストがサービスとともに記名する一般的な手段を提供します。 例えば、サービスは、HIPランデブーサーバ[RFC5204]かmiddleboxであるかもしれません[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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Laganier, et al. Experimental [Page 1] RFC 5203 HIP Registration Extension April 2008
Laganier、他 クールな[1ページ]実験的なRFC5203登録拡大2008年4月
2. Terminology
2. 用語
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 Architectureで定義された用語[RFC4423]、HIP仕様[RFC5201]、およびHIP Rendezvous Extension[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サービスの利益を得るのを許容して、リクエスタと記録係によって格納された共有された状態。 各登録には、関連有限寿命があります。 リクエスタが再登録で確立した登録証明書を広げることができる、(すなわち、aを実行してください、リフレッシュ、)
Registration Type:
an identifier for a given service in the registration protocol.
For example, the rendezvous service is identified by a specific
registration type.
登録タイプ: 登録プロトコルにおける与えられたサービスのための識別子。 例えば、ランデブーサービスは特定の登録タイプによって特定されます。
3. HIP Registration Extension Overview
3. クールな登録拡大概観
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]の違いについて説明します。
Laganier, et al. Experimental [Page 2] RFC 5203 HIP Registration Extension April 2008
Laganier、他 クールな[2ページ]実験的なRFC5203登録拡大2008年4月
3.1. Registrar Announcing Its Ability
3.1. 性能を発表する記録係
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.
できるのと記録係SHOULDとして機能しても構わないと思っているホストはそれがすべての塩基置換の間に送るR1パケットでレッジ_INFOパラメタを入れます。 現在それであることができないなら、提供するのは一時的な状態に支払われるべきものを修理します、それ。SHOULDは空のレッジ_INFO(すなわち、サービスが全く記載されていない1)を含んでいます。 サービスであるなら後で提供できます、それ。SHOULDはUPDATEパケットに現在の新しいレッジ_INFOパラメタでそれが関連しているすべてのホストにとって利用可能にサービスのセットを示させます。
3.2. Requester Requesting Registration
3.2. 登録を要求するリクエスタ
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パケットに対応するレッジ_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協会を全く設立しません、それ。SHOULDは最も前の可能性でレッジ_REQUESTを送ります、すなわち、I2パケットで。 これは記録係と共に交換される必要があるパケットの数を最小にします。 記録係はR2のタイプレッジ_REQUIREDと共にNOTIFYを含んでいることによってレッジ_REQUESTを運ばないHIP協会を終わらせるかもしれません。 この場合、HIP協会は全くホストの間に創設されません。 レッジ_REQUIRED通知誤りタイプは51歳です。
3.3. Registrar Granting or Refusing Service(s) Registration
3.3. サービス登録を承諾するか、または拒否する記録係
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にアイデンティティを含んでいて、ホストに基づくリクエスタを認証できます。 そして、それは、ホストのアイデンティティがローカルの方針に基づいて要求されたサービスとともに記名するのが認可されることを確かめます。 この認可手順の詳細は、要求されたサービスのタイプと、そして、記録係のローカルの方針に頼っていて、したがって、さらに本書では指定されません。
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.
認可の後に、記録係がそれが登録を認可したサービスタイプを含む応答とゼロでレッジ_RESPONSEパラメタを入れるか、またはサービスを含むより多くのレッジ_FAILEDパラメタが登録を認可していないか、または登録が他の理由で失敗した(s)をタイプします。 この応答は、それぞれ登録が塩基置換の間、要求されたか、または既存の協会を使用していたかによるR2かUPDATEメッセージのどちらかであるかもしれません。 特に、ゼロ失敗タイプがあるレッジ_FAILEDは登録のためにさらなる信任状を必要とするサービスタイプを示します。
Laganier, et al. Experimental [Page 3] RFC 5203 HIP Registration Extension April 2008
Laganier、他 クールな[3ページ]実験的なRFC5203登録拡大2008年4月
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協会が設立された後にリクエスタSHOULDは再びサービスとともに記名しようとします。 信任状を設立して、確かめる正確な手段は、このドキュメントの範囲を超えていて、他のドキュメントで定義されると予想されます。
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).
レッジ_RESPONSEパラメタのうまくいっている処理はリクエスタに登録状態を創設します。 同じように、レッジ_REQUESTパラメタのうまくいっている処理は記録係においてことによるとサービスときの登録状態を創設します。 ともに、期限が切れる前にリクエスタと記録係は登録を中止できます、登録で提供されたサービスをリクエスタがもう必要でないことができない、記録係がもう提供できないなら(例えば、構成が変化した、)
+-----+ I1 +-----+-----+
| |--------------------->| | S1 |
| |<---------------------| | |
| | R1(REG_INFO:S1,S2) | +-----+
| RQ | | R | S2 |
| | I2(REG_REQ:S1) | | |
| |--------------------->| +-----+
| |<---------------------| | S3 |
| | R2(REG_RESP:S1) | | |
+-----+ +-----+-----+
+-----+ I1+-----+-----+ | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| S1| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、| R1(レッジ_インフォメーション: S1、S2)| +-----+ | RQ| | R| S2| | | I2(レッジ_REQ: S1)| | | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| +-----+ | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| S3| | | R2(レッジ_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) | | |
| |<---------------------| | |
+-----+ +-----+-----+
+-----+ +-----+-----+ | | アップデート(レッジ_インフォメーション: S)| | | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| RQ|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| R| S| | | アップデート(レッジ_REQ: S)| | | | | アップデート(レッジ_RESP: S)| | | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| +-----+ +-----+-----+
A requester (RQ) registers with a registrar (R) of services (S), with
which it currently has a HIP association established.
リクエスタ(RQ)は現在それでHIP協会を設立するサービス(S)の記録係(R)とともに記名します。
Laganier, et al. Experimental [Page 4] RFC 5203 HIP Registration Extension April 2008
Laganier、他 クールな[4ページ]実験的なRFC5203登録拡大2008年4月
4. Parameter Formats and Processing
4. パラメタ形式と処理
This section describes the format and processing of the new parameters introduced by the HIP registration extension.
このセクションはHIP登録拡張子で紹介された新しいパラメタの形式と処理について説明します。
4.1. Encoding Registration Lifetimes with Exponents
4.1. 解説者と共に登録生涯をコード化します。
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登録は登録生涯の指数のコード化を使用します。 これは4msから178日間まで8ビットの整数分野に及ぶ255の異なった生涯値のコンパクトなコード化を許します。 生涯値を2^(生涯--64)/8)秒表して、このドキュメント中で使用される生涯解説者分野を解釈しなければなりません。
4.2. REG_INFO
4.2. レッジ_インフォメーション
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min Lifetime | Max Lifetime | Reg Type #1 | Reg Type #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... | Reg Type #n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 分、生涯| マックスLifetime| レッジタイプ#1| レッジタイプ#2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | ... | レッジタイプ#n| | +++++++++++++++++++++++++詰め物+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Type、Length、およびPaddingを除いて、930Length Lengthを八重奏にタイプしてください。 Lifetime Minimum登録生涯分。 マックスLifetime Maximum登録生涯。 登録タイプが記録係で提供したレッジ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パケットでパラメタを入れます。 サービス提供が変化したとき、記録係SHOULDはUPDATEパケットにパラメタを含んでいます。 HIP_SIGNATURE_2はR1パケットの中にパラメタを保護します。
Laganier, et al. Experimental [Page 5] RFC 5203 HIP Registration Extension April 2008
Laganier、他 クールな[5ページ]実験的なRFC5203登録拡大2008年4月
4.3. REG_REQUEST
4.3. レッジ_REQUEST
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Reg Type #1 | Reg Type #2 | Reg Type #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... | Reg Type #n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 生涯| レッジタイプ#1| レッジタイプ#2| レッジタイプ#3| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | ... | レッジタイプ#n| | +++++++++++++++++++++++++詰め物+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Type、Length、およびPaddingを除いて、932Length Lengthを八重奏にタイプしてください。 生涯Requested登録生涯。 都合のよい登録が好みの順にタイプするレッジType。
Other documents will define specific values for registration types. See Section 7 for more information.
他のドキュメントは登録タイプのために特定の値を定義するでしょう。 詳しい情報に関してセクション7を見てください。
A requester includes the REG_REQUEST parameter in I2 or UPDATE packets to register with a registrar's service(s). If the REG_REQUEST parameter is in an UPDATE packet, the registrar MUST NOT modify the registrations of registration types that are not listed in the parameter. Moreover, the requester MUST NOT include the parameter unless the registrar's R1 packet or latest received UPDATE packet has contained a REG_INFO parameter with the requested registration types.
リクエスタは、記録係のサービスとともに記名するためにI2かUPDATEパケットにレッジ_REQUESTパラメタを含んでいます。 レッジ_REQUESTパラメタがUPDATEパケットにあるなら、記録係はパラメタに記載されていない登録タイプの登録証明書を変更してはいけません。 そのうえ、記録係のR1パケットか最新の容認されたUPDATEパケットが要求された登録タイプがあるレッジ_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つ以上のレッジ_REQUESTパラメタを含んではいけません、記録係が容認されたI2かUPDATEパケットで1つ以上のレッジ_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.
記録係が生涯で登録を受けるとき、それは、最小の、または、最大の生涯よりさらに小さいか、または長く、それぞれ、次に、それはSHOULD交付金です。最小の、または、最大の生涯のためのそれぞれ登録。
HIP_SIGNATURE protects the parameter within the I2 and UPDATE packets.
HIP_SIGNATUREはI2とUPDATEパケットの中にパラメタを保護します。
Laganier, et al. Experimental [Page 6] RFC 5203 HIP Registration Extension April 2008
Laganier、他 クールな[6ページ]実験的なRFC5203登録拡大2008年4月
4.4. REG_RESPONSE
4.4. レッジ_応答
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Reg Type #1 | Reg Type #2 | Reg Type #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... | Reg Type #n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 生涯| レッジタイプ#1| レッジタイプ#2| レッジタイプ#3| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | ... | レッジタイプ#n| | +++++++++++++++++++++++++詰め物+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Type、Length、およびPaddingを除いて、934Length Lengthを八重奏にタイプしてください。 生涯Granted登録生涯。 与えられた登録が好みの順にタイプするレッジType。
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パケットにレッジ_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かUPDATEパケットの1つ以上のレッジ_RESPONSEパラメタを入れてはいけません、リクエスタが容認されたR2かUPDATEパケットで1つ以上のレッジ_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.
あらゆる登録生涯を得るようにリクエスタを準備しなければなりません、レッジ_INFOパラメタで示された最小の、そして、最大の生涯ものを含んでいて。 それは、返された寿命が要求されたものになると予想してはいけません、要求された寿命が発表された最小限と最大の中に下がると。
HIP_SIGNATURE protects the parameter within the R2 and UPDATE packets.
HIP_SIGNATUREはR2とUPDATEパケットの中にパラメタを保護します。
Laganier, et al. Experimental [Page 7] RFC 5203 HIP Registration Extension April 2008
Laganier、他 クールな[7ページ]実験的なRFC5203登録拡大2008年4月
4.5. REG_FAILED
4.5. レッジ_は失敗しました。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Failure Type | Reg Type #1 | Reg Type #2 | Reg Type #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... | Reg Type #n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 失敗タイプ| レッジタイプ#1| レッジタイプ#2| レッジタイプ#3| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | ... | レッジタイプ#n| | +++++++++++++++++++++++++詰め物+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Type、Length、およびPaddingを除いて、936Length Lengthを八重奏にタイプしてください。 失敗のための失敗Type Reason。 指定された理由で失敗した登録タイプのレッジType。
Failure Type Reason
------------ --------------------------------------------
0 Registration requires additional credentials
1 Registration type unavailable
2-200 Unassigned
201-255 Reserved by IANA for private use
失敗タイプ理由------------ -------------------------------------------- 0 登録はIANAで私的使用目的で追加信任状の1Registrationのタイプ入手できない2-200Unassigned201-255Reservedを必要とします。
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つ(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.
記録係SHOULDはそのR2かUPDATEパケットにレッジ_FAILEDパラメタを含んで、登録タイプとの登録が記載したなら、首尾よく完成されていなくて、aリクエスタが追加信任状で再試行するように頼まれましたか?
HIP_SIGNATURE protects the parameter within the R2 and UPDATE packets.
HIP_SIGNATUREはR2とUPDATEパケットの中にパラメタを保護します。
Laganier, et al. Experimental [Page 8] RFC 5203 HIP Registration Extension April 2008
Laganier、他 クールな[8ページ]実験的なRFC5203登録拡大2008年4月
5. Establishing and Maintaining Registrations
5. 登録証明書を確立して、維持します。
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.
登録を設立する、そして/または、維持するのは伝えられたレッジ_REQUESTかレッジ_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秒である、それらである間、SHOULDは少なくとも120秒について最大の生涯をサポートします。 これらの値は登録制に基づくサービスの仕様のために基線を定義します。 それらは、それほど短くなくて、またそれほど長くなく、存在するようにタイムアウトを収容するためにmiddleboxesに設置された状態について選ばれました。(例えば、NATsとファイアウォール。)
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.
寿命が目的を取り消しながら取っておかれるゼロ。 ゼロを要求して、登録タイプのための寿命はそのタイプの登録を中止するのと等しいです。 記録係へのaによる生涯を全くREG_REQに送らないことによって期限が切れる前にリクエスタは登録を取り消すかもしれません。 記録係SHOULDは応じて、ゼロがある登録に生涯を与えます。 一存で期限が切れる前に記録係(そして、付属サービス)は登録を取り消すかもしれません。 しかしながら、それがそのように、それをするなら、SHOULDはすべての登録されたリクエスタへの生涯を全くaがあるレッジ_RESPONSEに送りません。
6. Security Considerations
6. セキュリティ問題
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記録係がいつでも一存で登録証明書を中止するかもしれないので、例えば、攻撃の間のリソース規制のために。
Laganier, et al. Experimental [Page 9] RFC 5203 HIP Registration Extension April 2008
Laganier、他 クールな[9ページ]実験的なRFC5203登録拡大2008年4月
7. IANA Considerations
7. IANA問題
This section is to be interpreted according to the Guidelines for Writing an IANA Considerations Section in RFCs [RFC2434].
Guidelinesによると、このセクションはWritingのために解釈されることになっています。RFCs[RFC2434]のIANA Considerationsセクション。
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 Parameter Typesのために本書では定義された新しいHIP Parametersのために新しいHIP Parameter Types値を割り当てることによって、IANA Registryをアップデートします:
o REG_INFO (defined in Section 4.2)
o レッジ_インフォメーション(セクション4.2では、定義されます)
o REG_REQUEST (defined in Section 4.3)
o レッジ_REQUEST(セクション4.3では、定義されます)
o REG_RESPONSE (defined in Section 4.4)
o レッジ_応答(セクション4.4では、定義されます)
o REG_FAILED (defined in Section 4.5)
o レッジ_は失敗しました。(セクション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 Message Type登録のレッジ_REQUIRED通知誤りタイプのためにNotify Message Typeコード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
レッジタイプサービス-------- ------- 0-200 201-255 ReservedはIANAによって私的使用目的で割り当てられませんでした。
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
失敗タイプ理由------------ -------------------------------------------- 0 登録はIANAで私的使用目的で追加信任状の1Registrationのタイプ入手できない2-200Unassigned201-255Reservedを必要とします。
Adding a new type requires new IETF specifications.
新しいタイプを加えるのは新しいIETF仕様を必要とします。
Laganier, et al. Experimental [Page 10] RFC 5203 HIP Registration Extension April 2008
Laganier、他 クールな[10ページ]実験的なRFC5203登録拡大2008年4月
8. Acknowledgments
8. 承認
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、ミリアム・エステバン、ミカ甲佐、ペッカNikander、およびハンネスTschofenig。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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問題部に書くためのガイドライン」BCP26、RFC2434(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.ヘンダーソン、「ホストアイデンティティプロトコル」、RFC5201、4月2008日
9.2. Informative References
9.2. 有益な参照
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, February 2002.
[RFC3234]大工、B.、およびS.があふれそうになる、「Middleboxes:」 「分類学と問題」、RFC3234、2月2002日
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006.
[RFC4423] マスコウィッツ、R.、およびP.Nikander(「ホストのアイデンティティのプロトコルの(クール)の構造」、RFC4423)は2006がそうするかもしれません。
[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", RFC 5204, April 2008.
[RFC5204] LaganierとJ.とL.エッゲルト、「ホストのアイデンティティのプロトコルの(クール)のランデブー拡大」、RFC5204、2008年4月。
Laganier, et al. Experimental [Page 11] RFC 5203 HIP Registration Extension April 2008
Laganier、他 クールな[11ページ]実験的なRFC5203登録拡大2008年4月
Authors' Addresses
作者のアドレス
Julien Laganier DoCoMo Communications Laboratories Europe GmbH Landsberger Strasse 312 Munich 80687 Germany
ジュリアンLaganier DoCoMoコミュニケーション研究所ヨーロッパGmbHランツベルガーストラッセ312ミュンヘン80687ドイツ
Phone: +49 89 56824 231 EMail: julien.ietf@laposte.net URI: http://www.docomolab-euro.com/
以下に電話をしてください。 +49 89 56824 231メール: julien.ietf@laposte.net ユリ: 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
情報技術先端研究ユニット(ARU)私書箱9800ヘルシンキフィン02015HUTフィンランドのテームKoponenヘルシンキ研究所
Phone: +358 9 45 1 EMail: teemu.koponen@iki.fi URI: http://www.hiit.fi/
以下に電話をしてください。 +358 9 45 1 メール: teemu.koponen@iki.fi ユリ: http://www.hiit.fi/
Lars Eggert Nokia Research Center P.O. Box 407 Nokia Group 00045 Finland
ラースエッゲルトノキアリサーチセンター私書箱407Nokia Group00045フィンランド
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 ユリ: http://research.nokia.com/people/lars_eggert/
Laganier, et al. Experimental [Page 12] RFC 5203 HIP Registration Extension April 2008
Laganier、他 クールな[12ページ]実験的なRFC5203登録拡大2008年4月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Laganier, et al. Experimental [Page 13]
Laganier、他 実験的[13ページ]
一覧
スポンサーリンク
