[要約] RFC 6260は、Compressed Bundle Header Encoding（CBHE）の仕様を定義しています。CBHEは、バンドルヘッダの圧縮形式を提供し、無線ネットワークでの効率的なデータ転送を目指しています。
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)
圧縮バンドルヘッダーエンコーディング（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.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。このドキュメントは、インターネット研究タスクフォース（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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 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.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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]「Convergence-Layer」アダプターが、バンドルの主要なブロック内で圧縮された形式でエンドポイント識別子（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バンドルのプライマリブロックには、次の4つのBPエンドポイント識別子が含まれています。そのうちの2つ、3つ、または4つすべてが字句的に同一になる場合があります。各EIDは、[RFC3986]で定義されている均一なレコード識別子（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.
一次ブロックの設計によって、ある程度のブロック圧縮が提供されます。4つのエンドポイントのIDのスキーム名とスキーム固有の部分（最大8つのヌルターミネート文字列）は、ブロックの最後に連結されています。「辞書」と呼ばれる可変長さの文字配列があり、各EIDを、EIDのスキーム名とスキーム固有の部分のオフセット（辞書内）を示す整数のペアで表現できるようにします。重複する文字列は辞書から省略される可能性があるため、辞書の実際の連結ヌル終端文字列の数は8未満であり、ブロック内のスキーム名またはスキーム固有のパーツオフセットの2つ以上が同じ値を持つ場合があります。。さらに、プライマリブロックの8つのオフセットは、エンコードされた値に適合するように縮小する自己決定数値（SDNV）としてエンコードされます。辞書の全長が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).
ただし、これらの戦略は、スキーム名、特にスキーム固有のパーツ自体がASCIIテキストの長い文字列であることを妨げるものではありません。したがって、バンドルのペイロードが比較的小さい場合、バンドルのプライマリヘッダーの長さがバンドルの全長の非常に大きな割合になる可能性があります。いずれにせよ、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を表すためにCombngence-Layerアダプターが使用するバイト数をさらに減らすことにより、このようなアプリケーションの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 Eidsの唯一の有効なスキーム名は「DTN」です。「DTN」スキーム内で構成されているURISの有効な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適合」である場合にのみ可能です。次の2つの形式のエンドポイントIDは、CBHEの適合です。（a）nullエンドポイントID "dtn：none"および（b）「IPN」スキーム内で形成されたエンドポイント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. URIの「ノード番号」と呼ばれる範囲1から（2^64-1）の範囲の整数を表すASCII数値のシーケンス。
2. An ASCII period ('.') character.
2. ASCII期間（ '。'）文字。
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. URIの「サービス番号」と呼ばれる範囲0〜（2^64-1）の範囲の整数を表すASCII数字のシーケンス。
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）より大きいネガティブ整数と整数は、スキーム名の表現に使用されるSDNVにエンコードできないため、バンドルの主要なブロックのSSPオフセットにエンコードできないため、圧縮できないため、ノード番号として使用できません。この仕様で後述するように。ノード番号ゼロは、後で説明する圧縮形式のヌルエンドポイントIDの表現のために予約されています。圧縮されたnull eidを減圧すると、常に標準のnullエンドポイントid uri "dtn：none"を生成する必要があります。
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.
したがって、2つの整数のタプルへのCBHEコンフォーマントEidの変換は簡単です。ノード番号とサービス番号以外のEIDのすべての文字は一定です（「IPN」スキーム定義で定義されています）、ノード番号はサービス番号は、タプルの2つの整数と見なされます。この変換の容易さにより、整数のペアの配列がASCII String Eidsの辞書と同じ機能を提供することができます。
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圧縮のさらなる前提条件は、圧縮されるバンドルは、この順序で、追加なしで正確に次のとおりでなければなりません。
1. The scheme name of the destination endpoint ID.
1. 宛先エンドポイントIDのスキーム名。
2. The scheme-specific part of the destination endpoint ID.
2. 宛先エンドポイントIDのスキーム固有の部分。
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.
注：この制約は、ブロックの宛先、ソース、レポートツー、および現在のカストディアン以外のエンドポイントIDへのEID参照を含む拡張ブロックを含むバンドルが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が圧縮されたプライマリブロックでは、通常EIDSのスキーム名と辞書内のSSPオフセットを含む8つのSDNVが、代わりに、以下にリストされている8つの整数値を含むために使用されます。
1. The node number of the destination endpoint ID, or zero if the destination endpoint is the null endpoint.
1. 宛先エンドポイントIDのノード番号、または宛先エンドポイントがnullエンドポイントである場合はゼロ。
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のノード番号、またはソースエンドポイントがnullエンドポイントである場合はゼロ。
4. The service number of the source endpoint ID, or zero if the source endpoint is the null endpoint.
4. ソースエンドポイントIDのサービス番号、またはソースエンドポイントがnullエンドポイントである場合はゼロ。
5. The node number of the report-to endpoint ID, or zero if the report-to endpoint is the null endpoint.
5. レポートツーエンドポイントIDのノード番号、またはレポートツーエンドポイントがnullエンドポイントである場合はゼロ。
6. The service number of the report-to endpoint ID, or zero if the report-to endpoint is the null endpoint.
6. レポートツーエンドポイントIDのサービス番号、またはレポートツーエンドポイントがnullエンドポイントである場合はゼロ。
7. The node number of the current custodian endpoint ID, or zero if the current custodian endpoint is the null endpoint.
7. 現在のカストディアンエンドポイントがnullエンドポイントである場合、現在のカストディアンエンドポイントIDのノード番号、またはゼロ。
8. The service number of the current custodian endpoint ID, or zero if the current custodian endpoint is the null endpoint.
8. 現在のカストディアンエンドポイントがnullエンドポイントである場合、現在のカストディアンエンドポイント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コンフォーマントである（またはそうかもしれない）かどうかについての知識は、ノード投与によって主張される可能性があります。
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は、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.
この仕様では、[RFC5234]の[RFC5234]の拡張されたBackus-Naurフォーム（ABNF）表記を使用します。これには、その仕様で定義された桁のコア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
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スキームセマンティクス：IPNスキームのURISは、セクション2.1で説明されているように、遅延耐性ネットワーク（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エンドポイントは、いつでも到達可能であることが保証されておらず、それらのエンドポイントで動作する処理エンティティのIDは、バンドルプロトコル自体によって保証されません。この目的には、バンドルセキュリティプロトコルによって定義されているバンドル認証が必要です。
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-Scheme URIの悪意のある構造は、ノード番号の悪意のある選択とサービス番号の悪意のある選択に限定されています。つまり、悪意のあるIPN-Scheme URIを使用して、そのバンドルの到着によって損傷する可能性のあるエンドポイントにバンドルを向けることができます。それはバンドルを受け取ります。どちらの場合も（そして実際にはすべてのバンドル処理で）、バンドルを受信するノードは、何らかの方法で操作する前にその信ity性と有効性を確認する必要があります。
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-Scheme URISのどこにも表示されないため、関連性がありません。
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-Scheme URIは、バンドルプロトコルエンドポイントのアイデンティティを表すためにのみ使用されるため、これらのURIの傍受による機密情報の開示のリスクは最小限です。IPN-Scheme URISの検査は、トラフィック分析をサポートするために使用できます。トラフィック分析がもっともらしい危険である場合、エンドポイントIDを公開しない安全な収束層プロトコルによってバンドルを伝える必要があります。
o Semantic attacks: the simplicity of IPN-scheme URI syntax minimizes the possibility of misinterpretation of a URI by a human user.
o セマンティック攻撃：IPN-Scheme URI構文の単純さは、人間のユーザーによるURIの誤解の可能性を最小限に抑えます。
Contact: 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、スコットバーリージェット推進研究所Scott.C.Burleigh@jpl.nasa.gov 1
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-referencesを含む拡張ブロックを含むバンドルを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コンフォーマンス推論メカニズムは、サービス拒否攻撃の可能性を導入します。悪意のあるコードは、CHBE圧縮バンドルを発行する可能性があります。そのソースEIDは、CLAがCBHE適合性ではないいくつかのノードとしてバンドル起源を誤って識別します。このバンドルを受け取るCBHEコンフォータントCLAは、主張されたソースノードのCLAが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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、2005年1月。
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007.
[RFC5050] Scott、K。およびS. Burleigh、「バンドルプロトコル仕様」、RFC 5050、2007年11月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、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] Symington、S.、Farrell、S.、Weiss、H。、およびP. Lovell、「バンドルセキュリティプロトコル仕様」、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] Hansen、T.、Hardie、T.、およびL. Masinter、「新しいURIスキームのガイドラインと登録手順」、BCP 35、RFC 4395、2006年2月。
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パサデナ、カリフォルニア州91109 USAのスコットバーリージェット推進研究所4800オークグローブドライブ
Phone: +1 818 393 3353
EMail: Scott.C.Burleigh@jpl.nasa.gov