summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8368.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8368.txt')
-rw-r--r--doc/rfc/rfc8368.txt1347
1 files changed, 1347 insertions, 0 deletions
diff --git a/doc/rfc/rfc8368.txt b/doc/rfc/rfc8368.txt
new file mode 100644
index 0000000..ce61d68
--- /dev/null
+++ b/doc/rfc/rfc8368.txt
@@ -0,0 +1,1347 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) T. Eckert, Ed.
+Request for Comments: 8368 Huawei
+Category: Informational M. Behringer
+ISSN: 2070-1721 May 2018
+
+
+ Using an Autonomic Control Plane for Stable Connectivity of
+ Network Operations, Administration, and Maintenance (OAM)
+
+Abstract
+
+ Operations, Administration, and Maintenance (OAM), as per BCP 161,
+ for data networks is often subject to the problem of circular
+ dependencies when relying on connectivity provided by the network to
+ be managed for the OAM purposes.
+
+ Provisioning while bringing up devices and networks tends to be more
+ difficult to automate than service provisioning later on. Changes in
+ core network functions impacting reachability cannot be automated
+ because of ongoing connectivity requirements for the OAM equipment
+ itself, and widely used OAM protocols are not secure enough to be
+ carried across the network without security concerns.
+
+ 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 document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It has been approved for publication by the Internet
+ Engineering Steering Group (IESG). Not all documents approved by the
+ IESG are candidates for any level of Internet Standard; see Section 2
+ of RFC 7841.
+
+ 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.
+
+
+
+
+
+
+
+
+
+Eckert & Behringer Informational [Page 1]
+
+RFC 8368 AN Stable Connectivity OAM May 2018
+
+
+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 . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. Self-Dependent OAM Connectivity . . . . . . . . . . . . . 3
+ 1.2. Data Communication Networks (DCNs) . . . . . . . . . . . 3
+ 1.3. Leveraging a Generalized Autonomic Control Plane . . . . 4
+ 2. GACP Requirements . . . . . . . . . . . . . . . . . . . . . . 5
+ 3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.1. Stable Connectivity for Centralized OAM . . . . . . . . . 6
+ 3.1.1. Simple Connectivity for Non-GACP-Capable
+ NMS Hosts . . . . . . . . . . . . . . . . . . . . . . 7
+ 3.1.2. Challenges and Limitations of Simple Connectivity . . 8
+ 3.1.3. Simultaneous GACP and Data-Plane Connectivity . . . . 9
+ 3.1.4. IPv4-Only NMS Hosts . . . . . . . . . . . . . . . . . 10
+ 3.1.5. Path Selection Policies . . . . . . . . . . . . . . . 12
+ 3.1.6. Autonomic NOC Device/Applications . . . . . . . . . . 16
+ 3.1.7. Encryption of Data-Plane Connections . . . . . . . . 16
+ 3.1.8. Long-Term Direction of the Solution . . . . . . . . . 17
+ 3.2. Stable Connectivity for Distributed Network/OAM . . 18
+ 4. Architectural Considerations . . . . . . . . . . . . . . . . 18
+ 4.1. No IPv4 for GACP . . . . . . . . . . . . . . . . . . . . 18
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
+ 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
+ 7.1. Normative References . . . . . . . . . . . . . . . . . . 21
+ 7.2. Informative References . . . . . . . . . . . . . . . . . 22
+ Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
+
+
+
+
+
+
+
+
+Eckert & Behringer Informational [Page 2]
+
+RFC 8368 AN Stable Connectivity OAM May 2018
+
+
+1. Introduction
+
+1.1. Self-Dependent OAM Connectivity
+
+ Operations, Administration, and Maintenance (OAM), as per BCP 161
+ [RFC6291], for data networks is often subject to the problem of
+ circular dependencies when relying on the connectivity service
+ provided by the network to be managed. OAM can easily but
+ unintentionally break the connectivity required for its own
+ operations. Avoiding these problems can lead to complexity in OAM.
+ This document describes this problem and how to use an autonomic
+ control plane to solve it without further OAM complexity.
+
+ The ability to perform OAM on a network device requires first the
+ execution of OAM necessary to create network connectivity to that
+ device in all intervening devices. This typically leads to
+ sequential "expanding ring configuration" from a Network Operations
+ Center (NOC). It also leads to tight dependencies between
+ provisioning tools and security enrollment of devices. Any process
+ that wants to enroll multiple devices along a newly deployed network
+ topology needs to tightly interlock with the provisioning process
+ that creates connectivity before the enrollment can move on to the
+ next device.
+
+ Likewise, when performing change operations on a network, it is
+ necessary to understand at any step of that process that there is no
+ interruption of connectivity that could lead to removal of
+ connectivity to remote devices. This includes especially change
+ provisioning of routing, forwarding, security, and addressing
+ policies in the network that often occur through mergers and
+ acquisitions, the introduction of IPv6, or other major overhauls of
+ the infrastructure design. Examples include change of an IGP or
+ area, change from Provider Aggregatable (PA) to Provider Independent
+ (PI) addressing, or systematic topology changes (such as Layer 2 to
+ Layer 3 changes).
+
+ All these circular dependencies make OAM complex and potentially
+ fragile. When automation is being used (for example, through
+ provisioning systems), this complexity extends into that automation
+ software.
+
+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_G7712] and called "Data
+ Communications Networks" (DCNs). These were (and still are)
+
+
+
+Eckert & Behringer Informational [Page 3]
+
+RFC 8368 AN Stable Connectivity OAM May 2018
+
+
+ physically separate IP or IP/MPLS networks that provide access to OAM
+ interfaces of all equipment that had to be managed, from Public
+ Switched Telephone Network (PSTN) switches over optical equipment to
+ nowadays Ethernet and IP/MPLS production network equipment.
+
+ Such DCNs provide stable connectivity not subject to the
+ aforementioned problems because they are a separate network entirely,
+ so change configuration of the production IP network is done via the
+ DCN but never affects the DCN configuration. Of course, this
+ approach comes at a cost of buying and operating a separate network,
+ and this cost is not feasible for many providers -- most notably,
+ smaller providers, most enterprises, and typical Internet of Things
+ (IoT) networks.
+
+1.3. Leveraging a Generalized Autonomic Control Plane
+
+ One of the goals of the IETF ANIMA (Autonomic Networking Integrated
+ Model and Approach) Working Group is the specification of a secure
+ and automatically built in-band management plane that provides stable
+ connectivity similar to a DCN, but without having to build a separate
+ DCN. It is clear that such an "in-band" approach can never fully
+ achieve the same level of separation, but the goal is to get as close
+ to it as possible.
+
+ This document discusses how such an in-band management plane can be
+ used to support the DCN-like OAM use case, how to leverage its stable
+ connectivity, and what the options are for deploying it incrementally
+ in the short and long term.
+
+ The ANIMA Working Group's evolving specification [ACP] calls this in-
+ band management plane the "Autonomic Control Plane" (ACP). The
+ discussions in this document are not dependent on the specification
+ of that ACP, but only on a set of high-level constraints listed
+ below, which were decided upon early during the work on the ACP.
+ Except when being specific about details of the ACP, this document
+ uses the term "Generalized ACP" (GACP) and is applicable to any
+ designs that meet the high-level constraints -- for example, the
+ variations of the ACP protocol choices.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eckert & Behringer Informational [Page 4]
+
+RFC 8368 AN Stable Connectivity OAM May 2018
+
+
+2. GACP Requirements
+
+ The high-level constraints of a GACP assumed and discussed in this
+ document are as follows:
+
+ VRF isolation: The GACP is a virtual network (Virtual Routing and
+ Forwarding (VRF)) across network devices; its routing and
+ forwarding are separate from other routing and forwarding in the
+ network devices. Non-GACP routing/forwarding is called the "data
+ plane".
+
+ IPv6-only addressing: The GACP provides only IPv6 reachability. It
+ uses Unique Local Addresses (ULAs) [RFC4193] that are routed in a
+ location-independent fashion, for example, through a subnet prefix
+ for each network device. Therefore, automatic addressing in the
+ GACP is simple and stable: it does not require allocation by
+ address registries, addresses are identifiers, they do not change
+ when devices move, and no engineering of the address space to the
+ network topology is necessary.
+
+ NOC connectivity: NOC equipment (controlling OAM operations) either
+ has access to the GACP directly or has an IP subnet connection to
+ a GACP edge device.
+
+ 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 GACP cryptographic
+ credentials is through explicit configuration for the traffic
+ from/to the aforementioned non-GACP NOC equipment with subnet
+ connections to a GACP edge device (as a transition method).
+
+ 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.
+
+
+
+
+
+
+
+
+
+Eckert & Behringer Informational [Page 5]
+
+RFC 8368 AN Stable Connectivity OAM May 2018
+
+
+3. Solutions
+
+3.1. Stable Connectivity for Centralized OAM
+
+ The ANI is the Autonomic Networking Infrastructure consisting of
+ secure zero-touch bootstrap (BRSKI [BRSKI]), the GeneRic Autonomic
+ Signaling Protocol (GRASP [GRASP]), and Autonomic Control Plane (ACP
+ [ACP]). Refer to the reference model [REF_MODEL] for an overview of
+ the ANI and how its components interact and [RFC7575] for concepts
+ and terminology of ANI and autonomic networks.
+
+ This section describes stable connectivity for centralized OAM via
+ the GACP, for example, via the ACP with or without a complete ANI,
+ starting with the option that we expect to be the most easy to deploy
+ in the short term. It then describes limitations and challenges of
+ that approach and the corresponding solutions and workarounds; it
+ finishes with the preferred target option of autonomic NOC devices in
+ Section 3.1.6.
+
+ This order was chosen because it helps to explain how simple initial
+ use of a GACP can be and how difficult workarounds can become (and
+ therefore what to avoid). Also, one very promising long-term
+ solution is exactly like the most easy short-term solution, only
+ virtualized and automated.
+
+ In the most common case, OAM will be performed by one or more
+ applications running on a variety of centralized NOC systems that
+ communicate with network devices. This document describes approaches
+ to leverage a GACP for stable connectivity, from simple to complex,
+ depending on the capabilities and limitations of the equipment used.
+
+ Three stages can be considered:
+
+ o There are simple options described in Sections 3.1.1 through 3.1.3
+ that we consider to be good starting points to operationalize the
+ use of a GACP for stable connectivity today. These options
+ require only network and OAM/NOC device configuration.
+
+ o The are workarounds to connect a GACP to non-IPv6-capable NOC
+ devices through the use of IPv4/IPv6 NAT (Network Address
+ Translation) as described in Section 3.1.4. These workarounds are
+ not recommended; however, if non-IPv6-capable NOC devices need to
+ be used longer term, then the workarounds are the only way to
+ connect them to a GACP.
+
+
+
+
+
+
+
+Eckert & Behringer Informational [Page 6]
+
+RFC 8368 AN Stable Connectivity OAM May 2018
+
+
+ o Options for the near to long term can provide all the desired
+ operational, zero-touch, and security benefits of an autonomic
+ network, but a range of details for this still have to be worked
+ out, and development work on NOC/OAM equipment is necessary.
+ These options are discussed in Sections 3.1.5 through 3.1.8.
+
+3.1.1. Simple Connectivity for 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. See also
+ Section 6.1 of [ACP]. These devices "leak" the (otherwise encrypted)
+ GACP natively to NMS hosts. They act as the default routers to those
+ NMS hosts and provide them with IPv6 connectivity into the GACP. NMS
+ hosts with this setup need to support IPv6 (e.g., see [RFC6434]) but
+ require no other modifications to leverage the GACP.
+
+ Note that even though the GACP only uses IPv6, it can of course
+ support OAM for any type of network deployment as long as the network
+ devices support the GACP: The data plane can be IPv4 only, dual
+ stack, or IPv6 only. It is always separate from the GACP; therefore,
+ there is no dependency between the GACP and the IP version(s) used in
+ the data plane.
+
+ This setup is sufficient for troubleshooting mechanisms such as SSH
+ into network devices, NMS that performs SNMP read operations for
+ status checking, software downloads onto autonomic devices,
+ provisioning of devices via NETCONF, and so on. In conjunction with
+ otherwise unmodified OAM via separate NMS hosts, this setup can
+ provide a good subset of the stable connectivity goals. The
+ limitations of this approach are discussed in the next section.
+
+ Because the GACP provides "only" for IPv6 connectivity, and because
+ addressing provided by the GACP does not include any topological
+ addressing structure that a NOC often relies on to recognize where
+ devices are on the network, it is likely highly desirable to set up
+ the Domain Name System (DNS; see [RFC1034]) so that the GACP IPv6
+ addresses of autonomic devices are known via domain names that
+ include the desired structure. For example, if DNS in the network
+ were set up with names for network devices as
+ devicename.noc.example.com, and if the well-known structure of the
+ data-plane IPv4 address space were used by operators to infer the
+ region where a device is located, then the GACP address of that
+ device could be set up as devicename_<region>.acp.noc.example.com,
+ and devicename.acp.noc.example.com could be a CNAME to
+ devicename_<region>.acp.noc.example.com. Note that many networks
+ already use names for network equipment where topological information
+ is included, even without a GACP.
+
+
+
+
+Eckert & Behringer Informational [Page 7]
+
+RFC 8368 AN Stable Connectivity OAM May 2018
+
+
+3.1.2. Challenges and 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) and limitations (that is, operators cannot achieve desired goals
+ with this setup). The following list summarizes these challenges and
+ limitations, and the following sections describe additional
+ mechanisms to overcome them.
+
+ Note that these challenges and limitations exist because GACP is
+ primarily designed to support distributed Autonomic Service Agent
+ (ASA), a piece of autonomic software, in the most lightweight
+ fashion. GACP is not required to support the additional mechanisms
+ needed for centralized NOC systems. It is this document that
+ describes additional (short-term) workarounds and (long-term)
+ extensions.
+
+ 1. (Limitation) NMS hosts cannot directly probe whether the desired
+ so-called "data-plane" network connectivity works because they do
+ not directly have access to it. This problem is similar to
+ probing connectivity for other services (such as VPN services)
+ that they do not have direct access to, so the NOC may already
+ employ appropriate mechanisms to deal with this issue (probing
+ proxies). See Section 3.1.3 for candidate solutions.
+
+ 2. (Challenge) NMS hosts need to support IPv6, and this often is
+ still not possible in enterprise networks. See Section 3.1.4 for
+ some workarounds.
+
+ 3. (Limitation) Performance of the GACP may be limited versus normal
+ "data-plane" connectivity. The setup of the GACP will often
+ support only forwarding that is not hardware accelerated.
+ Running a large amount of traffic through the GACP, especially
+ for tasks where it is not necessary, will reduce its performance
+ and effectiveness for those operations where it is necessary or
+ highly desirable. See Section 3.1.5 for candidate solutions.
+
+ 4. (Limitation) Security of the GACP is reduced by exposing the GACP
+ natively (and unencrypted) in a subnet in the NOC where the NOC
+ devices are attached to it. See Section 3.1.7 for candidate
+ solutions.
+
+ These four problems can be tackled independently of each other by
+ solution improvements. Combining some of these improvements together
+ can lead towards a candidate long-term solution.
+
+
+
+
+
+
+Eckert & Behringer Informational [Page 8]
+
+RFC 8368 AN Stable Connectivity OAM May 2018
+
+
+3.1.3. Simultaneous GACP and Data-Plane Connectivity
+
+ Simultaneous connectivity to both the GACP and data plane can be
+ achieved in a variety of ways. If the data plane is IPv4 only, then
+ any method for dual-stack attachment of the NOC device/application
+ will suffice: IPv6 connectivity from the NOC provides access via the
+ GACP; IPv4 provides access via the data plane. If, as explained
+ above in the simple case, an autonomic device supports native
+ attachment to the GACP, and the existing NOC setup is IPv4 only, then
+ it could be sufficient to attach the GACP device(s) as the IPv6
+ default router to the NOC subnet and keep the existing IPv4 default
+ router setup unchanged.
+
+ If the data plane of the network is also supporting IPv6, then the
+ most compatible setup for NOC devices is to have two IPv6 interfaces
+ -- one virtual (e.g., via IEEE 802.1Q [IEEE.802.1Q]) or physical
+ interface connecting to a data-plane subnet, and another connecting
+ into a GACP connect subnet. See Section 8.1 of [ACP] for more
+ details. That document also specifies how a NOC device can receive
+ autoconfigured addressing and routes towards the ACP connect subnet
+ if it supports default address selection as specified in [RFC6724]
+ and default router preferences as specified in [RFC4191].
+
+ Configuring a second interface on a NOC host may be impossible or
+ seen as undesired complexity. In that case, the GACP edge device
+ needs to provide support for a "combined ACP and data-plane
+ interface" as described in Section 8.1 of [ACP]. This setup may not
+ work with autoconfiguration and all NOC host network stacks due to
+ limitations in those network stacks. They need to be able to perform
+ Rule 5.5 of [RFC6724] regarding source address selection, including
+ caching of next-hop information.
+
+ For security reasons, it is not considered appropriate to connect a
+ non-GACP router to a GACP connect interface. The reason is that the
+ GACP is a secured network domain, and all NOC devices connecting via
+ GACP connect interfaces are also part of that secure domain. The
+ main difference is that the physical links between the GACP edge
+ device and the NOC devices are not authenticated or encrypted and,
+ therefore, need to be physically secured. If the secure GACP was
+ extendable via untrusted routers, then it would be a lot more
+ difficult to verify the secure domain assertion. Therefore, the GACP
+ edge devices are not supposed to redistribute routes from non-GACP
+ routers into the GACP.
+
+
+
+
+
+
+
+
+Eckert & Behringer Informational [Page 9]
+
+RFC 8368 AN Stable Connectivity OAM May 2018
+
+
+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 (including
+ NMS hosts) support IPv6. Note that this expectation does not imply
+ any requirements for the data plane, especially it does not imply
+ that IPv6 must be supported in it. The data plane could be IPv4
+ only, IPv6 only, dual stack, or it may not need to have any IP host
+ stack on the network devices.
+
+ The implication of this architectural decision is the potential need
+ for short-term workarounds when the operational practices in a
+ network do not yet meet these target expectations. This section
+ explains when and why these workarounds may be operationally
+ necessary and describes them. However, the long-term goal is to
+ upgrade all NMS hosts to native IPv6, so the workarounds described in
+ this section should not be considered permanent.
+
+ Most network equipment today supports IPv6, but it is very far from
+ being ubiquitously supported in NOC backend solutions (hardware or
+ software) or in the product space for enterprises. Even when it is
+ supported, there are often additional limitations or issues using it
+ in a dual-stack setup, or the operator mandates (for simplicity)
+ single stack for all operations. For these reasons, an IPv4-only
+ management plane is still required and common practice in many
+ enterprises. Without the desire to leverage the GACP, this required
+ and common practice is not a problem for those enterprises even when
+ they run dual stack in the network. We discuss these workarounds
+ here because it is a short-term deployment challenge specific to the
+ operations of a GACP.
+
+ To connect IPv4-only management-plane devices/applications with a
+ GACP, some form of IP/ICMP translation of packets between IPv4 and
+ IPv6 is necessary. The basic mechanisms for this are in [RFC7915],
+ which describes the Stateless IP/ICMP Translation Algorithm (SIIT).
+ There are multiple solutions using this mechanism. To understand the
+ possible solutions, we consider the requirements:
+
+ 1. NMS hosts need to be able to initiate connections to any GACP
+ device for management purposes. Examples include provisioning
+ via NETCONF, SNMP poll operations, or just diagnostics via SSH
+ connections from operators. Every GACP device/function that
+ needs to be reachable from NMS hosts needs to have a separate
+ IPv4 address.
+
+
+
+
+
+
+
+Eckert & Behringer Informational [Page 10]
+
+RFC 8368 AN Stable Connectivity OAM May 2018
+
+
+ 2. GACP devices need to be able to initiate connections to NMS
+ hosts, for example, to initiate NTP or RADIUS/Diameter
+ connections, send syslog or SNMP trap, or initiate NETCONF Call
+ Home connections after bootstrap. Every NMS host needs to have a
+ separate IPv6 address reachable from the GACP. When a connection
+ from a GACP device is made to an NMS host, the IPv4 source
+ address of the connection (as seen by the NMS host) must be
+ unique per GACP device and must be the same address as in (1) to
+ maintain addressing simplicity similar to a native IPv4
+ deployment. For example in syslog, the source IP address of a
+ logging device is used to identify it, and if the device shows
+ problems, an operator might want to SSH into the device to
+ diagnose it.
+
+ Because of these requirements, the necessary and sufficient set of
+ solutions are those that provide 1:1 mapping of IPv6 GACP addresses
+ into IPv4 space and 1:1 mapping of IPv4 NMS host space into IPv6 (for
+ use in the GACP). This means that SIIT-based solutions are
+ sufficient and preferred.
+
+ Note that GACP devices may use multiple IPv6 addresses in the GACP.
+ For example, Section 6.10 of [ACP] defines multiple useful addressing
+ sub-schemes supporting this option. All those addresses may then
+ need to be reachable through IPv6/IPv4 address translation.
+
+ The need to allocate for every GACP device one or multiple IPv4
+ addresses should not be a problem if -- as we assume -- the NMS hosts
+ can use private IPv4 address space ([RFC1918]). Nevertheless, even
+ with private IPv4 address space, it is important that the GACP IPv6
+ addresses can be mapped efficiently into IPv4 address space without
+ too much waste.
+
+ Currently, the most flexible mapping scheme to achieve this is
+ [RFC7757] because it allows configured IPv4 <-> IPv6 prefix mapping.
+ Assume the GACP uses the ACP Zone Addressing Sub-Scheme and there are
+ 3 registrars. In the ACP Zone Addressing Sub-Scheme, for each
+ registrar, there is a constant /112 prefix for which an Explicit
+ Address Mapping (EAM), as defined in RFC 7757, to a /16 prefix can be
+ configured (e.g., in the private IPv4 address space described in
+ [RFC1918]). Within the registrar's /112 prefix, Device-Numbers for
+ devices are sequentially assigned: with the V bit (Virtualization
+ bit) effectively two numbers are assigned per GACP device. This also
+ means that if IPv4 address space is even more constrained, and it is
+ known that a registrar will never need the full /15 extent of Device-
+ Numbers, then a prefix longer than a /112 can be configured into the
+ EAM in order to use less IPv4 space.
+
+
+
+
+
+Eckert & Behringer Informational [Page 11]
+
+RFC 8368 AN Stable Connectivity OAM May 2018
+
+
+ When using the ACP Vlong Addressing Sub-Scheme, it is unlikely that
+ one wants or needs to translate the full /8 or /16 of addressing
+ space per GACP device into IPv4. In this case, the EAM rules of
+ dropping trailing bits can be used to map only N bits of the V bits
+ into IPv4. However, this does imply that only addresses that differ
+ in those high-order N V bits can be distinguished on the IPv4 side.
+
+ 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. 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'
+ IPv4 address space. As a workaround, this can also be done on non-
+ GACP Edge Devices connected to a GACP connect interface. The details
+ vary depending on implementation because the options to configure
+ address mappings vary widely. Outside of EAM, there are no
+ standardized solutions that allow for mapping of prefixes, so it will
+ most likely be necessary to explicitly map every individual (/128)
+ GACP device address to an IPv4 address. Such an approach should use
+ automation/scripting where these address translation entries are
+ created dynamically whenever a GACP device is enrolled or first
+ connected to the GACP network.
+
+ The NAT methods described here are not specific to a GACP. Instead,
+ they are similar to what would be necessary when some parts of a
+ network only support IPv6, but the NOC equipment does not support
+ IPv6. Whether it is more appropriate to wait until the NOC equipment
+ supports IPv6 or to use NAT beforehand depends in large part on how
+ long the former will take and how easy the latter will be when using
+ products that support the NAT options described to operationalize the
+ above recommendations.
+
+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. For existing
+ network device platforms, this often means that it is a lot more
+ effort to implement that additional connectivity with hardware
+
+
+
+
+Eckert & Behringer Informational [Page 12]
+
+RFC 8368 AN Stable Connectivity OAM May 2018
+
+
+ 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 tend to the needs of
+ a separate OAM plane, but it is wise to plan for long-term designs of
+ the solution that do NOT depend on high performance of the GACP.
+ This is the opposite of the expectations that future NMS hosts will
+ have IPv6 and that any considerations for IPv4/NAT in this solution
+ are temporary.
+
+ To solve the expected performance limitations of the GACP, we do
+ expect to have the above-described dual connectivity via both GACP
+ and data plane between NOC application devices and devices with GACP.
+ The GACP connectivity is expected to always be there (as soon as a
+ device is enrolled), but the data-plane connectivity is only present
+ under normal operations and will not be present during, e.g., early
+ stages of device bootstrap, failures, provisioning mistakes, or
+ network configuration changes.
+
+ The desired policy is therefore as follows: In the absence of further
+ security considerations (see below), traffic between NMS hosts and
+ GACP devices should prefer data-plane connectivity and resort only to
+ using the GACP when necessary. The exception is an operation known
+ to be covered by the use cases where the GACP is necessary, so that
+ it makes no sense to try using the data plane. An example is an SSH
+ connection from the NOC to a network device to troubleshoot network
+ connectivity. This could easily always rely on the GACP. Likewise,
+ if an NMS host is known to transmit large amounts of data, and it
+ uses the GACP, then its data rate needs to be controlled so that it
+ will not overload the GACP path. Typical examples of this are
+ software downloads.
+
+ There is a wide range of methods to build up these policies. We
+ describe a few below.
+
+ Ideally, a NOC system would learn and keep track of all addresses of
+ a device (GACP and the various data-plane addresses). Every action
+ of the NOC system would indicate via a "path-policy" what type of
+ connection it needs (e.g., only data-plane, GACP only, default to
+ data plane, fallback to GACP, etc.). A connection policy manager
+ would then build connection to the target using the right
+ address(es). Shorter term, a common practice is to identify
+ different paths to a device via different names (e.g., loopback vs.
+ interface addresses). This approach can be expanded to GACP uses,
+ whether it uses the DNS or names local to the NOC system. Below, we
+ describe example schemes using DNS.
+
+
+
+Eckert & Behringer Informational [Page 13]
+
+RFC 8368 AN Stable Connectivity OAM May 2018
+
+
+ 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) 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
+ used to throttle applications such as software download into the
+ GACP.
+
+ Using different names that map to different addresses (or subsets of
+ addresses) can be difficult to set up and maintain, especially
+ because data-plane addresses may change due to reconfiguration or
+ relocation of devices. The name-based approach alone cannot strongly
+ support policies for existing applications and long-lived flows to
+ automatically switch between the ACP and data plane in the face of
+ data-plane failure and recovery. A solution would be host transport
+ stacks on GACP nodes that support the following requirements:
+
+ 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.
+
+ 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 is
+ operational. When the additional flow cannot be built during
+ connection setup or when it fails later, traffic is sent
+ across the GACP flow. This could be a default policy for most
+ OAM applications using the GACP.
+
+
+
+
+
+Eckert & Behringer Informational [Page 14]
+
+RFC 8368 AN Stable Connectivity OAM May 2018
+
+
+ Suspend/Fail: Like the Fallback policy, except that traffic will
+ not use the GACP flow; instead, it will be suspended until a
+ data-plane flow is operational or until a policy-configurable
+ timeout indicates a connection failure to the application.
+ This policy would be appropriate for large-volume background
+ or scavenger-class OAM applications such as firmware downloads
+ or telemetry/diagnostic uploads -- applications that would
+ otherwise easily overrun performance-limited GACP
+ implementations.
+
+ GACP (only): No additional data-plane flow is built, traffic is
+ only sent via the GACP flow. This can just be a TCP
+ connection. This policy would be most appropriate for OAM
+ operations known to change the data plane in a way that could
+ impact connectivity through it (at least temporarily).
+
+ 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
+ recovers, including when the data-plane address of one side or
+ both sides may have changed -- for 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 these host
+ transport stack functions with the GACP domain credentials and
+ encrypted. This maintains the expectation that connections from
+ GACP addresses to GACP addresses are authenticated and encrypted.
+ This may be skipped if the application already provides for end-
+ to-end encryption.
+
+ 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 Multipath TCP (MPTCP; see [RFC6824]) and the Stream
+ Control Transmission Protocol (SCTP; see [RFC4960]) can already
+ support part of these requirements. MPTCP, for example, supports
+ signaling of addresses in a TCP backward-compatible fashion,
+ establishing additional flows (called subflows in MPTCP), and having
+ primary and fallback subflows via MP_PRIO signaling. The details of
+ how MPTCP, SCTP, and/or other approaches (potentially with extensions
+
+
+
+Eckert & Behringer Informational [Page 15]
+
+RFC 8368 AN Stable Connectivity OAM May 2018
+
+
+ and/or (shim) layers on top of them) can best provide a complete
+ solution for the above requirements need further work and are outside
+ the scope of this document.
+
+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 at the beginning of this document. It also results in a
+ range of connectivity considerations (discussed in Section 3.1.5),
+ some of which may be quite undesirable or complex to operationalize.
+
+ Making NMS hosts autonomic and having them participate in the GACP is
+ therefore not only a highly desirable solution to the security
+ issues, but can also provide a likely easier operationalization of
+ the GACP because it minimizes special edge considerations for the
+ NOC. The GACP is simply built all the way automatically, even inside
+ the NOC, and it is only authorizes and authenticates NOC devices/
+ applications that will have access to it.
+
+ According to [ACP], supporting the ACP all the way into an
+ application device requires implementing the following aspects in it:
+ AN bootstrap/enrollment mechanisms, the secure channel for the ACP
+ and at least the host side of IPv6 routing setup for the ACP.
+ Minimally, this could all be implemented as an application and be
+ made available to the host OS via, e.g., a TAP driver to make the ACP
+ show up as another IPv6-enabled interface.
+
+ Having said this: If the structure of NMS hosts is transformed
+ through virtualization anyhow, then it may be considered equally
+ secure and appropriate to construct a (physical) NMS host system by
+ combining a virtual GACP-enabled router with non-GACP-enabled Virtual
+ Machines (VMs) for NOC applications via a hypervisor. This would
+ leverage the configuration options described in the previous sections
+ but just virtualize them.
+
+3.1.7. Encryption of 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, most traffic will be encryption protected, especially when
+ considering the above-described use of application devices with GACP.
+ If, instead, the data plane is used, then this is not the case
+ anymore unless it is done by the application.
+
+ The simplest solution for this problem exists when using GACP-capable
+ NMS hosts, because in that case the communicating GACP-capable NMS
+ host and the GACP network device have credentials they can mutually
+
+
+
+Eckert & Behringer Informational [Page 16]
+
+RFC 8368 AN Stable Connectivity OAM May 2018
+
+
+ trust (same GACP domain). As a result, data-plane connectivity that
+ does support this can simply leverage TLS [RFC5246] or DTLS [RFC6347]
+ with those GACP credentials for mutual authentication -- and this
+ does not incur new key management.
+
+ If this automatic security benefit is seen as most important, but a
+ "full" GACP stack into the NMS host is unfeasible, then it would
+ still be possible to design a stripped-down version of GACP
+ functionality for such NOC hosts that only provides enrollment of the
+ NOC host with the GACP cryptographic credentials and does not
+ directly participate in the GACP encryption method. Instead, the
+ host would just leverage TLS/DTLS using its GACP credentials via the
+ data plane with GACP network devices as well as indirectly via the
+ GACP connect interface with the above-mentioned GACP connect
+ interface into the GACP.
+
+ When using the GACP itself, TLS/DTLS for the transport layer between
+ NMS hosts and network device is somewhat of a double price to pay
+ (GACP also encrypts) and could potentially be optimized away;
+ however, given the assumed lower performance of the GACP, it seems
+ that this is an unnecessary optimization.
+
+3.1.8. Long-Term Direction of the Solution
+
+ If we consider what potentially could be the most lightweight and
+ autonomic long-term solution based on the technologies described
+ above, we see the following direction:
+
+ 1. NMS hosts should at least support IPv6. IPv4/IPv6 NAT in the
+ network to enable use of a GACP is undesirable in the long term.
+ Having IPv4-only applications automatically leverage IPv6
+ connectivity via host-stack translation may be an option, but
+ this has not been investigated yet.
+
+ 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) enhance host transport stacks with
+ automatic GACP with multipath connectivity and data plane as
+ outlined in Section 3.1.5.
+
+ 4. Consider how to best map NMS host desires to underlying transport
+ mechanisms: The three points above do not cover all options.
+ Depending on the OAM, one may still want only GACP, want only
+ data plane, automatically prefer one over the other, and/or want
+ to use the GACP with low performance or high performance (for
+ emergency OAM such as countering DDoS). As of today, it is not
+ clear what the simplest set of tools is to explicitly enable the
+
+
+
+Eckert & Behringer Informational [Page 17]
+
+RFC 8368 AN Stable Connectivity OAM May 2018
+
+
+ choice of desired behavior of each OAM. The use of the above-
+ mentioned DNS and multipath mechanisms is a start, but this will
+ require additional work. This is likely a specific case of the
+ more generic scope of TAPS.
+
+3.2. Stable Connectivity for Distributed Network/OAM
+
+ Today, many distributed protocols implement their own unique security
+ mechanisms.
+
+ Keying and Authentication for Routing Protocols (KARP; see [RFC6518])
+ has tried to start to provide common directions and therefore reduce
+ the reinvention of at least some of the security aspects, but it only
+ covers routing protocols and it is unclear how applicable it is to a
+ wider range of network distributed agents such as those performing
+ distributed OAM. The common security of a GACP can help in those
+ cases.
+
+ Furthermore, a GRASP instance ([GRASP]) can run on top of a GACP as a
+ security and transport substrate and provide common local and remote
+ neighbor discovery and peer negotiation mechanisms; this would allow
+ unifying and reusing future protocol designs.
+
+4. Architectural Considerations
+
+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 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 in the use cases in this
+ document was made for the following reasons:
+
+ In service provider networks that have started to support IPv6, often
+ the next planned step is to consider moving IPv4 from a native
+ transport to just a service on the edge. There is no benefit or need
+ for multiple parallel transport families within the network, and
+ standardizing on one reduces operating expenses and improves
+ reliability. This evolution in the data plane makes it highly
+ unlikely that investing development cycles into IPv4 support for GACP
+ will have a longer term benefit or enough critical short-term use
+ cases. Support for IPv6-only for GACP is purely a strategic choice
+ to focus on the known important long-term goals.
+
+
+
+
+Eckert & Behringer Informational [Page 18]
+
+RFC 8368 AN Stable Connectivity OAM May 2018
+
+
+ In other types of networks as well, we think that efforts to support
+ autonomic networking are better spent in ensuring that one address
+ family will be supported so all use cases will work with it in the
+ long term, instead of duplicating effort with IPv4. Also, auto-
+ addressing for the GACP with IPv4 would be more complex than in IPv6
+ due to the IPv4 addressing space.
+
+5. Security Considerations
+
+ In this section, we discuss only security considerations not covered
+ in the appropriate subsections of the solutions described.
+
+ Even though GACPs are meant to be isolated, explicit operator
+ misconfiguration to connect to insecure OAM equipment and/or bugs in
+ GACP devices may cause leakage into places where it is not expected.
+ Mergers and acquisitions and other complex network reconfigurations
+ affecting the NOC are typical examples.
+
+ GACP addresses are ULAs. Using these addresses also for NOC devices,
+ as proposed in this document, is not only necessary for the simple
+ routing functionality explained above, but it is also more secure
+ than global IPv6 addresses. ULAs are not routed in the global
+ Internet and will therefore be subject to more filtering even in
+ places where specific ULAs are being used. Packets are therefore
+ less likely to leak and less likely to be successfully injected into
+ the isolated GACP environment.
+
+ The random nature of a ULA prefix provides strong protection against
+ address collision even though there is no central assignment
+ authority. This is helped by the expectation that GACPs will never
+ connect all together, and that only a few GACPs may ever need to
+ connect together, e.g., when mergers and acquisitions occur.
+
+ Note that the GACP constraints demand that only packets from
+ connected subnet prefixes are permitted from GACP connect interfaces,
+ limiting the scope of non-cryptographically secured transport to a
+ subnet within a NOC that instead has to rely on physical security
+ (i.e., only connect trusted NOC devices to it).
+
+ To help diagnose packets that unexpectedly leaked, for example, from
+ another GACP (that was meant to be deployed separately), it can be
+ useful to voluntarily list your own ULA GACP prefixes on some sites
+ on the Internet and hope that other users of GACPs do the same so
+ that you can look up unknown ULA prefix packets seen in your network.
+ Note that this does not constitute registration.
+ <https://www.sixxs.net/tools/grh/ula/> was a site to list ULA
+
+
+
+
+
+Eckert & Behringer Informational [Page 19]
+
+RFC 8368 AN Stable Connectivity OAM May 2018
+
+
+ prefixes, but it has not been open for new listings since mid-2017.
+ The authors are not aware of other active Internet sites to list ULA
+ use.
+
+ Note that there is a provision in [RFC4193] for address space that is
+ not locally assigned (L bit = 0), but there is no existing
+ standardization for this, so these ULA prefixes must not be used.
+
+ According to Section 4.4 of [RFC4193], PTR records for ULA addresses
+ should not be installed into the global DNS (no guaranteed
+ ownership). Hence, there is also the need to rely on voluntary lists
+ (as mentioned above) to make the use of an ULA prefix globally known.
+
+ Nevertheless, some legacy OAM applications running across the GACP
+ may rely on reverse DNS lookup for authentication of requests (e.g.,
+ TFTP for download of network firmware, configuration, or software).
+ Therefore, operators may need to use a private DNS setup for the GACP
+ ULAs. This is the same setup that would be necessary for using RFC
+ 1918 addresses in DNS. For example, see the last paragraph of
+ Section 5 of [RFC1918]. In Section 4 of [RFC6950], these setups are
+ discussed in more detail.
+
+ Any current and future protocols must rely on secure end-to-end
+ communications (TLS/DTLS) and identification and authentication via
+ the certificates assigned to both ends. This is enabled by the
+ cryptographic credential mechanisms of the GACP.
+
+ If DNS and especially reverse DNS are set up, then they should be set
+ up in an automated fashion when the GACP address for devices are
+ assigned. In the case of the ACP, DNS resource record creation can
+ be linked to the autonomic registrar backend so that the DNS and
+ reverse DNS records are actually derived from the subject name
+ elements of the ACP device certificates in the same way as the
+ autonomic devices themselves will derive their ULAs from their
+ certificates to ensure correct and consistent DNS entries.
+
+ If an operator feels that reverse DNS records are beneficial to its
+ own operations, but that they should not be made available publicly
+ for "security" by concealment reasons, then GACP DNS entries are
+ probably one of the least problematic use cases for split DNS: The
+ GACP DNS names are only needed for the NMS hosts intending to use the
+ GACP -- but not network wide across the enterprise.
+
+6. IANA Considerations
+
+ This document has no IANA actions.
+
+
+
+
+
+Eckert & Behringer Informational [Page 20]
+
+RFC 8368 AN Stable Connectivity OAM May 2018
+
+
+7. References
+
+7.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. 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>.
+
+
+
+
+
+
+
+
+
+Eckert & Behringer Informational [Page 21]
+
+RFC 8368 AN Stable Connectivity OAM May 2018
+
+
+7.2. Informative References
+
+ [ACP] Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic
+ Control Plane (ACP)", Work in Progress,
+ draft-ietf-anima-autonomic-control-plane-13,
+ December 2017.
+
+ [BRSKI] Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
+ S., and K. Watsen, "Bootstrapping Remote Secure Key
+ Infrastructures (BRSKI)", Work in Progress,
+ draft-ietf-anima-bootstrapping-keyinfra-15, April 2018.
+
+ [GRASP] Bormann, C., Carpenter, B., and B. Liu, "A Generic
+ Autonomic Signaling Protocol (GRASP)", Work in Progress,
+ draft-ietf-anima-grasp-15, July 2017.
+
+ [IEEE.802.1Q]
+ IEEE, "IEEE Standard for Local and metropolitan area
+ networks -- Bridges and Bridged Networks",
+ IEEE 802.1Q-2014, DOI 10.1109/ieeestd.2014.6991462,
+ December 2014, <http://ieeexplore.ieee.org/servlet/
+ opac?punumber=6991460>.
+
+ [ITUT_G7712]
+ ITU, "Architecture and specification of data communication
+ network", ITU-T Recommendation G.7712/Y.1703, November
+ 2001, <https://www.itu.int/rec/T-REC-G.7712/en>.
+
+ [REF_MODEL]
+ Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L.,
+ and J. Nobre, "A Reference Model for Autonomic
+ Networking", Work in Progress,
+ draft-ietf-anima-reference-model-06, February 2018.
+
+ [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>.
+
+
+
+
+
+Eckert & Behringer Informational [Page 22]
+
+RFC 8368 AN Stable Connectivity OAM May 2018
+
+
+ [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.
+
+
+
+
+
+
+
+
+
+
+
+Eckert & Behringer Informational [Page 23]
+
+RFC 8368 AN Stable Connectivity OAM May 2018
+
+
+Authors' Addresses
+
+ Toerless Eckert (editor)
+ Huawei USA
+ 2330 Central Expy
+ Santa Clara 95050
+ United States of America
+
+ Email: tte+ietf@cs.fau.de, toerless.eckert@huawei.com
+
+
+ Michael H. Behringer
+
+ Email: michael.h.behringer@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eckert & Behringer Informational [Page 24]
+