Internet Research Task Force (IRTF) M. Mosko
Request for Comments: 8609 PARC, Inc.
Category: Experimental I. Solis
ISSN: 2070-1721 LinkedIn
C. Wood
University of California Irvine
July 2019
Internet Research Task Force (IRTF) M. Mosko
Request for Comments: 8609 PARC, Inc.
Category: Experimental I. Solis
ISSN: 2070-1721 LinkedIn
C. Wood
University of California Irvine
July 2019
Content-Centric Networking (CCNx) Messages in TLV Format
TLV格式的以内容为中心的网络（CCNx）消息
Abstract
摘要
Content-Centric Networking (CCNx) is a network protocol that uses a hierarchical name to forward requests and to match responses to requests. This document specifies the encoding of CCNx messages in a TLV packet format, including the TLV types used by each message element and the encoding of each value. The semantics of CCNx messages follow the encoding-independent CCNx Semantics specification.
以内容为中心的网络（CCNx）是一种网络协议，它使用分层名称转发请求并将响应与请求相匹配。本文档以TLV数据包格式指定CCNx消息的编码，包括每个消息元素使用的TLV类型和每个值的编码。CCNx消息的语义遵循独立于编码的CCNx语义规范。
This document is a product of the Information Centric Networking research group (ICNRG). The document received wide review among ICNRG participants and has two full implementations currently in active use, which have informed the technical maturity of the protocol specification.
本文档是以信息为中心的网络研究小组（ICNRG）的产品。该文件在ICNRG参与者中得到了广泛的审查，目前有两个完整的实施方案正在积极使用中，这两个方案说明了协议规范的技术成熟度。
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 Information-Centric Networking Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
本文档为互联网社区定义了一个实验协议。本文件是互联网研究工作组（IRTF）的产品。IRTF发布互联网相关研究和开发活动的结果。这些结果可能不适合部署。本RFC代表了互联网研究任务组（IRTF）以信息为中心的网络研究小组的共识。IRSG批准发布的文件不适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8609.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8609.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Type-Length-Value (TLV) Packets . . . . . . . . . . . . . . . 5
3.1. Overall Packet Format . . . . . . . . . . . . . . . . . . 7
3.2. Fixed Headers . . . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Interest Fixed Header . . . . . . . . . . . . . . . . 9
3.2.1.1. Interest HopLimit . . . . . . . . . . . . . . . . 9
3.2.2. Content Object Fixed Header . . . . . . . . . . . . . 9
3.2.3. Interest Return Fixed Header . . . . . . . . . . . . 10
3.2.3.1. Interest Return HopLimit . . . . . . . . . . . . 10
3.2.3.2. Interest Return Flags . . . . . . . . . . . . . . 10
3.2.3.3. Return Code . . . . . . . . . . . . . . . . . . . 10
3.3. Global Formats . . . . . . . . . . . . . . . . . . . . . 11
3.3.1. Pad . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.2. Organization-Specific TLVs . . . . . . . . . . . . . 12
3.3.3. Hash Format . . . . . . . . . . . . . . . . . . . . . 12
3.3.4. Link . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4. Hop-by-Hop TLV Headers . . . . . . . . . . . . . . . . . 14
3.4.1. Interest Lifetime . . . . . . . . . . . . . . . . . . 14
3.4.2. Recommended Cache Time . . . . . . . . . . . . . . . 15
3.4.3. Message Hash . . . . . . . . . . . . . . . . . . . . 16
3.5. Top-Level Types . . . . . . . . . . . . . . . . . . . . . 17
3.6. CCNx Message TLV . . . . . . . . . . . . . . . . . . . . 18
3.6.1. Name . . . . . . . . . . . . . . . . . . . . . . . . 19
3.6.1.1. Name Segments . . . . . . . . . . . . . . . . . . 20
3.6.1.2. Interest Payload ID . . . . . . . . . . . . . . . 20
3.6.2. Message TLVs . . . . . . . . . . . . . . . . . . . . 21
3.6.2.1. Interest Message TLVs . . . . . . . . . . . . . . 21
3.6.2.2. Content Object Message TLVs . . . . . . . . . . . 23
3.6.3. Payload . . . . . . . . . . . . . . . . . . . . . . . 25
3.6.4. Validation . . . . . . . . . . . . . . . . . . . . . 25
3.6.4.1. Validation Algorithm . . . . . . . . . . . . . . 25
3.6.4.2. Validation Payload . . . . . . . . . . . . . . . 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Type-Length-Value (TLV) Packets . . . . . . . . . . . . . . . 5
3.1. Overall Packet Format . . . . . . . . . . . . . . . . . . 7
3.2. Fixed Headers . . . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Interest Fixed Header . . . . . . . . . . . . . . . . 9
3.2.1.1. Interest HopLimit . . . . . . . . . . . . . . . . 9
3.2.2. Content Object Fixed Header . . . . . . . . . . . . . 9
3.2.3. Interest Return Fixed Header . . . . . . . . . . . . 10
3.2.3.1. Interest Return HopLimit . . . . . . . . . . . . 10
3.2.3.2. Interest Return Flags . . . . . . . . . . . . . . 10
3.2.3.3. Return Code . . . . . . . . . . . . . . . . . . . 10
3.3. Global Formats . . . . . . . . . . . . . . . . . . . . . 11
3.3.1. Pad . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.2. Organization-Specific TLVs . . . . . . . . . . . . . 12
3.3.3. Hash Format . . . . . . . . . . . . . . . . . . . . . 12
3.3.4. Link . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4. Hop-by-Hop TLV Headers . . . . . . . . . . . . . . . . . 14
3.4.1. Interest Lifetime . . . . . . . . . . . . . . . . . . 14
3.4.2. Recommended Cache Time . . . . . . . . . . . . . . . 15
3.4.3. Message Hash . . . . . . . . . . . . . . . . . . . . 16
3.5. Top-Level Types . . . . . . . . . . . . . . . . . . . . . 17
3.6. CCNx Message TLV . . . . . . . . . . . . . . . . . . . . 18
3.6.1. Name . . . . . . . . . . . . . . . . . . . . . . . . 19
3.6.1.1. Name Segments . . . . . . . . . . . . . . . . . . 20
3.6.1.2. Interest Payload ID . . . . . . . . . . . . . . . 20
3.6.2. Message TLVs . . . . . . . . . . . . . . . . . . . . 21
3.6.2.1. Interest Message TLVs . . . . . . . . . . . . . . 21
3.6.2.2. Content Object Message TLVs . . . . . . . . . . . 23
3.6.3. Payload . . . . . . . . . . . . . . . . . . . . . . . 25
3.6.4. Validation . . . . . . . . . . . . . . . . . . . . . 25
3.6.4.1. Validation Algorithm . . . . . . . . . . . . . . 25
3.6.4.2. Validation Payload . . . . . . . . . . . . . . . 32
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
4.1. Packet Type Registry . . . . . . . . . . . . . . . . . . 33
4.2. Interest Return Code Registry . . . . . . . . . . . . . . 34
4.3. Hop-by-Hop Type Registry . . . . . . . . . . . . . . . . 35
4.4. Top-Level Type Registry . . . . . . . . . . . . . . . . . 36
4.5. Name Segment Type Registry . . . . . . . . . . . . . . . 37
4.6. Message Type Registry . . . . . . . . . . . . . . . . . . 37
4.7. Payload Type Registry . . . . . . . . . . . . . . . . . . 38
4.8. Validation Algorithm Type Registry . . . . . . . . . . . 39
4.9. Validation-Dependent Data Type Registry . . . . . . . . . 40
4.10. Hash Function Type Registry . . . . . . . . . . . . . . . 40
5. Security Considerations . . . . . . . . . . . . . . . . . . . 41
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.1. Normative References . . . . . . . . . . . . . . . . . . 44
6.2. Informative References . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
4.1. Packet Type Registry . . . . . . . . . . . . . . . . . . 33
4.2. Interest Return Code Registry . . . . . . . . . . . . . . 34
4.3. Hop-by-Hop Type Registry . . . . . . . . . . . . . . . . 35
4.4. Top-Level Type Registry . . . . . . . . . . . . . . . . . 36
4.5. Name Segment Type Registry . . . . . . . . . . . . . . . 37
4.6. Message Type Registry . . . . . . . . . . . . . . . . . . 37
4.7. Payload Type Registry . . . . . . . . . . . . . . . . . . 38
4.8. Validation Algorithm Type Registry . . . . . . . . . . . 39
4.9. Validation-Dependent Data Type Registry . . . . . . . . . 40
4.10. Hash Function Type Registry . . . . . . . . . . . . . . . 40
5. Security Considerations . . . . . . . . . . . . . . . . . . . 41
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.1. Normative References . . . . . . . . . . . . . . . . . . 44
6.2. Informative References . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
This document specifies a Type-Length-Value (TLV) packet format and the TLV type and value encodings for CCNx messages. A full description of the CCNx network protocol, providing an encoding-free description of CCNx messages and message elements, may be found in [RFC8569]. CCNx is a network protocol that uses a hierarchical name to forward requests and to match responses to requests. It does not use endpoint addresses; the Internet Protocol does. Restrictions in a request can limit the response by the public key of the response's signer or the cryptographic hash of the response. Every CCNx forwarder along the path does the name matching and restriction checking. The CCNx protocol fits within the broader framework of Information-Centric Networking (ICN) protocols [RFC7927].
本文档指定了类型长度值（TLV）数据包格式以及CCNx消息的TLV类型和值编码。CCNx网络协议的完整描述，提供了CCNx消息和消息元素的无编码描述，可在[RFC8569]中找到。CCNx是一种网络协议，它使用分层名称转发请求并将响应与请求相匹配。它不使用端点地址；互联网协议确实如此。请求中的限制可以通过响应签名者的公钥或响应的加密散列来限制响应。路径上的每个CCNx转发器都进行名称匹配和限制检查。CCNx协议适用于更广泛的以信息为中心的网络（ICN）协议框架[RFC7927]。
This document describes a TLV scheme using a fixed 2-byte T and a fixed 2-byte L field. The rational for this choice is described in Section 5. Briefly, this choice avoids multiple encodings of the same value (aliases) and reduces the work of a validator to ensure compliance. Unlike some uses of TLV in networking, each network hop must evaluate the encoding, so even small validation latencies at each hop could add up to a large overall forwarding delay. For very small packets or low-throughput links, where the extra bytes may become a concern, one may use a TLV compression protocol, for example, [compress] and [CCNxz].
本文档描述了使用固定2字节T和固定2字节L字段的TLV方案。第5节描述了这种选择的合理性。简单地说，这种选择避免了相同值（别名）的多次编码，并减少了验证器的工作量以确保遵从性。与TLV在网络中的某些用途不同，每个网络跃点都必须评估编码，因此，即使每个跃点的验证延迟很小，也可能导致较大的整体转发延迟。对于非常小的分组或低吞吐量链路，其中额外字节可能成为问题，可以使用TLV压缩协议，例如，[compress]和[CCNxz]。
This document uses the terms CCNx Packet, CCNx Message, and CCNx Message TLV. A CCNx Packet refers to the entire Layer 3 datagram as specified in Section 3.1. A CCNx Message is the ABNF token defined in the CCNx Semantics document [RFC8569]. A CCNx Message TLV refers to the encoding of a CCNx Message as specified in Section 3.6.
本文档使用术语CCNx数据包、CCNx消息和CCNx消息TLV。CCNx数据包是指第3.1节规定的整个第3层数据报。CCNx消息是在CCNx语义文档[RFC8569]中定义的ABNF令牌。CCNx消息TLV指第3.6节中规定的CCNx消息编码。
This document specifies:
本文件规定：
o the CCNx Packet format,
o CCNx数据包格式，
o the CCNx Message TLV format,
o CCNx消息TLV格式，
o the TLV types used by CCNx messages,
o CCNx消息使用的TLV类型，
o the encoding of values for each type,
o 每种类型的值编码，
o top-level types that exist at the outermost containment,
o 存在于最外层安全壳的顶级类型，
o Interest TLVs that exist within Interest containment, and
o 利益控制范围内存在的利益TLV，以及
o Content Object TLVs that exist within Content Object containment.
o 内容对象包含中存在的内容对象TLV。
This document is supplemented by these documents:
本文件由以下文件补充：
o [RFC8569], which covers message semantics and the protocol operation regarding Interest and Content Object, including the Interest Return protocol.
o [RFC8569]，其中包括消息语义和有关兴趣和内容对象的协议操作，包括兴趣返回协议。
o [CCNxURI], which covers the CCNx URI notation.
o [CCNxURI]，它涵盖了CCNxURI表示法。
The type values in Section 4 conform to the IANA-assigned numbers for the CCNx protocol. This document uses the symbolic names defined in that section. All TLV type values are relative to their parent containers. For example, each level of a nested TLV structure might define a "type = 1" with a completely different meaning.
第4节中的类型值符合CCNx协议的IANA分配编号。本文档使用该节中定义的符号名称。所有TLV类型值都是相对于其父容器的。例如，嵌套TLV结构的每个级别可能定义一个含义完全不同的“type=1”。
Packets are represented as 32-bit wide words using ASCII art. Due to the nested levels of TLV encoding and the presence of optional fields and variable sizes, there is no concise way to represent all possibilities. We use the convention that ASCII art fields enclosed by vertical bars "|" represent exact bit widths. Fields with a forward slash "/" are variable bit widths, which we typically pad out to word alignment for picture readability.
数据包使用ASCII art表示为32位宽的字。由于TLV编码的嵌套级别以及可选字段和变量大小的存在，没有简洁的方式来表示所有的可能性。我们使用由竖条“|”包围的ASCII艺术字段表示精确的位宽度的约定。带正斜杠“/”的字段是可变的位宽度，我们通常将其填充到字对齐中以提高图片可读性。
The document represents the consensus of the ICN RG. It is the first ICN protocol from the RG, created from the early CCNx protocol [nnc] with significant revision and input from the ICN community and RG members. The document has received critical reading by several members of the ICN community and the RG. The authors and RG chairs approve of the contents. The document is sponsored under the IRTF and is not issued by the IETF and is not an IETF standard. This is an experimental protocol and may not be suitable for any specific application and the specification may change in the future.
该文件代表了ICN RG的共识。这是RG的第一个ICN协议，由早期CCNx协议[nnc]创建，ICN社区和RG成员进行了重大修订和输入。ICN社区和RG的一些成员对该文件进行了批判性阅读。作者和RG主席对内容表示赞同。本文件由IRTF赞助，并非由IETF发布，也不是IETF标准。这是一个实验性协议，可能不适用于任何特定应用，规范可能会在将来更改。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
These definitions summarize items defined in [RFC8569]. This document defines their encodings.
这些定义总结了[RFC8569]中定义的项目。本文档定义了它们的编码。
o Name: A hierarchically structured variable-length identifier. It is an ordered list of path segments, which are variable-length octet strings. In human-readable form, it is represented in URI format as "ccnx:/path/part". There is no host or query string. See [CCNxURI] for complete details.
o 名称：分层结构的可变长度标识符。它是路径段的有序列表，路径段是可变长度的八位字节字符串。在人类可读的形式中，它以URI格式表示为“ccnx:/path/part”。没有主机或查询字符串。有关完整的详细信息，请参见[CCNxURI]。
o Interest: A message requesting a Content Object with a matching Name and other optional selectors to choose from multiple objects with the same Name. Any Content Object with a Name and attributes that matches the Name and optional selectors of the Interest is said to satisfy the Interest.
o 兴趣：请求具有匹配名称的内容对象和其他可选选择器从具有相同名称的多个对象中进行选择的消息。任何名称和属性与感兴趣的名称和可选选择器匹配的内容对象都被称为满足感兴趣。
o Content Object: A data object sent in response to an Interest request. It has an optional Name and a content payload that are bound together via cryptographic means.
o 内容对象：响应兴趣请求而发送的数据对象。它有一个可选名称和一个通过加密方式绑定在一起的内容负载。
We use 16-bit Type and 16-bit Length fields to encode TLV-based packets. This provides 65,536 different possible types and value field lengths of up to 64 KiB. With 65,536 possible types at each level of TLV encoding, there should be sufficient space for basic protocol types, while also allowing ample room for experimentation, application use, vendor extensions, and growth. This encoding does not allow for jumbo packets beyond 64 KiB total length. If used on a media that allows for jumbo frames, we suggest defining a media adaptation envelope that allows for multiple smaller frames.
我们使用16位类型和16位长度字段对基于TLV的数据包进行编码。这提供了65536种不同的可能类型和最长为64 KiB的值字段长度。由于TLV编码的每个级别都有65536种可能的类型，因此应该有足够的空间用于基本协议类型，同时也为实验、应用程序使用、供应商扩展和增长提供了充足的空间。此编码不允许超过64 KiB总长度的巨型数据包。如果在允许巨型帧的媒体上使用，我们建议定义允许多个较小帧的媒体适配封套。
+--------+------------------+---------------------------------------+
| Abbrev | Name | Description |
+--------+------------------+---------------------------------------+
| T_ORG | Vendor Specific | Information specific to a vendor |
| | Information | implementation (Section 3.3.2). |
| | | |
| T_PAD | Padding | Adds padding to a field (Section |
| | | 3.3.1). |
| | | |
| n/a | Experimental | Experimental use. |
+--------+------------------+---------------------------------------+
+--------+------------------+---------------------------------------+
| Abbrev | Name | Description |
+--------+------------------+---------------------------------------+
| T_ORG | Vendor Specific | Information specific to a vendor |
| | Information | implementation (Section 3.3.2). |
| | | |
| T_PAD | Padding | Adds padding to a field (Section |
| | | 3.3.1). |
| | | |
| n/a | Experimental | Experimental use. |
+--------+------------------+---------------------------------------+
Table 1: Reserved TLV Types
表1：保留TLV类型
There are several global TLV definitions that we reserve at all hierarchical contexts. The TLV types in the range 0x1000 - 0x1FFF are Reserved for Experimental Use. The TLV type T_ORG is also Reserved for Vendor Extensions (see Section 3.3.2). The TLV type T_PAD is used to optionally pad a field out to some desired alignment.
我们在所有层次上下文中保留了几个全局TLV定义。0x1000-0x1FFF范围内的TLV类型保留供实验使用。TLV类型T_组织也保留用于供应商扩展（见第3.3.2节）。TLV型T_焊盘用于选择性地将一个字段填充到某个所需的对齐位置。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Type | Length |
+---------------+---------------+---------------+---------------+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Type | Length |
+---------------+---------------+---------------+---------------+
Figure 1: Type and Length encoding
图1：类型和长度编码
The Length field contains the length of the Value field in octets. It does not include the length of the Type and Length fields. The Length MAY be zero.
长度字段包含值字段的长度（以八位字节为单位）。它不包括类型和长度字段的长度。长度可以是零。
TLV structures are nestable, allowing the Value field of one TLV structure to contain additional TLV structures. The enclosing TLV structure is called the container of the enclosed TLV.
TLV结构是可嵌套的，允许一个TLV结构的值字段包含其他TLV结构。封闭TLV结构称为封闭TLV的容器。
Type values are context dependent. Within a TLV container, one may reuse previous type values for new context-dependent purposes.
类型值依赖于上下文。在TLV容器中，可以重用以前的类型值用于新的上下文相关用途。
Each CCNx Packet includes the 8-byte fixed header, described below, followed by a set of TLV fields. These fields are optional hop-by-hop headers and the Packet Payload.
每个CCNx数据包包括8字节固定报头，如下所述，后跟一组TLV字段。这些字段是可选的逐跳标头和数据包负载。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Version | PacketType | PacketLength |
+---------------+---------------+---------------+---------------+
| PacketType-specific fields | HeaderLength |
+---------------+---------------+---------------+---------------+
/ Optional hop-by-hop header TLVs /
+---------------+---------------+---------------+---------------+
/ PacketPayload TLVs /
+---------------+---------------+---------------+---------------+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Version | PacketType | PacketLength |
+---------------+---------------+---------------+---------------+
| PacketType-specific fields | HeaderLength |
+---------------+---------------+---------------+---------------+
/ Optional hop-by-hop header TLVs /
+---------------+---------------+---------------+---------------+
/ PacketPayload TLVs /
+---------------+---------------+---------------+---------------+
Figure 2: Overall Packet Format
图2：总体数据包格式
The PacketPayload of a CCNx Packet is the protocol message itself. The Content Object Hash is computed over the PacketPayload only, excluding the fixed and hop-by-hop headers, as those might change from hop to hop. Signed information or similarity hashes should not include any of the fixed or hop-by-hop headers. The PacketPayload should be self-sufficient in the event that the fixed and hop-by-hop headers are removed. See Message Hash (Section 3.4.3).
CCNx数据包的PacketPayload是协议消息本身。内容对象散列仅在PacketPayload上计算，不包括固定和逐跳的头，因为这些头可能会随跳而变化。签名信息或相似性哈希不应包括任何固定或逐跳的头。在移除固定和逐跳标头的情况下，PacketPayload应该是自给自足的。见消息散列（第3.4.3节）。
Following the CCNx Message TLV, the PacketPayload may include optional Validation TLVs.
在CCNx消息TLV之后，PacketPayload可以包括可选的验证TLV。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| CCNx Message TLV /
+---------------+---------------+---------------+---------------+
/ Optional CCNx ValidationAlgorithm TLV /
+---------------+---------------+---------------+---------------+
/ Optional CCNx ValidationPayload TLV (ValidationAlg required) /
+---------------+---------------+---------------+---------------+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| CCNx Message TLV /
+---------------+---------------+---------------+---------------+
/ Optional CCNx ValidationAlgorithm TLV /
+---------------+---------------+---------------+---------------+
/ Optional CCNx ValidationPayload TLV (ValidationAlg required) /
+---------------+---------------+---------------+---------------+
Figure 3: PacketPayload TLVs
图3：包装有效载荷TLV
After discarding the fixed and hop-by-hop headers, the remaining PacketPayload should be a valid protocol message. Therefore, the PacketPayload always begins with 4 bytes of type-length that specifies the protocol message (whether it is an Interest, Content Object, or other message type) and its total length. The embedding
丢弃固定和逐跳标头后，剩余的PacketPayload应该是有效的协议消息。因此，PacketPayload总是以4个字节的类型长度开始，指定协议消息（无论是兴趣、内容对象还是其他消息类型）及其总长度。嵌入
of a self-sufficient protocol data unit inside the fixed and hop-by-hop headers allows a network stack to discard the headers and operate only on the embedded message. It also decouples the PacketType field -- which specifies how to forward the packet -- from the PacketPayload.
在固定和逐跳报头中设置一个自给自足的协议数据单元，允许网络堆栈丢弃报头并仅对嵌入的消息进行操作。它还将PacketType字段（指定如何转发数据包）与PacketPayload分离。
The range of bytes protected by the Validation includes the CCNx Message TLV and the ValidationAlgorithm TLV.
受验证保护的字节范围包括CCNx消息TLV和ValidationGorithm TLV。
The ContentObjectHash begins with the CCNx Message TLV and ends at the tail of the CCNx Packet.
ContentObjectHash从CCNx消息TLV开始，在CCNx数据包的尾部结束。
In Figure 2, the fixed header fields are:
在图2中，固定标题字段为：
o Version: defines the version of the packet, which MUST be 1.
o 版本：定义数据包的版本，该版本必须为1。
o HeaderLength: The length of the fixed header (8 bytes) and hop-by-hop headers. The minimum value MUST be 8.
o HeaderLength：固定标头（8字节）和逐跳标头的长度。最小值必须为8。
o PacketType: describes forwarder actions to take on the packet.
o PacketType：描述转发器对数据包采取的操作。
o PacketLength: Total octets of packet including all headers (fixed header plus hop-by-hop headers) and protocol message.
o PacketLength：数据包的八位字节总数，包括所有报头（固定报头加上逐跳报头）和协议消息。
o PacketType-specific Fields: specific PacketTypes define the use of these bits.
o PacketType特定字段：特定的PacketType定义这些位的使用。
The PacketType field indicates how the forwarder should process the packet. A Request Packet (Interest) has PacketType PT_INTEREST, a Response (Content Object) has PacketType PT_CONTENT, and an Interest Return has PacketType PT_RETURN.
PacketType字段指示转发器应如何处理数据包。请求数据包（兴趣）具有PacketType PT_兴趣，响应（内容对象）具有PacketType PT_内容，兴趣返回具有PacketType PT_返回。
HeaderLength is the number of octets from the start of the CCNx Packet (Version) to the end of the hop-by-hop headers. PacketLength is the number of octets from the start of the packet to the end of the packet. Both lengths have a minimum value of 8 (the fixed header itself).
HeaderLength是从CCNx数据包（版本）开始到逐跳标头结束的八位字节数。PacketLength是从数据包开始到数据包结束的八位字节数。两个长度的最小值均为8（固定收割台本身）。
The PacketType-specific fields are reserved bits whose use depends on the PacketType. They are used for network-level signaling.
PacketType特定字段是保留位，其使用取决于PacketType。它们用于网络级信令。
If the PacketType is PT_INTEREST, it indicates that the packet should be forwarded following the Interest pipeline in Section 2.4.4 of [RFC8569]. For this type of packet, the Fixed Header includes a field for a HopLimit as well as Reserved and Flags fields. The Reserved field MUST be set to 0 in an Interest. There are currently no flags defined, so the Flags field MUST be set to 0.
如果PacketType为PT_INTEREST，则表示应按照[RFC8569]第2.4.4节中的INTEREST管道转发数据包。对于这种类型的数据包，固定报头包括一个hopflimit字段以及Reserved和Flags字段。利息中的保留字段必须设置为0。当前没有定义标志，因此标志字段必须设置为0。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Version | PT_INTEREST | PacketLength |
+---------------+---------------+---------------+---------------+
| HopLimit | Reserved | Flags | HeaderLength |
+---------------+---------------+---------------+---------------+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Version | PT_INTEREST | PacketLength |
+---------------+---------------+---------------+---------------+
| HopLimit | Reserved | Flags | HeaderLength |
+---------------+---------------+---------------+---------------+
Figure 4: Interest Header
图4：利息标题
For an Interest message, the HopLimit is a counter that is decremented with each hop. It limits the distance an Interest may travel on the network. The node originating the Interest MAY put in any value up to the maximum of 255. Each node that receives an Interest with a HopLimit decrements the value upon reception. If the value is 0 after the decrement, the Interest MUST NOT be forwarded off the node.
对于感兴趣的消息，HopLimit是一个计数器，它随每个跃点递减。它限制了兴趣在网络上的传播距离。发起兴趣的节点可以输入最大值为255的任何值。接收到具有跳数限制的兴趣的每个节点在接收时递减该值。如果减量后的值为0，则利息不得从节点转出。
It is an error to receive an Interest from a remote node with the HopLimit field set to 0.
从HopLimit字段设置为0的远程节点接收兴趣是错误的。
If the PacketType is PT_CONTENT, it indicates that the packet should be forwarded following the Content Object pipeline in Section 2.4.4 of [RFC8569]. A Content Object defines a Flags field; however, there are currently no flags defined, so the Flags field must be set to 0.
如果PacketType为PT_CONTENT，则表示应按照[RFC8569]第2.4.4节中的内容对象管道转发数据包。内容对象定义标志字段；但是，当前没有定义标志，因此标志字段必须设置为0。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Version | PT_CONTENT | PacketLength |
+---------------+---------------+---------------+---------------+
| Reserved | Flags | HeaderLength |
+---------------+---------------+---------------+---------------+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Version | PT_CONTENT | PacketLength |
+---------------+---------------+---------------+---------------+
| Reserved | Flags | HeaderLength |
+---------------+---------------+---------------+---------------+
Figure 5: Content Object Header
图5：内容对象头
If the PacketType is PT_RETURN, it indicates that the packet should be processed following the Interest Return rules in Section 10 of [RFC8569]. The only difference between this Interest Return message and the original Interest is that the PacketType is changed to PT_RETURN and a ReturnCode is put into the ReturnCode field. All other fields are unchanged from the Interest packet. The purpose of this encoding is to prevent packet length changes so no additional bytes are needed to return an Interest to the previous hop.
如果PacketType为PT_RETURN，则表示应按照[RFC8569]第10节中的利息返还规则处理该数据包。此利息返回消息与原始利息之间的唯一区别是，PacketType更改为PT_Return，并在ReturnCode字段中输入ReturnCode。兴趣数据包中的所有其他字段均保持不变。这种编码的目的是防止数据包长度的变化，因此不需要额外的字节来返回对上一跳的兴趣。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Version | PT_RETURN | PacketLength |
+---------------+---------------+---------------+---------------+
| HopLimit | ReturnCode | Flags | HeaderLength |
+---------------+---------------+---------------+---------------+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Version | PT_RETURN | PacketLength |
+---------------+---------------+---------------+---------------+
| HopLimit | ReturnCode | Flags | HeaderLength |
+---------------+---------------+---------------+---------------+
Figure 6: Interest Return Header
图6：利息回报标题
This is the original Interest's HopLimit, as received before decrement at the node sending the Interest Return.
这是原始利息的HopLimit，在发送利息返回的节点上减量之前收到。
These are the original Flags as set in the Interest.
这些是在兴趣中设置的原始标志。
This section maps the Return Code name [RFC8569] to the TLV symbolic name. Section 4.2 maps the symbolic names to numeric values. This field is set by the node creating the Interest Return.
本节将返回代码名[RFC8569]映射到TLV符号名。第4.2节将符号名称映射为数值。此字段由创建利息回报的节点设置。
A return code of "0" MUST NOT be used, as it indicates that the returning system did not modify the Return Code field.
不得使用返回代码“0”，因为它表示返回系统未修改返回代码字段。
+-------------------------------------+-----------------------------+
| Return Type | Name in RFC 8569 |
+-------------------------------------+-----------------------------+
| T_RETURN_NO_ROUTE | No Route |
| | |
| T_RETURN_LIMIT_EXCEEDED | Hop Limit Exceeded |
| | |
| T_RETURN_NO_RESOURCES | No Resources |
| | |
| T_RETURN_PATH_ERROR | Path Error |
| | |
| T_RETURN_PROHIBITED | Prohibited |
| | |
| T_RETURN_CONGESTED | Congested |
| | |
| T_RETURN_MTU_TOO_LARGE | MTU too large |
| | |
| T_RETURN_UNSUPPORTED_HASH_RESTRICTI | Unsupported ContentObjectHa |
| ON | shRestriction |
| | |
| T_RETURN_MALFORMED_INTEREST | Malformed Interest |
+-------------------------------------+-----------------------------+
+-------------------------------------+-----------------------------+
| Return Type | Name in RFC 8569 |
+-------------------------------------+-----------------------------+
| T_RETURN_NO_ROUTE | No Route |
| | |
| T_RETURN_LIMIT_EXCEEDED | Hop Limit Exceeded |
| | |
| T_RETURN_NO_RESOURCES | No Resources |
| | |
| T_RETURN_PATH_ERROR | Path Error |
| | |
| T_RETURN_PROHIBITED | Prohibited |
| | |
| T_RETURN_CONGESTED | Congested |
| | |
| T_RETURN_MTU_TOO_LARGE | MTU too large |
| | |
| T_RETURN_UNSUPPORTED_HASH_RESTRICTI | Unsupported ContentObjectHa |
| ON | shRestriction |
| | |
| T_RETURN_MALFORMED_INTEREST | Malformed Interest |
+-------------------------------------+-----------------------------+
Table 2: Return Codes
表2：返回代码
This section defines global formats that may be nested within other TLVs.
本节定义了可嵌套在其他TLV中的全局格式。
The pad type may be used by sources that prefer word-aligned data. Padding 4-byte words, for example, would use a 1-byte, 2-byte, and 3-byte Length. Padding 8-byte words would use a (0, 1, 2, 3, 5, 6, 7)-byte Length.
pad类型可由喜欢字对齐数据的源使用。例如，填充4字节的字将使用1字节、2字节和3字节的长度。填充8字节的字将使用（0、1、2、3、5、6、7）字节长度。
One MUST NOT pad inside a Name. Apart from that, a pad MAY be inserted after any other TLV in the CCNx Message TLV or in the ValidationAlgorithm TLV. In the remainder of this document, we will not show optional Pad TLVs.
一个人不能在名字里面填上字。除此之外，可以在CCNx消息TLV或ValidationAlgorithm TLV中的任何其他TLV之后插入pad。在本文档的其余部分中，我们将不显示可选的Pad TLV。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_PAD | Length |
+---------------+---------------+---------------+---------------+
/ variable-length pad MUST be zeros /
+---------------+---------------+---------------+---------------+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_PAD | Length |
+---------------+---------------+---------------+---------------+
/ variable-length pad MUST be zeros /
+---------------+---------------+---------------+---------------+
Figure 7: Pad Encoding
图7：Pad编码
Organization-specific TLVs (also known as Vendor TLVs) MUST use the T_ORG type. The Length field is the length of the organization-specific information plus 3. The Value begins with the 3 byte organization number derived from the network byte order encoding of the IANA "Private Enterprise Numbers" registry [IANA-PEN], followed by the organization-specific information.
特定于组织的TLV（也称为供应商TLV）必须使用T_组织类型。长度字段是组织特定信息的长度加上3。该值以源自IANA“私有企业编号”注册表[IANA-PEN]的网络字节顺序编码的3字节组织编号开始，然后是组织特定信息。
A T_ORG MAY be used as a path segment in a Name. It is treated like any other path segment.
组织可以用作名称中的路径段。它与任何其他路径段一样处理。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_ORG | Length (3+value length) |
+---------------+---------------+---------------+---------------+
| PEN[0] | PEN[1] | PEN[2] | /
+---------------+---------------+---------------+ +
/ Vendor Specific Value /
+---------------+---------------+---------------+---------------+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_ORG | Length (3+value length) |
+---------------+---------------+---------------+---------------+
| PEN[0] | PEN[1] | PEN[2] | /
+---------------+---------------+---------------+ +
/ Vendor Specific Value /
+---------------+---------------+---------------+---------------+
Figure 8: Organization-Specific TLVs
图8：特定于组织的TLV
Hash values are used in several fields throughout a packet. This TLV encoding is commonly embedded inside those fields to specify the specific hash function used and its value. Note that the reserved TLV types are also reserved here for user-defined experimental functions.
散列值在整个数据包的多个字段中使用。这种TLV编码通常嵌入在这些字段中，以指定使用的特定哈希函数及其值。请注意，这里还为用户定义的实验功能保留了保留的TLV类型。
The LENGTH field of the hash value MUST be less than or equal to the hash function length. If the LENGTH is less than the full length, it is taken as the left LENGTH bytes of the hash function output. Only specified truncations are allowed, not arbitrary truncations.
哈希值的长度字段必须小于或等于哈希函数长度。如果长度小于全长，则将其作为哈希函数输出的左长度字节。只允许指定的截断，不允许任意截断。
This nested format is used because it allows binary comparison of hash values for certain fields without a router needing to understand a new hash function. For example, the KeyIdRestriction is bit-wise compared between an Interest's KeyIdRestriction field and a ContentObject's KeyId field. This format means the outer field values do not change with differing hash functions so a router can still identify those fields and do a binary comparison of the hash TLV without need to understand the specific hash used. An alternative approach, such as using T_KEYID_SHA512-256, would require each router keeps an up-to-date parser and supporting user-defined hash functions here would explode the parsing state-space.
之所以使用这种嵌套格式，是因为它允许对某些字段的哈希值进行二进制比较，而无需路由器理解新的哈希函数。例如，在感兴趣的KeyIdRestriction字段和ContentObject的KeyId字段之间按位比较KeyIdRestriction。这种格式意味着外部字段值不会随哈希函数的不同而改变，因此路由器仍然可以识别这些字段并对哈希TLV进行二进制比较，而无需了解所使用的特定哈希。另一种方法，如使用T_KEYID_SHA512-256，要求每个路由器保持一个最新的解析器，并且这里支持用户定义的哈希函数将分解解析状态空间。
A CCNx entity MUST support the hash type T_SHA-256. An entity MAY support the remaining hash types.
CCNx实体必须支持哈希类型T_SHA-256。实体可以支持剩余的散列类型。
+-----------+------------------------+
| Abbrev | Lengths (octets) |
+-----------+------------------------+
| T_SHA-256 | 32 |
| | |
| T_SHA-512 | 64, 32 |
| | |
| n/a | Experimental TLV types |
+-----------+------------------------+
+-----------+------------------------+
| Abbrev | Lengths (octets) |
+-----------+------------------------+
| T_SHA-256 | 32 |
| | |
| T_SHA-512 | 64, 32 |
| | |
| n/a | Experimental TLV types |
+-----------+------------------------+
Table 3: CCNx Hash Functions
表3:CCNx哈希函数
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_FOO | 36 |
+---------------+---------------+---------------+---------------+
| T_SHA512 | 32 |
+---------------+---------------+---------------+---------------+
/ 32-byte hash value /
+---------------+---------------+---------------+---------------+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_FOO | 36 |
+---------------+---------------+---------------+---------------+
| T_SHA512 | 32 |
+---------------+---------------+---------------+---------------+
/ 32-byte hash value /
+---------------+---------------+---------------+---------------+
Figure 9: Example nesting inside type T_FOO
图9:T_FOO类型内部嵌套示例
A Link is the tuple: {Name, [KeyIdRestr], [ContentObjectHashRestr]}. It is a general encoding that is used in both the payload of a Content Object with PayloadType = "Link" and in a Content Object's KeyLink field. A Link is essentially the body of an Interest.
链接是元组：{Name，[KeyIdRestr]，[contentObjectHashRester]}。它是一种通用编码，用于PayloadType=“Link”内容对象的有效负载和内容对象的KeyLink字段。链接本质上是利益主体。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
/ Mandatory CCNx Name /
+---------------+---------------+---------------+---------------+
/ Optional KeyIdRestriction /
+---------------+---------------+---------------+---------------+
/ Optional ContentObjectHashRestriction /
+---------------+---------------+---------------+---------------+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
/ Mandatory CCNx Name /
+---------------+---------------+---------------+---------------+
/ Optional KeyIdRestriction /
+---------------+---------------+---------------+---------------+
/ Optional ContentObjectHashRestriction /
+---------------+---------------+---------------+---------------+
Figure 10: Link Encoding
图10：链接编码
Hop-by-hop TLV headers are unordered and meaning MUST NOT be attached to their ordering. Three hop-by-hop headers are described in this document:
逐跳TLV标题是无序的，其顺序中不得附加含义。本文档中描述了三个逐跳标题：
+-------------+--------------------+--------------------------------+
| Abbrev | Name | Description |
+-------------+--------------------+--------------------------------+
| T_INTLIFE | Interest Lifetime | The time an Interest should |
| | (Section 3.4.1) | stay pending at an |
| | | intermediate node. |
| | | |
| T_CACHETIME | Recommended Cache | The Recommended Cache Time for |
| | Time (Section | Content Objects. |
| | 3.4.2) | |
| | | |
| T_MSGHASH | Message Hash | A cryptographic hash (Section |
| | (Section 3.4.3) | 3.3.3). |
+-------------+--------------------+--------------------------------+
+-------------+--------------------+--------------------------------+
| Abbrev | Name | Description |
+-------------+--------------------+--------------------------------+
| T_INTLIFE | Interest Lifetime | The time an Interest should |
| | (Section 3.4.1) | stay pending at an |
| | | intermediate node. |
| | | |
| T_CACHETIME | Recommended Cache | The Recommended Cache Time for |
| | Time (Section | Content Objects. |
| | 3.4.2) | |
| | | |
| T_MSGHASH | Message Hash | A cryptographic hash (Section |
| | (Section 3.4.3) | 3.3.3). |
+-------------+--------------------+--------------------------------+
Table 4: Hop-by-Hop Header Types
表4：逐跳标头类型
Additional hop-by-hop headers are defined in higher level specifications such as the fragmentation specification.
在更高级别的规范（如碎片规范）中定义了额外的逐跳标头。
The Interest Lifetime is the time that an Interest should stay pending at an intermediate node. It is expressed in milliseconds as an unsigned integer in network byte order.
兴趣生存期是指兴趣在中间节点处于挂起状态的时间。它以毫秒为单位表示为网络字节顺序的无符号整数。
A value of 0 (encoded as 1 byte 0x00) indicates the Interest does not elicit a Content Object response. It should still be forwarded, but no reply is expected and a forwarder could skip creating a PIT entry.
值0（编码为1字节0x00）表示该兴趣不会引发内容对象响应。仍应转发，但不需要回复，转发人可以跳过创建PIT条目。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_INTLIFE | Length |
+---------------+---------------+---------------+---------------+
/ /
/ Lifetime (Length octets) /
/ /
+---------------+---------------+---------------+---------------+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_INTLIFE | Length |
+---------------+---------------+---------------+---------------+
/ /
/ Lifetime (Length octets) /
/ /
+---------------+---------------+---------------+---------------+
Figure 11: Interest Lifetime Encoding
图11：兴趣生命周期编码
The Recommended Cache Time (RCT) is a measure of the useful lifetime of a Content Object as assigned by a content producer or upstream node. It serves as a guideline to the Content Store cache in determining how long to keep the Content Object. It is a recommendation only and may be ignored by the cache. This is in contrast to the ExpiryTime (described in Section 3.6.2.2.2) which takes precedence over the RCT and must be obeyed.
建议的缓存时间（RCT）是由内容生产者或上游节点分配的内容对象的有效生存期的度量。它作为内容存储缓存确定内容对象保留多长时间的指南。这只是一个建议，缓存可能会忽略它。这与过期时间（如第3.6.2.2.2节所述）相反，过期时间优先于RCT，必须遵守。
Because the Recommended Cache Time is an optional hop-by-hop header and not a part of the signed message, a content producer may re-issue a previously signed Content Object with an updated RCT without needing to re-sign the message. There is little ill effect from an attacker changing the RCT as the RCT serves as a guideline only.
由于建议的缓存时间是可选的逐跳标头，而不是已签名消息的一部分，因此内容生产者可以使用更新的RCT重新发布先前签名的内容对象，而无需重新签名消息。攻击者更改RCT的不良影响很小，因为RCT只是一个指南。
The Recommended Cache Time (a millisecond timestamp) is an unsigned integer in network byte order that indicates the time when the payload expires (as the number of milliseconds since the epoch in UTC). It is a 64-bit field.
建议的缓存时间（毫秒时间戳）是一个以网络字节顺序表示的无符号整数，表示有效负载过期的时间（以UTC为单位的历元后的毫秒数）。它是一个64位字段。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_CACHETIME | 8 |
+---------------+---------------+---------------+---------------+
/ /
/ Recommended Cache Time /
/ /
+---------------+---------------+---------------+---------------+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_CACHETIME | 8 |
+---------------+---------------+---------------+---------------+
/ /
/ Recommended Cache Time /
/ /
+---------------+---------------+---------------+---------------+
Figure 12: Recommended Cache Time Encoding
图12：推荐的缓存时间编码
Within a trusted domain, an operator may calculate the message hash at a border device and insert that value into the hop-by-hop headers of a message. An egress device should remove the value. This permits intermediate devices within that trusted domain to match against a ContentObjectHashRestriction without calculating it at every hop.
在可信域内，操作员可以计算边界设备上的消息哈希值，并将该值插入消息的逐跳标头中。出口设备应移除该值。这允许该受信任域中的中间设备与ContentObjectHashRestriction匹配，而无需在每个跃点计算它。
The message hash is a cryptographic hash from the start of the CCNx Message TLV to the end of the packet. It is used to match against the ContentObjectHashRestriction (Section 3.6.2.1.2). The Message Hash may be of longer length than an Interest's restriction, in which case the device should use the left bytes of the Message Hash to check against the Interest's value.
消息散列是从CCNx消息TLV开始到数据包结束的加密散列。它用于匹配ContentObjectHashRestriction（第3.6.2.1.2节）。消息散列的长度可能比兴趣的限制长，在这种情况下，设备应使用消息散列的左字节来检查兴趣的值。
The Message Hash may only carry one hash type and there may only be one Message Hash header.
消息哈希只能携带一种哈希类型，并且只能有一个消息哈希头。
The Message Hash header is unprotected, so this header is only of practical use within a trusted domain, such as an operator's autonomous system.
消息哈希头不受保护，因此此头仅在受信任域（如操作员的自治系统）中实际使用。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_MSGHASH | (length + 4) |
+---------------+---------------+---------------+---------------+
| hash type | length |
+---------------+---------------+---------------+---------------+
/ hash value /
+---------------+---------------+---------------+---------------+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_MSGHASH | (length + 4) |
+---------------+---------------+---------------+---------------+
| hash type | length |
+---------------+---------------+---------------+---------------+
/ hash value /
+---------------+---------------+---------------+---------------+
Figure 13: Message Hash Header
图13：消息哈希头
The top-level TLV types listed below exist at the outermost level of a CCNx Message TLV.
下面列出的顶级TLV类型存在于CCNx消息TLV的最外层。
+----------------------+------------+-------------------------------+
| Abbrev | Name | Description |
+----------------------+------------+-------------------------------+
| T_INTEREST | Interest | An Interest MessageType. |
| | (Section | |
| | 3.6) | |
| | | |
| T_OBJECT | Content | A Content Object MessageType |
| | Object | |
| | (Section | |
| | 3.6) | |
| | | |
| T_VALIDATION_ALG | Validation | The method of message |
| | Algorithm | verification such as a |
| | (Section | Message Integrity Check |
| | 3.6.4.1) | (MIC), Message Authentication |
| | | Code (MAC), or cryptographic |
| | | signature. |
| | | |
| T_VALIDATION_PAYLOAD | Validation | The validation output, such |
| | Payload | as the CRC32C code or the RSA |
| | (Section | signature. |
| | 3.6.4.2) | |
+----------------------+------------+-------------------------------+
+----------------------+------------+-------------------------------+
| Abbrev | Name | Description |
+----------------------+------------+-------------------------------+
| T_INTEREST | Interest | An Interest MessageType. |
| | (Section | |
| | 3.6) | |
| | | |
| T_OBJECT | Content | A Content Object MessageType |
| | Object | |
| | (Section | |
| | 3.6) | |
| | | |
| T_VALIDATION_ALG | Validation | The method of message |
| | Algorithm | verification such as a |
| | (Section | Message Integrity Check |
| | 3.6.4.1) | (MIC), Message Authentication |
| | | Code (MAC), or cryptographic |
| | | signature. |
| | | |
| T_VALIDATION_PAYLOAD | Validation | The validation output, such |
| | Payload | as the CRC32C code or the RSA |
| | (Section | signature. |
| | 3.6.4.2) | |
+----------------------+------------+-------------------------------+
Table 5: CCNx Top Level Types
表5:CCNx顶级类型
This is the format for the CCNx Message itself. The CCNx Message TLV is the portion of the CCNx Packet between the hop-by-hop headers and the Validation TLVs. The figure below is an expansion of the "CCNx Message TLV" depicted in the beginning of Section 3. The CCNx Message TLV begins with MessageType and runs through the optional Payload. The same general format is used for both Interest and Content Object messages which are differentiated by the MessageType field. The first enclosed TLV of a CCNx Message TLV is always the Name TLV, if present. This is followed by an optional Message TLVs and an optional Payload TLV.
这是CCNx消息本身的格式。CCNx消息TLV是CCNx数据包中逐跳标头和验证TLV之间的部分。下图是第3节开头描述的“CCNx消息TLV”的扩展。CCNx消息TLV以MessageType开始，并在可选负载中运行。相同的通用格式用于兴趣和内容对象消息，它们由MessageType字段区分。CCNx消息TLV的第一个封闭TLV始终是名称TLV（如果存在）。随后是可选消息TLV和可选有效负载TLV。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| MessageType | MessageLength |
+---------------+---------------+---------------+---------------+
/ Name TLV (Type = T_NAME) /
+---------------+---------------+---------------+---------------+
/ Optional Message TLVs (Various Types) /
+---------------+---------------+---------------+---------------+
/ Optional Payload TLV (Type = T_PAYLOAD) /
+---------------+---------------+---------------+---------------+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| MessageType | MessageLength |
+---------------+---------------+---------------+---------------+
/ Name TLV (Type = T_NAME) /
+---------------+---------------+---------------+---------------+
/ Optional Message TLVs (Various Types) /
+---------------+---------------+---------------+---------------+
/ Optional Payload TLV (Type = T_PAYLOAD) /
+---------------+---------------+---------------+---------------+
Figure 14: CCNx Message TLV Encoding
图14:CCNx消息TLV编码
+-----------+---------------+---------------------------------------+
| Abbrev | Name | Description |
+-----------+---------------+---------------------------------------+
| T_NAME | Name (Section | The CCNx Name requested in an |
| | 3.6.1) | Interest or published in a Content |
| | | Object. |
| | | |
| T_PAYLOAD | Payload | The message payload. |
| | (Section | |
| | 3.6.3) | |
+-----------+---------------+---------------------------------------+
+-----------+---------------+---------------------------------------+
| Abbrev | Name | Description |
+-----------+---------------+---------------------------------------+
| T_NAME | Name (Section | The CCNx Name requested in an |
| | 3.6.1) | Interest or published in a Content |
| | | Object. |
| | | |
| T_PAYLOAD | Payload | The message payload. |
| | (Section | |
| | 3.6.3) | |
+-----------+---------------+---------------------------------------+
Table 6: CCNx Message TLV Types
表6:CCNx消息TLV类型
A Name is a TLV encoded sequence of segments. The table below lists the type values appropriate for these name segments. A Name MUST NOT include Pad TLVs.
名称是TLV编码的段序列。下表列出了适用于这些名称段的类型值。名称不得包含Pad TLV。
As described in CCNx Semantics [RFC8569], using the CCNx URI [CCNxURI] notation, a T_NAME with zero length corresponds to "ccnx:/" (the default route). The message grammar does not allow the first name segment to have zero length in a CCNx Message TLV Name. In the TLV encoding, "ccnx:/" corresponds to T_NAME with zero length.
如CCNx语义[RFC8569]所述，使用CCNx URI[CCNxURI]表示法，长度为零的T_名称对应于“CCNx:/”（默认路由）。消息语法不允许名字段在CCNx消息TLV名称中的长度为零。在TLV编码中，“ccnx:/”对应于长度为零的T_名称。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_NAME | Length |
+---------------+---------------+---------------+---------------+
/ Name segment TLVs /
+---------------+---------------+---------------+---------------+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_NAME | Length |
+---------------+---------------+---------------+---------------+
/ Name segment TLVs /
+---------------+---------------+---------------+---------------+
Figure 15: Name Encoding
图15：名称编码
+---------------+-------------+-------------------------------------+
| Symbolic Name | Name | Description |
+---------------+-------------+-------------------------------------+
| T_NAMESEGMENT | Name | A generic name segment. |
| | segment | |
| | (Section | |
| | 3.6.1.1) | |
| | | |
| T_IPID | Interest | An identifier that represents the |
| | Payload ID | Interest Payload field. As an |
| | (Section | example, the Payload ID might be a |
| | 3.6.1.2) | hash of the Interest Payload. This |
| | | provides a way to differentiate |
| | | between Interests based on their |
| | | payloads without having to parse |
| | | all the bytes of the payload |
| | | itself, and instead using only this |
| | | Payload ID name segment. |
| | | |
| T_APP:00 - | Application | Application-specific payload in a |
| T_APP:4096 | Components | name segment. An application may |
| | (Section | apply its own semantics to the 4096 |
| | 3.6.1.1) | reserved types. |
+---------------+-------------+-------------------------------------+
+---------------+-------------+-------------------------------------+
| Symbolic Name | Name | Description |
+---------------+-------------+-------------------------------------+
| T_NAMESEGMENT | Name | A generic name segment. |
| | segment | |
| | (Section | |
| | 3.6.1.1) | |
| | | |
| T_IPID | Interest | An identifier that represents the |
| | Payload ID | Interest Payload field. As an |
| | (Section | example, the Payload ID might be a |
| | 3.6.1.2) | hash of the Interest Payload. This |
| | | provides a way to differentiate |
| | | between Interests based on their |
| | | payloads without having to parse |
| | | all the bytes of the payload |
| | | itself, and instead using only this |
| | | Payload ID name segment. |
| | | |
| T_APP:00 - | Application | Application-specific payload in a |
| T_APP:4096 | Components | name segment. An application may |
| | (Section | apply its own semantics to the 4096 |
| | 3.6.1.1) | reserved types. |
+---------------+-------------+-------------------------------------+
Table 7: CCNx Name Types
表7:CCNx名称类型
4096 special application payload name segments are allocated. These have application semantics applied to them. A good convention is to put the application's identity in the name prior to using these name segments.
分配了4096个特殊应用程序有效负载名称段。它们应用了应用程序语义。一个好的约定是在使用这些名称段之前将应用程序的标识放在名称中。
For example, a name like "ccnx:/foo/bar/hi" would be encoded as:
例如，“ccnx:/foo/bar/hi”这样的名称将被编码为：
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| (T_NAME) | 0x14 (20) |
+---------------+---------------+---------------+---------------+
| (T_NAME_SEGMENT) | 0x03 (3) |
+---------------+---------------+---------------+---------------+
| f o o |(T_NAME_SEGMENT)
+---------------+---------------+---------------+---------------+
| | 0x03 (3) | b |
+---------------+---------------+---------------+---------------+
| a r | (T_NAME_SEGMENT) |
+---------------+---------------+---------------+---------------+
| 0x02 (2) | h | i |
+---------------+---------------+---------------+---------------+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| (T_NAME) | 0x14 (20) |
+---------------+---------------+---------------+---------------+
| (T_NAME_SEGMENT) | 0x03 (3) |
+---------------+---------------+---------------+---------------+
| f o o |(T_NAME_SEGMENT)
+---------------+---------------+---------------+---------------+
| | 0x03 (3) | b |
+---------------+---------------+---------------+---------------+
| a r | (T_NAME_SEGMENT) |
+---------------+---------------+---------------+---------------+
| 0x02 (2) | h | i |
+---------------+---------------+---------------+---------------+
Figure 16: Name Encoding Example
图16：名称编码示例
The InterestPayloadID is a name segment created by the origin of an Interest to represent the Interest Payload. This allows the proper multiplexing of Interests based on their name if they have different payloads. A common representation is to use a hash of the Interest Payload as the InterestPayloadID.
InterestPayloadID是由兴趣来源创建的名称段，用于表示兴趣负载。这允许在不同有效负载的情况下，根据兴趣的名称进行适当的多路复用。一种常见的表示方法是使用兴趣负载的散列作为InterestPayloadID。
As part of the Value of the TLV, the InterestPayloadID contains a one-octet identifier of the method used to create the InterestPayloadID followed by a variable-length octet string. An implementation is not required to implement any of the methods to receive an Interest; the InterestPayloadID may be treated only as an opaque octet string for the purposes of multiplexing Interests with different payloads. Only a device creating an InterestPayloadID name segment or a device verifying such a segment needs to implement the algorithms.
作为TLV值的一部分，InterestPayloadID包含用于创建InterestPayloadID的方法的一个八位标识符，后跟一个可变长度的八位字符串。无需实施任何方法即可获得利息；为了使用不同的有效载荷复用兴趣，可以仅将InterestPayloadID视为不透明的八位字节字符串。只有创建InterestPayloadID名称段的设备或验证此类段的设备需要实现算法。
It uses the encoding of hash values specified in Section 3.3.3.
它使用第3.3.3节中规定的哈希值编码。
In normal operations, we recommend displaying the InterestPayloadID as an opaque octet string in a CCNx URI, as this is the common denominator for implementation parsing.
在正常操作中，我们建议将InterestPayloadID显示为CCNx URI中的不透明八位字节字符串，因为这是实现解析的公分母。
The InterestPayloadID, even if it is a hash, should not convey any security context. If a system requires confirmation that a specific entity created the InterestPayload, it should use a cryptographic signature on the Interest via the ValidationAlgorithm and ValidationPayload or use its own methods inside the Interest Payload.
InterestPayloadID即使是散列，也不应传递任何安全上下文。如果系统需要确认某个特定实体创建了InterestPayload，则应通过ValidationGorithm和ValidationPayload在兴趣上使用加密签名，或在兴趣负载内使用自己的方法。
Each message type (Interest or Content Object) is associated with a set of optional Message TLVs. Additional specification documents may extend the types associated with each.
每个消息类型（兴趣或内容对象）都与一组可选消息TLV相关联。附加规范文件可扩展与每个规范相关的类型。
There are two Message TLVs currently associated with an Interest message: the KeyIdRestriction selector and the ContentObjectHashRestr selector are used to narrow the universe of acceptable Content Objects that would satisfy the Interest.
当前有两个消息TLV与兴趣消息关联：KeyIdRestriction选择器和ContentObjectHashRestr选择器用于缩小满足兴趣的可接受内容对象的范围。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| MessageType | MessageLength |
+---------------+---------------+---------------+---------------+
| Name TLV |
+---------------+---------------+---------------+---------------+
/ Optional KeyIdRestriction TLV /
+---------------------------------------------------------------+
/ Optional ContentObjectHashRestriction TLV /
+---------------------------------------------------------------+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| MessageType | MessageLength |
+---------------+---------------+---------------+---------------+
| Name TLV |
+---------------+---------------+---------------+---------------+
/ Optional KeyIdRestriction TLV /
+---------------------------------------------------------------+
/ Optional ContentObjectHashRestriction TLV /
+---------------------------------------------------------------+
Figure 17: Interest Message TLVs
图17：兴趣消息TLV
+----------------+------------------------------+-------------------+
| Abbrev | Name | Description |
+----------------+------------------------------+-------------------+
| T_KEYIDRESTR | KeyIdRestriction (Section | A representation |
| | 3.6.2.1.1) | (as per Section |
| | | 3.3.3) of the |
| | | KeyId |
| | | |
| T_OBJHASHRESTR | ContentObjectHashRestriction | A representation |
| | (Section 3.6.2.1.2) | (as per Section |
| | | 3.3.3) of the |
| | | hash of the |
| | | specific Content |
| | | Object that would |
| | | satisfy the |
| | | Interest. |
+----------------+------------------------------+-------------------+
+----------------+------------------------------+-------------------+
| Abbrev | Name | Description |
+----------------+------------------------------+-------------------+
| T_KEYIDRESTR | KeyIdRestriction (Section | A representation |
| | 3.6.2.1.1) | (as per Section |
| | | 3.3.3) of the |
| | | KeyId |
| | | |
| T_OBJHASHRESTR | ContentObjectHashRestriction | A representation |
| | (Section 3.6.2.1.2) | (as per Section |
| | | 3.3.3) of the |
| | | hash of the |
| | | specific Content |
| | | Object that would |
| | | satisfy the |
| | | Interest. |
+----------------+------------------------------+-------------------+
Table 8: CCNx Interest Message TLV Types
表8:CCNx兴趣消息TLV类型
An Interest MAY include a KeyIdRestriction selector. This ensures that only Content Objects with matching KeyIds will satisfy the Interest. See Section 3.6.4.1.4.1 for the format of a KeyId.
兴趣可以包括KeyIdRestriction选择器。这确保只有具有匹配keyid的内容对象才能满足兴趣。有关密钥ID的格式，请参见第3.6.4.1.4.1节。
An Interest MAY contain a ContentObjectHashRestriction selector. This is the hash of the Content Object -- the self-certifying name restriction that must be verified in the network, if an Interest carried this restriction (see Message Hash (Section 3.4.3)). The LENGTH MUST be from one of the allowed values for that hash (see Section 3.3.3).
兴趣可能包含ContentObjectHashRestriction选择器。这是内容对象的散列——必须在网络中验证的自认证名称限制，如果某个兴趣具有此限制（请参阅消息散列（第3.4.3节））。长度必须是该散列允许的值之一（见第3.3.3节）。
The ContentObjectHashRestriction SHOULD be of type T_SHA-256 and of length 32 bytes.
ContentObjectHashRestriction的类型应为T_SHA-256，长度为32字节。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_OBJHASHRESTR | (LENGTH+4) |
+---------------+---------------+---------------+---------------+
| hash type | LENGTH |
+---------------+---------------+---------------+---------------+
/ LENGTH octets of hash /
+---------------+---------------+---------------+---------------+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_OBJHASHRESTR | (LENGTH+4) |
+---------------+---------------+---------------+---------------+
| hash type | LENGTH |
+---------------+---------------+---------------+---------------+
/ LENGTH octets of hash /
+---------------+---------------+---------------+---------------+
Figure 18: ContentObjectHashRestriction Encoding
图18:ContentObjectHashRestriction编码
The following message TLVs are currently defined for Content Objects: PayloadType (optional) and ExpiryTime (optional).
当前为内容对象定义了以下消息TLV：PayloadType（可选）和ExpiryTime（可选）。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| MessageType | MessageLength |
+---------------+---------------+---------------+---------------+
| Name TLV |
+---------------+---------------+---------------+---------------+
/ Optional PayloadType TLV /
+---------------------------------------------------------------+
/ Optional ExpiryTime TLV /
+---------------------------------------------------------------+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| MessageType | MessageLength |
+---------------+---------------+---------------+---------------+
| Name TLV |
+---------------+---------------+---------------+---------------+
/ Optional PayloadType TLV /
+---------------------------------------------------------------+
/ Optional ExpiryTime TLV /
+---------------------------------------------------------------+
Figure 19: Content Object Message TLVs
图19：内容对象消息TLV
+-------------+-------------+---------------------------------------+
| Abbrev | Name | Description |
+-------------+-------------+---------------------------------------+
| T_PAYLDTYPE | PayloadType | Indicates the type of Payload |
| | (Section | contents. |
| | 3.6.2.2.1) | |
| | | |
| T_EXPIRY | ExpiryTime | The time at which the Payload |
| | (Section | expires, as expressed in the number |
| | 3.6.2.2.2) | of milliseconds since the epoch in |
| | | UTC. If missing, Content Object may |
| | | be used as long as desired. |
+-------------+-------------+---------------------------------------+
+-------------+-------------+---------------------------------------+
| Abbrev | Name | Description |
+-------------+-------------+---------------------------------------+
| T_PAYLDTYPE | PayloadType | Indicates the type of Payload |
| | (Section | contents. |
| | 3.6.2.2.1) | |
| | | |
| T_EXPIRY | ExpiryTime | The time at which the Payload |
| | (Section | expires, as expressed in the number |
| | 3.6.2.2.2) | of milliseconds since the epoch in |
| | | UTC. If missing, Content Object may |
| | | be used as long as desired. |
+-------------+-------------+---------------------------------------+
Table 9: CCNx Content Object Message TLV Types
表9:CCNx内容对象消息TLV类型
The PayloadType is an octet representing the general type of the Payload TLV.
PayloadType是表示有效负载TLV的一般类型的八位字节。
o T_PAYLOADTYPE_DATA: Data (possibly encrypted)
o T_PAYLOADTYPE_数据：数据（可能加密）
o T_PAYLOADTYPE_KEY: Key
o T\u PAYLOADTYPE\u键：键
o T_PAYLOADTYPE_LINK: Link
o T_PAYLOADTYPE_链接：链接
The Data type indicates that the Payload of the ContentObject is opaque application bytes. The Key type indicates that the Payload is a DER-encoded public key. The Link type indicates that the Payload is one or more Links (Section 3.3.4). If this field is missing, a Data type is assumed.
数据类型指示ContentObject的负载是不透明的应用程序字节。密钥类型指示有效负载是DER编码的公钥。链路类型表示有效负载是一个或多个链路（第3.3.4节）。如果缺少此字段，则假定为数据类型。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_PAYLDTYPE | 1 |
+---------------+---------------+---------------+---------------+
| PayloadType |
+---------------+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_PAYLDTYPE | 1 |
+---------------+---------------+---------------+---------------+
| PayloadType |
+---------------+
Figure 20: PayloadType Encoding
图20：PayloadType编码
The ExpiryTime is the time at which the Payload expires, as expressed by a timestamp containing the number of milliseconds since the epoch in UTC. It is a network byte order unsigned integer in a 64-bit field. A cache or end system should not respond with a Content Object past its ExpiryTime. Routers forwarding a Content Object do not need to check the ExpiryTime. If the ExpiryTime field is missing, the Content Object has no expressed expiration, and a cache or end system may use the Content Object for as long as desired.
ExpiryTime是有效负载过期的时间，由时间戳表示，时间戳包含自UTC纪元以来的毫秒数。它是64位字段中的网络字节顺序无符号整数。缓存或终端系统不应在内容对象过期后响应。转发内容对象的路由器不需要检查过期时间。如果缺少ExpiryTime字段，则内容对象没有明确的过期期限，缓存或终端系统可以根据需要使用内容对象。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_EXPIRY | 8 |
+---------------+---------------+---------------+---------------+
/ ExpiryTime /
/ /
+---------------+---------------+---------------+---------------+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_EXPIRY | 8 |
+---------------+---------------+---------------+---------------+
/ ExpiryTime /
/ /
+---------------+---------------+---------------+---------------+
Figure 21: ExpiryTime encoding
图21：到期时间编码
The Payload TLV contains the content of the packet. It MAY be of zero length. If a packet does not have any payload, this field SHOULD be omitted, rather than being of zero length.
有效负载TLV包含数据包的内容。它可能是零长度的。如果数据包没有任何有效负载，则应忽略此字段，而不是长度为零的字段。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_PAYLOAD | Length |
+---------------+---------------+---------------+---------------+
/ Payload Contents /
+---------------+---------------+---------------+---------------+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_PAYLOAD | Length |
+---------------+---------------+---------------+---------------+
/ Payload Contents /
+---------------+---------------+---------------+---------------+
Figure 22: Payload Encoding
图22：有效载荷编码
Both Interests and Content Objects have the option to include information about how to validate the CCNx Message. This information is contained in two TLVs: the ValidationAlgorithm TLV and the ValidationPayload TLV. The ValidationAlgorithm TLV specifies the mechanism to be used to verify the CCNx Message. Examples include verification with a Message Integrity Check (MIC), a Message Authentication Code (MAC), or a cryptographic signature. The ValidationPayload TLV contains the validation output, such as the CRC32C code or the RSA signature.
兴趣和内容对象都可以选择包含有关如何验证CCNx消息的信息。此信息包含在两个TLV中：ValidationGorithm TLV和ValidationPayload TLV。ValidationAlgorithm TLV指定用于验证CCNx消息的机制。示例包括使用消息完整性检查（MIC）、消息身份验证码（MAC）或加密签名进行验证。ValidationPayload TLV包含验证输出，例如CRC32C代码或RSA签名。
An Interest would most likely only use a MIC type of validation -- a CRC, checksum, or digest.
兴趣很可能只使用MIC类型的验证——CRC、校验和或摘要。
The ValidationAlgorithm is a set of nested TLVs containing all of the information needed to verify the message. The outermost container has type = T_VALIDATION_ALG. The first nested TLV defines the specific type of validation to be performed on the message. The type is identified with the "ValidationType" as shown in the figure below and elaborated in the table below. Nested within that container are the TLVs for any ValidationType-dependent data -- for example, a Key Id, Key Locator, etc.
ValidationAlgorithm是一组嵌套的TLV，其中包含验证消息所需的所有信息。最外层的容器具有type=T\u VALIDATION\u ALG。第一个嵌套TLV定义要对消息执行的特定验证类型。该类型由“ValidationType”标识，如下图所示，并在下表中详细说明。该容器中嵌套了任何ValidationType相关数据的TLV，例如，密钥Id、密钥定位器等。
Complete examples of several types may be found in Section 3.6.4.1.5.
几种类型的完整示例见第3.6.4.1.5节。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_VALIDATION_ALG | ValidationAlgLength |
+---------------+---------------+---------------+---------------+
| ValidationType | Length |
+---------------+---------------+---------------+---------------+
/ ValidationType-dependent data /
+---------------+---------------+---------------+---------------+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_VALIDATION_ALG | ValidationAlgLength |
+---------------+---------------+---------------+---------------+
| ValidationType | Length |
+---------------+---------------+---------------+---------------+
/ ValidationType-dependent data /
+---------------+---------------+---------------+---------------+
Figure 23: Validation Algorithm Encoding
图23：验证算法编码
+-----------------+---------------+---------------------------------+
| Abbrev | Name | Description |
+-----------------+---------------+---------------------------------+
| T_CRC32C | CRC32C | Castagnoli CRC32 (iSCSI, ext4, |
| | (Section | etc.) with normal form |
| | 3.6.4.1.1) | polynomial 0x1EDC6F41. |
| | | |
| T_HMAC-SHA256 | HMAC-SHA256 | HMAC (RFC 2104) using SHA256 |
| | (Section | hash. |
| | 3.6.4.1.2) | |
| | | |
| T_RSA-SHA256 | RSA-SHA256 | RSA public-key signature using |
| | (Section | SHA256 digest. |
| | 3.6.4.1.3) | |
| | | |
| T_EC-SECP-256K1 | SECP-256K1 | Elliptic Curve signature with |
| | (Section | SECP-256K1 parameters (see |
| | 3.6.4.1.3) | [ECC]). |
| | | |
| T_EC-SECP-384R1 | SECP-384R1 | Elliptic Curve signature with |
| | (Section | SECP-384R1 parameters (see |
| | 3.6.4.1.3) | [ECC]). |
+-----------------+---------------+---------------------------------+
+-----------------+---------------+---------------------------------+
| Abbrev | Name | Description |
+-----------------+---------------+---------------------------------+
| T_CRC32C | CRC32C | Castagnoli CRC32 (iSCSI, ext4, |
| | (Section | etc.) with normal form |
| | 3.6.4.1.1) | polynomial 0x1EDC6F41. |
| | | |
| T_HMAC-SHA256 | HMAC-SHA256 | HMAC (RFC 2104) using SHA256 |
| | (Section | hash. |
| | 3.6.4.1.2) | |
| | | |
| T_RSA-SHA256 | RSA-SHA256 | RSA public-key signature using |
| | (Section | SHA256 digest. |
| | 3.6.4.1.3) | |
| | | |
| T_EC-SECP-256K1 | SECP-256K1 | Elliptic Curve signature with |
| | (Section | SECP-256K1 parameters (see |
| | 3.6.4.1.3) | [ECC]). |
| | | |
| T_EC-SECP-384R1 | SECP-384R1 | Elliptic Curve signature with |
| | (Section | SECP-384R1 parameters (see |
| | 3.6.4.1.3) | [ECC]). |
+-----------------+---------------+---------------------------------+
Table 10: CCNx Validation Types
表10:CCNx验证类型
MICs do not require additional data in order to perform the verification. An example is CRC32C that has a zero-length value.
MICs不需要额外数据来执行验证。例如，长度值为零的CRC32C。
MACs are useful for communication between two trusting parties who have already shared secret keys. An example is the HMAC algorithm. A MAC uses the KeyId field to identify which shared secret is in use. The meaning of the KeyId is specific to the two parties involved and could be simply an integer to enumerate keys. If a new MAC requires an additional field, such as an Initialization Vector, that field would need to be defined as part of the updated specification.
MAC对于已经共享密钥的两个信任方之间的通信非常有用。HMAC算法就是一个例子。MAC使用KeyId字段标识正在使用的共享机密。KeyId的含义特定于所涉及的双方，可以是枚举密钥的简单整数。如果一个新的MAC需要一个额外的字段，如初始化向量，则该字段需要定义为更新规范的一部分。
Signature type Validators specify a digest mechanism and a signing algorithm to verify the message. Examples include an RSA signature on a SHA256 digest, an Elliptic Curve signature with SECP-256K1 parameters, etc. These Validators require a KeyId and a mechanism for locating the publisher's public key (a KeyLocator) -- and optionally a PublicKey or Certificate or KeyLink.
签名类型验证器指定摘要机制和签名算法来验证消息。示例包括SHA256摘要上的RSA签名、带有SECP-256K1参数的椭圆曲线签名等。这些验证器需要一个密钥ID和一种机制来定位发布者的公钥（密钥定位器），还可以选择公钥或证书或密钥链接。
Different Validation Algorithms require access to different pieces of data contained in the ValidationAlgorithm TLV. As described above, Key Ids, Key Locators, Public Keys, Certificates, Links, and Key Names all play a role in different Validation Algorithms. Any number of Validation-Dependent Data containers can be present in a Validation Algorithm TLV.
不同的验证算法需要访问ValidationAlgorithm TLV中包含的不同数据段。如上所述，密钥ID、密钥定位器、公钥、证书、链接和密钥名称都在不同的验证算法中发挥作用。验证算法TLV中可以存在任意数量的验证相关数据容器。
Below is a table of CCNx ValidationType-dependent data types:
以下是CCNx ValidationType相关数据类型表：
+-------------+-----------------+-----------------------------------+
| Abbrev | Name | Description |
+-------------+-----------------+-----------------------------------+
| T_KEYID | SignerKeyId | An identifier of the shared |
| | (Section | secret or public key associated |
| | 3.6.4.1.4.1) | with a MAC or Signature. |
| | | |
| T_PUBLICKEY | Public Key | DER-encoded public key. |
| | (Section | |
| | 3.6.4.1.4.2) | |
| | | |
| T_CERT | Certificate | DER-encoded X.509 certificate. |
| | (Section | |
| | 3.6.4.1.4.3) | |
| | | |
| T_KEYLINK | KeyLink | A CCNx Link object. |
| | (Section | |
| | 3.6.4.1.4.4) | |
| | | |
| T_SIGTIME | SignatureTime | A millisecond timestamp |
| | (Section | indicating the time when the |
| | 3.6.4.1.4.5) | signature was created. |
+-------------+-----------------+-----------------------------------+
+-------------+-----------------+-----------------------------------+
| Abbrev | Name | Description |
+-------------+-----------------+-----------------------------------+
| T_KEYID | SignerKeyId | An identifier of the shared |
| | (Section | secret or public key associated |
| | 3.6.4.1.4.1) | with a MAC or Signature. |
| | | |
| T_PUBLICKEY | Public Key | DER-encoded public key. |
| | (Section | |
| | 3.6.4.1.4.2) | |
| | | |
| T_CERT | Certificate | DER-encoded X.509 certificate. |
| | (Section | |
| | 3.6.4.1.4.3) | |
| | | |
| T_KEYLINK | KeyLink | A CCNx Link object. |
| | (Section | |
| | 3.6.4.1.4.4) | |
| | | |
| T_SIGTIME | SignatureTime | A millisecond timestamp |
| | (Section | indicating the time when the |
| | 3.6.4.1.4.5) | signature was created. |
+-------------+-----------------+-----------------------------------+
Table 11: CCNx Validation-Dependent Data Types
表11:CCNx验证相关数据类型
The KeyId for a signature is the publisher key identifier. It is similar to a Subject Key Identifier from X.509 (see Section 4.2.1.2 of [RFC5280]). It should be derived from the key used to sign, such as from the SHA-256 hash of the key. It applies to both public and private key systems and to symmetric key systems.
签名的密钥ID是发布者密钥标识符。它类似于X.509中的主题密钥标识符（见[RFC5280]第4.2.1.2节）。它应该从用于签名的密钥派生，例如从密钥的SHA-256散列派生。它适用于公钥和私钥系统以及对称密钥系统。
The KeyId is represented using the hash format in Section 3.3.3. If an application protocol uses a non-hash identifier, it should use one of the reserved values.
密钥ID使用第3.3.3节中的哈希格式表示。如果应用程序协议使用非哈希标识符，则应使用保留值之一。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_KEYID | LENGTH+4 |
+---------------+---------------+---------------+---------------+
| <hash type> | LENGTH |
+---------------+---------------+---------------+---------------+
/ LENGTH octets of hash /
+---------------+---------------+---------------+---------------+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_KEYID | LENGTH+4 |
+---------------+---------------+---------------+---------------+
| <hash type> | LENGTH |
+---------------+---------------+---------------+---------------+
/ LENGTH octets of hash /
+---------------+---------------+---------------+---------------+
Figure 24: KeyId Encoding
图24:KeyId编码
A Public Key is a DER-encoded Subject Public Key Info block, as in an X.509 certificate.
公钥是DER编码的主体公钥信息块，如X.509证书中所示。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_PUBLICKEY | Length |
+---------------+---------------+---------------+---------------+
/ Public Key (DER-encoded SPKI) /
+---------------+---------------+---------------+---------------+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_PUBLICKEY | Length |
+---------------+---------------+---------------+---------------+
/ Public Key (DER-encoded SPKI) /
+---------------+---------------+---------------+---------------+
Figure 25: Public Key Encoding
图25：公钥编码
A Certificate is a DER-encoded X.509 certificate. The KeyId (Section 3.6.4.1.4.1) is derived from this encoding.
证书是DER编码的X.509证书。KeyId（第3.6.4.1.4.1节）源自此编码。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_CERT | Length |
+---------------+---------------+---------------+---------------+
/ Certificate (DER-encoded X.509) /
+---------------+---------------+---------------+---------------+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_CERT | Length |
+---------------+---------------+---------------+---------------+
/ Certificate (DER-encoded X.509) /
+---------------+---------------+---------------+---------------+
Figure 26: Certificate Encoding
图26：证书编码
A KeyLink type KeyLocator is a Link.
KeyLink类型的KeyLocator是一个链接。
The KeyLink ContentObjectHashRestr, if included, is the digest of the Content Object identified by KeyLink, not the digest of the public key. Likewise, the KeyIdRestr of the KeyLink is the KeyId of the ContentObject, not necessarily of the wrapped key.
KeyLink ContentObjectHashRestr（如果包括）是由KeyLink标识的内容对象的摘要，而不是公钥的摘要。同样，KeyLink的KeyIDRest是ContentObject的KeyId，不一定是包装键的KeyId。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------------------------------+
| T_KEYLINK | Length |
+---------------+---------------+-------------------------------+
/ Link /
+---------------------------------------------------------------+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------------------------------+
| T_KEYLINK | Length |
+---------------+---------------+-------------------------------+
/ Link /
+---------------------------------------------------------------+
Figure 27: KeyLink Encoding
图27：键链接编码
The SignatureTime is a millisecond timestamp indicating the time at which a signature was created. The signer sets this field to the current time when creating a signature. A verifier may use this time to determine whether or not the signature was created during the validity period of a key, or if it occurred in a reasonable sequence with other associated signatures. The SignatureTime is unrelated to any time associated with the actual CCNx Message, which could have been created long before the signature. The default behavior is to always include a SignatureTime when creating an authenticated message (e.g., HMAC or RSA).
SignatureTime是毫秒时间戳，指示创建签名的时间。签名者将此字段设置为创建签名时的当前时间。验证者可以利用这段时间来确定签名是否是在密钥的有效期内创建的，或者它是否与其他相关签名以合理的顺序发生。SignatureTime与实际CCNx消息相关联的任何时间无关，实际CCNx消息可能早在签名之前就创建了。默认行为是在创建经过身份验证的消息（例如HMAC或RSA）时始终包含SignatureTime。
SignatureTime is an unsigned integer in network byte order that indicates when the signature was created (as the number of milliseconds since the epoch in UTC). It is a fixed 64-bit field.
SignatureTime是一个以网络字节顺序表示的无符号整数，表示签名的创建时间（以UTC为单位，表示自历元以来的毫秒数）。它是一个固定的64位字段。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------------------------------+
| T_SIGTIME | 8 |
+---------------+---------------+-------------------------------+
/ SignatureTime /
+---------------------------------------------------------------+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------------------------------+
| T_SIGTIME | 8 |
+---------------+---------------+-------------------------------+
/ SignatureTime /
+---------------------------------------------------------------+
Figure 28: SignatureTime Encoding
图28：签名时间编码
As an example of a MIC-type validation, the encoding for CRC32C validation would be:
作为话筒类型验证的示例，CRC32C验证的编码应为：
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_VALIDATION_ALG | 4 |
+---------------+---------------+---------------+---------------+
| T_CRC32C | 0 |
+---------------+---------------+---------------+---------------+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_VALIDATION_ALG | 4 |
+---------------+---------------+---------------+---------------+
| T_CRC32C | 0 |
+---------------+---------------+---------------+---------------+
Figure 29: CRC32C Encoding Example
图29:CRC32C编码示例
As an example of a MAC-type validation, the encoding for an HMAC using a SHA256 hash would be:
作为MAC类型验证的示例，使用SHA256散列的HMAC编码将为：
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_VALIDATION_ALG | 40 |
+---------------+---------------+---------------+---------------+
| T_HMAC-SHA256 | 36 |
+---------------+---------------+---------------+---------------+
| T_KEYID | 32 |
+---------------+---------------+---------------+---------------+
/ KeyId /
/---------------+---------------+-------------------------------+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_VALIDATION_ALG | 40 |
+---------------+---------------+---------------+---------------+
| T_HMAC-SHA256 | 36 |
+---------------+---------------+---------------+---------------+
| T_KEYID | 32 |
+---------------+---------------+---------------+---------------+
/ KeyId /
/---------------+---------------+-------------------------------+
Figure 30: HMAC-SHA256 Encoding Example
图30:HMAC-SHA256编码示例
As an example of a Signature-type validation, the encoding for an RSA public-key signature using a SHA256 digest and Public Key would be:
作为签名类型验证的示例，使用SHA256摘要和公钥的RSA公钥签名的编码为：
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_VALIDATION_ALG | 44 octets + Variable Length |
+---------------+---------------+---------------+---------------+
| T_RSA-SHA256 | 40 octets + Variable Length |
+---------------+---------------+---------------+---------------+
| T_KEYID | 32 |
+---------------+---------------+---------------+---------------+
/ KeyId /
/---------------+---------------+-------------------------------+
| T_PUBLICKEY | Variable Length (~160 octets)|
+---------------+---------------+---------------+---------------+
/ Public Key (DER-encoded SPKI) /
+---------------+---------------+---------------+---------------+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_VALIDATION_ALG | 44 octets + Variable Length |
+---------------+---------------+---------------+---------------+
| T_RSA-SHA256 | 40 octets + Variable Length |
+---------------+---------------+---------------+---------------+
| T_KEYID | 32 |
+---------------+---------------+---------------+---------------+
/ KeyId /
/---------------+---------------+-------------------------------+
| T_PUBLICKEY | Variable Length (~160 octets)|
+---------------+---------------+---------------+---------------+
/ Public Key (DER-encoded SPKI) /
+---------------+---------------+---------------+---------------+
Figure 31: RSA-SHA256 Encoding Example
图31:RSA-SHA256编码示例
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_VALIDATION_PAYLOAD | ValidationPayloadLength |
+---------------+---------------+---------------+---------------+
/ Type-dependent data /
+---------------+---------------+---------------+---------------+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_VALIDATION_PAYLOAD | ValidationPayloadLength |
+---------------+---------------+---------------+---------------+
/ Type-dependent data /
+---------------+---------------+---------------+---------------+
Figure 32: Validation Payload Encoding
图32：验证有效负载编码
The ValidationPayload contains the validation output, such as the CRC32C code or the RSA signature.
ValidationPayload包含验证输出，例如CRC32C代码或RSA签名。
This section details each kind of CCNx protocol value that can be registered. Each type registry can be updated by incrementally expanding the type space, i.e., by allocating and reserving new types. As per [RFC8126], this section details the creation of the "Content-Centric Networking (CCNx)" registry and several subregistries.
本节详细介绍了可以注册的每种CCNx协议值。可以通过增量扩展类型空间（即分配和保留新类型）来更新每个类型注册表。根据[RFC8126]，本节详细介绍了“以内容为中心的网络（CCNx）”注册中心和几个子区的创建。
IANA has created the "CCNx Packet Types" registry and allocated the packet types described below. The registration procedure is RFC Required. The Type value is 1 octet. The range is 0x00-0xFF.
IANA已经创建了“CCNx数据包类型”注册表，并分配了下面描述的数据包类型。注册程序是RFC要求的。类型值为1个八位字节。范围为0x00-0xFF。
+------+-------------+----------------------------------+
| Type | Name | Reference |
+------+-------------+----------------------------------+
| 0x00 | PT_INTEREST | Fixed Header Types (Section 3.2) |
| | | |
| 0x01 | PT_CONTENT | Fixed Header Types (Section 3.2) |
| | | |
| 0x02 | PT_RETURN | Fixed Header Types (Section 3.2) |
+------+-------------+----------------------------------+
+------+-------------+----------------------------------+
| Type | Name | Reference |
+------+-------------+----------------------------------+
| 0x00 | PT_INTEREST | Fixed Header Types (Section 3.2) |
| | | |
| 0x01 | PT_CONTENT | Fixed Header Types (Section 3.2) |
| | | |
| 0x02 | PT_RETURN | Fixed Header Types (Section 3.2) |
+------+-------------+----------------------------------+
Packet Types
数据包类型
IANA has created the "CCNx Interest Return Code Types" registry and allocated the Interest Return code types described below. The registration procedure is Specification Required. The Type value is 1 octet. The range is 0x00-0xFF.
IANA已经创建了“CCNx利息返还代码类型”注册表，并分配了下述利息返还代码类型。注册程序是必需的。类型值为1个八位字节。范围为0x00-0xFF。
+------+---------------------------------------+--------------------+
| Type | Name | Reference |
+------+---------------------------------------+--------------------+
| 0x00 | Reserved | |
| | | |
| 0x01 | T_RETURN_NO_ROUTE | Fixed Header Types |
| | | (Section 3.2.3.3) |
| | | |
| 0x02 | T_RETURN_LIMIT_EXCEEDED | Fixed Header Types |
| | | (Section 3.2.3.3) |
| | | |
| 0x03 | T_RETURN_NO_RESOURCES | Fixed Header Types |
| | | (Section 3.2.3.3) |
| | | |
| 0x04 | T_RETURN_PATH_ERROR | Fixed Header Types |
| | | (Section 3.2.3.3) |
| | | |
| 0x05 | T_RETURN_PROHIBITED | Fixed Header Types |
| | | (Section 3.2.3.3) |
| | | |
| 0x06 | T_RETURN_CONGESTED | Fixed Header Types |
| | | (Section 3.2.3.3) |
| | | |
| 0x07 | T_RETURN_MTU_TOO_LARGE | Fixed Header Types |
| | | (Section 3.2.3.3) |
| | | |
| 0x08 | T_RETURN_UNSUPPORTED_HASH_RESTRICTION | Fixed Header Types |
| | | (Section 3.2.3.3) |
| | | |
| 0x09 | T_RETURN_MALFORMED_INTEREST | Fixed Header Types |
| | | (Section 3.2.3.3) |
+------+---------------------------------------+--------------------+
+------+---------------------------------------+--------------------+
| Type | Name | Reference |
+------+---------------------------------------+--------------------+
| 0x00 | Reserved | |
| | | |
| 0x01 | T_RETURN_NO_ROUTE | Fixed Header Types |
| | | (Section 3.2.3.3) |
| | | |
| 0x02 | T_RETURN_LIMIT_EXCEEDED | Fixed Header Types |
| | | (Section 3.2.3.3) |
| | | |
| 0x03 | T_RETURN_NO_RESOURCES | Fixed Header Types |
| | | (Section 3.2.3.3) |
| | | |
| 0x04 | T_RETURN_PATH_ERROR | Fixed Header Types |
| | | (Section 3.2.3.3) |
| | | |
| 0x05 | T_RETURN_PROHIBITED | Fixed Header Types |
| | | (Section 3.2.3.3) |
| | | |
| 0x06 | T_RETURN_CONGESTED | Fixed Header Types |
| | | (Section 3.2.3.3) |
| | | |
| 0x07 | T_RETURN_MTU_TOO_LARGE | Fixed Header Types |
| | | (Section 3.2.3.3) |
| | | |
| 0x08 | T_RETURN_UNSUPPORTED_HASH_RESTRICTION | Fixed Header Types |
| | | (Section 3.2.3.3) |
| | | |
| 0x09 | T_RETURN_MALFORMED_INTEREST | Fixed Header Types |
| | | (Section 3.2.3.3) |
+------+---------------------------------------+--------------------+
CCNx Interest Return Types
CCNx利息回报类型
IANA has created the "CCNx Hop-by-Hop Types" registry and allocated the hop-by-hop types described below. The registration procedure is RFC Required. The Type value is 2 octets. The range is 0x0000-0xFFFF.
IANA已经创建了“CCNx逐跳类型”注册表，并分配了下面描述的逐跳类型。注册程序是RFC要求的。类型值为2个八位字节。范围为0x0000-0xFFFF。
+---------------+-------------+-------------------------------------+
| Type | Name | Reference |
+---------------+-------------+-------------------------------------+
| 0x0000 | Reserved | |
| | | |
| 0x0001 | T_INTLIFE | Hop-by-hop TLV headers (Section |
| | | 3.4) |
| | | |
| 0x0002 | T_CACHETIME | Hop-by-hop TLV headers (Section |
| | | 3.4) |
| | | |
| 0x0003 | T_MSGHASH | Hop-by-hop TLV headers (Section |
| | | 3.4) |
| | | |
| 0x0004 - | Reserved | |
| 0x0007 | | |
| | | |
| 0x0FFE | T_PAD | Pad (Section 3.3.1) |
| | | |
| 0x0FFF | T_ORG | Organization-Specific TLVs (Section |
| | | 3.3.2) |
| | | |
| 0x1000-0x1FFF | Reserved | Experimental Use (Section 3) |
+---------------+-------------+-------------------------------------+
+---------------+-------------+-------------------------------------+
| Type | Name | Reference |
+---------------+-------------+-------------------------------------+
| 0x0000 | Reserved | |
| | | |
| 0x0001 | T_INTLIFE | Hop-by-hop TLV headers (Section |
| | | 3.4) |
| | | |
| 0x0002 | T_CACHETIME | Hop-by-hop TLV headers (Section |
| | | 3.4) |
| | | |
| 0x0003 | T_MSGHASH | Hop-by-hop TLV headers (Section |
| | | 3.4) |
| | | |
| 0x0004 - | Reserved | |
| 0x0007 | | |
| | | |
| 0x0FFE | T_PAD | Pad (Section 3.3.1) |
| | | |
| 0x0FFF | T_ORG | Organization-Specific TLVs (Section |
| | | 3.3.2) |
| | | |
| 0x1000-0x1FFF | Reserved | Experimental Use (Section 3) |
+---------------+-------------+-------------------------------------+
CCNx Hop-by-Hop Types
CCNx逐跳类型
IANA has created the "CCNx Top-Level Types" registry and allocated the top-level types described below. The registration procedure is RFC Required. The Type value is 2 octets. The range is 0x0000-0xFFFF.
IANA已经创建了“CCNx顶级类型”注册表，并分配了下面描述的顶级类型。注册程序是RFC要求的。类型值为2个八位字节。范围为0x0000-0xFFFF。
+--------+----------------------+-------------------------------+
| Type | Name | Reference |
+--------+----------------------+-------------------------------+
| 0x0000 | Reserved | |
| | | |
| 0x0001 | T_INTEREST | Top-Level Types (Section 3.5) |
| | | |
| 0x0002 | T_OBJECT | Top-Level Types (Section 3.5) |
| | | |
| 0x0003 | T_VALIDATION_ALG | Top-Level Types (Section 3.5) |
| | | |
| 0x0004 | T_VALIDATION_PAYLOAD | Top-Level Types (Section 3.5) |
+--------+----------------------+-------------------------------+
+--------+----------------------+-------------------------------+
| Type | Name | Reference |
+--------+----------------------+-------------------------------+
| 0x0000 | Reserved | |
| | | |
| 0x0001 | T_INTEREST | Top-Level Types (Section 3.5) |
| | | |
| 0x0002 | T_OBJECT | Top-Level Types (Section 3.5) |
| | | |
| 0x0003 | T_VALIDATION_ALG | Top-Level Types (Section 3.5) |
| | | |
| 0x0004 | T_VALIDATION_PAYLOAD | Top-Level Types (Section 3.5) |
+--------+----------------------+-------------------------------+
CCNx Top-Level Types
CCNx顶级类型
IANA has created the "CCNx Name Segment Types" registry and allocated the name segment types described below. The registration procedure is Specification Required. The Type value is 2 octets. The range is 0x0000-0xFFFF.
IANA已经创建了“CCNx名称段类型”注册表，并分配了下述名称段类型。注册程序是必需的。类型值为2个八位字节。范围为0x0000-0xFFFF。
+--------------+------------------+---------------------------------+
| Type | Name | Reference |
+--------------+------------------+---------------------------------+
| 0x0000 | Reserved | |
| | | |
| 0x0001 | T_NAMESEGMENT | Name (Section 3.6.1) |
| | | |
| 0x0002 | T_IPID | Name (Section 3.6.1) |
| | | |
| 0x0010 - | Reserved | RFC 8609 |
| 0x0013 | | |
| | | |
| 0x0FFF | T_ORG | Organization-Specific TLVs |
| | | (Section 3.3.2) |
| | | |
| 0x1000 - | T_APP:00 - | Application Components (Section |
| 0x1FFF | T_APP:4096 | 3.6.1) |
+--------------+------------------+---------------------------------+
+--------------+------------------+---------------------------------+
| Type | Name | Reference |
+--------------+------------------+---------------------------------+
| 0x0000 | Reserved | |
| | | |
| 0x0001 | T_NAMESEGMENT | Name (Section 3.6.1) |
| | | |
| 0x0002 | T_IPID | Name (Section 3.6.1) |
| | | |
| 0x0010 - | Reserved | RFC 8609 |
| 0x0013 | | |
| | | |
| 0x0FFF | T_ORG | Organization-Specific TLVs |
| | | (Section 3.3.2) |
| | | |
| 0x1000 - | T_APP:00 - | Application Components (Section |
| 0x1FFF | T_APP:4096 | 3.6.1) |
+--------------+------------------+---------------------------------+
CCNx Name Segment Types
CCNx名称段类型
IANA has created the "CCNx Message Types" registry and registered the message segment types described below. The registration procedure is RFC Required. The Type value is 2 octets. The range is 0x0000-0xFFFF.
IANA已经创建了“CCNx消息类型”注册表，并注册了下面描述的消息段类型。注册程序是RFC要求的。类型值为2个八位字节。范围为0x0000-0xFFFF。
+---------------+----------------+----------------------------------+
| Type | Name | Reference |
+---------------+----------------+----------------------------------+
| 0x0000 | T_NAME | Message Types (Section 3.6) |
| | | |
| 0x0001 | T_PAYLOAD | Message Types (Section 3.6) |
| | | |
| 0x0002 | T_KEYIDRESTR | Message Types (Section 3.6) |
| | | |
| 0x0003 | T_OBJHASHRESTR | Message Types (Section 3.6) |
| | | |
| 0x0005 | T_PAYLDTYPE | Content Object Message Types |
| | | (Section 3.6.2.2) |
| | | |
| 0x0006 | T_EXPIRY | Content Object Message Types |
| | | (Section 3.6.2.2) |
| | | |
| 0x0007 - | Reserved | RFC 8609 |
| 0x000C | | |
| | | |
| 0x0FFE | T_PAD | Pad (Section 3.3.1) |
| | | |
| 0x0FFF | T_ORG | Organization-Specific TLVs |
| | | (Section 3.3.2) |
| | | |
| 0x1000-0x1FFF | Reserved | Experimental Use (Section 3) |
+---------------+----------------+----------------------------------+
+---------------+----------------+----------------------------------+
| Type | Name | Reference |
+---------------+----------------+----------------------------------+
| 0x0000 | T_NAME | Message Types (Section 3.6) |
| | | |
| 0x0001 | T_PAYLOAD | Message Types (Section 3.6) |
| | | |
| 0x0002 | T_KEYIDRESTR | Message Types (Section 3.6) |
| | | |
| 0x0003 | T_OBJHASHRESTR | Message Types (Section 3.6) |
| | | |
| 0x0005 | T_PAYLDTYPE | Content Object Message Types |
| | | (Section 3.6.2.2) |
| | | |
| 0x0006 | T_EXPIRY | Content Object Message Types |
| | | (Section 3.6.2.2) |
| | | |
| 0x0007 - | Reserved | RFC 8609 |
| 0x000C | | |
| | | |
| 0x0FFE | T_PAD | Pad (Section 3.3.1) |
| | | |
| 0x0FFF | T_ORG | Organization-Specific TLVs |
| | | (Section 3.3.2) |
| | | |
| 0x1000-0x1FFF | Reserved | Experimental Use (Section 3) |
+---------------+----------------+----------------------------------+
CCNx Message Types
CCNx消息类型
IANA has created the "CCNx Payload Types" registry and allocated the payload types described below. The registration procedure is Specification Required. The Type value is 1 octet. The range is 0x00-0xFF.
IANA已经创建了“CCNx有效负载类型”注册表，并分配了下面描述的有效负载类型。注册程序是必需的。类型值为1个八位字节。范围为0x00-0xFF。
+------+--------------------+-----------------------------------+
| Type | Name | Reference |
+------+--------------------+-----------------------------------+
| 0x00 | T_PAYLOADTYPE_DATA | Payload Types (Section 3.6.2.2.1) |
| | | |
| 0x01 | T_PAYLOADTYPE_KEY | Payload Types (Section 3.6.2.2.1) |
| | | |
| 0x02 | T_PAYLOADTYPE_LINK | Payload Types (Section 3.6.2.2.1) |
+------+--------------------+-----------------------------------+
+------+--------------------+-----------------------------------+
| Type | Name | Reference |
+------+--------------------+-----------------------------------+
| 0x00 | T_PAYLOADTYPE_DATA | Payload Types (Section 3.6.2.2.1) |
| | | |
| 0x01 | T_PAYLOADTYPE_KEY | Payload Types (Section 3.6.2.2.1) |
| | | |
| 0x02 | T_PAYLOADTYPE_LINK | Payload Types (Section 3.6.2.2.1) |
+------+--------------------+-----------------------------------+
CCNx Payload Types
CCNx有效负载类型
IANA has created the "CCNx Validation Algorithm Types" registry and allocated the validation algorithm types described below. The registration procedure is Specification Required. The Type value is 2 octets. The range is 0x0000-0xFFFF.
IANA已经创建了“CCNx验证算法类型”注册表，并分配了下面描述的验证算法类型。注册程序是必需的。类型值为2个八位字节。范围为0x0000-0xFFFF。
+---------------+-----------------+---------------------------------+
| Type | Name | Reference |
+---------------+-----------------+---------------------------------+
| 0x0000 | Reserved | |
| | | |
| 0x0002 | T_CRC32C | Validation Algorithm (Section |
| | | 3.6.4.1) |
| | | |
| 0x0004 | T_HMAC-SHA256 | Validation Algorithm (Section |
| | | 3.6.4.1) |
| | | |
| 0x0005 | T_RSA-SHA256 | Validation Algorithm (Section |
| | | 3.6.4.1) |
| | | |
| 0x0006 | T_EC-SECP-256K1 | Validation Algorithm (Section |
| | | 3.6.4.1) |
| | | |
| 0x0007 | T_EC-SECP-384R1 | Validation Algorithm (Section |
| | | 3.6.4.1) |
| | | |
| 0x0FFE | T_PAD | Pad (Section 3.3.1) |
| | | |
| 0x0FFF | T_ORG | Organization-Specific TLVs |
| | | (Section 3.3.2) |
| | | |
| 0x1000-0x1FFF | Reserved | Experimental Use (Section 3) |
+---------------+-----------------+---------------------------------+
+---------------+-----------------+---------------------------------+
| Type | Name | Reference |
+---------------+-----------------+---------------------------------+
| 0x0000 | Reserved | |
| | | |
| 0x0002 | T_CRC32C | Validation Algorithm (Section |
| | | 3.6.4.1) |
| | | |
| 0x0004 | T_HMAC-SHA256 | Validation Algorithm (Section |
| | | 3.6.4.1) |
| | | |
| 0x0005 | T_RSA-SHA256 | Validation Algorithm (Section |
| | | 3.6.4.1) |
| | | |
| 0x0006 | T_EC-SECP-256K1 | Validation Algorithm (Section |
| | | 3.6.4.1) |
| | | |
| 0x0007 | T_EC-SECP-384R1 | Validation Algorithm (Section |
| | | 3.6.4.1) |
| | | |
| 0x0FFE | T_PAD | Pad (Section 3.3.1) |
| | | |
| 0x0FFF | T_ORG | Organization-Specific TLVs |
| | | (Section 3.3.2) |
| | | |
| 0x1000-0x1FFF | Reserved | Experimental Use (Section 3) |
+---------------+-----------------+---------------------------------+
CCNx Validation Algorithm Types
CCNx验证算法类型
IANA has created the "CCNx Validation-Dependent Data Types" registry and allocated the validation-dependent data types described below. The registration procedure is RFC Required. The Type value is 2 octets. The range is 0x0000-0xFFFF.
IANA已经创建了“CCNx验证相关数据类型”注册表，并分配了下面描述的验证相关数据类型。注册程序是RFC要求的。类型值为2个八位字节。范围为0x0000-0xFFFF。
+---------------+----------------+----------------------------------+
| Type | Name | Reference |
+---------------+----------------+----------------------------------+
| 0x0000 | Reserved | |
| | | |
| 0x0009 | T_KEYID | Validation-Dependent Data |
| | | (Section 3.6.4.1.4) |
| | | |
| 0x000A | T_PUBLICKEYLOC | Validation-Dependent Data |
| | | (Section 3.6.4.1.4) |
| | | |
| 0x000B | T_PUBLICKEY | Validation-Dependent Data |
| | | (Section 3.6.4.1.4) |
| | | |
| 0x000C | T_CERT | Validation-Dependent Data |
| | | (Section 3.6.4.1.4) |
| | | |
| 0x000D | T_LINK | Validation-Dependent Data |
| | | (Section 3.6.4.1.4) |
| | | |
| 0x000E | T_KEYLINK | Validation-Dependent Data |
| | | (Section 3.6.4.1.4) |
| | | |
| 0x000F | T_SIGTIME | Validation-Dependent Data |
| | | (Section 3.6.4.1.4) |
| | | |
| 0x0FFF | T_ORG | Organization-Specific TLVs |
| | | (Section 3.3.2) |
| | | |
| 0x1000-0x1FFF | Reserved | Experimental Use (Section 3) |
+---------------+----------------+----------------------------------+
+---------------+----------------+----------------------------------+
| Type | Name | Reference |
+---------------+----------------+----------------------------------+
| 0x0000 | Reserved | |
| | | |
| 0x0009 | T_KEYID | Validation-Dependent Data |
| | | (Section 3.6.4.1.4) |
| | | |
| 0x000A | T_PUBLICKEYLOC | Validation-Dependent Data |
| | | (Section 3.6.4.1.4) |
| | | |
| 0x000B | T_PUBLICKEY | Validation-Dependent Data |
| | | (Section 3.6.4.1.4) |
| | | |
| 0x000C | T_CERT | Validation-Dependent Data |
| | | (Section 3.6.4.1.4) |
| | | |
| 0x000D | T_LINK | Validation-Dependent Data |
| | | (Section 3.6.4.1.4) |
| | | |
| 0x000E | T_KEYLINK | Validation-Dependent Data |
| | | (Section 3.6.4.1.4) |
| | | |
| 0x000F | T_SIGTIME | Validation-Dependent Data |
| | | (Section 3.6.4.1.4) |
| | | |
| 0x0FFF | T_ORG | Organization-Specific TLVs |
| | | (Section 3.3.2) |
| | | |
| 0x1000-0x1FFF | Reserved | Experimental Use (Section 3) |
+---------------+----------------+----------------------------------+
CCNx Validation-Dependent Data Types
CCNx验证相关数据类型
IANA has created the "CCNx Hash Function Types" registry and allocated the hash function types described below. The registration procedure is Specification Required. The Type value is 2 octets. The range is 0x0000-0xFFFF.
IANA已经创建了“CCNx哈希函数类型”注册表，并分配了下面描述的哈希函数类型。注册程序是必需的。类型值为2个八位字节。范围为0x0000-0xFFFF。
+---------------+-----------+---------------------------------------+
| Type | Name | Reference |
+---------------+-----------+---------------------------------------+
| 0x0000 | Reserved | |
| | | |
| 0x0001 | T_SHA-256 | Hash Format (Section 3.3.3) |
| | | |
| 0x0002 | T_SHA-512 | Hash Format (Section 3.3.3) |
| | | |
| 0x0FFF | T_ORG | Organization-Specific TLVs (Section |
| | | 3.3.2) |
| | | |
| 0x1000-0x1FFF | Reserved | Experimental Use (Section 3) |
+---------------+-----------+---------------------------------------+
+---------------+-----------+---------------------------------------+
| Type | Name | Reference |
+---------------+-----------+---------------------------------------+
| 0x0000 | Reserved | |
| | | |
| 0x0001 | T_SHA-256 | Hash Format (Section 3.3.3) |
| | | |
| 0x0002 | T_SHA-512 | Hash Format (Section 3.3.3) |
| | | |
| 0x0FFF | T_ORG | Organization-Specific TLVs (Section |
| | | 3.3.2) |
| | | |
| 0x1000-0x1FFF | Reserved | Experimental Use (Section 3) |
+---------------+-----------+---------------------------------------+
CCNx Hash Function Types
CCNx哈希函数类型
The CCNx protocol is a Layer 3 network protocol, which may also operate as an overlay using other transports such as UDP or other tunnels. It includes intrinsic support for message authentication via a signature (e.g., RSA or elliptic curve) or Message Authentication Code (e.g., HMAC). In lieu of an authenticator, it may instead use a Message Integrity Check (e.g., SHA or CRC). CCNx does not specify an encryption envelope; that function is left to a high-layer protocol (e.g., Encrypted Sessions in CCNx [esic]).
CCNx协议是一个第3层网络协议，它也可以使用其他传输（如UDP或其他隧道）作为覆盖层运行。它包括通过签名（例如RSA或椭圆曲线）或消息身份验证码（例如HMAC）对消息身份验证的内在支持。代替身份验证器，它可以使用消息完整性检查（例如，SHA或CRC）。CCNx未指定加密信封；该功能留给高层协议（例如，CCNx[esic]中的加密会话）。
The CCNx Packet format includes the ability to attach MICs (e.g., SHA-256 or CRC), MACs (e.g., HMAC), and Signatures (e.g., RSA or ECDSA) to all packet types. Because Interest packets can be sent at will, an application should carefully select when to use a given ValidationAlgorithm in an Interest to avoid DoS attacks. MICs, for example, are inexpensive and could be used as desired, whereas MACs and Signatures are more expensive and their inappropriate use could open a computational DoS attack surface. Applications should use an explicit protocol to guide their use of packet signatures. As a general guideline, an application might use a MIC on an Interest to detect unintentionally corrupted packets. If one wishes to secure an Interest, one should consider using an encrypted wrapper and a protocol that prevents replay attacks, especially if the Interest is being used as an actuator. Simply using an authentication code or signature does not make an Interest secure. There are several examples in the literature on how to secure ICN-style messaging [mobile] [ace].
CCNx数据包格式包括将MIC（如SHA-256或CRC）、MAC（如HMAC）和签名（如RSA或ECDSA）连接到所有数据包类型的能力。因为兴趣包可以随意发送，所以应用程序应该仔细选择何时在兴趣中使用给定的ValidationAlgorithm以避免DoS攻击。例如，MIC价格低廉，可以根据需要使用，而MAC和签名更为昂贵，它们的不当使用可能会导致计算性DoS攻击。应用程序应该使用一个明确的协议来指导数据包签名的使用。一般来说，应用程序可能会在感兴趣的设备上使用麦克风来检测无意中损坏的数据包。如果希望获得兴趣，则应该考虑使用加密包装和防止重放攻击的协议，特别是如果兴趣被用作执行器的话。仅仅使用身份验证码或签名并不能保证利益的安全。文献中有几个例子说明了如何保护ICN风格的消息传递[mobile][ace]。
As a Layer 3 protocol, this document does not describe how one arrives at keys or how one trusts keys. The CCNx content object may include a public key embedded in the object or may use the PublicKeyLocator field to point to a public key (or public-key certificate) that authenticates the message. One key exchange specification is CCNxKE [ccnxke] [mobile], which is similar to the TLS 1.3 key exchange except it is over the CCNx Layer 3 messages. Trust is beyond the scope of a Layer 3 protocol and is left to applications or application frameworks.
作为第3层协议，本文档不描述如何获得密钥或如何信任密钥。CCNx内容对象可以包括嵌入在对象中的公钥，或者可以使用PublicKeyLocator字段来指向认证消息的公钥（或公钥证书）。一个密钥交换规范是CCNxKE[CCNxKE][mobile]，它类似于tls1.3密钥交换，只是它在CCNx第3层消息上。信任超出了第3层协议的范围，由应用程序或应用程序框架决定。
The combination of an ephemeral key exchange (e.g., CCNxKE [ccnxke]) and an encapsulating encryption (e.g., [esic]) provides the equivalent of a TLS tunnel. Intermediate nodes may forward the Interests and Content Objects but have no visibility inside. It also completely hides the internal names in those used by the encryption layer. This type of tunneling encryption is useful for content that has little or no cacheability, as it can only be used by someone with the ephemeral key. Short-term caching may help with lossy links or mobility, but long-term caching is usually not of interest.
临时密钥交换（例如CCNxKE[CCNxKE]）和封装加密（例如[esic]）的组合提供了TLS隧道的等效性。中间节点可以转发兴趣和内容对象，但内部不可见。它还完全隐藏了加密层使用的内部名称。这种类型的隧道加密对于可缓存性很低或不可缓存的内容很有用，因为它只能由具有临时密钥的人使用。短期缓存可能有助于有损链接或移动性，但长期缓存通常不受关注。
Broadcast encryption or proxy re-encryption may be useful for content with multiple uses over time or many consumers. There is currently no recommendation for this form of encryption.
广播加密或代理重新加密可能对具有随时间变化的多种用途或许多消费者的内容有用。目前没有关于这种加密形式的建议。
The specific encoding of messages will have security implications. This document uses a Type-Length-Value (TLV) encoding. We chose to compromise between extensibility and unambiguous encodings of types and lengths. Some TLV encodings use variable-length T and variable-length L fields to accommodate a wide gamut of values while trying to be byte efficient. Our TLV encoding uses a fixed length 2-byte T and 2-byte L. Using fixed-length T and L fields solves two problems. The first is aliases. If one is able to encode the same value, such as 0x02 and 0x0002, in different byte lengths, then one must decide if they mean the same thing, if they are different, or if one is illegal. If they are different, then one must always compare on the buffers not the integer equivalents. If one is illegal, then one must validate the TLV encoding -- every field of every packet at every hop. If they are the same, then one has the second problem: how to specify packet filters. For example, if a name has 6 name components, then there are 7 T fields and 7 L fields, each of which might have up to 4 representations of the same value. That would be 14 fields with 4 encodings each, or 1001 combinations. It also means that one cannot compare, for example, a name via a memory function, as one needs to consider that any embedded T or L might have a different format.
消息的特定编码将具有安全含义。此文档使用类型长度值（TLV）编码。我们选择在可扩展性和类型和长度的明确编码之间进行折衷。一些TLV编码使用可变长度T和可变长度L字段，以适应广泛的值范围，同时尽量提高字节效率。我们的TLV编码使用固定长度的2字节T和2字节L。使用固定长度的T和L字段解决了两个问题。第一个是别名。如果能够以不同的字节长度对相同的值（如0x02和0x0002）进行编码，则必须确定它们是否表示相同的内容、是否不同或是否非法。如果它们不同，则必须始终在缓冲区上进行比较，而不是在等效整数上进行比较。如果一个是非法的，那么必须验证TLV编码——每个跃点上每个数据包的每个字段。如果它们相同，那么就有第二个问题：如何指定数据包过滤器。例如，如果名称有6个名称组件，则有7个T字段和7个L字段，每个字段最多可以有4个相同值的表示形式。这将是14个字段，每个字段有4个编码，或1001个组合。这也意味着，不能通过内存函数来比较名称，因为需要考虑任何嵌入的T或L可能具有不同的格式。
The Interest Return message has no authenticator from the previous hop. Therefore, the payload of the Interest Return should only be used locally to match an Interest. A node should never forward that Interest payload as an Interest. It should also verify that it sent the Interest in the Interest Return to that node and not allow anyone to negate Interest messages.
兴趣返回消息没有来自上一跳的验证器。因此，利息回报的有效负载应该只在本地用于匹配利息。节点不应将该兴趣负载作为兴趣转发。它还应该验证是否已将兴趣返回中的兴趣发送到该节点，并且不允许任何人否定兴趣消息。
Caching nodes must take caution when processing content objects. It is essential that the Content Store obey the rules outlined in [RFC8569] to avoid certain types of attacks. CCNx 1.0 has no mechanism to work around an undesired result from the network (there are no "excludes"), so if a cache becomes poisoned with bad content it might cause problems retrieving content. There are three types of access to content from a Content Store: unrestricted, signature restricted, and hash restricted. If an Interest has no restrictions, then the requester is not particular about what they get back, so any matching cached object is OK. In the hash restricted case, the requester is very specific about what they want, and the Content Store (and every forward hop) can easily verify that the content matches the request. In the signature restricted case (which is often used for initial manifest discovery), the requester only knows the KeyId that signed the content. This case requires the closest attention in the Content Store to avoid amplifying bad data. The Content Store must only respond with a content object if it can verify the signature -- this means either the content object carries the public key inside it or the Interest carries the public key in addition to the KeyId. If that is not the case, then the Content Store should treat the Interest as a cache miss and let an endpoint respond.
在处理内容对象时，缓存节点必须小心。内容存储必须遵守[RFC8569]中概述的规则，以避免某些类型的攻击。CCNx 1.0没有机制来处理来自网络的不希望的结果（没有“排除”），因此，如果缓存被不良内容毒害，则可能会导致检索内容时出现问题。从内容存储中访问内容有三种类型：无限制、签名限制和哈希限制。如果一个兴趣没有限制，那么请求者对他们返回的内容并不挑剔，所以任何匹配的缓存对象都是可以的。在哈希限制的情况下，请求者非常明确他们想要什么，内容存储（和每个前向跃点）可以轻松地验证内容是否与请求匹配。在签名受限的情况下（通常用于初始清单发现），请求者只知道对内容签名的KeyId。这种情况需要内容存储中最密切的关注，以避免放大不良数据。如果内容存储能够验证签名，则它必须仅使用内容对象进行响应——这意味着内容对象在其内部携带公钥，或者兴趣除了KeyId之外还携带公钥。如果情况并非如此，则内容存储应将兴趣视为缓存未命中，并让端点响应。
A user-level cache could perform full signature verification by fetching a public key according to the PublicKeyLocator. However, that is not a burden we wish to impose on the forwarder. A user-level cache could also rely on out-of-band attestation, such as the cache operator only inserting content that it knows has the correct signature.
用户级缓存可以通过根据PublicKeyLocator获取公钥来执行完整签名验证。然而，这不是我们希望强加给货代的负担。用户级缓存也可以依赖带外认证，例如缓存操作员仅插入其知道具有正确签名的内容。
The CCNx grammar allows for hash algorithm agility via the HashType. It specifies a short list of acceptable hash algorithms that should be implemented at each forwarder. Some hash values only apply to end systems, so updating the hash algorithm does not affect forwarders -- they would simply match the buffer that includes the type-length-hash buffer. Some fields, such as the ConObjHash, must be verified at each hop, so a forwarder (or related system) must know the hash algorithm, and it could cause backward compatibility problems if the hash type is updated.
CCNx语法允许通过HashType实现哈希算法的灵活性。它指定了应在每个转发器上实现的可接受哈希算法的简短列表。一些散列值只适用于终端系统，因此更新散列算法不会影响转发器——它们只会匹配包含类型长度散列缓冲区的缓冲区。某些字段（如ConObjHash）必须在每个跃点进行验证，因此转发器（或相关系统）必须知道哈希算法，如果哈希类型更新，可能会导致向后兼容性问题。
A CCNx name uses binary matching, whereas a URI uses a case-insensitive hostname. Some systems may also use case-insensitive matching of the URI path to a resource. An implication of this is that human-entered CCNx names will likely have case or non-ASCII symbol mismatches unless one uses a consistent URI normalization for the CCNx name. It also means that an entity that registers a CCNx-routable prefix -- say, "ccnx:/example.com" -- would need separate registrations for simple variations like "ccnx:/Example.com". Unless this is addressed in URI normalization and routing protocol conventions, there could be phishing attacks.
CCNx名称使用二进制匹配，而URI使用不区分大小写的主机名。一些系统还可能使用URI路径到资源的不区分大小写的匹配。这意味着，除非对CCNx名称使用一致的URI规范化，否则人工输入的CCNx名称可能存在大小写或非ASCII符号不匹配。这还意味着注册CCNx可路由前缀的实体（例如，“CCNx:/example.com”）需要单独注册“CCNx:/example.com”等简单变体。除非URI规范化和路由协议约定解决了这一问题，否则可能存在网络钓鱼攻击。
For a more general introduction to ICN-related security concerns and approaches, see [RFC7927] and [RFC7945].
有关ICN相关安全问题和方法的更一般性介绍，请参阅[RFC7927]和[RFC7945]。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[ace] Shang, W., Yu, Y., Liang, T., Zhang, B., and L. Zhang, "NDN-ACE: Access control for constrained environments over named data networking", NDN Technical Report NDN-0036, 2015, <http://new.named-data.net/wp-content/uploads/2015/ 12/ndn-0036-1-ndn-ace.pdf>.
[ace]Shang，W.，Yu，Y.，Liang，T.，Zhang，B.，和L.Zhang，“NDN-ace：命名数据网络上受限环境的访问控制”，NDN技术报告NDN-00362015<http://new.named-data.net/wp-content/uploads/2015/ 12/ndn-0036-1-ndn-ace.pdf>。
[ccnxke] Mosko, M., Uzun, E., and C. Wood, "CCNx Key Exchange Protocol Version 1.0", Work in Progress, draft-wood-icnrg-ccnxkeyexchange-02, March 2017.
[ccnxke]Mosko，M.，Uzun，E.，和C.Wood，“CCNx密钥交换协议1.0版”，正在进行的工作，草稿-Wood-icnrg-ccnxkeyexchange-02，2017年3月。
[CCNxURI] Mosko, M. and C. Wood, "The CCNx URI Scheme", Work in Progress, draft-mosko-icnrg-ccnxurischeme-01, April 2016.
[CCNxURI]Mosko，M.和C.Wood，“CCNx URI方案”，正在进行的工作，草稿-Mosko-icnrg-CCNxURI-01，2016年4月。
[CCNxz] Mosko, M., "CCNxz TLV Header Compression Experimental Code", commit f1093a2, March 2018, <https://github.com/PARC/CCNxz>.
[CCNxz]Mosko，M.，“CCNxz TLV报头压缩实验代码”，提交f1093a2，2018年3月<https://github.com/PARC/CCNxz>.
[compress] Mosko, M., "Header Compression for TLV-based Packets", ICNRG Interim Meeting, 2016, <https://datatracker.ietf.org/meeting/interim-2016-icnrg-02/materials/slides-interim-2016-icnrg-2-7>.
[compress]Mosko，M.，“基于TLV的数据包的报头压缩”，ICNRG临时会议，2016年<https://datatracker.ietf.org/meeting/interim-2016-icnrg-02/materials/slides-interim-2016-icnrg-2-7>.
[ECC] Certicom Research, "SEC 2: Recommended Elliptic Curve Domain Parameters", 2010, <http://www.secg.org/sec2-v2.pdf>.
[ECC]Certicom Research，“第2节：建议的椭圆曲线域参数”，2010年<http://www.secg.org/sec2-v2.pdf>.
[esic] Mosko, M. and C. Wood, "Encrypted Sessions In CCNx (ESIC)", Work in Progress, draft-wood-icnrg-esic-01, September 2017.
[esic]Mosko，M.和C.Wood，“CCNx（esic）中的加密会话”，正在进行的工作，草稿-Wood-icnrg-esic-01，2017年9月。
[IANA-PEN] IANA, "Private Enterprise Numbers", <http://www.iana.org/assignments/enterprise-numbers>.
[IANA-PEN]IANA，“私营企业编号”<http://www.iana.org/assignments/enterprise-numbers>.
[mobile] Mosko, M., Uzun, E., and C. Wood, "Mobile Sessions in Content-Centric Networks", IFIP Networking, 2017, <http://dl.ifip.org/db/conf/networking/ networking2017/1570334964.pdf>.
[移动]Mosko，M.，Uzun，E.，和C.Wood，“以内容为中心的网络中的移动会话”，IFIP Networking，2017<http://dl.ifip.org/db/conf/networking/ 网络2017/1570334964.pdf>。
[nnc] Jacobson, V., Smetters, D., Thornton, J., Plass, M., Briggs, N., and R. Braynard, "Networking Named Content", Proceedings of the 5th international conference on Emerging networking experiments and technologies (CoNEXT '09), 2009, <http://dx.doi.org/10.1145/1658939.1658941>.
[nnc]Jacobson，V.，Smetters，D.，Thornton，J.，Plass，M.，Briggs，N.，和R.Braynard，“网络命名内容”，第五届新兴网络实验和技术国际会议记录（CoNEXT'09），2009年<http://dx.doi.org/10.1145/1658939.1658941>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 5280，DOI 10.17487/RFC5280，2008年5月<https://www.rfc-editor.org/info/rfc5280>.
[RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, "Information-Centric Networking (ICN) Research Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, <https://www.rfc-editor.org/info/rfc7927>.
[RFC7927]Kutscher，D.，Ed.，Eum，S.，Pentikousis，K.，Psaras，I.，Corujo，D.，Saucez，D.，Schmidt，T.，和M.Waehlisch，“信息中心网络（ICN）研究挑战”，RFC 7927，DOI 10.17487/RFC7927，2016年7月<https://www.rfc-editor.org/info/rfc7927>.
[RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., and G. Boggia, "Information-Centric Networking: Evaluation and Security Considerations", RFC 7945, DOI 10.17487/RFC7945, September 2016, <https://www.rfc-editor.org/info/rfc7945>.
[RFC7945]Pentikousis，K.，Ed.，Ohlman，B.，Davies，E.，Spirou，S.，和G.Boggia，“以信息为中心的网络：评估和安全考虑”，RFC 7945，DOI 10.17487/RFC79452016年9月<https://www.rfc-editor.org/info/rfc7945>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
[RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric Networking (CCNx) Semantics", RFC 8569, DOI 10.17487/RFC8569, July 2019, <https://www.rfc-editor.org/info/rfc8569>.
[RFC8569]Mosko，M.，Solis，I.，和C.Wood，“以内容为中心的网络（CCNx）语义”，RFC 8569，DOI 10.17487/RFC8569，2019年7月<https://www.rfc-editor.org/info/rfc8569>.
Authors' Addresses
作者地址
Marc Mosko PARC, Inc. Palo Alto, California 94304 United States of America
Marc Mosko PARC，Inc.美国加利福尼亚州帕洛阿尔托94304
Phone: +01 650-812-4405
Email: mmosko@parc.com
Phone: +01 650-812-4405
Email: mmosko@parc.com
Ignacio Solis LinkedIn Mountain View, California 94043 United States of America
美国加利福尼亚州伊格纳西奥·索利斯LinkedIn山景酒店94043
Email: nsolis@linkedin.com
Email: nsolis@linkedin.com
Christopher A. Wood University of California, Irvine Irvine, California 92697 United States of America
克里斯托弗A.伍德加利福尼亚大学，欧文欧文，加利福尼亚92697美利坚合众国
Phone: +01 315-806-5939
Email: woodc1@uci.edu
Phone: +01 315-806-5939
Email: woodc1@uci.edu