]> IPv6 over Link-Local Discovery Protocol Sandelman Software Works
mcr+ietf@sandelman.ca
Internet anima Working Group Internet-Draft This document describes a mechanism to encapsulate IPv6 packets over the Link-Local Discovery Protocol (LLDP). The LLDP is a single layer-two protocol and is never forwarded, which is a desireable property when building the IPv6-over-IPsec-over-IPv6-Link-Local tunnels that make up the ANIMA Autonomic Control Plane (ACP). This unorthodox encapsulation avoids unwanted interactions between the ACP packets and native packet forwarding engines, as well as being safe for layer-2 switches which might otherwise have no IPv6 capabilities.
Introduction The IEEE802.1AB Link Layer Discovery Protocol (LLDP) is a one-hop, vendor-neutral link-layer protocol used by end host network Things for advertising their identity, capabilities, and neighbors on an IEEE 802 local area network. Its Type-Length-Value (TLV) design allows for "vendor-specific" extensions to be defined. IANA has a registered IEEE 802 organizationally unique identifier (OUI) defined as documented in . 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 problem: the network may be unsafe for ACP discovery broadcasts until configured, and it can not be autonomically configured until the ACP discovery (and onboarding process) is done. LLDP provides an out, as it is never forwarded to other ports, and it discovers all compliant layer-2 devices in a network, even if they do not normally do layer-3 forwarding. Additional LLDP has the advantage that received LLDP frames are already configured in routing fabrics to be send up to the control plane processor, with information identifying which physical port it was received on. This is exactly the desired data flow for the : all traffic goes to the control processor. This document provides a way to transmit the IPv6 Link-Layer packets that are needed for formation of the . Those packets types include: IPv6 Neighbor Discovery, GRASP DULL over IPv6 Link-Local, IPsec ESP and IKEv2 packets.
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
LLDP Encapsulation The LLDP vendor-specific frame has the following format: where:
  • TLV Type = 127 indicates a vendor-specific TLV
  • len = indicates the TLV string length
  • OUI = 00 00 5E is the organizationally unique identifier of IANA
  • subtype = TBD (as assigned by IANA for this document)
  • IPv6 fragment, up to 255 octets of packet.
The vendor-specific frame has a limit of 255 octets, while IPv6 has a minimum MTU of 1280 bytes. An LLDP frame can contain more than one TLV, and ethernet accomodates up to 1500 bytes (often larger), so it should all fit. Two possible solutions are discussed here:
  1. use six subtype TLV values. The first for 255 octets go into the first TLV, the second 255 octets go into the second TLV, etc. Six options of 255 bytes each results in a maximum payload size of 1530, which exceeds the ethernet payload size. Given the overhead of 6 bytes per TLV, this results in an MTU of 1464 bytes within the 1500 byte ethernet payload space.
  2. use the same TLV value, repeated six times.
The second method seems more obvious but it is unclear if all LLDP subsystems would permit TLVs to be repeated, or if they would keep the TLVs in the correct order. While the IANA has only 253 available TLVs, and perhaps a request for 6 values might seem excessive, if this resource was depleted, a new OUI could be used. An OUI specific to this effort could be allocated, or a vendor OUI could be used during prototyping.
Content of Payload - option 1 - entire IPv6 packet The simplest encapsulation would put the entire IPv6 packet, including the IPv6 header in. This takes a bit more space, but provides the maximum flexibility. This flexibility may come at a cost of creating a new attack surface for devices. Any L2 connected device may not inject IPv6 frames into the control plane of the adjacenty router.
Content of Payload - option 2 - elided IPv6 packet The use case only sends IPv6 Link-Local packets. The IPv6 source and destination address are always directly related to the L2 Ethernet headers, with the use of SLAAC derived IIDs, and the prefix "fe80". This proposal is to include only the fields: 1. Payload Length 2. Next Header The Hop Limit is always 1 for Link-Local packets. The Flow Label is always 0. Note that in the a mesh of IPsec tunnels is created on top of ESP packets over IPv6 Link-Local, and within that tunnel all of IPv6 can be sent. The use hard coding of so many values significantly limits the attack surface possible.
Content of Payload - option 3 - RFC8138 compressed packet An option similar to above, yet providing a bit more flexibility is to use compression of packets as it done on low powered 802.15.4 networks. This results in compression that is close to what option 2 provides, yet provides for a lot of flexibility. This option requires more code, may be subject to new attacks on the decompression code, and expands the attack surface to all of IPv6, as well as the RFC8138 compression code.
Privacy Considerations YYY
Security Considerations ZZZ
IANA Considerations
Acknowledgements Hello.
Changelog
References Normative References Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words 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. IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses several uses of such parameters in IETF protocols, specifies IANA considerations for assignment of points under the IANA OUI (Organizationally Unique Identifier), and provides some values for use in documentation. This document obsoletes RFC 5342. An Autonomic Control Plane (ACP) Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Management and Control Plane should ideally be self-managing, and 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 misconfigured. IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header This specification introduces a new IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) dispatch type for use in 6LoWPAN route-over topologies, which initially covers the needs of Routing Protocol for Low-Power and Lossy Networks (RPL) data packet compression (RFC 6550). Using this dispatch type, this specification defines a method to compress the RPL Option (RFC 6553) information and Routing Header type 3 (RFC 6554), an efficient IP-in-IP technique, and is extensible for more applications. Key words for use in RFCs to Indicate Requirement Levels 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. Informative References Using an Autonomic Control Plane for Stable Connectivity of Network Operations, Administration, and Maintenance (OAM) 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.