[要約] ORCHIDv2は、オーバーレイネットワークで使用するためのIPv6プレフィックスを定義するRFCです。その目的は、暗号ハッシュ識別子を使用してネットワーク上のエンティティを一意に識別することです。
Internet Engineering Task Force (IETF) J. Laganier
Request for Comments: 7343 Luminate Wireless, Inc.
Obsoletes: 4843 F. Dupont
Category: Standards Track Internet Systems Consortium
ISSN: 2070-1721 September 2014
An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)
オーバーレイ可能なルーティング可能な暗号化ハッシュ識別子バージョン2（ORCHIDv2）のIPv6プレフィックス
Abstract
概要
This document specifies an updated Overlay Routable Cryptographic Hash Identifiers (ORCHID) format that obsoletes that in RFC 4843. These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (APIs) 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 regular IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered non-routable addresses from the IPv6-layer perspective, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses.
このドキュメントでは、RFC 4843で廃止された更新されたオーバーレイルーティング可能な暗号化ハッシュ識別子（ORCHID）形式を指定します。これらの識別子は、アプリケーションおよびアプリケーションプログラミングインターフェイス（API）でエンドポイント識別子として使用されることを意図しており、IPでのネットワークロケーションの識別子としては使用されませんレイヤー、つまりロケーター。これらはアプリケーション層エンティティとして、および既存のIPv6 APIで表示されるように設計されていますが、実際のIPv6ヘッダーには表示されません。それらを通常のIPv6アドレスのようにするために、オーバーレイレベルでルーティング可能であることが期待されます。したがって、IPv6層の観点からはルーティングできないアドレスと見なされますが、既存のすべてのIPv6アプリケーションは、現在のIPv6アドレスと互換性のある方法でそれらを使用できることが期待されます。
The Overlay Routable Cryptographic Hash Identifiers originally defined in RFC 4843 lacked a mechanism for cryptographic algorithm agility. The updated ORCHID format specified in this document removes this limitation by encoding, in the identifier itself, an index to the suite of cryptographic algorithms in use.
RFC 4843で最初に定義されたオーバーレイルーティング可能な暗号化ハッシュ識別子には、暗号化アルゴリズムの俊敏性のためのメカニズムがありませんでした。このドキュメントで指定されている更新されたORCHID形式は、使用中の暗号化アルゴリズムスイートへのインデックスを識別子自体にエンコードすることにより、この制限を取り除きます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7343.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7343で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Rationale and Intent . . . . . . . . . . . . . . . . . . 3
1.2. ORCHID Properties . . . . . . . . . . . . . . . . . . . . 4
1.3. Expected Use of ORCHIDs . . . . . . . . . . . . . . . . . 5
1.4. Action Plan . . . . . . . . . . . . . . . . . . . . . . . 5
1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Cryptographic Hash Identifier Construction . . . . . . . . . 5
3. Routing and Forwarding Considerations . . . . . . . . . . . . 7
4. Design Choices . . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Collision Considerations . . . . . . . . . . . . . . 13
Appendix B. Changes from RFC 4843 . . . . . . . . . . . . . . . 13
This document introduces Overlay Routable Cryptographic Hash Identifiers (ORCHID), a new class of identifiers that are like IP addresses. These identifiers are intended to be globally unique in a statistical sense (see Appendix A), 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）を紹介します。これらの識別子は、統計的な意味でグローバルに一意であり（付録Aを参照）、IP層でルーティングできず、一部のオーバーレイ層でルーティングできるようになっています。識別子は、安全なハッシュ関数を介して、入力ビット文字列とコンテキストタグの連結に安全にバインドされます。通常、必須ではありませんが、入力ビット文字列には、適切にエンコードされた公開暗号キーが含まれます。
These identifiers are expected to be used at the existing IPv6 Application Programming Interfaces (APIs) 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 (HITs) in the Host Identity Protocol (HIP) [HIPv2] and Temporary Mobile Identifiers (TMIs) for Mobile IPv6 Privacy Extension [PRIVACYTEXT].
これらの識別子は、既存のIPv6アプリケーションプログラミングインターフェイス（API）および同意ホスト間のアプリケーションプロトコルで使用されることが期待されています。それらは、異なるオーバーレイプロトコルに適した異なるコンテキストで定義および使用できます。これらの例には、ホストアイデンティティプロトコル（HIP）のホストアイデンティティタグ（HIT）[HIPv2]とモバイルIPv6プライバシー拡張の一時モバイル識別子（TMI）[PRIVACYTEXT]が含まれます。
As these identifiers are expected to be used along with IPv6 addresses at both applications and APIs, coordination is desired to make sure that an ORCHID is not inappropriately taken for a regular 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 use at the IP layer.
これらの識別子は、アプリケーションとAPIの両方でIPv6アドレスとともに使用されることが予想されるため、ORCHIDが通常のIPv6アドレスに対して不適切に行われないように、またその逆も行われないように調整することが望まれます。実際には、ORCHIDに個別のプレフィックスを割り当てるだけで十分であるように思われ、上位層のIPv6アドレスとの互換性を確保すると同時に、IP層での使用を防ぐのは簡単です。
While being technically possible to use ORCHIDs between consenting hosts without any coordination with the IETF and the IANA, the IETF would consider such practice potentially dangerous. A specific danger would be realized 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 balkanization of the Internet, similar to what has happened as a result of historical hijackings of IPv4 addresses that are not RFC 1918 [RFC1918] for private use.
IETFとIANAとの調整なしに同意ホスト間でORCHIDを使用することは技術的に可能ですが、IETFはそのような行為を潜在的に危険と見なします。 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 implement 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 deployments with minimum user effort.
ただし、インターネットの現状を考えると、アプリケーションの書き換えとホストスタックの更新を一度に要求するような変更を導入することは現実的ではないと考えています。それよりも、既存の資産の1つだけに手を加える必要がある断片的なアーキテクチャーの変更を信じています。 ORCHIDは、この状況に対処するように設計されています。アプリケーションを更新することなく、セキュアオーバーレイルーティング、HIP、モバイルIPプライバシー拡張などのプロトコルスタック拡張を実装できるようにします。目標は、最小限のユーザーの労力で大規模な展開を容易にすることです。
For example, at the time of this writing, there already exist 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を介して既存のアプリケーションで両方を使用できます。
The Overlay Routable Cryptographic Hash Identifiers originally defined in [RFC4843] lacked a mechanism for cryptographic algorithm agility. The updated ORCHID format specified in this document removes this limitation by encoding, in the identifier itself, an index to the suite of cryptographic algorithms in use.
[RFC4843]で最初に定義されたオーバーレイルーティング可能な暗号化ハッシュ識別子には、暗号化アルゴリズムの俊敏性のためのメカニズムがありませんでした。このドキュメントで指定されている更新されたORCHID形式は、使用中の暗号化アルゴリズムスイートへのインデックスを識別子自体にエンコードすることにより、この制限を取り除きます。
Because the updated ORCHIDv2 format is not backward compatible, IANA has allocated a new 28-bit prefix out of the IANA IPv6 Special Purpose Address Block, namely 2001:0000::/23, as per [RFC6890]. The prefix that was temporarily allocated for the experimental ORCHID was returned to IANA in March 2014 [RFC4843].
更新されたORCHIDv2形式には下位互換性がないため、[RFC6890]に従って、IANAはIANA IPv6特別目的アドレスブロックから新しい28ビットプレフィックス、つまり2001：0000 :: / 23を割り当てました。実験的なORCHIDに一時的に割り当てられたプレフィックスは、2014年3月にIANAに返されました[RFC4843]。
ORCHIDs are designed to have the following properties:
ORCHIDは、次のプロパティを持つように設計されています。
o Statistical uniqueness (see also Appendix A).
o 統計的一意性（付録Aも参照）。
o Secure binding to the input parameters used in their generation (i.e., the Context Identifier and a bitstring).
o それらの生成で使用される入力パラメーター（つまり、コンテキストIDとビット文字列）への安全なバインディング。
o Aggregation under a single IPv6 prefix. Note that this is only needed due to the coordination need as indicated above. Without such coordination 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 Appendix A for a
上記のように、ORCHIDは、さまざまなメカニズムやプロトコルに適した、さまざまなコンテキストで生成および使用されることを目的としています。コンテキスト識別子は、異なるコンテキストを区別するために使用されることを意図しています。付録Aを参照してください。
discussion of the related API issues implementation issues and Section 4 for the design choices explaining why the Context Identifiers are used.
関連するAPIの問題の実装に関する問題と、コンテキスト識別子が使用される理由を説明する設計上の選択に関するセクション4。
Examples of identifiers and protocols that are expected to adopt the ORCHID format include Host Identity Tags (HITs) in the Host Identity Protocol [HIPv2] and the Temporary Mobile Identifiers (TMIs) 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形式の採用が予想される識別子とプロトコルの例には、ホストアイデンティティプロトコル（HIPv2）のホストアイデンティティタグ（HIT）と、モバイルIPv6のシンプルプライバシー拡張[PRIVACYTEXT]の一時モバイル識別子（TMI）があります。このフォーマットは、他の実験的な提案が同じ名前空間を共有できるように拡張できるように設計されています。
This document requests IANA to allocate a prefix out of the IPv6 addressing space for Overlay Routable Cryptographic Hash Identifiers.
このドキュメントでは、オーバーレイ可能なルーティング可能な暗号化ハッシュ識別子のIPv6アドレス空間からプレフィックスを割り当てるようIANAに要求しています。
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 ORCHID Generation Algorithm (OGA). The algorithm takes a bitstring and a Context Identifier as input and produces an ORCHID as output. The hash function used in the ORCHID Generation Algorithm is defined for each OGA identifier by the specification for the respective usage context (e.g., HIPv2).
ORCHIDは、ORCHID生成アルゴリズム（OGA）を使用して生成されます。このアルゴリズムは、ビット文字列とコンテキスト識別子を入力として受け取り、ORCHIDを出力として生成します。 ORCHID生成アルゴリズムで使用されるハッシュ関数は、各OGA識別子に対して、それぞれの使用コンテキスト（HIPv2など）の仕様によって定義されます。
Input := any bitstring
OGA ID := 4-bit Orchid Generation Algorithm identifier
Hash Input := Context ID | Input
Hash := Hash_function( Hash Input )
ORCHID := Prefix | OGA ID | Encode_96( 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 Cryptographically Generated Addresses (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を参照）に導入された名前空間から割り当てられます。
OGA ID : A 4-bit-long identifier for the Hash_function in use within the specific usage context.
OGA ID：特定の使用状況で使用されているHash_functionの4ビット長の識別子。
Hash_function : The one-way hash function (i.e., hash function with preimage resistance and second-preimage resistance) to be used as identified by the value for the OGA ID according document defining the context usage identified by the Context ID. For example, version 2 of the HIP specification defines truncated SHA1 [RFC3174] as the hash function to be used to generate ORCHIDv2 in the HIPv2 protocol when the OGA ID is 3 [HIPv2].
Hash_function：一方向のハッシュ関数（つまり、プリイメージ耐性と2番目のプリイメージ耐性を持つハッシュ関数）。コンテキストIDで識別されるコンテキストの使用法を定義するドキュメントに従って、OGA IDの値によって識別されます。たとえば、HIP仕様のバージョン2では、OGA IDが3 [HIPv2]の場合に、HIPv2プロトコルでORCHIDv2を生成するために使用されるハッシュ関数として、切り捨てSHA1 [RFC3174]を定義しています。
Encode_96( ) : An extraction function in which output is obtained by extracting the middle 96-bit-long bitstring from the argument bitstring.
Encode_96()：引数のビット文字列から中央の96ビット長のビット文字列を抽出して出力を取得する抽出関数。
Prefix : A constant 28-bit-long bitstring value (2001:20::/28).
プレフィックス：28ビット長の定数ビット文字列値（2001：20 :: / 28）。
To form an ORCHID, two pieces of input data are needed. The first piece can be any bitstring, but it 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 6. Each specific ORCHIDv2 application (such as HIP HITs or MIP6 TMIs) is expected to allocate their own, specific Context Identifier.
ORCHIDを作成するには、2つの入力データが必要です。最初の部分は任意のビット文字列にすることができますが、通常は公開暗号鍵とその他のデータが含まれていることが予想されます。 2番目の部分はコンテキスト識別子で、128ビット長のデータであり、セクション6の指定に従って割り当てられます。特定の各ORCHIDv2アプリケーション（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 for the value of the OGA identifier 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 96-bit-long value. This value is prepended with the concatenation of the 28-bit ORCHID prefix and the 4-bit OGA ID. 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で識別されるコンテキスト使用法を定義するドキュメントに従って、OGA識別子の値に使用されます。ハッシュ関数の結果はエンコード関数によって処理され、96ビット長の値になります。この値の前には、28ビットのORCHIDプレフィックスと4ビットのOGA IDが連結されています。結果は、特定の実験に参加しているホストの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）。
ORCHIDs are not designed for use in IPv6 routing protocols, since such routing protocols are based on the architectural definition of IPv6 addresses. Future non-IPv6 routing systems, such as overlay routing systems, may be designed based on ORCHIDs. Any such ORCHID-based routing system is out of scope of this document.
ORCHIDはIPv6ルーティングプロトコルで使用するように設計されていません。そのようなルーティングプロトコルはIPv6アドレスのアーキテクチャの定義に基づいているためです。オーバーレイルーティングシステムなどの将来の非IPv6ルーティングシステムは、ORCHIDに基づいて設計される可能性があります。そのようなORCHIDベースのルーティングシステムは、このドキュメントの範囲外です。
Router software MUST NOT include any special handling code for ORCHIDs. In other words, the non-routability property of ORCHIDs, if implemented, is to be implemented via configuration rather than by hardwired software code, e.g., the ORCHID prefix can be blocked by a simple configuration rule such as an Access Control List entry.
ルーターソフトウェアには、ORCHIDの特別な処理コードを含めてはなりません。つまり、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 maximum: all the bits beyond the prefix and the ORCHID Generation Algorithm Identifier are used as hash output. This leaves no bits in the ORCHID itself available for identifying the context; however, the 4 bits used to encode the ORCHID Generation Algorithm Identifier provides cryptographic agility with respect to the hash function in use for a given context (see Section 5).
ハッシュ結果を長くしたいという願望は、接頭辞が可能な限り短いことと、追加の符号化のために（もしあれば）少しのビットを使用することを要求します。現在の設計ではこの要望を最大限に活用しています。プレフィックスとORCHID生成アルゴリズム識別子を超えるすべてのビットがハッシュ出力として使用されます。これにより、コンテキストを識別するために使用できるORCHID自体のビットは残りません。ただし、ORCHID生成アルゴリズム識別子のエンコードに使用される4ビットは、特定のコンテキストで使用されているハッシュ関数に関して暗号化の俊敏性を提供します（セクション5を参照）。
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 an 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 5).
複数のメカニズムが名前空間を共有できるようにするという要望は、ハッシュ関数の入力にコンテキスト識別子を含めることで解決されました。これにより、メカニズムをORCHIDから直接推論することはできませんが、特定の入力ビット文字列とORCHIDが特定のコンテキストに属することを高い確率で確認できます（セクション5も参照）。
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に対しても、他の、まだ安全なハッシュ関数。
An identifier for the hash function to be used for the ORCHID generation is encoded in the ORCHID itself, while the semantic for the values taken by this identifier are defined separately for each Context ID. Therefore, the present design allows the use of different hash functions per given Context ID for constructing ORCHIDs from input bitstrings. The intent is that the protocol or application using an ORCHIDv2 allocates a Context ID for that use and defines, within the scope of that Context ID, the registry for the ORCHID Generation Algorithm (OGA) ID. The rationale for this is to allow different applications to use different hash functions that best satisfy their specific requirements, such that the relatively small OGA ID namespace (4 bits wide, i.e., 16 different values) does not get exhausted too quickly. If more secure hash functions are later needed, newer values for the ORCHID Generation Algorithm can be defined for the given Context ID.
ORCHID生成に使用されるハッシュ関数の識別子はORCHID自体にエンコードされますが、この識別子が取る値のセマンティクスは、コンテキストIDごとに個別に定義されます。したがって、現在の設計では、特定のコンテキストIDごとに異なるハッシュ関数を使用して、入力ビット文字列からORCHIDを構築できます。その意図は、ORCHIDv2を使用するプロトコルまたはアプリケーションがその用途にコンテキストIDを割り当て、そのコンテキストIDのスコープ内で、ORCHID生成アルゴリズム（OGA）IDのレジストリを定義することです。これの理由は、比較的小さなOGA ID名前空間（4ビット幅、つまり16の異なる値）がすぐに使い果たされないように、さまざまなアプリケーションが特定の要件を最もよく満たすさまざまなハッシュ関数を使用できるようにすることです。より安全なハッシュ関数が後で必要になった場合は、ORCHID生成アルゴリズムの新しい値を特定のコンテキストIDに定義できます。
In order to preserve a low enough probability of collisions (see Appendix A), 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 pseudorandom number of sufficient entropy (minimum 96 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.
衝突の可能性を十分に低く保つため（付録Aを参照）、各メソッドは、そのコンテキスト内で個別の入力ビット文字列が一意または統計的に一意であることを確認するメカニズムを使用する必要があります。これを確実にする方法はいくつかあります。たとえば、グローバルに維持されるカウンタ値、十分なエントロピーの擬似乱数（最小96ビット）、またはランダムに生成された公開暗号鍵を入力ビット文字列に含めることができます。コンテキストIDは、異なるコンテキストからの入力ビット文字列が重複しないようにします。これらにより、衝突の確率はハッシュ空間での自然な衝突の確率によってのみ決定され、入力ビット文字列が衝突する可能性によって増加することはありません。
The generation of an ORCHIDv2 identifier from an input bitstring involves truncation of a hash output to construct a fixed-size identifier in a fashion similar to the scheme specified in "Naming Things with Hashes" [RFC6920]. Accordingly, the Security Considerations of [RFC6920] pertaining to truncation of the hash output during identifier generation are also applicable to ORCHIDv2 generation.
入力ビット文字列からORCHIDv2識別子を生成するには、「ハッシュによるものの命名」[RFC6920]で指定された方式と同様の方法で固定サイズの識別子を構築するために、ハッシュ出力の切り捨てが必要です。したがって、識別子生成中のハッシュ出力の切り捨てに関する[RFC6920]のセキュリティに関する考慮事項は、ORCHIDv2生成にも適用できます。
Because the updated ORCHIDv2 format is not backward compatible with the earlier one, IANA has allocated a new 28-bit prefix out of the IANA IPv6 Special Purpose Address Block, namely 2001:0000::/23, as per [RFC6890]. The prefix that was temporarily allocated for the experimental ORCHID was returned to IANA in March 2014 [RFC4843]. The registry information for the allocation is as follows:
更新されたORCHIDv2形式は以前の形式との下位互換性がないため、IANAは[RFC6890]に従って、IANA IPv6特殊目的アドレスブロックから新しい28ビットプレフィックス、つまり2001：0000 :: / 23を割り当てました。実験的なORCHIDに一時的に割り当てられたプレフィックスは、2014年3月にIANAに返されました[RFC4843]。割り当てのレジストリ情報は次のとおりです。
o Address Block: 2001:20::/28
o アドレスブロック：2001：20 :: / 28
o Name: ORCHIDv2
o 名前：ORCHIDv2
o RFC: RFC 7343
o RFC：RFC 7343
o Allocation Date: 2014-07
o 割り当て日：2014-07
o Termination Date: N/A
o 終了日：N / A
o Source: True
o 出典：True
o Destination: True
o 宛先：真
o Forwardable: True
o Forwardable：True
o Global: True
o グローバル：真
o Reserved-by-Protocol: False
o プロトコルによって予約済み：False
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. The Context ID shares the namespace introduced for CGA Type Tags. Hence, defining new values follows the rules of Section 8 of [RFC3972], i.e., First Come, First Served. However, no IANA actions are required.
コンテキスト識別子（またはコンテキストID）は、ランダムに生成された値で、ORCHIDの使用コンテキストと、このコンテキストでのORCHIDの生成に使用されるハッシュ関数を定義します。このドキュメントでは特定の値を定義していません。コンテキストIDは、CGAタイプタグに導入された名前空間を共有します。したがって、新しい値の定義は、[RFC3972]のセクション8の規則に従います。つまり、先着順です。ただし、IANAアクションは必要ありません。
Pekka Nikander (pekka.nikander@nomadiclab.com) co-authored an earlier, experimental version of this specification [RFC4843].
Pekka Nikander（pekka.nikander@nomadiclab.com）は、この仕様の初期の実験バージョン[RFC4843]を共同執筆しました。
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コミュニティからのレビュー、コメント、およびディスカッションによっても改善されています。
[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月。
[HIPv2] Moskowitz, R., Heer, T., Jokela, P., and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", Work in Progress, July 2014.
[HIPv2] Moskowitz、R.、Heer、T.、Jokela、P。、およびT. Henderson、「Host Identity Protocol Version 2（HIPv2）」、Work in Progress、2014年7月。
[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月。
[RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)", RFC 4843, April 2007.
[RFC4843] Nikander、P.、Laganier、J。、およびF. Dupont、「オーバーレイ可能なルーティング可能な暗号化ハッシュ識別子（ORCHID）のIPv6プレフィックス」、RFC 4843、2007年4月。
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, April 2013.
[RFC6890]綿、M。、ベゴダ、L。、ボニカ、R。、およびB.ハーバーマン、「特別な目的のIPアドレスレジストリ」、BCP 153、RFC 6890、2013年4月。
[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, April 2013.
[RFC6920] Farrell、S.、Kutscher、D.、Dannewitz、C.、Ohlman、B.、Keranen、A。、およびP. Hallam-Baker、「Naming Things with Hashes」、RFC 6920、2013年4月。
As noted earlier, the aim is that so long as keys are not reused, ORCHIDs be 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 4).
前述のように、キーが再利用されない限り、ORCHIDは統計的な意味でグローバルに一意であることが目的です。つまり、特定のエンティティを参照するORCHIDが与えられた場合、同じORCHIDがインターネットの他の場所で別のエンティティを参照するために使用される確率は、ほとんどの実用的な目的で無視できるように十分低くなければなりません。提示されたデザインはこの目標を満たしていると信じています（セクション4を参照）。
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 is 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-setup 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-setup protocol.
ORCHIDはIP層でルーティングできないため、APIレベルでORCHIDを使用してパケットを送信するには、送信側ホストがスタック内に追加のオーバーレイ状態を持たせて、送信パケットで使用するパラメーター（ロケーターなど）を決定する必要があります。ここでの根本的な仮定、および作成者が認識している提案の実際の問題は、この追加の状態を設定および維持するためのオーバーレイプロトコルがあることです。状態設定プロトコルは入力ビット文字列を伝送し、スタック内のORCHID関連の状態は、適切なコンテキストと状態設定プロトコルに関連付けることができると想定されています。
o Updated HIP references to revised HIP specifications.
o 修正されたHIP仕様へのHIPリファレンスを更新しました。
o The Overlay Routable Cryptographic Hash Identifiers originally defined in [RFC4843] lacked a mechanism for cryptographic algorithm agility. The updated ORCHID format specified in this document removes this limitation by encoding, in the identifier itself, an index to the suite of cryptographic algorithms in use.
o [RFC4843]で最初に定義されたオーバーレイルーティング可能な暗号化ハッシュ識別子には、暗号化アルゴリズムの俊敏性のためのメカニズムがありませんでした。このドキュメントで指定されている更新されたORCHID形式は、使用中の暗号化アルゴリズムスイートへのインデックスを識別子自体にエンコードすることにより、この制限を取り除きます。
o Moved the "Collision Considerations" section into an appendix and removed unnecessary discussions.
o 「衝突に関する考慮事項」セクションを付録に移動し、不要な議論を削除しました。
o Removed the discussion on overlay routing.
o オーバーレイルーティングに関する議論を削除しました。
Authors' Addresses
著者のアドレス
Julien Laganier Luminate Wireless, Inc. Cupertino, CA USA
ジュリアンラガニアLuminate Wireless、Inc.アメリカ、カリフォルニア州クパチーノ
EMail: julien.ietf@gmail.com
Francis Dupont Internet Systems Consortium
フランシスデュポンインターネットシステムコンソーシアム
EMail: fdupont@isc.org