idnits 2.17.1 draft-richardson-anima-ipv6-lldp-04.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 (April 07, 2020) is 1478 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) == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-24 ** Obsolete normative reference: RFC 7042 (Obsoleted by RFC 9542) Summary: 1 error (**), 0 flaws (~~), 2 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 L. Xia 5 Expires: October 9, 2020 Huawei 6 April 07, 2020 8 IPv6 over Link-Local Discovery Protocol 9 draft-richardson-anima-ipv6-lldp-04 11 Abstract 13 This document describes a mechanism to encapsulate IPv6 packets over 14 the Link Layer Discovery Protocol (LLDP). The LLDP is a single 15 layer-two protocol with its own ethertype. It is never forwarded, 16 which is a desireable property when building the IPv6-over-IPsec- 17 over-IPv6-Link-Local tunnels that make up the ANIMA Autonomic Control 18 Plane (ACP). 20 This unorthodox encapsulation avoids unwanted interactions between 21 the ACP packets and native packet forwarding engines, as well as 22 being safe for layer-2 switches which might otherwise have no IPv6 23 capabilities. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on October 9, 2020. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.1. LLDP Encapsulation . . . . . . . . . . . . . . . . . . . 3 63 2.2. Content of Payload - option 1 - entire IPv6 packet . . . 4 64 2.3. Content of Payload - option 2 - elided IPv6 packet . . . 5 65 2.4. Content of Payload - option 3 - RFC8138 compressed packet 5 66 3. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 70 7. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 73 8.2. Informative References . . . . . . . . . . . . . . . . . 7 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 76 1. Introduction 78 The IEEE802.1AB Link Layer Discovery Protocol (LLDP) is a one-hop, 79 vendor-neutral link-layer protocol used by network devices or Things 80 for advertising their identity, capabilities, and neighbors on an 81 IEEE 802 local area network. 83 The LLDP uses its own ethertype (0x88cc), and so is distinct from 84 production IPv4 or IPv6 traffic that might appear on a network. 85 Switching equipment is usually configured such that it does not 86 forward LLDP packets. 88 Its Type-Length-Value (TLV) design allows for "vendor-specific" 89 extensions to be defined. IANA has a registered IEEE 802 90 organizationally unique identifier (OUI) defined as documented in 91 [RFC7042]. 93 The creation and maintenance of the Autonomic Control Plane described 94 in [I-D.ietf-anima-autonomic-control-plane] requires creation of hop- 95 by-hop discovery of adjacent systems. There are Campus L2 systems 96 that are not broadcast safe until they have been connected to their 97 Software Defined Networking (SDN) controller. The use of the stable 98 connectivity provided by [RFC8368] can provide the SDN connectivity 99 required. 101 There is a bootstrap interlocking problem: the network may be unsafe 102 for ACP discovery broadcasts without the support of Spanning Tree 103 Protocol (STP) or similar mechanisms until configured, yet it can not 104 be automatically configured until the ACP discovery (and onboarding 105 process) is done. 107 LLDP provides a way for the above problem, as it is never forwarded 108 to other ports, and it discovers all compliant layer-2 devices in a 109 network, even if they do not normally do layer-3 forwarding. 111 Additionally, LLDP has the advantage that received LLDP frames are 112 already configured in routing fabrics to be send up to the control 113 plane processor, with information identifying which physical port 114 they were received on. This is exactly the desired data flow for the 115 [I-D.ietf-anima-autonomic-control-plane]: all traffic goes to the 116 control plane processor. 118 This document provides a way to transmit the IPv6 Link-Layer packets 119 that are needed for formation of the 120 [I-D.ietf-anima-autonomic-control-plane] over the LLDP. Those 121 packets types include: IPv6 Neighbor Discovery, GRASP DULL over IPv6 122 Link-Local, IPsec ESP and IKEv2 packets. 124 1.1. Terminology 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 128 "OPTIONAL" in this document are to be interpreted as described in 129 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 130 capitals, as shown here. 132 The term "octet" is used as a synonym for byte. As the IEEE prefers 133 the term octet, it is used whenever speaking of LLDP specific things. 135 2. Protocol 137 2.1. LLDP Encapsulation 139 The LLDP vendor-specific frame has the following format: 141 +--------+--------+----------+---------+-------------- 142 |TLV Type| len | OUI |subtype | IPv6 fragment 143 | =127 | |= 00 00 5E| = TBD | 144 |(7 bits)|(9 bits)|(3 octets)|(1 octet)|(0-507 octets) 145 +--------+--------+----------+---------+-------------- 147 where: 149 o TLV Type = 127 indicates a vendor-specific TLV 151 o len = indicates the TLV string length 153 o OUI = 00 00 5E is the organizationally unique identifier of IANA 155 o subtype = TBD (as assigned by IANA for this document) 157 o IPv6 fragment, up to 508 octets of packet. 159 The vendor-specific frame has a limit of 508 octets, while IPv6 has a 160 minimum MTU of 1280 bytes. An LLDP frame can contain more than one 161 TLV, and ethernet accomodates up to 1500 bytes (often larger), so it 162 should all fit. Two possible solutions are discussed here: 164 1. use three subtype TLV values. The first 508 octets go into the 165 first TLV, the second 508 octets go into the second TLV, etc. 166 three TLVs of 508 octets payload each results in a maximum 167 payload size of 1524, which exceeds the IPv6 minimum MTU of 1280 168 bytes. Given the overhead of 6 octets per TLV, the result is 169 that a maximum IPv6 MTU of 1464 bytes will fit within a standard 170 1500 octet ethernet payload space. 172 2. use the same subtype TLV value, repeated three times. 174 The second method seems more obvious but it is unclear if all LLDP 175 subsystems would permit TLVs to be repeated, or if they would keep 176 the TLVs in the correct order. While the IANA has only 253 available 177 TLVs, and perhaps a request for three values might seem excessive, if 178 this resource was depleted, a new OUI could be used. 180 Alternatively, an OUI specific to this effort could be allocated. A 181 vendor OUI could be used during prototyping. 183 2.2. Content of Payload - option 1 - entire IPv6 packet 185 The simplest encapsulation would put the entire IPv6 packet, 186 including the IPv6 header in. This takes a bit more space, but 187 provides the maximum flexibility. 189 This flexibility may come at a cost of creating a new attack surface 190 for devices. Any L2 connected device may not inject IPv6 frames into 191 the control plane of the adjacent devices. 193 2.3. Content of Payload - option 2 - elided IPv6 packet 195 The [I-D.ietf-anima-autonomic-control-plane] use case only sends IPv6 196 Link-Local packets. The IPv6 source and destination address are 197 always directly related to the L2 Ethernet headers, with the use of 198 SLAAC derived IIDs, and the prefix "fe80". 200 This proposal is to include only the fields: 202 1. Payload Length 204 2. Next Header 206 The Hop Limit is always 1 for Link-Local packets. The Flow Label is 207 always 0. 209 Note that in the [I-D.ietf-anima-autonomic-control-plane] a mesh of 210 IPsec tunnels is created on top of ESP packets over IPv6 Link-Local, 211 and within that tunnel all of IPv6 packets can be sent. 213 The use of hard coding of so many values significantly limits the 214 attack surface possible. 216 2.4. Content of Payload - option 3 - RFC8138 compressed packet 218 An option similar to above, yet providing a bit more flexibility is 219 to use [RFC8138] compression of packets as it done on low powered 220 802.15.4 networks. 222 This results in compression that is close to what option 2 provides, 223 yet providing a lot of flexibility. 225 This option requires more code, may be subject to new attacks on the 226 decompression code, and expands the attack surface to all of IPv6, as 227 well as the [RFC8138] compression code. 229 3. Privacy Considerations 231 YYY 233 4. Security Considerations 235 LLDP is relatively simple and does not provide any protections to the 236 traffic over it. The IPv6 packets over the LLDP SHOULD be protected 237 by all the existing best current practices. 239 The device control plane processor will be subject to the Deny of 240 Service (DoS) attack if excessive IPv6 packets over LLDP frames are 241 send up. Certain protecting mechanisms like rate limit and filtering 242 can be considered. 244 5. IANA Considerations 246 6. Acknowledgements 248 Hello. 250 7. Changelog 252 8. References 254 8.1. Normative References 256 [I-D.ietf-anima-autonomic-control-plane] 257 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 258 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 259 plane-24 (work in progress), March 2020. 261 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 262 Requirement Levels", BCP 14, RFC 2119, 263 DOI 10.17487/RFC2119, March 1997, 264 . 266 [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and 267 IETF Protocol and Documentation Usage for IEEE 802 268 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, 269 October 2013, . 271 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 272 "IPv6 over Low-Power Wireless Personal Area Network 273 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 274 April 2017, . 276 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 277 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 278 May 2017, . 280 8.2. Informative References 282 [RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic 283 Control Plane for Stable Connectivity of Network 284 Operations, Administration, and Maintenance (OAM)", 285 RFC 8368, DOI 10.17487/RFC8368, May 2018, 286 . 288 Authors' Addresses 290 Michael Richardson 291 Sandelman Software Works 293 Email: mcr+ietf@sandelman.ca 295 Liang Xia (Frank) 296 Huawei 298 Email: frank.xialiang@huawei.com