RFC 8799 - Limited Domains and Internet Protocols 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc8799.html
タイトル : RFC 8799 - 制限されたドメインとインターネットプロトコル
翻訳編集 : 自動生成

[要約] RFC 8799は、制限されたドメインとインターネットプロトコルに関するガイドラインです。その目的は、特定のドメイン内でのネットワークプロトコルの使用を制限し、セキュリティとパフォーマンスを向上させることです。

Independent Submission                                      B. Carpenter
Request for Comments: 8799                             Univ. of Auckland
Category: Informational                                           B. Liu
ISSN: 2070-1721                                      Huawei Technologies
                                                               July 2020

Limited Domains and Internet Protocols

制限されたドメインとインターネットプロトコル

Abstract

概要

There is a noticeable trend towards network behaviors and semantics that are specific to a particular set of requirements applied within a limited region of the Internet. Policies, default parameters, the options supported, the style of network management, and security requirements may vary between such limited regions. This document reviews examples of such limited domains (also known as controlled environments), notes emerging solutions, and includes a related taxonomy. It then briefly discusses the standardization of protocols for limited domains. Finally, it shows the need for a precise definition of "limited domain membership" and for mechanisms to allow nodes to join a domain securely and to find other members, including boundary nodes.

インターネットの限られた地域内で適用される特定の要件セットに固有のネットワークの動作とセマンティクスへの注目すべき傾向があります。ポリシー、デフォルトパラメータ、サポートされるオプション、ネットワーク管理のスタイル、およびセキュリティ要件は、このような限られた地域間で異なる場合があります。このドキュメントでは、そのような制限されたドメイン（制御された環境とも呼ばれます）の例を確認し、新たなソリューションについて説明し、関連する分類法を示します。次に、限られたドメインのプロトコルの標準化について簡単に説明します。最後に、「制限されたドメインメンバーシップ」の正確な定義と、ノードがドメインに安全に参加し、境界ノードを含む他のメンバーを見つけることができるメカニズムの必要性を示しています。

This document is the product of the research of the authors. It has been produced through discussions and consultation within the IETF but is not the product of IETF consensus.

この文書は著者の研究の産物です。これは、IETF内での議論および協議を通じて作成されましたが、IETFの合意の産物ではありません。

Status of This Memo

このメモのステータス

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。

This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.

これは、他のRFCストリームとは関係なく、RFCシリーズへの貢献です。 RFC Editorは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc8799.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8799で入手できます。

著作権表示

著作権（c）2020 IETFトラストおよび文書の作成者として識別された人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。

Table of Contents

1. Introduction 2. Failure Modes in Today's Internet 3. Examples of Limited Domain Requirements 4. Examples of Limited Domain Solutions 5. The Scope of Protocols in Limited Domains 6. Functional Requirements of Limited Domains 7. Security Considerations 8. IANA Considerations 9. Informative References Appendix A. Taxonomy of Limited Domains A.1. Domain as a Whole A.2. Individual Nodes A.3. Domain Boundary A.4. Topology A.5. Technology A.6. Connection to the Internet A.7. Security, Trust, and Privacy Model A.8. Operations A.9. Making Use of This Taxonomy Acknowledgements Contributors Authors' Addresses

1. はじめに2.今日のインターネットの障害モード3.制限付きドメイン要件の例4.制限付きドメインソリューションの例5.制限付きドメインでのプロトコルの範囲6.制限付きドメインの機能要件7.セキュリティに関する考慮事項8. IANAに関する考慮事項9.参考情報付録A.限定ドメインの分類A.1。全体としてのドメインA.2。個々のノードA.3。ドメイン境界A.4。トポロジA.5。テクノロジーA.6。インターネットへの接続A.7。セキュリティ、信頼、プライバシーモデルA.8。オペレーションA.9。この分類法の謝辞を利用する寄稿者著者のアドレス

1. Introduction

1. はじめに

As the Internet continues to grow and diversify, with a realistic prospect of tens of billions of nodes being connected directly and indirectly, there is a noticeable trend towards network-specific and local requirements, behaviors, and semantics. The word "local" should be understood in a special sense, however. In some cases, it may refer to geographical and physical locality -- all the nodes in a single building, on a single campus, or in a given vehicle. In other cases, it may refer to a defined set of users or nodes distributed over a much wider area, but drawn together by a single virtual network over the Internet, or a single physical network running in parallel with the Internet. We expand on these possibilities below. To capture the topic, this document refers to such networks as "limited domains". Of course, a similar situation may arise for a network that is completely disconnected from the Internet, but that is not our direct concern here. However, it should not be forgotten that interoperability is needed even within a disconnected network.

数百億のノードが直接的および間接的に接続されるという現実的な見通しとともに、インターネットが成長および多様化し続けるにつれて、ネットワーク固有およびローカルの要件、動作、およびセマンティクスへの注目すべき傾向があります。ただし、「ローカル」という言葉は特別な意味で理解する必要があります。場合によっては、地理的および物理的な局所性、つまり、単一の建物内、単一のキャンパス内、または特定の車両内のすべてのノードを指す場合があります。他の場合では、はるかに広い範囲に分散しているが、インターネット上の単一の仮想ネットワーク、またはインターネットと並行して実行されている単一の物理ネットワークによってまとめられた、定義済みのユーザーまたはノードのセットを指す場合があります。以下でこれらの可能性について詳しく説明します。トピックを把握するために、このドキュメントでは「限定ドメイン」などのネットワークを参照しています。もちろん、インターネットから完全に切断されたネットワークでも同様の状況が発生する可能性がありますが、ここでは直接の懸念はありません。ただし、切断されたネットワーク内でも相互運用性が必要であることを忘れないでください。

Some people have concerns about splintering of the Internet along political or linguistic boundaries by mechanisms that block the free flow of information. That is not the topic of this document, which does not discuss filtering mechanisms (see [RFC7754]) and does not apply to protocols that are designed for use across the whole Internet. It is only concerned with domains that have specific technical requirements.

一部の人々は、情報の自由な流れをブロックするメカニズムによって、政治的または言語的境界に沿ってインターネットが分裂することについて懸念を持っています。これは、フィルタリングのメカニズム（[RFC7754]を参照）については説明しておらず、インターネット全体で使用するように設計されたプロトコルには適用されない、このドキュメントのトピックではありません。これは、特定の技術要件を持つドメインにのみ関係しています。

The word "domain" in this document does not refer to naming domains in the DNS, although in some cases, a limited domain might incidentally be congruent with a DNS domain. In particular, with a "split horizon" DNS configuration [RFC6950], the split might be at the edge of a limited domain. A recent proposal for defining definite perimeters within the DNS namespace [DNS-PERIMETER] might also be considered to be a limited domain mechanism.

このドキュメントの「ドメイン」という言葉は、DNSのドメインの命名を指すものではありませんが、場合によっては、制限されたドメインが偶発的にDNSドメインと一致することがあります。特に、「スプリットホライズン」DNS構成[RFC6950]では、スプリットが制限されたドメインのエッジにある可能性があります。 DNS名前空間[DNS-PERIMETER]内で明確な境界を定義するための最近の提案も、制限されたドメインメカニズムと見なされる場合があります。

Another term that has been used in some contexts is "controlled environment". For example, [RFC8085] uses this to delimit the operational scope within which a particular tunnel encapsulation might be used. A specific example is GRE-in-UDP encapsulation [RFC8086], which explicitly states that "The controlled environment has less restrictive requirements than the general Internet." For example, non-congestion-controlled traffic might be acceptable within the controlled environment. The same phrase has been used to delimit the useful scope of quality-of-service protocols [RFC6398]. It is not necessarily the case that protocols will fail to operate outside the controlled environment, but rather that they might not operate optimally. In this document, we assume that "limited domain" and "controlled environment" mean the same thing in practice. The term "managed network" has been used in a similar way, e.g., [RFC6947]. In the context of secure multicast, a "group domain of interpretation" is defined by [RFC6407].

一部のコンテキストで使用されている別の用語は、「制御された環境」です。たとえば、[RFC8085]はこれを使用して、特定のトンネルカプセル化が使用される可能性のある動作範囲を区切ります。具体的な例は、GRE-in-UDPカプセル化[RFC8086]であり、「制御された環境の要件は、一般的なインターネットよりも制限が少ない」と明記されています。たとえば、輻輳が制御されていないトラフィックは、制御された環境内で許容できる場合があります。同じフレーズが、サービス品質プロトコルの有効範囲を区切るために使用されています[RFC6398]。プロトコルが制御された環境外で動作しない場合は必ずしもそうとは限りませんが、プロトコルが最適に動作しない場合があります。このドキュメントでは、「制限されたドメイン」と「制御された環境」は実際には同じことを意味すると想定しています。「管理されたネットワーク」という用語は、[RFC6947]など、同様の方法で使用されています。安全なマルチキャストのコンテキストでは、「グループドメイン解釈」は[RFC6407]によって定義されます。

Yet more definitions of types of domains are to be found in the routing area, such as [RFC4397], [RFC4427], and [RFC4655]. We conclude that the notion of a limited domain is very widespread in many aspects of Internet technology.

[RFC4397]、[RFC4427]、[RFC4655]など、ドメインのタイプのさらに多くの定義がルーティングエリアにあります。制限されたドメインの概念はインターネット技術の多くの面で非常に広まっていると私たちは結論付けます。

The requirements of limited domains will depend on the deployment scenario. Policies, default parameters, and the options supported may vary. Also, the style of network management may vary between a completely unmanaged network, one with fully autonomic management, one with traditional central management, and mixtures of the above. Finally, the requirements and solutions for security and privacy may vary.

限られたドメインの要件は、展開シナリオによって異なります。ポリシー、デフォルトパラメータ、およびサポートされるオプションは異なる場合があります。また、ネットワーク管理のスタイルは、完全に管理されていないネットワーク、完全に自律的な管理のネットワーク、従来の中央管理のネットワーク、およびこれらの混合によって異なります。最後に、セキュリティとプライバシーの要件とソリューションは異なる場合があります。

This document analyzes and discusses some of the consequences of this trend and how it may impact the idea of universal interoperability in the Internet. First, we list examples of limited domain scenarios and of technical solutions for limited domains, with the main focus being the Internet layer of the protocol stack. An appendix provides a taxonomy of the features to be found in limited domains. With this background, we discuss the resulting challenge to the idea that all Internet standards must be universal in scope and applicability. To the contrary, we assert that some protocols, although needing to be standardized and interoperable, also need to be specifically limited in their applicability. This implies that the concepts of a limited domain, and of its membership, need to be formalized and supported by secure mechanisms. While this document does not propose a design for such mechanisms, it does outline some functional requirements.

このドキュメントでは、この傾向の結果の一部と、それがインターネットの普遍的な相互運用性の考え方にどのように影響するかを分析して説明します。最初に、制限されたドメインのシナリオと制限されたドメインの技術ソリューションの例をリストします。主な焦点はプロトコルスタックのインターネットレイヤーです。付録では、限定されたドメインで見つかる機能の分類を提供しています。このような背景から、すべてのインターネット標準は適用範囲と適用範囲において普遍的でなければならないという考えに対する結果としての課題について説明します。逆に、一部のプロトコルは、標準化され相互運用可能である必要がありますが、その適用性も特に制限する必要があると主張します。これは、制限されたドメインとそのメンバーシップの概念を、安全なメカニズムによって形式化してサポートする必要があることを意味します。このドキュメントでは、そのようなメカニズムの設計を提案していませんが、いくつかの機能要件の概要を説明しています。

This document is the product of the research of the authors. It has been produced through discussions and consultation within the IETF but is not the product of IETF consensus.

この文書は著者の研究の産物です。これは、IETF内での議論および協議を通じて作成されましたが、IETFの合意の産物ではありません。

2. Failure Modes in Today's Internet

2. 今日のインターネットの障害モード

Today, the Internet does not have a well-defined concept of limited domains. One result of this is that certain protocols and features fail on certain paths. Earlier analyses of this topic have focused either on the loss of transparency of the Internet [RFC2775] [RFC4924] or on the middleboxes responsible for that loss [RFC3234] [RFC7663] [RFC8517]. Unfortunately, the problems persist both in application protocols and even in very fundamental mechanisms. For example, the Internet is not transparent to IPv6 extension headers [RFC7872], and Path MTU Discovery has been unreliable for many years [RFC2923] [RFC4821]. IP fragmentation is also unreliable [FRAG-FRAGILE], and problems in TCP MSS negotiation have been reported [IPV6-USE-MINMTU].

今日、インターネットには、限定されたドメインという明確に定義された概念がありません。この結果、特定のプロトコルと機能が特定のパスで失敗します。このトピックの以前の分析は、インターネットの透明性の喪失[RFC2775] [RFC4924]またはその喪失の原因であるミドルボックス[RFC3234] [RFC7663] [RFC8517]に焦点を当てています。残念ながら、問題はアプリケーションプロトコルと非常に基本的なメカニズムの両方に存在します。たとえば、インターネットはIPv6拡張ヘッダー[RFC7872]に対して透過的ではなく、パスMTUディスカバリは長年にわたって信頼できませんでした[RFC2923] [RFC4821]。 IPフラグメンテーションも信頼できない[FRAG-FRAGILE]であり、TCP MSSネゴシエーションの問題が報告されている[IPV6-USE-MINMTU]。

On the security side, the widespread insertion of firewalls at domain boundaries that are perceived by humans but unknown to protocols results in arbitrary failure modes as far as the application layer is concerned. There are operational recommendations and practices that effectively guarantee arbitrary failures in realistic scenarios [IPV6-EXT-HEADERS].

セキュリティの側面では、ドメインの境界にファイアウォールが広く挿入されているため、人間には知覚されているがプロトコルでは認識されないため、アプリケーション層に関する限り、任意の障害モードが発生します。現実的なシナリオ[IPV6-EXT-HEADERS]で任意の障害を効果的に保証する運用上の推奨事項と実践があります。

Domain boundaries that are defined administratively (e.g., by address filtering rules in routers) are prone to leakage caused by human error, especially if the limited domain traffic appears otherwise normal to the boundary routers. In this case, the network operator needs to take active steps to protect the boundary. This form of leakage is much less likely if nodes must be explicitly configured to handle a given limited-domain protocol, for example, by installing a specific protocol handler.

管理上（ルーターのアドレスフィルタリングルールなど）によって定義されたドメイン境界は、特に制限されたドメイントラフィックが境界ルーターに対して正常であるように見える場合は特に、人為的エラーによってリークが発生しやすくなります。この場合、ネットワークオペレータは境界を保護するためにアクティブな手順を実行する必要があります。特定のプロトコルハンドラーをインストールするなどして、ノードが特定の制限されたドメインプロトコルを処理するように明示的に構成する必要がある場合、この形式のリークははるかに発生しにくくなります。

Investigations of the unreliability of IP fragmentation [FRAG-FRAGILE] and the filtering of IPv6 extension headers [RFC7872] strongly suggest that at least for some protocol elements, transparency is a lost cause and middleboxes are here to stay. In the following two sections, we show that some application environments require protocol features that cannot, or should not, cross the whole Internet.

IPフラグメンテーションの信頼性に関する調査[FRAG-FRAGILE]およびIPv6拡張ヘッダーのフィルタリング[RFC7872]は、少なくとも一部のプロトコル要素では、透過性が失われた原因であり、ミドルボックスが残っていることを強く示唆しています。次の2つのセクションでは、一部のアプリケーション環境で、インターネット全体を通過できない、または通過できないプロトコル機能が必要であることを示します。

3. Examples of Limited Domain Requirements

3. 制限付きドメイン要件の例

This section describes various examples where limited domain requirements can easily be identified, either based on an application scenario or on a technical imperative. It is, of course, not a complete list, and it is presented in an arbitrary order, loosely from smaller to bigger.

このセクションでは、アプリケーションシナリオまたは技術的要請に基づいて、限られたドメイン要件を簡単に特定できるさまざまな例について説明します。もちろん、これは完全なリストではなく、小さいものから大きいものへと大まかに、任意の順序で示されています。

1. A home network. It will be mainly unmanaged, constructed by a non-specialist. It must work with devices "out of the box" as shipped by their manufacturers and must create adequate security by default. Remote access may be required. The requirements and applicable principles are summarized in [RFC7368].

1. ホームネットワーク。それは主に管理されていない、非専門家によって構築されます。メーカーから出荷された「そのまま」のデバイスで動作し、デフォルトで適切なセキュリティを作成する必要があります。リモートアクセスが必要な場合があります。要件と適用可能な原則は、[RFC7368]に要約されています。

2. A small office network. This is sometimes very similar to a home network, if whoever is in charge has little or no specialist knowledge, but may have differing security and privacy requirements. In other cases, it may be professionally constructed using recommended products and configurations but operate unmanaged. Remote access may be required.

2. 小規模オフィスネットワーク。担当者が専門知識をほとんどまたはまったく持たない場合でも、これはホームネットワークに非常に似ていますが、セキュリティとプライバシーの要件が異なる場合があります。他の場合では、推奨される製品と構成を使用して専門的に構築される場合がありますが、管理対象外で動作します。リモートアクセスが必要な場合があります。

3. A vehicle network. This will be designed by the vehicle manufacturer but may include devices added by the vehicle's owner or operator. Parts of the network will have demanding performance and reliability requirements with implications for human safety. Remote access may be required to certain functions but absolutely forbidden for others. Communication with other vehicles, roadside infrastructure, and external data sources will be required. See [IPWAVE-NETWORKING] for a survey of use cases.

3. 車両ネットワーク。これは車両メーカーによって設計されますが、車両の所有者またはオペレーターによって追加されたデバイスが含まれる場合があります。ネットワークの一部には、人間の安全に影響を与える厳しいパフォーマンスと信頼性の要件があります。特定の機能へのリモートアクセスが必要な場合がありますが、他の機能は絶対に禁止されています。他の車両、路側インフラ、外部データソースとの通信が必要になります。ユースケースの調査については、[IPWAVE-NETWORKING]を参照してください。

4. Supervisory Control And Data Acquisition (SCADA) networks and other hard real-time networks. These will exhibit specific technical requirements, including tough real-time performance targets. See, for example, [RFC8578] for numerous use cases. An example is a building services network. This will be designed specifically for a particular building but using standard components. Additional devices may need to be added at any time. Parts of the network may have demanding reliability requirements with implications for human safety. Remote access may be required to certain functions but absolutely forbidden for others. An extreme example is a network used for virtual reality or augmented reality applications where the latency requirements are very stringent.

4. 監視制御およびデータ収集（SCADA）ネットワークおよびその他のハードリアルタイムネットワーク。これらは、厳しいリアルタイムのパフォーマンス目標など、特定の技術要件を示します。多数の使用例については、たとえば、[RFC8578]を参照してください。例は、建物のサービスネットワークです。これは、特定の建物用に特別に設計されますが、標準コンポーネントを使用します。追加のデバイスはいつでも追加する必要がある場合があります。ネットワークの一部には、人間の安全に影響を与える厳しい信頼性要件があります。特定の機能へのリモートアクセスが必要な場合がありますが、他の機能は絶対に禁止されています。極端な例は、仮想現実や拡張現実アプリケーションに使用されるネットワークで、レイテンシ要件が非常に厳しいものです。

5. Sensor networks. The two preceding cases will all include sensors, but some networks may be specifically limited to sensors and the collection and processing of sensor data. They may be in remote or technically challenging locations and installed by non-specialists.

5. センサーネットワーク。前述の2つのケースにはすべてセンサーが含まれますが、一部のネットワークは、センサーとセンサーデータの収集および処理に特に限定される場合があります。それらは遠隔地または技術的に困難な場所にあり、非専門家によって設置される場合があります。

6. Internet-of-Things (IoT) networks. While this term is very flexible and covers many innovative types of networks, including ad hoc networks that are formed spontaneously and some applications of 5G technology, it seems reasonable to expect that IoT edge networks will have special requirements and protocols that are useful only within a specific domain, and that these protocols cannot, and for security reasons should not, run over the Internet as a whole.

6. モノのインターネット（IoT）ネットワーク。この用語は非常に柔軟であり、自発的に形成されるアドホックネットワークや5Gテクノロジーの一部のアプリケーションなど、多くの革新的なタイプのネットワークをカバーしますが、IoTエッジネットワークには特別な要件とプロトコルがあり、特定のドメイン、およびこれらのプロトコルは、全体としてインターネット上で実行することはできず、セキュリティ上の理由から実行してはなりません。

7. Constrained Networks. An important subclass of IoT networks consists of constrained networks [RFC7228] in which the nodes are limited in power consumption and communications bandwidth and are therefore limited to using very frugal protocols.

7. 制約付きネットワーク。 IoTネットワークの重要なサブクラスは、ノードの電力消費と通信帯域幅が制限されているため、非常に質素なプロトコルの使用に制限されている制約付きネットワーク[RFC7228]で構成されています。

8. Delay-tolerant networks. These may consist of domains that are relatively isolated and constrained in power (e.g., deep space networks) and are connected only intermittently to the outside, with a very long latency on such connections [RFC4838]. Clearly, the protocol requirements and possibilities are very specialized in such networks.

8. 遅延耐性ネットワーク。これらは、比較的分離されていて電力が制限されているドメイン（ディープスペースネットワークなど）で構成され、断続的にのみ外部に接続され、そのような接続では非常に長いレイテンシが発生します[RFC4838]。明らかに、プロトコルの要件と可能性は、そのようなネットワークに非常に特化しています。

9. "Traditional" enterprise and campus networks, which may be spread over many kilometers and over multiple separate sites, with multiple connections to the Internet. Interestingly, the IETF appears never to have analyzed this long-established class of networks in a general way, except in connection with IPv6 deployment (e.g., [RFC7381]).

9. 「伝統的な」企業およびキャンパスネットワーク。インターネットへの複数の接続を使用して、何キロメートルにもおよび複数の別々のサイトに広がる場合があります。興味深いことに、IETFは、IPv6の導入（[RFC7381]など）に関連する場合を除いて、この長く確立されたネットワークのクラスを一般的な方法で分析したことがないようです。

10. Unsuitable standards. A situation that can arise in an enterprise network is that the Internet-wide solution for a particular requirement may either fail locally or be much more complicated than is necessary. An example is that the complexity induced by a mechanism such as Interactive Connectivity Establishment (ICE) [RFC8445] is not justified within such a network. Furthermore, ICE cannot be used in some cases because candidate addresses are not known before a call is established, so a different local solution is essential [RFC6947].

10. 不適切な基準。企業ネットワークで発生する可能性のある状況は、特定の要件に対するインターネット全体のソリューションがローカルで失敗するか、必要以上に複雑になる可能性があることです。一例は、Interactive Connectivity Establishment（ICE）[RFC8445]などのメカニズムによって引き起こされる複雑さは、そのようなネットワーク内では正当化されないことです。さらに、コールが確立されるまで候補アドレスが不明であるため、ICEを使用できない場合があるため、別のローカルソリューションが不可欠です[RFC6947]。

11. Managed wide-area networks run by service providers for enterprise services such as Layer 2 (Ethernet, etc.) point-to-point pseudowires, multipoint Layer 2 Ethernet VPNs using Virtual Private LAN Service (VPLS) or Ethernet VPN (EVPN), and Layer 3 IP VPNs. These are generally characterized by service-level agreements for availability, packet loss, and possibly multicast service. These are different from the previous case in that they mostly run over MPLS infrastructures, and the requirements for these services are well defined by the IETF.

11. レイヤー2（イーサネットなど）ポイントツーポイント疑似配線、仮想プライベートLANサービス（VPLS）またはイーサネットVPN（EVPN）を使用するマルチポイントレイヤー2イーサネットVPNなどのエンタープライズサービスのためにサービスプロバイダーによって実行されるマネージド広域ネットワーク、およびレイヤ3 IP VPN。これらは一般に、可用性、パケット損失、および場合によってはマルチキャストサービスに関するサービスレベル契約によって特徴付けられます。これらは、ほとんどがMPLSインフラストラクチャ上で実行され、これらのサービスの要件がIETFによって適切に定義されているという点で、前のケースとは異なります。

12. Data centers and hosting centers, or distributed services acting as such centers. These will have high performance, security, and privacy requirements and will typically include large numbers of independent "tenant" networks overlaid on shared infrastructure.

12. データセンターとホスティングセンター、またはそのようなセンターとして機能する分散サービス。これらには、高いパフォーマンス、セキュリティ、プライバシー要件があり、通常、共有インフラストラクチャ上にオーバーレイされた多数の独立した「テナント」ネットワークが含まれます。

13. Content Delivery Networks (CDNs), comprising distributed data centers and the paths between them, spanning thousands of kilometers, with numerous connections to the Internet.

13. コンテンツ配信ネットワーク（CDN）。分散したデータセンターとそれらの間のパスで構成され、数千キロメートルに及び、インターネットへの多数の接続があります。

14. Massive Web Service Provider Networks. This is a small class of networks with well-known trademarked names, combining aspects of distributed enterprise networks, data centers, and CDNs. They have their own international networks bypassing the generic carriers. Like CDNs, they have numerous connections to the Internet, typically offering a tailored service in each economy.

14. 大規模なWebサービスプロバイダーネットワーク。これは、よく知られた商標名が付いた小さなクラスのネットワークであり、分散型エンタープライズネットワーク、データセンター、およびCDNの側面を組み合わせています。彼らはジェネリックキャリアをバイパスする独自の国際ネットワークを持っています。 CDNと同様に、インターネットへの接続が多数あり、通常、それぞれの経済に合わせたサービスを提供しています。

Three other aspects, while not tied to specific network types, also strongly depend on the concept of limited domains:

他の3つの側面は、特定のネットワークタイプに関連付けられていませんが、制限付きドメインの概念に強く依存しています。

1. Many of the above types of networks may be extended throughout the Internet by a variety of virtual private network (VPN) techniques. Therefore, we argue that limited domains may overlap each other in an arbitrary fashion by use of virtualization techniques. As noted above in the discussion of controlled environments, specific tunneling and encapsulation techniques may be tailored for use within a given domain.

1. 上記のタイプのネットワークの多くは、さまざまな仮想プライベートネットワーク（VPN）技術によってインターネット全体に拡張できます。したがって、仮想化技術を使用することにより、限られたドメインが任意の方法で互いにオーバーラップする可能性があると主張します。制御された環境の説明で前述したように、特定のトンネリングおよびカプセル化技術は、特定のドメイン内で使用するために調整できます。

2. Intent-Based Networking. In this concept, a network domain is configured and managed in accordance with an abstract policy known as "Intent" to ensure that the network performs as required [IBN-CONCEPTS]. Whatever technologies are used to support this will be applied within the domain boundary, even if the services supported in the domain are globally accessible.

2. インテントベースのネットワーキング。この概念では、ネットワークドメインは、「意図」と呼ばれる抽象的なポリシーに従って構成および管理され、ネットワークが必要に応じて実行されるようにします[IBN-CONCEPTS]。ドメインでサポートされているサービスがグローバルにアクセス可能であっても、これをサポートするために使用されるテクノロジーはすべてドメイン境界内で適用されます。

3. Network Slicing. A network slice is a form of virtual network that consists of a managed set of resources carved off from a larger network [ENHANCED-VPN]. This is expected to be significant in 5G deployments [USER-PLANE-PROTOCOL]. Whatever technologies are used to support slicing will require a clear definition of the boundary of a given slice within a larger domain.

3. ネットワークスライシング。ネットワークスライスは仮想ネットワークの一種であり、大規模なネットワーク[ENHANCED-VPN]から切り離されたリソースの管理対象セットで構成されます。これは、5G展開で重要になると予想されます[USER-PLANE-PROTOCOL]。スライスをサポートするためにどのようなテクノロジーを使用する場合でも、より大きなドメイン内の特定のスライスの境界を明確に定義する必要があります。

While it is clearly desirable to use common solutions, and therefore common standards, wherever possible, it is increasingly difficult to do so while satisfying the widely varying requirements outlined above. However, there is a tendency when new protocols and protocol extensions are proposed to always ask the question "How will this work across the open Internet?" This document suggests that this is not always the best question. There are protocols and extensions that are not intended to work across the open Internet. On the contrary, their requirements and semantics are specifically limited (in the sense defined above).

可能な限り共通のソリューション、つまり共通の標準を使用することが明らかに望ましいですが、上で概説したさまざまな要件を満たす一方で、そうすることはますます困難になっています。ただし、新しいプロトコルとプロトコル拡張が提案され、常に「オープンインターネット上でこれがどのように機能するか」という質問をする傾向がある。このドキュメントは、これが常に最良の質問であるとは限らないことを示唆しています。オープンインターネット上で機能することを目的としていないプロトコルと拡張機能があります。それどころか、それらの要件とセマンティクスは（上記で定義した意味で）具体的に制限されています。

A common argument is that if a protocol is intended for limited use, the chances are very high that it will in fact be used (or misused) in other scenarios including the so-called open Internet. This is undoubtedly true and means that limited use is not an excuse for bad design or poor security. In fact, a limited use requirement potentially adds complexity to both the protocol and its security design, as discussed later.

一般的な議論は、プロトコルが限定された使用を目的としている場合、いわゆるオープンインターネットを含む他のシナリオで実際に使用（または誤用）される可能性が非常に高いということです。これは間違いなく真実であり、制限された使用が悪い設計または不十分なセキュリティの言い訳にはならないことを意味します。実際、使用制限があるため、プロトコルとそのセキュリティ設計の両方が複雑になる可能性があります。これについては、後で説明します。

Nevertheless, because of the diversity of limited domains with specific requirements that is now emerging, specific standards (and ad hoc standards) will probably emerge for different types of domains. There will be attempts to capture each market sector, but the market will demand standardized solutions within each sector. In addition, operational choices will be made that can in fact only work within a limited domain. The history of RSVP [RFC2205] illustrates that a standard defined as if it could work over the open Internet might not in fact do so. In general, we can no longer assume that a protocol designed according to classical Internet guidelines will in fact work reliably across the network as a whole. However, the "open Internet" must remain as the universal method of interconnection. Reconciling these two aspects is a major challenge.

それにもかかわらず、現在出現している特定の要件を持つ限定されたドメインの多様性のために、特定の標準（およびアドホック標準）は、おそらく異なるタイプのドメインに対して現れるでしょう。各市場セクターを捉えようとする試みがありますが、市場は各セクター内の標準化されたソリューションを要求します。さらに、実際には限られたドメイン内でのみ機能する運用上の選択が行われます。 RSVP [RFC2205]の歴史は、あたかもオープンインターネット上で機能するかのように定義された標準が実際には機能しない可能性があることを示しています。一般に、従来のインターネットガイドラインに従って設計されたプロトコルが実際にネットワーク全体で確実に機能するとは、もはや想定できません。しかし、「オープンインターネット」は相互接続の普遍的な方法として残っていなければなりません。これら2つの側面を両立させることは、大きな課題です。

4. Examples of Limited Domain Solutions

4. 限定ドメインソリューションの例

This section lists various examples of specific limited domain solutions that have been proposed or defined. It intentionally does not include Layer 2 technology solutions, which by definition apply to limited domains. It is worth noting, however, that with recent developments such as Transparent Interconnection of Lots of Links (TRILL) [RFC6325] or Shortest Path Bridging [SPB], Layer 2 domains may become very large.

このセクションでは、提案または定義されている特定の限定ドメインソリューションのさまざまな例を示します。意図的に、限定されたドメインに適用されるレイヤ2テクノロジーソリューションは含まれていません。ただし、リンクの透過的な相互接続（TRILL）[RFC6325]または最短パスブリッジ[SPB]などの最近の開発では、レイヤー2ドメインが非常に大きくなる可能性があることに注意してください。

1. Differentiated Services. This mechanism [RFC2474] allows a network to assign locally significant values to the 6-bit Differentiated Services Code Point field in any IP packet. Although there are some recommended code point values for specific per-hop queue management behaviors, these are specifically intended to be domain-specific code points with traffic being classified, conditioned, and mapped or re-marked at domain boundaries (unless there is an inter-domain agreement that makes mapping or re-marking unnecessary).

1. 差別化サービス。このメカニズム[RFC2474]により、ネットワークは任意のIPパケットの6ビットのDiffServコードポイントフィールドにローカルで重要な値を割り当てることができます。特定のホップ単位のキュー管理動作に推奨されるコードポイント値がいくつかありますが、これらは特にドメイン固有のコードポイントであり、ドメイン境界でトラフィックが分類、条件付け、マッピング、または再マーキングされることを意図しています（インター-マッピングまたは再マーキングを不要にするドメイン契約。

2. Integrated Services. Although it is not intrinsic in the design of RSVP [RFC2205], it is clear from many years' experience that Integrated Services can only be deployed successfully within a limited domain that is configured with adequate equipment and resources.

2. 統合サービス。 RSVP [RFC2205]の設計に固有のものではありませんが、統合サービスは、適切な機器とリソースで構成された限られたドメイン内でのみ正常に展開できることが長年の経験から明らかです。

3. Network function virtualization. As described in [RFC8568], this general concept is an open research topic in which virtual network functions are orchestrated as part of a distributed system. Inevitably, such orchestration applies to an administrative domain of some kind, even though cross-domain orchestration is also a research area.

3. ネットワーク機能の仮想化。 [RFC8568]で説明されているように、この一般的な概念は、仮想ネットワーク機能が分散システムの一部として編成されるオープンな研究トピックです。クロスドメインオーケストレーションも研究領域ですが、必然的に、このようなオーケストレーションは何らかの管理ドメインに適用されます。

4. Service Function Chaining (SFC). This technique [RFC7665] assumes that services within a network are constructed as sequences of individual service functions within a specific SFC-enabled domain such as a 5G domain. As that RFC states: "Specific features may need to be enforced at the boundaries of an SFC-enabled domain, for example to avoid leaking SFC information". A Network Service Header (NSH) [RFC8300] is used to encapsulate packets flowing through the service function chain: "The intended scope of the NSH is for use within a single provider's operational domain."

4. サービス機能連鎖（SFC）。この手法[RFC7665]は、ネットワーク内のサービスが、5Gドメインなどの特定のSFC対応ドメイン内の個々のサービス機能のシーケンスとして構築されることを前提としています。そのRFCが述べているように、「特定の機能は、SFCが有効なドメインの境界で適用される必要があるかもしれません。たとえば、SFC情報の漏洩を回避するために」。ネットワークサービスヘッダー（NSH）[RFC8300]は、サービス機能チェーンを流れるパケットをカプセル化するために使用されます：「NSHの意図されたスコープは、単一のプロバイダーの運用ドメイン内で使用するためのものです。」

5. Firewall and Service Tickets (FAST). Such tickets would accompany a packet to claim the right to traverse a network or request a specific network service [FAST]. They would only be meaningful within a particular domain.

5. ファイアウォールとサービスチケット（FAST）。このようなチケットは、ネットワークを通過する権利または特定のネットワークサービスを要求する権利を主張するパケットに付随します[FAST]。特定のドメイン内でのみ意味があります。

6. Data Center Network Virtualization Overlays. A common requirement in data centers that host many tenants (clients) is to provide each one with a secure private network, all running over the same physical infrastructure. [RFC8151] describes various use cases for this, and specifications are under development. These include use cases in which the tenant network is physically split over several data centers, but which must appear to the user as a single secure domain.

6. データセンターネットワーク仮想化オーバーレイ。多くのテナント（クライアント）をホストするデータセンターの一般的な要件は、それぞれに同じ物理インフラストラクチャ上で実行される安全なプライベートネットワークを提供することです。 [RFC8151]はこれのさまざまな使用例を説明しており、仕様は開発中です。これには、テナントネットワークが物理的に複数のデータセンターに分割されているが、ユーザーには単一の安全なドメインとして見える必要があるユースケースが含まれます。

7. Segment Routing. This is a technique that "steers a packet through an ordered list of instructions, called segments" [RFC8402]. The semantics of these instructions are explicitly local to a segment routing domain or even to a single node. Technically, these segments or instructions are represented as an MPLS label or an IPv6 address, which clearly adds a semantic interpretation to them within the domain.

7. セグメントルーティング。これは、「セグメントと呼ばれる、命令の順序付けられたリストを通じてパケットを操縦する」手法です[RFC8402]。これらの命令のセマンティクスは、セグメントルーティングドメインまたは単一のノードに対して明示的にローカルです。技術的には、これらのセグメントまたは命令はMPLSラベルまたはIPv6アドレスとして表され、ドメイン内のセマンティック解釈を明確に追加します。

8. Autonomic Networking. As explained in [REF-MODEL], an autonomic network is also a security domain within which an autonomic control plane [ACP] is used by autonomic service agents. These agents manage technical objectives, which may be locally defined, subject to domain-wide policy. Thus, the domain boundary is important for both security and protocol purposes.

8. 自律型ネットワーキング。 [REF-MODEL]で説明されているように、オートノミックネットワークは、オートノミックサービスエージェントがオートノミックコントロールプレーン[ACP]を使用するセキュリティドメインでもあります。これらのエージェントは、ドメイン全体のポリシーに従って、ローカルで定義される可能性のある技術目標を管理します。したがって、ドメイン境界はセキュリティとプロトコルの両方の目的で重要です。

9. Homenet. As shown in [RFC7368], a home networking domain has specific protocol needs that differ from those in an enterprise network or the Internet as a whole. These include the Home Network Control Protocol (HNCP) [RFC7788] and a naming and discovery solution [HOMENET-NAMING].

9. ホームネット。 [RFC7368]に示されているように、ホームネットワーキングドメインには、企業ネットワークやインターネット全体とは異なる特定のプロトコルのニーズがあります。これらには、ホームネットワークコントロールプロトコル（HNCP）[RFC7788]と命名および検出ソリューション[HOMENET-NAMING]が含まれます。

10. Creative uses of IPv6 features. As IPv6 enters more general use, engineers notice that it has much more flexibility than IPv4. Innovative suggestions have been made for:

10. IPv6機能のクリエイティブな使用。 IPv6がより一般的に使用されるようになると、エンジニアはIPv4よりもはるかに柔軟性が高いことに気づきます。革新的な提案が行われました：

* The flow label, e.g., [RFC6294].

* フローラベル（例：[RFC6294]）。

* Extension headers, e.g., for segment routing [RFC8754] or Operations, Administration, and Maintenance (OAM) marking [IPV6-ALT-MARK].

* セグメントルーティング[RFC8754]または運用、管理、保守（OAM）マーキング[IPV6-ALT-MARK]などの拡張ヘッダー。

* Meaningful address bits, e.g., [EMBEDDED-SEMANTICS]. Also, segment routing uses IPv6 addresses as segment identifiers with specific local meanings [RFC8402].

* [EMBEDDED-SEMANTICS]などの意味のあるアドレスビット。また、セグメントルーティングは、特定のローカルな意味を持つセグメント識別子としてIPv6アドレスを使用します[RFC8402]。

* If segment routing is used for network programming [SRV6-NETWORK], IPv6 extension headers can support rather complex local functionality.

* セグメントルーティングがネットワークプログラミング[SRV6-NETWORK]に使用される場合、IPv6拡張ヘッダーはかなり複雑なローカル機能をサポートできます。

The case of the extension header is particularly interesting, since its existence has been a major "selling point" for IPv6, but new extension headers are notorious for being virtually impossible to deploy across the whole Internet [RFC7045] [RFC7872]. It is worth noting that extension header filtering is considered an important security issue [IPV6-EXT-HEADERS]. There is considerable appetite among vendors or operators to have flexibility in defining extension headers for use in limited or specialized domains, e.g., [IPV6-SRH], [BIGIP], and [APP-AWARE]. Locally significant hop-by-hop options are also envisaged, that would be understood by routers inside a domain but not elsewhere, e.g., [IN-SITU-OAM].

拡張ヘッダーの場合は、その存在がIPv6の主要な「セールスポイント」であるため、特に興味深いものですが、新しい拡張ヘッダーは、インターネット全体に展開することが事実上不可能であることで有名です[RFC7045] [RFC7872]。拡張ヘッダーのフィルタリングは重要なセキュリティ問題と見なされていることは注目に値します[IPV6-EXT-HEADERS]。 [IPV6-SRH]、[BIGIP]、[APP-AWARE]などの制限されたドメインや特殊なドメインで使用する拡張ヘッダーを柔軟に定義することは、ベンダーや事業者の間でかなりの意欲があります。ローカルで重要なホップバイホップオプションも想定されています。これは、ドメイン内のルーターによって理解されますが、[IN-SITU-OAM]など、他の場所では理解されません。

11. Deterministic Networking (DetNet). The Deterministic Networking Architecture [RFC8655] and encapsulation [DETNET-DATA-PLANE] aim to support flows with extremely low data loss rates and bounded latency but only within a part of the network that is "DetNet aware". Thus, as for Differentiated Services above, the concept of a domain is fundamental.

11. 確定的ネットワーキング（DetNet）。確定的ネットワーキングアーキテクチャ[RFC8655]およびカプセル化[DETNET-DATA-PLANE]は、データ損失率が非常に低く、遅延が制限されているが、「DetNet対応」のネットワークの一部内でのみフローをサポートすることを目的としています。したがって、上記の差別化サービスに関しては、ドメインの概念が基本です。

12. Provisioning Domains (PvDs). An architecture for Multiple Provisioning Domains has been defined [RFC7556] to allow hosts attached to multiple networks to learn explicit details about the services provided by each of those networks.

12. プロビジョニングドメイン（PvD）。複数のプロビジョニングドメインのアーキテクチャが定義されており[RFC7556]、複数のネットワークに接続されたホストが、各ネットワークによって提供されるサービスに関する明示的な詳細を学習できるようになっています。

13. Address Scopes. For completeness, we mention that, particularly in IPv6, some addresses have explicitly limited scope. In particular, link-local addresses are limited to a single physical link [RFC4291], and Unique Local Addresses [RFC4193] are limited to a somewhat loosely defined local site scope. Previously, site-local addresses were defined, but they were obsoleted precisely because of "the fuzzy nature of the site concept" [RFC3879]. Multicast addresses also have explicit scoping [RFC4291].

13. アドレススコープ。完全を期すために、特にIPv6では、一部のアドレスのスコープが明示的に制限されていることに言及します。特に、リンクローカルアドレスは単一の物理リンク[RFC4291]に制限され、一意のローカルアドレス[RFC4193]はやや緩く定義されたローカルサイトスコープに制限されます。以前はサイトローカルアドレスが定義されていましたが、「サイトコンセプトのあいまいな性質」[RFC3879]が原因で廃止されました。マルチキャストアドレスには、明示的なスコープ指定もあります[RFC4291]。

14. As an application-layer example, consider streaming services such as IPTV infrastructures that rely on standard protocols, but for which access is not globally available.

14. アプリケーション層の例として、IPTVインフラストラクチャなどの標準プロトコルに依存しているが、グローバルにアクセスできないストリーミングサービスを検討してください。

All of these suggestions are only viable within a specified domain. Nevertheless, all of them are clearly intended for multivendor implementation on thousands or millions of network domains, so interoperable standardization would be beneficial. This argument might seem irrelevant to private or proprietary implementations, but these have a strong tendency to become de facto standards if they succeed, so the arguments of this document still apply.

これらの提案はすべて、指定されたドメイン内でのみ実行可能です。それにもかかわらず、これらはすべて、数千または数百万のネットワークドメインでのマルチベンダー実装を明確に意図しているため、相互運用可能な標準化が有益です。この議論は、プライベート実装やプロプライエタリ実装には無関係に見えるかもしれませんが、成功した場合、事実上の標準になる傾向が強いため、このドキュメントの議論は引き続き適用されます。

5. The Scope of Protocols in Limited Domains

5. 限定されたドメインにおけるプロトコルの範囲

One consequence of the deployment of limited domains in the Internet is that some protocols will be designed, extended, or configured so that they only work correctly between end systems in such domains. This is to some extent encouraged by some existing standards and by the assignment of code points for local or experimental use. In any case, it cannot be prevented. Also, by endorsing efforts such as Service Function Chaining, Segment Routing, and Deterministic Networking, the IETF is in effect encouraging such deployments. Furthermore, it seems inevitable, if the Internet of Things becomes reality, that millions of edge networks containing completely novel types of nodes will be connected to the Internet; each one of these edge networks will be a limited domain.

インターネットに限定されたドメインを展開した結果として生じるのは、一部のプロトコルは、そのようなドメインのエンドシステム間でのみ正しく機能するように設計、拡張、または構成されることです。これは、一部の既存の標準と、ローカルまたは実験的使用のためのコードポイントの割り当てによってある程度奨励されています。いずれにせよ、それを防ぐことはできません。また、サービス機能チェーン、セグメントルーティング、確定的ネットワーキングなどの取り組みを推奨することで、IETFは事実上、このような展開を奨励しています。さらに、モノのインターネットが実現した場合、まったく新しいタイプのノードを含む数百万のエッジネットワークがインターネットに接続されることは避けられないようです。これらのエッジネットワークはそれぞれ制限されたドメインになります。

It is therefore appropriate to discuss whether protocols or protocol extensions should sometimes be standardized to interoperate only within a limited-domain boundary. Such protocols would not be required to interoperate across the Internet as a whole. Various scenarios could then arise if there are multiple domains using the limited-domain protocol in question:

したがって、プロトコルまたはプロトコル拡張を制限して、限られたドメインの境界内でのみ相互運用するように標準化する必要があるかどうかを検討することが適切です。このようなプロトコルは、インターネット全体で相互運用する必要はありません。問題の制限ドメインプロトコルを使用する複数のドメインがある場合、さまざまなシナリオが発生する可能性があります。

A. If a domain is split into two parts connected over the Internet directly at the IP layer (i.e., with no tunnel encapsulating the packets), a limited-domain protocol could be operated between those two parts regardless of its special nature, as long as it respects standard IP formats and is not arbitrarily blocked by firewalls. A simple example is any protocol using a port number assigned to a specific non-IETF protocol.

A.ドメインがインターネット経由でIP層に直接接続された2つの部分に分割されている場合（つまり、パケットをカプセル化するトンネルがない場合）、制限付きドメインプロトコルは、特別な性質に関係なく、これら2つの部分間で操作できます。標準のIPフォーマットを尊重し、ファイアウォールによって勝手にブロックされないためです。簡単な例は、特定の非IETFプロトコルに割り当てられたポート番号を使用するプロトコルです。

Such a protocol could reasonably be described as an "inter-domain" protocol because the Internet is transparent to it, even if it is meaningless except in the two limited domains. This is, of course, nothing new in the Internet architecture.

このようなプロトコルは、2つの制限されたドメインを除いて意味がないとしても、インターネットは透過的であるため、「ドメイン間」プロトコルとして合理的に説明できます。もちろん、これはインターネットアーキテクチャの新機能ではありません。

B. If a limited-domain protocol does not respect standard IP formats (for example, if it includes a non-standard IPv6 extension header), it could not be operated between two domains connected over the Internet directly at the IP layer.

B.制限されたドメインのプロトコルが標準のIPフォーマットを尊重しない場合（たとえば、非標準のIPv6拡張ヘッダーが含まれている場合）、インターネット経由でIP層に直接接続されている2つのドメイン間で操作できません。

Such a protocol could reasonably be described as an "intra-domain" protocol, and the Internet is opaque to it.

このようなプロトコルは「ドメイン内」プロトコルとして合理的に説明でき、インターネットはそれに対して不透明です。

C. If a limited-domain protocol is clearly specified to be invalid outside its domain of origin, neither scenario A nor B applies. The only solution would be a single virtual domain. For example, an encapsulating tunnel between two domains could be used to create the virtual domain. Also, nodes at the domain boundary must drop all packets using the limited-domain protocol.

C.制限されたドメインのプロトコルがその発信元のドメイン外では無効であることが明確に指定されている場合、シナリオAもBも適用されません。唯一の解決策は、単一の仮想ドメインです。たとえば、2つのドメイン間のカプセル化トンネルを使用して、仮想ドメインを作成できます。また、ドメイン境界のノードは、制限付きドメインプロトコルを使用してすべてのパケットをドロップする必要があります。

D. If a limited-domain protocol has domain-specific variants, such that implementations in different domains could not interoperate if those domains were unified by some mechanism as in scenario C, the protocol is not interoperable in the normal sense. If two domains using it were merged, the protocol might fail unpredictably. A simple example is any protocol using a port number assigned for experimental use. Related issues are discussed in [RFC5704], including the complex example of Transport MPLS.

D.制限されたドメインのプロトコルにドメイン固有のバリアントがあり、シナリオCのようにそれらのドメインが何らかのメカニズムによって統合された場合、それらのドメインの実装が相互運用できない場合、プロトコルは通常の意味で相互運用できません。それを使用する2つのドメインがマージされた場合、プロトコルは予期せず失敗する可能性があります。簡単な例は、実験用に割り当てられたポート番号を使用するプロトコルです。トランスポートMPLSの複雑な例を含め、関連する問題は[RFC5704]で説明されています。

To provide a widespread example, consider Differentiated Services [RFC2474]. A packet containing any value whatsoever in the 6 bits of the Differentiated Services Code Point (DSCP) is well formed and falls into scenario A. However, because the semantics of DSCP values are locally significant, the packet also falls into scenario D. In fact, Differentiated Services are only interoperable across domain boundaries if there is a corresponding agreement between the operators; otherwise, a specific gateway function is required for meaningful interoperability. Much more detailed discussion is found in [RFC2474] and [RFC8100].

広範な例を提供するために、差別化サービス[RFC2474]を検討してください。 DiffServコードポイント（DSCP）の6ビットに値が含まれているパケットは整形式であり、シナリオAに該当します。ただし、DSCP値のセマンティクスはローカルで重要であるため、パケットはシナリオDにも該当します。、差別化されたサービスは、事業者間に対応する合意がある場合にのみ、ドメインの境界を越えて相互運用できます。それ以外の場合は、意味のある相互運用性のために特定のゲートウェイ機能が必要です。より詳細な議論は[RFC2474]と[RFC8100]にあります。

To provide a provocative example, consider the proposal in [IPV6-SRH] that the restrictions in [RFC8200] should be relaxed to allow IPv6 extension headers to be inserted on the fly in IPv6 packets. If this is done in such a way that the affected packets can never leave the specific limited domain in which they were modified, scenario C applies. If the semantic content of the inserted headers is locally defined, scenario D also applies. In neither case is the Internet outside the limited domain disturbed. However, inside the domain, nodes must understand the variant protocol. Unless it is standardized as a formal version, with all the complexity that implies [RFC6709], the nodes must all be non-standard to the extent of understanding the variant protocol. For the example of IPv6 header insertion, that means non-compliance with [RFC8200] within the domain, even if the inserted headers are themselves fully compliant. Apart from the issue of formal compliance, such deviations from documented standard behavior might lead to significant debugging issues. The possible practical impact of the header insertion example is explored in [IN-FLIGHT-IPV6].

挑発的な例を示すために、[RFC8200]の制限を緩和してIPv6拡張ヘッダーをオンザフライでIPv6パケットに挿入できるようにする必要がある[IPV6-SRH]の提案を検討してください。これが影響を受けるパケットが変更された特定の制限されたドメインを決して離れることができないような方法で行われる場合、シナリオCが適用されます。挿入されたヘッダーのセマンティックコンテンツがローカルで定義されている場合、シナリオDも適用されます。どちらの場合も、制限されたドメイン外のインターネットは妨害されません。ただし、ドメイン内では、ノードはバリアントプロトコルを理解する必要があります。正式バージョンとして標準化されていない限り、[RFC6709]を意味する複雑さはすべてあり、バリアントプロトコルを理解するためには、ノードはすべて非標準である必要があります。 IPv6ヘッダー挿入の例では、挿入されたヘッダー自体が完全に準拠していても、ドメイン内の[RFC8200]に準拠していないことになります。正式なコンプライアンスの問題とは別に、文書化された標準動作からの逸脱は、重大なデバッグ問題につながる可能性があります。ヘッダー挿入の例の考えられる実際の影響は、[IN-FLIGHT-IPV6]で検討されています。

The FAST proposal mentioned in Section 4, Paragraph 2, Item 5 is also an interesting case study. The semantics of FAST tickets [FAST] have limited scope. However, they are designed in a way that, in principle, allows them to traverse the open Internet, as standardized IPv6 hop-by-hop options or even as a proposed form of IPv4 extension header [IPV4-EXT-HEADERS]. Whether such options can be used reliably across the open Internet remains unclear [IPV6-EXT-HEADERS].

セクション4、パラグラフ2、アイテム5で述べたFASTの提案も興味深いケーススタディです。 FASTチケットの意味[FAST]のスコープは限られています。ただし、それらは原則として、標準化されたIPv6ホップバイホップオプションとして、または提案された形式のIPv4拡張ヘッダー[IPV4-EXT-HEADERS]としても、オープンインターネットを通過できるように設計されています。そのようなオプションがオープンインターネット全体で確実に使用できるかどうかは、不明なままです[IPV6-EXT-HEADERS]。

We conclude that it is reasonable to explicitly define limited-domain protocols, either as standards or as proprietary mechanisms, as long as they describe which of the above scenarios apply and they clarify how the domain is defined. As long as all relevant standards are respected outside the domain boundary, a well-specified limited-domain protocol need not damage the rest of the Internet. However, as described in the next section, mechanisms are needed to support domain membership operations.

上記のどのシナリオが当てはまり、ドメインの定義方法が明確である限り、制限付きドメインプロトコルを標準または独自のメカニズムとして明示的に定義するのが妥当であると結論付けます。関連するすべての標準がドメイン境界の外側で尊重される限り、明確に指定された限定ドメインプロトコルは、インターネットの残りの部分を損傷する必要はありません。ただし、次のセクションで説明するように、ドメインメンバーシップ操作をサポートするにはメカニズムが必要です。

Note that this conclusion is not a recommendation to abandon the normal goal that a standardized protocol should be global in scope and able to interoperate across the open Internet. It is simply a recognition that this will not always be the case.

この結論は、標準化されたプロトコルのスコープがグローバルであり、オープンインターネット全体で相互運用できる必要があるという通常の目標を放棄することを推奨するものではないことに注意してください。これは常にそうであるとは限らないという認識にすぎません。

6. Functional Requirements of Limited Domains

6. 限定ドメインの機能要件

Noting that limited-domain protocols have been defined in the past, and that others will undoubtedly be defined in the future, it is useful to consider how a protocol can be made aware of the domain within which it operates and how the domain boundary nodes can be identified. As the taxonomy in Appendix A shows, there are numerous aspects to a domain. However, we can identify some generally required features and functions that would apply partially or completely to many cases.

制限されたドメインのプロトコルは過去に定義されており、他のプロトコルも間違いなく将来的に定義されることに注意して、プロトコルが動作するドメインとドメイン境界ノードがどのように動作できるかをプロトコルに通知する方法を検討することは有用です。識別されます。付録Aの分類法が示すように、ドメインには多くの側面があります。ただし、多くの場合に部分的または完全に適用される、一般的に必要ないくつかの機能を特定できます。

Today, where limited domains exist, they are essentially created by careful configuration of boundary routers and firewalls. If a domain is characterized by one or more address prefixes, address assignment to hosts must also be carefully managed. This is an error-prone method, and a combination of configuration errors and default routing can lead to unwanted traffic escaping the domain. Our basic assumption is therefore that it should be possible for domains to be created and managed automatically, with minimal human configuration. We now discuss requirements for automating domain creation and management.

限られたドメインが存在する今日、それらは本質的に境界ルーターとファイアウォールの注意深い構成によって作成されています。ドメインが1つ以上のアドレスプレフィックスで特徴付けられる場合、ホストへのアドレス割り当ても注意深く管理する必要があります。これはエラーが発生しやすい方法であり、構成エラーとデフォルトのルーティングの組み合わせにより、不要なトラフィックがドメインをエスケープする可能性があります。したがって、基本的な想定では、最小限の人的構成でドメインを自動的に作成および管理できるようにする必要があります。次に、ドメインの作成と管理を自動化するための要件について説明します。

First, if we drew a topology map, any given domain -- virtual or physical -- will have a well-defined boundary between "inside" and "outside". However, that boundary in itself has no technical meaning. What matters in reality is whether a node is a member of the domain and whether it is at the boundary between the domain and the rest of the Internet. Thus, the boundary in itself does not need to be identified, but boundary nodes face both inwards and outwards. Inside the domain, a sending node needs to know whether it is sending to an inside or outside destination, and a receiving node needs to know whether a packet originated inside or outside. Also, a boundary node needs to know which of its interfaces are inward facing or outward facing. It is irrelevant whether the interfaces involved are physical or virtual.

最初に、トポロジマップを作成すると、仮想ドメインまたは物理ドメインは、「内部」と「外部」の間に明確に定義された境界を持ちます。ただし、その境界自体には技術的な意味はありません。実際に重要なのは、ノードがドメインのメンバーであるかどうか、およびノードがドメインと残りのインターネットの境界にあるかどうかです。したがって、境界自体を識別する必要はありませんが、境界ノードは内側と外側の両方に面しています。ドメイン内では、送信ノードは内部または外部の宛先に送信しているかどうかを知る必要があり、受信ノードはパケットが内部または外部のどちらから発信されたかを知る必要があります。また、境界ノードは、そのインターフェースの内向きまたは外向きを知る必要があります。関係するインターフェイスが物理か仮想かは関係ありません。

To underline that domain boundaries need to be identifiable, consider the statement from the Deterministic Networking Problem Statement [RFC8557] that "there is still a lack of clarity regarding the limits of a domain where a deterministic path can be set up". This remark can certainly be generalized.

ドメイン境界を識別可能にする必要があることを強調するために、「確定的パスを設定できるドメインの制限に関する明確さの欠如はまだある」という確定的ネットワーク問題ステートメント[RFC8557]のステートメントを検討してください。この発言は確かに一般化することができます。

With this perspective, we can list some general functional requirements. An underlying assumption here is that domain membership operations should be cryptographically secured; a domain without such security cannot be reliably protected from attack.

この観点から、いくつかの一般的な機能要件をリストできます。ここでの根本的な前提は、ドメインメンバーシップの操作は暗号で保護される必要があるということです。このようなセキュリティのないドメインは、攻撃から確実に保護することはできません。

1. Domain Identity. A domain must have a unique and verifiable identifier; effectively, this should be a public key for the domain. Without this, there is no way to secure domain operations and domain membership. The holder of the corresponding private key becomes the trust anchor for the domain.

1. ドメインID。ドメインには、一意で検証可能な識別子が必要です。事実上、これはドメインの公開鍵である必要があります。これがなければ、ドメイン操作とドメインメンバーシップを保護する方法はありません。対応する秘密鍵の所有者は、ドメインのトラストアンカーになります。

2. Nesting. It must be possible for domains to be nested (see, for example, the network-slicing example mentioned above).

2. ネスティング。ドメインがネストされていることが可能である必要があります（たとえば、上記のネットワークスライスの例を参照）。

3. Overlapping. It must be possible for nodes and links to be in more than one domain (see, for example, the case of PvDs mentioned above).

3. 重複。ノードとリンクが複数のドメインに存在することが可能でなければなりません（たとえば、上記のPvDの場合を参照）。

4. Node Eligibility. It must be possible for a node to determine which domain(s) it can potentially join and on which interface(s).

4. ノードの適格性。ノードは、ノードが参加できる可能性のあるドメインと、どのインターフェイス上にあるかを判別できる必要があります。

5. Secure Enrollment. A node must be able to enroll in a given domain via secure node identification and to acquire relevant security credentials (authorization) for operations within the domain. If a node has multiple physical or virtual interfaces, individual enrollment for each interface may be required.

5. 安全な登録。ノードは、安全なノード識別を介して特定のドメインに登録でき、ドメイン内の操作に関連するセキュリティ資格情報（承認）を取得できる必要があります。ノードに複数の物理または仮想インターフェイスがある場合、各インターフェイスの個別の登録が必要になる場合があります。

6. Withdrawal. A node must be able to cancel enrollment in a given domain.

6. 撤退。ノードは、特定のドメインへの登録をキャンセルできる必要があります。

7. Dynamic Membership. Optionally, a node should be able to temporarily leave or rejoin a domain (i.e., enrollment is persistent but membership is intermittent).

7. 動的メンバーシップ。オプションで、ノードは一時的にドメインから離脱または再参加できる必要があります（つまり、登録は永続的ですが、メンバーシップは断続的です）。

8. Role, implying authorization to perform a certain set of actions. A node must have a verifiable role. In the simplest case, the role choices are "interior node" and "boundary node". In a boundary node, individual interfaces may have different roles, e.g., "inward facing" and "outward facing".

8. 特定の一連のアクションを実行するための承認を意味する役割。ノードには検証可能な役割が必要です。最も単純なケースでは、役割の選択は「内部ノード」と「境界ノード」です。境界ノードでは、個々のインターフェースが異なる役割、たとえば「内向き」と「外向き」を持つ場合があります。

9. Peer Verification. A node must be able to verify whether another node is a member of the domain.

9. ピア検証。ノードは、別のノードがドメインのメンバーであるかどうかを確認できる必要があります。

10. Role Verification. A node should be able to learn the verified role of another node. In particular, it should be possible for a node to find boundary nodes (interfacing to the Internet).

10. 役割の検証。ノードは、別のノードの検証済みの役割を学習できる必要があります。特に、ノードが境界ノードを見つけることが可能である必要があります（インターネットへのインターフェース）。

11. Domain Data. In a domain with management requirements, it must be possible for a node to acquire domain policy and/or domain configuration data. This would include, for example, filtering policy to ensure that inappropriate packets do not leave the domain.

11. ドメインデータ。管理要件のあるドメインでは、ノードがドメインポリシーやドメイン構成データを取得できる必要があります。これには、たとえば、不適切なパケットがドメインを出ないようにするためのフィルタリングポリシーが含まれます。

These requirements could form the basis for further analysis and solution design.

これらの要件は、さらなる分析とソリューション設計の基礎を形成する可能性があります。

Another aspect is whether individual packets within a limited domain need to carry any sort of indicator that they belong to that domain or whether this information will be implicit in the IP addresses of the packet. A related question is whether individual packets need cryptographic authentication. This topic is for further study.

別の側面は、制限されたドメイン内の個々のパケットが、それらがそのドメインに属していることを示す何らかのインジケーターを運ぶ必要があるかどうか、またはこの情報がパケットのIPアドレスに暗黙的に含まれるかどうかです。関連する質問は、個々のパケットが暗号認証を必要とするかどうかです。このトピックは今後の検討課題です。

7. Security Considerations

7. セキュリティに関する考慮事項

As noted above, a protocol intended for limited use may well be inadvertently used on the open Internet, so limited use is not an excuse for poor security. In fact, a limited use requirement potentially adds complexity to the security design.

上記のように、限定された使用を目的としたプロトコルは、オープンインターネットで誤って使用される可能性があるため、限定された使用は、セキュリティの低下の言い訳にはなりません。実際、使用制限があるため、セキュリティ設計が複雑になる可能性があります。

Often, the boundary of a limited domain will also act as a security boundary. In particular, it will serve as a trust boundary and as a boundary of authority for defining capabilities. For example, segment routing [RFC8402] explicitly uses the concept of a "trusted domain" in this way. Within the boundary, limited-domain protocols or protocol features will be useful, but they will in many cases be meaningless or harmful if they enter or leave the domain.

多くの場合、制限されたドメインの境界は、セキュリティ境界としても機能します。特に、これは信頼境界として、および機能を定義するための権限の境界として機能します。たとえば、セグメントルーティング[RFC8402]は、このように「信頼できるドメイン」の概念を明示的に使用しています。境界内では、制限されたドメインのプロトコルまたはプロトコル機能が役立ちますが、ドメインに出入りする場合、それらは多くの場合無意味または有害になります。

The boundary also serves to provide confidentiality and privacy for operational parameters that the operator does not wish to reveal. Note that this is distinct from privacy protection for individual users within the domain.

境界は、オペレーターが明らかにしたくない操作パラメーターの機密性とプライバシーを提供する役割も果たします。これは、ドメイン内の個々のユーザーのプライバシー保護とは異なることに注意してください。

The security model for a limited-scope protocol must allow for the boundary and in particular for a trust model that changes at the boundary. Typically, credentials will need to be signed by a domain-specific authority.

スコープが限定されたプロトコルのセキュリティモデルでは、境界、特に境界で変化する信頼モデルを考慮に入れる必要があります。通常、資格情報はドメイン固有の機関によって署名される必要があります。

8. IANA Considerations

8. IANAに関する考慮事項

This document has no IANA actions.

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

9. Informative References

9. 参考引用

[ACP] Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic Control Plane (ACP)", Work in Progress, Internet-Draft, draft-ietf-anima-autonomic-control-plane-27, 2 July 2020, <https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-27>.

[ACP] Eckert、T.、Behringer、M。、およびS. Bjarnason、「Autonomic Control Plane（ACP）」、Work in Progress、Internet-Draft、draft-ietf-anima-autonomic-control-plane-27、 2020年7月2日、<https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-27>。

[APP-AWARE] Li, Z., Peng, S., Li, C., Xie, C., Voyer, D., Li, X., Liu, P., Liu, C., and K. Ebisawa, "Application-aware IPv6 Networking (APN6) Encapsulation", Work in Progress, Internet-Draft, draft-li-6man-app-aware-ipv6-network-02, 2 July 2020, <https://tools.ietf.org/html/draft-li-6man-app-aware-ipv6-network-02>.

[APP-AWARE] Li、Z、Peng、S、Li、C、Xie、C、Voyer、D、Li、X、Liu、P、Li、C、K。Ebisawa、「Application-aware IPv6 Networking（APN6）Encapsulation」、Work in Progress、Internet-Draft、draft-li-6man-app-aware-ipv6-network-02、2020年7月2日、<https://tools.ietf.org / html / draft-li-6man-app-aware-ipv6-network-02>。

[BIGIP] Li, R., "HUAWEI - Big IP Initiative", 2018, <https://www.iaria.org/announcements/HuaweiBigIP.pdf>.

[big IP] l i、R。、「hu A Wei-big IP initiative」、2018、<HTTPS：//woowoowoo.I aria.org/announcements/hu A是big IP.PDF>。

[DETNET-DATA-PLANE] Varga, B., Farkas, J., Berger, L., Malis, A., and S. Bryant, "DetNet Data Plane Framework", Work in Progress, Internet-Draft, draft-ietf-detnet-data-plane-framework-06, 6 May 2020, <https://tools.ietf.org/html/draft-ietf-detnet-data-plane-framework-06>.

[DETNET-DATA-PLANE] Varga、B.、Farkas、J.、Berger、L.、Malis、A。、およびS. Bryant、「DetNet Data Plane Framework」、Work in Progress、Internet-Draft、draft-ietf -detnet-data-plane-framework-06、2020年5月6日、<https://tools.ietf.org/html/draft-ietf-detnet-data-plane-framework-06>。

[DNS-PERIMETER] Crocker, D. and T. Adams, "DNS Perimeter Overlay", Work in Progress, Internet-Draft, draft-dcrocker-dns-perimeter-01, 11 June 2019, <https://tools.ietf.org/html/draft-dcrocker-dns-perimeter-01>.

[DNS-PERIMETER] Crocker、D。およびT. Adams、「DNS Perimeter Overlay」、Work in Progress、Internet-Draft、draft-dcrocker-dns-perimeter-01、2019年6月11日、<https：//tools.ietf .org / html / draft-dcrocker-dns-perimeter-01>。

[EMBEDDED-SEMANTICS] Jiang, S., Qiong, Q., Farrer, I., Bo, Y., and T. Yang, "Analysis of Semantic Embedded IPv6 Address Schemas", Work in Progress, Internet-Draft, draft-jiang-semantic-prefix-06, 15 July 2013, <https://tools.ietf.org/html/draft-jiang-semantic-prefix-06>.

[EMBEDDED-SEMANTICS] Jiang、S.、Qiong、Q.、Farrer、I.、Bo、Y。、およびT. Yang、「Analysis of Semantic Embedded IPv6 Address Schemas」、進行中の作業、インターネットドラフト、ドラフト- jiang-semantic-prefix-06、2013年7月15日、<https://tools.ietf.org/html/draft-jiang-semantic-prefix-06>。

[ENHANCED-VPN] Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A Framework for Enhanced Virtual Private Networks (VPN+) Service", Work in Progress, Internet-Draft, draft-ietf-teas-enhanced-vpn-06, 13 July 2020, <https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn-06>.

[ENHANCED-VPN] Dong、J.、Bryant、S.、Li、Z.、Miyasaka、T。、およびY. Lee、「A Enhanced Framework for Private Virtual Private Networks（VPN +）Service」、Work in Progress、Internet-ドラフト、draft-ietf-teas-enhanced-vpn-06、2020年7月13日、<https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn-06>。

[FAST] Herbert, T., "Firewall and Service Tickets", Work in Progress, Internet-Draft, draft-herbert-fast-04, 10 April 2019, <https://tools.ietf.org/html/draft-herbert-fast-04>.

[FAST]ハーバート、T。、「ファイアウォールとサービスチケット」、作業中、インターネットドラフト、draft-herbert-fast-04、2019年4月10日、<https://tools.ietf.org/html/draft- herbert-fast-04>。

[FRAG-FRAGILE] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., and F. Gont, "IP Fragmentation Considered Fragile", Work in Progress, Internet-Draft, draft-ietf-intarea-frag-fragile-17, 30 September 2019, <https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-17>.

[FRAG-FRAGILE] Bonica、R.、Baker、F.、Huston、G.、Hinden、R.、Troan、O。、およびF. Gont、「壊れそうなIPフラグメンテーション」、進行中の作業、インターネットドラフト、 draft-ietf-intarea-frag-fragile-17、2019年9月30日、<https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-17>。

[HOMENET-NAMING] Lemon, T., Migault, D., and S. Cheshire, "Homenet Naming and Service Discovery Architecture", Work in Progress, Internet-Draft, draft-ietf-homenet-simple-naming-03, 23 October 2018, <https://tools.ietf.org/html/draft-ietf-homenet-simple-naming-03>.

[HOMENET-NAMING] Lemon、T.、Migault、D。、およびS. Cheshire、「Homenet Naming and Service Discovery Architecture」、Work in Progress、Internet-Draft、draft-ietf-homenet-simple-naming-03、23 2018年10月、<https://tools.ietf.org/html/draft-ietf-homenet-simple-naming-03>。

[IBN-CONCEPTS] Clemm, A., Ciavaglia, L., Granville, L., and J. Tantsura, "Intent-Based Networking - Concepts and Definitions", Work in Progress, Internet-Draft, draft-irtf-nmrg-ibn-concepts-definitions-01, 9 March 2020, <https://tools.ietf.org/html/draft-irtf-nmrg-ibn-concepts-definitions-01>.

[IBN-CONCEPTS] Clemm、A.、Ciavaglia、L.、Granville、L.、and J. Tantsura、 "Intent-Based Networking-Concepts and Definitions"、Work in Progress、Internet-Draft、draft-irtf-nmrg- ibn-concepts-definitions-01、2020年3月9日、<https://tools.ietf.org/html/draft-irtf-nmrg-ibn-concepts-definitions-01>。

[IN-FLIGHT-IPV6] Smith, M., Kottapalli, N., Bonica, R., Gont, F., and T. Herbert, "In-Flight IPv6 Extension Header Insertion Considered Harmful", Work in Progress, Internet-Draft, draft-smith-6man-in-flight-eh-insertion-harmful-02, 30 May 2020, <https://tools.ietf.org/html/draft-smith-6man-in-flight-eh-insertion-harmful-02>.

[IN-FLIGHT-IPV6]スミス、M。、コッタパリ、N。、ボニカ、R。、ゴント、F。、およびT.ハーバート、「飛行中のIPv6拡張ヘッダーの挿入は有害と見なされる」、進行中の作業、インターネットドラフト、draft-smith-6man-in-flight-eh-insertion-harmful-02、2020年5月30日、<https://tools.ietf.org/html/draft-smith-6man-in-flight-eh-insertion -harmful-02>。

[IN-SITU-OAM] Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., Lapukhov, P., Spiegel, M., Krishnan, S., and R. Asati, "In-situ OAM IPv6 Options", Work in Progress, Internet-Draft, draft-ietf-ippm-ioam-ipv6-options-02, 13 July 2020, <https://tools.ietf.org/html/draft-ietf-ippm-ioam-ipv6- options-02>.

[IN-SITU-OAM] Bhandari、S.、Brockners、F.、Pignataro、C.、Gredler、H.、Leddy、J.、Youell、S.、Mizrahi、T.、Kfir、A.、Gafni、B 。、Lapukhov、P.、Spiegel、M.、Krishnan、S。、およびR. Asati、「In-situ OAM IPv6 Options」、Work in Progress、Internet-Draft、draft-ietf-ippm-ioam-ipv6-options -02、2020年7月13日、<https://tools.ietf.org/html/draft-ietf-ippm-ioam-ipv6- options-02>。

[IPV4-EXT-HEADERS] Herbert, T., "IPv4 Extension Headers and Flow Label", Work in Progress, Internet-Draft, draft-herbert-ipv4-eh-01, 2 May 2019, <https://tools.ietf.org/html/draft-herbert-ipv4-eh-01>.

[IPV4-EXT-HEADERS] Herbert、T。、「IPv4 Extension Headers and Flow Label」、Work in Progress、Internet-Draft、draft-herbert-ipv4-eh-01、2019年5月2日、<https：// tools。 ietf.org/html/draft-herbert-ipv4-eh-01>。

[IPV6-ALT-MARK] Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. Pang, "IPv6 Application of the Alternate Marking Method", Work in Progress, Internet-Draft, draft-ietf-6man-ipv6- alt-mark-01, 22 June 2020, <https://tools.ietf.org/html/ draft-ietf-6man-ipv6-alt-mark-01>.

[IPV6-ALT-MARK] Fioccola、G.、Zhou、T.、Cociglio、M.、Qin、F。、およびR. Pang、「代替マーキング方式のIPv6アプリケーション」、進行中の作業、インターネットドラフト、 draft-ietf-6man-ipv6- alt-mark-01、2020年6月22日、<https://tools.ietf.org/html/draft-ietf-6man-ipv6-alt-mark-01>。

[IPV6-EXT-HEADERS] Gont, F. and W. LIU, "Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers", Work in Progress, Internet-Draft, draft-ietf-opsec-ipv6-eh-filtering-06, 2 July 2018, <https://tools.ietf.org/html/ draft-ietf-opsec-ipv6-eh-filtering-06>.

[IPV6-EXT-HEADERS] Gont、F。およびW. LIU、「IPv6拡張ヘッダーを含むIPv6パケットのフィルタリングに関する推奨事項」、進行中の作業、インターネットドラフト、draft-ietf-opsec-ipv6-eh-filtering- 2018年7月2日、<https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-06>。

[IPV6-SRH] Voyer, D., Filsfils, C., Dukes, D., Matsushima, S., Leddy, J., Li, Z., and J. Guichard, "Deployments With Insertion of IPv6 Segment Routing Headers", Work in Progress, Internet-Draft, draft-voyer-6man-extension-header-insertion-09, 19 May 2020, <https://tools.ietf.org/html/ draft-voyer-6man-extension-header-insertion-09>.

[IPV6-SRH] Voyer、D.、Filsfils、C.、Dukes、D.、Matsushima、S.、Leddy、J.、Li、Z。、およびJ. Guichard、「IPv6セグメントルーティングヘッダーの挿入による展開」、Work in Progress、Internet-Draft、draft-voyer-6man-extension-header-insertion-09、19 May 2020、<https://tools.ietf.org/html/draft-voyer-6man-extension-header- Insertion-09>。

[IPV6-USE-MINMTU] Andrews, M., "TCP Fails To Respect IPV6_USE_MIN_MTU", Work in Progress, Internet-Draft, draft-andrews-tcp-and-ipv6- use-minmtu-04, 18 October 2015, <https://tools.ietf.org/html/draft-andrews-tcp-and-ipv6- use-minmtu-04>.

[IPV6-USE-MINMTU]アンドリュースM。、「TCPはIPV6_USE_MIN_MTUを尊重しない」、進行中の作業、インターネットドラフト、draft-andrews-tcp-and-ipv6-use-minmtu-04、2015年10月18日、<https ：//tools.ietf.org/html/draft-andrews-tcp-and-ipv6-use-minmtu-04>。

[IPWAVE-NETWORKING] Jeong, J., "IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases", Work in Progress, Internet-Draft, draft-ietf-ipwave-vehicular-networking-16, 7 July 2020, <https://tools.ietf.org/html/ draft-ietf-ipwave-vehicular-networking-16>.

[IPWAVE-NETWORKING] Jeong、J。、「車両環境でのIPv6ワイヤレスアクセス（IPWAVE）：問題の説明と使用例」、作業中、インターネットドラフト、draft-ietf-ipwave-vehicular-networking-16、7月7日2020、<https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-16>。

[REF-MODEL] Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., and J. Nobre, "A Reference Model for Autonomic Networking", Work in Progress, Internet-Draft, draft-ietf-anima-reference-model-10, 22 November 2018, <https://tools.ietf.org/html/draft-ietf-anima-reference-model-10>.

[参考モデル] Behringer、M.、Carpenter、B.、Eckert、T.、Ciavaslia、L.、J。Nobre、「オートノミックネットワーキングの参照モデル」、Work in Progress、インターネットドラフト、draft-ietf -anima-reference-model-10、2018年11月22日、<https://tools.ietf.org/html/draft-ietf-anima-reference-model-10>。

[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, <https://www.rfc-editor.org/info/rfc2205>.

[RFC2205] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S.、and S. Jamin、 "Resource ReSerVation Protocol（RSVP）-Version 1 Functional Specification"、RFC 2205、DOI 10.17487 / RFC2205、1997年9月、<https://www.rfc-editor.org/info/rfc2205>。

[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.

[RFC2474]ニコルズ、K。、ブレイク、S。、ベイカー、F。、およびD.ブラック、「IPv4およびIPv6ヘッダーのDiffServフィールド（DSフィールド）の定義」、RFC 2474、DOI 10.17487 / RFC2474、 1998年12月、<https://www.rfc-editor.org/info/rfc2474>。

[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, DOI 10.17487/RFC2775, February 2000, <https://www.rfc-editor.org/info/rfc2775>.

[RFC2775] Carpenter、B。、「Internet Transparency」、RFC 2775、DOI 10.17487 / RFC2775、2000年2月、<https://www.rfc-editor.org/info/rfc2775>。

[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, DOI 10.17487/RFC2923, September 2000, <https://www.rfc-editor.org/info/rfc2923>.

[RFC2923] Lahey、K。、「Path MTU Discovery with Path MTU Discovery」、RFC 2923、DOI 10.17487 / RFC2923、2000年9月、<https://www.rfc-editor.org/info/rfc2923>。

[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, <https://www.rfc-editor.org/info/rfc3234>.

[RFC3234]カーペンター、B。およびS.ブリム、「ミドルボックス：分類と問題」、RFC 3234、DOI 10.17487 / RFC3234、2002年2月、<https://www.rfc-editor.org/info/rfc3234>。

[RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local Addresses", RFC 3879, DOI 10.17487/RFC3879, September 2004, <https://www.rfc-editor.org/info/rfc3879>.

[RFC3879] Huitema、C。およびB. Carpenter、「Deprecating Site Local Addresses」、RFC 3879、DOI 10.17487 / RFC3879、2004年9月、<https://www.rfc-editor.org/info/rfc3879>。

[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, <https://www.rfc-editor.org/info/rfc4193>.

[RFC4193] Hinden、R。およびB. Haberman、「Unique Local IPv6 Unicast Addresses」、RFC 4193、DOI 10.17487 / RFC4193、2005年10月、<https://www.rfc-editor.org/info/rfc4193>。

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>.

[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、DOI 10.17487 / RFC4291、2006年2月、<https://www.rfc-editor.org/info/rfc4291>。

[RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture", RFC 4397, DOI 10.17487/RFC4397, February 2006, <https://www.rfc-editor.org/info/rfc4397>.

[RFC4397] Bryskin、I。およびA. Farrel、「ITU-Tの自動切り替え光ネットワーク（ASON）アーキテクチャーのコンテキスト内での一般化マルチプロトコルラベルスイッチング（GMPLS）用語の解釈のための辞書編集」、RFC 4397、DOI 10.17487 / RFC4397、2006年2月、<https://www.rfc-editor.org/info/rfc4397>。

[RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, DOI 10.17487/RFC4427, March 2006, <https://www.rfc-editor.org/info/rfc4427>.

[RFC4427]マニー、E、エド。 D. Papadimitriou、Ed。、「Recovery（Protection and Restoration）Terminology for Generalized Multi-Protocol Label Switching（GMPLS）」、RFC 4427、DOI 10.17487 / RFC4427、2006年3月、<https：//www.rfc-editor。 org / info / rfc4427>。

[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <https://www.rfc-editor.org/info/rfc4655>.

[RFC4655] Farrel、A.、Vasseur、J.-P。、およびJ. Ash、「A Path Computation Element（PCE）-Based Architecture」、RFC 4655、DOI 10.17487 / RFC4655、2006年8月、<https：// www.rfc-editor.org/info/rfc4655>。

[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, <https://www.rfc-editor.org/info/rfc4821>.

[RFC4821] Mathis、M。およびJ. Heffner、「Packetization Layer Path MTU Discovery」、RFC 4821、DOI 10.17487 / RFC4821、2007年3月、<https://www.rfc-editor.org/info/rfc4821>。

[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, April 2007, <https://www.rfc-editor.org/info/rfc4838>.

[RFC4838] Cerf、V.、Burleigh、S.、Hooke、A.、Torgerson、L.、Durst、R.、Scott、K.、Fall、K。、およびH. Weiss、「遅延耐性のあるネットワークアーキテクチャ」、RFC 4838、DOI 10.17487 / RFC4838、2007年4月、<https://www.rfc-editor.org/info/rfc4838>。

[RFC4924] Aboba, B., Ed. and E. Davies, "Reflections on Internet Transparency", RFC 4924, DOI 10.17487/RFC4924, July 2007, <https://www.rfc-editor.org/info/rfc4924>.

[RFC4924]アボバ、B。、エド。 E. Davies、「Reflections on Internet Transparency」、RFC 4924、DOI 10.17487 / RFC4924、2007年7月、<https://www.rfc-editor.org/info/rfc4924>。

[RFC5704] Bryant, S., Ed., Morrow, M., Ed., and IAB, "Uncoordinated Protocol Development Considered Harmful", RFC 5704, DOI 10.17487/RFC5704, November 2009, <https://www.rfc-editor.org/info/rfc5704>.

[RFC5704]ブライアント、S。、編、モロー、M。、編、およびIAB、「有害な非協調的プロトコル開発」、RFC 5704、DOI 10.17487 / RFC5704、2009年11月、<https：//www.rfc- editor.org/info/rfc5704>。

[RFC6294] Hu, Q. and B. Carpenter, "Survey of Proposed Use Cases for the IPv6 Flow Label", RFC 6294, DOI 10.17487/RFC6294, June 2011, <https://www.rfc-editor.org/info/rfc6294>.

[RFC6294] Hu、Q。、およびB. Carpenter、「IPv6フローラベルの提案された使用例の調査」、RFC 6294、DOI 10.17487 / RFC6294、2011年6月、<https://www.rfc-editor.org/info / rfc6294>。

[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, <https://www.rfc-editor.org/info/rfc6325>.

[RFC6325] Perlman、R.、Eastlake 3rd、D.、Dutt、D.、Gai、S。、およびA. Ghanwani、「Routing Bridges（RBridges）：Base Protocol Specification」、RFC 6325、DOI 10.17487 / RFC6325、7月2011、<https://www.rfc-editor.org/info/rfc6325>。

[RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October 2011, <https://www.rfc-editor.org/info/rfc6398>.

[RFC6398] Le Faucheur、F。、編、「IPルーターアラートの考慮事項と使用法」、BCP 168、RFC 6398、DOI 10.17487 / RFC6398、2011年10月、<https://www.rfc-editor.org/info/ rfc6398>。

[RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of Interpretation", RFC 6407, DOI 10.17487/RFC6407, October 2011, <https://www.rfc-editor.org/info/rfc6407>.

[RFC6407] Weis、B.、Rowles、S。、およびT. Hardjono、「The Group Domain of Interpretation」、RFC 6407、DOI 10.17487 / RFC6407、2011年10月、<https://www.rfc-editor.org/ info / rfc6407>。

[RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design Considerations for Protocol Extensions", RFC 6709, DOI 10.17487/RFC6709, September 2012, <https://www.rfc-editor.org/info/rfc6709>.

[RFC6709] Carpenter、B.、Aboba、B.、Ed。、およびS. Cheshire、「プロトコル拡張の設計上の考慮事項」、RFC 6709、DOI 10.17487 / RFC6709、2012年9月、<https：//www.rfc-editor .org / info / rfc6709>。

[RFC6947] Boucadair, M., Kaplan, H., Gilman, R., and S. Veikkolainen, "The Session Description Protocol (SDP) Alternate Connectivity (ALTC) Attribute", RFC 6947, DOI 10.17487/RFC6947, May 2013, <https://www.rfc-editor.org/info/rfc6947>.

[RFC6947] Boucadair、M.、Kaplan、H.、Gilman、R。、およびS. Veikkolainen、「セッション記述プロトコル（SDP）代替接続（ALTC）属性」、RFC 6947、DOI 10.17487 / RFC6947、2013年5月、 <https://www.rfc-editor.org/info/rfc6947>。

[RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, "Architectural Considerations on Application Features in the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013, <https://www.rfc-editor.org/info/rfc6950>.

[RFC6950] Peterson、J.、Kolkman、O.、Tschofenig、H。、およびB. Aboba、「DNSのアプリケーション機能に関するアーキテクチャの考慮事項」、RFC 6950、DOI 10.17487 / RFC6950、2013年10月、<https：// www.rfc-editor.org/info/rfc6950>。

[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing of IPv6 Extension Headers", RFC 7045, DOI 10.17487/RFC7045, December 2013, <https://www.rfc-editor.org/info/rfc7045>.

[RFC7045] Carpenter、B。およびS. Jiang、「IPv6拡張ヘッダーの送信と処理」、RFC 7045、DOI 10.17487 / RFC7045、2013年12月、<https://www.rfc-editor.org/info/rfc7045> 。

[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <https://www.rfc-editor.org/info/rfc7228>.

[RFC7228] Bormann、C.、Ersue、M.、and A. Keranen、 "Terminology for Constrained-Node Networks"、RFC 7228、DOI 10.17487 / RFC7228、May 2014、<https://www.rfc-editor.org / info / rfc7228>。

[RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. Weil, "IPv6 Home Networking Architecture Principles", RFC 7368, DOI 10.17487/RFC7368, October 2014, <https://www.rfc-editor.org/info/rfc7368>.

[RFC7368] Chown、T.、Ed。、Arkko、J.、Brandt、A.、Troan、O。、およびJ. Weil、「IPv6 Home Networking Architecture Principles」、RFC 7368、DOI 10.17487 / RFC7368、2014年10月、 <https://www.rfc-editor.org/info/rfc7368>。

[RFC7381] Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V., Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment Guidelines", RFC 7381, DOI 10.17487/RFC7381, October 2014, <https://www.rfc-editor.org/info/rfc7381>.

[RFC7381] Chittimaneni、K.、Chown、T.、Howard、L.、Kuarsingh、V.、Pouffary、Y.、and E. Vyncke、 "Enterprise IPv6 Deployment Guidelines"、RFC 7381、DOI 10.17487 / RFC7381、October 2014 、<https://www.rfc-editor.org/info/rfc7381>。

[RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, <https://www.rfc-editor.org/info/rfc7556>.

[RFC7556] Anipko、D。、編、「Multiple Provisioning Domain Architecture」、RFC 7556、DOI 10.17487 / RFC7556、2015年6月、<https://www.rfc-editor.org/info/rfc7556>。

[RFC7663] Trammell, B., Ed. and M. Kuehlewind, Ed., "Report from the IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI)", RFC 7663, DOI 10.17487/RFC7663, October 2015, <https://www.rfc-editor.org/info/rfc7663>.

[RFC7663]トランメル、B。、エド。 M.キュールウィンド編、「ミドルボックスインターネット（SEMI）のスタック進化に関するIABワークショップからの報告」、RFC 7663、DOI 10.17487 / RFC7663、2015年10月、<https://www.rfc-editor.org/ info / rfc7663>。

[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, <https://www.rfc-editor.org/info/rfc7665>.

[RFC7665] Halpern、J.、Ed。 C. Pignataro、編、「Service Function Chaining（SFC）Architecture」、RFC 7665、DOI 10.17487 / RFC7665、2015年10月、<https://www.rfc-editor.org/info/rfc7665>。

[RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E. Nordmark, "Technical Considerations for Internet Service Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754, March 2016, <https://www.rfc-editor.org/info/rfc7754>.

[RFC7754] Barnes、R.、Cooper、A.、Kolkman、O.、Thaler、D。、およびE. Nordmark、「インターネットサービスのブロッキングとフィルタリングに関する技術的な考慮事項」、RFC 7754、DOI 10.17487 / RFC7754、2016年3月、 <https://www.rfc-editor.org/info/rfc7754>。

[RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 2016, <https://www.rfc-editor.org/info/rfc7788>.

[RFC7788] Stenberg、M.、Barth、S。、およびP. Pfister、「Home Networking Control Protocol」、RFC 7788、DOI 10.17487 / RFC7788、2016年4月、<https://www.rfc-editor.org/info / rfc7788>。

[RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, "Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World", RFC 7872, DOI 10.17487/RFC7872, June 2016, <https://www.rfc-editor.org/info/rfc7872>.

[RFC7872] Gont、F.、Linkova、J.、Chown、T。、およびW. Liu、「実際のIPv6拡張ヘッダーを使用したパケットのドロップに関する観察」、RFC 7872、DOI 10.17487 / RFC7872、2016年6月、<https://www.rfc-editor.org/info/rfc7872>。

[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.

[RFC8085]エガート、L。、フェアハースト、G。、およびG.シェパード、「UDP使用ガイドライン」、BCP 145、RFC 8085、DOI 10.17487 / RFC8085、2017年3月、<https://www.rfc-editor.org / info / rfc8085>。

[RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE-in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, March 2017, <https://www.rfc-editor.org/info/rfc8086>.

[RFC8086] Yong、L.、Ed。、Crabbe、E.、Xu、X。、およびT. Herbert、「GRE-in-UDP Encapsulation」、RFC 8086、DOI 10.17487 / RFC8086、2017年3月、<https：/ /www.rfc-editor.org/info/rfc8086>。

[RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection Classes and Practice", RFC 8100, DOI 10.17487/RFC8100, March 2017, <https://www.rfc-editor.org/info/rfc8100>.

[RFC8100]ガイブ、R。、エド。 D. Black、「Diffserv-Interconnection Classes and Practice」、RFC 8100、DOI 10.17487 / RFC8100、2017年3月、<https://www.rfc-editor.org/info/rfc8100>。

[RFC8151] Yong, L., Dunbar, L., Toy, M., Isaac, A., and V. Manral, "Use Cases for Data Center Network Virtualization Overlay Networks", RFC 8151, DOI 10.17487/RFC8151, May 2017, <https://www.rfc-editor.org/info/rfc8151>.

[RFC8151] Yong、L.、Dunbar、L.、Toy、M.、Isaac、A。、およびV. Manral、「データセンターネットワーク仮想化オーバーレイネットワークの使用例」、RFC 8151、DOI 10.17487 / RFC8151、2017年5月、<https://www.rfc-editor.org/info/rfc8151>。

[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.

[RFC8200] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、STD 86、RFC 8200、DOI 10.17487 / RFC8200、2017年7月、<https://www.rfc-editor.org / info / rfc8200>。

[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, January 2018, <https://www.rfc-editor.org/info/rfc8300>.

[RFC8300] Quinn、P。、編、Elzur、U、編、およびC. Pignataro、編、「Network Service Header（NSH）」、RFC 8300、DOI 10.17487 / RFC8300、2018年1月、<https： //www.rfc-editor.org/info/rfc8300>。

[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>.

[RFC8402] Filsfils、C.、Ed。、Previdi、S.、Ed。、Ginsberg、L.、Decraene、B.、Litkowski、S.、and R. Shakir、 "Segment Routing Architecture"、RFC 8402、DOI 10.17487 / RFC8402、2018年7月、<https://www.rfc-editor.org/info/rfc8402>。

[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, <https://www.rfc-editor.org/info/rfc8445>.

[RFC8445] Keranen、A.、Holmberg、C。、およびJ. Rosenberg、「Interactive Connectivity Establishment（ICE）：A Protocol for Network Address Translator（NAT）Traversal」、RFC 8445、DOI 10.17487 / RFC8445、2018年7月、< https://www.rfc-editor.org/info/rfc8445>。

[RFC8517] Dolson, D., Ed., Snellman, J., Boucadair, M., Ed., and C. Jacquenet, "An Inventory of Transport-Centric Functions Provided by Middleboxes: An Operator Perspective", RFC 8517, DOI 10.17487/RFC8517, February 2019, <https://www.rfc-editor.org/info/rfc8517>.

[RFC8517] Dolson、D.、Ed。、Snellman、J.、Boucadair、M.、Ed。、and C. Jacquenet、 "An Inventory of Transport-Centric Functions Provided by Middleboxes：an Operator Perspective"、RFC 8517、DOI 10.17487 / RFC8517、2019年2月、<https://www.rfc-editor.org/info/rfc8517>。

[RFC8557] Finn, N. and P. Thubert, "Deterministic Networking Problem Statement", RFC 8557, DOI 10.17487/RFC8557, May 2019, <https://www.rfc-editor.org/info/rfc8557>.

[RFC8557] Finn、N。およびP. Thubert、「Deterministic Networking Problem Statement」、RFC 8557、DOI 10.17487 / RFC8557、2019年5月、<https://www.rfc-editor.org/info/rfc8557>。

[RFC8568] Bernardos, CJ., Rahman, A., Zuniga, JC., Contreras, LM., Aranda, P., and P. Lynch, "Network Virtualization Research Challenges", RFC 8568, DOI 10.17487/RFC8568, April 2019, <https://www.rfc-editor.org/info/rfc8568>.

[RFC8568]バーナードス、CJ。、ラーマン、A。、ズニーガ、JC。、コントレラス、LM。、アランダ、P。、およびP.リンチ、「ネットワーク仮想化の研究課題」、RFC 8568、DOI 10.17487 / RFC8568、2019年4月、<https://www.rfc-editor.org/info/rfc8568>。

[RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", RFC 8578, DOI 10.17487/RFC8578, May 2019, <https://www.rfc-editor.org/info/rfc8578>.

[RFC8578] Grossman、E.、Ed。、「Deterministic Networking Use Cases」、RFC 8578、DOI 10.17487 / RFC8578、2019年5月、<https://www.rfc-editor.org/info/rfc8578>。

[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, October 2019, <https://www.rfc-editor.org/info/rfc8655>.

[RFC8655] Finn、N.、Thubert、P.、Varga、B。、およびJ. Farkas、「Deterministic Networking Architecture」、RFC 8655、DOI 10.17487 / RFC8655、2019年10月、<https：//www.rfc-editor .org / info / rfc8655>。

[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, <https://www.rfc-editor.org/info/rfc8754>.

[RFC8754] Filsfils、C.、Ed。、Dukes、D.、Ed。、Previdi、S.、Leddy、J.、Matsushima、S.、and D. Voyer、 "IPv6 Segment Routing Header（SRH）"、RFC 8754、DOI 10.17487 / RFC8754、2020年3月、<https://www.rfc-editor.org/info/rfc8754>。

[SPB] "IEEE Standard for Local and metropolitan area networks - Bridges and Bridged Networks", DOI 10.1109/IEEESTD.2018.8403927, IEEE 802.1Q-2018, July 2018, <https://ieeexplore.ieee.org/document/8403927>.

[SPB]「ローカルおよびメトロポリタンエリアネットワークのIEEE標準-ブリッジおよびブリッジネットワーク」、DOI 10.1109 / IEEESTD.2018.8403927、IEEE 802.1Q-2018、2018年7月、<https://ieeexplore.ieee.org/document/8403927> 。

[SRV6-NETWORK] Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "SRv6 Network Programming", Work in Progress, Internet-Draft, draft-ietf-spring-srv6- network-programming-16, 27 June 2020, <https://tools.ietf.org/html/draft-ietf-spring-srv6- network-programming-16>.

[SRV6-NETWORK] Filsfils、C.、Camarillo、P.、Leddy、J.、Voyer、D.、Matsushima、S.、Z。Li、「SRv6ネットワークプログラミング」、作業中、インターネットドラフト、ドラフト-ietf-spring-srv6- network-programming-16、2020年6月27日、<https://tools.ietf.org/html/draft-ietf-spring-srv6- network-programming-16>。

[USER-PLANE-PROTOCOL] Homma, S., Miyasaka, T., Matsushima, S., and D. Voyer, "User Plane Protocol and Architectural Analysis on 3GPP 5G System", Work in Progress, Internet-Draft, draft-ietf-dmm-5g-uplane-analysis-03, 3 November 2019, <https://tools.ietf.org/html/draft-ietf-dmm-5g-uplane-analysis-03>.

[USER-PLANE-PROTOCOL]本間晋、宮坂竜、松島晋、D。ボイヤー、「3GPP 5Gシステムのユーザープレーンプロトコルとアーキテクチャ分析」、進行中の作業、インターネットドラフト、ドラフト- ietf-dmm-5g-uplane-analysis-03、2019年11月3日、<https://tools.ietf.org/html/draft-ietf-dmm-5g-uplane-analysis-03>。

Appendix A. Taxonomy of Limited Domains

付録A.制限されたドメインの分類

This appendix develops a taxonomy for describing limited domains. Several major aspects are considered in this taxonomy:

この付録では、制限されたドメインを記述するための分類法を作成します。この分類法では、いくつかの主要な側面が考慮されています。

* The domain as a whole

* ドメイン全体

* The individual nodes

* 個々のノード

* The domain boundary

* ドメイン境界

* The domain's topology

* ドメインのトポロジー

* The domain's technology

* ドメインのテクノロジー

* How the domain connects to the Internet

* ドメインがインターネットに接続する方法

* The security, trust, and privacy model

* セキュリティ、信頼、プライバシーモデル

* Operations

* 操作

The following sub-sections analyze each of these aspects.

次のサブセクションでは、これらの各側面を分析します。

A.1. Domain as a Whole

A.1. 全体としてのドメイン

* Why does the domain exist? (e.g., human choice, administrative policy, orchestration requirements, technical requirements such as operational partitioning for scaling reasons)

* ドメインが存在するのはなぜですか？（例：人間の選択、管理ポリシー、オーケストレーション要件、スケーリング上の理由による運用上のパーティション分割などの技術要件）

* If there are special requirements, are they at Layer 2, Layer 3, or an upper layer?

* 特別な要件がある場合、それらはレイヤー2、レイヤー3、または上位レイヤーにありますか？

* Where does the domain lie on the spectrum between completely managed by humans and completely autonomic?

* ドメインは、人間が完全に管理しているものと完全に自律的なものの間のどこにあるのでしょうか。

* If managed, what style of management applies? (Manual configuration, automated configuration, orchestration?)

* 管理されている場合、どのような管理スタイルが適用されますか？（手動構成、自動構成、オーケストレーション？）

* Is there a policy model? (Intent, configuration policies?)

* ポリシーモデルはありますか？（意図、構成ポリシー？）

* Does the domain provide controlled or paid service or open access?

* ドメインは、制御または有料サービスまたはオープンアクセスを提供していますか？

A.2. Individual Nodes

A.2. 個々のノード

* Is a domain member a complete node or only one interface of a node?

* ドメインメンバーは完全なノードですか、それともノードの1つのインターフェイスだけですか？

* Are nodes permanent members of a given domain, or are join and leave operations possible?

* ノードは特定のドメインの永続的なメンバーですか、それとも参加と脱退の操作が可能ですか？

* Are nodes physical or virtual devices?

* ノードは物理デバイスですか、仮想デバイスですか？

* Are virtual nodes general purpose or limited to specific functions, applications, or users?

* 仮想ノードは汎用ですか、それとも特定の機能、アプリケーション、またはユーザーに限定されますか？

* Are nodes constrained (by battery, etc.)?

* ノードは（バッテリーなどによって）制約されていますか？

* Are devices installed "out of the box" or pre-configured?

* デバイスは「そのまま」インストールされるか、事前に構成されていますか？

A.3. Domain Boundary

A.3. ドメイン境界

* How is the domain boundary identified or defined?

* ドメイン境界はどのように識別または定義されますか？

* Is the domain boundary fixed or dynamic?

* ドメイン境界は固定ですか、それとも動的ですか？

* Are boundary nodes special, or can any node be at the boundary?

* 境界ノードは特別ですか、それとも任意のノードを境界に置くことができますか？

A.4. Topology

A.4. トポロジー

* Is the domain a subset of a Layer 2 or 3 connectivity domain?

* ドメインはレイヤー2または3接続ドメインのサブセットですか？

* Does the domain overlap other domains? (In other words, is a node allowed to be a member of multiple domains?)

* ドメインは他のドメインと重複していますか？（つまり、ノードは複数のドメインのメンバーになることができますか？）

* Does the domain match physical topology, or does it have a virtual (overlay) topology?

* ドメインは物理トポロジに一致しますか、それとも仮想（オーバーレイ）トポロジがありますか？

* Is the domain in a single building, vehicle, or campus? Or is it distributed?

* ドメインは単一の建物、車両、またはキャンパス内にありますか？それとも配布されていますか？

* If distributed, are the interconnections private or over the Internet?

* 分散されている場合、相互接続はプライベートですか、それともインターネット経由ですか？

* In IP addressing terms, is the domain Link local, Site local, or Global?

* IPアドレッシング用語で、ドメインはリンクローカル、サイトローカル、またはグローバルですか？

* Does the scope of IP unicast or multicast addresses map to the domain boundary?

* IPユニキャストまたはマルチキャストアドレスのスコープはドメイン境界にマッピングされますか？

A.5. Technology

A.5. 技術

* What routing protocol(s) or different forwarding mechanisms (MPLS or other non-IP mechanism) are used?

* どのルーティングプロトコルまたは異なる転送メカニズム（MPLSまたはその他の非IPメカニズム）が使用されていますか？

* In an overlay domain, what overlay technique is used (L2VPN, L3VPN, etc.)?

* オーバーレイドメインでは、どのようなオーバーレイ技術が使用されていますか（L2VPN、L3VPNなど）？

* Are there specific QoS requirements?

* 特定のQoS要件はありますか？

* Link latency - Normal or long latency links?

* リンク遅延-通常のリンクまたは長い遅延リンク？

* Mobility - Are nodes mobile? Is the whole network mobile?

* モビリティ-ノードはモバイルですか？ネットワーク全体がモバイルですか？

* Which specific technologies, such as those in Section 4, are applicable?

* セクション4にあるような特定の技術はどれが適用可能ですか？

A.6. Connection to the Internet

A.6. インターネットへの接続

* Is the Internet connection permanent or intermittent? (Never connected is out of scope.)

* インターネット接続は永続的ですか、それとも断続的ですか？（接続されていることは範囲外です。）

* What traffic is blocked, in and out?

* どのようなトラフィックがブロックされていますか？

* What traffic is allowed, in and out?

* どのようなトラフィックが許可されていますか？

* What traffic is transformed, in and out?

* どのトラフィックが内外に変換されますか？

* Is secure and privileged remote access needed?

* 安全で特権的なリモートアクセスが必要ですか？

* Does the domain allow unprivileged remote sessions?

* ドメインは非特権リモートセッションを許可しますか？

A.7. Security, Trust, and Privacy Model

A.7. セキュリティ、信頼、プライバシーモデル

* Must domain members be authorized?

* ドメインメンバーを承認する必要がありますか？

* Are all nodes in the domain at the same trust level?

* ドメイン内のすべてのノードが同じ信頼レベルにありますか？

* Is traffic authenticated?

* トラフィックは認証されていますか？

* Is traffic encrypted?

* トラフィックは暗号化されていますか？

* What is hidden from the outside?

* 外部から何が隠されていますか？

A.8. Operations

A.8. 操作

* Safety level - Does the domain have a critical (human) safety role?

* 安全レベル-ドメインには重要な（人間の）安全の役割がありますか？

* Reliability requirement - Normal or 99.999%?

* 信頼性要件-通常または99.999％

* Environment - Hazardous conditions?

* 環境-危険な条件？

* Installation - Are specialists needed?

* インストール-専門家は必要ですか？

* Service visits - Easy, difficult, or impossible?

* サービス訪問-簡単ですか、難しいですか、それとも不可能ですか？

* Software/firmware updates - Possible or impossible?

* ソフトウェア/ファームウェアの更新-可能か不可能か？

A.9. Making Use of This Taxonomy

A.9. この分類法を利用する

This taxonomy could be used to design or analyze a specific type of limited domain. For the present document, it is intended only to form a background to the scope of protocols used in limited domains and the mechanisms required to securely define domain membership and properties.

この分類法は、特定のタイプの限定ドメインを設計または分析するために使用できます。このドキュメントでは、限られたドメインで使用されるプロトコルの範囲と、ドメインのメンバーシップとプロパティを安全に定義するために必要なメカニズムの背景を形成することのみを目的としています。

Acknowledgements

謝辞

Useful comments were received from Amelia Andersdotter, Edward Birrane, David Black, Ron Bonica, Mohamed Boucadair, Tim Chown, Darren Dukes, Donald Eastlake, Adrian Farrel, Tom Herbert, Ben Kaduk, John Klensin, Mirja Kuehlewind, Warren Kumari, Andy Malis, Michael Richardson, Mark Smith, Rick Taylor, Niels ten Oever, and others.

アメリア・アンダースドッター、エドワード・ビラン、デビッド・ブラック、ロン・ボニカ、モハメド・ブカデール、ティム・チョウン、ダレン・デュークス、ドナルド・イーストレイク、エイドリアン・ファレル、トム・ハーバート、ベン・カドゥック、ジョン・クレンシン、ミルジャ・キュールウィンド、ウォーレン・クマリ、アンディ・マリスから有用なコメントが寄せられた。マイケル・リチャードソン、マーク・スミス、リック・テイラー、ニールス・テン・オーヴァーなど。

Contributors

貢献者

Sheng Jiang Huawei Technologies Q14, Huawei Campus No. 156 Beiqing Road Hai-Dian District, Beijing 100095 China

S横江hu AはテクノロジーQ14、hu Aはキャンパス番号156はi青道路H艾-Dイアン地区、北京100095中国

   Email: jiangsheng@huawei.com

Authors' Addresses

著者のアドレス

Brian Carpenter The University of Auckland School of Computer Science University of Auckland PB 92019 Auckland 1142 New Zealand

ブライアンカーペンターオークランド大学コンピュータサイエンス学部オークランド大学PB 92019オークランド1142ニュージーランド

   Email: brian.e.carpenter@gmail.com

Bing Liu Huawei Technologies Q14, Huawei Campus No. 156 Beiqing Road Hai-Dian District, Beijing 100095 China

Bing l IU hu AはテクノロジーQ14、hu Aはキャンパス番号156はi青路H艾-Dイアン地区、北京100095中国

   Email: leo.liubing@huawei.com