idnits 2.17.1 draft-richardson-anima-l2-friendly-acp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (15 June 2021) is 1039 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 anima Working Group M. Richardson 3 Internet-Draft Sandelman Software Works 4 Intended status: Standards Track W. Pan 5 Expires: 17 December 2021 Huawei Technologies 6 15 June 2021 8 Autonomic Control Plane design for Layer-Two Switched Networks 9 draft-richardson-anima-l2-friendly-acp-02 11 Abstract 13 This document proposes a design for an L2 aware Autonomic Control 14 Plane that can be deployed easily to layer-two (Ethernet) switched 15 technologies that are common on Campus/Enterprise network 16 architectures. 18 This document leverages the hop-by-hop announcement used in LLDP, but 19 runs bulk data over normal IPv6 Link-Local unicast ethernet frames. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 17 December 2021. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Onbording process . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Other constraints . . . . . . . . . . . . . . . . . . . . . . 4 59 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 4 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 62 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 63 9. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 10.1. Normative References . . . . . . . . . . . . . . . . . . 5 66 10.2. Informative References . . . . . . . . . . . . . . . . . 5 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 69 1. Introduction 71 The creation and maintenance of the Autonomic Control Plane described 72 in [RFC8994] requires creation of hop-by-hop discovery of adjacent 73 systems. There are Campus L2 systems that are not broadcast safe 74 until they have been connected to their Software Defined Networking 75 (SDN) controller. The use of the stable connectivity provided by 76 [RFC8368] can provide the SDN connectivity required. 78 There is a bootstrap interlocking problem: the network may be unsafe 79 for ACP discovery broadcasts without the support of Spanning Tree 80 Protocol (STP) or similar mechanisms until configured, yet it can not 81 be automatically configured until the ACP discovery (and onboarding 82 process) is done. Meantime, because of STP complicated topological 83 calculations, the convergence can be very slow for larger networks. 84 This can delay on-boarding. 86 In addition, forming a campus-wide network by default and using 87 enabling STP does not work. STP is not secure and could be easily 88 spoofed by malicious or untrusted devices. On manually configured 89 networks today, STP is turned off on "access" ports, and enabled only 90 for trunk ports. But in an autonomic network, it is not possible to 91 know a-priori which ports will be trunk ports. 93 What is needed is a way to send IPv6 traffic between these L2 94 switching devices in a way that is never forwarded, regardless of how 95 the network is eventually configured. This is not just an inital 96 configuration problem: devices may be added and removed at any time, 97 due to needed expansion of capacity, planned upgrades, or devices 98 failures. 100 This document proposes using LLDP for what it is good at: announcing 101 capabilities, while using normal EtherType 0x86DD IPv6 frames for the 102 normal ACP transport. 104 1.1. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 108 "OPTIONAL" in this document are to be interpreted as described in 109 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 110 capitals, as shown here. 112 2. Protocol 114 A new TLV for LLDP is allocated and called the GRASP-DULL. The 115 contents of the new TLV are the payload of the normal [RFC8994] GRASP 116 DULL M_FLOOD, AN_ACP message. 118 The LLDP subsystem in the control plane CPU needs to forward these 119 messages along to the ACP GRASP daemon, and it needs to also include 120 the source MAC address (and port number) from which the LLDP message 121 was received. 123 The ACP GRASP daemon can see the origin IPv6 Link-Local address from 124 the GRASP DULL packet, and can now create an IPv6 neighbour cache 125 entry (NCE) for that combination. By forcing this NCE entry, the 126 node avoids the need to do an unsafe multicast IPv6 Neighbor 127 Discovery. 129 The node SHOULD unicast a Neighbor Advertisement to the corresponding 130 node to establish that node's NCE. 132 At this point it is possible to initiate the right key management 133 daemon (IKEv2, etc.) using unicast IPv6 datagrams that only need 134 unicast Ethernet packets. 136 3. Onbording process 138 In addition to normal operation, devices need to be onboarding. 139 [RFC8995] section 4.1.1 defines the AN_PROXY message to be used for a 140 new pledge to discover which neighbors are willing to act as 141 onboarding proxies. 143 This M_FLOOD message will fit into the same GRASP DULL M_FLOOD 144 message that contains the AN_ACP message. 146 After discover of an eligible neighbour, onboarding proceeds with a 147 TCP connection over IPv6 link-local addresses, using unicast Ethernet 148 frames. 150 A pledge that is in an L2 network that is broadcast unsafe MUST NOT 151 do mDNS queries as described in [RFC8995] appendix B. 153 4. Other constraints 155 On broadcast unsafe L2 networks, IPv6 Duplicate Address Detection 156 (DAD) MUST be turned off. Only auto-configured IPv6 link-local 157 addresses using SLAAC or stable-IID [RFC7217] may be used. 159 5. Privacy Considerations 161 The LLDP messages commonly contain information that uniquely 162 identifies a specific piece of switching equipment. The addition of 163 the GRASP DULL message will also now reveal the link-local IPv6 164 addresses of the device. This additional information is either 165 derived from ethernet addresses (so no new information), or will be 166 derived using [RFC7217]. 168 6. Security Considerations 170 Unclear as yet. 172 7. IANA Considerations 174 IANA is asked to allocate a TLV from the "IANA Link Layer Discovery 175 Protocol (LLDP) TLV Subtypes" https://www.iana.org/assignments/ieee- 176 802-numbers/ieee-802-numbers.xhtml#iana-lldp-tlv-subtypes 178 for the GRASP DULL L2 announcement. 180 8. Acknowledgements 182 Paul Congdon was very helpful in understanding how LLDP was actually 183 processed in production equipment. 185 9. Changelog 187 1. A specific LLDP method for announcement using normal IPv6 188 datagrams described. 190 2. Document renamed, focus changed. 192 10. References 194 10.1. Normative References 196 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 197 Requirement Levels", BCP 14, RFC 2119, 198 DOI 10.17487/RFC2119, March 1997, 199 . 201 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 202 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 203 May 2017, . 205 [RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An 206 Autonomic Control Plane (ACP)", RFC 8994, 207 DOI 10.17487/RFC8994, May 2021, 208 . 210 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 211 and K. Watsen, "Bootstrapping Remote Secure Key 212 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, 213 May 2021, . 215 10.2. Informative References 217 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 218 Interface Identifiers with IPv6 Stateless Address 219 Autoconfiguration (SLAAC)", RFC 7217, 220 DOI 10.17487/RFC7217, April 2014, 221 . 223 [RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic 224 Control Plane for Stable Connectivity of Network 225 Operations, Administration, and Maintenance (OAM)", 226 RFC 8368, DOI 10.17487/RFC8368, May 2018, 227 . 229 Authors' Addresses 231 Michael Richardson 232 Sandelman Software Works 234 Email: mcr+ietf@sandelman.ca 236 Wei Pan 237 Huawei Technologies 239 Email: william.panwei@huawei.com