idnits 2.17.1 draft-kompella-mpls-larp-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 (September 8, 2015) is 3151 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 101, but not defined == Missing Reference: 'HTYPE-MPLS' is mentioned on line 373, but not defined ** Obsolete normative reference: RFC 2002 (Obsoleted by RFC 3220) Summary: 1 error (**), 0 flaws (~~), 3 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: March 11, 2016 Juniper Networks, Inc. 6 G. Swallow 7 Cisco Systems 8 September 8, 2015 10 Label Distribution Using ARP 11 draft-kompella-mpls-larp-04 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, which is a key goal of the MPLS Fabric architecture. 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 March 11, 2016. 47 Copyright Notice 49 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 65 1.1. Approach . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Overview of Ethernet ARP . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 5. Client-Server Synchronization . . . . . . . . . . . . . . . . 6 73 6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 7 74 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 7 75 8. For Future Study . . . . . . . . . . . . . . . . . . . . . . 7 76 9. L-ARP Message Format . . . . . . . . . . . . . . . . . . . . 8 77 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 78 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 79 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 80 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 13.1. Normative References . . . . . . . . . . . . . . . . . . 11 82 13.2. Informative References . . . . . . . . . . . . . . . . . 12 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 85 1. Introduction 87 This document describes extensions to the Address Resolution Protocol 88 (ARP) [RFC0826] to advertise label bindings for IP host addresses. 89 While there are well-established protocols, such as LDP, RSVP and 90 BGP, that provide robust mechanisms for label distribution, these 91 protocols tend to be relatively complex, and often require detailed 92 configuration for proper operation. There are situations where a 93 simpler protocol may be more suitable from an operational standpoint. 94 An example is the case where an MPLS Fabric is the underlay 95 technology in a Data Center; here, MPLS tunnels originate from host 96 machines. The host thus needs a mechanism to acquire label bindings 97 to participate in the MPLS Fabric, but in a simple, plug-and-play 98 manner. Existing signaling/routing protocols do not always meet this 99 need. Labeled ARP (L-ARP) is a proposal to fill that gap. 101 [TODO-MPLS-FABRIC] describes the motivation for using MPLS as the 102 fabric technology. 104 1.1. 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 query 126 is broadcast, with the Target Protocol Address field (see Section 9 127 for a description of the fields in an ARP message) carrying the IP 128 address of another node in the same subnet. All the nodes in the LAN 129 receive this ARP query. All the nodes, except the node that owns the 130 IP address, ignore the ARP query. The IP address owner learns the 131 MAC address of the sender from the Source Hardware Address field in 132 the ARP request, and unicasts an ARP reply to the sender. The ARP 133 reply carries the replying node's MAC address in the Source Hardware 134 Address field, thus enabling two-way communication between the two 135 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. 175 . . . . . . 176 . . 177 H1 --- T1 T4 178 \ . MPLS . 179 \ . . 180 \ . Fabric . 181 H2 --- T2 T3 --- H3 182 . . 183 . . . . . . . 185 Figure 1 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 H1-H3). T1-T3 are L-ARP servers; T4 need not be. H1-H3 are L-ARP 193 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 via some other protocol. On receiving a packet with label 201 L3, T3 pops the label and send the packet to H3. This is the usual 202 operation of an MPLS Fabric, with the addition of advertising labels 203 for nodes outside the fabric. 205 3.3. Ingress Operation 207 A node (say H1, the L-ARP client) that needs an MPLS tunnel to a node 208 (say H3) identified by a host address (either IPv4 or IPv6) 209 broadcasts over all its interfaces an L-ARP query with the Target 210 Protocol Address set to H3. A node (say T1, an L-ARP server) that 211 has MPLS reachability to H3 sends an L-ARP reply with the Source 212 Hardware Address set to its Ethernet MAC address M1, with a new TLV 213 containing a label L1. To send a packet to H3 over an MPLS tunnel, 214 H1 pushes L1 onto the packet, sets the destination MAC address to M1 215 and sends it to T1. On receiving this packet, T1 swaps the top label 216 with the label(s) for its MPLS tunnel to H3. 218 Note that H1 broadcasts its L-ARP request over its attached 219 interfaces. H1 may receive several L-ARP replies; in that case, H1 220 can select any subset of these to send MPLS packets destined to H3. 221 As described later, the L-ARP response may contain certain parameters 222 that enable the client to make an informed choice. If the target H3 223 belongs to one of the subnets that H1 participates in, and H3 is 224 capable of sending L-ARP replies, H1 can use H3's response to send 225 MPLS packets to H3. 227 4. Attributes 229 In addition to carrying a label stack to be used in the data plane, 230 an L-ARP reply carries some attributes that are typically used in the 231 control plane. One of these is a metric. The metric is the distance 232 from the L-ARP server to the destination. This allows an L-ARP 233 client that receives multiple responses to decide which ones to use, 234 and whether to load-balance across some of them. The metric 235 typically will be the IGP shortest path distance from server to the 236 destination; this makes comparing metrics from different servers 237 meaningful. 239 Another attribute, carried in the LST TLV, is Entropy Label (EL) 240 Capability. This attribute says whether the destination is EL 241 capable (ELC). In Figure 1, if T3 advertises a label to reach H3 and 242 T3 is ELC, T3 can include in its signaling to T1 that it is ELC. In 243 that case, if T1's L-ARP reply to H1 consists of a single label, T1 244 can set the ELC bit in the label field of the LST TLV. This tells H1 245 that it may include (below the outermost label) an Entropy Label 246 Indicator followed by an Entropy Label. This will help improve load 247 balancing across the MPLS Fabric, and possibly on the last hop to H3. 249 5. Client-Server Synchronization 251 In an L-ARP reply, the server communicates several pieces of 252 information to the client: its hardware address, the MPLS label, 253 Entropy Label capability and metric. Since ARP is a stateless 254 protocol, it is possible that one of these changes without the client 255 knowing, which leads to a loss of synchronization between the client 256 and the server. This loss of synchronization can have several 257 undesirable effects. 259 If the server's hardware address changes or the MPLS label is 260 repurposed by the server for a different purpose, then packets may be 261 sent to the wrong destination. The consequences can range from 262 suboptimally routed packets to dropped packets to packets being 263 delivered to the wrong customer, which may be a security breach. 264 This last may be the most troublesome consequence of loss of 265 synchronization. 267 If a destination transitions from entropy label capable to entropy 268 label incapable (an unlikely event) without the client knowing, then 269 packets encapsulated with entropy labels will be dropped. A 270 transition in the other direction is benign. 272 If the metric changes without the client knowing, packets may be 273 suboptimally routed. This may be the most benign consequence of loss 274 of synchronization. 276 Standard ARP has similar issues. These are dealt with in two ways: 277 a) ARP bindings are time-bound; and b) an ARP server, recognizing 278 that a change has occurred, can send unsolicited ARP messages 279 ([RFC2002]). Both these techniques are used in L-ARP: the validity 280 of the MPLS label obtained using L-ARP is time-bound; an L-ARP client 281 should periodically resend L-ARP requests to obtain the latest 282 information, and time out entries in its ARP cache if such an update 283 is not forthcoming. Furthermore, an L-ARP server may update an 284 advertised label binding by sending an unsolicited L-ARP message if 285 any of the parameters mentioned above change. 287 6. Applicability 289 L-ARP can be used between a host and its Top-of-Rack switch in a Data 290 Center. L-ARP can also be used between a DSLAM and its aggregation 291 switch going to the B-RAS. More generally, L-ARP can be used between 292 an "Access Node" (AN) (e.g., the DSLAM) and its first hop MPLS- 293 enabled device in the context of Seamless MPLS 294 [I-D.ietf-mpls-seamless-mpls]. The first-hop device is part of the 295 MPLS Fabric, as is the Service Node (SN) (e.g., the B-RAS). L-ARP 296 helps create an MPLS tunnel from the AN to the SN, without requiring 297 that the AN be part of the MPLS Fabric. In all these cases, L-ARP 298 can handle the presence of multiple connections between the access 299 device and its first hop devices. 301 ARP is not a routing protocol. The use of L-ARP should be limited to 302 cases where an L-ARP client has Ethernet connectivity to its L-ARP 303 servers. 305 7. Backward Compatibility 307 Since L-ARP uses a new hardware type, it is backward compatible with 308 "regular" ARP. ARP servers and clients MUST be able to send out, 309 receive and process ARP messages based on hardware type. They MAY 310 choose to ignore requests and replies of some hardware types; they 311 MAY choose to log errors if they encounter hardware types they do not 312 recognize; however, they MUST handle all hardware types gracefully. 313 For hardware types that they do understand, ARP servers and clients 314 MUST handle operation codes gracefully, processing those they 315 understand, and ignoring (and possibly logging) others. 317 8. For Future Study 319 The L-ARP specification is quite simple, and the goal is to keep it 320 that way. However, inevitably, there will be questions and features 321 that will be requested. Some of these are: 323 1. Keeping L-ARP clients and servers in sync. In particular, 324 dealing with: 326 A. client and/or server control plane restart 328 B. lost packets 330 C. timeouts 332 2. Withdrawing a response. 334 3. Dealing with scale. 336 4. If there are many servers, which one to pick? 338 5. How can a client make best use of underlying ECMP paths? 340 6. and probably many more. 342 In all of these, it is important to realize that, whenever possible, 343 a solution that places most of the burden on the server rather than 344 on the client is preferable. 346 These questions (and others that come up during discussions) will be 347 dealt with in future versions of this draft. 349 9. L-ARP Message Format 351 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 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | ar$hrd | ar$pro | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | ar$hln | ar$pln | ar$op | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 // ar$sha (ar$hln octets) // 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 // ar$spa (ar$pln octets) // 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 // ar$tha (ar$hln octets) // 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 // ar$tpa (ar$pln octets) // 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 // ar$lst (variable...) // 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 // ar$att (variable...) // 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 Figure 2: L-ARP Packet Format 372 ar$hrd Hardware Type: MPLS-over-Ethernet. The value of the field 373 used here is [HTYPE-MPLS]. To start with, we will use the 374 experimental value HW_EXP2 (256) 376 ar$pro Protocol Type: IPv4/IPv6. The value of the field used here 377 is 0x0800 to resolve an IPv4 address and 0x86DD to resolve an 378 IPv6 address. 380 ar$hln Hardware Length: 6. 382 ar$pln Protocol Address Length: for an IPv4 address, the value is 4; 383 for an IPv6 address, it is 16. 385 ar$op Operation Code: set to 1 for request, 2 for reply, and 10 for 386 ARP-NAK. Other op codes may be used as needed. 388 ar$sha Source Hardware Address: In an L-ARP message, Source Hardware 389 Address is the 6 octet sender's MAC address. 391 ar$spa Source Protocol Address: In an L-ARP message, this field 392 carries the sender's IP address. 394 ar$tha Target Hardware Address: In an L-ARP query message, Target 395 Hardware Address is the all-ones Broadcast MAC address; in an 396 L-ARP reply message, it is the client's MAC address. 398 ar$tpa Target Protocol Address: In an L-ARP message, this field 399 carries the IP address for which the client is seeking an MPLS 400 label. 402 ar$lst Label Stack: In an L-ARP request, this field is empty. In an 403 L-ARP reply, this field carries the MPLS label stack as an ARP 404 TLV in the format below. 406 ar$att Attributes: In an L-ARP request, this field is empty. In an 407 L-ARP reply, this field carries attributes for the MPLS label 408 stack as an ARP TLV in the format below. 410 This document introduces the notion of ARP TLVs. These take the form 411 as in Figure 3. Figure 4 describes the format of Label Stack TLV 412 carried in L-ARP. Figure 5 describes the format of Attributes TLV 413 carried in L-ARP. 415 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 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Type | Length | Value (Length octets) ... | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | ... | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 Type is the type of the TLV; Length is the length of the value field 423 in octets; Value is the value field. 425 Figure 3: ARP TLVs 427 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 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Type | Length | MPLS Label (20 bits) | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | |E|Z|Z|Z| MPLS Label (20 bits) |E|Z|Z|Z| 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | ... 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 Figure 4: MPLS Label Stack Format 438 Label Stack: Type = TLV-LST; Length = n*3 octets, where n is the 439 number of labels. The Value field contains the MPLS label stack 440 for the client to use to get to the target. Each label is 3 441 octets. This field is valid only in an L-ARP reply message. 443 E-bit: Entropy Label Capable: this flag indicates whether the 444 corresponding label in the label stack can be followd by an 445 Entropy Label. If this flag is set, the client has the option of 446 inserting ELI and EL as specified in [RFC6790]. The client can 447 choose not to insert ELI/EL pair. If this flag is clear, the 448 client must not insert ELI/EL after the corresponding label. 450 Z These bits are not used, and SHOULD be set to zero on sending and 451 ignored on receipt. 453 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 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Type | Length | Metric (4 octets) ... | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | ... Metric | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 Figure 5: Attribute TLV 462 Attributes TLV: Type = TLV-ATT; Length = 4 octets. The Value field 463 contains the metric (typically, IGP distance) from the responder 464 to the destination (device with the requested IP address). This 465 field is valid only in an L-ARP reply message. 467 If other parameters are deemed useful in the ATT TLV, they will be 468 added as needed. 470 10. Security Considerations 472 There are many possible attacks on ARP: ARP spoofing, ARP cache 473 poisoning and ARP poison routing, to name a few. These attacks use 474 gratuitous ARP as the underlying mechanism, a mechanism used by 475 L-ARP. Thus, these types of attacks are applicable to L-ARP. 476 Furthermore, ARP does not have built-in security mechanisms; defenses 477 rely on means external to the protocol. 479 It is well outside the scope of this document to present a general 480 solution to the ARP security problem. One simple answer is to add a 481 TLV that contains a digital signature of the contents of the ARP 482 message. This TLV would be defined for use only in L-ARP messages, 483 although in principle, other ARP messages could use it as well. Such 484 an approach would, of course, need a review and approval by the 485 Security Directorate. If approved, the type of this TLV and its 486 procedures would be defined in this document. If some other 487 technique is suggested, the authors would be happy to include the 488 relevant text in this document, and refer to some other document for 489 the full solution. 491 11. IANA Considerations 493 IANA is requested to allocate a new ARP hardware type (from the 494 registry hrd) for HTYPE-MPLS. 496 IANA is also requested to create a new registry ARP-TLV ("tlv"). 497 This is a registry of one octet numbers. Allocation policies: 0 is 498 not to be allocated; the range 1-127 is Standards Action; the values 499 128-251 are FCFS; and the values 252-255 are Experimental. 501 Finally, IANA is requested to allocate two values in the ARP-TLV 502 registry, one for TLV-LST and another for TLV-ATT. 504 12. Acknowledgments 506 Many thanks to Shane Amante for his detailed comments and 507 suggestions. Many thanks to the team in Juniper prototyping this 508 work for their suggestions on making this variant workable in the 509 context of existing ARP implementations. Thanks too to Luyuan Fang, 510 Alex Semenyaka and Dmitry Afanasiev for their comments and 511 encouragement. 513 13. References 515 13.1. Normative References 517 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 518 Converting Network Protocol Addresses to 48.bit Ethernet 519 Address for Transmission on Ethernet Hardware", STD 37, 520 RFC 826, DOI 10.17487/RFC0826, November 1982, 521 . 523 [RFC2002] Perkins, C., Ed., "IP Mobility Support", RFC 2002, 524 DOI 10.17487/RFC2002, October 1996, 525 . 527 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 528 Requirement Levels", BCP 14, RFC 2119, 529 DOI 10.17487/RFC2119, March 1997, 530 . 532 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 533 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 534 RFC 6790, DOI 10.17487/RFC6790, November 2012, 535 . 537 13.2. Informative References 539 [I-D.ietf-mpls-seamless-mpls] 540 Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, 541 M., and D. Steinberg, "Seamless MPLS Architecture", draft- 542 ietf-mpls-seamless-mpls-07 (work in progress), June 2014. 544 Authors' Addresses 546 Kireeti Kompella 547 Juniper Networks 548 1194 N. Mathilda Avenue 549 Sunnyvale, CA 94089 550 USA 552 Email: kireeti.kompella@gmail.com 554 Balaji Rajagopalan 555 Juniper Networks, Inc. 556 Prestige Electra, Exora Business Park 557 Marathahalli - Sarjapur Outer Ring Road 558 Bangalore 560103 559 India 561 Email: balajir@juniper.net 562 George Swallow 563 Cisco Systems 564 1414 Massachusetts Ave 565 Boxborough, MA 01719 566 US 568 Email: swallow@cisco.com