[要約] RFC 9236は、情報中心ネットワーキング（ICN）における名前解決サービス（NRS）の使用に関連するアーキテクチャ上の考慮事項と影響を説明しています。ICNアーキテクチャがNRSを利用する際にどのように変化し、その使用がICNルーティングシステムにどのように影響を与えるかを説明しています。ICNRGの成果物です。
Internet Research Task Force (IRTF) J. Hong
Request for Comments: 9236 T. You
Category: Informational ETRI
ISSN: 2070-1721 V. Kafle
NICT
April 2022
Architectural Considerations of Information-Centric Networking (ICN) Using a Name Resolution Service
名前解決サービスを使用した情報中心ネットワーキング（ICN）のアーキテクチャに関する考慮事項
Abstract
概要
This document describes architectural considerations and implications related to the use of a Name Resolution Service (NRS) in Information-Centric Networking (ICN). It explains how the ICN architecture can change when an NRS is utilized and how its use influences the ICN routing system. This document is a product of the Information-Centric Networking Research Group (ICNRG).
このドキュメントでは、情報中心のネットワーキング（ICN）における名前解像度サービス（NRS）の使用に関連するアーキテクチャの考慮事項と意味について説明します。ICNアーキテクチャがNRSを利用したときにどのように変化するか、およびその使用がICNルーティングシステムにどのように影響するかを説明します。このドキュメントは、情報中心のネットワーキング研究グループ（ICNRG）の製品です。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Information-Centric Networking Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネット研究タスクフォース（IRTF）の製品です。IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適していない場合があります。このRFCは、インターネット研究タスクフォース（IRTF）の情報中心のネットワーキング研究グループのコンセンサスを表しています。IRSGによって公開されることが承認された文書は、インターネット標準のレベルの候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9236.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9236で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 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ドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Introduction
2. Terminology
3. Background
4. Implications of an NRS in ICN
5. ICN Architectural Considerations for NRS
5.1. Name Mapping Records Registration, Resolution, and Update
5.2. Protocols and Semantics
5.3. Routing System
6. Conclusion
7. IANA Considerations
8. Security Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Authors' Addresses
Information-Centric Networking (ICN) is an approach to evolving the Internet infrastructure to provide direct access to Named Data Objects (NDOs) by names. In two common ICN architectures, Named Data Networking (NDN) [NDN] and Content-Centric Networking (CCNx) [CCNx], the name of an NDO is used directly to route a request to retrieve the data object. Such direct name-based routing has inherent challenges in enabling a globally scalable routing system, accommodating producer mobility, and supporting off-path caching. These specific issues are discussed in detail in Section 3. In order to address these challenges, a Name Resolution Service (NRS) has been utilized in the literature as well as the proposals of several ICN projects [Afanasyev] [Zhang2] [Ravindran] [SAIL] [MF] [Bayhan].
情報中心のネットワーキング（ICN）は、インターネットインフラストラクチャを進化させるアプローチであり、名前ごとに指名されたデータオブジェクト（NDO）に直接アクセスできるようにします。データネットワーキング（NDN）[NDN]とコンテンツ中心のネットワーキング（CCNX）[CCNX]という名前の2つの一般的なICNアーキテクチャでは、NDOの名前が直接使用され、データオブジェクトを取得するためにリクエストをルーティングします。このような直接的な名前ベースのルーティングには、グローバルにスケーラブルなルーティングシステムを有効にし、生産者のモビリティに対応し、オフパスキャッシングをサポートすることに固有の課題があります。これらの具体的な問題については、セクション3で詳しく説明します。これらの課題に対処するために、いくつかのICNプロジェクト[afanasyev] [zhang2] [ravindran] [afanasyev] [afanasyev] [afanasyev] [afanasyev] [afanasyev] [afanasyev] [afanasyev] [afanasyev] [afanasyev] [afanasyev] [afanasyev]の提案では、名前解決サービス（NRS）が利用されています。帆] [MF] [Bayhan]。
This document describes the potential changes in the ICN architecture caused by the introduction of an NRS and the corresponding implication to the ICN routing system. It also describes ICN architectural considerations for the integration of an NRS. The scope of this document includes considerations from the perspective of an ICN architecture and routing system when using an NRS in ICN. A description of the NRS itself is provided in the companion NRS design considerations document [RFC9138], which provides the NRS approaches, functions, and design considerations.
このドキュメントでは、NRSの導入によって引き起こされるICNアーキテクチャの潜在的な変化と、ICNルーティングシステムへの対応する意味について説明します。また、NRSの統合に関するICNアーキテクチャの考慮事項についても説明しています。このドキュメントの範囲には、ICNでNRSを使用する場合のICNアーキテクチャおよびルーティングシステムの観点から考慮されます。NRS自体の説明は、NRSアプローチ、機能、および設計上の考慮事項を提供するコンパニオンNRS設計上の考慮事項ドキュメント[RFC9138]に記載されています。
This document represents the consensus of the Information-Centric Networking Research Group (ICNRG). It has been reviewed extensively by the Research Group (RG) members who are actively involved in the research and development of the technology covered by this document. It is not an IETF product and is not a standard.
このドキュメントは、情報中心のネットワーキング研究グループ（ICNRG）のコンセンサスを表しています。この文書の対象となる技術の研究開発に積極的に関与している研究グループ（RG）メンバーによって広範囲にレビューされています。IETF製品ではなく、標準でもありません。
Name Resolution Service (NRS): An NRS in ICN is defined as a service that provides the function of translating a content name or a data object name into some other information such as a routable prefix, a locator, an off-path-cache pointer, or an alias name that is more amenable than the input name to forwarding the object request toward the target destination storing the NDO [RFC9138]. An NRS is most likely implemented through the use of a distributed mapping database system. The Domain Name System (DNS) may be used as an NRS. However, in this case, the requirements of frequent updates of NRS records due to the creations of a lot of new NDOs and changes in their locations in the network need to be considered.
名前解像度サービス（NRS）：ICNのNRSは、コンテンツ名またはデータオブジェクト名をルーティング可能なプレフィックス、ロケーター、オフパスキャッシュポインターなどの他の情報に変換する機能を提供するサービスとして定義されます。、または、NDO [RFC9138]を保存するターゲット宛先にオブジェクトリクエストを転送することに入力名よりも適切なエイリアス名。NRSは、分散マッピングデータベースシステムを使用して実装される可能性が最も高くなります。ドメイン名システム（DNS）は、NRSとして使用できます。ただし、この場合、多くの新しいNDOの作成とネットワーク内の場所の変更により、NRSレコードの頻繁な更新の要件を考慮する必要があります。
NRS server: An NRS comprises the distributed NRS servers storing the mapping records in their databases. NRS servers store and maintain the mapping records that keep the mappings of content or object name to some other information that is used for forwarding the content request or the content itself.
NRSサーバー：NRSは、データベースにマッピングレコードを保存する分散NRSサーバーを含む。NRSサーバーは、コンテンツまたはオブジェクト名のマッピングをコンテンツリクエストまたはコンテンツ自体の転送に使用する他の情報に保持するマッピングレコードを保存および維持します。
NRS resolver: The client-side function of an NRS is called an NRS resolver. The NRS resolver is responsible for initiating name resolution request queries that ultimately lead to a name resolution of the target data objects. NRS resolvers can be located in the consumer (or client) nodes and/or ICN routers. An NRS resolver may also cache the mapping records obtained through the name resolution for later usage.
NRSリゾルバー：NRSのクライアント側の関数は、NRSリゾルバーと呼ばれます。NRSリゾルバーは、最終的にターゲットデータオブジェクトの名前解決につながる名前解決要求クエリを開始する責任があります。NRSリゾルバーは、消費者（またはクライアント）ノードおよび/またはICNルーターに配置できます。NRSリゾルバーは、後で使用するために名前の解像度を通じて取得したマッピングレコードをキャッシュすることもできます。
Name registration: In order to populate the NRS, the content names and their mapping records must be registered in the NRS system by a publisher who has access rights to at least one authoritative NRS server or by a producer who generates named data objects. The records contain the mapping of an object name to some information such as other alias names, routable prefixes, and locators, which are used for forwarding the content request. Thus, a publisher or producer of content creates an NRS registration request and sends it to an NRS server. On registration, the NRS server stores (or updates) the name mapping record in the database and sends an acknowledgement back to the producer or publisher that made the registration request.
名前の登録：NRSを設定するには、コンテンツ名とマッピングレコードをNRSシステムに、少なくとも1つの権威あるNRSサーバーにアクセス権を持つ出版社または名前付きデータオブジェクトを生成するプロデューサーによって登録する必要があります。レコードには、コンテンツリクエストの転送に使用される他のエイリアス名、ルーティング可能なプレフィックス、ロケーターなどのいくつかの情報へのオブジェクト名のマッピングが含まれています。したがって、コンテンツの出版社またはプロデューサーがNRS登録要求を作成し、NRSサーバーに送信します。登録時に、NRSサーバーはデータベースに名前マッピングレコードを保存（または更新）し、登録リクエストを行ったプロデューサーまたはパブリッシャーに謝辞を送り返します。
Name resolution: Name resolution is the main function of the NRS system. It is performed by an NRS resolver, which can be deployed on a consumer node or an ICN router. Resolvers are responsible for either returning a cached mapping record (whose lifetime has not expired) or alternatively sending a name resolution request toward an NRS server. The NRS server searches for the content name in its mapping record database and, if found, retrieves the mapping record and returns it in a name resolution response message to the NRS resolver.
名前解決：名前解決は、NRSシステムの主な機能です。これは、消費者ノードまたはICNルーターに展開できるNRSリゾルバーによって実行されます。リゾルバーは、キャッシュされたマッピングレコードを返す（寿命の期限が切れていない）か、NRSサーバーに名前の解決要求を送信するかどうかを担当します。NRSサーバーは、マッピングレコードデータベースのコンテンツ名を検索し、見つかった場合、マッピングレコードを取得し、NRSリゾルバーへの名前解像度応答メッセージで返します。
NRS node: NRS servers are also referred to as NRS nodes that maintain the name records. The terms are used interchangeably.
NRSノード：NRSサーバーは、名前の記録を維持するNRSノードとも呼ばれます。用語は同じ意味で使用されます。
NRS client: A node that uses the NRS is called an NRS client. Any node that initiates a name registration, resolution, or update procedure is an NRS client; that is, NRS resolvers, ICN client nodes, ICN routers, or producers can be NRS clients.
NRSクライアント：NRSを使用するノードは、NRSクライアントと呼ばれます。名前の登録、解決、または更新手順を開始するノードは、NRSクライアントです。つまり、NRSリゾルバー、ICNクライアントノード、ICNルーター、または生産者はNRSクライアントになる可能性があります。
A pure name-based routing approach in ICN has inherent challenges in enabling a globally scalable routing system, accommodating producer mobility, and supporting off-path caching. In order to address these challenges, an NRS has been utilized in proposals and literature of several ICN projects as follows:
ICNの純粋な名前ベースのルーティングアプローチは、グローバルにスケーラブルなルーティングシステムを有効にし、生産者のモビリティに対応し、オフパスキャッシングをサポートすることに固有の課題を抱えています。これらの課題に対処するために、次のように、いくつかのICNプロジェクトの提案と文献でNRSが利用されています。
Routing scalability: In ICN, application names identifying content are intended to be used directly for packet delivery, so ICN routers run a name-based routing protocol to build name-based routing and forwarding tables. Similar to the scalability challenge of IP routing, if non-aggregatable name prefixes are injected into the Default Route Free Zone (DFZ) of ICN routers, they would be driving the uncontrolled growth of the DFZ routing table size. Thus, providing the level of indirection enabled by an NRS in ICN can be an approach to keeping the routing table size under control. The NRS system resolves name prefixes that do not exist in the DFZ forwarding table into globally routable prefixes such as the one proposed in NDN [Afanasyev]. Another approach dealing with routing scalability is the Multi-level Distributed Hash Table (MDHT) used in NetInf [Dannewitz]. It provides name-based anycast routing that can support a non-hierarchical namespace and can be adopted on a global scale [Dannewitz2].
ルーティングスケーラビリティ：ICNでは、アプリケーション名の識別コンテンツをパケット配信に直接使用することを目的としているため、ICNルーターは名前ベースのルーティングプロトコルを実行して、名前ベースのルーティングと転送テーブルを構築します。 IPルーティングのスケーラビリティチャレンジと同様に、凝集不可能な名前のプレフィックスがICNルーターのデフォルトルートフリーゾーン（DFZ）に注入された場合、DFZルーティングテーブルサイズの制御されていない成長を促進します。したがって、ICNのNRSによって有効な間接レベルのレベルを提供することは、ルーティングテーブルサイズを制御下に保つためのアプローチになります。 NRSシステムは、DFZ転送テーブルに存在しない名前のプレフィックスを解決し、NDN [Afanasyev]で提案されているようなグローバルにルーティング可能なプレフィックスになります。ルーティングのスケーラビリティを扱うもう1つのアプローチは、NetInf [Dannewitz]で使用されるマルチレベル分散ハッシュテーブル（MDHT）です。非階層的な名前空間をサポートできる名前ベースのAnycastルーティングを提供し、グローバルスケールで採用できる[Dannewitz2]。
Producer mobility: In ICN, if a producer moves into a different name domain that uses a different name prefix, the request for a content produced by the moving producer with the origin content name must be forwarded to the moving producer's new location. Especially in a hierarchical naming scheme, producer mobility support is much harder than in a flat naming scheme since the routing tables in a broader area need to be updated to track the producer movement. Therefore, various ICN architectures such as NetInf [Dannewitz] and MobilityFirst [MF] have adopted NRS systems to tackle the issues of producers whose location changes.
プロデューサーのモビリティ：ICNでは、プロデューサーが異なる名前のプレフィックスを使用する別の名前ドメインに移動する場合、Originのコンテンツ名を持つ移動プロデューサーによって生成されたコンテンツのリクエストは、移動プロデューサーの新しい場所に転送する必要があります。特に階層的な命名スキームでは、生産者の動きを追跡するために広い領域のルーティングテーブルを更新する必要があるため、プロデューサーのモビリティサポートはフラットネーミングスキームよりもはるかに困難です。したがって、NetInf [Dannewitz]やMobilityFirst [MF]などのさまざまなICNアーキテクチャは、NRSシステムを採用して、場所が変化する生産者の問題に取り組んでいます。
Off-path caching: In-network caching is a common feature of an ICN architecture. Caching approaches can be categorized into on-path caching and off-path caching, according to the location of caches in relation to the forwarding path from the original content store to a consumer. Off-path caching, sometimes also referred to as content replication or content storing, aims to replicate a Named Data Object in various locations within a network in order to increase the availability of content, reduce access latency, or both. These caching locations may not be lying along the content forwarding path. Thus, finding off-path cached content requires more complex forwarding procedures if a pure name-based routing is employed. In order to support access to off-path caches, the locations of replicas are usually advertised into a name-based routing system or into an NRS as described in [Bayhan].
オフパスキャッシュ：ネットワーク内キャッシュは、ICNアーキテクチャの一般的な機能です。キャッシュアプローチは、元のコンテンツストアから消費者への転送パスに関連するキャッシュの場所に応じて、パス上のキャッシュとパスのキャッシュに分類できます。コンテンツレプリケーションまたはコンテンツ保存とも呼ばれる場合もあるオフパスのキャッシュは、コンテンツの可用性を高め、アクセス待ち時間を減らす、またはその両方を増やすために、ネットワーク内のさまざまな場所で名前付きデータオブジェクトを複製することを目指しています。これらのキャッシングの場所は、コンテンツ転送パスに沿って横たわっていない可能性があります。したがって、純粋な名前ベースのルーティングが採用されている場合、オフパスキャッシュコンテンツを見つけるには、より複雑な転送手順が必要です。オフパスキャッシュへのアクセスをサポートするために、レプリカの場所は通常、[Bayhan]で説明されているように、名前ベースのルーティングシステムまたはNRSに宣伝されます。
This document discusses architectural considerations and implications of ICN when an NRS is utilized to solve such challenges facing a name-based routing in ICN.
このドキュメントでは、ICNの名前ベースのルーティングに直面しているこのような課題を解決するためにNRSが利用された場合のICNのアーキテクチャの考慮事項と意味について説明します。
An NRS is not a mandatory part of an ICN architecture, as the majority of ICN architectures uses name-based routing that avoids the need for a name resolution procedure. Therefore, the utilization of an NRS in an ICN architecture changes some architectural aspects at least with respect to forwarding procedures, latency, and security, as discussed below:
ICNアーキテクチャの大部分は、名前解決手順の必要性を回避する名前ベースのルーティングを使用しているため、NRSはICNアーキテクチャの必須部分ではありません。したがって、以下で説明するように、ICNアーキテクチャでのNRSの利用は、少なくとも転送手順、待ち時間、セキュリティに関していくつかのアーキテクチャの側面を変更します。
Forwarding procedure: When an NRS is included in an ICN architecture, the name resolution procedure has to be included in the ICN overall routing and forwarding architectural procedures. To integrate an NRS into an ICN architecture, there are certain things that have to be decided and specified such as where, when, and how the name resolution task is performed.
転送手順：NRSがICNアーキテクチャに含まれている場合、名前解決手順をICN全体のルーティングおよび転送アーキテクチャ手順に含める必要があります。NRをICNアーキテクチャに統合するには、名前解像度タスクの実行方法など、決定および指定されなければならない特定の事柄があります。
Latency: When an NRS is included in an ICN architecture, additional latency introduced by the name resolution process is incurred by the routing and forwarding system. Although the latency due to the name resolution is added, the total latency of individual requests being served could be lower if the nearest copies or off-path caches can be located by the NRS lookup procedure. Additionally, there might be a favorable trade-off between the name resolution latency and inter-domain traffic reduction by finding the nearest off-path cached copy of the content. Finding the nearest cache holding the content might significantly reduce the content discovery as well as delivery latency.
レイテンシ：NRSがICNアーキテクチャに含まれている場合、名前解像度プロセスによって導入された追加のレイテンシは、ルーティングおよび転送システムによって発生します。名前の解像度によるレイテンシは追加されていますが、NRSルックアップ手順で最も近いコピーまたはオフパスキャッシュを配置できる場合、個々のリクエストの合計レイテンシは低くなる可能性があります。さらに、コンテンツの最も近いオフパスキャッシュされたコピーを見つけることにより、名前解像度のレイテンシとドメイン間の交通削減の間には、好ましいトレードオフがあるかもしれません。コンテンツを保持している最も近いキャッシュを見つけると、コンテンツの発見と配信遅延が大幅に減少する可能性があります。
Security: When any new component such as an NRS is introduced in the ICN architecture, the attack surface may increase. Protection of the NRS system itself against attacks such as Distributed Denial of Service (DDoS) and spoofing or alteration of name mapping records and related signaling messages may be challenging.
セキュリティ：ICNアーキテクチャにNRSなどの新しいコンポーネントが導入されると、攻撃面が増加する可能性があります。NRSシステム自体の保護自体は、分散型サービス拒否（DDO）や名前マッピングレコードのスプーフィングまたは変更や関連シグナリングメッセージなどの攻撃に対する攻撃に対するものです。
This section discusses the various items that can be considered from the perspective of ICN architecture when employing an NRS system. These items are related to the registration, resolution, and update of name mapping records, protocols and messages, and integration with the routing system.
このセクションでは、NRSシステムを使用する際にICNアーキテクチャの観点から考慮できるさまざまな項目について説明します。これらの項目は、名前マッピングレコード、プロトコル、メッセージの登録、解像度、更新、およびルーティングシステムとの統合に関連しています。
When an NRS is integrated in ICN architecture, the functions related to the registration, resolution, and update of name mapping records have to be considered. The NRS nodes maintain the name mapping records and may exist as an overlay network over the ICN routers, that is, they communicate to each other through ICN routers. Figure 1 shows the NRS nodes and NRS clients connected through an underlying network. The NRS nodes should be deployed in such a manner that an NRS node is always available at a short distance from an NRS client so that communication latency for the name registration and resolution requested by the NRS client remains very low. The name registration, name resolution, and name record update procedures are briefly discussed below.
NRSがICNアーキテクチャに統合されている場合、名前マッピングレコードの登録、解像度、および更新に関連する機能を考慮する必要があります。NRSノードは、名前マッピングレコードを維持し、ICNルーター上のオーバーレイネットワークとして存在する可能性があります。つまり、ICNルーターを介して互いに通信します。図1は、基礎となるネットワークを介して接続されているNRSノードとNRSクライアントを示しています。NRSノードは、NRSクライアントが要求する名前の登録と解像度の通信レイテンシを非常に低いままであるため、NRSノードがNRSクライアントからすぐに利用できるように展開する必要があります。名前の登録、名前の解決、および名前の記録更新手順について、以下で簡単に説明します。
+------------+ +------------+
| NRS Node | | NRS Node |
+------------+ +------------+
| |
| |
+------------+ | | +------------+
| NRS Client |--------------------------------------| NRS Client |
+------------+ underlying network +------------+
Figure 1: NRS Nodes and NRS Clients Connected through an Underlying Network
図1：基礎となるネットワークを介して接続されているNRSノードとNRSクライアント
Name registration: Name registration is performed by the producer (as an NRS client) when it creates a new content. When a producer creates content and assigns a name from its name prefix space to the content, the producer performs the name registration in an NRS node. Name registration may be performed by an ICN router when the ICN architecture supports off-path caching or cooperative caching since involving an NRS may be a good idea for off-path caching. The ICN routers with forwarder caches do not require name registration for their cached content because they lie on the path toward an upstream content store or producer. They will be hit when a future request is forwarded to the content producer by an ICN router lying downstream toward the ICN client node. However, ICN routers performing off-path caching of content must invoke the name registration procedure so that other ICN routers can depend on name resolutions to know about the off-path cache locations. If a content gets cached in many off-path ICN routers, all of them may register the same content names in the same NRS node, resulting in multiple registration actions. In this case, the NRS node adds the new location of the content to the name record together with the previous locations. In this way, each of the name records stored in the NRS node may contain multiple locations of the content. Assigning validity time or a lifetime of each mapping record may be considered especially for the off-path caching content and managing mobility.
名前登録：名前登録は、新しいコンテンツを作成するときに（NRSクライアントとして）プロデューサーによって実行されます。プロデューサーがコンテンツを作成し、その名前プレフィックススペースからコンテンツに名前を割り当てると、プロデューサーはNRSノードで名前登録を実行します。 ICNアーキテクチャがオフパスキャッシュまたは協同キャッシングをサポートする場合、ICNルーターによって名前の登録が実行される場合があります。NRSを含むことは、パスオフキャッシュのための良いアイデアかもしれません。フォワーダーキャッシュを備えたICNルーターは、上流のコンテンツストアまたはプロデューサーへの道にあるため、キャッシュコンテンツの名前登録を必要としません。それらは、将来のリクエストがICNクライアントノードに向かって下流にあるICNルーターによってコンテンツプロデューサーに転送されるとヒットします。ただし、コンテンツのオフパスキャッシングを実行するICNルーターは、他のICNルーターがオフパスキャッシュの場所について知るために名前の解像度に依存できるように、名前登録手順を呼び出す必要があります。コンテンツが多くのオフパスICNルーターでキャッシュされた場合、それらはすべて同じNRSノードで同じコンテンツ名を登録して、複数の登録アクションになります。この場合、NRSノードは、以前の場所とともにコンテンツの新しい場所を名前レコードに追加します。このようにして、NRSノードに保存されている各名前の記録には、コンテンツの複数の場所が含まれる場合があります。各マッピングレコードの有効期間または寿命の割り当ては、特にオフパスのキャッシュコンテンツとモビリティの管理で考慮される場合があります。
Name resolution: Name resolution is performed by an NRS client to obtain the name record from an NRS node by sending a name resolution request message and getting a response containing the record. In the name-based ICN routing context, the name resolution is needed by any ICN router whose forwarding information base (FIB) does not contain the requested name prefix. Name resolution may also be performed by the consumer (especially in the case where the consumer is multihomed) to forward the content request in a better direction so that it obtains the content from the nearest cache. If the consumer is single homed, it may not bother to perform name resolution, instead depending on either straightforward name-based routing or name resolution by an upstream ICN router. In this case, the consumer creates the content request packet containing the content name and forwards to the nearest ICN router. The ICN router checks its FIB table to see where to forward the content request. If the ICN router fails to identify whether the requested content is reachable, it performs name resolution to obtain the name mapping record and adds this information to its FIB. The ICN router may also perform name resolution even before the arrival of a content request to use the name mapping record to configure its FIB.
名前の解決：名前解像度は、NRSクライアントによって実行され、名前解決要求メッセージを送信し、レコードを含む応答を取得することにより、NRSノードから名前レコードを取得します。名前ベースのICNルーティングコンテキストでは、フォワーディング情報ベース（FIB）に要求された名前プレフィックスが含まれていないICNルーターによって名前の解決が必要です。名前の解決は、消費者（特に消費者がマルチホームされている場合）によって実行され、コンテンツ要求をより良い方向に転送して、最寄りのキャッシュからコンテンツを取得することもできます。消費者が単一の家庭である場合、その代わりに、名前の解像度を実行することを気にすることはありません。この場合、消費者はコンテンツ名を含むコンテンツリクエストパケットを作成し、最も近いICNルーターに転送します。 ICNルーターは、FIBテーブルをチェックして、コンテンツリクエストをどこに転送するかを確認します。 ICNルーターが要求されたコンテンツに到達可能かどうかを識別できない場合、名前の解像度を実行して名前マッピングレコードを取得し、この情報をFIBに追加します。 ICNルーターは、コンテンツリクエストが到着する前でも名前マッピングレコードを使用してFIBを構成することもできます。
Name record update: Name record update is carried out when a content name mapping record changes, e.g., the content is not available in one or more of the previous locations. The name record update includes the substitution and deletion of the name mapping records. The name record update may take place explicitly by the exchange of name record update messages or implicitly when a timeout occurs and a name record is deemed to be invalid. The implicit update is possible when each record is accompanied by a lifetime value. The lifetime can be renewed only by the authoritative producer or node. The cached mapping records get erased after the lifetime expires unless a lifetime extension indication is obtained from the authoritative producer.
名前レコードの更新：名前レコードの更新は、コンテンツ名マッピングレコードが変更されたときに実行されます。たとえば、コンテンツは以前の場所の1つ以上では使用できません。名前レコードの更新には、名前マッピングレコードの代替と削除が含まれます。名前レコードの更新は、タイムアウトが発生し、名前レコードが無効であるとみなされた場合、名前レコード更新メッセージの交換によって明示的に行われる場合があります。暗黙の更新は、各レコードに生涯価値を伴う場合に可能です。生涯は、権威あるプロデューサーまたはノードによってのみ更新できます。キャッシュされたマッピングレコードは、権威ある生産者から生涯延長兆候が得られない限り、生涯の期限が切れた後に消去されます。
In order to develop an NRS system within a local ICN network domain or global ICN network domain, new protocols and semantics must be designed and implemented to manage and resolve names among different namespaces.
ローカルICNネットワークドメインまたはグローバルICNネットワークドメイン内でNRSシステムを開発するには、異なる名前空間間の名前を管理および解決するために、新しいプロトコルとセマンティクスを設計および実装する必要があります。
One way of implementing an NRS for CCNx is by extending the basic TLV format and semantics [RFC8569] [RFC8609]. For instance, name resolution and response messages can be implemented by defining new type fields in the Interest and Content Object messages [CCNxNRS]. By leveraging the existing CCNx Interest and Content Object packets for name resolution and registration, the NRS system can be deployed with a few ICN protocol changes. However, because of confining the changes to the basic ICN protocol and semantics, the NRS system may not be able to exploit more flexible and scalable designs.
CCNXのNRSを実装する1つの方法は、基本的なTLV形式とセマンティクス[RFC8569] [RFC8609]を拡張することです。たとえば、対象とコンテンツオブジェクトメッセージ[CCNXNRS]で新しいタイプフィールドを定義することにより、名前の解決と応答メッセージを実装できます。名前の解決と登録のために既存のCCNX関心とコンテンツオブジェクトパケットを活用することにより、NRSシステムをいくつかのICNプロトコルの変更で展開できます。ただし、基本的なICNプロトコルとセマンティクスへの変更を制限するため、NRSシステムは、より柔軟でスケーラブルな設計を活用できない可能性があります。
On the other hand, an NRS system can be designed independently with its own protocol and semantics like the NRS system described in [Hong]. For instance, the NRS protocol and messages can be implemented by using a RESTful API, and the NRS can be operated as an application protocol independent of the rest of the ICN protocol.
一方、NRSシステムは、[Hong]で説明されているNRSシステムのような独自のプロトコルとセマンティクスで独立して設計できます。たとえば、NRSプロトコルとメッセージは、RESTFUL APIを使用して実装でき、NRSはICNプロトコルの残りの部分とは無関係にアプリケーションプロトコルとして操作できます。
An NRS reduces the routing complexity of ICN architecture compared to pure name-based routing. It does so by permitting the routing system to update the routing table on demand with the help of name records obtained from NRS. The routing system therefore needs to make name resolution requests and process the information returned, such as a prefix, a locator, an off-path-cache pointer, or an alias name, obtained from the name resolution.
NRSは、純粋な名前ベースのルーティングと比較して、ICNアーキテクチャのルーティングの複雑さを減らします。これは、NRSから取得した名前のレコードの助けを借りて、ルーティングシステムがオンデマンドでルーティングテーブルを更新することを許可することにより行います。したがって、ルーティングシステムは、名前の解決策、ロケーター、オフパスキャッシュポインター、または名前解像度から取得したエイリアス名など、返される情報を処理し、処理する必要があります。
No matter what kind of information is obtained from the name resolution, as long as it is in the form of a name, the content request message in the routing system may be reformatted with the obtained information. In this case, the content name requested originally by a consumer needs to be involved in the reformatted content request to check the integrity of the binding between the name and the requested content. In other words, the information obtained from the name resolution is used to forward the content request, and the original content name requested by a consumer is used to identify the content. Alternatively, the resolved information may be used to build the routing table.
名前の解像度からどのような情報が得られても、名前の形式である限り、ルーティングシステムのコンテンツ要求メッセージは、取得した情報で再フォーマットされる場合があります。この場合、元々消費者が要求したコンテンツ名は、名前と要求されたコンテンツの間のバインディングの完全性を確認するために、再フォーマットコンテンツ要求に関与する必要があります。言い換えれば、名前の解決から得られた情報は、コンテンツ要求を転送するために使用され、消費者が要求した元のコンテンツ名はコンテンツを識別するために使用されます。あるいは、解決された情報を使用して、ルーティングテーブルを構築することもできます。
The information obtained from name resolution may not be in the form of a name. For example, it may identify tunnel endpoints by IP address and instead be used to construct an IP protocol tunnel through which to forward the content request.
名前の解決から得られた情報は、名前の形ではない場合があります。たとえば、IPアドレスごとにトンネルエンドポイントを識別し、代わりにコンテンツリクエストを転送するためのIPプロトコルトンネルを構築するために使用できます。
A Name Resolution Service (NRS) is not a mandatory part in an ICN architecture, as the majority of ICN architectures use name-based routing that does not employ a name resolution procedure. However, such name-based routing in ICN has inherent challenges in enabling a globally scalable routing system, accommodating producer mobility, and supporting off-path caching. In order to address these challenges, an NRS system has been introduced in several ICN projects. Therefore, this document describes how the ICN architecture changes when an NRS is utilized and how this affects the ICN routing system.
ICNアーキテクチャの大部分は、名前解決手順を使用しない名前ベースのルーティングを使用しているため、名前解像度サービス（NRS）はICNアーキテクチャの必須部分ではありません。ただし、ICNのこのような名前ベースのルーティングには、グローバルにスケーラブルなルーティングシステムを有効にし、生産者のモビリティに対応し、オフパスキャッシュをサポートすることに固有の課題があります。これらの課題に対処するために、いくつかのICNプロジェクトでNRSシステムが導入されています。したがって、このドキュメントでは、NRSが利用されたときにICNアーキテクチャがどのように変化するか、これがICNルーティングシステムにどのように影響するかについて説明します。
The document defines a few terminologies related to an NRS and explains some inherent challenges of pure name-based routing in ICN such as routing scalability, producer mobility, and off-path caching. This document describes how the ICN architecture would change with respect to procedures, latency, and security when an NRS is utilized. According to the ICN architectural changes, this document describes ICN architectural considerations for NRS such as the functions related to the registration, resolution and update of name mapping records, protocols and semantics to implement an NRS system, and the routing system involving the name resolution.
このドキュメントは、NRSに関連するいくつかの用語を定義し、ルーティングのスケーラビリティ、生産者のモビリティ、オフパスキャッシュなど、ICNの純粋な名前ベースのルーティングのいくつかの固有の課題について説明します。このドキュメントでは、NRSが利用されたときの手順、遅延、セキュリティに関してICNアーキテクチャがどのように変化するかについて説明します。ICNアーキテクチャの変更によると、このドキュメントは、NRSシステムを実装するための名前マッピングレコード、プロトコル、セマンティクス、および名前解決を含むルーティングシステムの登録、解像度、および更新に関連する機能など、NRSのICNアーキテクチャに関する考慮事項について説明します。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
When any new component such as an NRS is introduced in the ICN architecture, the attack surface increases. The related security vulnerability issues are discussed below:
ICNアーキテクチャにNRSなどの新しいコンポーネントが導入されると、攻撃面が増加します。関連するセキュリティの脆弱性の問題については、以下で説明します。
Namespace security: In order to deploy an NRS system in ICN architecture, ICN namespaces, which may be assigned by authoritative entities, must be securely mapped to the content publishers and securely managed by them. According to the ICN research challenges [RFC7927], a new namespace can also provide an integrity verification function to authenticate its publisher. The issues of namespace authentication and the mapping among different namespaces require further investigation.
名前空間セキュリティ：ICNアーキテクチャにNRSシステムを展開するには、権威あるエンティティによって割り当てられるICNネームスペースは、コンテンツパブリッシャーに安全にマッピングし、それらによって安全に管理される必要があります。ICN Researchの課題[RFC7927]によると、新しい名前空間は、パブリッシャーを認証するための整合性検証関数を提供することもできます。名前空間認証の問題と異なる名前空間間のマッピングには、さらなる調査が必要です。
NRS system security: An NRS requires the deployment of new entities (e.g., NRS servers) to build distributed and scalable NRS systems. Thus, the entities, e.g., an NRS server maintaining a mapping database, could be the focus of attacks by receiving malicious requests from innumerable adversaries comprising of Denial-of-Service or Distributed-Denial-of-Service attacks. In addition, NRS clients in general must trust the NRS nodes in other network domains to some degree, and communication among them must also be protected securely to prevent malicious entities from participating in this communication. The history of name resolution data requires to be stored and analyzed as in passive DNS to uncover potential security incidents or discover malicious infrastructures.
NRSシステムセキュリティ：NRSでは、分散およびスケーラブルなNRSシステムを構築するために、新しいエンティティ（NRSサーバーなど）の展開が必要です。したがって、例えば、マッピングデータベースを維持するNRSサーバーなどのエンティティは、サービスの拒否または分散系サービス攻撃で構成される無数の敵から悪意のあるリクエストを受信することにより、攻撃の焦点となる可能性があります。さらに、一般にNRSクライアントは、他のネットワークドメインのNRSノードをある程度信頼する必要があり、それらの間のコミュニケーションは、悪意のあるエンティティがこのコミュニケーションに参加するのを防ぐために安全に保護する必要があります。名前解像度データの履歴は、受動的なDNSのように保存および分析する必要があります。
NRS protocol and message security: In an NRS system, the protocols to generate, transmit, and receive NRS messages related to the name registration, resolution, and record update should be protected by proper security mechanisms. Proper security measures must be provided so that only legitimate nodes can initiate and read NRS messages. These messages must be secured by integrity protection and authentication mechanisms so that unauthorized parties cannot manipulate them when being forwarded through the network. Security measures to encrypt these messages should also be developed to thwart all threats to both security and privacy. Numerous problems similar to the security issues of an IP network and DNS can affect the overall ICN architecture. The DNS QNAME minimization type of approach would be suitable for preserving privacy in the name resolution process. Therefore, security mechanisms such as accessibility, authentication, etc., for the NRS system [RFC9138] should be considered to protect not only the NRS system but also the ICN architecture overall.
NRSプロトコルとメッセージセキュリティ：NRSシステムでは、名前の登録、解像度、およびレコードの更新に関連するNRSメッセージを生成、送信、および受信するプロトコルは、適切なセキュリティメカニズムによって保護する必要があります。正当なノードのみがNRSメッセージを開始および読み取ることができるように、適切なセキュリティ対策を提供する必要があります。これらのメッセージは、不正な当事者がネットワークを介して転送されるときにそれらを操作できないように、整合性保護および認証メカニズムによって保護する必要があります。これらのメッセージを暗号化するためのセキュリティ対策は、セキュリティとプライバシーの両方に対するすべての脅威を阻止するために開発する必要があります。 IPネットワークとDNSのセキュリティ問題と同様の多くの問題は、ICNアーキテクチャ全体に影響を与える可能性があります。 DNS QNAME最小化アプローチのタイプは、名前解決プロセスでプライバシーを維持するのに適しています。したがって、NRSシステム[RFC9138]のアクセシビリティ、認証などのセキュリティメカニズムは、NRSシステムだけでなく、ICNアーキテクチャ全体も保護するために考慮する必要があります。
[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.、Sauce、D.、Schmidt、T。、およびM. Waehlisch、「情報中心」ネットワーキング（ICN）研究課題」、RFC 7927、DOI 10.17487/RFC7927、2016年7月、<https://www.rfc-editor.org/info/rfc7927>。
[RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric Networking (CCNx) Semantics", RFC 8569, DOI 10.17487/RFC8569, July 2019, <https://www.rfc-editor.org/info/rfc8569>.
[RFC8569] Mosko、M.、Solis、I。、およびC. Wood、「コンテンツ中心のネットワーキング（CCNX）セマンティクス」、RFC 8569、DOI 10.17487/RFC8569、2019年7月、<https：//www.rfc-editor.org/info/rfc8569>。
[RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric Networking (CCNx) Messages in TLV Format", RFC 8609, DOI 10.17487/RFC8609, July 2019, <https://www.rfc-editor.org/info/rfc8609>.
[RFC8609] Mosko、M.、Solis、I。、およびC. Wood、「TLV形式のコンテンツ中心のネットワーキング（CCNX）メッセージ」、RFC 8609、DOI 10.17487/RFC8609、2019年7月、<https：// www。rfc-editor.org/info/rfc8609>。
[RFC9138] Hong, J., You, T., Dong, L., Westphal, C., and B. Ohlman, "Design Considerations for Name Resolution Service in Information-Centric Networking (ICN)", RFC 9138, DOI 10.17487/RFC9138, December 2021, <https://www.rfc-editor.org/info/rfc9138>.
[RFC9138] Hong、J.、You、T.、Dong、L.、Westphal、C。、およびB. Ohlman、「情報中心ネットワーキング（ICN）における名前解決サービスの設計上の考慮事項」、RFC 9138、DOI 10.17487/RFC9138、2021年12月、<https://www.rfc-editor.org/info/rfc9138>。
[Afanasyev] Afanasyev, A., Yi, C., Wang, L., Zhang, B., and L. Zhang, "SNAMP: Secure namespace mapping to scale NDN forwarding", 2015 IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS), DOI 10.1109/INFCOMW.2015.7179398, April 2015, <https://doi.org/10.1109/INFCOMW.2015.7179398>.
[Afanasyev] Afanasyev、A.、Yi、C.、Wang、L.、Zhang、B。、およびL. Zhang、「Snamp：Secure Namespace Mapping to Scale NDN Forwarding」、2015 IEEE Conference on Computer Communications Workshops（InfoCom WKSHPS）、doi 10.1109/infcomw.2015.7179398、2015年4月、<https://doi.org/10.1109/infcomw.2015.7179398>。
[Bayhan] Bayhan, S., Ott, J., Kangasharju, J., Sathiaseelan, A., and J. Crowcroft, "On Content Indexing for Off-Path Caching in Information-Centric Networks", ACM ICN, DOI 10.1145/2984356.2984372, September 2016, <https://doi.org/10.1145/2984356.2984372>.
[Bayhan] Bayhan、S.、Ott、J.、Kangasharju、J.、Sathiaseelan、A。、およびJ. Crowcroft、「情報中心のネットワークでのオフパスキャッシュのコンテンツインデックスについて」、ACM ICN、DOI 10.1145/2984356.2984372、2016年9月、<https://doi.org/10.1145/2984356.2984372>。
[CCNx] "Cicn", <https://wiki.fd.io/view/Cicn>.
[ccnx] "cicn"、<https://wiki.fd.io/view/cicn>。
[CCNxNRS] Hong, J., You, T., and Y. Hong, "CCNx Extension for Name Resolution Service", Work in Progress, Internet-Draft, draft-hong-icnrg-ccnx-nrs-02, 2 July 2018, <https://datatracker.ietf.org/doc/html/draft-hong-icnrg-ccnx-nrs-02>.
[CCNXNRS] Hong、J.、You、T.、Y。Hong、「名前解決サービスのccnx拡張」、進行中の作業、インターネットドラフト、ドラフトホン-ホン-ICNRG-CCNX-NRS-02、2018年7月2日、<https://datatracker.ietf.org/doc/html/draft-hong-icnrg-ccnx-nrs-02>。
[Dannewitz] Dannewitz, C., Kutscher, D., Ohlman, B., Farrell, S., Ahlgren, B., and H. Karl, "Network of Information (NetInf) - An information-centric networking architecture", Computer Communications vol. 36, issue 7, DOI 10.1016/j.comcom.2013.01.009, April 2013, <https://doi.org/10.1016/j.comcom.2013.01.009>.
[Dannewitz] Dannewitz、C.、Kutscher、D.、Ohlman、B.、Farrell、S.、Ahlgren、B。、およびH. Karl、「Network of Information（NetInf） - 情報中心のネットワーキングアーキテクチャ」、コンピューターCommunications Vol。36、第7号、DOI 10.1016/j.comcom.2013.01.009、2013年4月、<https://doi.org/10.1016/j.comcom.2013.01.009>。
[Dannewitz2] Dannewitz, C., D'Ambrosio, M., and V. Vercellone, "Hierarchical DHT-based name resolution for information-centric networks", Computer Communications vol. 36, issue 7, DOI 10.1016/j.comcom.2013.01.014, April 2013, <https://doi.org/10.1016/j.comcom.2013.01.014>.
[Dannewitz2] Dannewitz、C.、D'Ambrosio、M。、およびV. Vercellone、「情報中心ネットワークの階層DHTベースの名前解像度」、Computer Communications Vol。36、第7号、DOI 10.1016/j.comcom.2013.01.014、2013年4月、<https://doi.org/10.1016/j.comcom.2013.01.014>。
[Hong] Hong, J., Chun, W., and H. Jung, "Demonstrating a Scalable Name Resolution System for Information-Centric Networking", ACM ICN, DOI 10.1145/2810156.2812617, September 2015, <https://doi.org/10.1145/2810156.2812617>.
[Hong] Hong、J.、Chun、W。、およびH. Jung、「情報中心のネットワーキングのためのスケーラブルな名前解像度システムの実証」、ACM ICN、DOI 10.1145/2810156.2812617、2015年9月、<https：// doi。org/10.1145/2810156.2812617>。
[MF] Future Internet Architecture (FIA), "MobilityFirst", <http://mobilityfirst.cs.umass.edu/>.
[MF]将来のインターネットアーキテクチャ（FIA）、「MobilityFirst」、<http://mobilityfirst.cs.umass.edu/>。
[NDN] NDN, "Named Data Networking", September 2010, <https://www.named-data.net>.
[ndn] ndn、「名前付きデータネットワーキング」、2010年9月、<https://www.named-data.net>。
[Ravindran] Ravindran, R., Chakraborti, A., and A. Azgin, "Forwarding Label support in CCN Protocol", Work in Progress, Internet-Draft, draft-ravi-icnrg-ccn-forwarding-label-02, 5 March 2018, <https://datatracker.ietf.org/doc/html/ draft-ravi-icnrg-ccn-forwarding-label-02>.
[Ravindran] Ravindran、R.、Chakraborti、A。、およびA. Azgin、「CCN Protocolでの転送ラベルサポート」、Work in Progress、Internet-Draft、Draft-Ravi-ICNRG-CCN-Forwarding-Label-02、52018年3月、<https://datatracker.ietf.org/doc/html/ draft-ravi-icnrg-ccn-forwarding-label-02>。
[SAIL] "Scalable and Adaptive Internet Solutions (SAIL)", <https://www.sail-project.eu/>.
[SAIL]「スケーラブルで適応性のあるインターネットソリューション（SAIL）」、<https://www.sail-project.eu/>。
[Zhang2] Zhang, Y., Afanasyev, A., Burke, J., and L. Zhang, "A Survey of Mobility Support in Named Data Networking", Named Data Networking, Workshop on Name-Oriented Mobility: Architecture, Algorithms and Applications (NOM), April 2016.
[Zhang2] Zhang、Y.、Afanasyev、A.、Burke、J。、およびL. Zhang、「名前付きデータネットワーキングにおけるモビリティサポートの調査」、名前付きデータネットワーキング、名前指向のモビリティに関するワークショップ：アーキテクチャ、アルゴリズム、および申請（NOM）、2016年4月。
Acknowledgements
謝辞
The authors would like to thank Dave Oran (ICNRG Co-chair) for very useful reviews and comments, which helped to immeasurably improve this document.
著者は、非常に有用なレビューとコメントについて、Dave Oran（ICNRGの共同議長）に感謝したいと思います。
Authors' Addresses
著者のアドレス
Jungha Hong ETRI Yuseung-Gu 218 Gajeong-ro Daejeon 34129 Republic of Korea Email: jhong@etri.re.kr
Jungha Hong Etri Yusung-Gu 218 Gajeong-Ro Daejeon 34129韓国共和国メールメール：jhong@etri.re.kr
Tae-Wan You ETRI Yuseung-Gu 218 Gajeong-ro Daejeon 34129 Republic of Korea Email: twyou@etri.re.kr
Tae-Wan You Etri Yusung-gu 218 Gajeong-ro Daejeon 34129韓国共和国メールメール：twyou@etri.re.kr
Ved Kafle NICT Koganei 4-2-1 Nukui-Kitamachi, Tokyo 184-8795 Japan Email: kafle@nict.go.jp
Ved Kafle Nict Koganei 4-2-1 Nukui-Kitamachi、Tokyo 184-8795日本メール：kafle@nict.go.jp