Internet Research Task Force (IRTF) S. Burleigh
Request for Comments: 6260 Jet Propulsion Laboratory,
Category: Experimental California Institute of Technology
ISSN: 2070-1721 May 2011
Compressed Bundle Header Encoding (CBHE)
Abstract
抽象
This document describes a convention by which Delay-Tolerant Networking (DTN) Bundle Protocol (BP) "convergence-layer" adapters may represent endpoint identifiers in a compressed form within the primary blocks of bundles, provided those endpoint identifiers conform to the structure prescribed by this convention.
この文書は、遅延耐性ネットワーク（DTN）バンドルプロトコル（BP）「収束層」アダプタはバンドルの主要ブロック内の圧縮形式でエンドポイント識別子を表すことができることにより、規則を説明し、これらのエンドポイント識別子によって規定構造に適合提供この大会。
Compressed Bundle Header Encoding (CBHE) compression is a convergence-layer adaptation. It is opaque to bundle processing. Therefore, it has no impact on the interoperability of different Bundle Protocol implementations, but instead affects only the interoperability of different convergence-layer adaptation implementations.
圧縮バンドルヘッダ符号化（CBHE）圧縮収束レイヤアダプテーションあります。処理をバンドルする不透明です。したがって、異なるバンドルプロトコル実装の相互運用性に影響を与えないが、その代わりに異なる収束レイヤアダプテーションの実装の唯一の相互運用性に影響を与えます。
This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised.
この文書では、遅延耐性ネットワーク研究グループの製品であり、そのグループによって検討されています。 RFCとしての公表に異議を提起しませんでした。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはインターネット標準化過程仕様ではありません。それは、検査、実験的な実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Delay-Tolerant Networking Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。この文書はインターネットResearch Task Force（IRTF）の製品です。 IRTFはインターネット関連の研究開発活動の成果を公表しています。これらの結果は、展開に適していない可能性があります。このRFCはインターネットリサーチタスクフォースの遅延耐性ネットワーク研究グループ（IRTF）のコンセンサスを表しています。 IRSGによって公表のために承認されたドキュメントは、インターネット標準の任意のレベルの候補ではありません。 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/rfc6260.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6260で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Requirements Language ......................................3
2. Compression Convention ..........................................3
2.1. Constraints ................................................3
2.2. Method .....................................................6
3. Specification ...................................................7
3.1. Transmission ...............................................7
3.2. Reception ..................................................7
4. IANA Considerations .............................................8
5. Security Considerations ........................................10
6. References .....................................................11
6.1. Normative References ......................................11
6.2. Informative References ....................................11
Appendix A. Acknowledgments .......................................12
This document describes a convention by which Delay-Tolerant Networking (DTN) Bundle Protocol (BP) [RFC5050] "convergence-layer" adapters may represent endpoint identifiers (EIDs) in a compressed form within the primary blocks of bundles, provided those endpoint identifiers conform to the structure prescribed by this convention.
この文書では、遅延耐性ネットワーク（DTN）バンドルプロトコル（BP）[RFC5050]「収束層」アダプタはバンドルの主要ブロック内に圧縮形式でエンドポイント識別子（のEID）を表してもよく、それらのエンドポイント識別子を設けたことにより、規則を記述するこの条約で規定された構造に準拠しています。
Each DTN bundle's primary block contains the following four BP endpoint identifiers, of which any two, any three, or even all four may be lexically identical: the endpoint identifiers of the bundle's source, destination, report-to endpoint, and current custodian. Each EID is a Uniform Record Identifier (URI) as defined by [RFC3986]. More specifically, each BP EID is a URI consisting of a "scheme name" followed by ":", followed by a sequence of characters -- historically, termed the "scheme-specific part" (SSP) in DTN specifications -- conforming to URI syntax as defined by RFC 3986.
、バンドルの送信元、宛先のエンドポイント識別子をレポートするためにエンドポイント、及び現在のカストディアン：各DTN束の主ブロックは、のいずれか2つ、いずれか3つ、またはさらにはすべて4つの字句的に同一であってもよく、次の4つのBPエンドポイント識別子を含んでいます。 [RFC3986]で定義されるように各EIDはユニフォームレコードの識別子（URI）です。 「：」より具体的には、各BP EIDが続く「スキーム名」からなるURIであり、文字のシーケンスが続く - 歴史的に、DTN仕様に「スキーマ固有部分」（SSP）と呼ばれる - に準拠RFC 3986で定義されたURIの構文。
A degree of block compression is provided by the design of the primary block: the scheme names and scheme-specific parts of the four endpoints' IDs -- up to eight NULL-terminated strings -- are concatenated at the end of the block in a variable-length character array called a "dictionary", enabling each EID to be represented by a pair of integers indicating the offsets (within the dictionary) of the EID's scheme name and scheme-specific part. Duplicate strings may be omitted from the dictionary, so the actual number of concatenated NULL-terminated strings in the dictionary may be less than eight, and two or more of the scheme name or scheme-specific part offsets in the block may have the same value. Moreover, the eight offsets in the primary block are encoded as Self-Delimiting Numeric Values (SDNVs), which shrink to fit the encoded values; when the total length of the dictionary is less than 127 bytes, all eight offsets can be encoded into just eight bytes.
ブロック圧縮の程度は、一次ブロックの設計によって提供される：スキーム名四のエンドポイントのIDのスキーマ固有部分 - 8 NULLで終了する文字列までは - のブロックの端部に連結され可変長文字列は、EIDのスキーム名とスキーマ固有部分の（辞書内）のオフセットを示す整数の組で表される各EIDを可能にする、「辞書」と呼ばれます。文字列を複製する辞書から省略されてもよいので、辞書に連結NULLで終了する文字列の実際の数が8未満であってもよいし、ブロック内のスキーム名またはスキーマ固有部分オフセットの2つ以上が同じ値を有していてもよいです。また、一次ブロック内の8つのオフセットは、エンコードされた値に合うように縮小自己区切り数値値（SDNVs）として符号化されます。辞書の合計長さが127バイト未満である場合、8つのすべてのオフセットがわずか8バイトに符号化することができます。
However, these strategems do not prevent the scheme names and especially the scheme-specific parts themselves from being lengthy strings of ASCII text. It is therefore still possible for the length of a bundle's primary header to be a very large fraction of the total length of the bundle when the bundle's payload is relatively small, as is anticipated for a number of DTN applications such as space flight operations (and as is in any case true of bundles carrying BP administrative records).
しかし、これらのstrategemsはASCIIテキストの長い文字列であることから、スキーム名と、特にスキーム固有の部分に自分自身を防ぐことはできません。これは、バンドルの主ヘッダの長さは、バンドルの全長の非常に大きな部分であるために、バンドルのペイロードが比較的小さい場合、このような宇宙飛行操作などDTNアプリケーションの数のために予想されるように、依然としてことが可能である（及び）BP管理レコードを運ぶバンドルの真のいずれの場合です。
The Compressed Bundle Header Encoding (CBHE) convention was developed to improve DTN transmission efficiency for such applications by further reducing the number of bytes used by convergence-layer adapters to represent EIDs in the primary blocks of bundles.
圧縮バンドルヘッダ符号化（CBHE）規則はさらにバンドルの主要ブロックでのEIDを表現するために収束層アダプタによって使用されるバイトの数を減らすことによって、そのような用途のためのDTN伝送効率を改善するために開発されました。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
The only valid scheme name for BP EIDs identified to date is "dtn". Although no specification of valid SSP syntax for URIs composed within the "dtn" scheme has yet been formally defined, the syntax on which rough agreement has been reached in practice is unsuitable for CBHE's compression procedures. For the purposes of CBHE, then, this document defines an additional URI scheme named "ipn". As noted in Section 4, IANA has registered this new URI scheme.
現在までに同定されたBPのEIDのための唯一の有効なスキーム名は「DTN」です。 「DTN」のスキームの中で構成されるURIの有効なSSP構文のない仕様はまだ正式に定義されていないが、大まかな合意が実際に到達された構文はCBHEの圧縮手順には不向きです。 CBHEの目的のために、そして、このドキュメントは、「IPN」という名前の追加のURIスキームを定義します。第4節で述べたように、IANAは、この新しいURIスキームを登録しています。
Compressed Bundle Header Encoding (CBHE) is possible only when all endpoint IDs in the primary block of a given bundle are "CBHE conformant". The following two forms of endpoint ID are CBHE conformant: (a) the null endpoint ID "dtn:none" and (b) any endpoint ID formed within the "ipn" scheme.
圧縮バンドルヘッダ符号化（CBHE）指定された束の主要ブロック内のすべてのエンドポイントIDが「CBHEの適合」である場合にのみ可能です。エンドポイントIDの次の2つの形式がCBHE準拠である：（A）ヌルエンドポイントID「DTN：なし」と「IPN」スキーム内に形成された（b）のいずれかのエンドポイントID。
The SSP of every URI formed within the "ipn" scheme must comprise:
「IPN」スキーム内に形成されたすべてのURIのSSPを構成する必要があります。
1. A sequence of ASCII numeric digits representing an integer in the range 1 to (2^64 - 1), termed the "node number" of the URI.
1.（2 ^ 64から1）の範囲1の整数を表すASCII数字のシーケンスは、URIの「ノード番号」と呼ばれます。
3. A sequence of ASCII numeric digits representing an integer in the range 0 to (2^64 - 1), termed the "service number" of the URI.
3.（2 ^ 64から1）の範囲0の整数を表すASCII数字のシーケンスは、URIの「サービス番号」と呼ばれます。
The node number notionally identifies a BP node. However, since CBHE is not used universally in Delay-Tolerant Networking, it must not be assumed that all BP nodes are identified by node numbers.
ノード番号は、概念的BPノードを識別する。 CBHEが遅延耐性ネットワークにおいて普遍的に使用されていないので、全てのBPノードがノード番号によって識別されることを想定してはなりません。
Negative integers and integers larger than (2^64 - 1) cannot be used as node numbers because they cannot be encoded into the SDNVs that are used for representation of scheme name and SSP offsets in the primary blocks of bundles and therefore could not be compressed as described later in this specification. Node number zero is reserved for representation of the null endpoint ID in the compressed form described later; decompressing a compressed null EID must always yield the standard null endpoint ID URI "dtn:none".
負の整数と（2 ^ 64から1）よりも大きい整数は、それらがバンドルの主要ブロックにスキーム名とSSPオフセットを表すために使用されるSDNVsに符号化することができず、したがって、圧縮されなかったため、ノード番号として使用することができませんこの仕様書で後述するように。ノード番号ゼロは、後述する圧縮形式でヌルエンドポイントIDの表現のために予約されています。圧縮されたヌルEIDを解凍すると、常に標準のヌルエンドポイントID URI「：なしDTN」を得なければなりません。
The service number notionally functions as a de-multiplexing token. When the bundle payload is a protocol data unit of some protocol that has its own de-multiplexing identifiers, the service number may function in a manner similar to that of the protocol number in an IP packet, characterizing the encapsulated protocol; alternatively, the service number may function in a manner similar to that of the port number in a UDP datagram. Service numbers enable inbound bundles' application data units to be de-multiplexed to instances of application functionality that are designed to process them, so that effective communication relationships can be developed between bundle producers and consumers.
サービス番号は、概念的に逆多重化トークンとして機能します。バンドルペイロードは、自身の逆多重化識別子を持ついくつかのプロトコルのプロトコルデータユニットである場合、サービスの数は、カプセル化されたプロトコルを特徴付ける、IPパケット内のプロトコル番号と同様に機能することができます。代替的に、サービス番号がUDPデータグラム内のポート番号と同様に機能することができます。サービス番号は、効果的なコミュニケーション関係がバンドル生産者と消費者の間で開発することができるように、それらを処理するように設計されているアプリケーション機能のインスタンスに逆多重化するために、インバウンドバンドルアプリケーション・データ・ユニットを有効にします。
A service number must not be negative or exceed (2^64 - 1) for the same reason that a node number must not do so.
サービス番号が負であるか、または超えてはならない - ノードの数はそうはならないのと同じ理由で（2 ^ 64 1）。
For example, "ipn:9.37" would be a CBHE-conformant endpoint ID.
たとえば、「IPN：9.37は、」CBHE準拠のエンドポイントのIDになります。
Conversion of a CBHE-conformant EID to and from a tuple of two integers is therefore straightforward: all characters in the EID other than the node number and service number are constant (as defined by the "ipn" scheme definition), and the node number and service number are taken as the two integers of the tuple. This ease of conversion enables an array of pairs of integers to serve the same function as a dictionary of ASCII string EIDs.
二つの整数の組へとからCBHE準拠EIDの変換したがって、簡単である：（「IPN」スキームの定義によって定義されるように）ノード番号とサービス番号以外のEID内のすべての文字は、一定で、ノード番号そして、サービス番号がタプルの二つの整数として解釈されています。この変換しやすさは、ASCII文字列のEIDの辞書と同じ機能を提供するために、整数のペアの配列を可能にします。
Note, however, that CBHE decompression cannot faithfully recreate the dictionary of a compressed primary block from an array of integer pairs unless the order of the scheme names and scheme-specific part strings in the dictionary of the original, uncompressed block is known. (The Bundle Protocol Specification does not require that the strings in the dictionary appear in any particular order and does not require that redundant strings be omitted from the dictionary.) Therefore, a further precondition to CBHE compression is that the strings in the dictionary of the bundle to be compressed must be exactly as follows, in this order and without addition:
ただし、オリジナルの、圧縮されていないブロックの辞書におけるスキーム名とスキーマ固有部分文字列の順序が知られていない限りCBHE伸長を忠実整数のペアの配列から圧縮主要ブロックの辞書を作成し直すことができません。 （バンドルプロトコル仕様は、辞書内の文字列は、任意の特定の順序で表示され、その冗長な文字列が辞書から省略することが必要としないことを必要としない。）したがって、CBHE圧縮にさらに前提条件であることの辞書の文字列次のように圧縮されるようにバンドルすることは、この順にして添加することなく、正確でなければなりません。
3. The scheme name of the source endpoint ID, if and only if different from any prior string in the dictionary.
3.ソースエンドポイントIDのスキーム名、場合のみ辞書内の任意の前の文字列と異なる場合。
4. The scheme-specific part of the source endpoint ID, if and only if different from any prior string in the dictionary.
4.ソースエンドポイントIDのスキーマ固有部分、辞書内の任意の前の文字列と異なる場合のみなら。
5. The scheme name of the report-to endpoint ID, if and only if different from any prior string in the dictionary.
5.レポートする辞書内の任意の前の文字列と異なる場合のみならば、IDをエンドポイントのスキーム名に。
6. The scheme-specific part of the report-to endpoint ID, if and only if different from any prior string in the dictionary.
6.レポートする辞書内の任意の前の文字列と異なる場合にのみ場合、IDをエンドポイントのスキーマ固有部分。
7. The scheme name of the current custodian endpoint ID, if and only if different from any prior string in the dictionary.
7.現在の管理人のエンドポイントIDのスキーム名、場合にのみ、辞書内の任意の前の文字列と異なる場合。
8. The scheme-specific part of the current custodian endpoint ID, if and only if different from any prior string in the dictionary.
8.現在のカストディアンエンドポイントIDのスキーマ固有部分、辞書内の任意の前の文字列と異なる場合のみなら。
Note: this constraint implies that a bundle that includes any extension blocks containing EID-references to endpoint IDs other than the block's destination, source, report-to, and current custodian cannot be CBHE compressed since such compression would result in a dictionary that would deviate from this structure.
注：この制約は、EID-参照を含む任意の拡張ブロックを含むバンドルは、ブロックの宛先以外のIDをエンドポイントすることを意味ソース、レポートに、このような圧縮がずれることになる辞書をもたらすので、現在の管理者はCBHEを圧縮することができませんこのような構造から。
When the constraints enumerated above are met, the CBHE block compression method can be applied by the convergence-layer adapter (CLA) at the time the bundle is transmitted via a convergence-layer protocol. In a CBHE-compressed primary block, the eight SDNVs that normally contain EIDs' scheme name and SSP offsets within the dictionary are instead used to contain the eight integer values listed below, in the order shown:
上記に列挙した制約が満たされた場合、CBHEブロック圧縮方法は、束が収束層プロトコルを介して送信された時点で収束層アダプタ（CLA）によって適用することができます。 CBHE圧縮主要ブロックに、通常の辞書内のEIDスキーム名とSSPオフセットを含む8 SDNVs代わりに示された順序で、以下に示す8つの整数値を含むために使用されます。
1. The node number of the destination endpoint ID, or zero if the destination endpoint is the null endpoint.
1.宛先エンドポイントは、ヌルエンドポイント宛先エンドポイントID、またはゼロのノード番号である場合。
2. The service number of the destination endpoint ID, or zero if the destination endpoint is the null endpoint.
2.サービス宛先エンドポイントIDの数、またはゼロを宛先エンドポイントがnullのエンドポイントである場合。
3. The node number of the source endpoint ID, or zero if the source endpoint is the null endpoint.
3.ソースエンドポイントは、ヌルエンドポイントのソースエンドポイントID、またはゼロのノード番号である場合。
4. The service number of the source endpoint ID, or zero if the source endpoint is the null endpoint.
前記発信元エンドポイントは、ヌルエンドポイントのソースエンドポイントID、またはゼロのサービス番号である場合。
5. The node number of the report-to endpoint ID, or zero if the report-to endpoint is the null endpoint.
5.レポートのエンドポイントは、ヌルエンドポイントがノードレポートするためのエンドポイントIDの数、またはゼロである場合。
6. The service number of the report-to endpoint ID, or zero if the report-to endpoint is the null endpoint.
6.レポートにエンドポイントは、ヌルエンドポイントサービスレポートするエンドポイントIDの数、またはゼロである場合。
7. The node number of the current custodian endpoint ID, or zero if the current custodian endpoint is the null endpoint.
7.現在のカストディアンエンドポイントは、ヌルエンドポイント現在のカストディアンエンドポイントID、またはゼロのノード番号である場合。
8. The service number of the current custodian endpoint ID, or zero if the current custodian endpoint is the null endpoint.
8.現在のカストディアンエンドポイントは、ヌルエンドポイントは、現在のカストディアンエンドポイントID、またはゼロのサービス番号である場合。
Further, the dictionary is omitted from the primary block and the primary block's dictionary length is set to zero.
さらに、辞書は、一次ブロックから省略され、一次ブロックの辞書の長さはゼロに設定されています。
Upon reception, the receiving convergence-layer adaptation de-compresses the block by simply reversing the process so that the bundle presented to the bundle protocol agent has the standard form (i.e., the dictionary is reconstituted).
受信時、受信収束レイヤアダプテーションバンドルプロトコルエージェントに提示束が標準形（即ち、辞書が再構成されている）を有するように、単にプロセスを逆にすることによってブロックを解除し圧縮します。
CBHE compression is a convergence-layer adaptation. It is opaque to bundle processing. Therefore, it has no impact on the interoperability of different Bundle Protocol implementations, but instead affects only the interoperability of different convergence-layer adaptation implementations.
CBHE圧縮は収束層の適応です。処理をバンドルする不透明です。したがって、異なるバンドルプロトコル実装の相互運用性に影響を与えないが、その代わりに異なる収束レイヤアダプテーションの実装の唯一の相互運用性に影響を与えます。
Bundle Protocol convergence-layer adapters that conform to the CBHE specification must implement the following procedures.
CBHE仕様に準拠バンドルプロトコルコンバージェンスレイヤアダプタは、次の手順を実装する必要があります。
When and only when required by the bundle protocol agent to transmit a bundle whose primary block's endpoint IDs satisfy the constraints identified in Section 2.1, the CLA MAY encode the primary block of the bundle in accordance with the CBHE compression convention described in Section 2.2 UNLESS the CLA to which the bundle is to be transmitted is known not to be CBHE conformant. Note that CBHE compression may be applied only if the receiving CLA is known or presumed to be CBHE conformant, i.e., able to decode the encoded primary block. Knowledge as to whether or not a receiving CLA is (or might be) CBHE conformant may be asserted by node administration and/or may be inferred from reception of a CBHE-compressed bundle as noted in Section 3.2.
ときに、その主要ブロックのエンドポイントIDのセクション2.1で識別された制約を満たすバンドルを送信するために、バンドルプロトコルエージェントによって要求される場合にのみ、CLAがない限り、セクション2.2で説明CBHE圧縮慣例に従ってバンドルの主要ブロックを符号化することができますバンドルが送信されるべきCLAはCBHE適合でないことが知られています。 CBHE圧縮が受信CLAが知られているか、または符号化された一次ブロックを復号することができ、すなわち、CBHE適合であると推定されている場合にのみ適用されてもよいことに留意されたいです。受信CLAがある（またはかもしれない）かどうかの知識CBHE準拠ノード投与によってアサートすることができ、および/またはセクション3.2で述べたようCBHE圧縮束の受信から推測することができます。
Upon receiving a bundle whose dictionary length is zero (and only in this circumstance), a CBHE-conformant convergence-layer adapter:
その辞書長さゼロ（のみこの状況で）バンドルを受信すると、CBHE準拠収束層アダプタ。
1. MAY infer that the CLA from which the bundle was received is CBHE conformant.
1.バンドルが受信されたCLAはCBHE準拠であることを推論することができます。
2. MUST decode the primary block of the bundle in accordance with the CBHE compression convention described in Section 2.2 before delivering it to the bundle protocol agent.
2.バンドルプロトコルエージェントに配信する前に、セクション2.2で説明CBHE圧縮慣例に従ってバンドルの主要ブロックを復号しなければなりません。
Note that when a CLA that is not CBHE conformant receives a bundle whose dictionary length is zero, it has no choice but to pass it to the bundle agent without modification. In this case, the bundle protocol agent will be unable to dispatch the received bundle, because it will be unable to determine the destination endpoint; the bundle will be judged to be malformed. The behavior of the bundle protocol agent in this circumstance is an implementation matter.
CBHEの準拠ではありませんCLAは、その辞書の長さがゼロのバンドルを受信したとき、それは変更せずに、バンドル・エージェントに渡しするしかないことに注意してください。宛先エンドポイントを決定することができなくなるので、この場合、バンドルプロトコルエージェントは、受信されたバンドルをディスパッチすることができません。バンドルは、不正な形式であると判断されます。この状況では、バンドルプロトコルエージェントの動作は実装の問題です。
IANA has registered a provisional registration (per [RFC4395]) for a URI scheme for CBHE, with the string "ipn" as the scheme name, as follows:
次のようにIANAは、スキーム名として文字列「IPN」と、CBHEのURIスキームのために（[RFC4395]あたりの）仮登録を登録しました。
URI scheme name: "ipn"
URIのスキーム名： "IPN"
Status: provisional
ステータス：暫定
URI scheme syntax:
URIスキームの構文：
This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234], including the core ABNF syntax rule for DIGIT defined by that specification.
この仕様はその仕様によって定義された桁のコアABNF文法規則を含む[RFC5234]の増補バッカス - ナウアフォーム（ABNF）の表記を使用します。
ipn-uri = "ipn:" ipn-hier-part ipn-hier-part = node-nbr nbr-delim service-nbr ; a path-rootless node-nbr = 1*DIGIT nbr-delim = "." service-nbr = 1*DIGIT
IPN-URI = "IPN：" IPN-のhier-一部IPN-のhier-部分=ノード-NBR NBR-でdelimサービス-NBR;パス・ルートレスノード-NBR = 1 * DIGIT NBR-DELIM = ""サービス-NBR = 1 * DIGIT
None of the reserved characters defined in the generic URI syntax are used as delimiters within URIs of the IPN scheme.
一般的なURI構文で定義されている予約文字のいずれもIPNスキームのURIの内の区切り文字として使用されていません。
URI scheme semantics: URIs of the IPN scheme are used as endpoint identifiers in the Delay-Tolerant Networking (DTN) Bundle Protocol (BP) [RFC5050] as described in Section 2.1.
URIスキームのセマンティクス：2.1節で説明したようにIPNスキームのURIは、遅延耐性ネットワーク（DTN）バンドルプロトコル（BP）[RFC5050]でエンドポイント識別子として使用されます。
Encoding considerations: URIs of the IPN scheme are encoded exclusively in US-ASCII characters.
エンコードの考慮事項：IPNスキームのURIは、US-ASCII文字に独占的にエンコードされます。
Applications and/or protocols that use this URI scheme name: the Delay-Tolerant Networking (DTN) Bundle Protocol (BP) [RFC5050].
このURIのスキーム名を使用するアプリケーションおよび/またはプロトコル：遅延耐性ネットワーク（DTN）バンドルプロトコル（BP）[RFC5050]。
Interoperability considerations: as noted above, URIs of the IPN scheme are encoded exclusively in US-ASCII characters.
相互運用性に関する注意事項：上記のように、IPNスキームのURIはUS-ASCII文字に独占的にエンコードされます。
Security considerations:
セキュリティの考慮事項：
o Reliability and consistency: none of the BP endpoints identified by the URIs of the IPN scheme are guaranteed to be reachable at any time, and the identity of the processing entities operating on those endpoints is never guaranteed by the Bundle Protocol itself. Bundle authentication as defined by the Bundle Security Protocol is required for this purpose.
Oの信頼性と一貫性：IPNスキームのURIので識別BPエンドポイントのいずれもが、いつでも到達可能であることが保証されており、それらのエンドポイント上で動作する処理エンティティのアイデンティティは、バンドルプロトコル自体によって保証されることはありません。バンドルセキュリティプロトコルで定義されたバンドル認証は、この目的のために必要とされます。
o Malicious construction: malicious construction of a conformant IPN-scheme URI is limited to the malicious selection of node numbers and the malicious selection of service numbers. That is, a maliciously constructed IPN-scheme URI could be used to direct a bundle to an endpoint that might be damaged by the arrival of that bundle or, alternatively, to declare a false source for a bundle and thereby cause incorrect processing at a node that receives the bundle. In both cases (and indeed in all bundle processing), the node that receives a bundle should verify its authenticity and validity before operating on it in any way.
悪意のある建設O：準拠IPN-スキームの悪意のある構成URIは、ノード番号の悪意のある選択及びサービス番号の悪意の選択に制限されます。つまり、URIは、あるいは、バンドルの偽のソースを宣言し、それによってノードに誤った処理を引き起こすそのバンドルの到着によって損傷する可能性があるエンドポイントにバンドルを指示するために使用することができる悪意構築IPN-方式でありますそれは、バンドルを受け取ります。両方の場合（実際にすべてのバンドル処理中）に、バンドルを受信するノードは、何らかの方法でそれを操作する前に、その信憑性と有効性を検証すべきです。
o Back-end transcoding: the limited expressiveness of URIs of the IPN scheme effectively eliminates the possibility of threat due to errors in back-end transcoding.
Oバックエンドのトランスコーディング：IPNスキームのURIの限られた表現が効果的に起因するバックエンドのトランスコーディングのエラーに脅威の可能性を排除します。
o Rare IP address formats: not relevant, as IP addresses do not appear anywhere in conformant IPN-scheme URIs.
OレアIPアドレス形式：IPアドレスがどこかに準拠IPN-スキームのURIで表示されないよう、関係ありません。
o Sensitive information: because IPN-scheme URIs are used only to represent the identities of Bundle Protocol endpoints, the risk of disclosure of sensitive information due to interception of these URIs is minimal. Examination of IPN-scheme URIs could be used to support traffic analysis; where traffic analysis is a plausible danger, bundles should be conveyed by secure convergence-layer protocols that do not expose endpoint IDs.
O機密情報：IPN-スキームのURIがバンドルプロトコルエンドポイントのアイデンティティを表現するためにのみ使用されるため、原因これらのURIの傍受に機密情報の開示のリスクは最小限です。 IPN-スキームのURIの検討は、トラフィック分析をサポートするために使用することができ、トラフィック解析がもっともらしい危険であり、バンドルは、エンドポイントのIDを公開していない安全な収束層プロトコルによって伝達されなければなりません。
o Semantic attacks: the simplicity of IPN-scheme URI syntax minimizes the possibility of misinterpretation of a URI by a human user.
セマンティック攻撃○：IPN-スキームURI構文のシンプルさは、人間のユーザによってURIの誤解の可能性を最小限に抑えることができます。
Contact: Scott Burleigh Jet Propulsion Laboratory, California Institute of Technology scott.c.burleigh@jpl.nasa.gov +1 (800) 393-3353
連絡先：スコット・バーレイジェット推進研究所、カリフォルニア工科大学が+1（800）393から3353をscott.c.burleigh@jpl.nasa.gov
Author/Change controller: Scott Burleigh Jet Propulsion Laboratory, California Institute of Technology scott.c.burleigh@jpl.nasa.gov +1 (800) 393-3353
著者/変更コントローラ：スコット・バーレイジェット推進研究所、カリフォルニア工科大学scott.c.burleigh@jpl.nasa.gov +1（800）393から3353
References: S. Burleigh, "Compressed Bundle Header Encoding (CBHE)", RFC 6260, May 2011.
参考文献：S.バーレイ、 "圧縮バンドルヘッダーエンコーディング（CBHE）"、RFC 6260、2011年5月。
The Bundle Security Protocol (BSP) may, under some conditions, insert additional endpoint ID strings into the dictionary of a bundle and reference those strings in BSP extension blocks. Because a bundle that includes any extension blocks containing EID-references to endpoint IDs other than the block's destination, source, report-to, and current custodian cannot be CBHE compressed, bundles cannot be compressed under those conditions.
バンドルセキュリティプロトコル（BSP）は、いくつかの条件の下で、バンドルの辞書に追加のエンドポイントIDの文字列を挿入し、BSP拡張ブロックにそれらの文字列を参照することができます。ブロックのデスティネーション、ソース以外のIDをエンドポイントするEID-参照を含む任意の拡張ブロックを含むバンドルのため、レポートに、および現在カストディアンがCBHEを圧縮することができない、バンドルは、これらの条件下で圧縮することができません。
Specifically, the specification detailed above implies that a bundle cannot be CBHE compressed when the security-source endpoint for the Bundle Authentication Block (BAB) is noted in the dictionary (typically, because there is no other way for the receiving bundle protocol agent to determine the security-source endpoint); when the security-destination endpoint for the BAB is noted in the dictionary (in the rare case that the receiving endpoint is not the security-destination endpoint); when the security-source endpoint for the Payload Integrity Block (PIB), Payload Confidentiality Block (PCB), or Extension Security Block (ESB) is not the source endpoint; or when the security-destination endpoint for the PIB, PCB, or ESB is not the destination endpoint.
具体的には、上記の詳細な仕様は、受信バンドルプロトコルエージェントが決定するための他の方法がないため、バンドル認証ブロック（BAB）のセキュリティ・ソースエンドポイントが、典型的には（辞書に留意されたいときに束CBHEを圧縮することができないことを意味しますセキュリティ・ソースエンドポイント）。 BABのセキュリティ先エンドポイントは、（受信側エンドポイントがセキュリティ宛先エンドポイントでない稀な場合に）辞書に記録されたときに、場合ペイロード整合ブロック（PIB）、ペイロード機密性ブロック（PCB）、または拡張セキュリティ・ブロック（ESB）のセキュリティ・ソースエンドポイントがソースエンドポイントはありません。またはPIB、PCB、またはESBのセキュリティ先エンドポイントは、宛先エンドポイントでないとき。
Also, the CBHE-conformance inference mechanism identified in Section 3.2 introduces a possible denial-of-service attack. Malicious code could issue a CHBE-compressed bundle whose source EID falsely identifies the bundle origin as some node whose CLA is not CBHE conformant; a CBHE-conformant CLA receiving this bundle might incorrectly infer that the CLA at the purported source node was CBHE conformant and might then begin CBHE compressing all bundles that it sends to that node, thus preventing those bundles from being dispatched by the node's bundle protocol agent. Nodes can defend against such an attack by requiring Bundle Authentication Blocks and discarding any inference of CBHE conformance for the CLAs at nodes from which inauthentic bundles are received.
また、3.2節で識別CBHE-適合推論メカニズムは、可能なサービス拒否攻撃を紹介します。悪意のあるコードは、そのソースEIDが誤っCLA CBHE適合しないいくつかのノードとしてバンドル起源を識別するCHBE圧縮バンドルを発行することができます。このバンドルを受けCBHE準拠CLAは間違って主張ソースノードでのCLAはCBHE準拠し、次いでこれノードのバンドルプロトコルエージェントによってディスパッチされることから、これらのバンドルを防止すること、それがそのノードに送信するすべてのバンドルを圧縮CBHEを始めるかもしれないと推測するかもしれません。ノードは、バンドル認証ブロックを必要と本物でない束が受信されるノードにおけるCLAへの同意のためCBHE適合性の任意の推論を廃棄することによって、そのような攻撃を防御することができます。
These caveats aside, CBHE introduces no new security considerations beyond those discussed in the DTN Bundle Protocol RFC 5050 [RFC5050] and Bundle Security Protocol RFC 6257 [RFC6257] Specifications.
これらの警告はさておき、CBHEはDTNバンドルプロトコルRFC 5050 [RFC5050]とバンドルセキュリティプロトコルのRFC 6257 [RFC6257]仕様で論じたものを超えてどんな新しいセキュリティ問題も紹介しません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007.
[RFC5050]スコット、K.およびS.バーリー、 "バンドルプロトコル仕様"、RFC 5050、2007年11月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、STD 68、RFC 5234、2008年1月。
[RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell, "Bundle Security Protocol Specification", RFC 6257, May 2011.
[RFC6257]シミントン、S.、ファレル、S.、ワイス、H.、およびP.ラヴェル、 "バンドルセキュリティプロトコル仕様"、RFC 6257、2011年5月。
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 35, RFC 4395, February 2006.
[RFC4395]ハンセン、T.、ハーディ、T.、およびL. Masinter、 "新しいURIスキームのためのガイドラインと登録手順"、BCP 35、RFC 4395、2006年2月。
Appendix A. Acknowledgments
付録A.謝辞
This research was carried out at the Jet Propulsion Laboratory, California Institute of Technology, under a contract with the National Aeronautics and Space Administration. Government sponsorship acknowledged.
この研究は国立航空宇宙局との契約の下で、ジェット推進研究所、カリフォルニア工科大学で行いました。政府の後援を認めました。
Author's Address
著者のアドレス
Scott Burleigh Jet Propulsion Laboratory, California Institute of Technology 4800 Oak Grove Drive, m/s 301-490 Pasadena, CA 91109 USA
スコット・バーレイジェット推進研究所、カリフォルニア工科大学4800オークグローブドライブ、M / S 301から490パサデナ、CA 91109 USA
Phone: +1 818 393 3353 EMail: Scott.C.Burleigh@jpl.nasa.gov
電話：+1 818 393 3353 Eメール：Scott.C.Burleigh@jpl.nasa.gov