idnits 2.17.1 draft-kompella-mpls-larp-07.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 (March 07, 2020) is 1511 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) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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: September 8, 2020 Juniper Networks 6 March 07, 2020 8 Label Distribution Using ARP 9 draft-kompella-mpls-larp-07 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 September 8, 2020. 36 Copyright Notice 38 Copyright (c) 2020 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 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 55 1.2. Approach . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Overview of Ethernet ARP . . . . . . . . . . . . . . . . . . 3 57 3. L-ARP Protocol Operation . . . . . . . . . . . . . . . . . . 4 58 3.1. Setup . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.2. Egress Operation . . . . . . . . . . . . . . . . . . . . 5 60 3.3. Ingress Operation . . . . . . . . . . . . . . . . . . . . 5 61 3.4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . 6 62 4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 5. L-ARP Message Format . . . . . . . . . . . . . . . . . . . . 7 64 5.1. Hardware Address Format . . . . . . . . . . . . . . . . . 8 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 70 9.2. Informative References . . . . . . . . . . . . . . . . . 10 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 73 1. Introduction 75 This document describes extensions to the Address Resolution Protocol 76 (ARP) [RFC0826] to advertise label bindings for IP host addresses. 77 While there are well-established protocols, such as LDP, RSVP and 78 BGP, that provide robust mechanisms for label distribution, these 79 protocols tend to be relatively complex, and often require detailed 80 configuration for proper operation. There are situations where a 81 simpler protocol may be more suitable from an operational standpoint. 82 An example is the case where an MPLS Fabric is the underlay 83 technology in a Data Center; here, MPLS tunnels originate from host 84 machines. The host thus needs a mechanism to acquire label bindings 85 to participate in the MPLS Fabric, but in a simple, plug-and-play 86 manner. Existing signaling/routing protocols do not always meet this 87 need. Labeled ARP (L-ARP) is a proposal to fill that gap. 89 1.1. Requirements Language 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. 95 The term "server" will be used in this document to refer to an ARP/ 96 L-ARP server; the term "host" will be used to refer to a compute 97 server or other device acting as an ARP/L-ARP client. 99 1.2. Approach 101 ARP is a nearly ubiquitous protocol; every device with an Ethernet 102 interface, from hand-helds to hosts, have an implementation of ARP. 103 ARP is plug-and-play; ARP clients do not need configuration to use 104 ARP. That suggests that ARP may be a good fit for devices that want 105 to source and sink MPLS tunnels, but do so in a zero-config, plug- 106 and-play manner, with minimal impact to their code. 108 The approach taken here is to create a minor variant of the ARP 109 protocol, labeled ARP (L-ARP), which is distinguished by a new 110 hardware type, MPLS-over-Ethernet. Regular (Ethernet) ARP (E-ARP) 111 and L-ARP can coexist; a device, as an ARP client, can choose to send 112 out an E-ARP or an L-ARP request, depending on whether it needs 113 Ethernet or MPLS connectivity. Another device may choose to function 114 as an E-ARP server and/or an L-ARP server, depending on its ability 115 to provide an IP-to-Ethernet and/or IP-to-MPLS mapping. 117 2. Overview of Ethernet ARP 119 In the most straightforward mode of operation [RFC0826], ARP queries 120 are sent to resolve "directly connected" IP addresses. The ARP 121 request is broadcast, with the Target Protocol Address field (see 122 Section 5 for a description of the fields in an ARP message) carrying 123 the IP address of another node in the same subnet. All the nodes in 124 the LAN receive this ARP request. All the nodes, except the node 125 that owns the IP address, ignore the ARP request. The IP address 126 owner learns the MAC address of the sender from the Source Hardware 127 Address field in the ARP request, and unicasts an ARP reply to the 128 sender. The ARP reply carries the replying node's MAC address in the 129 Source Hardware Address field, thus enabling two-way communication 130 between the two nodes. 132 A variation of this scheme, known as "proxy ARP" [RFC2002], allows a 133 node to respond to an ARP request with its own MAC address, even when 134 the responding node does not own the requested IP address. 135 Generally, the proxy ARP response is generated by routers to attract 136 traffic for prefixes they can forward packets to. This scheme 137 requires the host to send ARP queries for the IP address the host is 138 trying to reach, rather than the IP address of the router. When 139 there is more than one router connected to a network, proxy ARP 140 enables a host to automatically select an exit router without running 141 any routing protocol to determine IP reachability. Unlike regular 142 ARP, a proxy ARP request can elicit multiple responses, e.g., when 143 more than one router has connectivity to the address being resolved. 144 The sender must be prepared to select one of the responding routers. 146 Yet another variation of the ARP protocol, called 'Gratuitous ARP' 147 [RFC2002], allows a node to update the ARP cache of other nodes in an 148 unsolicited fashion. Gratuitous ARP is sent as either an ARP request 149 or an ARP reply. In either case, the Source Protocol Address and 150 Target Protocol Address contain the sender's address, and the Source 151 Hardware Address is set to the sender's hardware address. In case of 152 a gratuitous ARP reply, the Target Hardware Address is also set to 153 the sender's address. 155 3. L-ARP Protocol Operation 157 The L-ARP protocol builds on the proxy ARP model, and also leverages 158 gratuitous ARP model for asynchronous updates. 160 In this memo, we will refer to L-ARP clients (that make L-ARP 161 requests) and L-ARP servers (that send L-ARP responses). In 162 Figure 1, H1, H2 and H3 are L-ARP clients, and T1, T2 and T3 are 163 L-ARP servers. T4 is a member of the MPLS Fabric that may not be an 164 L-ARP server. Within the MPLS Fabric, the usual MPLS protocols (IGP, 165 LDP, RSVP-TE) are run. Say H1, H2 and H3 want to establish MPLS 166 tunnels to each other (for example, they are using BGP MPLS VPNs as 167 the overlay virtual network technology). H1 might also want to talk 168 to a member of the MPLS Fabric, say T. Also, the "protocol" 169 addresses in L-ARP requests are either IPv4 or IPv6 addresses; note 170 that while it is common to use Neighbor Discovery (ND) [RFC4861] for 171 "regular" ARP requests when dealing with IPv6 (i.e., to obtain 172 Ethernet MAC addresses corresponding to an IPv6 address), ND is not 173 used when the ARP request is for an MPLS label. 175 . . . . . . . 176 . . 177 H1 --- T1 T4 178 \ . MPLS . 179 \ . . 180 \ . Fabric . 181 H2 --- T2 T3 --- H3 182 . . 183 . . . . . . . 185 Figure 1: MPLS Fabric 187 3.1. Setup 189 In Figure 1, the nodes T1-T4, and those in between making up the 190 "MPLS Fabric" are assumed to be running some protocol whereby they 191 can signal MPLS reachability to themselves and to other nodes (like 192 hosts H1-H3). T1-T3 are L-ARP servers; T4 need not be, since it 193 doesn't have an attached L-ARP client. H1-H3 are L-ARP clients. 195 3.2. Egress Operation 197 A node (say T3) that wants an attached node (say H3) to have MPLS 198 reachability allocates a label L3 to reach H3 and advertises this 199 label into the MPLS Fabric. This can be triggered by configuration 200 on T3, or when T3 first receives an L-ARP request from H3 (indicating 201 that H3 wants MPLS connectivity), or via some other protocol. T3 202 then advertises (H3, L3) to its peers in the MPLS Fabric so that all 203 members of the Fabric have connectivity to H3. This advertisement 204 can be one of the following: 206 o a "proxy" LDP message (sent on behalf of H3) with prefix H3 and 207 label L3; or 209 o a node SID advertised on behalf of H3; or 211 o a labeled BGP advertisement, with prefix H3, label L3 and next hop 212 self. 214 On receiving a packet with label L3, T3 pops the label and send 215 the packet to H3. (In the case of labeled BGP, there would be a 216 two-label stack, with outer label to reach T3 and inner label of 217 L3.) This is the usual operation of an MPLS Fabric, with the 218 addition of advertising labels for nodes outside the fabric. 220 3.3. Ingress Operation 222 A node (say H1, an L-ARP client) that needs an MPLS tunnel to another 223 node (say H3) identified by a host address (either IPv4 or IPv6) 224 broadcasts over all its interfaces an L-ARP request with the Target 225 Protocol Address set to H3 and Hardware Type set to "MPLS-over- 226 Ethernet". A node receiving the L-ARP request (say T1, an L-ARP 227 server) does the following: 229 1. checks if it has reachability to H3. If not, it ignores the 230 L-ARP request. 232 2. if it does, T1 allocates a label TL3 to reach H3 (if it doesn't 233 already have such a label) and installs an L-FIB entry to swap L1 234 with the label (stack) to reach H3. 236 3. sends a (proxy) L-ARP reply to H1 with the Source Hardware 237 Address (SHA) set to (L, M), where M is T1's metric to H3. T1 238 may also set some attribute bits in the SHA. 240 3.4. Data Plane 242 To send a packet to H3 over an MPLS tunnel, H1 pushes L1 onto the 243 packet, sets the destination MAC address to M1 and sends it to T1. 244 On receiving this packet, T1 swaps the top label with the label(s) 245 for its MPLS tunnel to H3. If T1's reachability to H3 is via a 246 SPRING label stack, the label L1 acts as an implicit binding SID. 248 If H1 and H3 have an overlay connection (say an IPVPN [RFC4364] VPN- 249 foo) whereby VM1 on H1 wishes to talk to VM3 on H3 over VPN-foo, H1 250 does the following: 252 1. H1 learns information about VPN-foo via BGP (or an SDN 253 controller), including the VPN label VL3 to use to talk to VM3; 255 2. H1 installs a VRF for VPN-foo, with prefix VM3, label VL3 and 256 next hop H3; 258 3. H1 binds the local "veth" interface to VM1 to this VRF. 260 4. When VM1 sends a packet to dest IP address VM3 over its veth 261 interface, H1 looks up VM3 in the corresponding VRF, gets label 262 VL3. It then sends an L-ARP request for next hop H3, and gets 263 TL3. 265 5. Finally, H1 pushes the label pair (TL3, VL3) onto the packet from 266 VM1 and sends this to T1. This packet will then end up at VM3 on 267 H3. 269 Note that H1 broadcasts its L-ARP request over its attached 270 interfaces. H1 may receive several L-ARP replies; in that case, H1 271 can select any subset of these to send MPLS packets destined to H3. 272 As described later, the L-ARP response may contain certain parameters 273 that enable the client to make an informed choice. If the target H3 274 belongs to one of the subnets that H1 participates in, and H3 is 275 capable of sending L-ARP replies, H1 can use H3's response to send 276 MPLS packets to H3. 278 4. Attributes 280 In addition to carrying a label stack to be used in the data plane, 281 an L-ARP reply carries some attributes that are typically used in the 282 control plane. One of these is a metric. The metric is the distance 283 from the L-ARP server to the destination. This allows an L-ARP 284 client that receives multiple responses to decide which ones to use, 285 and whether to load-balance across some of them. The metric 286 typically will be the IGP shortest path distance from server to the 287 destination; this makes comparing metrics from different servers 288 meaningful. 290 Another attribute is Entropy Label (EL) Capability. This attribute 291 says whether the destination is EL capable (ELC). In Figure 1, if T3 292 advertises a label to reach H3 and T3 is ELC, T3 can include in its 293 signaling to T1 that it is ELC. In that case, T1's L-ARP reply to H1 294 can have ELC bit set. This tells H1 that it may include (below the 295 outermost label) an Entropy Label Indicator followed by an Entropy 296 Label. This will help improve load balancing across the MPLS Fabric, 297 and possibly on the last hop to H3. 299 5. L-ARP Message Format 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | ar$hrd | ar$pro | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | ar$hln | ar$pln | ar$op | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 // ar$sha (ar$hln octets) // 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 // ar$spa (ar$pln octets) // 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 // ar$tha (ar$hln octets) // 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 // ar$tpa (ar$pln octets) // 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 Figure 2: L-ARP Packet Format 318 ar$hrd: Hardware Type: MPLS-over-Ethernet. The value of the field 319 used here is HTYPE-MPLS. To start with, we will use the 320 experimental value HW_EXP2 (256). 322 ar$pro: Protocol Type: IPv4/IPv6. The value of the field used here 323 is 0x0800 to resolve an IPv4 address and 0x86DD to resolve an IPv6 324 address. 326 ar$hln: Hardware Address Length: 6 328 ar$pln: Protocol Address Length: for an IPv4 address, the length is 329 4 octets; for an IPv6 address, it is 16. 331 ar$op: Operation Code: set to 1 for request, 2 for reply, and 10 for 332 ARP-NAK. Other op codes may be used as needed. 334 ar$sha: Source Hardware Address: In an L-ARP request, this is 335 usually all zeros. In an L-ARP reply, Source Hardware Address is 336 the label to reach ar$spa, as specified in Figure 3 below. 338 ar$spa: Source Protocol Address: In an L-ARP request, this field 339 carries the sender's IP address. In an L-ARP reply, this field 340 carries the requested IP address (which may not be the sender's IP 341 address). 343 ar$tha: Target Hardware Address: In an L-ARP message, this is all 344 zeros. 346 ar$tpa: Target Protocol Address: In an L-ARP request, this field 347 carries the IP address for which the client is seeking an MPLS 348 label. 350 5.1. Hardware Address Format 352 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 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | MPLS Label (20 bits) |E|Z|Z|Z| Metric ... | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | ... (3 octets) | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 Figure 3: Label Format in L-ARP 361 MPLS Label: The 20-bit label 363 E-bit: Entropy Label Capable: this flag indicates whether the 364 corresponding label in the label stack can be followd by an 365 Entropy Label. If this flag is set, the client has the option of 366 inserting ELI and EL as specified in [RFC6790]. The client can 367 choose not to insert ELI/EL pair. If this flag is clear, the 368 client must not insert ELI/EL after the corresponding label. 370 Z: These bits are not used, and SHOULD be set to zero on sending and 371 ignored on receipt. 373 Metric: The IGP metric to ar$tha from the point of view of the L-ARP 374 replier. 376 6. Security Considerations 378 There are many possible attacks on ARP: ARP spoofing, ARP cache 379 poisoning and ARP poison routing, to name a few. These attacks use 380 gratuitous ARP as the underlying mechanism, a mechanism used by 381 L-ARP. Thus, these types of attacks are applicable to L-ARP. 382 Furthermore, ARP does not have built-in security mechanisms; defenses 383 rely on means external to the protocol. 385 It is well outside the scope of this document to present a general 386 solution to the ARP security problem. One simple answer is to add a 387 TLV that contains a digital signature of the contents of the ARP 388 message. This TLV would be defined for use only in L-ARP messages, 389 although in principle, other ARP messages could use it as well. Such 390 an approach would, of course, need a review and approval by the 391 Security Directorate. If approved, the type of this TLV and its 392 procedures would be defined in this document. If some other 393 technique is suggested, the authors would be happy to include the 394 relevant text in this document, and refer to some other document for 395 the full solution. 397 7. IANA Considerations 399 IANA is requested to allocate a new ARP hardware type (from registry 400 hrd) for HTYPE-MPLS. 402 8. Acknowledgments 404 Many thanks to Shane Amante for his detailed comments and 405 suggestions. Many thanks to the team in Juniper prototyping this 406 work for their suggestions on making this variant workable in the 407 context of existing ARP implementations. Thanks too to Luyuan Fang, 408 Alex Semenyaka and Dmitry Afanasiev for their comments and 409 encouragement. 411 9. References 413 9.1. Normative References 415 [RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or 416 Converting Network Protocol Addresses to 48.bit Ethernet 417 Address for Transmission on Ethernet Hardware", STD 37, 418 RFC 826, DOI 10.17487/RFC0826, November 1982, 419 . 421 [RFC2002] Perkins, C., Ed., "IP Mobility Support", RFC 2002, 422 DOI 10.17487/RFC2002, October 1996, 423 . 425 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 426 Requirement Levels", BCP 14, RFC 2119, 427 DOI 10.17487/RFC2119, March 1997, 428 . 430 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 431 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 432 RFC 6790, DOI 10.17487/RFC6790, November 2012, 433 . 435 9.2. Informative References 437 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 438 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 439 2006, . 441 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 442 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 443 DOI 10.17487/RFC4861, September 2007, 444 . 446 Authors' Addresses 448 Kireeti Kompella 449 Juniper Networks 450 1133 Innovation Way 451 Sunnyvale 94089 452 USA 454 Phone: +1-408-745-2000 455 Email: kireeti.kompella@gmail.com 457 Balaji Rajagopalan 458 Juniper Networks 459 Survey No.111/1 to 115/4, Wing A & B 460 Bangalore 560103 461 India 463 Email: balajir@juniper.net 464 Reji Thomas 465 Juniper Networks 466 Survey No.111/1 to 115/4, Wing A & B 467 Bangalore 560103 468 India 470 Email: rejithomas@juniper.net