Internet Research Task Force (IRTF) S. Symington
Request for Comments: 6259 The MITRE Corporation
Category: Experimental May 2011
ISSN: 2070-1721
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不能通过汇聚层或其他方式提供，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.
本文档为互联网社区定义了一个实验协议。本文件是互联网研究工作组（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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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
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 Bundle协议将Bundle定义为其协议数据单元，并定义“Bundle block”以承载不同类型的数据。本文档定义了一个称为前一跳插入块（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”。根据其所属端点的数量，节点可能有一个或多个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信息来支持各种路由协议。例如，PHIB在实现泛洪路由时可能会很有帮助，因为每个接收节点都可以使用PHIB来确定从相邻节点列表中排除哪个EID，该相邻节点将接收到的捆绑转发到该EID，就像它在泛洪捆绑中所做的一样。节点将向所有相邻节点（从中接收捆绑包的节点除外，如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，而不是使用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。隧道接收端的节点将从其一个相邻节点接收封装包，并且它可能能够使用汇聚层协议告知该相邻节点的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。第3节将进一步讨论在PHIB中呈现EID的这两种替代方法。
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中的一个跃点。如果接收到包含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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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 块类型代码（一个字节）-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]中定义的复合字段，包含EID引用计数（表示为SDNV），后跟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引用计数的值必须为1，这意味着该字段正好包含一个EID引用，该引用必须是对插入节点的M-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，则PHIB中不得存在该字段，该字段必须由块处理控制标志中未设置的“块包含EID参考字段”标志指示。
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方案名称-以null结尾的字节数组，包含插入此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-一个以null结尾的字节数组，包含插入此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.
如果PHIB中不存在块EID引用计数和EID引用字段，则必须存在上述两个EID方案名称和SSP块类型特定数据字段。如果PHIB中存在块EID引用计数和EID引用字段，则上述两个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)|
+-------------------------------------------------------------------+
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.
当根据捆绑传输请求的参数创建出站捆绑时，该捆绑可以包括一个或多个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（如果有）。如捆绑协议规范中所述，节点可以删除捆绑字典中当前捆绑中没有端点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.
根据本地策略的规定，节点可以在转发包之前将一个或多个PHIB插入包中。如果捆绑包的字典中已有表示插入节点的M-EID的字符串（方案名称和SSP），PHIB可以引用这些字符串，如果引用，则不能包含任何块类型特定的数据字段。插入节点不得将字符串插入捆绑包的字典中，以便它们只能被PHIB引用。如果PHIB的构造不引用字典中的任何字符串，则插入节点必须包括其M-EID之一的方案名称和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:
将PHIB插入捆绑包的节点可能有多个端点，它是其中的一个成员。应按照以下方式选择插入PIB的M-EID：
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.
o 如果插入节点恰好是一个单例端点的成员，则该节点最多可以将一个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.
如果插入节点具有由下一跳节点支持的URI方案的先验知识，并且如果插入节点具有可在一个或多个URI方案中表达的一个或多个单例M-eid，则插入节点可以将一个或多个phib插入正在转发的包中。插入的PHIB中的EID必须是唯一的，它们必须是插入节点的单例M-EID，并且必须用下一跳节点支持的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.
如果插入节点具有一个或多个单例M-eid，这些单例M-eid可在与正在转发的捆绑的目的地相同的URI方案中表达，则插入节点可将一个或多个phib插入正在转发的捆绑中。插入的PHIB中的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，则插入节点可以将一个或多个phib插入正在转发的捆绑中。插入PHIB中的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
如果捆绑包包括PHIB，则PHIB中标识的EID应可用于接收节点（例如，在转发决策中，或者如果接收节点是捆绑目的地，则EID可供接收应用程序使用；是否可供接收应用程序使用是一个实现问题）。如果EID由PHIB的块EID引用计数和EID引用字段中的引用以及块类型特定字段中的方案名称和SSP标识，则PHIB不被视为格式良好。在接收到这种格式不良的PHIB的情况下，如果标识的EID相同，则
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不同，则接收节点不得处理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 Bundle安全协议[DTNBSP]定义了安全相关块，以提供逐跳Bundle身份验证和完整性、端到端完整性以及Bundle或Bundle部分的端到端机密性，以及一组可用于计算这些安全块中携带的安全结果的密码套件。当将PCB-RSA-AES128-PAYLOAD-PIB-PCB密码套件与有效负载保密块（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）和BAB-HMAC（散列消息认证码），在从转发节点到相邻接收节点的单跳范围内整体保护其完整性捆绑包安全协议规范中定义的密码套件。
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的完整性。但是，接收带有PHIB的捆绑包的节点应该知道，插入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]中定义的“Bundle Block Types”注册表中分配代码点（见第2节）：
Additional Entry for the Bundle Block Type Codes Registry:
+-------+----------------------------------------+----------------+
| Value | Description + Reference |
+-------+----------------------------------------+----------------+
| 5 | Previous-Hop Insertion Block + This document |
+-------+----------------------------------------+----------------+
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 50502007年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 48382007年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/
Phone: +1 (703) 983-7209
EMail: susan@mitre.org
URI: http://mitre.org/