[要約] RFC 6259は、遅延に対応したネットワーキングにおける前方挿入ブロックに関するものであり、その目的は、ネットワークの信頼性とパフォーマンスを向上させるために、データ転送の遅延を最小限に抑えることです。
Internet Research Task Force (IRTF) S. Symington
Request for Comments: 6259 The MITRE Corporation
Category: Experimental May 2011
ISSN: 2070-1721
Delay-Tolerant Networking Previous-Hop Insertion Block
遅延トレラントネットワーキング前ホップ挿入ブロック
Abstract
概要
This document defines an extension block for use with the Delay-Tolerant Networking (DTN) Bundle Protocol. This Previous-Hop Insertion Block (PHIB) extension block is designed to be inserted by a forwarding node to provide the endpoint identifier (EID) of an endpoint of which the forwarding node is a member so that this EID may be conveyed to the next-hop receiving node. Knowledge of an EID of an endpoint of which a previous-hop node is a member may be required in some circumstances to support certain routing protocols (e.g., flood routing). If this EID cannot be provided by the convergence layer or other means, the PHIB defines the mechanism whereby the EID can be provided with the bundle. Each PHIB is always removed from the bundle by the receiving node so that its presence within the bundle is limited to exactly one hop. This document defines the format and processing of this PHIB. 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）バンドルプロトコルで使用する拡張ブロックを定義します。この前ホップ挿入ブロック（PHIB）拡張ブロックは、転送ノードによって挿入され、エンドポイントのエンドポイント識別子（EID）を提供するように設計されています。このエンドポイントは、転送ノードがメンバーであるため、このEIDが次のEIDに伝えられるようにします。ホップ受信ノード。特定のルーティングプロトコル（洪水ルーティングなど）をサポートするために、状況によっては、前ホップノードがメンバーであるエンドポイントのEIDの知識が必要になる場合があります。このEIDを収束層またはその他の手段で提供できない場合、PHIBは、EIDをバンドルで提供できるメカニズムを定義します。各PHIBは、受信ノードによって常にバンドルから削除されるため、バンドル内の存在が正確に1つのホップに制限されます。このドキュメントでは、このPHIBの形式と処理を定義しています。このドキュメントは、遅延耐性ネットワーキング研究グループの製品であり、そのグループによってレビューされています。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/rfc6259.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6259で取得できます。
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. Previous-Hop Insertion Block Format .............................4
3. Previous-Hop Insertion Block Processing .........................6
3.1. Bundle Transmission ........................................6
3.2. Bundle Forwarding ..........................................6
3.3. Bundle Reception ...........................................7
4. Security Considerations .........................................8
5. IANA Considerations .............................................9
6. References ......................................................9
6.1. Normative References .......................................9
6.2. Informative References .....................................9
This document defines an extension block for use with the Bundle Protocol [RFC5050] within the context of a Delay-Tolerant Networking architecture [RFC4838]. The DTN Bundle Protocol defines the bundle as its protocol data unit and defines "bundle blocks" to carry data of different types. This document defines an optional bundle block called a Previous-Hop Insertion Block (PHIB).
このドキュメントは、遅延耐性ネットワークアーキテクチャ[RFC4838]のコンテキスト内で、バンドルプロトコル[RFC5050]で使用する拡張ブロックを定義します。DTNバンドルプロトコルは、バンドルをプロトコルデータユニットとして定義し、「バンドルブロック」を定義して、さまざまなタイプのデータを伝達します。このドキュメントは、前ホップ挿入ブロック（PHIB）と呼ばれるオプションのバンドルブロックを定義します。
The PHIB is inserted into a bundle by a forwarding node to provide the endpoint identifier (EID) of an endpoint of which the forwarding node is a member so that this EID may be conveyed to the next-hop receiving node. (Hereafter, an EID of an endpoint of which a node is a member will be referred to as an "M-EID" of that node. A node may have one or more M-EIDs, depending on the number of endpoints to which it belongs. An EID of a singleton endpoint of which a node is a member will be referred to as a "singleton M-EID" of that node.) In situations where there is a requirement that the receiving node be able to determine an M-EID of a forwarding node, but the M-EID of the forwarding node cannot be inferred by the receiving node through existing mechanisms, the forwarding node must explicitly provide this M-EID in the bundle. This specification defines the mechanism whereby a node can insert such an M-EID into a bundle before forwarding it to the bundle's next hop.
PHIBは、転送ノードによってバンドルに挿入され、エンドポイントのエンドポイント識別子（EID）を提供するエンドポイントが提供されているため、このEIDは次のホップ受信ノードに伝達されるようにします。（以下、ノードがメンバーであるエンドポイントのEIDは、そのノードの「m-eid」と呼ばれます。ノードには、エンドポイントの数に応じて1つ以上のm-eidがあります。属します。ノードがメンバーであるシングルトンのエンドポイントのEidは、そのノードの「シングルトンm-eid」と呼ばれます。）受信ノードがm-を決定できるという要件がある状況では、転送ノードのEIDですが、転送ノードのM-EIDは、既存のメカニズムを介して受信ノードによって推測することはできません。この仕様は、ノードがそのようなM-EIDをバンドルに挿入してから、バンドルの次のホップに転送できるメカニズムを定義します。
This previous-hop M-EID information may be used in some circumstances to support various routing protocols. For example, the PHIB could be helpful when implementing flood routing because each receiving node could use the PHIB to determine which EID to exclude from the list of adjacent nodes to which it forwards received bundles as it does its part in flooding the bundle. A node will flood the bundle to all neighboring nodes except for the node from which it received the bundle, as identified in the PHIB.
この前ホップM-EID情報は、さまざまなルーティングプロトコルをサポートするために、状況によっては使用される場合があります。たとえば、各受信ノードがPHIBを使用してどのEIDを使用して、バンドルの洪水に伴う隣接するノードのリストから除外するためにPHIBを使用するためにPHIBを使用できるため、PHIBは役立つ可能性があります。ノードは、PHIBで識別されているように、バンドルを受け取ったノードを除き、バンドルをすべての隣接ノードにあふれさせます。
The PHIB could also be used in conjunction with the Bundle Authentication Block (BAB) of the DTN Bundle Security Protocol [DTNBSP] to provide the security-source EID for the BAB. The PHIB can be used to carry the BAB's security-source EID instead of conveying this EID using a reference in the BAB's EID-reference field or including the EID as part of the BAB's key-information parameters.
PHIBは、DTNバンドルセキュリティプロトコル[DTNBSP]のバンドル認証ブロック（BAB）と組み合わせて使用して、BABにセキュリティソースEIDを提供することもできます。PHIBは、BABのEid -Referenceフィールドでの参照を使用して、またはBABのキー情報パラメーターの一部としてEidを含める代わりに、このEidを伝える代わりに、BABのセキュリティソースEidを運ぶために使用できます。
In many situations, a node that receives a bundle may be able to infer an M-EID of the node that forwarded the bundle. In some situations, however, no M-EID will be able to be inferred by the receiving node. For example, if tunneling DTN bundles across some portion of the DTN network, it is not possible for the node at the receiving end of the tunnel to determine from the convergence layer the M-EID of the node at the sending end of the tunnel. The node at the receiving end of the tunnel will receive an encapsulating bundle from one of its adjacent nodes, and it may be able to tell the M-EID of this adjacent node using the convergence-layer protocol. However, the node at the sending end of the tunnel is most likely not adjacent to the node at the receiving end of the tunnel, so in order for the node at the receiving end of the tunnel to be able to learn the M-EID of the node at the sending end of the tunnel, which is the previous-hop node of the tunneled bundle, the M-EID must be provided within the tunneled bundle. In this case, the PHIB is the vehicle for enabling the node at the sending end of the tunnel to provide its M-EID to the node at the receiving end of the tunnel.
多くの場合、バンドルを受信するノードは、バンドルを転送したノードのM-EIDを推測できる場合があります。ただし、状況によっては、受信ノードによってM-EIDを推測することはできません。たとえば、DTNネットワークの一部にDTNバンドルがバンドルする場合、トンネルの受信端にあるノードが収束層から、トンネルの送信端でノードのm-eidを決定することは不可能です。トンネルの受信端にあるノードは、隣接するノードの1つからカプセル化バンドルを受け取り、Convergence-Layer Protocolを使用してこの隣接するノードのM-EIDに伝えることができる場合があります。ただし、トンネルの送信端にあるノードは、トンネルの受信側のノードに隣接していない可能性が高いため、トンネルの受信側のノードがM-EIDを学習できるようにするためにトンネル付きバンドルの前ホップノードであるトンネルの送信端にあるノードは、トンネル付きバンドル内でM-EIDを提供する必要があります。この場合、PHIBは、トンネルの送信端でノードを有効にするための手段であり、トンネルの受信端にあるノードにM-EIDを提供します。
EIDs may be presented in two ways within the PHIB. If the M-EID of the forwarding node is already in the Dictionary field of the bundle's primary bundle block, the PHIB MAY identify this EID using its Block EID-reference count and EID-reference field. Otherwise, the PHIB MUST identify this EID by providing the EID in its block-type-specific data field. These two alternative ways of presenting EIDs in the PHIB are further discussed in Section 3.
Eidsは、PHIB内で2つの方法で提示される場合があります。転送ノードのM-EIDがすでにバンドルのプライマリバンドルブロックの辞書フィールドにある場合、PHIBはそのブロックEid-ReferenceカウントとEid-Referenceフィールドを使用してこのEIDを識別することができます。それ以外の場合、PHIBは、ブロック型固有のデータフィールドにEIDを提供することにより、このEIDを特定する必要があります。PHIBでEIDを提示するこれら2つの代替方法については、セクション3でさらに説明します。
The lifetime of the PHIB is always exactly one hop in the DTN. If a bundle containing a PHIB is received, the receiving node is assured that this PHIB was inserted by the previous node, assuming all nodes are operating correctly; likewise, this PHIB is not retained with the bundle when the bundle is forwarded. If the bundle is forwarded with a PHIB, this PHIB MUST identify an M-EID of the forwarding node.
PHIBの寿命は、常にDTNの1つのホップです。PHIBを含むバンドルが受信された場合、受信ノードは、すべてのノードが正しく動作していると仮定して、このPHIBが前のノードによって挿入されることを保証します。同様に、このPHIBは、バンドルが転送されたときにバンドルで保持されません。バンドルにPHIBで転送されている場合、このPHIBは転送ノードのM-EIDを識別する必要があります。
This document defines the format and processing of the PHIB. The capabilities described in this document are OPTIONAL for deployment with the Bundle Protocol. Bundle Protocol implementations claiming to support the PHIB MUST be capable of:
このドキュメントでは、PHIBの形式と処理を定義します。このドキュメントで説明されている機能は、バンドルプロトコルを使用した展開にオプションです。PHIBをサポートすると主張するバンドルプロトコルの実装は、次のことができなければなりません。
o generating a PHIB and inserting it into a bundle,
o PHIBを生成してバンドルに挿入する、
o receiving bundles containing a PHIB and making the information contained in this PHIB available for use, e.g., in forwarding decisions, and
o PHIBを含むバンドルを受け取り、このPHIBに含まれる情報を使用できるようにします。
o deleting a PHIB from a bundle
o バンドルからPHIBを削除します
as defined in this document.
このドキュメントで定義されているとおり。
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 PHIB uses the Canonical Bundle Block Format as defined in the Bundle Protocol Specification [RFC5050]. That is, the PHIB 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 also described in the Bundle Protocol Specification:
PHIBは、バンドルプロトコル仕様[RFC5050]で定義されているように、正規のバンドルブロック形式を使用します。つまり、PHIBは次の要素で構成されており、プライマリバンドルブロックを除くすべてのバンドルプロトコルブロックのように定義されています。自己削減数値（SDNV）エンコードは、バンドルプロトコル仕様でも説明されていることに注意してください。
o Block-type code (one byte) - The block-type code for the PHIB is 0x05.
o ブロック型コード（1バイト） - PHIBのブロックタイプコードは0x05です。
o Block processing control flags (SDNV) - The following block processing control flag MUST be set:
o ブロック処理制御フラグ（SDNV） - 次のブロック処理制御フラグを設定する必要があります。
Discard block if it can't be processed
処理できない場合はブロックを破棄します
o Block EID-reference count and EID-references (optional) - composite field defined in [RFC5050] containing a count of EID-references (expressed as an SDNV) followed by an EID-reference (expressed as a pair of SDNVs).
o Block Eid -Reference count and eid-references（オプション） - eid references（SDNVとして表される）の数を含む[RFC5050]で定義された複合フィールド（SDNVのペアとして表される）。
Whether or not this field is allowed in the PHIB is determined by whether or not an M-EID of the node inserting the PHIB is already in the Dictionary field of the primary bundle block (e.g., whether an M-EID of the inserting node is also an M-EID of the bundle's source, current custodian, or report-to endpoint, or is the same as some other endpoint in the dictionary that is referenced by another block in the bundle).
PHIBでこのフィールドが許可されているかどうかは、PHIBを挿入するノードのM-EIDがすでにプライマリバンドルブロックの辞書フィールドにあるかどうかによって決定されます（たとえば、挿入ノードのM-EIDがまた、バンドルのソース、現在のカストディアン、またはレポートツーエンドポイントのM-EID、またはバンドルの別のブロックによって参照される辞書の他のエンドポイントと同じです）。
If an M-EID of the inserting node is already in the dictionary, this field MAY be present in the PHIB. If this field is present in the PHIB, the value of the EID-reference count MUST be one, meaning that the field contains exactly one EID-reference, which MUST be a reference to an M-EID of the inserting node. Presence of this field MUST be indicated by a set "block contains an EID-reference field" flag in the block processing control flags.
挿入ノードのM-EIDがすでに辞書にある場合、このフィールドはPHIBに存在する場合があります。このフィールドがPHIBに存在する場合、Eid-referenceカウントの値は1つでなければなりません。つまり、フィールドには1つのEID参照が含まれています。これは、挿入ノードのM-EIDへの参照でなければなりません。このフィールドの存在は、ブロック処理制御フラグの「ブロックにEid-Referenceフィールドが含まれている」フラグで示される必要があります。
If no M-EID of the inserting node is in the dictionary, this field MUST NOT be present in the PHIB, which MUST be indicated by an unset "block contains an EID-reference field" flag in the block processing control flags.
挿入ノードのm-eidが辞書にない場合、このフィールドはPHIBに存在してはなりません。これは、ブロック処理制御フラグの[ブロックにはeid-referenceフィールドが含まれています」フラグで示される必要があります。
o Block data length (SDNV) - If this value is zero, there are no block-type-specific data fields. In this case, the M-EID of the inserting node must be in the dictionary and it MUST be referenced in the Block EID-reference count and EID-references field as described above.
o ブロックデータ長（SDNV） - この値がゼロの場合、ブロック型固有のデータフィールドはありません。この場合、挿入ノードのM-EIDは辞書にある必要があり、上記のようにブロックEID -ReferenceカウントとEID参照フィールドで参照する必要があります。
o Block-type-specific data fields (optional) as follows:
o ブロックタイプ固有のデータフィールド（オプション）次のように：
* Inserting Node's EID Scheme Name - A null-terminated array of bytes that comprises the scheme name of an M-EID of the node inserting this PHIB.
* 挿入ノードのEIDスキーム名 - このPHIBを挿入するノードのM-EIDのスキーム名を含むバイトのヌル終端の配列。
* Inserting Node's EID SSP - A null-terminated array of bytes that comprises the scheme-specific part (SSP) of an M-EID of the node inserting this PHIB.
* 挿入NodeのEID SSP-このPHIBを挿入するノードのM-EIDのスキーム固有の部分（SSP）を含むバイトのヌル終端アレイ。
If the Block EID-reference count and EID-references field is not present in the PHIB, the above two EID scheme name and SSP block-type-specific data fields MUST be present. If the Block EID-reference count and EID-references field is present in the PHIB, the above two EID scheme name and SSP block-type-specific data fields MUST NOT be present.
ブロックEid-ReferenceカウントとEid-ReferencesフィールドがPHIBに存在しない場合、上記の2つのEIDスキーム名とSSPブロック型固有のデータフィールドが存在する必要があります。ブロックEid-ReferenceカウントとEid-ReferencesフィールドがPHIBに存在する場合、上記の2つのEIDスキーム名とSSPブロック型固有のデータフィールドが存在しないでください。
The structure of a PHIB is as follows:
PHIBの構造は次のとおりです。
PHIB Format:
+----+------------+--------------------------------- -+-------------+
|type|flags (SDNV)|EID-ref count and list (comp) (opt)|length (SDNV)|
+----+------------+-----------------------------------+-------------+
| Inserting Node EID Scheme Name (opt)| Inserting Node EID SSP (opt)|
+-------------------------------------------------------------------+
Figure 1
図1
The following are the processing steps that a bundle node must take relative to generation, reception, and processing of a PHIB.
以下は、バンドルノードがPHIBの生成、受信、処理に関連して取得する必要がある処理手順です。
When an outbound bundle is created per the parameters of the bundle transmission request, this bundle MAY include one or more PHIBs. Whether or not PHIBs are included is a local bundle agent configuration option and may be influenced by other factors, such as the routing protocol in use.
バンドル送信要求のパラメーターごとにアウトバウンドバンドルが作成されると、このバンドルには1つ以上のPHIBが含まれる場合があります。PHIBが含まれているかどうかは、ローカルバンドルエージェント構成オプションであり、使用中のルーティングプロトコルなどの他の要因の影響を受ける可能性があります。
Before forwarding a bundle, the node SHALL delete all PHIBs that were in the bundle when it was received (if any). As described in the Bundle Protocol Specification, the node MAY delete all strings (scheme names and SSPs) in the bundle's dictionary to which no endpoint ID references in the bundle currently refer (if any).
バンドルを転送する前に、ノードは、受信したときにバンドルにあったすべてのPHIBを削除する必要があります（もしあれば）。バンドルプロトコルの仕様で説明されているように、ノードはバンドルの辞書のすべての文字列（スキーム名とSSP）を削除する場合があります。
The node MAY insert one or more PHIBs into the bundle before forwarding it, as dictated by local policy. If there are already strings (scheme names and SSPs) in the bundle's dictionary that denote the M-EID of the inserting node, the PHIB MAY reference these strings and, if it does, it MUST NOT include any block-type-specific data fields. The inserting node MUST NOT insert strings into the bundle's dictionary in order that they may be referenced by only the PHIB. If the PHIB is constructed such that it does not reference any strings from the dictionary, the inserting node MUST include the scheme name and SSP of one of its M-EIDs as the PHIB's block-type-specific data fields.
ノードは、ローカルポリシーによって指示されているように、1つ以上のPHIBをバンドルに転送する前に挿入する場合があります。バンドルの辞書に挿入ノードのm-eidを示す文字列（スキーム名とSSP）が既にある場合、PHIBはこれらの文字列を参照し、もしそうなら、ブロック型固有のデータフィールドを含めてはなりません。挿入ノードは、PHIBのみが参照できるように、バンドルの辞書に文字列を挿入してはなりません。PHIBが辞書からの文字列を参照しないように構築されている場合、挿入ノードには、M-EIDの1つのスキーム名とSSPをPHIBのブロック型固有のデータフィールドとして含める必要があります。
The node that is inserting a PHIB into the bundle may have more than one endpoint in which it is a member. The choice of which M-EID to insert into the PIB SHALL be made as follows: o If the inserting node is a member of exactly one singleton endpoint, the node may insert at most one PHIB into the bundle and the EID of this singleton endpoint is what MUST be inserted into the PHIB.
PHIBをバンドルに挿入しているノードには、メンバーであるエンドポイントが複数ある場合があります。PIBに挿入するM-EIDの選択は次のように作成されます。O挿入ノードが正確に1つのシングルトンエンドポイントのメンバーである場合、ノードは最大1つのPHIBをバンドルに挿入し、このシングルトンエンドポイントのEidを挿入できますPHIBに挿入する必要があるものです。
o If the inserting node is a member of more than one singleton endpoint, then:
o 挿入ノードが複数のシングルトンエンドポイントのメンバーである場合、次のようになります。
If the inserting node has a priori knowledge of the URI schemes supported by the next-hop node and if the inserting node has one or more singleton M-EIDs that are expressible in one or more of those URI schemes, then the inserting node MAY insert one or more PHIBs into the bundle being forwarded. The EIDs in the inserted PHIBs MUST be unique, they MUST be singleton M-EIDs of the inserting node, and they MUST be expressed in URI schemes supported by the next-hop node. Mechanisms for determining what URI schemes are supported by particular next-hop neighbors are not defined here.
挿入ノードには、Next-HopノードでサポートされているURIスキームの先験的な知識があり、挿入ノードにそれらのURIスキームの1つ以上で表現可能な1つまたは複数のシングルトンM-EIDがある場合、挿入ノードは挿入される場合があります転送されるバンドルに1つまたは複数のPhibsがあります。挿入されたPHIBSのEidsは一意でなければなりません。挿入ノードのSingleton M-Eidsでなければならず、Next-HopノードでサポートされているURIスキームで表現する必要があります。特定のネクストホップ隣人によってサポートされているURIスキームを決定するためのメカニズムは、ここでは定義されていません。
If the inserting node has one or more singleton M-EIDs that are expressible in the same URI scheme as the destination of the bundle that is being forwarded, then the inserting node MAY insert one or more PHIBs into the bundle being forwarded. The EIDs in the inserted PHIBs MUST be unique, they MUST be singleton M-EIDs of the inserting node, and they MUST be expressed in the destination URI scheme of the bundle.
挿入ノードに、転送されているバンドルの宛先と同じURIスキームで表現可能な1つまたは複数のシングルトンM-EIDがある場合、挿入ノードは1つ以上のPHIBを転送されるバンドルに挿入する場合があります。挿入されたPhibsのEidsは一意でなければなりません。挿入ノードのSingleton M-Eidsでなければならず、バンドルの宛先URIスキームで表現する必要があります。
Else, if the inserting node has neither a singleton M-EID that is expressible in a URI scheme known to be supported by the next-hop node nor a singleton M-EID that is expressible in the same URI scheme as the destination of the bundle that is being forwarded, then the inserting node MAY insert one or more PHIBs into the bundle being forwarded. The EIDs in the inserted PHIBs MUST be unique, and they MUST be singleton M-EIDs of the inserting node.
それ以外の場合、挿入ノードには、次のホップノードによってサポートされることが知られているURIスキームで表現できるシングルトンM-EIDも、バンドルの宛先と同じURIスキームで表現可能なシングルトンM-EIDのどちらも持っていない場合それは転送されているので、挿入ノードは転送されるバンドルに1つ以上のPHIBを挿入する場合があります。挿入されたPhibsのEidsは一意でなければならず、挿入ノードのSingleton M-eidsでなければなりません。
If the bundle includes a PHIB, the EID identified in the PHIB SHALL be made available for use at the receiving node (e.g., in forwarding decisions or, if the receiving node is the bundle-destination, the EID may be made available to the receiving application; whether or not it is made available to the receiving application is an implementation matter). If the EID is identified both by a reference in the PHIB's block EID-reference count and EID-references field and by a scheme name and SSP in the block-type-specific fields, the PHIB is not considered to be well-formed. In the case of reception of such an ill-formed PHIB, if the identified EIDs are the same, the receiving node MAY process the PHIB as if it were well-formed. However, if the identified EIDs differ, the receiving node MUST NOT process the PHIB and must take action on the PHIB as specified by the PHIB's block processing flags.
バンドルにPHIBが含まれている場合、PHIBで識別されたEIDが受信ノードで使用できるようになります（たとえば、転送決定で、または受信ノードがバンドル描写である場合、EIDは受信者が利用できるようにすることができますアプリケーション;受信アプリケーションが利用できるかどうかは実装事項です）。EIDがPHIBのブロックEid -ReferenceカウントとEID -Referencesフィールドの参照と、ブロック型固有のフィールドのスキーム名とSSPの両方によって識別される場合、PHIBは十分に形成されているとは見なされません。このような不正なPHIBの受容の場合、特定されたEIDが同じ場合、受信ノードはPHIBをよく形成しているかのように処理する場合があります。ただし、特定されたEIDが異なる場合、受信ノードはPHIBを処理してはならず、PHIBのブロック処理フラグで指定されているようにPHIBに対してアクションを実行する必要があります。
The DTN Bundle Security Protocol [DTNBSP] defines security-related blocks to provide hop-by-hop bundle authentication and integrity, end-to-end integrity, and end-to-end confidentiality of bundles or parts of bundles, as well as a set of ciphersuites that may be used to calculate security-results carried in these security blocks. The PHIB will not be encrypted when using the PCB-RSA-AES128-PAYLOAD-PIB-PCB ciphersuite with the Payload Confidentiality Block (PCB) to provide end-to-end confidentiality. This ciphersuite only allows for payload and Payload Integrity Block (PIB) encryption. If encryption of the PHIB block is desired, the Extension Security Block (ESB) could be used for this purpose.
DTNバンドルセキュリティプロトコル[DTNBSP]は、バンドルまたはバンドルの一部のホップバイホップバンドル認証、エンドツーエンドの整合性、エンドツーエンドの機密性を提供するセキュリティ関連のブロックを定義します。これらのセキュリティブロックで運ばれるセキュリティ反応を計算するために使用される可能性のあるシファースーツのセット。PCB-RSA-AES128-Payload-PIB-PCB Ciphersuiteを使用してペイロード機密性のブロック（PCB）を使用してエンドツーエンドの機密性を提供する場合、PHIBは暗号化されません。このciphersuiteは、ペイロードとペイロードの整合性ブロック（PIB）暗号化のみを可能にします。PHIBブロックの暗号化が必要な場合、この目的のために拡張セキュリティブロック（ESB）を使用できます。
All ciphersuites that use the strict canonicalization algorithm [DTNBSP] 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 PHIB and would include that block in the calculation of their security-result. In particular, bundles including the optional PHIB would have their integrity protected in their entirety for the extent of a single hop, from a forwarding node to an adjacent receiving node, using the Bundle Authentication Block (BAB) with the BAB-HMAC (Hashed Message Authentication Code) ciphersuite defined in the Bundle Security Protocol Specification.
厳密な標準化アルゴリズム[dtnbsp]を使用して、セキュリティ反応（たとえば、多くのホップバイホップ認証暗号剤）を計算して検証するすべてのciphersuitesは、バンドルのすべてのブロックに適用されるため、オプションのPHIBとオプションのPHIBを含むバンドルに適用されます。セキュリティ結果の計算にそのブロックを含めます。特に、オプションのPHIBを含むバンドルは、バンドル認証ブロック（BAB）をBAB-HMAC（Hashed Message）を使用して、転送ノードから隣接する受信ノードまで、1つのホップの範囲で完全性を完全に保護します。認証コード）バンドルセキュリティプロトコル仕様で定義されている暗号外観。
Ciphersuites that use the mutable canonicalization algorithm to calculate and verify security-results (e.g., the PIB-RSA-SHA256 ciphersuite and most end-to-end authentication ciphersuites used with the PIB) will (correctly) omit the PHIB from their calculation. The fact that several different instantiations of this PHIB block may be added to and deleted from the bundle as the bundle transits the network will not interfere with end-to-end security protection when using ciphersuites that use mutable canonicalization.
可変性の標準化アルゴリズムを使用してセキュリティ反応を計算して検証する顕微鏡（たとえば、PIB-RSA-SHA256 CIPHERSUITEおよびPIBで使用されるほとんどのエンドツーエンド認証暗号）は、（正しく）PHIBを計算から省略します。このPHIBブロックのいくつかの異なるインスタンス化が、バンドルが通過するため、バンドルから削除される可能性があるという事実は、ネットワークが可変正規化を使用するCipherSuitesを使用する場合、エンドツーエンドのセキュリティ保護を妨げません。
As stated above, the BAB can be used to ensure the integrity of the PHIB. Nodes receiving bundles with PHIBs should be aware, however, that forwarding nodes that insert PHIBs might lie about the EIDs of endpoints of which they are members. Lying in this way could provide a mechanism for subverting routing strategies that base routing decisions on EID information in the PHIB.
上記のように、BABはPHIBの完全性を確保するために使用できます。ただし、PHIBSでバンドルを受け取るノードは、PHIBSを挿入する転送ノードをメンバーであるエンドポイントのEidについて嘘をつく可能性があることに注意する必要があります。このように横たわることは、PHIBのEID情報に基づいてルーティング決定を基にするルーティング戦略を破壊するメカニズムを提供することができます。
Note that if some Bundle Protocol implementation does not support the PHIB but does not properly implement the "Discard block if it can't be processed" flag, then a PHIB may unexpectedly persist for longer than a single hop.
一部のバンドルプロトコルの実装はPHIBをサポートしていないが、「処理できない場合は廃棄ブロック」を適切に実装しない場合、PHIBは1回のホップよりも長く続く可能性があります。
This specification allocates a codepoint from the "Bundle Block Types" registry defined in [RFC6255] (see Section 2):
この仕様では、[RFC6255]で定義されている「バンドルブロックタイプ」レジストリからコードポイントを割り当てます（セクション2を参照）：
Additional Entry for the Bundle Block Type Codes Registry:
+-------+----------------------------------------+----------------+
| Value | Description + Reference |
+-------+----------------------------------------+----------------+
| 5 | Previous-Hop Insertion 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月。
[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 2011.
[RFC6255] Blanchet、M。、「遅延耐性ネットワーキング（DTN）バンドルプロトコルIANAレジストリ」、RFC 6255、2011年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月。
[DTNBSP] Symington, S., Farrell, S., Weiss, H., and P. Lovell, "Bundle Security Protocol Specification", RFC 6257, May 2011.
[DTNBSP] 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/