idnits 2.17.1 draft-kompella-mpls-larp-09.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 (14 January 2021) is 1170 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 2002 (Obsoleted by RFC 3220) == Outdated reference: A later version (-17) exists of draft-kaliraj-idr-bgp-classful-transport-planes-00 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group K. Kompella 3 Internet-Draft R. Balaji 4 Intended status: Standards Track R. Thomas 5 Expires: 18 July 2021 Juniper Networks 6 14 January 2021 8 Label Distribution Using ARP 9 draft-kompella-mpls-larp-09 11 Abstract 13 This document describes extensions to the Address Resolution Protocol 14 to distribute MPLS labels for IPv4 and IPv6 host addresses. 15 Distribution of labels via ARP enables simple plug-and-play operation 16 of MPLS, which is key to deploying MPLS in data centers and 17 enterprises. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 18 July 2021. 36 Copyright Notice 38 Copyright (c) 2021 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 54 1.2. Approach . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Overview of Ethernet ARP . . . . . . . . . . . . . . . . . . 3 56 3. L-ARP Protocol Operation . . . . . . . . . . . . . . . . . . 4 57 3.1. Setup . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3.2. Egress Operation . . . . . . . . . . . . . . . . . . . . 5 59 3.3. Ingress Operation . . . . . . . . . . . . . . . . . . . . 5 60 3.4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . 6 61 4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 4.1. Secondary Attributes . . . . . . . . . . . . . . . . . . 7 63 5. L-ARP Message Format . . . . . . . . . . . . . . . . . . . . 7 64 5.1. Hardware Address Format . . . . . . . . . . . . . . . . . 9 65 5.2. CT TLV . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 6. L-ARP Client Server Synchronisation . . . . . . . . . . . . . 10 67 6.1. L-ARP NAK . . . . . . . . . . . . . . . . . . . . . . . . 10 68 6.2. Bulk withdrawal . . . . . . . . . . . . . . . . . . . . . 11 69 6.3. Garbage Collection Requirements . . . . . . . . . . . . . 11 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 75 10.2. Informative References . . . . . . . . . . . . . . . . . 12 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 78 1. Introduction 80 This document describes extensions to the Address Resolution Protocol 81 (ARP) [RFC0826] to advertise label bindings for IP host addresses. 82 While there are well-established protocols, such as LDP, RSVP and 83 BGP, that provide robust mechanisms for label distribution, these 84 protocols tend to be relatively complex, and often require detailed 85 configuration for proper operation. There are situations where a 86 simpler protocol may be more suitable from an operational standpoint. 87 An example is the case where an MPLS Fabric is the underlay 88 technology in a Data Center; here, MPLS tunnels originate from host 89 machines. The host thus needs a mechanism to acquire label bindings 90 to participate in the MPLS Fabric, but in a simple, plug-and-play 91 manner. Existing signaling/routing protocols do not always meet this 92 need. Labeled ARP (L-ARP) is a proposal to fill that gap. 94 1.1. Requirements Language 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 The term "server" will be used in this document to refer to an ARP/ 101 L-ARP server; the term "host" will be used to refer to a compute 102 server or other device acting as an ARP/L-ARP client. 104 1.2. Approach 106 ARP is a nearly ubiquitous protocol; every device with an Ethernet 107 interface, from hand-helds to hosts, have an implementation of ARP. 108 ARP is plug-and-play; ARP clients do not need configuration to use 109 ARP. That suggests that ARP may be a good fit for devices that want 110 to source and sink MPLS tunnels, but do so in a zero-config, plug- 111 and-play manner, with minimal impact to their code. 113 The approach taken here is to create a minor variant of the ARP 114 protocol, labeled ARP (L-ARP), which is distinguished by a new 115 hardware type, MPLS-over-Ethernet. Regular (Ethernet) ARP (E-ARP) 116 and L-ARP can coexist; a device, as an ARP client, can choose to send 117 out an E-ARP or an L-ARP request, depending on whether it needs 118 Ethernet or MPLS connectivity. Another device may choose to function 119 as an E-ARP server and/or an L-ARP server, depending on its ability 120 to provide an IP-to-Ethernet and/or IP-to-MPLS mapping. 122 2. Overview of Ethernet ARP 124 In the most straightforward mode of operation [RFC0826], ARP queries 125 are sent to resolve "directly connected" IP addresses. The ARP 126 request is broadcast, with the Target Protocol Address field (see 127 Section 5 for a description of the fields in an ARP message) carrying 128 the IP address of another node in the same subnet. All the nodes in 129 the LAN receive this ARP request. All the nodes, except the node 130 that owns the IP address, ignore the ARP request. The IP address 131 owner learns the MAC address of the sender from the Source Hardware 132 Address field in the ARP request, and unicasts an ARP reply to the 133 sender. The ARP reply carries the replying node's MAC address in the 134 Source Hardware Address field, thus enabling two-way communication 135 between the two nodes. 137 A variation of this scheme, known as "proxy ARP" [RFC2002], allows a 138 node to respond to an ARP request with its own MAC address, even when 139 the responding node does not own the requested IP address. 140 Generally, the proxy ARP response is generated by routers to attract 141 traffic for prefixes they can forward packets to. This scheme 142 requires the host to send ARP queries for the IP address the host is 143 trying to reach, rather than the IP address of the router. When 144 there is more than one router connected to a network, proxy ARP 145 enables a host to automatically select an exit router without running 146 any routing protocol to determine IP reachability. Unlike regular 147 ARP, a proxy ARP request can elicit multiple responses, e.g., when 148 more than one router has connectivity to the address being resolved. 149 The sender must be prepared to select one of the responding routers. 151 Yet another variation of the ARP protocol, called 'Gratuitous ARP' 152 [RFC2002], allows a node to update the ARP cache of other nodes in an 153 unsolicited fashion. Gratuitous ARP is sent as either an ARP request 154 or an ARP reply. In either case, the Source Protocol Address and 155 Target Protocol Address contain the sender's address, and the Source 156 Hardware Address is set to the sender's hardware address. In case of 157 a gratuitous ARP reply, the Target Hardware Address is also set to 158 the sender's address. 160 3. L-ARP Protocol Operation 162 The L-ARP protocol builds on the proxy ARP model, and also leverages 163 gratuitous ARP model for asynchronous updates. 165 In this memo, we will refer to L-ARP clients (that make L-ARP 166 requests) and L-ARP servers (that send L-ARP responses). In 167 Figure 1, H1, H2 and H3 are L-ARP clients, and T1, T2 and T3 are 168 L-ARP servers. T4 is a member of the MPLS Fabric that may not be an 169 L-ARP server. Within the MPLS Fabric, the usual MPLS protocols (IGP, 170 LDP, RSVP-TE) are run. Say H1, H2 and H3 want to establish MPLS 171 tunnels to each other (for example, they are using BGP MPLS VPNs as 172 the overlay virtual network technology). H1 might also want to talk 173 to a member of the MPLS Fabric, say T. Also, the "protocol" 174 addresses in L-ARP requests are either IPv4 or IPv6 addresses; note 175 that while it is common to use Neighbor Discovery (ND) [RFC4861] for 176 "regular" ARP requests when dealing with IPv6 (i.e., to obtain 177 Ethernet MAC addresses corresponding to an IPv6 address), ND is not 178 used when the ARP request is for an MPLS label. 180 . . . . . . . 181 . . 182 H1 --- T1 T4 183 \ . MPLS . 184 \ . . 185 \ . Fabric . 186 H2 --- T2 T3 --- H3 187 . . 188 . . . . . . . 190 Figure 1: MPLS Fabric 192 3.1. Setup 194 In Figure 1, the nodes T1-T4, and those in between making up the 195 "MPLS Fabric" are assumed to be running some protocol whereby they 196 can signal MPLS reachability to themselves and to other nodes (like 197 hosts H1-H3). T1-T3 are L-ARP servers; T4 need not be, since it 198 doesn't have an attached L-ARP client. H1-H3 are L-ARP clients. 200 3.2. Egress Operation 202 A node (say T3) that wants an attached node (say H3) to have MPLS 203 reachability allocates a label L3 to reach H3 and advertises this 204 label into the MPLS Fabric. This can be triggered by configuration 205 on T3, or when T3 first receives an L-ARP request from H3 (indicating 206 that H3 wants MPLS connectivity), or via some other protocol. T3 207 then advertises (H3, L3) to its peers in the MPLS Fabric so that all 208 members of the Fabric have connectivity to H3. This advertisement 209 can be one of the following: 211 * a "proxy" LDP message (sent on behalf of H3) with prefix H3 and 212 label L3; or 214 * a node SID advertised on behalf of H3; or 216 * a labeled BGP advertisement, with prefix H3, label L3 and next hop 217 self. 219 On receiving a packet with label L3, T3 pops the label and send 220 the packet to H3. (In the case of labeled BGP, there would be a 221 two-label stack, with outer label to reach T3 and inner label of 222 L3.) This is the usual operation of an MPLS Fabric, with the 223 addition of advertising labels for nodes outside the fabric. 225 3.3. Ingress Operation 227 A node (say H1, an L-ARP client) that needs an MPLS tunnel to another 228 node (say H3) identified by a host address (either IPv4 or IPv6) 229 broadcasts over all its interfaces an L-ARP request with the Target 230 Protocol Address set to H3 and Hardware Type set to "MPLS-over- 231 Ethernet". A node receiving the L-ARP request (say T1, an L-ARP 232 server) does the following: 234 1. checks if it has reachability to H3. If not, it ignores the 235 L-ARP request. 237 2. if it does, T1 allocates a label TL3 to reach H3 (if it doesn't 238 already have such a label) and installs an L-FIB entry to swap L1 239 with the label (stack) to reach H3. 241 3. sends a (proxy) L-ARP reply to H1 with the Source Hardware 242 Address (SHA) set to (L, M), where M is T1's metric to H3. T1 243 may also set some attribute bits in the SHA. 245 3.4. Data Plane 247 To send a packet to H3 over an MPLS tunnel, H1 pushes L1 onto the 248 packet, sets the destination MAC address to M1 and sends it to T1. 249 On receiving this packet, T1 swaps the top label with the label(s) 250 for its MPLS tunnel to H3. If T1's reachability to H3 is via a 251 SPRING label stack, the label L1 acts as an implicit binding SID. 253 If H1 and H3 have an overlay connection (say an IPVPN [RFC4364] VPN- 254 foo) whereby VM1 on H1 wishes to talk to VM3 on H3 over VPN-foo, H1 255 does the following: 257 1. H1 learns information about VPN-foo via BGP (or an SDN 258 controller), including the VPN label VL3 to use to talk to VM3; 260 2. H1 installs a VRF for VPN-foo, with prefix VM3, label VL3 and 261 next hop H3; 263 3. H1 binds the local "veth" interface to VM1 to this VRF. 265 4. When VM1 sends a packet to dest IP address VM3 over its veth 266 interface, H1 looks up VM3 in the corresponding VRF, gets label 267 VL3. It then sends an L-ARP request for next hop H3, and gets 268 TL3. 270 5. Finally, H1 pushes the label pair (TL3, VL3) onto the packet from 271 VM1 and sends this to T1. This packet will then end up at VM3 on 272 H3. 274 Note that H1 broadcasts its L-ARP request over its attached 275 interfaces. H1 may receive several L-ARP replies; in that case, H1 276 can select any subset of these to send MPLS packets destined to H3. 277 As described later, the L-ARP response may contain certain parameters 278 that enable the client to make an informed choice. If the target H3 279 belongs to one of the subnets that H1 participates in, and H3 is 280 capable of sending L-ARP replies, H1 can use H3's response to send 281 MPLS packets to H3. 283 4. Attributes 285 In addition to carrying a label stack to be used in the data plane, 286 an L-ARP reply carries some attributes that are typically used in the 287 control plane. One of these is a metric. The metric is the distance 288 from the L-ARP server to the destination. This allows an L-ARP 289 client that receives multiple responses to decide which ones to use, 290 and whether to load-balance across some of them. The metric 291 typically will be the IGP shortest path distance from server to the 292 destination; this makes comparing metrics from different servers 293 meaningful. 295 Another attribute is Entropy Label (EL) Capability. This attribute 296 says whether the destination is EL capable (ELC). In Figure 1, if T3 297 advertises a label to reach H3 and T3 is ELC, T3 can include in its 298 signaling to T1 that it is ELC. In that case, T1's L-ARP reply to H1 299 can have ELC bit set. This tells H1 that it may include (below the 300 outermost label) an Entropy Label Indicator followed by an Entropy 301 Label. This will help improve load balancing across the MPLS Fabric, 302 and possibly on the last hop to H3. 304 4.1. Secondary Attributes 306 Beyond the basic attributes that are carried with every L-ARP 307 request, there more optional attributes, for example, to ask for 308 certain characteristics of the path traffic takes to the destination. 309 These attributes are carried in TLVs that are carried in L-ARP 310 requests and replies. 312 One such TLV is the "CT" TLV. This TLV allows the L-ARP client to 313 request a label to a destination over a tunnel in the Transport Class 314 given by CT [I-D.kaliraj-idr-bgp-classful-transport-planes]. To 315 satisfy this request, the L-ARP server creates (or finds) a tunnel to 316 the destination that is routed over the CT Transport Plane, allocates 317 a label L, inserts an entry in the LFIB to swap L to the tunnel, and 318 sends L to the L-ARP client in its reply. 320 5. L-ARP Message Format 321 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | ar$hrd | ar$pro | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | ar$hln | ar$pln | ar$op | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 // ar$sha (ar$hln octets) // 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 // ar$spa (ar$pln octets) // 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 // ar$tha (ar$hln octets) // 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 // ar$tpa (ar$pln octets) // 334 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 335 | Type | Length | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 // Value // 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Type | Length | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 // Value // 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | ... | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 Figure 2: L-ARP Packet Format 348 ar$hrd: Hardware Type: MPLS-over-Ethernet. The value of the field 350 used here is HTYPE-MPLS. To start with, we will use the 351 experimental value HW_EXP2 (256). 353 ar$pro: Protocol Type: IPv4/IPv6. The value of the field used here 355 is 0x0800 to resolve an IPv4 address and 0x86DD to resolve an IPv6 356 address. 358 ar$hln: Hardware Address Length: 6 360 ar$pln: Protocol Address Length: for an IPv4 address, the length is 362 4 octets; for an IPv6 address, it is 16. 364 ar$op: Operation Code: set to 1 for request, 2 for reply, and 10 for 366 ARP-NAK. Other op codes may be used as needed. 368 ar$sha: Source Hardware Address: In an L-ARP request, this is 370 usually all zeros. In an L-ARP reply, Source Hardware Address is 371 the label to reach ar$spa, as specified in Figure 3 below. 373 ar$spa: Source Protocol Address: In an L-ARP request, this field 375 carries the sender's IP address. In an L-ARP reply, this field 376 carries the requested IP address (which may not be the sender's IP 377 address). 379 ar$tha: Target Hardware Address: In an L-ARP message, this is all 381 zeros. 383 ar$tpa: Target Protocol Address: In an L-ARP request, this field 385 carries the IP address for which the client is seeking an MPLS 386 label. 388 Type: a 2-octet field defining the Type of the TVL 390 Length: a 2-octet field defining the Length L of the TVL 392 Value: an L-octet field with the Value of the TLV 394 5.1. Hardware Address Format 396 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | MPLS Label (20 bits) |E|Z|Z|Z| Metric ... | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | ... (3 octets) | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 Figure 3: Label Format in L-ARP 405 MPLS Label: 406 The 20-bit label 408 E-bit: 409 Entropy Label Capable: this flag indicates whether the 411 corresponding label in the label stack can be followd by an 412 Entropy Label. If this flag is set, the client has the option of 413 inserting ELI and EL as specified in [RFC6790]. The client can 414 choose not to insert ELI/EL pair. If this flag is clear, the 415 client must not insert ELI/EL after the corresponding label. 417 Z: These bits are not used, and SHOULD be set to zero on sending 418 and 419 ignored on receipt. 421 Metric: 422 The IGP metric to ar$tha from the point of view of the L-ARP 424 replier. 426 5.2. CT TLV 428 The CT TLV has Type (TBD) and Length 4 octets; the Value field 429 consists of the CT attribute. 431 6. L-ARP Client Server Synchronisation 433 The information that is communicated in the L-ARP reply can change 434 and hence it is necessary to have both the client and server 435 synchronised with each other. Loss of synchronisation between client 436 and server can have undesirable side effects such as packet drops or 437 packets getting diverted to wrong or suboptimal path. To keep the 438 client cache synchronised with server L-ARP protocol employs two 439 methods 441 1. Periodic refresh from L-ARP client side: To prevent stale 442 information remaining in the cache indefinitely, L-ARP client 443 should periodically send unicast L-ARP requests and refresh its 444 cache. In the absence of any replies for a configured no of 445 times, L-ARP client should purge the entry from its cache. The 446 server SHOULD send an explicit L-ARP NAK message in reply for 447 such unicast L-ARP requests received if it has no mapping for the 448 requested IP or when the entry is withdrawn. 450 2. Explicit notifications from server side: On advertised parameter 451 changes, the L-ARP server should broadcast an unsolicited L-ARP 452 reply with the updated parameters. L-ARP client on receipt of 453 the unsolicited reply should update the cache if the entry 454 already exists in its cache. If the entry does not exist client 455 should drop the unsolicited L-ARP packet without any processing. 457 6.1. L-ARP NAK 459 On events like label withdrawal the L-ARP server SHOULD notify the 460 clients to invalidate the cache entry by broadcasting an L-ARP NAK 461 message for that label. On receiving the NAK message a node SHOULD 462 delete the cache entry associated with the corresponding label. 464 6.2. Bulk withdrawal 466 In cases where the server doesn't store advertised label bindings in 467 a persistent storage, it would be necessary to withdraw all the 468 advertised labels in case of server events like reboot. To handle 469 such scenarios L-ARP provides a bulk withdrawal request of its 470 advertised labels. Bulk withdrawal L-ARP request is made by 471 broadcasting an L-ARP NAK packet with all-zero address in the source 472 protocol address field. 474 6.3. Garbage Collection Requirements 476 To limit the storage needed on both server and client side for the 477 L-ARP caches, a node may need to periodically garbage-collect old 478 entries. The client can follow a LRU-based policy to reclaim the 479 entries. On server side the liveness of the entry can be determined 480 by the periodic refreshes from the client and in the absence of any 481 refreshes for a configurable time interval the labels advertised can 482 be reclaimed. 484 7. Security Considerations 486 There are many possible attacks on ARP: ARP spoofing, ARP cache 487 poisoning and ARP poison routing, to name a few. These attacks use 488 gratuitous ARP as the underlying mechanism, a mechanism used by 489 L-ARP. Thus, these types of attacks are applicable to L-ARP. 490 Furthermore, ARP does not have built-in security mechanisms; defenses 491 rely on means external to the protocol. 493 It is well outside the scope of this document to present a general 494 solution to the ARP security problem. One simple answer is to add a 495 TLV that contains a digital signature of the contents of the ARP 496 message. This TLV would be defined for use only in L-ARP messages, 497 although in principle, other ARP messages could use it as well. Such 498 an approach would, of course, need a review and approval by the 499 Security Directorate. If approved, the type of this TLV and its 500 procedures would be defined in this document. If some other 501 technique is suggested, the authors would be happy to include the 502 relevant text in this document, and refer to some other document for 503 the full solution. 505 8. IANA Considerations 507 IANA is requested to allocate a new ARP hardware type (from registry 508 hrd) for HTYPE-MPLS. 510 9. Acknowledgments 512 Many thanks to Shane Amante for his detailed comments and 513 suggestions. Many thanks to the team in Juniper prototyping this 514 work for their suggestions on making this variant workable in the 515 context of existing ARP implementations. Thanks too to Luyuan Fang, 516 Alex Semenyaka and Dmitry Afanasiev for their comments and 517 encouragement. 519 10. References 521 10.1. Normative References 523 [RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or 524 Converting Network Protocol Addresses to 48.bit Ethernet 525 Address for Transmission on Ethernet Hardware", STD 37, 526 RFC 826, DOI 10.17487/RFC0826, November 1982, 527 . 529 [RFC2002] Perkins, C., Ed., "IP Mobility Support", RFC 2002, 530 DOI 10.17487/RFC2002, October 1996, 531 . 533 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 534 Requirement Levels", BCP 14, RFC 2119, 535 DOI 10.17487/RFC2119, March 1997, 536 . 538 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 539 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 540 RFC 6790, DOI 10.17487/RFC6790, November 2012, 541 . 543 10.2. Informative References 545 [I-D.kaliraj-idr-bgp-classful-transport-planes] 546 Vairavakkalai, K., Venkataraman, N., and B. Rajagopalan, 547 "BGP Classful Transport Planes", Work in Progress, 548 Internet-Draft, draft-kaliraj-idr-bgp-classful-transport- 549 planes-00, 8 May 2020, . 553 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 554 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 555 2006, . 557 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 558 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 559 DOI 10.17487/RFC4861, September 2007, 560 . 562 Authors' Addresses 564 Kireeti Kompella 565 Juniper Networks 566 1133 Innovation Way 567 Sunnyvale 94089 568 USA 570 Phone: +1-408-745-2000 571 Email: kireeti.kompella@gmail.com 573 R. Balaji 574 Juniper Networks 575 Survey No.111/1 to 115/4, Wing A & B 576 Bangalore 560103 577 India 579 Email: balajir@juniper.net 581 Reji Thomas 582 Juniper Networks 583 Survey No.111/1 to 115/4, Wing A & B 584 Bangalore 560103 585 India 587 Email: rejithomas@juniper.net