RFC5204 日本語訳
5204 Host Identity Protocol (HIP) Rendezvous Extension. J. Laganier,L. Eggert. April 2008. (Format: TXT=30233 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Laganier
Request for Comments: 5204 DoCoMo Euro-Labs
Category: Experimental L. Eggert
Nokia
April 2008
Laganierがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 5204年のDoCoMoユーロ研究室カテゴリ: 実験的なL.エッゲルトノキア2008年4月
Host Identity Protocol (HIP) Rendezvous 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 defines a rendezvous extension for the Host Identity Protocol (HIP). The rendezvous extension extends HIP and the HIP registration extension for initiating communication between HIP nodes via HIP rendezvous servers. Rendezvous servers improve reachability and operation when HIP nodes are multi-homed or mobile.
このドキュメントはHost Identityプロトコル(HIP)のためのランデブー拡大を定義します。 ランデブー拡大はHIPとHIPランデブーサーバでHIPノードのコミュニケーションを開始するためのHIP登録拡張子を広げています。 HIPノードが改良するとき、ランデブーサーバが可到達性と操作を改良する、マルチ、家へ帰り、または、可動です。
Laganier & Eggert Experimental [Page 1] RFC 5204 HIP Rendezvous Extension April 2008
Laganierとエッゲルト実験的な[1ページ]RFC5204HIPは拡大2008年4月に集合します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Rendezvous Server Operation . . . . . . . . . . . 4
3.1. Diagram Notation . . . . . . . . . . . . . . . . . . . . . 5
3.2. Rendezvous Client Registration . . . . . . . . . . . . . . 6
3.3. Relaying the Base Exchange . . . . . . . . . . . . . . . . 6
4. Rendezvous Server Extensions . . . . . . . . . . . . . . . . . 7
4.1. RENDEZVOUS Registration Type . . . . . . . . . . . . . . . 7
4.2. Parameter Formats and Processing . . . . . . . . . . . . . 8
4.2.1. RVS_HMAC Parameter . . . . . . . . . . . . . . . . . . 8
4.2.2. FROM Parameter . . . . . . . . . . . . . . . . . . . . 9
4.2.3. VIA_RVS Parameter . . . . . . . . . . . . . . . . . . 10
4.3. Modified Packets Processing . . . . . . . . . . . . . . . 10
4.3.1. Processing Outgoing I1 Packets . . . . . . . . . . . . 10
4.3.2. Processing Incoming I1 Packets . . . . . . . . . . . . 11
4.3.3. Processing Outgoing R1 Packets . . . . . . . . . . . . 11
4.3.4. Processing Incoming R1 Packets . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 14
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 ランデブーサーバ操作. . . . . . . . . . . 4 3.1の概観。 記法. . . . . . . . . . . . . . . . . . . . . 5 3.2を図解してください。 クライアント登録. . . . . . . . . . . . . . 6 3.3を集合させてください。 塩基置換. . . . . . . . . . . . . . . . 6 4をリレーします。 サーバ拡大. . . . . . . . . . . . . . . . . 7 4.1を集合させてください。 ランデブー登録は.74.2をタイプします。 パラメタ形式と処理. . . . . . . . . . . . . 8 4.2.1。 RVS_HMACパラメタ. . . . . . . . . . . . . . . . . . 8 4.2.2。 パラメタ. . . . . . . . . . . . . . . . . . . . 9 4.2.3から。 _RVSパラメタ. . . . . . . . . . . . . . . . . . 10 4.3で。 変更されたパケット処理. . . . . . . . . . . . . . . 10 4.3.1。 出発しているI1パケット. . . . . . . . . . . . 10 4.3.2を処理します。 入って来るI1パケット. . . . . . . . . . . . 11 4.3.3を処理します。 出発しているR1パケット. . . . . . . . . . . . 11 4.3.4を処理します。 入って来るR1パケット. . . . . . . . . . . . 11 5を処理します。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 12 6。 IANA問題. . . . . . . . . . . . . . . . . . . . . 12 7。 承認. . . . . . . . . . . . . . . . . . . . . . . 13 8。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1。 引用規格. . . . . . . . . . . . . . . . . . . 13 8.2。 有益な参照. . . . . . . . . . . . . . . . . . 14
Laganier & Eggert Experimental [Page 2] RFC 5204 HIP Rendezvous Extension April 2008
Laganierとエッゲルト実験的な[2ページ]RFC5204HIPは拡大2008年4月に集合します。
1. Introduction
1. 序論
The Host Identity Protocol (HIP) Architecture [RFC4423] introduces
the rendezvous mechanism to help a HIP node to contact a frequently
moving HIP node. The rendezvous mechanism involves a third party,
the rendezvous server (RVS), which serves as an initial contact point
("rendezvous point") for its clients. The clients of an RVS are HIP
nodes that use the HIP Registration Extension [RFC5203] to register
their HIT->IP address mappings with the RVS. After this
registration, other HIP nodes can initiate a base exchange using the
IP address of the RVS instead of the current IP address of the node
they attempt to contact. Essentially, the clients of an RVS become
reachable at the RVS's IP address. Peers can initiate a HIP base
exchange with the IP address of the RVS, which will relay this
initial communication such that the base exchange may successfully
complete.
Host Identityプロトコル(HIP)構造[RFC4423]は、頻繁に感動的なHIPノードに連絡するためにHIPノードを助けるランデブーメカニズムを紹介します。 ランデブーメカニズムは第三者、クライアントのための初期接触ポイント(「ランデブーポイント」)として機能するランデブーサーバ(RVS)にかかわります。 RVSのクライアントが登録するのに、HIP Registration Extension[RFC5203]を使用するHIPノードである、それら、HIT->、IP、RVSと共にマッピングを記述してください。 この登録の後に、他のHIPノードは、彼らが連絡するのを試みるノードの現在のIPアドレスの代わりにRVSのIPアドレスを使用することで塩基置換を起こすことができます。 本質的には、RVSのクライアントはRVSのIPアドレスで届くようになります。 同輩は、塩基置換が首尾よく完全な状態で起こすようにRVSのIPアドレスでHIP塩基置換を起こすことができます。(RVSはこの初期のコミュニケーションをリレーするでしょう)。
2. Terminology
2. 用語
This section defines terms used throughout the remainder of this specification.
このセクションはこの仕様の残り中で使用される用語を定義します。
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]で説明されるように本書では解釈されることであるべきですか?
In addition to the terminology defined in the HIP specification [RFC5201] and the HIP Registration Extension [RFC5203], this document defines and uses the following terms:
HIP仕様[RFC5201]とHIP Registration Extension[RFC5203]で定義された用語に加えて、このドキュメントは、次の用語を定義して、使用します:
Rendezvous Service
A HIP service provided by a rendezvous server to its rendezvous
clients. The rendezvous server offers to relay some of the
arriving base exchange packets between the initiator and
responder.
ランデブーサーバによってランデブークライアントに提供されたService A HIPサービスを集合させてください。 到着のいくつかをリレーするというランデブーサーバ申し出は創始者と応答者の間の交換パケットを基礎づけます。
Rendezvous Server (RVS)
A HIP registrar providing rendezvous service.
HIP記録係提供ランデブーが修理するServer(RVS)を集合させてください。
Rendezvous Client
A HIP requester that has registered for rendezvous service at a
rendezvous server.
ランデブーサーバでランデブーサービスに登録したClient A HIPリクエスタを集合させてください。
Rendezvous Registration
A HIP registration for rendezvous service, established between a
rendezvous server and a rendezvous client.
ランデブーサーバとランデブークライアントの間で確立されたランデブーサービスのためのRegistration A HIP登録を集合させてください。
Laganier & Eggert Experimental [Page 3] RFC 5204 HIP Rendezvous Extension April 2008
Laganierとエッゲルト実験的な[3ページ]RFC5204HIPは拡大2008年4月に集合します。
3. Overview of Rendezvous Server Operation
3. ランデブーサーバ操作の概観
Figure 1 shows a simple HIP base exchange without a rendezvous server, in which the initiator initiates the exchange directly with the responder by sending an I1 packet to the responder's IP address, as per the HIP specification [RFC5201].
図1はランデブーサーバなしで簡単なHIP塩基置換を示しています、HIP仕様[RFC5201]に従って。(そこでは、創始者が、直接応答者と共に応答者のIPアドレスにI1パケットを送ることによって、交換を起こします)。
+-----+ +-----+
| |-------I1------>| |
| I |<------R1-------| R |
| |-------I2------>| |
| |<------R2-------| |
+-----+ +-----+
+-----+ +-----+ | |-------I1------>|、|、| I| <、-、-、-、-、--R1-------| R| | |-------I2------>|、|、| | <、-、-、-、-、--R2-------| | +-----+ +-----+
Figure 1: HIP base exchange without rendezvous server.
図1: HIPはランデブーサーバなしで交換を基礎づけます。
The End-Host Mobility and Multihoming with the Host Identity Protocol specification [RFC5206] allows a HIP node to notify its peers about changes in its set of IP addresses. This specification presumes initial reachability of the two nodes with respect to each other.
Host Identityプロトコル仕様[RFC5206]があるEnd-ホストのMobilityとMultihomingはHIPノードにIPアドレスのセットにおける変化に関して同輩を通知させます。 この仕様は互いに関して2つのノードの初期の可到達性を推定します。
However, such a HIP node MAY also want to be reachable to other future correspondent peers that are unaware of its location change. The HIP Architecture [RFC4423] introduces rendezvous servers with whom a HIP node MAY register its host identity tags (HITs) and current IP addresses. An RVS relays HIP packets arriving for these HITs to the node's registered IP addresses. When a HIP node has registered with an RVS, it SHOULD record the IP address of its RVS in its DNS record, using the HIP DNS resource record type defined in the HIP DNS Extension [RFC5205].
しかしながら、また、そのようなHIPノードは他の位置の変化に気づかない将来の通信員の同輩にとって届くようになりたがっているかもしれません。 HIP Architecture[RFC4423]はHIPノードがそのホストアイデンティティタグ(HITs)と現在のIPアドレスを登録するかもしれないランデブーサーバを紹介します。 RVSはこれらのHITsのためにノードの登録されたIPアドレスに到着するHIPパケットをリレーします。 HIP DNSリソースレコード種類を使用するのはHIP DNS Extension[RFC5205]でいつHIPノードがRVSとともに記名して、それがIPが記述するDNS記録のRVSに関するSHOULD記録であるかを定義しました。
+-----+
+--I1--->| RVS |---I1--+
| +-----+ |
| v
+-----+ +-----+
| |<------R1-------| |
| I |-------I2------>| R |
| |<------R2-------| |
+-----+ +-----+
+-----+ +--I1--->| RVS|---I1--+| +-----+ | | +に対して-----+ +-----+ | | <、-、-、-、-、--R1-------| | | I|-------I2------>| R| | | <、-、-、-、-、--R2-------| | +-----+ +-----+
Figure 2: HIP base exchange with a rendezvous server.
図2: HIPはランデブーサーバで交換を基礎づけます。
Figure 2 shows a HIP base exchange involving a rendezvous server. It is assumed that HIP node R previously registered its HITs and current IP addresses with the RVS, using the HIP Registration Extension [RFC5203]. When the initiator I tries to establish contact with the
図2は、HIP塩基置換がランデブーサーバにかかわるのを示します。HIPノードRが以前にHITsと現在のIPアドレスをRVSに登録したと思われます、HIP Registration Extension[RFC5203]を使用して。 いつで、創始者Iは接触しようとするか。
Laganier & Eggert Experimental [Page 4] RFC 5204 HIP Rendezvous Extension April 2008
Laganierとエッゲルト実験的な[4ページ]RFC5204HIPは拡大2008年4月に集合します。
responder R, it must send the I1 of the base exchange either to one of R's IP addresses (if known via DNS or other means) or to one of R's rendezvous servers. Here, I obtains the IP address of R's rendezvous server from R's DNS record and then sends the I1 packet of the HIP base exchange to RVS. RVS, noticing that the HIT contained in the arriving I1 packet is not one of its own, MUST check its current registrations to determine if it needs to relay the packets. Here, it determines that the HIT belongs to R and then relays the I1 packet to the registered IP address. R then completes the base exchange without further assistance from RVS by sending an R1 directly to the I's IP address, as obtained from the I1 packet. In this specification, the client of the RVS is always the responder. However, there might be reasons to allow a client to initiate a base exchange through its own RVS, like NAT and firewall traversal. This specification does not address such scenarios, which should be specified in other documents.
応答者R、それはRのIPアドレス(DNSか他の手段で知られているなら)の1つ、または、Rのランデブーサーバの1つに塩基置換のI1を送らなければなりません。 ここで、私は、RのDNS記録からRのランデブーサーバのIPアドレスを得て、次に、HIP塩基置換のI1パケットをRVSに送ります。 それ自身の1つではなく、RVS、到着しているI1パケットに含まれたHITがそうである認識が、それが、パケットをリレーする必要であるかどうか決定するために現在の登録証明書をチェックしなければなりません。 ここで、それは、HITが登録されたIPアドレスにRのものて、次に、I1パケットをリレーすることを決定します。 次に、RはRVSからさらなる支援なしで直接IのIPアドレスにR1を送ることによって、塩基置換を終了します、I1パケットから得るように。 この仕様では、いつもRVSのクライアントは応答者です。 しかしながら、クライアントがそれ自身のRVSを通した塩基置換を起こすのを許容する理由があるかもしれません、NATとファイアウォール縦断のように。 この仕様はそのようなシナリオを記述しません。(シナリオは他のドキュメントで指定されるべきです)。
3.1. Diagram Notation
3.1. 記法を図解してください。
Notation Significance -------- ------------
記法意味-------- ------------
I, R I and R are the respective source and destination IP
addresses in the IP header.
私、R I、およびRは、IPがIPヘッダーで演説するそれぞれのソースと目的地です。
HIT-I, HIT-R HIT-I and HIT-R are the initiator's and the
responder's HITs in the packet, respectively.
HIT-I、HIT-R HIT-I、およびHIT-Rはそれぞれパケットの創始者と応答者のHITsです。
REG_REQ A REG_REQUEST parameter is present in the HIP header.
レッジ_REQ Aレッジ_REQUESTパラメタはHIPヘッダーに存在しています。
REG_RES A REG_RESPONSE parameter is present in the HIP header.
レッジ_RES Aレッジ_RESPONSEパラメタはHIPヘッダーに存在しています。
FROM:I A FROM parameter containing the IP address I is
present in the HIP header.
FROM:IPアドレスIを含むI A FROMパラメタはHIPヘッダーに存在しています。
RVS_HMAC An RVS_HMAC parameter containing an HMAC keyed with the
appropriate registration key is present in the HIP
header.
HMACが適切な登録キーで合わせたRVS_HMAC An RVS_HMACパラメタ含有はHIPヘッダーに存在しています。
VIA:RVS A VIA_RVS parameter containing the IP address RVS of a
rendezvous server is present in the HIP header.
VIA: ランデブーサーバのIPアドレスRVSを含むRVS A VIA_RVSパラメタはHIPヘッダーに存在しています。
Laganier & Eggert Experimental [Page 5] RFC 5204 HIP Rendezvous Extension April 2008
Laganierとエッゲルト実験的な[5ページ]RFC5204HIPは拡大2008年4月に集合します。
3.2. Rendezvous Client Registration
3.2. ランデブークライアント登録
Before a rendezvous server starts to relay HIP packets to a rendezvous client, the rendezvous client needs to register with it to receive rendezvous service by using the HIP Registration Extension [RFC5203] as illustrated in the following schema:
ランデブーサーバがランデブークライアントにHIPパケットをリレーし始める前に、ランデブークライアントは、以下の図式で例証されるようにHIP Registration Extension[RFC5203]を使用することによってランデブーサービスを受けるためにそれとともに記名する必要があります:
+-----+ +-----+
| | I1 | |
| |--------------------------->| |
| |<---------------------------| |
| I | R1(REG_INFO) | RVS |
| | I2(REG_REQ) | |
| |--------------------------->| |
| |<---------------------------| |
| | R2(REG_RES) | |
+-----+ +-----+
+-----+ +-----+ | | I1| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| I| R1(レッジ_インフォメーション)| RVS| | | I2(レッジ_REQ)| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |<---------------------------| | | | R2(レッジ_RES)| | +-----+ +-----+
Rendezvous client registering with a rendezvous server.
ランデブーサーバとともに記名するクライアントを集合させてください。
3.3. Relaying the Base Exchange
3.3. 塩基置換をリレーします。
If a HIP node and one of its rendezvous servers have a rendezvous registration, the rendezvous servers relay inbound I1 packets (that contain one of the client's HITs) by rewriting the IP header. They replace the destination IP address of the I1 packet with one of the IP addresses of the owner of the HIT, i.e., the rendezvous client. They MUST also recompute the IP checksum accordingly.
HIPノードとランデブーサーバの1つにランデブー登録があるなら、ランデブーサーバは、IPヘッダーを書き直すことによって、本国行きのI1パケット(それはクライアントのHITsの1つを含んでいる)をリレーします。 彼らはHIT(すなわち、ランデブークライアント)の所有者のIPアドレスの1つにI1パケットの送付先IPアドレスを置き換えます。 また、彼らはそれに従って、IPチェックサムを再計算しなければなりません。
Because of egress filtering on the path from the RVS to the client [RFC2827][RFC3013], a HIP rendezvous server SHOULD replace the source IP address, i.e., the IP address of I, with one of its own IP addresses. The replacement IP address SHOULD be chosen according to relevant IPv4 and IPv6 specifications [RFC1122][RFC3484]. Because this replacement conceals the initiator's IP address, the RVS MUST append a FROM parameter containing the original source IP address of the packet. This FROM parameter MUST be integrity protected by an RVS_HMAC keyed with the corresponding rendezvous registration integrity key [RFC5203].
経路でRVSからクライアントまで[RFC2827][RFC3013]をフィルターにかける出口のために、a HIPランデブーサーバSHOULDはソースIPアドレスを置き換えます、すなわち、IのIPアドレス、それ自身のIPアドレスの1つで。 交換IPはSHOULDを記述します。関連IPv4とIPv6仕様[RFC1122][RFC3484]通りに、選ばれてください。 この交換が創始者のIPアドレスを隠すので、RVS MUSTはパケットの一次資料IPアドレスを含むFROMパラメタを追加します。 このFROMパラメタは対応するランデブー登録保全キー[RFC5203]で合わせられたRVS_HMACによって保護された保全であるに違いありません。
Laganier & Eggert Experimental [Page 6] RFC 5204 HIP Rendezvous Extension April 2008
Laganierとエッゲルト実験的な[6ページ]RFC5204HIPは拡大2008年4月に集合します。
I1(RVS, R, HIT-I, HIT-R
I1(I, RVS, HIT-I, HIT-R) +---------+ FROM:I, RVS_HMAC)
+----------------------->| |--------------------+
| | RVS | |
| | | |
| +---------+ |
| V
+-----+ R1(R, I, HIT-R, HIT-I, VIA:RVS) +-----+
| |<---------------------------------------------| |
| | | |
| I | I2(I, R, HIT-I, HIT-R) | R |
| |--------------------------------------------->| |
| |<---------------------------------------------| |
+-----+ R2(R, I, HIT-R, HIT-I) +-----+
I1、(RVS、RヒットI、ヒット-R I1(I、RVSヒットI、ヒットR)+、-、-、-、-、-、-、-、--、+ RVS_HMAC) FROM:I、+----------------------->| |--------------------+ | | RVS| | | | | | | +---------+ | | +に対して-----+ R1(R、: RVSを通したRが打たれて、私が打たれた私)+-----+ | |<---------------------------------------------| | | | | | | I| I2(I、R、ヒットI、ヒットR)| R| | |--------------------------------------------->| | | |<---------------------------------------------| | +-----+ R2(R、I、ヒットR、ヒットI)+-----+
Rendezvous server rewriting IP addresses.
IPアドレスを書き直すサーバを集合させてください。
This modification of HIP packets at a rendezvous server can be problematic because the HIP protocol uses integrity checks. Because the I1 does not include HMAC or SIGNATURE parameters, these two end- to-end integrity checks are unaffected by the operation of rendezvous servers.
HIPプロトコルが保全チェックを使用するので、ランデブーサーバにおけるHIPパケットのこの変更は問題が多い場合があります。 I1がHMACかSIGNATUREパラメタを含んでいないので、これらの2つの終わりまでの終わりの保全チェックがランデブーサーバの操作で影響を受けないです。
The RVS SHOULD verify the checksum field of an I1 packet before doing any modifications. After modification, it MUST recompute the checksum field using the updated HIP header, which possibly included new FROM and RVS_HMAC parameters, and a pseudo-header containing the updated source and destination IP addresses. This enables the responder to validate the checksum of the I1 packet "as is", without having to parse any FROM parameters.
どんな変更もする前に、RVS SHOULDはI1パケットのチェックサム分野について確かめます。 変更の後に、それはチェックサム分野のアップデートされたソースを含んでいて、ことによると新しいFROMとRVS_HMACパラメタを含んでいたアップデートされたHIPヘッダーと疑似ヘッダーを使用して、目的地IPが記述するrecomputeがそうしなければなりません。 これは、応答者が「そのままで」I1パケットのチェックサムを有効にするのを可能にします、どんなFROMパラメタも分析する必要はなくて。
4. Rendezvous Server Extensions
4. ランデブーサーバ拡大
This section describes extensions to the HIP Registration Extension [RFC5203], allowing a HIP node to register with a rendezvous server for rendezvous service and notify the RVS aware of changes to its current location. It also describes an extension to the HIP specification [RFC5201] itself, allowing establishment of HIP associations via one or more HIP rendezvous server(s).
このセクションはHIP Registration Extension[RFC5203]に拡大について説明します、HIPノードがランデブーサービスのためのランデブーサーバとともに記名して、現在の位置への変化を意識しているRVSに通知するのを許容して。 また、それはHIP仕様[RFC5201]自体に拡大について説明します、1つ以上のHIPランデブーサーバでHIP協会の設立を許容して。
4.1. RENDEZVOUS Registration Type
4.1. ランデブー登録タイプ
This specification defines an additional registration for the HIP Registration Extension [RFC5203] that allows registering with a rendezvous server for rendezvous service.
この仕様はランデブーサービスのためのランデブーサーバとともに記名させるHIP Registration Extension[RFC5203]のために追加登録を定義します。
Laganier & Eggert Experimental [Page 7] RFC 5204 HIP Rendezvous Extension April 2008
Laganierとエッゲルト実験的な[7ページ]RFC5204HIPは拡大2008年4月に集合します。
Number Registration Type ------ ----------------- 1 RENDEZVOUS
数の登録タイプ------ ----------------- 1つのランデブー
4.2. Parameter Formats and Processing
4.2. パラメタ形式と処理
4.2.1. RVS_HMAC Parameter
4.2.1. RVS_HMACパラメタ
The RVS_HMAC is a non-critical parameter whose only difference with the HMAC parameter defined in the HIP specification [RFC5201] is its "type" code. This change causes it to be located after the FROM parameter (as opposed to the HMAC):
RVS_HMACはHMACパラメタがHIP仕様[RFC5201]に基づき定義されている唯一の違いがその「タイプ」コードである非臨界パラメタです。 この変化で、FROMパラメタ(HMACと対照的に)の後にそれの見つけます:
Type 65500
Length Variable. Length in octets, excluding Type, Length, and
Padding.
HMAC HMAC computed over the HIP packet, excluding the
RVS_HMAC parameter and any following parameters. The
HMAC is keyed with the appropriate HIP integrity key
(HIP-lg or HIP-gl) established when rendezvous
registration happened. The HIP "checksum" field MUST be set
to zero, and the HIP header length in the HIP common header
MUST be calculated not to cover any excluded parameter
when the HMAC is calculated. The size of the
HMAC is the natural size of the hash computation
output depending on the used hash function.
65500長さの変数をタイプしてください。 Type、Length、およびPaddingを除いた八重奏における長さ。 HMAC HMACはRVS_HMACパラメタとどんな次のパラメタを除いたHIPパケットの上で計算しました。 ランデブー登録が起こったとき、適切なHIP保全キー(HIP-lgかHIP-gl)が確立していた状態で、HMACは合わせられます。 HIP「チェックサム」分野をゼロに設定しなければなりません、そして、HMACが計算されるとき、どんな除かれたパラメタもカバーしないようにHIPの一般的なヘッダーのHIPヘッダ長について計算しなければなりません。 HMACのサイズは中古のハッシュ関数に依存する細切れ肉料理計算出力の自然なサイズです。
To allow a rendezvous client and its RVS to verify the integrity of packets flowing between them, both SHOULD protect packets with an added RVS_HMAC parameter keyed with the HIP-lg or HIP-gl integrity key established while registration occurred. A valid RVS_HMAC SHOULD be present on every packet flowing between a client and a server and MUST be present when a FROM parameter is processed.
ランデブークライアントとそのRVSがそれらの間を流れるパケットの保全、SHOULDが保護する両方について確かめるのを許容するために、HIP-lgかHIP-gl保全キーが設立されている状態で付記されたRVS_HMACパラメタが合わせられているパケットは登録である間、起こりました。 有効なRVS_HMAC SHOULDはクライアントとサーバの間を流れながらあらゆるパケットに存在していて、FROMパラメタが処理されるとき、存在していなければなりません。
Laganier & Eggert Experimental [Page 8] RFC 5204 HIP Rendezvous Extension April 2008
Laganierとエッゲルト実験的な[8ページ]RFC5204HIPは拡大2008年4月に集合します。
4.2.2. FROM Parameter
4.2.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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 65498
Length 16
Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address.
65498Length16Address An IPv6アドレスかIPv6のIPv4形式IPv4アドレスをタイプしてください。
A rendezvous server MUST add a FROM parameter containing the original source IP address of a HIP packet whenever the source IP address in the IP header is rewritten. If one or more FROM parameters are already present, the new FROM parameter MUST be appended after the existing ones.
ランデブーサーバはIPヘッダーのソースIPアドレスが書き直されるときはいつも、HIPパケットの一次資料IPアドレスを含むFROMパラメタを加えなければなりません。 1つ以上のFROMパラメタが既に存在しているなら、既存のものの後に新しいFROMパラメタを追加しなければなりません。
Whenever an RVS inserts a FROM parameter, it MUST insert an RVS_HMAC protecting the packet integrity, especially the IP address included in the FROM parameter.
RVSがFROMパラメタを挿入するときはいつも、パケット保全を保護するRVS_HMACを挿入しなければなりません、FROMパラメタにIPアドレスを特に含んでいて。
Laganier & Eggert Experimental [Page 9] RFC 5204 HIP Rendezvous Extension April 2008
Laganierとエッゲルト実験的な[9ページ]RFC5204HIPは拡大2008年4月に集合します。
4.2.3. VIA_RVS Parameter
4.2.3. _RVSパラメタで
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . .
. . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 65502
Length Variable
Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address.
65502Length Variable Address An IPv6アドレスかIPv6のIPv4形式IPv4アドレスをタイプしてください。
After the responder receives a relayed I1 packet, it can begin to send HIP packets addressed to the initiator's IP address, without further assistance from an RVS. For debugging purposes, it MAY include a subset of the IP addresses of its RVSs in some of these packets. When a responder does so, it MUST append a newly created VIA_RVS parameter at the end of the HIP packet. The main goal of using the VIA_RVS parameter is to allow operators to diagnose possible issues encountered while establishing a HIP association via an RVS.
応答者がリレーされたI1パケットを受けた後に、創始者のIPアドレスに記述されたパケットをHIPに送り始めることができます、RVSからのさらなる支援なしで。 デバッグ目的のために、それはこれらのいくつかのパケットにRVSsのIPアドレスの部分集合を含むかもしれません。 応答者がそうすると、それはHIPパケットの端で新たに作成されたVIA_RVSパラメタを追加しなければなりません。 オペレータはVIA_RVSパラメタを使用する第一目的でRVSを通してHIP協会を設立している間に遭遇する可能な問題を診断することになっていることができます。
4.3. Modified Packets Processing
4.3. 変更されたパケット処理
The following subsections describe the differences of processing of I1 and R1 while a rendezvous server is involved in the base exchange.
ランデブーサーバが塩基置換にかかわっている間、以下の小区分はI1とR1の処理の違いについて説明します。
4.3.1. Processing Outgoing I1 Packets
4.3.1. 出発しているI1パケットを処理します。
An initiator SHOULD NOT send an opportunistic I1 with a NULL destination HIT to an IP address that is known to be a rendezvous server address, unless it wants to establish a HIP association with the rendezvous server itself and does not know its HIT.
SHOULD NOTがランデブーサーバ自体とのHIP協会を設立したくない場合ランデブーサーバアドレスであることが知られていて、HITは知らないIPへのHITが記述するNULLの目的地がある便宜主義的なI1を送る創始者。
Laganier & Eggert Experimental [Page 10] RFC 5204 HIP Rendezvous Extension April 2008
Laganierとエッゲルト実験的な[10ページ]RFC5204HIPは拡大2008年4月に集合します。
When an RVS rewrites the source IP address of an I1 packet due to egress filtering, it MUST add a FROM parameter to the I1 that contains the initiator's source IP address. This FROM parameter MUST be protected by an RVS_HMAC keyed with the integrity key established at rendezvous registration.
RVSが出口フィルタリングのためI1パケットのソースIPアドレスを書き直すとき、それは創始者のソースIPアドレスを含むI1にFROMパラメタを加えなければなりません。 保全キーがランデブー登録で設立されている状態で合わせられたRVS_HMACはこのFROMパラメタを保護しなければなりません。
4.3.2. Processing Incoming I1 Packets
4.3.2. 入って来るI1パケットを処理します。
When a rendezvous server receives an I1 whose destination HIT is not its own, it consults its registration database to find a registration for the rendezvous service established by the HIT owner. If it finds an appropriate registration, it relays the packet to the registered IP address. If it does not find an appropriate registration, it drops the packet.
ランデブーサーバがI1を受ける、だれのもの、目的地HITがそれ自身でない、それはHIT所有者によって確立されたランデブーサービスのための登録を見つけるために登録データベースに相談します。 適切な登録を見つけるなら、それは登録されたIPアドレスにパケットをリレーします。 適切な登録を見つけないなら、それはパケットを落とします。
A rendezvous server SHOULD interpret any incoming opportunistic I1 (i.e., an I1 with a NULL destination HIT) as an I1 addressed to itself and SHOULD NOT attempt to relay it to one of its clients.
それ自体に記述されたI1とSHOULD NOTが、クライアントのひとりにそれをリレーするのを試みるとき、ランデブーサーバSHOULDはどんな入って来る便宜主義的なI1(すなわち、NULLの目的地HITとI1)も解釈します。
When a rendezvous client receives an I1, it MUST validate any present RVS_HMAC parameter. If the RVS_HMAC cannot be verified, the packet SHOULD be dropped. If the RVS_HMAC cannot be verified and a FROM parameter is present, the packet MUST be dropped.
ランデブークライアントがI1を受け取るとき、それはどんな現在のRVS_HMACパラメタも有効にしなければなりません。 RVS_であるならHMACについて確かめることができないで、パケットはSHOULDです。落とされます。 RVS_HMACについて確かめることができないで、FROMパラメタが存在しているなら、パケットを落とさなければなりません。
A rendezvous client acting as responder SHOULD drop opportunistic I1s that include a FROM parameter, because this indicates that the I1 has been relayed.
応答者SHOULDとして務めているランデブークライアントはFROMパラメタを含んでいる便宜主義的なI1sを落とします、これが、I1がリレーされたのを示すので。
4.3.3. Processing Outgoing R1 Packets
4.3.3. 出発しているR1パケットを処理します。
When a responder replies to an I1 relayed via an RVS, it MUST append to the regular R1 header a VIA_RVS parameter containing the IP addresses of the traversed RVSs.
応答者がRVSを通してリレーされたI1に答えると、それは横断されたRVSsのIPアドレスを含むVIA_RVSパラメタをレギュラーのR1ヘッダーに追加しなければなりません。
4.3.4. Processing Incoming R1 Packets
4.3.4. 入って来るR1パケットを処理します。
The HIP specification [RFC5201] mandates that a system receiving an R1 MUST first check to see if it has sent an I1 to the originator of the R1 (i.e., the system is in state I1-SENT). When the R1 is replying to a relayed I1, this check SHOULD be based on HITs only. In case the IP addresses are also checked, then the source IP address MUST be checked against the IP address included in the VIA_RVS parameter.
HIP仕様[RFC5201]は、最初にR1 MUSTを受けるシステムがそれがR1の創始者にI1を送ったかどうかを(すなわち、システムが州のI1-SENTにあります)見るためにチェックするのを強制します。 R1がリレーされたI1に答えているとき、このチェックSHOULDはHITsだけに基づいて答えています。 また、IPアドレスがチェックされるといけないので、そして、VIA_RVSパラメタにアドレスを含んでいる場合、IPに対してソースIPアドレスをチェックしなければなりません。
Laganier & Eggert Experimental [Page 11] RFC 5204 HIP Rendezvous Extension April 2008
Laganierとエッゲルト実験的な[11ページ]RFC5204HIPは拡大2008年4月に集合します。
5. Security Considerations
5. セキュリティ問題
This section discusses the known threats introduced by these HIP extensions and the implications on the overall security of HIP. In particular, it argues that the extensions described in this document do not introduce additional threats to the Host Identity Protocol.
このセクションはHIPの総合的なセキュリティでこれらのHIP拡張子と含意によって導入された知られている脅威について論じます。 特に、それは、本書では説明された拡大がHost Identityプロトコルに追加脅威を紹介しないと主張します。
It is difficult to encompass the whole scope of threats introduced by rendezvous servers because their presence has implications both at the IP and HIP layers. In particular, these extensions might allow for redirection, amplification, and reflection attacks at the IP layer, as well as attacks on the HIP layer itself, for example, man- in-the-middle attacks against the HIP base exchange.
それらの存在がIPとHIP層に意味を持っているのでランデブーサーバによって導入された脅威の全体の範囲を取り囲むのは難しいです。 特に、これらの拡張子はIP層でリダイレクション、増幅、および反射攻撃を考慮するかもしれません、HIP層自体に対する攻撃と同様に、例えば、HIPに対する中央での男性攻撃は交換を基礎づけます。
If an initiator has a priori knowledge of the responder's host identity when it first contacts the responder via an RVS, it has a means to verify the signatures in the HIP base exchange, which protects against man-in-the-middle attacks.
最初にRVSを通して応答者に連絡するとき創始者に応答者のホストのアイデンティティに関する先験的な知識があるなら、それにはHIP塩基置換における署名について確かめる手段があります。塩基置換は介入者攻撃から守ります。
If an initiator does not have a priori knowledge of the responder's host identity (so-called "opportunistic initiators"), it is almost impossible to defend the HIP exchange against these attacks, because the public keys exchanged cannot be authenticated. The only approach would be to mitigate hijacking threats on HIP state by requiring an R1 answering an opportunistic I1 to come from the same IP address that originally sent the I1. This procedure retains a level of security that is equivalent to what exists in the Internet today.
創始者に応答者のホストのアイデンティティ(いわゆる「便宜主義的な創始者」)に関する先験的な知識がないなら、これらの攻撃に対してHIP交換を防御するのはほとんど不可能です、交換された公開鍵を認証できないので。 唯一のアプローチは便宜主義的なI1に答えるR1が元々I1を送ったのと同じIPアドレスから来るのを必要とすることによってHIP状態でハイジャックの脅威を緩和するだろうことです。 この手順は今日インターネットに存在するものに同等なセキュリティのレベルを保有します。
However, for reasons of simplicity, this specification does not allow the establishment of a HIP association via a rendezvous server in an opportunistic manner.
しかしながら、簡単さの理由で、この仕様は便宜主義的な方法によるランデブーサーバでHIP協会の設立を許容しません。
6. IANA Considerations
6. 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 Parameters Types by assigning new HIP Parameter Types values for the new HIP Parameters defined in Section 4.2:
このドキュメントはHIP Parameters Typesのためにセクション4.2で定義された新しいHIP Parametersのために新しいHIP Parameter Types値を割り当てることによって、IANA Registryをアップデートします:
o RVS_HMAC (defined in Section 4.2.1)
o RVS_HMAC(セクション4.2.1では、定義されます)
o FROM (defined in Section 4.2.2)
o from(セクション4.2.2では、定義されます)
o VIA_RVS (defined in Section 4.2.3)
o _RVSを通して(セクション4.2.3では、定義されます)
Laganier & Eggert Experimental [Page 12] RFC 5204 HIP Rendezvous Extension April 2008
Laganierとエッゲルト実験的な[12ページ]RFC5204HIPは拡大2008年4月に集合します。
This document defines an additional registration for the HIP Registration Extension [RFC5203] that allows registering with a rendezvous server for rendezvous service.
このドキュメントはランデブーサービスのためのランデブーサーバとともに記名させるHIP Registration Extension[RFC5203]のために追加登録を定義します。
Number Registration Type ------ ----------------- 1 RENDEZVOUS
数の登録タイプ------ ----------------- 1つのランデブー
7. Acknowledgments
7. 承認
The following people have provided thoughtful and helpful discussions and/or suggestions that have improved this document: Marcus Brunner, Tom Henderson, Miika Komu, Mika Kousa, Pekka Nikander, Justino Santos, Simon Schuetz, Tim Shepard, Kristian Slavov, Martin Stiemerling, and Juergen Quittek.
以下の人々は考え深くて役立っている議論、そして/または、このドキュメントを改良した提案を提供しました: マーカス・ブルンナー、トム・ヘンダーソン、ミカKomu、ミカ甲佐、ペッカNikander、Justinoサントス、サイモンSchuetz、ティム・シェパード、クリスチャンSlavov、マーチンStiemerling、およびユルゲンQuittek。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日
[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月)。
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484]Draves、R.、「インターネットプロトコルバージョン6(IPv6)のためのデフォルトAddress Selection」、RFC3484、2003年2月。
[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日
[RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity
Protocol (HIP) Registration Extension", RFC 5203,
April 2008.
[RFC5203] Laganier、J.、Koponen、T.、およびL.エッゲルト、「ホストのアイデンティティのプロトコルの(クール)の登録拡大」、RFC5203、2008年4月。
[RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol
(HIP) Domain Name System (DNS) Extensions", RFC 5205,
April 2008.
[RFC5205] NikanderとP.とJ.Laganier、「ホストのアイデンティティのプロトコルの(クール)のドメインネームシステム(DNS)拡大」、RFC5205、2008年4月。
Laganier & Eggert Experimental [Page 13] RFC 5204 HIP Rendezvous Extension April 2008
Laganierとエッゲルト実験的な[13ページ]RFC5204HIPは拡大2008年4月に集合します。
8.2. Informative References
8.2. 有益な参照
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827] ファーガソン、P.、およびD.Senieは「以下をフィルターにかけるイングレスをネットワークでつなぎます」。 「IP Source Address Spoofingを使うサービス妨害Attacksを破ります」、BCP38、RFC2827、2000年5月。
[RFC3013] Killalea, T., "Recommended Internet Service Provider
Security Services and Procedures", BCP 46, RFC 3013,
November 2000.
T. [RFC3013]Killalea、BCP46、RFC3013、11月2000日「インターネットサービスプロバイダセキュリティー・サービスと手順は推薦され」て、
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006.
[RFC4423] マスコウィッツ、R.、およびP.Nikander(「ホストのアイデンティティのプロトコルの(クール)の構造」、RFC4423)は2006がそうするかもしれません。
[RFC5206] Henderson, T., Ed., "End-Host Mobility and Multihoming
with the Host Identity Protocol", RFC 5206, April 2008.
[RFC5206] ヘンダーソン、T.、エド、「ホストのアイデンティティがある終わりホストの移動性とマルチホーミングは議定書を作る」、RFC5206、4月2008日
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/
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 & Eggert Experimental [Page 14] RFC 5204 HIP Rendezvous Extension April 2008
Laganierとエッゲルト実験的な[14ページ]RFC5204HIPは拡大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 & Eggert Experimental [Page 15]
LaganierとエッゲルトExperimentalです。[15ページ]
一覧
スポンサーリンク
