RFC4843 日本語訳
4843 An IPv6 Prefix for Overlay Routable Cryptographic HashIdentifiers (ORCHID). P. Nikander, J. Laganier, F. Dupont. April 2007. (Format: TXT=32483 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Nikander Request for Comments: 4843 Ericsson Research Nomadic Lab Category: Experimental J. Laganier DoCoMo Euro-Labs F. Dupont CELAR April 2007
Nikanderがコメントのために要求するワーキンググループP.をネットワークでつないでください: 4843年のエリクソンの研究の遊牧民的な研究室カテゴリ: 実験的なJ.のLaganier DoCoMoユーロ研究室F.デュポンCELAR2007年4月
An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)
オーバレイのRoutableの暗号の細切れ肉料理識別子のためのIPv6接頭語(ラン)
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プロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
This document introduces Overlay Routable Cryptographic Hash Identifiers (ORCHID) as a new, experimental class of IPv6-address- like identifiers. These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (API) and not as identifiers for network location at the IP layer, i.e., locators. They are designed to appear as application layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like vanilla IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered non-routable addresses from the IPv6 layer point-of-view, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses.
このドキュメントは新しくて、実験しているクラスのIPv6-アドレス同様の識別子としてOverlay Routable Cryptographic Hash Identifiers(ORCHID)を導入します。 IP層のネットワークの位置のための識別子で使用されるのではなく、終点識別子としてアプリケーションとApplication Programming Interfaces(API)でこれらの識別子が使用されることを意図します、すなわち、ロケータ。 応用層実体と、そして、既存のIPv6APIに現れるように設計されていますが、それらは実際のIPv6ヘッダーに現れるべきではありません。 バニラIPv6アドレスのようにそれらをさらに作るために、オーバレイレベルで発送可能であると予想されます。 その結果、それらはIPv6層の観点からの非発送可能アドレスであると考えられますが、すべての既存のIPv6アプリケーションが現在のIPv6アドレスとのコンパチブル方法でそれらを使用できると予想されます。
This document requests IANA to allocate a temporary prefix out of the IPv6 addressing space for Overlay Routable Cryptographic Hash Identifiers. By default, the prefix will be returned to IANA in 2014, with continued use requiring IETF consensus.
このドキュメントは、Overlay Routable Cryptographic Hash Identifiersのためにスペースを記述するIPv6から一時的な接頭語を割り当てるようIANAに要求します。 デフォルトで、継続的な使用がIETFコンセンサスを必要とすることで、2014年に接頭語をIANAに返すでしょう。
Nikander, et al. Experimental [Page 1] RFC 4843 Cryptographic Hash IDentifiers (ORCHID) April 2007
Nikander、他 細切れ肉料理識別子(ラン)2007年4月の暗号の実験的な[1ページ]RFC4843
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Rationale and Intent . . . . . . . . . . . . . . . . . . . 3 1.2. ORCHID Properties . . . . . . . . . . . . . . . . . . . . 4 1.3. Expected use of ORCHIDs . . . . . . . . . . . . . . . . . 4 1.4. Action Plan . . . . . . . . . . . . . . . . . . . . . . . 4 1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Cryptographic Hash Identifier Construction . . . . . . . . . . 5 3. Routing Considerations . . . . . . . . . . . . . . . . . . . . 6 3.1. Overlay Routing . . . . . . . . . . . . . . . . . . . . . 6 4. Collision Considerations . . . . . . . . . . . . . . . . . . . 7 5. Design Choices . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . . 11
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 原理と意図. . . . . . . . . . . . . . . . . . . 3 1.2。 ランの特性. . . . . . . . . . . . . . . . . . . . 4 1.3。 ORCHIDs. . . . . . . . . . . . . . . . . 4 1.4に使用を予想しました。 行動計画. . . . . . . . . . . . . . . . . . . . . . . 4 1.5。 用語. . . . . . . . . . . . . . . . . . . . . . . 4 2。 暗号の細切れ肉料理識別子工事. . . . . . . . . . 5 3。 問題. . . . . . . . . . . . . . . . . . . . 6 3.1を発送します。 オーバレイルート設定. . . . . . . . . . . . . . . . . . . . . 6 4。 衝突問題. . . . . . . . . . . . . . . . . . . 7 5。 選択. . . . . . . . . . . . . . . . . . . . . . . . 9 6を設計してください。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 9 7。 IANA問題. . . . . . . . . . . . . . . . . . . . . 10 8。 承認. . . . . . . . . . . . . . . . . . . . . . . 11 9。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1。 引用規格. . . . . . . . . . . . . . . . . . . 11 9.2。 有益な参照. . . . . . . . . . . . . . . . . . 11
1. Introduction
1. 序論
This document introduces Overlay Routable Cryptographic Hash Identifiers (ORCHID), a new class of IP address-like identifiers. These identifiers are intended to be globally unique in a statistical sense (see Section 4), non-routable at the IP layer, and routable at some overlay layer. The identifiers are securely bound, via a secure hash function, to the concatenation of an input bitstring and a context tag. Typically, but not necessarily, the input bitstring will include a suitably encoded public cryptographic key.
このドキュメントはOverlay Routable Cryptographic Hash Identifiers(ORCHID)、新しいクラスのIPのアドレスのような識別子を紹介します。 統計的な意味(セクション4を見る)でグローバルにユニークで、IP層で非発送可能で、これらの識別子が何らかのオーバレイ層で発送可能であることを意図します。 識別子はしっかりと縛られます、安全なハッシュ関数で、入力bitstringの連結と文脈タグに。 必ずない、しかし、通常、入力bitstringは適当にコード化された公共の暗号化キーを含むでしょう。
1.1. Rationale and Intent
1.1. 原理と意図
These identifiers are expected to be used at the existing IPv6 Application Programming Interfaces (API) and application protocols between consenting hosts. They may be defined and used in different contexts, suitable for different overlay protocols. Examples of these include Host Identity Tags (HIT) in the Host Identity Protocol (HIP) [HIP-BASE] and Temporary Mobile Identifiers (TMI) for Mobile IPv6 Privacy Extension [PRIVACYTEXT].
同意しているホストの間の既存のIPv6 Application Programming Interfaces(API)とアプリケーション・プロトコルにこれらの識別子が使用されると予想されます。 それらは、異なったオーバレイプロトコルに適した異なった文脈で定義されて、使用されるかもしれません。 これらに関する例はモバイルIPv6 Privacy Extension[PRIVACYTEXT]のためのHost Identityプロトコル(HIP)[HIP-基地]とTemporaryのモバイルIdentifiers(TMI)にHost Identity Tags(HIT)を含んでいます。
As these identifiers are expected to be used along with IPv6 addresses at both applications and APIs, co-ordination is desired to make sure that an ORCHID is not inappropriately taken for a vanilla IPv6 address and vice versa. In practice, allocation of a separate prefix for ORCHIDs seems to suffice, making them compatible with IPv6 addresses at the upper layers while simultaneously making it trivial to prevent their usage at the IP layer.
IPv6アドレスと共にアプリケーションとAPIの両方でこれらの識別子が使用されると予想されるとき、コーディネーションが、ORCHIDが不適当に逆もまた同様にバニラIPv6アドレスに連れて行かれないのを確実にすることが望まれています。 実際には、ORCHIDsのための別々の接頭語の配分は十分であるように思えます、同時にIP層でそれらの用法を防ぐのを些細にする間、それらを上側の層のIPv6アドレスと互換性があるようにして。
Nikander, et al. Experimental [Page 2] RFC 4843 Cryptographic Hash IDentifiers (ORCHID) April 2007
Nikander、他 細切れ肉料理識別子(ラン)2007年4月の暗号の実験的な[2ページ]RFC4843
While being technically possible to use ORCHIDs between consenting hosts without any co-ordination with the IETF and the IANA, the authors would consider such practice potentially dangerous. A specific danger would be realised if the IETF community later decided to use the ORCHID prefix for some different purpose. In that case, hosts using the ORCHID prefix would be, for practical purposes, unable to use the prefix for the other new purpose. That would lead to partial balkanisation of the Internet, similar to what has happened as a result of historical hijackings of non-RFC 1918 [RFC1918] IPv4 addresses for private use.
同意することの間のORCHIDsがIETFとIANAと共に少しもコーディネーションなしで主催する使用に技術的に可能である間、作者は、そのような習慣が潜在的に危険であると考えるでしょう。 IETF共同体が、後で何らかの異なる役割にORCHID接頭語を使用すると決めるなら、特定の危険はわかるでしょうに。 その場合、実用的な目的のために、ORCHID接頭語を使用しているホストはもう片方の新しい目的に接頭語を使用できないでしょう。 それはインターネットの部分的な小国分割に通じるでしょう、1918[RFC1918]の非RFC IPv4アドレスの歴史的なハイジャックの結果、私的使用目的で起こったことと同様です。
The whole need for the proposed allocation grows from the desire to be able to use ORCHIDs with existing applications and APIs. This desire leads to the potential conflict, mentioned above. Resolving the conflict requires the proposed allocation.
提案された配分の全体の必要性は既存のアプリケーションとAPIでORCHIDsを使用できる願望から成長します。 この願望は前記のように潜在的闘争に通じます。 対立を解決するのは提案された配分を必要とします。
One can argue that the desire to use these kinds of identifiers via existing APIs is architecturally wrong, and there is some truth in that argument. Indeed, it would be more desirable to introduce a new API and update all applications to use identifiers, rather than locators, via that new API. That is exactly what we expect to happen in the long run.
1つは建築上、既存のAPIを通してこれらの種類に関する識別子を使用する願望が間違って、その議論には何らかの真実があると主張できます。 本当に、ロケータよりむしろ識別子を使用するために新しいAPIを導入して、すべてのアプリケーションをアップデートするのは、より望ましいでしょう、その新しいAPIを通して。 それはまさに結局起こる私たちが予想することです。
However, given the current state of the Internet, we do not consider it viable to introduce any changes that, at once, require applications to be rewritten and host stacks to be updated. Rather than that, we believe in piece-wise architectural changes that require only one of the existing assets to be touched. ORCHIDs are designed to address this situation: to allow people to experiment with protocol stack extensions, such as secure overlay routing, HIP, or Mobile IP privacy extensions, without requiring them to update their applications. The goal is to facilitate large-scale experiments with minimum user effort.
しかしながら、インターネットの現状を考えて、私たちは、アップデートするためにすぐにアプリケーションが書き直されるのを必要とするどんな変化とホストスタックも導入するのが実行可能であると考えません。 それよりむしろ、私たちは1だけを必要とする触れられるべき既存資産の断片の建築変化を信じます。 ORCHIDsはこの状況を記述するように設計されています: 人々がプロトコルを実験するのを許容するには、彼らのアプリケーションをアップデートする必要でない、安全なオーバレイルーティング、HIP、またはモバイルIPプライバシー拡大などの拡大を積み重ねてください。 目標は最小のユーザの努力で大規模な実験を容易にすることです。
For example, there already exists, at the time of this writing, HIP implementations that run fully in user space, using the operating system to divert a certain part of the IPv6 address space to a user level daemon for HIP processing. In practical terms, these implementations are already using a certain IPv6 prefix for differentiating HIP identifiers from IPv6 addresses, allowing them both to be used by the existing applications via the existing APIs.
例えば、ユーザスペースへ完全に駆け込むHIP実現がこの書くこと時点で既に存在します、HIP処理のためにIPv6アドレス空間のある部分をユーザレベルデーモンに紛らすのにオペレーティングシステムを使用して。 実際的な言い方をするなら、これらの実現はIPv6アドレスとHIP識別子を区別するのに既にあるIPv6接頭語を使用しています、それらの両方が既存のAPIを通して既存のアプリケーションで使用されるのを許容して。
This document argues for allocating an experimental prefix for such purposes, thereby paving the way for large-scale experiments with cryptographic identifiers without the dangers caused by address-space hijacking.
このドキュメントはそのような目的のために実験接頭語を割り当てるために論争します、その結果、暗号の識別子でアドレス空間ハイジャックによって引き起こされた危険なしで大規模な実験へ道を開きます。
Nikander, et al. Experimental [Page 3] RFC 4843 Cryptographic Hash IDentifiers (ORCHID) April 2007
Nikander、他 細切れ肉料理識別子(ラン)2007年4月の暗号の実験的な[3ページ]RFC4843
1.2. ORCHID Properties
1.2. ランの特性
ORCHIDs are designed to have the following properties:
ORCHIDsは以下の特性を持つように設計されています:
o Statistical uniqueness; also see Section 4
o 統計的なユニークさ。 また、セクション4を見てください。
o Secure binding to the input parameters used in their generation (i.e., the context identifier and a bitstring).
o 入力パラメタとの安全な結合は彼らの世代に(すなわち、文脈識別子とbitstring)を使用しました。
o Aggregation under a single IPv6 prefix. Note that this is only needed due to the co-ordination need as indicated above. Without such co-ordination need, the ORCHID namespace could potentially be completely flat.
o ただ一つのIPv6接頭語の下における集合。 これがコーディネーションの必要性のため上で示されるように必要であるだけであることに注意してください。 そのようなコーディネーションの必要性がなければ、ORCHID名前空間は完全に潜在的に平坦であるかもしれません。
o Non-routability at the IP layer, by design.
o デザインはIP層で非routabilityです。
o Routability at some overlay layer, making them, from an application point of view, semantically similar to IPv6 addresses.
o いくつかのRoutabilityはアプリケーション観点からそれらを作って、IPv6アドレスと意味的に同様の層をかぶせました。
As mentioned above, ORCHIDs are intended to be generated and used in different contexts, as suitable for different mechanisms and protocols. The context identifier is meant to be used to differentiate between the different contexts; see Section 4 for a discussion of the related API and kernel level implementation issues, and Section 5 for the design choices explaining why the context identifiers are used.
以上のように、ORCHIDsは異なった文脈で発生して、使用されることを意図します、異なったメカニズムとプロトコルに適するとして。 文脈識別子は異なった文脈を区別するのに使用されることになっています。 関連するAPIとカーネルレベル導入問題の議論のためのセクション4、および文脈識別子がなぜ使用されているかがわかるデザイン選択のためのセクション5を見てください。
1.3. Expected use of ORCHIDs
1.3. ORCHIDsの予想された使用
Examples of identifiers and protocols that are expected to adopt the ORCHID format include Host Identity Tags (HIT) in the Host Identity Protocol [HIP-BASE] and the Temporary Mobile Identifiers (TMI) in the Simple Privacy Extension for Mobile IPv6 [PRIVACYTEXT]. The format is designed to be extensible to allow other experimental proposals to share the same namespace.
ORCHID形式を採用すると予想される識別子とプロトコルに関する例はHost Identityプロトコル[HIP-基地]とモバイルIPv6[PRIVACYTEXT]のためのSimple Privacy ExtensionのTemporaryのモバイルIdentifiers(TMI)にHost Identity Tags(HIT)を含んでいます。 形式は、同じ名前空間を共有するという他の実験的な提案を許すのにおいて広げることができるように設計されています。
1.4. Action Plan
1.4. 行動計画
This document requests IANA to allocate an experimental prefix out of the IPv6 addressing space for Overlay Routable Cryptographic Hash Identifiers.
このドキュメントは、Overlay Routable Cryptographic Hash Identifiersのためにスペースを記述するIPv6から実験接頭語を割り当てるようIANAに要求します。
1.5. Terminology
1.5. 用語
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 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Nikander, et al. Experimental [Page 4] RFC 4843 Cryptographic Hash IDentifiers (ORCHID) April 2007
Nikander、他 細切れ肉料理識別子(ラン)2007年4月の暗号の実験的な[4ページ]RFC4843
2. Cryptographic Hash Identifier Construction
2. 暗号の細切れ肉料理識別子工事
An ORCHID is generated using the algorithm below. The algorithm takes a bitstring and a context identifier as input and produces an ORCHID as output.
ORCHIDは、以下のアルゴリズムを使用することで発生します。 アルゴリズムは、入力されるようにbitstringと文脈識別子を取って、出力されるようにORCHIDを生産します。
Input := any bitstring Hash Input := Context ID | Input Hash := Hash_function( Hash Input ) ORCHID := Prefix | Encode_100( Hash )
入力:=はあらゆるbitstring Hash Input:=Context IDです。| 入力細切れ肉料理:=細切れ肉料理_機能(細切れ肉料理入力)ラン:=接頭語| エンコード_100(細切れ肉料理)
where:
どこ:
| : Denotes concatenation of bitstrings
| : bitstringsの連結を指示します。
Input : A bitstring that is unique or statistically unique within a given context. The bitstring is intended to be associated with the to-be-created ORCHID in the given context.
以下を入力してください。 ある与えられた状況内ではユニークであるか、または統計的にユニークなbitstring。 bitstringが与えられた文脈の作成されたORCHIDに関連させていることを意図します。
Context ID : A randomly generated value defining the expected usage context for the particular ORCHID and the hash function to be used for generation of ORCHIDs in this context. These values are allocated out of the namespace introduced for CGA Type Tags; see RFC 3972 and http://www.iana.org/assignments/cga-message-types.
文脈ID: 特定のORCHIDのための予想された用法文脈を定義する手当たりしだいに発生している値と細切れ肉料理は、ORCHIDsの世代にこのような関係においては使用されるために機能します。 CGA Type Tagsのために導入された名前空間からこれらの値を割り当てます。 RFC3972と http://www.iana.org/assignments/cga-message-types を見てください。
Hash_function : The one-way hash function (i.e., hash function with pre-image resistance and second pre-image resistance) to be used according to the document defining the context usage identified by the Context ID. For example, the current version of the HIP specification defines SHA1 [RFC3174] as the hash function to be used to generate ORCHIDs used in the HIP protocol [HIP-BASE].
細切れ肉料理_は機能します: Context IDによって特定された文脈用法を定義するドキュメントによると、使用されるべき片道ハッシュ関数(すなわち、プレイメージ抵抗と2番目のプレイメージ抵抗があるハッシュ関数)。 例えば、HIP仕様の最新版は、HIPプロトコル[HIP-基地]に使用されるORCHIDsを発生させるのに使用されるために、SHA1[RFC3174]をハッシュ関数と定義します。
Encode_100( ) : An extraction function in which output is obtained by extracting the middle 100-bit-long bitstring from the argument bitstring.
_100( )をコード化してください: どの出力に議論bitstringからの中央長さ100ビットのbitstringを抽出することによって、抽出機能を得るか。
Prefix : A constant 28-bit-long bitstring value (2001:10::/28).
以下を前に置いてください。 値(2001: 10: : /28)をbitstringする長さ28ビットの定数。
To form an ORCHID, two pieces of input data are needed. The first piece can be any bitstring, but is typically expected to contain a public cryptographic key and some other data. The second piece is a
ORCHIDを形成するために、入力データの2つの断片が必要です。 最初の断片は、どんなbitstringであることができますがも、公共の暗号化キーとある他のデータを含むと通常予想されます。 2番目の断片はaです。
Nikander, et al. Experimental [Page 5] RFC 4843 Cryptographic Hash IDentifiers (ORCHID) April 2007
Nikander、他 細切れ肉料理識別子(ラン)2007年4月の暗号の実験的な[5ページ]RFC4843
context identifier, which is a 128-bit-long datum, allocated as specified in Section 7. Each specific experiment (such as HIP HITs or MIP6 TMIs) is expected to allocate their own, specific context identifier.
文脈識別子。(その識別子はセクション7で指定されるように割り当てられた長さ128ビットのデータです)。 それぞれの特定の実験(HIP HITsかMIP6 TMIsなどの)がそれら自身のを割り当てると予想されて、特定の文脈は識別子です。
The input bitstring and context identifier are concatenated to form an input datum, which is then fed to the cryptographic hash function to be used according to the document defining the context usage identified by the Context ID. The result of the hash function is processed by an encoding function, resulting in a 100-bit-long value. This value is prepended with the 28-bit ORCHID prefix. The result is the ORCHID, a 128-bit-long bitstring that can be used at the IPv6 APIs in hosts participating to the particular experiment.
入力bitstringと文脈識別子は、入力データを形成するために連結されます。(次に、データは、Context IDによって特定された文脈用法を定義するドキュメントによると、使用されるために暗号のハッシュ関数に与えられています)。 長さ100ビットの値をもたらして、ハッシュ関数の結果はコード化機能によって処理されます。 この値は28ビットのORCHID接頭語でprependedされます。 結果はORCHID、特定の実験に参加するホストでIPv6APIで使用できる長さ128ビットのbitstringです。
The ORCHID prefix is allocated under the IPv6 global unicast address block. Hence, ORCHIDs are indistinguishable from IPv6 global unicast addresses. However, it should be noted that ORCHIDs do not conform with the IPv6 global unicast address format defined in Section 2.5.4 of [RFC4291] since they do not have a 64-bit Interface ID formatted as described in Section 2.5.1. of [RFC4291].
IPv6グローバルなユニキャストあて先ブロックの下でORCHID接頭語を割り当てます。 したがって、ORCHIDsはIPv6のグローバルなユニキャストアドレスから区別がつきません。 しかしながら、ORCHIDsが彼らがセクション2.5で[RFC4291]について.1に説明されるように64ビットのInterface IDをフォーマットさせないので.4セクション2.5[RFC4291]で定義されたIPv6のグローバルなユニキャストアドレス形式に従わないことに注意されるべきです。
3. Routing Considerations
3. ルート設定問題
ORCHIDs are designed to serve as location independent endpoint- identifiers rather than IP-layer locators. Therefore, routers MAY be configured not to forward any packets containing an ORCHID as a source or a destination address. If the destination address is an ORCHID but the source address is a valid unicast source address, routers MAY be configured to generate an ICMP Destination Unreachable, Administratively Prohibited message.
ORCHIDsは、位置としてIP-層のロケータよりむしろ独立している終点識別子に役立つように設計されています。 したがって、ルータは、ソースか送付先アドレスとしてORCHIDを含むどんなパケットも進めないように構成されるかもしれません。 送付先アドレスがORCHIDですが、ソースアドレスが有効なユニキャストソースアドレスであるなら、ルータは、ICMP Destination Unreachable(Administratively Prohibitedメッセージ)を発生させるように構成されるかもしれません。
Due to the experimental nature of ORCHIDs, router software MUST NOT include any special handling code for ORCHIDs. In other words, the non-routability property of ORCHIDs, if implemented, MUST be implemented via configuration and NOT by hardwired software code. At this time, it is RECOMMENDED that the default router configuration not handle ORCHIDs in any special way. In other words, there is no need to touch existing or new routers due to this experiment. If such a reason should later appear, for example, due to a faulty implementation leaking ORCHIDs to the IP layer, the prefix can be and should be blocked by a simple configuration rule.
ORCHIDsの実験自然のため、ルータソフトウェアは少しのORCHIDsに、特別な取り扱いコードも含んではいけません。 言い換えれば、実行されるなら、組み込まれているソフトウェアコードで実行するのではなく、構成でORCHIDsの非routabilityの特性を実行しなければなりません。 このとき、デフォルトルータ構成がどんな特別な方法でもORCHIDsを扱わないのは、RECOMMENDEDです。 言い換えれば、この実験のため存在か新しいルータに触れる必要は全くありません。 そのような理由が後で現れるべきであり、例えば、接頭語がIP層にORCHIDsを漏らす不完全な実現のためあることができて、簡単な構成規則で妨げられるなら。
3.1. Overlay Routing
3.1. オーバレイルート設定
As mentioned multiple times, ORCHIDs are designed to be non-routable at the IP layer. However, there are multiple ongoing research efforts for creating various overlay routing and resolution mechanisms for flat identifiers. For example, the Host Identity
複数の回言及されるように、ORCHIDsはIP層で非発送可能になるように設計されています。 しかしながら、平坦な識別子のための様々なオーバレイルーティングと解決メカニズムを作成するための複数の継続中の研究の努力があります。 例えば、Host Identity
Nikander, et al. Experimental [Page 6] RFC 4843 Cryptographic Hash IDentifiers (ORCHID) April 2007
Nikander、他 細切れ肉料理識別子(ラン)2007年4月の暗号の実験的な[6ページ]RFC4843
Indirection Infrastructure (Hi3) [Hi3] and Node Identity Internetworking Architecture (NodeID) [NodeID] proposals, outline ways for using a Distributed Hash Table to forward HIP packets based on the Host Identity Tag.
間接指定Infrastructure(Hi3)[Hi3]とNode Identity Internetworking Architecture(NodeID)[NodeID]提案(Host Identity Tagに基づくパケットをHIPに送るのにDistributed Hash Tableを使用するためのアウトライン方法)。
What is common to the various research proposals is that they create a new kind of resolution or routing infrastructure on top of the existing Internet routing structure. In practical terms, they allow delivery of packets based on flat, non-routable identifiers, utilising information stored in a distributed database. Usually, the database used is based on Distributed Hash Tables. This effectively creates a new routing network on top of the existing IP-based routing network, capable of routing packets that are not addressed by IP addresses but some other kind of identifiers.
様々な研究提案に共通のことは既存のインターネット・ルーティング構造の上で新しい種類の解決かルーティングインフラストラクチャを作成するということです。 実際的な言い方をするなら、彼らは分散データベースに格納された情報を利用して、平坦で、非発送可能な識別子に基づくパケットの配信を許します。 通常、使用されるデータベースはDistributed Hash Tablesに基づいています。 事実上、これは既存のIPを拠点とするルーティングネットワークの上に新しいルーティングネットワークを創設します、IPアドレスにもかかわらず、ある他の種類に関する識別子によって記述されないルーティングパケットでは、できます。
Typical benefits from overlay routing include location independence, more scalable multicast, anycast, and multihoming support than in IP, and better DoS resistance than in the vanilla Internet. The main drawback is typically an order of magnitude of slower performance, caused by an easily largish number of extra look-up or forwarding steps needed. Consequently, in most practical cases, the overlay routing system is used only during initial protocol state set-up (cf. TCP handshake), after which the communicating endpoints exchange packets directly with IP, bypassing the overlay network.
オーバレイルーティングからの典型的な利益はバニラインターネットよりIPの、そして、良いDoS抵抗より位置の独立、よりスケーラブルなマルチキャスト、anycast、およびマルチホーミングサポートを含んでいます。 通常、主な欠点は容易にやや大きい数の余分なルックアップかステップが必要とした推進で引き起こされた1桁の、より遅い性能です。 その結果、ほとんどの実用的な場合では、初期のプロトコル州のセットアップだけの間オーバレイルーティングシステムは使用されます。(Cf。 TCP握手), オーバレイネットワークを迂回させて、交信終点は直接IPとパケットを交換します。
The net result of the typical overlay routing approaches is a communication service whose basic functionality is comparable to that provided by classical IP but provides considerably better resilience that vanilla IP in dynamic networking environments. Some experiments also introduce additional functionality, such as enhanced security or ability to effectively route through several IP addressing domains.
典型的なオーバレイルーティングアプローチの最終結果は基本機能が古典的なIPによって提供されたそれに匹敵していますが、ダイナミックなネットワーク環境でそのバニラIPをかなり良い弾力に提供する通信サービスです。 また、いくつかの実験が事実上、いくつかのIPアドレス指定領域を通って発送する警備の強化か能力などの追加機能性を紹介します。
The authors expect ORCHIDs to become fully routable, via one or more overlay systems, before the end of the experiment.
作者は、ORCHIDsが実験の終わり以前1台以上のオーバレイシステムで完全に発送可能になると予想します。
4. Collision Considerations
4. 衝突問題
As noted above, the aim is that ORCHIDs are globally unique in a statistical sense. That is, given the ORCHID referring to a given entity, the probability of the same ORCHID being used to refer to another entity elsewhere in the Internet must be sufficiently low so that it can be ignored for most practical purposes. We believe that the presented design meets this goal; see Section 5.
上で述べたように、目的はORCHIDsが統計的な意味でグローバルにユニークであるということです。 すなわち、与えられた実体について言及するORCHIDを考えて、別の実体をインターネットのほかの場所と呼ぶのに使用される同じORCHIDの確率は、ほとんどの実用的な目的のためにそれを無視できるくらい十分低くなければなりません。 私たちは、提示されたデザインがこの目標を達成すると信じています。 セクション5を見てください。
Consider next the very rare case that some ORCHID happens to refer to two different entities at the same time, at two different locations in the Internet. Even in this case, the probability of this fact becoming visible (and therefore a matter of consideration) at any
次に同時間のいくらかのORCHIDがたまたま2つの異なった実体を参照する非常にまれなケースを考えてください、インターネットの2つの別の場所で。 この事実がいずれでも目に見えるように(そして、したがって、考慮の問題)なるというこの場合確率さえ
Nikander, et al. Experimental [Page 7] RFC 4843 Cryptographic Hash IDentifiers (ORCHID) April 2007
Nikander、他 細切れ肉料理識別子(ラン)2007年4月の暗号の実験的な[7ページ]RFC4843
single location in the Internet is negligible. For the vast majority of cases, the two simultaneous uses of the ORCHID will never cross each other. However, while rare, such collisions are still possible. This section gives reasonable guidelines on how to mitigate the consequences in the case that such a collision happens.
インターネットの単一の位置は取るにたらないです。 かなりの大多数に関するケースのために、ORCHIDの2つの同時の用途は互いに決して交差しないでしょう。 しかしながら、まれですが、そのような衝突はまだ可能です。 このセクションはそのような衝突が起こって、どう結果を緩和するかに関する妥当なガイドラインを与えます。
As mentioned above, ORCHIDs are expected to be used at the legacy IPv6 APIs between consenting hosts. The context ID is intended to differentiate between the various experiments, or contexts, sharing the ORCHID namespace. However, the context ID is not present in the ORCHID itself, but only in front of the input bitstring as an input to the hash function. While this may lead to certain implementation- related complications, we believe that the trade-off of allowing the hash result part of an ORCHID being longer more than pays off the cost.
以上のように、同意しているホストの間の遺産IPv6APIでORCHIDsが使用されると予想されます。 ORCHID名前空間を共有して、文脈IDが様々な実験、または文脈を区別することを意図します。 しかしながら、文脈IDは、入力としてハッシュ関数にbitstringしながら、ORCHID自身、しかし、単に入力に存在していません。 これが、ある実現関連する複雑さに通じているかもしれない間、私たちは、費用を全部支払うよりそれがさらに長いORCHIDの細切れ肉料理結果の部分を許容するトレードオフであると信じています。
Because ORCHIDs are not routable at the IP layer, in order to send packets using ORCHIDs at the API level, the sending host must have additional overlay state within the stack to determine which parameters (e.g., what locators) to use in the outgoing packet. An underlying assumption here, and a matter of fact in the proposals that the authors are aware of, is that there is an overlay protocol for setting up and maintaining this additional state. It is assumed that the state-set-up protocol carries the input bitstring, and that the resulting ORCHID-related state in the stack can be associated back with the appropriate context and state-set-up protocol.
ORCHIDsがIP層で発送可能でないので、APIレベルにORCHIDsを使用することでパケットを送って、送付ホストは出発しているパケットでどのパラメタ(例えば、何というロケータ)を使用したらよいかを決定するためにスタックの中に追加オーバレイ状態を持たなければなりません。 ここでの基本的な仮定、および作者が意識している提案における事実の問題はこの追加状態を設立して、維持するためのオーバレイプロトコルがあるということです。 州セットアッププロトコルが入力bitstringを運んで、スタックの結果として起こるORCHID関連の状態は適切な関係と州セットアッププロトコルに関連づけて戻すことができると思われます。
Even though ORCHID collisions are expected to be extremely rare, two kinds of collisions may still happen. First, it is possible that two different input bitstrings within the same context may map to the same ORCHID. In this case, the state-set-up mechanism is expected to resolve the conflict, for example, by indicating to the peer that the ORCHID in question is already in use.
ORCHID衝突が非常にまれであると予想されますが、2種類の衝突はまだ起こっているかもしれません。 まず最初に、同じ文脈の中の2の異なった入力bitstringsがORCHIDを同じくらいに写像するのは、可能です。 この場合、例えば、問題のORCHIDが既に使用中であることを同輩に示すことによって州セットアップメカニズムが対立を解決すると予想されます。
A second type of collision may happen if two input bitstrings, used in different usage contexts, map to the same ORCHID. In this case, the main confusion is about which context to use. In order to prevent these types of collisions, it is RECOMMENDED that implementations that simultaneously support multiple different contexts maintain a node-wide unified database of known ORCHIDs, and indicate a conflict if any of the mechanisms attempt to register an ORCHID that is already in use. For example, if a given ORCHID is already being used as a HIT in HIP, it cannot simultaneously be used as a TMI in Mobile IP. Instead, if Mobile IP attempts to use the ORCHID, it will be notified (by the kernel) that the ORCHID in question is already in use.
2がbitstringsを入力したなら、2番目のタイプの衝突は起こるかもしれません、異なった用法文脈(同じORCHIDへの地図)では、使用されています。 この場合、主な混乱はどの文脈を使用したらよいかに関するものです。 これらのタイプの衝突を防ぐために、同時に複数の異なった文脈を支持する実現が知られているORCHIDsのノード全体の統一されたデータベースを維持して、もしあれば既に使用中のORCHIDを登録するメカニズム試みの闘争を示すのは、RECOMMENDEDです。 例えば、与えられたORCHIDがHITとしてHIPで既に使用されているなら、同時に、TMIとしてモバイルIPにそれを使用できません。 代わりに、モバイルIPが、ORCHIDを使用するのを試みると、それは問題のORCHIDが既に使用中であるように通知されるでしょう(カーネルで)。
Nikander, et al. Experimental [Page 8] RFC 4843 Cryptographic Hash IDentifiers (ORCHID) April 2007
Nikander、他 細切れ肉料理識別子(ラン)2007年4月の暗号の実験的な[8ページ]RFC4843
5. Design Choices
5. デザイン選択
The design of this namespace faces two competing forces:
この名前空間のデザインは2つの競争している力に直面しています:
o As many bits as possible should be preserved for the hash result.
o できるだけ多くのビットが細切れ肉料理結果のために保存されるべきです。
o It should be possible to share the namespace between multiple mechanisms.
o 複数のメカニズムの間の名前空間を共有するのは可能であるべきです。
The desire to have a long hash result requires that the prefix be as short as possible, and use few (if any) bits for additional encoding. The present design takes this desire to the maxim: all the bits beyond the prefix are used as hash output. This leaves no bits in the ORCHID itself available for identifying the context. Additionally, due to security considerations, the present design REQUIRES that the hash function used in constructing ORCHIDs be constant; see Section 6.
長い細切れ肉料理結果を持つ願望は、接頭語ができるだけ短く、追加コード化に(もしあれば)数ビットしか使用しないのを必要とします。 現在のデザインはこの願望を格言に取ります: 接頭語を超えたすべてのビットが細切れ肉料理出力として使用されます。 これはORCHID自身のビットを全く文脈を特定するのに利用可能な状態でおきません。 さらに定数はセキュリティ問題、ハッシュ関数がORCHIDsを組み立てる際に使用した現在のデザインREQUIRESのためにです セクション6を見てください。
The authors explicitly considered including a hash-extension mechanism, similar to the one in CGA [RFC3972], but decided to leave it out. There were two reasons: desire for simplicity, and the somewhat unclear IPR situation around the hash-extension mechanism. If there is a future revision of this document, we strongly advise the future authors to reconsider the decision.
作者は、CGA[RFC3972]のものと同様の細切れ肉料理拡大メカニズムを含んでいると明らかに考えましたが、それを省くと決めました。 2つの理由がありました: 簡単さに関する願望、および細切れ肉料理拡大メカニズムの周りのいくらか不明瞭なIPR状況。 このドキュメントの今後の改正があれば、私たちは、将来の作者が決定を再考するように強くアドバイスします。
The desire to allow multiple mechanisms to share the namespace has been resolved by including the context identifier in the hash- function input. While this does not allow the mechanism to be directly inferred from a ORCHID, it allows one to verify that a given input bitstring and ORCHID belong to a given context, with high- probability; but also see Section 6.
細切れ肉料理関数入力に文脈識別子を含んでいることによって、複数のメカニズムが名前空間を共有するのを許容する願望を取り除いてあります。 これは、メカニズムがORCHIDから直接推論されるのを許容しませんが、人は、それで与えられた入力bitstringとORCHIDが与えられた文脈に属すことを確かめることができます、高い確率で。 しかし、また、セクション6を見てください。
6. Security Considerations
6. セキュリティ問題
ORCHIDs are designed to be securely bound to the Context ID and the bitstring used as the input parameters during their generation. To provide this property, the ORCHID generation algorithm relies on the second-preimage resistance (a.k.a. one-way) property of the hash function used in the generation [RFC4270]. To have this property and to avoid collisions, it is important that the allocated prefix is as short as possible, leaving as many bits as possible for the hash output.
ORCHIDsは、しっかりと彼らの世代の間に入力パラメタとして使用されるContext IDとbitstringに縛られるように設計されています。 この特性、ORCHID世代を提供するために、アルゴリズムが2番目-「前-イメージ」抵抗に依存する、(別名、片道、)、ハッシュ関数の特性は世代に[RFC4270]を使用しました。 この特性を持って、衝突を避けるために、割り当てられた接頭語ができるだけ短いのは、重要です、できるだけ細切れ肉料理において多くのビットを出力に残して。
For a given Context ID, all mechanisms using ORCHIDs MUST use exactly the same mechanism for generating an ORCHID from the input bitstring. Allowing different mechanisms, without explicitly encoding the mechanism in the Context ID or the ORCHID itself, would allow so- called bidding-down attacks. That is, if multiple different hash
与えられたContext IDに関しては、ORCHIDsを使用するすべてのメカニズムが、入力bitstringからORCHIDを発生させるのにまさに同じメカニズムを使用しなければなりません。 Context IDで明らかにメカニズムをコード化しないで異なったメカニズムを許容するか、ORCHID自身が下にそのように呼ばれた入札に攻撃を許すでしょう。 複数の異なった細切れ肉料理であるなら、それはそうです。
Nikander, et al. Experimental [Page 9] RFC 4843 Cryptographic Hash IDentifiers (ORCHID) April 2007
Nikander、他 細切れ肉料理識別子(ラン)2007年4月の暗号の実験的な[9ページ]RFC4843
functions were allowed to construct ORCHIDs valid for the same Context ID, and if one of the hash functions became insecure, that would allow attacks against even those ORCHIDs valid for the same Context ID that had been constructed using the other, still secure hash functions.
機能は同じContext IDに、有効なORCHIDsを組み立てることができました、そして、ハッシュ関数の1つが不安定になるなら、それはもう片方、それでも安全なハッシュ関数を使用することで組み立てられた同じContext IDに、有効なそれらのORCHIDsに対してさえ攻撃を許すでしょうに。
Due to the desire to keep the hash output value as long as possible, the hash function is not encoded in the ORCHID itself, but rather in the Context ID. Therefore, the present design allows only one method per given Context ID for constructing ORCHIDs from input bitstrings. If other methods (perhaps using more secure hash functions) are later needed, they MUST use a different Context ID. Consequently, the suggested method to react to the hash result becoming too short, due to increased computational power, or to the used hash function becoming insecure due to advances in cryptology, is to allocate a new Context ID and cease to use the present one.
細切れ肉料理出力価値をできるだけ長く保つ願望のため、ハッシュ関数はORCHID自身、しかし、むしろContext IDでコード化されません。 したがって、現在のデザインは、入力bitstringsからORCHIDsを組み立てるために与えられたContext IDあたり1つの方法だけを許容します。 他の方法(恐らく、より安全なハッシュ関数を使用する)が後で必要であるなら、それらは異なったContext IDを使用しなければなりません。 その結果、増加するコンピュータのパワー、または、不安定になる中古のハッシュ関数に短くなり過ぎる細切れ肉料理結果に反応する提案された方法は、暗号理論で進んで、新しいContext IDを割り当てて、現在のものを使用するのをやめることです。
As of today, SHA1 [RFC3174] is considered as satisfying the second- preimage resistance requirement. The current version of the HIP specification defines SHA1 [RFC3174] as the hash function to be used to generate ORCHIDs for the Context ID used by the HIP protocol [HIP-BASE].
今日現在、SHA1[RFC3174]は2番目の「前-イメージ」抵抗要件を満たすと考えられます。 HIP仕様の最新版は、HIPプロトコル[HIP-基地]によって使用されるContext IDにORCHIDsを発生させるのに使用されるために、SHA1[RFC3174]をハッシュ関数と定義します。
In order to preserve a low enough probability of collisions (see Section 4), each method MUST utilize a mechanism that makes sure that the distinct input bitstrings are either unique or statistically unique within that context. There are several possible methods to ensure this; for example, one can include into the input bitstring a globally maintained counter value, a pseudo-random number of sufficient entropy (minimum 100 bits), or a randomly generated public cryptographic key. The Context ID makes sure that input bitstrings from different contexts never overlap. These together make sure that the probability of collisions is determined only by the probability of natural collisions in the hash space and is not increased by a possibility of colliding input bitstrings.
衝突(セクション4を見る)の十分低い確率を保存するために、各方法は異なった入力bitstringsが確実にユニークであるかその文脈の中で統計的にユニークになるようにするメカニズムを利用しなければなりません。 これを確実にするいくつかの可能な方法があります。 例えば、1つはグローバルに維持された対価をbitstringするか、十分なエントロピー(最小の100ビット)の擬似乱数、または手当たりしだいに発生している公共の暗号化キーを入力に含むことができます。 Context IDは、異なった文脈からの入力bitstringsが決して重ならないのを確実にします。 これら、一緒にいる、衝突の確率は単に細切れ肉料理スペースの自然な衝突の確率に従って断固として、衝突する入力がbitstringsされる可能性によって増加させられないのを確実にしてください。
7. IANA Considerations
7. IANA問題
IANA allocated a temporary non-routable 28-bit prefix from the IPv6 address space. By default, the prefix will be returned to IANA in 2014, continued use requiring IETF consensus. As per [RFC4773], the 28-bit prefix was drawn out of the IANA Special Purpose Address Block, namely 2001:0000::/23, in support of the experimental usage described in this document. IANA has updated the IPv6 Special Purpose Address Registry.
IANAはIPv6アドレス空間から一時的な非発送可能28ビットの接頭語を割り当てました。 デフォルトで、継続的な使用がIETFコンセンサスを必要とする場合、2014年に接頭語をIANAに返すでしょう。 すなわち、[RFC4773]に従って28ビットの接頭語がIANA Special Purpose Address Blockで描かれた、2001:0000、:、:本書では説明された実験用法を支持した/23。 IANAはIPv6 Special Purpose Address Registryをアップデートしました。
Nikander, et al. Experimental [Page 10] RFC 4843 Cryptographic Hash IDentifiers (ORCHID) April 2007
Nikander、他 細切れ肉料理識別子(ラン)2007年4月の暗号の実験的な[10ページ]RFC4843
During the discussions related to this document, it was suggested that other identifier spaces may be allocated from this block later. However, this document does not define such a policy or allocations.
このドキュメントに関連する議論の間、他の識別子空間が後でこのブロックから割り当てられるかもしれないことが提案されました。 しかしながら、このドキュメントはそのような方針か配分を定義しません。
The Context Identifier (or Context ID) is a randomly generated value defining the usage context of an ORCHID and the hash function to be used for generation of ORCHIDs in this context. This document defines no specific value.
Context Identifier(または、Context ID)はORCHIDsの世代にこのような関係においては使用されるためにORCHIDの用法文脈とハッシュ関数を定義する手当たりしだいに発生している値です。 このドキュメントはどんな特定の値も定義しません。
We propose sharing the name space introduced for CGA Type Tags. Hence, defining new values would follow the rules of Section 8 of [RFC3972], i.e., on a First Come First Served basis.
私たちは、CGA Type Tagsのために導入された名前スペースを共有するよう提案します。 したがって、新しい値を定義すると、[RFC3972]のセクション8の規則は従われるでしょう、すなわち、First Come First Servedベースで。
8. Acknowledgments
8. 承認
Special thanks to Geoff Huston for his sharp but constructive critique during the development of this memo. Tom Henderson helped to clarify a number of issues. This document has also been improved by reviews, comments, and discussions originating from the IPv6, Internet Area, and IETF communities.
彼の鋭い、しかし、建設的な批評のためのジェフ・ヒューストンのおかげで、このメモの開発の間、特別です。 トム・ヘンダーソンは、多くの問題をはっきりさせるのを助けました。 また、このドキュメントはIPv6、インターネットArea、およびIETF共同体から発するレビュー、コメント、および議論で改良されました。
Julien Laganier is partly funded by Ambient Networks, a research project supported by the European Commission under its Sixth Framework Program. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the Ambient Networks project or the European Commission.
ジュリアンLaganierはAmbient Networks(Sixth Framework Programの下で欧州委員会によって支持された研究計画)によって一部資金を供給されます。 ここに含まれた視点と結論を、作者のものであり、必ず言い表されるか、または含意された公式方針か裏書きを表しながら、Ambient Networksプロジェクトか欧州委員会について解釈するべきではありません。
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月。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[RFC3972]香気(T.)が「暗号で、アドレス(CGA)を作った」、RFC3972、3月2005日
9.2. Informative References
9.2. 有益な参照
[HIP-BASE] Moskowitz, R., "Host Identity Protocol", Work in Progress, February 2007.
[クールなベースの] マスコウィッツ、R.、「ホストアイデンティティプロトコル」が進歩、2007年2月に働いています。
[Hi3] Nikander, P., Arkko, J., and B. Ohlman, "Host Identity Indirection Infrastructure (Hi3)", November 2004.
[Hi3]Nikander、P.、Arkko、J.、およびB.Ohlman、「ホストアイデンティティ間接指定インフラストラクチャ(Hi3)」、2004年11月。
Nikander, et al. Experimental [Page 11] RFC 4843 Cryptographic Hash IDentifiers (ORCHID) April 2007
Nikander、他 細切れ肉料理識別子(ラン)2007年4月の暗号の実験的な[11ページ]RFC4843
[NodeID] Ahlgren, B., Arkko, J., Eggert, L., and J. Rajahalme, "A Node Identity Internetworking Architecture (NodeID)", April 2006.
[NodeID]Ahlgren、B.、Arkko、J.、エッゲルト、L.、およびJ.Rajahalme、「ノードアイデンティティインターネットワーキング構造(NodeID)」、2006年4月。
[PRIVACYTEXT] Dupont, F., "A Simple Privacy Extension for Mobile IPv6", Work in Progress, July 2006.
[PRIVACYTEXT] デュポン、F.、「モバイルIPv6"、処理中の作業、2006年7月のための簡単なプライバシー拡大。」
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]RekhterとY.とマスコウィッツとR.とKarrenbergとD.とグルート、G.とE.リア、「個人的なインターネットのためのアドレス配分」BCP5、RFC1918(1996年2月)。
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[RFC3174]イーストレークとD.とP.ジョーンズ、「米国安全な細切れ肉料理アルゴリズム1(SHA1)」、RFC3174 2001年9月。
[RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005.
[RFC4270] ホフマンとP.とB.シュナイアー、「暗号に対する攻撃はインターネットでプロトコルを論じ尽くす」RFC4270、2005年11月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC4291、2006年2月。
[RFC4773] Huston, G., "Administration of the IANA Special Purpose IPv6 Address Block", RFC 4773, December 2006.
[RFC4773] ヒューストン、G.、「IANA専用IPv6あて先ブロック政権」、RFC4773、2006年12月。
Nikander, et al. Experimental [Page 12] RFC 4843 Cryptographic Hash IDentifiers (ORCHID) April 2007
Nikander、他 細切れ肉料理識別子(ラン)2007年4月の暗号の実験的な[12ページ]RFC4843
Authors' Addresses
作者のアドレス
Pekka Nikander Ericsson Research Nomadic Lab JORVAS FI-02420 Finland
ペッカNikanderエリクソンの研究の遊牧民的な研究室JORVAS FI-02420フィンランド
Phone: +358 9 299 1 EMail: pekka.nikander@nomadiclab.com
以下に電話をしてください。 +358 9 299 1 メール: pekka.nikander@nomadiclab.com
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
以下に電話をしてください。 +49 89 56824 231メール: julien.ietf@laposte.net
Francis Dupont CELAR
フランシスデュポンCELAR
EMail: Francis.Dupont@fdupont.fr
メール: Francis.Dupont@fdupont.fr
Nikander, et al. Experimental [Page 13] RFC 4843 Cryptographic Hash IDentifiers (ORCHID) April 2007
Nikander、他 細切れ肉料理識別子(ラン)2007年4月の暗号の実験的な[13ページ]RFC4843
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
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に情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Nikander, et al. Experimental [Page 14]
Nikander、他 実験的[14ページ]
一覧
スポンサーリンク