draft-ietf-anima-autonomic-control-plane-08.txt   draft-ietf-anima-autonomic-control-plane-09.txt 
ANIMA WG M. Behringer, Ed. ANIMA WG M. Behringer, Ed.
Internet-Draft Internet-Draft
Intended status: Standards Track T. Eckert, Ed. Updates: 4291,4193 (if approved) T. Eckert, Ed.
Expires: January 21, 2018 Huawei Intended status: Standards Track Huawei
S. Bjarnason Expires: February 3, 2018 S. Bjarnason
Arbor Networks Arbor Networks
July 20, 2017 August 2, 2017
An Autonomic Control Plane (ACP) An Autonomic Control Plane (ACP)
draft-ietf-anima-autonomic-control-plane-08 draft-ietf-anima-autonomic-control-plane-09
Abstract Abstract
Autonomic functions need a control plane to communicate, which Autonomic functions need a control plane to communicate, which
depends on some addressing and routing. This Autonomic Control Plane depends on some addressing and routing. This Autonomic Control Plane
should ideally be self-managing, and as independent as possible of should ideally be self-managing, and as independent as possible of
configuration. This document defines an "Autonomic Control Plane", configuration. This document defines an "Autonomic Control Plane",
with the primary use as a control plane for autonomic functions. It with the primary use as a control plane for autonomic functions. It
also serves as a "virtual out of band channel" for OAM communications also serves as a "virtual out of band channel" for OAM communications
over a network that is not configured, or mis-configured. over a network that is not configured, or mis-configured.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 21, 2018. This Internet-Draft will expire on February 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Use Cases for an Autonomic Control Plane . . . . . . . . . . 8 3. Use Cases for an Autonomic Control Plane . . . . . . . . . . 8
3.1. An Infrastructure for Autonomic Functions . . . . . . . . 8 3.1. An Infrastructure for Autonomic Functions . . . . . . . . 8
3.2. Secure Bootstrap over an Unconfigured Network . . . . . . 8 3.2. Secure Bootstrap over an Unconfigured Network . . . . . . 8
3.3. Data Plane Independent Permanent Reachability . . . . . . 8 3.3. Data Plane Independent Permanent Reachability . . . . . . 9
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 11 6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 12
6.1. Domain Certificate . . . . . . . . . . . . . . . . . . . 12 6.1. Domain Certificate . . . . . . . . . . . . . . . . . . . 12
6.1.1. ACP information . . . . . . . . . . . . . . . . . . . 12 6.1.1. ACP information . . . . . . . . . . . . . . . . . . . 12
6.1.2. Maintenance . . . . . . . . . . . . . . . . . . . . . 14 6.1.2. Maintenance . . . . . . . . . . . . . . . . . . . . . 14
6.2. AN Adjacency Table . . . . . . . . . . . . . . . . . . . 16 6.2. AN Adjacency Table . . . . . . . . . . . . . . . . . . . 16
6.3. Neighbor Discovery with DULL GRASP . . . . . . . . . . . 16 6.3. Neighbor Discovery with DULL GRASP . . . . . . . . . . . 17
6.4. Candidate ACP Neighbor Selection . . . . . . . . . . . . 19 6.4. Candidate ACP Neighbor Selection . . . . . . . . . . . . 19
6.5. Channel Selection . . . . . . . . . . . . . . . . . . . . 19 6.5. Channel Selection . . . . . . . . . . . . . . . . . . . . 20
6.6. Candidate ACP Neighbor certificate verification . . . . . 21 6.6. Candidate ACP Neighbor certificate verification . . . . . 21
6.7. Security Association protocols . . . . . . . . . . . . . 21 6.7. Security Association protocols . . . . . . . . . . . . . 22
6.7.1. ACP via IKEv2 . . . . . . . . . . . . . . . . . . . . 21 6.7.1. ACP via IKEv2 . . . . . . . . . . . . . . . . . . . . 22
6.7.2. ACP via dTLS . . . . . . . . . . . . . . . . . . . . 22 6.7.2. ACP via dTLS . . . . . . . . . . . . . . . . . . . . 23
6.7.3. ACP Secure Channel Requirements . . . . . . . . . . . 23 6.7.3. ACP Secure Channel Requirements . . . . . . . . . . . 23
6.8. GRASP in the ACP . . . . . . . . . . . . . . . . . . . . 23 6.8. GRASP in the ACP . . . . . . . . . . . . . . . . . . . . 24
6.8.1. GRASP as a core service of the ACP . . . . . . . . . 23 6.8.1. GRASP as a core service of the ACP . . . . . . . . . 24
6.8.2. ACP as the Security and Transport substrate for GRASP 23 6.8.2. ACP as the Security and Transport substrate for GRASP 24
6.9. Context Separation . . . . . . . . . . . . . . . . . . . 24 6.9. Context Separation . . . . . . . . . . . . . . . . . . . 25
6.10. Addressing inside the ACP . . . . . . . . . . . . . . . . 25 6.10. Addressing inside the ACP . . . . . . . . . . . . . . . . 25
6.10.1. Fundamental Concepts of Autonomic Addressing . . . . 25 6.10.1. Fundamental Concepts of Autonomic Addressing . . . . 26
6.10.2. The ACP Addressing Base Scheme . . . . . . . . . . . 26 6.10.2. The ACP Addressing Base Scheme . . . . . . . . . . . 27
6.10.3. ACP Zone Addressing Sub-Scheme . . . . . . . . . . . 27 6.10.3. ACP Zone Addressing Sub-Scheme . . . . . . . . . . . 27
6.10.4. ACP V8 Addressing Sub-Scheme . . . . . . . . . . . . 29 6.10.4. ACP Manual Addressing Sub-Scheme . . . . . . . . . . 30
6.10.5. Other ACP Addressing Sub-Schemes . . . . . . . . . . 29 6.10.5. ACP Vlong Addressing Sub-Scheme . . . . . . . . . . 31
6.11. Routing in the ACP . . . . . . . . . . . . . . . . . . . 30 6.10.6. Other ACP Addressing Sub-Schemes . . . . . . . . . . 32
6.11.1. RPL Profile . . . . . . . . . . . . . . . . . . . . 30 6.11. Routing in the ACP . . . . . . . . . . . . . . . . . . . 32
6.12. General ACP Considerations . . . . . . . . . . . . . . . 33 6.11.1. RPL Profile . . . . . . . . . . . . . . . . . . . . 32
6.12.1. Addressing of Secure Channels in the data plane . . 33 6.12. General ACP Considerations . . . . . . . . . . . . . . . 36
6.12.2. MTU . . . . . . . . . . . . . . . . . . . . . . . . 33 6.12.1. Addressing of Secure Channels in the data plane . . 36
6.12.3. Multiple links between nodes . . . . . . . . . . . . 34 6.12.2. MTU . . . . . . . . . . . . . . . . . . . . . . . . 36
6.12.4. ACP interfaces . . . . . . . . . . . . . . . . . . . 34 6.12.3. Multiple links between nodes . . . . . . . . . . . . 37
7. ACP support on L2 switches/ports (Normative) . . . . . . . . 36 6.12.4. ACP interfaces . . . . . . . . . . . . . . . . . . . 37
7.1. Why . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 7. ACP support on L2 switches/ports (Normative) . . . . . . . . 38
7.2. How (per L2 port DULL GRASP) . . . . . . . . . . . . . . 37 7.1. Why . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8. Workarounds for Non-Autonomic Nodes (Normative) . . . . . . . 38 7.2. How (per L2 port DULL GRASP) . . . . . . . . . . . . . . 40
8.1. Non-Autonomic Controller / NMS system (ACP connect) . . . 38 8. Support for Non-Autonomic Components (Normative) . . . . . . 41
8.1. ACP Connect . . . . . . . . . . . . . . . . . . . . . . . 41
8.1.1. Non-Autonomic Controller / NMS system . . . . . . . . 41
8.1.2. Software Components . . . . . . . . . . . . . . . . . 44
8.1.3. Auto Configuration . . . . . . . . . . . . . . . . . 45
8.1.4. Combined ACP and Data Data Plane Interface (VRF
Select) . . . . . . . . . . . . . . . . . . . . . . . 45
8.1.5. Use of GRASP . . . . . . . . . . . . . . . . . . . . 47
8.2. ACP through Non-Autonomic L3 Clouds (Remote ACP 8.2. ACP through Non-Autonomic L3 Clouds (Remote ACP
neighbors) . . . . . . . . . . . . . . . . . . . . . . . 40 neighbors) . . . . . . . . . . . . . . . . . . . . . . . 48
8.2.1. Configured Remote ACP neighbor . . . . . . . . . . . 40 8.2.1. Configured Remote ACP neighbor . . . . . . . . . . . 48
8.2.2. Tunneled Remote ACP Neighbor . . . . . . . . . . . . 41 8.2.2. Tunneled Remote ACP Neighbor . . . . . . . . . . . . 49
8.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 42 8.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 50
9. Benefits (Informative) . . . . . . . . . . . . . . . . . . . 42 9. Benefits (Informative) . . . . . . . . . . . . . . . . . . . 50
9.1. Self-Healing Properties . . . . . . . . . . . . . . . . . 42 9.1. Self-Healing Properties . . . . . . . . . . . . . . . . . 50
9.2. Self-Protection Properties . . . . . . . . . . . . . . . 43 9.2. Self-Protection Properties . . . . . . . . . . . . . . . 51
9.2.1. From the outside . . . . . . . . . . . . . . . . . . 43 9.2.1. From the outside . . . . . . . . . . . . . . . . . . 51
9.2.2. From the inside . . . . . . . . . . . . . . . . . . . 44 9.2.2. From the inside . . . . . . . . . . . . . . . . . . . 52
9.3. The Administrator View . . . . . . . . . . . . . . . . . 45 9.3. The Administrator View . . . . . . . . . . . . . . . . . 53
10. Further Considerations (Informative) . . . . . . . . . . . . 45 10. Further Considerations (Informative) . . . . . . . . . . . . 53
10.1. Domain Certificate provisioning / enrollment . . . . . . 45 10.1. Domain Certificate provisioning / enrollment . . . . . . 53
10.2. ACP Neighbor discovery protocol selection . . . . . . . 47 10.2. ACP Neighbor discovery protocol selection . . . . . . . 55
10.2.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 47 10.2.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 55
10.2.2. mDNS and L2 support . . . . . . . . . . . . . . . . 47 10.2.2. mDNS and L2 support . . . . . . . . . . . . . . . . 55
10.2.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 47 10.2.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 55
10.3. Choice of routing protocol (RPL) . . . . . . . . . . . . 48 10.3. Choice of routing protocol (RPL) . . . . . . . . . . . . 56
10.4. Extending ACP channel negotiation (via GRASP) . . . . . 49 10.4. Extending ACP channel negotiation (via GRASP) . . . . . 57
10.5. CAs, domains and routing subdomains considerations . . . 51 10.5. CAs, domains and routing subdomains . . . . . . . . . . 59
11. Security Considerations . . . . . . . . . . . . . . . . . . . 53 11. RFC4291/RFC4193 Updates Considerations . . . . . . . . . . . 61
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 12. Security Considerations . . . . . . . . . . . . . . . . . . . 63
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 53 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63
14. Change log [RFC Editor: Please remove] . . . . . . . . . . . 54 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 63
14.1. Initial version . . . . . . . . . . . . . . . . . . . . 54 15. Change log [RFC Editor: Please remove] . . . . . . . . . . . 64
14.2. draft-behringer-anima-autonomic-control-plane-00 . . . . 54 15.1. Initial version . . . . . . . . . . . . . . . . . . . . 64
14.3. draft-behringer-anima-autonomic-control-plane-01 . . . . 54 15.2. draft-behringer-anima-autonomic-control-plane-00 . . . . 64
14.4. draft-behringer-anima-autonomic-control-plane-02 . . . . 54 15.3. draft-behringer-anima-autonomic-control-plane-01 . . . . 64
14.5. draft-behringer-anima-autonomic-control-plane-03 . . . . 54 15.4. draft-behringer-anima-autonomic-control-plane-02 . . . . 64
14.6. draft-ietf-anima-autonomic-control-plane-00 . . . . . . 55 15.5. draft-behringer-anima-autonomic-control-plane-03 . . . . 65
14.7. draft-ietf-anima-autonomic-control-plane-01 . . . . . . 55 15.6. draft-ietf-anima-autonomic-control-plane-00 . . . . . . 65
14.8. draft-ietf-anima-autonomic-control-plane-02 . . . . . . 56 15.7. draft-ietf-anima-autonomic-control-plane-01 . . . . . . 65
14.9. draft-ietf-anima-autonomic-control-plane-03 . . . . . . 56 15.8. draft-ietf-anima-autonomic-control-plane-02 . . . . . . 66
14.10. draft-ietf-anima-autonomic-control-plane-04 . . . . . . 56 15.9. draft-ietf-anima-autonomic-control-plane-03 . . . . . . 66
14.11. draft-ietf-anima-autonomic-control-plane-05 . . . . . . 57 15.10. draft-ietf-anima-autonomic-control-plane-04 . . . . . . 66
14.12. draft-ietf-anima-autonomic-control-plane-06 . . . . . . 57 15.11. draft-ietf-anima-autonomic-control-plane-05 . . . . . . 67
14.13. draft-ietf-anima-autonomic-control-plane-07 . . . . . . 58 15.12. draft-ietf-anima-autonomic-control-plane-06 . . . . . . 67
14.14. draft-ietf-anima-autonomic-control-plane-08 . . . . . . 59 15.13. draft-ietf-anima-autonomic-control-plane-07 . . . . . . 68
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 61 15.14. draft-ietf-anima-autonomic-control-plane-08 . . . . . . 69
15.1. Normative References . . . . . . . . . . . . . . . . . . 61 15.15. draft-ietf-anima-autonomic-control-plane-09 . . . . . . 71
15.2. Informative References . . . . . . . . . . . . . . . . . 62 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 73
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63 16.1. Normative References . . . . . . . . . . . . . . . . . . 73
16.2. Informative References . . . . . . . . . . . . . . . . . 74
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76
1. Introduction 1. Introduction
Autonomic Networking is a concept of self-management: Autonomic Autonomic Networking is a concept of self-management: Autonomic
functions self-configure, and negotiate parameters and settings functions self-configure, and negotiate parameters and settings
across the network. [RFC7575] defines the fundamental ideas and across the network.[RFC7575] defines the fundamental ideas and design
design goals of Autonomic Networking. A gap analysis of Autonomic goals of Autonomic Networking. A gap analysis of Autonomic
Networking is given in [RFC7576]. The reference architecture for Networking is given in [RFC7576]. The reference architecture for
Autonomic Networking in the IETF is currently being defined in the Autonomic Networking in the IETF is currently being defined in the
document [I-D.ietf-anima-reference-model] document [I-D.ietf-anima-reference-model]
Autonomic functions need a stable and robust infrastructure to Autonomic functions need a stable and robust infrastructure to
communicate on. This infrastructure should be as robust as possible, communicate on. This infrastructure should be as robust as possible,
and it should be re-usable by all autonomic functions. [RFC7575] and it should be re-usable by all autonomic functions.[RFC7575] calls
calls it the "Autonomic Control Plane". This document defines the it the "Autonomic Control Plane". This document defines the
Autonomic Control Plane. Autonomic Control Plane.
Today, the management and control plane of networks typically runs in Today, the management and control plane of networks typically runs in
the global routing table, which is dependent on correct configuration the global routing table, which is dependent on correct configuration
and routing. Misconfigurations or routing problems can therefore and routing. Misconfigurations or routing problems can therefore
disrupt management and control channels. Traditionally, an out of disrupt management and control channels. Traditionally, an out of
band network has been used to recover from such problems, or band network has been used to recover from such problems, or
personnel is sent on site to access devices through console ports personnel is sent on site to access devices through console ports
(craft ports). However, both options are operationally expensive. (craft ports). However, both options are operationally expensive.
skipping to change at page 5, line 15 skipping to change at page 5, line 21
o A controller or network management system can use it to securely o A controller or network management system can use it to securely
bootstrap network devices in remote locations, even if the network bootstrap network devices in remote locations, even if the network
in between is not yet configured; no data-plane dependent in between is not yet configured; no data-plane dependent
bootstrap configuration is required. An example of such a secure bootstrap configuration is required. An example of such a secure
bootstrap process is described in bootstrap process is described in
[I-D.ietf-anima-bootstrapping-keyinfra] [I-D.ietf-anima-bootstrapping-keyinfra]
This document describes some use cases for the ACP in Section 3, it This document describes some use cases for the ACP in Section 3, it
defines the requirements in Section 4, Section 5 gives an overview defines the requirements in Section 4, Section 5 gives an overview
how an Autonomic Control Plane is constructed, and in Section 6 the how an Autonomic Control Plane is constructed, and in Section 6 the
detailed process is explained. Section 8 explains how non-autonomic detailed process is explained.Section 8 explains how non-autonomic
nodes and networks can be integrated, and Section 6.7 the first nodes and networks can be integrated, and Section 6.7 the first
channel types for the ACP. channel types for the ACP.
The document "Autonomic Network Stable Connectivity" The document "Autonomic Network Stable Connectivity"
[I-D.ietf-anima-stable-connectivity] describes how the ACP can be [I-D.ietf-anima-stable-connectivity] describes how the ACP can be
used to provide stable connectivity for OAM applications. It also used to provide stable connectivity for OAM applications. It also
explains on how existing management solutions can leverage the ACP in explains on how existing management solutions can leverage the ACP in
parallel with traditional management models, when to use the ACP parallel with traditional management models, when to use the ACP
versus the data plane, how to integrate IPv4 based management, etc. versus the data plane, how to integrate IPv4 based management, etc.
skipping to change at page 5, line 41 skipping to change at page 5, line 47
this document. It provides secure zero-touch network wide IPv6 this document. It provides secure zero-touch network wide IPv6
connectivity between devices supporting it. The ACP is primarily connectivity between devices supporting it. The ACP is primarily
meant to be used as a component of the ANI to enable Autonomic meant to be used as a component of the ANI to enable Autonomic
Networks but it can equally be used in simple ANI networks (with Networks but it can equally be used in simple ANI networks (with
no other Autonomic Functions) or completely by itself. no other Autonomic Functions) or completely by itself.
ACP address An IPv6 ULA address assigned to the ACP device. It is ACP address An IPv6 ULA address assigned to the ACP device. It is
stored in the ACP information field of an ACP devices LDevID. stored in the ACP information field of an ACP devices LDevID.
ACP connect A physical interface on an ACP device providing access ACP connect A physical interface on an ACP device providing access
to the ACP for non ACP capable devices. See Section 8.1. to the ACP for non ACP capable devices. See Section 8.1.1.
ACP device A device supporting the ACP according to this document. ACP device A device supporting the ACP according to this document.
ACP information (field) An rfc822Name information element (eg: ACP information (field) An rfc822Name information element (eg:
field) in the Domain Certificate in which the ACP relevant field) in the Domain Certificate in which the ACP relevant
information is encoded: the AN Domain Name and the ACP address. information is encoded: the AN Domain Name and the ACP address.
ACP (loopback) interface The loopback interface in the ACP VRF that ACP (loopback) interface The loopback interface in the ACP VRF that
hosts the ACP address. hosts the ACP address.
ACP (ULA) prefix(es) The prefixes routed across the ACP. In the
normal/simple case, the ACP has one ULA prefix, see Section 6.10.
The ACP routing table may include multiple ULA prefixes if the
"rsub" option is used to create addresses from more than one ULA
prefix. See Section 6.1.1. The ACP may also include non-ULA
prefixes if those are configured on ACP connect interfaces. See
Section 8.1.1.
ACP secure channel A virtual subinterface/tunnel established hop-by- ACP secure channel A virtual subinterface/tunnel established hop-by-
hop between adjacent ACP devices to carry traffic of the ACP VRF hop between adjacent ACP devices to carry traffic of the ACP VRF
separated from Data Plane traffic inband over the same links as separated from Data Plane traffic inband over the same links as
the Data Plane. the Data Plane.
ACP secure channel protocol The protocol used to build an ACP secure ACP secure channel protocol The protocol used to build an ACP secure
channel, eg: IKEv2/IPsec or dTLS. channel, eg: IKEv2/IPsec or dTLS.
ACP virtual interface An interface in the ACP VRF mapped to one or ACP virtual interface An interface in the ACP VRF mapped to one or
more ACP secure channels. See Section 6.12.4. more ACP secure channels. See Section 6.12.4.
ACP VRF The ACP is modelled in this document as a "Virtual Routing ACP VRF The ACP is modelled in this document as a "Virtual Routing
and Forwarding" (VRF) component in a network device. and Forwarding" (VRF) component in a network device.
AN "Autonomic Network". A network according to AN "Autonomic Network". A network according to
[I-D.ietf-anima-reference-model]. Its main components are Intent, [I-D.ietf-anima-reference-model]. Its main components are Intent,
Autonomic Functions and ANI. Autonomic Functions and ANI.
AN Domain Name A string name (typically in a format of a DNS domain AN Domain Name An FQDN (Fully Qualified Domain Name) identifying an
name) identifying an Autonomic Network. It is stored in the ACP Autonomic Network. It is stored in the ACP information field of
information field of an ANI devices LDevID. an ANI devices LDevID. See Section 6.1.1.
ANI (device/network) "Autonomic Network Infrastructure". A device ANI (device/network) "Autonomic Network Infrastructure". A device
with ANI supports ACP, BRSKI and GRASP. The ANI is the with ANI supports ACP, BRSKI and GRASP. The ANI is the
infrastructure to enable autonomic functions. An ANI network or infrastructure to enable autonomic functions. An ANI network or
device is a most basic Autonomic Network or device: it does not device is a most basic Autonomic Network or device: it does not
need to have ASAs other than the ones implementing ACP, BRSKI and need to have ASAs other than the ones implementing ACP, BRSKI and
GRASP nor Intent support. A simple ANI network (without further GRASP nor Intent support. A simple ANI network (without further
autonomic functions) can for example support secure zero touch autonomic functions) can for example support secure zero touch
bootstrap and stble connectivity for SDN networks - see bootstrap and stble connectivity for SDN networks - see
[I-D.ietf-anima-stable-connectivity]. [I-D.ietf-anima-stable-connectivity].
skipping to change at page 12, line 39 skipping to change at page 13, line 7
Example: Example:
anima.acp+fda379A6f6ee00000200000064000001+area51.research@acp.exampl anima.acp+fda379A6f6ee00000200000064000001+area51.research@acp.exampl
e.com e.com
The acp-address MUST be specified as a string of 32 hex characters The acp-address MUST be specified as a string of 32 hex characters
with only lower letters a-f and numbers 0-9 so that the local part of with only lower letters a-f and numbers 0-9 so that the local part of
the address can matches the simple dot-atom format of [RFC5322] (":" the address can matches the simple dot-atom format of [RFC5322] (":"
are not allowed in that format). are not allowed in that format).
<domain> is used to indicate the autonomic "domain" across which all <domain> is used to indicate the Autonomic Domain across which all
ACP nodes trust each other and are willing to build ACP channel with ACP nodes trust each other and are willing to build ACP channel with
each other. See Section 6.6. each other. See Section 6.6. It SHOULD be the FQDN of a domain
owned by the operator assigning the certificate. This is a simple
method to ensure that the domain name is globally unique and
collision of ACP addresses would therefore only happen due to ULA
hash collisions. If the operator does not own any FQDN, it should
choose am FQDN format string that intends to be equally unique.
{<rsub>.}<domain> is the autonomic "routing subdomain" that is used {<rsub>.}<domain> is the autonomic "routing subdomain" that is used
used in addressing to calculate the hash used in the creation of the used in addressing to calculate the hash used in the creation of the
ACP address of the device. As the name implies, every routing ACP address of the device. As the name implies, every routing
subdomain is also a separate routing subdomain. <rsub> is optional subdomain is also a separate routing subdomain. <rsub> is optional
and should only used when its impacts are understood. The domain and should only used when its impacts are understood. The domain
without any leading rsub field is also just another routing without any leading rsub field is also just another routing
subdomain. subdomain.
The optional <extensions> field is used for future extensions to this The optional <extensions> field is used for future extensions to this
skipping to change at page 14, line 26 skipping to change at page 15, line 5
The ACP network MUST have one or more nodes that support EST server The ACP network MUST have one or more nodes that support EST server
([RFC7030] functionality (eg: as an ASA) through which ACP nodes can ([RFC7030] functionality (eg: as an ASA) through which ACP nodes can
renew their domain certificate. The ACP address of at least one such renew their domain certificate. The ACP address of at least one such
EST server SHOULD have been enrolled/provisioned into the ACP device EST server SHOULD have been enrolled/provisioned into the ACP device
during initial installation of the domain certificate. during initial installation of the domain certificate.
EST servers MUST announce their service via GRASP in the ACP through EST servers MUST announce their service via GRASP in the ACP through
M_FLOOD messages: M_FLOOD messages:
Example: Example:
[M_FLOOD, 12340815, h'fda379a6f6ee0000200000064000001', 180000, [M_FLOOD, 12340815, h'fda379a6f6ee0000200000064000001', 180000,
["AN_join_registrar", SYNCH-FLAG, 255, "EST-TLS"], ["AN_join_registrar", SYNCH-FLAG, 255, "EST-TLS"],
[O_IPv6_LOCATOR, [O_IPv6_LOCATOR,
h'fda379a6f6ee0000200000064000001', TCP, 80] h'fda379a6f6ee0000200000064000001', TCP, 80]
] ]
The formal CDDL definition is: The formal CDDL definition is:
flood-message = [M_FLOOD, session-id, initiator, ttl, flood-message = [M_FLOOD, session-id, initiator, ttl,
+[objective, (locator-option / [])]] +[objective, (locator-option / [])]]
objective = ["AN_join_registrar", objective-flags, loop-count, objective = ["AN_join_registrar", objective-flags, loop-count,
objective-value] objective-value]
objective-flags = SYNCH-FLAG ; as in GRASP spec objective-flags = SYNCH-FLAG ; as in GRASP spec
loop-count = 255 ; mandatory maximum loop-count = 255 ; mandatory maximum
objective-value = text ; name of the (list of) of supported objective-value = text ; name of the (list of) of supported
; protocols: "EST-TLS" for RFC7030. ; protocols: "EST-TLS" for RFC7030.
The M_FLOOD message MUST be sent periodic. The period is subject to The M_FLOOD message MUST be sent periodically. The period is subject
network administrator policy (EST server configuration). It must be to network administrator policy (EST server configuration). It must
so low that the aggregate amount of periodic M_FLOOD from all EST be so low that the aggregate amount of periodic M_FLOODs from all EST
servers causes negligible traffic across the ACP. servers causes negligible traffic across the ACP.
In the above (recommended) example the period could be 60 seconds and In the above (recommended) example the period could be 60 seconds and
the indicated ttl of 180000 msec means that the objective would the indicated ttl of 180000 msec means that the objective would
continuously be cached by ACP devices even when two out of three continuously be cached by ACP devices even when two out of three
messages are dropped in transit (which is unlikely because GRASP hop- messages are dropped in transit (which is unlikely because GRASP hop-
by-hop forwarding is realiable). by-hop forwarding is realiable).
The locator-option indicates the ACP transport address for the EST The locator-option indicates the ACP transport address for the EST
server. The loop-count MUST be sete to 255. When an ACP node server. The loop-count MUST be sete to 255. When an ACP node
skipping to change at page 16, line 42 skipping to change at page 17, line 22
connection should be established. connection should be established.
6.3. Neighbor Discovery with DULL GRASP 6.3. Neighbor Discovery with DULL GRASP
Because of the the considerations in Section 10.2, the ACP uses DULL Because of the the considerations in Section 10.2, the ACP uses DULL
(Discovery Unsolicited Link-Local) insecure instances of GRASP for (Discovery Unsolicited Link-Local) insecure instances of GRASP for
discovery of ACP neighbors. See section 3.5.2.2 of discovery of ACP neighbors. See section 3.5.2.2 of
[I-D.ietf-anima-grasp] for its formal definition. [I-D.ietf-anima-grasp] for its formal definition.
The ACP uses one instance of DULL GRASP for every physical L2 subnet The ACP uses one instance of DULL GRASP for every physical L2 subnet
of the ACP device to discovery physcially adjacent candidate ACP of the ACP device to discovery physically adjacent candidate ACP
neighbors. Ideally, all physcial interfaces SHOULD be brought up neighbors. Ideally, all physical interfaces SHOULD be brought up
enough so that ACP discovery can be performed and any physcially enough so that ACP discovery can be performed and any physically
connected interfaces with ACP neighbors can then be brought into the connected interfaces with ACP neighbors can then be brought into the
ACP even if the interface is otherwise not configured. Reception of ACP even if the interface is otherwise not configured. Reception of
packets on such otherwise unconfigure interfaces MUST be limited so packets on such otherwise unconfigure interfaces MUST be limited so
that at first only IPv6 link-local address assignment (SLAAC) and that at first only IPv6 link-local address assignment (SLAAC) and
DULL GRASP works and then only the following ACP secure channel setup DULL GRASP works and then only the following ACP secure channel setup
packets - but not any other unnecessary traffic (eg: no other link- packets - but not any other unnecessary traffic (eg: no other link-
local IPv6 transport stack responders for example). local IPv6 transport stack responders for example).
ACP discovery MUST NOT be enabled by default on any non-physcial ACP discovery MUST NOT be enabled by default on any non-physical
interfaces. See Section 8.2.2 how to enable and use ACP with auto- interfaces. In particular, ACP discovery MUST NOT run inside the
discovery across configured tunnels. ACP. See Section 8.2.2 how to enable and use ACP with auto-discovery
across configured tunnels.
See Section 7 for how ACP should be extended on L3/L2 devices. See Section 7 for how ACP should be extended on L3/L2 devices.
Note: If an ACP device also implements BRSKI (see Section 10.1) then Note: If an ACP device also implements BRSKI (see Section 10.1) then
the above considerations also apply to discovery for BRSKI. Each the above considerations also apply to discovery for BRSKI. Each
DULL instance of GRASP set up for ACP is then also used for the DULL instance of GRASP set up for ACP is then also used for the
discovery of a bootstrap proxy via BRSKI when the device does not discovery of a bootstrap proxy via BRSKI when the device does not
have a domain certificate. Discovery of ACP neighbors happens only have a domain certificate. Discovery of ACP neighbors happens only
when the device does have the certificate. The device therefore when the device does have the certificate. The device therefore
never needs to discover both a bootstrap proxy and ACP neighbor at never needs to discover both a bootstrap proxy and ACP neighbor at
skipping to change at page 19, line 12 skipping to change at page 19, line 42
Table, see Section 6.2 which then drives the further building of the Table, see Section 6.2 which then drives the further building of the
ACP to that neighbor. ACP to that neighbor.
6.4. Candidate ACP Neighbor Selection 6.4. Candidate ACP Neighbor Selection
An autonomic node must determine to which other autonomic nodes in An autonomic node must determine to which other autonomic nodes in
the adjacency table it should build an ACP connection. This is based the adjacency table it should build an ACP connection. This is based
on the information in the AN Adjacency table. on the information in the AN Adjacency table.
The ACP is by default established exclusively between nodes in the The ACP is by default established exclusively between nodes in the
same domain. This includes all routing subdomains. Section 10.5 same domain. This includes all routing subdomains.Section 10.5
explains how ACP connections across routing subdomains are special. explains how ACP connections across routing subdomains are special.
Future extensions to this document including Intent can change this Future extensions to this document including Intent can change this
default behaviour. Examples include: default behaviour. Examples include:
o Build the ACP across all domains that have a common parent domain. o Build the ACP across all domains that have a common parent domain.
For example ACP nodes with domain "example.com", nodes of For example ACP nodes with domain "example.com", nodes of
"example.com", "access.example.com", "core.example.com" and "example.com", "access.example.com", "core.example.com" and
"city.core.example.com" could all establish one single ACP. "city.core.example.com" could all establish one single ACP.
o ACP connections across domain with different CA (certificate o ACP connections across domains with different CA (certificate
authorities) could establish a common ACP by prior adding the authorities) could establish a common ACP by installing the
other domains CA as recognized trust anchors. alternate domains' CA into the trusted anchor store. This is an
executive management action that could easily be accomplished
through the control channel created by the ACP.
Since Intent is transported over the ACP, the first ACP connection a Since Intent is transported over the ACP, the first ACP connection a
node establishes is always following the default behaviour. See node establishes is always following the default behaviour. See
Section 10.5 for more details. Section 10.5 for more details.
The result of the candidate ACP neighbor selection process is a list The result of the candidate ACP neighbor selection process is a list
of adjacent or configured autonomic neighbors to which an ACP channel of adjacent or configured autonomic neighbors to which an ACP channel
should be established. The next step begins that channel should be established. The next step begins that channel
establishment. establishment.
skipping to change at page 21, line 27 skipping to change at page 22, line 8
domain certificate. This implies that any security association domain certificate. This implies that any security association
protocol MUST support certificate based authentication that can protocol MUST support certificate based authentication that can
support the following verification steps: support the following verification steps:
o The certificate is valid as proven by the security associations o The certificate is valid as proven by the security associations
protocol exchanges. protocol exchanges.
o The peers certificate is signed by the same CA as the devices o The peers certificate is signed by the same CA as the devices
domain certificate. domain certificate.
o If our devices certificate indicates a CDP or OCSP then the peers o If the device certificates indicate a CDP or OCSP then the peer's
certificate must be valid occrding to those (eg: OCSP check across certificate must be valid occording to those criteria. eg: OCSP
the ACP or not listed in the CRL). check across the ACP or not listed in the CRL.
o The peers certificate has a valid ACP information field o The peers certificate has a valid ACP information field
(subjectAltName / rfc822Name) and the domain name in that peers (subjectAltName / rfc822Name) and the domain name in that peers
ACP information field is the same as in the devices certificate. ACP information field is the same as in the devices certificate.
Note that future Intent rules may modify this for example in Note that future Intent rules may modify this for example in
support of subdomains. See Section 10.5. support of subdomains. See Section 10.5.
If the peers certificate fails any of these checks, the connection If the peers certificate fails any of these checks, the connection
attempt is aborted and an error logged (with throttling). attempt is aborted and an error logged (with throttling).
skipping to change at page 23, line 17 skipping to change at page 23, line 42
6.7.3. ACP Secure Channel Requirements 6.7.3. ACP Secure Channel Requirements
A baseline autonomic device MUST support IPsec natively and MAY A baseline autonomic device MUST support IPsec natively and MAY
support IPsec via GRE. A constrained autonomic device MUST support support IPsec via GRE. A constrained autonomic device MUST support
dTLS. Autonomic edge device connecting constrained areas with dTLS. Autonomic edge device connecting constrained areas with
baseline areas MUST therefore support IPsec and dTLS. baseline areas MUST therefore support IPsec and dTLS.
Autonomic devices need to specify in documentation the set of secure Autonomic devices need to specify in documentation the set of secure
ACP mechanisms they suppport. ACP mechanisms they suppport.
ACP secure channel MUST imediately be terminated when the lifetime of
any certificate in the chain used to authenticate the neighbor
expires or becomes revoked. Note that is is not standard behavior in
secure channel protocols such as IPsec because the certificate
authentication only influences the setup of the secure channel in
these protocols.
6.8. GRASP in the ACP 6.8. GRASP in the ACP
6.8.1. GRASP as a core service of the ACP 6.8.1. GRASP as a core service of the ACP
The ACP MUST run an instance of GRASP inside of it. It is a key part The ACP MUST run an instance of GRASP inside of it. It is a key part
of the ACP services. They function in GRASP that makes it of the ACP services. They function in GRASP that makes it
fundamental as a service is the ability for ACP wide service fundamental as a service is the ability for ACP wide service
discovery (called objectives in GRASP). In most other solution discovery (called objectives in GRASP). In most other solution
designs such distributed discovery does not exist at all or it was designs such distributed discovery does not exist at all or it was
added as an afterthought and relied upon inconsistently resulting in added as an afterthought and relied upon inconsistently resulting in
skipping to change at page 26, line 29 skipping to change at page 27, line 16
o OAM protocols no not require IPv4: The ACP may carry OAM o OAM protocols no not require IPv4: The ACP may carry OAM
protocols. All relevant protocols (SNMP, TFTP, SSH, SCP, Radius, protocols. All relevant protocols (SNMP, TFTP, SSH, SCP, Radius,
Diameter, ...) are available in IPv6. Diameter, ...) are available in IPv6.
6.10.2. The ACP Addressing Base Scheme 6.10.2. The ACP Addressing Base Scheme
The Base ULA addressing scheme for autonomic nodes has the following The Base ULA addressing scheme for autonomic nodes has the following
format: format:
8 40 2 78 8 40 2 78
+--+-----------------+------+------------------------------------------+ +--+-----------------+------+--------------------------------------+
|FD| hash(subdomain) | Type | (sub-scheme) | |FD| hash(subdomain) | Type | (sub-scheme) |
+--+-----------------+------+------------------------------------------+ +--+-----------------+------+--------------------------------------+
Figure 2: ACP Addressing Base Scheme Figure 2: ACP Addressing Base Scheme
The first 48 bits follow the ULA scheme, as defined in [RFC4193], to The first 48 bits follow the ULA scheme, as defined in [RFC4193], to
which a type field is added: which a type field is added:
o "FD" identifies a locally defined ULA address. o "FD" identifies a locally defined ULA address.
o The ULA "global ID" is set here to be a hash of the subdomain o The ULA "global ID" is set here to be a hash of the subdomain
name, which results in a pseudo-random 40 bit value. It is name, which results in a pseudo-random 40 bit value. It is
skipping to change at page 27, line 13 skipping to change at page 27, line 49
response to the CSR Attribute Request by the pledge. response to the CSR Attribute Request by the pledge.
o Type: This field allows different address sub-schemes in the o Type: This field allows different address sub-schemes in the
future. The goal is to start with a single sub-schemes, but to future. The goal is to start with a single sub-schemes, but to
allow for extensions later if and when required. This addresses allow for extensions later if and when required. This addresses
the "upgradability" requirement. Assignment of types for this the "upgradability" requirement. Assignment of types for this
field should be maintained by IANA. field should be maintained by IANA.
6.10.3. ACP Zone Addressing Sub-Scheme 6.10.3. ACP Zone Addressing Sub-Scheme
The sub-scheme defined here is defined by the Type value 0 (zero) in The sub-scheme defined here is defined by the Type value 00b (zero)
the base scheme. in the base scheme.
51 1 13 63 1 64 64
+---------------------+---+---------+-----------------------------+---+ +-----------------+---------+---++-----------------------------+---+
| (base scheme) | Z | Zone-ID | Device-ID | V | | (base scheme) | Zone-ID | Z || Device-ID |
| | | | Registrar-ID | Device-Number| | | | | || Registrar-ID | Device-Number| V |
+---------------------+---+---------+--------------+--------------+---+ +-----------------+---------+---++--------------+--------------+---+
48 15 50 13 1 48 15 1
Figure 3: ACP Zone Addressing Sub-Scheme Figure 3: ACP Zone Addressing Sub-Scheme
The fields are defined as follows: The fields are defined as follows:
o Z: MUST be 0. This is an unused bit in this scheme that allows
for another encoding scheme to be defined in the future with this
bit set to 1.
o Zone-ID: If set to all zero bits: The Device-ID bits are used as o Zone-ID: If set to all zero bits: The Device-ID bits are used as
an identifier (as opposed to a locator). This results in a non- an identifier (as opposed to a locator). This results in a non-
hierarchical, flat addressing scheme. Any other value indicates a hierarchical, flat addressing scheme. Any other value indicates a
zone. See section Section 6.10.3.1 on how this field is used in zone. See section Section 6.10.3.1 on how this field is used in
detail. detail.
o Z: MUST be 0.
o Device-ID: A unique value for each device. o Device-ID: A unique value for each device.
o V: Virtualization bit: 0: autonomic node base system; 1: a virtual The 64 bit Device-ID is derived and composed as follows:
context on an autonomic node.
The Device-ID is derived as follows: In an Autonomic Network, a o Registrar-ID (48 bit): A number unique inside the domain that
registrar is enrolling new devices. As part of the enrolment process identifies the registrar which assigned the Device-ID to the
the registrar assigns a number to the device, which is unique for device. A MAC address of the registrar can be used for this
this registrar, but not necessarily unique in the domain. The 64 bit purpose.
Device-ID is then composed as:
o 48 bit: Registrar ID, a number unique inside the domain that o Device-Number (Device-Number): A number which is unique for a
identifies the registrar which assigned the name to the device. A given registrar, to identify the device. This can be a
MAC address of the registrar can be used for this purpose. sequentially assigned number.
o 15 bit: Device number, a number which is unique for a given o V (1 bit): Virtualization bit: 0: Indicates the ACP itself
registrar, to identify the device. This can be a sequentially ("autonomic node base system); 1: Indicates the optional "host"
assigned number. context on the ACP device (see below).
When referring to the Device-ID of an ACP device overall, the V
bit(s) is/are always "0". This is also the address used in the ACP
information in the domain certificate. The V bit(s) identify the
bits the device can assign itself. The Device knows how many bits
those are from the addressing sub-scheme (see below for a Sub-Scheme
with more than one V-bit).
The "Device-ID" itself is unique in a domain (i.e., the Zone-ID is The "Device-ID" itself is unique in a domain (i.e., the Zone-ID is
not required for uniqueness). Therefore, a device can be addressed not required for uniqueness). Therefore, a device can be addressed
either as part of a flat hierarchy (zone ID = 0), or with an either as part of a flat hierarchy (zone ID = 0), or with an
aggregation scheme (any other zone ID). A address with zone-ID = 0 aggregation scheme (any other zone ID). A address with zone-ID = 0
is an identifier, with another zone-ID as a locator. See is an identifier, with another zone-ID as a locator. See
Section 6.10.3.1 for a description of the zone bits. Section 6.10.3.1 for a description of the zone bits.
The Virtual bit in this sub-scheme allows to easily add the ACP as a The Virtual bit in this sub-scheme allows to easily add the ACP as a
component to existing systems without causing problems in the port component to existing systems without causing problems in the port
number space between the services in the ACP and the existing system. number space between the services in the ACP and the existing system.
V:0 is the ACP router (autonomous node base ssystem), V:1 is the host V:0 is the ACP router (autonomous node base system), V:1 is the host
with pre-existing transport endpoints on it that could collide with with pre-existing transport endpoints on it that could collide with
the transport endpoints used by the AP router. The host can have a the transport endpoints used by the ACP router. The ACP host could
virtual p2p interface with the V:0 address as its router into the for example have a virtual p2p interface with the V:0 address as its
ACP. Depending on the SW design of systems, future ASA may use the router into the ACP. Depending on the SW design of ASA (outside the
V:0 or V:1 address. scope of this specification), they may use the V:0 or V:1 address.
The location of the V bit(s) at the end of the address allows to The location of the V bit(s) at the end of the address allows to
announce a single prefix for each autonomic node, while having announce a single prefix for each autonomic node. For example, in a
separate virtual contexts addressable directly. network with 20,000 ACP devices, this avoid 20,000 additional routes
in the routing table.
6.10.3.1. Usage of the Zone Field 6.10.3.1. Usage of the Zone Field
The "Zone-ID" allows for the introduction of structure in the The "Zone-ID" allows for the introduction of structure in the
addressing scheme. addressing scheme.
Zone = zero is the default addressing scheme in an autonomic domain. Zone = zero is the default addressing scheme in an autonomic domain.
Every autonomic node MUST respond to its ACP address with zone=0. Every autonomic node MUST respond to its ACP address with zone=0.
Used on its own this leads to a non-hierarchical address scheme, Used on its own this leads to a non-hierarchical address scheme,
which is suitable for networks up to a certain size. In this case, which is suitable for networks up to a certain size. In this case,
the addresses primarily act as identifiers for the nodes, and the addresses primarily act as identifiers for the nodes, and
aggregation is not possible. aggregation is not possible.
If aggregation is required, the 13 bit value allows for up to 8191 If aggregation is required, the 13 bit value allows for up to 8192
zones. The allocation of zone numbers may either happen zones. The allocation of zone numbers may either happen
automatically through a to-be-defined algorithm; or it could be automatically through a to-be-defined algorithm; or it could be
configured and maintained manually. configured and maintained manually.
If a device learns through an autonomic method or through If a device learns through an autonomic method or through
configuration that it is part of a zone, it MUST also respond to its configuration that it is part of a zone, it MUST also respond to its
ACP address with that zone number. In this case the ACP loopback is ACP address with that zone number. In this case the ACP loopback is
configured with two ACP addresses: One for zone 0 and one for the configured with two ACP addresses: One for zone 0 and one for the
assigned zone. This method allows for a smooth transition between a assigned zone. This method allows for a smooth transition between a
flat addressing scheme and an hierarchical one. flat addressing scheme and an hierarchical one.
skipping to change at page 29, line 9 skipping to change at page 30, line 4
configuration that it is part of a zone, it MUST also respond to its configuration that it is part of a zone, it MUST also respond to its
ACP address with that zone number. In this case the ACP loopback is ACP address with that zone number. In this case the ACP loopback is
configured with two ACP addresses: One for zone 0 and one for the configured with two ACP addresses: One for zone 0 and one for the
assigned zone. This method allows for a smooth transition between a assigned zone. This method allows for a smooth transition between a
flat addressing scheme and an hierarchical one. flat addressing scheme and an hierarchical one.
(Theoretically, the 13 bits for the Zone-ID would allow also for two (Theoretically, the 13 bits for the Zone-ID would allow also for two
levels of zones, introducing a sub-hierarchy. We do not think this levels of zones, introducing a sub-hierarchy. We do not think this
is required at this point, but a new type could be used in the future is required at this point, but a new type could be used in the future
to support such a scheme.) to support such a scheme.)
Note: The Zone-ID is one method to introduce structure or hierarchy Note: The Zone-ID is one method to introduce structure or hierarchy
into the ACP. Another way is the use of the routing subdomain field into the ACP. Another way is the use of the routing subdomain field
in the ACP that leads to different /40 ULA prefixes within an in the ACP that leads to different /40 ULA prefixes within an
autonomic domain. This gives followup work two options to consider. autonomic domain. This gives followup work two options to consider.
6.10.4. ACP V8 Addressing Sub-Scheme 6.10.4. ACP Manual Addressing Sub-Scheme
The sub-scheme defined here is defined by the Type value 1 (one) in The sub-scheme defined here is defined by the Type value 00b (zero)
in the base scheme.
64 64
+---------------------+---------+---++-----------------------------+
| (base scheme) |Subnet-ID| Z || Interface Identifier |
+---------------------+---------+---++-----------------------------+
50 13 1
Figure 4: ACP Manual Addressing Sub-Scheme
The fields are defined as follows:
o Subnet-ID: Configured subnet identifier.
o Z: MUST be 1.
o Interface Identifier.
This sub-scheme is meant for "manual" allocation to subnets where the
other addressing schemes can not be used. The primary use case is
for assignment to ACP connect subnets (see Section 8.1.1).
"Manual" means that allocations of the Subnet-ID need to be done
today with pre-existing, non-autonomic mechanisms. Every subnet that
uses this addressing sub-scheme needs to use a unique Subnet-ID
(unless some anycast setup is done). Future work may define
mechanisms for auto-coordination between ACP devices and auto-
allocation of Subnet-IDs between them.
The Z field is following the Subnet-ID field so that future work
could allocate/coordinate both Zone-ID and Subnet-ID consistently and
use an integrated aggregateable routing approach across them. Z=0
(Zone sub-scheme) would then be used for network wide unique,
registrar assigned (and certificate protected) Device-IDs primarily
for ACP devices while Z=1 would be used for device-level assigned
Interface Identifiers primarily for non-ACP-devices.
6.10.5. ACP Vlong Addressing Sub-Scheme
The sub-scheme defined here is defined by the Type value 01b (one) in
the base scheme. the base scheme.
51 63 8 50 78
+---------------------+-----------------------------+----------+ +---------------------++-----------------------------+----------+
| (base scheme) | Device-ID | V | | (base scheme) || Device-ID |
| | Registrar-ID | Device-Number| | | || Registrar-ID | Device-Number| V |
+---------------------+--------------+--------------+----------+ +---------------------++--------------+--------------+----------+
46 32 46 33/17 8/16
Figure 4: ACP V8 Addressing Sub-Scheme Figure 5: ACP Vlong Addressing Sub-Scheme
This addressing scheme foregoes the Zone field to allow for larger, This addressing scheme foregoes the Zone field to allow for larger,
flatter networks (eg: as in IoT) with up to 2^32 Device-Numbers. It flatter routed networks (eg: as in IoT) with more than 2^32 Device-
also allows for up to 2^8 - 256 different virtualized adddresses, Numbers. It also allows for up to 2^16 - 65536 different virtualized
which could be used to address individual linecards or the like. adddresses, which could be used to address individual software
components in an ACP device.
The fields are the same as in the Zone sub-scheme with the following The fields are the same as in the Zone sub-scheme with the following
refinements: refinements:
o V: Virtualization bit: Values 0 and 1 as in Zone sub-scheme, o V: Virtualization bit: Values 0 and 1 as in Zone sub-scheme,
values 2-255 for use via definition in followup work. further values use via definition in followup work.
o Registrar-ID: To maximize Device-Number and V, the Registrar-ID is o Registrar-ID: To maximize Device-Number and V, the Registrar-ID is
reduced to 46 bits. This still allows to use the MAC address of a reduced to 46 bits. This still allows to use the MAC address of a
registrar by removing the V and U bits from the 48 bits of a MAC registrar by removing the V and U bits from the 48 bits of a MAC
address (those two bits are never unique, so they can not be used address (those two bits are never unique, so they can not be used
to distinguish MAC addresses anyhow). to distinguish MAC addresses).
6.10.5. Other ACP Addressing Sub-Schemes o If the first bit of the "Device-Number" is "1", then the Device
number is 17 bit long and the V field is 16 bit long. Otherwise
the Device-Number is 33 bit long and the V field is 8 bit long.
"0" bit Device-Numbers are intended to be used for "general
purpose" ACP devices that would potentially have a limited number
(< 256) of internal users of the ACP that require separate
V(irtual) addresses. "1" bit Device-Numbers are intended for ACP
devices that are ACP edge devices (see Section 8.1.1) or that have
a large number of internal ACP users requiring separate V(irtual)
addresses. For example large SDN controllers with container
modular software architecture (see Section 8.1.2).
6.10.6. Other ACP Addressing Sub-Schemes
Other ACP addressing sub-schemes can be defined if and when required. Other ACP addressing sub-schemes can be defined if and when required.
IANA would need to assign a new "type" for each new addressing sub- IANA would need to assign a new "type" for each new addressing sub-
scheme. With the current allocations, 5 more schemes are possible scheme. With the current allocations, 5 more schemes are possible
without further reducing the number of bits in a future scheme. without further reducing the number of bits in a future scheme.
6.11. Routing in the ACP 6.11. Routing in the ACP
Once ULA address are set up all autonomic entities should run a Once ULA address are set up all autonomic entities should run a
routing protocol within the autonomic control plane context. This routing protocol within the autonomic control plane context. This
skipping to change at page 30, line 38 skipping to change at page 32, line 45
details. details.
6.11.1. RPL Profile 6.11.1. RPL Profile
The following is a description of the RPL profile that ACP nodes need The following is a description of the RPL profile that ACP nodes need
to support by default. The format of this section is derived from to support by default. The format of this section is derived from
draft-ietf-roll-applicability-template. draft-ietf-roll-applicability-template.
6.11.1.1. Summary 6.11.1.1. Summary
In summary, the profile choosen for RPL is one that expect a fairly In summary, the profile chosen for RPL is one that expects a fairly
reliable network reasonable fast links so that RPL convergence will reliable network reasonable fast links so that RPL convergence will
be triggered immediately upon recognition of link failure/recovery. be triggered immediately upon recognition of link failure/recovery.
The key limitation of the choosen profile is that it is design to not The key limitation of the chosen profile is that it is designed to
require any dataplane artefacts. The sender/receivers of ACP packets not require any dataplane artifacts (such as [RFC6553]). While the
can be legacy NOC devices connected via "ACP connect" (see senders/receivers of ACP packets can be legacy NOC devices connected
Section 8.1 to the ACP. These devices could not handle RPL data via "ACP connect" (see Section 8.1.1 to the ACP, their connectivity
plane artefacts. The profile also avoids the complexity of can be handled as non-RPL-aware leafs (or "Internet") accoding to the
performing IpinIP encap/decap on ACP routers to deal with non-RPL dataplane architecture explained in [I-D.ietf-roll-useofrplinfo].
dataplane artefacts. This non-artifact profile is largely driven by the desire to avoid
introducing the required Hop-by-Hop headers into the ACP VRF control
plane. Many devices will have their VRF forwarding code designed
into silicon.
In return for this profile choice, RPL has no dataplane artefacts and In this profile choice, RPL has no dataplane artifacts. A simple
install just a simple destination prefix based routing table. As a destination prefix based upon the routing table is used. A
downside it will only create a DODAG for one root which will be consequence of supporting only a single instanceID (containing one
either configured (eg: ACP connect NOC edge device) or a registrar DODAG), the ACP will only accomodate only a single class of routing
(likely the same ACP connect NOC edge device). Consider a network table and can not create optimized routing paths to accomplish
has multiple NOCs in different locations, then only paths to the one latency or energy goals.
NOC with the RPL root will be optimal, the other ones will not be
optimal. Consider a network that has multiple NOCs in different locations.
Only one NOC will become the DODAG root. Other NOCs will have to
send traffic through the DODAG (tree) rooted in the primary NOC.
Depending on topology, this can be an annoyance from a latency point
of view, but it does not represent a single point of failure, as the
DODAG can reconfigure itself when it detects data plane forwarding
failures.
The lack of a RPI (the header defined by [RFC6553]), means that the
dataplane will have no rank value that can be used to detect loops.
As a result, traffic may loop until the TTL of the packet reaches
zero. This the same behavior as that of other IGPs that do not have
the data plane options as RPPL. There are a variety of heuristics
that can be used to signal from the data plane to the RPL control
plane that a new route is needed.
Additionally, failed ACP tunnels will be detected by IKEv2 Dead Peer
Detection (which can function as a replacement for an LLN's ETX). A
failure of an ACP tunnel should signal the RPL control plane to pick
a different parent.
Future Extensions to this RPL profile can provide optimality for Future Extensions to this RPL profile can provide optimality for
multiple NOCs. This requires utilizing data plane artefacts multiple NOCs. This requires utilizing data plane artifact including
including IPinIP encap/decap on ACP routers and processing of IPv6 IPinIP encap/decap on ACP routers and processing of IPv6 RPI headers.
RPI headers. Alternatively (Src,Dst) routing table entries could be Alternatively (Src,Dst) routing table entries could be used. A
used. A decision for the preferred technology would have to be done decision for the preferred technology would have to be done when such
when such extension is defined. extension is defined.
6.11.1.2. RPL Instances 6.11.1.2. RPL Instances
Single RPL instance. Default RPLInstanceID = 0. Single RPL instance. Default RPLInstanceID = 0.
6.11.1.3. Storing vs. Non-Storing Mode 6.11.1.3. Storing vs. Non-Storing Mode
RPL Mode of Operations (MOP): mode 3 "Storing Mode of Operations with RPL Mode of Operations (MOP): mode 3 "Storing Mode of Operations with
multicast support". Implementations should support also other modes. multicast support". Implementations should support also other modes.
Note: Root indicates mode in DIO flow. Note: Root indicates mode in DIO flow.
skipping to change at page 32, line 38 skipping to change at page 35, line 19
6.11.1.9. Security 6.11.1.9. Security
[RFC6550] security not used, substituted by ACP security. [RFC6550] security not used, substituted by ACP security.
6.11.1.10. P2P communications 6.11.1.10. P2P communications
Not used. Not used.
6.11.1.11. IPv6 address configuration 6.11.1.11. IPv6 address configuration
Every ACP device (RPL node) announces an IPv7 prefix covering the Every ACP device (RPL node) announces an IPv6 prefix covering the
address(es) used internally in the ACP device. The prefix length address(es) used internally in the ACP device. The prefix length
depends on the choosen mode of the ACP address provisioned into the depends on the choosen addressing sub-scheme of the ACP address
certificate of the ACP device and is either /96 or /127. See provisioned into the certificate of the ACP device, eg: /127 for Zone
Section 6.10 for more details. addressing sub-scheme or /112 or /120 for Vlong addressing sub-
scheme. See Section 6.10 for more details.
Every ACP device MUST install a blackhole (aka null route) route for
whatever ACP address space that it advertises (i.e: the /96 or /127).
This is avoid routing loops for addresses that an ACP node has not
(yet) used.
6.11.1.12. Administrative parameters 6.11.1.12. Administrative parameters
Administrative Preference ([RFC6552], 3.2.6 - to become root): Administrative Preference ([RFC6552], 3.2.6 - to become root):
Indicated in DODAGPreference field of DIO message. Indicated in DODAGPreference field of DIO message.
o Explicit configured "root": 0b100 o Explicit configured "root": 0b100
o Registrar (Default): 0b011 o Registrar (Default): 0b011
o AN-connect (non registrar): 0b010 o AN-connect (non registrar): 0b010
o Default: 0b001. o Default: 0b001.
6.11.1.13. RPL Dataplane artifacts 6.11.1.13. RPL Dataplane artifacts
RPI (RPL Packet Information): Not used. Because we are only using a RPI (RPL Packet Information [RFC6553]): Not used as there is only a
single instance and because we are not using data path validation. single instance, and data path validation is not being used.
SRH (RPL Source Routing - RFC6552): Not used. Because we are using SRH (RPL Source Routing - RFC6552): Not used. Storing mode is being
storing mode. used.
6.11.1.14. Unknown Destinations
Because RPL minimizes the size of the routing and forwarding table,
prefixes reachable through the same interface as the RPL root are not
known on every ACP device. Therefore traffic to unknown destination
addresses can only be discovered at the RPL root. The RPL root
SHOULD have attach safe mechanisms to operationally discover and log
such packets.
6.12. General ACP Considerations 6.12. General ACP Considerations
Since channels are by default established between adjacent neighbors, Since channels are by default established between adjacent neighbors,
the resulting overlay network does hop by hop encryption. Each node the resulting overlay network does hop by hop encryption. Each node
decrypts incoming traffic from the ACP, and encrypts outgoing traffic decrypts incoming traffic from the ACP, and encrypts outgoing traffic
to its neighbors in the ACP. Routing is discussed in Section 6.11. to its neighbors in the ACP. Routing is discussed in Section 6.11.
6.12.1. Addressing of Secure Channels in the data plane 6.12.1. Addressing of Secure Channels in the data plane
In order to be independent of the Data Plane configuration of global In order to be independent of the Data Plane configuration of global
IPv6 subnet addresses (that may not exist when the ACP is brought IPv6 subnet addresses (that may not exist when the ACP is brought
up), Link-local secure channels MUST use IPv6 link local addresses up), Link-local secure channels MUST use IPv6 link local addresses
between adjacent neighbors. The fully autonomic mechanisms in this between adjacent neighbors. The fully autonomic mechanisms in this
document only specify these link-local secure channels. Section 8.2 document only specify these link-local secure channels.Section 8.2
specify extensions in which secure channels are tunnels, then this specify extensions in which secure channels are tunnels, then this
requirement does not apply. requirement does not apply.
The Link-local secure channels specified in this document therefore The Link-local secure channels specified in this document therefore
depend on basic IPv6 link-local functionality to be auto-enabled by depend on basic IPv6 link-local functionality to be auto-enabled by
the ACP and prohibiting the Data Plane from disabling it. The ACP the ACP and prohibiting the Data Plane from disabling it. The ACP
also depends on being able to operate the secure channel protocol also depends on being able to operate the secure channel protocol
(eg: IPsec / dTLS) across IPv6 link-local addresses, something that (eg: IPsec / dTLS) across IPv6 link-local addresses, something that
may be an uncommon profile. Functionaly, these are the only may be an uncommon profile. Functionaly, these are the only
interactions with the Data Plane that the ACP needs to have. interactions with the Data Plane that the ACP needs to have.
skipping to change at page 35, line 15 skipping to change at page 38, line 12
channel is mapped into a separate point-to-point ACP virtual channel is mapped into a separate point-to-point ACP virtual
interface. If a physical subnet has more than two ACP capable nodes interface. If a physical subnet has more than two ACP capable nodes
(in the same domain), this implementation approach will lead to a (in the same domain), this implementation approach will lead to a
full mesh of ACP virtual interfaces between them. In a more advanced full mesh of ACP virtual interfaces between them. In a more advanced
implementation approach, the ACP will construct a single multi-access implementation approach, the ACP will construct a single multi-access
ACP virtual interface for all ACP secure channels to ACP capable ACP virtual interface for all ACP secure channels to ACP capable
nodes reachable across the same physical subnet. The multi-access nodes reachable across the same physical subnet. The multi-access
ACP virtual interace needs to replicate link-local IPv6 multicast ACP virtual interace needs to replicate link-local IPv6 multicast
packets sent into the interface towards all ACP secure channels packets sent into the interface towards all ACP secure channels
mapped into it. There is no need for all ACP capable nodes on the mapped into it. There is no need for all ACP capable nodes on the
same physcial multi-access subnet to agree on a common implementation same physical multi-access subnet to agree on a common implementation
approach. This is purely a node local decision. approach. This is purely a node local decision.
Multi-access ACP virtual interfaces are preferrable because they do Multi-access ACP virtual interfaces are preferrable because they do
reflect the presence of a multi-access physcial networks into the reflect the presence of a multi-access physical networks into the
virtual interfaces of the ACP. This makes it for example simpler to virtual interfaces of the ACP. This makes it for example simpler to
build services with topology awareness inside the ACP VRF in the same build services with topology awareness inside the ACP VRF in the same
way as they could habe been built running natively on the multi- way as they could habe been built running natively on the multi-
access interfaces. One example is the efficiency of flooding of access interfaces. One example is the efficiency of flooding of
GRASP messages. Assume such a LAN with three ACP neighbors, Alice GRASP messages. Assume such a LAN with three ACP neighbors, Alice
Bob and Carol. Alice sends a GRASP link-local multicast message to Bob and Carol. Alice sends a GRASP link-local multicast message to
Bob and Carol. If Alices ACP emulates the LAN as one point-to-point Bob and Carol. If Alices ACP emulates the LAN as one point-to-point
interface to Bob and one to Carol, GRASP itself will send two copies, interface to Bob and one to Carol, GRASP itself will send two copies,
if Alices ACP emulates a LAN, GRASP will send one packet and the ACP if Alices ACP emulates a LAN, GRASP will send one packet and the ACP
will replicate it. The result is the same. The difference happens will replicate it. The result is the same. The difference happens
skipping to change at page 36, line 6 skipping to change at page 39, line 4
access LANs into multi-access ACP virtual interfaces. access LANs into multi-access ACP virtual interfaces.
Care must be taken when creating multi-access ACP virtual interfaces Care must be taken when creating multi-access ACP virtual interfaces
across ACP secure channels between ACP devices in different domains across ACP secure channels between ACP devices in different domains
or routing subdomains. The policies to be negotiated may be or routing subdomains. The policies to be negotiated may be
described as peer-to-peer policies in which case it is easier to described as peer-to-peer policies in which case it is easier to
create point-to-point ACP virtual interfaces for these secure create point-to-point ACP virtual interfaces for these secure
channels. channels.
7. ACP support on L2 switches/ports (Normative) 7. ACP support on L2 switches/ports (Normative)
7.1. Why 7.1. Why
ANrtr1 ------ ANswitch1 --- ANswitch2 ------- ANrtr2 ANrtr1 ------ ANswitch1 --- ANswitch2 ------- ANrtr2
.../ \ \ ... .../ \ \ ...
ANrtrM ------ \ ------- ANrtrN ANrtrM ------ \ ------- ANrtrN
ANswitchM ... ANswitchM ...
Figure 5 Figure 6
Consider a large L2 LAN with ANrtr1...ANrtrN connected via some Consider a large L2 LAN with ANrtr1...ANrtrN connected via some
topology of L2 switches. Examples include large enterprise campus topology of L2 switches. Examples include large enterprise campus
networks with an L2 core, IoT networks or broadband aggregation networks with an L2 core, IoT networks or broadband aggregation
networks which often have even a multi-level L2 switched topology. networks which often have even a multi-level L2 switched topology.
If the discovery protocol used for the ACP is operating at the subnet If the discovery protocol used for the ACP is operating at the subnet
level, every AN router will see all other AN routers on the LAN as level, every AN router will see all other AN routers on the LAN as
neighbors and a full mesh of ACP channels will be built. If some or neighbors and a full mesh of ACP channels will be built. If some or
all of the AN switches are autonomic with the same discovery all of the AN switches are autonomic with the same discovery
skipping to change at page 36, line 41 skipping to change at page 39, line 38
any other ACP operations (such as routing) needs to scale to the any other ACP operations (such as routing) needs to scale to the
number of direct ACP neigbors. An AN router with just 4 interfaces number of direct ACP neigbors. An AN router with just 4 interfaces
might be deployed into a LAN with hundreds of neighbors connected via might be deployed into a LAN with hundreds of neighbors connected via
switches. Introducing such a new unpredictable scaling factor switches. Introducing such a new unpredictable scaling factor
requirement makes it harder to support the ACP on arbitrary platforms requirement makes it harder to support the ACP on arbitrary platforms
and in arbitrary deployments. and in arbitrary deployments.
Predictable scaling requirements for ACP neighbors can most easily be Predictable scaling requirements for ACP neighbors can most easily be
achieved if in topologies like these, AN capable L2 switches can achieved if in topologies like these, AN capable L2 switches can
ensure that discovery messages terminate on them so that neighboring ensure that discovery messages terminate on them so that neighboring
AN routers and switches will only find the physcially connected AN L2 AN routers and switches will only find the physically connected AN L2
switches as their candidate ACP neighbors. With such a discovery switches as their candidate ACP neighbors. With such a discovery
mechanism in place, the ACP and its security associations will only mechanism in place, the ACP and its security associations will only
need to scale to the number of physcial interfaces instead of a need to scale to the number of physical interfaces instead of a
potentially much larger number of "LAN-connected" neighbors. And the potentially much larger number of "LAN-connected" neighbors. And the
ACP topology will follow directly the physical topology, something ACP topology will follow directly the physical topology, something
which can then also be leveraged in management operations or by ASAs. which can then also be leveraged in management operations or by ASAs.
In the example above, consider ANswitch1 and ANswitchM are AN In the example above, consider ANswitch1 and ANswitchM are AN
capable, and ANswitch2 is not AN capable. The desired ACP topology capable, and ANswitch2 is not AN capable. The desired ACP topology
is therefore that ANrtr1 and ANrtrM only have an ACP connetion to is therefore that ANrtr1 and ANrtrM only have an ACP connetion to
ANswitch1, and that ANswitch1, ANrtr2, ANrtrN have a full mesh of ACP ANswitch1, and that ANswitch1, ANrtr2, ANrtrN have a full mesh of ACP
connection amongst each other. ANswitch1 also has an ACP connection connection amongst each other. ANswitch1 also has an ACP connection
with ANswitchM and ANswitchM has ACP connections to anything else with ANswitchM and ANswitchM has ACP connections to anything else
skipping to change at page 38, line 41 skipping to change at page 41, line 39
also across ports that are blocked in STP so that the ACP does not also across ports that are blocked in STP so that the ACP does not
depend on STP and can continue to run unaffected across STP topology depend on STP and can continue to run unaffected across STP topology
changes (where reconvergence can be quite slow). The above described changes (where reconvergence can be quite slow). The above described
simple implementation options are not sufficient for this. Instead simple implementation options are not sufficient for this. Instead
they would simply have the ACP run across the active STP topology and they would simply have the ACP run across the active STP topology and
therefore the ACP would equally be interrupted and reconverge with therefore the ACP would equally be interrupted and reconverge with
STP changes. STP changes.
L3/L2 devices SHOULD support per-L2 port ACP. L3/L2 devices SHOULD support per-L2 port ACP.
8. Workarounds for Non-Autonomic Nodes (Normative) 8. Support for Non-Autonomic Components (Normative)
8.1. Non-Autonomic Controller / NMS system (ACP connect) 8.1. ACP Connect
8.1.1. Non-Autonomic Controller / NMS system
The Autonomic Control Plane can be used by management systems, such The Autonomic Control Plane can be used by management systems, such
as controllers or network management system (NMS) hosts (henceforth as controllers or network management system (NMS) hosts (henceforth
called simply "NMS hosts"), to connect to devices through it. For called simply "NMS hosts"), to connect to devices through it. For
this, an NMS host must have access to the ACP. The ACP is a self- this, an NMS host must have access to the ACP. The ACP is a self-
protecting overlay network, which allows by default access only to protecting overlay network, which allows by default access only to
trusted, autonomic systems. Therefore, a traditional, non-autonomic trusted, autonomic systems. Therefore, a traditional, non-autonomic
NMS system does not have access to the ACP by default, just like any NMS system does not have access to the ACP by default, just like any
other external device. other external device.
If the NMS host is not autonomic, i.e., it does not support autonomic If the NMS host is not autonomic, i.e., it does not support autonomic
negotiation of the ACP, then it can be brought into the ACP by negotiation of the ACP, then it can be brought into the ACP by
explicit configuration. To support connections to adjacent non- explicit configuration. To support connections to adjacent non-
autonomic nodes, an autonomic node with ACP must support "ACP autonomic nodes, an autonomic node with ACP must support "ACP
connect" (sometimes also connect "autonomic connect"): connect" (sometimes also connect "autonomic connect"):
"ACP connect" is a function on an autonomic device that we call an "ACP connect" is a function on an autonomic device that is called an
"ACP edge device". With "ACP connect", interfaces on the device can "ACP edge device". With "ACP connect", interfaces on the device can
be configured to be put into the ACP VRF. The ACP is then accessible be configured to be put into the ACP VRF. The ACP is then accessible
to other (NOC) systems on such an interface without those systems to other (NOC) systems on such an interface without those systems
having to support any ACP discovery or ACP channel setup. This is having to support any ACP discovery or ACP channel setup. This is
also called "native" access to the ACP because to those (NOC) systems also called "native" access to the ACP because to those (NOC) systems
the interface looks like a normal network interface (without any the interface looks like a normal network interface (without any
encryption/novel-signaling). encryption/novel-signaling).
data-plane "native" (no ACP) data-plane "native" (no ACP)
. .
+-----------+ +-----------+ . +-------------+ +--------+ +----------------+ . +-------------+
| | | Autonomic | v | |+ | ACP | |ACP Edge Device | . | |
| | | Device |-----------------| |+ | Device | | | v | |
| Autonomic |-----------|"ACP edge | | NOC Device || | |-------|...[ACP VRF]....+-----------------| |+
| Device | ^ | device" O-----------------| "NMS hosts" || | | ^ |. | | NOC Device ||
| | . | | . ^ | || | | . | .[Data Plane]..+-----------------| "NMS hosts" ||
+-----------+ . +-----------+ . . +-------------+| | | . | [ VRF ] | . ^ | ||
. . . +-------------+ +--------+ . +----------------+ . . +-------------+|
data-plane "native" . ACP "native" (unencrypted) . . . +-------------+
+ ACP auto-negotiated . . . .
and encrypted ACP connect interface data-plane "native" . ACP "native" (unencrypted)
+ ACP auto-negotiated . "ACP connect subnet"
and encrypted .
ACP connect interface
eg: "vrf ACP native" (config) eg: "vrf ACP native" (config)
Figure 6: ACP connect Figure 7: ACP connect
ACP connect has security consequences: All systems and processes ACP connect has security consequences: All systems and processes
connected via ACP connect have access to all autonomic nodes on the connected via ACP connect have access to all autonomic nodes on the
entire ACP, without further authentication. Thus, the ACP connect entire ACP, without further authentication. Thus, the ACP connect
interface and (NOC) systems connected to it must be physically interface and (NOC) systems connected to it must be physically
controlled/secured. controlled/secured. For this reason the mechanisms described here do
explicitly not include options to allow for a non-ACP router to be
The ACP connect interface must be configured with some IPv6 address connected across an ACP connect interface and addresses behind such a
prefix. This prefix could use the ACP address prefix or could be router routed inside the ACP.
different. It must be distributed into the ACP routing protocol
unless the ACP device is the root of the ACP routing protocol (eg:
when all other autonomic devices have a default route in the ACP
towards it). The NOC hosts must route the ACP address prefix to the
ACP edge devices address on the ACP connect interface.
An ACP connect interface provides exclusively access to only the ACP. An ACP connect interface provides exclusively access to only the ACP.
This is likely insufficient for many NOC hosts. Instead, they would This is likely insufficient for many NMS hosts. Instead, they would
likely require a second interface outside the ACP for connections require a second "data-plane" interface outside the ACP for
between the NMS host and administrators, or Internet based services, connections between the NMS host and administrators, or Internet
or even for direct access to the data plane. The document "Autonomic based services, or for direct access to the data plane. The document
Network Stable Connectivity" [I-D.ietf-anima-stable-connectivity] "Autonomic Network Stable Connectivity"
explains in more detail how the ACP can be integrated in a mixed NOC [I-D.ietf-anima-stable-connectivity] explains in more detail how the
environment. ACP can be integrated in a mixed NOC environment.
Note: If an NMS host is autonomic itself, it negotiates access to the The ACP connect interface must be (auto-)configured with an IPv6
ACP with its neighbor, like any other autonomic node and then runs a address prefix. Is prefix SHOULD be covered by one of the (ULA)
normal (encrypted) ACP connection to the neighbor. prefix(es) used in the ACP. If using non-autonomic configuration, it
SHOULD use the ACP Manual Addressing Sub-Scheme (Section 6.10.4). It
SHOULD NOT use a prefix that is also routed outside the ACP so that
the addresses clearly indicate whether it is used inside the ACP or
not.
The prefix of ACP connect subnets MUST be distributed by the ACP edge
device into the ACP routing protocol (RPL). The NMS hosts MUST
connect to prefixes in the ACP routing table via its ACP connect
interface. In the simple case where the ACP usesonly one ULA prefix
and all ACP connect subnets have prefixes covered by that ULA prefix,
NMS hosts can rely on [RFC6724] - The NMS host will select the ACP
connect interface because any ACP destination address is best matched
by the address on the ACP connect interface. If the NMS hosts ACP
connect interface uses another prefix or if the ACP uses multiple ULA
prefixes, then the NMS hosts require (static) routes towards the ACP
interface.
ACP Edge Device MUST only forward IPv6 packets received from an ACP
connect interface into the ACP that has an IPv6 address from the ACP
prefix assigned to this interface (sometimes called "RPF filtering").
This MAY be changed through administrative measures.
To limit the security impact of ACP connect, devices supporting it
SHOULD implement a security mechanism to allow configuration/use of
ACP connect interfaces only on devices explicitly targeted to be
deployed with it (such as those physically secure locations like a
NOC). For example, the certificate of such devices could include an
extension required to permit configuration of ACP connect interfaces.
This prohibits that a random ACP device with easy physical access
that is not meant to run ACP connect could start leaking the ACP when
it becomes compromised and the intruder configures ACP connect on it.
The full workflow including the mechanism by which a registrar would
select which device to give such a certificate to is subject to
future work.
8.1.2. Software Components
The ACP connect mechanism be only be used to connect physically
external systems (NMS hosts) to the ACP but also other applications,
containers or virtual machines. In fact, one possible way to
eliminate the security issue of the external ACP connect interface is
to collocate an ACP edge device and an NMS host by making one a
virtual machine or container inside the other - and therefore
converting the unprotected external ACP subnet into an internal
virtual subnet in a single device. This would ultimately result in a
fully autonomic NMS host with minimum impact to the NMS hosts
software architecture. This approach is not limited to NMS hosts but
could equally be applied to devices consisting of one or more VNF
(virtual network functions): An internal virtual subnet connecting
out-of-band-management interfaces of the VNFs to an ACP edge router
VNF.
The core requirement is that the software components need to have a
network stack that permits access to the ACP and optionally also the
data plane. Like in the physical setup for NMS hosts this can be
realized via two internal virtual subnets. One that is connecting to
the ACP (which could be a container or virtual machine by itself),
and one (or more) connecting into the data plane.
This "internal" use of ACP connect approach should not considered to
be a "workaround" because in this case it is possible to build a
correct security model: It is not necessary to rely on unprovable
external physical security mechanisms as in the case of external NMS
hosts. Instead, the orchestration of the ACP, the virtual subnets
and the software components can be done by trusted software that
could be considered to be part of the ANI (or even an extended ACP).
This software component is responsible to ensure that only trusted
software components will get access to that virtual subnet and that
only even more trusted software components will get access to both
the ACP virtual subnet and the data plane (because those ACP users
could leak traffic between ACP and data plane). This trust could be
established for example through cryptographic means such signed
software packages. The specification of these mechanisms is subject
to future work.
Note that ASA (Autonomic Software Agents) could also be software
components as described in this section, but further details of ASAs
are subject to future work.
8.1.3. Auto Configuration
ACP edge devices, NMS hosts and software components that as describd
in the previous section are meant to be composed via virtual
interfaces SHOULD support on the ACP connect subnet Stateless Address
Autoconfiguration (SLAAC - [RFC4862]) and route autoconfiguration
according to [RFC4191].
The ACP edge device acts as the router on the ACP connect subnet,
providing the (auto-)configured prefix for the ACP connect subnet to
NMS hosts and/or software components. The ACP edge device uses route
prefix option of RFC4191 to announce the default route (::/) with a
lifetime of 0 and aggregated prefixes for routes in the ACP routing
table with normal lifetimes. This will ensure that the ACP edge
device does not become a default router, but that the NMS hosts and
software components will route the prefixes used in the ACP to the
ACP edge device.
Aggregated prefix means that the ACP edge device needs to only
announce the /48 ULA prefixes used in the ACP but none of the actual
/64 (Manual Addressing Sub-Scheme), /127 (Zone Addressing Sub-
Scheme), /112 or /120 (Vlong Addressing Sub-Scheme) routes of actual
ACP devices. If ACP interfaces are configured with non ULA prefixes,
then those prefixes can not be aggreged without further configured
policy on the ACP edge device. This explains the above
recommendation to use ACP ULA prefix covered prefixes for ACP connect
interfaces: They allow for a shorter list of prefixes to be signalled
via RFC4191 to NMS hosts and software components.
The ACP edge devices that have a Vlong ACP address MAY allocate a
subset of their /112 or /120 address prefix to ACP connect
interface(s) to eliminate the need to non-autonomically configure/
provision the address prefixes for such ACP connect interfaces. See
Section 11 for considerations how this updates the IPv6 address
architecture and ULA specification.
8.1.4. Combined ACP and Data Data Plane Interface (VRF Select)
Combined ACP and Data Plane interface
.
+--------+ +--------------------+ . +--------------+
| ACP | |ACP Edge Device | . | NMS Host(s) |
| Device | | | . | / Software |
| | | [ACP ]. | . | |+
| | | .[VRF ] .[VRF ] | v | "ACP address"||
| +-------+. .[Select].+--------+ "Date Plane ||
| | ^ | .[Data ]. | | Address(es)"||
| | . | [Plane] | | ||
| | . | [VRF ] | +--------------+|
+--------+ . +--------------------+ +--------------+
.
data-plane "native" and + ACP auto-negotiated/encrypted
Figure 8: VRF select
Using two physical and/or virtual subnets (and therefore interfaces)
into NMS Hosts (as per Section 8.1.1) or Software (as per
Section 8.1.2) may be seen as additional complexity, for example with
legacy NMS Hosts that support only one IP interface.
To provide a single subnet into both ACP and Data Plane, the ACP Edge
device needs to demultiplex packets from NMS hosts into ACP VRF and
Data Plane VRF. This is sometimes called "VRF select". If the ACP
VRF has no overlapping IPv6 addresses with the Data Plane (as it
should), then this function can use the IPv6 Destination address.
The problem is Source Address Selection on the NMS Host(s) according
to RFC6724.
Consider the simple case: The ACP uses only one ULA prefix, the ACP
IPv6 prefix for the Combined ACP and Data Plane interface is covered
by that ULA prefix. The ACP edge device announces both the ACP IPv6
prefix and one (or more) prefixes for the data plane. Without
further policy configurations on the NMS Host(s), it may select its
ACP address as a source address for Data Plane ULA destinations
because of Rule 8 of RFC6724. The ACP edge device can pass on the
packet to the Data Plane, but the ACP source address should not be
used for Data Plane traffic, and return traffic may fail.
If the ACP carries multiple ULA prefixes or non-ULA ACP connect
prefixes, then the correct source address selection becomes even more
problematic.
With separate ACP connect and Data Plane subnets and RFC4191 prefix
announcements that are to be routed across the ACP connect interface,
RFC6724 source address selection Rule 5 (use address of outgoing
interface) will be used, so that above problems do not occur, even in
more complex cases of multiple ULA and non-ULA prefixes in the ACP
routing table.
To achieve the same behavior with a Combined ACP and Data Plane
interface, the ACP Edge Device needs to behave as two separate
routers on the interface: One link-local IPv6 address/router for its
ACP reachability, and one link-local IPv6 address/router for its Data
Plane reachability. The Router Advertisements for both are as
described above (Section 8.1.3): For the ACP, the ACP prefix is
announced together with RFC4191 option for the prefixes routed across
the ACP and lifetime=0 to disqualify this next-hop as a default
router. For the Data Plane, the Data Plane prefix(es) are announced
together with whatever dafault router parameters are used for the
Data Plane.
In result, RFC6724 source address selection Rule 5.5 may result in
the same correct source address selection behavior of NMS hosts
without further configuration on it as the separate ACP connect and
Data Plane interfaces. As described in the text for Rule 5.5, this
is only a may, because IPv6 hosts are not required to track next-hop
information. If an NMS Host does not do this, then separate ACP
connect and Data Plane interfaces are the preferrable method of
attachment.
ACP edge devices MAY support the Combined ACP and Data Plane
interface.
8.1.5. Use of GRASP
GRASP can and should be possible to use across ACP connect
interfaces, especially in the architectural correct solution when it
is used as a mechanism to connect Software (eg: ASA or legacy NMS
applications) to the ACP. Given how the ACP is the security and
transport substrate for GRASP, the trustworthyness of devices/
software allowed to participate in the ACP GRASP domain is one of the
main reasons why the ACP section describes no solution with non-ACP
routers participating in the ACP routing table.
ACP connect interfaces can be dealt with in the GRASP ACP domain like
any other ACP interface assuming that any physical ACP connect
interface is physically protected from attacks and that the connected
Software or NMS Hosts are equally trusted as that on other ACP
devices. ACP edge devices SHOULD have options to filter GRASP
messages in and out of ACP connect interfaces (permit/deny) and MAY
have more fine-grained filtering (eg: based on IPv6 address of
originator or objective).
When using "Combined ACP and Data Plane Interfaces", care must be
taken that only GRASP messages intended for the ACP GRASP domain
received from Software or NMS Hosts are forwarded by ACP edge
devices. Currently there is no definition for a GRASP security and
transport substrate beside the ACP, so there is no definition how
such Software/NMS Host could participate in two separate GRASP
Domains across the same subnet (ACP and Data Plane domains). At
current it is therefore assumed that all GRASP packets on a Combined
ACP and Data Plane interface belong to the GRASP ACP Domain. They
must therefore all use the ACP IPv6 addresses of the Software/NMS
Hosts. The link-local IPv6 addresses of Software/NMS Hosts (used for
GRASP M_DISCOVERY and M_FLOOD messages) are also assumed to belong to
the ACP address space.
8.2. ACP through Non-Autonomic L3 Clouds (Remote ACP neighbors) 8.2. ACP through Non-Autonomic L3 Clouds (Remote ACP neighbors)
Not all devices in a network may support the ACP. If non-ACP Layer-2 Not all devices in a network may support the ACP. If non-ACP Layer-2
devices are between ACP nodes, the ACP will work across it since it devices are between ACP nodes, the ACP will work across it since it
is IP based. However, the autonomic discovery of ACP neigbhors via is IP based. However, the autonomic discovery of ACP neigbhors via
DULL GRASP is only intended to work across L2 connections, so it is DULL GRASP is only intended to work across L2 connections, so it is
not sufficient to autonomically create ACP connections across non-ACP not sufficient to autonomically create ACP connections across non-ACP
Layer-3 devices. Layer-3 devices.
8.2.1. Configured Remote ACP neighbor 8.2.1. Configured Remote ACP neighbor
On the autonomic device remote ACP neighbors are configured as On the autonomic device remote ACP neighbors are configured as
follows: follows:
remote-peer = [ local-address, method, remote-address ] remote-peer = [ local-address, method, remote-address ]
local-address = ip-address local-address = ip-address
remote-address = transport-address remote-address = transport-address
transport-address = transport-address =
[ (ip-address | pattern) ?( , protocol ?(, port)) (, pmtu) ] [ (ip-address | pattern) ?( , protocol ?(, port)) (, pmtu) ]
ip-address = (ipv4-address | ipv6-address ) ip-address = (ipv4-address | ipv6-address )
method = "IKEv2" / "dTLS" / .. method = "IKEv2" / "dTLS" / ..
pattern = some IP address set pattern = some IP address set
For each candidate configured remote ACP neighbor, the secure channel For each candidate configured remote ACP neighbor, the secure channel
protocol "method" is configured with its expected local IP address protocol "method" is configured with its expected local IP address
and remote transport endpoint (transport protocol and port number for and remote transport endpoint (transport protocol and port number for
the remote transport endpoint are usually not necessary to configure the remote transport endpoint are usually not necessary to configure
if defaults for the secure channel protocol method exist. if defaults for the secure channel protocol method exist.
This is the same information that would be communicated via DULL for This is the same information that would be communicated via DULL for
L2 adjacent candidate ACP neighbors. DULL is not used because the L2 adjacent candidate ACP neighbors. DULL is not used because the
remote IP address would need to be configured anyhow and if the remote IP address would need to be configured anyhow and if the
skipping to change at page 45, line 29 skipping to change at page 53, line 29
options, as for any other network function. Specifically, a network options, as for any other network function. Specifically, a network
management system or controller must be able to discover the ACP, and management system or controller must be able to discover the ACP, and
monitor its health. This visibility of ACP operations must clearly monitor its health. This visibility of ACP operations must clearly
be separated from visibility of data plane so automated systems will be separated from visibility of data plane so automated systems will
never have to deal with ACP aspect unless they explicitly desire to never have to deal with ACP aspect unless they explicitly desire to
do so. do so.
Since an ACP is self-protecting, a device not supporting the ACP, or Since an ACP is self-protecting, a device not supporting the ACP, or
without a valid domain certificate cannot connect to it. This means without a valid domain certificate cannot connect to it. This means
that by default a traditional controller or network management system that by default a traditional controller or network management system
cannot connect to an ACP. See Section 8.1 for more details on how to cannot connect to an ACP. See Section 8.1.1 for more details on how
connect an NMS host into the ACP. to connect an NMS host into the ACP.
10. Further Considerations (Informative) 10. Further Considerations (Informative)
The following sections cover topics that are beyond the primary cope The following sections cover topics that are beyond the primary cope
of this document (eg: bootstrap), that explain decisions made in this of this document (eg: bootstrap), that explain decisions made in this
document (eg: choice of GRASP) or that explain desirable extensions document (eg: choice of GRASP) or that explain desirable extensions
to the behavior of the ACP that are not far enough worked out to be to the behavior of the ACP that are not far enough worked out to be
already standardized in this document. already standardized in this document.
10.1. Domain Certificate provisioning / enrollment 10.1. Domain Certificate provisioning / enrollment
skipping to change at page 51, line 22 skipping to change at page 59, line 22
o TLS is subject to reset attacks, which IKEv2 is not. Normally, o TLS is subject to reset attacks, which IKEv2 is not. Normally,
ACP connections (as specified in this document) will be over link- ACP connections (as specified in this document) will be over link-
local addresses so the attack surface for this one issue in TCP local addresses so the attack surface for this one issue in TCP
should be reduced (note that this may not be true when ACP is should be reduced (note that this may not be true when ACP is
tunneled as described in Section 8.2.2. tunneled as described in Section 8.2.2.
o GRASP packets received inside a TLS connection established for o GRASP packets received inside a TLS connection established for
GRASP/TLS ACP negotiation are assigned to a separate GRASP domain GRASP/TLS ACP negotiation are assigned to a separate GRASP domain
unique to that TLS connection. unique to that TLS connection.
10.5. CAs, domains and routing subdomains considerations 10.5. CAs, domains and routing subdomains
There is a wide range of setting up different ACP solution by There is a wide range of setting up different ACP solution by
appropriately using CAs and the domain and rsub elements in the ACP appropriately using CAs and the domain and rsub elements in the ACP
information field of the domain certificate. We summarize these information field of the domain certificate. We summarize these
options here as they have been explained in different parts of the options here as they have been explained in different parts of the
document in before and discuss possible and desirable extensions: document in before and discuss possible and desirable extensions:
An ACP domain is the set of all ACP devices using certificates from An ACP domain is the set of all ACP devices using certificates from
the same CA using the same domain field. GRASP inside the ACP is run the same CA using the same domain field. GRASP inside the ACP is run
across all transitively connected ACP devices in a domain. across all transitively connected ACP devices in a domain.
skipping to change at page 53, line 5 skipping to change at page 61, line 5
transit and what data-plane forwarding should be done. This approach transit and what data-plane forwarding should be done. This approach
could also allow for for Intent to only be injected into the network could also allow for for Intent to only be injected into the network
from one side and propagate via this GRASP connection. from one side and propagate via this GRASP connection.
If different domains have different CAs, they should start to trust If different domains have different CAs, they should start to trust
each other by intent injected into both domains that would add the each other by intent injected into both domains that would add the
other domains CA as a trust point during the ACP connection setup - other domains CA as a trust point during the ACP connection setup -
and then following up with the previous point of inter-domain and then following up with the previous point of inter-domain
connections across domains with the same CA (eg: GRASP negotiation). connections across domains with the same CA (eg: GRASP negotiation).
11. Security Considerations 11. RFC4291/RFC4193 Updates Considerations
This document may be considered to be updating the IPv6 addressing
architecture ([RFC4291]) and/or the Unique Local IPv6 Unicast
addresses ([RFC4193]) depending on how strict specific statements in
those specs are to be interpreted. This section summarized and
explains the necessity and benefits of these changes. The normative
parts of this document cover the actual updates.
ACP addresses (Section 6.10) are used by network devices supporting
the ACP. They are assigned during bootstrap of the device or initial
provisioning of the ACP. They are encoded in the Domain Certificate
of the device and are primarily used internally within the network
device. In that role they can be thought of as loopback addresses.
Each ACP domain assigns ACP addresses from one or more ULA prefixes.
Within an ACP network, addresses are assigned by nodes called
registrars. A unique Registrar-ID(entifier) is used in ACP addresses
to allow multiple registrars to assign addresses autonomously and
uncoordinated from each other. Typically these Registrar-IDs are
derived from the IEEE 802 48-bit MAC addresses of registrars.
In the ACP Zone Addressing Sub-Scheme (Section 6.10.3), the registrar
assigns a unique 15 bit value to an ACP device. The ACP address has
a 64-bit Device-ID(entifier) composed of the 48-bit Registrar-ID, the
registrar assigned 15-bit Device-Number and 1 V(irtualization) bit
that allows for an ACP device to have two addresses.
The 64-bit Device-Identifier in the ACP Zone Addressing Sub-Scheme
matches the 64 bit Interface Identifier (IID) address part as
specified in RFC4291 section 2.5.1. IIDs are unique across ACP
devices, but all ACP devices with the same ULA prefix that use the
ACP Zone Addressing Sub-Scheme will share the same subnet prefix
(according to the definition of that term in RFC4291). Each ACP
device injects a /127 route into the ACP routing table to cover its
two assigned addresses (V(irtual) bit being 0 or 1). This approach
is used because these ACP addresses are identifiers and not locators.
The ACP device can connect anywhere in the autonomic domain without
having to change its addresses. A lightweight, highly scaleable
routing protocol (RPL) is used to allow for large scale ACP networks.
It is possible, that this scheme constitutes an update to RFC4191
because the same 64 bit subnet prefix is used across many ACP
devices. The ACP Zone addressing Sub-Scheme is very similar to the
common operational practices of assigning /128 loopback addresses to
network devices from the same /48 or /64 subnet prefix.
In the ACP Vlong Addressing Sub-Scheme (Section 6.10.5), the address
elements are the same as described for the Zone Addressing Sub-
Scheme, but the V field is expanded from 1 bit to 8 or 16 bits. The
ACP device with ACP Vlong addressing therefore injects /120 or /112
prefixes into the ACP routing table to cover its internal addresses.
The goal for the 8 or 16-bit addresses available to an ACP device in
this scheme is to assign them as required to software components,
which in autonomic networking are called ASA (Autonomic Service
Agents). It could equally be used for existing software components
such as VNFs (Virtual Networking Functions). The ACP interface would
then be the out-of-band management interface of such a VNF software
component. It should especially be possible to use these software
components in a variety of contexts to allow standardized modular
system composition: Native applications (in some VRF context if
available), containers, virtual machines or other future ones. To
modularily compose a system with containers and virtual machines and
avoid problems such as port space collision or NAT, it is necessary
not only to assign separate addresses to those contexts, but also to
use the notion of virtual interfaces between these contexts to
compose the system.
In practical terms, the ACP should be enabled to create from its /8
or /16 prefix one or more device internal virtual subnets and to
start software components connected to those virtual subnets.
Ideally, these software components should be able to autoconfigure
their addresses on these virtual interfaces. Future work has to
determine whether this address autoconfiguration for the virtual
interface is best done with DHCPv6, if SLAAC should be recommended
for these /8 or /16 virtual interfaces, or if some additional
standardized method would be required.
In the ACP Vlong Addressing scheme, the Device-ID does not match the
RFC4291/RFC4193 64 bith length for the Interface Identifier, so this
addressing Sub-Scheme in the ACP is an update to both standards.
This document also specifies the workaround solution of exposing the
ACP on physical interfaces in support of adoption by existing
hardware and software solutions. A NOC based NMS host could for
example be configured with a second physical interface connecting to
an ACP device that exposes the ACP to that NMS host (called ACP edge
device). The desired evolution of this workaround is that those two
functions would merge into a single device, for example by making the
ACP router a container/virtual machine inside the NMS host or vice
versa. The addressing for those physical interfaces allows for
manually configured address prefixes but it could be fully autonomous
if it could leverage the Vlong addressing format. That would result
in a non /64 IID boundary on those external interfaces (but instead
in /112 or /120 subnet prefixes).
Note that both in the internal as well as the workaround external use
of ACP addresses, all ACP addresses are meant to be used exclusively
by components that are part of network control and OAM, but not for
network users such as normal hosts. This implies that for example no
requirements for privacy addressing have been identified for ACP
addresses.
12. Security Considerations
An ACP is self-protecting and there is no need to apply configuration An ACP is self-protecting and there is no need to apply configuration
to make it secure. Its security therefore does not depend on to make it secure. Its security therefore does not depend on
configuration. configuration.
However, the security of the ACP depends on a number of other However, the security of the ACP depends on a number of other
factors: factors:
o The usage of domain certificates depends on a valid supporting PKI o The usage of domain certificates depends on a valid supporting PKI
infrastructure. If the chain of trust of this PKI infrastructure infrastructure. If the chain of trust of this PKI infrastructure
skipping to change at page 53, line 33 skipping to change at page 63, line 42
This implies that if an attacker gains access to the ACP, it can This implies that if an attacker gains access to the ACP, it can
spoof all addresses inside the ACP and fake messages from any other spoof all addresses inside the ACP and fake messages from any other
device. device.
Fundamentally, security depends on correct operation, implementation Fundamentally, security depends on correct operation, implementation
and architecture. Autonomic approaches such as the ACP largely and architecture. Autonomic approaches such as the ACP largely
eliminate the dependency on correct operation; implementation and eliminate the dependency on correct operation; implementation and
architectural mistakes are still possible, as in all networking architectural mistakes are still possible, as in all networking
technologies. technologies.
12. IANA Considerations 13. IANA Considerations
13. Acknowledgements 14. Acknowledgements
This work originated from an Autonomic Networking project at Cisco This work originated from an Autonomic Networking project at Cisco
Systems, which started in early 2010. Many people contributed to Systems, which started in early 2010. Many people contributed to
this project and the idea of the Autonomic Control Plane, amongst this project and the idea of the Autonomic Control Plane, amongst
which (in alphabetical order): Ignas Bagdonas, Parag Bhide, Balaji which (in alphabetical order): Ignas Bagdonas, Parag Bhide, Balaji
BL, Alex Clemm, Yves Hertoghs, Bruno Klauser, Max Pritikin, Ravi BL, Alex Clemm, Yves Hertoghs, Bruno Klauser, Max Pritikin, Michael
Kumar Vadapalli. Richardson, Ravi Kumar Vadapalli.
Special thanks to Pascal Thubert to provide the details for the Special thanks to Pascal Thubert and Michael Richardson to provide
recommendations of the RPL profile to use in the ACP the details for the recommendations of the use of RPL in the ACP
Further input and suggestions were received from: Rene Struik, Brian Further input and suggestions were received from: Rene Struik, Brian
Carpenter, Benoit Claise. Carpenter, Benoit Claise.
14. Change log [RFC Editor: Please remove] 15. Change log [RFC Editor: Please remove]
14.1. Initial version 15.1. Initial version
First version of this document: draft-behringer-autonomic-control- First version of this document: draft-behringer-autonomic-control-
plane plane
14.2. draft-behringer-anima-autonomic-control-plane-00 15.2. draft-behringer-anima-autonomic-control-plane-00
Initial version of the anima document; only minor edits. Initial version of the anima document; only minor edits.
14.3. draft-behringer-anima-autonomic-control-plane-01 15.3. draft-behringer-anima-autonomic-control-plane-01
o Clarified that the ACP should be based on, and support only IPv6. o Clarified that the ACP should be based on, and support only IPv6.
o Clarified in intro that ACP is for both, between devices, as well o Clarified in intro that ACP is for both, between devices, as well
as for access from a central entity, such as an NMS. as for access from a central entity, such as an NMS.
o Added a section on how to connect an NMS system. o Added a section on how to connect an NMS system.
o Clarified the hop-by-hop crypto nature of the ACP. o Clarified the hop-by-hop crypto nature of the ACP.
o Added several references to GDNP as a candidate protocol. o Added several references to GDNP as a candidate protocol.
o Added a discussion on network split and merge. Although, this o Added a discussion on network split and merge. Although, this
should probably go into the certificate management story longer should probably go into the certificate management story longer
term. term.
14.4. draft-behringer-anima-autonomic-control-plane-02 15.4. draft-behringer-anima-autonomic-control-plane-02
Addresses (numerous) comments from Brian Carpenter. See mailing list Addresses (numerous) comments from Brian Carpenter. See mailing list
for details. The most important changes are: for details. The most important changes are:
o Introduced a new section "overview", to ease the understanding of o Introduced a new section "overview", to ease the understanding of
the approach. the approach.
o Merged the previous "problem statement" and "use case" sections o Merged the previous "problem statement" and "use case" sections
into a mostly re-written "use cases" section, since they were into a mostly re-written "use cases" section, since they were
overlapping. overlapping.
o Clarified the relationship with draft-ietf-anima-stable- o Clarified the relationship with draft-ietf-anima-stable-
connectivity connectivity
14.5. draft-behringer-anima-autonomic-control-plane-03 15.5. draft-behringer-anima-autonomic-control-plane-03
o Took out requirement for IPv6 --> that's in the reference doc. o Took out requirement for IPv6 --> that's in the reference doc.
o Added requirement section. o Added requirement section.
o Changed focus: more focus on autonomic functions, not only virtual o Changed focus: more focus on autonomic functions, not only virtual
out of band. This goes a bit throughout the document, starting out of band. This goes a bit throughout the document, starting
with a changed abstract and intro. with a changed abstract and intro.
14.6. draft-ietf-anima-autonomic-control-plane-00 15.6. draft-ietf-anima-autonomic-control-plane-00
No changes; re-submitted as WG document. No changes; re-submitted as WG document.
14.7. draft-ietf-anima-autonomic-control-plane-01 15.7. draft-ietf-anima-autonomic-control-plane-01
o Added some paragraphs in addressing section on "why IPv6 only", to o Added some paragraphs in addressing section on "why IPv6 only", to
reflect the discussion on the list. reflect the discussion on the list.
o Moved the data-plane ACP out of the main document, into an o Moved the data-plane ACP out of the main document, into an
appendix. The focus is now the virtually separated ACP, since it appendix. The focus is now the virtually separated ACP, since it
has significant advantages, and isn't much harder to do. has significant advantages, and isn't much harder to do.
o Changed the self-creation algorithm: Part of the initial steps go o Changed the self-creation algorithm: Part of the initial steps go
into the reference document. This document now assumes an into the reference document. This document now assumes an
skipping to change at page 56, line 5 skipping to change at page 66, line 7
o Introduce a section for the capability negotiation protocol o Introduce a section for the capability negotiation protocol
(section 7). This needs to be worked out in more detail. This (section 7). This needs to be worked out in more detail. This
will likely be based on GRASP. will likely be based on GRASP.
o Introduce a new parameter: ACP tunnel type. And defines it in the o Introduce a new parameter: ACP tunnel type. And defines it in the
IANA considerations section. Suggest GRE protected with IPSec IANA considerations section. Suggest GRE protected with IPSec
transport mode as the default tunnel type. transport mode as the default tunnel type.
o Updated links, lots of small edits. o Updated links, lots of small edits.
14.8. draft-ietf-anima-autonomic-control-plane-02 15.8. draft-ietf-anima-autonomic-control-plane-02
o Added explicitly text for the ACP channel negotiation. o Added explicitly text for the ACP channel negotiation.
o Merged draft-behringer-anima-autonomic-addressing-02 into this o Merged draft-behringer-anima-autonomic-addressing-02 into this
document, as suggested by WG chairs. document, as suggested by WG chairs.
14.9. draft-ietf-anima-autonomic-control-plane-03 15.9. draft-ietf-anima-autonomic-control-plane-03
o Changed Neighbor discovery protocol from GRASP to mDNS. Bootstrap o Changed Neighbor discovery protocol from GRASP to mDNS. Bootstrap
protocol team decided to go with mDNS to discover bootstrap proxy, protocol team decided to go with mDNS to discover bootstrap proxy,
and ACP should be consistent with this. Reasons to go with mDNS and ACP should be consistent with this. Reasons to go with mDNS
in bootstrap were a) Bootstrap should be reuseable also outside of in bootstrap were a) Bootstrap should be reuseable also outside of
full anima solutions and introduce as few as possible new full anima solutions and introduce as few as possible new
elements. mDNS was considered well-known and very-likely even pre- elements. mDNS was considered well-known and very-likely even pre-
existing in low-end devices (IoT). b) Using GRASP both for the existing in low-end devices (IoT). b) Using GRASP both for the
insecure neighbor discovery and secure ACP operatations raises the insecure neighbor discovery and secure ACP operatations raises the
risk of introducing security issues through implementation issues/ risk of introducing security issues through implementation issues/
skipping to change at page 56, line 44 skipping to change at page 66, line 46
planned, and the paragraph in the main text referring to it. planned, and the paragraph in the main text referring to it.
o Deleted one sub-addressing scheme, focusing on a single scheme o Deleted one sub-addressing scheme, focusing on a single scheme
now. now.
o Included information on how ANIMA information must be encoded in o Included information on how ANIMA information must be encoded in
the domain certificate in section "preconditions". the domain certificate in section "preconditions".
o Editorial changes, updated draft references, etc. o Editorial changes, updated draft references, etc.
14.10. draft-ietf-anima-autonomic-control-plane-04 15.10. draft-ietf-anima-autonomic-control-plane-04
Changed discovery of ACP neighbor back from mDNS to GRASP after Changed discovery of ACP neighbor back from mDNS to GRASP after
revisiting the L2 problem. Described problem in discovery section revisiting the L2 problem. Described problem in discovery section
itself to justify. Added text to explain how ACP discovery relates itself to justify. Added text to explain how ACP discovery relates
to BRSKY (bootstrap) discovery and pointed to Michael Richardsons to BRSKY (bootstrap) discovery and pointed to Michael Richardsons
draft detailing it. Removed appendix section that contained the draft detailing it. Removed appendix section that contained the
original explanations why GRASP would be useful (current text is original explanations why GRASP would be useful (current text is
meant to be better). meant to be better).
14.11. draft-ietf-anima-autonomic-control-plane-05 15.11. draft-ietf-anima-autonomic-control-plane-05
o Section 5.3 (candidate ACP neighbor selection): Add that Intent o Section 5.3 (candidate ACP neighbor selection): Add that Intent
can override only AFTER an initial default ACP establishment. can override only AFTER an initial default ACP establishment.
o Section 6.10.1 (addressing): State that addresses in the ACP are o Section 6.10.1 (addressing): State that addresses in the ACP are
permanent, and do not support temporary addresses as defined in permanent, and do not support temporary addresses as defined in
RFC4941. RFC4941.
o Modified Section 6.3 to point to the GRASP objective defined in o Modified Section 6.3 to point to the GRASP objective defined in
draft-carpenter-anima-ani-objectives. (and added that reference) draft-carpenter-anima-ani-objectives. (and added that reference)
o Section 6.10.2: changed from MD5 for calculating the first 40 bits o Section 6.10.2: changed from MD5 for calculating the first 40 bits
to SHA256; reason is MD5 should not be used any more. to SHA256; reason is MD5 should not be used any more.
o Added address sub-scheme to the IANA section. o Added address sub-scheme to the IANA section.
o Made the routing section more prescriptive. o Made the routing section more prescriptive.
o Clarified in Section 8.1 the ACP Connect port, and defined that o Clarified in Section 8.1.1 the ACP Connect port, and defined that
term "ACP Connect". term "ACP Connect".
o Section 8.2: Added some thoughts (from mcr) on how traversing a L3 o Section 8.2: Added some thoughts (from mcr) on how traversing a L3
cloud could be automated. cloud could be automated.
o Added a CRL check in Section 6.7. o Added a CRL check in Section 6.7.
o Added a note on the possibility of source-address spoofing into o Added a note on the possibility of source-address spoofing into
the security considerations section. the security considerations section.
o Other editoral changes, including those proposed by Michael o Other editoral changes, including those proposed by Michael
Richardson on 30 Nov 2016 (see ANIMA list). Richardson on 30 Nov 2016 (see ANIMA list).
14.12. draft-ietf-anima-autonomic-control-plane-06 15.12. draft-ietf-anima-autonomic-control-plane-06
o Added proposed RPL profile. o Added proposed RPL profile.
o detailed dTLS profile - dTLS with any additional negotiation/ o detailed dTLS profile - dTLS with any additional negotiation/
signaling channel. signaling channel.
o Fixed up text for ACP/GRE encap. Removed text claiming its o Fixed up text for ACP/GRE encap. Removed text claiming its
incompatible with non-GRE IPsec and detailled it. incompatible with non-GRE IPsec and detailled it.
o Added text to suggest admin down interfaces should still run ACP. o Added text to suggest admin down interfaces should still run ACP.
14.13. draft-ietf-anima-autonomic-control-plane-07 15.13. draft-ietf-anima-autonomic-control-plane-07
o Changed author association. o Changed author association.
o Improved ACP connect setion (after confusion about term came up in o Improved ACP connect setion (after confusion about term came up in
the stable connectivity draft review). Added picture, defined the stable connectivity draft review). Added picture, defined
complete terminology. complete terminology.
o Moved ACP channel negotiation from normative section to appendix o Moved ACP channel negotiation from normative section to appendix
because it can in the timeline of this document not be fully because it can in the timeline of this document not be fully
specified to be implementable. Aka: work for future document. specified to be implementable. Aka: work for future document.
skipping to change at page 59, line 37 skipping to change at page 69, line 37
do not specify which one is to be used but that the ACP should be do not specify which one is to be used but that the ACP should be
used to reach the URL included in the certificate to get to the used to reach the URL included in the certificate to get to the
CRL storage or OCSP server. CRL storage or OCSP server.
o Changed ACP via IPsec to ACP via IKEv2 and restructured the o Changed ACP via IPsec to ACP via IKEv2 and restructured the
sections to make IPsec native and IPsec via GRE subsections. sections to make IPsec native and IPsec via GRE subsections.
o No need for any assigned dTLS port if ACP is run across dTLS o No need for any assigned dTLS port if ACP is run across dTLS
because it is signalled via GRASP. because it is signalled via GRASP.
14.14. draft-ietf-anima-autonomic-control-plane-08 15.14. draft-ietf-anima-autonomic-control-plane-08
Modified mentioning of BRSKI to make it consistent with current Modified mentioning of BRSKI to make it consistent with current
(07/2017) target for BRSKI: MASA and IDevID are mandatory. Devices (07/2017) target for BRSKI: MASA and IDevID are mandatory. Devices
with only insecure UDI would need a security reduced variant of with only insecure UDI would need a security reduced variant of
BRSKI. Also added mentioning of Netconf Zerotouch. Made BRSKI non- BRSKI. Also added mentioning of Netconf Zerotouch. Made BRSKI non-
normative for ACP because wrt. ACP it is just one option how the normative for ACP because wrt. ACP it is just one option how the
domain certificate can be provisioned. Instead, BRSKI is mandatory domain certificate can be provisioned. Instead, BRSKI is mandatory
when a device implements ANI which is ACP+BRSKI. when a device implements ANI which is ACP+BRSKI.
Enhanced text for ACP across tunnels to decribe two options: one Enhanced text for ACP across tunnels to decribe two options: one
skipping to change at page 61, line 5 skipping to change at page 71, line 5
local-parts (":" as required by RFC5952 are not permitted in simple local-parts (":" as required by RFC5952 are not permitted in simple
dot-atoms according to RFC5322. Removed reference to RFC5952 as its dot-atoms according to RFC5322. Removed reference to RFC5952 as its
now not needed anymore. now not needed anymore.
Introduced a sub-domain field in the ACP information in the Introduced a sub-domain field in the ACP information in the
certificate to allow defining such subdomains with depending on certificate to allow defining such subdomains with depending on
future Intent definitions. It also makes it clear what the "main future Intent definitions. It also makes it clear what the "main
domain" is. Scheme is called "routing subdomain" to have a unique domain" is. Scheme is called "routing subdomain" to have a unique
name. name.
Added V8 addressing sub-scheme according to suggestion from mcr in Added V8 (now called Vlong) addressing sub-scheme according to
his mail from 30 Nov 2016 suggestion from mcr in his mail from 30 Nov 2016
(https://mailarchive.ietf.org/arch/msg/anima/ (https://mailarchive.ietf.org/arch/msg/anima/
nZpEphrTqDCBdzsKMpaIn2gsIzI). Also modified the explanation of the nZpEphrTqDCBdzsKMpaIn2gsIzI). Also modified the explanation of the
single V bit in the first sub-scheme now renamed to Zone sub-scheme single V bit in the first sub-scheme now renamed to Zone sub-scheme
to distinguish it. to distinguish it.
15. References 15.15. draft-ietf-anima-autonomic-control-plane-09
15.1. Normative References Added reference to RFC4191 and explained how it should be used on ACP
edge routers to allow autoconfiguration of routing by NMS hosts.
This came after review of stable connectivity draft where ACP connect
is being referred to.
V8 addressing Sub-Scheme was modified to allow not only /8 device-
local address space but also /16. This was in response to the
possible need to have maybe as much as 2^12 local addresses for
future encaps in BRSKI like IPinIP. It also would allow fully
autonomic address assignment for ACP connect interfaces from this
local address space (on an ACP edge device), subject to approval of
the implied update to rfc4291/rfc4193 (IID length). Changed name to
Vlong addressing sub-scheme.
Added text in response to Brian Carpenters review of draft-ietf-
anima-stable-connectivity-04. The stable connectivity draft was
vaguely describing ACP connect behavior that is better standardized
in this ACP draft:
o Added new ACP "Manual" addressing sub-scheme with /64 subnets for
use with ACP connect interfaces. Being covered by the ACP ULA
prefix, these subnets do not require additional routing entries
for NMS hosts. They also are fully 64-bit IID length compliant
and therefore not subject to 4191bis considerations. And they
avoid that operators manually assign prefixes from the ACP ULA
prefixes that might later be assigned autonomiously.
o ACP connect auto-configuration: Defined that ACP edge devices, NMS
hosts should use RFC4191 to automatically learn ACP prefixes.
This is especially necessary when the ACP uses multiple ULA
prefixes (via eg: the rsub domain certificate option), or if ACP
connect subinterfaces use manually configured prefixes NOT covered
by the ACP ULA prefixes.
o Explained how rfc6724 is (only) sufficient when the NMS host has a
separate ACP connect and data plane interface. But not when there
is a single interface.
o Added a separate subsection to talk about "software" instead of
"NMS hosts" connecting to the ACP via the "ACP connect" method.
The reason is to point out that the "ACP connect" method is not
only a workaround (for NMS hosts), but an actual desirable long
term architectural component to modularily build software (eg: ASA
or OAM for VNF) into ACP devices.
o Added a section to define how to run ACP connect across the same
interface as the Data Plane. This turns out to be quite
challenging because we only want to rely on existing standards for
the network stack in the NMS host/software and only define what
features the ACP edge device needs.
o Added section about use of GRASP over ACP connect.
o Added text to indicate packet processing/filtering for security:
filter incorrect packets arriving on ACP connect interfaces,
diagnose on RPL root packets to incorrect destination address (not
in ACP connect section, but because of it).
o Reaffirm security goal of ACP: Do not permit non-ACP routers into
ACP routing domain.
Made this ACP document be an update to RFC4291 and RFC4193. At the
core, some of the ACP addressing sub-schemes do effectively not use
64-bit IIDs as required by RFC4191 and debated in rfc4191bis. During
6man in prague, it was suggested that all documents that do not do
this should be classified as such updates. Add a rather long section
that summarizes the relevant parts of ACP addressing and usage and.
Aka: This section is meant to be the primary review section for
readers interested in these changes (eg: 6man WG.).
Added changes from Michael Richardsons review https://github.com/
anima-wg/autonomic-control-plane/pull/3/commits, textual and:
o ACP discovery inside ACP is bad *doh*!.
o Better CA trust and revocation sentences.
o More details about RPL behavior in ACP.
o blackhole route to avoid loops in RPL.
Added requirement to terminate ACP channels upon cert expiry/
revocation.
Added fixes from 08-mcr-review-reply.txt (on github):
o AN Domain Names are FQDNs.
o Fixed bit length of schemes, numerical writing of bits (00b/01b).
o Lets use US american english.
16. References
16.1. Normative References
[I-D.ietf-anima-grasp] [I-D.ietf-anima-grasp]
Bormann, C., Carpenter, B., and B. Liu, "A Generic Bormann, C., Carpenter, B., and B. Liu, "A Generic
Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-
grasp-15 (work in progress), July 2017. grasp-15 (work in progress), July 2017.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
November 2005, <http://www.rfc-editor.org/info/rfc4191>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<http://www.rfc-editor.org/info/rfc4193>. <http://www.rfc-editor.org/info/rfc4193>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<http://www.rfc-editor.org/info/rfc4862>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <http://www.rfc-editor.org/info/rfc5246>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>. <http://www.rfc-editor.org/info/rfc5280>.
skipping to change at page 62, line 20 skipping to change at page 74, line 31
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030, "Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013, DOI 10.17487/RFC7030, October 2013,
<http://www.rfc-editor.org/info/rfc7030>. <http://www.rfc-editor.org/info/rfc7030>.
[RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support [RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support
for Generic Routing Encapsulation (GRE)", RFC 7676, for Generic Routing Encapsulation (GRE)", RFC 7676,
DOI 10.17487/RFC7676, October 2015, DOI 10.17487/RFC7676, October 2015,
<http://www.rfc-editor.org/info/rfc7676>. <http://www.rfc-editor.org/info/rfc7676>.
15.2. Informative References 16.2. Informative References
[I-D.ietf-anima-bootstrapping-keyinfra] [I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Behringer, M., Bjarnason, Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
S., and K. Watsen, "Bootstrapping Remote Secure Key S., and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-07 (work in progress), July 2017. keyinfra-07 (work in progress), July 2017.
[I-D.ietf-anima-reference-model] [I-D.ietf-anima-reference-model]
Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L.,
Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A
Reference Model for Autonomic Networking", draft-ietf- Reference Model for Autonomic Networking", draft-ietf-
anima-reference-model-04 (work in progress), July 2017. anima-reference-model-04 (work in progress), July 2017.
[I-D.ietf-anima-stable-connectivity] [I-D.ietf-anima-stable-connectivity]
Eckert, T. and M. Behringer, "Using Autonomic Control Eckert, T. and M. Behringer, "Using Autonomic Control
Plane for Stable Connectivity of Network OAM", draft-ietf- Plane for Stable Connectivity of Network OAM", draft-ietf-
anima-stable-connectivity-03 (work in progress), July anima-stable-connectivity-04 (work in progress), July
2017. 2017.
[I-D.ietf-netconf-zerotouch] [I-D.ietf-netconf-zerotouch]
Watsen, K., Abrahamsson, M., and I. Farrer, "Zero Touch Watsen, K., Abrahamsson, M., and I. Farrer, "Zero Touch
Provisioning for NETCONF or RESTCONF based Management", Provisioning for NETCONF or RESTCONF based Management",
draft-ietf-netconf-zerotouch-14 (work in progress), June draft-ietf-netconf-zerotouch-14 (work in progress), June
2017. 2017.
[I-D.ietf-roll-useofrplinfo]
Robles, I., Richardson, M., and P. Thubert, "When to use
RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll-
useofrplinfo-16 (work in progress), July 2017.
[RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax
Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998, Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998,
<http://www.rfc-editor.org/info/rfc2315>. <http://www.rfc-editor.org/info/rfc2315>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<http://www.rfc-editor.org/info/rfc4941>. <http://www.rfc-editor.org/info/rfc4941>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>. <http://www.rfc-editor.org/info/rfc6241>.
[RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
Power and Lossy Networks (RPL) Option for Carrying RPL
Information in Data-Plane Datagrams", RFC 6553,
DOI 10.17487/RFC6553, March 2012,
<http://www.rfc-editor.org/info/rfc6553>.
[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,
<http://www.rfc-editor.org/info/rfc6724>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013, DOI 10.17487/RFC6762, February 2013,
<http://www.rfc-editor.org/info/rfc6762>. <http://www.rfc-editor.org/info/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<http://www.rfc-editor.org/info/rfc6763>. <http://www.rfc-editor.org/info/rfc6763>.
[RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local
Addressing inside an IPv6 Network", RFC 7404, Addressing inside an IPv6 Network", RFC 7404,
 End of changes. 112 change blocks. 
280 lines changed or deleted 856 lines changed or added

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