idnits 2.17.00 (12 Aug 2021) /tmp/idnits5810/draft-ietf-trill-arp-optimization-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 == Line 107 has weird spacing: '...enience along...' -- The document date (October 9, 2017) is 1678 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: 'IA-draft' is mentioned on line 427, but not defined == Unused Reference: 'RFC7356' is defined on line 648, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRILL Working Group Y. Li 3 INTERNET-DRAFT D. Eastlake 4 Intended Status: Standard Track L. Dunbar 5 Huawei Technologies 6 R. Perlman 7 EMC 8 M. Umair 9 Cisco 10 Expires: April 12, 2017 October 9, 2017 12 TRILL: ARP/ND Optimization 13 draft-ietf-trill-arp-optimization-09 15 Abstract 17 This document describes mechanisms to optimize the ARP (Address 18 Resolution Protocol) and ND (Neighbor Discovery) traffic in a TRILL 19 campus. TRILL switches maintain a cache of IP/MAC address/Data Label 20 bindings that are learned from ARP/ND requests and responses that 21 pass through them. In many cases, this cache allows an edge RBridge 22 to avoid flooding an ARP/ND request by either responding to it 23 directly or by encapsulating it and unicasting it. Such optimization 24 reduces packet flooding over a TRILL campus. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as 34 Internet-Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/1id-abstracts.html 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html 47 Copyright and License Notice 49 Copyright (c) 2017 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 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2 ARP/ND Optimization Requirement and Solution . . . . . . . . . . 4 67 3 IP/MAC Address Mappings . . . . . . . . . . . . . . . . . . . . 5 68 4 Handling ARP/ND/SEND Messages . . . . . . . . . . . . . . . . . 5 69 4.1 SEND Considerations . . . . . . . . . . . . . . . . . . . . 6 70 4.2 Address Verification . . . . . . . . . . . . . . . . . . . . 7 71 4.3 Extracting Local End Station IP/MAC Mapping Information . . 7 72 4.4 Determine How to Reply to ARP/ND . . . . . . . . . . . . . . 8 73 4.5 Determine How to Handle the ARP/ND Response . . . . . . . . 10 74 5 Handling of RARP (Reverse Address Resolution Protocol) 75 Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 6 Handling of DHCP messages . . . . . . . . . . . . . . . . . . . 10 77 7 Handling of Duplicate IP Addresses . . . . . . . . . . . . . . . 10 78 8 RBridge ARP/ND Cache Liveness and MAC Mobility . . . . . . . . . 11 79 9 Security Considerations . . . . . . . . . . . . . . . . . . . . 12 80 9.1 Data Plane Based Considerations . . . . . . . . . . . . . . 12 81 9.2 Directory Based Considerations . . . . . . . . . . . . . . . 13 82 9.3 Use of the Confidence Level Feature . . . . . . . . . . . . 13 83 10 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 13 84 11 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 14 85 12 References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 12.1 Normative References . . . . . . . . . . . . . . . . . . . 14 87 12.2 Informative References . . . . . . . . . . . . . . . . . . 15 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 90 1 Introduction 92 ARP [RFC826] and ND [RFC4861] are normally sent by broadcast and 93 multicast respectively. To reduce the burden on a TRILL campus caused 94 by these multi-destination messages, RBridges MAY implement an 95 "optimized ARP/ND response", as specified herein, when the target's 96 location is known by the ingress RBridge or can be obtained from a 97 directory. This avoids ARP/ND query and answer flooding. 99 1.1 Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in 104 [RFC2119]. 106 The acronyms and terminology in [RFC6325] are used herein. Some of 107 these are listed below for convenience along with some additions: 109 APPsub-TLV Application sub-Type-Length-Value [RFC6823] 111 ARP Address Resolution Protocol [RFC826] 113 Campus A TRILL network consisting of RBridges, links, and 114 possibly bridges bounded by end stations and IP routers [RFC6325] 116 DAD Duplicate Address Detection 118 Data Label VLAN or FGL 120 DHCP In this document refers to both DHCP for IPv4 121 [RFC2131] and DHCPv6 [RFC3315] 123 ESADI End Station Address Distribution Information [RFC7357] 125 FGL Fine-Grained Label [RFC7172] 127 IA Interface Addresses, a TRILL APPsub-TLV [RFC7961] 129 IP Internet Protocol, both IPv4 and IPv6 131 MAC Media Access Control [RFC7042] 133 ND Neighbor Discovery [RFC4861] 135 RBridge A contraction of "Routing Bridge". A device 136 implementing the TRILL protocol. 138 SEND secure neighbor discovery [RFC3971] 140 TRILL Transparent Interconnection of Lots of Links or 141 Tunneled Routing in the Link Layer [RFC6325] [RFC7780] 143 2 ARP/ND Optimization Requirement and Solution 145 IP address resolution can create significant issues in data centers 146 due to flooded packets as discussed in [RFC6820]. Such flooding can 147 be avoided by a proxy ARP/ND function on edge RBridges as described 148 in this document. This section is a general discussion of this 149 problem and is not intended to be normative. 151 To support such ARP/ND optimization, edge RBridges need to know end- 152 station's IP to MAC mapping through manual configuration 153 (management), through control plane mechanisms such as directories 154 [RFC8171], or through Data plane learning by snooping of messages 155 such as ARP/ND (including DHCP or gratuitous ARP messages). 157 When all the end-stations IP/MAC address mapping is known to edge 158 RBridges or provisioned through management or learnt via control 159 plane on the edge RBridges, it should be possible to completely 160 suppress flooding of ARP/ND messages in a TRILL Campus, When all end- 161 station MAC addresses are similarly known, it should be possible to 162 suppress unknown unicast flooding by dropping any unknown unicast 163 received at an edge RBridge. 165 An ARP/ND optimization mechanism should include provisions for an 166 edge RBridge to issue an ARP/ND request to an attached end station to 167 confirm or update information and should allow an end station to 168 detect detect duplication of its IP address. 170 Most of the end station hosts either send DHCP messages requesting an 171 IP Address or send out gratuitous ARP or RARP requests to announce 172 themselves to the network right after they come online. Thus the 173 local edge RBridge will immediately have the opportunity to snoop and 174 learn their MAC and IP addresses and distribute this information to 175 other edge RBridges through the TRILL control plane ESADI [RFC7357] 176 protocol. Once remote RBridges received this information via the 177 control plane they should add IP to MAC mapping information to their 178 ARP/ND cache along with the nickname and data label of the address 179 information. Therefore, most active IP hosts in TRILL network can be 180 learned by the edge RBridges either through local learning or 181 control-plane-based remote learning. As a result, ARP suppression can 182 vastly reduce the network flooding caused by host ARP learning 183 behavior. 185 When complete directory information is available, the default data 186 plane learning of MAC addresses of end station is not only 187 unnecessary but could be harmful if there is learning based on frames 188 with forged source addresses. Such data plane learning can be 189 suppressed because TRILL already provides an option to disable data- 190 plane learning from the source MAC address of end-station frames (see 191 Section 5.3 of [RFC6325]). 193 3 IP/MAC Address Mappings 195 By default, an RBridge [RFC6325] [RFC7172] learns MAC Address and 196 Data Label (VLAN or FGL) to egress nickname mapping information from 197 TRILL data frames it receives. No IP address information is learned 198 directly from the TRILL data frame. The Interface Addresses (IA) 199 APPsub-TLV [RFC7961] enhances the TRILL base protocol by allowing IP 200 and MAC address mappings to be distributed in the control plane by 201 any RBridge. This APPsub-TLV appears inside the TRILL GENINFO TLV in 202 ESADI [RFC7357] but the value data structure it specifies may also 203 occur in other application contexts. Edge RBridge Directory Assist 204 Mechanisms [RFC8171] makes use of this APPsub-TLV for its push model 205 and uses the value data structure it specifies in its pull model. 207 An RBridge can easily know the IP/MAC address mappings of the local 208 end stations that it is attached to it via its access ports by 209 receiving ARP [RFC826] or ND [RFC4861] messages. If the edge RBridge 210 has extracted the sender's IP/MAC address pair from the received data 211 frame (either ARP or ND), it may save the information and then use 212 the IA APPsub-TLV to link the IP and MAC addresses and distribute it 213 to other RBridges through ESADI. Then the relevant remote RBridges 214 (normally those interested in the same Data Label as the original 215 ARP/ND messages) also receive and save such mapping information. 216 There are others ways that RBridges save IP/MAC address mappings in 217 advance, e.g. import from management system and distribution by 218 directory servers [RFC8171]. 220 The examples given above show that RBridges might have saved an end 221 station's triplet of {IP address, MAC address, ingress nickname} for 222 a given Data Label (VLAN or FGL) before that end station sends or 223 receives any real data packet. Note such information might or might 224 not be a complete list and might or might not exist on all RBridges. 225 The information could possibly be from different sources. RBridges 226 can then use the Flags Field in IA APPsub-TLV to identify if the 227 source is a directory server or local observation by the sender. A 228 different confidence level may also be used to indicate the 229 reliability of the mapping information. 231 4 Handling ARP/ND/SEND Messages 232 A native frame that is an ARP [RFC826] message is detected by its 233 Ethertype of 0x0806. A native frame that is an ND [RFC4861] is 234 detected by being one of five different ICMPv6 packet types. ARP/ND 235 is commonly used on a link to (1) query for the MAC address 236 corresponding to an IPv4 or IPv6 address, (2) test if an IPv4/IPv6 237 address is already in use, or (3) to announce the new or updated info 238 on any of IPv4/IPv6 address, MAC address, and/or point of attachment. 240 To simplify the text, we use the following terms in this section. 242 1) IP address - indicated protocol address that is normally an IPv4 243 address in ARP or an IPv6 address in ND. 245 2) sender's IP/MAC address - sender IP/MAC address in ARP, source 246 IP address and source link-layer address in ND 248 3) target's IP/MAC address - target IP/MAC address in ARP, target 249 address and target link-layer address in ND 251 When an ingress RBridge receives an ARP/ND/SEND message, it can 252 perform the steps described within the sub-sections below. In 253 particular, Section 4.4 describes the options for such an ingress 254 handling an ARP/ND message and, in the cases where it forwards the 255 message, Section 4.5 describes how to handle any response that may be 256 returned due to the forwarded message. 258 Section 4.3 describes the extraction of address information by an 259 RBridge from ARP/ND messages it handles. Under some circumstances, 260 this extraction may prompt verification with an end station. Section 261 4.2 describes an optional use of ARP/ND messages originated by 262 RBridges to verify addresses or liveness. 264 As described in Section 4.1, SEND messages are not optimized by the 265 mechanisms specified in this document but are snooped on. 267 4.1 SEND Considerations 269 SEND (Secure Neighbor Discovery [RFC3971] is a method of securing ND 270 that addresses the threats discussed in [RFC3756]. Typical TRILL 271 campuses are inside data centers, Internet exchange points, or 272 carrier facilities. These are generally controlled and protected 273 environments where these threats are of less concern. Nevertheless, 274 SEND provides an additional layer of protection. 276 Secure SEND messages require knowledge of cryptographic keys. Methods 277 of communicating such keys to RBridges for use in SEND are beyond the 278 scope of this document. Thus, using the optimizations in this 279 document, RBridges do not attempt to construct SEND messages and are 280 generally transparent to them. RBridges only construct ARP, RARP, or 281 insecure ND messages, as appropriate. Nevertheless, RBridges 282 implementing ARP/ND optimization SHOULD snoop on SEND messages to 283 extract the addressing information that would be present if the SEND 284 had been sent as an insecure ND message and is still present in the 285 SEND message. 287 4.2 Address Verification 289 RBridges may use ARP/ND to probe directly attached or remote end 290 stations for address or liveness verification. This is typically most 291 appropriate in less managed and/or higher mobility environments. In 292 strongly managed environments, such as a typical data center, where a 293 central orchestration/directory system has complete addressing 294 knowledge [RFC7067], optimized ARP/ND responses can use that 295 knowledge. In such cases, there is little reason for verification 296 except for debugging operational problems or the like. 298 4.3 Extracting Local End Station IP/MAC Mapping Information 300 Edge RBridges extract and use information about the correspondence 301 between local end station IP and MAC addresses from the ARP/ND 302 messages those end stations send as described below. An apparent zero 303 source IP address means that the end station is probing for duplicate 304 IP addresses and messages with such a zero source IP address are not 305 used for the extraction of IP/MAC address mapping information. 307 o If the sender's IP is not present in the ingress RBridge's ARP/ND 308 cache, populate the information of sender's IP/MAC in its ARP/ND 309 cache table. The ingress RBridge correlates its nickname and that 310 IP/MAC mapping information. Such triplet of {IP address, MAC address, 311 ingress nickname} information is saved locally and can be distributed 312 to other RBridges as explain later. 314 o Else if the sender's IP has been saved before but with a 315 different MAC address mapped or a different ingress nickname 316 associated with the same pair of IP/MAC, the RBridge SHOULD verify if 317 a duplicate IP address has already been in use or an end station has 318 changed its attaching RBridge. The RBridge may use different 319 strategies to do so. For example, the RBridge might ask an 320 authoritative entity like directory servers or it might encapsulate 321 and unicast the ARP/ND message to the location where it believes the 322 address is in use (Section 4.2). RBridge SHOULD update the saved 323 triplet of {IP address, MAC address, ingress nickname} based on the 324 verification results. An RBridge might not verify an IP address if 325 the network manager's policy is to have the network behave, for each 326 Data Label, as if it were a single link and just believe an ARP/ND it 327 receives. 329 The ingress RBridge MAY use the IA APPsub-TLV [RFC7961] with the 330 Local flag set in ESADI [RFC7357] to distribute any new or updated 331 triplet of {IP address, MAC address, ingress nickname} information 332 obtained. If a push directory server is used, such information can be 333 distributed as specified in [RFC8171]. 335 4.4 Determine How to Reply to ARP/ND 337 The options for an edge RBridge to handle a native ARP/ND are given 338 below. For generic ARP/ND request seeking the MAC address 339 corresponding to an IP address, if the edge RBridge knows the IP 340 address and corresponding MAC, behavior is as in item (a), otherwise 341 behavior is as in item (b). Behavior for gratuitous ARP and ND 342 Unsolicited Neighbor Advertisements [RFC4861] is given in item (c). 343 And item (d) covers handling of Address Probe ARP Query. Within each 344 lettered item, it is an implementation decision which numbered 345 strategy to use for any particular ARP/ND query falling under that 346 item. 348 a) If the message is a generic ARP/ND request and the ingress RBridge 349 knows the target's IP address and associated MAC address, the ingress 350 RBridge MUST take one or a combination of the actions below. In the 351 case of secure neighbor discovery (SEND) [RFC3971], cryptography 352 would prevent local reply by the ingress RBridge, since the RBridge 353 would not be able to sign the response with the target's private key, 354 and only action a.2 or a.5 is valid. 356 a.1. Send an ARP/ND response directly to the querier, using the 357 target's MAC address present in the ingress RBridge's ARP/ND cache 358 table. Because the edge RBridge might not have an IPv6 address, the 359 source IP address for such an ND response MUST be that of the 360 target end station. 362 a.2. Encapsulate the ARP/ND/SEND request to the target's Designated 363 RBridge, and have the egress RBridge for the target forward the 364 query to the target. This behavior has the advantage that a 365 response to the request is authoritative. If the request does not 366 reach the target, then the querier does not get a response. 368 a.3. Block ARP/ND requests that occur for some time after a request 369 to the same target has been launched, and then respond to the 370 querier when the response to the recently-launched query to that 371 target is received. 373 a.4 Reply to the querier based on directory information [RFC8171] 374 such as information obtained from a pull directory server or 375 directory information that the ingress RBridge has requested to be 376 pushed to it. 378 a.5. Flood the ARP/ND/SEND request as per [RFC6325]. 380 (b) If the message is a generic ARP/ND/SEND request and the ingress 381 RBridge does not know target's IP address, the ingress RBridge MUST 382 take one of the following actions. In the case of secure neighbor 383 discovery (SEND) [RFC3971], cryptography would prevent local reply by 384 the ingress RBridge, since the RBridge would not be able to sign the 385 response with the target's private key therefore only action b.1 is 386 valid. 388 b.1. Flood the ARP/ND/SEND message as per [RFC6325]. 390 b.2. Use directory server to pull the information [RFC8171] and 391 reply to the querier. 393 b.3. Drop the message if there should be no response because the 394 directory server gives authoritative information that the address 395 being queried is non-existent. 397 (c) If the message is a gratuitous ARP, which can be identified by 398 the same sender's and target's "protocol" address fields, or an 399 Unsolicited Neighbor Advertisements [RFC4861] in ND/SEND: 401 The RBridge MAY use an IA APPsub-TLV [RFC7961] with the Local flag 402 set to distribute the sender's MAC and IP mapping information. When 403 one or more directory servers are deployed and complete Push 404 Directory information is used by all the RBridges in the Data Label, 405 a gratuitous ARP or unsolicited NA SHOULD be discarded rather than 406 ingressed. Otherwise, they are either ingressed and flooded as per 407 [RFC6325] or discarded depending on local policy. 409 (d) If the message is a Address Probe ARP Query [RFC5227] which can 410 be identified by the sender's protocol (IPv4) address field being 411 zero and the target's protocol address field being the IPv4 address 412 to be tested or a Neighbor Solicitation for DAD (Duplicate Address 413 Detection) which has the unspecified source address [RFC4862]: it 414 SHOULD be handled as the generic ARP message as in (a) or (b) above. 416 4.5 Determine How to Handle the ARP/ND Response 418 If the ingress RBridge R1 decides to unicast the ARP/ND request to 419 the target's egress RBridge R2 as discussed in subsection 3.2 item 420 a.2 or to flood the request as per [RFC6325] and item a.5, then R2 421 decapsulates the query, and initiates an ARP/ND query on the target's 422 link. If and when the target responds, R2 encapsulates and unicasts 423 the response to R1, which decapsulates the response and sends it to 424 the querier. R2 SHOULD initiate a link state update to inform all the 425 other RBridges of the target's location, layer 3 address, and layer 2 426 address, in addition to forwarding the reply to the querier. The 427 update uses an IA APPsub-TLV [IA-draft] (so the layer 3 and layer 2 428 addresses can be linked) with the Local flag set in ESADI [RFC7357] 429 or as per [RFC8171] if push directory server is in use. 431 5 Handling of RARP (Reverse Address Resolution Protocol) Messages 433 RARP [RFC903] uses the same packet format as ARP but a different 434 Ethertype (0x8035) and opcode values. Its processing is similar to 435 the generic ARP Request/Response as described in 3.2 a) and b). The 436 difference is that it is intended to query for the target "protocol" 437 (IP) address corresponding to the target "hardware" (MAC) address 438 provided. It SHOULD be handled by doing a local cache or directory 439 server lookup on the target "hardware" address provided to find a 440 mapping to the desired "protocol" address. 442 6 Handling of DHCP messages 444 When a newly connected end-station exchanges messages with a DHCP 445 [RFC3315][RFC2131] server an edge RBridge should snoop them (mainly 446 the DHCPAck message) and store IP/MAC mapping information in its 447 ARP/ND cache and should also send the information out through the 448 TRILL control plane using ESADI. 450 7 Handling of Duplicate IP Addresses 452 Duplicate IP addresses within a Data Label can occur due to an 453 attacker sending fake ARP/ND messages or due to human/configuration 454 errors. If complete directory information is available, then by 455 definition the IP location information in the directory is correct. 456 Any appearance of an IP address in a different place (different edge 457 RBridge or port) from other sources is not correct. 459 Without complete directory information, the ARP/ND optimization 460 function should support duplicate IP detection. This is critical in a 461 Data Center to stop an attacker from using ARP/ND spoofing to divert 462 traffic from its intended destination. 464 Duplicate IP addresses can be detected when an existing active IP/MAC 465 mapping gets modified. Also an edge RBridge may send a query called a 466 DAD-query (Duplicate Address Detection query) asking about the IP 467 address in question to the former owner of that IP address by using 468 the MAC address formerly associated with that IP address. A DAD-query 469 is a unicast ARP/ND message with sender IP 0.0.0.0 in case of ARP (or 470 a configurable IP address per RBridge called the DAD-Query source IP) 471 and an IPv6 Link Local Address in case of ND with source MAC set to 472 the DAD-querier RBridge's MAC. If the querying RBridge does not 473 receive an answer within a given time, it may be a case of mobility 474 and in any case the new IP entry will be confirmed and activated in 475 its ARP/ND cache. 477 In the case where the former owner replies, a Duplicate Address has 478 been detected. In this case the querying RBridge SHOULD log the 479 duplicate so that the network administrator can take appropriate 480 action. 482 It is an implementation choice how to respond to a query for an 483 address that is duplicated in the network when authoritative 484 information is not available from a directory or configuration. 485 Typically the information most recently snooped is returned. 487 8 RBridge ARP/ND Cache Liveness and MAC Mobility 489 A maintenance procedure is needed for RBridge ARP/ND caching to 490 ensure IP end-stations connected to ingress RBridges are still 491 active. 493 Some links provide a physical layer indication of link liveness. A 494 dynamic proxy-ARP/ND entry (one learned from data plane observation) 495 MUST be removed from the table if the link over which it was learned 496 fails. 498 Similarly a dynamic proxy-ARP/ND entry SHOULD be flushed out of the 499 table if the IP/MAC mapping has not been refreshed within a given 500 age-time. The entry is refreshed if an ARP or ND message is received 501 for the same IP/MAC mapping entry from any location. The IP/MAC 502 mapping information ageing timer is configurable per RBridge and 503 defaults to 3/4 of the MAC address learning Ageing Timer [RFC6325]. 505 For example end-Station "A" is connected to edge-RBridge1 (RB1) and 506 has been learnt as local entry on RB1. If end-Station "A" moves to 507 some other location (MAC/VM Mobility) and gets connected to edge- 508 RBridge2 (RB2), after learning on RB2's access port, RB2 advertise 509 this entry through the TRILL control-plane and it gets learnt on RB1 510 as a remote entry. The old entry on RB1 SHOULD get replaced and all 511 other edge-RBridges with end-station service enabled for that data- 512 label should update the entry to show reachability from RB2 instead 513 of RB1. 515 If an ARP/ND entry in the cache is not refreshed, then the RBridge 516 connected to that end-station MAY send periodic refresh messages 517 (ARP/ND "probes") to that end-station, so that the entries can be 518 refreshed before they age out. The end-station would reply to the 519 ARP/ND probe and the reply resets the corresponding entry age-timer. 521 9 Security Considerations 523 There are generally two modes of learning the address information 524 that is the basis of ARP/ND optimization: data plane mode and 525 directory mode. The data plane mode is the traditional bridge address 526 learning [802.1Q] that is also implemented in TRILL switches 527 [RFC6325] and is discussed in Section 9.1. The directory mode uses 528 data obtained from a directory [RFC8171] and is discussed in Section 529 9.2. The TRILL confidence level feature, which can help arbitrate 530 between conflicting address information, is discussed in Section 9.3. 532 RBridges should rate limit of ARP/ND queries injected into the TRILL 533 campus to limit some potential denial of service attacks. 535 9.1 Data Plane Based Considerations 537 Generally speaking, when ARP/ND optimization is operating in the data 538 plane mode, the information learned by RBridges is the same as that 539 which is learned by end stations. Thus the answers generated by 540 RBridges to the query messages being optimized are generally those 541 that would be generated by end stations in the absence of 542 optimization and the security considerations are those of the 543 underlying ARP/ND protocols. 545 RBridges that snoop on DHCPack messages respond to ARP/ND messages in 546 essentially the same way that the end stations sending those DHCPack 547 messages would. Thus, for Security Considerations of ARP/ND 548 optimization for DHCP messages that may be snooped, see the Security 549 Considerations sections of [RFC3315] and [RFC2131]. 551 Unless Secure ND (SEND [RFC3971]) is used, ARP and ND messages can be 552 easily forged. Therefore the learning of MAC/IP addresses by RBridges 553 from ARP/ND is hackable but is what is available for data plane 554 learning without SEND. See Section 4.1 for SEND Considerations. 556 Since end stations communicate with edge RBridges using Ethernet, 557 some security improvement could be obtained by the use of [802.1AE] 558 between end stations and edge RBridges. Such link security would 559 impose requirements on edge stations, while TRILL is generally 560 designed to operate with unmodified, TRILL-ignorant end stations, and 561 is beyond the scope of this document 563 ARP/ND address mapping information learned locally at an RBridge can 564 be distributed to other RBridges using the TRILL ESADI protocol that 565 can be secured as specified in [RFC7357]. (ESADI is also used for 566 push directories with flags in the data indicating whether data come 567 from a directory or from data plane learning, as well as a confidence 568 level (see Section 9.3).) 570 9.2 Directory Based Considerations 572 ARP/ND optimization can be based on directory information [RFC8171]. 573 If the directory information is know to be trustworthy and complete, 574 then trustworthy responses to ARP/ND queries can be entirely based on 575 this information. This bounds the damage that forged ARP/ND messages 576 can do to the local link between end stations and edge RBridges. (In 577 TRILL, such a "link" can be a bridged LAN.) 579 Of course, there can also be incomplete and/or un-reliable directory 580 address mapping data. The network administrator can configure their 581 TRILL campus to use such directory data in place of data plane 582 learned data. Alternatively, such directory data can be used along 583 with data plane learned arbitrated by confidence level as discussed 584 in Section 9.3. 586 9.3 Use of the Confidence Level Feature 588 An RBridge can use the confidence level in IA APPsub-TLV information 589 received via ESADI or pull directory retrievals to determine the 590 configured relative reliability of MAC/IP address mapping information 591 from those sources and from locally learned address information. 592 ESADI / push directory information can be secured as provided in 593 [RFC7357] and pull directory information can be secured as provided 594 in [RFC8171]. The implementation decides if an RBridge will 595 distribute the IP and MAC address mappings received from local native 596 ARP/ND messages to other RBridges in the same Data Label, and with 597 what confidence level it does so. Thus the implementer can, to some 598 extent, cause sources that they know are more reliable to dominate 599 those they know to be less reliable. How the implementer determines 600 this is beyond the scope of this document. 602 10 IANA Considerations 604 No IANA action is required. RFC Editor: please delete this section 605 before publication. 607 11 Acknowledgments 609 The authors would like to thank Igor Gashinsky and Sue Hares for 610 their contributions. 612 12 References 614 12.1 Normative References 616 [RFC826] Plummer, D., "An Ethernet Address Resolution Protocol", RFC 617 826, November 1982. 619 [RFC903] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A 620 Reverse Address Resolution Protocol", STD 38, RFC 903, 621 June 1984 623 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 624 Requirement Levels", BCP 14, RFC 2119, March 1997. 626 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 627 RFC 2131, March 1997. 629 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 630 C., and M. Carney, "Dynamic Host Configuration Protocol 631 for IPv6 (DHCPv6)", RFC 3315, July 2003. 633 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 634 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 635 September 2007. 637 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 638 Address Autoconfiguration", RFC 4862, September 2007. 640 [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 641 Ghanwani, "Routing Bridges (RBridges): Base Protocol 642 Specification", RFC 6325, July 2011. 644 [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and 645 D. Dutt, "Transparent Interconnection of Lots of Links 646 (TRILL): Fine-Grained Labeling", RFC 7172, May 2014. 648 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 649 Scope Link State PDUs (LSPs)", RFC 7356, September 2014. 651 [RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. 653 Stokes, "Transparent Interconnection of Lots of Links 654 (TRILL): End Station Address Distribution Information 655 (ESADI) Protocol", RFC 7357, September 2014. 657 [RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 658 Ghanwani, A., and S. Gupta, "Transparent Interconnection 659 of Lots of Links (TRILL): Clarifications, Corrections, and 660 Updates", RFC 7780, February 2016. 662 [RFC7961] Eastlake 3rd, D. and L. Yizhou, "Transparent 663 Interconnection of Lots of Links (TRILL): Interface 664 Addresses APPsub-TLV", RFC 7961, August 2016. 666 [RFC8171] Eastlake 3rd, D., Dunbar, L., Perlman, R., and Y. Li, 667 "Transparent Interconnection of Lots of Links (TRILL): 668 Edge Directory Assistance Mechanisms", RFC 8171, June 669 2017. 671 12.2 Informative References 673 [802.1AE] IEEE Std 802.1AE-2006, IEEE Standard for Local and 674 metropolitan networks / Media Access Control (MAC) 675 Security, 18 August 2006. 677 [802.1Q] IEE Std 8021Q-2014, IEEE Standard for Local and 678 metropolitan area networks / Bridges and Bridged Networks, 679 3 November 2014. 681 [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 682 Neighbor Discovery (ND) Trust Models and Threats", 683 RFC 3756, May 2004. 685 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 686 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 688 [RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, 689 July 2008. 691 [RFC6820] Narten, T., Karir, M., and I. Foo, "Address Resolution 692 Problems in Large Data Center Networks", RFC 6820, January 693 2013. 695 [RFC6823] Ginsberg, L., Previdi, S., and M. Shand, "Advertising 696 Generic Information in IS-IS", RFC 6823, December 2012. 698 [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and 699 IETF Protocol and Documentation Usage for IEEE 802 700 Parameters", BCP 141, RFC 7042, October 2013. 702 [RFC7067] Dunbar, L., Eastlake 3rd, D., Perlman, R., and I. 703 Gashinsky, "Directory Assistance Problem and High-Level 704 Design Proposal", RFC 7067, November 2013. 706 Authors' Addresses 708 Yizhou Li 709 Huawei Technologies 710 101 Software Avenue, 711 Nanjing 210012 712 China 714 Phone: +86-25-56625375 715 EMail: liyizhou@huawei.com 717 Donald Eastlake 718 Huawei R&D USA 719 155 Beaver Street 720 Milford, MA 01757 USA 722 Phone: +1-508-333-2270 723 EMail: d3e3e3@gmail.com 725 Linda Dunbar 726 Huawei Technologies 727 5430 Legacy Drive, Suite #175 728 Plano, TX 75024, USA 730 Phone: +1-469-277-5840 731 EMail: ldunbar@huawei.com 733 Radia Perlman 734 EMC 735 2010 256th Avenue NE, #200 736 Bellevue, WA 98007 737 USA 739 EMail: Radia@alum.mit.edu 741 Mohammed Umair 742 Cisco 743 Cessna Business Park, Kadubeesanahalli Village, Hobli, 744 Sarjapur, Varthur Main Road, Marathahalli, 745 Bengaluru, Karnataka 560087 India 747 Email: mohammed.umair2@gmail.com