idnits 2.17.1 draft-ietf-trill-arp-optimization-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 == Line 91 has weird spacing: '...enience along...' -- The document date (March 11, 2016) is 2967 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: 'RFC7357' is mentioned on line 304, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 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 Expires: September 12, 2016 March 11, 2016 10 TRILL: ARP/ND Optimization 11 draft-ietf-trill-arp-optimization-04 13 Abstract 15 This document describes mechanisms to optimize the ARP (Address 16 Resolution Protocol) and ND (Neighbor Discovery) traffic in TRILL 17 campus. Such optimization reduces packet flooding over a TRILL 18 campus. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/1id-abstracts.html 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 Copyright and License Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2 IP/MAC Address Mappings . . . . . . . . . . . . . . . . . . . . 4 61 3 Handling ARP/ND Messages . . . . . . . . . . . . . . . . . . . . 4 62 3.1 Get Sender's IP/MAC Mapping Information for Non-zero IP . . 5 63 3.2 Determine How to Reply to ARP/ND . . . . . . . . . . . . . . 5 64 3.3 Determine How to Handle the ARP/ND Response . . . . . . . . 7 65 4 Handling RARP (Reverse Address Resolution Protocol) Messages . . 7 66 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 7 67 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 68 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 69 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 8 71 8.2 Informative References . . . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 74 1 Introduction 76 ARP [RFC826] and ND [RFC4861] are normally sent by broadcast and 77 multicast respectively. To reduce the burden on a TRILL campus caused 78 by these multi-destination messages, RBridges MAY implement an 79 "optimized ARP/ND response", as specified herein, when the target's 80 location is known by the ingress RBridge or can be obtained from a 81 directory. This avoids ARP/ND query flooding. 83 1.1 Terminology 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 87 "OPTIONAL" in this document are to be interpreted as described in 88 [RFC2119]. 90 The acronyms and terminology in [RFC6325] are used herein. Some of 91 these are listed below for convenience along with some additions: 93 APPsub-TLV Application sub-Type-Length-Values 95 ARP Address Resolution Protocol [RFC826] 97 Campus A TRILL network consisting of RBridges, links, and 98 possibly bridges bounded by end stations and IP routers. 100 DAD Duplicate Address Detection 102 Data Label VLAN or FGL 104 ESADI End Station Address Distribution Information [RFC7357] 106 FGL Fine-Grained Label [RFC7172] 108 IA Interface Addresses, a TRILL APPsub-TLV [IA-draft] 110 IP Internet Protocol 112 MAC Media Access Control 114 ND Neighbor Discovery [RFC4861] 116 RBridge A contraction of "Routing Bridge". A device 117 implementing the TRILL protocol. 119 SEND secure neighbor discovery [RFC3971] 120 TRILL Transparent Interconnection of Lots of Links or 121 Tunneled Routing in the Link Layer. 123 2 IP/MAC Address Mappings 125 By default, an RBridge [RFC6325] [RFC7172] learns MAC Address and 126 Data Label (VLAN or FGL) to egress nickname mapping information from 127 TRILL data frames it receives. No IP address information is learned 128 directly from the TRILL data frame. Interface Addresses (IA) APPsub- 129 TLV [IA-draft] enhances the TRILL base protocol by allowing IP and 130 MAC address mappings to be distributed in the control plane by any 131 RBridge. This APPsub-TLV appears inside the TRILL GENINFO TLV in 132 ESADI [RFC7357] but the value data structure it specifies may also 133 occur in other application contexts. Edge Directory Assist Mechanisms 134 [DirMech] makes use of this APPsub-TLV for its push model and uses 135 the value data structure it specifies in its pull model. 137 An RBridge can easily know the IP/MAC address mappings of the local 138 end stations that it is attached to it via its access ports by 139 receiving ARP [RFC826] or ND [RFC4861] messages. If the RBridge has 140 extracted the sender's IP/MAC address pair from the received data 141 packet (either ARP or ND), it MAY save the information and use the IA 142 APPsub-TLV to distribute it to other RBridges through ESADI. Then the 143 relevant remote RBridges (normally those interested in the same Data 144 Label as the original ARP/ND messages) receive and save such mapping 145 information also. There are others ways that RBridges save IP/MAC 146 address mappings in advance, e.g. import from management system and 147 distribution by directory servers [DirMech]. 149 The examples given above show that RBridges might have saved an end 150 station's triplet of {IP address, MAC address, ingress nickname} for 151 a given Data Label (VLAN or FGL) before that end station sends or 152 receives any real data packet. Note such information might or might 153 not be a complete list and might or might not exist on all RBridges. 154 The information could possibly be from different sources. RBridges 155 can then use the Flags Field in IA APPsub-TLV to identify if the 156 source is a directory server or local observation by the sender. A 157 different confidence level MAY also be used to indicate the 158 reliability of the mapping information. 160 3 Handling ARP/ND Messages 162 A native frame that is an ARP [RFC826] message is detected by its 163 Ethertype of 0x0806. A native frame that is an ND [RFC4861] is 164 detected by being one of five different ICMPv6 packet types. ARP/ND 165 is commonly used on a link to (1) query for the MAC address 166 corresponding to an IPv4 or IPv6 address, (2) test if an IPv4/IPv6 167 address is already in use, or (3) to announce the new or updated info 168 on any of IPv4/IPv6 address, MAC address, and/or point of attachment. 170 To simplify the text, we use the following terms in this section. 172 1) IP address - indicated protocol address that is normally an IPv4 173 address in ARP or an IPv6 address in ND. 175 2) sender's IP/MAC address - sender IP/MAC address in ARP, source 176 IP address and source link-layer address in ND 178 3) target's IP/MAC address - target IP/MAC address in ARP, target 179 address and target link-layer address in ND 181 When an ingress RBridge receives an ARP/ND message, it can perform 182 the steps described in the sub-sections below. 184 3.1 Get Sender's IP/MAC Mapping Information for Non-zero IP 186 o If the sender's IP has not been saved by the ingress RBridge 187 before, populate the information of sender's IP/MAC in its ARP table; 189 o else if the sender's IP has been saved before but with a 190 different MAC address mapped or a different ingress nickname 191 associated with the same pair of IP/MAC, the RBridge SHOULD verify if 192 a duplicate IP address has already been in use or an end station has 193 changed its attaching RBridge. The RBridge MAY use different 194 strategies to do so. For example, the RBridge might ask an 195 authoritative entity like directory servers or it might encapsulate 196 and unicast the ARP/ND message to the location where it believes the 197 address is in use. RBridge SHOULD update the saved triplet of {IP 198 address, MAC address, ingress nickname} based on the verification. 200 The ingress RBridge MAY use the IA APPsub-TLV [IA-draft] with the 201 Local flag set in ESADI [RFC7357] to distribute any new or updated 202 triplet of {IP address, MAC address, ingress nickname} information 203 obtained in this step. If a push directory server is used, such 204 information can be distributed as per [DirMech]. 206 3.2 Determine How to Reply to ARP/ND 208 a) If the message is a generic ARP/ND request and the ingress RBridge 209 knows the target's IP address, the ingress RBridge MAY take one or a 210 combination of the following actions: 212 a.1. Send an ARP/ND response directly to the querier, with the 213 target's MAC address, as known by the ingress RBridge. 215 a.2. Encapsulate the ARP/ND request to the target's Designated 216 RBridge, and have the egress RBridge for the target forward the 217 query to the target. This behavior has the advantage that a 218 response to the request is authoritative. If the request does not 219 reach the target, then the querier does not get a response. 221 a.3. Block ARP/ND requests that occur for some time after a request 222 to the same target has been launched, and then respond to the 223 querier when the response to the recently-launched query to that 224 target is received. 226 a.4. Pull the most up-to-date records if a pull directory server is 227 available [DirMech] and reply to the querier. 229 a.5. Flood the request as per [RFC6325]. 231 b) If the message is a generic ARP request and the ingress RBridge 232 does not know target's IP address, the ingress RBridge MAY take one 233 of the following actions. 235 b.1. Flood the message as per [RFC6325]. 237 b.2. Use directory server to pull the information [DirMech] and 238 reply to the querier. 240 b.3. Drop the message. 242 c) If the message is a gratuitous ARP which can be identified by the 243 same sender's and target's "protocol" address fields or an 244 Unsolicited Neighbor Advertisements [RFC4861] in ND: 246 The RBridge MAY use an IA APPsub-TLV [IA-draft] with the Local flag 247 set to distribute the sender's MAC and IP mapping information. When 248 one or more directory servers are deployed and complete Push 249 Directory information is used by all the RBridges in the Data Label, 250 a gratuitous ARP or unsolicited NA SHOULD be discarded rather than 251 ingressed. Otherwise, they are either ingressed and flooded as per 252 [RFC6325] or discarded depending on local policy. 254 d) If the message is a Address Probe ARP Query [RFC5227] which can be 255 identified by the sender's protocol (IPv4) address field being zero 256 and the target's protocol address field being the IPv4 address to be 257 tested or a Neighbor Solicitation for DAD (Duplicate Address 258 Detection) which has the unspecified source address [RFC4862]: it 259 SHOULD be handled as the generic ARP message as in a) and b). 261 Note that in the case of secure neighbor discovery (SEND) [RFC3971], 262 cryptography would prevent local reply by the ingress RBridge, since 263 the RBridge would not be able to sign the response with the target's 264 private key. 266 It is not essential that all RBridges use the same strategy for which 267 option to select for a particular ARP/ND query. It is up to the 268 implementation. 270 3.3 Determine How to Handle the ARP/ND Response 272 If the ingress RBridge R1 decides to unicast the ARP/ND request to 273 the target's egress RBridge R2 as discussed in subsection 3.2 item a) 274 or to flood the request as per [RFC6325], then R2 decapsulates the 275 query, and initiates an ARP/ND query on the target's link. When/if 276 the target responds, R2 encapsulates and unicasts the response to R1, 277 which decapsulates the response and sends it to the querier. R2 278 SHOULD initiate a link state update to inform all the other RBridges 279 of the target's location, layer 3 address, and layer 2 address, in 280 addition to forwarding the reply to the querier. The update message 281 can be carried by an IA APPsub-TLV [IA-draft] with the Local flag set 282 in ESADI [RFC7357] or as per [DirMech] if push directory server is in 283 use. 285 4 Handling RARP (Reverse Address Resolution Protocol) Messages 287 RARP [RFC903] uses the same packet format as ARP but a different 288 Ethertype (0x8035) and opcode values. Its use is similar to the 289 generic ARP Request/Response as described in 3.2 a) and b). The 290 difference is that it is intended to query for the target "protocol" 291 (IP) address corresponding to the target "hardware" (MAC) address 292 provided. It SHOULD be handled by doing a local cache or directory 293 server lookup on the target "hardware" address provided to find a 294 mapping to the desired "protocol" address. Normally, it is used to 295 look up a MAC address to find the corresponding IP address. 297 5 Security Considerations 299 ARP and ND messages can be easily forged. Therefore the learning of 300 MAC/IP addresses from them should not be considered as reliable. 301 RBridge can use the confidence level in IA APPsub-TLV information 302 received via ESADI or pull directory retrievals to determine the 303 reliability of MAC/IP address mapping. ESADI information can be 304 secured as provide in [RFC7357] and pull directory information can be 305 secured as provide in [DirMech]. The implementation decides if an 306 RBridge will distribute the IP and MAC address mappings received from 307 local native ARP/ND messages to other RBridges in the same Data 308 Label. 310 The ingress RBridge SHOULD also rate limit the ARP/ND queries for the 311 same target to be injected into the TRILL campus to prevent possible 312 denial of service attacks. 314 6 IANA Considerations 316 No IANA action is required. RFC Editor: please delete this section 317 before publication. 319 7 Acknowledgments 321 The authors would like to thank Igor Gashinsky for his contributions. 323 8 References 325 8.1 Normative References 327 [RFC826] Plummer, D., "An Ethernet Address Resolution Protocol", RFC 328 826, November 1982. 330 [RFC903] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A 331 Reverse Address Resolution Protocol", STD 38, RFC 903, 332 June 1984 334 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 335 Requirement Levels", BCP 14, RFC 2119, March 1997. 337 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 338 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 339 September 2007. 341 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 342 Address Autoconfiguration", RFC 4862, September 2007. 344 [RFC6325] Perlman, R., et.al. "RBridge: Base Protocol 345 Specification", RFC 6325, July 2011. 347 [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and 348 D. Dutt, "Transparent Interconnection of Lots of Links 349 (TRILL): Fine-Grained Labeling", RFC 7172, May 2014, 350 . 352 8.2 Informative References 354 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 355 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 357 [RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, 358 July 2008. 360 [IA-draft] Eastlake, D., Li Y., R. Perlman, "TRILL: Interface 361 Addresses APPsub-TLV", draft-ietf-trill-ia-appsubtlv, work 362 in progress. 364 [DirMech] Dunbar, L., Eastlake 3rd, D., Perlman, R., I. Gashinsky. 365 and Li Y., TRILL: Edge Directory Assist Mechanisms", 366 draft-ietf-trill-directory-assist-mechanisms, work in 367 progress. 369 Authors' Addresses 371 Yizhou Li 372 Huawei Technologies 373 101 Software Avenue, 374 Nanjing 210012 375 China 377 Phone: +86-25-56625375 378 EMail: liyizhou@huawei.com 380 Donald Eastlake 381 Huawei R&D USA 382 155 Beaver Street 383 Milford, MA 01757 USA 385 Phone: +1-508-333-2270 386 EMail: d3e3e3@gmail.com 388 Linda Dunbar 389 Huawei Technologies 390 5430 Legacy Drive, Suite #175 391 Plano, TX 75024, USA 393 Phone: +1-469-277-5840 394 EMail: ldunbar@huawei.com 395 Radia Perlman 396 EMC 397 2010 256th Avenue NE, #200 398 Bellevue, WA 98007 399 USA 401 EMail: Radia@alum.mit.edu