原文

[要約] RFC 8569は、CCNxネットワークの意味論と動作を定義し、Interest、Content Object、Interest Returnの各メッセージ、名前、転送、キャッシュ、照合の規則を説明します。仕様は特定のワイヤ符号化に依存せず、CCNxメッセージのTLV符号化を定めるRFC 8609を補完します。IRTFのICNRGが策定した実験的プロトコルです。

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）アーキテクチャのコアコンセプトについて説明し、InterestとContent Objectの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メッセージを返すことができます。これは、現在のシステムが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.

この文書はインターネット標準化過程の仕様ではなく、検討、実験的な実装および評価を目的として公開されています。

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のInformation-Centric Networking Research Groupの合意を表します。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.  はじめに .......................................................4
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   5
     1.1.  要件言語 ...................................................5
     1.2.  Architecture  . . . . . . . . . . . . . . . . . . . . . .   5
     1.2.  アーキテクチャ .............................................5
     1.3.  Protocol Overview . . . . . . . . . . . . . . . . . . . .   6
     1.3.  プロトコルの概要 ...........................................6
   2.  Protocol  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   2.  プロトコル ....................................................10
     2.1.  Message Grammar . . . . . . . . . . . . . . . . . . . . .  10
     2.1.  メッセージ文法 ............................................10
     2.2.  Consumer Behavior . . . . . . . . . . . . . . . . . . . .  14
     2.2.  コンシューマーー行動 ......................................14
     2.3.  Publisher Behavior  . . . . . . . . . . . . . . . . . . .  15
     2.3.  パブリッシャーの行動 ......................................15
     2.4.  Forwarder Behavior  . . . . . . . . . . . . . . . . . . .  16
     2.4.  フォワーダーの動作 ........................................16
       2.4.1.  Interest HopLimit . . . . . . . . . . . . . . . . . .  16
       2.4.1.  Interestホップリミット ................................16
       2.4.2.  Interest Aggregation  . . . . . . . . . . . . . . . .  17
       2.4.2.  Interestアグリゲーション ..............................17
       2.4.3.  Content Store Behavior  . . . . . . . . . . . . . . .  19
       2.4.3.  Content Storeの動作 ...................................19
       2.4.4.  Interest Pipeline . . . . . . . . . . . . . . . . . .  19
       2.4.4.  Interestパイプライン ..................................19
       2.4.5.  Content Object Pipeline . . . . . . . . . . . . . . .  20
       2.4.5.  Content Objectパイプライン ............................20
   3.  Names . . . . . . . . . . . . . . . . . . . . . . . . . . . .  21
   3.  名前 ..........................................................21
     3.1.  Name Examples . . . . . . . . . . . . . . . . . . . . . .  23
     3.1.  名前の例 ..................................................23
     3.2.  Interest Payload ID . . . . . . . . . . . . . . . . . . .  23
     3.2.  Interest Payload ID .......................................23
   4.  Cache Control . . . . . . . . . . . . . . . . . . . . . . . .  23
   4.  キャッシュ制御 ................................................23
   5.  Content Object Hash . . . . . . . . . . . . . . . . . . . . .  24
   5.  Content Objectハッシュ ........................................24
   6.  Link  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  24
   6.  リンク ........................................................24
   7.  Hashes  . . . . . . . . . . . . . . . . . . . . . . . . . . .  25
   7.  ハッシュ ......................................................25
   8.  Validation  . . . . . . . . . . . . . . . . . . . . . . . . .  25
   8.  検証 ..........................................................25
     8.1.  Validation Algorithm  . . . . . . . . . . . . . . . . . .  25
     8.1.  検証アルゴリズム ..........................................25
     8.2.  Message Integrity Codes . . . . . . . . . . . . . . . . .  26
     8.2.  メッセージ整合性コード ....................................26
     8.3.  Message Authentication Codes  . . . . . . . . . . . . . .  26
     8.3.  メッセージ認証コード ......................................26
     8.4.  Signature . . . . . . . . . . . . . . . . . . . . . . . .  26
     8.4.  署名 ......................................................26
   9.  Interest to Content Object Matching . . . . . . . . . . . . .  28
   9.  InterestとContent Objectの照合 ................................28
   10. Interest Return . . . . . . . . . . . . . . . . . . . . . . .  29
   10. Interest Return ...............................................29
     10.1.  Message Format . . . . . . . . . . . . . . . . . . . . .  30
     10.1.  メッセージフォーマット ...................................30
     10.2.  ReturnCode Types . . . . . . . . . . . . . . . . . . . .  31
     10.2.  ReturnCodeタイプ .........................................31
     10.3.  Interest Return Protocol . . . . . . . . . . . . . . . .  32
     10.3.  Interest Returnプロトコル ................................32
       10.3.1.  No Route . . . . . . . . . . . . . . . . . . . . . .  32
       10.3.1.  ルートなし ...........................................32
       10.3.2.  HopLimit Exceeded  . . . . . . . . . . . . . . . . .  33
       10.3.2.  HopLimit Exceeded ....................................33
       10.3.3.  Interest MTU Too Large . . . . . . . . . . . . . . .  33
       10.3.3.  Interest MTUの過大 ...................................33
       10.3.4.  No Resources . . . . . . . . . . . . . . . . . . . .  33
       10.3.4.  リソースなし .........................................33
       10.3.5.  Path Error . . . . . . . . . . . . . . . . . . . . .  33
       10.3.5.  パスエラー ...........................................33
       10.3.6.  Prohibited . . . . . . . . . . . . . . . . . . . . .  33
       10.3.6.  禁止 .................................................33
       10.3.7.  Congestion . . . . . . . . . . . . . . . . . . . . .  34
       10.3.7.  輻輳 .................................................34
       10.3.8.  Unsupported Content Object Hash Algorithm  . . . . .  34
       10.3.8.  サポートされていないContent Objectハッシュアルゴリズム ..34
       10.3.9.  Malformed Interest . . . . . . . . . . . . . . . . .  34
       10.3.9.  不正なInterest .......................................34
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  34
   11. IANAに関する考慮事項 ..........................................34
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  34
   12. セキュリティに関する考慮事項 ..................................34
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  37
   13. 参考文献 ......................................................37
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  37
     13.1.  引用文献 .................................................37
     13.2.  Informative References . . . . . . . . . . . . . . . . .  37
     13.2.  Informative References ...................................37
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  40
   著者のアドレス ....................................................40
1. Introduction
1. はじめに

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アーキテクチャの原則を説明します。階層名を使って要求を転送し、その要求に対する応答を照合するネットワークプロトコルを定義します。Internet Protocolのようなエンドポイントアドレスは使いません。要求に指定する制約によって、応答の署名者の公開鍵または応答の暗号学的ハッシュ値に基づき、応答を限定できます。経路上の各CCNxフォワーダーが名前の照合と制約の確認を行います。CCNxは情報中心ネットワーキング（ICN）プロトコルの広い枠組みに属します [RFC7927]。この文書はプロトコルの意味論を扱い、特定のワイヤ形式には依存しません。CCNx Messages [RFC8609]は、type-length-value（TLV）形式のワイヤプロトコル符号化を定義します。このセクションでは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]です。もう1つはCCN-lite [ccn-lite]で、Internet of Things（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では、Interest名は応答名の階層的なプレフィックスである場合があり、これにより、レイヤー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.

この文書は、Information-Centric Networking Research Group（ICNRG）の合意を表します。同グループ初のICNプロトコルであり、初期のCCNxプロトコル [nnc] を基に、ICNコミュニティと同グループの参加者からの意見を反映して大幅に改訂されました。ICNコミュニティと同グループの複数の参加者が内容を精査しています。著者と同グループの議長は内容を承認しています。この文書はIRTFの下で発行され、IETFが発行した文書でもIETF標準でもありません。実験的プロトコルであり、特定の用途への展開に適さない場合があります。仕様は将来変更される可能性があります。

1.1. Requirements Language
1.1. 要件言語

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] で説明されているように、すべて大文字で表示される場合にのみ解釈されるものとします。

1.2. Architecture
1.2. アーキテクチャ

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が動作するネットワークのアーキテクチャを説明し、[terminology] の用語を紹介します。各構成要素の動作とメッセージ文法の詳細はセクション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ネットワークで転送するためにコンテンツをContent Objectにカプセル化するエンドポイントです。プロデューサーは、公開/秘密キーペアを持ち、Content Objectに（直接的または間接的に）署名します。通常、プロデューサーの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上に構築される上位層プロトコルがその役割を担います。コンシューマーはInterestと呼ばれる要求を作成し、自身のFIBを介して転送します。通常は、Interestに一致する応答（Content Object）か、ネットワークが要求を処理できないことを示す制御メッセージ（Interest Return）を受け取ります。

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.

Interest処理でエラーを検出する方法は3つあります。 Interest Returnは、「ルートなし」や「リソース不足」などの低レベルのエラーを示すネットワーク制御メッセージです。Interestがプロデューサに到着したが、プロデューサが要求されたコンテンツを持っていない場合、プロデューサはアプリケーション固有のエラーメッセージ（たとえば、「見つかりません」メッセージ）を送信する必要があります。最後に、コンシューマーーは何も受け取りません。その場合はタイムアウトし、アプリケーションに応じて、要求を再試行するか、アプリケーションにエラーを返します。

1.3. Protocol Overview
1.3. プロトコルの概要

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名は、人間の可読性や文字エンコードに関する要件なしに、意図的に一般的なオクテットエンコードタイプおよび値として残されます。これは、フォワーダーが名前を処理する方法にInterestがあるためです。アプリケーション、ルーティングプロトコル、またはその他の上位層が、許可された名前セグメントタイプと名前セグメント値に独自の規則と制限を適用することを期待しています。

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（署名など）の対象です。利用側は同じ暗号学的ハッシュ値を再計算し、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 Check（CRC）など）もサポートします。暗号学的な結び付きを保つには、少なくとも1つのオブジェクトに署名または認証コードを付けますが、すべてのオブジェクトに付ける必要はありません。たとえば、署名付きの最初のオブジェクトから、ハッシュチェーン、Merkle tree、または署名付きマニフェストを使って他のオブジェクトを参照できます。後続のオブジェクトには検証情報を付けず、参照だけに依存する場合があります。完全性コード（CRCなど）は、Interestの偶発的な破損を検出するために使います。

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は、名前付きペイロードを転送するため、Interest（要求メッセージ）とContent Object（応答メッセージ）を中心とするネットワークプロトコルを定義します。Interestには、望む応答を識別するNameフィールドと、任意の照合制約が含まれます。制約は一致しうるContent Objectを限定します。制約はKey ID制約（KeyIdRestr）とContent Object Hash制約（ContentObjectHashRestr）の2つです。前者は、ValidationAlgorithmのKeyIdフィールドが制約値と一致する署名付き応答に限定します。後者は、名前付きペイロード全体の暗号学的ハッシュ値が制約値と一致する応答に限定します。これらの制約によるContent ObjectとInterestの照合方法はセクション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名の階層は、フォワーダーでの最長一致プレフィックスに基づくルーティングに使われます。階層名の最長一致プレフィックスは、名前セグメント単位で計算します。照合時には各セグメントが完全に一致する必要があります。プレフィックスをグローバルにルーティング可能にする必要はありません。1つのフラットな（非階層の）名前セグメントだけを使う場合も含め、配備環境内では任意のローカルルーティングを使えます。

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では、InterestメッセージとContent Objectメッセージの流量が釣り合うように設計されています。ネットワーク上の単一経路を通るInterestには、Content Objectを1つだけ返すのが基本です。ノードがInterestを複数経路に送る場合は、応答を集約し、要求元へ戻るContent Objectを1つにすることが望まれます。マルチアクセス媒体でInterestをブロードキャストまたはマルチキャストする場合は、ゴシップ抑制やリーダー選出など媒体に応じた仕組みがなければ、送信側は複数の応答を想定します。

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.

InterestはFIBに沿って転送される過程で各フォワーダーに状態を作ります。その状態により、要求元がルーティング可能な返信先アドレスを指定しなくても、Content Objectの応答が元の要求元（複数の場合を含む）まで戻れます。Content Objectの返送に必要な状態を保持する概念上のテーブルとして、Pending Interest Table（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 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には、Interestの直前のホップ、Nameフィールド、および任意の制約を保存します。これらはContent ObjectとInterestを照合するために必要な情報です（セクション9を参照）。Content Objectが到着すると、どのPITエントリを満たすかを判定するために照合します。該当する各エントリについて、PITエントリに記録された各直前ホップへContent Objectを最大1つずつ送信します。

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]}タプルを持つ複数のInterestが、最初のInterestに一致するContent Objectの到着前にノードへ届くと、それらは同じPITエントリにまとめられ、直前のホップが集約されます（セクション2.4.2を参照）。したがって、1つのContent ObjectがPIT内の複数の保留中Interestを満たすことがあります。

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.

この文書では、Interest Returnと呼ばれる制御メッセージも説明します。Interestの処理中にエラーが発生した場合、ネットワーク要素はInterestを直前のホップへ返すことがあります。返されたInterestは、そのホップでさらに処理するか、Interestの起点に向けて返すことができます。ノードがInterestを返すと、直前のホップはそのノードからの応答を期待できません。つまり、返送元ノードには、その後Content Objectを返すための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でより大きなオブジェクトを記述する方法は複数あります。 L3Content Objectをより大きなオブジェクトに集約することは、このドキュメントの範囲外です。提案されている方法の1つであるファイルライクICNコレクション（FLIC）[flic]は、マニフェストを使用して、より大きなオブジェクトの断片を列挙します。マニフェストは、それ自体がContent Objectです。もう1つのオプションは、CCNx Chunking [chunking]プロトコルのように、Content Object名に規則を使用することです。この場合、大きなオブジェクトは小さなチャンクに分割され、各チャンクはそのシリアル順序を示す特別な名前コンポーネントを受け取ります。

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.

これらの概念により、ドキュメントの残りの部分では、Interest、Content Object、およびInterest Returnメッセージの処理におけるフォワーダーの動作を指定します。

2. Protocol
2. プロトコル

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メッセージ（Interest、Content Object、またはInterest Return）の文法を定義します。次に、コンシューマーー、パブリッシャー、およびフォワーダーの典型的な動作を示します。フォワーダーセクションでは、HopLimitやContent Storeなどのフォワーダー固有のトピックを処理する方法と、InterestメッセージおよびContent Objectメッセージの詳細な処理パイプラインについて詳しく説明しています。

2.1. Message Grammar
2.1. メッセージ文法

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」レジストリ [eprise-numbers] に登録されたIANA値に対応させます。

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：パブリッシャーがContent Objectをキャッシュする価値が低いと判断するまでの絶対時間。これはキャッシュの推奨事項です（セクション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：これらは、Content Objectに表示されるオプションのフィールドです。

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：Content Object Hashの値です。メッセージ本文の先頭からメッセージ末尾までを対象とするSHA256-32です。この対象範囲はValidationAlgの範囲とは異なります。この値は信頼境界を越えて信頼すべきではありません (SHOULD NOT)（セクション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：Content Object Hashの制約です。Content Objectは、同じHashTypeを使って制約値と同じハッシュ値になる必要があります。ContentObjectHashRestrにはSHA256-32を使わなければなりません (MUST)。

ExpiryTime: An absolute time after which the Content Object should be considered expired (see Section 4).

ExpiryTime：Content Objectが期限切れと見なされるまでの絶対時間（セクション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：転送プレーンにループがある場合、Interestメッセージがループすることがあります。最終的にループを終了するために、各Interestは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制限。Content Objectには、制限と同じ値の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.

Lifetime：要求元が応答を待つ時間の概算値で、通常は秒単位です。ネットワークの往復時間とは強く関係しませんが、往復時間より長く設定する必要があります。

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.

Name：名前は、空でない最初のセグメントと、それに続く0個以上の追加セグメントで構成されます。追加セグメントの長さは0でもかまいません。名前セグメントは不透明なオクテット列であり、UTF-8で符号化する場合は大文字と小文字を区別します。InterestにはNameを指定しなければなりません (MUST)。Content ObjectにはNameを指定してもかまいません (MAY)（セクション9を参照）。名前の各セグメントが単一のContent Objectを一意に識別する場合、その名前は完全です。完全なセグメントを持つ名前を完全一致名と呼びます。完全名を持つInterestは、完全一致名と、対応するContent ObjectのContent Object Hash制約を指定します。

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：署名の検証に使う公開鍵をメッセージ内に埋め込むアプリケーションもあります。PublicKeyは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文法

2.2. Consumer Behavior
2.2. コンシューマーー行動

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, [KeyIdRestr], [ContentObjectHashRestr]}タプルのコンテンツを要求するには、コンシューマーはそれらの値を持つInterestメッセージを作成します。検証セクション（通常はCRC32Cのみ）を追加してもかまいません (MAY)。ペイロードに含まれる情報を名前以外にパブリッシャーへ送るため、InterestにPayloadフィールドを含めてもかまいません (MAY)。名前はルーティングに使われ、Content Objectの返送を容易にするため概念上のPITで各ホップに記憶される場合があります。名前に大量の状態を詰めると、必要なメモリーが増える可能性があります。Interestの転送やInterestとContent Objectの照合ではPayloadを考慮しないため、異なるPayloadを持つInterestが集約されないよう、コンシューマーはInterest Payload ID（セクション3.2を参照）を名前の一部に含めるべきです (SHOULD)。同様に、MACまたは署名を使う場合は、他のInterestとの集約や検証に無関係なContent Objectによる応答を防ぐため、名前の一部に一意なセグメントを含めるべきです (SHOULD)。

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)。コンシューマーーがルーティングを介してプロデューサーまでの距離を知っている場合は、その値を使用すべきです（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).

コンシューマーはInterestを最初のフォワーダに渡し、次にInterestをネットワーク経由でパブリッシャ（またはレプリカ）に転送します。パブリッシャ（またはレプリカ）は、名前に基づいてそれを満たします（セクション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.

Interestメッセージ自体には信頼性のある配送機能がありません。応答がない場合に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.

ネットワークは、Interestを処理できないことを示すInterest Returnメッセージをコンシューマーへ送信してもかまいません (MAY)。ReturnCodeは、経路がない、輻輳しているなどの失敗理由を示します。ReturnCodeに応じて、コンシューマーはInterestを再試行してもかまいません (MAY)。または、要求元アプリケーションへエラーを返してもかまいません (MAY)。

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:

最初のフォワーダーがコンテンツを見つけて返した場合、コンシューマーーはContent Objectを受け取ります。コンシューマーは、次の一連のチェックを使用して、受信したContent Objectを検証します。

o The consumer MUST ensure the Content Object is properly formatted.

o コンシューマーは、Content Objectが適切にフォーマットされていることを確認しなければなりません (MUST)。

o The consumer MUST verify that the returned Content Object matches one or more pending Interests as per Section 9.

o コンシューマーーは、返されたContent Objectがセクション9の1つ以上の保留中のInterestと一致することを確認しなければなりません (MUST)。

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 Content Objectが署名されている場合、コンシューマーーはセクション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が含まれている場合、コンシューマーは署名の有効性を判断する際に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 Content Objectが署名されている場合、コンシューマーは名前空間に対する署名鍵の信頼性をアサートすべきです (SHOULD)。このようなアサーションはこのドキュメントの範囲外ですが、従来のPKIメソッド、信頼できるキー解決サービス、または[trust]などのメソッドを使用する場合があります。

o The consumer MAY cache the Content Object for future use, up to the ExpiryTime if present.

o コンシューマーは、存在する場合はExpiryTimeまで、将来の使用のためにContent Objectをキャッシュできます（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 コンシューマーは、転送中に期限切れとなったContent Objectを受け入れてもかまいません (MAY)。パケット内のContent Objectは転送中に期限切れになる場合があります。転送中の期限切れパケットをフォワーダーが破棄する義務はありません。Content Store、キャッシュ、またはプロデューサーは、期限切れのContent Objectを応答に使ってはなりません (MUST NOT)。

2.3. Publisher Behavior
2.3. パブリッシャーの行動

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:

パブリッシャーがInterestを受信したときは、次の処理を行うべきです (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 InterestにValidationセクションがある場合は、セクション8に従って検証します。パブリッシャーアプリケーションが他の検証方式に明示的に対応していない限り、Interestに含まれるのは通常CRC32Cだけです。計算資源を消費するサービス拒否攻撃になりうるため、想定していない署名を含むValidationセクション付きInterestを破棄してもかまいません (MAY)。署名の検証に必要な鍵をパブリッシャーが持っていない場合、アプリケーションの想定動作に含まれない限り、ネットワーク経由で鍵を取得することは推奨されません (SHOULD NOT)。

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 要求されたContent Objectを取得または生成し、Interestの直前のホップへ返します。要求されたコンテンツを返せない場合は、Interest Return、またはコンテンツが利用できないことを示すアプリケーションペイロード付きContent Objectで応答すべきです (SHOULD)。後者のContent Objectは、短い将来のExpiryTimeを設定するか、キャッシュ不可（ExpiryTimeを0）にすることが望まれます。

2.4. Forwarder Behavior
2.4. フォワーダーの動作

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.

フォワーダーはForwarding Information Base（FIB）に基づいてInterestメッセージを転送し、Interestに一致するContent ObjectをInterestの直前のホップへ返し、Interest Return制御メッセージを処理します。また、概念上のContent StoreにContent Objectをキャッシュする場合があります。この文書はフォワーダーの内部動作ではなく、これらを含む外部から観測可能な動作を規定します。

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.

この文書では、Interest用とContent Object用の2つの処理パイプラインを示します。Interestの処理では、PIT内の重複Interestを確認し（セクション2.4.2）、Content Store内のキャッシュ済みContent Objectを確認し（セクション2.4.3）、FIBを介してInterestを転送します。Content Storeの処理では、PIT内で一致するInterestを確認し、それらのInterestを送信した直前のホップへ転送します。

2.4.1. Interest HopLimit
2.4.1. Interestホップリミット

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ではInterestループは防止されません。ループを通過するInterestは、Interestのホップ制限フィールドを使用して最終的に破棄されます。このフィールドは、Interestが通過するホップごとにデクリメントされます。

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.

ループ上のノードでInterestが既存のPITエントリに集約されることによっても、ループは終了する場合があります。この場合、Content Objectはループに沿って返送され、すでにコンテンツを転送したノードに再び到達します。そのノードには通常PITエントリが残っていないため、Content Objectは破棄されます。新しいInterestまたは別のループ中のInterestが同じノードに戻る場合は、ノードがキャッシュ済み応答を返し、後述のように新しい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は、Content Objectがループの周りのInterestを追跡し、中間ノードが何らかの理由でPITエントリを持たなくなり、Content ObjectをキャッシュしないInterestループを停止する最後の手段です。

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.

すべてのInterestにはHopLimitを含めなければなりません (MUST)。ローカルアプリケーションから受信したInterestのHopLimitは0でもかまいません (MAY)。その場合、Interestの転送先は他のローカルソースに限られます。

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.

別のフォワーダーからInterestを受信した場合、HopLimitは正の値でなければなりません (MUST)。そうでなければ、フォワーダーはInterestを破棄します。フォワーダーはInterestを転送する前に、そのHopLimitを少なくとも1減らさなければなりません (MUST)。

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の場合、Interestを別のフォワーダーへ転送してはなりません (MUST NOT)。ローカルパブリッシャーアプリケーションへ送信するか、ローカルContent Storeから応答してもかまいません (MAY)。

A RECOMMENDED HopLimit-processing pipeline is below:

推奨されるHopLimit処理手順は次のとおりです (SHOULD)：

o If Interest received from a remote system:

o リモートシステムからInterestを受け取った場合：

* If received HopLimit is 0, optionally send Interest Return (HopLimit Exceeded), and discard Interest.

* 受信したHopLimitが0の場合、オプションでInterest Return（HopLimit Exceeded）を送信し、Interestを破棄します。

* 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 Interestが転送される場合：

* If the (potentially decremented) HopLimit is 0, restrict forwarding to the local system.

* （減少する可能性がある）HopLimitが0の場合、ローカルシステムへの転送を制限します。

* Otherwise, forward as desired to local or remote systems.

* それ以外の場合は、必要に応じてローカルシステムまたはリモートシステムに転送します。

2.4.2. Interest Aggregation
2.4.2. Interestアグリゲーション

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.

Interest集約とは、フォワーダーが、すでに転送した別のInterestへの応答で満たせるInterestを受信し、新しいInterestの転送を抑制することです。フォワーダーは追加の直前ホップだけを記録します。最初のInterestへの応答として送られたContent Objectが、両方のInterestを満たします。

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のInterest集約規則では、InterestLifetimeをネットワーク往復時間ではなく、購読の有効期間に相当するものとして扱います。従来の一部の集約規則ではLifetimeを往復時間とみなしていましたが、RTTを短く見積もると応答前にInterestが期限切れになる問題がありました。また、RTTを過大評価した以前のInterestが、再送を望む自動再送要求（ARQ）方式を妨げることもあります。

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メッセージを転送します。これは、複数の (場合によっては同一の) Content Objectが返ってくることを意味するわけではありません。フォワーダーは依然として保留中のすべてのInterestを満たさなければならない (MUST) ため、フォワーダーが重複したInterestメッセージを抑制しなかったとしても、1つのContent Objectで複数の類似したInterestを満たすことができます。

A RECOMMENDED Interest aggregation scheme is:

推奨されるInterest集約方式は次のとおりです (SHOULD)：

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つのInterestは、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 Interestの最初の受信を転送しなければなりません (MUST)。

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 同じ前のホップからの有効な保留中のInterestに類似したInterestの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 新しい前のホップからの有効な保留中のInterestに類似した2回目以降のInterestの受信は、集約される場合があります (MAY)（転送されません）。このInterestに保留中のInterestよりも大きなHopLimitがある場合は、転送しなければなりません (MUST)。

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 Interestを集約する際には、InterestレコードのInterestExpiry時刻を延長しなければなりません (MUST)。実装は、すべての前ホップに対して単一のInterestExpiry時刻を保持してもよく (MAY)、前ホップごとにInterestExpiry時刻を保持してもよいです (MAY)。前者の場合、フォワーダーはもはやContent Objectを待っていない経路にそれを送信することがあり、その場合は前ホップ (Content Objectにとっての次ホップ) がそれを破棄します。

2.4.3. Content Store Behavior
2.4.3. Content Storeの動作

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の動作には特別な規則があります。

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は通常の一致ルールを介してContent ObjectをInterestに一致させます（セクション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. InterestにKeyId制約がある場合、一致するContent Objectの署名が正しいと確認できない限り、Content Storeは応答してはなりません (MUST NOT)。確認には、管理ネットワークや事前にキャッシュを設定したシステムで得た外部情報を使う方法と、公開鍵で署名を暗号学的に検証する方法があります。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が署名を検証する場合は、次の方法を使ってもかまいません (MAY)。公開鍵がContent Object自体（PublicKeyフィールド）またはInterestに含まれる場合、公開鍵のハッシュがKeyIdと一致することを確認し、署名を検証しなければなりません (MUST)（セクション8.4を参照）。Content Storeはキャッシュ前にContent Objectのデジタル署名を検証してもかまいません (MAY)。ただし、その検証は必須ではありません。Content Storeはネットワーク経由で鍵を取得すべきではありません (SHOULD NOT)。署名を検証できない場合、またはまだ検証していない場合は、Interestをキャッシュミスとして扱います。

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. InterestにContent Object Hash制約がある場合、一致するContent Objectのハッシュが正しいと確認できない限り、Content Storeは応答してはなりません (MUST NOT)。ハッシュを検証できない場合は、Interestをキャッシュミスとして扱います。

5. It must obey the cache control directives (see Section 4).

5. キャッシュ制御ディレクティブに従う必要があります（セクション4を参照）。

2.4.4. Interest Pipeline
2.4.4. Interestパイプライン

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. InterestにMICや、公開鍵または証明書を含む署名などの検証情報がある場合、フォワーダーはセクション8に従ってInterestを検証してもかまいません (MAY)。フォワーダーはKeyLink経由で鍵を取得すべきではありません (SHOULD NOT)。検証に失敗してInterestを破棄する場合、Interest Returnを送信してもかまいません (MAY)（セクション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に従ってInterestを集約できるかどうかを判断します。可能であれば、集約してInterestを転送しないでください。

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のヒットを確認します。一致するContent Objectが見つかった場合、それをInterestの前のホップに戻します。これにより、セクション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でInterestを検索します。最長一致プレフィックス（LPM）は、バイト単位やビット単位ではなく、名前セグメント単位で実行します。Interestの直前のホップは除外することが推奨されます (SHOULD)。一致があればInterestを転送します。一致がない場合、または輻輳などのローカル事情で転送しない場合は、セクション10に従いInterest Returnメッセージを送信することが推奨されます (SHOULD)。

2.4.5. Content Object Pipeline
2.4.5. Content Objectパイプライン

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. Content Objectを受信したフォワーダーは、それが想定した直前のホップから届いたことを確認することが推奨されます (SHOULD)。想定される直前のホップとは、FIBで示されるホップ、または一致するInterestをそのホップへ送信したことが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. Content Objectは、照合規則を満たすすべての保留中Interestと照合しなければなりません (MUST)（セクション9を参照）。照合が成立した各保留中Interestは、保留中の集合から削除しなければなりません (MUST)。

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. フォワーダーは、受信したContent Objectの複製を同じInterestの直前のホップへ複数回送信すべきではありません (SHOULD NOT)。たとえば、2つのInterestが異なる方法（名前のみ、または名前とKeyId）で同じContent Objectを要求し、同じ直前のホップから届く場合があります。異なる直前のホップへ送るのであれば、Ethernetなどの同じインターフェイスから同じContent Objectを複数回送信しても通常は問題ありません。

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. Content Objectは、Interestを満たした（かつ上記の規則#1を通過した）場合にのみ、Content Storeに格納すべきです (SHOULD)。これは、キャッシュポイズニングの可能性を減らすためです。

3. Names
3. 名前

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名は、名前セグメントの構成です。各名前セグメントには、名前セグメントの目的を識別するラベルと値が含まれています。たとえば、一部の名前セグメントは一般的な名前であり、バージョン情報の伝達や大きなオブジェクトの多数のチャンクの小さな署名されたContent Objectへのシーケンスなど、特定の目的に役立つものもあります。

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種類があります。プレフィックス名は、単一のContent Objectを一意に識別するのではなく、既存のContent Object名の名前空間またはプレフィックスを表します。完全一致名は、Content Objectの名前を一意に識別します。完全名は完全一致名に明示的または暗黙的なConObjHashを加えたものです。ConObjHashはInterestでは明示され、Content Objectでは暗黙的です。

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.

フォワーダーは名前に関するセマンティクスを知る必要がないことに注意してください。Interestを転送する場合はプレフィックスに一致し、Content Objectを転送する場合は正確な名前または完全な名前に一致する必要があるだけです。これは、名前セグメントタイプの影響を受けません。

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は、Interestのペイロードを識別する名前セグメントです。アプリケーションコンポーネントは、アプリケーションで使用するために予約されている名前セグメントタイプのセットです。 

   +-------------+-----------------------------------------------------+
   |     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つの名前セグメント（ラベルと値の両方）が等しいかどうかを比較できる必要があるだけです。フォワーダーは、転送テーブルとセグメントごとに名前を照合して、ネクストホップを決定します。

3.1. Name Examples
3.1. 名前の例

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]表現を使用します。メッセージの文法に従って、Interestには少なくとも1オクテットの値が必要な少なくとも1つの名前セグメントを持つ名前が必要です。Content Objectには、類似した名前を付けるか、名前を付けないでください。一方、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名の例

3.2. Interest Payload ID
3.2. Interest Payload ID

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.

Interestには、Interestに関する状態を保持するPayloadフィールドを含める場合がありますが、これはContent Objectとの照合には使いません。InterestにPayloadが含まれる場合、Interest名にはInterest Payload ID（IPID）を含めることが推奨されます。IPIDにより、PITエントリは特定のPayload IDを持つInterestへの応答としてContent Objectを正しく多重化できます。IPIDはPayloadのハッシュから導出するほか、Globally Unique Identifier（GUID）やnonceを使うこともできます。任意のMetadataフィールドでIPIDを定義すると、Payloadのハッシュから導出した場合などに、他のシステムがIPIDを検証できます。IPIDの検証は必須ではありません。

4. Cache Control
4. キャッシュ制御

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つのフィールドをサポートしています。これらは、キャッシュまたはContent StoreがContent Objectを処理する方法を決定します。それらは高速パスでは使用されません。これらは、Interestに応じてContent Objectを高速パスに挿入できるかどうかを決定するためにのみ使用されます。

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はValidation Algorithmの署名エンベロープ内にあるフィールドです。Content Objectが期限切れとみなされる時刻をミリ秒単位のUTC時刻で示し、その時刻以降はキャッシュからのInterestへの応答に使ってはなりません (MUST)。期限切れのコンテンツはキャッシュから削除してもかまいません (MAY)。

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.

Recommended Cache Time（RCT）は署名エンベロープの外側にあるフィールドです。パブリッシャーがContent Objectをキャッシュする価値が低いと判断する時刻を、ミリ秒単位のUTC時刻で示します。キャッシュはRCT以降にそのContent Objectを破棄すべきです (SHOULD) が、保持して応答に使ってもかまいません (MAY)。キャッシュはRCTより前にContent Objectを破棄してもかまいません (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が短いContent Objectを作成し、RCTを拡張することにより、同じ署名付きContent Objectを何度も繰り返し公開し続けることができます。これにより、コンテンツが使用されていることをパブリッシャーが定期的に確認したい「フォーンホーム」の形式が可能になります。

5. Content Object Hash
5. Content Objectハッシュ

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では、Interestが特定のハッシュへの応答を制限できます。ハッシュは、Content Objectのメッセージ本文と、存在する場合は検証セクションをカバーします。したがって、Content Objectが署名されている場合、そのハッシュにはその署名値が含まれます。ハッシュには、Content Objectの固定ヘッダーまたはホップバイホップヘッダーは含まれません。ハッシュはマッチングルールの一部であるため（セクション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.

InterestのContent Object Hash制約を照合する方法は2つあります。1つ目は、フォワーダー自身がハッシュ値を計算して制約値と比較する方法です。この処理には大きなコストがかかります。2つ目は、境界装置がハッシュを一度計算し、その値をConObjHashヘッダーに入れてネットワーク内で運ぶ方法です。この方法ではハッシュ照合によるセキュリティ特性が失われるため、信頼できるドメイン内でのみ使うべきです (SHOULD)。信頼境界を越えるときはヘッダーを削除すべきです (SHOULD)。

6. Link
6. リンク

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.

Linkは{Name, [KeyIdRestr], [ContentObjectHashRestr]}というタプルです。Linkの情報は、そのリンク先を取得するInterestのフィールドから成ります。PayloadTypeが「Link」のContent Objectは、1つ以上のLinkをPayloadに含むオブジェクトです。このタプルをKeyLinkとして使い、証明書でラップされた鍵を持つ特定のオブジェクトを識別できます。KeyId制約またはContent Object Hash制約の少なくとも一方を含めることが推奨されます (SHOULD)。どちらの制約もない場合、任意のパブリッシャーが持つ同名のContent Objectが返される可能性があります。

7. Hashes
7. ハッシュ

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]仕様は、許容可能なハッシュ関数と使用法の定義として解釈されるべきです。

8. Validation
8. 検証
8.1. Validation Algorithm
8.1. 検証アルゴリズム

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は含めません。この範囲を検証領域と呼びます。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）は、許可される検証アルゴリズムとその構造を示しています。ベンダーアルゴリズムの場合、ベンダーは任意の構造を使用できます。バリデーターは、InterestまたはContent Objectにのみ適用でき、Interest Returnには適用できません。Interest Return内のInterestには、元のバリデータがある場合でも、それが含まれます。

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を追加して、高価な署名検証を使用せずにネットワーク内のエラーチェックを行うことができます。この仕様の一部として、これらのベンダーメソッド以外の複数の検証アルゴリズムブロックは許可されていません。

8.2. Message Integrity Codes
8.2. メッセージ整合性コード

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はInterestとともに使用され、偶発的なネットワーク内の破損を回避します。オブジェクトは署名されているか、ハッシュチェーンによってリンクされているため、CRC32Cは冗長であるため、通常、これらはContent Objectでは使用されません。

8.3. Message Authentication Codes
8.3. メッセージ認証コード

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フィールドは、キーをネゴシエートする方法を示し、キー交換エンドポイントを指す必要があります。キーネゴシエーションアルゴリズムの使用はこの仕様の範囲外であり、このフィールドを使用するためにキーネゴシエーションアルゴリズムは必要ありません。

8.4. Signature
8.4. 署名

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のSubject Key Identifierに相当します（[RFC5280]のセクション4.2.1.2）。KeyIdをDER形式の公開鍵の暗号学的ハッシュ値と定義します。すべての実装は、KeyIdのハッシュとしてSHA-256ダイジェストをサポートしなければなりません (MUST)。

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の一致を確認する必要があるContent Storeで問題が発生する可能性があります（セクション2.4.3を参照）。ただし、この場合、キャッシュミスが発生するだけで、Interestはパブリッシャーに転送されます。パブリッシャーとコンシューマーーがハッシュをサポートしている限り、データは検証されます。

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が複数含まれる場合、エンドポイント（コンシューマー、キャッシュ、Content Store）は、使用する各フィールドに矛盾がないことを確認しなければなりません (MUST)。KeyIdは、埋め込み公開鍵または証明書内の公開鍵に対応するハッシュでなければなりません (MUST)。使用するハッシュ関数はKeyIdのHashTypeで指定します。埋め込み公開鍵と証明書の両方がある場合、それらの公開鍵は同一でなければなりません (MUST)。

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を含めてもかまいません (MAY)。

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.

最初のContent Object内のKeyLinkは、PublicKeyフィールドにDER形式の公開鍵を持ち、Payloadに任意でDER形式のX.509証明書を含む2つ目のContent Objectを指す場合があります。2つ目のオブジェクトのKeyIdは、最初のオブジェクトのKeyIdと等しくなければなりません (MUST)。2つ目のオブジェクトのPublicKeyフィールドには、KeyIdに対応する公開鍵を指定しなければなりません (MUST)。その鍵で最初と2つ目のオブジェクト双方の署名を検証できる必要があります。2つ目のオブジェクトのPayloadにDER形式のX.509証明書を含める場合、証明書内の公開鍵はPublicKeyと一致しなければなりません (MUST)。証明書は信頼できる機関が発行したものである必要があり、識別名には鍵の有効な名前空間を指定することが望まれます。2つ目のオブジェクトにKeyLinkを含めてはなりません (MUST NOT)。再帰的な鍵検索は認めません。

9. Interest to Content Object Matching
9. InterestとContent Objectの照合

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.

Content ObjectがInterestを満たすのは、次のすべてを満たす場合に限ります。（a）Content ObjectにNameがある場合、そのNameがInterestのNameと完全一致する。（b）InterestにKeyId制約がある場合、Content ObjectのValidationAlgorithmにあるKeyIdが制約値と完全一致する。（c）InterestにContent Object Hash制約がある場合、計算したContent Object Hashが制約値と完全一致する。

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.

照合規則は次の述語で表され、評価結果が真ならContent ObjectはInterestに一致します。NiはInterestのName（空ではない）、KiはInterestのKeyIdRestr（空の場合あり）、HiはInterestのContentObjectHashRestr（空の場合あり）です。同様に、No、Ko、HoはContent Object側の各属性で、NoとKoは空の場合があります。HoはContent Object固有の属性で、常に存在します。二項関係ではANDを「&」、ORを「|」で表します。「E」は存在（空でない）演算子、「!」は非存在演算子です。

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のContent Object Hash制約が未対応のハッシュアルゴリズムを指定するときは、一致するContent Objectが存在しないため、システムはInterestを破棄すべきです。Interest Returnを直前のホップへ送信してもかまいません (MAY)。この場合、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種類あります。最初の項はContent Object内に属性が存在するかに依存し、次の2項はInterest内に属性が存在するかに依存します。最後の項は「名前なしオブジェクト」の制約です。Content ObjectにNameがない場合、少なくともHash制約によってInterestと一致しなければならないことを示します。

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.

Content Objectが表現されたフィールドとしてContent Objectハッシュを持たない場合は、一致するようにネットワークで計算する必要があります。自律システム内では、境界ルーターでContent Objectハッシュを計算し、自律システム内の信頼できる手段を介してそれを運ぶだけで十分です。Content ObjectのValidationAlgorithmにKeyIdがない場合、Content ObjectはKeyId制限のあるInterestに一致できません。

10. Interest Return
10. Interest Return

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.

このセクションでは、Interestの処理中にエラーが起きた場合に、ネットワーク要素がInterestを直前のホップへ返す手順を説明します。返されたInterestは直前のホップでさらに処理するか、Interestの起点へ返すことができます。ノードがInterestを返した場合、直前のホップはそのノードからInterestへの応答を期待できません。返送元ノードには、そのInterestに対応する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.

フォワーダーにInterest Returnメッセージの送信義務はありません。

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メッセージの処理義務はありません。処理しない場合は、通知せずに破棄すべきです (SHOULD)。

The Interest Return message does not apply to a Content Object or any other message type.

Interest Returnメッセージは、Content Objectやその他のメッセージタイプには適用されません。

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を介して複数のホップに伝播されることはありません。Interest Returnを受信した中間ノードは、PITエントリの逆のパスに示されているように、修正アクションを実行するか、独自のInterest Returnを前のホップに伝播する場合があります。

10.1. Message Format
10.1. メッセージフォーマット

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をInterest Returnを示す値にし、Interestヘッダーの予約バイトをReturn Codeとして使います。PacketTypeとReturnCodeの数値は[RFC8609]で定義されています。

10.2. ReturnCode Types
10.2. ReturnCodeタイプ

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：Interest Returnの理由コード

10.3. Interest Return Protocol
10.3. Interest Returnプロトコル

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.

このセクションでは、Interest Returnの各Reason codeに対するフォワーダーの動作を説明します。フォワーダーはコードを生成する義務はありませんが、生成する場合はこの仕様に従わなければなりません (MUST)。

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.

フォワーダーがInterest Returnを受け取った場合、フォワーダーはこれらの標準的な是正措置を取るべきです (SHOULD)。フォワーダーはInterest Returnメッセージを無視できます。その場合、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 対応するInterestのPITエントリがない場合、フォワーダーはInterest Returnを無視します。

o If a PIT entry for the corresponding Interest does exist, the forwarder MAY do one of the following:

o 対応するInterestのPITエントリが存在する場合、フォワーダーは次のいずれかを実行できます（MAY）。

* Try a different forwarding path, if one exists, and discard the Interest Return, or

* 別の転送パスが存在する場合は、それを試し、Interest Returnを破棄します。

* Clear the PIT state and send an Interest Return along the reverse path.

* PIT状態をクリアし、リバースパスに沿ってInterest Returnを送信します。

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.

フォワーダーが代替ルートを試みる場合、フォワーダーが同じパスを複数回使用しないことを確認しなければなりません (MUST)。たとえば、試行したネクストホップを追跡し、再利用しない場合があります。

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つ目のInterest Returnを受信する場合があります。たとえば、ノードAがノードBにInterestを送り、ノードBがNo Routeを返した後、ノードAがノードCに再送し、ノードCがProhibitedを返す場合です。ノード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.

フォワーダーが代替ルートを試行する場合、これまでInterestの処理に費やされた時間を考慮して、Interestライフタイムをデクリメントする必要があります。

10.3.1. No Route
10.3.1. ルートなし

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.

フォワーダーがルートがないInterestを受信した場合、またはInterestを送信したシステムにルートが戻るだけの場合、フォワーダーは「ルートなし」のInterest Returnメッセージを生成すべきです (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管理方法は実装に依存します。一般に、No RouteのInterest Returnを受け取っただけでフォワーダーが経路を削除することは望ましくありません。経路を設定した動的ルーティングプロトコル、または静的経路を作成した管理者が設定を修正することが想定されます。フォワーダーは、一定期間そのネクストホップを使わないようにする場合があります。

10.3.2. HopLimit Exceeded
10.3.2. HopLimit Exceeded

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.

フォワーダーは、システムから転送する必要があるInterestを受信し、HopLimitが0の場合に、HopLimit Exceededメッセージを送信することを選択できます（MAY）。

10.3.3. Interest MTU Too Large
10.3.3. Interest MTUの過大

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が所定の最小値を超えるInterestを受信した場合、「InterestMTUが大きすぎます」メッセージを送信する場合があります (MAY)。

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"応答を受信した場合、代替パスを試すべきではありません (SHOULD NOT)。それは以前のホップにInterest Returnを伝播すべきです (SHOULD)。

10.3.4. No Resources
10.3.4. リソースなし

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.

フォワーダーがInterestを受け取り、リソース不足のためInterestを処理できない場合、Interest Returnを送信できます（MAY）。リソースの不足は、PITが大きすぎるか、他の容量制限があることを意味する場合があります。

10.3.5. Path Error
10.3.5. パスエラー

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.

フォワーダーが、信頼できるリンクなどを介してInterestの転送エラーを検出した場合、転送エラーを送信または修復できなかったことを示すパスエラーInterest Returnを送信できます（MAY）。

10.3.6. Prohibited
10.3.6. 禁止

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）など、Interestの受信または転送を禁止する管理ポリシーがある場合があります。ポリシーに基づいてInterestを破棄した場合、フォワーダーは直前のホップへProhibited Interest Returnを送信してもかまいません (MAY)。たとえば、「/example/private」はインターフェイスe0からのみ受け付けるというACLがあるのに、フォワーダーがe1から受信した場合、理由を添えてInterestを返す方法が必要です。

10.3.7. Congestion
10.3.7. 輻輳

If a forwarder discards an Interest due to congestion, it MAY send a Congestion Interest Return to the previous hop.

フォワーダーが輻輳のためにInterestを破棄する場合、それは前のホップに輻輳Interest Returnを送信してもよい（MAY）。

10.3.8. Unsupported Content Object Hash Algorithm
10.3.8. サポートされていないContent Objectハッシュアルゴリズム

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.

Content Objectハッシュ制限がフォワーダーが確認できないハッシュアルゴリズムを指定している場合、Interestは受け入れられず、フォワーダーは前のホップにInterest Returnを送信できます（MAY）。

10.3.9. Malformed Interest
10.3.9. 不正なInterest

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.

フォワーダーがInterestに構造上または構文上の誤りを検出した場合、そのInterestを破棄すべきであり (SHOULD)、前ホップにInterest Returnを送信してもよいです (MAY)。これは、ルーターがInterestの構造全体を検証しなければならないことを意味するものではありません。

11. IANA Considerations
11. IANAに関する考慮事項

This document has no IANA actions.

このドキュメントにはIANAアクションはありません。

12. Security Considerations
12. セキュリティに関する考慮事項

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パケットに含めることが適切とは限りません。計算資源を消費するサービス拒否攻撃につながるおそれがあるためです。アプリケーションは、パケット署名の使い方を明示するプロトコルを用いるべきです。一般的には、意図しないパケット破損を検出するためにInterestへMICを付ける方法があります。Interestを保護する場合、特にアクチュエーターとして使う場合は、暗号化ラッパーとリプレイ攻撃を防ぐプロトコルを検討します。認証コードや署名を付けるだけではInterestを安全にできません。ICN形式のメッセージを保護する方法は、文献にも複数示されています [mobile] [ace]。

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プロトコルとして、キーに到達する方法やキーを信頼する方法については説明していません。 CCNxContent Objectには、オブジェクトに埋め込まれた公開鍵または証明書を含めるか、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トンネルと同等の機能が提供されます。中間ノードはInterestとContent Objectを転送できますが、内部は見えません。また、暗号化層が使用する内部名を完全に隠します。このタイプのトンネリング暗号化は、一時的な鍵を持つユーザーしか使用できないため、キャッシュ機能がほとんどまたはまったくないコンテンツに役立ちます。短期間のキャッシングは、損失の多いリンクやモビリティに役立ちますが、長期間のキャッシングは通常は重要ではありません。

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フィールドを可変長にします。この仕様では、TとLをそれぞれ固定長の2バイトとします。固定長にすることで、まず別名表現の問題を避けられます。たとえば%x02と%x0002を異なる長さで符号化できる場合、同じ値として扱うか、異なる値とするか、片方を不正とするかを決める必要があります。異なる値とすれば整数値ではなくバッファーを比較しなければなりません。不正とすれば、すべてのホップで全パケットの全フィールドについてTLV符号化を検証しなければなりません。同じ値とすれば、パケットフィルターの指定が問題になります。たとえば、名前に6個の名前要素があると、TとLはそれぞれ7個ずつあります。同じ値に最大4種類の表現を許すと、14フィールドに各4通り、合計1001通りの組み合わせが生じます。また、埋め込まれたTやLの形式が異なる可能性を考慮する必要があるため、メモリー関数だけで名前を比較することもできません。

The Interest Return message has no authenticator from the previous hop. Therefore, the payload of the Interest Return should only be used locally to match an Interest. A node should never forward that Interest Payload as an Interest. It should also verify that it sent the Interest in the Interest Return to that node and not allow anyone to negate Interest messages.

Interest Returnメッセージには、直前のホップによる認証情報がありません。そのため、Interest ReturnのPayloadは、Interestとの照合にローカルでのみ使う想定です。ノードはそのInterest Payloadを新しいInterestとして転送しないでください。また、Interest Return内のInterestをそのノード自身が送信したことを確認し、第三者がInterestメッセージを無効化できないようにします。

Caching nodes must take caution when processing Content Objects. It is essential that the Content Store obey the rules outlined in 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.

キャッシュノードはContent Objectの処理に注意が必要です。特定の攻撃を避けるには、Content Storeがセクション2.4.3の規則に従うことが不可欠です。CCNx 1.0にはネットワークから返る望ましくない結果を除外する仕組み（exclude）がないため、キャッシュが不正なコンテンツで汚染されると、コンテンツの取得に支障が出る場合があります。Content Storeからの取得方法は、制約なし、署名制約付き、ハッシュ制約付きの3種類です。Interestに制約がなければ、要求元は応答内容を限定していないため、一致するキャッシュ済みオブジェクトを返せます。ハッシュ制約がある場合、要求元が求める内容は明確であり、Content Storeと経路上の各フォワーダーは要求との一致を容易に確認できます。署名制約の場合（初期マニフェストの発見でよく使われます）、要求元が知っているのはコンテンツに署名したKeyIdだけです。不正なデータの拡散を防ぐため、Content Storeはこのケースを特に慎重に扱います。署名を検証できる場合に限りContent Objectで応答します。つまり、Content Object自体に公開鍵が含まれるか、InterestにKeyIdと公開鍵の両方が含まれている必要があります。それ以外の場合、Content StoreはInterestをキャッシュミスとして扱い、エンドポイントが応答するようにします。

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パスも、大文字と小文字を区別せずに照合するシステムがあります。そのため、URIからCCNx名への正規化規則を統一しない限り、人が入力したCCNx名では大文字小文字や非ASCII文字の不一致が起きる可能性があります。また、たとえば「ccnx:/example.com」というCCNxルーティング可能プレフィックスを登録する主体は、「ccnx:/Example.com」のような表記違いも別途登録する必要があります。URI正規化とルーティングプロトコルの慣例でこの点に対処しなければ、フィッシング攻撃につながるおそれがあります。

For a more general introduction to ICN-related security concerns and approaches, see [RFC7927] and [RFC7945].

ICN関連のセキュリティ問題とアプローチのより一般的な概要については、[RFC7927]および[RFC7945]を参照してください。

13. References
13. 参考文献
13.1. Normative References
13.1. 引用文献

[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., "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>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

13.2. Informative References
13.2. Informative References

[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, December 2015, <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. and C. Tschudin, "ICN "Begin-End" Hop by Hop Fragmentation", Work in Progress, draft-mosko-icnrg-beginendfragment-02, December 2016.

[ccn-lite] Tschudin, C., et al., "CCN-lite", University of Basel, 2011-2019, <http://ccn-lite.net>.

[ccn-lite] Tschudin, C., et al., "CCN-lite", University of Basel, 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., and C. Wood, "CCNx Key Exchange Protocol Version 1.0", Work in Progress, draft-wood-icnrg-ccnxkeyexchange-02, March 2017.

[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. and C. Wood, "The CCNx URI Scheme", Work in Progress, draft-mosko-icnrg-ccnxurischeme-01, April 2016.

[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, June 2016.

[cicn] FD.io, "Community ICN (CICN)", February 2017, <https://wiki.fd.io/index.php?title=Cicn&oldid=7191>.

[cicn] FD.io, "Community ICN (CICN)", February 2017, <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. 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>.

[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. and C. Wood, "Encrypted Sessions In CCNx (ESIC)", Work in Progress, draft-wood-icnrg-esic-01, September 2017.

[flic] Tschudin, C. and C. Wood, "File-Like ICN Collection (FLIC)", Work in Progress, draft-tschudin-icnrg-flic-03, March 2017.

[flic] Tschudin, C. and C. Wood, "File-Like ICN Collection (FLIC)", Work in Progress, draft-tschudin-icnrg-flic-03, March 2017.

[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>.

[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>.

[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 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>.

[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] 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>.

[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., 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>.

[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., and M. Waehlisch, "Information-Centric Networking (ICN) Research Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, <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, September 2016, <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., 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>.

[selectors] Mosko, M., "CCNx Selector Based Discovery", Work in Progress, draft-mosko-icnrg-selectors-01, May 2019.

[selectors] Mosko, M., "CCNx Selector Based Discovery", Work in Progress, draft-mosko-icnrg-selectors-01, May 2019.

[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.

[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.

[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>.

[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>.

Authors' Addresses

著者のアドレス

Marc Mosko PARC, Inc. Palo Alto, California 94304 United States of America

Marc Mosko PARC, Inc. Palo Alto, California 94304 United States of America 

   Phone: +01 650-812-4405
   Email: marc.mosko@parc.com

Ignacio Solis LinkedIn Mountain View, California 94043 United States of America

Ignacio Solis LinkedIn Mountain View, California 94043 United States of America 

   Email: nsolis@linkedin.com

Christopher A. Wood University of California Irvine Irvine, California 92697 United States of America

Christopher A. Wood University of California Irvine Irvine, California 92697 United States of America 

   Phone: +01 315-806-5939
   Email: woodc1@uci.edu