Internet Research Task Force (IRTF) S. Symington
Request for Comments: 6258 The MITRE Corporation
Category: Experimental May 2011
ISSN: 2070-1721
Delay-Tolerant Networking Metadata Extension Block
Abstract
抽象
This document defines an extension block that may be used with the Delay-Tolerant Networking (DTN) Bundle Protocol. This Metadata Extension Block is designed to carry additional information that DTN nodes can use to make processing decisions regarding bundles, such as deciding whether to store a bundle or determining to which nodes to forward a bundle. The metadata that is carried in a metadata block must be formatted according to the metadata type that is identified in the block's metadata type field. One specific metadata type, for carrying URIs as metadata, is defined in this document. Other metadata types may be defined in separate documents. 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.
この文書では、遅延耐性ネットワーク（DTN）バンドルプロトコルと共に使用することができる拡張ブロックを定義します。このメタデータの拡張ブロックは、DTNノードは、このようなバンドルを保存するかどうかを決定またはバンドルを転送するノードにするかを決定するようバンドルを、に関する処理決定を行うために使用できる追加情報を運ぶように設計されています。メタデータブロックに搭載されたメタデータは、ブロックのメタデータタイプフィールドで識別されたメタデータの種類に応じてフォーマットする必要があります。一つの特定のメタデータ・タイプは、メタデータとしてURIを運ぶために、このドキュメントで定義されています。その他のメタデータ・タイプは、別の文書で定義されていてもよいです。この文書では、遅延耐性ネットワーク研究グループの製品であり、そのグループによって検討されています。 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/rfc6258.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6258で取得することができます。
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 ......................................4
2. Metadata Block Format ...........................................4
3. Metadata Block Processing .......................................5
3.1. Bundle Transmission ........................................6
3.2. Bundle Forwarding ..........................................6
3.3. Bundle Reception ...........................................6
4. Predefined Metadata Types .......................................6
4.1. URI Metadata Type ..........................................6
4.2. Private Metadata Types .....................................7
5. Security Considerations .........................................7
6. IANA Considerations .............................................8
6.1. Metadata Type Codes ........................................8
6.2. Block Type Code for the Metadata Block .....................9
7. References ......................................................9
7.1. Normative References .......................................9
7.2. Informative References .....................................9
This document defines an extension block that may be used with the Bundle Protocol [RFC5050] within the context of a Delay-Tolerant Networking architecture [RFC4838]. The DTN Bundle Protocol [RFC5050] defines the bundle as its protocol data unit. This document defines a bundle block called a "metadata block". This block is designed to carry additional information that DTN nodes can use to make processing decisions regarding bundles.
この文書では、遅延耐性ネットワークアーキテクチャ[RFC4838]のコンテキスト内でバンドルプロトコル[RFC5050]と共に使用することができる拡張ブロックを定義します。 DTNバンドルプロトコル[RFC5050]は、そのプロトコルデータユニットとしてバンドルを定義します。この文書では、「メタデータブロック」と呼ばれるバンドルブロックを定義します。このブロックは、DTNノードがバンドルに関する処理決定を行うために使用できる追加情報を運ぶために設計されています。
The metadata block has been deliberately defined to be flexible enough that it would be capable of supporting a variety of metadata types and formats. Indeed, the only restriction imposed on the metadata to be used is that its type and format be predefined and registered (if public) so that it can be parsed and processed by DTN nodes that support metadata of that type. Section 4 defines a
メタデータブロックは、意図的に、それは、メタデータの種類と様々なフォーマットをサポートすることができるであろうことは十分に柔軟であると定義されています。実際、使用するメタデータに課される唯一の制限は、（パブリック場合）、それはそのタイプのメタデータをサポートするDTNノードによって解析して処理することができるように、その種類及び形式が事前定義し、登録することです。セクション4で定義され
specific metadata type and discusses the use of other metadata types that may be defined elsewhere. As mentioned, it is the intention that the metadata that is carried in this block be application-related information. For example, the metadata might be information that is associated with the payload of a bundle. Additional extension blocks could be (and have been) defined for carrying additional network-related information.
特定のメタデータ・タイプとは別の場所で定義されてもよい他のメタデータタイプの使用を論じています。上述したように、このブロックにおいて実行されるメタデータは、アプリケーション関連情報であることを意図しています。例えば、メタデータは、バンドルのペイロードに関連付けられた情報であるかもしれません。追加の拡張ブロックは、することができた（とされている）追加のネットワーク関連情報を搬送するために定義されました。
While the bundle payload may be processed opaquely by DTN nodes, metadata is intended to serve as a mechanism for providing DTN nodes with access to additional information that they can use to process the bundle. Examples of such additional information include keywords found in the payload; payload provenance information; GPS coordinates (if the payload is a map, for instance); message IDs; and artist, album, and track name (if the payload is a song). Even though the metadata is additional information related to the application, its purpose is to be used by DTN nodes to make decisions regarding how to process bundles within the network, such as whether or not a bundle should be stored or to which nodes a bundle should be forwarded. Metadata that is about bundle payload, for example, might serve as a content-based index of bundles that are stored in a DTN cache. So, in response to a request for bundles related to a certain subject or related to specific GPS coordinates, for example, the metadata of stored bundles could be searched, and all bundles with metadata matching the search criteria could be retrieved and returned to the requestor.
バンドルペイロードがDTNノードによって不透明に処理することができるが、メタデータは、それらがバンドルを処理するために使用できる追加情報へのアクセスをDTNノードを提供するためのメカニズムとして機能することが意図されています。そのような追加情報の例には、ペイロードに見出されるキーワードを含みます。ペイロード出所情報。 GPS座標（ペイロードは、例えば、地図の場合）。メッセージID。そして、アーティスト、アルバム、およびトラック名（ペイロードは歌である場合）。メタデータは、アプリケーションに関連する追加情報であっても、その目的は、ネットワーク内のバンドルを処理する方法に関する決定を行うためにDTNノードによって使用される、そのような束は保存されるべきか否かのような、またはこれにバンドルノードべき転送されます。バンドルペイロードについてですメタデータは、例えば、DTNキャッシュに格納されているバンドルのコンテンツベースのインデックスとなる恐れがあります。だから、特定の主題に関連する、または特定のGPS座標に関連するバンドルの要求に応じて、例えば、格納されたバンドルのメタデータを検索することができ、検索条件に一致するメタデータを持つすべてのバンドルが取得され、要求元に返される可能性が。
This document defines the general format of and the processing required to support the metadata block. The actual metadata to be inserted into a metadata block MUST be formatted according to the metadata type that is identified in the block's metadata type field. One specific metadata type, for carrying Uniform Resource Identifiers (URIs) [RFC3986] as metadata, is defined in this document. Other metadata types may be defined in separate documents, along with the steps required to process records of that type, if necessary. If such other metadata types are defined, they should be registered to ensure global uniqueness (see the IANA Considerations section).
この文書は、一般的なフォーマット及びメタデータブロックをサポートするために必要な処理を定義します。実際のメタデータは、ブロックのメタデータ・タイプ・フィールドで識別されたメタデータの種類に応じてフォーマットする必要があり、メタデータブロックに挿入されます。一つの特定のメタデータ・タイプ、メタデータとして[RFC3986] Uniform Resource Identifier（URI）を運ぶため、この文書で定義されています。必要に応じて他のメタデータタイプは、そのタイプのレコードを処理するために必要な手順とともに、別の文書で定義されてもよいです。そのような他のメタデータの種類が定義されている場合、彼らは（IANAの考慮事項のセクションを参照してください）グローバルな一意性を保証するために登録する必要があります。
The capabilities described in this document are OPTIONAL for deployment with the Bundle Protocol. As defined in this document, Bundle Protocol implementations claiming to support the metadata block MUST be capable of:
この文書で説明する機能は、バンドルプロトコルで展開するためのオプションです。この文書で定義されているように、メタデータブロックをサポートするために主張バンドルプロトコルの実装は、ことができなければなりません。
- generating a metadata block and inserting it into a bundle,
- メタデータブロックを生成し、束に挿入、
- receiving bundles containing a metadata block and making the information contained in this metadata block's metadata field available for use, e.g., in bundle storage or forwarding decisions, and
- メタデータのブロックを含有し、例えば利用可能なこのメタデータブロックのメタデータフィールドに含まれる情報を作り、バンドルストレージまたは転送の決定に、及び受信バンドル
- deleting a metadata block from a received bundle before forwarding the bundle.
- バンドルを転送する前に受信されたバンドルからのメタデータ・ブロックを削除します。
Bundle Protocol implementations claiming to support a specific metadata type must both support the metadata block as defined above and be capable of parsing and processing the metadata itself according to the definition of the metadata type in which the metadata is expressed. This metadata type may be the URI metadata type (see the URI metadata type section), or it may be another metadata type defined in a separate document.
特定のメタデータ・タイプをサポートすると主張バンドルプロトコル実装は、メタデータが表現されたメタデータ・タイプの定義によれば、メタデータ自体を上記で定義したメタデータブロックをサポートし、解析および処理することができなければならないの両方。このメタデータ・タイプは、URIのメタデータ型（URIメタデータ・タイプの項を参照）であってもよいし、別の文書で定義された別のメタデータ・タイプであってもよいです。
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 metadata block uses the Canonical Bundle Block Format as defined in the Bundle Protocol [RFC5050]. That is, it is comprised of the following elements, which are defined as in all bundle protocol blocks except the primary bundle block. (Note that Self-Delimiting Numeric Value (SDNV) encoding is described in the Bundle Protocol.):
バンドルプロトコル[RFC5050]で定義されるように、メタデータブロックが標準バンドルブロックフォーマットを使用します。つまり、一次バンドルブロックを除くすべてのバンドル・プロトコル・ブロックのように定義され、以下の要素で構成されています。 （自己区切り数値（SDNV）符号化がバンドルプロトコルに記載されていることに注意してください。）：
- Block-type code (1 byte) - defined as in all bundle protocol blocks except the primary bundle block (as described in the Bundle Protocol). The block-type code for the metadata block is 0x08.
- ブロックタイプコード（1バイト） - （バンドルプロトコルに記載されているように）一次バンドルブロックを除くすべてのバンドルプロトコルブロックで定義した通り。メタデータブロックのブロックタイプのコードが0x08にあります。
- Block processing control flags (SDNV) - defined as in all bundle protocol blocks except the primary bundle block. SDNV encoding is described in the Bundle Protocol. There are no constraints on the use of the block processing control flags. If a bundle node receives a bundle with a metadata block and it is capable of supporting the metadata block but it is not able to parse and process the metadata itself, either because it does not support the metadata type being used or because the metadata is not well-formed according to the metadata type definition, the bundle node must process the bundle as if it cannot process the metadata block. That is, it must operate according to the settings of the block processing control flags, including the "Delete bundle if block can't be processed" flag and the "Discard block if it can't be processed" flag.
- ブロック処理制御フラグ（SDNV） - 一次バンドルブロックを除くすべてのバンドルプロトコルブロックで定義した通り。 SDNV符号化はバンドルプロトコルに記載されています。ブロック処理制御フラグの使用には制約がありません。バンドルノードは、メタデータブロックとバンドルを受信し、メタデータ・ブロックをサポートすることができるが、それは使用されているメタデータ・タイプをサポートしていないためか、メタデータがないので、どちらか、メタデータ自体を解析して処理することができない場合メタデータ型定義によれば、十分に形成されたことがメタデータ・ブロックを処理できないかのように、バンドル・ノードは、バンドルを処理しなければなりません。つまり、フラグを「それは処理できない場合は破棄ブロック」フラグと「ブロックが処理できない場合、バンドルを削除する」を含む、ブロック処理制御フラグの設定に従って動作しなければなりません。
- Block EID-reference count and EID-references (optional) - composite field defined in the Bundle Protocol that is present if and only if the metadata block references EID elements in the primary block's dictionary. Presence of this field is indicated by the setting of the "Block contains an EID-reference field" bit of the block processing control flags. If EIDs are referenced in the metadata block, then their interpretation is defined by the particular metadata type that is being used in this metadata block, as indicated in the metadata type field.
- ブロックEID-参照カウントとEID-参照（オプション） - 存在しているバンドルプロトコルで定義された複合フィールド場合にのみ、一次ブロックの辞書内のメタデータブロック参照のEID要素場合。このフィールドの存在は、ブロック処理制御フラグのビット「ブロックがEID-参照フィールドが含まれている」の設定で示されています。 EIDは、メタデータブロックで参照される場合、それらの解釈は、メタデータ型フィールドに示されているように、このメタデータブロックで使用されている特定のメタデータ・タイプによって定義されます。
- Block data length (SDNV) - defined as in all bundle protocol blocks except the primary bundle block. SDNV encoding is described in the Bundle Protocol.
- ブロックデータ長（SDNV） - 一次バンドルブロックを除くすべてのバンドルプロトコルブロックで定義した通り。 SDNV符号化はバンドルプロトコルに記載されています。
- Block-type-specific data fields as follows:
- ブロック型固有のデータ・フィールドを次のように：
- Metadata Type field (SDNV) - indicates which metadata type is to be used to interpret both the metadata in the metadata field and the EID-references in the optional Block EID-reference count and EID-references field (if present). One metadata type is defined in this document. Other metadata types may be defined in separate documents.
- メタデータタイプフィールド（SDNVは） - メタデータフィールド内のメタデータと任意のブロックのEID-参照カウントとEID-参照フィールドにおけるEID-参照（存在する場合）の両方を解釈するために使用されるべきメタデータのタイプを示しています。 1つのメタデータ・タイプは、この文書で定義されています。その他のメタデータ・タイプは、別の文書で定義されていてもよいです。
- Metadata field - contains the metadata itself, formatted according to the metadata type that has been specified for this block. One metadata type is defined in Section 4.1. Other metadata types may be defined elsewhere, as discussed in Section 4.
- メタデータフィールド - このブロックのために指定されているメタデータ型に従ってフォーマット、メタデータ自体を含んでいます。 1つのメタデータ・タイプは、セクション4.1で定義されています。セクション4で説明したように他のメタデータ・タイプは、他の場所で定義されてもよいです。
The structure of a metadata block is as follows:
次のように、メタデータブロックの構造は以下の通りであります：
Metadata Block Format:
+-----+------+--------------------+------+----------+----------|
|Type |Flags |EID-Reference count |Len | Metadata | Metadata |
| |(SDNV)| and list (opt) |(SDNV)| Type | |
+-----+------+--------------------+------+----------+----------+
Figure 1
図1
The following are the processing steps that a bundle node may take relative to generation, reception, and processing of metadata blocks.
以下は、バンドルノードはメタデータブロックの生成、受信、および処理に対して取ることができる処理ステップです。
When an outbound bundle is created per the parameters of the bundle transmission request, this bundle MAY (as influenced by local policy and the metadata type being used) include one or more metadata blocks (as defined in this specification).
アウトバウンドバンドルは、バンドル送信要求のパラメータごとに作成されたときに、このバンドルMAYは（ローカル・ポリシーおよび使用されているメタデータの種類によって影響される）（本明細書で定義されるような）1つ以上のメタデータブロックを含みます。
A node MAY insert one or more metadata blocks into a bundle before forwarding it; and a node MAY delete one or more metadata blocks from a bundle before forwarding it, as dictated by local policy and the metadata type being used.
ノードは、それを転送する前に、バンドルの中に1つ以上のメタデータブロックを挿入することができます。ノードは、ローカル・ポリシーおよび使用されているメタデータの種類によって決定されるように、それを転送する前に、バンドルから1つ以上のメタデータブロックを削除してもよいです。
If the bundle includes one or more metadata blocks, the metadata information records in these blocks SHALL be made available for use at this node (e.g., in bundle storage or forwarding decisions, or, if the receiving node is the bundle-destination, the metadata information records may be provided to the receiving application).
バンドルは、1つ以上のメタデータ・ブロックが含まれている場合、受信ノードは、バンドル先であれば、これらのブロックのメタデータ情報レコードは、バンドルストレージまたは転送決定に、例えば（このノードでの使用のために利用可能に、またはされるべきであり、メタデータ情報レコード）を受信側アプリケーションに提供されてもよいです。
As mentioned in the previous section, any number of different metadata types may be defined to indicate the format of both the metadata field and the EID-references in the optional Block EID-reference count and EID-references field (if present) and, if necessary, how metadata of this type should be processed. One metadata type is defined in this document, URI metadata type (0x01). In addition, a range of metadata type values is reserved for private use.
前節で述べたように、異なるメタデータ・タイプの任意の数の場合、メタデータ・フィールドと任意のブロックEID-参照カウントとEID-参照フィールドにおけるEID-参照（存在する場合）との両方のフォーマットを示すように定義することができます必要に応じて、このタイプのメタデータがどのように処理すべきか。 1つのメタデータ・タイプは、この文書、URIのメタデータタイプ（0×01）で定義されています。また、メタデータ型の値の範囲は、私的使用のために予約されています。
It is believed that use of URIs will, in many cases, be adequate for encoding metadata, although it is recognized that use of URIs may not be the most efficient method for such encoding. Because of the expected utility of using URI encoding for metadata, the metadata type value of 0x01 is defined to indicate a metadata type of URI. Metadata type values other than 0x01 will be used to indicate alternative metadata types.
それはURIの使用は、このようなエンコーディングのための最も効率的な方法ではないかもしれないことを認識されているが、URIの使用は、多くの場合、メタデータを符号化するために適切であると考えられます。なぜならメタデータのURIエンコーディングを使用しての期待効用を、0×01のメタデータ・タイプの値はURIのメタデータのタイプを示すために定義されています。 0x01の以外のメタデータ型の値は、代替メタデータの種類を示すために使用されます。
The Metadata field for metadata of metadata type URI (0x01) consists of an array of bytes formed by concatenating one or more null-terminated URIs. Unless determined by local policy, the specific processing steps that must be performed on bundles with metadata blocks containing metadata of type URI are expected to be indicated as part of the URI encoding of the metadata. It is envisioned that users might define URI schemes for this purpose. Metadata blocks containing metadata of type URI MUST NOT include a Block EID-reference count and EID-references field. The absence of this field MUST be indicated by a value of 0 for the "Block contains an EID-reference field" flag in the block processing control flags. Support for the URI metadata type is OPTIONAL.
メタデータ型URI（0×01）のメタデータのメタデータ・フィールドは、1つまたは複数のヌル終端URIを連結することによって形成されたバイトのアレイからなります。ローカルポリシーによって決定されない限り、タイプURIのメタデータを含むメタデータブロックとバンドル上で実行されなければならない特定の処理ステップは、メタデータのURIエンコードの一部として表示されることが期待されます。これにより、ユーザーは、この目的のためにURIスキームを定義するかもしれないことが想定されます。 URI型のメタデータを含むメタデータ・ブロックは、ブロックEID-参照カウントとEID-参照フィールドを含んではいけません。このフィールドが存在しない場合は、ブロック処理制御フラグに「ブロックEID参照フィールドを含む」フラグのための0の値によって示されなければなりません。 URIのメタデータ型のサポートはオプションです。
Metadata type values 192 through 255 are not defined in this specification and are available for private and/or experimental use. Such private metadata types are not required to be registered. All other values of the metadata type are reserved for future use and, when defined, should be registered to ensure global uniqueness (see the IANA Considerations section). Local policy will define how private metadata types are handled.
メタデータの種類は255 192はこの仕様で定義されており、民間および/または実験的な使用のために用意されていない値。このようなプライベートメタデータの種類が登録されている必要はありません。メタデータタイプの他のすべての値は（IANAの考慮事項のセクションを参照）は、将来の使用のために予約されており、定義された場合、グローバル一意性を保証するために登録されるべきです。ローカルポリシーは、メタデータの種類がどのように処理されるか、民間定義します。
The DTN Bundle Security Protocol [RFC6257] defines security-related blocks to provide hop-by-hop authentication, end-to-end authentication, end-to-end confidentiality of bundles or parts of bundles, and an extension security block to provide confidentiality and integrity for extension blocks, as well as a set of standard ciphersuites that may be used to calculate security-results carried in these security blocks. All ciphersuites that use the strict canonicalization algorithm [RFC6257] to calculate and verify security-results (e.g., many hop-by-hop authentication ciphersuites) apply to all blocks in the bundle and so would apply to bundles that include an optional metadata block and would include that block in the calculation of their security-result. In particular, bundles including the optional metadata block would be protected in their entirety for the duration of a single hop, from a forwarding node to an adjacent receiving node (but not from source to destination over multiple hops), using the standard BAB-HMAC (Bundle Authentication Block - Hashed Message Authentication Code) ciphersuite defined in the Bundle Security Protocol.
DTNバンドルセキュリティプロトコル[RFC6257]は機密性を提供するために、ホップバイホップ認証、エンドツーエンドの認証、束または束の一部のエンドツーエンドの機密性、および拡張セキュリティブロックを提供するために、セキュリティ関連ブロックを定義しますそして、拡張ブロックの完全性、ならびにこれらのセキュリティブロックで運ばセキュリティ結果を計算するために使用することができる標準的な暗号スイートのセット。計算及び検証セキュリティ結果（例えば、多くのホップバイホップ認証暗号スイート）をバンドル内のすべてのブロックに適用されるので、任意のメタデータ・ブロックを含むバンドルに適用されるために、厳密な正規化アルゴリズム[RFC6257]を使用するすべての暗号スイートと彼らのセキュリティ-結果の計算にそのブロックが含まれるであろう。具体的には、オプションのメタデータブロックが標準BAB-HMACを使用して、（ただしソースから複数のホップにわたって宛先へ）転送ノードから隣接受信ノードに、シングルホップの持続時間のためにその全体が保護される含むバンドル（バンドル認証ブロック - ハッシュメッセージ認証コード）バンドルセキュリティプロトコルで定義されている暗号スイート。
Ciphersuites that use the mutable canonicalization algorithm to calculate and verify security-results (e.g., the mandatory PSH-RSA-SHA256 ciphersuite and most end-to-end authentication ciphersuites) will omit the metadata block from their calculation. Therefore, the fact that metadata in the metadata block may be modified or that metadata blocks themselves may be added to or deleted from a bundle as it transits the network will not interfere with end-to-end security protection when using ciphersuites that use mutable canonicalization.
（例えば、必須PSH-RSA-SHA256の暗号スイートとほとんどのエンドツーエンドの認証暗号スイート）セキュリティの結果を計算し検証する可変正規化アルゴリズムを使用する暗号スイートは、それらの計算からメタデータブロックを省略する。それは可変正規化を使用する暗号スイートを使用する場合、ネットワークは、エンドツーエンドのセキュリティ保護を妨害しない遷移したがって、メタデータ・ブロック内のメタデータを修正することができるという事実、またはそのメタデータブロック自体が追加またはバンドルから削除することができます。
The metadata block will not be encrypted by the mandatory CH-RSA-AES-PAYLOAD-PSH end-to-end confidentiality ciphersuite, which only allows for payload and PSH encryption.
メタデータブロックは、ペイロード及びPSH暗号化を可能にする必須CH-RSA-AES-PAYLOAD-PSHのエンドツーエンドの機密暗号スイートによって暗号化されません。
In order to provide the metadata block with end-to-end confidentiality and authentication independent of any confidentiality or authentication that is provided for the payload or other parts of the bundle, the extension security block may be used to encrypt and authenticate the metadata block. A bundle may contain multiple metadata extension blocks. In some cases, multiple metadata blocks may be carried in the bundle, possibly with each being encrypted separately from each other and from the payload. Such separate encryption of metadata from payload would enable bundle nodes to perform content-based searching and routing on bundle metadata that they are able to decrypt, even if they are not able to decrypt the bundle payload.
ペイロードまたはバンドルの他の部分のために提供される任意の機密性または認証のエンドツーエンドの機密性および認証独立してメタデータ・ブロックを提供するために、拡張セキュリティブロックは、メタデータブロックを暗号化し、認証するために使用されてもよいです。バンドルには、複数のメタデータの拡張ブロックを含んでいてもよいです。いくつかのケースでは、複数のメタデータブロックは、おそらくそれぞれが互いにおよびペイロードは別に暗号化されると、バンドルで実施することができます。ペイロードからのメタデータのような別個の暗号化は、彼らがバンドルペイロードを解読することができない場合でも、それらは復号することができるバンドルメタデータのコンテンツベースの検索およびルーティングを実行するために、バンドルノードを可能にします。
Given that metadata can be modified by forwarding nodes, it may be desirable to eventually support the ability to audit changes to the metadata at the individual record level. No such capability has been provided in this specification as currently written.
メタデータは、ノードを転送することによって改変することができることを考えると、最終的に個々のレコードレベルのメタデータへの変更を監査する能力をサポートすることが望ましい場合があります。そのような能力は、現在書かれたとして、この仕様で提供されていません。
The metadata block carried in the Metadata Extension Block has a Metadata Type Code field (see Sections 2 and 3). An IANA registry has been set up as follows.
メタデータの拡張ブロックに運ばメタデータブロックがメタデータタイプコードフィールド（セクション2及び3を参照）を有します。次のようにIANAレジストリが設定されています。
Metadata Type Codes Registry
メタデータのタイプ・コードレジストリ
The registration policy for this registry is: 0-191: Specification Required 192-255: Private and/or Experimental Use. No assignment by IANA.
このレジストリの登録ポリシーがある：0から191：仕様が必要で192から255：プライベートおよび/または実験的に使用します。 IANAによって割り当てなしません。
The Value range is unsigned 8-bit integer.
値の範囲は、符号なし8ビットの整数です。
+---------+---------------------------------+---------------+
| Value | Description | Reference |
+---------+---------------------------------+---------------+
| 0 | Reserved | This document |
| 1 | URI | This document |
| 2-191 | Unassigned | |
| 192-255 | Private and/or experimental use | This document |
+---------+---------------------------------+---------------+
This specification allocates a codepoint from the Bundle Block Type Codes registry defined in [RFC6255] (see Section 2 of this document):
この仕様は、[RFC6255]で定義バンドルブロックタイプコードレジストリ（このドキュメントのセクション2を参照）からのコードポイントを割り当てます。
Additional Entry for the Bundle Block Type Codes Registry:
+-------+----------------------------------------+----------------+
| Value | Description + Reference |
+-------+----------------------------------------+----------------+
| 8 | Metadata Extension Block + This document |
+-------+----------------------------------------+----------------+
[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月。
[RFC6255] Blanchet, M., "Delay-Tolerant Networking (DTN) Bundle Protocol IANA Registries", RFC 6255, May 2010.
[RFC6255]ブランシェ、M.、 "遅延耐性ネットワーク（DTN）バンドルプロトコルIANAレジストリ"、RFC 6255、2010年5月。
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Networking Architecture", RFC 4838, April 2007.
[RFC4838]サーフ、V.、バーレイ、S.、フック、A.、Torgerson、L.、ダースト、R.、スコット、K.、秋、K.、およびH.ワイス、 "遅延耐性ネットワークアーキテクチャ" 、RFC 4838、2007年4月。
[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月。
Author's Address
著者のアドレス
Susan Flynn Symington The MITRE Corporation 7515 Colshire Drive McLean, VA 22102 US
スーザン・フリンシミントンザ・MITRE社7515 Colshireドライブマクリーン、バージニア州22102米国
Phone: +1 (703) 983-7209 EMail: susan@mitre.org URI: http://mitre.org/
電話：+1（703）983-7209 Eメール：susan@mitre.org URI：http://mitre.org/