ANIMA
Internet Engineering Task Force (IETF)                    T. Eckert, Ed.
Internet-Draft
Request for Comments: 8368                                        Huawei
Intended status:
Category: Informational                                     M. Behringer
Expires: August 9, 2018                                 February 5,
ISSN: 2070-1721                                                 May 2018

      Using an Autonomic Control Plane for Stable Connectivity of
       Network OAM
                draft-ietf-anima-stable-connectivity-10 Operations, Administration, and Maintenance (OAM)

Abstract

   OAM (Operations, Administration

   Operations, Administration, and Maintenance - (OAM), as per BCP161,
   (RFC6291) processes BCP 161,
   for data networks are is often subject to the problem of circular
   dependencies when relying on connectivity provided by the network to
   be managed for the OAM purposes.

   Provisioning while bringing up devices and networks tends to be more
   difficult to automate than service provisioning later on, changes on.  Changes in
   core network functions impacting reachability cannot be automated
   because of ongoing connectivity requirements for the OAM equipment
   itself, and widely used OAM protocols are not secure enough to be
   carried across the network without security concerns.

   This document describes how to integrate OAM processes with an
   autonomic control plane in order to provide stable and secure
   connectivity for those OAM processes.  This connectivity is not
   subject to the aforementioned circular dependencies.

Status of This Memo

   This Internet-Draft document is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working  It has been approved for publication by the Internet
   Engineering Steering Group (IESG).  Not all documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts approved by the
   IESG are draft documents valid candidates for a maximum any level of Internet Standard; see Section 2
   of RFC 7841.

   Information about the current status of six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 9, 2018.
   https://www.rfc-editor.org/info/rfc8368.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2   3
     1.1.  Self-dependent  Self-Dependent OAM Connectivity . . . . . . . . . . . . .   3
     1.2.  Data Communication Networks (DCNs)  . . . . . . . . . . .   3
     1.3.  Leveraging a generalized autonomic control plane Generalized Autonomic Control Plane  . . . .   4
   2.  GACP Requirements . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Solutions . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.1.   6
     3.1.  Stable Connectivity for Centralized OAM . . . . . . . . .   5
       2.1.1.   6
       3.1.1.  Simple Connectivity for Non-GACP capable Non-GACP-Capable
               NMS Hosts .   6
       2.1.2. . . . . . . . . . . . . . . . . . . . . .   7
       3.1.2.  Challenges and Limitation Limitations of Simple Connectivity . .   7
       2.1.3.   8
       3.1.3.  Simultaneous GACP and data-plane Data-Plane Connectivity . . . .   8
       2.1.4.  IPv4-only   9
       3.1.4.  IPv4-Only NMS Hosts . . . . . . . . . . . . . . . . .   9
       2.1.5.  10
       3.1.5.  Path Selection Policies . . . . . . . . . . . . . . .  12
       2.1.6.
       3.1.6.  Autonomic NOC Device/Applications . . . . . . . . . .  15
       2.1.7.  16
       3.1.7.  Encryption of data-plane connections Data-Plane Connections  . . . . . . . .  15
       2.1.8.  Long Term  16
       3.1.8.  Long-Term Direction of the Solution . . . . . . . . .  16
     2.2.  17
     3.2.  Stable Connectivity for Distributed       Network/OAM . . . . .  17
   3.  18
   4.  Architectural Considerations  . . . . . . . . . . . . . . . .  17
     3.1.  18
     4.1.  No IPv4 for GACP  . . . . . . . . . . . . . . . . . . . .  17
   4.  18
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
   5.  19
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
   6.  Acknowledgements  . . . . . . . .
   7.  References  . . . . . . . . . . . . . .  20
   7.  Change log [RFC Editor: Please remove] . . . . . . . . . . .  20
   8.  21
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  21
     7.2.  Informative References  . . . . . . .  23
     8.1.  Normative References  . . . . . . . . . . .  22
   Acknowledgements  . . . . . . .  23
     8.2.  Informative References . . . . . . . . . . . . . . . . .  24  23
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  25  24

1.  Introduction

1.1.  Self-dependent  Self-Dependent OAM Connectivity

   OAM (Operations, Administration

   Operations, Administration, and Maintenance - (OAM), as per BCP161,
   [RFC6291]) BCP 161
   [RFC6291], for data networks is often subject to the problem of
   circular dependencies when relying on the connectivity service
   provided by the network to be managed.  OAM can easily but
   unintentionally break the connectivity required for its own
   operations.  Avoiding these problems can lead to complexity in OAM.
   This document describes this problem and how to use an autonomic
   control plane to solve it without further OAM complexity: complexity.

   The ability to perform OAM on a network device requires first the
   execution of OAM necessary to create network connectivity to that
   device in all intervening devices.  This typically leads to
   sequential, 'expanding
   sequential "expanding ring configuration' configuration" from a NOC (Network Network Operations Center).
   Center (NOC).  It also leads to tight dependencies between
   provisioning tools and security enrollment of devices.  Any process
   that wants to enroll multiple devices along a newly deployed network
   topology needs to tightly interlock with the provisioning process
   that creates connectivity before the enrollment can move on to the
   next device.

   When

   Likewise, when performing change operations on a network, it likewise is
   necessary to understand at any step of that process that there is no
   interruption of connectivity that could lead to removal of
   connectivity to remote devices.  This includes especially change
   provisioning of routing, forwarding, security security, and addressing
   policies in the network that often occur through mergers and
   acquisitions, the introduction of IPv6 IPv6, or other mayor re-hauls in major overhauls of
   the infrastructure design.  Examples include change of an IGP or areas, PA (Provider
   Aggregatable) to PI (Provider Independent)
   area, change from Provider Aggregatable (PA) to Provider Independent
   (PI) addressing, or systematic topology changes (such as L2 Layer 2 to L3
   Layer 3 changes).

   All these circular dependencies make OAM complex and potentially
   fragile.  When automation is being used, for example used (for example, through
   provisioning systems, systems), this complexity extends into that automation
   software.

1.2.  Data Communication Networks (DCNs)

   In the late 1990s and early 2000, IP networks became the method of
   choice to build separate OAM networks for the communications
   infrastructure within Network Providers.  This concept was
   standardized in ITU-T G.7712/Y.1703 [ITUT] [ITUT_G7712] and called "Data
   Communications Networks" (DCN). (DCNs).  These were (and still are)
   physically separate IP(/MPLS) IP or IP/MPLS networks that provide access to OAM
   interfaces of all equipment that had to be managed, from PSTN (Public Public
   Switched Telephone Network) Network (PSTN) switches over optical equipment to
   nowadays Ethernet and IP/MPLS production network equipment.

   Such DCN DCNs provide stable connectivity not subject to the
   aforementioned problems because they are a separate network entirely,
   so change configuration of the production IP network is done via the
   DCN but never affects the DCN configuration.  Of course, this
   approach comes at a cost of buying and operating a separate network network,
   and this cost is not feasible for many providers, providers -- most notably notably,
   smaller providers, most
   enterprises enterprises, and typical IoT networks (Internet Internet of Things). Things
   (IoT) networks.

1.3.  Leveraging a generalized autonomic control plane Generalized Autonomic Control Plane

   One of the goals of the IETF ANIMA (Autonomic Networking Integrated
   Model and Approach ) working group Approach) Working Group is the specification of a secure
   and automatically built inband in-band management plane that provides similar stable
   connectivity as similar to a DCN, but without having to build a separate
   DCN.  It is clear that such 'in-band' an "in-band" approach can never achieve fully
   achieve the same level of separation, but the goal is to get as close
   to it as possible.

   This goal of this document is to discuss discusses how such an inband in-band management plane can be
   used to support the DCN-like OAM use-case, use case, how to leverage its stable connectivity
   connectivity, and details what the options of are for deploying it incrementally -
   in the short and long term.

   The evolving ANIMA working groups Working Group's evolving specification
   [I-D.ietf-anima-autonomic-control-plane] ) [ACP] calls this inband in-
   band management plane the "Autonomic Control Plane" (ACP).  The
   discussions in this document are not depending dependent on the specification
   of that ACP, but only on a set of high level high-level constraints listed
   below, which were decided upon early on in during the work for on the ACP.  Unless
   Except when being specific about details of the ACP, this document
   uses the term "Generalized ACP" (GACP) and is applicable to any
   designs that meet those high level
   constraints.  For example - but not limited to - the high-level constraints -- for example, the
   variations of the ACP protocol choices.

2.  GACP Requirements

   The high level high-level constraints of a GACP assumed and discussed in this
   document are as follows:

   VRF Isolation: isolation:  The GACP is a virtual network ("VRF") (Virtual Routing and
      Forwarding (VRF)) across network
      devices - devices; its routing and
      forwarding are separate from other routing and forwarding in the
      network devices.  Non-GACP routing/
      forwarding routing/forwarding is called the "data-plane".

   IPv6 only "data
      plane".

   IPv6-only addressing:  The GACP provides only IPv6 reachability.  It
      uses ULA addresses ([RFC4193]) Unique Local Addresses (ULAs) [RFC4193] that are routed in a location
      independent fashion
      location-independent fashion, for example example, through per network device a subnet
      prefixes.  Automatic prefix
      for each network device.  Therefore, automatic addressing in the
      GACP is therefore simple & and stable: it does not require allocation by
      address registries, addresses are identifiers, they do not change
      when devices move, and no engineering of the address space to the
      network topology is necessary.

   NOC connectivity:  NOC equipment (controlling OAM operations) either
      has access to the GACP directly or has an IP subnet connection to
      a GACP-edge GACP edge device.

   Closed Group Security:  GACP devices have cryptographic credentials
      to mutually authenticate each other as members of a GACP.  Traffic
      across the GACP is authenticated with these credentials and then
      encrypted.

   GACP connect (interface):  The only traffic permitted in & and out of
      the GACP that is not authenticated by these GACP cryptographic
      credentials is through explicit configuration for the traffic
      from/to the aforementioned non-GACP NOC equipment with subnet
      connections to a GACP-edge GACP edge device (as a transition method).

   The GACP must be built to be autonomic and its function must not be
   disruptable
   able to be disrupted by operator or automated (NMS/SDN) configuration/
   provisioning actions.  These actions (i.e., Network Management System (NMS) or
   Software-Defined Networking (SDN)).  Those actions are allowed to only
   impact only the "data-
   plane". data plane.  This aspect is document does not currently covered in this document.
   Instead, cover those
   aspects; instead, it focusses focuses on the impact of the above constraints:
   IPv6 only, dual connectivity connectivity, and security.

2.

3.  Solutions

2.1.

3.1.  Stable Connectivity for Centralized OAM

   The ANI is the "Autonomic Autonomic Networking Infrastructure" Infrastructure consisting of
   secure zero touch Bootstrap zero-touch bootstrap (BRSKI -
   [I-D.ietf-anima-bootstrapping-keyinfra]), [BRSKI]), the GeneRic Autonomic
   Signaling Protocol (GRASP - [I-D.ietf-anima-grasp]), [GRASP]), and Autonomic Control Plane (ACP - [I-D.ietf-anima-autonomic-control-plane]).
   [ACP]).  Refer to
   [I-D.ietf-anima-reference-model] the reference model [REF_MODEL] for an overview of
   the ANI and how its components interact and [RFC7575] for concepts
   and terminology of ANI and autonomic networks.

   This section describes stable connectivity for centralized OAM via
   the GACP, for example example, via the ACP with or without a complete ANI,
   starting by what with the option that we expect to be the most easy to deploy short-term
   option.
   in the short term.  It then describes limitation limitations and challenges of
   that approach and their solutions/workarounds to finish the corresponding solutions and workarounds; it
   finishes with the preferred target option of autonomic NOC devices in
   Section 2.1.6. 3.1.6.

   This order was chosen because it helps to explain how simple initial
   use of a GACP can be, be and how difficult workarounds can become (and
   therefore what to avoid), and finally because avoid).  Also, one very promising long-term
   solution alternative is exactly like the most easy short-
   term solution short-term solution, only
   virtualized and automated.

   In the most common case, OAM will be performed by one or more
   applications running on a variety of centralized NOC systems that
   communicate with network devices.  We describe differently advanced  This document describes approaches
   to leverage a GACP for stable connectivity.  There is a
   wide range of options, some connectivity, from simple to complex,
   depending on the capabilities and limitations of which are simple, some more complex. the equipment used.

   Three stages can be considered:

   o  There are simple options described in sections Section 2.1.1 Sections 3.1.1 through Section 2.1.3 3.1.3
      that we consider to be good starting points to operationalize the
      use of a GACP for stable connectivity today.  These options
      require only network and OAN/NOC OAM/NOC device configuration.

   o  The are workarounds to connect a GACP to non-IPv6 capable non-IPv6-capable NOC
      devices through the use of IPv4/IPv6 NAT (Network Address
      Translation) as described in section Section 2.1.4. 3.1.4.  These workarounds are
      not recommended but recommended; however, if such non-IPv6 capable non-IPv6-capable NOC devices need to
      be used longer term, then this is the workarounds are the only option way to
      connect them to a GACP.

   o  Near  Options for the near to long term options can provide all the desired
      operational,
      zero touch zero-touch, and security benefits of an autonomic
      network, but a range of details for this still have to be worked out
      out, and development work on NOC/OAM equipment is necessary.
      These options are discussed in sections Section 2.1.5 Sections 3.1.5 through Section 2.1.8.

2.1.1. 3.1.8.

3.1.1.  Simple Connectivity for Non-GACP capable Non-GACP-Capable NMS Hosts

   In the most simple candidate deployment case, the GACP extends all
   the way into the NOC via one or more "GACP-edge-devices". GACP edge devices.  See also
   section
   Section 6.1 of [I-D.ietf-anima-autonomic-control-plane]. [ACP].  These devices "leak" the (otherwise encrypted)
   GACP natively to NMS hosts.  They act as the default routers to those
   NMS hosts and provide them with IPv6 connectivity into the GACP.  NMS
   hosts with this setup need to support IPv6 (see e.g. (e.g., see [RFC6434]) but
   require no other modifications to leverage the GACP.

   Note that even though the GACP only uses IPv6, it can of course
   support OAM for any type of network deployment as long as the network
   devices support the GACP: The data-plane data plane can be IPv4 only, dual-stack dual
   stack, or IPv6 only.  It is always separate from the GACP, therefore GACP; therefore,
   there is no dependency between the GACP and the IP version(s) used in
   the
   data-plane. data plane.

   This setup is sufficient for troubleshooting mechanisms such as SSH
   into network devices, NMS that performs SNMP read operations for
   status checking, software downloads into onto autonomic devices,
   provisioning of devices via NETCONF NETCONF, and so on.  In conjunction with
   otherwise unmodified OAM via separate NMS hosts it hosts, this setup can
   provide a good subset of the stable connectivity goals.  The
   limitations of this approach are discussed in the next section.

   Because the GACP provides 'only' "only" for IPv6 connectivity, and because
   addressing provided by the GACP does not include any topological
   addressing structure that operations in a NOC often relies on to recognize where
   devices are on the network, it is likely highly desirable to set up DNS (Domain
   the Domain Name System - (DNS; see [RFC1034]) so that the GACP IPv6
   addresses of autonomic devices are known via domain names that
   include the desired structure.  For example, if DNS in the network was
   were set up with names for network devices as
   devicename.noc.example.com, and if the well-known structure of the data-
   plane
   data-plane IPv4 addresses address space was were used by operators to infer the
   region where a device is located in, located, then the GACP address of that
   device could be set up as devicename_<region>.acp.noc.example.com,
   and devicename.acp.noc.example.com could be a CNAME to
   devicename_<region>.acp.noc.example.com.  Note that many networks
   already use names for network equipment where topological information
   is included, even without a GACP.

2.1.2.

3.1.2.  Challenges and Limitation Limitations of Simple Connectivity

   This simple connectivity of non-autonomic NMS hosts suffers from a
   range of challenges (that is, operators may not be able to do it this
   way) or and limitations (that is, operator operators cannot achieve desired goals
   with this setup).  The following list summarizes these challenges and
   limitations.  The
   limitations, and the following sections describe additional
   mechanisms to overcome them.

   Note that these challenges and limitations exist because GACP is
   primarily designed to support distributed ASA (Autonomic Autonomic Service
   Agent, Agent
   (ASA), a piece of autonomic software) software, in the most lightweight
   fashion, but
   fashion.  GACP is not mandatorily require required to support for the additional mechanisms to best support
   needed for centralized NOC operations. systems.  It is this document that
   describes additional (short term) (short-term) workarounds and (long
   term) (long-term)
   extensions.

   1.  (Limitation) NMS hosts cannot directly probe whether the desired
       so called 'data-plane'
       so-called "data-plane" network connectivity works because they do
       not directly have access to it.  This problem is similar to
       probing connectivity for other services (such as VPN services)
       that they do not have direct access to, so the NOC may already
       employ appropriate mechanisms to deal with this issue (probing
       proxies).  See Section 2.1.3 3.1.3 for candidate solutions.

   2.  (Challenge) NMS hosts need to support IPv6 which IPv6, and this often is
       still not possible in enterprise networks.  See Section 2.1.4 3.1.4 for
       some workarounds.

   3.  (Limitation) Performance of the GACP may be limited versus normal
       'data-plane'
       "data-plane" connectivity.  The setup of the GACP will often
       support only non-hardware accelerated forwarding. forwarding that is not hardware accelerated.
       Running a large amount of traffic through the GACP, especially
       for tasks where it is not necessary necessary, will reduce its performance/ performance
       and effectiveness for those operations where it is necessary or
       highly desirable.  See Section 2.1.5 3.1.5 for candidate solutions.

   4.  (Limitation) Security of the GACP is reduced by exposing the GACP
       natively (and unencrypted) into in a subnet in the NOC where the NOC
       devices are attached to it.  See Section 2.1.7 3.1.7 for candidate
       solutions.

   These four problems can be tackled independently of each other by
   solution improvements.  Combining some of these solutions improvements together
   can lead towards a candidate long term long-term solution.

2.1.3.

3.1.3.  Simultaneous GACP and data-plane Data-Plane Connectivity

   Simultaneous connectivity to both the GACP and data-plane data plane can be
   achieved in a variety of ways.  If the data-plane data plane is IPv4-only, IPv4 only, then
   any method for dual-stack attachment of the NOC device/application
   will suffice: IPv6 connectivity from the NOC provides access via the GACP,
   GACP; IPv4 will provide provides access via the data-plane.  If data plane.  If, as explained
   above in the simple case, an autonomic device supports native
   attachment to the GACP, and the existing NOC setup is IPv4 only, then
   it could be sufficient to attach the GACP device(s) as the IPv6
   default router to the NOC subnet and keep the existing IPv4 default
   router setup unchanged.

   If the data-plane data plane of the network is also supporting IPv6, then the
   most compatible setup for NOC devices is to have two IPv6 interfaces.
   One interfaces
   -- one virtual ((e.g. (e.g., via IEEE 802.1Q [IEEE802.1Q]) [IEEE.802.1Q]) or physical
   interface connecting to a data-plane subnet, and another connecting
   into an a GACP connect subnet.  See section Section 8.1 of
   [I-D.ietf-anima-autonomic-control-plane] [ACP] for more
   details.  That document also specifies how the a NOC devices device can receive auto
   configured
   autoconfigured addressing and routes towards the ACP connect subnet
   if it supports default address selection as specified in [RFC6724]
   and default router preferences as specified in [RFC4191].

   Configuring a second interface on a NOC host may be impossible or be
   seen as undesired complexity.  In that case case, the GACP edge device
   needs to provide support for a "Combined "combined ACP and data-plane
   interface" as also described in section Section 8.1 of
   [I-D.ietf-anima-autonomic-control-plane]. [ACP].  This setup may not
   work with auto configuration autoconfiguration and all NOC host network stacks due to
   limitations in those network stacks.  They need to be able to perform
   RFC6724
   Rule 5.5 of [RFC6724] regarding source address selection rule 5.5 selection, including
   caching of next-
   hop next-hop information.

   For security reasons, it is not considered appropriate to connect a
   non-GACP router to a GACP connect interface.  The reason is that the
   GACP is a secured network domain domain, and all NOC devices connecting via
   GACP connect interfaces are also part of that secure domain - the domain.  The
   main difference is that the physical link links between the GACP edge
   device and the NOC devices is are not authenticated/encrypted and authenticated or encrypted and,
   therefore, needs need to be physically secured.  If the secure GACP was
   extendable via untrusted routers routers, then it would be a lot more
   difficult to verify the secure domain assertion.  Therefore  Therefore, the GACP
   edge devices are not supposed to redistribute routes from non-GACP
   routers into the GACP.

2.1.4.  IPv4-only

3.1.4.  IPv4-Only NMS Hosts

   One architectural expectation for the GACP as described in
   Section 1.3 is that all devices that want to use the GACP do (including
   NMS hosts) support IPv6.  Including NMS hosts.  Note that this expectation does not imply
   any requirements against for the data-plane, data plane, especially no need to
   support it does not imply
   that IPv6 must be supported in it.  The data-plane data plane could be IPv4
   only, IPv6 only, dual stack stack, or it may not need to have any IP host
   stack on the network devices.

   The implication of this architectural decision is the potential need
   for short-term workarounds when the operational practices in a
   network do not yet meet these target expectations.  This section
   explains when and why these workarounds may be operationally
   necessary and describes them.  However, the long term long-term goal is to
   upgrade all NMS hosts to native IPv6, so the workarounds described in
   this section should not be considered permanent.

   Most network equipment today supports IPv6 IPv6, but it is by very far not from
   being ubiquitously supported in NOC backend solutions (HW/SW), especially
   not (hardware or
   software) or in the product space for enterprises.  Even when it is
   supported, there are often additional limitations or issues using it
   in a dual
   stack setup dual-stack setup, or the operator mandates for simplicity (for simplicity)
   single stack for all operations.  For these reasons reasons, an IPv4 only IPv4-only
   management plane is still required and common practice in many
   enterprises.  Without the desire to leverage the GACP, this required
   and common practice is not a problem for those enterprises even when
   they run dual stack in the network.  We discuss these workarounds
   here because it is a short
   term short-term deployment challenge specific to the
   operations of a GACP.

   To connect IPv4 only management plane IPv4-only management-plane devices/applications with a
   GACP, some form of IP/ICMP translation of packets IPv4<->IPv6 between IPv4 and
   IPv6 is necessary.  The basic mechanisms for this are defined in SIIT
   ([RFC7915]). [RFC7915],
   which describes the Stateless IP/ICMP Translation Algorithm (SIIT).
   There are multiple solutions using this mechanism.  To understand the
   possible solutions, we consider the requirements:

   1.  NMS hosts need to be able to initiate connections to any GACP
       device for management purposes.  Examples include provisioning
       via Netconf/(SSH), NETCONF, SNMP poll operations operations, or just diagnostics via SSH
       connections from operators.  Every GACP device/function that
       needs to be reachable from NMS hosts needs to have a separate
       IPv4 address.

   2.  GACP devices need to be able to initiate connections to NMS hosts
       hosts, for example example, to initiate NTP or radius/diameter RADIUS/Diameter
       connections, send syslog or SNMP trap trap, or initiate Netconf NETCONF Call
       Home connections after bootstrap.  Every NMS host needs to have a
       separate IPv6 address reachable from the GACP.  When connections a connection
       from a GACP
       devices are device is made to an NMS hosts, host, the IPv4 source
       address of these
       connections as the connection (as seen by the NMS Host host) must also be
       unique per GACP device and must be the same address as in (1) to
       maintain the same addressing simplicity as in similar to a native IPv4
       deployment.  For example in syslog, the source-IP source IP address of a
       logging device is used to identify it, and if the device shows
       problems, an operator might want to SSH into the device to
       diagnose it.

   Because of these requirements, the necessary and sufficient set of
   solutions are those that provide 1:1 mapping of IPv6 GACP addresses
   into IPv4 space and 1:1 mapping of IPv4 NMS host space into IPv6 (for
   use in the GACP).  This means that stateless SIIT based SIIT-based solutions are
   sufficient and preferred.

   Note that GACP devices may use multiple IPv6 addresses in the GACP.
   For example, [I-D.ietf-anima-autonomic-control-plane] section Section 6.10 of [ACP] defines multiple useful addressing
   sub-schemes supporting this option.  All those addresses may then
   need to be reachable through
   the IPv6/IPv4 address translation.

   The need to allocate for every GACP device one or multiple IPv4
   addresses should not be a problem if - -- as we assume - -- the NMS hosts
   can use private IPv4 address space ([RFC1918]).  Nevertheless  Nevertheless, even
   with RFC1918 private IPv4 address space space, it is important that the GACP IPv6
   addresses can efficiently be mapped efficiently into IPv4 address space without
   too much waste.

   The currently

   Currently, the most flexible mapping scheme to achieve this is
   [RFC7757] because it allows configured IPv4 <-> IPv6 prefix mapping.
   Assume the GACP uses the ACP "Zone Addressing" Zone Addressing Sub-Scheme and there are
   3 registrars.  In the ACP Zone Addressing Sub-Scheme, there is for each registrar
   registrar, there is a constant /112 prefix for which in RFC7757 an EAM
   (Explicit Explicit
   Address Mapping) into Mapping (EAM), as defined in RFC 7757, to a /16 (e.g.: RFC1918) prefix into
   IPv4 can be configured.
   configured (e.g., in the private IPv4 address space described in
   [RFC1918]).  Within the registrars registrar's /112 prefix, Device-
   Numbers Device-Numbers for
   devices are sequentially assigned: with V-bit the V bit (Virtualization
   bit) effectively two numbers are assigned per GACP device.  This also
   means that if IPv4 address space is even more constrained, and it is
   known that a registrar will never need the full /15 extent of Device-Numbers, Device-
   Numbers, then a prefix longer than a /112 prefix can be configured into the
   EAM in order to use less IPv4 space.

   When using the ACP "Vlong Addressing" Vlong Addressing Sub-Scheme, it is unlikely that
   one wants or need needs to translate the full /8 or /16 bits of addressing
   space per GACP device into IPv4.  In this case, the EAM rules of
   dropping trailing bits can be used to map only N bits of the V-bits V bits
   into IPv4.  This  However, this does imply though that only V-addresses addresses that differ
   in those high-order N V-bits V bits can be distinguished on the IPv4 side.

   Likewise, the IPv4 address space used for NMS hosts can easily be
   mapped into an address prefix assigned to a GACP connect interface.

   A full specification of a solution to perform SIIT in conjunction
   with GACP connect following the considerations below is outside the
   scope of this document.

   To be in compliance with security expectations, SIIT has to happen on
   the GACP edge device itself so that GACP security considerations can
   be taken into account.  E.g.: that IPv4 only  For example, IPv4-only NMS hosts can be dealt
   with exactly like IPv6 hosts connected to a GACP connect interface.

   Note that prior solutions such as NAT64 ([RFC6146]) may equally be
   useable to translate between GACP IPv6 address space and NMS Hosts hosts'
   IPv4 address space, and that as workarounds space.  As a workaround, this can also be done on
   non non-
   GACP Edge Devices connected to a GACP connect interface.  The details
   vary depending on implementation because the options to configure
   address mappings vary widely.  Outside of EAM, there are no
   standardized solutions that allow for mapping of prefixes, so it will
   most likely be necessary to explicitly map every individual (/128)
   GACP device address to an IPv4 address.  Such an approach should use
   automation/scripting where these address translation entries are
   created dynamically whenever a GACP device is enrolled or first
   connected to the GACP network.

   Overall, the use of

   The NAT is especially subject to the ROI (Return On
   Investment) considerations, but the methods described here may are not specific to a GACP.  Instead,
   they are similar to what would be
   too different from the same problems encountered totally independent
   of GACP necessary when some parts of the a
   network are to introduce IPv6 only support IPv6, but NMS
   hosts are the NOC equipment does not (yet) upgradeable.

2.1.5. support
   IPv6.  Whether it is more appropriate to wait until the NOC equipment
   supports IPv6 or to use NAT beforehand depends in large part on how
   long the former will take and how easy the latter will be when using
   products that support the NAT options described to operationalize the
   above recommendations.

3.1.5.  Path Selection Policies

   As mentioned above, a GACP is not expected to have high performance
   because its primary goal is connectivity and security, and for security.  For existing
   network device platforms platforms, this often means that it is a lot more
   effort to implement that additional connectivity with hardware
   acceleration than without - -- especially because of the desire to
   support full encryption across the GACP to achieve the desired
   security.

   Some of these issues may go away in the future with further adoption
   of a GACP and network device designs that better tender tend to the needs of
   a separate OAM plane, but it is wise to plan for even long-term designs of
   the solution that does do NOT depend on high-performance high performance of the GACP.
   This is the opposite to of the expectation expectations that future NMS hosts will
   have IPv6, so IPv6 and that any considerations for IPv4/NAT in this solution
   are temporary.

   To solve the expected performance limitations of the GACP, we do
   expect to have the above describe dual-connectivity above-described dual connectivity via both GACP
   and
   data-plane data plane between NOC application devices and devices with GACP.
   The GACP connectivity is expected to always be there (as soon as a
   device is enrolled), but the data-plane connectivity is only present
   under normal operations but and will not be present during e.g. during, e.g., early
   stages of device bootstrap, failures, provisioning mistakes mistakes, or during
   network configuration changes.

   The desired policy is therefore as follows: In the absence of further
   security considerations (see below), traffic between NMS hosts and
   GACP devices should prefer data-plane connectivity and resort only to
   using the GACP when necessary, unless it necessary.  The exception is an operation known
   to be
   so much tied to covered by the use cases where the GACP is necessary necessary, so that
   it makes no sense to try using the data-plane. data plane.  An example are is an SSH connections
   connection from the NOC into to a network device to troubleshoot network
   connectivity.  This could easily always rely on the GACP.  Likewise,
   if an NMS host is known to transmit large amounts of data, and it
   uses the GACP, then its performance need data rate needs to be controlled so that it
   will not overload the GACP performance. path.  Typical examples of this are
   software downloads.

   There is a wide range of methods to build up these policies.  We
   describe a few: few below.

   Ideally, a NOC system would learn and keep track of all addresses of
   a device (GACP and the various data-plane addresses).  Every action
   of the NOC system would indicate via a "path-policy" what type of
   connection it needs (e.g. (e.g., only data-plane, GACP-only, GACP only, default to
   data-plane,
   data plane, fallback to GACP,...). GACP, etc.).  A connection policy manager
   would then build connection to the target using the right
   address(es).  Shorter term, a common practice is to identify
   different paths to a device via different names (e.g. (e.g., loopback vs.
   interface addresses).  This approach can be expanded to GACP uses,
   whether it uses NOC
   system local names the DNS or DNS.  We names local to the NOC system.  Below, we
   describe example schemes using DNS: DNS.

   DNS can be used to set up names for the same network devices but with
   different addresses assigned:

   o  One name (name.noc.example.com) with only the data-plane
      address(es) (IPv4 and/or IPv6) to be used for probing connectivity
      or performing routine software downloads that may stall/fail when
      there are connectivity issues.

   o  One name (name-
   acp.noc.example.com) (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 (name-both.noc.example.com).
      addresses.

   Traffic policing and/or shaping at the GACP edge in the NOC can be
   used to throttle applications such as software download into the
   GACP.

   Using different names mapping that map to different (subset of) addresses (or subsets of
   addresses) can be difficult to set up and maintain, especially also
   because data-
   plane data-plane addresses may change due to reconfiguration or
   relocation of devices.  The name based name-based approach alone can also not well cannot strongly
   support policies for existing applications and long-lived flows to
   automatically switch between the ACP and data-plane data plane in the face of data-
   plane
   data-plane failure and recovery.  A solution would be GACP node host transport
   stacks supporting on GACP nodes that support the following requirements:

   1.  Only the GACP addresses of the responder must be required by the
       initiator for the initial setup of a connection/flow across the
       GACP.

   2.  Responder and Initiator must be able to exchange their data-plane
       addresses through the GACP, and then - -- if needed by policy - --
       build an additional flow across the data-plane. data plane.

   3.  For unmodified application, the following policies should be
       configurable on at least a per-application basis for its TCP
       connections with GACP peers:

       Fallback (to GACP):  An additional data-plane flow is built and
          used exclusively to send data whenever the data-plane data plane is
          operational.  When it can not the additional flow cannot be built during
          connection setup or when it fails later, traffic is sent
          across the GACP flow.  This could be a default-policy default policy for most
          OAM applications using the GACP.

       >Suspend/Fail:

       Suspend/Fail:  Like the Fallback policy, except that traffic will
          not use the GACP flow but flow; instead, it will be suspended until a data-
          plane
          data-plane flow is operational or until a policy configurable policy-configurable
          timeout indicates a connection failure to the application.
          This policy would be appropriate for large volume background/
          scavenger class large-volume background
          or scavenger-class OAM application/connections applications such as firmware downloads
          or telemetry/diagnostic uploads - which -- applications that would
          otherwise easily overrun performance limited performance-limited GACP
          implementations.

       >GACP

       GACP (only):  No additional data-plane flow is built, traffic is
          only sent via the GACP flow.  This can just be a TCP
          connection.  This policy would be most appropriate for OAM
          operations known to change the data plane in a way that could
          impact (at least temporarily) connectivity through it. it (at least temporarily).

   4.  In the presence of responders or initiators not supporting these
       host stack functions, the Fallback and GACP policies must result
       in a TCP connection across the GACP.  For Suspend/Fail, presence
       of TCP-only peers should result in failure during connection
       setup.

   5.  In case of Fallback and Suspend/Fail, a failed data-plane
       connection should automatically be rebuilt when the data-plane data plane
       recovers, including the case that when the data-plane address of one
       (or both) side(s) side or
       both sides may have changed - -- for example example, because of
       reconfiguration or device repositioning.

   6.  Additional data-plane flows created by these host transport stack
       functions must be end-to-end authenticated by it these host
       transport stack functions with the GACP domain credentials and
       encrypted.  This maintains the expectation that connections from
       GACP addresses to GACP addresses are
       authenticated/encrypted. authenticated and encrypted.
       This may be skipped if the application already provides for end-to-end end-
       to-end encryption.

   7.  For enhanced applications, the host stack may support application
       control to select the policy on a per-connection basis, or even
       more explicit control for building of the flows and which flow
       should pass traffic.

   Protocols like MPTCP (Multipath Multipath TCP -see (MPTCP; see [RFC6824]) and SCTP
   ([RFC4960]) the Stream
   Control Transmission Protocol (SCTP; see [RFC4960]) can already
   support part of these requirements.  MPTCP  MPTCP, for example example, supports
   signaling of addresses in a TCP backward
   compatible backward-compatible fashion, establishment of
   establishing additional flows (called subflows in MPTCP) MPTCP), and having
   primary and fallback subflows via MP_PRIO signalling. signaling.  The details if or of
   how MPTCP, SCTP SCTP, and/or other approaches potentially (potentially with extensions
   and/or (shim) layers on top of
   them them) can best provide a complete
   solution for the above requirements
   is subject to need further work and are outside
   the scope of this document.

2.1.6.

3.1.6.  Autonomic NOC Device/Applications

   Setting up connectivity between the NOC and autonomic devices when
   the NOC device itself is non-autonomic is a security issue, as
   mentioned in at the beginning a security issue. of this document.  It also results as shown in the previous
   paragraphs in a
   range of connectivity considerations, considerations (discussed in Section 3.1.5),
   some of which may be quite undesirable or complex to operationalize.

   Making NMS hosts autonomic and having them participate in the GACP is
   therefore not only a highly desirable solution to the security
   issues, but can also provide a likely easier operationalization of
   the GACP because it minimizes NOC-special special edge considerations - for the
   NOC.  The GACP is simply built all the way automatically, even inside
   the NOC NOC, and it is only authorized authorizes and authenticate authenticates NOC devices/applications devices/
   applications that will have access to it.

   Supporting

   According to [ACP], supporting the ACP according to
   [I-D.ietf-anima-autonomic-control-plane] all the way into an
   application device requires implementing the following aspects in it:
   AN bootstrap/enrollment mechanisms, the secure channel for the ACP
   and at least the host side of IPv6 routing setup for the ACP.
   Minimally
   Minimally, this could all be implemented as an application and be
   made available to the host OS via e.g. via, e.g., a tap TAP driver to make the ACP
   show up as another IPv6 enabled IPv6-enabled interface.

   Having said this: If the structure of NMS hosts is transformed
   through virtualization anyhow, then it may be considered equally
   secure and appropriate to construct a (physical) NMS host system by
   combining a virtual GACP enabled GACP-enabled router with non-GACP enabled NOC-
   application VMs non-GACP-enabled Virtual
   Machines (VMs) for NOC applications via a hypervisor, leveraging hypervisor.  This would
   leverage the configuration options described in the previous sections
   but just virtualizing virtualize them.

2.1.7.

3.1.7.  Encryption of data-plane connections Data-Plane Connections

   When combining GACP and data-plane connectivity for availability and
   performance reasons, this too has an impact on security: When using
   the GACP, the most traffic will be mostly encryption protected, especially when
   considering the above described above-described use of application devices with GACP.  If instead
   If, instead, the data-plane data plane is used, then this is not the case
   anymore unless it is done by the application.

   The simplest solution for this problem exists when using GACP capable GACP-capable
   NMS hosts, because in that case the communicating GACP capable GACP-capable NMS
   host and the GACP network device have credentials they can mutually
   trust (same GACP domain).  In  As a result, data-plane connectivity that
   does support this can simply leverage TLS/DTLS
   ([RFC5246])/([RFC6347]) TLS [RFC5246] or DTLS [RFC6347]
   with those GACP credentials for mutual authentication - -- and this
   does not incur new key management.

   If this automatic security benefit is seen as most important, but a
   "full" GACP stack into the NMS host is unfeasible, then it would
   still be possible to design a stripped down stripped-down version of GACP
   functionality for such NOC hosts that only provides enrollment of the
   NOC host with the GACP cryptographic credentials but without and does not
   directly
   participating participate in the GACP encryption method.  Instead, the
   host would just leverage TLS/DTLS using its GACP credentials via the data-plane
   data plane with GACP network devices as well as indirectly via the
   GACP connect interface with the
   above mentioned above-mentioned GACP connect
   interface into the GACP.

   When using the GACP itself, TLS/DTLS for the transport layer between
   NMS hosts and network device is somewhat of a double price to pay
   (GACP also encrypts) and could potentially be optimized away, but away;
   however, given the assumed lower performance of the GACP, it seems
   that this is an unnecessary optimization.

2.1.8.  Long Term

3.1.8.  Long-Term Direction of the Solution

   If we consider what potentially could be the most lightweight and
   autonomic long term long-term solution based on the technologies described
   above, we see the following direction:

   1.  NMS hosts should at least support IPv6.  IPv4/IPv6 NAT in the
       network to enable use of a GACP is undesirable in the long term undesirable. term.
       Having
       IPv4 only IPv4-only applications automatically leverage IPv6
       connectivity via host-stack translation may be an option option, but
       this has not been investigated yet.

   2.  Build the GACP as a lightweight application for NMS hosts so GACP
       extends all the way into the actual NMS hosts.

   3.  Leverage and as necessary (as necessary) enhance host transport stacks with
       automatic multipath-connectivity GACP with multipath connectivity and data-plane data plane as
       outlined in Section 2.1.5. 3.1.5.

   4.  Consider how to best map NMS host desires to underlying transport
       mechanisms: With the The three points above mentioned 3 points, do not cover all options
       are covered. options.
       Depending on the OAM, one may still want only GACP, want only data-plane, or
       data plane, automatically prefer one over the other and/
       or other, and/or want
       to use the GACP with low performance or high-performance high performance (for
       emergency OAM such as countering DDoS).  It is as  As of today today, it is not
       clear what the simplest set of tools is to enable explicitly enable the
       choice of desired behavior of each OAM.  The use of the above above-
       mentioned DNS and multipath mechanisms is a start, but this will
       require additional work.  This is likely a specific case of the
       more generic scope of TAPS.

2.2.

3.2.  Stable Connectivity for Distributed Network/OAM

   Today, many distributed protocols implement their own unique security
   mechanisms.

   KARP (Keying

   Keying and Authentication for Routing Protocols, Protocols (KARP; see [RFC6518])
   has tried to start to provide common directions and therefore reduce
   the re-invention reinvention of at least some of the security aspects, but it only
   covers routing-protocols routing protocols and it is unclear how well applicable it is
   applicable to a potentially
   wider range of network distributed agents such as those performing
   distributed OAM.  The common security of a GACP can help in these those
   cases.

   Furthermore, a GRASP ([I-D.ietf-anima-grasp]) instance ([GRASP]) can run on top of a GACP as a
   security and transport substrate and provide common local & and remote
   neighbor discovery and peer negotiation mechanism, further
   allowing to mechanisms; this would allow
   unifying & reuse and reusing future protocol designs.

3.

4.  Architectural Considerations

3.1.

4.1.  No IPv4 for GACP

   The GACP is intended to be IPv6 only, and the prior explanations in
   this document show that this can lead to some complexity when having
   to connect IPv4 only IPv4-only NOC solutions, and that it will be impossible to
   leverage the GACP when the OAM agents on a GACP network device do not
   support IPv6.  Therefore, the question was raised whether the GACP
   should optionally also support IPv4.

   The decision not to include IPv4 for GACP as something that is
   considered in the use cases in this
   document is because of was made for the following reasons:

   In SP service provider networks that have started to support IPv6, often
   the next planned step is to consider moving out IPv4 from a native
   transport to just a service on the edge.  There is no benefit/need benefit or need
   for multiple parallel transport families within the network, and
   standardizing on one reduces OPEX operating expenses and improves
   reliability.  This evolution in the
   data-plane data plane makes it highly
   unlikely that investing development cycles into IPv4 support for GACP
   will have a longer term benefit or enough critical short-term use-cases. use
   cases.  Support for IPv6-only for GACP is purely a strategic choice
   to focus on the known important long term long-term goals.

   In other types of networks as well, we think that efforts to support
   autonomic networking is are better spent in ensuring that one address
   family will be supported so all use cases will long-term work with
   it, it in the
   long term, instead of duplicating effort into with IPv4.  Especially because
   auto-addressing  Also, auto-
   addressing for the GACP with IPv4 would be more complex than in IPv6
   due to the IPv4 addressing space.

4.

5.  Security Considerations

   In this section, we discuss only security considerations not covered
   in the appropriate sub-sections subsections of the solutions described.

   Even though GACPs are meant to be isolated, explicit operator
   misconfiguration to connect to insecure OAM equipment and/or bugs in
   GACP devices may cause leakage into places where it is not expected.
   Mergers/Acquisitions
   Mergers and acquisitions and other complex network reconfigurations
   affecting the NOC are typical examples.

   GACP addresses are ULA addresses. ULAs.  Using these addresses also for NOC
   devices devices,
   as proposed in this document document, is not only necessary for above
   explained the simple
   routing functionality explained above, but it is also more secure
   than global IPv6 addresses.  ULA addresses  ULAs are not routed in the global
   Internet and will therefore be subject to more filtering even in
   places where specific ULA addresses ULAs are being used.  Packets are therefore
   less likely to leak and less likely to be successfully injected into
   the isolated GACP environment.

   The random nature of a ULA prefix provides strong protection against
   address collision even though there is no central assignment
   authority.  This is helped by the expectation that GACPs are will never
   expected to
   connect all together, but and that only a few GACPs may ever need to
   connect together, e.g. e.g., when mergers and acquisitions occur.

   Note that the GACP constraints demands demand that only packets from
   connected subnet prefixes are permitted from GACP connect interfaces,
   limiting the scope of non-cryptographically secured transport to a
   subnet within a NOC that instead has to rely on physical security
   (only
   (i.e., only connect trusted NOC devices to it).

   To help diagnose packets that unexpectedly leaked leaked, for example example, from
   another GACP (that was meant to be deployed separately), it can be
   useful to voluntarily list your own the ULA GACP prefixes on some
   site(s) sites
   on the Internet and hope that other users of GACPs do the same so
   that you can look up unknown ULA prefix packets seen in your network.
   Note that this does not constitute registration.

   https://www.sixxs.net/tools/grh/ula/
   <https://www.sixxs.net/tools/grh/ula/> was a site to list ULA prefixes
   prefixes, but it is has not been open for new listings anymore since the mid of 2017. mid-2017.
   The authors are not aware of other active Internet sites to list ULA
   use.

   Note that there is a provision in [RFC4193] for non-locally assigned address space that is
   not locally assigned (L bit = 0), but there is no existing
   standardization for this, so these ULA prefixes must not be used.

   According to [RFC4193] section 4.4, Section 4.4 of [RFC4193], PTR records for ULA addresses
   should not be installed into the global DNS (no guaranteed
   ownership).  Hence  Hence, there is also the need to rely on voluntary lists (and in
   prior paragraph)
   (as mentioned above) to make the use of an ULA prefix globally known.

   Nevertheless, some legacy OAM applications running across the GACP
   may rely on reverse DNS lookup for authentication of requests (e.g.: (e.g.,
   TFTP for download of network firmware/config/software).  Operators firmware, configuration, or software).
   Therefore, operators may therefore need to use a private DNS setup for the GACP ULA
   addresses.
   ULAs.  This is the same setup that would be necessary for using
   RFC1918 RFC
   1918 addresses in DNS.  See for example [RFC1918] section 5,  For example, see the last
   paragraph. paragraph of
   Section 5 of [RFC1918].  In [RFC6950] section 4, Section 4 of [RFC6950], these setups are
   discussed in more detail.

   Any current and future protocols must rely on secure end-to-end
   communications (TLS/DTLS) and identification and authentication via
   the certificates assigned to both ends.  This is enabled by the
   cryptographic credentials credential mechanisms of the GACP.

   If DNS and especially reverse DNS are set up, then it they should be set
   up in an automated fashion when the GACP address for devices are
   assigned.  In the case of the ACP, DNS resource record creation can
   be linked to the autonomic registrar backend so that the DNS and
   reverse DNS records are actually derived from the subject name
   elements of the ACP device certificates in the same way as the
   autonomic devices themselves will derive their ULA addresses ULAs from their
   certificates to ensure correct and consistent DNS entries.

   If an operator feels that reverse DNS records are beneficial to its
   own operations operations, but that they should not be made available publically publicly
   for "security" by concealment reasons, then the case of GACP DNS entries is are
   probably one of the least problematic use cases for split- split DNS: The
   GACP DNS names are only needed for the NMS hosts intending to use the
   GACP - -- but not network wide across the enterprise.

5.

6.  IANA Considerations

   This document requests has 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 IANA actions.

7.  References

7.1.  Normative References

   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
              and Brian Carpenter E. Lear, "Address Allocation 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
      address prefix selection and DNS for ACP.  Title change to
      emphasize focus on OAM.  Expanded abstract.

      individual-00: Initial version.

8.  References

8.1.  Normative References

   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
              and E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
              <https://www.rfc-editor.org/info/rfc1918>.

   [RFC4191]  Draves, R. Private Internets",
              BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
              <https://www.rfc-editor.org/info/rfc1918>.

   [RFC4191]  Draves, R. and D. Thaler, "Default Router Preferences and
              More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
              November 2005, <https://www.rfc-editor.org/info/rfc4191>.

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

   [RFC6724]  Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
              "Default Address Selection for Internet Protocol Version 6
              (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
              <https://www.rfc-editor.org/info/rfc6724>.

   [RFC6824]  Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
              "TCP Extensions for Multipath Operation with Multiple
              Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
              <https://www.rfc-editor.org/info/rfc6824>.

   [RFC7575]  Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
              Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
              Networking: Definitions and Design Goals", RFC 7575,
              DOI 10.17487/RFC7575, June 2015,
              <https://www.rfc-editor.org/info/rfc7575>.

   [RFC7757]  Anderson, T. and A. Leiva Popper, "Explicit Address
              Mappings for Stateless IP/ICMP Translation", RFC 7757,
              DOI 10.17487/RFC7757, February 2016,
              <https://www.rfc-editor.org/info/rfc7757>.

   [RFC7915]  Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont,
              "IP/ICMP Translation Algorithm", RFC 7915,
              DOI 10.17487/RFC7915, June 2016,
              <https://www.rfc-editor.org/info/rfc7915>.

8.2.

7.2.  Informative References

   [I-D.ietf-anima-autonomic-control-plane]

   [ACP]      Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic
              Control Plane (ACP)", draft-ietf-anima-autonomic-control-
              plane-13 (work Work in progress), Progress, draft-ietf-anima-
              autonomic-control-plane-13, December 2017.

   [I-D.ietf-anima-bootstrapping-keyinfra]

   [BRSKI]    Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
              S., and K. Watsen, "Bootstrapping Remote Secure Key
              Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
              keyinfra-09 (work Work in progress), October 2017.

   [I-D.ietf-anima-grasp] Progress, draft-ietf-
              anima-bootstrapping-keyinfra-15, April 2018.

   [GRASP]    Bormann, C., Carpenter, B., and B. Liu, "A Generic
              Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-
              grasp-15 (work Work in progress), Progress,
              draft-ietf-anima-grasp-15, July 2017.

   [I-D.ietf-anima-reference-model]
              Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L.,
              Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A
              Reference Model for Autonomic Networking", draft-ietf-
              anima-reference-model-05 (work in progress), October 2017.

   [IEEE802.1Q]
              International Telecommunication Union, "802.1Q-2014 - IEEE

   [IEEE.802.1Q]
              IEEE, "IEEE Standard for Local and metropolitan area
              networks - -- Bridges and Bridged Networks", 2014.

   [ITUT]     International Telecommunication Union, IEEE 802.1Q-
              2014, DOI 10.1109/ieeestd.2014.6991462, December 2014,
              <http://ieeexplore.ieee.org/servlet/
              opac?punumber=6991460>.

   [ITUT_G7712]
              ITU, "Architecture and specification of data communication
              network", ITU-T Recommendation G.7712/Y.1703, Noevember 2001.

              This is the earliest but superceeded version of the
              series.  See "https://www.itu.int/rec/T-REC-G.7712/en" November
              2001, <https://www.itu.int/rec/T-REC-G.7712/en>.

   [REF_MODEL]
              Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L.,
              and J. Nobre, "A Reference Model for
              current versions. Autonomic
              Networking", Work in Progress, draft-ietf-anima-reference-
              model-06, February 2018.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <https://www.rfc-editor.org/info/rfc1034>.

   [RFC4960]  Stewart, R., Ed., "Stream Control Transmission Protocol",
              RFC 4960, DOI 10.17487/RFC4960, September 2007,
              <https://www.rfc-editor.org/info/rfc4960>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <https://www.rfc-editor.org/info/rfc5246>.

   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
              NAT64: Network Address and Protocol Translation from IPv6
              Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
              April 2011, <https://www.rfc-editor.org/info/rfc6146>.

   [RFC6291]  Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
              D., and S. Mansfield, "Guidelines for the Use of the "OAM"
              Acronym in the IETF", BCP 161, RFC 6291,
              DOI 10.17487/RFC6291, June 2011,
              <https://www.rfc-editor.org/info/rfc6291>.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
              January 2012, <https://www.rfc-editor.org/info/rfc6347>.

   [RFC6434]  Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
              Requirements", RFC 6434, DOI 10.17487/RFC6434, December
              2011, <https://www.rfc-editor.org/info/rfc6434>.

   [RFC6518]  Lebovitz, G. and M. Bhatia, "Keying and Authentication for
              Routing Protocols (KARP) Design Guidelines", RFC 6518,
              DOI 10.17487/RFC6518, February 2012,
              <https://www.rfc-editor.org/info/rfc6518>.

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

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

   Toerless Eckert (editor)
   Futurewei Technologies Inc.
   Huawei USA
   2330 Central Expy
   Santa Clara  95050
   USA
   United States of America

   Email: tte+ietf@cs.fau.de tte+ietf@cs.fau.de, toerless.eckert@huawei.com

   Michael H. Behringer

   Email: michael.h.behringer@gmail.com