]> Sandelman Software Works

mcr+ietf@sandelman.ca

Huawei Technologies

william.panwei@huawei.com

Internet anima Working Group Internet-Draft This document proposes a design for an L2 aware Autonomic Control Plane that can be deployed easily to layer-two (Ethernet) switched technologies that are common on Campus/Enterprise network architectures. This document leverages the hop-by-hop announcement used in LLDP, but runs bulk data over normal IPv6 Link-Local unicast ethernet frames.

Introduction The creation and maintenance of the Autonomic Control Plane described in requires creation of hop-by-hop discovery of adjacent systems. There are Campus L2 systems that are not broadcast safe until they have been connected to their Software Defined Networking (SDN) controller. The use of the stable connectivity provided by can provide the SDN connectivity required. There is a bootstrap interlocking problem: the network may be unsafe for ACP discovery broadcasts without the support of Spanning Tree Protocol (STP) or similar mechanisms until configured, yet it can not be automatically configured until the ACP discovery (and onboarding process) is done. Meantime, because of STP complicated topological calculations, the convergence can be very slow for larger networks. This can delay on-boarding. In addition, forming a campus-wide network by default and using enabling STP does not work. STP is not secure and could be easily spoofed by malicious or untrusted devices. On manually configured networks today, STP is turned off on "access" ports, and enabled only for trunk ports. But in an autonomic network, it is not possible to know a-priori which ports will be trunk ports, so STP would have to be on by default if it is was to be used. What is needed is a way to send IPv6 traffic between these L2 switching devices in a way that is never forwarded, regardless of how the network is eventually configured. This is not just an inital configuration problem: devices may be added and removed at any time, due to needed expansion of capacity, planned upgrades, or devices failures. This document proposes using LLDP for what it is good at: announcing capabilities, while using normal EtherType 0x86DD IPv6 frames for the normal ACP transport.

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 BCP 14 when, and only when, they appear in all capitals, as shown here.

Protocol A new TLV for LLDP is allocated and called the GRASP-DULL. The contents of the new TLV are the payload of the normal GRASP DULL M_FLOOD, AN_ACP message. The LLDP subsystem in the control plane CPU needs to forward these messages along to the ACP GRASP daemon, and it needs to also include the source MAC address (and port number) from which the LLDP message was received. The ACP GRASP daemon can see the origin IPv6 Link-Local address from the GRASP DULL packet, and can now create an IPv6 neighbour cache entry (NCE) for that combination. By forcing this NCE entry, the node avoids the need to do an unsafe multicast IPv6 Neighbor Discovery. The node SHOULD unicast a Neighbor Advertisement to the corresponding node to establish that node's NCE. At this point it is possible to initiate the right key management daemon (IKEv2, etc.) using unicast IPv6 datagrams that only need unicast Ethernet packets. It is likely that many L2 switching fabrics may not support IPsec ESP, or L3 routing. It was always the case that the ACP might have to be implemented as a software fabric in a control plane CPU. This is not a significant hurdle, as the ACP is not intended to be used for customer data, only control plane communication, and often only as a last resort. In addition to normal operation, devices may need to be onboarded. section 4.1.1 defines the AN_PROXY message to be used for a new pledge to discover which neighbors are willing to act as onboarding proxies. This M_FLOOD message will fit into the same GRASP DULL M_FLOOD message that contains the AN_ACP message. After discover of an eligible neighbour, onboarding proceeds with a TCP connection over IPv6 link-local addresses, using unicast Ethernet frames. LLDP traffic also uses a destination multicast address: 01:80:c2:00:00:0e, 01:80:c2:00:00:03, or 01:80:c2:00:00:00. The use of this destination address facilitiates transmission of the traffic through unmanaged switches ("dumb ethernet switches"), as well as allowing for seperation of provider and customer traffic in provider bridged (IEEE 802.1ad) situations.

Other constraints On broadcast unsafe L2 networks, IPv6 Duplicate Address Detection (DAD) MUST be turned off. Only auto-configured IPv6 link-local addresses using SLAAC or stable-IID may be used. A pledge that is in an L2 network that is broadcast unsafe MUST NOT do mDNS queries as described in appendix B.

Privacy Considerations The LLDP messages commonly contain information that uniquely identifies a specific piece of switching equipment. The addition of the GRASP DULL message will also now reveal the link-local IPv6 addresses of the device. This additional information is either derived from ethernet addresses (so no new information), or will be derived using .

Security Considerations Unclear as yet.

IANA Considerations IANA is asked to allocate a TLV from the "IANA Link Layer Discovery Protocol (LLDP) TLV Subtypes" https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml#iana-lldp-tlv-subtypes for the GRASP DULL L2 announcement.

Acknowledgements Paul Congdon was very helpful in understanding how LLDP was actually processed in production equipment.

Changelog

1. A specific LLDP method for announcement using normal IPv6 datagrams described.
2. Document renamed, focus changed.

References Normative References Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Control Plane should ideally be self-managing and be as independent as possible of configuration. This document defines such a plane and calls it the "Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out-of-band channel" for Operations, Administration, and Management (OAM) communications over a network that provides automatically configured, hop-by-hop authenticated and encrypted communications via automatically configured IPv6 even when the network is not configured or is misconfigured. This document specifies automated bootstrapping of an Autonomic Control Plane. To do this, a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur when using a routable address and a cloud service, only link-local connectivity, or limited/disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Operations, Administration, and Maintenance (OAM), as per BCP 161, for data networks is often subject to the problem of circular dependencies when relying on connectivity provided by the network to be managed for the OAM purposes. Provisioning while bringing up devices and networks tends to be more difficult to automate than service provisioning later on. Changes in core network functions impacting reachability cannot be automated because of ongoing connectivity requirements for the OAM equipment itself, and widely used OAM protocols are not secure enough to be carried across the network without security concerns. This document describes how to integrate OAM processes with an autonomic control plane in order to provide stable and secure connectivity for those OAM processes. This connectivity is not subject to the aforementioned circular dependencies. This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that an IPv6 address configured using this method is stable within each subnet, but the corresponding Interface Identifier changes when the host moves from one network to another. This method is meant to be an alternative to generating Interface Identifiers based on hardware addresses (e.g., IEEE LAN Media Access Control (MAC) addresses), such that the benefits of stable addresses can be achieved without sacrificing the security and privacy of users. The method specified in this document applies to all prefixes a host may be employing, including link-local, global, and unique-local prefixes (and their corresponding addresses).