Internet Engineering Task Force (IETF) T. Eckert, Ed.
Request for Comments: 8368 Huawei
Category: Informational M. Behringer
ISSN: 2070-1721 May 2018
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.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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）的产品。互联网工程指导小组（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.
版权所有（c）2018 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. 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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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)
在20世纪90年代末和2000年初，IP网络成为为网络提供商内的通信基础设施构建独立OAM网络的首选方法。这一概念在ITU-T G.7712/Y.1703[ITU_G7712]中被标准化，并被称为“数据通信网络”（DCN）。过去（现在仍然是）
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.
物理上分离IP或IP/MPLS网络，提供对所有必须管理的设备的OAM接口的访问，从通过光学设备的公共交换电话网络（PSTN）交换机到现在的以太网和IP/MPLS生产网络设备。
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（自主网络集成模型和方法）工作组的目标之一是规范一个安全且自动构建的带内管理平面，该平面提供类似于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]将这种带内管理平面称为“自主控制平面”（Autonomic Control plane，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是跨网络设备的虚拟网络（虚拟路由和转发（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 NOC设备的流量，该设备具有到GACP边缘设备的子网连接（作为转换方法）。
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]）、通用自主信令协议（GRAP[GRAP]）和自主控制平面（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的稳定连接，例如，通过ACP（带或不带完整ANI），从我们预计在短期内最容易部署的选项开始。然后介绍了该方法的局限性和挑战，以及相应的解决方案和变通办法；它以第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的初始使用有多简单，以及解决方法有多困难（因此需要避免什么）。另外，一个非常有前途的长期解决方案与最简单的短期解决方案完全相同，只是虚拟化和自动化。
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系统上的一个或多个应用程序执行。本文档描述了利用GACP实现稳定连接的方法，从简单到复杂，具体取决于所用设备的能力和限制。
Three stages can be considered:
可以考虑三个阶段：
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 这些是通过使用IPv4/IPv6 NAT（网络地址转换）将GACP连接到不支持IPv6的NOC设备的变通方法，如第3.1.4节所述。不建议采用这些变通办法；然而，如果不支持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通过一个或多个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\uuz>.acp.noc.example.com的CNAME。注意，许多网络已经使用包含拓扑信息的网络设备的名称，即使没有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.
这四个问题可以通过解决方案的改进独立解决。将这些改进结合在一起可以得到一个候选的长期解决方案。
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设备最兼容的设置是有两个IPv6接口——一个虚拟接口（例如，通过IEEE 802.1Q[IEEE.802.1Q]）或物理接口连接到数据平面子网，另一个连接到GACP连接子网。详见[ACP]第8.1节。该文件还规定，如果NOC设备支持[RFC6724]中规定的默认地址选择和[RFC4191]中规定的默认路由器首选项，则NOC设备如何接收自动配置的寻址并路由至ACP connect子网。
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主机上配置第二个接口可能是不可能的，或者被视为不必要的复杂性。在这种情况下，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的一个体系结构期望是所有希望使用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后端解决方案（硬件或软件）或企业产品领域，IPv6还远远没有得到普遍支持。即使在支持它的情况下，在双堆栈设置中使用它通常也会有额外的限制或问题，或者操作员要求（为简单起见）对所有操作使用单堆栈。由于这些原因，仍然需要只使用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:
要使用GACP连接仅IPv4的管理平面设备/应用程序，需要在IPv4和IPv6之间对数据包进行某种形式的IP/ICMP转换。[RFC7915]中描述了无状态IP/ICMP转换算法（SIIT）的基本机制。使用此机制有多种解决方案。为了理解可能的解决方案，我们考虑以下要求：
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呼叫总部连接。每个NMS主机都需要有一个单独的IPv6地址，可以从GACP访问。当从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设备分配一个或多个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区域寻址子方案中，对于每个注册器，都有一个常量/112前缀，可以为其配置RFC 7757中定义的到/16前缀的显式地址映射（EAM）（例如，在[RFC1918]中描述的专用IPv4地址空间中）。在注册器的/112前缀内，设备的设备编号按顺序分配：使用V位（虚拟化位），每个GACP设备有效地分配两个编号。这也意味着，如果IPv4地址空间受到更大的限制，并且众所周知，注册器永远不需要完整的/15设备号，那么可以在EAM中配置比a/112长的前缀，以便使用更少的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 connect接口的地址前缀。
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 connect执行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.
为了符合安全预期，SIIT必须发生在GACP边缘设备本身上，以便可以考虑GACP安全考虑因素。例如，仅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 connect接口的非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时所必需的。等待国家奥委会设备支持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
如上所述，由于GACP的主要目标是连接性和安全性，因此预计GACP不会具有高性能。对于现有的网络设备平台，这通常意味着要实现与硬件的额外连接需要付出更多的努力
acceleration than without -- especially because of the desire to support full encryption across the GACP to achieve the desired security.
加速比没有加速更重要——特别是因为希望支持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等）。然后，连接策略管理器将使用正确的地址建立到目标的连接。短期而言，通常的做法是通过不同的名称（例如，环回与接口地址）识别到设备的不同路径。这种方法可以扩展到GACP使用，无论它使用的是DNS还是NOC系统的本地名称。下面，我们将介绍使用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 一个名称（name.noc.example.com），其中仅包含数据平面地址（IPv4和/或IPv6），用于探测连接或执行例行软件下载，当存在连接问题时，这些软件下载可能会暂停/失败。
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 一个名称（名称acp.noc.example.com），仅包含设备的GACP可访问地址，用于故障排除和探测/发现，希望始终仅使用GACP。
o One name (name-both.noc.example.com) with data-plane and GACP addresses.
o 一个带有数据平面和GACP地址的名称（名称均为.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.
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.translate error, please retry
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
诸如多路径TCP（MPTCP；请参阅[RFC6824]）和流控制传输协议（SCTP；请参阅[RFC4960]）之类的协议已经可以支持这些要求的一部分。例如，MPTCP支持以TCP向后兼容的方式发送地址信号，建立额外的流（在MPTCP中称为子流），并通过MP_PRIO信令具有主和回退子流。MPTCP、SCTP和/或其他方法（可能包括扩展）的详细信息
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.
和/或（或其上的垫片）层）可以最好地为上述需要进一步工作的要求提供完整的解决方案，并且不在本文件的范围内。
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不仅是解决安全问题的一个非常理想的解决方案，而且还可以使GACP更易于操作，因为这可以最大限度地减少NOC的特殊边缘考虑。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进入应用设备需要在其中实现以下方面：引导/注册机制、ACP的安全通道以及至少ACP的IPv6路由设置的主机端。至少，这一切都可以作为一个应用程序实现，并通过一个TAP驱动程序提供给主机操作系统，使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的虚拟机（VM）结合起来，为NOC应用程序构建一个（物理）NMS主机系统，可能会被认为是同样安全和合适的。这将利用前面章节中描述的配置选项，但只是将它们虚拟化。
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
使用支持GACP的NMS主机时，存在此问题的最简单解决方案，因为在这种情况下，支持GACP的通信NMS主机和GACP网络设备具有可以相互访问的凭据
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域）。因此，支持这一点的数据平面连接可以简单地利用TLS[RFC5246]或DTL[RFC6347]和这些GACP凭据进行相互身份验证，而这不会产生新的密钥管理。
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.
如果这一自动安全优势被视为最重要的，但将“完整”GACP堆栈放入NMS主机是不可行的，然后，仍然可以为此类NOC主机设计GACP功能的精简版本，该版本仅提供具有GACP加密凭据的NOC主机注册，而不直接参与GACP加密方法。相反，主机将只利用TLS/DTL，通过GACP网络设备的数据平面使用其GACP凭据，以及通过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/DTL的价格是双倍的（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连接可能是一种选择，但目前尚未对此进行研究。
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
4. 考虑如何将NMS主机愿望映射到底层传输机制：上面的三点不覆盖所有选项。根据OAM的不同，用户可能仍然只需要GACP、只需要数据平面、自动选择其中一个而不是另一个，和/或希望使用低性能或高性能的GACP（用于紧急OAM，如抵御DDoS）。到目前为止，还不清楚明确启用
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.
选择每个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.
此外，GRAP实例（[GRAP]）可以在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解决方案时，这可能会导致一些复杂性，并且当GACP网络设备上的OAM代理不支持IPv6时，不可能利用GACP。因此，有人提出了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从本地传输移动到仅在边缘上的服务。在网络中没有多个并行传输系列的好处或需要，一个标准化减少了运营费用并提高了可靠性。数据平面的这种演变使得将开发周期投资于对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.
在其他类型的网络中，我们认为支持自主网络的努力最好用于确保支持一个地址系列，以便所有用例都能长期使用它，而不是重复IPv4的工作。此外，由于IPv4寻址空间的原因，使用IPv4的GACP的自动寻址将比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设备中的漏洞可能会导致泄漏到预期之外的地方。合并和收购以及其他影响国家奥委会的复杂网络重组就是典型的例子。
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
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年年中以来，该公司一直未对新上市公司开放。作者不知道还有其他活跃的互联网站点可以列出他们的使用情况。
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中使用RFC1918地址所需的设置相同。例如，参见[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地址时以自动方式设置它们。就机场核心计划而言，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中问题最少的用例之一：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.and 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，“唯一本地IPv6单播地址”，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/RFC67242012年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 6824DOI 10.17487/RFC68242013年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，“自主网络：定义和设计目标”，RFC 7575，DOI 10.17487/RFC7575752015年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]Anderson，T.和A.Leiva Popper，“无状态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，“自主控制平面（ACP）”，正在进行的工作，草稿-ietf-anima-Autonomic-Control-Plane-132017年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，“引导远程安全密钥基础设施（BRSKI）”，正在进行的工作，草稿-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.
[GRAP]Bormann，C.，Carpenter，B.，和B.Liu，“通用自主信号协议（GRAP）”，正在进行的工作，草稿-ietf-anima-GRAP-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标准——网桥和桥接网络”，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>.
[ITU_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.，和J.Nobre，“自主网络的参考模型”，在建工程，草案-ietf-anima-Reference-MODEL-06，2018年2月。
[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.“流控制传输协议”，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，“传输层安全（TLS）协议版本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，“数据报传输层安全版本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.
这项工作起源于思科系统公司（Cisco Systems）的一个自主网络项目，该项目始于2010年初，客户参与了设计和早期测试。许多人对本文中描述的方面做出了贡献，包括按字母顺序排列的：BL Balaji、Steinthor Bjarnason、Yves Herthoghs、Sebastian Meissner和Ravi Kumar Vadapalli。作者还要感谢迈克尔·理查森、詹姆斯·伍迪亚特和布赖恩·卡彭特的评论和评论。特别感谢盛江和穆罕默德·布卡代尔的全面审查。
Authors' Addresses
作者地址
Toerless Eckert (editor) Huawei USA 2330 Central Expy Santa Clara 95050 United States of America
无托勒埃克特（编辑）华为美国2330美国中部出口圣克拉拉95050美国
Email: tte+ietf@cs.fau.de, toerless.eckert@huawei.com
Email: tte+ietf@cs.fau.de, toerless.eckert@huawei.com
Michael H. Behringer
迈克尔·H·贝林格
Email: michael.h.behringer@gmail.com
Email: michael.h.behringer@gmail.com