[要約] RFC 6258は、遅延許容ネットワーキングメタデータ拡張ブロックに関するものであり、遅延許容ネットワーキングプロトコルで使用されるメタデータの拡張機能を提供します。このRFCの目的は、遅延許容ネットワーキングの効率と信頼性を向上させるために、メタデータの拡張機能を定義することです。
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.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。このドキュメントは、インターネット研究タスクフォース（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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
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 ......................................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 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.
メタデータブロックは、さまざまなメタデータの種類と形式をサポートできるほど柔軟であると意図的に定義されています。実際、使用するメタデータに課される唯一の制限は、そのタイプと形式を事前定義および登録して（公開されている場合）、そのタイプのメタデータをサポートするDTNノードで解析および処理できるようにすることです。セクション4では、特定のメタデータタイプを定義し、他の場所で定義できる他のメタデータタイプの使用について説明します。前述のように、このブロックで運ばれるメタデータがアプリケーション関連情報であるという意図です。たとえば、メタデータはバンドルのペイロードに関連付けられている情報である可能性があります。追加のネットワーク関連情報を運ぶために、追加の拡張ブロックを定義できます（および定義されています）。
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).
このドキュメントは、メタデータブロックをサポートするために必要な一般的な形式と処理を定義します。メタデータブロックに挿入される実際のメタデータは、ブロックのメタデータ型フィールドで識別されるメタデータタイプに従ってフォーマットする必要があります。メタデータとして、均一なリソース識別子（URIS）[RFC3986]を運ぶための特定のメタデータタイプがこのドキュメントで定義されています。他のメタデータタイプは、必要に応じて、そのタイプのレコードを処理するために必要な手順とともに、個別のドキュメントで定義できます。そのような他のメタデータタイプが定義されている場合、それらはグローバルな一意性を確保するために登録する必要があります（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.
- Block Eid-Reference count and eid-references（オプション） - メタデータがプライマリブロックの辞書のEID要素を参照している場合にのみ存在するバンドルプロトコルで定義された複合フィールド。このフィールドの存在は、ブロック処理制御フラグのビット「ブロックにはeid-referenceフィールドが含まれています」の設定によって示されます。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-ReferenceカウントとEid-Referencesフィールドの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).
バンドル送信要求のパラメーターごとにアウトバウンドバンドルが作成されると、このバンドルは（ローカルポリシーと使用中のメタデータタイプの影響を受けます）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-referenceカウントとeid-referencesフィールド（存在する場合）のメタデータフィールドとeid-referencesの両方の形式を示すために、任意の数の異なるメタデータタイプを定義することができます。必要に、このタイプのメタデータをどのように処理するか。1つのメタデータタイプは、このドキュメントであるURIメタデータタイプ（0x01）で定義されています。さらに、さまざまなメタデータタイプの値が私的使用のために予約されています。
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エンコードを使用することが予想されるユーティリティのため、0x01のメタデータタイプ値は、メタデータタイプの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（0x01）のメタデータのメタデータフィールドは、1つ以上のヌル終端URIを連結することにより形成されるバイトの配列で構成されています。ローカルポリシーによって決定されない限り、型URIのメタデータを含むメタデータブロックを使用してバンドルで実行する必要がある特定の処理手順は、メタデータのURIエンコードの一部として示されると予想されます。ユーザーがこの目的のためにURIスキームを定義する可能性があると考えられています。型URIのメタデータを含むメタデータブロックには、ブロックEID -ReferenceカウントとEID参照フィールドを含めてはなりません。このフィールドの欠如は、「ブロックにはEid -Referenceフィールドが含まれている」の値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.
メタデータタイプの値192〜255は、この仕様では定義されておらず、プライベートおよび/または実験的な使用に使用できます。このようなプライベートメタデータタイプは登録する必要はありません。メタデータタイプの他のすべての値は将来の使用のために予約されており、定義された場合、グローバルな一意性を確保するために登録する必要があります（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を使用して、転送ノードから隣接する受信ノードまで（ただし、複数のホップでソースから宛先までではなく）、1回のホップの期間中に完全に保護されます。（バンドル認証ブロック-Hashedメッセージ認証コード）バンドルセキュリティプロトコルで定義されたCipherSuite。
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 CIPHERSUITEおよびほとんどのエンドツーエンド認証暗号剤）は、メタデータブロックを計算から省略します。したがって、メタデータブロック内のメタデータが変更される可能性があるか、メタデータブロック自体がバンドルに追加または削除される可能性があります。。
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-AES-AES-PAYLOAD-PSHエンドツーエンドの機密性CipherSuiteによって暗号化されません。
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] 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月。
[RFC6255] Blanchet, M., "Delay-Tolerant Networking (DTN) Bundle Protocol IANA Registries", RFC 6255, May 2010.
[RFC6255] Blanchet、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] Cerf、V.、Burleigh、S.、Hooke、A.、Torgerson、L.、Durst、R.、Scott、K.、Fall、K。、およびH. Weiss、「遅延耐性ネットワーキングアーキテクチャ」、RFC 4838、2007年4月。
[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月。
Author's Address
著者の連絡先
Susan Flynn Symington The MITRE Corporation 7515 Colshire Drive McLean, VA 22102 US
スーザンフリンシミントンマイターコーポレーション7515コルシャードライブマクリーン、バージニア州22102米国
Phone: +1 (703) 983-7209
EMail: susan@mitre.org
URI: http://mitre.org/