[要約] RFC 8569は、Content-Centric Networking (CCNx)のセマンティクスに関する仕様であり、CCNxのデータモデル、プロトコル、およびセキュリティについて説明しています。このRFCの目的は、CCNxの実装と展開を支援し、ネットワークの効率性とセキュリティを向上させることです。
Internet Research Task Force (IRTF) M. Mosko
Request for Comments: 8569 PARC, Inc.
Category: Experimental I. Solis
ISSN: 2070-1721 LinkedIn
C. Wood
University of California Irvine
July 2019
Content-Centric Networking (CCNx) Semantics
コンテンツ中心のネットワーキング（CCNx）セマンティクス
Abstract
概要
This document describes the core concepts of the Content-Centric Networking (CCNx) architecture and presents a network protocol based on two messages: Interests and Content Objects. It specifies the set of mandatory and optional fields within those messages and describes their behavior and interpretation. This architecture and protocol specification is independent of a specific wire encoding.
このドキュメントでは、コンテンツセントリックネットワーキング（CCNx）アーキテクチャのコアコンセプトについて説明し、インタレストとコンテンツオブジェクトの2つのメッセージに基づくネットワークプロトコルを示します。これらのメッセージ内の必須フィールドとオプションフィールドのセットを指定し、それらの動作と解釈について説明します。このアーキテクチャとプロトコルの仕様は、特定のワイヤエンコーディングとは無関係です。
The protocol also uses a control message called an Interest Return, whereby one system can return an Interest message to the previous hop due to an error condition. This indicates to the previous hop that the current system will not respond to the Interest.
また、プロトコルはInterest Returnと呼ばれる制御メッセージを使用します。これにより、1つのシステムがエラー条件のために前のホップにInterestメッセージを返すことができます。これは、現在のシステムがインタレストに応答しないことを前のホップに示します。
This document is a product of the Information-Centric Networking Research Group (ICNRG). The document received wide review among ICNRG participants. Two full implementations are in active use and have informed the technical maturity of the protocol specification.
この文書は、情報中心型ネットワーキング研究グループ（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/rfc8569.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8569で入手できます。
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 . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
1.2. Architecture . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Protocol Overview . . . . . . . . . . . . . . . . . . . . 6
2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1. Message Grammar . . . . . . . . . . . . . . . . . . . . . 10
2.2. Consumer Behavior . . . . . . . . . . . . . . . . . . . . 14
2.3. Publisher Behavior . . . . . . . . . . . . . . . . . . . 15
2.4. Forwarder Behavior . . . . . . . . . . . . . . . . . . . 16
2.4.1. Interest HopLimit . . . . . . . . . . . . . . . . . . 16
2.4.2. Interest Aggregation . . . . . . . . . . . . . . . . 17
2.4.3. Content Store Behavior . . . . . . . . . . . . . . . 19
2.4.4. Interest Pipeline . . . . . . . . . . . . . . . . . . 19
2.4.5. Content Object Pipeline . . . . . . . . . . . . . . . 20
3. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1. Name Examples . . . . . . . . . . . . . . . . . . . . . . 23
3.2. Interest Payload ID . . . . . . . . . . . . . . . . . . . 23
4. Cache Control . . . . . . . . . . . . . . . . . . . . . . . . 23
5. Content Object Hash . . . . . . . . . . . . . . . . . . . . . 24
6. Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7. Hashes . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8. Validation . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.1. Validation Algorithm . . . . . . . . . . . . . . . . . . 25
8.2. Message Integrity Codes . . . . . . . . . . . . . . . . . 26
8.3. Message Authentication Codes . . . . . . . . . . . . . . 26
8.4. Signature . . . . . . . . . . . . . . . . . . . . . . . . 26
9. Interest to Content Object Matching . . . . . . . . . . . . . 28
10. Interest Return . . . . . . . . . . . . . . . . . . . . . . . 29
10.1. Message Format . . . . . . . . . . . . . . . . . . . . . 30
10.2. ReturnCode Types . . . . . . . . . . . . . . . . . . . . 31
10.3. Interest Return Protocol . . . . . . . . . . . . . . . . 32
10.3.1. No Route . . . . . . . . . . . . . . . . . . . . . . 32
10.3.2. HopLimit Exceeded . . . . . . . . . . . . . . . . . 33
10.3.3. Interest MTU Too Large . . . . . . . . . . . . . . . 33
10.3.4. No Resources . . . . . . . . . . . . . . . . . . . . 33
10.3.5. Path Error . . . . . . . . . . . . . . . . . . . . . 33
10.3.6. Prohibited . . . . . . . . . . . . . . . . . . . . . 33
10.3.7. Congestion . . . . . . . . . . . . . . . . . . . . . 34
10.3.8. Unsupported Content Object Hash Algorithm . . . . . 34
10.3.9. Malformed Interest . . . . . . . . . . . . . . . . . 34
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
12. Security Considerations . . . . . . . . . . . . . . . . . . . 34
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
13.1. Normative References . . . . . . . . . . . . . . . . . . 37
13.2. Informative References . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
This document describes the principles of the CCNx architecture. It describes a network protocol that uses a hierarchical name to forward requests and to match responses to requests. It does not use endpoint addresses, such as Internet Protocol. 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]. This document concerns the semantics of the protocol and is not dependent on a specific wire encoding. The CCNx Messages [RFC8609] document describes a type-length-value (TLV) wire-protocol encoding. This section introduces the main concepts of CCNx, which are further elaborated in the remainder of the document.
このドキュメントでは、CCNxアーキテクチャの原理について説明します。階層名を使用して要求を転送し、要求への応答を照合するネットワークプロトコルについて説明します。インターネットプロトコルなどのエンドポイントアドレスは使用しません。リクエストの制限により、レスポンスの署名者の公開鍵またはレスポンスの暗号化ハッシュによってレスポンスを制限できます。パス上のすべてのCCNxフォワーダーは、名前の一致と制限のチェックを行います。 CCNxプロトコルは、情報中心型ネットワーキング（ICN）プロトコル[RFC7927]のより広範なフレームワークに適合します。このドキュメントはプロトコルのセマンティクスに関するものであり、特定のワイヤエンコーディングに依存していません。 CCNxメッセージ[RFC8609]ドキュメントでは、type-length-value（TLV）ワイヤープロトコルエンコーディングについて説明しています。このセクションでは、CCNxの主要な概念を紹介します。CCNxについては、このドキュメントの残りの部分でさらに詳しく説明します。
The CCNx protocol derives from the early ICN work by Jacobson, et al. [nnc]. Jacobson's version of CCNx is known as the 0.x version ("CCNx 0.x"), and the present work is known as the 1.0 version ("CCNx 1.0"). There are two active implementations of CCNx 1.0. The most complete implementation is Community ICN (CICN) [cicn], a Linux Foundation project hosted at fd.io. Another active implementation is CCN-lite [ccn-lite], with support for Internet of Things (IoT) systems and the RIOT operating system. CCNx 0.x formed the basis of the Named Data Networking (NDN) [ndn] university project.
CCNxプロトコルは、Jacobsonらによる初期のICN作業に由来しています。 [nnc]。 JacobsonのCCNxのバージョンは0.xバージョン（ "CCNx 0.x"）として知られ、現在の作業は1.0バージョン（ "CCNx 1.0"）として知られています。 CCNx 1.0には2つのアクティブな実装があります。最も完全な実装は、fd.ioでホストされるLinux FoundationプロジェクトであるCommunity ICN（CICN）[cicn]です。別のアクティブな実装はCCN-lite [ccn-lite]で、モノのインターネット（IoT）システムとRIOTオペレーティングシステムをサポートしています。 CCNx 0.xは、Named Data Networking（NDN）[ndn]大学プロジェクトの基礎を形成しました。
The current CCNx 1.0 specification diverges from CCNx 0.x in a few significant areas. The most pronounced behavioral difference between CCNx 0.x and CCNx 1.0 is that CCNx 1.0 has a simpler response processing behavior. In both versions, a forwarder uses a hierarchical longest prefix match of a request name against the forwarding information base (FIB) to send the request through the network to a system that can issue a response. A forwarder must then match a response's name to a request's name to determine the reverse path and deliver the response to the requester. In CCNx 0.x, the Interest name may be a hierarchical prefix of the response name, which allows a form of Layer 3 (L3) content discovery. In CCNx 1.0, a response's name must exactly equal a request's name. Content discovery is performed by a higher-layer protocol.
現在のCCNx 1.0仕様は、いくつかの重要な領域でCCNx 0.xとは異なります。 CCNx 0.xとCCNx 1.0の最も顕著な動作の違いは、CCNx 1.0の方が応答処理動作が単純であることです。どちらのバージョンでも、フォワーダーは転送情報ベース（FIB）に対する要求名の階層最長プレフィックス一致を使用して、ネットワーク経由で応答を発行できるシステムに要求を送信します。フォワーダーは、応答の名前を要求の名前と照合して、リバースパスを決定し、応答を要求者に配信する必要があります。 CCNx 0.xでは、インタレスト名は応答名の階層的なプレフィックスである場合があり、これにより、レイヤー3（L3）コンテンツ検出の形式が可能になります。 CCNx 1.0では、応答の名前は要求の名前と正確に同じでなければなりません。コンテンツの検出は、上位層のプロトコルによって実行されます。
The selector protocol "CCNx Selectors" [selectors] is an example of using a higher-layer protocol on top of the CCNx 1.0 L3 to perform content discovery. The selector protocol uses a method similar to the original CCNx 0.x techniques without requiring partial name matching of a response to a request in the forwarder.
セレクター・プロトコル「CCNxセレクター」[selectors]は、CCNx 1.0 L3の上に上位層プロトコルを使用してコンテンツ検出を実行する例です。セレクタープロトコルは、元のCCNx 0.x手法と同様の方法を使用しますが、フォワーダーでの要求に対する応答の部分的な名前の一致は必要ありません。
This document represents the consensus of the Information-Centric Networking Research Group (ICNRG). 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. This document has received critical reading by several members of the ICN community and the RG. The authors and RG chairs approve of the contents. This document is sponsored under the IRTF, 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. The specification may change in the future.
このドキュメントは、情報中心のネットワーキング研究グループ（ICNRG）のコンセンサスを表しています。これは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]で説明されているように解釈されます。
We describe the architecture of the network in which CCNx operates and introduce certain terminology from [terminology]. The detailed behavior of each component and message grammar is in Section 2.
CCNxが動作するネットワークのアーキテクチャについて説明し、[用語]から特定の用語を紹介します。各コンポーネントとメッセージ文法の詳細な動作はセクション2にあります。
A producer (also called a "publisher") is an endpoint that encapsulates content in Content Objects for transport in the CCNx network. A producer has a public/private keypair and signs (directly or indirectly) the Content Objects. Usually, the producer's KeyId (hash of the public key) is well known or may be derived from the producer's namespace via standard means.
プロデューサー（「パブリッシャー」とも呼ばれる）は、CCNxネットワークで転送するためにコンテンツをコンテンツオブジェクトにカプセル化するエンドポイントです。プロデューサーは、公開/秘密キーペアを持ち、コンテンツオブジェクトに（直接的または間接的に）署名します。通常、プロデューサーのKeyId（公開鍵のハッシュ）はよく知られているか、標準的な方法でプロデューサーの名前空間から派生させることができます。
A producer operates within one or more namespaces. A namespace is a name prefix that is represented in the forwarding information base (FIB). This allows a request to reach the producer and fetch a response (if one exists).
プロデューサーは1つ以上の名前空間内で動作します。名前空間は、転送情報ベース（FIB）で表される名前の接頭辞です。これにより、リクエストがプロデューサーに到達し、レスポンスが存在する場合はそれをフェッチできます。
The FIB is a table that tells a forwarder where to send a request. It may point to a local application, a local cache or Content Store, or to a remote system. If there is no matching entry in the FIB, a forwarder cannot process a request. The detailed rules on name matching to the FIB are given in Section 2.4.4. An endpoint has a FIB, though it may be a simple default route. An intermediate system (i.e., a router) typically has a much larger FIB. A core CCNx forwarder, for example, would know all the global routes.
FIBは、フォワーダーにリクエストの送信先を通知するテーブルです。ローカルアプリケーション、ローカルキャッシュまたはContent Store、またはリモートシステムを指す場合があります。 FIBに一致するエントリがない場合、フォワーダーは要求を処理できません。 FIBに一致する名前の詳細なルールは、セクション2.4.4に記載されています。エンドポイントにはFIBがありますが、これは単純なデフォルトルートの場合があります。中間システム（つまり、ルーター）は通常、はるかに大きなFIBを持っています。たとえば、コアCCNxフォワーダーは、すべてのグローバルルートを知っています。
A consumer is an endpoint that requests a name. It is beyond the scope of this document to describe how a consumer learns of a name or publisher KeyId; higher-layer protocols built on top of CCNx handle those tasks, such as search engines or lookup services or well-known names. The consumer constructs a request, called an Interest, and forwards it via the endpoint's FIB. The consumer should get back either a response (called a Content Object) that matches the Interest or a control message (called an Interest Return) that indicates the network cannot handle the request.
コンシューマーは、名前を要求するエンドポイントです。消費者が名前または発行者のKeyIdをどのように学習するかを説明することは、このドキュメントの範囲を超えています。 CCNxの上に構築された上位層のプロトコルは、検索エンジンやルックアップサービス、既知の名前などのタスクを処理します。コンシューマはインタレストと呼ばれるリクエストを作成し、エンドポイントのFIBを介して転送します。コンシューマは、インタレストに一致する応答（コンテンツオブジェクトと呼ばれる）またはネットワークが要求を処理できないことを示す制御メッセージ（インタレストリターンと呼ばれる）のいずれかを返す必要があります。
There are three ways to detect errors in Interest handling. An Interest Return is a network control message that indicates a low-level error like "no route" or "out of resources". If an Interest arrives at a producer, but the producer does not have the requested content, the producer should send an application-specific error message (e.g., a "not found" message). Finally, a consumer may not receive anything; in which case, it should timeout and, depending on the application, retry the request or return an error to the application.
インタレスト処理でエラーを検出する方法は3つあります。 Interest Returnは、「ルートなし」や「リソース不足」などの低レベルのエラーを示すネットワーク制御メッセージです。インタレストがプロデューサに到着したが、プロデューサが要求されたコンテンツを持っていない場合、プロデューサはアプリケーション固有のエラーメッセージ（たとえば、「見つかりません」メッセージ）を送信する必要があります。最後に、消費者は何も受け取りません。その場合はタイムアウトし、アプリケーションに応じて、要求を再試行するか、アプリケーションにエラーを返します。
The goal of CCNx is to name content and retrieve the content from the network without binding it to a specific network endpoint. A routing system (specified separately) populates the FIB tables at each CCNx router with hierarchical name prefixes that point towards the content producers under that prefix. A request finds matching content along those paths, in which case a response carries the data, or, if no match is found, a control message indicates the failure. A request may further refine acceptable responses with a restriction on the response's signer and the cryptographic hash of the response. The details of these restrictions are described below.
CCNxの目的は、コンテンツに名前を付け、特定のネットワークエンドポイントにバインドせずにネットワークからコンテンツを取得することです。ルーティングシステム（個別に指定）は、各CCNxルーターのFIBテーブルに、そのプレフィックスの下のコンテンツプロデューサーを指す階層的な名前プレフィックスを設定します。リクエストは、それらのパスに沿って一致するコンテンツを見つけます。その場合、応答はデータを運ぶか、または一致が見つからない場合、制御メッセージは失敗を示します。要求は、応答の署名者および応答の暗号化ハッシュに対する制限を使用して、許容可能な応答をさらに洗練する場合があります。これらの制限の詳細を以下に説明します。
The CCNx name is a hierarchical series of name segments. Each name segment has a type and zero or more bytes. Matching two names is done as a binary comparison of the type and value, and is done segment by segment. The human-readable form is defined under a URI scheme "ccnx:" [ccnx-uri], though the canonical encoding of a name is a series of pairs (type, octet string). There is no requirement that any name segment be human readable or UTF-8. The first few segments in a name will be matched against the FIB, and a routing protocol may put its own restrictions on the routable name components (e.g., a maximum length or character-encoding rules). In principle, name segments and names have unbounded length, though in practice they are limited by the wire encoding and practical considerations imposed by a routing protocol. Note that in CCNx, name segments use binary comparison, whereas in a URI, the authority uses a case-insensitive hostname (due to DNS).
CCNx名は、階層的な一連の名前セグメントです。各名前セグメントには、タイプとゼロ以上のバイトがあります。 2つの名前の照合は、タイプと値のバイナリ比較として行われ、セグメントごとに行われます。人間が読める形式は、URIスキーム "ccnx：" [ccnx-uri]で定義されていますが、名前の標準的なエンコードは一連のペア（タイプ、オクテット文字列）です。名前セグメントが人間が読める形式またはUTF-8である必要はありません。名前の最初のいくつかのセグメントはFIBと照合されます。ルーティングプロトコルは、ルーティング可能な名前コンポーネントに独自の制限を課す場合があります（最大長や文字エンコードルールなど）。原則として、名前セグメントと名前の長さには制限がありませんが、実際には、ワイヤーエンコードとルーティングプロトコルによって課される実際的な考慮事項によって制限されます。 CCNxでは、名前セグメントはバイナリ比較を使用しますが、URIでは、機関は（DNSのため）大文字と小文字を区別しないホスト名を使用します。
The CCNx name, as used by the forwarder, is purposefully left as a general octet-encoded type and value without any requirements on human readability and character encoding. The reason for this is that we are concerned with how a forwarder processes names. We expect that applications, routing protocols, or other higher layers will apply their own conventions and restrictions on the allowed name segment types and name segment values.
フォワーダーが使用するCCNx名は、人間の可読性や文字エンコードに関する要件なしに、意図的に一般的なオクテットエンコードタイプおよび値として残されます。これは、フォワーダーが名前を処理する方法に関心があるためです。アプリケーション、ルーティングプロトコル、またはその他の上位層が、許可された名前セグメントタイプと名前セグメント値に独自の規則と制限を適用することを期待しています。
CCNx is a request and response protocol that fetches chunks of data using a name. The integrity of each chunk may be directly asserted through a digital signature or Message Authentication Code (MAC), or, alternatively, indirectly via hash chains. Chunks may also carry weaker Message Integrity Codes (MICs) or no integrity protection mechanism at all. Because provenance information is carried with each chunk (or larger indirectly protected block), we no longer need to rely on host identities, such as those derived from TLS certificates, to ascertain the chunk legitimacy. Therefore, data integrity is a core feature of CCNx; it does not rely on the data transmission channel. There are several options for data confidentiality, discussed later.
CCNxは、名前を使用してデータのチャンクをフェッチする要求および応答プロトコルです。各チャンクの整合性は、デジタル署名またはメッセージ認証コード（MAC）を介して直接、またはハッシュチェーンを介して間接的にアサートできます。チャンクは、より弱いメッセージ整合性コード（MIC）を運ぶことも、完全性保護メカニズムをまったく持たないこともあります。来歴情報は各チャンク（または、より大きな間接的に保護されたブロック）で伝達されるため、チャンクの正当性を確認するために、TLS証明書から派生したものなどのホストIDに依存する必要がなくなりました。したがって、データの整合性はCCNxのコア機能です。データ伝送チャネルに依存しません。後で説明するように、データの機密性にはいくつかのオプションがあります。
This document only defines the general properties of CCNx names. In some isolated environments, CCNx users may be able to use any name they choose and either inject that name (or prefix) into a routing protocol or use other information foraging techniques. In the Internet environment, there will be policies around the formats of names and assignments of names to publishers, though those are not specified here.
このドキュメントでは、CCNx名の一般的なプロパティのみを定義しています。一部の隔離された環境では、CCNxユーザーは選択した任意の名前を使用でき、その名前（またはプレフィックス）をルーティングプロトコルに挿入するか、他の情報探索技術を使用できます。ここでは明記していませんが、インターネット環境では、名前の形式と発行者への名前の割り当てに関するポリシーがあります。
The key concept of CCNx is that a subjective name is cryptographically bound to a fixed payload. These publisher-generated bindings can therefore be cryptographically verified. A named payload is thus the tuple {{Name, ExtraFields, Payload, ValidationAlgorithm}, ValidationPayload}, where all fields in the inner tuple are covered by the validation payload (e.g., signature). Consumers of this data can check the binding integrity by recomputing the same cryptographic hash and verifying the digital signature in ValidationPayload.
CCNxの重要な概念は、主観的な名前が暗号で固定ペイロードにバインドされることです。したがって、これらのパブリッシャーが生成したバインディングは、暗号で検証できます。したがって、名前付きペイロードはタプル{{Name、ExtraFields、Payload、ValidationAlgorithm}、ValidationPayload}であり、内部タプルのすべてのフィールドは検証ペイロード（例：シグネチャ）でカバーされています。このデータの利用者は、同じ暗号ハッシュを再計算し、ValidationPayloadでデジタル署名を検証することにより、バインディングの整合性を確認できます。
In addition to digital signatures (e.g., RSA), CCNx also supports message authentication codes (e.g., Hashed Message Authentication Code (HMAC)) and message integrity codes (e.g., Cyclic Redundancy Checks (CRC)). To maintain the cryptographic binding, there should be at least one object with a signature or authentication code, but not all objects require it. For example, a first object with a signature could refer to other objects via a hash chain, a Merkle tree, or a signed manifest. The later objects may not have any validation and rely purely on the references. The use of an integrity code (e.g., CRC) is intended for detecting accidental corruption in an Interest.
デジタル署名（RSAなど）に加えて、CCNxはメッセージ認証コード（Hashed Message Authentication Code（HMAC）など）およびメッセージ整合性コード（Cyclic Redundancy Checks（CRC）など）もサポートしています。暗号バインディングを維持するには、署名または認証コードを持つオブジェクトが少なくとも1つ必要ですが、すべてのオブジェクトがそれを必要とするわけではありません。たとえば、署名付きの最初のオブジェクトは、ハッシュチェーン、Merkleツリー、または署名付きマニフェストを介して他のオブジェクトを参照できます。後者のオブジェクトは検証されておらず、純粋に参照に依存している場合があります。整合性コード（CRCなど）の使用は、インタレストの偶発的な破損を検出することを目的としています。
CCNx specifies a network protocol around Interests (request messages) and Content Objects (response messages) to move named payloads. An Interest includes the Name field, which identifies the desired response, and optional matching restrictions. Restrictions limit the possible matching Content Objects. Two restrictions exist: the Key ID restriction (KeyIdRestr) and Content Object Hash restriction (ContentObjectHashRestr). The first restriction on the KeyId limits responses to those signed with a ValidationAlgorithm KeyId field equal to the restriction. The second is the Content Object Hash restriction, which limits the response to one where the cryptographic hash of the entire named payload is equal to the restriction. Section 9 fully explains how these restrictions limit matching of a Content Object to an Interest.
CCNxは、インタレスト（要求メッセージ）とコンテンツオブジェクト（応答メッセージ）に関連するネットワークプロトコルを指定して、名前付きペイロードを移動します。インタレストには、目的の応答を識別する名前フィールドと、オプションのマッチング制限が含まれます。制限により、一致する可能性のあるコンテンツオブジェクトが制限されます。キーID制限（KeyIdRestr）とコンテンツオブジェクトハッシュ制限（ContentObjectHashRestr）の2つの制限があります。 KeyIdに対する最初の制限は、制限と等しいValidationAlgorithm KeyIdフィールドで署名されたものへの応答を制限します。 2つ目は、コンテンツオブジェクトハッシュの制限です。これは、名前付きペイロード全体の暗号化ハッシュが制限に等しいものに応答を制限します。セクション9は、これらの制限がコンテンツオブジェクトとインタレストのマッチングをどのように制限するかを完全に説明しています。
The hierarchy of a CCNx name is used for routing via the longest matching prefix in a forwarder. The longest matching prefix is computed name segment by name segment in the hierarchical name, where each name segment must be exactly equal to match. There is no requirement that the prefix be globally routable. Within a deployment, any local routing may be used, even one that only uses a single flat (nonhierarchical) name segment.
CCNx名の階層は、フォワーダー内の一致する最長のプレフィックスを介したルーティングに使用されます。最長の一致するプレフィックスは、階層名の名前セグメントごとに計算された名前セグメントです。各名前セグメントは、一致するように正確に一致する必要があります。プレフィックスがグローバルにルーティング可能である必要はありません。デプロイメント内では、単一のフラットな（非階層的な）名前セグメントのみを使用するものであっても、ローカルルーティングを使用できます。
Another concept of CCNx is that there should be flow balance between Interest messages and Content Object messages. At the network level, an Interest traveling along a single path should elicit no more than one Content Object response. If some node sends the Interest along more than one path, that node should consolidate the responses such that only one Content Object flows back towards the requester. If an Interest is sent broadcast or multicast on a multiple-access media, the sender should be prepared for multiple responses unless some other media-dependent mechanism like gossip suppression or leader election is used.
CCNxのもう1つの概念は、インタレストメッセージとコンテンツオブジェクトメッセージの間にフローバランスが必要であることです。ネットワークレベルでは、1つのパスに沿って移動するインタレストは、コンテンツオブジェクトの応答を1つだけ引き出します。一部のノードが複数のパスに沿ってインタレストを送信する場合、そのノードは、1つのコンテンツオブジェクトのみがリクエスタに向かって戻るように、応答を統合する必要があります。インタレストがマルチアクセスメディアでブロードキャストまたはマルチキャストで送信される場合、ゴシップ抑制やリーダー選出など、他のメディア依存のメカニズムが使用されていない限り、送信者は複数の応答に備える必要があります。
As an Interest travels the forward path following the FIB, it establishes state at each forwarder such that a Content Object response can trace its way back to the original requester(s) without the requester needing to include a routable return address. We use the notional Pending Interest Table (PIT) as a method to store state that facilitates the return of a Content Object.
インタレストはFIBに沿って転送パスを移動するときに、各フォワーダーで状態を確立し、コンテンツオブジェクトの応答が、リクエスターがルーティング可能な戻りアドレスを含める必要なく、元のリクエスターに戻ることができるようにします。コンテンツオブジェクトの返却を容易にする状態を保存する方法として、概念的な保留利子テーブル（PIT）を使用します。
The notional PIT stores the last hop of an Interest plus its Name field and optional restrictions. This is the data required to match a Content Object to an Interest (see Section 9). When a Content
概念上のPITは、インタレストの最後のホップと、その名前フィールドおよびオプションの制限を格納します。これは、コンテンツオブジェクトをインタレストに照合するために必要なデータです（セクション9を参照）。コンテンツ
Object arrives, it must be matched against the PIT to determine which entries it satisfies. For each such entry, at most one copy of the Content Object is sent to each listed last hop in the PIT entries.
オブジェクトが到着したら、PITと照合して、満たすエントリを判別する必要があります。このようなエントリごとに、最大でコンテンツオブジェクトの1つのコピーが、PITエントリにリストされている各最終ホップに送信されます。
An actual PIT is not mandated by this specification. An implementation may use any technique that gives the same external behavior. There are, for example, research papers that use techniques like label switching in some parts of the network to reduce the per-node state incurred by the PIT [dart]. Some implementations store the PIT state in the FIB, so there is not a second table.
実際のPITは、この仕様では必須ではありません。実装では、同じ外部動作を提供する任意の手法を使用できます。たとえば、ネットワークの一部でラベルスイッチングなどの手法を使用して、PIT [dart]によって発生するノードごとの状態を削減する研究論文があります。一部の実装はPIT状態をFIBに格納するため、2番目のテーブルはありません。
If multiple Interests with the same {Name, [KeyIdRestr], [ContentObjectHashRestr]} tuple arrive at a node before a Content Object matching the first Interest comes back, they are grouped in the same PIT entry and their last hops are aggregated (see Section 2.4.2). Thus, one Content Object might satisfy multiple pending Interests in a PIT.
同じ{Name、[KeyIdRestr]、[ContentObjectHashRestr]}タプルを持つ複数のインタレストがノードに到着してから、最初のインタレストに一致するコンテンツオブジェクトが返される場合、それらは同じPITエントリにグループ化され、最後のホップが集約されます（セクションを参照） 2.4.2）。したがって、1つのコンテンツオブジェクトがPITの保留中の複数のインタレストを満たす場合があります。
In CCNx, higher-layer protocols are often called "name-based protocols" because they operate on the CCNx name. For example, a versioning protocol might append additional name segments to convey state about the version of payload. A content discovery protocol might append certain protocol-specific name segments to a prefix to discover content under that prefix. Many such protocols may exist and apply their own rules to names. They may be layered with each protocol encapsulating (to the left) a higher layer's name prefix.
CCNxでは、上位層プロトコルはCCNx名で動作するため、「名前ベースのプロトコル」と呼ばれることがよくあります。たとえば、バージョン管理プロトコルは、ペイロードのバージョンに関する状態を伝えるために追加の名前セグメントを追加する場合があります。コンテンツ検出プロトコルは、特定のプロトコル固有の名前セグメントをプレフィックスに追加して、そのプレフィックスの下のコンテンツを検出する場合があります。このようなプロトコルが多数存在し、独自のルールを名前に適用する場合があります。それらは、上位層の名前の接頭辞を（左側に）カプセル化する各プロトコルで階層化できます。
This document also describes a control message called an Interest Return. A network element may return an Interest message to a previous hop if there is an error processing the Interest. The returned Interest may be further processed at the previous hop or returned towards the Interest origin. When a node returns an Interest, it indicates that the previous hop should not expect a response from that node for the Interest, i.e., there is no PIT entry left at the returning node for a Content Object to follow.
このドキュメントでは、インタレストリターンと呼ばれる制御メッセージについても説明します。インタレストの処理中にエラーが発生した場合、ネットワーク要素は前のホップにインタレストメッセージを返すことがあります。返されたインタレストは、前のホップでさらに処理されるか、インタレストの起点に向けて返されます。ノードがインタレストを返すとき、それは前のホップがインタレストに対するそのノードからの応答を期待してはならないことを示します。つまり、コンテンツオブジェクトが続くための戻りノードにPITエントリが残っていません。
There are multiple ways to describe larger objects in CCNx. Aggregating L3 Content Objects into larger objects is beyond the scope of this document. One proposed method, File-Like ICN Collection (FLIC) [flic], uses a manifest to enumerate the pieces of a larger object. Manifests are, themselves, Content Objects. Another option is to use a convention in the Content Object name, as in the CCNx Chunking [chunking] protocol where a large object is broken into small chunks and each chunk receives a special name component indicating its serial order.
CCNxでより大きなオブジェクトを記述する方法は複数あります。 L3コンテンツオブジェクトをより大きなオブジェクトに集約することは、このドキュメントの範囲外です。提案されている方法の1つであるファイルライクICNコレクション（FLIC）[flic]は、マニフェストを使用して、より大きなオブジェクトの断片を列挙します。マニフェストは、それ自体がコンテンツオブジェクトです。もう1つのオプションは、CCNx Chunking [chunking]プロトコルのように、コンテンツオブジェクト名に規則を使用することです。この場合、大きなオブジェクトは小さなチャンクに分割され、各チャンクはそのシリアル順序を示す特別な名前コンポーネントを受け取ります。
At the semantic level, described in this document, we do not address fragmentation. One experimental fragmentation protocol, BeginEnd Fragments [befrags], uses a multipoint PPP-style technique for use over L2 interfaces with the specification for CCNx Messages [RFC8609] in TLV wire encoding.
このドキュメントで説明されているセマンティックレベルでは、断片化については扱いません。実験的なフラグメンテーションプロトコルの1つであるBeginEnd Fragments [befrags]は、TLVワイヤエンコーディングでのCCNxメッセージ[RFC8609]の仕様を備えたL2インターフェイスで使用するマルチポイントPPPスタイルの手法を使用しています。
With these concepts, the remainder of the document specifies the behavior of a forwarder in processing Interest, Content Object, and Interest Return messages.
これらの概念により、ドキュメントの残りの部分では、インタレスト、コンテンツオブジェクト、およびインタレストリターンメッセージの処理におけるフォワーダーの動作を指定します。
This section defines the grammar of a CCNx Message (Interest, Content Object, or Interest Return). It then presents typical behaviors for a consumer, a publisher, and a forwarder. In the forwarder section, there are detailed descriptions about how to handle the forwarder-specific topics, such as HopLimit and Content Store, along with detailed processing pipelines for Interest and Content Object messages.
このセクションでは、CCNxメッセージ（インタレスト、コンテンツオブジェクト、またはインタレストリターン）の文法を定義します。次に、コンシューマー、パブリッシャー、およびフォワーダーの典型的な動作を示します。フォワーダーセクションでは、HopLimitやContent Storeなどのフォワーダー固有のトピックを処理する方法と、インタレストメッセージおよびコンテンツオブジェクトメッセージの詳細な処理パイプラインについて詳しく説明しています。
The CCNx Message ABNF [RFC5234] grammar is shown in Figure 1. The grammar does not include any encoding delimiters, such as TLVs. Specific wire encodings are given in a separate document. If a Validation section exists, the Validation Algorithm covers from the Body (BodyName or BodyOptName) through the end of the ValidationAlg section. The InterestLifetime, CacheTime, and Return Code fields exist outside of the validation envelope and may be modified.
CCNxメッセージABNF [RFC5234]文法を図1に示します。文法には、TLVなどのエンコード区切り文字は含まれていません。特定のワイヤエンコーディングについては、別のドキュメントで説明しています。検証セクションが存在する場合、検証アルゴリズムは本文（BodyNameまたはBodyOptName）からValidationAlgセクションの終わりまでをカバーします。 InterestLifetime、CacheTime、およびReturn Codeの各フィールドは、検証エンベロープの外側にあり、変更される場合があります。
HashType, PayloadType, and Private Enterprise Number (PEN) need to correspond to IANA values registered in the "CCNx Hash Function Types" and "CCNx Payload Types" registries [ccnx-registry], as well as the "Private Enterprise Numbers" registry [eprise-numbers], respectively.
HashType、PayloadType、およびPrivate Enterprise Number（PEN）は、「CCNx Hash Function Types」および「CCNx Payload Types」レジストリ[ccnx-registry]、および「Private Enterprise Numbers」レジストリに登録されているIANA値に対応する必要があります[ eprise-numbers]、それぞれ。
The various fields, in alphabetical order, are defined as:
アルファベット順のさまざまなフィールドは、次のように定義されます。
AbsTime: Absolute times are conveyed as the 64-bit UTC time in milliseconds since the epoch (standard POSIX time).
AbsTime：絶対時間は、エポック（標準POSIX時間）からのミリ秒単位の64ビットUTC時間として伝達されます。
CacheTime: The absolute time after which the publisher believes there is low value in caching the Content Object. This is a recommendation to caches (see Section 4).
CacheTime：パブリッシャーがコンテンツオブジェクトをキャッシュする価値が低いと判断するまでの絶対時間。これはキャッシュの推奨事項です（セクション4を参照）。
Cert: Some applications may wish to embed an X.509 certificate to both validate the signature and provide a trust anchor. The Cert is a DER-encoded X.509 certificate.
証明書：一部のアプリケーションでは、署名の検証とトラストアンカーの提供の両方のためにX.509証明書を埋め込むことができます。証明書は、DERでエンコードされたX.509証明書です。
ConObjField: These are optional fields that may appear in a Content Object.
ConObjField：これらは、コンテンツオブジェクトに表示されるオプションのフィールドです。
ConObjHash: The value of the Content Object Hash, which is the SHA256-32 over the message from the beginning of the body to the end of the message. Note that this coverage area is different from the ValidationAlg. This value SHOULD NOT be trusted across domains (see Section 5).
ConObjHash：コンテンツオブジェクトハッシュの値。本文の最初からメッセージの終わりまでのメッセージのSHA256-32です。このカバレッジエリアはValidationAlgとは異なることに注意してください。この値は、ドメイン全体で信頼すべきではありません（セクション5を参照）。
ContentObjectHashRestr: The Content Object Hash restriction. A Content Object must hash to the same value as the restriction using the same HashType. The ContentObjectHashRestr MUST use SHA256-32.
ContentObjectHashRestr：コンテンツオブジェクトハッシュの制限。コンテンツオブジェクトは、同じHashTypeを使用して、制限と同じ値にハッシュする必要があります。 ContentObjectHashRestrはSHA256-32を使用する必要があります。
ExpiryTime: An absolute time after which the Content Object should be considered expired (see Section 4).
ExpiryTime：コンテンツオブジェクトが期限切れと見なされるまでの絶対時間（セクション4を参照）。
Hash: Hash values carried in a Message carry a HashType to identify the algorithm used to generate the hash followed by the hash value. This form is to allow hash agility. Some fields may mandate a specific HashType.
ハッシュ：メッセージ内で運ばれるハッシュ値は、ハッシュを生成するために使用されるアルゴリズムを特定するHashTypeを運び、その後にハッシュ値が続きます。この形式は、ハッシュの俊敏性を可能にするためのものです。一部のフィールドは、特定のHashTypeを要求する場合があります。
HashType: The algorithm used to calculate a hash, which must correspond to one of the IANA "CCNx Hash Function Types" [ccnx-registry].
HashType：ハッシュの計算に使用されるアルゴリズム。これは、IANAの「CCNxハッシュ関数タイプ」[ccnx-registry]の1つに対応している必要があります。
HopLimit: Interest messages may loop if there are loops in the forwarding plane. To eventually terminate loops, each Interest carries a HopLimit that is decremented after each hop and no longer forwarded when it reaches zero. See Section 2.4.
HopLimit：転送プレーンにループがある場合、インタレストメッセージがループすることがあります。最終的にループを終了するために、各インタレストはHopLimitを伝達します。HopLimitは、各ホップの後に減分され、ゼロに達すると転送されなくなります。セクション2.4を参照してください。
InterestField: These are optional fields that may appear in an Interest message.
InterestField：これらは、Interestメッセージに表示されるオプションのフィールドです。
KeyId: An identifier for the key used in the ValidationAlg. See Validation (Section 8) for a description of how it is used for MACs and signatures.
KeyId：ValidationAlgで使用されるキーの識別子。 MACとシグネチャでの使用方法の説明については、検証（セクション8）を参照してください。
KeyIdRestr: The KeyId Restriction. A Content Object must have a KeyId with the same value as the restriction.
KeyIdRestr：KeyId制限。コンテンツオブジェクトには、制限と同じ値のKeyIdが必要です。
KeyLink: A Link (see Section 6) that names how to retrieve the key used to verify the ValidationPayload (see Section 8).
KeyLink：ValidationPayload（セクション8を参照）を検証するために使用されるキーを取得する方法を指定するリンク（セクション6を参照）。
Lifetime: The approximate time during which a requester is willing to wait for a response, usually measured in seconds. It is not strongly related to the network round-trip time, though it must necessarily be larger.
存続時間：リクエスターが応答を待つ用意があるおおよその時間。通常は秒単位で測定されます。ネットワークの往復時間とはあまり関係ありませんが、必ず大きくする必要があります。
Name: A name is made up of a nonempty first segment followed by zero or more additional segments, which may be of 0 length. Name segments are opaque octet strings and are thus case sensitive if encoding UTF-8. An Interest MUST have a Name. A Content Object MAY have a Name (see Section 9). The segments of a name are said to be complete if its segments uniquely identify a single Content Object. A name is exact if its segments are complete. An Interest carrying a full name is one that specifies an exact name and the Content Object Hash restriction of the corresponding Content Object.
名前：名前は、空でない最初のセグメントとそれに続く0個以上の追加セグメントで構成されます。名前セグメントは不透明なオクテット文字列であるため、UTF-8をエンコードする場合は大文字と小文字が区別されます。インタレストには名前が必要です。コンテンツオブジェクトには名前を付けることができます（セクション9を参照）。名前のセグメントが単一のコンテンツオブジェクトを一意に識別する場合、名前のセグメントは完全であると言います。セグメントが完全であれば、名前は正確です。完全な名前を持つインタレストは、対応するコンテンツオブジェクトの正確な名前とコンテンツオブジェクトハッシュ制限を指定するインタレストです。
Payload: The message's data, as defined by PayloadType.
ペイロード：PayloadTypeで定義されているメッセージのデータ。
PayloadType: The format of the Payload field. If missing, assume Data type (T_PAYLOADTYPE_DATA) [ccnx-registry]. Data type means the payload is opaque application bytes. Key type (T_PAYLOADTYPE_KEY [ccnx-registry]) means the payload is a DER-encoded public key or X.509 certificate. Link type (T_PAYLOADTYPE_LINK [ccnx-registry]) means it is one or more Links (see Section 6).
PayloadType：Payloadフィールドのフォーマット。欠落している場合は、データタイプ（T_PAYLOADTYPE_DATA）[ccnx-registry]であると想定します。データ型は、ペイロードが不透明なアプリケーションバイトであることを意味します。鍵タイプ（T_PAYLOADTYPE_KEY [ccnx-registry]）は、ペイロードがDERエンコードされた公開鍵またはX.509証明書であることを意味します。リンクタイプ（T_PAYLOADTYPE_LINK [ccnx-registry]）は、1つ以上のリンクであることを意味します（セクション6を参照）。
PublicKey: Some applications may wish to embed the public key used to verify the signature within the message itself. The PublickKey is DER encoded.
PublicKey：一部のアプリケーションでは、署名の検証に使用する公開鍵をメッセージ自体に埋め込むことができます。 PublickKeyはDERエンコードされています。
RelTime: A relative time, measured in milliseconds.
RelTime：ミリ秒で測定される相対時間。
ReturnCode: States the reason an Interest message is being returned to the previous hop (see Section 10.2).
ReturnCode：Interestメッセージが前のホップに返されている理由を示します（セクション10.2を参照）。
SigTime: The absolute time (UTC milliseconds) when the signature was generated. The signature time only applies to the validation algorithm; it does not necessarily represent when the validated message was created.
SigTime：署名が生成された絶対時間（UTCミリ秒）。署名時間は検証アルゴリズムにのみ適用されます。検証されたメッセージがいつ作成されたかは必ずしも表されません。
Vendor: Vendor-specific opaque data. The Vendor data includes the IANA Private Enterprise Numbers [eprise-numbers], followed by vendor-specific information. CCNx allows vendor-specific data in most locations of the grammar.
ベンダー：ベンダー固有の不透明なデータ。ベンダーデータには、IANA Private Enterprise Numbers [eprise-numbers]が含まれ、その後にベンダー固有の情報が続きます。 CCNxは、文法のほとんどの場所でベンダー固有のデータを許可します。
Message = Interest / ContentObject / InterestReturn
Interest = IntHdr BodyName [Validation]
IntHdr = HopLimit [Lifetime] *Vendor
ContentObject = ConObjHdr BodyOptName [Validation]
ConObjHdr = [CacheTime / ConObjHash] *Vendor
InterestReturn= ReturnCode Interest
BodyName = Name Common
BodyOptName = [Name] Common
Common = *Field [Payload]
Validation = ValidationAlg ValidationPayload
Name = FirstSegment *Segment
FirstSegment = 1*OCTET / Vendor
Segment = *OCTET / Vendor
ValidationAlg = (RSA-SHA256 / EC-SECP-256K1 / EC-SECP-384R1 /
HMAC-SHA256 / CRC32C) *Vendor
ValidationPayload = 1*OCTET
PublicAlg = KeyId [SigTime] [KeyLink] [PublicKey] [Cert]
RSA-SHA256 = PublicAlg
EC-SECP-256K1 = PublicAlg
EC-SECP-384R1 = PublicAlg
HMAC-SHA256 = KeyId [SigTime] [KeyLink]
CRC32C = [SigTime]
AbsTime = 8OCTET ; 64-bit UTC msec since epoch
CacheTime = AbsTime
ConObjField = ExpiryTime / PayloadType
ConObjHash = Hash
ExpiryTime = AbsTime
Field = InterestField / ConObjField / Vendor
Hash = HashType 1*OCTET
HashType = 2OCTET ; IANA "CCNx Hash Function Types"
HopLimit = OCTET
InterestField = KeyIdRestr / ContentObjectHashRestr
KeyId = Hash
KeyIdRestr = Hash
KeyLink = Link
Lifetime = RelTime
Link = Name [KeyIdRestr] [ContentObjectHashRestr]
ContentObjectHashRestr = Hash
Payload = *OCTET
PayloadType = OCTET ; IANA "CCNx Payload Types"
PublicKey = *OCTET ; DER-encoded public key
Cert = *OCTET ; DER-encoded X.509 Certificate
RelTime = 1*OCTET ; msec
ReturnCode = OCTET ; see Section 10.2
SigTime = AbsTime
Vendor = PEN *OCTET
PEN = 1*OCTET ; IANA "Private Enterprise Number"
Figure 1: CCNx Message ABNF Grammar
図1：CCNxメッセージABNF文法
To request a piece of content for a given {Name, [KeyIdRest], [ContentObjectHashRestr]} tuple, a consumer creates an Interest message with those values. It MAY add a validation section, typically only a CRC32C. A consumer MAY put a Payload field in an Interest to send additional data to the producer beyond what is in the name. The name is used for routing and may be remembered at each hop in the notional PIT to facilitate returning a Content Object; storing large amounts of state in the name could lead to high memory requirements. Because the payload is not considered when forwarding an Interest or matching a Content Object to an Interest, a consumer SHOULD put an Interest Payload ID (see Section 3.2) as part of the name to allow a forwarder to match Interests to Content Objects and avoid aggregating Interests with different payloads. Similarly, if a consumer uses a MAC or a signature, it SHOULD also include a unique segment as part of the name to prevent the Interest from being aggregated with other Interests or satisfied by a Content Object that has no relation to the validation.
指定された{Name、[KeyIdRest]、[ContentObjectHashRestr]}タプルのコンテンツをリクエストするために、コンシューマーはそれらの値でInterestメッセージを作成します。検証セクション、通常はCRC32Cのみを追加できます。コンシューマーは、ペイロードフィールドをインタレストに配置して、名前に含まれるもの以外の追加のデータをプロデューサーに送信する場合があります。この名前はルーティングに使用され、コンテンツオブジェクトを返すのを容易にするために、概念的なPITの各ホップで記憶される場合があります。名前に大量の状態を保存すると、メモリ要件が高くなる可能性があります。インタレストを転送するとき、またはコンテンツオブジェクトをインタレストに照合するときにペイロードは考慮されないため、コンシューマは、インタレストペイロードID（セクション3.2を参照）を名前の一部として入れて、フォワーダがインタレストをコンテンツオブジェクトに照合し、集約を回避できるようにする必要があります。さまざまなペイロードの関心。同様に、コンシューマーがMACまたは署名を使用する場合は、名前の一部として一意のセグメントを含めて、インタレストが他のインタレストと集約されたり、検証とは関係のないコンテンツオブジェクトによって満たされたりしないようにする必要があります。
The consumer SHOULD specify an InterestLifetime, which is the length of time the consumer is willing to wait for a response. The InterestLifetime is an application-scale time, not a network round-trip time (see Section 2.4.2). If not present, the InterestLifetime will use a default value (2 seconds).
コンシューマは、コンシューマが応答を待つ用意がある時間の長さであるInterestLifetimeを指定する必要があります（SHOULD）。 InterestLifetimeはアプリケーションスケールの時間であり、ネットワークの往復時間ではありません（セクション2.4.2を参照）。存在しない場合、InterestLifetimeはデフォルト値（2秒）を使用します。
The consumer SHOULD set the Interest HopLimit to a reasonable value or use the default 255. If the consumer knows the distances to the producer via routing, it SHOULD use that value.
コンシューマーはInterest HopLimitを適切な値に設定するか、デフォルトの255を使用する必要があります。コンシューマーがルーティングを介してプロデューサーまでの距離を知っている場合は、その値を使用する必要があります（SHOULD）。
A consumer hands off the Interest to its first forwarder, which will then forward the Interest over the network to a publisher (or replica) that may satisfy it based on the name (see Section 2.4).
コンシューマはインタレストを最初のフォワーダに渡し、次にインタレストをネットワーク経由でパブリッシャ（またはレプリカ）に転送します。パブリッシャ（またはレプリカ）は、名前に基づいてそれを満たします（セクション2.4を参照）。
Interest messages are unreliable. A consumer SHOULD run a transport protocol that will retry the Interest if it goes unanswered, up to the InterestLifetime. No transport protocol is specified in this document.
関心メッセージは信頼できません。コンシューマーは、InterestLifetimeまで、応答がない場合にInterestを再試行するトランスポートプロトコルを実行する必要があります（SHOULD）。このドキュメントでは、トランスポートプロトコルは指定されていません。
The network MAY send to the consumer an Interest Return message that indicates the network cannot fulfill the Interest. The ReturnCode specifies the reason for the failure, such as no route or congestion. Depending on the ReturnCode, the consumer MAY retry the Interest or MAY return an error to the requesting application.
ネットワークは、ネットワークがインタレストを満たすことができないことを示すインタレストリターンメッセージをコンシューマに送信する場合があります。 ReturnCodeは、ルートや輻輳がないなどの失敗の理由を指定します。 ReturnCodeに応じて、コンシューマはInterestを再試行するか、要求しているアプリケーションにエラーを返す場合があります。
If the content was found and returned by the first forwarder, the consumer will receive a Content Object. The consumer uses the following set of checks to validate a received Content Object:
最初のフォワーダーがコンテンツを見つけて返した場合、コンシューマーはコンテンツオブジェクトを受け取ります。コンシューマは、次の一連のチェックを使用して、受信したコンテンツオブジェクトを検証します。
o The consumer MUST ensure the Content Object is properly formatted.
o コンシューマは、コンテンツオブジェクトが適切にフォーマットされていることを確認する必要があります。
o The consumer MUST verify that the returned Content Object matches one or more pending Interests as per Section 9.
o 消費者は、返されたコンテンツオブジェクトがセクション9の1つ以上の保留中のインタレストと一致することを確認する必要があります。
o If the Content Object is signed, the consumer SHOULD cryptographically verify the signature as per Section 8. If it does not have the corresponding key, it SHOULD fetch the key, such as from a key resolution service or via the KeyLink.
o コンテンツオブジェクトが署名されている場合、消費者はセクション8に従って署名を暗号で検証する必要があります（SHOULD）。対応するキーがない場合は、キー解決サービスから、またはKeyLink経由などでキーをフェッチする必要があります（SHOULD）。
o If the signature has a SigTime, the consumer MAY use that in considering if the signature is valid. For example, if the consumer is asking for dynamically generated content, it should expect the SigTime not to be before the time the Interest was generated.
o 署名にSigTimeが含まれている場合、コンシューマは署名が有効かどうかを検討する際にそれを使用できます（MAY）。たとえば、コンシューマが動的に生成されたコンテンツを要求している場合は、SigTimeがInterestが生成された時間より前ではないと想定する必要があります。
o If the Content Object is signed, the consumer SHOULD assert the trustworthiness of the signing key to the namespace. Such an assertion is beyond the scope of this document, though one may use traditional PKI methods, a trusted key resolution service, or methods like [trust].
o コンテンツオブジェクトが署名されている場合、コンシューマは名前空間に対する署名鍵の信頼性をアサートする必要があります（SHOULD）。このようなアサーションはこのドキュメントの範囲外ですが、従来のPKIメソッド、信頼できるキー解決サービス、または[trust]などのメソッドを使用する場合があります。
o The consumer MAY cache the Content Object for future use, up to the ExpiryTime if present.
o コンシューマは、存在する場合はExpiryTimeまで、将来の使用のためにコンテンツオブジェクトをキャッシュできます（MAY）。
o The consumer MAY accept a Content Object off the wire that is expired. A packet Content Object may expire while in flight; there is no requirement that forwarders drop expired packets in flight. The only requirement is that Content Stores, caches, or producers MUST NOT respond with an expired Content Object.
o 消費者は、期限切れのオフ・ザ・コンテンツ・オブジェクトを受け入れることができます。パケットコンテンツオブジェクトは、飛行中に期限切れになることがあります。フォワーダが期限切れのパケットを処理中にドロップする必要はありません。唯一の要件は、コンテンツストア、キャッシュ、またはプロデューサーが期限切れのコンテンツオブジェクトで応答してはならないことです。
This document does not specify the method by which names populate a FIB table at forwarders (see Section 2.4). A publisher is either configured with one or more name prefixes under which it may create content or it chooses its name prefixes and informs the routing layer to advertise those prefixes.
このドキュメントでは、フォワーダーでFIBテーブルに名前を入力する方法を指定していません（セクション2.4を参照）。パブリッシャーは、コンテンツを作成できる1つ以上の名前プレフィックスで構成されているか、または名前プレフィックスを選択してルーティングレイヤーに通知し、それらのプレフィックスをアドバタイズします。
When a publisher receives an Interest, it SHOULD:
パブリッシャーがインタレストを受け取るとき、それはすべきです：
o Verify that the Interest is part of the publisher's namespace(s).
o Interestが発行者の名前空間の一部であることを確認します。
o If the Interest has a Validation section, verify it as per Section 8. Usually an Interest will only have a CRC32C, unless the publisher application specifically accommodates other validations. The publisher MAY choose to drop Interests that carry a Validation section if the publisher application does not expect those signatures, as this could be a form of computational denial of service. If the signature requires a key that the publisher does not have, it is NOT RECOMMENDED that the publisher fetch the key over the network unless it is part of the application's expected behavior.
o インタレストに検証セクションがある場合は、セクション8に従って確認します。パブリッシャーアプリケーションが他の検証に特に対応していない限り、インタレストには通常CRC32Cのみが含まれます。パブリッシャーアプリケーションがこれらのシグネチャを予期していない場合、パブリッシャーは検証セクションを含むインタレストをドロップすることを選択できます。これは、これが計算によるサービス拒否の一種である可能性があるためです。署名にパブリッシャーが持たないキーが必要な場合、アプリケーションの予期される動作の一部でない限り、パブリッシャーがネットワーク経由でキーをフェッチすることはお勧めしません。
o Retrieve or generate the requested Content Object and return it to the Interest's previous hop. If the requested content cannot be returned, the publisher SHOULD reply with an Interest Return or a Content Object with application payload that says the content is not available; this Content Object should have a short ExpiryTime in the future or not be cacheable (i.e., an expiry time of 0).
o 要求されたコンテンツオブジェクトを取得または生成し、それをインタレストの前のホップに戻します。要求されたコンテンツが返されない場合、発行者は、利息の返答またはコンテンツが利用できないことを示すアプリケーションペイロードを含むコンテンツオブジェクトで応答する必要があります。このコンテンツオブジェクトは、将来のExpiryTimeが短いか、キャッシュできない（つまり、有効期限が0である）必要があります。
A forwarder routes Interest messages based on a Forwarding Information Base (FIB), returns Content Objects that match Interests to the Interest's previous hop, and processes Interest Return control messages. It may also keep a cache of Content Objects in the notional Content Store table. This document does not specify the internal behavior of a forwarder, only these and other external behaviors.
フォワーダーは、転送情報ベース（FIB）に基づいてインタレストメッセージをルーティングし、インタレストをインタレストの前のホップに一致させるコンテンツオブジェクトを返し、インタレストリターンコントロールメッセージを処理します。また、概念的なコンテンツストアテーブルにコンテンツオブジェクトのキャッシュを保持することもできます。このドキュメントでは、フォワーダーの内部動作は指定せず、これらおよび他の外部動作のみを指定します。
In this document, we will use two processing pipelines: one for Interests and one for Content Objects. Interest processing is made up of checking for duplicate Interests in the PIT (see Section 2.4.2), checking for a cached Content Object in the Content Store (see Section 2.4.3), and forwarding an Interest via the FIB. Content Store processing is made up of checking for matching Interests in the PIT and forwarding to those previous hops.
このドキュメントでは、インタレスト用とコンテンツオブジェクト用の2つの処理パイプラインを使用します。インタレスト処理は、PITでのインタレストの重複のチェック（セクション2.4.2を参照）、コンテンツストアのキャッシュされたコンテンツオブジェクトのチェック（セクション2.4.3を参照）、およびFIBを介してインタレストを転送することで構成されます。 Content Storeの処理は、PIT内の一致するインタレストのチェックと、それらの以前のホップへの転送で構成されています。
Interest looping is not prevented in CCNx. An Interest traversing loops is eventually discarded using the hop-limit field of the Interest, which is decremented at each hop traversed by the Interest.
CCNxではインタレストループは防止されません。ループを通過するインタレストは、インタレストのホップ制限フィールドを使用して最終的に破棄されます。このフィールドは、インタレストが通過するホップごとにデクリメントされます。
A loop may also terminate because the Interest is aggregated with its previous PIT entry along the loop. In this case, the Content Object will be sent back along the loop and eventually return to a node that already forwarded the content, so it will likely not have a PIT entry anymore. When the content reaches a node without a PIT entry, it will be discarded. It may be that a new Interest or another looped Interest will return to that same node, in which case the node will return a cached response to make a new PIT entry, as below.
ループは、ループに沿って以前のPITエントリでインタレストが集約されるため、ループが終了することもあります。この場合、コンテンツオブジェクトはループに沿って送り返され、最終的にはすでにコンテンツを転送したノードに戻るため、PITエントリはもうありません。コンテンツがPITエントリのないノードに到達すると、そのコンテンツは破棄されます。新しいインタレストまたはループされた別のインタレストが同じノードに戻る場合があります。その場合、ノードはキャッシュされた応答を返し、以下のように新しいPITエントリを作成します。
The HopLimit is the last resort method to stop Interest loops where a Content Object chases an Interest around a loop and where the intermediate nodes, for whatever reason, no longer have a PIT entry and do not cache the Content Object.
HopLimitは、コンテンツオブジェクトがループの周りのインタレストを追跡し、中間ノードが何らかの理由でPITエントリを持たなくなり、コンテンツオブジェクトをキャッシュしないインタレストループを停止する最後の手段です。
Every Interest MUST carry a HopLimit. An Interest received from a local application MAY have a 0 HopLimit, which restricts the Interest to other local sources.
すべてのインタレストはHopLimitを運ぶ必要があります。ローカルアプリケーションから受信したインタレストには、ホップリミットが0である場合があり、これによりインタレストが他のローカルソースに制限されます。
When an Interest is received from another forwarder, the HopLimit MUST be positive, otherwise the forwarder will discard the Interest. A forwarder MUST decrement the HopLimit of an Interest by at least 1 before it is forwarded.
別のフォワーダーからインタレストを受信した場合、HopLimitは正でなければなりません。そうでない場合、フォワーダーはインタレストを破棄します。フォワーダーは、転送される前に、インタレストのHopLimitを少なくとも1つデクリメントする必要があります。
If the decremented HopLimit equals 0, the Interest MUST NOT be forwarded to another forwarder; it MAY be sent to a local publisher application or serviced from a local Content Store.
デクリメントされたHopLimitが0に等しい場合、インタレストを別のフォワーダーに転送してはなりません（MUST NOT）。ローカルパブリッシャーアプリケーションに送信するか、ローカルコンテンツストアからサービスを提供できます。
A RECOMMENDED HopLimit-processing pipeline is below:
推奨されるHopLimit処理パイプラインを以下に示します。
o If Interest received from a remote system:
o リモートシステムからインタレストを受け取った場合：
* If received HopLimit is 0, optionally send Interest Return (HopLimit Exceeded), and discard Interest.
* 受信したHopLimitが0の場合、オプションでインタレストリターン（HopLimit Exceeded）を送信し、インタレストを破棄します。
* Otherwise, decrement the HopLimit by 1.
* それ以外の場合は、HopLimitを1だけ減らします。
o Process as per Content Store and Aggregation rules.
o Content Storeおよび集約ルールに従って処理します。
o If the Interest will be forwarded:
o インタレストが転送される場合：
* If the (potentially decremented) HopLimit is 0, restrict forwarding to the local system.
* （減少する可能性がある）HopLimitが0の場合、ローカルシステムへの転送を制限します。
* Otherwise, forward as desired to local or remote systems.
* それ以外の場合は、必要に応じてローカルシステムまたはリモートシステムに転送します。
Interest aggregation is when a forwarder receives an Interest message that could be satisfied by the response to another Interest message already forwarded by the node, so the forwarder suppresses forwarding the new Interest; it only records the additional previous hop so a Content Object sent in response to the first Interest will satisfy both Interests.
インタレスト集約とは、フォワーダーがノードによって既に転送された別のインタレストメッセージへの応答で満たすことができるインタレストメッセージを受信した場合です。そのため、フォワーダーは新しいインタレストの転送を抑制します。追加の以前のホップのみを記録するため、最初のインタレストに応答して送信されたコンテンツオブジェクトは両方のインタレストを満たします。
CCNx uses an Interest aggregation rule that assumes the InterestLifetime is akin to a subscription time and is not a network round-trip time. Some previous aggregation rules assumed the lifetime was a round-trip time, but this leads to problems of expiring an Interest before a response comes if the RTT is estimated too short or interfering with an Automatic Repeat reQuest (ARQ) scheme that wants to retransmit an Interest but a prior Interest overestimated the RTT.
CCNxは、InterestLifetimeがサブスクリプション時間と同じであり、ネットワークラウンドトリップ時間ではないことを前提とするInterest集計ルールを使用します。以前の一部の集約ルールでは、ライフタイムは往復時間であると想定されていましたが、RTTが短すぎると推定される場合、または再送を要求する自動繰り返し要求（ARQ）スキームを妨害する場合、応答が来る前にインタレストが期限切れになるという問題が発生します。インタレストですが、以前のインタレストはRTTを過大評価していました。
A forwarder MAY implement an Interest aggregation scheme. If it does not, then it will forward all Interest messages. This does not imply that multiple, possibly identical, Content Objects will come back. A forwarder MUST still satisfy all pending Interests, so one Content Object could satisfy multiple similar Interests, even if the forwarder did not suppress duplicate Interest messages.
フォワーダーはInterest集計スキームを実装してもよい（MAY）。そうでない場合は、すべてのInterestメッセージを転送します。これは、複数の、おそらく同一のコンテンツオブジェクトが返されることを意味するものではありません。フォワーダーは保留中のすべてのインタレストを依然として満たす必要があるため、フォワーダーが重複するインタレストメッセージを抑制しなかった場合でも、1つのコンテンツオブジェクトが複数の同様のインタレストを満たせる可能性があります。
A RECOMMENDED Interest aggregation scheme is:
推奨される金利集計スキームは次のとおりです。
o Two Interests are considered "similar" if they have the same Name, KeyIdRestr, and ContentObjectHashRestr, where a missing optional field in one must be missing in the other.
o 2つのインタレストは、Name、KeyIdRestr、およびContentObjectHashRestrが同じである場合、「類似している」と見なされます。一方のオプションフィールドが欠落していると、もう一方のフィールドも欠落する必要があります。
o Let the notional value InterestExpiry (a local value at the forwarder) be equal to the receive time plus the InterestLifetime (or a platform-dependent default value if not present).
o 想定値InterestExpiry（フォワーダーのローカル値）を、受信時間+ InterestLifetime（または存在しない場合はプラットフォーム依存のデフォルト値）に等しくしたものとします。
o An Interest record (PIT entry) is considered invalid if its InterestExpiry time is in the past.
o InterestExpiry時間が過去の場合、Interestレコード（PITエントリ）は無効と見なされます。
o The first reception of an Interest MUST be forwarded.
o インタレストの最初の受信を転送する必要があります。
o A second or later reception of an Interest similar to a valid pending Interest from the same previous hop MUST be forwarded. We consider these a retransmission request.
o 同じ前のホップからの有効な保留中のインタレストに類似したインタレストの2回目以降の受信は転送されなければなりません（MUST）。これらは再送信リクエストと見なされます。
o A second or later reception of an Interest similar to a valid pending Interest from a new previous hop MAY be aggregated (not forwarded). If this Interest has a larger HopLimit than the pending Interest, it MUST be forwarded.
o 新しい前のホップからの有効な保留中のインタレストに類似した2回目以降のインタレストの受信は、集約される場合があります（転送されません）。このインタレストに保留中のインタレストよりも大きなHopLimitがある場合は、転送する必要があります。
o Aggregating an Interest MUST extend the InterestExpiry time of the Interest record. An implementation MAY keep a single InterestExpiry time for all previous hops or MAY keep the InterestExpiry time per previous hop. In the first case, the forwarder might send a Content Object down a path that is no longer waiting for it, in which case the previous hop (next hop of the Content Object) would drop it.
o インタレストを集約すると、インタレストレコードのInterestExpiry時間を延長する必要があります。実装は、以前のすべてのホップについて単一のInterestExpiry時間を維持してもよいし、前のホップごとのInterestExpiry時間を維持してもよい（MAY）。最初のケースでは、フォワーダーがコンテンツオブジェクトを、それを待機していないパスに送信する場合があります。その場合、前のホップ（コンテンツオブジェクトの次のホップ）がドロップします。
The Content Store is a special cache that is an integral part of a CCNx forwarder. It is an optional component. It serves to repair lost packets and handle flash requests for popular content. It could be prepopulated or use opportunistic caching. Because the Content Store could serve to amplify an attack via cache poisoning, there are special rules about how a Content Store behaves.
Content Storeは、CCNxフォワーダーの不可欠な部分である特別なキャッシュです。これはオプションのコンポーネントです。失われたパケットを修復し、人気のあるコンテンツのフラッシュリクエストを処理します。事前に入力するか、日和見キャッシングを使用できます。 Content Storeはキャッシュポイズニングを介して攻撃を増幅する可能性があるため、Content Storeの動作には特別なルールがあります。
1. A forwarder MAY implement a Content Store. If it does, the Content Store matches a Content Object to an Interest via the normal matching rules (see Section 9).
1. フォワーダーはContent Storeを実装してもよい（MAY）。一致する場合、Content Storeは通常の一致ルールを介してコンテンツオブジェクトをインタレストに一致させます（セクション9を参照）。
2. If an Interest has a KeyId restriction, then the Content Store MUST NOT reply unless it knows the signature on the matching Content Object is correct. It may do this by external knowledge (i.e., in a managed network or system with prepopulated caches) or by having the public key and cryptographically verifying the signature. A Content Store is NOT REQUIRED to verify signatures; if it does not, then it treats these cases like a cache miss.
2. インタレストにKeyId制限がある場合、一致するコンテンツオブジェクトの署名が正しいことを知らない限り、コンテンツストアは応答してはなりません。これは、外部の知識（つまり、管理されたネットワークまたは事前にキャッシュが設定されているシステム内）によって、または公開鍵を持ち、署名を暗号で検証することによって行われます。 Content Storeは署名を検証する必要はありません。そうでない場合は、これらのケースをキャッシュミスのように扱います。
3. If a Content Store chooses to verify signatures, then it MAY do so as follows. If the public key is provided in the Content Object itself (i.e., in the PublicKey field) or in the Interest, the Content Store MUST verify that the public key's hash is equal to the KeyId and that it verifies the signature (see Section 8.4). A Content Store MAY verify the digital signature of a Content Object before it is cached, but it is not required to do so. A Content Store SHOULD NOT fetch keys over the network. If it cannot or has not yet verified the signature, it should treat the Interest as a cache miss.
3. Content Storeが署名を検証することを選択した場合は、次のように行うことができます。公開鍵がコンテンツオブジェクト自体（つまり、PublicKeyフィールド）またはインタレストで提供される場合、コンテンツストアは、公開鍵のハッシュがKeyIdと等しいこと、および署名を検証することを検証する必要があります（セクション8.4を参照） 。 Content Storeは、キャッシュされる前にコンテンツオブジェクトのデジタル署名を検証できますが、そうする必要はありません。 Content Storeはネットワーク経由でキーをフェッチしてはいけません。署名を検証できない、またはまだ検証していない場合、インタレストをキャッシュミスとして処理する必要があります。
4. If an Interest has a Content Object Hash restriction, then the Content Store MUST NOT reply unless it knows the matching Content Object has the correct hash. If it cannot verify the hash, then it should treat the Interest as a cache miss.
4. インタレストにコンテンツオブジェクトハッシュ制限がある場合、コンテンツストアは、一致するコンテンツオブジェクトに正しいハッシュがあることを知らない限り、応答してはなりません（MUST NOT）。ハッシュを検証できない場合、インタレストをキャッシュミスとして処理する必要があります。
5. It must obey the cache control directives (see Section 4).
5. キャッシュ制御ディレクティブに従う必要があります（セクション4を参照）。
1. Perform the HopLimit check (see Section 2.4.1).
1. HopLimitチェックを実行します（セクション2.4.1を参照）。
2. If the Interest carries a validation, such as a MIC or a signature with an embedded public key or certificate, a forwarder MAY validate the Interest as per Section 8. A forwarder SHOULD NOT fetch keys via a KeyLink. If the forwarder drops an Interest due to failed validation, it MAY send an Interest Return (Section 10.3.9).
2.インタレストがMICまたは公開キーまたは証明書が埋め込まれた署名などの検証を行う場合、フォワーダーはセクション8に従ってインタレストを検証できます（MAY）。フォワーダーはKeyLinkを介してキーをフェッチしないでください。検証が失敗したためにフォワーダーがインタレストをドロップした場合、フォワーダーはインタレストリターンを送信してもよい（セクション10.3.9）。
3. Determine if the Interest can be aggregated as per Section 2.4.2. If it can be, aggregate and do not forward the Interest.
3. セクション2.4.2に従ってインタレストを集約できるかどうかを判断します。可能であれば、集約してインタレストを転送しないでください。
4. If forwarding the Interest, check for a hit in the Content Store as per Section 2.4.3. If a matching Content Object is found, return it to the Interest's previous hop. This injects the Content Store as per Section 2.4.5.
4. Interestを転送する場合は、セクション2.4.3に従ってContent Storeのヒットを確認します。一致するコンテンツオブジェクトが見つかった場合、それをインタレストの前のホップに戻します。これにより、セクション2.4.5に従ってContent Storeが挿入されます。
5. Look up the Interest in the FIB. Longest Prefix Match (LPM) is performed name segment by name segment (not byte or bit). It SHOULD exclude the Interest's previous hop. If a match is found, forward the Interest. If no match is found or the forwarder chooses not to forward due to a local condition (e.g., congestion), it SHOULD send an Interest Return message as per Section 10.
5. FIBのインタレストを調べます。最長プレフィックス一致（LPM）は、名前セグメントごとに実行されます（バイトまたはビットではありません）。インタレストの以前のホップを除外する必要があります。一致が見つかった場合、インタレストを転送します。一致が見つからない場合、またはフォワーダーがローカルの状態（輻輳など）のために転送しないことを選択した場合は、セクション10に従ってインタレストリターンメッセージを送信する必要があります（SHOULD）。
1. It is RECOMMENDED that a forwarder that receives a Content Object check that the Content Object came from an expected previous hop. An expected previous hop is one pointed to by the FIB or one recorded in the PIT as having had a matching Interest sent that way.
1. コンテンツオブジェクトを受信するフォワーダーは、コンテンツオブジェクトが予期された以前のホップから来たことを確認することをお勧めします。予想される以前のホップは、FIBによってポイントされたもの、または一致するインタレストが送信されたとしてPITに記録されたものです。
2. A Content Object MUST be matched to all pending Interests that satisfy the matching rules (see Section 9). Each satisfied pending Interest MUST then be removed from the set of pending Interests.
2. コンテンツオブジェクトは、一致ルールを満たすすべての保留中のインタレストに一致する必要があります（セクション9を参照）。満たされた保留中の各興味は、保留中の興味のセットから削除する必要があります。
3. A forwarder SHOULD NOT send more than one copy of the received Content Object to the same Interest previous hop. It may happen, for example, that two Interests ask for the same Content Object in different ways (e.g., by name and by name and KeyId), and that they both come from the same previous hop. It is normal to send the same Content Object multiple times on the same interface, such as Ethernet, if it is going to different previous hops.
3. フォワーダーは、受信したコンテンツオブジェクトの複数のコピーを同じインタレストの前のホップに送信してはなりません（SHOULD NOT）。たとえば、2つのインタレストが同じコンテンツオブジェクトを異なる方法で（たとえば、名前と名前とKeyIdで）要求し、両方が同じ前のホップからのものである場合があります。同じコンテンツオブジェクトがイーサネットなどの同じインターフェイスで複数回送信されるのは、以前のホップが異なる場合は通常です。
4. A Content Object SHOULD only be put in the Content Store if it satisfied an Interest (and passed rule #1 above). This is to reduce the chances of cache poisoning.
4. コンテンツオブジェクトは、インタレストを満たしている（および上記のルール＃1に合格した）場合にのみコンテンツストアに配置する必要があります（SHOULD）。これは、キャッシュポイズニングの可能性を減らすためです。
A CCNx name is a composition of name segments. Each name segment carries a label identifying the purpose of the name segment, and a value. For example, some name segments are general names and some serve specific purposes such as carrying version information or the sequencing of many chunks of a large object into smaller, signed Content Objects.
CCNx名は、名前セグメントの構成です。各名前セグメントには、名前セグメントの目的を識別するラベルと値が含まれています。たとえば、一部の名前セグメントは一般的な名前であり、バージョン情報の伝達や大きなオブジェクトの多数のチャンクの小さな署名されたコンテンツオブジェクトへのシーケンスなど、特定の目的に役立つものもあります。
There are three different types of names in CCNx: prefix, exact, and full names. A prefix name is simply a name that does not uniquely identify a single Content Object, but rather a namespace or prefix of an existing Content Object name. An exact name is one that uniquely identifies the name of a Content Object. A full name is one that is exact and is accompanied by an explicit or implicit ConObjHash. The ConObjHash is explicit in an Interest and implicit in a Content Object.
CCNxには3種類の名前があります：プレフィックス、完全名、フルネーム。プレフィックス名は、単一のコンテンツオブジェクトを一意に識別しない名前であり、既存のコンテンツオブジェクト名の名前空間またはプレフィックスです。正確な名前は、コンテンツオブジェクトの名前を一意に識別する名前です。完全な名前は正確で、明示的または暗黙的なConObjHashを伴います。 ConObjHashはインタレストでは明示的であり、コンテンツオブジェクトでは暗黙的です。
Note that a forwarder does not need to know any semantics about a name. It only needs to be able to match a prefix to forward Interests and match an exact or full name to forward Content Objects. It is not sensitive to the name segment types.
フォワーダーは名前に関するセマンティクスを知る必要がないことに注意してください。インタレストを転送する場合はプレフィックスに一致し、コンテンツオブジェクトを転送する場合は正確な名前または完全な名前に一致する必要があるだけです。これは、名前セグメントタイプの影響を受けません。
The name segment labels specified in this document are given in Table 1. Name Segment is a general name segment, typically occurring in the routable prefix and user-specified content name. Interest Payload ID is a name segment to identify the Interest's payload. Application Components are a set of name segment types reserved for application use.
このドキュメントで指定されている名前セグメントラベルを表1に示します。名前セグメントは一般的な名前セグメントであり、通常はルーティング可能なプレフィックスとユーザー指定のコンテンツ名で発生します。 Interest Payload IDは、インタレストのペイロードを識別する名前セグメントです。アプリケーションコンポーネントは、アプリケーションで使用するために予約されている名前セグメントタイプのセットです。
+-------------+-----------------------------------------------------+
| Type | Description |
+-------------+-----------------------------------------------------+
| Name | A generic name segment that includes arbitrary |
| Segment | octets. |
| | |
| Interest | An octet string that identifies the payload carried |
| Payload ID | in an Interest. As an example, the Payload ID |
| | might be a hash of the Interest Payload. This |
| | provides a way to differentiate between Interests |
| | based on the payload solely through a name segment |
| | without having to include all the extra bytes of |
| | the payload itself. |
| | |
| Application | An application-specific payload in a name segment. |
| Components | An application may apply its own semantics to these |
| | components. A good practice is to identify the |
| | application in a name segment prior to the |
| | application component segments. |
+-------------+-----------------------------------------------------+
Table 1: CCNx Name Segment Types
表1：CCNx名前セグメントタイプ
At the lowest level, a forwarder does not need to understand the semantics of name segments; it need only identify name segment boundaries and be able to compare two name segments (both label and value) for equality. The forwarder matches names segment by segment against its forwarding table to determine a next hop.
最低レベルでは、フォワーダーは名前セグメントのセマンティクスを理解する必要はありません。名前セグメントの境界を識別し、2つの名前セグメント（ラベルと値の両方）が等しいかどうかを比較できる必要があるだけです。フォワーダーは、転送テーブルとセグメントごとに名前を照合して、ネクストホップを決定します。
This section uses the CCNx URI [ccnx-uri] representation of CCNx names. Note that as per the message grammar, an Interest must have a Name with at least one name segment that must have at least 1 octet of value. A Content Object must have a similar name or no name at all. The FIB, on the other hand, could have 0-length names (a default route), or a first name segment with no value, or a regular name.
このセクションでは、CCNx名のCCNx URI [ccnx-uri]表現を使用します。メッセージの文法に従って、インタレストには少なくとも1オクテットの値が必要な少なくとも1つの名前セグメントを持つ名前が必要です。コンテンツオブジェクトには、類似した名前を付けるか、名前を付けないでください。一方、FIBには長さ0の名前（デフォルトルート）、値のない名前セグメント、または通常の名前を付けることができます。
+--------------------------+----------------------------------------+
| Name | Description |
+--------------------------+----------------------------------------+
| ccnx:/ | A 0-length name, corresponds to a |
| | default route. |
| | |
| ccnx:/NAME= | A name with 1 segment of 0 length, |
| | distinct from ccnx:/. |
| | |
| ccnx:/NAME=foo/APP:0=bar | A 2-segment name, where the first |
| | segment is of type NAME and the second |
| | segment is of type APP:0. |
+--------------------------+----------------------------------------+
Table 2: CCNx Name Examples
表2：CCNx名の例
An Interest may also have a Payload field that carries state about the Interest but is not used to match a Content Object. If an Interest contains a payload, the Interest name should contain an Interest Payload ID (IPID). The IPID allows a PIT entry to correctly multiplex Content Objects in response to a specific Interest with a specific payload ID. The IPID could be derived from a hash of the payload or could be a Globally Unique Identifier (GUID) or a nonce. An optional Metadata field defines the IPID field so other systems can verify the IPID, such as when it is derived from a hash of the payload. No system is required to verify the IPID.
インタレストには、インタレストに関する状態を運ぶペイロードフィールドがある場合がありますが、コンテンツオブジェクトの照合には使用されません。インタレストにペイロードが含まれている場合、インタレスト名にはインタレストペイロードID（IPID）を含める必要があります。 IPIDにより、PITエントリは、特定のペイロードIDを持つ特定のインタレストに応じてコンテンツオブジェクトを正しく多重化できます。 IPIDは、ペイロードのハッシュから取得することも、グローバル一意識別子（GUID）またはナンスにすることもできます。オプションのメタデータフィールドはIPIDフィールドを定義するため、ペイロードのハッシュから派生した場合など、他のシステムがIPIDを検証できます。 IPIDを検証するためのシステムは必要ありません。
CCNx supports two fields that affect cache control. These determine how a cache or Content Store handles a Content Object. They are not used in the fast path; they are only used to determine if a Content Object can be injected onto the fast path in response to an Interest.
CCNxは、キャッシュ制御に影響する2つのフィールドをサポートしています。これらは、キャッシュまたはコンテンツストアがコンテンツオブジェクトを処理する方法を決定します。それらは高速パスでは使用されません。これらは、インタレストに応じてコンテンツオブジェクトを高速パスに挿入できるかどうかを決定するためにのみ使用されます。
The ExpiryTime is a field that exists within the signature envelope of a Validation Algorithm. It is the UTC time in milliseconds after which the Content Object is considered expired and MUST no longer be used to respond to an Interest from a cache. Stale content MAY be flushed from the cache.
ExpiryTimeは、検証アルゴリズムの署名エンベロープ内に存在するフィールドです。これは、ミリ秒単位のUTC時間であり、その後、コンテンツオブジェクトは期限切れと見なされ、キャッシュからのインタレストに応答するために使用する必要はなくなります。古いコンテンツはキャッシュからフラッシュされる場合があります。
The Recommended Cache Time (RCT) is a field that exists outside the signature envelope. It is the UTC time in milliseconds after which the publisher considers the Content Object to be of low value to cache. A cache SHOULD discard it after the RCT, though it MAY keep it and still respond with it. A cache MAY also discard the Content Object before the RCT time; there is no contractual obligation to remember anything.
推奨キャッシュ時間（RCT）は、署名エンベロープの外側にあるフィールドです。これは、ミリ秒単位のUTC時間であり、その後、パブリッシャーは、コンテンツオブジェクトがキャッシュする価値が低いと見なします。キャッシュはRCT後に破棄する必要があります（SHOULD）。ただし、RCTは保持し、引き続き応答する場合があります。キャッシュは、RCT時間の前にコンテンツオブジェクトを破棄してもよい（MAY）。何かを覚えておく契約上の義務はありません。
This formulation allows a producer to create a Content Object with a long ExpiryTime but short RCT and keep republishing the same signed Content Object over and over again by extending the RCT. This allows a form of "phone home" where the publisher wants to periodically see that the content is being used.
この定式化により、プロデューサーはExpiryTimeは長くてもRCTが短いコンテンツオブジェクトを作成し、RCTを拡張することにより、同じ署名付きコンテンツオブジェクトを何度も繰り返し公開し続けることができます。これにより、コンテンツが使用されていることをパブリッシャーが定期的に確認したい「フォーンホーム」の形式が可能になります。
CCNx allows an Interest to restrict a response to a specific hash. The hash covers the Content Object message body and the validation sections, if present. Thus, if a Content Object is signed, its hash includes that signature value. The hash does not include the fixed or hop-by-hop headers of a Content Object. Because it is part of the matching rules (see Section 9), the hash is used at every hop.
CCNxでは、インタレストが特定のハッシュへの応答を制限できます。ハッシュは、コンテンツオブジェクトのメッセージ本文と、存在する場合は検証セクションをカバーします。したがって、コンテンツオブジェクトが署名されている場合、そのハッシュにはその署名値が含まれます。ハッシュには、コンテンツオブジェクトの固定ヘッダーまたはホップバイホップヘッダーは含まれません。ハッシュはマッチングルールの一部であるため（セクション9を参照）、ハッシュはすべてのホップで使用されます。
There are two options for matching the Content Object Hash restriction in an Interest. First, a forwarder could compute for itself the hash value and compare it to the restriction. This is an expensive operation. The second option is for a border device to compute the hash once and place the value in a header (ConObjHash) that is carried through the network. The second option, of course, removes any security properties from matching the hash, so it SHOULD only be used within a trusted domain. The header SHOULD be removed when crossing a trust boundary.
インタレストのコンテンツオブジェクトハッシュ制限に一致させるには、2つのオプションがあります。まず、フォワーダーがハッシュ値を計算し、それを制限と比較できます。これは高価な操作です。 2番目のオプションは、境界デバイスがハッシュを1回計算し、その値をヘッダー（ConObjHash）に配置することです。これは、ネットワークを介して伝送されます。もちろん、2番目のオプションは、ハッシュに一致するセキュリティプロパティを削除するため、信頼できるドメイン内でのみ使用する必要があります（SHOULD）。ヘッダーは、信頼境界を越えるときに削除する必要があります（SHOULD）。
A Link is the tuple {Name, [KeyIdRestr], [ContentObjectHashRestr]}. The information in a Link comprises the fields of an Interest that would retrieve the Link target. A Content Object with PayloadType of "Link" is an object whose payload is one or more Links. This tuple may be used as a KeyLink to identify a specific object with the certificate-wrapped key. It is RECOMMENDED to include at least one of either KeyId restriction or Content Object Hash restriction. If neither restriction is present, then any Content Object with a matching name from any publisher could be returned.
リンクはタプル{名前、[KeyIdRestr]、[ContentObjectHashRestr]}です。リンクの情報は、リンクターゲットを取得するインタレストのフィールドで構成されます。 PaylinkTypeが「Link」のコンテンツオブジェクトは、ペイロードが1つ以上のリンクであるオブジェクトです。このタプルは、証明書でラップされたキーを持つ特定のオブジェクトを識別するためのKeyLinkとして使用できます。 KeyId制限またはコンテンツオブジェクトハッシュ制限の少なくとも1つを含めることをお勧めします。どちらの制限も存在しない場合、任意の発行元からの一致する名前を持つ任意のコンテンツオブジェクトが返される可能性があります。
Several protocol fields use cryptographic hash functions, which must be secure against attack and collisions. Because these hash functions change over time, with better ones appearing and old ones falling victim to attacks, it is important that a CCNx protocol implementation supports hash agility.
いくつかのプロトコルフィールドは、暗号ハッシュ関数を使用します。これは、攻撃や衝突に対して安全でなければなりません。これらのハッシュ関数は時間の経過とともに変化するため、より良い関数が現れ、古い関数が攻撃の犠牲になっているため、CCNxプロトコルの実装がハッシュの俊敏性をサポートしていることが重要です。
In this document, we suggest certain hashes (e.g., SHA-256), but a specific implementation may use what it deems best. The normative CCNx Messages [RFC8609] specification should be taken as the definition of acceptable hash functions and uses.
このドキュメントでは、特定のハッシュ（SHA-256など）をお勧めしますが、特定の実装では、それが最良と見なされるものを使用する場合があります。規範的なCCNxメッセージ[RFC8609]仕様は、許容可能なハッシュ関数と使用法の定義として解釈されるべきです。
The Validator consists of a ValidationAlgorithm that specifies how to verify the message and a ValidationPayload containing the validation output, e.g., the digital signature or MAC. The ValidationAlgorithm section defines the type of algorithm to use and includes any necessary additional information. The validation is calculated from the beginning of the CCNx Message through the end of the ValidationAlgorithm section (i.e., up to but not including the validation payload). We refer to this as the validation region. The ValidationPayload is the integrity value bytes, such as a MAC or signature.
Validatorは、メッセージの検証方法を指定するValidationAlgorithmと、デジタル署名やMACなどの検証出力を含むValidationPayloadで構成されます。 ValidationAlgorithmセクションは、使用するアルゴリズムのタイプを定義し、必要な追加情報を含みます。検証は、CCNxメッセージの最初からValidationAlgorithmセクションの終わりまで（つまり、検証ペイロードまで（ただし検証ペイロードを含まない））に計算されます。これを検証領域と呼びます。 ValidationPayloadは、MACや署名などの整合性値のバイトです。
The CCNx Message Grammar (Section 2.1) shows the allowed validation algorithms and their structure. In the case of a Vendor algorithm, the vendor may use any desired structure. A Validator can only be applied to an Interest or a Content Object, not an Interest Return. An Interest inside an Interest Return would still have the original validator, if any.
CCNxメッセージ文法（セクション2.1）は、許可される検証アルゴリズムとその構造を示しています。ベンダーアルゴリズムの場合、ベンダーは任意の構造を使用できます。バリデーターは、インタレストまたはコンテンツオブジェクトにのみ適用でき、インタレストリターンには適用できません。インタレストリターン内のインタレストには、元のバリデータがある場合でも、それが含まれます。
The grammar allows multiple Vendor extensions to the validation algorithm. It is up to the vendor to describe the validation region for each extension. A vendor may, for example, use a regular signature in the validation algorithm, then append a proprietary MIC to allow for in-network error checking without using expensive signature verification. As part of this specification, we do not allow for multiple Validation Algorithm blocks apart from these vendor methods.
文法により、検証アルゴリズムに対する複数のベンダー拡張が可能になります。各拡張機能の検証領域を記述するのはベンダー次第です。たとえば、ベンダーは検証アルゴリズムで通常の署名を使用し、独自のMICを追加して、高価な署名検証を使用せずにネットワーク内のエラーチェックを行うことができます。この仕様の一部として、これらのベンダーメソッド以外の複数の検証アルゴリズムブロックは許可されていません。
If the validation algorithm is CRC32C, then the validation payload is the output of the CRC over the validation region. This validation algorithm allows for an optional signature time (SigTime) to timestamp when the message was validated (calling it a "signature" time is a slight misnomer, but we reuse the same field for this purpose between MICs, MACs, and signatures).
検証アルゴリズムがCRC32Cの場合、検証ペイロードは、検証領域でのCRCの出力です。この検証アルゴリズムでは、オプションの署名時間（SigTime）を使用して、メッセージが検証されたときにタイムスタンプを付けることができます（「署名」時間と呼ぶのは少し間違っていますが、MIC、MAC、および署名の間でこの目的で同じフィールドを再利用します）。
MICs are usually used with an Interest to avoid accidental in-network corruption. They are usually not used on Content Objects because the objects are either signed or linked to by hash chains, so the CRC32C is redundant.
通常、MICはインタレストとともに使用され、偶発的なネットワーク内の破損を回避します。オブジェクトは署名されているか、ハッシュチェーンによってリンクされているため、CRC32Cは冗長であるため、通常、これらはコンテンツオブジェクトでは使用されません。
If the validation algorithm is HMAC-SHA256, then the validation payload is the output of the HMAC over the validation region. The validation algorithm requires a KeyId and allows for a signature time (SigTime) and KeyLink.
検証アルゴリズムがHMAC-SHA256の場合、検証ペイロードは検証領域でのHMACの出力です。検証アルゴリズムはKeyIdを必要とし、署名時間（SigTime）とKeyLinkを可能にします。
The KeyId field identifies the shared secret used between two parties to authenticate messages. These secrets SHOULD be derived from a key exchange protocol such as [ccnx-ke]. The KeyId, for a shared secret, SHOULD be an opaque identifier not derived from the actual key; an integer counter, for example, is a good choice.
KeyIdフィールドは、メッセージを認証するために2つのパーティ間で使用される共有秘密を識別します。これらの秘密は、[ccnx-ke]などの鍵交換プロトコルから派生する必要があります（SHOULD）。 KeyIdは、共有シークレットの場合、実際のキーから派生したものではない不透明な識別子である必要があります（SHOULD）。たとえば、整数カウンタは良い選択です。
The signature time is the timestamp when the authentication code was computed and added to the messages.
署名時刻は、認証コードが計算されてメッセージに追加されたときのタイムスタンプです。
The KeyLink field in a MAC indicates how to negotiate keys and should point towards the key exchange endpoint. The use of a key negotiation algorithm is beyond the scope of this specification, and a key negotiation algorithm is not required to use this field.
MACのKeyLinkフィールドは、キーをネゴシエートする方法を示し、キー交換エンドポイントを指す必要があります。キーネゴシエーションアルゴリズムの使用はこの仕様の範囲外であり、このフィールドを使用するためにキーネゴシエーションアルゴリズムは必要ありません。
Signature-validation algorithms use public key cryptographic algorithms such as RSA and the Elliptic Curve Digital Signature Algorithm (ECDSA). This specification and the corresponding wire encoding [RFC8609] only support three specific signature algorithms: RSA-SHA256, EC-SECP-256K1, and EC-SECP-384R1. Other algorithms may be added in through other documents or by using experimental or vendor-validation algorithm types.
署名検証アルゴリズムは、RSAや楕円曲線デジタル署名アルゴリズム（ECDSA）などの公開鍵暗号アルゴリズムを使用します。この仕様と対応するワイヤエンコーディング[RFC8609]は、RSA-SHA256、EC-SECP-256K1、およびEC-SECP-384R1の3つの特定の署名アルゴリズムのみをサポートしています。他のアルゴリズムは、他のドキュメントを通じて、または実験的またはベンダー検証アルゴリズムタイプを使用して追加できます。
A signature that is public key based requires a KeyId field and may optionally carry a signature time, an embedded public key, an embedded certificate, and a KeyLink. The signature time behaves as normal to timestamp when the signature was created. We describe the use and relationship of the other fields here.
公開鍵ベースの署名にはKeyIdフィールドが必要で、オプションで署名時刻、埋め込み公開鍵、埋め込み証明書、およびKeyLinkを含めることができます。署名時刻は、署名が作成されたときのタイムスタンプと同じように動作します。ここでは、他のフィールドの使用と関係について説明します。
It is not common to use embedded certificates, as they can be very large and may have validity periods different than the validated data. The preferred method is to use a KeyLink to the validating certificate.
埋め込み証明書は非常に大きくなる可能性があり、有効期間が検証済みデータと異なる場合があるため、埋め込み証明書を使用することは一般的ではありません。推奨される方法は、証明書の検証にKeyLinkを使用することです。
The KeyId field in the ValidationAlgorithm identifies the public key used to verify the signature. It is similar to a Subject Key Identifier from X.509 (Section 4.2.1.2 of [RFC5280]). We define the KeyId to be a cryptographic hash of the public key in DER form. All implementations MUST support the SHA-256 digest as the KeyId hash.
ValidationAlgorithmのKeyIdフィールドは、署名の検証に使用される公開鍵を識別します。 X.509のサブジェクトキー識別子に似ています（[RFC5280]のセクション4.2.1.2）。 KeyIdは、DER形式の公開鍵の暗号化ハッシュであると定義します。すべての実装は、KeyIdハッシュとしてSHA-256ダイジェストをサポートする必要があります。
The use of other algorithms for the KeyId is allowed, and it will not cause problems at a forwarder because the forwarder only matches the digest algorithm and digest output and does not compute the digest (see Section 9). It may cause issues with a Content Store, which needs to verify the KeyId and PublicKey match (see Section 2.4.3); though in this case, it only causes a cache miss and the Interest would still be forwarded to the publisher. As long as the publisher and consumers support the hash, data will validate.
KeyIdには他のアルゴリズムの使用が許可されており、フォワーダーはダイジェストアルゴリズムとダイジェスト出力にのみ一致し、ダイジェストを計算しないため（セクション9を参照）、フォワーダーで問題が発生することはありません。 KeyIdとPublicKeyの一致を確認する必要があるコンテンツストアで問題が発生する可能性があります（セクション2.4.3を参照）。ただし、この場合、キャッシュミスが発生するだけで、インタレストはパブリッシャーに転送されます。パブリッシャーとコンシューマーがハッシュをサポートしている限り、データは検証されます。
As per Section 9, a forwarder only matches the KeyId to a KeyId restriction. It does not need to look at the other fields such as the public key, certificate, or KeyLink.
セクション9と同様に、フォワーダーはKeyIdをKeyId制限にのみ一致させます。公開鍵、証明書、KeyLinkなどの他のフィールドを調べる必要はありません。
If a message carries multiples of the KeyId, public key, certificate, or KeyLink, an endpoint (consumer, cache, or Content Store) MUST ensure that any fields it uses are consistent. The KeyId MUST be the corresponding hash of the embedded public key or certificate public key. The hash function to use is the KeyId's HashType. If there is both an embedded public key and a certificate, the public keys MUST be the same.
メッセージがKeyId、公開鍵、証明書、またはKeyLinkの倍数を運ぶ場合、エンドポイント（コンシューマー、キャッシュ、またはコンテンツストア）は、使用するフィールドが一貫していることを確認する必要があります。 KeyIdは、埋め込まれた公開鍵または証明書公開鍵の対応するハッシュでなければなりません。使用するハッシュ関数は、KeyIdのHashTypeです。埋め込み公開鍵と証明書の両方がある場合、公開鍵は同じでなければなりません。
A message SHOULD NOT have both a PublicKey and a KeyLink to a public key, as that is redundant. It MAY have a PublicKey and a KeyLink to a certificate.
メッセージには、PublicKeyと公開鍵へのKeyLinkの両方が冗長であるため、SHOULD NOTにする必要があります。証明書へのPublicKeyとKeyLinkがある場合があります。
A KeyLink in a first Content Object may point to a second Content Object with a DER-encoded public key in the PublicKey field and an optional DER-encoded X.509 certificate in the payload. The second Content Object's KeyId MUST equal the first object's KeyId. The second object's PublicKey field MUST be the public key corresponding to the KeyId. That key must validate both the first and second object's signature. A DER-encoded X.509 certificate may be included in the second object's payload and its embedded public key MUST match the PublicKey. It must be issued by a trusted authority, preferably specifying the valid namespace of the key in the distinguished name. The second object MUST NOT have a KeyLink; we do not allow for recursive key lookup.
最初のコンテンツオブジェクトのKeyLinkは、PublicKeyフィールドにDERエンコードされた公開鍵と、ペイロードにオプションのDERエンコードされたX.509証明書を含む2番目のコンテンツオブジェクトを指す場合があります。 2番目のコンテンツオブジェクトのKeyIdは、最初のオブジェクトのKeyIdと等しい必要があります。 2番目のオブジェクトのPublicKeyフィールドは、KeyIdに対応する公開鍵でなければなりません。そのキーは、最初と2番目のオブジェクトの署名の両方を検証する必要があります。 DERでエンコードされたX.509証明書は、2番目のオブジェクトのペイロードに含めることができ、その埋め込み公開鍵はPublicKeyと一致する必要があります。信頼できる機関が発行する必要があります。できれば、識別名にキーの有効な名前空間を指定してください。 2番目のオブジェクトにはKeyLinkがあってはなりません。再帰的なキー検索はできません。
A Content Object satisfies an Interest if and only if (a) the Content Object name, if present, exactly matches the Interest name, (b) the ValidationAlgorithm KeyId of the Content Object exactly equals the Interest KeyId restriction, if present, and (c) the computed Content Object Hash exactly equals the Interest Content Object Hash restriction, if present.
コンテンツオブジェクトは、（a）コンテンツオブジェクト名（存在する場合）がインタレスト名に完全に一致する場合、（b）コンテンツオブジェクトのValidationAlgorithm KeyIdが存在する場合、インタレストキーID制限に完全に等しい場合、および（c ）計算されたコンテンツオブジェクトハッシュは、存在する場合、インタレストコンテンツオブジェクトハッシュ制限と完全に等しくなります。
The KeyId and KeyIdRestr use the Hash format (see Section 2.1). The Hash format has an embedded HashType followed by the hash value. When comparing a KeyId and KeyIdRestr, one compares both the HashType and the value.
KeyIdおよびKeyIdRestrはハッシュ形式を使用します（セクション2.1を参照）。ハッシュ形式には、HashTypeとそれに続くハッシュ値が埋め込まれています。 KeyIdとKeyIdRestrを比較する場合、HashTypeと値の両方を比較します。
The matching rules are given by this predicate, which, if it evaluates true, means the Content Object matches the Interest. Ni = Name in the Interest (may not be empty), Ki = KeyIdRestr in the Interest (may be empty), and Hi = ContentObjectHashRestr in the Interest (may be empty). Likewise, No, Ko, and Ho are those properties in the Content Object, where No and Ko may be empty; Ho always exists (it is an intrinsic property of the Content Object). For binary relations, we use "&" for AND and "|" for OR. We use "E" for the EXISTS (not empty) operator and "!" for the NOT EXISTS operator.
一致ルールはこの述語によって与えられます。これがtrueと評価された場合、コンテンツオブジェクトがInterestと一致することを意味します。 Ni =インタレストの名前（空ではない場合があります）、Ki =インタレストのKeyIdRestr（空の場合があります）、Hi =インタレストのContentObjectHashRestr（空の場合があります）。同様に、No、Ko、およびHoはコンテンツオブジェクトのプロパティであり、NoおよびKoは空の場合があります。 Hoは常に存在します（コンテンツオブジェクトの固有のプロパティです）。二項関係の場合、ANDおよび "|"には "＆"を使用しますORの場合。 EXISTS（空ではない）演算子には「E」を使用し、「！」を使用します。 NOT EXISTS演算子の場合。
As a special case, if the Content Object Hash restriction in the Interest specifies an unsupported hash algorithm, then no Content Object can match the Interest, so the system should drop the Interest and MAY send an Interest Return to the previous hop. In this case, the predicate below will never get executed because the Interest is never forwarded. If the system is using the optional behavior of having a different system calculate the hash for it, then the system may assume all hash functions are supported and leave it to the other system to accept or reject the Interest.
特別なケースとして、インタレストのコンテンツオブジェクトハッシュ制限がサポートされていないハッシュアルゴリズムを指定している場合、インタレストに一致するコンテンツオブジェクトはないため、システムはインタレストをドロップし、インタレストリターンを前のホップに送信する必要があります。この場合、Interestは転送されないため、以下の述語は実行されません。別のシステムにハッシュを計算させるオプションの動作をシステムが使用している場合、システムはすべてのハッシュ関数がサポートされていると想定し、インタレストを受け入れるか拒否するかを他のシステムに任せる場合があります。
(!No | (Ni=No)) & (!Ki | (Ki=Ko)) & (!Hi | (Hi=Ho)) & (E No | E Hi)
As one can see, there are two types of attributes one can match. The first term depends on the existence of the attribute in the Content Object while the next two terms depend on the existence of the attribute in the Interest. The last term is the "Nameless Object" restriction that states that if a Content Object does not have a Name, then it must match the Interest on at least the Hash restriction.
ご覧のとおり、一致できる属性には2つのタイプがあります。最初の用語はコンテンツオブジェクト内の属性の存在に依存し、次の2つの用語は対象内の属性の存在に依存します。最後の用語は、「名前のないオブジェクト」の制限です。これは、コンテンツオブジェクトに名前がない場合、少なくともハッシュの制限でインタレストと一致する必要があることを示します。
If a Content Object does not carry the Content Object Hash as an expressed field, it must be calculated in network to match against. It is sufficient within an autonomous system to calculate a Content Object Hash at a border router and carry it via trusted means within the autonomous system. If a Content Object ValidationAlgorithm does not have a KeyId, then the Content Object cannot match an Interest with a KeyId restriction.
コンテンツオブジェクトが表現されたフィールドとしてコンテンツオブジェクトハッシュを持たない場合は、一致するようにネットワークで計算する必要があります。自律システム内では、境界ルーターでコンテンツオブジェクトハッシュを計算し、自律システム内の信頼できる手段を介してそれを運ぶだけで十分です。コンテンツオブジェクトのValidationAlgorithmにKeyIdがない場合、コンテンツオブジェクトはKeyId制限のあるインタレストに一致できません。
This section describes the process whereby a network element may return an Interest message to a previous hop if there is an error processing the Interest. The returned Interest may be further processed at the previous hop or returned towards the Interest origin. When a node returns an Interest, it indicates that the previous hop should not expect a response from that node for the Interest, i.e., there is no PIT entry left at the returning node.
このセクションでは、インタレストの処理中にエラーが発生した場合に、ネットワーク要素がインタレストメッセージを前のホップに返すプロセスについて説明します。返されたインタレストは、前のホップでさらに処理されるか、インタレストの起点に向けて返されます。ノードがインタレストを返すとき、それは前のホップがインタレストに対するそのノードからの応答を予期してはならないことを示します。つまり、戻るノードにPITエントリが残っていません。
The returned message maintains compatibility with the existing TLV packet format (a fixed header, optional hop-by-hop headers, and the CCNx Message body). The returned Interest packet is modified in only two ways:
返されるメッセージは、既存のTLVパケット形式（固定ヘッダー、オプションのホップバイホップヘッダー、およびCCNxメッセージ本文）との互換性を維持します。返されたInterestパケットは、次の2つの方法でのみ変更されます。
o The PacketType is set to Interest Return to indicate a Feedback message.
o PacketTypeはInterest Returnに設定され、フィードバックメッセージを示します。
o The ReturnCode is set to the appropriate value to signal the reason for the return.
o ReturnCodeは適切な値に設定され、戻りの理由を示します。
The specific encodings of the Interest Return are specified in [RFC8609].
Interest Returnの特定のエンコーディングは[RFC8609]で指定されています。
A forwarder is not required to send any Interest Return messages.
フォワーダーは、インタレストリターンメッセージを送信する必要はありません。
A forwarder is not required to process any received Interest Return message. If a forwarder does not process Interest Return messages, it SHOULD silently drop them.
フォワーダーは、受信したInterest Returnメッセージを処理する必要はありません。フォワーダーがインタレストリターンメッセージを処理しない場合は、メッセージを表示せずにドロップする必要があります。
The Interest Return message does not apply to a Content Object or any other message type.
Interest Returnメッセージは、コンテンツオブジェクトやその他のメッセージタイプには適用されません。
An Interest Return message is a 1-hop message between peers. It is not propagated multiple hops via the FIB. An intermediate node that receives an Interest Return may take corrective actions or may propagate its own Interest Return to previous hops as indicated in the reverse path of a PIT entry.
Interest Returnメッセージは、ピア間の1ホップメッセージです。 FIBを介して複数のホップに伝播されることはありません。インタレストリターンを受信した中間ノードは、PITエントリの逆のパスに示されているように、修正アクションを実行するか、独自のインタレストリターンを前のホップに伝播する場合があります。
The Interest Return message looks exactly like the original Interest message with the exception of the two modifications mentioned above. The PacketType is set to indicate the message is an Interest Return, and the reserved byte in the Interest header is used as a Return Code. The numeric values for the PacketType and ReturnCodes are in [RFC8609].
Interest Returnメッセージは、上記の2つの変更を除いて、元のInterestメッセージとまったく同じです。 PacketTypeは、メッセージがインタレストリターンであることを示すように設定されており、インタレストヘッダーの予約バイトがリターンコードとして使用されます。 PacketTypeとReturnCodesの数値は[RFC8609]にあります。
This section defines the Interest Return ReturnCode introduced in this RFC. The numeric values used in the packet are defined in [RFC8609].
このセクションでは、このRFCで導入されたInterest Return ReturnCodeを定義します。パケットで使用される数値は、[RFC8609]で定義されています。
+----------------------+--------------------------------------------+
| Name | Description |
+----------------------+--------------------------------------------+
| No Route (Section | The returning forwarder has no route to |
| 10.3.1) | the Interest name. |
| | |
| HopLimit Exceeded | The HopLimit has decremented to 0 and |
| (Section 10.3.2) | needs to forward the packet. |
| | |
| Interest MTU too | The Interest's MTU does not conform to the |
| large (Section | required minimum and would require |
| 10.3.3) | fragmentation. |
| | |
| No Resources | The node does not have the resources to |
| (Section 10.3.4) | process the Interest. |
| | |
| Path error (Section | There was a transmission error when |
| 10.3.5) | forwarding the Interest along a route (a |
| | transient error). |
| | |
| Prohibited (Section | An administrative setting prohibits |
| 10.3.6) | processing this Interest. |
| | |
| Congestion (Section | The Interest was dropped due to congestion |
| 10.3.7) | (a transient error). |
| | |
| Unsupported Content | The Interest was dropped because it |
| Object Hash | requested a Content Object Hash |
| Algorithm (Section | restriction using a hash algorithm that |
| 10.3.8) | cannot be computed. |
| | |
| Malformed Interest | The Interest was dropped because it did |
| (Section 10.3.9) | not correctly parse. |
+----------------------+--------------------------------------------+
Table 3: Interest Return Reason Codes
表3：インタレストリターンの理由コード
This section describes the forwarder behavior for the various Reason codes for Interest Return. A forwarder is not required to generate any of the codes, but if it does, it MUST conform to this specification.
このセクションでは、インタレストリターンのさまざまな理由コードに対するフォワーダーの動作について説明します。フォワーダーはコードを生成する必要はありませんが、生成する場合は、この仕様に準拠する必要があります。
If a forwarder receives an Interest Return, it SHOULD take these standard corrective actions. A forwarder is allowed to ignore Interest Return messages, in which case its PIT entry would go through normal timeout processes.
フォワーダーがインタレストリターンを受け取った場合、フォワーダーはこれらの標準的な是正措置を取る必要があります。フォワーダーはインタレストリターンメッセージを無視できます。その場合、PITエントリは通常のタイムアウトプロセスを通過します。
o Verify that the Interest Return came from a next hop to which it actually sent the Interest.
o Interest Returnが実際にInterestを送信したネクストホップからのものであることを確認します。
o If a PIT entry for the corresponding Interest does not exist, the forwarder should ignore the Interest Return.
o 対応するインタレストのPITエントリが存在しない場合、フォワーダーはインタレストリターンを無視する必要があります。
o If a PIT entry for the corresponding Interest does exist, the forwarder MAY do one of the following:
o 対応するインタレストのPITエントリが存在する場合、フォワーダーは次のいずれかを実行できます（MAY）。
* Try a different forwarding path, if one exists, and discard the Interest Return, or
* 別の転送パスが存在する場合は、それを試し、インタレストリターンを破棄します。
* Clear the PIT state and send an Interest Return along the reverse path.
* PIT状態をクリアし、リバースパスに沿ってインタレストリターンを送信します。
If a forwarder tries alternate routes, it MUST ensure that it does not use the same path multiple times. For example, it could keep track of which next hops it has tried and not reuse them.
フォワーダーが代替ルートを試みる場合、フォワーダーが同じパスを複数回使用しないことを確認する必要があります。たとえば、試行したネクストホップを追跡し、再利用しない場合があります。
If a forwarder tries an alternate route, it may receive a second Interest Return, possibly of a different type than the first Interest Return. For example, node A sends an Interest to node B, which sends a No Route return. Node A then tries node C, which sends a Prohibited Interest Return. Node A should choose what it thinks is the appropriate code to send back to its previous hop.
フォワーダーが別のルートを試行すると、おそらく最初のインタレストリターンとは異なるタイプの2番目のインタレストリターンを受け取る可能性があります。たとえば、ノードAはノードBにインタレストを送信し、ノードBはルートなしの返信を送信します。次に、ノードAはノードCを試行し、禁止されたインタレストリターンを送信します。ノードAは、前のホップに送り返すのに適切なコードであると考えるものを選択する必要があります。
If a forwarder tries an alternate route, it should decrement the Interest Lifetime to account for the time spent thus far processing the Interest.
フォワーダーが代替ルートを試行する場合、これまでインタレストの処理に費やされた時間を考慮して、インタレストライフタイムをデクリメントする必要があります。
If a forwarder receives an Interest for which it has no route, or for which the only route is back towards the system that sent the Interest, the forwarder SHOULD generate a "No Route" Interest Return message.
フォワーダーがルートがないインタレストを受信した場合、またはインタレストを送信したシステムにルートが戻るだけの場合、フォワーダーは「ルートなし」のインタレストリターンメッセージを生成する必要があります（SHOULD）。
How a forwarder manages the FIB table when it receives a No Route message is implementation dependent. In general, receiving a No Route Interest Return should not cause a forwarder to remove a route. The dynamic routing protocol that installed the route should correct the route, or the administrator who created a static route should correct the configuration. A forwarder could suppress using that next hop for some period of time.
フォワーダーがNo Routeメッセージを受信したときにFIBテーブルを管理する方法は、実装に依存します。一般に、ルートなしインタレストリターンを受信しても、フォワーダーがルートを削除することはありません。ルートをインストールした動的ルーティングプロトコルがルートを修正するか、静的ルートを作成した管理者が設定を修正する必要があります。フォワーダーは、そのネクストホップを一定期間使用しないようにすることができます。
A forwarder MAY choose to send HopLimit Exceeded messages when it receives an Interest that must be forwarded off system and the HopLimit is 0.
フォワーダーは、システムから転送する必要があるインタレストを受信し、HopLimitが0の場合に、HopLimit Exceededメッセージを送信することを選択できます（MAY）。
If a forwarder receives an Interest whose MTU exceeds the prescribed minimum, it MAY send an "Interest MTU Too Large" message, or it may silently discard the Interest.
フォワーダーがMTUが所定の最小値を超えるインタレストを受信した場合、「インタレストMTUが大きすぎます」メッセージを送信する場合があります。
If a forwarder receives an "Interest MTU Too Large" response, it SHOULD NOT try alternate paths. It SHOULD propagate the Interest Return to its previous hops.
フォワーダーが "Interest MTU Too Large"応答を受信した場合、代替パスを試すべきではありません。それは以前のホップにインタレストリターンを伝播する必要があります。
If a forwarder receives an Interest and it cannot process the Interest due to lack of resources, it MAY send an Interest Return. A lack of resources could mean the PIT is too large or that there is some other capacity limit.
フォワーダーがインタレストを受け取り、リソース不足のためインタレストを処理できない場合、インタレストリターンを送信できます（MAY）。リソースの不足は、PITが大きすぎるか、他の容量制限があることを意味する場合があります。
If a forwarder detects an error forwarding an Interest, such as over a reliable link, it MAY send a Path-Error Interest Return indicating that it was not able to send or repair a forwarding error.
フォワーダーが、信頼できるリンクなどを介してインタレストの転送エラーを検出した場合、転送エラーを送信または修復できなかったことを示すパスエラーインタレストリターンを送信できます（MAY）。
A forwarder may have administrative policies, such as access control lists (ACLs), that prohibit receiving or forwarding an Interest. If a forwarder discards an Interest due to a policy, it MAY send a Prohibited Interest Return to the previous hop. For example, if there is an ACL that says "/example/private" can only come from interface e0, but the forwarder receives one from e1, the forwarder must have a way to return the Interest with an explanation.
フォワーダーには、アクセス制御リスト（ACL）などの、インタレストの受信または転送を禁止する管理ポリシーがある場合があります。フォワーダーがポリシーのためにインタレストを破棄した場合、フォワーダーは禁止されたインタレストリターンを前のホップに送信できます（MAY）。たとえば、「/ example / private」というACLがあり、インターフェースe0からしか取得できないが、フォワーダーがe1から受信した場合、フォワーダーはインタレストを説明付きで返す方法を持っている必要があります。
If a forwarder discards an Interest due to congestion, it MAY send a Congestion Interest Return to the previous hop.
フォワーダーが輻輳のためにインタレストを破棄する場合、それは前のホップに輻輳インタレストリターンを送信してもよい（MAY）。
If a Content Object Hash restriction specifies a hash algorithm the forwarder cannot verify, the Interest should not be accepted and the forwarder MAY send an Interest Return to the previous hop.
コンテンツオブジェクトハッシュ制限がフォワーダーが確認できないハッシュアルゴリズムを指定している場合、インタレストは受け入れられず、フォワーダーは前のホップにインタレストリターンを送信できます（MAY）。
If a forwarder detects a structural or syntactical error in an Interest, it SHOULD drop the Interest and MAY send an Interest Return to the previous hop. This does not imply that any router must validate the entire structure of an Interest.
フォワーダーがインタレストの構造的エラーまたは構文エラーを検出した場合、インタレストをドロップし、前のホップにインタレストリターンを送信する必要があります（SHOULD）。これは、ルーターがインタレストの構造全体を検証する必要があることを意味するものではありません。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
The CCNx protocol is an L3 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., [esic]).
CCNxプロトコルはL3ネットワークプロトコルであり、UDPや他のトンネルなどの他のトランスポートを使用するオーバーレイとしても動作します。署名（RSAや楕円曲線など）またはメッセージ認証コード（HMACなど）によるメッセージ認証の組み込みサポートが含まれています。オーセンティケーターの代わりに、メッセージの完全性チェック（SHAやCRCなど）を使用する場合があります。 CCNxは暗号化エンベロープを指定しません。その機能は上位層のプロトコル（[esic]など）に任されています。
The CCNx message format includes the ability to attach MICs (e.g., CRC32C), MACs (e.g., HMAC), and signatures (e.g., RSA or ECDSA) to all packet types. This does not mean that it is a good idea to use an arbitrary ValidationAlgorithm, nor to include computationally expensive algorithms in Interest packets, as that could lead to computational DoS attacks. 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（CRC32Cなど）、MAC（HMACなど）、および署名（RSAまたはECDSAなど）をすべてのパケットタイプに添付する機能が含まれています。これは、任意のValidationAlgorithmを使用することや、計算コストの高いアルゴリズムをInterestパケットに含めることは、計算上のDoS攻撃につながる可能性があるため、良い考えではありません。アプリケーションは、明示的なプロトコルを使用して、パケット署名の使用をガイドする必要があります。一般的なガイドラインとして、アプリケーションはインタレストでMICを使用して、意図せず破損したパケットを検出する場合があります。インタレストを保護したい場合、特にインタレストがアクチュエータとして使用されている場合は、暗号化されたラッパーとリプレイ攻撃を防ぐプロトコルの使用を検討する必要があります。認証コードまたは署名を使用するだけでは、インタレストは安全ではありません。文献には、ICNスタイルのメッセージング[モバイル] [エース]を保護する方法に関するいくつかの例があります。
As an L3 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 or certificate embedded in the object or may use the KeyLink field to point to a public key or certificate that authenticates the message. One key-exchange specification is CCNxKE [ccnx-ke] [mobile], which is similar to the TLS 1.3 key exchange except it is over the CCNx L3 messages. Trust is beyond the scope of an L3 protocol and left to applications or application frameworks.
このドキュメントでは、L3プロトコルとして、キーに到達する方法やキーを信頼する方法については説明していません。 CCNxコンテンツオブジェクトには、オブジェクトに埋め込まれた公開鍵または証明書を含めるか、KeyLinkフィールドを使用して、メッセージを認証する公開鍵または証明書を指すことができます。鍵交換の仕様の1つはCCNxKE [ccnx-ke] [モバイル]です。これは、CCNx L3メッセージを介する点を除いて、TLS 1.3鍵交換に似ています。信頼はL3プロトコルの範囲を超えており、アプリケーションまたはアプリケーションフレームワークに任されています。
The combination of an ephemeral key exchange (e.g., CCNxKE [ccnx-ke]) 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 [ccnx-ke]など）とカプセル化暗号化（[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. [RFC8609] 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 a fixed-length "T" and "L" field solves two problems. The first is aliases. If one is able to encode the same value, such as %x02 and %x0002, 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's and 7 L's, 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.
メッセージの特定のエンコーディングは、セキュリティに影響します。 [RFC8609]はtype-length-value（TLV）エンコーディングを使用します。私たちは、拡張性と、型と長さの明確なエンコーディングとの間の妥協を選択しました。一部のTLVエンコーディングは、可変長の「T」および可変長の「L」フィールドを使用して、バイトの効率を高めながら、さまざまな値に対応します。 TLVエンコーディングでは、固定長の2バイトの「T」と2バイトの「L」を使用します。固定長の「T」および「L」フィールドを使用すると、2つの問題が解決します。 1つ目はエイリアスです。 ％x02と％x0002などの同じ値を異なるバイト長でエンコードできる場合、それらが同じことを意味するのか、異なるのか、または違法なのかを判断する必要があります。それらが異なる場合は、同等の整数ではなく、常にバッファーで比較する必要があります。 1つが違法である場合、すべてのホップのすべてのパケットのすべてのフィールドである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メッセージには、前のホップからのオーセンティケーターがありません。したがって、インタレストリターンのペイロードは、インタレストを照合するためにローカルでのみ使用する必要があります。ノードはそのインタレストペイロードをインタレストとして転送しないでください。また、インタレストリターンのインタレストをそのノードに送信したことを確認し、誰もインタレストメッセージを否定できないようにする必要があります。
Caching nodes must take caution when processing Content Objects. It is essential that the Content Store obey the rules outlined in Section 2.4.3 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 (often used for initial manifest discovery), the requester only knows the KeyId that signed the content. It is this case that 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.
キャッシュノードは、コンテンツオブジェクトを処理するときに注意する必要があります。特定の種類の攻撃を回避するには、コンテンツストアがセクション2.4.3で概説されているルールに従うことが不可欠です。 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 or certificate according to the KeyLink. That is not, however, 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.
ユーザーレベルのキャッシュは、KeyLinkに従って公開鍵または証明書をフェッチすることにより、完全な署名検証を実行できます。ただし、それはフォワーダーに課したい負担ではありません。ユーザーレベルのキャッシュは、キャッシュオペレーターが正しい署名を持っていることがわかっているコンテンツのみを挿入するなど、帯域外の認証に依存する場合もあります。
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; it could cause backward compatibility problems if the hash type is updated. [RFC8609] is the authoritative source for per-field-allowed hash types in that encoding.
CCNx文法は、HashTypeを介してハッシュアルゴリズムの俊敏性を可能にします。各フォワーダーに実装する必要のある許容可能なハッシュアルゴリズムの短いリストを指定します。一部のハッシュ値はエンドシステムにのみ適用されるため、ハッシュアルゴリズムを更新してもフォワーダーには影響しません。それらは単純にtype-length-hashバッファーを含むバッファーと一致します。 ConObjHashなどの一部のフィールドは各ホップで検証する必要があるため、フォワーダー（または関連システム）はハッシュアルゴリズムを知っている必要があります。ハッシュタイプが更新されると、下位互換性の問題が発生する可能性があります。 [RFC8609]は、そのエンコーディングでフィールドごとに許可されたハッシュタイプの信頼できるソースです。
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 to 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名は、CCNx名に対して一貫したURI正規化を使用しない限り、大文字または非ASCII記号の不一致が発生する可能性があることを意味します。また、CCNxのルーティング可能なプレフィックスを登録するエンティティ（「ccnx：/example.com」など）は、「ccnx：/Example.com」のような単純なバリエーションの場合、個別の登録が必要になることも意味します。これがURIの正規化とルーティングプロトコルの規則で扱われていない限り、フィッシング攻撃が行われる可能性があります。
For a more general introduction to ICN-related security concerns and approaches, see [RFC7927] and [RFC7945].
ICN関連のセキュリティ問題とアプローチのより一般的な概要については、[RFC7927]および[RFC7945]を参照してください。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[ace] Shang, W., Yu, Y., Liang, T., Zhang, B., and L. Zhang, "NDN-ACE: Access Control for Constrained Environments over Named Data Networking", NDN Technical Report NDN-0036, December 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.、and L. Zhang、 "NDN-ACE：Access Control for Constrained Environments over Named Data Networking"、NDN Technical Report NDN-0036 、2015年12月、<http://new.named-data.net/ wp-content / uploads / 2015/12 / ndn-0036-1-ndn-ace.pdf>。
[befrags] Mosko, M. and C. Tschudin, "ICN "Begin-End" Hop by Hop Fragmentation", Work in Progress, draft-mosko-icnrg-beginendfragment-02, December 2016.
[befrags] Mosko、M.、C。Tschudin、「ICN "Begin-End" Hop by Hop Fragmentation "、Work in Progress、draft-mosko-icnrg-beginendfragment-02、2016年12月。
[ccn-lite] Tschudin, C., et al., "CCN-lite", University of Basel, 2011-2019, <http://ccn-lite.net>.
[ccn-lite] Tschudin、C.他、「CCN-lite」、バーゼル大学、2011-2019、<http://ccn-lite.net>。
[ccnx-ke] Mosko, M., Uzun, E., and C. Wood, "CCNx Key Exchange Protocol Version 1.0", Work in Progress, draft-wood-icnrg-ccnxkeyexchange-02, March 2017.
[ccnx-ke] Mosko、M.、Uzun、E。、およびC. Wood、「CCNx Key Exchange Protocol Version 1.0」、Work in Progress、draft-wood-icnrg-ccnxkeyexchange-02、2017年3月。
[ccnx-registry] IANA, "Content-Centric Networking (CCNx)", <https://www.iana.org/assignments/ccnx>.
[ccnx-registry] IANA、「Content-Centric Networking（CCNx）」、<https://www.iana.org/assignments/ccnx>。
[ccnx-uri] Mosko, M. and C. Wood, "The CCNx URI Scheme", Work in Progress, draft-mosko-icnrg-ccnxurischeme-01, April 2016.
[ccnx-uri] Mosko、M。、およびC. Wood、「The CCNx URI Scheme」、Work in Progress、draft-mosko-icnrg-ccnxurischeme-01、2016年4月。
[chunking] Mosko, M., "CCNx Content Object Chunking", Work in Progress, draft-mosko-icnrg-ccnxchunking-02, June 2016.
[chunking] Mosko、M。、「CCNx Content Object Chunking」、Work in Progress、draft-mosko-icnrg-ccnxchunking-02、2016年6月。
[cicn] FD.io, "Community ICN (CICN)", February 2017, <https://wiki.fd.io/index.php?title=Cicn&oldid=7191>.
[cicn] FD.io、「Community ICN（CICN）」、2017年2月、<https://wiki.fd.io/index.php?title=Cicn&oldid=7191>。
[dart] Garcia-Luna-Aceves, J. and M. Mirzazad-Barijough, "A Light-Weight Forwarding Plane for Content-Centric Networks", International Conference on Computing, Networking, and Communications (ICNC), DOI 10.1109/ICCNC.2016.7440637, February 2016, <https://arxiv.org/pdf/1603.06044.pdf>.
[dart] Garcia-Luna-Aceves、J。およびM. Mirzazad-Barijough、「コンテンツ中心のネットワークのための軽量転送プレーン」、コンピューティング、ネットワーキング、および通信に関する国際会議（ICNC）、DOI 10.1109 / ICCNC。 2016.7440637、2016年2月、<https://arxiv.org/pdf/1603.06044.pdf>。
[eprise-numbers] IANA, "IANA Private Enterprise Numbers", <https://www.iana.org/assignments/enterprise-numbers>.
[eprise-numbers] IANA、「IANA Private Enterprise Numbers」、<https://www.iana.org/assignments/enterprise-numbers>。
[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月。
[flic] Tschudin, C. and C. Wood, "File-Like ICN Collection (FLIC)", Work in Progress, draft-tschudin-icnrg-flic-03, March 2017.
[flic] Tschudin、C。およびC. Wood、「File-Like ICN Collection（FLIC）」、Work in Progress、draft-tschudin-icnrg-flic-03、2017年3月。
[mobile] Mosko, M., Uzun, E., and C. Wood, "Mobile Sessions in Content-Centric Networks", IFIP Networking Conference (IFIP Networking) and Workshops, DOI 10.23919/IFIPNetworking.2017.8264861, June 2017, <https://dl.ifip.org/db/conf/networking/ networking2017/1570334964.pdf>.
[モバイル] Mosko、M.、Uzun、E。、およびC. Wood、「コンテンツ中心のネットワークにおけるモバイルセッション」、IFIPネットワーキング会議（IFIPネットワーキング）およびワークショップ、DOI 10.23919 / IFIPNetworking.2017.8264861、2017年6月、<https ：//dl.ifip.org/db/conf/networking/ networking2017 / 1570334964.pdf>。
[ndn] UCLA, "Named Data Networking", 2019, <https://www.named-data.net>.
[ndn] UCLA、「Named Data Networking」、2019、<https://www.named-data.net>。
[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, DOI 10.1145/1658939.1658941, December 2009, <https://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 on the 5th International Conference on Emerging Networking Experiments and Technologies、DOI 10.1145 / 1658939.1658941、2009年12月、<https://dx.doi.org/10.1145/1658939.1658941>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<https://www.rfc-editor.org/info/rfc5234>。
[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.、and G. Boggia、 "Information-Centric Networking：Evaluation and Security Considerations"、RFC 7945、DOI 10.17487 / RFC7945 、2016年9月、<https://www.rfc-editor.org/info/rfc7945>。
[RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric Networking (CCNx) Messages in TLV Format", RFC 8609, DOI 10.17487/RFC8609, July 2019, <https://www.rfc-editor.org/info/rfc8609>.
[RFC8609] Mosko、M.、Solis、I。、およびC. Wood、「TLV形式のContent-Centric Networking（CCNx）メッセージ」、RFC 8609、DOI 10.17487 / RFC8609、2019年7月、<https：// www。 rfc-editor.org/info/rfc8609>。
[selectors] Mosko, M., "CCNx Selector Based Discovery", Work in Progress, draft-mosko-icnrg-selectors-01, May 2019.
[selectors] Mosko、M。、「CCNx Selector Based Discovery」、作業中、draft-mosko-icnrg-selectors-01、2019年5月。
[terminology] Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran, D., and C. Tschudin, "Information-Centric Networking (ICN): CCN and NDN Terminology", Work in Progress, draft-irtf-icnrg-terminology-04, June 2019.
[用語] Wissingh、B.、Wood、C.、Afanasyev、A.、Zhang、L.、Oran、D。、およびC. Tschudin、「情報中心のネットワーキング（ICN）：CCNおよびNDNの用語」、作業進捗状況、draft-irtf-icnrg-terminology-04、2019年6月。
[trust] Tschudin, C., Uzun, E., and C. Wood, "Trust in Information-Centric Networking: From Theory to Practice", 25th International Conference on Computer Communication and Networks (ICCCN), DOI 10.1109/ICCCN.2016.7568589, August 2016, <https://doi.org/10.1109/ICCCN.2016.7568589>.
[信頼] Tschudin、C.、Uzun、E。、およびC. Wood、「情報中心のネットワーキングにおける信頼：理論から実践へ」、第25回コンピュータ通信およびネットワークに関する国際会議（ICCCN）、DOI 10.1109 / ICCCN.2016.7568589 、2016年8月、<https://doi.org/10.1109/ICCCN.2016.7568589>。
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: marc.mosko@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