idnits 2.17.1 draft-trill-trill-arp-optimization-00.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (April 2, 2015) is 3309 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 307, but not defined == Unused Reference: 'RFC2119' is defined on line 333, but no explicit reference was found in the text == Unused Reference: 'RFC6165' is defined on line 343, but no explicit reference was found in the text == Unused Reference: 'RFC6439' is defined on line 349, but no explicit reference was found in the text == Unused Reference: 'RFC7067' is defined on line 365, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6439 (Obsoleted by RFC 8139) Summary: 1 error (**), 0 flaws (~~), 7 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 I. Gashinsky 9 Yahoo 10 Expires: October 4, 2015 April 2, 2015 12 TRILL: ARP/ND Optimization 13 draft-trill-trill-arp-optimization-00 15 Abstract 17 This document describes mechanisms to optimize the ARP (Address 18 Resolution Protocol) and ND (Neighbor Discovery) traffic in TRILL 19 campus. Such optimization reduces packet flooding over a TRILL 20 campus. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as 30 Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 Copyright and License Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2 IP/MAC Address Mappings . . . . . . . . . . . . . . . . . . . . 4 63 3 Handling ARP/ND Messages . . . . . . . . . . . . . . . . . . . . 4 64 3.1 Get Sender's IP/MAC Mapping Information for Non-zero IP . . 5 65 3.2 Determine How to Reply to ARP/ND . . . . . . . . . . . . . . 5 66 3.3 Determine How to Handle the ARP/ND Response . . . . . . . . 7 67 4 Handling RARP (Reverse Address Resolution Protocol) Messages . . 7 68 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 7 69 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 70 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 8 72 7.2 Informative References . . . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 75 1 Introduction 77 ARP [RFC826] and ND [RFC4861] are normally sent by broadcast and 78 multicast respectively. To reduce the burden on a TRILL campus caused 79 by these multi-destination messages, RBridges MAY implement an 80 "optimized ARP/ND response", as specified herein, when the target's 81 location is known by the ingress RBridge or can be obtained from a 82 directory. This avoids ARP/ND query flooding. 84 1.1 Terminology 86 The acronyms and terminology in [RFC6325] are used herein. Some of 87 these are listed below for convenience with the following along with 88 some additions: 90 Campus: a TRILL network consisting of TRILL switches, links, and 91 possibly bridges bounded by end stations and IP routers. For TRILL, 92 there is no "academic" implication in the name "campus". 94 APPsub-TLV Application sub-Type-Length-Values 96 ARP Address Resolution Protocol [RFC826] 98 DAD Duplicate Address Detection 100 Data Label VLAN or FGL 102 ESADI End Station Address Distribution Information [RFC7357] 104 FGL Fine-Grained Label [RFC7172] 106 IA Interface Addresses, a TRILL APPsub-TLV [IA-draft] 108 IP Internet Protocol 110 MAC Media Access Control address 112 ND Neighbor Discoery [RFC4861] 114 RBridge Routing Bridge, an alternative term for a TRILL 115 switch. 117 SEND secure neighbor discovery [RFC3971] 119 TRILL Transparent Interconnection of Lots of Links or 120 Tunneled Routing in the Link Layer. 122 TRILL switch A device implementing the TRILL protocol, an 123 alternative term for an RBridge. 125 2 IP/MAC Address Mappings 127 Traditionally an RBridge learns the MAC and Data Label (VLAN or FGL) 128 to nickname correspondence of a remote host, as per [RFC6325] and 129 [RFC7172], from TRILL data frames received. No IP address information 130 is learned directly from the TRILL data frame. Interface Addresses 131 (IA) APPsub-TLV [IA-draft] enhances the TRILL base protocol by 132 allowing IP and MAC address mappings to be distributed in the control 133 plane by any RBridge. This APPsub-TLV appears inside the TRILL 134 GENINFO TLV in ESADI [RFC7357] but the value data structure it 135 specifies may also occur in other application contexts. Edge 136 Directory Assist Mechanisms [DirMech] makes use of this APPsub-TLV 137 for its push model and uses the value data structure it specifies in 138 its pull model. 140 An RBridge can easily know the IP/MAC address mappings of the local 141 hosts that it is attached to it via its access ports by receiving ARP 142 [RFC826] or ND [RFC4861] messages. If the RBridge has extracted the 143 sender's IP/MAC address pair from the received data packet, it may 144 save the information and use the IA APPsub-TLV to distribute it to 145 other RBridges through ESADI. Then the relevant remote RBridges 146 (normally those interested in the same Data Label as the original 147 ARP/ND messages) receive and save such mapping information also. 148 There are others ways that RBridges save IP/MAC address mappings in 149 advance, e.g. import from management system and distribution by 150 directory servers [DirMech]. 152 The examples given above shows that RBridges may have saved a host's 153 triplet of {IP address, MAC address, ingress nickname} for a given 154 Data Label (VLAN or FGL) before that host sends or receives any real 155 data packet. Note such information may or may not be a complete list 156 and may or may not exist on all RBridges. The information may 157 possibly be from different sources. RBridges can then use the Flags 158 Field in IA APPsub-TLV to identify if the source is a directory 159 server or local observation by the sender. A different confidence 160 level may also be used to indicate the reliability of the mapping 161 information. 163 3 Handling ARP/ND Messages 165 A native frame that is an ARP [RFC826] message is detected by its 166 Ethertype of 0x0806. A native frame that is an ND [RFC4861] is 167 detected by being one of five different ICMPv6 packet types. ARP/ND 168 is commonly used on a link to (1) query for the MAC address 169 corresponding to an IPv4 or IPv6 address, (2) test if an IPv4/IPv6 170 address is already in use, or (3) to announce the new or updated info 171 on any of IPv4/IPv6 address, MAC address, and/or point of attachment. 173 To simplify the text, we use the following terms in this section. 175 1) IP address - indicated protocol address that is normally an IPv4 176 address in ARP or an IPv6 address in ND. 178 2) sender's IP/MAC address - sender protocol/hardware address in 179 ARP, source IP address and source link-layer address in ND 181 3) target's IP/MAC address - target protocol/hardware address in 182 ARP, target address and target link-layer address in ND 184 When an ingress RBridge receives an ARP/ND message, it can perform 185 the steps described in the sub-sections below. 187 3.1 Get Sender's IP/MAC Mapping Information for Non-zero IP 189 If the sender's IP has not been saved by the ingress RBridge before, 190 populate the information of sender's IP/MAC in its ARP table; 192 else if the sender's IP has been saved before but with a different 193 MAC address mapped or a different ingress nickname associated with 194 the same pair of IP/MAC, the RBridge should verify if a duplicate IP 195 address has already been in use or a host has changed its attaching 196 RBridge. The RBridge may use different strategies to do so, for 197 example, ask an authoritative entity like directory servers or 198 encapsulate and unicast the ARP/ND message to the location where it 199 believes the address is in use. RBridge should update the saved 200 triplet of {IP address, MAC address, ingress nickname} based on the 201 verification. 203 The ingress RBridge may use the IA APPsub-TLV [IA-draft] with the 204 Local flag set in ESADI [RFC7357] to distribute any new or updated 205 triplet of {IP address, MAC address, ingress nickname} information 206 obtained in this step. If a push directory server is used, such 207 information can be distributed as per [DirMech]. 209 3.2 Determine How to Reply to ARP/ND 211 a) If the message is a generic ARP/ND request and the ingress RBridge 212 knows the target's IP address, the ingress RBridge may decide to take 213 one or a combination of the following actions: 215 a.1. Send an ARP/ND response directly to the querier, with the 216 target's MAC address, as believed by the ingress RBridge. 218 a.2. Encapsulate the ARP/ND request to the target's Designated 219 RBridge, and have the egress RBridge for the target forward the 220 query to the target. This behavior has the advantage that a 221 response to the request is authoritative. If the request does not 222 reach the target, then the querier does not get a response. 224 a.3. Block ARP/ND requests that occur for some time after a request 225 to the same target has been launched, and then respond to the 226 querier when the response to the recently-launched query to that 227 target is received. 229 a.4. Pull the most up-to-date records if a pull directory server is 230 available [DirMech] and reply to the querier. 232 a.5. Flood the request as per [RFC6325]. 234 b) If the message is a generic ARP request and the ingress RBridge 235 does not know target's IP address, the ingress RBridge may take one 236 of the following actions. 238 b.1. Flood the message as per [RFC6325]. 240 b.2. Use directory server to pull the information [DirMech] and 241 reply to the querier. 243 b.3. Drop the message. 245 c) If the message is a gratuitous ARP which can be identified by the 246 same sender's and target's "protocol" address fields or an 247 Unsolicited Neighbor Advertisements [RFC4861] in ND: 249 The RBridge may use an IA APPsub-TLV [IA-draft] with the Local flag 250 set to distribute the sender's MAC and IP mapping information. When 251 one or more directory servers are deployed and complete Push 252 Directory information is used by all the TRILL switches in the Data 253 Label, a gratuitous ARP or unsolicited NA SHOULD be discarded rather 254 than ingressed. Otherwise, they are either ingressed and flooded as 255 per [RFC6325] or discarded depending on local policy. 257 d) If the message is a Address Probe ARP Query [RFC5227] which can be 258 identified by the sender's protocol (IPv4) address field being zero 259 and the target's protocol address field being the IPv4 address to be 260 tested or a Neighbor Solicitation for DAD (Duplicate Address 261 Detection) which has the unspecified source address [RFC4862]: it 262 should be handled as the generic ARP message as in a) and b). 264 It should be noted in the case of secure neighbor discovery (SEND) 265 [RFC3971], cryptography might prevent local reply by the ingress 266 RBridge, since the RBridge would not be able to sign the response 267 with the target's private key. 269 It is not essential that all RBridges use the same strategy for which 270 option to select for a particular ARP/ND query. It is up to the 271 implementation. 273 3.3 Determine How to Handle the ARP/ND Response 275 If the ingress RBridge R1 decides to unicast the ARP/ND request to 276 the target's egress RBridge R2 as discussed in subsection 3.2 item a) 277 or to flood the request as per [RFC6325], then R2 decapsulates the 278 query, and initiates an ARP/ND query on the target's link. When/if 279 the target responds, R2 encapsulates and unicasts the response to R1, 280 which decapsulates the response and sends it to the querier. R2 281 should initiates a link state update to inform all the other RBridges 282 of the target's location, layer 3 address, and layer 2 address, in 283 addition to forwarding the reply to the querier. The update message 284 can be carried by an IA APPsub-TLV [IA-draft] with the Local flag set 285 in ESADI [RFC7357] or as per [DirMech] if push directory server is in 286 use. 288 4 Handling RARP (Reverse Address Resolution Protocol) Messages 290 RARP [RFC903] uses the same packet format as ARP but a different 291 Ethertype (0x8035) and opcode values. Its use is similar to the 292 generic ARP Request/Response as described in 3.2 a) and b). The 293 difference is that it is intended to query for the target "protocol" 294 address corresponding to the target "hardware" address provided. It 295 should be handled by doing a local cache or directory server lookup 296 on the target "hardware" address provided to find a mapping to the 297 desired "protocol" address. Normally, it is used to look up a MAC 298 address to find the corresponding IP address. 300 5 Security Considerations 302 ARP and ND messages can be easily forged. Therefore the learning of 303 MAC/IP addresses from them should not be considered as reliable. 304 RBridge can use the confidence level in IA APPsub-TLV information 305 received via ESADI or pull directory retrievals to determine the 306 reliability of MAC/IP address mapping. (ESADI information can be 307 secured as provide in [RFC7357] and pull directory information can be 308 secured as provide in [DirMech].) It is up to the implementation to 309 decide if an RBridge should distribute the IP and MAC address 310 mappings received from local native ARP/ND messages to other RBridges 311 in the same Data Label. 313 The ingress RBridge should also rate limit the ARP/ND queries for the 314 same target to be injected into the TRILL campus to prevent possible 315 denial of service attacks. 317 6 IANA Considerations 319 No IANA action is required. RFC Editor: please delete this section 320 before publication. 322 7 References 324 7.1 Normative References 326 [RFC826] Plummer, D., "An Ethernet Address Resolution Protocol", RFC 327 826, November 1982. 329 [RFC903] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A 330 Reverse Address Resolution Protocol", STD 38, RFC 903, 331 June 1984 333 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 334 Requirement Levels", BCP 14, RFC 2119, March 1997. 336 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 337 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 338 September 2007. 340 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 341 Address Autoconfiguration", RFC 4862, September 2007. 343 [RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 344 Systems", RFC 6165, April 2011. 346 [RFC6325] Perlman, R., et.al. "RBridge: Base Protocol 347 Specification", RFC 6325, July 2011. 349 [RFC6439] Eastlake, D. et.al., "RBridge: Appointed Forwarder", RFC 350 6439, November 2011. 352 [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and 353 D. Dutt, "Transparent Interconnection of Lots of Links 354 (TRILL): Fine-Grained Labeling", RFC 7172, May 2014, 355 . 357 7.2 Informative References 359 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 360 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 362 [RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, 363 July 2008. 365 [RFC7067] Dunbar, L., Eastlake 3rd, D., Perlman, R., and I. 366 Gashinsky, "Directory Assistance Problem and High-Level 367 Design Proposal", RFC 7067, November 2013. 369 [IA-draft] Eastlake, D., Li Y., R. Perlman, "TRILL: Interface 370 Addresses APPsub-TLV", draft-eastlake-trill-ia-appsubtlv, 371 work in progress. 373 [DirMech] Dunbar, L., Eastlake 3rd, D., Perlman, R., I. Gashinsky. 374 and Li Y., TRILL: Edge Directory Assist Mechanisms", 375 draft-ietf-trill-directory-assist-mechanisms, work in 376 progress. 378 Authors' Addresses 380 Yizhou Li 381 Huawei Technologies 382 101 Software Avenue, 383 Nanjing 210012 384 China 386 Phone: +86-25-56625375 387 EMail: liyizhou@huawei.com 389 Donald Eastlake 390 Huawei R&D USA 391 155 Beaver Street 392 Milford, MA 01757 USA 394 Phone: +1-508-333-2270 395 EMail: d3e3e3@gmail.com 397 Linda Dunbar 398 Huawei Technologies 399 5430 Legacy Drive, Suite #175 400 Plano, TX 75024, USA 402 Phone: +1-469-277-5840 403 EMail: ldunbar@huawei.com 405 Radia Perlman 406 EMC 407 2010 256th Avenue NE, #200 408 Bellevue, WA 98007 409 USA 411 EMail: Radia@alum.mit.edu 413 Igor Gashinsky 414 Yahoo 415 45 West 18th Street 6th floor 416 New York, NY 10011 USA 418 EMail: igor@yahoo-inc.com