Skip to main content

IPv6 over Link-Local Discovery Protocol
draft-richardson-anima-ipv6-lldp-03

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Michael Richardson , Liang Xia
Last updated 2020-03-09 (Latest revision 2019-12-18)
Replaced by draft-richardson-anima-l2-friendly-acp, draft-richardson-anima-l2-friendly-acp
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-richardson-anima-ipv6-lldp-03
anima Working Group                                        M. Richardson
Internet-Draft                                  Sandelman Software Works
Intended status: Standards Track                                  L. Xia
Expires: 10 September 2020                                        Huawei
                                                            9 March 2020

                IPv6 over Link-Local Discovery Protocol
                  draft-richardson-anima-ipv6-lldp-03

Abstract

   This document describes a mechanism to encapsulate IPv6 packets over
   the Link Layer Discovery Protocol (LLDP).  The LLDP is a single
   layer-two protocol with its own ethertype.  It 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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 10 September 2020.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/

Richardson & Xia        Expires 10 September 2020               [Page 1]
Internet-Draft                   v6-LLDP                      March 2020

   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Protocol  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  LLDP Encapsulation  . . . . . . . . . . . . . . . . . . .   3
     2.2.  Content of Payload - option 1 - entire IPv6 packet  . . .   4
     2.3.  Content of Payload - option 2 - elided IPv6 packet  . . .   5
     2.4.  Content of Payload - option 3 - RFC8138 compressed
           packet  . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   7.  Changelog . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   The IEEE802.1AB Link Layer Discovery Protocol (LLDP) is a one-hop,
   vendor-neutral link-layer protocol used by network devices or Things
   for advertising their identity, capabilities, and neighbors on an
   IEEE 802 local area network.

   The LLDP uses its own ethertype (0x88cc), and so is distinct from
   production IPv4 or IPv6 traffic that might appear on a network.
   Switching equipment is usually configured such that it does not
   forward LLDP packets.

   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
   [RFC7042].

   The creation and maintenance of the Autonomic Control Plane described
   in [I-D.ietf-anima-autonomic-control-plane] 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

Richardson & Xia        Expires 10 September 2020               [Page 2]
Internet-Draft                   v6-LLDP                      March 2020

   Software Defined Networking (SDN) controller.  The use of the stable
   connectivity provided by [RFC8368] 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.

   LLDP provides a way for the above problem, 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.

   Additionally, 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
   they were received on.  This is exactly the desired data flow for the
   [I-D.ietf-anima-autonomic-control-plane]: all traffic goes to the
   control plane processor.

   This document provides a way to transmit the IPv6 Link-Layer packets
   that are needed for formation of the
   [I-D.ietf-anima-autonomic-control-plane] over the LLDP.  Those
   packets types include: IPv6 Neighbor Discovery, GRASP DULL over IPv6
   Link-Local, IPsec ESP and IKEv2 packets.

1.1.  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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Protocol

2.1.  LLDP Encapsulation

   The LLDP vendor-specific frame has the following format:

      +--------+--------+----------+---------+--------------
      |TLV Type|  len   |   OUI    |subtype  | IPv6 fragment
      |  =127  |        |= 00 00 5E|  = TBD  |
      |(7 bits)|(9 bits)|(3 octets)|(1 octet)|(0-507 octets)
      +--------+--------+----------+---------+--------------

   where:

Richardson & Xia        Expires 10 September 2020               [Page 3]
Internet-Draft                   v6-LLDP                      March 2020

   *  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 507 octets of packet.

   The vendor-specific frame has a limit of 507 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 three subtype TLV values.  The first 507 octets go into the
       first TLV, the second 507 octets go into the second TLV, etc.
       three TLVs of 507 octets payload each results in a maximum
       payload size of 1521, which exceeds the ethernet payload size of
       1500 bytes.  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 subtype TLV value, repeated three 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 three 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.

2.2.  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 adjacent devices.

Richardson & Xia        Expires 10 September 2020               [Page 4]
Internet-Draft                   v6-LLDP                      March 2020

2.3.  Content of Payload - option 2 - elided IPv6 packet

   The [I-D.ietf-anima-autonomic-control-plane] 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 [I-D.ietf-anima-autonomic-control-plane] a mesh of
   IPsec tunnels is created on top of ESP packets over IPv6 Link-Local,
   and within that tunnel all of IPv6 packets can be sent.

   The use of hard coding of so many values significantly limits the
   attack surface possible.

2.4.  Content of Payload - option 3 - RFC8138 compressed packet

   An option similar to above, yet providing a bit more flexibility is
   to use [RFC8138] 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 providing 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.

3.  Privacy Considerations

   YYY

4.  Security Considerations

   LLDP is relatively simple and does not provide any protections to the
   traffic over it.  The IPv6 packets over the LLDP SHOULD be protected
   by all the existing best current practices.

   The device control plane processor will be subject to the Deny of
   Service (DoS) attack if excessive IPv6 packets over LLDP frames are

Richardson & Xia        Expires 10 September 2020               [Page 5]
Internet-Draft                   v6-LLDP                      March 2020

   send up.  Certain protecting mechanisms like rate limit and filtering
   can be considered.

5.  IANA Considerations

6.  Acknowledgements

   Hello.

7.  Changelog

8.  References

8.1.  Normative References

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC7042]  Eastlake 3rd, D. and J. Abley, "IANA Considerations and
              IETF Protocol and Documentation Usage for IEEE 802
              Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042,
              October 2013, <https://www.rfc-editor.org/info/rfc7042>.

   [I-D.ietf-anima-autonomic-control-plane]
              Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic
              Control Plane (ACP)", Work in Progress, Internet-Draft,
              draft-ietf-anima-autonomic-control-plane-22, 3 February
              2020, <http://www.ietf.org/internet-drafts/draft-ietf-
              anima-autonomic-control-plane-22.txt>.

   [RFC8138]  Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
              "IPv6 over Low-Power Wireless Personal Area Network
              (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
              April 2017, <https://www.rfc-editor.org/info/rfc8138>.

   [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>.

8.2.  Informative References

   [RFC8368]  Eckert, T., Ed. and M. Behringer, "Using an Autonomic
              Control Plane for Stable Connectivity of Network
              Operations, Administration, and Maintenance (OAM)",
              RFC 8368, DOI 10.17487/RFC8368, May 2018,
              <https://www.rfc-editor.org/info/rfc8368>.

Richardson & Xia        Expires 10 September 2020               [Page 6]
Internet-Draft                   v6-LLDP                      March 2020

Authors' Addresses

   Michael Richardson
   Sandelman Software Works

   Email: mcr+ietf@sandelman.ca

   Liang Xia (Frank)
   Huawei

   Email: frank.xialiang@huawei.com

Richardson & Xia        Expires 10 September 2020               [Page 7]