[要約] RFC 4843は、ORCHID（Overlay Routable Cryptographic Hash Identifiers）のためのIPv6プレフィックスに関する規格です。その目的は、ORCHIDを使用してIPv6ネットワーク上で一意の識別子を生成し、セキュリティとプライバシーを向上させることです。
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
An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)
オーバーレイ可能なルーティング可能な暗号化ハッシュ識別子（ORCHID）の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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準も規定していません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
Copyright（C）IETF Trust（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アドレスのような識別子の新しい実験的なクラスとして、オーバーレイルーティング可能な暗号化ハッシュ識別子（ORCHID）を紹介します。これらの識別子は、アプリケーションおよびアプリケーションプログラミングインターフェース（API）でのエンドポイント識別子として使用することを目的としており、IPレイヤーでのネットワークロケーション、つまりロケーターの識別子としては使用されません。これらは、アプリケーションレイヤーエンティティとして、および既存のIPv6 APIで表示されるように設計されていますが、実際の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.
このドキュメントは、オーバーレイルーティング可能な暗号化ハッシュ識別子のIPv6アドレス空間から一時的なプレフィックスを割り当てるようIANAに要求します。デフォルトでは、プレフィックスは2014年にIANAに返され、継続して使用するにはIETFの合意が必要です。
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
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.
このドキュメントでは、IPアドレスのような識別子の新しいクラスであるオーバーレイルーティング可能な暗号化ハッシュ識別子（ORCHID）を紹介します。これらの識別子は、統計的な意味でグローバルに一意であるように意図され（セクション4を参照）、IP層でルーティングできず、一部のオーバーレイ層でルーティングできます。識別子は、安全なハッシュ関数を介して、入力ビット文字列とコンテキストタグの連結に安全にバインドされます。通常、必須ではありませんが、入力ビット文字列には、適切にエンコードされた公開暗号キーが含まれます。
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アプリケーションプログラミングインターフェイス（API）および同意ホスト間のアプリケーションプロトコルで使用されることが期待されています。それらは、異なるオーバーレイプロトコルに適した異なるコンテキストで定義および使用できます。これらの例には、ホストアイデンティティプロトコル（HIP）のホストアイデンティティタグ（HIT）[HIP-BASE]や、モバイルIPv6プライバシー拡張の一時モバイル識別子（TMI）[PRIVACYTEXT]が含まれます。
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.
これらの識別子は、アプリケーションとAPIの両方でIPv6アドレスと一緒に使用されることが予想されるため、ORCHIDが一般的なIPv6アドレスに対して不適切に取得されたり、その逆が行われたりしないように調整することが望まれます。実際には、ORCHIDに個別のプレフィックスを割り当てるだけで十分であるように思われ、上位層のIPv6アドレスと互換性を持たせると同時に、IP層での使用を防ぐのは簡単です。
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.
IETFとIANAとの調整なしに同意ホスト間でORCHIDを使用することは技術的に可能ですが、著者はそのような行為は潜在的に危険であると考えます。 IETFコミュニティが後にORCHIDプレフィックスを別の目的で使用することを決定した場合、特定の危険が認識されます。その場合、ORCHIDプレフィックスを使用するホストは、実用的な目的で、他の新しい目的にプレフィックスを使用できなくなります。それは、非RFC 1918 [RFC1918] 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でORCHIDを使用できるようにしたいという願望から高まっています。この願望は、前述の潜在的な対立につながります。競合を解決するには、提案された割り当てが必要です。
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.
既存の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つだけに手を加える必要がある断片的なアーキテクチャーの変更を信じています。 ORCHIDは、この状況に対処するように設計されています。アプリケーションを更新しなくても、セキュアオーバーレイルーティング、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.
たとえば、この記事の執筆時点では、オペレーティングシステムを使用してIPv6アドレス空間の特定の部分をHIP処理用のユーザーレベルデーモンに転送するために、ユーザー空間で完全に実行されるHIP実装が既に存在します。実際には、これらの実装はすでに特定のIPv6プレフィックスを使用して、IPv6アドレスとHIP識別子を区別しているため、既存の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.
このドキュメントは、そのような目的で実験的なプレフィックスを割り当てることで、アドレス空間のハイジャックによる危険を伴うことなく、暗号識別子による大規模な実験の道を開くことを主張しています。
ORCHIDs are designed to have the following properties:
ORCHIDは、次のプロパティを持つように設計されています。
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 生成で使用された入力パラメーター（つまり、コンテキスト識別子とビット文字列）への安全なバインディング。
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レイヤーでのルーティング不可。
o Routability at some overlay layer, making them, from an application point of view, semantically similar to IPv6 addresses.
o 一部のオーバーレイ層でのルーティング可能性。アプリケーションの観点からは、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.
上記のように、ORCHIDは、さまざまなメカニズムやプロトコルに適した、さまざまなコンテキストで生成および使用されることを目的としています。コンテキスト識別子は、異なるコンテキストを区別するために使用されることを意図しています。関連するAPIとカーネルレベルの実装の問題についてはセクション4を、コンテキスト識別子が使用される理由を説明する設計の選択についてはセクション5を参照してください。
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形式を採用すると予想される識別子とプロトコルの例には、ホストアイデンティティプロトコル（HIP-BASE）のホストアイデンティティタグ（HIT）とモバイルIPv6のシンプルプライバシー拡張[PRIVACYTEXT]の一時モバイル識別子（TMI）が含まれます。このフォーマットは、他の実験的な提案が同じ名前空間を共有できるように拡張できるように設計されています。
This document requests IANA to allocate an experimental prefix out of the IPv6 addressing space for Overlay Routable Cryptographic Hash Identifiers.
このドキュメントでは、IANAに、ルーティング可能な暗号化ハッシュ識別子をオーバーレイするためのIPv6アドレス空間から実験的なプレフィックスを割り当てるように要求しています。
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」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
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は、以下のアルゴリズムを使用して生成されます。このアルゴリズムは、ビット文字列とコンテキスト識別子を入力として受け取り、ORCHIDを出力として生成します。
Input := any bitstring
Hash Input := Context ID | Input
Hash := Hash_function( Hash Input )
ORCHID := Prefix | Encode_100( Hash )
where:
ただし：
| : Denotes concatenation of 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.
入力：特定のコンテキスト内で一意または統計的に一意のビット文字列。ビット文字列は、特定のコンテキストで作成される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の予想される使用コンテキストを定義するランダムに生成された値と、このコンテキストでORCHIDの生成に使用されるハッシュ関数。これらの値は、CGAタイプタグに導入された名前空間から割り当てられます。 RFC 3972および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].
Hash_function：コンテキストIDで識別されるコンテキストの使用法を定義するドキュメントに従って使用される、一方向のハッシュ関数（つまり、プリイメージ耐性と2番目のプリイメージ耐性を持つハッシュ関数）。たとえば、HIP仕様の現在のバージョンでは、SHA1 [RFC3174]を、HIPプロトコル[HIP-BASE]で使用されるORCHIDを生成するために使用されるハッシュ関数として定義しています。
Encode_100( ) : An extraction function in which output is obtained by extracting the middle 100-bit-long bitstring from the argument bitstring.
Encode_100()：引数のビット文字列から中央の100ビット長のビット文字列を抽出して出力を取得する抽出関数。
Prefix : A constant 28-bit-long bitstring value (2001:10::/28).
プレフィックス：28ビット長の定数ビット文字列値（2001：10 :: / 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 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.
ORCHIDを作成するには、2つの入力データが必要です。最初の部分は任意のビット文字列にすることができますが、通常は公開暗号鍵とその他のデータが含まれていることが予想されます。 2番目の部分はコンテキスト識別子であり、セクション7の指定に従って割り当てられた128ビット長のデータです。各特定の実験（HIP HITやMIP6 TMIなど）は、独自の特定のコンテキスト識別子を割り当てることが期待されています。
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.
入力ビット文字列とコンテキスト識別子は連結されて入力データムを形成します。これは、暗号ハッシュ関数に送られ、コンテキストIDで識別されるコンテキストの使用法を定義するドキュメントに従って使用されます。ハッシュ関数の結果は、エンコード関数によって処理され、100ビット長の値になります。この値には、28ビットのORCHIDプレフィックスが付加されます。結果は、特定の実験に参加しているホストのIPv6 APIで使用できる128ビット長のビット文字列であるORCHIDです。
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].
ORCHIDプレフィックスは、IPv6グローバルユニキャストアドレスブロックの下に割り当てられます。したがって、ORCHIDはIPv6グローバルユニキャストアドレスと区別できません。ただし、ORCHIDは[RFC4291]のセクション2.5.4で定義されているIPv6グローバルユニキャストアドレス形式に準拠していないことに注意してください。これは、セクション2.5.1で説明されているようにフォーマットされた64ビットのインターフェースIDがないためです。 [RFC4291]の。
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.
ORCHIDは、IPレイヤーロケーターではなく、場所に依存しないエンドポイント識別子として機能するように設計されています。したがって、ルーターは、送信元または宛先アドレスとしてORCHIDを含むパケットを転送しないように構成できます。宛先アドレスがORCHIDであるが、送信元アドレスが有効なユニキャスト送信元アドレスである場合、ICMP宛先到達不能、管理上禁止のメッセージを生成するようにルーターを構成できます（MAY）。
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.
ORCHIDの実験的な性質により、ルーターソフトウェアにはORCHIDの特別な処理コードを含めてはなりません。言い換えると、ORCHIDの非ルーティングプロパティは、実装されている場合、ハードワイヤードソフトウェアコードではなく、構成を介して実装する必要があります。現時点では、デフォルトのルーター構成で特別な方法でORCHIDを処理しないことをお勧めします。つまり、この実験により、既存または新しいルーターに触れる必要はありません。 ORCHIDがIP層にリークしている実装の欠陥などが原因で、このような理由が後で発生する場合、プレフィックスは単純な構成ルールによってブロックされる可能性があり、ブロックされる必要があります。
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 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.
複数回言及されているように、ORCHIDはIP層でルーティングできないように設計されています。ただし、フラット識別子のさまざまなオーバーレイルーティングおよび解決メカニズムを作成するために、現在進行中の研究が複数あります。たとえば、ホストアイデンティティインダイレクションインフラストラクチャ（Hi3）[Hi3]およびノードアイデンティティインターネットワーキングアーキテクチャ（NodeID）[NodeID]の提案では、分散ハッシュテーブルを使用して、ホストアイデンティティタグに基づいてHIPパケットを転送する方法の概要を説明しています。
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.
さまざまな研究提案に共通するのは、既存のインターネットルーティング構造の上に新しい種類の解決またはルーティングインフラストラクチャを作成することです。実際には、分散データベースに格納されている情報を利用して、フラットでルーティングできない識別子に基づいてパケットを配信できます。通常、使用されるデータベースは分散ハッシュテーブルに基づいています。これにより、既存の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耐性があります。主な欠点は、通常、パフォーマンスが大幅に低下することです。これは、必要な追加のルックアップまたは転送手順が簡単に大量に発生するためです。その結果、ほとんどの実際的なケースでは、オーバーレイルーティングシステムは、プロトコル状態の初期設定（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.
著者らは、実験が終了する前に、1つ以上のオーバーレイシステムを介してORCHIDが完全にルーティング可能になることを期待しています。
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.
上記のように、ORCHIDは統計的な意味でグローバルに一意であることが目的です。つまり、特定のエンティティを参照する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 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つの異なる場所で同時に2つの異なるエンティティを参照するという非常にまれなケースについて考えます。この場合でも、インターネットの単一の場所でこの事実が見えるようになる（したがって、検討事項になる）可能性は無視できます。ほとんどの場合、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.
上記のように、ORCHIDは同意ホスト間のレガシーIPv6 APIで使用されることが期待されています。コンテキストIDは、ORCHID名前空間を共有するさまざまな実験またはコンテキストを区別することを目的としています。ただし、コンテキストIDは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.
ORCHIDはIP層でルーティングできないため、APIレベルでORCHIDを使用してパケットを送信するには、送信側ホストがスタック内に追加のオーバーレイ状態を持たせて、送信パケットで使用するパラメーター（ロケーターなど）を決定する必要があります。ここでの根本的な仮定、および作成者が認識している提案の実際の問題は、この追加の状態を設定および維持するためのオーバーレイプロトコルがあることです。状態設定プロトコルは入力ビット文字列を伝送し、スタック内の結果として生じる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つの異なる入力ビット文字列が同じ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つ目のタイプの衝突は、異なる使用状況で使用される2つの入力ビット文字列が同じORCHIDにマッピングされる場合に発生する可能性があります。この場合、主な混乱は、どのコンテキストを使用するかです。これらのタイプの衝突を防ぐために、複数の異なるコンテキストを同時にサポートする実装が既知のORCHIDのノード全体の統合データベースを維持し、いずれかのメカニズムがすでに使用されているORCHIDを登録しようとした場合に競合を示すことが推奨されます。たとえば、特定のORCHIDがHIPのHITとしてすでに使用されている場合、モバイルIPのTMIとして同時に使用することはできません。代わりに、モバイルIPがORCHIDを使用しようとすると、問題のORCHIDがすでに使用されていることが（カーネルによって）通知されます。
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自体にビットが残りません。さらに、セキュリティ上の理由から、現在の設計では、ORCHIDの構築に使用されるハッシュ関数が一定である必要があります。セクション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から直接推論することはできませんが、特定の入力ビット文字列とORCHIDが特定のコンテキストに属していることを高い確率で確認できます。セクション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.
ORCHIDは、コンテキストIDおよび生成時に入力パラメーターとして使用されるビット文字列に安全にバインドされるように設計されています。このプロパティを提供するために、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 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.
特定のコンテキストIDについて、ORCHIDを使用するすべてのメカニズムは、入力ビット文字列からORCHIDを生成するためにまったく同じメカニズムを使用する必要があります。メカニズムをコンテキストIDまたはORCHID自体に明示的にエンコードせずにさまざまなメカニズムを許可すると、いわゆるビッドダウン攻撃が可能になります。つまり、複数の異なるハッシュ関数が同じコンテキストIDに対して有効なORCHIDを構築することが許可され、ハッシュ関数の1つが安全でなくなった場合、同じコンテキストIDに対して有効なORCHIDに対しても、他の、まだ安全なハッシュ関数。
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自体ではなく、コンテキストIDでエンコードされます。したがって、現在の設計では、入力ビット文字列からORCHIDを構築するために、特定のコンテキストIDごとに1つのメソッドしか使用できません。他の方法（おそらくより安全なハッシュ関数を使用する）が後で必要になった場合は、別のコンテキストIDを使用する必要があります。したがって、計算能力の向上によりハッシュ結果が短くなりすぎたり、暗号化の進歩により使用されているハッシュ関数が安全でなくなったりすることに対応するための提案された方法は、新しいコンテキストIDを割り当て、現在のコンテキスト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仕様の現在のバージョンでは、SHA1 [RFC3174]が、HIPプロトコル[HIP-BASE]で使用されるコンテキストIDのORCHIDを生成するために使用されるハッシュ関数として定義されています。
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を参照）を維持するために、各メソッドは、そのコンテキスト内で個別の入力ビット文字列が一意または統計的に一意であることを確認するメカニズムを使用する必要があります。これを確実にする方法はいくつかあります。たとえば、グローバルに維持されるカウンター値、十分なエントロピーの疑似乱数（最小100ビット）、またはランダムに生成された公開暗号鍵を入力ビット文字列に含めることができます。コンテキストIDは、異なるコンテキストからの入力ビット文字列が重複しないようにします。これらにより、衝突の確率はハッシュ空間での自然な衝突の確率によってのみ決定され、入力ビット文字列が衝突する可能性によって増加することはありません。
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ビットのプレフィックスを割り当てました。デフォルトでは、プレフィックスは2014年にIANAに返されるため、引き続き使用するにはIETFの合意が必要です。 [RFC4773]によると、28ビットプレフィックスは、このドキュメントで説明されている実験的な使用法をサポートするために、IANA特別目的アドレスブロック、つまり2001：0000 :: / 23から引き出されました。 IANAはIPv6 Special Purpose Address Registryを更新しました。
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.
コンテキスト識別子（またはコンテキストID）は、ランダムに生成された値で、ORCHIDの使用コンテキストと、このコンテキストでの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タイプタグに導入された名前空間の共有を提案します。したがって、新しい値の定義は、[RFC3972]のセクション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.
このメモの作成中に鋭くて建設的な批評をしてくれたGeoff Hustonに特に感謝します。トムヘンダーソンは、多くの問題を明確にするのに役立ちました。このドキュメントは、IPv6、インターネットエリア、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.
ジュリアンラガニエは、第6回フレームワークプログラムに基づいて欧州委員会が支援する研究プロジェクトであるアンビエントネットワークスから資金提供を受けています。ここに含まれている見解と結論は著者の見解と結論であり、Ambient Networksプロジェクトまたは欧州委員会の公式のポリシーまたは承認を、明示または暗示を問わず、必ずしも表すものと解釈すべきではありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[RFC3972] Aura、T。、「Cryptographically Generated Addresses（CGA）」、RFC 3972、2005年3月。
[HIP-BASE] Moskowitz, R., "Host Identity Protocol", Work in Progress, February 2007.
[HIP-BASE] Moskowitz、R。、「Host Identity Protocol」、Work in Progress、2007年2月。
[Hi3] Nikander, P., Arkko, J., and B. Ohlman, "Host Identity Indirection Infrastructure (Hi3)", November 2004.
[Hi3] Nikander、P.、Arkko、J。、およびB. Ohlman、「Host Identity Indirection Infrastructure（Hi3）」、2004年11月。
[NodeID] Ahlgren, B., Arkko, J., Eggert, L., and J. Rajahalme, "A Node Identity Internetworking Architecture (NodeID)", April 2006.
[NodeID] Ahlgren、B.、Arkko、J.、Eggert、L。、およびJ. Rajahalme、「A Node Identity Internetworking Architecture（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.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[RFC3174] Eastlake、D。およびP. Jones、「US Secure Hash Algorithm 1（SHA1）」、RFC 3174、2001年9月。
[RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005.
[RFC4270] Hoffman、P.およびB. Schneier、「インターネットプロトコルにおける暗号化ハッシュへの攻撃」、RFC 4270、2005年11月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、2006年2月。
[RFC4773] Huston, G., "Administration of the IANA Special Purpose IPv6 Address Block", RFC 4773, December 2006.
[RFC4773] Huston、G。、「Administration of the IANA Special Purpose IPv6 Address Block」、RFC 4773、2006年12月。
Authors' Addresses
著者のアドレス
Pekka Nikander Ericsson Research Nomadic Lab JORVAS FI-02420 Finland
Pekka Nikander Ericsson Research遊牧研究所JORVAS FI-02420フィンランド
Phone: +358 9 299 1
EMail: pekka.nikander@nomadiclab.com
Julien Laganier DoCoMo Communications Laboratories Europe GmbH Landsberger Strasse 312 Munich 80687 Germany
Julien Laganier DoCoMo Communications Laboratories Europe GmbH Landsberger Strasse 312ミュンヘン80687ドイツ
Phone: +49 89 56824 231
EMail: julien.ietf@laposte.net
Francis Dupont CELAR
フランシス・デュポンCELAR
EMail: Francis.Dupont@fdupont.fr
Full Copyright Statement
完全な著作権表示
Copyright (C) The IETF Trust (2007).
Copyright（C）IETF Trust（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.
このドキュメントは、BCP 78に含まれる権利、ライセンス、および制限の対象であり、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または（もしあれば）組織、インターネット社会、IETFトラスト、およびインターネットエンジニアリングタスクフォースはすべてを否認します。明示または黙示を問わず、ここに含まれる情報の使用が商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害しないことを保証するものではありません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に対して行われたIPR開示のコピー、および利用可能になるライセンスの保証、または一般ライセンスを取得しようとした試み、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得した結果を取得できます。 http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、この規格の実装に必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、利害関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。