idnits 2.17.1 draft-richardson-anima-ipv6-lldp-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (18 December 2019) is 1588 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) ** Obsolete normative reference: RFC 7042 (Obsoleted by RFC 9542) == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-21 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 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 18 December 2019 5 Expires: 20 June 2020 7 IPv6 over Link-Local Discovery Protocol 8 draft-richardson-anima-ipv6-lldp-02 10 Abstract 12 This document describes a mechanism to encapsulate IPv6 packets over 13 the Link-Local Discovery Protocol (LLDP). The LLDP is a single 14 layer-two protocol and is never forwarded, which is a desireable 15 property when building the IPv6-over-IPsec-over-IPv6-Link-Local 16 tunnels that make up the ANIMA Autonomic Control Plane (ACP). 18 This unorthodox encapsulation avoids unwanted interactions between 19 the ACP packets and native packet forwarding engines, as well as 20 being safe for layer-2 switches which might otherwise have no IPv6 21 capabilities. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 20 June 2020. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. LLDP Encapsulation . . . . . . . . . . . . . . . . . . . 3 60 2.2. Content of Payload - option 1 - entire IPv6 packet . . . 4 61 2.3. Content of Payload - option 2 - elided IPv6 packet . . . 4 62 2.4. Content of Payload - option 3 - RFC8138 compressed 63 packet . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 67 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 68 7. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 71 8.2. Informative References . . . . . . . . . . . . . . . . . 6 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 74 1. Introduction 76 The IEEE802.1AB Link Layer Discovery Protocol (LLDP) is a one-hop, 77 vendor-neutral link-layer protocol used by end host network Things 78 for advertising their identity, capabilities, and neighbors on an 79 IEEE 802 local area network. 81 Its Type-Length-Value (TLV) design allows for "vendor-specific" 82 extensions to be defined. IANA has a registered IEEE 802 83 organizationally unique identifier (OUI) defined as documented in 84 [RFC7042]. 86 The creation and maintenance of the Autonomic Control Plane described 87 in [I-D.ietf-anima-autonomic-control-plane] requires creation of hop- 88 by-hop discovery of adjacent systems. There are Campus L2 systems 89 that are not broadcast safe until they have been connected to their 90 Software Defined Networking (SDN) controller. The use of the stable 91 connectivity provided by [RFC8368] can provide the SDN connectivity 92 required. 94 There is a bootstrap problem: the network may be unsafe for ACP 95 discovery broadcasts until configured, and it can not be 96 autonomically configured until the ACP discovery (and onboarding 97 process) is done. 99 LLDP provides an out, as it is never forwarded to other ports, and it 100 discovers all compliant layer-2 devices in a network, even if they do 101 not normally do layer-3 forwarding. 103 Additional LLDP has the advantage that received LLDP frames are 104 already configured in routing fabrics to be send up to the control 105 plane processor, with information identifying which physical port it 106 was received on. This is exactly the desired data flow for the 107 [I-D.ietf-anima-autonomic-control-plane]: all traffic goes to the 108 control processor. 110 This document provides a way to transmit the IPv6 Link-Layer packets 111 that are needed for formation of the 112 [I-D.ietf-anima-autonomic-control-plane]. Those packets types 113 include: IPv6 Neighbor Discovery, GRASP DULL over IPv6 Link-Local, 114 IPsec ESP and IKEv2 packets. 116 1.1. Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 120 "OPTIONAL" in this document are to be interpreted as described in 121 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 122 capitals, as shown here. 124 2. Protocol 126 2.1. LLDP Encapsulation 128 The LLDP vendor-specific frame has the following format: 130 +--------+--------+----------+---------+-------------- 131 |TLV Type| len | OUI |subtype | IPv6 fragment 132 | =127 | |= 00 00 5E| = TBD | 133 |(7 bits)|(9 bits)|(3 octets)|(1 octet)|(1-255 octets) 134 +--------+--------+----------+---------+-------------- 136 where: 138 * TLV Type = 127 indicates a vendor-specific TLV 140 * len = indicates the TLV string length 142 * OUI = 00 00 5E is the organizationally unique identifier of IANA 143 * subtype = TBD (as assigned by IANA for this document) 145 * IPv6 fragment, up to 255 octets of packet. 147 The vendor-specific frame has a limit of 255 octets, while IPv6 has a 148 minimum MTU of 1280 bytes. An LLDP frame can contain more than one 149 TLV, and ethernet accomodates up to 1500 bytes (often larger), so it 150 should all fit. Two possible solutions are discussed here: 152 1. use six subtype TLV values. The first for 255 octets go into the 153 first TLV, the second 255 octets go into the second TLV, etc. 154 Six options of 255 bytes each results in a maximum payload size 155 of 1530, which exceeds the ethernet payload size. Given the 156 overhead of 6 bytes per TLV, this results in an MTU of 1464 bytes 157 within the 1500 byte ethernet payload space. 159 2. use the same TLV value, repeated six times. 161 The second method seems more obvious but it is unclear if all LLDP 162 subsystems would permit TLVs to be repeated, or if they would keep 163 the TLVs in the correct order. While the IANA has only 253 available 164 TLVs, and perhaps a request for 6 values might seem excessive, if 165 this resource was depleted, a new OUI could be used. 167 An OUI specific to this effort could be allocated, or a vendor OUI 168 could be used during prototyping. 170 2.2. Content of Payload - option 1 - entire IPv6 packet 172 The simplest encapsulation would put the entire IPv6 packet, 173 including the IPv6 header in. This takes a bit more space, but 174 provides the maximum flexibility. 176 This flexibility may come at a cost of creating a new attack surface 177 for devices. Any L2 connected device may not inject IPv6 frames into 178 the control plane of the adjacenty router. 180 2.3. Content of Payload - option 2 - elided IPv6 packet 182 The [I-D.ietf-anima-autonomic-control-plane] use case only sends IPv6 183 Link-Local packets. The IPv6 source and destination address are 184 always directly related to the L2 Ethernet headers, with the use of 185 SLAAC derived IIDs, and the prefix "fe80". 187 This proposal is to include only the fields: 1. Payload Length 2. 188 Next Header 189 The Hop Limit is always 1 for Link-Local packets. The Flow Label is 190 always 0. 192 Note that in the [I-D.ietf-anima-autonomic-control-plane] a mesh of 193 IPsec tunnels is created on top of ESP packets over IPv6 Link-Local, 194 and within that tunnel all of IPv6 can be sent. 196 The use hard coding of so many values significantly limits the attack 197 surface possible. 199 2.4. Content of Payload - option 3 - RFC8138 compressed packet 201 An option similar to above, yet providing a bit more flexibility is 202 to use [RFC8138] compression of packets as it done on low powered 203 802.15.4 networks. 205 This results in compression that is close to what option 2 provides, 206 yet provides for a lot of flexibility. 208 This option requires more code, may be subject to new attacks on the 209 decompression code, and expands the attack surface to all of IPv6, as 210 well as the RFC8138 compression code. 212 3. Privacy Considerations 214 YYY 216 4. Security Considerations 218 ZZZ 220 5. IANA Considerations 222 6. Acknowledgements 224 Hello. 226 7. Changelog 228 8. References 230 8.1. Normative References 232 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 233 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 234 May 2017, . 236 [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and 237 IETF Protocol and Documentation Usage for IEEE 802 238 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, 239 October 2013, . 241 [I-D.ietf-anima-autonomic-control-plane] 242 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 243 Control Plane (ACP)", Work in Progress, Internet-Draft, 244 draft-ietf-anima-autonomic-control-plane-21, 3 November 245 2019, . 248 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 249 "IPv6 over Low-Power Wireless Personal Area Network 250 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 251 April 2017, . 253 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 254 Requirement Levels", BCP 14, RFC 2119, 255 DOI 10.17487/RFC2119, March 1997, 256 . 258 8.2. Informative References 260 [RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic 261 Control Plane for Stable Connectivity of Network 262 Operations, Administration, and Maintenance (OAM)", 263 RFC 8368, DOI 10.17487/RFC8368, May 2018, 264 . 266 Author's Address 268 Michael Richardson 269 Sandelman Software Works 271 Email: mcr+ietf@sandelman.ca