[要約] RFC 8368は、ネットワークの運用、管理、および保守（OAM）の安定した接続性のために自律制御プレーンを使用する方法について説明しています。このRFCの目的は、ネットワークのOAM機能を改善し、自律的な制御プレーンの利点を活用することです。
Internet Engineering Task Force (IETF) T. Eckert, Ed.
Request for Comments: 8368 Huawei
Category: Informational M. Behringer
ISSN: 2070-1721 May 2018
Using an Autonomic Control Plane for Stable Connectivity of Network Operations, Administration, and Maintenance (OAM)
オートノミックコントロールプレーンを使用してネットワークの運用、管理、保守（OAM）を安定的に接続
Abstract
概要
Operations, Administration, and Maintenance (OAM), as per BCP 161, for data networks is often subject to the problem of circular dependencies when relying on connectivity provided by the network to be managed for the OAM purposes.
データネットワークのBCP 161に基づく運用、管理、保守（OAM）は、OAMの目的で管理されるネットワークによって提供される接続に依存している場合、循環依存関係の問題の影響を受けることがよくあります。
Provisioning while bringing up devices and networks tends to be more difficult to automate than service provisioning later on. Changes in core network functions impacting reachability cannot be automated because of ongoing connectivity requirements for the OAM equipment itself, and widely used OAM protocols are not secure enough to be carried across the network without security concerns.
デバイスとネットワークを立ち上げる間のプロビジョニングは、後のサービスプロビジョニングよりも自動化が難しい傾向があります。 OAM機器自体の継続的な接続要件のため、到達可能性に影響を与えるコアネットワーク機能の変更を自動化することはできません。また、広く使用されているOAMプロトコルは、セキュリティ上の懸念なしにネットワーク全体に伝送するには安全ではありません。
This document describes how to integrate OAM processes with an autonomic control plane in order to provide stable and secure connectivity for those OAM processes. This connectivity is not subject to the aforementioned circular dependencies.
このドキュメントでは、OAMプロセスに安定した安全な接続を提供するために、OAMプロセスをオートノミックコントロールプレーンと統合する方法について説明します。この接続は、前述の循環依存関係の影響を受けません。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。 Internet Engineering Steering Group（IESG）による公開が承認されています。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補であるとは限りません。 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/rfc8368.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8368で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Self-Dependent OAM Connectivity . . . . . . . . . . . . . 3
1.2. Data Communication Networks (DCNs) . . . . . . . . . . . 3
1.3. Leveraging a Generalized Autonomic Control Plane . . . . 4
2. GACP Requirements . . . . . . . . . . . . . . . . . . . . . . 5
3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Stable Connectivity for Centralized OAM . . . . . . . . . 6
3.1.1. Simple Connectivity for Non-GACP-Capable
NMS Hosts . . . . . . . . . . . . . . . . . . . . . . 7
3.1.2. Challenges and Limitations of Simple Connectivity . . 8
3.1.3. Simultaneous GACP and Data-Plane Connectivity . . . . 9
3.1.4. IPv4-Only NMS Hosts . . . . . . . . . . . . . . . . . 10
3.1.5. Path Selection Policies . . . . . . . . . . . . . . . 12
3.1.6. Autonomic NOC Device/Applications . . . . . . . . . . 16
3.1.7. Encryption of Data-Plane Connections . . . . . . . . 16
3.1.8. Long-Term Direction of the Solution . . . . . . . . . 17
3.2. Stable Connectivity for Distributed Network/OAM . . 18
4. Architectural Considerations . . . . . . . . . . . . . . . . 18
4.1. No IPv4 for GACP . . . . . . . . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Normative References . . . . . . . . . . . . . . . . . . 21
7.2. Informative References . . . . . . . . . . . . . . . . . 22
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
Operations, Administration, and Maintenance (OAM), as per BCP 161 [RFC6291], for data networks is often subject to the problem of circular dependencies when relying on the connectivity service provided by the network to be managed. OAM can easily but unintentionally break the connectivity required for its own operations. Avoiding these problems can lead to complexity in OAM. This document describes this problem and how to use an autonomic control plane to solve it without further OAM complexity.
データネットワークのBCP 161 [RFC6291]による運用、管理、および保守（OAM）は、管理対象のネットワークによって提供される接続サービスに依存している場合、循環依存関係の問題の影響を受けることがよくあります。 OAMは、独自の操作に必要な接続を簡単に、しかし意図せずに切断する可能性があります。これらの問題を回避すると、OAMが複雑になる可能性があります。このドキュメントでは、この問題と、オートノミックコントロールプレーンを使用してOAMをさらに複雑にすることなく解決する方法について説明します。
The ability to perform OAM on a network device requires first the execution of OAM necessary to create network connectivity to that device in all intervening devices. This typically leads to sequential "expanding ring configuration" from a Network Operations Center (NOC). It also leads to tight dependencies between provisioning tools and security enrollment of devices. Any process that wants to enroll multiple devices along a newly deployed network topology needs to tightly interlock with the provisioning process that creates connectivity before the enrollment can move on to the next device.
ネットワークデバイスでOAMを実行するには、最初に、介在するすべてのデバイスでそのデバイスへのネットワーク接続を作成するために必要なOAMを実行する必要があります。これは通常、ネットワークオペレーションセンター（NOC）からの順次「拡張リング構成」につながります。また、プロビジョニングツールとデバイスのセキュリティ登録の間の緊密な依存関係にもつながります。新しく展開されたネットワークトポロジに沿って複数のデバイスを登録するプロセスは、登録を次のデバイスに移す前に接続を作成するプロビジョニングプロセスと緊密に連動する必要があります。
Likewise, when performing change operations on a network, it is necessary to understand at any step of that process that there is no interruption of connectivity that could lead to removal of connectivity to remote devices. This includes especially change provisioning of routing, forwarding, security, and addressing policies in the network that often occur through mergers and acquisitions, the introduction of IPv6, or other major overhauls of the infrastructure design. Examples include change of an IGP or area, change from Provider Aggregatable (PA) to Provider Independent (PI) addressing, or systematic topology changes (such as Layer 2 to Layer 3 changes).
同様に、ネットワーク上で変更操作を実行するときは、そのプロセスの任意のステップで、リモートデバイスへの接続の削除につながる可能性のある接続の中断がないことを理解する必要があります。これには、合併や買収、IPv6の導入、その他のインフラストラクチャ設計の大幅な見直しを通じて頻繁に発生する、ネットワーク内のルーティング、転送、セキュリティ、およびアドレス指定ポリシーのプロビジョニングの変更が含まれます。例には、IGPまたはエリアの変更、プロバイダー集約可能（PA）からプロバイダー独立（PI）アドレッシングへの変更、または体系的なトポロジー変更（レイヤー2からレイヤー3への変更など）が含まれます。
All these circular dependencies make OAM complex and potentially fragile. When automation is being used (for example, through provisioning systems), this complexity extends into that automation software.
これらの循環依存関係はすべて、OAMを複雑にし、潜在的に脆弱にします。自動化が使用されている場合（たとえば、プロビジョニングシステムを介して）、この複雑さはその自動化ソフトウェアにまで及びます。
In the late 1990s and early 2000, IP networks became the method of choice to build separate OAM networks for the communications infrastructure within Network Providers. This concept was standardized in ITU-T G.7712/Y.1703 [ITUT_G7712] and called "Data Communications Networks" (DCNs). These were (and still are) physically separate IP or IP/MPLS networks that provide access to OAM interfaces of all equipment that had to be managed, from Public Switched Telephone Network (PSTN) switches over optical equipment to nowadays Ethernet and IP/MPLS production network equipment.
1990年代後半から2000年初頭にかけて、ネットワークプロバイダー内の通信インフラストラクチャ用に個別のOAMネットワークを構築する方法として、IPネットワークが選択されました。この概念はITU-T G.7712 / Y.1703 [ITUT_G7712]で標準化され、「データ通信ネットワーク」（DCN）と呼ばれていました。これらは物理的に分離されたIPまたはIP / MPLSネットワークであり、光学機器を介した公衆交換電話網（PSTN）スイッチから現在のイーサネットおよびIP / MPLS生産まで、管理する必要があったすべての機器のOAMインターフェイスへのアクセスを提供しますネットワーク機器。
Such DCNs provide stable connectivity not subject to the aforementioned problems because they are a separate network entirely, so change configuration of the production IP network is done via the DCN but never affects the DCN configuration. Of course, this approach comes at a cost of buying and operating a separate network, and this cost is not feasible for many providers -- most notably, smaller providers, most enterprises, and typical Internet of Things (IoT) networks.
このようなDCNは、完全に独立したネットワークであるため、前述の問題の影響を受けない安定した接続を提供します。したがって、運用IPネットワークの構成の変更はDCNを介して行われますが、DCN構成には影響しません。もちろん、このアプローチには別のネットワークを購入して運用するというコストが伴います。このコストは、多くのプロバイダー、特に小規模なプロバイダー、ほとんどの企業、および一般的なモノのインターネット（IoT）ネットワークにとって実現可能ではありません。
One of the goals of the IETF ANIMA (Autonomic Networking Integrated Model and Approach) Working Group is the specification of a secure and automatically built in-band management plane that provides stable connectivity similar to a DCN, but without having to build a separate DCN. It is clear that such an "in-band" approach can never fully achieve the same level of separation, but the goal is to get as close to it as possible.
IETF ANIMA（オートノミックネットワーキング統合モデルおよびアプローチ）ワーキンググループの目標の1つは、DCNと同様の安定した接続を提供する、安全で自動的に構築される帯域内管理プレーンの仕様ですが、個別のDCNを構築する必要はありません。このような「インバンド」アプローチでは、同じレベルの分離を完全に達成することはできないことは明らかですが、目標は、可能な限りそれに近づけることです。
This document discusses how such an in-band management plane can be used to support the DCN-like OAM use case, how to leverage its stable connectivity, and what the options are for deploying it incrementally in the short and long term.
このドキュメントでは、そのようなインバンド管理プレーンを使用してDCNのようなOAMユースケースをサポートする方法、その安定した接続を活用する方法、および短期的および長期的に段階的に導入するためのオプションについて説明します。
The ANIMA Working Group's evolving specification [ACP] calls this in-band management plane the "Autonomic Control Plane" (ACP). The discussions in this document are not dependent on the specification of that ACP, but only on a set of high-level constraints listed below, which were decided upon early during the work on the ACP. Except when being specific about details of the ACP, this document uses the term "Generalized ACP" (GACP) and is applicable to any designs that meet the high-level constraints -- for example, the variations of the ACP protocol choices.
ANIMAワーキンググループの進化する仕様[ACP]は、この帯域内管理プレーンを "オートノミックコントロールプレーン"（ACP）と呼んでいます。このドキュメントの説明は、そのACPの仕様に依存するのではなく、ACPの作業の初期に決定された、以下にリストされている一連の高レベルの制約にのみ依存します。 ACPの詳細について具体的に説明する場合を除き、このドキュメントでは「一般化ACP」（GACP）という用語を使用しており、ACPプロトコルの選択肢のバリエーションなど、高レベルの制約を満たすすべての設計に適用できます。
The high-level constraints of a GACP assumed and discussed in this document are as follows:
このドキュメントで想定および説明されているGACPの高レベルの制約は次のとおりです。
VRF isolation: The GACP is a virtual network (Virtual Routing and Forwarding (VRF)) across network devices; its routing and forwarding are separate from other routing and forwarding in the network devices. Non-GACP routing/forwarding is called the "data plane".
VRF分離：GACPは、ネットワークデバイス全体の仮想ネットワーク（Virtual Routing and Forwarding（VRF））です。そのルーティングと転送は、ネットワークデバイス内の他のルーティングと転送から分離されています。非GACPルーティング/転送は「データプレーン」と呼ばれます。
IPv6-only addressing: The GACP provides only IPv6 reachability. It uses Unique Local Addresses (ULAs) [RFC4193] that are routed in a location-independent fashion, for example, through a subnet prefix for each network device. Therefore, automatic addressing in the GACP is simple and stable: it does not require allocation by address registries, addresses are identifiers, they do not change when devices move, and no engineering of the address space to the network topology is necessary.
IPv6のみのアドレッシング：GACPはIPv6到達可能性のみを提供します。たとえば、各ネットワークデバイスのサブネットプレフィックスを介して、場所に依存しない方法でルーティングされる一意のローカルアドレス（ULA）[RFC4193]を使用します。したがって、GACPでの自動アドレッシングはシンプルで安定しています。アドレスレジストリによる割り当ては不要であり、アドレスは識別子であり、デバイスが移動しても変化せず、ネットワークトポロジに対するアドレス空間のエンジニアリングは必要ありません。
NOC connectivity: NOC equipment (controlling OAM operations) either has access to the GACP directly or has an IP subnet connection to a GACP edge device.
NOC接続：NOC機器（OAMオペレーションを制御）は、GACPに直接アクセスするか、GACPエッジデバイスにIPサブネット接続します。
Closed Group Security: GACP devices have cryptographic credentials to mutually authenticate each other as members of a GACP. Traffic across the GACP is authenticated with these credentials and then encrypted.
クローズドグループセキュリティ：GACPデバイスには、GACPのメンバーとして相互に認証するための暗号化された資格情報があります。 GACPを通過するトラフィックは、これらの資格情報で認証され、暗号化されます。
GACP connect (interface): The only traffic permitted in and out of the GACP that is not authenticated by GACP cryptographic credentials is through explicit configuration for the traffic from/to the aforementioned non-GACP NOC equipment with subnet connections to a GACP edge device (as a transition method).
GACP接続（インターフェイス）：GACP暗号化資格情報によって認証されない、GACPの内外で許可される唯一のトラフィックは、GACPエッジデバイスへのサブネット接続を持つ前述の非GACP NOC機器との間のトラフィックの明示的な構成によるものです（移行方法として）。
The GACP must be built to be autonomic and its function must not be able to be disrupted by operator or automated configuration/ provisioning actions (i.e., Network Management System (NMS) or Software-Defined Networking (SDN)). Those actions are allowed to impact only the data plane. This document does not cover those aspects; instead, it focuses on the impact of the above constraints: IPv6 only, dual connectivity, and security.
GACPはオートノミックになるように構築する必要があり、その機能がオペレーターまたは自動構成/プロビジョニングアクション（つまり、ネットワーク管理システム（NMS）またはソフトウェア定義ネットワーク（SDN））によって中断されてはなりません。これらのアクションは、データプレーンにのみ影響を与えることが許可されています。このドキュメントでは、これらの側面については説明しません。代わりに、IPv6のみ、デュアル接続、およびセキュリティという上記の制約の影響に焦点を当てています。
The ANI is the Autonomic Networking Infrastructure consisting of secure zero-touch bootstrap (BRSKI [BRSKI]), the GeneRic Autonomic Signaling Protocol (GRASP [GRASP]), and Autonomic Control Plane (ACP [ACP]). Refer to the reference model [REF_MODEL] for an overview of the ANI and how its components interact and [RFC7575] for concepts and terminology of ANI and autonomic networks.
ANIは、安全なゼロタッチブートストラップ（BRSKI [BRSKI]）、GeneRic Autonomic Signaling Protocol（GRASP [GRASP]）、およびAutonomic Control Plane（ACP [ACP]）で構成されるオートノミックネットワークインフラストラクチャです。 ANIの概要とそのコンポーネントの相互作用については参照モデル[REF_MODEL]を、ANIとオートノミックネットワークの概念と用語については[RFC7575]を参照してください。
This section describes stable connectivity for centralized OAM via the GACP, for example, via the ACP with or without a complete ANI, starting with the option that we expect to be the most easy to deploy in the short term. It then describes limitations and challenges of that approach and the corresponding solutions and workarounds; it finishes with the preferred target option of autonomic NOC devices in Section 3.1.6.
このセクションでは、GACPを介した集中型OAMの安定した接続について説明します。たとえば、完全なANIの有無に関係なく、ACPを介して、短期的に最も簡単に展開できると予想されるオプションから始めます。次に、そのアプローチの制限と課題、対応するソリューションと回避策について説明します。それは、セクション3.1.6の自律型NOCデバイスの優先ターゲットオプションで終了します。
This order was chosen because it helps to explain how simple initial use of a GACP can be and how difficult workarounds can become (and therefore what to avoid). Also, one very promising long-term solution is exactly like the most easy short-term solution, only virtualized and automated.
この順序が選択されたのは、GACPの最初の使用がいかに簡単であり、回避策がどれほど困難になるか（したがって、何を回避するか）を説明するのに役立つためです。また、非常に有望な長期ソリューションの1つは、仮想化および自動化された、最も簡単な短期ソリューションとまったく同じです。
In the most common case, OAM will be performed by one or more applications running on a variety of centralized NOC systems that communicate with network devices. This document describes approaches to leverage a GACP for stable connectivity, from simple to complex, depending on the capabilities and limitations of the equipment used.
最も一般的なケースでは、OAMは、ネットワークデバイスと通信するさまざまな集中型NOCシステムで実行される1つ以上のアプリケーションによって実行されます。このドキュメントでは、使用する機器の機能と制限に応じて、単純なものから複雑なものまで、安定した接続のためにGACPを活用するアプローチについて説明します。
Three stages can be considered:
次の3つの段階を考慮することができます。
o There are simple options described in Sections 3.1.1 through 3.1.3 that we consider to be good starting points to operationalize the use of a GACP for stable connectivity today. These options require only network and OAM/NOC device configuration.
o セクション3.1.1から3.1.3で説明されている簡単なオプションは、今日の安定した接続のためにGACPの使用を運用可能にするための良い出発点と考えています。これらのオプションでは、ネットワークとOAM / NOCデバイスの構成のみが必要です。
o The are workarounds to connect a GACP to non-IPv6-capable NOC devices through the use of IPv4/IPv6 NAT (Network Address Translation) as described in Section 3.1.4. These workarounds are not recommended; however, if non-IPv6-capable NOC devices need to be used longer term, then the workarounds are the only way to connect them to a GACP.
o セクション3.1.4で説明されているように、IPv4 / IPv6 NAT（ネットワークアドレス変換）を使用してGACPを非IPv6対応NOCデバイスに接続するための回避策があります。これらの回避策は推奨されません。ただし、IPv6非対応のNOCデバイスを長期間使用する必要がある場合は、回避策がデバイスをGACPに接続する唯一の方法です。
o Options for the near to long term can provide all the desired operational, zero-touch, and security benefits of an autonomic network, but a range of details for this still have to be worked out, and development work on NOC/OAM equipment is necessary. These options are discussed in Sections 3.1.5 through 3.1.8.
o 短期から長期のオプションは、オートノミックネットワークの望ましい運用、ゼロタッチ、およびセキュリティのすべての利点を提供できますが、これについての詳細の範囲はまだ解決する必要があり、NOC / OAM機器の開発作業が必要です。 。これらのオプションについては、セクション3.1.5から3.1.8で説明します。
In the most simple candidate deployment case, the GACP extends all the way into the NOC via one or more GACP edge devices. See also Section 6.1 of [ACP]. These devices "leak" the (otherwise encrypted) GACP natively to NMS hosts. They act as the default routers to those NMS hosts and provide them with IPv6 connectivity into the GACP. NMS hosts with this setup need to support IPv6 (e.g., see [RFC6434]) but require no other modifications to leverage the GACP.
最も単純な候補展開のケースでは、GACPは1つ以上のGACPエッジデバイスを介してNOCまで拡張されます。 [ACP]のセクション6.1も参照してください。これらのデバイスは、（そうでなければ暗号化された）GACPをネイティブにNMSホストに「リーク」します。それらは、それらのNMSホストへのデフォルトルーターとして機能し、GACPへのIPv6接続を提供します。この設定のNMSホストはIPv6をサポートする必要がありますが（たとえば、[RFC6434]を参照）、GACPを活用するために他の変更は必要ありません。
Note that even though the GACP only uses IPv6, it can of course support OAM for any type of network deployment as long as the network devices support the GACP: The data plane can be IPv4 only, dual stack, or IPv6 only. It is always separate from the GACP; therefore, there is no dependency between the GACP and the IP version(s) used in the data plane.
GACPはIPv6のみを使用しますが、ネットワークデバイスがGACPをサポートしている限り、もちろんあらゆるタイプのネットワーク展開でOAMをサポートできます。データプレーンはIPv4のみ、デュアルスタック、またはIPv6のみにすることができます。これは常にGACPとは別のものです。したがって、GACPとデータプレーンで使用されるIPバージョンの間に依存関係はありません。
This setup is sufficient for troubleshooting mechanisms such as SSH into network devices, NMS that performs SNMP read operations for status checking, software downloads onto autonomic devices, provisioning of devices via NETCONF, and so on. In conjunction with otherwise unmodified OAM via separate NMS hosts, this setup can provide a good subset of the stable connectivity goals. The limitations of this approach are discussed in the next section.
このセットアップは、ネットワークデバイスへのSSH、ステータスチェックのためのSNMP読み取り操作を実行するNMS、オートノミックデバイスへのソフトウェアのダウンロード、NETCONFを介したデバイスのプロビジョニングなどのトラブルシューティングメカニズムに十分です。別のNMSホストを介して変更されていないOAMと組み合わせて、このセットアップは安定した接続目標の良いサブセットを提供できます。このアプローチの制限については、次のセクションで説明します。
Because the GACP provides "only" for IPv6 connectivity, and because addressing provided by the GACP does not include any topological addressing structure that a NOC often relies on to recognize where devices are on the network, it is likely highly desirable to set up the Domain Name System (DNS; see [RFC1034]) so that the GACP IPv6 addresses of autonomic devices are known via domain names that include the desired structure. For example, if DNS in the network were set up with names for network devices as devicename.noc.example.com, and if the well-known structure of the data-plane IPv4 address space were used by operators to infer the region where a device is located, then the GACP address of that device could be set up as devicename_<region>.acp.noc.example.com, and devicename.acp.noc.example.com could be a CNAME to devicename_<region>.acp.noc.example.com. Note that many networks already use names for network equipment where topological information is included, even without a GACP.
GACPはIPv6接続に「のみ」を提供し、GACPによって提供されるアドレッシングには、デバイスがネットワーク上のどこにあるかを認識するためにNOCがしばしば依存するトポロジーアドレッシング構造が含まれないため、ドメインをセットアップすることが非常に望ましいネームシステム（DNS。[RFC1034]を参照）。オートノミックデバイスのGACP IPv6アドレスが、必要な構造を含むドメイン名を介して認識されるようにします。たとえば、ネットワーク内のDNSがネットワークデバイスの名前でdevicename.noc.example.comとしてセットアップされていて、データプレーンIPv4アドレス空間の既知の構造がオペレーターによって使用されている地域を推測するために使用されている場合デバイスが見つかったら、そのデバイスのGACPアドレスをdevicename_ <region> .acp.noc.example.comとして設定し、devicename.acp.noc.example.comをdevicename_ <region> .acpへのCNAMEにすることができます。 .noc.example.com。 GACPがなくても、多くのネットワークはトポロジー情報が含まれているネットワーク機器の名前をすでに使用していることに注意してください。
This simple connectivity of non-autonomic NMS hosts suffers from a range of challenges (that is, operators may not be able to do it this way) and limitations (that is, operators cannot achieve desired goals with this setup). The following list summarizes these challenges and limitations, and the following sections describe additional mechanisms to overcome them.
非自律型NMSホストのこの単純な接続は、さまざまな課題（つまり、オペレーターがこの方法でこれを行うことができない場合があります）と制限（つまり、オペレーターがこの設定で目的を達成できない）に悩まされています。次のリストは、これらの課題と制限をまとめたものであり、次のセクションでは、それらを克服するための追加のメカニズムについて説明します。
Note that these challenges and limitations exist because GACP is primarily designed to support distributed Autonomic Service Agent (ASA), a piece of autonomic software, in the most lightweight fashion. GACP is not required to support the additional mechanisms needed for centralized NOC systems. It is this document that describes additional (short-term) workarounds and (long-term) extensions.
GACPは主に、自律型ソフトウェアの一部である分散型オートノミックサービスエージェント（ASA）を最も軽量な方法でサポートするように設計されているため、これらの課題と制限が存在することに注意してください。 GACPは、集中型NOCシステムに必要な追加のメカニズムをサポートする必要はありません。追加の（短期的な）回避策と（長期的な）拡張機能について説明するのは、このドキュメントです。
1. (Limitation) NMS hosts cannot directly probe whether the desired so-called "data-plane" network connectivity works because they do not directly have access to it. This problem is similar to probing connectivity for other services (such as VPN services) that they do not have direct access to, so the NOC may already employ appropriate mechanisms to deal with this issue (probing proxies). See Section 3.1.3 for candidate solutions.
1. （制限）NMSホストは直接アクセスできないため、目的のいわゆる「データプレーン」ネットワーク接続が機能しているかどうかを直接プローブできません。この問題は、直接アクセスできない他のサービス（VPNサービスなど）のプローブ接続に似ているため、NOCはすでにこの問題に対処するために適切なメカニズム（プローブプロキシ）を採用している場合があります。候補ソリューションについては、セクション3.1.3を参照してください。
2. (Challenge) NMS hosts need to support IPv6, and this often is still not possible in enterprise networks. See Section 3.1.4 for some workarounds.
2. （課題）NMSホストはIPv6をサポートする必要があり、これは多くの場合、エンタープライズネットワークではまだ不可能です。いくつかの回避策については、セクション3.1.4を参照してください。
3. (Limitation) Performance of the GACP may be limited versus normal "data-plane" connectivity. The setup of the GACP will often support only forwarding that is not hardware accelerated. Running a large amount of traffic through the GACP, especially for tasks where it is not necessary, will reduce its performance and effectiveness for those operations where it is necessary or highly desirable. See Section 3.1.5 for candidate solutions.
3. （制限）GACPのパフォーマンスは、通常の「データプレーン」接続に対して制限される場合があります。 GACPの設定は、ハードウェアアクセラレーションではない転送のみをサポートすることがよくあります。 GACPを介して大量のトラフィックを実行すると、特に必要のないタスクでは、必要または非常に望ましい操作のパフォーマンスと効率が低下します。候補ソリューションについては、セクション3.1.5を参照してください。
4. (Limitation) Security of the GACP is reduced by exposing the GACP natively (and unencrypted) in a subnet in the NOC where the NOC devices are attached to it. See Section 3.1.7 for candidate solutions.
4. （制限）GACPのセキュリティは、NOCデバイスが接続されているNOC内のサブネットでGACPをネイティブに（暗号化せずに）公開することによって低下します。候補ソリューションについては、セクション3.1.7を参照してください。
These four problems can be tackled independently of each other by solution improvements. Combining some of these improvements together can lead towards a candidate long-term solution.
これらの4つの問題は、ソリューションの改善によって互いに独立して取り組むことができます。これらの改善のいくつかを組み合わせると、長期的なソリューションの候補につながる可能性があります。
Simultaneous connectivity to both the GACP and data plane can be achieved in a variety of ways. If the data plane is IPv4 only, then any method for dual-stack attachment of the NOC device/application will suffice: IPv6 connectivity from the NOC provides access via the GACP; IPv4 provides access via the data plane. If, as explained above in the simple case, an autonomic device supports native attachment to the GACP, and the existing NOC setup is IPv4 only, then it could be sufficient to attach the GACP device(s) as the IPv6 default router to the NOC subnet and keep the existing IPv4 default router setup unchanged.
GACPとデータプレーンの両方への同時接続は、さまざまな方法で実現できます。データプレーンがIPv4のみの場合、NOCデバイス/アプリケーションのデュアルスタック接続の方法で十分です。NOCからのIPv6接続は、GACPを介したアクセスを提供します。 IPv4は、データプレーン経由のアクセスを提供します。上記の簡単なケースで説明したように、オートノミックデバイスがGACPへのネイティブ接続をサポートし、既存のNOC設定がIPv4のみの場合、GACPデバイスをIPv6デフォルトルーターとしてNOCに接続するだけで十分な場合があります。サブネットを変更し、既存のIPv4デフォルトルーターの設定を変更しないでください。
If the data plane of the network is also supporting IPv6, then the most compatible setup for NOC devices is to have two IPv6 interfaces -- one virtual (e.g., via IEEE 802.1Q [IEEE.802.1Q]) or physical interface connecting to a data-plane subnet, and another connecting into a GACP connect subnet. See Section 8.1 of [ACP] for more details. That document also specifies how a NOC device can receive autoconfigured addressing and routes towards the ACP connect subnet if it supports default address selection as specified in [RFC6724] and default router preferences as specified in [RFC4191].
ネットワークのデータプレーンもIPv6をサポートしている場合、NOCデバイスの最も互換性のあるセットアップは、2つのIPv6インターフェースを持つことです。1つは仮想（例：IEEE 802.1Q [IEEE.802.1Q]）またはデータプレーンサブネット、およびGACP接続サブネットに接続する別のサブネット。詳細については、[ACP]のセクション8.1を参照してください。このドキュメントは、[RFC6724]で指定されているデフォルトのアドレス選択と[RFC4191]で指定されているデフォルトのルーター設定をサポートしている場合、NOCデバイスがACP接続サブネットに向けて自動構成されたアドレッシングとルートを受信する方法も指定しています。
Configuring a second interface on a NOC host may be impossible or seen as undesired complexity. In that case, the GACP edge device needs to provide support for a "combined ACP and data-plane interface" as described in Section 8.1 of [ACP]. This setup may not work with autoconfiguration and all NOC host network stacks due to limitations in those network stacks. They need to be able to perform Rule 5.5 of [RFC6724] regarding source address selection, including caching of next-hop information.
NOCホストで2番目のインターフェースを構成することは不可能であるか、望ましくない複雑さであると見なされる場合があります。その場合、GACPエッジデバイスは、[ACP]のセクション8.1で説明されている「結合されたACPとデータプレーンインターフェース」のサポートを提供する必要があります。これらのネットワークスタックの制限により、この設定は自動構成およびすべてのNOCホストネットワークスタックで機能しない場合があります。彼らは、ネクストホップ情報のキャッシングを含む送信元アドレスの選択に関して、[RFC6724]のルール5.5を実行できる必要があります。
For security reasons, it is not considered appropriate to connect a non-GACP router to a GACP connect interface. The reason is that the GACP is a secured network domain, and all NOC devices connecting via GACP connect interfaces are also part of that secure domain. The main difference is that the physical links between the GACP edge device and the NOC devices are not authenticated or encrypted and, therefore, need to be physically secured. If the secure GACP was extendable via untrusted routers, then it would be a lot more difficult to verify the secure domain assertion. Therefore, the GACP edge devices are not supposed to redistribute routes from non-GACP routers into the GACP.
セキュリティ上の理由から、非GACPルーターをGACP接続インターフェースに接続することは適切とは見なされません。その理由は、GACPが安全なネットワークドメインであり、GACP接続インターフェースを介して接続するすべてのNOCデバイスもその安全なドメインの一部であるためです。主な違いは、GACPエッジデバイスとNOCデバイス間の物理リンクが認証または暗号化されないため、物理的に保護する必要があることです。セキュアなGACPが信頼できないルーターを介して拡張可能である場合、セキュアなドメインのアサーションを確認することははるかに困難になります。したがって、GACPエッジデバイスは、非GACPルーターからGACPにルートを再配布することは想定されていません。
One architectural expectation for the GACP as described in Section 1.3 is that all devices that want to use the GACP (including NMS hosts) support IPv6. Note that this expectation does not imply any requirements for the data plane, especially it does not imply that IPv6 must be supported in it. The data plane could be IPv4 only, IPv6 only, dual stack, or it may not need to have any IP host stack on the network devices.
1.3節で説明したGACPのアーキテクチャ上の期待の1つは、GACPを使用するすべてのデバイス（NMSホストを含む）がIPv6をサポートすることです。この期待は、データプレーンの要件を意味するものではないことに注意してください。特に、IPv6をサポートする必要があることを意味するものではありません。データプレーンには、IPv4のみ、IPv6のみ、デュアルスタックを使用できます。また、ネットワークデバイスにIPホストスタックがなくてもかまいません。
The implication of this architectural decision is the potential need for short-term workarounds when the operational practices in a network do not yet meet these target expectations. This section explains when and why these workarounds may be operationally necessary and describes them. However, the long-term goal is to upgrade all NMS hosts to native IPv6, so the workarounds described in this section should not be considered permanent.
このアーキテクチャ上の決定の意味するところは、ネットワークの運用慣行がこれらの目標の期待をまだ満たしていない場合の短期的な回避策の潜在的な必要性です。このセクションでは、これらの回避策が運用上必要な場合とその理由を説明し、それらについて説明します。ただし、長期的な目標はすべてのNMSホストをネイティブIPv6にアップグレードすることであるため、このセクションで説明する回避策は永続的なものと見なすべきではありません。
Most network equipment today supports IPv6, but it is very far from being ubiquitously supported in NOC backend solutions (hardware or software) or in the product space for enterprises. Even when it is supported, there are often additional limitations or issues using it in a dual-stack setup, or the operator mandates (for simplicity) single stack for all operations. For these reasons, an IPv4-only management plane is still required and common practice in many enterprises. Without the desire to leverage the GACP, this required and common practice is not a problem for those enterprises even when they run dual stack in the network. We discuss these workarounds here because it is a short-term deployment challenge specific to the operations of a GACP.
今日のほとんどのネットワーク機器はIPv6をサポートしていますが、NOCバックエンドソリューション（ハードウェアまたはソフトウェア）や企業の製品分野で広く普及しているわけではありません。それがサポートされている場合でも、デュアルスタックセットアップでの使用には追加の制限や問題があることが多く、またはオペレーターはすべての操作に対して単一のスタックを（簡単にするために）義務付けています。これらの理由から、IPv4のみの管理プレーンが依然として必要であり、多くの企業で一般的な慣行です。 GACPを活用したくない場合は、ネットワークでデュアルスタックを実行している場合でも、この必要かつ一般的な慣行は問題になりません。 GACPの運用に固有の短期的な展開の課題であるため、ここではこれらの回避策について説明します。
To connect IPv4-only management-plane devices/applications with a GACP, some form of IP/ICMP translation of packets between IPv4 and IPv6 is necessary. The basic mechanisms for this are in [RFC7915], which describes the Stateless IP/ICMP Translation Algorithm (SIIT). There are multiple solutions using this mechanism. To understand the possible solutions, we consider the requirements:
IPv4のみの管理プレーンデバイス/アプリケーションをGACPに接続するには、IPv4とIPv6間のパケットの何らかの形式のIP / ICMP変換が必要です。これの基本的なメカニズムは、ステートレスIP / ICMP変換アルゴリズム（SIIT）を説明する[RFC7915]にあります。このメカニズムを使用する複数のソリューションがあります。可能な解決策を理解するために、要件を検討します。
1. NMS hosts need to be able to initiate connections to any GACP device for management purposes. Examples include provisioning via NETCONF, SNMP poll operations, or just diagnostics via SSH connections from operators. Every GACP device/function that needs to be reachable from NMS hosts needs to have a separate IPv4 address.
1. NMSホストは、管理目的でGACPデバイスへの接続を開始できる必要があります。例には、NETCONFによるプロビジョニング、SNMPポーリング操作、またはオペレーターからのSSH接続による単なる診断が含まれます。 NMSホストから到達可能にする必要があるすべてのGACPデバイス/機能には、個別のIPv4アドレスが必要です。
2. GACP devices need to be able to initiate connections to NMS hosts, for example, to initiate NTP or RADIUS/Diameter connections, send syslog or SNMP trap, or initiate NETCONF Call Home connections after bootstrap. Every NMS host needs to have a separate IPv6 address reachable from the GACP. When a connection from a GACP device is made to an NMS host, the IPv4 source address of the connection (as seen by the NMS host) must be unique per GACP device and must be the same address as in (1) to maintain addressing simplicity similar to a native IPv4 deployment. For example in syslog, the source IP address of a logging device is used to identify it, and if the device shows problems, an operator might want to SSH into the device to diagnose it.
2. GACPデバイスは、NMSホストへの接続を開始できる必要があります。たとえば、NTPまたはRADIUS / Diameter接続を開始したり、syslogまたはSNMPトラップを送信したり、ブートストラップ後にNETCONF Call Home接続を開始したりできます。すべてのNMSホストには、GACPから到達可能な個別のIPv6アドレスが必要です。 GACPデバイスからNMSホストへの接続が行われる場合、接続のIPv4送信元アドレス（NMSホストから見たもの）はGACPデバイスごとに一意であり、（1）と同じアドレスである必要があります。ネイティブIPv4展開に似ています。たとえば、syslogでは、ロギングデバイスの送信元IPアドレスを使用してそれを識別します。デバイスに問題がある場合、オペレーターはデバイスにSSHで接続して診断することができます。
Because of these requirements, the necessary and sufficient set of solutions are those that provide 1:1 mapping of IPv6 GACP addresses into IPv4 space and 1:1 mapping of IPv4 NMS host space into IPv6 (for use in the GACP). This means that SIIT-based solutions are sufficient and preferred.
これらの要件のため、必要かつ十分なソリューションのセットは、IPv6 GACPアドレスのIPv4スペースへの1：1マッピングとIPv4 NMSホストスペースのIPv6への1：1マッピング（GACPで使用するため）を提供するものです。これは、SIITベースのソリューションで十分かつ好ましいことを意味します。
Note that GACP devices may use multiple IPv6 addresses in the GACP. For example, Section 6.10 of [ACP] defines multiple useful addressing sub-schemes supporting this option. All those addresses may then need to be reachable through IPv6/IPv4 address translation.
GACPデバイスは、GACPで複数のIPv6アドレスを使用する場合があることに注意してください。たとえば、[ACP]のセクション6.10は、このオプションをサポートする複数の有用なアドレッシングサブスキームを定義しています。これらのアドレスはすべて、IPv6 / IPv4アドレス変換を介して到達可能である必要があります。
The need to allocate for every GACP device one or multiple IPv4 addresses should not be a problem if -- as we assume -- the NMS hosts can use private IPv4 address space ([RFC1918]). Nevertheless, even with private IPv4 address space, it is important that the GACP IPv6 addresses can be mapped efficiently into IPv4 address space without too much waste.
NMSホストがプライベートIPv4アドレス空間（[RFC1918]）を使用できる場合、すべてのGACPデバイスに1つまたは複数のIPv4アドレスを割り当てる必要は問題になりません。それでも、プライベートIPv4アドレススペースがあっても、GACP IPv6アドレスを無駄にせずにIPv4アドレススペースに効率的にマッピングできることが重要です。
Currently, the most flexible mapping scheme to achieve this is [RFC7757] because it allows configured IPv4 <-> IPv6 prefix mapping. Assume the GACP uses the ACP Zone Addressing Sub-Scheme and there are 3 registrars. In the ACP Zone Addressing Sub-Scheme, for each registrar, there is a constant /112 prefix for which an Explicit Address Mapping (EAM), as defined in RFC 7757, to a /16 prefix can be configured (e.g., in the private IPv4 address space described in [RFC1918]). Within the registrar's /112 prefix, Device-Numbers for devices are sequentially assigned: with the V bit (Virtualization bit) effectively two numbers are assigned per GACP device. This also means that if IPv4 address space is even more constrained, and it is known that a registrar will never need the full /15 extent of Device-Numbers, then a prefix longer than a /112 can be configured into the EAM in order to use less IPv4 space.
現在、これを実現するための最も柔軟なマッピングスキームは[RFC7757]です。これは、構成されたIPv4 <-> IPv6プレフィックスマッピングを許可するためです。 GACPがACPゾーンアドレス指定サブスキームを使用し、3つのレジストラがあると仮定します。 ACPゾーンアドレス指定サブスキームでは、レジストラごとに、RFC 7757で定義されている/ 16プレフィックスへの明示アドレスマッピング（EAM）を構成できる定数/ 112プレフィックスがあります（たとえば、プライベート[RFC1918]で説明されているIPv4アドレス空間。レジストラの/ 112プレフィックス内で、デバイスのデバイス番号が順番に割り当てられます。Vビット（仮想化ビット）を使用すると、GACPデバイスごとに事実上2つの番号が割り当てられます。これは、IPv4アドレススペースがさらに制約されていて、レジストラが/ 15のデバイス番号の全範囲を必要としないことがわかっている場合、/ 112より長いプレフィックスをEAMに構成して、 IPv4スペースの使用量を減らします。
When using the ACP Vlong Addressing Sub-Scheme, it is unlikely that one wants or needs to translate the full /8 or /16 of addressing space per GACP device into IPv4. In this case, the EAM rules of dropping trailing bits can be used to map only N bits of the V bits into IPv4. However, this does imply that only addresses that differ in those high-order N V bits can be distinguished on the IPv4 side.
ACP Vlongアドレッシングサブスキームを使用する場合、GACPデバイスごとのアドレス空間の/ 8または/ 16全体をIPv4に変換する必要がある、または変換する必要がある可能性は低いです。この場合、後続ビットを削除するEAMルールを使用して、VビットのNビットのみをIPv4にマッピングできます。ただし、これは、それらの上位N Vビットが異なるアドレスのみがIPv4側で区別できることを意味します。
Likewise, the IPv4 address space used for NMS hosts can easily be mapped into an address prefix assigned to a GACP connect interface.
同様に、NMSホストに使用されるIPv4アドレススペースは、GACP接続インターフェイスに割り当てられたアドレスプレフィックスに簡単にマッピングできます。
A full specification of a solution to perform SIIT in conjunction with GACP connect following the considerations below is outside the scope of this document.
以下の考慮事項に従ってGACP接続と組み合わせてSIITを実行するソリューションの完全な仕様は、このドキュメントの範囲外です。
To be in compliance with security expectations, SIIT has to happen on the GACP edge device itself so that GACP security considerations can be taken into account. For example, IPv4-only NMS hosts can be dealt with exactly like IPv6 hosts connected to a GACP connect interface.
セキュリティの期待に準拠するには、GACPのセキュリティに関する考慮事項を考慮できるように、GAITエッジデバイス自体でSIITを実行する必要があります。たとえば、IPv4のみのNMSホストは、GACP接続インターフェースに接続されたIPv6ホストとまったく同じように扱うことができます。
Note that prior solutions such as NAT64 ([RFC6146]) may equally be useable to translate between GACP IPv6 address space and NMS hosts' IPv4 address space. As a workaround, this can also be done on non-GACP Edge Devices connected to a GACP connect interface. The details vary depending on implementation because the options to configure address mappings vary widely. Outside of EAM, there are no standardized solutions that allow for mapping of prefixes, so it will most likely be necessary to explicitly map every individual (/128) GACP device address to an IPv4 address. Such an approach should use automation/scripting where these address translation entries are created dynamically whenever a GACP device is enrolled or first connected to the GACP network.
NAT64（[RFC6146]）などの以前のソリューションは、GACP IPv6アドレス空間とNMSホストのIPv4アドレス空間の間の変換にも同様に使用できる場合があることに注意してください。回避策として、これはGACP接続インターフェースに接続された非GACPエッジデバイスでも実行できます。アドレスマッピングを構成するオプションは大きく異なるため、詳細は実装によって異なります。 EAMの外には、プレフィックスのマッピングを可能にする標準化されたソリューションがないため、ほとんどすべての個別（/ 128）GACPデバイスアドレスをIPv4アドレスに明示的にマッピングする必要があります。このようなアプローチでは、GACPデバイスが登録されるか、GACPネットワークに最初に接続されるたびにこれらのアドレス変換エントリが動的に作成される自動化/スクリプトを使用する必要があります。
The NAT methods described here are not specific to a GACP. Instead, they are similar to what would be necessary when some parts of a network only support IPv6, but the NOC equipment does not support IPv6. Whether it is more appropriate to wait until the NOC equipment supports IPv6 or to use NAT beforehand depends in large part on how long the former will take and how easy the latter will be when using products that support the NAT options described to operationalize the above recommendations.
ここで説明するNAT方式は、GACPに固有のものではありません。代わりに、ネットワークの一部がIPv6のみをサポートしている場合に必要なものと似ていますが、NOC機器はIPv6をサポートしていません。 NOC機器がIPv6をサポートするまで待つのが適切か、NATを事前に使用するのが適切かは、前者の所要時間と、上記の推奨事項を運用するために説明されているNATオプションをサポートする製品を使用する場合の後者の容易さによって大きく異なります。 。
As mentioned above, a GACP is not expected to have high performance because its primary goal is connectivity and security. For existing network device platforms, this often means that it is a lot more effort to implement that additional connectivity with hardware acceleration than without -- especially because of the desire to support full encryption across the GACP to achieve the desired security.
上記のように、GACPの主な目的は接続性とセキュリティであるため、GACPは高いパフォーマンスを期待できません。既存のネットワークデバイスプラットフォームの場合、これは多くの場合、特にGACP全体で完全な暗号化をサポートして必要なセキュリティを実現したいため、ハードウェアアクセラレーションを使用して追加の接続を実装する方がはるかに多くの労力を要することを意味します。
Some of these issues may go away in the future with further adoption of a GACP and network device designs that better tend to the needs of a separate OAM plane, but it is wise to plan for long-term designs of the solution that do NOT depend on high performance of the GACP. This is the opposite of the expectations that future NMS hosts will have IPv6 and that any considerations for IPv4/NAT in this solution are temporary.
これらの問題の一部は、GACPとネットワークデバイスの設計をさらに採用することで将来的になくなる可能性があります。これは、個別のOAMプレーンのニーズにより適していますが、依存しないソリューションの長期的な設計を計画するのが賢明です。 GACPの高性能について。これは、将来のNMSホストにIPv6が搭載され、このソリューションでのIPv4 / NATに関する考慮事項は一時的なものであるという期待とは正反対です。
To solve the expected performance limitations of the GACP, we do expect to have the above-described dual connectivity via both GACP and data plane between NOC application devices and devices with GACP. The GACP connectivity is expected to always be there (as soon as a device is enrolled), but the data-plane connectivity is only present under normal operations and will not be present during, e.g., early stages of device bootstrap, failures, provisioning mistakes, or network configuration changes.
GACPの予想されるパフォーマンスの制限を解決するために、NOCアプリケーションデバイスとGACPを備えたデバイス間で、GACPとデータプレーンの両方を介した上記のデュアル接続が想定されています。 GACP接続は常に存在すると予想されますが（デバイスが登録されるとすぐに）、データプレーン接続は通常の操作でのみ存在し、デバイスのブートストラップの初期段階、障害、プロビジョニングのミスなどでは存在しません。 、またはネットワーク構成の変更。
The desired policy is therefore as follows: In the absence of further security considerations (see below), traffic between NMS hosts and GACP devices should prefer data-plane connectivity and resort only to using the GACP when necessary. The exception is an operation known to be covered by the use cases where the GACP is necessary, so that it makes no sense to try using the data plane. An example is an SSH connection from the NOC to a network device to troubleshoot network connectivity. This could easily always rely on the GACP. Likewise, if an NMS host is known to transmit large amounts of data, and it uses the GACP, then its data rate needs to be controlled so that it will not overload the GACP path. Typical examples of this are software downloads.
したがって、望ましいポリシーは次のとおりです。これ以上のセキュリティの考慮事項がない場合（下記を参照）、NMSホストとGACPデバイス間のトラフィックは、データプレーン接続を優先し、必要な場合にのみGACPを使用するようにします。例外は、GACPが必要なユースケースでカバーされることがわかっている操作であるため、データプレーンの使用を試みても意味がありません。たとえば、NOCからネットワークデバイスへのSSH接続で、ネットワーク接続のトラブルシューティングを行います。これは常にGACPに簡単に依存する可能性があります。同様に、NMSホストが大量のデータを送信することがわかっていて、GACPを使用している場合、GACPパスが過負荷にならないようにデータレートを制御する必要があります。この典型的な例は、ソフトウェアのダウンロードです。
There is a wide range of methods to build up these policies. We describe a few below.
これらのポリシーを構築するには、さまざまな方法があります。以下にいくつか説明します。
Ideally, a NOC system would learn and keep track of all addresses of a device (GACP and the various data-plane addresses). Every action of the NOC system would indicate via a "path-policy" what type of connection it needs (e.g., only data-plane, GACP only, default to data plane, fallback to GACP, etc.). A connection policy manager would then build connection to the target using the right address(es). Shorter term, a common practice is to identify different paths to a device via different names (e.g., loopback vs. interface addresses). This approach can be expanded to GACP uses, whether it uses the DNS or names local to the NOC system. Below, we describe example schemes using DNS.
理想的には、NOCシステムはデバイスのすべてのアドレス（GACPおよびさまざまなデータプレーンアドレス）を学習して追跡します。 NOCシステムのすべてのアクションは、「パスポリシー」を介して、必要な接続のタイプを示します（たとえば、データプレーンのみ、GACPのみ、デフォルトはデータプレーン、GACPへのフォールバックなど）。接続ポリシーマネージャは、正しいアドレスを使用してターゲットへの接続を構築します。短期的には、一般的な方法は、デバイスへの異なるパスを異なる名前で識別することです（例：ループバックアドレスとインターフェイスアドレス）。このアプローチは、DNSを使用するか、NOCシステムのローカル名を使用するかに関係なく、GACPの使用に拡張できます。以下では、DNSを使用したスキーマの例について説明します。
DNS can be used to set up names for the same network devices but with different addresses assigned:
DNSは、同じネットワークデバイスに名前を設定するために使用できますが、異なるアドレスが割り当てられています。
o One name (name.noc.example.com) with only the data-plane address(es) (IPv4 and/or IPv6) to be used for probing connectivity or performing routine software downloads that may stall/fail when there are connectivity issues.
o 接続の調査または接続の問題がある場合に停止/失敗する可能性のある定期的なソフトウェアダウンロードの実行に使用されるデータプレーンアドレス（IPv4またはIPv6、あるいはその両方）のみを含む1つの名前（name.noc.example.com）。
o One name (name-acp.noc.example.com) with only the GACP reachable address of the device for troubleshooting and probing/discovery that is desired to always only use the GACP.
o 常にGACPのみを使用することが望まれるトラブルシューティングとプローブ/検出のために、デバイスのGACP到達可能アドレスのみを持つ1つの名前（name-acp.noc.example.com）。
o One name (name-both.noc.example.com) with data-plane and GACP addresses.
o データプレーンとGACPアドレスを持つ1つの名前（name-both.noc.example.com）。
Traffic policing and/or shaping at the GACP edge in the NOC can be used to throttle applications such as software download into the GACP.
NOCのGACPエッジでのトラフィックポリシングやシェーピングは、GACPへのソフトウェアダウンロードなどのアプリケーションを抑制するために使用できます。
Using different names that map to different addresses (or subsets of addresses) can be difficult to set up and maintain, especially because data-plane addresses may change due to reconfiguration or relocation of devices. The name-based approach alone cannot strongly support policies for existing applications and long-lived flows to automatically switch between the ACP and data plane in the face of data-plane failure and recovery. A solution would be host transport stacks on GACP nodes that support the following requirements:
異なるアドレス（またはアドレスのサブセット）にマップする異なる名前を使用すると、特にデータプレーンアドレスがデバイスの再構成または再配置により変更される可能性があるため、セットアップおよび維持が困難になる可能性があります。名前ベースのアプローチだけでは、データプレーンの障害と復旧に直面した場合に、ACPとデータプレーンを自動的に切り替える既存のアプリケーションと長命のフローのポリシーを強力にサポートできません。ソリューションは、次の要件をサポートするGACPノード上のホストトランスポートスタックです。
1. Only the GACP addresses of the responder must be required by the initiator for the initial setup of a connection/flow across the GACP.
1. GACPを介した接続/フローの初期設定では、イニシエーターがレスポンダーのGACPアドレスのみを要求する必要があります。
2. Responder and Initiator must be able to exchange their data-plane addresses through the GACP, and then -- if needed by policy -- build an additional flow across the data plane.
2. レスポンダとイニシエータは、GACPを介してデータプレーンアドレスを交換できる必要があり、ポリシーで必要な場合は、データプレーン全体に追加のフローを構築できます。
3. For unmodified application, the following policies should be configurable on at least a per-application basis for its TCP connections with GACP peers:
3. 変更されていないアプリケーションの場合、GACPピアとのTCP接続について、少なくともアプリケーションごとに次のポリシーを構成できる必要があります。
Fallback (to GACP): An additional data-plane flow is built and used exclusively to send data whenever the data plane is operational. When the additional flow cannot be built during connection setup or when it fails later, traffic is sent across the GACP flow. This could be a default policy for most OAM applications using the GACP.
フォールバック（GACPへ）：追加のデータプレーンフローが構築され、データプレーンが動作しているときはいつでも、データを送信するためだけに使用されます。接続のセットアップ中に追加のフローを構築できない場合、または後で失敗した場合、GACPフローを介してトラフィックが送信されます。これは、GACPを使用するほとんどのOAMアプリケーションのデフォルトポリシーになる可能性があります。
Suspend/Fail: Like the Fallback policy, except that traffic will not use the GACP flow; instead, it will be suspended until a data-plane flow is operational or until a policy-configurable timeout indicates a connection failure to the application. This policy would be appropriate for large-volume background or scavenger-class OAM applications such as firmware downloads or telemetry/diagnostic uploads -- applications that would otherwise easily overrun performance-limited GACP implementations.
一時停止/失敗：トラフィックがGACPフローを使用しないことを除いて、フォールバックポリシーと同様です。代わりに、データプレーンフローが動作するまで、またはポリシーで構成可能なタイムアウトがアプリケーションへの接続障害を示すまで、中断されます。このポリシーは、ファームウェアのダウンロードやテレメトリ/診断のアップロードなど、大容量のバックグラウンドやスカベンジャークラスのOAMアプリケーション（パフォーマンスが制限されたGACP実装を簡単にオーバーランさせるアプリケーション）に適しています。
GACP (only): No additional data-plane flow is built, traffic is only sent via the GACP flow. This can just be a TCP connection. This policy would be most appropriate for OAM operations known to change the data plane in a way that could impact connectivity through it (at least temporarily).
GACP（のみ）：追加のデータプレーンフローは構築されず、トラフィックはGACPフロー経由でのみ送信されます。これは単にTCP接続にすることができます。このポリシーは、（少なくとも一時的に）データプレーンを介した接続に影響を与える可能性のある方法でデータプレーンを変更することがわかっているOAM操作に最適です。
4. In the presence of responders or initiators not supporting these host stack functions, the Fallback and GACP policies must result in a TCP connection across the GACP. For Suspend/Fail, presence of TCP-only peers should result in failure during connection setup.
4. これらのホストスタック機能をサポートしていないレスポンダーまたはイニシエーターが存在する場合、フォールバックおよびGACPポリシーは、GACP全体でTCP接続になる必要があります。一時停止/失敗の場合、TCPのみのピアが存在すると、接続のセットアップ中にエラーが発生するはずです。
5. In case of Fallback and Suspend/Fail, a failed data-plane connection should automatically be rebuilt when the data plane recovers, including when the data-plane address of one side or both sides may have changed -- for example, because of reconfiguration or device repositioning.
5. フォールバックおよびサスペンド/フェイルの場合、片側または両側のデータプレーンアドレスが変更された可能性がある場合など、データプレーンが回復すると、失敗したデータプレーン接続が自動的に再構築されます。デバイスの再配置。
6. Additional data-plane flows created by these host transport stack functions must be end-to-end authenticated by these host transport stack functions with the GACP domain credentials and encrypted. This maintains the expectation that connections from GACP addresses to GACP addresses are authenticated and encrypted. This may be skipped if the application already provides for end-to-end encryption.
6. これらのホストトランスポートスタック機能によって作成される追加のデータプレーンフローは、GACPドメインの資格情報を使用して、これらのホストトランスポートスタック機能によってエンドツーエンドで認証され、暗号化される必要があります。これは、GACPアドレスからGACPアドレスへの接続が認証および暗号化されるという期待を維持します。アプリケーションがすでにエンドツーエンドの暗号化を提供している場合、これはスキップできます。
7. For enhanced applications, the host stack may support application control to select the policy on a per-connection basis, or even more explicit control for building of the flows and which flow should pass traffic.
7. 拡張アプリケーションの場合、ホストスタックはアプリケーション制御をサポートして、接続ごとにポリシーを選択するか、フローの構築とトラフィックを通過させるフローをより明確に制御できます。
Protocols like Multipath TCP (MPTCP; see [RFC6824]) and the Stream Control Transmission Protocol (SCTP; see [RFC4960]) can already support part of these requirements. MPTCP, for example, supports signaling of addresses in a TCP backward-compatible fashion, establishing additional flows (called subflows in MPTCP), and having primary and fallback subflows via MP_PRIO signaling. The details of how MPTCP, SCTP, and/or other approaches (potentially with extensions and/or (shim) layers on top of them) can best provide a complete solution for the above requirements need further work and are outside the scope of this document.
マルチパスTCP（MPTCP; [RFC6824]を参照）やストリーム制御伝送プロトコル（SCTP; [RFC4960]を参照）などのプロトコルは、これらの要件の一部をすでにサポートしています。たとえば、MPTCPは、TCP下位互換性のある方法でアドレスのシグナリングをサポートし、追加のフロー（MPTCPではサブフローと呼ばれます）を確立し、MP_PRIOシグナリングを介してプライマリおよびフォールバックサブフローを持ちます。 MPTCP、SCTP、および/またはその他のアプローチ（拡張機能やその上に（シム）レイヤーが存在する可能性がある）の詳細は、上記の要件に対する完全なソリューションを提供するのに最適であり、さらに作業が必要であり、このドキュメントの範囲外です。 。
Setting up connectivity between the NOC and autonomic devices when the NOC device itself is non-autonomic is a security issue, as mentioned at the beginning of this document. It also results in a range of connectivity considerations (discussed in Section 3.1.5), some of which may be quite undesirable or complex to operationalize.
このドキュメントの冒頭で述べたように、NOCデバイス自体が非自律型である場合に、NOCデバイスと自律型デバイス間の接続を設定することは、セキュリティの問題です。また、接続に関するさまざまな考慮事項（セクション3.1.5で説明）も発生します。そのいくつかは、運用するのが非常に望ましくないか、複雑な場合があります。
Making NMS hosts autonomic and having them participate in the GACP is therefore not only a highly desirable solution to the security issues, but can also provide a likely easier operationalization of the GACP because it minimizes special edge considerations for the NOC. The GACP is simply built all the way automatically, even inside the NOC, and it is only authorizes and authenticates NOC devices/ applications that will have access to it.
したがって、NMSホストをオートノミックにしてGACPに参加させることは、セキュリティの問題に対する非常に望ましい解決策であるだけでなく、NOCの特別なエッジの考慮事項を最小限に抑えるため、GACPの運用が容易になる可能性があります。 GACPは、NOC内であっても、自動的に構築されるだけで、それにアクセスするNOCデバイス/アプリケーションの承認と認証のみが行われます。
According to [ACP], supporting the ACP all the way into an application device requires implementing the following aspects in it: AN bootstrap/enrollment mechanisms, the secure channel for the ACP and at least the host side of IPv6 routing setup for the ACP. Minimally, this could all be implemented as an application and be made available to the host OS via, e.g., a TAP driver to make the ACP show up as another IPv6-enabled interface.
[ACP]によると、アプリケーションデバイスに至るまでACPをサポートするには、ANブートストラップ/登録メカニズム、ACPのセキュアチャネル、および少なくともACPのIPv6ルーティング設定のホスト側を実装する必要があります。最低限、これはすべてアプリケーションとして実装され、TAPドライバーなどを介してホストOSで利用できるようにして、ACPを別のIPv6対応インターフェースとして表示させることができます。
Having said this: If the structure of NMS hosts is transformed through virtualization anyhow, then it may be considered equally secure and appropriate to construct a (physical) NMS host system by combining a virtual GACP-enabled router with non-GACP-enabled Virtual Machines (VMs) for NOC applications via a hypervisor. This would leverage the configuration options described in the previous sections but just virtualize them.
つまり、NMSホストの構造が仮想化によって何らかの形で変換された場合、仮想GACP対応ルーターと非GACP対応仮想マシンを組み合わせて（物理）NMSホストシステムを構築することも同様に安全かつ適切であると考えられます。 （VM）ハイパーバイザーを介したNOCアプリケーション用。これは、前のセクションで説明した構成オプションを活用しますが、それらを仮想化するだけです。
When combining GACP and data-plane connectivity for availability and performance reasons, this too has an impact on security: When using the GACP, most traffic will be encryption protected, especially when considering the above-described use of application devices with GACP. If, instead, the data plane is used, then this is not the case anymore unless it is done by the application.
可用性とパフォーマンスの理由でGACPとデータプレーン接続を組み合わせると、これもセキュリティに影響します。GACPを使用する場合、特にGACPでのアプリケーションデバイスの上記の使用を検討する場合、ほとんどのトラフィックは暗号化保護されます。代わりに、データプレーンが使用されている場合、アプリケーションで実行しない限り、これは当てはまりません。
The simplest solution for this problem exists when using GACP-capable NMS hosts, because in that case the communicating GACP-capable NMS host and the GACP network device have credentials they can mutually trust (same GACP domain). As a result, data-plane connectivity that does support this can simply leverage TLS [RFC5246] or DTLS [RFC6347] with those GACP credentials for mutual authentication -- and this does not incur new key management.
この問題の最も簡単な解決策は、GACP対応のNMSホストを使用する場合に存在します。その場合、通信するGACP対応のNMSホストとGACPネットワークデバイスには、相互に信頼できる資格情報（同じGACPドメイン）があるためです。その結果、これをサポートするデータプレーン接続は、相互認証用のGACP資格情報を使用してTLS [RFC5246]またはDTLS [RFC6347]を単純に活用できます。これにより、新しいキー管理は発生しません。
If this automatic security benefit is seen as most important, but a "full" GACP stack into the NMS host is unfeasible, then it would still be possible to design a stripped-down version of GACP functionality for such NOC hosts that only provides enrollment of the NOC host with the GACP cryptographic credentials and does not directly participate in the GACP encryption method. Instead, the host would just leverage TLS/DTLS using its GACP credentials via the data plane with GACP network devices as well as indirectly via the GACP connect interface with the above-mentioned GACP connect interface into the GACP.
この自動セキュリティの利点が最も重要であると考えられているが、NMSホストへの「完全な」GACPスタックが実現不可能である場合、登録のみを提供するこのようなNOCホスト用のGACP機能の簡略バージョンを設計することは可能です。 GACP暗号化資格情報を備えたNOCホストであり、GACP暗号化方式には直接関与しません。代わりに、ホストはGACPネットワークデバイスのデータプレーンを介してGACPクレデンシャルを使用してTLS / DTLSを利用するだけでなく、GACP接続インターフェイスを介して間接的にGACP接続インターフェイスを介してGACPに接続します。
When using the GACP itself, TLS/DTLS for the transport layer between NMS hosts and network device is somewhat of a double price to pay (GACP also encrypts) and could potentially be optimized away; however, given the assumed lower performance of the GACP, it seems that this is an unnecessary optimization.
GACP自体を使用する場合、NMSホストとネットワークデバイス間のトランスポートレイヤーのTLS / DTLSは、いくらか二重の価格（GACPも暗号化する）であり、最適化される可能性があります。ただし、GACPのパフォーマンスが低いと想定されているため、これは不要な最適化のようです。
If we consider what potentially could be the most lightweight and autonomic long-term solution based on the technologies described above, we see the following direction:
上記のテクノロジーに基づいて、最も軽量で自律的な長期的なソリューションになる可能性があるものを検討すると、次の方向性が見えます。
1. NMS hosts should at least support IPv6. IPv4/IPv6 NAT in the network to enable use of a GACP is undesirable in the long term. Having IPv4-only applications automatically leverage IPv6 connectivity via host-stack translation may be an option, but this has not been investigated yet.
1. NMSホストは少なくともIPv6をサポートする必要があります。ネットワークでIPv4 / IPv6 NATを使用してGACPを使用できるようにすることは、長期的には望ましくありません。 IPv4のみのアプリケーションがホストスタック変換を介してIPv6接続を自動的に活用することもオプションの1つですが、これはまだ調査されていません。
2. Build the GACP as a lightweight application for NMS hosts so GACP extends all the way into the actual NMS hosts.
2. GACPをNMSホストの軽量アプリケーションとして構築し、GACPを実際のNMSホストまで拡張します。
3. Leverage and (as necessary) enhance host transport stacks with automatic GACP with multipath connectivity and data plane as outlined in Section 3.1.5.
3. セクション3.1.5で概説されているように、マルチパス接続とデータプレーンを備えた自動GACPを使用して、ホストトランスポートスタックを活用および（必要に応じて）拡張します。
4. Consider how to best map NMS host desires to underlying transport mechanisms: The three points above do not cover all options. Depending on the OAM, one may still want only GACP, want only data plane, automatically prefer one over the other, and/or want to use the GACP with low performance or high performance (for emergency OAM such as countering DDoS). As of today, it is not clear what the simplest set of tools is to explicitly enable the choice of desired behavior of each OAM. The use of the above-mentioned DNS and multipath mechanisms is a start, but this will require additional work. This is likely a specific case of the more generic scope of TAPS.
4. NMSホストの要望を基礎となるトランスポートメカニズムに最適にマッピングする方法を検討します。上記の3つのポイントはすべてのオプションを網羅しているわけではありません。 OAMに応じて、GACPのみが必要、データプレーンのみが必要、どちらか一方が自動的に優先される、および/または低パフォーマンスまたは高パフォーマンスでGACPを使用したい（DDoSに対抗する緊急OAMの場合）。現在のところ、各OAMの望ましい動作の選択を明示的に有効にするための最も単純なツールセットが何であるかは明らかではありません。上記のDNSおよびマルチパスメカニズムの使用は開始ですが、これには追加の作業が必要になります。これは、TAPSのより一般的な範囲の特定のケースである可能性があります。
Today, many distributed protocols implement their own unique security mechanisms.
今日、多くの分散プロトコルは独自の独自のセキュリティメカニズムを実装しています。
Keying and Authentication for Routing Protocols (KARP; see [RFC6518]) has tried to start to provide common directions and therefore reduce the reinvention of at least some of the security aspects, but it only covers routing protocols and it is unclear how applicable it is to a wider range of network distributed agents such as those performing distributed OAM. The common security of a GACP can help in those cases.
ルーティングプロトコルのキーイングと認証（KARP、[RFC6518]を参照）は、共通の指示を提供し始め、それによりセキュリティ面の少なくとも一部の再発明を削減しようとしましたが、ルーティングプロトコルのみをカバーしており、どのように適用できるかは不明です分散OAMを実行するエージェントなど、より広範囲のネットワーク分散エージェント。このような場合、GACPの一般的なセキュリティが役立ちます。
Furthermore, a GRASP instance ([GRASP]) can run on top of a GACP as a security and transport substrate and provide common local and remote neighbor discovery and peer negotiation mechanisms; this would allow unifying and reusing future protocol designs.
さらに、GRASPインスタンス（[GRASP]）は、セキュリティとトランスポートの基質としてGACPの上で実行でき、共通のローカルおよびリモートの近隣探索とピアネゴシエーションメカニズムを提供します。これにより、将来のプロトコル設計を統合して再利用できます。
The GACP is intended to be IPv6 only, and the prior explanations in this document show that this can lead to some complexity when having to connect IPv4-only NOC solutions, and that it will be impossible to leverage the GACP when the OAM agents on a GACP network device do not support IPv6. Therefore, the question was raised whether the GACP should optionally also support IPv4.
GACPはIPv6のみを対象としています。このドキュメントのこれまでの説明では、IPv4のみのNOCソリューションを接続する必要がある場合に多少複雑になる可能性があり、OAMエージェントがGACPネットワークデバイスはIPv6をサポートしていません。したがって、GACPがオプションでIPv4もサポートする必要があるかどうかという質問が出されました。
The decision not to include IPv4 for GACP in the use cases in this document was made for the following reasons:
このドキュメントのユースケースにGACPにIPv4を含めないという決定は、次の理由で行われました。
In service provider networks that have started to support IPv6, often the next planned step is to consider moving IPv4 from a native transport to just a service on the edge. There is no benefit or need for multiple parallel transport families within the network, and standardizing on one reduces operating expenses and improves reliability. This evolution in the data plane makes it highly unlikely that investing development cycles into IPv4 support for GACP will have a longer term benefit or enough critical short-term use cases. Support for IPv6-only for GACP is purely a strategic choice to focus on the known important long-term goals.
IPv6のサポートを開始したサービスプロバイダーネットワークでは、多くの場合、計画されている次のステップは、IPv4をネイティブトランスポートからエッジ上のサービスだけに移行することを検討することです。ネットワーク内に複数の並列トランスポートファミリーを用意する必要はありません。1つに標準化すると、運用コストが削減され、信頼性が向上します。データプレーンのこの進化により、GACPのIPv4サポートに開発サイクルを投資しても、長期的なメリットや十分な重要な短期的な使用事例が生じる可能性は非常に低くなります。 GACPのIPv6のみのサポートは、既知の重要な長期目標に焦点を合わせるための純粋に戦略的な選択です。
In other types of networks as well, we think that efforts to support autonomic networking are better spent in ensuring that one address family will be supported so all use cases will work with it in the long term, instead of duplicating effort with IPv4. Also, auto-addressing for the GACP with IPv4 would be more complex than in IPv6 due to the IPv4 addressing space.
他のタイプのネットワークでも、オートノミックネットワーキングをサポートするための取り組みは、1つのアドレスファミリがサポートされることを保証することに費やされ、すべてのユースケースがIPv4での取り組みを重複させるのではなく、長期的に使用できると考えています。また、IPv4を使用したGACPの自動アドレス指定は、IPv4アドレス空間のため、IPv6の場合よりも複雑になります。
In this section, we discuss only security considerations not covered in the appropriate subsections of the solutions described.
このセクションでは、説明されているソリューションの適切なサブセクションでカバーされていないセキュリティの考慮事項についてのみ説明します。
Even though GACPs are meant to be isolated, explicit operator misconfiguration to connect to insecure OAM equipment and/or bugs in GACP devices may cause leakage into places where it is not expected. Mergers and acquisitions and other complex network reconfigurations affecting the NOC are typical examples.
GACPは分離することを目的としていますが、安全でないOAM機器に接続するための明示的なオペレーターの設定ミスやGACPデバイスのバグにより、予期しない場所にリークが発生する可能性があります。合併や買収、NOCに影響を与えるその他の複雑なネットワークの再構成は、典型的な例です。
GACP addresses are ULAs. Using these addresses also for NOC devices, as proposed in this document, is not only necessary for the simple routing functionality explained above, but it is also more secure than global IPv6 addresses. ULAs are not routed in the global Internet and will therefore be subject to more filtering even in places where specific ULAs are being used. Packets are therefore less likely to leak and less likely to be successfully injected into the isolated GACP environment.
GACPアドレスはULAです。このドキュメントで提案されているように、これらのアドレスをNOCデバイスにも使用することは、上記で説明した単純なルーティング機能に必要なだけでなく、グローバルIPv6アドレスよりも安全です。 ULAはグローバルインターネットでルーティングされないため、特定のULAが使用されている場所でも、より多くのフィルタリングの対象になります。したがって、パケットはリークする可能性が低く、隔離されたGACP環境に正常に挿入される可能性が低くなります。
The random nature of a ULA prefix provides strong protection against address collision even though there is no central assignment authority. This is helped by the expectation that GACPs will never connect all together, and that only a few GACPs may ever need to connect together, e.g., when mergers and acquisitions occur.
ULAプレフィックスのランダムな性質は、中央割り当て権限がない場合でも、アドレスの衝突に対する強力な保護を提供します。これは、GACPがすべてを一緒に接続することは決してなく、たとえば合併や買収が発生した場合でも、接続する必要があるGACPはほんのわずかであるという期待に助けられています。
Note that the GACP constraints demand that only packets from connected subnet prefixes are permitted from GACP connect interfaces, limiting the scope of non-cryptographically secured transport to a subnet within a NOC that instead has to rely on physical security (i.e., only connect trusted NOC devices to it).
GACP制約は、接続されたサブネットプレフィックスからのパケットのみがGACP接続インターフェースから許可されることを要求し、非暗号化的に保護されたトランスポートの範囲を、物理的なセキュリティに依存する必要があるNOC内のサブネットに制限することに注意してください（つまり、信頼できるNOCのみを接続します）それへのデバイス）。
To help diagnose packets that unexpectedly leaked, for example, from
another GACP (that was meant to be deployed separately), it can be
useful to voluntarily list your own ULA GACP prefixes on some sites
on the Internet and hope that other users of GACPs do the same so
that you can look up unknown ULA prefix packets seen in your network.
Note that this does not constitute registration.
<https://www.sixxs.net/tools/grh/ula/> was a site to list ULA
prefixes, but it has not been open for new listings since mid-2017. The authors are not aware of other active Internet sites to list ULA use.
接頭辞ですが、2017年半ば以降、新しいリスティングには公開されていません。著者は、ULAの使用をリストする他のアクティブなインターネットサイトを認識していません。
Note that there is a provision in [RFC4193] for address space that is not locally assigned (L bit = 0), but there is no existing standardization for this, so these ULA prefixes must not be used.
[RFC4193]には、ローカルに割り当てられていないアドレス空間（Lビット= 0）に対する規定がありますが、これに対する既存の標準化がないため、これらのULAプレフィックスを使用しないでください。
According to Section 4.4 of [RFC4193], PTR records for ULA addresses should not be installed into the global DNS (no guaranteed ownership). Hence, there is also the need to rely on voluntary lists (as mentioned above) to make the use of an ULA prefix globally known.
[RFC4193]のセクション4.4によると、ULAアドレスのPTRレコードをグローバルDNSにインストールしないでください（所有権は保証されません）。したがって、ULAプレフィックスの使用をグローバルに知られるようにするために、（上記の）任意リストに依存する必要もあります。
Nevertheless, some legacy OAM applications running across the GACP may rely on reverse DNS lookup for authentication of requests (e.g., TFTP for download of network firmware, configuration, or software). Therefore, operators may need to use a private DNS setup for the GACP ULAs. This is the same setup that would be necessary for using RFC 1918 addresses in DNS. For example, see the last paragraph of Section 5 of [RFC1918]. In Section 4 of [RFC6950], these setups are discussed in more detail.
それにもかかわらず、GACP全体で実行されている一部のレガシーOAMアプリケーションは、リクエストの認証にDNSの逆ルックアップに依存している可能性があります（ネットワークファームウェア、構成、またはソフトウェアのダウンロードにはTFTPなど）。したがって、オペレーターはGACP ULAにプライベートDNSセットアップを使用する必要がある場合があります。これは、DNSでRFC 1918アドレスを使用するために必要な設定と同じです。たとえば、[RFC1918]のセクション5の最後の段落を参照してください。 [RFC6950]のセクション4では、これらの設定について詳しく説明しています。
Any current and future protocols must rely on secure end-to-end communications (TLS/DTLS) and identification and authentication via the certificates assigned to both ends. This is enabled by the cryptographic credential mechanisms of the GACP.
現在および将来のプロトコルは、安全なエンドツーエンド通信（TLS / DTLS）と、両端に割り当てられた証明書による識別および認証に依存する必要があります。これは、GACPの暗号化資格メカニズムによって有効になります。
If DNS and especially reverse DNS are set up, then they should be set up in an automated fashion when the GACP address for devices are assigned. In the case of the ACP, DNS resource record creation can be linked to the autonomic registrar backend so that the DNS and reverse DNS records are actually derived from the subject name elements of the ACP device certificates in the same way as the autonomic devices themselves will derive their ULAs from their certificates to ensure correct and consistent DNS entries.
DNS、特にリバースDNSが設定されている場合、デバイスのGACPアドレスが割り当てられるときに、自動方式で設定する必要があります。 ACPの場合、DNSリソースレコードの作成をオートノミックレジストラーバックエンドにリンクできるため、DNSおよびリバースDNSレコードは、オートノミックデバイス自体と同じ方法で、ACPデバイス証明書のサブジェクト名要素から実際に派生します。証明書からULAを導出して、正確で一貫したDNSエントリを保証します。
If an operator feels that reverse DNS records are beneficial to its own operations, but that they should not be made available publicly for "security" by concealment reasons, then GACP DNS entries are probably one of the least problematic use cases for split DNS: The GACP DNS names are only needed for the NMS hosts intending to use the GACP -- but not network wide across the enterprise.
オペレーターがリバースDNSレコードは自身の操作に有益であると感じているが、隠蔽の理由により「セキュリティ」のためにそれらを公に利用可能にすべきではない場合、GACP DNSエントリはおそらくスプリットDNSの最も問題の少ない使用例の1つです。 GACP DNS名は、GACPを使用するNMSホストにのみ必要ですが、企業全体のネットワーク全体には必要ありません。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <https://www.rfc-editor.org/info/rfc1918>.
[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、de Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、DOI 10.17487 / RFC1918、1996年2月、<https://www.rfc-editor.org/info/rfc1918>。
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, November 2005, <https://www.rfc-editor.org/info/rfc4191>.
[RFC4191] Draves、R。およびD. Thaler、「デフォルトのルーター設定とより具体的なルート」、RFC 4191、DOI 10.17487 / RFC4191、2005年11月、<https://www.rfc-editor.org/info/rfc4191 >。
[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>。
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, <https://www.rfc-editor.org/info/rfc6724>.
[RFC6724] Thaler、D.、Ed。、Draves、R.、Matsumoto、A。、およびT. Chown、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 6724、DOI 10.17487 / RFC6724、2012年9月、<https://www.rfc-editor.org/info/rfc6724>。
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, <https://www.rfc-editor.org/info/rfc6824>.
[RFC6824] Ford、A.、Raiciu、C.、Handley、M。、およびO. Bonaventure、「複数のアドレスによるマルチパス操作のためのTCP拡張機能」、RFC 6824、DOI 10.17487 / RFC6824、2013年1月、<https：// www.rfc-editor.org/info/rfc6824>。
[RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic Networking: Definitions and Design Goals", RFC 7575, DOI 10.17487/RFC7575, June 2015, <https://www.rfc-editor.org/info/rfc7575>.
[RFC7575] Behringer、M.、Pritikin、M.、Bjarnason、S.、Clemm、A.、Carpenter、B.、Jiang、S。、およびL. Ciavaglia、「Autonomic Networking：Definitions and Design Goals」、RFC 7575 、DOI 10.17487 / RFC7575、2015年6月、<https://www.rfc-editor.org/info/rfc7575>。
[RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address Mappings for Stateless IP/ICMP Translation", RFC 7757, DOI 10.17487/RFC7757, February 2016, <https://www.rfc-editor.org/info/rfc7757>.
[RFC7757]アンダーソン、T。およびA.リーバポッパー、「ステートレスIP / ICMP変換のための明示的なアドレスマッピング」、RFC 7757、DOI 10.17487 / RFC7757、2016年2月、<https://www.rfc-editor.org/info / rfc7757>。
[RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, "IP/ICMP Translation Algorithm", RFC 7915, DOI 10.17487/RFC7915, June 2016, <https://www.rfc-editor.org/info/rfc7915>.
[RFC7915] Bao、C.、Li、X.、Baker、F.、Anderson、T。、およびF. Gont、「IP / ICMP変換アルゴリズム」、RFC 7915、DOI 10.17487 / RFC7915、2016年6月、<https： //www.rfc-editor.org/info/rfc7915>。
[ACP] Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic Control Plane (ACP)", Work in Progress, draft-ietf-anima-autonomic-control-plane-13, December 2017.
[ACP] Eckert、T.、Behringer、M。、およびS. Bjarnason、「An Autonomic Control Plane（ACP）」、Work in Progress、draft-ietf-anima-autonomic-control-plane-13、2017年12月。
[BRSKI] Pritikin, M., Richardson, M., Behringer, M., Bjarnason, S., and K. Watsen, "Bootstrapping Remote Secure Key Infrastructures (BRSKI)", Work in Progress, draft-ietf-anima-bootstrapping-keyinfra-15, April 2018.
[BRSKI] Pritikin、M.、Richardson、M.、Behringer、M.、Bjarnason、S。、およびK. Watsen、「Bootstrapping Remote Secure Key Infrastructures（BRSKI）」、Work in Progress、draft-ietf-anima-bootstrapping -keyinfra-15、2018年4月。
[GRASP] Bormann, C., Carpenter, B., and B. Liu, "A Generic Autonomic Signaling Protocol (GRASP)", Work in Progress, draft-ietf-anima-grasp-15, July 2017.
[GRASP] Bormann、C.、Carpenter、B。、およびB. Liu、「A Generic Autonomic Signaling Protocol（GRASP）」、Work in Progress、draft-ietf-anima-grasp-15、2017年7月。
[IEEE.802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks -- Bridges and Bridged Networks", IEEE 802.1Q-2014, DOI 10.1109/ieeestd.2014.6991462, December 2014, <http://ieeexplore.ieee.org/servlet/ opac?punumber=6991460>.
[IEEE.802.1Q] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Bridges and Bridged Networks」、IEEE 802.1Q-2014、DOI 10.1109 / ieeestd.2014.6991462、2014年12月、<http://ieeexplore.ieee。 org / servlet / opac？punumber = 6991460>。
[ITUT_G7712] ITU, "Architecture and specification of data communication network", ITU-T Recommendation G.7712/Y.1703, November 2001, <https://www.itu.int/rec/T-REC-G.7712/en>.
[ITUT_G7712] ITU、「データ通信ネットワークのアーキテクチャと仕様」、ITU-T勧告G.7712 / Y.1703、2001年11月、<https://www.itu.int/rec/T-REC-G.7712 / en>。
[REF_MODEL] Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., and J. Nobre, "A Reference Model for Autonomic Networking", Work in Progress, draft-ietf-anima-reference-model-06, February 2018.
[REF_MODEL] Behringer、M.、Carpenter、B.、Eckert、T.、Ciavaglia、L.、and J. Nobre、 "A Reference Model for Autonomic Networking"、Work in Progress、draft-ietf-anima-reference-model 2018年2月6日。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.
[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、DOI 10.17487 / RFC1034、1987年11月、<https://www.rfc-editor.org/info/rfc1034>。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>.
[RFC4960] Stewart、R.、Ed。、「Stream Control Transmission Protocol」、RFC 4960、DOI 10.17487 / RFC4960、2007年9月、<https://www.rfc-editor.org/info/rfc4960>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<https://www.rfc-editor.org/info / rfc5246>。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[RFC6146] Bagnulo、M.、Matthews、P。、およびI. van Beijnum、「ステートフルNAT64：IPv6クライアントからIPv4サーバーへのネットワークアドレスおよびプロトコル変換」、RFC 6146、DOI 10.17487 / RFC6146、2011年4月、<https： //www.rfc-editor.org/info/rfc6146>。
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, "Guidelines for the Use of the "OAM" Acronym in the IETF", BCP 161, RFC 6291, DOI 10.17487/RFC6291, June 2011, <https://www.rfc-editor.org/info/rfc6291>.
[RFC6291] Andersson、L.、van Helvoort、H.、Bonica、R.、Romascanu、D。、およびS. Mansfield、「IETFでの「OAM」の頭字語の使用に関するガイドライン」、BCP 161、RFC 6291 、DOI 10.17487 / RFC6291、2011年6月、<https://www.rfc-editor.org/info/rfc6291>。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<https://www.rfc-editor.org/info/rfc6347>。
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node Requirements", RFC 6434, DOI 10.17487/RFC6434, December 2011, <https://www.rfc-editor.org/info/rfc6434>.
[RFC6434] Jankiewicz、E.、Loughney、J。、およびT. Narten、「IPv6ノードの要件」、RFC 6434、DOI 10.17487 / RFC6434、2011年12月、<https://www.rfc-editor.org/info/ rfc6434>。
[RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines", RFC 6518, DOI 10.17487/RFC6518, February 2012, <https://www.rfc-editor.org/info/rfc6518>.
[RFC6518] Lebovitz、G。、およびM. Bhatia、「ルーティングプロトコルのキーイングおよび認証（KARP）設計ガイドライン」、RFC 6518、DOI 10.17487 / RFC6518、2012年2月、<https://www.rfc-editor.org/ info / rfc6518>。
[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>。
Acknowledgements
謝辞
This work originated from an Autonomic Networking project at Cisco Systems, which started in early 2010, with customers involved in the design and early testing. Many people contributed to the aspects described in this document, including in alphabetical order: BL Balaji, Steinthor Bjarnason, Yves Herthoghs, Sebastian Meissner, and Ravi Kumar Vadapalli. The authors would also like to thank Michael Richardson, James Woodyatt, and Brian Carpenter for their review and comments. Special thanks to Sheng Jiang and Mohamed Boucadair for their thorough reviews.
この作業は、2010年の初めに開始された、シスコシステムズのオートノミックネットワーキングプロジェクトに端を発し、設計と初期テストに携わったお客様を対象としています。このドキュメントで説明されている側面には、BLバラジ、シュタイナージャーナソン、イヴヘルソグス、セバスチャンマイスナー、ラヴィクマールヴァダパリなど多くの人々が貢献しました。著者は、レビューとコメントを提供してくれたMichael Richardson、James Woodyatt、Brian Carpenterにも感謝します。 Sheng Jiang氏とMohamed Boucadair氏の徹底したレビューに感謝します。
Authors' Addresses
著者のアドレス
Toerless Eckert (editor) Huawei USA 2330 Central Expy Santa Clara 95050 United States of America
Toerless Eckert（editor）Huawei USA 2330 Central Expy Santa Clara 95050アメリカ合衆国
Email: tte+ietf@cs.fau.de, toerless.eckert@huawei.com
Michael H. Behringer
マイケルH.ベーリンガー
Email: michael.h.behringer@gmail.com