idnits 2.17.1 draft-kompella-mpls-larp-05.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 10, 2016) is 2969 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) == Missing Reference: 'TODO-MPLS-FABRIC' is mentioned on line 105, but not defined == Missing Reference: 'TO-BE-ASSIGNED-BY-IANA-1' is mentioned on line 395, but not defined == Missing Reference: 'TO-BE-ASSIGNED-BY-IANA-2' is mentioned on line 396, but not defined == Missing Reference: 'HTYPE-MPLS' is mentioned on line 486, but not defined ** Obsolete normative reference: RFC 2002 (Obsoleted by RFC 3220) ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) ** Obsolete normative reference: RFC 6424 (Obsoleted by RFC 8029) == Outdated reference: A later version (-15) exists of draft-gredler-idr-bgplu-epe-04 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS WG K. Kompella 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track R. Balaji 5 Expires: September 11, 2016 Juniper Networks, Inc. 6 G. Swallow 7 Cisco Systems 8 March 10, 2016 10 Label Distribution Using ARP 11 draft-kompella-mpls-larp-05 13 Abstract 15 This document describes extensions to the Address Resolution Protocol 16 to distribute MPLS labels for IPv4 and IPv6 host addresses. 17 Distribution of labels via ARP enables simple plug-and-play operation 18 of MPLS. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in [RFC2119]. 26 The term "server" will be used in this document to refer to an ARP/ 27 L-ARP server; the term "host" will be used to refer to a compute 28 server or other device acting as an ARP/L-ARP client. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 11, 2016. 47 Copyright Notice 49 Copyright (c) 2016 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Approach . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Overview of Ethernet ARP . . . . . . . . . . . . . . . . . . 4 67 3. L-ARP Protocol Operation . . . . . . . . . . . . . . . . . . 4 68 3.1. Setup . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.2. Egress Operation . . . . . . . . . . . . . . . . . . . . 5 70 3.3. Ingress Operation . . . . . . . . . . . . . . . . . . . . 5 71 4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 5. Client-Server Synchronization . . . . . . . . . . . . . . . . 7 73 5.1. Restart Handling . . . . . . . . . . . . . . . . . . . . 7 74 5.1.1. Server Restart . . . . . . . . . . . . . . . . . . . 7 75 5.1.2. Client Restart . . . . . . . . . . . . . . . . . . . 8 76 5.2. Expedited Reachability Determination . . . . . . . . . . 8 77 6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 8 78 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 9 79 8. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 8.1. L-ARP IPv4 FEC . . . . . . . . . . . . . . . . . . . . . 9 81 8.2. L-ARP IPv6 FEC . . . . . . . . . . . . . . . . . . . . . 9 82 9. For Future Study . . . . . . . . . . . . . . . . . . . . . . 10 83 10. L-ARP Message Format . . . . . . . . . . . . . . . . . . . . 11 84 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 85 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 86 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 87 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 14.1. Normative References . . . . . . . . . . . . . . . . . . 14 89 14.2. Informative References . . . . . . . . . . . . . . . . . 15 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 92 1. Introduction 94 This document describes extensions to the Address Resolution Protocol 95 (ARP) [RFC0826] to advertise label bindings for IP host addresses. 96 While there are well-established protocols, such as LDP, RSVP and 97 BGP, that provide robust mechanisms for label distribution, these 98 protocols tend to be relatively complex, and often require detailed 99 configuration for proper operation. There are situations where a 100 simpler protocol may be more suitable from an operational standpoint. 102 An example is the case where an MPLS Fabric is the underlay 103 technology in a Data Center; here, MPLS tunnels originate from host 104 machines. The host thus needs a mechanism to acquire label bindings 105 to participate in the MPLS Fabric. [TODO-MPLS-FABRIC] describes the 106 motivation for using MPLS as the fabric technology. 108 Another use-case is Egress Peer Traffic-Engineering (EPE) 109 [I-D.gredler-idr-bgplu-epe]. In EPE, if the host makes the decision 110 to direct packets towards a specific link using MPLS tunneling 111 techniques, there needs to a suitable protocol for the host to 112 acquire MPLS labels from the network. 114 In both the cases, the mechanism that the host uses to partcipate in 115 label exchange with the network needs to be simple, and plug-and- 116 play. Existing signaling/routing protocols do not always meet this 117 need. Labeled ARP (L-ARP) is a proposal to fill that gap. 119 1.1. Approach 121 ARP is a nearly ubiquitous protocol; every device with an Ethernet 122 interface, from hand-helds to hosts, have an implementation of ARP. 123 ARP is plug-and-play; ARP clients do not need configuration to use 124 ARP. That suggests that ARP may be a good fit for devices that want 125 to source and sink MPLS tunnels, but do so in a zero-config, plug- 126 and-play manner, with minimal impact to their code. 128 The approach taken here is to create a minor variant of the ARP 129 protocol, labeled ARP (L-ARP), which is distinguished by a new 130 hardware type, MPLS-over-Ethernet. Regular (Ethernet) ARP (E-ARP) 131 and L-ARP can coexist; a device, as an ARP client, can choose to send 132 out an E-ARP or an L-ARP request, depending on whether it needs 133 Ethernet or MPLS connectivity. Another device may choose to function 134 as an E-ARP server and/or an L-ARP server, depending on its ability 135 to provide an IP-to-Ethernet and/or IP-to-MPLS mapping. 137 2. Overview of Ethernet ARP 139 In the most straightforward mode of operation [RFC0826], ARP queries 140 are sent to resolve "directly connected" IP addresses. The ARP query 141 is broadcast, with the Target Protocol Address field (see Section 10 142 for a description of the fields in an ARP message) carrying the IP 143 address of another node in the same subnet. All the nodes in the LAN 144 receive this ARP query. All the nodes, except the node that owns the 145 IP address, ignore the ARP query. The IP address owner learns the 146 MAC address of the sender from the Source Hardware Address field in 147 the ARP request, and unicasts an ARP reply to the sender. The ARP 148 reply carries the replying node's MAC address in the Source Hardware 149 Address field, thus enabling two-way communication between the two 150 nodes. 152 A variation of this scheme, known as "proxy ARP" [RFC2002], allows a 153 node to respond to an ARP request with its own MAC address, even when 154 the responding node does not own the requested IP address. 155 Generally, the proxy ARP response is generated by routers to attract 156 traffic for prefixes they can forward packets to. This scheme 157 requires the host to send ARP queries for the IP address the host is 158 trying to reach, rather than the IP address of the router. When 159 there is more than one router connected to a network, proxy ARP 160 enables a host to automatically select an exit router without running 161 any routing protocol to determine IP reachability. Unlike regular 162 ARP, a proxy ARP request can elicit multiple responses, e.g., when 163 more than one router has connectivity to the address being resolved. 164 The sender must be prepared to select one of the responding routers. 166 Yet another variation of the ARP protocol, called 'Gratuitous ARP' 167 [RFC2002], allows a node to update the ARP cache of other nodes in an 168 unsolicited fashion. Gratuitous ARP is sent as either an ARP request 169 or an ARP reply. In either case, the Source Protocol Address and 170 Target Protocol Address contain the sender's address, and the Source 171 Hardware Address is set to the sender's hardware address. In case of 172 a gratuitous ARP reply, the Target Hardware Address is also set to 173 the sender's address. 175 3. L-ARP Protocol Operation 177 The L-ARP protocol builds on the proxy ARP model, and also leverages 178 gratuitous ARP model for asynchronous updates. 180 In this memo, we will refer to L-ARP clients (that make L-ARP 181 requests) and L-ARP servers (that send L-ARP responses). In 182 Figure 1, H1, H2 and H3 are L-ARP clients, and T1, T2 and T3 are IP 183 routers playing the role of L-ARP server. T4 is a member of the MPLS 184 Fabric that may not be an L-ARP server. Within the MPLS Fabric, the 185 usual MPLS protocols (IGP, LDP, RSVP-TE) are run. Say H1, H2 and H3 186 want to establish MPLS tunnels to each other (for example, they are 187 using BGP MPLS VPNs as the overlay virtual network technology). H1 188 might also want to talk to a member of the MPLS Fabric, say T (not 189 depicted in the diagram). 191 . . . . . . 192 . . 193 H1 --- T1 T4 194 \ . MPLS . 195 \ . . 196 \ . Fabric . 197 H2 --- T2 T3 --- H3 198 . . 199 . . . . . . . 201 Figure 1 203 3.1. Setup 205 In Figure 1, the nodes T1-T4, and those in between making up the 206 "MPLS Fabric" are assumed to be running some protocol whereby they 207 can signal MPLS reachability to themselves and to other nodes (like 208 H1-H3). T1-T3 are L-ARP servers; T4 need not be. H1-H3 are L-ARP 209 clients. 211 3.2. Egress Operation 213 A node (say T3) that wants an attached node (say H3) to have MPLS 214 reachability, allocates a label L3 to reach H3, and advertises this 215 label into the MPLS Fabric. This can be triggered by configuration 216 on T3, or via some other protocol. On receiving a packet with label 217 L3, T3 pops the label and send the packet to H3. This is the usual 218 operation of an MPLS Fabric, with the addition of advertising labels 219 for nodes outside the fabric. 221 3.3. Ingress Operation 223 A node (say H1, the L-ARP client) that needs an MPLS tunnel to a node 224 (say H3) identified by a host address (either IPv4 or IPv6) 225 broadcasts over all its interfaces an L-ARP query with the Target 226 Protocol Address set to H3. A node (say T1, an L-ARP server) that 227 has MPLS reachability to H3 sends an L-ARP reply with the Source 228 Hardware Address set to its Ethernet MAC address M1, with a new TLV 229 containing a label L1. To send a packet to H3 over an MPLS tunnel, 230 H1 pushes L1 onto the packet, sets the destination MAC address to M1 231 and sends it to T1. On receiving this packet, T1 swaps the top label 232 with the label(s) for its MPLS tunnel to H3. 234 Note that H1 broadcasts its L-ARP request over its attached 235 interfaces. H1 may receive several L-ARP replies; in that case, H1 236 can select any subset of these to send MPLS packets destined to H3. 237 As described later, the L-ARP response may contain certain parameters 238 that enable the client to make an informed choice. However, it is 239 completely a matter of local policy on H1 which of the many responses 240 are used. Some possibilites include, but not limited to, 242 o Use the first reply that arrives, and ignore the rest 244 o Wait for a certain amount of time, and choose the response 245 carrying the least metric 247 o If there is more than one response carrying the least metric, 248 perform load-balancing among them 250 o Consult local configuration to select a gateway 252 If the target H3 belongs to one of the subnets that H1 participates 253 in, and H3 is capable of sending L-ARP replies, H1 can use H3's 254 response to send MPLS packets to H3. 256 4. Attributes 258 In addition to carrying a label stack to be used in the data plane, 259 an L-ARP reply carries some attributes that are typically used in the 260 control plane. One of these is a metric. The metric is the distance 261 from the L-ARP server to the destination. This allows an L-ARP 262 client that receives multiple responses to decide which ones to use, 263 and whether to load-balance across some of them. The metric 264 typically will be the IGP shortest path distance from server to the 265 destination; this makes comparing metrics from different servers 266 meaningful. 268 Another attribute, carried in the LST TLV, is Entropy Label (EL) 269 Capability. This attribute says whether the destination is EL 270 capable (ELC). In Figure 1, if T3 advertises a label to reach H3 and 271 T3 is ELC, T3 can include in its signaling to T1 that it is ELC. In 272 that case, if T1's L-ARP reply to H1 consists of a single label, T1 273 can set the ELC bit in the label field of the LST TLV. This tells H1 274 that it may include (below the outermost label) an Entropy Label 275 Indicator followed by an Entropy Label. This will help improve load 276 balancing across the MPLS Fabric, and possibly on the last hop to H3. 278 5. Client-Server Synchronization 280 In an L-ARP reply, the server communicates several pieces of 281 information to the client: its hardware address, the MPLS label, 282 Entropy Label capability and metric. Since ARP is a stateless 283 protocol, it is possible that one of these changes without the client 284 knowing, which leads to a loss of synchronization between the client 285 and the server. This loss of synchronization can have several 286 undesirable effects. 288 If the server's hardware address changes or the MPLS label is 289 repurposed by the server for a different purpose, then packets may be 290 sent to the wrong destination. The consequences can range from 291 suboptimally routed packets to dropped packets to packets being 292 delivered to the wrong customer, which may be a security breach. 293 This last may be the most troublesome consequence of loss of 294 synchronization. 296 If a destination transitions from entropy label capable to entropy 297 label incapable (an unlikely event) without the client knowing, then 298 packets encapsulated with entropy labels will be dropped. A 299 transition in the other direction is benign. 301 If the metric changes without the client knowing, packets may be 302 suboptimally routed. This may be the most benign consequence of loss 303 of synchronization. 305 Standard ARP has similar issues. These are dealt with in two ways: 306 a) ARP bindings are time-bound; and b) an ARP server, recognizing 307 that a change has occurred, can send unsolicited ARP messages 308 ([RFC2002]). Both these techniques are used in L-ARP: the validity 309 of the MPLS label obtained using L-ARP is time-bound; an L-ARP client 310 should periodically resend L-ARP requests to obtain the latest 311 information, and time out entries in its ARP cache if such an update 312 is not forthcoming. 314 Furthermore, an L-ARP server may update an advertised label binding 315 by sending an unsolicited L-ARP message if any of the parameters 316 mentioned above change. Likewise, an L-ARP server may withdraw its 317 earlier advertisement by sending an unsolicited LARP-NAK message. 319 5.1. Restart Handling 321 5.1.1. Server Restart 323 In order to support graceful restart, the L-ARP server must remember 324 the advertised bindings across restarts. The mechanism that the 325 L-ARP server uses to accomplish this is outside the scope of this 326 document. Some possible mechanisms are, usage of shared memory or 327 non-volatile storage to store bindings. Upon restart, the L-ARP 328 server waits until the LSPs advertised in the previous incarnation 329 are restored. Then, it reconciles the L-ARP bindings with the 330 current state of the LSPs, updating the clients with unsolicted L-ARP 331 replies & NAK for bindings that have undergone changes. 333 During the above procedure, the client does not really know that the 334 server has restarted. If there were no changes to the LSPs during 335 restart, the client receives no updates. If there were changes, then 336 the client would receive unsolicited updates to the bindings, as it 337 would on a normal change. If the server does not successfully 338 restart, the client's periodic refresh will detect the loss of 339 connectivity and purge out the bindings. 341 If the L-ARP server does not support graceful restart, it SHOULD 342 withdraw the advertised bindings before shutting down. Unplanned 343 restarts rely on the slower perioidc refresh mechanism for re- 344 synchronization. 346 5.1.2. Client Restart 348 If the client restarts gracefully, it re-acquires the bindings 349 immediately after restart to learn about any changes. 351 If the client does not support graceful restart, it leaves the 352 bindings to age out. 354 5.2. Expedited Reachability Determination 356 As with other control protocols, the client and server may use data 357 plane liveness detection mechanisms, such as Loss of Signal (LOS) 358 and/or BFD, to expedite detection of loss of connectivity. However, 359 usage of these mechanisms are outside the scope of this document. 361 6. Applicability 363 L-ARP can be used between a host and its Top-of-Rack switch in a Data 364 Center. L-ARP can also be used between a DSLAM and its aggregation 365 switch going to the B-RAS. In seamless MPLS terms, L-ARP can be used 366 between an "Access Node" (AN) (e.g., the DSLAM) and its first hop 367 MPLS-enabled device in the context of Seamless MPLS 368 [I-D.ietf-mpls-seamless-mpls]. The first-hop device is part of the 369 MPLS Fabric, as is the Service Node (SN) (e.g., the B-RAS). L-ARP 370 helps create an MPLS tunnel from the AN to the SN, without requiring 371 that the AN be part of the MPLS Fabric. In all these cases, L-ARP 372 can handle the presence of multiple connections between the access 373 device and its first hop devices. 375 ARP is not a routing protocol. The use of L-ARP should be limited to 376 cases where an L-ARP client has Ethernet connectivity to its L-ARP 377 servers. 379 7. Backward Compatibility 381 Since L-ARP uses a new hardware type, it is backward compatible with 382 "regular" ARP. ARP servers and clients MUST be able to send out, 383 receive and process ARP messages based on hardware type. They MAY 384 choose to ignore requests and replies of some hardware types; they 385 MAY choose to log errors if they encounter hardware types they do not 386 recognize; however, they MUST handle all hardware types gracefully. 387 For hardware types that they do understand, ARP servers and clients 388 MUST handle operation codes gracefully, processing those they 389 understand, and ignoring (and possibly logging) others. 391 8. OAM 393 L-ARP uses standard MPLS OAM procedures defined in [RFC4379] & 394 [RFC6424]. Extending the definitions in section 3.2 of RFC 4379, we 395 use a sub-type of [TO-BE-ASSIGNED-BY-IANA-1] to represent L-ARP IPv4 396 FEC, and [TO-BE-ASSIGNED-BY-IANA-2] to represent L-ARP IPv6 FEC. The 397 following sub-sections define the format of L-ARP FEC's. 399 8.1. L-ARP IPv4 FEC 401 The L-ARP IPv4 FEC is defined as follows: 403 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 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | IPv4 address | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 IPv4 address is the tunnel destination address. 410 Figure 2: ARP IPv4 FEC 412 The length of the L-ARP IPv4 FEC is 4 bytes. 414 8.2. L-ARP IPv6 FEC 416 The L-ARP IPv6 FEC is defined as follows: 418 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 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | IPv6 address | 421 | (16 octets) | 422 | | 423 | | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 IPv6 address is the tunnel destination address. 428 Figure 3: ARP IPv6 FEC 430 The length of the L-ARP IPv6 FEC is 16 bytes. 432 9. For Future Study 434 The L-ARP specification is quite simple, and the goal is to keep it 435 that way. However, inevitably, there will be questions and features 436 that will be requested. Some of these are: 438 1. Keeping L-ARP clients and servers in sync. In particular, 439 dealing with: 441 A. client and/or server control plane restart 443 B. lost packets 445 C. timeouts 447 2. Dealing with scale. 449 3. If there are many servers, which one to pick? 451 4. How can a client make best use of underlying ECMP paths? 453 5. and probably many more. 455 In all of these, it is important to realize that, whenever possible, 456 a solution that places most of the burden on the server rather than 457 on the client is preferable. 459 These questions (and others that come up during discussions) will be 460 dealt with in future versions of this draft. 462 10. L-ARP Message Format 464 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 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | ar$hrd | ar$pro | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | ar$hln | ar$pln | ar$op | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 // ar$sha (ar$hln octets) // 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 // ar$spa (ar$pln octets) // 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 // ar$tha (ar$hln octets) // 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 // ar$tpa (ar$pln octets) // 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 // ar$lst (variable...) // 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 // ar$att (variable...) // 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 Figure 4: L-ARP Packet Format 485 ar$hrd Hardware Type: MPLS-over-Ethernet. The value of the field 486 used here is [HTYPE-MPLS]. To start with, we will use the 487 experimental value HW_EXP2 (256) 489 ar$pro Protocol Type: IPv4/IPv6. The value of the field used here 490 is 0x0800 to resolve an IPv4 address and 0x86DD to resolve an 491 IPv6 address. 493 ar$hln Hardware Length: 6. 495 ar$pln Protocol Address Length: for an IPv4 address, the value is 4; 496 for an IPv6 address, it is 16. 498 ar$op Operation Code: set to 1 for request, 2 for reply, and 10 for 499 ARP-NAK. Other op codes may be used as needed. 501 ar$sha Source Hardware Address: In an L-ARP message, Source Hardware 502 Address is the 6 octet sender's MAC address. 504 ar$spa Source Protocol Address: In an L-ARP message, this field 505 carries the sender's IP address. 507 ar$tha Target Hardware Address: In an L-ARP query message, Target 508 Hardware Address is the all-ones Broadcast MAC address; in an 509 L-ARP reply message, it is the client's MAC address. 511 ar$tpa Target Protocol Address: In an L-ARP message, this field 512 carries the IP address for which the client is seeking an MPLS 513 label. 515 ar$lst Label Stack: In an L-ARP request, this field is empty. In an 516 L-ARP reply, this field carries the MPLS label stack as an ARP 517 TLV in the format below. 519 ar$att Attributes: In an L-ARP request, this field is empty. In an 520 L-ARP reply, this field carries attributes for the MPLS label 521 stack as an ARP TLV in the format below. 523 This document introduces the notion of ARP TLVs. These take the form 524 as in Figure 5. Figure 6 describes the format of Label Stack TLV 525 carried in L-ARP. Figure 7 describes the format of Attributes TLV 526 carried in L-ARP. 528 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 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Type | Length | Value (Length octets) ... | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | ... | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 Type is the type of the TLV; Length is the length of the value field 536 in octets; Value is the value field. 538 Figure 5: ARP TLVs 540 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 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Type | Length | MPLS Label (20 bits) | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | |E|Z|Z|Z| MPLS Label (20 bits) |E|Z|Z|Z| 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | ... 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 Figure 6: MPLS Label Stack Format 551 Label Stack: Type = TLV-LST; Length = n*3 octets, where n is the 552 number of labels. The Value field contains the MPLS label stack 553 for the client to use to get to the target. Each label is 3 554 octets. This field is valid only in an L-ARP reply message. 556 E-bit: Entropy Label Capable: this flag indicates whether the 557 corresponding label in the label stack can be followd by an 558 Entropy Label. If this flag is set, the client has the option of 559 inserting ELI and EL as specified in [RFC6790]. The client can 560 choose not to insert ELI/EL pair. If this flag is clear, the 561 client MUST NOT insert ELI/EL after the corresponding label. 563 Z These bits are not used, and SHOULD be set to zero on sending and 564 ignored on receipt. 566 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 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Type | Length | Metric (4 octets) ... | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | ... Metric | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 Figure 7: Attribute TLV 575 Attributes TLV: Type = TLV-ATT; Length = 4 octets. The Value field 576 contains the metric (typically, IGP distance) from the responder 577 to the destination (device with the requested IP address). If the 578 responder is the destination, then the metric value is zero. This 579 field is valid only in an L-ARP reply message. 581 If other parameters are deemed useful in the ATT TLV, they will be 582 added as needed. 584 11. Security Considerations 586 There are many possible attacks on ARP: ARP spoofing, ARP cache 587 poisoning and ARP poison routing, to name a few. These attacks use 588 gratuitous ARP as the underlying mechanism, a mechanism used by 589 L-ARP. Thus, these types of attacks are applicable to L-ARP. 590 Furthermore, ARP does not have built-in security mechanisms; defenses 591 rely on means external to the protocol. 593 It is well outside the scope of this document to present a general 594 solution to the ARP security problem. One simple answer is to add a 595 TLV that contains a digital signature of the contents of the ARP 596 message. This TLV would be defined for use only in L-ARP messages, 597 although in principle, other ARP messages could use it as well. Such 598 an approach would, of course, need a review and approval by the 599 Security Directorate. If approved, the type of this TLV and its 600 procedures would be defined in this document. If some other 601 technique is suggested, the authors would be happy to include the 602 relevant text in this document, and refer to some other document for 603 the full solution. 605 12. IANA Considerations 607 IANA is requested to allocate a new ARP hardware type (from the 608 registry hrd) for HTYPE-MPLS. 610 IANA is also requested to create a new registry ARP-TLV ("tlv"). 611 This is a registry of one octet numbers. Allocation policies: 0 is 612 not to be allocated; the range 1-127 is Standards Action; the values 613 128-251 are FCFS; and the values 252-255 are Experimental. 615 Finally, IANA is requested to allocate two values in the ARP-TLV 616 registry, one for TLV-LST and another for TLV-ATT. 618 13. Acknowledgments 620 Many thanks to Shane Amante for his detailed comments and 621 suggestions. Many thanks to the team in Juniper prototyping this 622 work for their suggestions on making this variant workable in the 623 context of existing ARP implementations. Thanks too to Luyuan Fang, 624 Alex Semenyaka and Dmitry Afanasiev for their comments and 625 encouragement. 627 14. References 629 14.1. Normative References 631 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 632 Converting Network Protocol Addresses to 48.bit Ethernet 633 Address for Transmission on Ethernet Hardware", STD 37, 634 RFC 826, DOI 10.17487/RFC0826, November 1982, 635 . 637 [RFC2002] Perkins, C., Ed., "IP Mobility Support", RFC 2002, 638 DOI 10.17487/RFC2002, October 1996, 639 . 641 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 642 Requirement Levels", BCP 14, RFC 2119, 643 DOI 10.17487/RFC2119, March 1997, 644 . 646 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 647 Label Switched (MPLS) Data Plane Failures", RFC 4379, 648 DOI 10.17487/RFC4379, February 2006, 649 . 651 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 652 Performing Label Switched Path Ping (LSP Ping) over MPLS 653 Tunnels", RFC 6424, DOI 10.17487/RFC6424, November 2011, 654 . 656 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 657 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 658 RFC 6790, DOI 10.17487/RFC6790, November 2012, 659 . 661 14.2. Informative References 663 [I-D.gredler-idr-bgplu-epe] 664 Gredler, H., Vairavakkalai, K., R, C., Rajagopalan, B., 665 and L. Fang, "Egress Peer Engineering using BGP-LU", 666 draft-gredler-idr-bgplu-epe-04 (work in progress), 667 September 2015. 669 [I-D.ietf-mpls-seamless-mpls] 670 Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, 671 M., and D. Steinberg, "Seamless MPLS Architecture", draft- 672 ietf-mpls-seamless-mpls-07 (work in progress), June 2014. 674 Authors' Addresses 676 Kireeti Kompella 677 Juniper Networks 678 1194 N. Mathilda Avenue 679 Sunnyvale, CA 94089 680 USA 682 Email: kireeti.kompella@gmail.com 684 Balaji Rajagopalan 685 Juniper Networks, Inc. 686 Prestige Electra, Exora Business Park 687 Marathahalli - Sarjapur Outer Ring Road 688 Bangalore 560103 689 India 691 Email: balajir@juniper.net 692 George Swallow 693 Cisco Systems 694 1414 Massachusetts Ave 695 Boxborough, MA 01719 696 US 698 Email: swallow@cisco.com