draft-ietf-anima-stable-connectivity-10.txt   rfc8368.txt 
ANIMA T. Eckert, Ed. Internet Engineering Task Force (IETF) T. Eckert, Ed.
Internet-Draft Huawei Request for Comments: 8368 Huawei
Intended status: Informational M. Behringer Category: Informational M. Behringer
Expires: August 9, 2018 February 5, 2018 ISSN: 2070-1721 May 2018
Using Autonomic Control Plane for Stable Connectivity of Network OAM Using an Autonomic Control Plane for Stable Connectivity of
draft-ietf-anima-stable-connectivity-10 Network Operations, Administration, and Maintenance (OAM)
Abstract Abstract
OAM (Operations, Administration and Maintenance - as per BCP161, Operations, Administration, and Maintenance (OAM), as per BCP 161,
(RFC6291) processes for data networks are often subject to the for data networks is often subject to the problem of circular
problem of circular dependencies when relying on connectivity dependencies when relying on connectivity provided by the network to
provided by the network to be managed for the OAM purposes. be managed for the OAM purposes.
Provisioning while bringing up devices and networks tends to be more Provisioning while bringing up devices and networks tends to be more
difficult to automate than service provisioning later on, changes in difficult to automate than service provisioning later on. Changes in
core network functions impacting reachability cannot be automated core network functions impacting reachability cannot be automated
because of ongoing connectivity requirements for the OAM equipment because of ongoing connectivity requirements for the OAM equipment
itself, and widely used OAM protocols are not secure enough to be itself, and widely used OAM protocols are not secure enough to be
carried across the network without security concerns. carried across the network without security concerns.
This document describes how to integrate OAM processes with an This document describes how to integrate OAM processes with an
autonomic control plane in order to provide stable and secure autonomic control plane in order to provide stable and secure
connectivity for those OAM processes. This connectivity is not connectivity for those OAM processes. This connectivity is not
subject to aforementioned circular dependencies. subject to the aforementioned circular dependencies.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It has been approved for publication by the Internet
time. It is inappropriate to use Internet-Drafts as reference Engineering Steering Group (IESG). Not all documents approved by the
material or to cite them other than as "work in progress." IESG are candidates for any level of Internet Standard; see Section 2
of RFC 7841.
This Internet-Draft will expire on August 9, 2018. 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.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Self-dependent OAM Connectivity . . . . . . . . . . . . . 3 1.1. Self-Dependent OAM Connectivity . . . . . . . . . . . . . 3
1.2. Data Communication Networks (DCNs) . . . . . . . . . . . 3 1.2. Data Communication Networks (DCNs) . . . . . . . . . . . 3
1.3. Leveraging a generalized autonomic control plane . . . . 4 1.3. Leveraging a Generalized Autonomic Control Plane . . . . 4
2. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. GACP Requirements . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Stable Connectivity for Centralized OAM . . . . . . . . . 5 3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1. Simple Connectivity for Non-GACP capable NMS Hosts . 6 3.1. Stable Connectivity for Centralized OAM . . . . . . . . . 6
2.1.2. Challenges and Limitation of Simple Connectivity . . 7 3.1.1. Simple Connectivity for Non-GACP-Capable
2.1.3. Simultaneous GACP and data-plane Connectivity . . . . 8 NMS Hosts . . . . . . . . . . . . . . . . . . . . . . 7
2.1.4. IPv4-only NMS Hosts . . . . . . . . . . . . . . . . . 9 3.1.2. Challenges and Limitations of Simple Connectivity . . 8
2.1.5. Path Selection Policies . . . . . . . . . . . . . . . 12 3.1.3. Simultaneous GACP and Data-Plane Connectivity . . . . 9
2.1.6. Autonomic NOC Device/Applications . . . . . . . . . . 15 3.1.4. IPv4-Only NMS Hosts . . . . . . . . . . . . . . . . . 10
2.1.7. Encryption of data-plane connections . . . . . . . . 15 3.1.5. Path Selection Policies . . . . . . . . . . . . . . . 12
2.1.8. Long Term Direction of the Solution . . . . . . . . . 16 3.1.6. Autonomic NOC Device/Applications . . . . . . . . . . 16
2.2. Stable Connectivity for Distributed Network/OAM . . . . . 17 3.1.7. Encryption of Data-Plane Connections . . . . . . . . 16
3. Architectural Considerations . . . . . . . . . . . . . . . . 17 3.1.8. Long-Term Direction of the Solution . . . . . . . . . 17
3.1. No IPv4 for GACP . . . . . . . . . . . . . . . . . . . . 17 3.2. Stable Connectivity for Distributed Network/OAM . . 18
4. Security Considerations . . . . . . . . . . . . . . . . . . . 18 4. Architectural Considerations . . . . . . . . . . . . . . . . 18
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 4.1. No IPv4 for GACP . . . . . . . . . . . . . . . . . . . . 18
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. Change log [RFC Editor: Please remove] . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . 23 7.1. Normative References . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . 24 7.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
1.1. Self-dependent OAM Connectivity
OAM (Operations, Administration and Maintenance - as per BCP161, 1.1. Self-Dependent OAM Connectivity
[RFC6291]) for data networks is often subject to the problem of
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 circular dependencies when relying on the connectivity service
provided by the network to be managed. OAM can easily but provided by the network to be managed. OAM can easily but
unintentionally break the connectivity required for its own unintentionally break the connectivity required for its own
operations. Avoiding these problems can lead to complexity in OAM. operations. Avoiding these problems can lead to complexity in OAM.
This document describes this problem and how to use an autonomic This document describes this problem and how to use an autonomic
control plane to solve it without further OAM complexity: control plane to solve it without further OAM complexity.
The ability to perform OAM on a network device requires first the The ability to perform OAM on a network device requires first the
execution of OAM necessary to create network connectivity to that execution of OAM necessary to create network connectivity to that
device in all intervening devices. This typically leads to device in all intervening devices. This typically leads to
sequential, 'expanding ring configuration' from a NOC (Network sequential "expanding ring configuration" from a Network Operations
Operations Center). It also leads to tight dependencies between Center (NOC). It also leads to tight dependencies between
provisioning tools and security enrollment of devices. Any process provisioning tools and security enrollment of devices. Any process
that wants to enroll multiple devices along a newly deployed network that wants to enroll multiple devices along a newly deployed network
topology needs to tightly interlock with the provisioning process topology needs to tightly interlock with the provisioning process
that creates connectivity before the enrollment can move on to the that creates connectivity before the enrollment can move on to the
next device. next device.
When performing change operations on a network, it likewise is Likewise, when performing change operations on a network, it is
necessary to understand at any step of that process that there is no necessary to understand at any step of that process that there is no
interruption of connectivity that could lead to removal of interruption of connectivity that could lead to removal of
connectivity to remote devices. This includes especially change connectivity to remote devices. This includes especially change
provisioning of routing, forwarding, security and addressing policies provisioning of routing, forwarding, security, and addressing
in the network that often occur through mergers and acquisitions, the policies in the network that often occur through mergers and
introduction of IPv6 or other mayor re-hauls in the infrastructure acquisitions, the introduction of IPv6, or other major overhauls of
design. Examples include change of an IGP or areas, PA (Provider the infrastructure design. Examples include change of an IGP or
Aggregatable) to PI (Provider Independent) addressing, or systematic area, change from Provider Aggregatable (PA) to Provider Independent
topology changes (such as L2 to L3 changes). (PI) addressing, or systematic topology changes (such as Layer 2 to
Layer 3 changes).
All these circular dependencies make OAM complex and potentially All these circular dependencies make OAM complex and potentially
fragile. When automation is being used, for example through fragile. When automation is being used (for example, through
provisioning systems, this complexity extends into that automation provisioning systems), this complexity extends into that automation
software. software.
1.2. Data Communication Networks (DCNs) 1.2. Data Communication Networks (DCNs)
In the late 1990s and early 2000, IP networks became the method of In the late 1990s and early 2000, IP networks became the method of
choice to build separate OAM networks for the communications choice to build separate OAM networks for the communications
infrastructure within Network Providers. This concept was infrastructure within Network Providers. This concept was
standardized in ITU-T G.7712/Y.1703 [ITUT] and called "Data standardized in ITU-T G.7712/Y.1703 [ITUT_G7712] and called "Data
Communications Networks" (DCN). These were (and still are) Communications Networks" (DCNs). These were (and still are)
physically separate IP(/MPLS) networks that provide access to OAM physically separate IP or IP/MPLS networks that provide access to OAM
interfaces of all equipment that had to be managed, from PSTN (Public interfaces of all equipment that had to be managed, from Public
Switched Telephone Network) switches over optical equipment to Switched Telephone Network (PSTN) switches over optical equipment to
nowadays Ethernet and IP/MPLS production network equipment. nowadays Ethernet and IP/MPLS production network equipment.
Such DCN provide stable connectivity not subject to aforementioned Such DCNs provide stable connectivity not subject to the
problems because they are a separate network entirely, so change aforementioned problems because they are a separate network entirely,
configuration of the production IP network is done via the DCN but so change configuration of the production IP network is done via the
never affects the DCN configuration. Of course, this approach comes DCN but never affects the DCN configuration. Of course, this
at a cost of buying and operating a separate network and this cost is approach comes at a cost of buying and operating a separate network,
not feasible for many providers, most notably smaller providers, most and this cost is not feasible for many providers -- most notably,
enterprises and typical IoT networks (Internet of Things). smaller providers, most enterprises, and typical Internet of Things
(IoT) networks.
1.3. Leveraging a generalized autonomic control plane 1.3. Leveraging a Generalized Autonomic Control Plane
One of the goals of the IETF ANIMA (Autonomic Networking Integrated One of the goals of the IETF ANIMA (Autonomic Networking Integrated
Model and Approach ) working group is the specification of a secure Model and Approach) Working Group is the specification of a secure
and automatically built inband management plane that provides similar and automatically built in-band management plane that provides stable
stable connectivity as a DCN, but without having to build a separate connectivity similar to a DCN, but without having to build a separate
DCN. It is clear that such 'in-band' approach can never achieve DCN. It is clear that such an "in-band" approach can never fully
fully the same level of separation, but the goal is to get as close achieve the same level of separation, but the goal is to get as close
to it as possible. to it as possible.
This goal of this document is to discuss how such an inband This document discusses how such an in-band management plane can be
management plane can be used to support the DCN-like OAM use-case, used to support the DCN-like OAM use case, how to leverage its stable
leverage its stable connectivity and details the options of deploying connectivity, and what the options are for deploying it incrementally
it incrementally - short and long term. in the short and long term.
The evolving ANIMA working groups specification The ANIMA Working Group's evolving specification [ACP] calls this in-
[I-D.ietf-anima-autonomic-control-plane] ) calls this inband band management plane the "Autonomic Control Plane" (ACP). The
management plane the "Autonomic Control Plane" (ACP). The discussions in this document are not dependent on the specification
discussions in this document are not depending on the specification of that ACP, but only on a set of high-level constraints listed
of that ACP, but only on a set of high level constraints decided below, which were decided upon early during the work on the ACP.
early on in the work for the ACP. Unless being specific about Except when being specific about details of the ACP, this document
details of the ACP, this document uses the term "Generalized ACP" uses the term "Generalized ACP" (GACP) and is applicable to any
(GACP) and is applicable to any designs that meet those high level designs that meet the high-level constraints -- for example, the
constraints. For example - but not limited to - variations of the variations of the ACP protocol choices.
ACP protocol choices.
The high level constraints of a GACP assumed and discussed in this 2. GACP Requirements
The high-level constraints of a GACP assumed and discussed in this
document are as follows: document are as follows:
VRF Isolation: The GACP is a virtual network ("VRF") across network VRF isolation: The GACP is a virtual network (Virtual Routing and
devices - its routing and forwarding are separate from other Forwarding (VRF)) across network devices; its routing and
routing and forwarding in the network devices. Non-GACP routing/ forwarding are separate from other routing and forwarding in the
forwarding is called the "data-plane". network devices. Non-GACP routing/forwarding is called the "data
plane".
IPv6 only addressing: The GACP provides only IPv6 reachability. It IPv6-only addressing: The GACP provides only IPv6 reachability. It
uses ULA addresses ([RFC4193]) that are routed in a location uses Unique Local Addresses (ULAs) [RFC4193] that are routed in a
independent fashion for example through per network device subnet location-independent fashion, for example, through a subnet prefix
prefixes. Automatic addressing in the GACP is therefore simple & for each network device. Therefore, automatic addressing in the
stable: it does not require allocation by address registries, GACP is simple and stable: it does not require allocation by
addresses are identifiers, they do not change when devices move, address registries, addresses are identifiers, they do not change
and no engineering of the address space to the network topology is when devices move, and no engineering of the address space to the
necessary. network topology is necessary.
NOC connectivity: NOC equipment (controlling OAM operations) either NOC connectivity: NOC equipment (controlling OAM operations) either
has access to the GACP directly or has an IP subnet connection to has access to the GACP directly or has an IP subnet connection to
a GACP-edge device. a GACP edge device.
Closed Group Security: GACP devices have cryptographic credentials Closed Group Security: GACP devices have cryptographic credentials
to mutually authenticate each other as members of a GACP. Traffic to mutually authenticate each other as members of a GACP. Traffic
across the GACP is authenticated with these credentials and then across the GACP is authenticated with these credentials and then
encrypted. The only traffic permitted in & out of the GACP that encrypted.
is not authenticated by these credentials is through explicit
configuration the traffic from/to the aforementioned non-GACP NOC
equipment with subnet connections to a GACP-edge device (as a
transition method).
The GACP must be built autonomic and its function must not be GACP connect (interface): The only traffic permitted in and out of
disruptable by operator or automated (NMS/SDN) configuration/ the GACP that is not authenticated by GACP cryptographic
provisioning actions. These are allowed to only impact the "data- credentials is through explicit configuration for the traffic
plane". This aspect is not currently covered in this document. from/to the aforementioned non-GACP NOC equipment with subnet
Instead, it focusses on the impact of the above constraints: IPv6 connections to a GACP edge device (as a transition method).
only, dual connectivity and security.
2. Solutions 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.
2.1. Stable Connectivity for Centralized OAM 3. Solutions
The ANI is the "Autonomic Networking Infrastructure" consisting of 3.1. Stable Connectivity for Centralized OAM
secure zero touch Bootstrap (BRSKI -
[I-D.ietf-anima-bootstrapping-keyinfra]), GeneRic Autonomic Signaling The ANI is the Autonomic Networking Infrastructure consisting of
Protocol (GRASP - [I-D.ietf-anima-grasp]), and Autonomic Control secure zero-touch bootstrap (BRSKI [BRSKI]), the GeneRic Autonomic
Plane (ACP - [I-D.ietf-anima-autonomic-control-plane]). Refer to Signaling Protocol (GRASP [GRASP]), and Autonomic Control Plane (ACP
[I-D.ietf-anima-reference-model] for an overview of the ANI and how [ACP]). Refer to the reference model [REF_MODEL] for an overview of
its components interact and [RFC7575] for concepts and terminology of the ANI and how its components interact and [RFC7575] for concepts
ANI and autonomic networks. and terminology of ANI and autonomic networks.
This section describes stable connectivity for centralized OAM via This section describes stable connectivity for centralized OAM via
the GACP, for example via the ACP with or without a complete ANI, the GACP, for example, via the ACP with or without a complete ANI,
starting by what we expect to be the most easy to deploy short-term starting with the option that we expect to be the most easy to deploy
option. It then describes limitation and challenges of that approach in the short term. It then describes limitations and challenges of
and their solutions/workarounds to finish with the preferred target that approach and the corresponding solutions and workarounds; it
option of autonomic NOC devices in Section 2.1.6. finishes with the preferred target option of autonomic NOC devices in
Section 3.1.6.
This order was chosen because it helps to explain how simple initial This order was chosen because it helps to explain how simple initial
use of a GACP can be, how difficult workarounds can become (and use of a GACP can be and how difficult workarounds can become (and
therefore what to avoid), and finally because one very promising therefore what to avoid). Also, one very promising long-term
long-term solution alternative is exactly like the most easy short- solution is exactly like the most easy short-term solution, only
term solution only virtualized and automated. virtualized and automated.
In the most common case, OAM will be performed by one or more In the most common case, OAM will be performed by one or more
applications running on a variety of centralized NOC systems that applications running on a variety of centralized NOC systems that
communicate with network devices. We describe differently advanced communicate with network devices. This document describes approaches
approaches to leverage a GACP for stable connectivity. There is a to leverage a GACP for stable connectivity, from simple to complex,
wide range of options, some of which are simple, some more complex. depending on the capabilities and limitations of the equipment used.
Three stages can be considered: Three stages can be considered:
o There are simple options described in sections Section 2.1.1 o There are simple options described in Sections 3.1.1 through 3.1.3
through Section 2.1.3 that we consider to be good starting points that we consider to be good starting points to operationalize the
to operationalize the use of a GACP for stable connectivity today. use of a GACP for stable connectivity today. These options
These options require only network and OAN/NOC device require only network and OAM/NOC device configuration.
configuration.
o The are workarounds to connect a GACP to non-IPv6 capable NOC o The are workarounds to connect a GACP to non-IPv6-capable NOC
devices through the use of IPv4/IPv6 NAT (Network Address devices through the use of IPv4/IPv6 NAT (Network Address
Translation) as described in section Section 2.1.4. These Translation) as described in Section 3.1.4. These workarounds are
workarounds are not recommended but if such non-IPv6 capable NOC not recommended; however, if non-IPv6-capable NOC devices need to
devices need to be used longer term, then this is the only option be used longer term, then the workarounds are the only way to
to connect them to a GACP. connect them to a GACP.
o Near to long term options can provide all the desired operational, o Options for the near to long term can provide all the desired
zero touch and security benefits of an autonomic network, but a operational, zero-touch, and security benefits of an autonomic
range of details for this still have to be worked out and network, but a range of details for this still have to be worked
development work on NOC/OAM equipment is necessary. These options out, and development work on NOC/OAM equipment is necessary.
are discussed in sections Section 2.1.5 through Section 2.1.8. These options are discussed in Sections 3.1.5 through 3.1.8.
2.1.1. Simple Connectivity for Non-GACP capable NMS Hosts 3.1.1. Simple Connectivity for Non-GACP-Capable NMS Hosts
In the most simple candidate deployment case, the GACP extends all 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 the way into the NOC via one or more GACP edge devices. See also
section 6.1 of [I-D.ietf-anima-autonomic-control-plane]. These Section 6.1 of [ACP]. These devices "leak" the (otherwise encrypted)
devices "leak" the (otherwise encrypted) GACP natively to NMS hosts. GACP natively to NMS hosts. They act as the default routers to those
They act as the default routers to those NMS hosts and provide them NMS hosts and provide them with IPv6 connectivity into the GACP. NMS
with IPv6 connectivity into the GACP. NMS hosts with this setup need hosts with this setup need to support IPv6 (e.g., see [RFC6434]) but
to support IPv6 (see e.g. [RFC6434]) but require no other require no other modifications to leverage the GACP.
modifications to leverage the GACP.
Note that even though the GACP only uses IPv6, it can of course 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 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 devices support the GACP: The data plane can be IPv4 only, dual
or IPv6 only. It is always separate from the GACP, therefore there stack, or IPv6 only. It is always separate from the GACP; therefore,
is no dependency between the GACP and the IP version(s) used in the there is no dependency between the GACP and the IP version(s) used in
data-plane. the data plane.
This setup is sufficient for troubleshooting such as SSH into network This setup is sufficient for troubleshooting mechanisms such as SSH
devices, NMS that performs SNMP read operations for status checking, into network devices, NMS that performs SNMP read operations for
software downloads into autonomic devices, provisioning of devices status checking, software downloads onto autonomic devices,
via NETCONF and so on. In conjunction with otherwise unmodified OAM provisioning of devices via NETCONF, and so on. In conjunction with
via separate NMS hosts it can provide a good subset of the stable otherwise unmodified OAM via separate NMS hosts, this setup can
connectivity goals. The limitations of this approach are discussed provide a good subset of the stable connectivity goals. The
in the next section. limitations of this approach are discussed in the next section.
Because the GACP provides 'only' for IPv6 connectivity, and because Because the GACP provides "only" for IPv6 connectivity, and because
addressing provided by the GACP does not include any topological addressing provided by the GACP does not include any topological
addressing structure that operations in a NOC often relies on to addressing structure that a NOC often relies on to recognize where
recognize where devices are on the network, it is likely highly devices are on the network, it is likely highly desirable to set up
desirable to set up DNS (Domain Name System - see [RFC1034]) so that the Domain Name System (DNS; see [RFC1034]) so that the GACP IPv6
the GACP IPv6 addresses of autonomic devices are known via domain addresses of autonomic devices are known via domain names that
names that include the desired structure. For example, if DNS in the include the desired structure. For example, if DNS in the network
network was set up with names for network devices as were set up with names for network devices as
devicename.noc.example.com, and the well-known structure of the data- devicename.noc.example.com, and if the well-known structure of the
plane IPv4 addresses space was used by operators to infer the region data-plane IPv4 address space were used by operators to infer the
where a device is located in, then the GACP address of that device region where a device is located, then the GACP address of that
could be set up as devicename_<region>.acp.noc.example.com, and device could be set up as devicename_<region>.acp.noc.example.com,
devicename.acp.noc.example.com could be a CNAME to and devicename.acp.noc.example.com could be a CNAME to
devicename_<region>.acp.noc.example.com. Note that many networks devicename_<region>.acp.noc.example.com. Note that many networks
already use names for network equipment where topological information already use names for network equipment where topological information
is included, even without a GACP. is included, even without a GACP.
2.1.2. Challenges and Limitation of Simple Connectivity 3.1.2. Challenges and Limitations of Simple Connectivity
This simple connectivity of non-autonomic NMS hosts suffers from a 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 range of challenges (that is, operators may not be able to do it this
way) or limitations (that is, operator cannot achieve desired goals way) and limitations (that is, operators cannot achieve desired goals
with this setup). The following list summarizes these challenges and with this setup). The following list summarizes these challenges and
limitations. The following sections describe additional mechanisms limitations, and the following sections describe additional
to overcome them. mechanisms to overcome them.
Note that these challenges and limitations exist because GACP is Note that these challenges and limitations exist because GACP is
primarily designed to support distributed ASA (Autonomic Service primarily designed to support distributed Autonomic Service Agent
Agent, a piece of autonomic software) in the most lightweight (ASA), a piece of autonomic software, in the most lightweight
fashion, but not mandatorily require support for additional fashion. GACP is not required to support the additional mechanisms
mechanisms to best support centralized NOC operations. It is this needed for centralized NOC systems. It is this document that
document that describes additional (short term) workarounds and (long describes additional (short-term) workarounds and (long-term)
term) extensions. extensions.
1. (Limitation) NMS hosts cannot directly probe whether the desired 1. (Limitation) NMS hosts cannot directly probe whether the desired
so called 'data-plane' network connectivity works because they do so-called "data-plane" network connectivity works because they do
not directly have access to it. This problem is similar to not directly have access to it. This problem is similar to
probing connectivity for other services (such as VPN services) probing connectivity for other services (such as VPN services)
that they do not have direct access to, so the NOC may already that they do not have direct access to, so the NOC may already
employ appropriate mechanisms to deal with this issue (probing employ appropriate mechanisms to deal with this issue (probing
proxies). See Section 2.1.3 for candidate solutions. proxies). See Section 3.1.3 for candidate solutions.
2. (Challenge) NMS hosts need to support IPv6 which often is still 2. (Challenge) NMS hosts need to support IPv6, and this often is
not possible in enterprise networks. See Section 2.1.4 for some still not possible in enterprise networks. See Section 3.1.4 for
workarounds. some workarounds.
3. (Limitation) Performance of the GACP may be limited versus normal 3. (Limitation) Performance of the GACP may be limited versus normal
'data-plane' connectivity. The setup of the GACP will often "data-plane" connectivity. The setup of the GACP will often
support only non-hardware accelerated forwarding. Running a support only forwarding that is not hardware accelerated.
large amount of traffic through the GACP, especially for tasks Running a large amount of traffic through the GACP, especially
where it is not necessary will reduce its performance/ for tasks where it is not necessary, will reduce its performance
effectiveness for those operations where it is necessary or and effectiveness for those operations where it is necessary or
highly desirable. See Section 2.1.5 for candidate solutions. highly desirable. See Section 3.1.5 for candidate solutions.
4. (Limitation) Security of the GACP is reduced by exposing the GACP 4. (Limitation) Security of the GACP is reduced by exposing the GACP
natively (and unencrypted) into a subnet in the NOC where the NOC natively (and unencrypted) in a subnet in the NOC where the NOC
devices are attached to it. See Section 2.1.7 for candidate devices are attached to it. See Section 3.1.7 for candidate
solutions. solutions.
These four problems can be tackled independently of each other by These four problems can be tackled independently of each other by
solution improvements. Combining some of these solutions solution improvements. Combining some of these improvements together
improvements together can lead towards a candidate long term can lead towards a candidate long-term solution.
solution.
2.1.3. Simultaneous GACP and data-plane Connectivity 3.1.3. Simultaneous GACP and Data-Plane Connectivity
Simultaneous connectivity to both GACP and data-plane can be achieved Simultaneous connectivity to both the GACP and data plane can be
in a variety of ways. If the data-plane is IPv4-only, then any achieved in a variety of ways. If the data plane is IPv4 only, then
method for dual-stack attachment of the NOC device/application will any method for dual-stack attachment of the NOC device/application
suffice: IPv6 connectivity from the NOC provides access via the GACP, will suffice: IPv6 connectivity from the NOC provides access via the
IPv4 will provide access via the data-plane. If as explained above GACP; IPv4 provides access via the data plane. If, as explained
in the simple case, an autonomic device supports native attachment to above in the simple case, an autonomic device supports native
the GACP, and the existing NOC setup is IPv4 only, then it could be attachment to the GACP, and the existing NOC setup is IPv4 only, then
sufficient to attach the GACP device(s) as the IPv6 default router to it could be sufficient to attach the GACP device(s) as the IPv6
the NOC subnet and keep the existing IPv4 default router setup default router to the NOC subnet and keep the existing IPv4 default
unchanged. router setup unchanged.
If the data-plane of the network is also supporting IPv6, then the 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. most compatible setup for NOC devices is to have two IPv6 interfaces
One virtual ((e.g. via IEEE 802.1Q [IEEE802.1Q]) or physical -- one virtual (e.g., via IEEE 802.1Q [IEEE.802.1Q]) or physical
interface connecting to a data-plane subnet, and another into an GACP interface connecting to a data-plane subnet, and another connecting
connect subnet. See section 8.1 of into a GACP connect subnet. See Section 8.1 of [ACP] for more
[I-D.ietf-anima-autonomic-control-plane] for more details. That details. That document also specifies how a NOC device can receive
document also specifies how the NOC devices can receive auto autoconfigured addressing and routes towards the ACP connect subnet
configured addressing and routes towards the ACP connect subnet if it if it supports default address selection as specified in [RFC6724]
supports [RFC6724] and [RFC4191]. and default router preferences as specified in [RFC4191].
Configuring a second interface on a NOC host may be impossible or be Configuring a second interface on a NOC host may be impossible or
seen as undesired complexity. In that case the GACP edge device seen as undesired complexity. In that case, the GACP edge device
needs to provide support for a "Combined ACP and data-plane needs to provide support for a "combined ACP and data-plane
interface" as also described in section 8.1 of interface" as described in Section 8.1 of [ACP]. This setup may not
[I-D.ietf-anima-autonomic-control-plane]. This setup may not work work with autoconfiguration and all NOC host network stacks due to
with auto configuration and all NOC host network stacks due to
limitations in those network stacks. They need to be able to perform limitations in those network stacks. They need to be able to perform
RFC6724 source address selection rule 5.5 including caching of next- Rule 5.5 of [RFC6724] regarding source address selection, including
hop information. caching of next-hop information.
For security reasons, it is not considered appropriate to connect a For security reasons, it is not considered appropriate to connect a
non-GACP router to a GACP connect interface. The reason is that the 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 is a secured network domain, and all NOC devices connecting via
GACP connect interfaces are also part of that secure domain - the GACP connect interfaces are also part of that secure domain. The
main difference is that the physical link between the GACP edge main difference is that the physical links between the GACP edge
device and the NOC devices is not authenticated/encrypted and device and the NOC devices are not authenticated or encrypted and,
therefore, needs to be physically secured. If the secure GACP was therefore, need to be physically secured. If the secure GACP was
extendable via untrusted routers then it would be a lot more extendable via untrusted routers, then it would be a lot more
difficult to verify the secure domain assertion. Therefore the GACP difficult to verify the secure domain assertion. Therefore, the GACP
edge devices are not supposed to redistribute routes from non-GACP edge devices are not supposed to redistribute routes from non-GACP
routers into the GACP. routers into the GACP.
2.1.4. IPv4-only NMS Hosts 3.1.4. IPv4-Only NMS Hosts
One architectural expectation for the GACP as described in One architectural expectation for the GACP as described in
Section 1.3 is that all devices that want to use the GACP do support Section 1.3 is that all devices that want to use the GACP (including
IPv6. Including NMS hosts. Note that this expectation does not NMS hosts) support IPv6. Note that this expectation does not imply
imply any requirements against the data-plane, especially no need to any requirements for the data plane, especially it does not imply
support IPv6 in it. The data-plane could be IPv4 only, IPv6 only, that IPv6 must be supported in it. The data plane could be IPv4
dual stack or it may not need to have any IP host stack on the only, IPv6 only, dual stack, or it may not need to have any IP host
network devices. stack on the network devices.
The implication of this architectural decision is the potential need The implication of this architectural decision is the potential need
for short-term workarounds when the operational practices in a for short-term workarounds when the operational practices in a
network do not yet meet these target expectations. This section network do not yet meet these target expectations. This section
explains when and why these workarounds may be operationally explains when and why these workarounds may be operationally
necessary and describes them. However, the long term goal is to necessary and describes them. However, the long-term goal is to
upgrade all NMS hosts to native IPv6, so the workarounds described in upgrade all NMS hosts to native IPv6, so the workarounds described in
this section should not be considered permanent. this section should not be considered permanent.
Most network equipment today supports IPv6 but it is by far not Most network equipment today supports IPv6, but it is very far from
ubiquitously supported in NOC backend solutions (HW/SW), especially being ubiquitously supported in NOC backend solutions (hardware or
not in the product space for enterprises. Even when it is supported, software) or in the product space for enterprises. Even when it is
there are often additional limitations or issues using it in a dual supported, there are often additional limitations or issues using it
stack setup or the operator mandates for simplicity single stack for in a dual-stack setup, or the operator mandates (for simplicity)
all operations. For these reasons an IPv4 only management plane is single stack for all operations. For these reasons, an IPv4-only
still required and common practice in many enterprises. Without the management plane is still required and common practice in many
desire to leverage the GACP, this required and common practice is not enterprises. Without the desire to leverage the GACP, this required
a problem for those enterprises even when they run dual stack in the and common practice is not a problem for those enterprises even when
network. We discuss these workarounds here because it is a short they run dual stack in the network. We discuss these workarounds
term deployment challenge specific to the operations of a GACP. here because it is a short-term deployment challenge specific to the
operations of a GACP.
To connect IPv4 only management plane devices/applications with a To connect IPv4-only management-plane devices/applications with a
GACP, some form of IP/ICMP translation of packets IPv4<->IPv6 is GACP, some form of IP/ICMP translation of packets between IPv4 and
necessary. The basic mechanisms for this are defined in SIIT IPv6 is necessary. The basic mechanisms for this are in [RFC7915],
([RFC7915]). There are multiple solutions using this mechanism. To which describes the Stateless IP/ICMP Translation Algorithm (SIIT).
understand the possible solutions, we consider the requirements: There are multiple solutions using this mechanism. To understand the
possible solutions, we consider the requirements:
1. NMS hosts need to be able to initiate connections to any GACP 1. NMS hosts need to be able to initiate connections to any GACP
device for management purposes. Examples include provisioning device for management purposes. Examples include provisioning
via Netconf/(SSH), SNMP poll operations or just diagnostics via via NETCONF, SNMP poll operations, or just diagnostics via SSH
SSH connections from operators. Every GACP device/function that connections from operators. Every GACP device/function that
needs to be reachable from NMS hosts needs to have a separate needs to be reachable from NMS hosts needs to have a separate
IPv4 address. IPv4 address.
2. GACP devices need to be able to initiate connections to NMS hosts 2. GACP devices need to be able to initiate connections to NMS
for example to initiate NTP or radius/diameter connections, send hosts, for example, to initiate NTP or RADIUS/Diameter
syslog or SNMP trap or initiate Netconf Call Home connections connections, send syslog or SNMP trap, or initiate NETCONF Call
after bootstrap. Every NMS host needs to have a separate IPv6 Home connections after bootstrap. Every NMS host needs to have a
address reachable from the GACP. When connections from GACP separate IPv6 address reachable from the GACP. When a connection
devices are made to NMS hosts, the IPv4 source address of these from a GACP device is made to an NMS host, the IPv4 source
connections as seen by the NMS Host must also be unique per GACP address of the connection (as seen by the NMS host) must be
device and the same address as in (1) to maintain the same unique per GACP device and must be the same address as in (1) to
addressing simplicity as in a native IPv4 deployment. For maintain addressing simplicity similar to a native IPv4
example in syslog, the source-IP address of a logging device is deployment. For example in syslog, the source IP address of a
used to identify it, and if the device shows problems, an logging device is used to identify it, and if the device shows
operator might want to SSH into the device to diagnose it. problems, an operator might want to SSH into the device to
diagnose it.
Because of these requirements, the necessary and sufficient set of Because of these requirements, the necessary and sufficient set of
solutions are those that provide 1:1 mapping of IPv6 GACP addresses 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 into IPv4 space and 1:1 mapping of IPv4 NMS host space into IPv6 (for
use in the GACP). This means that stateless SIIT based solutions are use in the GACP). This means that SIIT-based solutions are
sufficient and preferred. sufficient and preferred.
Note that GACP devices may use multiple IPv6 addresses in the GACP. Note that GACP devices may use multiple IPv6 addresses in the GACP.
For example, [I-D.ietf-anima-autonomic-control-plane] section 6.10 For example, Section 6.10 of [ACP] defines multiple useful addressing
defines multiple useful addressing sub-schemes supporting this sub-schemes supporting this option. All those addresses may then
option. All those addresses may then need to be reachable through need to be reachable through IPv6/IPv4 address translation.
the IPv6/IPv4 address translation.
The need to allocate for every GACP device one or multiple 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 addresses should not be a problem if -- as we assume -- the NMS hosts
can use private IPv4 address space ([RFC1918]). Nevertheless even can use private IPv4 address space ([RFC1918]). Nevertheless, even
with RFC1918 address space it is important that the GACP IPv6 with private IPv4 address space, it is important that the GACP IPv6
addresses can efficiently be mapped into IPv4 address space without addresses can be mapped efficiently into IPv4 address space without
too much waste. too much waste.
The currently most flexible mapping scheme to achieve this is Currently, the most flexible mapping scheme to achieve this is
[RFC7757] because it allows configured IPv4 <-> IPv6 prefix mapping. [RFC7757] because it allows configured IPv4 <-> IPv6 prefix mapping.
Assume the GACP uses the ACP "Zone Addressing" Sub-Scheme and there Assume the GACP uses the ACP Zone Addressing Sub-Scheme and there are
are 3 registrars. In the Zone Addressing Sub-Scheme, there is for 3 registrars. In the ACP Zone Addressing Sub-Scheme, for each
each registrar a constant /112 prefix for which in RFC7757 an EAM registrar, there is a constant /112 prefix for which an Explicit
(Explicit Address Mapping) into a /16 (e.g.: RFC1918) prefix into Address Mapping (EAM), as defined in RFC 7757, to a /16 prefix can be
IPv4 can be configured. Within the registrars /112 prefix, Device- configured (e.g., in the private IPv4 address space described in
Numbers for devices are sequentially assigned: with V-bit effectively [RFC1918]). Within the registrar's /112 prefix, Device-Numbers for
two numbers are assigned per GACP device. This also means that if devices are sequentially assigned: with the V bit (Virtualization
IPv4 address space is even more constrained, and it is known that a bit) effectively two numbers are assigned per GACP device. This also
registrar will never need the full /15 extent of Device-Numbers, then means that if IPv4 address space is even more constrained, and it is
a longer than /112 prefix can be configured into the EAM to use less known that a registrar will never need the full /15 extent of Device-
IPv4 space. Numbers, then a prefix longer than a /112 can be configured into the
EAM in order to use less IPv4 space.
When using the ACP "Vlong Addressing" Sub-Scheme, it is unlikely that When using the ACP Vlong Addressing Sub-Scheme, it is unlikely that
one wants or need to translate the full /8 or /16 bits of addressing 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 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 dropping trailing bits can be used to map only N bits of the V bits
into IPv4. This does imply though that only V-addresses that differ 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. in those high-order N V bits can be distinguished on the IPv4 side.
Likewise, the IPv4 address space used for NMS hosts can easily be Likewise, the IPv4 address space used for NMS hosts can easily be
mapped into an address prefix assigned to a GACP connect interface. mapped into an address prefix assigned to a GACP connect interface.
A full specification of a solution to perform SIIT in conjunction A full specification of a solution to perform SIIT in conjunction
with GACP connect following the considerations below is outside the with GACP connect following the considerations below is outside the
scope of this document. scope of this document.
To be in compliance with security expectations, SIIT has to happen on To be in compliance with security expectations, SIIT has to happen on
the GACP edge device itself so that GACP security considerations can the GACP edge device itself so that GACP security considerations can
be taken into account. E.g.: that IPv4 only NMS hosts can be dealt be taken into account. For example, IPv4-only NMS hosts can be dealt
with exactly like IPv6 hosts connected to a GACP connect interface. with exactly like IPv6 hosts connected to a GACP connect interface.
Note that prior solutions such as NAT64 ([RFC6146]) may equally be Note that prior solutions such as NAT64 ([RFC6146]) may equally be
useable to translate between GACP IPv6 address space and NMS Hosts useable to translate between GACP IPv6 address space and NMS hosts'
IPv4 address space, and that as workarounds this can also be done on IPv4 address space. As a workaround, this can also be done on non-
non GACP Edge Devices connected to a GACP connect interface. The GACP Edge Devices connected to a GACP connect interface. The details
details vary depending on implementation because the options to vary depending on implementation because the options to configure
configure address mappings vary widely. Outside of EAM, there are no address mappings vary widely. Outside of EAM, there are no
standardized solutions that allow for mapping of prefixes, so it will standardized solutions that allow for mapping of prefixes, so it will
most likely be necessary to explicitly map every individual (/128) most likely be necessary to explicitly map every individual (/128)
GACP device address to an IPv4 address. Such an approach should use GACP device address to an IPv4 address. Such an approach should use
automation/scripting where these address translation entries are automation/scripting where these address translation entries are
created dynamically whenever a GACP device is enrolled or first created dynamically whenever a GACP device is enrolled or first
connected to the GACP network. connected to the GACP network.
Overall, the use of NAT is especially subject to the ROI (Return On The NAT methods described here are not specific to a GACP. Instead,
Investment) considerations, but the methods described here may not be they are similar to what would be necessary when some parts of a
too different from the same problems encountered totally independent network only support IPv6, but the NOC equipment does not support
of GACP when some parts of the network are to introduce IPv6 but NMS IPv6. Whether it is more appropriate to wait until the NOC equipment
hosts are not (yet) upgradeable. 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.
2.1.5. Path Selection Policies 3.1.5. Path Selection Policies
As mentioned above, a GACP is not expected to have high performance As mentioned above, a GACP is not expected to have high performance
because its primary goal is connectivity and security, and for because its primary goal is connectivity and security. For existing
existing network device platforms this often means that it is a lot network device platforms, this often means that it is a lot more
more effort to implement that additional connectivity with hardware effort to implement that additional connectivity with hardware
acceleration than without - especially because of the desire to acceleration than without -- especially because of the desire to
support full encryption across the GACP to achieve the desired support full encryption across the GACP to achieve the desired
security. security.
Some of these issues may go away in the future with further adoption Some of these issues may go away in the future with further adoption
of a GACP and network device designs that better tender to the needs of a GACP and network device designs that better tend to the needs of
of a separate OAM plane, but it is wise to plan for even long-term a separate OAM plane, but it is wise to plan for long-term designs of
designs of the solution that does NOT depend on high-performance of the solution that do NOT depend on high performance of the GACP.
the GACP. This is opposite to the expectation that future NMS hosts This is the opposite of the expectations that future NMS hosts will
will have IPv6, so that any considerations for IPv4/NAT in this have IPv6 and that any considerations for IPv4/NAT in this solution
solution are temporary. are temporary.
To solve the expected performance limitations of the GACP, we do To solve the expected performance limitations of the GACP, we do
expect to have the above describe dual-connectivity via both GACP and expect to have the above-described dual connectivity via both GACP
data-plane between NOC application devices and devices with 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 The GACP connectivity is expected to always be there (as soon as a
device is enrolled), but the data-plane connectivity is only present device is enrolled), but the data-plane connectivity is only present
under normal operations but will not be present during e.g. early under normal operations and will not be present during, e.g., early
stages of device bootstrap, failures, provisioning mistakes or during stages of device bootstrap, failures, provisioning mistakes, or
network configuration changes. network configuration changes.
The desired policy is therefore as follows: In the absence of further The desired policy is therefore as follows: In the absence of further
security considerations (see below), traffic between NMS hosts and security considerations (see below), traffic between NMS hosts and
GACP devices should prefer data-plane connectivity and resort only to GACP devices should prefer data-plane connectivity and resort only to
using the GACP when necessary, unless it is an operation known to be using the GACP when necessary. The exception is an operation known
so much tied to the cases where the GACP is necessary that it makes to be covered by the use cases where the GACP is necessary, so that
no sense to try using the data-plane. An example are SSH connections it makes no sense to try using the data plane. An example is an SSH
from the NOC into a network device to troubleshoot network connection from the NOC to a network device to troubleshoot network
connectivity. This could easily always rely on the GACP. Likewise, connectivity. This could easily always rely on the GACP. Likewise,
if an NMS host is known to transmit large amounts of data, and it if an NMS host is known to transmit large amounts of data, and it
uses the GACP, then its performance need to be controlled so that it uses the GACP, then its data rate needs to be controlled so that it
will not overload the GACP performance. Typical examples of this are will not overload the GACP path. Typical examples of this are
software downloads. software downloads.
There is a wide range of methods to build up these policies. We There is a wide range of methods to build up these policies. We
describe a few: describe a few below.
Ideally, a NOC system would learn and keep track of all addresses of Ideally, a NOC system would learn and keep track of all addresses of
a device (GACP and the various data-plane addresses). Every action a device (GACP and the various data-plane addresses). Every action
of the NOC system would indicate via a "path-policy" what type of 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 connection it needs (e.g., only data-plane, GACP only, default to
data-plane, fallback to GACP,...). A connection policy manager would data plane, fallback to GACP, etc.). A connection policy manager
then build connection to the target using the right address(es). would then build connection to the target using the right
Shorter term, a common practice is to identify different paths to a address(es). Shorter term, a common practice is to identify
device via different names (e.g. loopback vs. interface addresses). different paths to a device via different names (e.g., loopback vs.
This approach can be expanded to GACP uses, whether it uses NOC interface addresses). This approach can be expanded to GACP uses,
system local names or DNS. We describe example schemes using DNS: whether it uses the DNS or names local to the NOC system. Below, we
describe example schemes using DNS.
DNS can be used to set up names for the same network devices but with DNS can be used to set up names for the same network devices but with
different addresses assigned: One name (name.noc.example.com) with different addresses assigned:
only the data-plane address(es) (IPv4 and/or IPv6) to be used for
probing connectivity or performing routine software downloads that o One name (name.noc.example.com) with only the data-plane
may stall/fail when there are connectivity issues. One name (name- address(es) (IPv4 and/or IPv6) to be used for probing connectivity
acp.noc.example.com) with only the GACP reachable address of the or performing routine software downloads that may stall/fail when
device for troubleshooting and probing/discovery that is desired to there are connectivity issues.
always only use the GACP. One name with data-plane and GACP
addresses (name-both.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 One name (name-both.noc.example.com) with data-plane and GACP
addresses.
Traffic policing and/or shaping at the GACP edge in the NOC can be Traffic policing and/or shaping at the GACP edge in the NOC can be
used to throttle applications such as software download into the used to throttle applications such as software download into the
GACP. GACP.
Using different names mapping to different (subset of) addresses can Using different names that map to different addresses (or subsets of
be difficult to set up and maintain, especially also because data- addresses) can be difficult to set up and maintain, especially
plane addresses may change due to reconfiguration or relocation of because data-plane addresses may change due to reconfiguration or
devices. The name based approach alone can also not well support relocation of devices. The name-based approach alone cannot strongly
policies for existing applications and long-lived flows to support policies for existing applications and long-lived flows to
automatically switch between ACP and data-plane in the face of data- automatically switch between the ACP and data plane in the face of
plane failure and recovery. A solution would be GACP node host data-plane failure and recovery. A solution would be host transport
transport stacks supporting the following requirements: stacks on GACP nodes that support the following requirements:
1. Only the GACP addresses of the responder must be required by the 1. Only the GACP addresses of the responder must be required by the
initiator for the initial setup of a connection/flow across the initiator for the initial setup of a connection/flow across the
GACP. GACP.
2. Responder and Initiator must be able to exchange their data-plane 2. Responder and Initiator must be able to exchange their data-plane
addresses through the GACP, and then - if needed by policy - addresses through the GACP, and then -- if needed by policy --
build an additional flow across the data-plane. build an additional flow across the data plane.
3. For unmodified application, the following policies should be 3. For unmodified application, the following policies should be
configurable on at least a per-application basis for its TCP configurable on at least a per-application basis for its TCP
connections with GACP peers: connections with GACP peers:
Fallback (to GACP): An additional data-plane flow is built and Fallback (to GACP): An additional data-plane flow is built and
used exclusively to send data whenever the data-plane is used exclusively to send data whenever the data plane is
operational. When it can not be built during connection setup operational. When the additional flow cannot be built during
or when it fails later, traffic is sent across the GACP flow. connection setup or when it fails later, traffic is sent
This could be a default-policy for most OAM applications using across the GACP flow. This could be a default policy for most
the GACP. OAM applications using the GACP.
>Suspend/Fail: Like the Fallback policy, except that traffic Suspend/Fail: Like the Fallback policy, except that traffic will
will not use the GACP flow but will be suspended until a data- not use the GACP flow; instead, it will be suspended until a
plane flow is operational or until a policy configurable data-plane flow is operational or until a policy-configurable
timeout indicates a connection failure to the application. timeout indicates a connection failure to the application.
This policy would be appropriate for large volume background/ This policy would be appropriate for large-volume background
scavenger class OAM application/connections such as firmware or scavenger-class OAM applications such as firmware downloads
downloads or telemetry/diagnostic uploads - which would or telemetry/diagnostic uploads -- applications that would
otherwise easily overrun performance limited GACP otherwise easily overrun performance-limited GACP
implementations. implementations.
>GACP (only): No additional data-plane flow is built, traffic is GACP (only): No additional data-plane flow is built, traffic is
only sent via the GACP flow. This can just be a TCP only sent via the GACP flow. This can just be a TCP
connection. This policy would be most appropriate for OAM connection. This policy would be most appropriate for OAM
operations known to change the data plane in a way that could operations known to change the data plane in a way that could
impact (at least temporarily) connectivity through it. impact connectivity through it (at least temporarily).
4. In the presence of responders or initiators not supporting these 4. In the presence of responders or initiators not supporting these
host stack functions, the Fallback and GACP policies must result host stack functions, the Fallback and GACP policies must result
in a TCP connection across the GACP. For Suspend/Fail, presence in a TCP connection across the GACP. For Suspend/Fail, presence
of TCP-only peers should result in failure during connection of TCP-only peers should result in failure during connection
setup. setup.
5. In case of Fallback and Suspend/Fail, a failed data-plane 5. In case of Fallback and Suspend/Fail, a failed data-plane
connection should automatically be rebuilt when the data-plane connection should automatically be rebuilt when the data plane
recovers, including the case that the data-plane address of one recovers, including when the data-plane address of one side or
(or both) side(s) may have changed - for example because of both sides may have changed -- for example, because of
reconfiguration or device repositioning. reconfiguration or device repositioning.
6. Additional data-plane flows created by these host transport stack 6. Additional data-plane flows created by these host transport stack
functions must be end-to-end authenticated by it with the GACP functions must be end-to-end authenticated by these host
domain credentials and encrypted. This maintains the expectation transport stack functions with the GACP domain credentials and
that connections from GACP addresses to GACP addresses are encrypted. This maintains the expectation that connections from
authenticated/encrypted. This may be skipped if the application GACP addresses to GACP addresses are authenticated and encrypted.
already provides for end-to-end encryption. This may be skipped if the application already provides for end-
to-end encryption.
7. For enhanced applications, the host stack may support application 7. For enhanced applications, the host stack may support application
control to select the policy on a per-connection basis, or even control to select the policy on a per-connection basis, or even
more explicit control for building of the flows and which flow more explicit control for building of the flows and which flow
should pass traffic. should pass traffic.
Protocols like MPTCP (Multipath TCP -see [RFC6824]) and SCTP Protocols like Multipath TCP (MPTCP; see [RFC6824]) and the Stream
([RFC4960]) can already support part of these requirements. MPTCP Control Transmission Protocol (SCTP; see [RFC4960]) can already
for example supports signaling of addresses in a TCP backward support part of these requirements. MPTCP, for example, supports
compatible fashion, establishment of additional flows (called signaling of addresses in a TCP backward-compatible fashion,
subflows in MPTCP) and having primary and fallback subflows via establishing additional flows (called subflows in MPTCP), and having
MP_PRIO signalling. The details if or how MPTCP, SCTP and/or other primary and fallback subflows via MP_PRIO signaling. The details of
approaches potentially with extensions and/or (shim) layers on top of how MPTCP, SCTP, and/or other approaches (potentially with extensions
them can best provide a complete solution for the above requirements and/or (shim) layers on top of them) can best provide a complete
is subject to further work outside the scope of this document. solution for the above requirements need further work and are outside
the scope of this document.
2.1.6. Autonomic NOC Device/Applications 3.1.6. Autonomic NOC Device/Applications
Setting up connectivity between the NOC and autonomic devices when Setting up connectivity between the NOC and autonomic devices when
the NOC device itself is non-autonomic is as mentioned in the the NOC device itself is non-autonomic is a security issue, as
beginning a security issue. It also results as shown in the previous mentioned at the beginning of this document. It also results in a
paragraphs in a range of connectivity considerations, some of which range of connectivity considerations (discussed in Section 3.1.5),
may be quite undesirable or complex to operationalize. some of which may be quite undesirable or complex to operationalize.
Making NMS hosts autonomic and having them participate in the GACP is Making NMS hosts autonomic and having them participate in the GACP is
therefore not only a highly desirable solution to the security therefore not only a highly desirable solution to the security
issues, but can also provide a likely easier operationalization of issues, but can also provide a likely easier operationalization of
the GACP because it minimizes NOC-special edge considerations - the the GACP because it minimizes special edge considerations for the
GACP is simply built all the way automatically, even inside the NOC NOC. The GACP is simply built all the way automatically, even inside
and only authorized and authenticate NOC devices/applications will the NOC, and it is only authorizes and authenticates NOC devices/
have access to it. applications that will have access to it.
Supporting the ACP according to According to [ACP], supporting the ACP all the way into an
[I-D.ietf-anima-autonomic-control-plane] all the way into an
application device requires implementing the following aspects in it: application device requires implementing the following aspects in it:
AN bootstrap/enrollment mechanisms, the secure channel for the ACP AN bootstrap/enrollment mechanisms, the secure channel for the ACP
and at least the host side of IPv6 routing setup 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 Minimally, this could all be implemented as an application and be
available to the host OS via e.g. a tap driver to make the ACP show made available to the host OS via, e.g., a TAP driver to make the ACP
up as another IPv6 enabled interface. show up as another IPv6-enabled interface.
Having said this: If the structure of NMS hosts is transformed Having said this: If the structure of NMS hosts is transformed
through virtualization anyhow, then it may be considered equally through virtualization anyhow, then it may be considered equally
secure and appropriate to construct (physical) NMS host system by secure and appropriate to construct a (physical) NMS host system by
combining a virtual GACP enabled router with non-GACP enabled NOC- combining a virtual GACP-enabled router with non-GACP-enabled Virtual
application VMs via a hypervisor, leveraging the configuration Machines (VMs) for NOC applications via a hypervisor. This would
options described in the previous sections but just virtualizing leverage the configuration options described in the previous sections
them. but just virtualize them.
2.1.7. Encryption of data-plane connections 3.1.7. Encryption of Data-Plane Connections
When combining GACP and data-plane connectivity for availability and When combining GACP and data-plane connectivity for availability and
performance reasons, this too has an impact on security: When using performance reasons, this too has an impact on security: When using
the GACP, the traffic will be mostly encryption protected, especially the GACP, most traffic will be encryption protected, especially when
when considering the above described use of application devices with considering the above-described use of application devices with GACP.
GACP. If instead the data-plane is used, then this is not the case If, instead, the data plane is used, then this is not the case
anymore unless it is done by the application. anymore unless it is done by the application.
The simplest solution for this problem exists when using GACP capable The simplest solution for this problem exists when using GACP-capable
NMS hosts, because in that case the communicating GACP capable NMS NMS hosts, because in that case the communicating GACP-capable NMS
host and the GACP network device have credentials they can mutually host and the GACP network device have credentials they can mutually
trust (same GACP domain). In result, data-plane connectivity that trust (same GACP domain). As a result, data-plane connectivity that
does support this can simply leverage TLS/DTLS does support this can simply leverage TLS [RFC5246] or DTLS [RFC6347]
([RFC5246])/([RFC6347]) with those GACP credentials for mutual with those GACP credentials for mutual authentication -- and this
authentication - and does not incur new key management. does not incur new key management.
If this automatic security benefit is seen as most important, but a If this automatic security benefit is seen as most important, but a
"full" GACP stack into the NMS host is unfeasible, then it would "full" GACP stack into the NMS host is unfeasible, then it would
still be possible to design a stripped down version of GACP still be possible to design a stripped-down version of GACP
functionality for such NOC hosts that only provides enrollment of the functionality for such NOC hosts that only provides enrollment of the
NOC host with the GACP cryptographic credentials but without directly NOC host with the GACP cryptographic credentials and does not
participating in the GACP encryption method. Instead, the host would directly participate in the GACP encryption method. Instead, the
just leverage TLS/DTLS using its GACP credentials via the data-plane host would just leverage TLS/DTLS using its GACP credentials via the
with GACP network devices as well as indirectly via the GACP with the data plane with GACP network devices as well as indirectly via the
above mentioned GACP connect into the GACP. GACP connect interface with the above-mentioned GACP connect
interface into the GACP.
When using the GACP itself, TLS/DTLS for the transport layer between 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 NMS hosts and network device is somewhat of a double price to pay
(GACP also encrypts) and could potentially be optimized away, but (GACP also encrypts) and could potentially be optimized away;
given the assumed lower performance of the GACP, it seems that this however, given the assumed lower performance of the GACP, it seems
is an unnecessary optimization. that this is an unnecessary optimization.
2.1.8. Long Term Direction of the Solution 3.1.8. Long-Term Direction of the Solution
If we consider what potentially could be the most lightweight and If we consider what potentially could be the most lightweight and
autonomic long term solution based on the technologies described autonomic long-term solution based on the technologies described
above, we see the following direction: above, we see the following direction:
1. NMS hosts should at least support IPv6. IPv4/IPv6 NAT in the 1. NMS hosts should at least support IPv6. IPv4/IPv6 NAT in the
network to enable use of a GACP is long term undesirable. Having network to enable use of a GACP is undesirable in the long term.
IPv4 only applications automatically leverage IPv6 connectivity Having IPv4-only applications automatically leverage IPv6
via host-stack translation may be an option but this has not been connectivity via host-stack translation may be an option, but
investigated yet. this has not been investigated yet.
2. Build the GACP as a lightweight application for NMS hosts so GACP 2. Build the GACP as a lightweight application for NMS hosts so GACP
extends all the way into the actual NMS hosts. extends all the way into the actual NMS hosts.
3. Leverage and as necessary enhance host transport stacks with 3. Leverage and (as necessary) enhance host transport stacks with
automatic multipath-connectivity GACP and data-plane as outlined automatic GACP with multipath connectivity and data plane as
in Section 2.1.5. outlined in Section 3.1.5.
4. Consider how to best map NMS host desires to underlying transport 4. Consider how to best map NMS host desires to underlying transport
mechanisms: With the above mentioned 3 points, not all options mechanisms: The three points above do not cover all options.
are covered. Depending on the OAM, one may still want only GACP, Depending on the OAM, one may still want only GACP, want only
only data-plane, or automatically prefer one over the other and/ data plane, automatically prefer one over the other, and/or want
or use the GACP with low performance or high-performance (for to use the GACP with low performance or high performance (for
emergency OAM such as countering DDoS). It is as of today not emergency OAM such as countering DDoS). As of today, it is not
clear what the simplest set of tools is to enable explicitly the clear what the simplest set of tools is to explicitly enable the
choice of desired behavior of each OAM. The use of the above choice of desired behavior of each OAM. The use of the above-
mentioned DNS and multipath mechanisms is a start, but this will mentioned DNS and multipath mechanisms is a start, but this will
require additional work. This is likely a specific case of the require additional work. This is likely a specific case of the
more generic scope of TAPS. more generic scope of TAPS.
2.2. Stable Connectivity for Distributed Network/OAM 3.2. Stable Connectivity for Distributed Network/OAM
Today, many distributed protocols implement their own unique security Today, many distributed protocols implement their own unique security
mechanisms. mechanisms.
KARP (Keying and Authentication for Routing Protocols, see [RFC6518]) Keying and Authentication for Routing Protocols (KARP; see [RFC6518])
has tried to start to provide common directions and therefore reduce has tried to start to provide common directions and therefore reduce
the re-invention of at least some of the security aspects, but it the reinvention of at least some of the security aspects, but it only
only covers routing-protocols and it is unclear how well it is covers routing protocols and it is unclear how applicable it is to a
applicable to a potentially wider range of network distributed agents wider range of network distributed agents such as those performing
such as those performing distributed OAM. The common security of a distributed OAM. The common security of a GACP can help in those
GACP can help in these cases. cases.
Furthermore, GRASP ([I-D.ietf-anima-grasp]) can run on top of a GACP Furthermore, a GRASP instance ([GRASP]) can run on top of a GACP as a
as a security and transport substrate and provide common local & security and transport substrate and provide common local and remote
remote neighbor discovery and peer negotiation mechanism, further neighbor discovery and peer negotiation mechanisms; this would allow
allowing to unifying & reuse future protocol designs. unifying and reusing future protocol designs.
3. Architectural Considerations 4. Architectural Considerations
3.1. No IPv4 for GACP 4.1. No IPv4 for GACP
The GACP is intended to be IPv6 only, and the prior explanations in 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 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 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 leverage the GACP when the OAM agents on a GACP network device do not
support IPv6. Therefore, the question was raised whether the GACP support IPv6. Therefore, the question was raised whether the GACP
should optionally also support IPv4. should optionally also support IPv4.
The decision not to include IPv4 for GACP as something that is The decision not to include IPv4 for GACP in the use cases in this
considered in the use cases in this document is because of the document was made for the following reasons:
following reasons:
In SP networks that have started to support IPv6, often the next In service provider networks that have started to support IPv6, often
planned step is to consider moving out IPv4 from a native transport the next planned step is to consider moving IPv4 from a native
to just a service on the edge. There is no benefit/need for multiple transport to just a service on the edge. There is no benefit or need
parallel transport families within the network, and standardizing on for multiple parallel transport families within the network, and
one reduces OPEX and improves reliability. This evolution in the standardizing on one reduces operating expenses and improves
data-plane makes it highly unlikely that investing development cycles reliability. This evolution in the data plane makes it highly
into IPv4 support for GACP will have a longer term benefit or enough unlikely that investing development cycles into IPv4 support for GACP
critical short-term use-cases. Support for IPv6-only for GACP is will have a longer term benefit or enough critical short-term use
purely a strategic choice to focus on the known important long term cases. Support for IPv6-only for GACP is purely a strategic choice
goals. to focus on the known important long-term goals.
In other types of networks as well, we think that efforts to support In other types of networks as well, we think that efforts to support
autonomic networking is better spent in ensuring that one address autonomic networking are better spent in ensuring that one address
family will be supported so all use cases will long-term work with family will be supported so all use cases will work with it in the
it, instead of duplicating effort into IPv4. Especially because long term, instead of duplicating effort with IPv4. Also, auto-
auto-addressing for the GACP with IPv4 would be more complex than in addressing for the GACP with IPv4 would be more complex than in IPv6
IPv6 due to the IPv4 addressing space. due to the IPv4 addressing space.
4. Security Considerations 5. Security Considerations
In this section, we discuss only security considerations not covered In this section, we discuss only security considerations not covered
in the appropriate sub-sections of the solutions described. in the appropriate subsections of the solutions described.
Even though GACPs are meant to be isolated, explicit operator Even though GACPs are meant to be isolated, explicit operator
misconfiguration to connect to insecure OAM equipment and/or bugs in misconfiguration to connect to insecure OAM equipment and/or bugs in
GACP devices may cause leakage into places where it is not expected. GACP devices may cause leakage into places where it is not expected.
Mergers/Acquisitions and other complex network reconfigurations Mergers and acquisitions and other complex network reconfigurations
affecting the NOC are typical examples. affecting the NOC are typical examples.
GACP addresses are ULA addresses. Using these addresses also for NOC GACP addresses are ULAs. Using these addresses also for NOC devices,
devices as proposed in this document is not only necessary for above as proposed in this document, is not only necessary for the simple
explained simple routing functionality but it is also more secure routing functionality explained above, but it is also more secure
than global IPv6 addresses. ULA addresses are not routed in the than global IPv6 addresses. ULAs are not routed in the global
global Internet and will therefore be subject to more filtering even Internet and will therefore be subject to more filtering even in
in places where specific ULA addresses are being used. Packets are places where specific ULAs are being used. Packets are therefore
therefore less likely to leak to be successfully injected into the less likely to leak and less likely to be successfully injected into
isolated GACP environment. the isolated GACP environment.
The random nature of a ULA prefix provides strong protection against The random nature of a ULA prefix provides strong protection against
address collision even though there is no central assignment address collision even though there is no central assignment
authority. This is helped by the expectation that GACPs are never authority. This is helped by the expectation that GACPs will never
expected to connect all together, but only few GACPs may ever need to connect all together, and that only a few GACPs may ever need to
connect together, e.g. when mergers and acquisitions occur. connect together, e.g., when mergers and acquisitions occur.
Note that the GACP constraints demands that only packets from Note that the GACP constraints demand that only packets from
connected subnet prefixes are permitted from GACP connect interfaces, connected subnet prefixes are permitted from GACP connect interfaces,
limiting the scope of non-cryptographically secured transport to a limiting the scope of non-cryptographically secured transport to a
subnet within a NOC that instead has to rely on physical security subnet within a NOC that instead has to rely on physical security
(only connect trusted NOC devices to it). (i.e., only connect trusted NOC devices to it).
To help diagnose packets that unexpectedly leaked for example from To help diagnose packets that unexpectedly leaked, for example, from
another GACP (that was meant to be deployed separately), it can be another GACP (that was meant to be deployed separately), it can be
useful to voluntarily list your own the ULA GACP prefixes on some useful to voluntarily list your own ULA GACP prefixes on some sites
site(s) on the Internet and hope that other users of GACPs do the on the Internet and hope that other users of GACPs do the same so
same so that you can look up unknown ULA prefix packets seen in your that you can look up unknown ULA prefix packets seen in your network.
network. Note that this does not constitute registration. Note that this does not constitute registration.
<https://www.sixxs.net/tools/grh/ula/> was a site to list ULA
https://www.sixxs.net/tools/grh/ula/ was a site to list ULA prefixes prefixes, but it has not been open for new listings since mid-2017.
but it is not open for new listings anymore since the mid of 2017.
The authors are not aware of other active Internet sites to list ULA The authors are not aware of other active Internet sites to list ULA
use. use.
Note that there is a provision in [RFC4193] for non-locally assigned Note that there is a provision in [RFC4193] for address space that is
address space (L bit = 0), but there is no existing standardization not locally assigned (L bit = 0), but there is no existing
for this, so these ULA prefixes must not be used. standardization for this, so these ULA prefixes must not be used.
According to [RFC4193] section 4.4, PTR records for ULA addresses According to Section 4.4 of [RFC4193], PTR records for ULA addresses
should not be installed into the global DNS (no guaranteed should not be installed into the global DNS (no guaranteed
ownership). Hence also the need to rely on voluntary lists (and in ownership). Hence, there is also the need to rely on voluntary lists
prior paragraph) to make the use of an ULA prefix globally known. (as mentioned above) to make the use of an ULA prefix globally known.
Nevertheless, some legacy OAM applications running across the GACP Nevertheless, some legacy OAM applications running across the GACP
may rely on reverse DNS lookup for authentication of requests (e.g.: may rely on reverse DNS lookup for authentication of requests (e.g.,
TFTP for download of network firmware/config/software). Operators TFTP for download of network firmware, configuration, or software).
may therefore need to use a private DNS setup for the GACP ULA Therefore, operators may need to use a private DNS setup for the GACP
addresses. This is the same setup that would be necessary for using ULAs. This is the same setup that would be necessary for using RFC
RFC1918 addresses in DNS. See for example [RFC1918] section 5, last 1918 addresses in DNS. For example, see the last paragraph of
paragraph. In [RFC6950] section 4, these setups are discussed in Section 5 of [RFC1918]. In Section 4 of [RFC6950], these setups are
more detail. discussed in more detail.
Any current and future protocols must rely on secure end-to-end Any current and future protocols must rely on secure end-to-end
communications (TLS/DTLS) and identification and authentication via communications (TLS/DTLS) and identification and authentication via
the certificates assigned to both ends. This is enabled by the the certificates assigned to both ends. This is enabled by the
cryptographic credentials mechanisms of the GACP. cryptographic credential mechanisms of the GACP.
If DNS and especially reverse DNS are set up, then it should be set 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 up in an automated fashion when the GACP address for devices are
assigned. In the case of the ACP, DNS resource record creation can assigned. In the case of the ACP, DNS resource record creation can
be linked to the autonomic registrar backend so that the DNS and be linked to the autonomic registrar backend so that the DNS and
reverse DNS records are actually derived from the subject name reverse DNS records are actually derived from the subject name
elements of the ACP device certificates in the same way as the elements of the ACP device certificates in the same way as the
autonomic devices themselves will derive their ULA addresses from autonomic devices themselves will derive their ULAs from their
their certificates to ensure correct and consistent DNS entries. certificates to ensure correct and consistent DNS entries.
If an operator feels that reverse DNS records are beneficial to its If an operator feels that reverse DNS records are beneficial to its
own operations but that they should not be made available publically own operations, but that they should not be made available publicly
for "security" by concealment reasons, then the case of GACP DNS for "security" by concealment reasons, then GACP DNS entries are
entries is probably one of the least problematic use cases for split- probably one of the least problematic use cases for split DNS: The
DNS: The GACP DNS names are only needed for the NMS hosts intending GACP DNS names are only needed for the NMS hosts intending to use the
to use the GACP - but not network wide across the enterprise. GACP -- but not network wide across the enterprise.
5. IANA Considerations
This document requests no action by IANA.
6. Acknowledgements
This work originated from an Autonomic Networking project at cisco
Systems, which started in early 2010 including 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, Ravi
Kumar Vadapalli. The author 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 review.
7. Change log [RFC Editor: Please remove]
10: Added paragraph to multipath text to better summarize the
reason why to do this.
10: Mirja: reworded multipath text to remove instructive
description how the desired functionality would map to MPTCP
features, extensions or shim layers. Describe the desired
functionality now only as requirements. Expert WGs including but
not limited to MPTCP and future documents need to define best
design/spec option.
10: BrianC: Added requirement to 'MPTCP' section for end-to-end
encryption across data plane when connection is via GACP.
09: Mirja/Yoshifumi: reworded MPTCP policy rule examples,
stack->endpoint (agnostic to where policy is implemented).
08: IESG review fixes.
* Spell check.
* https://raw.githubusercontent.com/anima-wg/autonomic-control-
plane/01908364cfc7259009603bf2b261354b0cc26913/draft-ietf-
anima-stable-connectivity/draft-ietf-anima-stable-connectivity-
08.txt
* Eric Rescorla (comments):Typos, listing ULA on internet
benefits. Other comments from Eric where addressed via commits
for other reviewers already.
* https://raw.githubusercontent.com/anima-wg/autonomic-control-
plane/c02252710fbd7aea15aff550fb393eb36584658b/draft-ietf-
anima-stable-connectivity/draft-ietf-anima-stable-connectivity-
08.txt
* Mirja Kuehlewind (discuss) / Yoshifumi Nishida: Fixed and
Rewrote MPTCP text to be more explanatory, answering questions
raised in disucss.
* https://raw.githubusercontent.com/anima-wg/autonomic-control-
plane/14d5f9b66b8318bc160cee74ad152c0b926b4042/draft-ietf-
anima-stable-connectivity/draft-ietf-anima-stable-connectivity-
08.txt
* Matthew Miller/Alissa Cooper: syntactic nits.
* https://raw.githubusercontent.com/anima-wg/autonomic-control-
plane/9bff109281e8b3c22522c3144cbf0f13e5000498/draft-ietf-
anima-stable-connectivity/draft-ietf-anima-stable-connectivity-
08.txt
* Suresh Krishnan (comment): rewrote first paragraph of 2.1.4
(incomprehensible).
* https://raw.githubusercontent.com/anima-wg/autonomic-control-
plane/f2d8a85c2cc65ca7f823abac0f57d19c744f9b65/draft-ietf-
anima-stable-connectivity/draft-ietf-anima-stable-connectivity-
08.txt
* Alvaro Retana: Made references normative where the authors
think is is important to understand all or parts for the
mechanisms described in this document.
* Alvaro Retana: Clarified that the discussions in this document
are not specific to the ANI ACP, but instead rely primarily on
a set of design constraints for any type of autonomic inband
management network. Called this the GACP (generalized ACP).
Mayor add: explanation of those design constraints in section
1.3. Textual fixes ACP -> GACP throughout the document, but
without semantic changes.
* https://raw.githubusercontent.com/anima-wg/autonomic-control-
plane/d26df831da2953779c3b3ac41ec118cbbe43373e/draft-ietf-
anima-stable-connectivity/draft-ietf-anima-stable-connectivity-
08.txt
* Co-author organization fix.
07: Fixed ID nits.
06: changed "split-horizon" term to "private-DNS" and reworded the
paragraph about it.
05: Integrated fixes from Brian Carpenters review. See github
draft-ietf-anima-stable-connectivity/04-brian-carpenter-review-
reply.txt. Details on semantic/structural changes:
* Folded most comments back into draft-ietf-anima-autonomic-
control-plane-09 because this stable connectivity draft was
suggesting things that are better written out and standardized
in the ACP document.
* Section on simultaneous ACP and data-plane connectivity section
reduced/rewritten because of this.
* Re-emphasized security model of ACP - ACP-connect can not
arbitrarily extend ACP routing domain.
* Re-wrote much of NMS section to be less suggestive and more
descriptive, avoiding the term NAT and referring to relevant
RFCs (SIIT etc.).
* Main additional text in IPv4 section is about explaining how we
suggest to use EAM (Explicit Address Mapping) which actuall
would well work with the Zone and Vlong Addressing Sub-Schemes
of ACP.
* Moved, but not changed section of "why no IPv4 in ACP" before
IANA considerations to make structure of document more logical.
* Refined security considerations: explained how optional ULA
prefix listing on Internet is only for diagnostic purposes.
Explained how this is useful because DNS must not be used.
Explained how split horizon DNS can be used nevertheless.
04: Integrated fixes from Mohamed Boucadairs review (thorough
textual review).
03: Integrated fixes from thorough Shepherd review (Sheng Jiang).
01: Refresh timeout. Stable document, change in author
association.
01: Refresh timeout. Stable document, no changes.
00: Changed title/dates.
individual-02: Updated references.
individual-03: Modified ULA text to not suggest ULA-C as much
better anymore, but still mention it.
individual-02: Added explanation why no IPv4 for ACP.
individual-01: Added security section discussing the role of 6. IANA Considerations
address prefix selection and DNS for ACP. Title change to
emphasize focus on OAM. Expanded abstract.
individual-00: Initial version. This document has no IANA actions.
8. References 7. References
8.1. Normative References 7.1. Normative References
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets", and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<https://www.rfc-editor.org/info/rfc1918>. <https://www.rfc-editor.org/info/rfc1918>.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
November 2005, <https://www.rfc-editor.org/info/rfc4191>. November 2005, <https://www.rfc-editor.org/info/rfc4191>.
skipping to change at page 24, line 15 skipping to change at page 22, line 5
[RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address [RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address
Mappings for Stateless IP/ICMP Translation", RFC 7757, Mappings for Stateless IP/ICMP Translation", RFC 7757,
DOI 10.17487/RFC7757, February 2016, DOI 10.17487/RFC7757, February 2016,
<https://www.rfc-editor.org/info/rfc7757>. <https://www.rfc-editor.org/info/rfc7757>.
[RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont,
"IP/ICMP Translation Algorithm", RFC 7915, "IP/ICMP Translation Algorithm", RFC 7915,
DOI 10.17487/RFC7915, June 2016, DOI 10.17487/RFC7915, June 2016,
<https://www.rfc-editor.org/info/rfc7915>. <https://www.rfc-editor.org/info/rfc7915>.
8.2. Informative References 7.2. Informative References
[I-D.ietf-anima-autonomic-control-plane] [ACP] Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic
Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic Control Plane (ACP)", Work in Progress,
Control Plane (ACP)", draft-ietf-anima-autonomic-control- draft-ietf-anima-autonomic-control-plane-13,
plane-13 (work in progress), December 2017. December 2017.
[I-D.ietf-anima-bootstrapping-keyinfra] [BRSKI] Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
S., and K. Watsen, "Bootstrapping Remote Secure Key S., and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- Infrastructures (BRSKI)", Work in Progress,
keyinfra-09 (work in progress), October 2017. draft-ietf-anima-bootstrapping-keyinfra-15, April 2018.
[I-D.ietf-anima-grasp]
Bormann, C., Carpenter, B., and B. Liu, "A Generic
Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-
grasp-15 (work in progress), July 2017.
[I-D.ietf-anima-reference-model] [GRASP] Bormann, C., Carpenter, B., and B. Liu, "A Generic
Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., Autonomic Signaling Protocol (GRASP)", Work in Progress,
Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A draft-ietf-anima-grasp-15, July 2017.
Reference Model for Autonomic Networking", draft-ietf-
anima-reference-model-05 (work in progress), October 2017.
[IEEE802.1Q] [IEEE.802.1Q]
International Telecommunication Union, "802.1Q-2014 - IEEE IEEE, "IEEE Standard for Local and metropolitan area
Standard for Local and metropolitan area networks - networks -- Bridges and Bridged Networks",
Bridges and Bridged Networks", 2014. IEEE 802.1Q-2014, DOI 10.1109/ieeestd.2014.6991462,
December 2014, <http://ieeexplore.ieee.org/servlet/
opac?punumber=6991460>.
[ITUT] International Telecommunication Union, "Architecture and [ITUT_G7712]
specification of data communication network", ITU, "Architecture and specification of data communication
ITU-T Recommendation G.7712/Y.1703, Noevember 2001. network", ITU-T Recommendation G.7712/Y.1703, November
2001, <https://www.itu.int/rec/T-REC-G.7712/en>.
This is the earliest but superceeded version of the [REF_MODEL]
series. See "https://www.itu.int/rec/T-REC-G.7712/en" for Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L.,
current versions. and J. Nobre, "A Reference Model for Autonomic
Networking", Work in Progress,
draft-ietf-anima-reference-model-06, February 2018.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007, RFC 4960, DOI 10.17487/RFC4960, September 2007,
<https://www.rfc-editor.org/info/rfc4960>. <https://www.rfc-editor.org/info/rfc4960>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
skipping to change at page 25, line 47 skipping to change at page 23, line 34
[RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for
Routing Protocols (KARP) Design Guidelines", RFC 6518, Routing Protocols (KARP) Design Guidelines", RFC 6518,
DOI 10.17487/RFC6518, February 2012, DOI 10.17487/RFC6518, February 2012,
<https://www.rfc-editor.org/info/rfc6518>. <https://www.rfc-editor.org/info/rfc6518>.
[RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, [RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba,
"Architectural Considerations on Application Features in "Architectural Considerations on Application Features in
the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013, the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013,
<https://www.rfc-editor.org/info/rfc6950>. <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.
Authors' Addresses Authors' Addresses
Toerless Eckert (editor) Toerless Eckert (editor)
Futurewei Technologies Inc. Huawei USA
2330 Central Expy 2330 Central Expy
Santa Clara 95050 Santa Clara 95050
USA United States of America
Email: tte+ietf@cs.fau.de Email: tte+ietf@cs.fau.de, toerless.eckert@huawei.com
Michael H. Behringer Michael H. Behringer
Email: michael.h.behringer@gmail.com Email: michael.h.behringer@gmail.com
 End of changes. 160 change blocks. 
723 lines changed or deleted 594 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/