draft-ietf-anima-autonomic-control-plane-10.txt   draft-ietf-anima-autonomic-control-plane-11.txt 
ANIMA WG M. Behringer, Ed. ANIMA WG M. Behringer, Ed.
Internet-Draft Internet-Draft
Updates: 4291,4193 (if approved) T. Eckert, Ed. Updates: 4291,4193 (if approved) T. Eckert, Ed.
Intended status: Standards Track Huawei Intended status: Standards Track Huawei
Expires: March 19, 2018 S. Bjarnason Expires: April 15, 2018 S. Bjarnason
Arbor Networks Arbor Networks
September 15, 2017 October 12, 2017
An Autonomic Control Plane (ACP) An Autonomic Control Plane (ACP)
draft-ietf-anima-autonomic-control-plane-10 draft-ietf-anima-autonomic-control-plane-11
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 March 19, 2018. This Internet-Draft will expire on April 15, 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 15 skipping to change at page 2, line 15
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . 9
3.2. Secure Bootstrap over an Unconfigured Network . . . . . . 8 3.2. Secure Bootstrap over an unconfigured Network . . . . . . 9
3.3. Data Plane Independent Permanent Reachability . . . . . . 9 3.3. Data Plane Independent Permanent Reachability . . . . . . 9
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 12 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 . . . . . . . . . . . . . . . . . . . 13 6.1.1. ACP information . . . . . . . . . . . . . . . . . . . 13
6.1.2. Maintenance . . . . . . . . . . . . . . . . . . . . . 15 6.1.2. Maintenance . . . . . . . . . . . . . . . . . . . . . 15
6.2. AN Adjacency Table . . . . . . . . . . . . . . . . . . . 17 6.2. AN Adjacency Table . . . . . . . . . . . . . . . . . . . 17
6.3. Neighbor Discovery with DULL GRASP . . . . . . . . . . . 18 6.3. Neighbor Discovery with DULL GRASP . . . . . . . . . . . 18
6.4. Candidate ACP Neighbor Selection . . . . . . . . . . . . 20 6.4. Candidate ACP Neighbor Selection . . . . . . . . . . . . 21
6.5. Channel Selection . . . . . . . . . . . . . . . . . . . . 21 6.5. Channel Selection . . . . . . . . . . . . . . . . . . . . 21
6.6. Candidate ACP Neighbor certificate verification . . . . . 23 6.6. Candidate ACP Neighbor certificate verification . . . . . 23
6.7. Security Association protocols . . . . . . . . . . . . . 23 6.7. Security Association protocols . . . . . . . . . . . . . 23
6.7.1. ACP via IKEv2 . . . . . . . . . . . . . . . . . . . . 23 6.7.1. ACP via IKEv2 . . . . . . . . . . . . . . . . . . . . 23
6.7.2. ACP via dTLS . . . . . . . . . . . . . . . . . . . . 24 6.7.2. ACP via dTLS . . . . . . . . . . . . . . . . . . . . 25
6.7.3. ACP Secure Channel Requirements . . . . . . . . . . . 25 6.7.3. ACP Secure Channel Requirements . . . . . . . . . . . 25
6.8. GRASP in the ACP . . . . . . . . . . . . . . . . . . . . 25 6.8. GRASP in the ACP . . . . . . . . . . . . . . . . . . . . 25
6.8.1. GRASP as a core service of the ACP . . . . . . . . . 25 6.8.1. GRASP as a core service of the ACP . . . . . . . . . 25
6.8.2. ACP as the Security and Transport substrate for GRASP 26 6.8.2. ACP as the Security and Transport substrate for GRASP 27
6.9. Context Separation . . . . . . . . . . . . . . . . . . . 28 6.9. Context Separation . . . . . . . . . . . . . . . . . . . 30
6.10. Addressing inside the ACP . . . . . . . . . . . . . . . . 28 6.10. Addressing inside the ACP . . . . . . . . . . . . . . . . 30
6.10.1. Fundamental Concepts of Autonomic Addressing . . . . 28 6.10.1. Fundamental Concepts of Autonomic Addressing . . . . 31
6.10.2. The ACP Addressing Base Scheme . . . . . . . . . . . 29 6.10.2. The ACP Addressing Base Scheme . . . . . . . . . . . 32
6.10.3. ACP Zone Addressing Sub-Scheme . . . . . . . . . . . 30 6.10.3. ACP Zone Addressing Sub-Scheme . . . . . . . . . . . 33
6.10.4. ACP Manual Addressing Sub-Scheme . . . . . . . . . . 32 6.10.4. ACP Manual Addressing Sub-Scheme . . . . . . . . . . 35
6.10.5. ACP Vlong Addressing Sub-Scheme . . . . . . . . . . 33 6.10.5. ACP Vlong Addressing Sub-Scheme . . . . . . . . . . 36
6.10.6. Other ACP Addressing Sub-Schemes . . . . . . . . . . 34 6.10.6. Other ACP Addressing Sub-Schemes . . . . . . . . . . 37
6.11. Routing in the ACP . . . . . . . . . . . . . . . . . . . 35 6.11. Routing in the ACP . . . . . . . . . . . . . . . . . . . 37
6.11.1. RPL Profile . . . . . . . . . . . . . . . . . . . . 35 6.11.1. RPL Profile . . . . . . . . . . . . . . . . . . . . 38
6.12. General ACP Considerations . . . . . . . . . . . . . . . 39 6.12. General ACP Considerations . . . . . . . . . . . . . . . 41
6.12.1. Performance . . . . . . . . . . . . . . . . . . . . 39 6.12.1. Performance . . . . . . . . . . . . . . . . . . . . 42
6.12.2. Addressing of Secure Channels in the data plane . . 39 6.12.2. Addressing of Secure Channels in the data plane . . 42
6.12.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . 40 6.12.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . 42
6.12.4. Multiple links between nodes . . . . . . . . . . . . 40 6.12.4. Multiple links between nodes . . . . . . . . . . . . 43
6.12.5. ACP interfaces . . . . . . . . . . . . . . . . . . . 40 6.12.5. ACP interfaces . . . . . . . . . . . . . . . . . . . 43
7. ACP support on L2 switches/ports (Normative) . . . . . . . . 43 7. ACP support on L2 switches/ports (Normative) . . . . . . . . 46
7.1. Why . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 7.1. Why . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7.2. How (per L2 port DULL GRASP) . . . . . . . . . . . . . . 44 7.2. How (per L2 port DULL GRASP) . . . . . . . . . . . . . . 47
8. Support for Non-Autonomic Components (Normative) . . . . . . 46 8. Support for Non-Autonomic Components (Normative) . . . . . . 49
8.1. ACP Connect . . . . . . . . . . . . . . . . . . . . . . . 46 8.1. ACP Connect . . . . . . . . . . . . . . . . . . . . . . . 49
8.1.1. Non-Autonomic Controller / NMS system . . . . . . . . 46 8.1.1. Non-Autonomic Controller / NMS system . . . . . . . . 49
8.1.2. Software Components . . . . . . . . . . . . . . . . . 48 8.1.2. Software Components . . . . . . . . . . . . . . . . . 51
8.1.3. Auto Configuration . . . . . . . . . . . . . . . . . 49 8.1.3. Auto Configuration . . . . . . . . . . . . . . . . . 52
8.1.4. Combined ACP and Data Data Plane Interface (VRF 8.1.4. Combined ACP and Data Data Plane Interface (VRF
Select) . . . . . . . . . . . . . . . . . . . . . . . 50 Select) . . . . . . . . . . . . . . . . . . . . . . . 53
8.1.5. Use of GRASP . . . . . . . . . . . . . . . . . . . . 52 8.1.5. Use of GRASP . . . . . . . . . . . . . . . . . . . . 55
8.2. ACP through Non-Autonomic L3 Clouds (Remote ACP 8.2. ACP through Non-Autonomic L3 Clouds (Remote ACP
neighbors) . . . . . . . . . . . . . . . . . . . . . . . 52 neighbors) . . . . . . . . . . . . . . . . . . . . . . . 55
8.2.1. Configured Remote ACP neighbor . . . . . . . . . . . 52 8.2.1. Configured Remote ACP neighbor . . . . . . . . . . . 55
8.2.2. Tunneled Remote ACP Neighbor . . . . . . . . . . . . 54 8.2.2. Tunneled Remote ACP Neighbor . . . . . . . . . . . . 57
8.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 54 8.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 57
9. Benefits (Informative) . . . . . . . . . . . . . . . . . . . 54 9. Benefits (Informative) . . . . . . . . . . . . . . . . . . . 57
9.1. Self-Healing Properties . . . . . . . . . . . . . . . . . 54 9.1. Self-Healing Properties . . . . . . . . . . . . . . . . . 57
9.2. Self-Protection Properties . . . . . . . . . . . . . . . 56 9.2. Self-Protection Properties . . . . . . . . . . . . . . . 59
9.2.1. From the outside . . . . . . . . . . . . . . . . . . 56 9.2.1. From the outside . . . . . . . . . . . . . . . . . . 59
9.2.2. From the inside . . . . . . . . . . . . . . . . . . . 56 9.2.2. From the inside . . . . . . . . . . . . . . . . . . . 59
9.3. The Administrator View . . . . . . . . . . . . . . . . . 57 9.3. The Administrator View . . . . . . . . . . . . . . . . . 60
10. Further Considerations (Informative) . . . . . . . . . . . . 57 10. Further Considerations (Informative) . . . . . . . . . . . . 60
10.1. Domain Certificate provisioning / enrollment . . . . . . 58 10.1. Domain Certificate provisioning / enrollment . . . . . . 61
10.2. ACP Neighbor discovery protocol selection . . . . . . . 59 10.2. ACP Neighbor discovery protocol selection . . . . . . . 62
10.2.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 59 10.2.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 62
10.2.2. mDNS and L2 support . . . . . . . . . . . . . . . . 59 10.2.2. mDNS and L2 support . . . . . . . . . . . . . . . . 62
10.2.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 60 10.2.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 63
10.3. Choice of routing protocol (RPL) . . . . . . . . . . . . 60 10.3. Choice of routing protocol (RPL) . . . . . . . . . . . . 63
10.4. Extending ACP channel negotiation (via GRASP) . . . . . 61 10.4. Extending ACP channel negotiation (via GRASP) . . . . . 64
10.5. CAs, domains and routing subdomains . . . . . . . . . . 63 10.5. CAs, domains and routing subdomains . . . . . . . . . . 66
11. RFC4291/RFC4193 Updates Considerations . . . . . . . . . . . 65 11. RFC4291/RFC4193 Updates Considerations . . . . . . . . . . . 68
12. Security Considerations . . . . . . . . . . . . . . . . . . . 67 12. Security Considerations . . . . . . . . . . . . . . . . . . . 70
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 68 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 68 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 72
15. Change log [RFC Editor: Please remove] . . . . . . . . . . . 68 15. Change log [RFC Editor: Please remove] . . . . . . . . . . . 72
15.1. Initial version . . . . . . . . . . . . . . . . . . . . 68 15.1. Initial version . . . . . . . . . . . . . . . . . . . . 72
15.2. draft-behringer-anima-autonomic-control-plane-00 . . . . 68 15.2. draft-behringer-anima-autonomic-control-plane-00 . . . . 72
15.3. draft-behringer-anima-autonomic-control-plane-01 . . . . 68 15.3. draft-behringer-anima-autonomic-control-plane-01 . . . . 72
15.4. draft-behringer-anima-autonomic-control-plane-02 . . . . 69 15.4. draft-behringer-anima-autonomic-control-plane-02 . . . . 72
15.5. draft-behringer-anima-autonomic-control-plane-03 . . . . 69 15.5. draft-behringer-anima-autonomic-control-plane-03 . . . . 73
15.6. draft-ietf-anima-autonomic-control-plane-00 . . . . . . 69 15.6. draft-ietf-anima-autonomic-control-plane-00 . . . . . . 73
15.7. draft-ietf-anima-autonomic-control-plane-01 . . . . . . 69 15.7. draft-ietf-anima-autonomic-control-plane-01 . . . . . . 73
15.8. draft-ietf-anima-autonomic-control-plane-02 . . . . . . 70 15.8. draft-ietf-anima-autonomic-control-plane-02 . . . . . . 74
15.9. draft-ietf-anima-autonomic-control-plane-03 . . . . . . 70 15.9. draft-ietf-anima-autonomic-control-plane-03 . . . . . . 74
15.10. draft-ietf-anima-autonomic-control-plane-04 . . . . . . 71 15.10. draft-ietf-anima-autonomic-control-plane-04 . . . . . . 75
15.11. draft-ietf-anima-autonomic-control-plane-05 . . . . . . 71 15.11. draft-ietf-anima-autonomic-control-plane-05 . . . . . . 75
15.12. draft-ietf-anima-autonomic-control-plane-06 . . . . . . 72 15.12. draft-ietf-anima-autonomic-control-plane-06 . . . . . . 76
15.13. draft-ietf-anima-autonomic-control-plane-07 . . . . . . 72 15.13. draft-ietf-anima-autonomic-control-plane-07 . . . . . . 76
15.14. draft-ietf-anima-autonomic-control-plane-08 . . . . . . 74 15.14. draft-ietf-anima-autonomic-control-plane-08 . . . . . . 78
15.15. draft-ietf-anima-autonomic-control-plane-09 . . . . . . 75 15.15. draft-ietf-anima-autonomic-control-plane-09 . . . . . . 79
15.16. draft-ietf-anima-autonomic-control-plane-10 . . . . . . 77 15.16. draft-ietf-anima-autonomic-control-plane-10 . . . . . . 81
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 78 15.17. draft-ietf-anima-autonomic-control-plane-11 . . . . . . 83
16.1. Normative References . . . . . . . . . . . . . . . . . . 78 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 83
16.2. Informative References . . . . . . . . . . . . . . . . . 80 16.1. Normative References . . . . . . . . . . . . . . . . . . 83
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 82 16.2. Informative References . . . . . . . . . . . . . . . . . 85
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 88
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 design across the network.[RFC7575] defines the fundamental ideas and 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]
skipping to change at page 5, line 37 skipping to change at page 5, line 37
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.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119] when they appear in ALL CAPS. When these words are not in
ALL CAPS (such as "should" or "Should"), they have their usual
English meanings, and are not to be interpreted as [RFC2119] key
words.
This document uses the following terms (sorted alphabetically): This document uses the following terms (sorted alphabetically):
ACP "Autonomic Control Plane". The Autonomic Function defined in ACP "Autonomic Control Plane". The Autonomic Function defined in
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
skipping to change at page 6, line 38 skipping to change at page 6, line 45
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.5. more ACP secure channels. See Section 6.12.5.
ACP VRF The ACP is modelled in this document as a "Virtual Routing
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 An FQDN (Fully Qualified Domain Name) identifying an AN Domain Name An FQDN (Fully Qualified Domain Name) identifying an
Autonomic Network. It is stored in the ACP information field of Autonomic Network. It is stored in the ACP information field of
an ANI devices LDevID. See Section 6.1.1. 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
skipping to change at page 8, line 11 skipping to change at page 8, line 14
the "ACP instance of GRASP" which is run inside the ACP to support the "ACP instance of GRASP" which is run inside the ACP to support
BRSKI and other future Autonomic Functions. See BRSKI and other future Autonomic Functions. See
[I-D.ietf-anima-grasp]. [I-D.ietf-anima-grasp].
IDevID An "Initial Device IDentity" X.509 certificate installed by IDevID An "Initial Device IDentity" X.509 certificate installed by
the vendor on new equipment. Contains information that the vendor on new equipment. Contains information that
establishes the identity of the device in the context of its establishes the identity of the device in the context of its
vendor/manufacturer such as device model/type and serial number. vendor/manufacturer such as device model/type and serial number.
See [AR8021]. See [AR8021].
Intent Northbound operator and automation facing interface of an
Autonomic Network according to [I-D.ietf-anima-reference-model].
LDevID A "Local Device IDentity" X.509 certificate installed during LDevID A "Local Device IDentity" X.509 certificate installed during
an "enrollment". The ACP depends on a Domain Certificate which is an "enrollment". The ACP depends on a Domain Certificate which is
an LDevID. See [AR8021]. an LDevID. See [AR8021].
MIC "Manufacturer Installed Certificate". Another word not used in MIC "Manufacturer Installed Certificate". Another word not used in
this document to describe an IDevID. this document to describe an IDevID.
RPL "IPv6 Routing Protocol for Low-Power and Lossy Networks". The RPL "IPv6 Routing Protocol for Low-Power and Lossy Networks". The
routing protocol used in the ACP. routing protocol used in the ACP.
skipping to change at page 8, line 37 skipping to change at page 8, line 43
UDI "Unique Device Identifier". In the context of this document UDI "Unique Device Identifier". In the context of this document
unsecured identity information of a device typically consisting of unsecured identity information of a device typically consisting of
at least device model/type and serial number, often in a vendor at least device model/type and serial number, often in a vendor
specific format. See sUDI and LDevID. specific format. See sUDI and LDevID.
ULA A "Unique Local Address" (ULA) is an IPv6 address in the block ULA A "Unique Local Address" (ULA) is an IPv6 address in the block
fc00::/7, defined in [RFC4193]. It is the approximate IPv6 fc00::/7, defined in [RFC4193]. It is the approximate IPv6
counterpart of the IPv4 private address ([RFC1918]). counterpart of the IPv4 private address ([RFC1918]).
3. Use Cases for an Autonomic Control Plane ACP VRF The ACP is modelled in this document as a "Virtual Routing
and Forwarding" (VRF) component in a network device.
3. Use Cases for an Autonomic Control Plane
3.1. An Infrastructure for Autonomic Functions 3.1. An Infrastructure for Autonomic Functions
Autonomic Functions need a stable infrastructure to run on, and all Autonomic Functions need a stable infrastructure to run on, and all
autonomic functions should use the same infrastructure to minimise autonomic functions should use the same infrastructure to minimise
the complexity of the network. This way, there is only need for a the complexity of the network. This way, there is only need for a
single discovery mechanism, a single security mechanism, and other single discovery mechanism, a single security mechanism, and other
processes that distributed functions require. processes that distributed functions require.
3.2. Secure Bootstrap over an Unconfigured Network 3.2. Secure Bootstrap over an unconfigured Network
Today, bootstrapping a new device typically requires all devices Today, bootstrapping a new device typically requires all devices
between a controlling node (such as an SDN controller) and the new between a controlling node (such as an SDN controller) and the new
device to be completely and correctly addressed, configured and device to be completely and correctly addressed, configured and
secured. Therefore, bootstrapping a network happens in layers around secured. Therefore, bootstrapping a network happens in layers around
the controller. Without console access (for example through an out the controller. Without console access (for example through an out
of band network) it is not possible today to make devices securely of band network) it is not possible today to make devices securely
reachable before having configured the entire network leading up to reachable before having configured the entire network leading up to
them. them.
skipping to change at page 13, line 15 skipping to change at page 13, line 15
options. options.
6.1.1. ACP information 6.1.1. ACP information
The domain certificate (LDevID) of an autonomic node MUST contain ACP The domain certificate (LDevID) of an autonomic node MUST contain ACP
specific information, specifically the domain name, and the ACP specific information, specifically the domain name, and the ACP
address of the device. This information MUST be encoded in the address of the device. This information MUST be encoded in the
LDevID in the subjectAltName / rfc822Name field according to the LDevID in the subjectAltName / rfc822Name field according to the
following ABNF definition ([RFC5234]): following ABNF definition ([RFC5234]):
anima.acp+<acp-address>[+<rsub>{+<extensions>}}@<domain> ani.acp+<acp-address>[+<rsub>{+<extensions>}}@<domain>
acp-information = acp-device-info "@" acp-domain acp-information = acp-device-info "@" acp-domain
acp-device-info = "ani.acp+" acp-address [ "+" rsub extensions ] acp-device-info = "ani.acp+" acp-address [ "+" rsub extensions ]
acp-address = 32hex-dig acp-address = 32hex-dig
hex-dig = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" hex-dig = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
rsub = [ domain-name ] ; empty if not used rsub = [ domain-name ] ; empty if not used
skipping to change at page 13, line 40 skipping to change at page 13, line 40
domain-name = ; <domain> according to section 3.5 of [RFC1034] domain-name = ; <domain> according to section 3.5 of [RFC1034]
extensions = *( "+" extension ) extensions = *( "+" extension )
extension = ; future definition. Must fit into [RFC5322] simple dot- extension = ; future definition. Must fit into [RFC5322] simple dot-
atom format. atom format.
Example: Example:
acp-information = anima.acp+fda379A6f6ee00000200000064000000+area51 acp-information = ani.acp+fda379a6f6ee00000200000064000000+area51.r
.research@acp.example.com esearch@acp.example.com
routing-subdomain = area51.research.acp.example.com routing-subdomain = area51.research.acp.example.com
"acp-address" can not use standard IPv6 address formats because it "acp-address" can not use standard IPv6 address formats because it
must match the simple dot-atom format of [RFC5322]. ":" are not must match the simple dot-atom format of [RFC5322]. ":" are not
allowed in that format. allowed in that format.
"acp-domain" is used to indicate the Autonomic Domain across which "acp-domain" is used to indicate the Autonomic Domain across which
all ACP nodes trust each other and are willing to build ACP channel all ACP nodes trust each other and are willing to build ACP channel
with each other. See Section 6.6. It SHOULD be the FQDN of a domain with 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 owned by the operator assigning the certificate. This is a simple
method to ensure that the acp-domain is globally unique and collision method to ensure that the acp-domain is globally unique and collision
of ACP addresses would therefore only happen due to ULA hash of ACP addresses would therefore only happen due to ULA hash
collisions. If the operator does not own any FQDN, it should choose collisions. If the operator does not own any FQDN, it should choose
a string in FQDN format that intends to be equally unique. a string in FQDN format that intends to be equally unique.
"routing-subdomain" is the autonomic "routing subdomain" that is used "routing-subdomain" is the autonomic subdomain that is used to
used in addressing to calculate the hash used in the creation of the calculate the hash for the ULA prefix of the ACP address of the
ACP address of the device. As the name implies, every routing device. "rsub" is optional and should only used when its impacts are
subdomain is also a separate routing subdomain. "rsub" is optional understood. When "rsub" is not used, "routing-subdomain" is "acp-
and should only used when its impacts are understood. When "rsub" is domain".
not used, "routing-subdomain" is "acp-domain".
The optional "extensions" field is used for future extensions to this The optional "extensions" field is used for future extensions to this
specification. It MUST be ignored if present and not understood. specification. It MUST be ignored if present and not understood.
Note that the maximum size of "acp-information" is 254 characters and Note that the maximum size of "acp-information" is 254 characters and
the maximum size of acp-device-info is 64 characters according to the maximum size of acp-device-info is 64 characters according to
[RFC5280] that is referring to [RFC2821] (superceeded by [RFC5321]). [RFC5280] that is referring to [RFC2821] (superceeded by [RFC5321]).
The subjectAlName / rfc822Name encoding of the ACP domain name and The subjectAlName / rfc822Name encoding of the ACP domain name and
ACP address is used for the following reasons: ACP address is used for the following reasons:
skipping to change at page 15, line 21 skipping to change at page 15, line 20
appropriate fields of the certificate, so there are not many appropriate fields of the certificate, so there are not many
alternatives with pre-existing fields where the only possible alternatives with pre-existing fields where the only possible
conflicts would likely be beneficial. conflicts would likely be beneficial.
o rfc822Name encoding is quite flexible. We choose to encode the o rfc822Name encoding is quite flexible. We choose to encode the
full ACP address AND the domain name with sub part into a single full ACP address AND the domain name with sub part into a single
rfc822Name information element it, so that it is easier to rfc822Name information element it, so that it is easier to
examine/use the encoded "ACP information (field)". examine/use the encoded "ACP information (field)".
o The format of the rfc822Name is choosen so that an operator can o The format of the rfc822Name is choosen so that an operator can
set up a mailbox called anima.acp@<domain> that would receive set up a mailbox called ani.acp@<domain> that would receive
emails sent towards the rfc822Name of any AN device inside a emails sent towards the rfc822Name of any AN device inside a
domain. This is possible because in many modern mail systems, domain. This is possible because in many modern mail systems,
components behind a plus symbol are considered part of a single components behind a plus symbol are considered part of a single
mailbox. In other words, it is not necessary to set up a separate mailbox. In other words, it is not necessary to set up a separate
mailbox for every autonomic devices ACP information field, but mailbox for every autonomic devices ACP information field, but
only one for the whole domain. only one for the whole domain.
o In result, if any unexpected use of the ACP addressing information o In result, if any unexpected use of the ACP addressing information
in a certificate happens, it is benign and detectable: it would be in a certificate happens, it is benign and detectable: it would be
mail to that mailbox. mail to that mailbox.
skipping to change at page 17, line 36 skipping to change at page 17, line 36
of running parts of a network disconnected from any CA. of running parts of a network disconnected from any CA.
Certificate lifetime should be set to be as short as feasible. Given Certificate lifetime should be set to be as short as feasible. Given
how certificate renewal is fully automated via ACP and EST, the how certificate renewal is fully automated via ACP and EST, the
primarily imiting factor for shorter certificate lifetimes (than the primarily imiting factor for shorter certificate lifetimes (than the
typical one year) is load on the EST server(s) and CA. It is typical one year) is load on the EST server(s) and CA. It is
therefore recommended that ACP domain certificates are managed via a therefore recommended that ACP domain certificates are managed via a
CA chain where the assigning CA has enough peformance to manage short CA chain where the assigning CA has enough peformance to manage short
lived certificates. lived certificates.
See Section 10.1 for further optimizationss of certificate See Section 10.1 for further optimizations of certificate
optimizations when BRSKI can be used. optimizations when BRSKI can be used.
6.2. AN Adjacency Table 6.2. AN Adjacency Table
To know to which nodes to establish an ACP channel, every autonomic To know to which nodes to establish an ACP channel, every autonomic
node maintains an adjacency table. The adjacency table contains node maintains an adjacency table. The adjacency table contains
information about adjacent autonomic nodes, at a minimum: node-ID, information about adjacent autonomic nodes, at a minimum: node-ID,
Link-local IPv6 address (discovered by GRASP as explained below), Link-local IPv6 address (discovered by GRASP as explained below),
domain, certificate. An autonomic device MUST maintain this domain, certificate. An autonomic device MUST maintain this
adjacency table up to date. This table is used to determine to which adjacency table up to date. This table is used to determine to which
skipping to change at page 18, line 38 skipping to change at page 18, line 38
neighbors. Ideally, all physical interfaces SHOULD be brought up neighbors. Ideally, all physical interfaces SHOULD be brought up
enough so that ACP discovery can be performed and any physically 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).
Note that the use of the IPv6 link-local multicast address
(ALL_GRASP_NEIGHBORS) implies the need to use MLD ([RFC3810]) to
announce the desire to receive packets for that address. Otherwise
DULL GRASP could fail to operate correctly in the presence of MLD
snooping, non-ACP enabled L2 switches - because those would stop
forwarding DULL GRASP packets. Switches not supporting MLD snooping
simply need to operate as pure L2 bridges for IPv6 multicast packets
for DULL GRASP to work.
ACP discovery MUST NOT be enabled by default on any non-physical ACP discovery MUST NOT be enabled by default on any non-physical
interfaces. In particular, ACP discovery MUST NOT run inside the interfaces. In particular, ACP discovery MUST NOT run inside the
ACP. See Section 8.2.2 how to enable and use ACP with auto-discovery ACP. See Section 8.2.2 how to enable and use ACP with auto-discovery
across configured tunnels. 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
skipping to change at page 21, line 6 skipping to change at page 21, line 12
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 multiple 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 domains with different CA (certificate o ACP connections across domains with different CA (certificate
skipping to change at page 23, line 29 skipping to change at page 23, line 36
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 the device certificates indicate a CDP or OCSP then the peer's o If the device certificates indicate a CDP or OCSP then the peer's
certificate must be valid occording to those criteria. eg: OCSP certificate must be valid occording to those criteria. eg: OCSP
check across 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. 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).
6.7. Security Association protocols 6.7. Security Association protocols
The following sections define the security association protocols that The following sections define the security association protocols that
we consider to be important and feasible to specify in this document: we consider to be important and feasible to specify in this document:
6.7.1. ACP via IKEv2 6.7.1. ACP via IKEv2
skipping to change at page 25, line 46 skipping to change at page 26, line 7
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 was added designs such distributed discovery does not exist at all or was added
as an afterthought and relied upon inconsistently. as an afterthought and relied upon inconsistently.
ACP provides IP unicast routing via the RPL routing protocol
(described below).
The ACP does not use IP multicast routing nor does it provide generic The ACP does not use IP multicast routing nor does it provide generic
IP multicast services, but only IP unicast which is realized via the IP multicast services. Instead, the ACP provides service discovery
RPL routing protocol (described below). Instead of IP multicast via the objective discovery/announcement and negotiation mechanisms
routing, the ACP provides objective discovery and negotiation of the ACP GRASP instance (services are a form of objectives). These
realized via the ACP instance of GRASP. We consider this to be a mechanisms use hop-by-hop reliable flooding of GRASP messages for
more lightweight, modular and easier to extend approach than trying both service discovery (GRASP M_DISCOVERY messages) and service
to put service announcement and discovery onto some autoconfigured announcement (GRASP M_FLOOD messages).
network wide IP multicast layer (for which so far there is no good
definition) or embed it into some IGP flooding mechanism (which makes IP multicast is not used by the ACP because the ANI itself does not
it less modular and agile to improve upon). require IP multicast but only service announcement/discovery. Using
IP multicast for that would have made it necessary to develop a zero-
touch autoconfiguring solution for ASM (Any Source Multicast -
original form of IP multicast defined in [RFC1112]), which would be
quite complex and difficult to justify. One aspect of complexity
that has never been attempted to be solved in IETF documents is the
automatic-selection of routers that should be PIM-SM rendezvous
points (RPs) (see xref target="RFC7761"/>. The other aspects of
complexity are the implementation of MLD ([RFC4604]), PIM-SM and
Anycast-RP (see [RFC4610]). If those implementations already exist
in a product, then they would be very likely tied to accelerated
forwarding which consumes hardware resources, and that in return is
difficult to justify as a cost of performing only service discovery.
Future ASA may need high performance in-network data replication.
That is the case when the use of IP multicast is justified. These
ASA can then use service discovery from ACP GRASP, and then they do
not need ASM but only SSM (Source Specific Multicast, see xref
target="RFC4607"/>) for the IP multicast replication. SSM itself can
simply be enabled in the data plane (or even in an update to the ACP)
without any other configuration than just enabling it on all nodes
and only requires a simpler version of MLD (see [RFC5790]).
LSP (Link State Protocol) based IGP routing protocols typically have
a mechanism to flood information, and such a mechanism could be used
to flood GRASP objectives by defining them to be information of that
IGP. This would be a possible optimization in future variations of
the ACP that do use an LSP routing protocol. Note though that such a
mechanism would not work easily for GRASP M_DISCOVERY messages which
are constrained flooded up to a node where a responder is found. We
do expect that many future services in ASA will have only few
consuming ASA, and for those cases, M_DISCOVERY is the more efficient
method than flooding across the whole domain.
Beceause the ACP uses RPL, one desireable future extension is to use
RPLs existing notion of loop-free distribution trees (DODAG) to make
GRASPs flooding more efficient both for M_FLOOD and M_DISCOVERY) See
Section 6.12.5 how this will be specifically beneficial when using
NBMA interfaces. For robustness and easyness, this is not currently
used in this document because it is not quite clear yet what exactly
the implications are to make GRASP flooding depend on RPL DODAG
convergence and how difficult it would be to let GRASP flooding
access the DODAG information.
6.8.2. ACP as the Security and Transport substrate for GRASP 6.8.2. ACP as the Security and Transport substrate for GRASP
In the terminology of GRASP ([I-D.ietf-anima-grasp]), the ACP is the In the terminology of GRASP ([I-D.ietf-anima-grasp]), the ACP is the
security and transport substrate for the GRASP instance run inside security and transport substrate for the GRASP instance run inside
the ACP ("ACP GRASP"). the ACP ("ACP GRASP").
This means that the ACP is responsible to ensure that this instance This means that the ACP is responsible to ensure that this instance
of GRASP is only using the virtual interfaces created by the ACP for of GRASP is only sending messages across the virtual interfaces
ACP GRASP. Whenever the ACP adds or deletes such an interface created by the ACP for ACP GRASP. Whenever the ACP adds or deletes
(because of new ACP secure channels or loss thereof), the ACP needs such an interface (because of new ACP secure channels or loss
to indicate this to the ACP instance of GRASP. The ACP exists also thereof), the ACP needs to indicate this to the ACP instance of
in the absence of any active ACP neighbors. It is created when the GRASP. The ACP exists also in the absence of any active ACP
device has a domain certificate. In this case ASAs using GRASP neighbors. It is created when the device has a domain certificate.
running on the same device would still need to be able to discover In this case ASAs using GRASP running on the same device would still
each others objectives. When the ACP does not exist, ASAs leveraging need to be able to discover each others objectives. When the ACP
the ACP instance of GRASP via APIs MUST still be able to operate, and does not exist, ASAs leveraging the ACP instance of GRASP via APIs
MUST be able to understand that there is no ACP and that therefore MUST still be able to operate, and MUST be able to understand that
the ACP instance of GRASP can not provide services. there is no ACP and that therefore the ACP instance of GRASP can not
provide services.
GRASP unicast messages inside the ACP to a non-link-local ACP peer The way ACP acts as the security and transport substrate for GRASP is
address use TLS 1.2 ([RFC5246]) connections with AES256 encryption visualized in the following picture:
and SHA256. Mutual authentication is via the domain certificates
using the same rules as for secure channels (Section 6.6). GRASP ACP:
unicast messages inside the ACP to link-local ACP neighbor addresses ...............................................................
use TCP. . .
. /-GRASP-flooding-\ ACP GRASP instance .
. / \ .
. GRASP GRASP GRASP .
. link-local unicast link-local .
. multicast messages multicast .
. messages | messages .
. | | | .
...............................................................
. v v v ACP security and transport .
. | | | substrate for GRASP .
. | | | .
. | ACP GRASP | - ACP GRASP loopback .
. | loopback | loopback interface .
. | TLS | - AN-cert auth .
. | | | .
. ACP GRASP | ACP GRASP - ACP GRASP virtual .
. subnet1 | subnet2 virtual inerfaces .
. TCP | TCP .
. | | | .
...............................................................
. | | | ^^^ Users of ACP (GRASP/ASA) .
. | | | ACP interfaces/addressing .
. | | | .
. | | | .
. | ACP-loopack | - ACP loopback interface .
. | ACP-address | - address (global ULA) .
. subnet1 | subnet2 - ACP virtual interfaces .
. link-local | link-local - addresses .
...............................................................
. | | | ACP routing and forwarding .
. | RPL-routing | .
. | /IP-Forwarding\ | .
. | / \ | .
. ACP IPv6 packets ACP IPv6 packets .
. |/ \| .
. IPsec/dTLS IPsec/dTLS - AN-cert auth .
...............................................................
| | Data Plane
| |
| | - ACP secure channe
link-local link-local - encap addresses
subnet1 subnet2 - data plane interfaces
| |
ACP-Nbr1 ACP-Nbr2
Figure 2
GRASP unicast messages inside the ACP always use the ACP address.
Link-local ACP addresses must not be used inside objectives. GRASP
unicast messages inside the ACP are transported via TLS 1.2
([RFC5246]) connections with AES256 encryption and SHA256. Mutual
authentication is via the domain certificate using the same rules as
for secure channels (Section 6.6).
GRASP link-local multicast messages are targeted for a specific ACP GRASP link-local multicast messages are targeted for a specific ACP
virtual interface (as defined Section 6.12.5) but are sent by the ACP virtual interface (as defined Section 6.12.5) but are sent by the ACP
into an equally built ACP GRASP virtual interface constructed from into an equally built ACP GRASP virtual interface constructed from
the TCP connection(s) to the IPv6 link-local neighbor address(es) on the TCP connection(s) to the IPv6 link-local neighbor address(es) on
the underlying ACP virtual interface. If the ACP GRASP virtual the underlying ACP virtual interface. If the ACP GRASP virtual
interface has two or more neighbors, the GRASP link-local multicast interface has two or more neighbors, the GRASP link-local multicast
messages are replicated to all neighbor TCP connections. messages are replicated to all neighbor TCP connections.
TLS and TLS connections for GRASP in the ACP use the IANA assigned TLS and TLS connections for GRASP in the ACP use the IANA assigned
TCP port for GRASP (7107). Effectively the transport stack is TCP port for GRASP (7107). Effectively the transport stack is
expected to be TLS for connections from/to the ULA address and TCP expected to be TLS for connections from/to the ACP address (eg:
for connections from/to link-local addreses on the ACP virtual global scope address(es)) and TCP for connections from/to link-local
interfaces. addreses on the ACP virtual interfaces. The latter ones are only
used for flooding of GRASP messages.
6.8.2.1. Discussion 6.8.2.1. Discussion
TCP encapsulation for GRASP M_DISCOVERY and M_FLOOD link local TCP encapsulation for GRASP M_DISCOVERY and M_FLOOD link local
messages is used because these messages are flooded across messages is used because these messages are flooded across
potentially many hops to all ACP devices and a single link with even potentially many hops to all ACP devices and a single link with even
temporary packet loss issues (eg: WiFi/Powerline link) can reduce the temporary packet loss issues (eg: WiFi/Powerline link) can reduce the
probability for loss free transmission so much that applications probability for loss free transmission so much that applications
would want to increase the frequency with which they send these would want to increase the frequency with which they send these
messages. This would result in more traffic flooding than hop-by-hop messages. This would result in more traffic flooding than hop-by-hop
reliable retransmission as provided for by TCP. reliable retransmission as provided for by TCP.
TLS is mandated for GRASP non-link-local unicast because the ACP TLS is mandated for GRASP non-link-local unicast because the ACP
secure channel mandatory authentication and encryption protects only secure channel mandatory authentication and encryption protects only
against attacks from the outside but not against attacks from the against attacks from the outside but not against attacks from the
inside: Compromised ACP members that have (not yet) been detected and inside: Compromised ACP members that have (not yet) been detected and
removed (eg: via domain certificate revocation / expiry). removed (eg: via domain certificate revocation / expiry).
If GRASP peer connections would just use TCP, compromised ACP members If GRASP peer connections would just use TCP, compromised ACP members
could simply eavesdrop passively on GRASP peer connections for whom could simply eavesdrop passively on GRASP peer connections for whom
they are onpath (man in the middle). Or intercept and modify them. they are onpath ("Man In The Middle" - MITM). Or intercept and
With TLS, it is not possible to completely eliminate problems with modify them. With TLS, it is not possible to completely eliminate
compromised ACP members, but it is a lot more complex for them. problems with compromised ACP members, but attacks are a lot more
complex:
With TLS, eavesdropping/spoofing by a compromised ACP device is still Eavesdropping/spoofing by a compromised ACP device is still possible
possible because the provider and consumer of an objective have no because in the model of the ANI and GRASP, the provider and consumer
unique information about the other side that would allow them to of an objective have initially no unique information (such as an
distinguish a benevolent from a compromised peer. The compromised identifty) about the other side that would allow them to distinguish
ACP device would simply announce the objective as well, potentially a benevolent from a compromised peer. The compromised ACP device
filter the original objective in GRASP when it is a Man In The Middle would simply announce the objective as well, potentially filter the
(MITM) and act as an application level proxy. This of course original objective in GRASP when it is a MITM and act as an
requires that the compromised ACP node understand the semantic of the application level proxy. This of course requires that the
GRASP negotiation to an extend that allows it to proxy it without compromised ACP node understand the semantic of the GRASP negotiation
being detected, but in an AN environment this is quite likely. to an extend that allows it to proxy it without being detected, but
in an AN environment this is quite likely public knowledge or evens
standardized.
The GRASP TLS connections are run like any other ACP traffic through The GRASP TLS connections are run like any other ACP traffic through
the ACP secure channels. This leads to double authentication/ the ACP secure channels. This leads to double authentication/
encryption. Future work optimizations can minimize could run GRASP encryption. Future work optimizations could avoid this but it is
beside the secure channel to avoid this but it is unclear how unclear how beneficial/feasible this is:
beneficial/feasible this is:
o The security considerations for GRASP change against attacks from o The security considerations for GRASP change against attacks from
non-ACP (eg: "outside") nodes: TLS is subject to reset attacks non-ACP (eg: "outside") nodes: TLS is subject to reset attacks
while secure channel protocols may be not (eg: IPsec is not). while secure channel protocols may be not (eg: IPsec is not).
o The secure channel method may leverage hardware acceleration and o The secure channel method may leverage hardware acceleration and
there may be little or no gain in eliminating it. there may be little or no gain in eliminating it.
o The GRASP TLS connections need to implement any additional o The GRASP TLS connections need to implement any additional
security options that are required for secure channels. For security options that are required for secure channels. For
skipping to change at page 28, line 40 skipping to change at page 30, line 52
The channels explained above typically only establish communication The channels explained above typically only establish communication
between two adjacent nodes. In order for communication to happen between two adjacent nodes. In order for communication to happen
across multiple hops, the autonomic control plane requires internal across multiple hops, the autonomic control plane requires internal
network wide valid addresses and routing. Each autonomic node must network wide valid addresses and routing. Each autonomic node must
create a virtual interface with a network wide unique address inside create a virtual interface with a network wide unique address inside
the ACP context mentioned in Section 6.9. This address may be used the ACP context mentioned in Section 6.9. This address may be used
also in other virtual contexts. also in other virtual contexts.
With the algorithm introduced here, all ACP devices in the same With the algorithm introduced here, all ACP devices in the same
subdomain have the same /48 prefix. Conversely, global IDs from routing subdomain have the same /48 ULA global ID prefix.
different domains are unlikely to clash, such that two networks can
be merged, as long as the policy allows that merge. See also Conversely, ULA global IDs from different domains are unlikely to
Section 9.1 for a discussion on merging domains. clash, such that two networks can be merged, as long as the policy
allows that merge. See also Section 9.1 for a discussion on merging
domains.
Links inside the ACP only use link-local IPv6 addressing, such that Links inside the ACP only use link-local IPv6 addressing, such that
each node only requires one routable virtual address. each node only requires one routable virtual address.
6.10.1. Fundamental Concepts of Autonomic Addressing 6.10.1. Fundamental Concepts of Autonomic Addressing
o Usage: Autonomic addresses are exclusively used for self- o Usage: Autonomic addresses are exclusively used for self-
management functions inside a trusted domain. They are not used management functions inside a trusted domain. They are not used
for user traffic. Communications with entities outside the for user traffic. Communications with entities outside the
trusted domain use another address space, for example normally trusted domain use another address space, for example normally
skipping to change at page 29, line 31 skipping to change at page 31, line 45
was deemed to be sufficient. was deemed to be sufficient.
o No external connectivity: They do not provide access to the o No external connectivity: They do not provide access to the
Internet. If a node requires further reaching connectivity, it Internet. If a node requires further reaching connectivity, it
should use another, traditionally managed address scheme in should use another, traditionally managed address scheme in
parallel. parallel.
o Addresses in the ACP are permanent, and do not support temporary o Addresses in the ACP are permanent, and do not support temporary
addresses as defined in [RFC4941]. addresses as defined in [RFC4941].
o Addresses in the ACP are not considered sensitive on privacy
grounds because ACP devices are not expected to be end-user
devices. Therefore, ACP addresses do not need to be pseudo-random
as discussed in [RFC7721]. Because they are not propagated to
untrusted (non ACP) devices and stay within a domain (of trust),
we also consider them not to be subject to scanning attacks.
The ACP is based exclusively on IPv6 addressing, for a variety of The ACP is based exclusively on IPv6 addressing, for a variety of
reasons: reasons:
o Simplicity, reliability and scale: If other network layer o Simplicity, reliability and scale: If other network layer
protocols were supported, each would have to have its own set of protocols were supported, each would have to have its own set of
security associations, routing table and process, etc. security associations, routing table and process, etc.
o Autonomic functions do not require IPv4: Autonomic functions and o Autonomic functions do not require IPv4: Autonomic functions and
autonomic service agents are new concepts. They can be autonomic service agents are new concepts. They can be
exclusively built on IPv6 from day one. There is no need for exclusively built on IPv6 from day one. There is no need for
skipping to change at page 30, line 5 skipping to change at page 32, line 26
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(routing-subdomain) | Type | (sub-scheme) |
+--+-----------------+------+--------------------------------------+ +--+-------------------------+------+------------------------------+
Figure 2: ACP Addressing Base Scheme Figure 3: 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" (term from [RFC4193]) is set here to be a hash o The 40 bits ULA "global ID" (term from [RFC4193]) for ACP
of the subdomain name, which results in a pseudo-random 40 bit addresses carried in the ACP information field of domain
value. It is calculated as the first 40 bits of the SHA256 hash certificates are the first 40 bits of the SHA256 hash of the
of the subdomain name, in the example of Section 6.1.1 routing subdomain from the same ACP information field. In the
"area51.research.acp.example.com". example of Section 6.1.1, the routing subdomain is
"area51.research.acp.example.com" and the 40 bits ULA "global ID"
a379a6f6ee.
o To allow for extensibility, the fact that the ULA "global ID" is a o To allow for extensibility, the fact that the ULA "global ID" is a
hash of the subdomain name SHOULD NOT be assumed by any autonomic hash of the routing subdomain SHOULD NOT be assumed by any
device during normal operations. The hash function is only autonomic device during normal operations. The hash function is
executed during the creation of the certificate. If BRSKI is used only executed during the creation of the certificate. If BRSKI is
then the registrar will create the ACP information field in used then the registrar will create the ACP information field in
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. This o Type: This field allows different address sub-schemes. This
addresses the "upgradability" requirement. Assignment of types addresses the "upgradability" requirement. Assignment of types
for this field should be maintained by IANA. for this field will be maintained by IANA.
The sub-scheme may imply a range or set of addresses assigned to the The sub-scheme may imply a range or set of addresses assigned to the
device, this is called the ACP address range/set and explained in device, this is called the ACP address range/set and explained in
each sub-scheme. each sub-scheme.
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 00b (zero) The sub-scheme defined here is defined by the Type value 00b (zero)
in the base scheme. in the base scheme.
64 64 64 64
+-----------------+---------+---++-----------------------------+---+ +-----------------+---------+---++-----------------------------+---+
| (base scheme) | Zone-ID | Z || Device-ID | | (base scheme) | Zone-ID | Z || Device-ID |
| | | || Registrar-ID | Device-Number| V | | | | || Registrar-ID | Device-Number| V |
+-----------------+---------+---++--------------+--------------+---+ +-----------------+---------+---++--------------+--------------+---+
50 13 1 48 15 1 50 13 1 48 15 1
Figure 3: ACP Zone Addressing Sub-Scheme Figure 4: ACP Zone Addressing Sub-Scheme
The fields are defined as follows: The fields are defined as follows:
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 Z: MUST be 0.
skipping to change at page 33, line 11 skipping to change at page 35, line 33
The sub-scheme defined here is defined by the Type value 00b (zero) The sub-scheme defined here is defined by the Type value 00b (zero)
in the base scheme. in the base scheme.
64 64 64 64
+---------------------+---------+---++-----------------------------+ +---------------------+---------+---++-----------------------------+
| (base scheme) |Subnet-ID| Z || Interface Identifier | | (base scheme) |Subnet-ID| Z || Interface Identifier |
+---------------------+---------+---++-----------------------------+ +---------------------+---------+---++-----------------------------+
50 13 1 50 13 1
Figure 4: ACP Manual Addressing Sub-Scheme Figure 5: ACP Manual Addressing Sub-Scheme
The fields are defined as follows: The fields are defined as follows:
o Subnet-ID: Configured subnet identifier. o Subnet-ID: Configured subnet identifier.
o Z: MUST be 1. o Z: MUST be 1.
o Interface Identifier. o Interface Identifier.
This sub-scheme is meant for "manual" allocation to subnets where the This sub-scheme is meant for "manual" allocation to subnets where the
skipping to change at page 34, line 12 skipping to change at page 36, line 32
The sub-scheme defined here is defined by the Type value 01b (one) in The sub-scheme defined here is defined by the Type value 01b (one) in
the base scheme. the base scheme.
50 78 50 78
+---------------------++-----------------------------+----------+ +---------------------++-----------------------------+----------+
| (base scheme) || Device-ID | | (base scheme) || Device-ID |
| || Registrar-ID | Device-Number| V | | || Registrar-ID | Device-Number| V |
+---------------------++--------------+--------------+----------+ +---------------------++--------------+--------------+----------+
46 33/17 8/16 46 33/17 8/16
Figure 5: ACP Vlong Addressing Sub-Scheme Figure 6: 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 routed networks (eg: as in IoT) with more than 2^32 Device- flatter routed networks (eg: as in IoT) with more than 2^32 Device-
Numbers. It also allows for up to 2^16 - 65536 different virtualized Numbers. It also allows for up to 2^16 - 65536 different virtualized
adddresses, which could be used to address individual software adddresses, which could be used to address individual software
components in an ACP device. 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:
skipping to change at page 34, line 50 skipping to change at page 37, line 23
a large number of internal ACP users requiring separate V(irtual) a large number of internal ACP users requiring separate V(irtual)
addresses. For example large SDN controllers with container addresses. For example large SDN controllers with container
modular software architecture (see Section 8.1.2). modular software architecture (see Section 8.1.2).
In the Vlong addressing sub-scheme, the ACP address in the In the Vlong addressing sub-scheme, the ACP address in the
certificate has all V field bits as zero. The ACP address set certificate has all V field bits as zero. The ACP address set
includes address for the device includes any V value. includes address for the device includes any V value.
6.10.6. Other ACP Addressing Sub-Schemes 6.10.6. Other ACP Addressing Sub-Schemes
Other ACP addressing sub-schemes can be defined if and when required. Before further addressing sub-schemes are defined, experience with
IANA would need to assign a new "type" for each new addressing sub- the schemes defined here should be collected. The schemes defined in
scheme. With the current allocations, 5 more schemes are possible this document have been devised to allow hopefully sufficiently
without further reducing the number of bits in a future scheme. flexible setup of ACPs for a variety of situation. These reasons
also lead to the fairly liberal use of address space: The Zone
addressing sub-schemes is intended to enable optimized routing in
large networks by reserving bits for zones. The Vlong addressing
sub-scheme enables the allocation of 8/16 bit of addresses inside
individual ACP nodes. Both address spaces allow distributed,
uncoordinated allocation of node addresses by reserving bits for the
Registrar-ID field in the address.
IANA is asked need to assign a new "type" for each new addressing
sub-scheme. With the current allocations, only 2 more schemes are
possible, so the last addressing scheme should consider to be
extensible in itself (eg: by reserving bits from it for further
extensions.
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
routing protocol distributes the ULA created in the previous section routing protocol distributes the ULA created in the previous section
for reachability. The use of the autonomic control plane specific for reachability. The use of the autonomic control plane specific
context eliminates the probable clash with the global routing table context eliminates the probable clash with the global routing table
and also secures the ACP from interference from the configuration and also secures the ACP from interference from the configuration
mismatch or incorrect routing updates. mismatch or incorrect routing updates.
skipping to change at page 42, line 42 skipping to change at page 45, line 31
Assume a LAN with three ACP neighbors, Alice, Bob and Carol. Alices Assume a LAN with three ACP neighbors, Alice, Bob and Carol. Alices
ACP GRASP wants to send a link-local GRASP multicast message to Bob ACP GRASP wants to send a link-local GRASP multicast message to Bob
and Carol. If Alices ACP emulates the LAN as one point-to-point and Carol. If Alices ACP emulates the LAN as one point-to-point
interface to Bob and one to Carol, The sending applications itself interface to Bob and one to Carol, The sending applications itself
will send two copies, if Alices ACP emulates a LAN, GRASP will send will send two copies, if Alices ACP emulates a LAN, GRASP will send
one packet and the ACP will replicate it. The result is the same. one packet and the ACP will replicate it. The result is the same.
The difference happens when Bob and Carol receive their packet. If The difference happens when Bob and Carol receive their packet. If
they use point-to-point ACP virtual interfaces, their GRASP instance they use point-to-point ACP virtual interfaces, their GRASP instance
would forward the packet from Alice to each other as part of the would forward the packet from Alice to each other as part of the
GRASP flooding procedure. These packets are unnecessary and would be GRASP flooding procedure. These packets are unnecessary and would be
discarded by GRASP on receipt as duplicates. If Bob and Charlies ACP discarded by GRASP on receipt as duplicates (by use of the GRASP
would emulate a multi-acccess virtual interface, then this would not Session ID). If Bob and Charlies ACP would emulate a multi-acccess
happen, because GRASPs flooding procedure does not replicate back virtual interface, then this would not happen, because GRASPs
packets to the interface that they where received from. flooding procedure does not replicate back packets to the interface
that they where received from.
Note that link-local GRASP multicast messages are not sent directly Note that link-local GRASP multicast messages are not sent directly
as IPv6 link-local multicast UDP messages into ACP virtual as IPv6 link-local multicast UDP messages into ACP virtual
interfaces, but instead into ACP GRASP virtual interfaces, that are interfaces, but instead into ACP GRASP virtual interfaces, that are
layered on top of ACP virtual interfaces to add TCP reliability to layered on top of ACP virtual interfaces to add TCP reliability to
link-local multicast GRASP messages. Nevertheless, these ACP GRASP link-local multicast GRASP messages. Nevertheless, these ACP GRASP
virtual interfaces perform the same replication of message and virtual interfaces perform the same replication of message and
therefore result in the same impact on flooding. See Section 6.8.2 therefore result in the same impact on flooding. See Section 6.8.2
for more details. for more details.
skipping to change at page 43, line 36 skipping to change at page 46, line 26
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 6 Figure 7
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 44, line 34 skipping to change at page 47, line 26
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
behind it. behind it.
7.2. How (per L2 port DULL GRASP) 7.2. How (per L2 port DULL GRASP)
To support ACP on L2 switches or L2 switches ports of an L3 device, To support ACP on L2 switches or L2 switched ports of an L3 device,
it is necessary to to make those L2 ports look like L3 interfaces for it is necessary to make those L2 ports look like L3 interfaces for
the ACP implementation. This primarily involves the creation of a the ACP implementation. This primarily involves the creation of a
separate DULL GRASP instance/domain on every such L2 port. Because separate DULL GRASP instance/domain on every such L2 port. Because
GRASP has a dedicated IPv6 link-local multicast address, it is GRASP has a dedicated link-local IPv6 multicast address
sufficient that all ethernet packets for this address are being (ALL_GRASP_NEIGHBORS), it is sufficient that all packets for this
extracted at the port level and passed to that DULL GRASP instance. address are being extracted at the port level and passed to that DULL
Likewise the IPv6 link-local multicast packets sent by that DULL GRASP instance. Likewise the IPv6 link-local multicast packets sent
GRASP instance need to be sent only towards the L2 port for this DULL by that DULL GRASP instance need to be sent only towards the L2 port
GRASP instance. for this DULL GRASP instance.
If the device with L2 ports is supporting per L2 port ACP DULL GRASP
as well as MLD snooping ([RFC4541]), then MLD snooping must be
changed to never forward packets for ALL_GRASP_NEIGHBORS because that
would cause the problem that per L2 port ACP DULL GRASP is meant to
overcome (forwarding DULL GRASP packets across L2 ports).
The rest of ACP operations can operate in the same way as in L3 The rest of ACP operations can operate in the same way as in L3
devices: Assume for example that the device is an L3/L2 hybrid device devices: Assume for example that the device is an L3/L2 hybrid device
where L3 interfaces are assigned to VLANs and each VLAN has where L3 interfaces are assigned to VLANs and each VLAN has
potentially multiple ports. DULL GRASP is run as described potentially multiple ports. DULL GRASP is run as described
individually on each L2 port. When it discovers a candidate ACP individually on each L2 port. When it discovers a candidate ACP
neighbor, it passes its IPv6 link-local address and supported secure neighbor, it passes its IPv6 link-local address and supported secure
channel protocols to the ACP secure channel negotiation that can be channel protocols to the ACP secure channel negotiation that can be
bound to the L3 (VLAN) interface. It will simply use link-local IPv6 bound to the L3 (VLAN) interface. It will simply use link-local IPv6
multicast packets to the candidate ACP neighbor. Once a secure multicast packets to the candidate ACP neighbor. Once a secure
skipping to change at page 46, line 15 skipping to change at page 49, line 11
A generic issue with ACP in L2 switched networks is the interaction A generic issue with ACP in L2 switched networks is the interaction
with the Spanning Tree Protocol. Ideally, the ACP should be built with the Spanning Tree Protocol. Ideally, the ACP should be built
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.
8. Support for Non-Autonomic Components (Normative) 8. Support for Non-Autonomic Components (Normative)
8.1. ACP Connect 8.1. ACP Connect
8.1.1. Non-Autonomic Controller / NMS system 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-
skipping to change at page 47, line 23 skipping to change at page 50, line 23
| | . | [ VRF ] | . ^ | || | | . | [ VRF ] | . ^ | ||
+--------+ . +----------------+ . . +-------------+| +--------+ . +----------------+ . . +-------------+|
. . . +-------------+ . . . +-------------+
. . . . . .
data-plane "native" . ACP "native" (unencrypted) data-plane "native" . ACP "native" (unencrypted)
+ ACP auto-negotiated . "ACP connect subnet" + ACP auto-negotiated . "ACP connect subnet"
and encrypted . and encrypted .
ACP connect interface ACP connect interface
eg: "vrf ACP native" (config) eg: "vrf ACP native" (config)
Figure 7: ACP connect Figure 8: 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. For this reason the mechanisms described here do controlled/secured. For this reason the mechanisms described here do
explicitly not include options to allow for a non-ACP router to be explicitly not include options to allow for a non-ACP router to be
connected across an ACP connect interface and addresses behind such a connected across an ACP connect interface and addresses behind such a
router routed inside the ACP. router routed inside the ACP.
skipping to change at page 50, line 36 skipping to change at page 53, line 36
| | | [ACP ]. | . | |+ | | | [ACP ]. | . | |+
| | | .[VRF ] .[VRF ] | v | "ACP address"|| | | | .[VRF ] .[VRF ] | v | "ACP address"||
| +-------+. .[Select].+--------+ "Date Plane || | +-------+. .[Select].+--------+ "Date Plane ||
| | ^ | .[Data ]. | | Address(es)"|| | | ^ | .[Data ]. | | Address(es)"||
| | . | [Plane] | | || | | . | [Plane] | | ||
| | . | [VRF ] | +--------------+| | | . | [VRF ] | +--------------+|
+--------+ . +--------------------+ +--------------+ +--------+ . +--------------------+ +--------------+
. .
data-plane "native" and + ACP auto-negotiated/encrypted data-plane "native" and + ACP auto-negotiated/encrypted
Figure 8: VRF select Figure 9: VRF select
Using two physical and/or virtual subnets (and therefore interfaces) Using two physical and/or virtual subnets (and therefore interfaces)
into NMS Hosts (as per Section 8.1.1) or Software (as per 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 Section 8.1.2) may be seen as additional complexity, for example with
legacy NMS Hosts that support only one IP interface. legacy NMS Hosts that support only one IP interface.
To provide a single subnet into both ACP and Data Plane, the ACP Edge 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 device needs to demultiplex packets from NMS hosts into ACP VRF and
Data Plane VRF. This is sometimes called "VRF select". If the ACP Data Plane VRF. This is sometimes called "VRF select". If the ACP
VRF has no overlapping IPv6 addresses with the Data Plane (as it VRF has no overlapping IPv6 addresses with the Data Plane (as it
skipping to change at page 68, line 5 skipping to change at page 70, line 50
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.
Many design details of ACP are designed with security in mind and
discussed elsehwere in the document:
IPv6 addresses used by devices in the ACP are covered as part of the
Device AN domain certificate as described in Section 6.1.1. This
allows even verification of ownership of a peers IPv6 address when
using a connection authenticated with the AN domain certificate.
The ACP acts as a security (and transport) substrate for GRASP inside
the ACP such that GRASP is not only protected by atacks from the
outside, but also by attacks from compromised inside attackers - by
relying not only on hop-by-hop security of ACP secure channels, but
adding end-to-end security for those GRASP messages. See
Section 6.8.2.
ACP provides for secure, resilient zero-touch discovery of EST
servers for certificate renewal. See Section 6.1.2.
ACP provides extensible, auto-configuring hop-by-hop protection of
the ACP infrastructure via the negotiation of hop-by-hop secure
channel protocols. See Section 6.5 and Section 10.4.
The ACP is designed to minimize attacks from the outside by
minimizing its dependency against any non-ACP operations on a network
device. The only dependency in the specification in this document is
the need to share link-local addresses for the ACP secure channel
encapsulation with the data plane. See Section 6.12.2.
In combination with BRSKI, ACP enables a resilient, fully zero-touch
network solution for short-lived certificates that can be renewed or
re-enrolled even after unintential expiry (eg: because of interrupted
connectivity). See Section 10.1.
13. IANA Considerations 13. IANA Considerations
This document defines the "Autonomic Control Plane".
The IANA is requested to create an ACP Parameter Registry with
currently one registry table - the "ACP Address Type" table.
"ACP Address Type" Table. The value in this table are numeric values
0...3 paired with a name (string). Future values values MUST be
assigned using the Standards Action policy defined by [RFC8126]. The
following initial values are assigned by this document:
0: ACP Zone Addressing Sub-Scheme (ACP RFC Figure 4) / ACP Manual
Addressing Sub-Scheme (ACP RFC Section 6.10.4)
1: ACP Vlong Addressing Sub-Scheme (ACP RFC Section 6.10.5)
14. 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, Michael BL, Alex Clemm, Yves Hertoghs, Bruno Klauser, Max Pritikin, Michael
Richardson, Ravi Kumar Vadapalli. Richardson, Ravi Kumar Vadapalli.
Special thanks to Pascal Thubert and Michael Richardson to provide Special thanks to Pascal Thubert and Michael Richardson to provide
skipping to change at page 75, line 42 skipping to change at page 79, line 42
V8 addressing Sub-Scheme was modified to allow not only /8 device- V8 addressing Sub-Scheme was modified to allow not only /8 device-
local address space but also /16. This was in response to the 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 possible need to have maybe as much as 2^12 local addresses for
future encaps in BRSKI like IPinIP. It also would allow fully future encaps in BRSKI like IPinIP. It also would allow fully
autonomic address assignment for ACP connect interfaces from this autonomic address assignment for ACP connect interfaces from this
local address space (on an ACP edge device), subject to approval of local address space (on an ACP edge device), subject to approval of
the implied update to rfc4291/rfc4193 (IID length). Changed name to the implied update to rfc4291/rfc4193 (IID length). Changed name to
Vlong addressing sub-scheme. Vlong addressing sub-scheme.
Added text in response to Brian Carpenters review of draft-ietf- Added text in response to Brian Carpenters review of draft-ietf-
anima-stable-connectivity-04. The stable connectivity draft was anima-stable-connectivity-04.
vaguely describing ACP connect behavior that is better standardized
in this ACP draft. o 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 o Added new ACP "Manual" addressing sub-scheme with /64 subnets for
use with ACP connect interfaces. Being covered by the ACP ULA use with ACP connect interfaces. Being covered by the ACP ULA
prefix, these subnets do not require additional routing entries prefix, these subnets do not require additional routing entries
for NMS hosts. They also are fully 64-bit IID length compliant for NMS hosts. They also are fully 64-bit IID length compliant
and therefore not subject to 4191bis considerations. And they and therefore not subject to 4191bis considerations. And they
avoid that operators manually assign prefixes from the ACP ULA avoid that operators manually assign prefixes from the ACP ULA
prefixes that might later be assigned autonomiously. prefixes that might later be assigned autonomiously.
o ACP connect auto-configuration: Defined that ACP edge devices, NMS o ACP connect auto-configuration: Defined that ACP edge devices, NMS
skipping to change at page 77, line 26 skipping to change at page 81, line 26
Added fixes from 08-mcr-review-reply.txt (on github): Added fixes from 08-mcr-review-reply.txt (on github):
o AN Domain Names are FQDNs. o AN Domain Names are FQDNs.
o Fixed bit length of schemes, numerical writing of bits (00b/01b). o Fixed bit length of schemes, numerical writing of bits (00b/01b).
o Lets use US american english. o Lets use US american english.
15.16. draft-ietf-anima-autonomic-control-plane-10 15.16. draft-ietf-anima-autonomic-control-plane-10
Used the term routing subdomain more consistently where previously
only subdomain was used. Clarified use of routing subdomain in
creation of ULA "global ID" addressing prefix.
6.7.1.* Changed native IPsec encapsulation to tunnel mode 6.7.1.* Changed native IPsec encapsulation to tunnel mode
(necessary), explaned why. Added notion that ESP is used, added (necessary), explaned why. Added notion that ESP is used, added
explanations why tunnel/transport mode in native vs. GRE cases. explanations why tunnel/transport mode in native vs. GRE cases.
6.10.3/6.10.5 Added term "ACP address range/set" to be able to better 6.10.3/6.10.5 Added term "ACP address range/set" to be able to better
explain how the address in the ACP certificate is actually the base explain how the address in the ACP certificate is actually the base
address (lowest address) of a range/set that is available to the address (lowest address) of a range/set that is available to the
device. device.
6.10.4 Added note that manual address sub-scheme addresses must not 6.10.4 Added note that manual address sub-scheme addresses must not
skipping to change at page 77, line 50 skipping to change at page 82, line 5
built a multi-access interface on top of a full mesh of p2p built a multi-access interface on top of a full mesh of p2p
connections (6man WG, anima WG mailing lists), but could not find any connections (6man WG, anima WG mailing lists), but could not find any
prior work that had a succinct explanation. So wrote up an prior work that had a succinct explanation. So wrote up an
explanation here. Added hopefully all necessary and sufficient explanation here. Added hopefully all necessary and sufficient
details how to map ACP unicast packets to ACP secure channel, how to details how to map ACP unicast packets to ACP secure channel, how to
deal with ND packet details. Added verbage for ACP not to assign the deal with ND packet details. Added verbage for ACP not to assign the
virtual interface link-local address from the underlying interface. virtual interface link-local address from the underlying interface.
Addd note that GRAP link-local messages are treated specially but Addd note that GRAP link-local messages are treated specially but
logically the same. Added paragraph about NBMA interfaces. logically the same. Added paragraph about NBMA interfaces.
From Brian Carpenters review: remaining changes from Brian Carpenters review. See Github file
draft-ietf-anima-autonomic-control-plane/08-carpenter-review-reply.tx
for more detailst:
Added multiple new RFC references for terms/technologies used. Added multiple new RFC references for terms/technologies used.
Fixed verbage in several places. Fixed verbage in several places.
2. (terminology) Added 802.1AR as reference. 2. (terminology) Added 802.1AR as reference.
2. Fixed up definition of ULA. 2. Fixed up definition of ULA.
6.1.1 Changed definition of ACP information in cert into ABNF format. 6.1.1 Changed definition of ACP information in cert into ABNF format.
skipping to change at page 78, line 25 skipping to change at page 82, line 31
6.2 Mentioned API requirement between ACP and clients leveraging 6.2 Mentioned API requirement between ACP and clients leveraging
adjacency table. adjacency table.
6.3 Fixed TTL in GRASP example: msec, not hop-count!. 6.3 Fixed TTL in GRASP example: msec, not hop-count!.
6.8.2 MAYOR: expanded security/transport substrate text: 6.8.2 MAYOR: expanded security/transport substrate text:
Introduced term ACP GRASP virtual interface to explain how GRASP Introduced term ACP GRASP virtual interface to explain how GRASP
link-local multicast messages are encapsulated and replicated to link-local multicast messages are encapsulated and replicated to
neighbors. Explain how ACP knows when to use TLS vs. TCP (TCP only neighbors. Explain how ACP knows when to use TLS vs. TCP (TCP only
for link-local address (sockets). for link-local address (sockets). Introduced "ladder" picture to
visualize stack.
6.8.2.1 Expanded discussion/explanation of security model. TLS for 6.8.2.1 Expanded discussion/explanation of security model. TLS for
GRASP unicsast connections across ACP is double encryption (plus GRASP unicsast connections across ACP is double encryption (plus
underlying ACP secure channel), but highly necessary to avoid very underlying ACP secure channel), but highly necessary to avoid very
simple man-in-the-middle attacks by compromised ACP members on-path. simple man-in-the-middle attacks by compromised ACP members on-path.
Ultimately, this is done to ensure that any apps using GRASP can get Ultimately, this is done to ensure that any apps using GRASP can get
full end-to-end secrecy for information sent across GRASP. But for full end-to-end secrecy for information sent across GRASP. But for
publically known ASA services, even this will not provide 100% publically known ASA services, even this will not provide 100%
security (this is discussed). Also why double encryption is the security (this is discussed). Also why double encryption is the
better/easier solution than trying to optimize this. better/easier solution than trying to optimize this.
6.10.1 Added discussion about pseudo-random addressing, scanning-
attaacks (not an issue for ACP).
6.12.2 New performance requirements section added. 6.12.2 New performance requirements section added.
6.10.1 Added notion to first experiment with existing addressing
schemes before defining new ones - we should be flexible enough.
6.3/7.2 clarified the interactions between MLD and DULL GRASP and
specified what needs to be done (eg: in 2 switches doing ACP per L2
port).
12. Added explanations and cross-references to various security
aspects of ACP discussed elsewhere in the document.
13. Added IANA requirements.
Added RFC2119 boilerplate.
15.17. draft-ietf-anima-autonomic-control-plane-11
Same text as -10 Unfortunately when uploading -10 .xml/.txt to
datatracker, a wrong version of .txt got uploaded, only the .xml was
correct. This impacts the -10 html version on datatracker and the
PDF versions as well. Because rfcdiff also compares the .txt
version, this -11 version was created so that one can compare changes
from -09 and changes to the next version (-12).
16. References 16. References
16.1. Normative 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.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004,
<https://www.rfc-editor.org/info/rfc3810>.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
November 2005, <https://www.rfc-editor.org/info/rfc4191>. November 2005, <https://www.rfc-editor.org/info/rfc4191>.
[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,
<https://www.rfc-editor.org/info/rfc4193>. <https://www.rfc-editor.org/info/rfc4193>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
skipping to change at page 80, line 42 skipping to change at page 85, line 37
[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-05 (work in progress), August anima-stable-connectivity-06 (work in progress), September
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-17 (work in progress), draft-ietf-netconf-zerotouch-17 (work in progress),
September 2017. September 2017.
[I-D.ietf-roll-useofrplinfo] [I-D.ietf-roll-useofrplinfo]
Robles, I., Richardson, M., and P. Thubert, "When to use Robles, I., Richardson, M., and P. Thubert, "When to use
RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll- RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll-
useofrplinfo-16 (work in progress), July 2017. useofrplinfo-16 (work in progress), July 2017.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, DOI 10.17487/RFC1112, August 1989,
<https://www.rfc-editor.org/info/rfc1112>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets", and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<https://www.rfc-editor.org/info/rfc1918>. <https://www.rfc-editor.org/info/rfc1918>.
[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,
<https://www.rfc-editor.org/info/rfc2315>. <https://www.rfc-editor.org/info/rfc2315>.
[RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", [RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol",
RFC 2821, DOI 10.17487/RFC2821, April 2001, RFC 2821, DOI 10.17487/RFC2821, April 2001,
<https://www.rfc-editor.org/info/rfc2821>. <https://www.rfc-editor.org/info/rfc2821>.
[RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006,
<https://www.rfc-editor.org/info/rfc4541>.
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Protocol Version 2 (MLDv2) for Source-
Specific Multicast", RFC 4604, DOI 10.17487/RFC4604,
August 2006, <https://www.rfc-editor.org/info/rfc4604>.
[RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol
Independent Multicast (PIM)", RFC 4610,
DOI 10.17487/RFC4610, August 2006,
<https://www.rfc-editor.org/info/rfc4610>.
[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,
<https://www.rfc-editor.org/info/rfc4941>. <https://www.rfc-editor.org/info/rfc4941>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008, DOI 10.17487/RFC5321, October 2008,
<https://www.rfc-editor.org/info/rfc5321>. <https://www.rfc-editor.org/info/rfc5321>.
[RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790,
DOI 10.17487/RFC5790, February 2010,
<https://www.rfc-editor.org/info/rfc5790>.
[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,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
Power and Lossy Networks (RPL) Option for Carrying RPL Power and Lossy Networks (RPL) Option for Carrying RPL
Information in Data-Plane Datagrams", RFC 6553, Information in Data-Plane Datagrams", RFC 6553,
DOI 10.17487/RFC6553, March 2012, DOI 10.17487/RFC6553, March 2012,
<https://www.rfc-editor.org/info/rfc6553>. <https://www.rfc-editor.org/info/rfc6553>.
skipping to change at page 82, line 29 skipping to change at page 88, line 5
Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
Networking: Definitions and Design Goals", RFC 7575, Networking: Definitions and Design Goals", RFC 7575,
DOI 10.17487/RFC7575, June 2015, DOI 10.17487/RFC7575, June 2015,
<https://www.rfc-editor.org/info/rfc7575>. <https://www.rfc-editor.org/info/rfc7575>.
[RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap
Analysis for Autonomic Networking", RFC 7576, Analysis for Autonomic Networking", RFC 7576,
DOI 10.17487/RFC7576, June 2015, DOI 10.17487/RFC7576, June 2015,
<https://www.rfc-editor.org/info/rfc7576>. <https://www.rfc-editor.org/info/rfc7576>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016,
<https://www.rfc-editor.org/info/rfc7721>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
Authors' Addresses Authors' Addresses
Michael H. Behringer (editor) Michael H. Behringer (editor)
Email: michael.h.behringer@gmail.com Email: michael.h.behringer@gmail.com
Toerless Eckert (editor) Toerless Eckert (editor)
Futurewei Technologies Inc. Futurewei Technologies Inc.
2330 Central Expy 2330 Central Expy
Santa Clara 95050 Santa Clara 95050
 End of changes. 67 change blocks. 
195 lines changed or deleted 474 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/