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）バンドルプロトコルと共に使用するための拡張ブロックを定義します。ブロックが転送ノードのエンドポイントのエンドポイント識別子（EID）を提供するために、転送ノードによって挿入されるように設計され、この前ホップ挿入ブロック（PHIB）拡張このEIDは、ネクストに搬送することができるようにされるメンバーであります受信ノードホップ。前ホップノードがメンバであるエンドポイントのEIDの知識は、特定のルーティングプロトコル（例えば、フラッドルーティング）をサポートするために、いくつかの状況で必要とされ得ます。このEID収束層または他の手段によって提供することができない場合、PHIBはEIDバンドルを提供することができるメカニズムを定義します。バンドル内のその存在が正確に一つのホップに制限されるように、各PHIBは常に受信ノードによってバンドルから除去されます。この文書は、この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.
この文書は、インターネットコミュニティのために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/rfc6259.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（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. 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
PHIBこのEIDは、ネクストホップ受信ノードに搬送することができるように、転送ノードがメンバであるエンドポイントのエンドポイント識別子（EID）を提供するために、転送ノードが束内に挿入されます。 （以下、ノードがメンバであるエンドポイントのEIDは、そのノードの「M-EID」と呼ぶことにする。ノードはそれへのエンドポイントの数に応じて、1つまたは複数のM-のEIDを有していてもよいですノードがメンバであるシングルトンエンドポイントのEIDは、そのノードの「シングルトンM-EID」と呼ぶ。）受信ノードはM-を決定することができる必要がある状況では。属し転送ノードのEIDが、転送ノードのM-EIDは既存のメカニズムを介して受信ノードによって推測することができない、転送ノードは、明示的にこれを提供しなければなりません
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.
バンドル内の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情報はさまざまなルーティングプロトコルをサポートするために、いくつかの状況で使用することができます。フラッドルーティングを実装する際に、各受信ノードは、それがバンドルをフラッディングにその一部がそうであるように、それは前方バンドルを受信する隣接ノードのリストから除外するためにどのEID決定する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もBABのセキュリティソースEIDを提供するDTNバンドルセキュリティプロトコル[DTNBSP]のバンドル認証ブロック（BAB）と組み合わせて使用することができます。 PHIB代わりにBABのEID-参照フィールド内の参照を使用して、このEID搬送またはBABの鍵情報パラメータの一部として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から決定するため。トンネルの受信側のノードは、その隣接ノードの一方から封入束を受け取り、収束層プロトコルを使用して、この隣接ノードの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.
EIDはPHIB内の二つの方法で提示することができます。転送ノードのM-EIDは、バンドルの主なバンドルブロックのディクショナリ項目にすでに存在する場合は、PHIBはそのブロックEID-参照カウントとEID-参照フィールドを使用して、このEIDを識別することができます。そうでなければ、PHIBは、そのブロックタイプ固有のデータフィールドにEIDを提供することによって、このEIDを識別しなければなりません。 PHIB内のEIDを提示するこれら二つの代替の方法は、さらに第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,
PHIBを生成し、束に挿入O、
o receiving bundles containing a PHIB and making the information contained in this PHIB available for use, e.g., in forwarding decisions, and
PHIBを含むバンドルを受信し、使用可能なこのPHIBに含まれる情報を作り、例えば、転送の決定に、及びo
o deleting a PHIB from a bundle
バンドルからPHIBを削除するO
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:
バンドルプロトコル仕様[RFC5050]で定義されるようPHIBは標準バンドルブロックフォーマットを使用します。つまり、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ブロックEID-参照カウントとEID-参照（オプション） - [RFC5050]で定義された複合フィールド（SDNVsのペアとして表される）EID-参照続いEID-参照（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-参照カウントの値は、フィールドに挿入ノードのM-EIDを参照しなければなりません正確に一つのEID-参照し、含まれていることを意味し、一つでなければなりません。このフィールドの存在は、ブロック処理制御フラグのフラグ「ブロックがEID-参照フィールド含ま」をセットすることによって示されなければなりません。
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が辞書にない場合、このフィールドは、ブロック処理制御フラグに設定解除することによって、「ブロックEID-参照フィールド含ま」フラグを示さなければならないPHIB、中に存在してはなりません。
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-参照カウントと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.
・挿入ノードの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-参照カウントとEID-参照フィールドがPHIBに存在しない場合、上記の二つのEIDスキーム名とSSPブロックタイプ固有のデータフィールドが存在しなければなりません。ブロックEID-参照カウントとEID-参照フィールドがPHIB中に存在する場合、上記の二つの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.
アウトバウンドバンドルがバンドル送信要求のパラメータごとに作成されている場合、このバンドルは、一つ以上のフィウズを含むかもしれません。フィウズが含まれているかどうかは、ローカルバンドルエージェント構成オプションであり、そのような使用におけるルーティングプロトコルのような他の要因によって影響され得ます。
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).
バンドルを転送する前に、ノードは、それが受信されたときにバンドルしていた全てフィウズ（もしあれば）を削除するものとします。バンドルプロトコル仕様で説明したように、ノードは、（もしあれば）のバンドルには、エンドポイントのIDの参照は、現在参照していない先のバンドルの辞書内のすべての文字列（スキーム名との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.
ノードはローカルポリシーによって指示されるように、それを転送する前に、束に一つ以上のフィウズを挿入することができます。挿入ノードのM-EIDを表すバンドルの辞書内の文字列（スキーム名とのSSP）がすでに存在する場合、PHIBは、これらの文字列を参照することができ、それがない場合は、任意のブロック型固有のデータ・フィールドを含んではいけません。挿入ノードは、彼らが唯一のPHIBによって参照することができるように、バンドルの辞書に文字列を挿入してはなりません。 PHIBはそれが辞書から任意の文字列を参照しないように構成されている場合は、挿入ノードはPHIBのブロックタイプ固有のデータフィールドとしてのM-のEIDの一方のスキーム名とSSPを含まなければなりません。
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の選択がなされなければならない：挿入ノードは、ちょうど1つのシングルトンのエンドポイントのメンバーである場合、O、ノードが束に最大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.
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を有する場合、挿入ノードは、転送される束に一つ以上のフィウズを挿入することができます。挿入フィウズ内のEIDは一意である必要があります、それらは挿入ノードのシングルトンM-のEIDでなければなりません、そして、彼らは、バンドルの宛先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どちらを持っている場合それが転送され、その後、挿入ノードは、転送される束に一つ以上のフィウズを挿入することができます。挿入フィウズ内のEIDは一意である必要があり、それらは挿入ノードのシングルトンM-のEIDでなければなりません。
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-参照カウントとEID-参照フィールドを参照することにより、ブロック型特有の分野におけるスキーム名とSSPの両方によって識別された場合、PHIBはよく形成されると考えていません。同定のEIDが同じである場合、それは整形式であるかのような病気に形成されPHIBの受信の場合には、受信ノードは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）とPCB-RSA-AES128-PAYLOAD-PIB-PCBの暗号スイートを使用する場合PHIBは暗号化されません。この暗号スイートはペイロードとペイロードの整合性ブロック（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]を使用するすべての暗号スイートを計算し、セキュリティの結果を検証するために（例えば、多くのホップバイホップ認証暗号スイート）バンドル内のすべてのブロックに適用され、したがって任意PHIBとを含むバンドルに適用されます彼らのセキュリティ-結果の計算にそのブロックが含まれるであろう。具体的には、任意PHIBは、それらの完全性がBAB-HMAC（ハッシュメッセージとバンドル認証ブロック（BAB）を使用して、転送ノードから隣接受信ノードに、シングルホップの程度のためにその全体が保護されたであろう含むバンドルバンドルセキュリティプロトコル仕様で定義された認証コード）暗号スイート。
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の暗号スイートおよびPIBで使用される最もエンドツーエンド認証暗号スイート）を計算し、確認するために変更可能な正規化アルゴリズムを使用する暗号スイートは、（正しく）、それらの計算からPHIBを省略する。このPHIBブロックのいくつかの異なるインスタンスを添加し、バンドルとしてバンドルから削除することができるという事実は、変更可能な正規化を使用する暗号スイートを使用する場合、ネットワークは、エンドツーエンドのセキュリティ保護を妨害しない遷移します。
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の完全性を保証するために使用することができます。フィウズでバンドルを受信ノードはフィウズを挿入ノードを転送すると、彼らがメンバーであるエンドポイントのの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が突然シングルホップよりも長く持続することがあることに注意してください。
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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[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 2011.
[RFC6255]ブランシェ、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]サーフ、V.、バーレイ、S.、フック、A.、Torgerson、L.、ダースト、R.、スコット、K.、秋、K.、およびH.ワイス、 "遅延耐性ネットワークアーキテクチャ" 、RFC 4838、2007年4月。
[DTNBSP] Symington, S., Farrell, S., Weiss, H., and P. Lovell, "Bundle Security Protocol Specification", RFC 6257, May 2011.
[DTNBSP]シミントン、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/