[要約] RFC 8609は、Content-Centric Networking (CCNx) メッセージをTLV形式で表現するための仕様です。このRFCの目的は、CCNxメッセージの標準化と相互運用性の向上を促進することです。
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形式のContent-Centric Networking（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.
Content-Centric Networking（CCNx）は、階層名を使用して要求を転送し、応答を要求に一致させるネットワークプロトコルです。このドキュメントでは、各メッセージ要素で使用されるTLVタイプと各値のエンコーディングを含む、TLNパケット形式でのCCNxメッセージのエンコーディングを指定します。 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.
このドキュメントは、Information Centric Networking Research Group（ICNRG）の製品です。この文書はICNRG参加者の間で幅広いレビューを受け、現在積極的に使用されている2つの完全な実装があり、プロトコル仕様の技術的な成熟度を通知しています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
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.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。この文書は、Internet Research Task Force（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.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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
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].
このドキュメントでは、Type-Length-Value（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 Interest Containment内に存在するInterest 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]、CCNx URI表記をカバーしています。
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アートを使用して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.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、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 インタレスト：名前が一致するコンテンツオブジェクトと、同じ名前の複数のオブジェクトから選択する他のオプションのセレクターを要求するメッセージ。 Nameに一致するNameと属性を持ち、Interestのオプションセレクターを持つコンテンツオブジェクトは、Interestを満たすと言われます。
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 コンテンツオブジェクト：Interestリクエストへの応答として送信されるデータオブジェクト。オプションの名前とコンテンツペイロードがあり、これらは暗号化手段を介してバインドされています。
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ビットのTypeフィールドと16ビットの長さフィールドを使用して、TLVベースのパケットをエンコードします。これにより、65,536の異なる型と最大64 KiBの値フィールド長が提供されます。 TLVエンコーディングの各レベルで65,536の可能なタイプがあるので、基本的なプロトコルタイプ用に十分なスペースが必要ですが、実験、アプリケーションの使用、ベンダーの拡張、および成長のための十分な余地があります。このエンコーディングでは、全長が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. |
+--------+------------------+---------------------------------------+
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_ORGもベンダー拡張用に予約されています（セクション3.3.2を参照）。 TLVタイプのT_PADは、必要に応じてフィールドをパディングして、いくつかの望ましい配置にします。
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構造はネスト可能であり、1つのTLV構造のValueフィールドに追加の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 /
+---------------+---------------+---------------+---------------+
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) /
+---------------+---------------+---------------+---------------+
Figure 3: PacketPayload TLVs
図3：PacketPayload 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 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.
固定ヘッダーとホップバイホップヘッダーを破棄すると、残りのPacketPayloadは有効なプロトコルメッセージになります。したがって、PacketPayloadは常に、プロトコルメッセージ（インタレスト、コンテンツオブジェクト、またはその他のメッセージタイプ）とその全長を指定する4バイトのタイプ長で始まります。固定およびホップバイホップヘッダー内に自己完結型のプロトコルデータユニットを埋め込むことにより、ネットワークスタックはヘッダーを破棄し、埋め込まれたメッセージでのみ動作することができます。また、PacketPayloadからPacketTypeフィールド（パケットの転送方法を指定）を分離します。
The range of bytes protected by the Validation includes the CCNx Message TLV and the ValidationAlgorithm TLV.
検証によって保護されるバイトの範囲には、CCNxメッセージTLVとValidationAlgorithm 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_INTEREST、応答（コンテンツオブジェクト）にはPacketType PT_CONTENT、インタレストリターンにはPacketType PT_RETURNがあります。
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パイプラインに従ってパケットを転送する必要があることを示しています。このタイプのパケットの場合、固定ヘッダーには、HopLimitのフィールドと、ReservedおよびFlagsフィールドが含まれます。予約済みフィールドはインタレストで0に設定する必要があります。現在定義されているフラグはないため、Flagsフィールドは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 |
+---------------+---------------+---------------+---------------+
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.
Interestメッセージの場合、HopLimitは、ホップごとに減少するカウンターです。インタレストがネットワーク上を移動する距離を制限します。 Interestを発信するノードは、最大255までの任意の値を入力できます。HopLimitでInterestを受信する各ノードは、受信時に値を減らします。デクリメント後の値が0の場合、インタレストをノードから転送してはなりません（MUST NOT）。
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のコンテンツオブジェクトパイプラインに従ってパケットを転送する必要があることを示しています。コンテンツオブジェクトはフラグフィールドを定義します。ただし、現在定義されているフラグはないため、Flagsフィールドは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 |
+---------------+---------------+---------------+---------------+
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のインタレストリターンルールに従ってパケットを処理する必要があることを示しています。このInterest Returnメッセージと元のInterestの唯一の違いは、PacketTypeがPT_RETURNに変更され、ReturnCodeがReturnCodeフィールドに入力されることです。他のすべてのフィールドはInterestパケットから変更されていません。このエンコーディングの目的は、パケット長の変更を防ぐことです。そのため、前のホップにインタレストを返すために追加のバイトは必要ありません。
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」は、戻りシステムが「戻りコード」フィールドを変更しなかったことを示すため、使用してはなりません（MUST NOT）。
+-------------------------------------+-----------------------------+
| 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.
パッドタイプは、ワードアラインされたデータを好むソースによって使用される場合があります。たとえば、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の後にパッドを挿入してもよい（MAY）。このドキュメントの残りの部分では、オプションのパッド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 /
+---------------+---------------+---------------+---------------+
Figure 7: Pad Encoding
図7：パッドのエンコーディング
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_ORGタイプを使用する必要があります。長さフィールドは、組織固有の情報に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.
T_ORGは、名前のパスセグメントとして使用できます。他のパスセグメントと同様に扱われます。
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.
ハッシュ値のLENGTHフィールドは、ハッシュ関数の長さ以下でなければなりません。 LENGTHが全長より短い場合は、ハッシュ関数出力の左側のLENGTHバイトと見なされます。指定された切り捨てのみが許可され、任意の切り捨ては許可されません。
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は、InterestのKeyIdRestrictionフィールドとContentObjectのKeyIdフィールドの間でビット単位で比較されます。この形式は、異なるハッシュ関数を使用しても外部フィールドの値は変化しないため、ルーターはそれらのフィールドを識別し、使用される特定のハッシュを理解する必要なくハッシュ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をサポートする必要があります。エンティティは残りのハッシュタイプをサポートしてもよい（MAY）。
+-----------+------------------------+
| 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 /
+---------------+---------------+---------------+---------------+
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]、[ContentObjectHashRestr]}。これは、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 /
+---------------+---------------+---------------+---------------+
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ヘッダーは順序付けされておらず、順序付けに意味を付加してはなりません。このドキュメントでは、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) /
/ /
+---------------+---------------+---------------+---------------+
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）は、コンテンツプロデューサーまたは上流ノードによって割り当てられたコンテンツオブジェクトの有効寿命の尺度です。これは、コンテンツオブジェクトを保持する期間を決定する際のコンテンツストアキャッシュのガイドラインとして機能します。これは推奨のみであり、キャッシュによって無視される場合があります。これは、RCTよりも優先され、従わなければならないExpiryTime（セクション3.6.2.2.2で説明）とは対照的です。
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.
Recommended Cache Timeはオプションのホップバイホップヘッダーであり、署名付きメッセージの一部ではないため、コンテンツプロデューサーは、メッセージに再署名する必要なしに、更新済み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 /
/ /
+---------------+---------------+---------------+---------------+
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.
メッセージハッシュは1つのハッシュタイプのみを伝送でき、メッセージハッシュヘッダーは1つしか存在できません。
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 /
+---------------+---------------+---------------+---------------+
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) | |
+----------------------+------------+-------------------------------+
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は、ホップバイホップヘッダーと検証TLVの間のCCNxパケットの一部です。以下の図は、セクション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) /
+---------------+---------------+---------------+---------------+
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) | |
+-----------+---------------+---------------------------------------+
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でエンコードされたセグメントのシーケンスです。以下の表は、これらの名前セグメントに適切なタイプ値を示しています。名前にパッド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_NAMEは "ccnx：/"（デフォルトルート）に対応します。メッセージ文法では、CCNxメッセージTLV名の最初の名前セグメントの長さがゼロであることは許可されていません。 TLVエンコーディングでは、「ccnx：/」は長さがゼロのT_NAMEに対応します。
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. |
+---------------+-------------+-------------------------------------+
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の特別なアプリケーションペイロード名セグメントが割り当てられます。これらには、アプリケーションのセマンティクスが適用されています。これらの名前セグメントを使用する前に、アプリケーションのIDを名前に含めることをお勧めします。
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 |
+---------------+---------------+---------------+---------------+
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を作成するために使用されるメソッドの1オクテット識別子が含まれ、その後に可変長オクテット文字列が続きます。実装は、Interestを受け取るためのメソッドを実装する必要はありません。 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.
通常の操作では、CCIx URIで不透明なオクテット文字列としてInterestPayloadIDを表示することをお勧めします。これは、これが実装解析の一般的な特徴であるためです。
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を作成したことの確認が必要なシステムでは、ValidationAlgorithmとValidationPayloadを介してInterestに暗号署名を使用するか、Interest Payload内の独自のメソッドを使用する必要があります。
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は2つあります。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 /
+---------------------------------------------------------------+
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. |
+----------------+------------------------------+-------------------+
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を持つコンテンツオブジェクトのみがインタレストを満たすことが保証されます。 KeyIdの形式については、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).
InterestはContentObjectHashRestrictionセレクターを含むかもしれません。これは、コンテンツオブジェクトのハッシュです。インタレストがこの制限を備えている場合は、ネットワークで検証する必要がある自己認証名の制限です（メッセージハッシュ（セクション3.4.3）を参照）。 LENGTHは、そのハッシュに許可されている値の1つである必要があります（セクション3.3.3を参照）。
The ContentObjectHashRestriction SHOULD be of type T_SHA-256 and of length 32 bytes.
ContentObjectHashRestrictionは、タイプT_SHA-256で長さが32バイトである必要があります（SHOULD）。
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 /
+---------------------------------------------------------------+
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. |
+-------------+-------------+---------------------------------------+
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_DATA：データ（暗号化されている可能性があります）
o T_PAYLOADTYPE_KEY: Key
o T_PAYLOADTYPE_KEY：キー
o T_PAYLOADTYPE_LINK: Link
o T_PAYLOADTYPE_LINK：リンク
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エンコードされた公開キーであることを示します。リンクタイプは、ペイロードが1つ以上のリンクであることを示します（セクション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 |
+---------------+
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を過ぎたコンテンツオブジェクトで応答してはなりません。コンテンツオブジェクトを転送するルーターは、ExpiryTimeを確認する必要はありません。 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：ExpiryTimeエンコーディング
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には、パケットのコンテンツが含まれています。長さがゼロの場合があります。パケットにペイロードがない場合、このフィールドは長さがゼロではなく、省略されるべきです（SHOULD）。
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.
InterestsとContent Objectsの両方に、CCNxメッセージの検証方法に関する情報を含めるオプションがあります。この情報は、ValidationAlgorithm TLVとValidationPayload TLVの2つの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のセットです。最も外側のコンテナのタイプはT_VALIDATION_ALGです。最初のネストされたTLVは、メッセージに対して実行される特定のタイプの検証を定義します。タイプは、次の図に示すように「ValidationType」で識別され、下の表で詳しく説明されています。そのコンテナ内にネストされているのは、ValidationTypeに依存するデータ（たとえば、キーID、キーロケーターなど）のTLVです。
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 /
+---------------+---------------+---------------+---------------+
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]). |
+-----------------+---------------+---------------------------------+
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.
MICは、検証を実行するために追加のデータを必要としません。例は、長さがゼロの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は、秘密鍵をすでに共有している2つの信頼できる当事者間の通信に役立ちます。 HMACアルゴリズムがその一例です。 MACはKeyIdフィールドを使用して、使用されている共有シークレットを識別します。 KeyIdの意味は、関係する2つのパーティに固有であり、キーを列挙するための単なる整数である場合があります。新しい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パラメーターを使用した楕円曲線署名などがあります。これらのバリデーターには、KeyIdと、発行者の公開鍵（KeyLocator）を見つけるためのメカニズム、およびオプションでPublicKeyまたはCertificateまたはKeyLinkが必要です。 。
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. |
+-------------+-----------------+-----------------------------------+
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.
署名のKeyIdは、発行者のキー識別子です。 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.
KeyIdは、セクション3.3.3のハッシュ形式を使用して表されます。アプリケーションプロトコルが非ハッシュ識別子を使用する場合、予約された値の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_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.
公開鍵は、X.509証明書のように、DERでエンコードされたサブジェクト公開鍵情報ブロックです。
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) /
+---------------+---------------+---------------+---------------+
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のKeyIdRestrは、必ずしもラップされたキーではなく、ContentObjectの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 /
+---------------------------------------------------------------+
Figure 27: KeyLink Encoding
図27：KeyLinkエンコーディング
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メッセージに関連付けられている時間とは無関係です。これは、署名のかなり前に作成された可能性があります。デフォルトの動作では、認証されたメッセージ（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 /
+---------------------------------------------------------------+
Figure 28: SignatureTime Encoding
図28：SignatureTimeエンコーディング
As an example of a MIC-type validation, the encoding for CRC32C validation would be:
MICタイプの検証の例として、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 |
+---------------+---------------+---------------+---------------+
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 /
/---------------+---------------+-------------------------------+
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) /
+---------------+---------------+---------------+---------------+
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 /
+---------------+---------------+---------------+---------------+
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必須です。 Type値は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) |
+------+-------------+----------------------------------+
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インタレストリターンコードタイプ」レジストリを作成し、以下で説明するインタレストリターンコードタイプを割り当てました。登録手続きは「要指定」です。 Type値は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) |
+------+---------------------------------------+--------------------+
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必須です。 Type値は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) |
+---------------+-------------+-------------------------------------+
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必須です。 Type値は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) |
+--------+----------------------+-------------------------------+
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名前セグメントタイプ」レジストリを作成し、以下に説明する名前セグメントタイプを割り当てました。登録手続きは「要指定」です。 Type値は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) |
+--------------+------------------+---------------------------------+
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必須です。 Type値は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) |
+---------------+----------------+----------------------------------+
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ペイロードタイプ」レジストリを作成し、以下に説明するペイロードタイプを割り当てました。登録手続きは「要指定」です。 Type値は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) |
+------+--------------------+-----------------------------------+
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検証アルゴリズムタイプ」レジストリを作成し、以下に説明する検証アルゴリズムタイプを割り当てました。登録手続きは「要指定」です。 Type値は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) |
+---------------+-----------------+---------------------------------+
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必須です。 Type値は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) |
+---------------+----------------+----------------------------------+
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ハッシュ関数タイプ」レジストリを作成し、以下に説明するハッシュ関数タイプを割り当てました。登録手続きは「要指定」です。 Type値は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) |
+---------------+-----------+---------------------------------------+
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など）をすべてのパケットタイプに添付する機能が含まれています。 Interestパケットは自由に送信できるため、アプリケーションはDoS攻撃を回避するために、特定のValidationAlgorithmをInterestでいつ使用するかを慎重に選択する必要があります。たとえば、MICは安価であり、必要に応じて使用できますが、MACとシグネチャはより高価であり、不適切な使用はDoS攻撃の計算面を開く可能性があります。アプリケーションは、明示的なプロトコルを使用して、パケット署名の使用をガイドする必要があります。一般的なガイドラインとして、アプリケーションはインタレストでMICを使用して、意図せず破損したパケットを検出する場合があります。インタレストを保護したい場合、特にインタレストがアクチュエータとして使用されている場合は、暗号化されたラッパーとリプレイ攻撃を防ぐプロトコルの使用を検討する必要があります。認証コードまたは署名を使用するだけでは、インタレストは安全ではありません。文献には、ICNスタイルのメッセージング[モバイル] [エース]を保護する方法に関するいくつかの例があります。
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フィールドを使用してメッセージを認証する公開鍵（または公開鍵証明書）をポイントする場合があります。鍵交換の仕様の1つはCCNxKE [ccnxke] [モバイル]です。これは、CCNxレイヤー3メッセージを介する点を除いて、TLS 1.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.
メッセージの特定のエンコーディングは、セキュリティに影響します。このドキュメントでは、Type-Length-Value（TLV）エンコーディングを使用しています。私たちは、拡張性と、型と長さの明確なエンコーディングとの間の妥協を選択しました。一部のTLVエンコーディングでは、可変長のTフィールドと可変長のLフィールドを使用して、幅広いバイト値に対応しながらバイト効率を高めます。 TLVエンコーディングでは、固定長の2バイトTおよび2バイトLを使用します。固定長のTおよびLフィールドを使用すると、2つの問題を解決できます。 1つ目はエイリアスです。同じ値（0x02と0x0002など）を異なるバイト長でエンコードできる場合、それらが同じことを意味するのか、異なるのか、または違法なのかを判断する必要があります。それらが異なる場合は、常に同等の整数ではなくバッファで比較する必要があります。不正なものがある場合は、TLVエンコーディング（すべてのホップのすべてのパケットのすべてのフィールド）を検証する必要があります。それらが同じである場合、2番目の問題、パケットフィルターの指定方法があります。たとえば、名前に6つの名前コンポーネントがある場合、7つのTフィールドと7つのLフィールドがあり、それぞれに同じ値の最大4つの表現がある場合があります。それは、それぞれ4つのエンコーディング、または1001の組み合わせを持つ14フィールドです。また、埋め込まれた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.
Interest Returnメッセージには、前のホップからのオーセンティケーターがありません。したがって、インタレストリターンのペイロードは、インタレストを照合するためにローカルでのみ使用する必要があります。ノードはそのInterestペイロードをInterestとして転送してはなりません。また、インタレストリターンのインタレストをそのノードに送信したことを確認し、誰もインタレストメッセージを否定できないようにする必要があります。
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には、ネットワークからの望ましくない結果（「除外」はありません）を回避するメカニズムがないため、キャッシュに不正なコンテンツが含まれていると、コンテンツの取得で問題が発生する可能性があります。 Content Storeからコンテンツへのアクセスには、制限なし、署名制限付き、ハッシュ制限付きの3つのタイプがあります。インタレストに制限がない場合、リクエスタは返されるものに特別ではないので、一致するキャッシュオブジェクトは問題ありません。ハッシュ制限の場合、リクエスタは要求する内容について非常に具体的であり、コンテンツストア（およびすべてのフォワードホップ）は、コンテンツが要求に一致することを簡単に確認できます。署名が制限されている場合（初期マニフェストの検出によく使用されます）、リクエスターはコンテンツに署名したKeyIdしか知りません。このケースでは、不良データの増幅を回避するために、Content Storeで最も注意が必要です。 Content Storeは、署名を検証できる場合にのみコンテンツオブジェクトで応答する必要があります。これは、コンテンツオブジェクトが内部に公開鍵を運ぶか、インタレストがKeyIdに加えて公開鍵を運ぶことを意味します。そうでない場合、Content Storeはインタレストをキャッシュミスとして扱い、エンドポイントに応答させる必要があります。
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を介してハッシュアルゴリズムの俊敏性を可能にします。各フォワーダーに実装する必要のある許容可能なハッシュアルゴリズムの短いリストを指定します。一部のハッシュ値はエンドシステムにのみ適用されるため、ハッシュアルゴリズムを更新してもフォワーダーには影響しません。それらは単純にtype-length-hashバッファーを含むバッファーと一致します。 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., "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>.
[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-0036 、2015、<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 Key Exchange Protocol Version 1.0」、Work in Progress、draft-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、「The CCNx URI Scheme」、Work in Progress、draft-mosko-icnrg-ccnxurischeme-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>.
[圧縮] 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、「SEC 2：Recommended Elliptic Curve Domain Parameters」、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）」、作業中、draft-wood-icnrg-esic-01、2017年9月。
[IANA-PEN] IANA, "Private Enterprise Numbers", <http://www.iana.org/assignments/enterprise-numbers>.
[IANA-PEN] IANA、「Private Enterprise Numbers」、<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>.
[mobile] Mosko、M.、Uzun、E。、およびC. Wood、「コンテンツ中心のネットワークにおけるモバイルセッション」、IFIPネットワーキング、2017、<http://dl.ifip.org/db/conf/networking/ networking2017 / 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.、and R. Braynard、 "Networking Named Content"、Proceedings of the 5th International Conference on Emerging Networking Experiments andテクノロジー（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 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、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、「情報中心型Networking（ICN）Research Challenges」、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 / RFC7945 、2016年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]コットン、M。、レイバ、B。、およびT.ナルテン、「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、「Content-Centric Networking（CCNx）Semantics」、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
Ignacio Solis LinkedIn Mountain View, California 94043 United States of America
イグナシオソリスLinkedInマウンテンビュー、カリフォルニア州94043アメリカ合衆国
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