idnits 2.17.1 draft-yizhou-trill-arp-optimization-01.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 (February 15, 2015) is 3359 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 291, but not defined == Unused Reference: 'RFC2119' is defined on line 321, but no explicit reference was found in the text == Unused Reference: 'RFC6165' is defined on line 331, but no explicit reference was found in the text == Unused Reference: 'RFC6439' is defined on line 337, but no explicit reference was found in the text == Unused Reference: 'RFC7067' is defined on line 353, 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 Yizhou Li 3 INTERNET-DRAFT Donald Eastlake 4 Intended Status: Standard Track Linda Dunbar 5 Huawei Technologies 6 Radia Perlman 7 EMC 8 Igor Gashinsky 9 Yahoo 10 Expires: August 19, 2015 February 15, 2015 12 TRILL: ARP/ND Optimization 13 draft-yizhou-trill-arp-optimization-01 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 . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . 6 67 4 Handling RARP (Reverse Address Resolution Protocol) Messages . . 7 68 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 7 69 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 70 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 8 72 7.2 Informative References . . . . . . . . . . . . . . . . . . . 8 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] is 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 Data Label - VLAN or FGL. 96 ARP - Address Resolution Protocol [RFC826]. 98 ESADI - End Station Address Distribution Information [RFC7357]. 100 FGL - Fine-Grained Label [RFC7172]. 102 IA - Interface Addresses, a TRILL APPsub-TLV [IA]. 104 ND - Neighbor Discoery [RFC4861]. 106 RBridge - Routing Bridge, an alternative term for a TRILL switch. 108 TRILL - Transparent Interconnection of Lots of Links or Tunneled 109 Routing in the Link Layer. 111 TRILL switch -- a device implementing the TRILL protocol, an 112 alternative term for an RBridge. 114 2 IP/MAC Address Mappings 116 Traditionally an RBridge learns the MAC and and Data Label (VLAN or 117 FGL) to nickname correspondence of a remote host, as per [RFC6325] 118 and [RFC7172], from TRILL data frames received. No IP address 119 information is learned directly from the TRILL data frame. Interface 120 Addresses (IA) APPsub-TLV [IA] enhances the TRILL base protocol by 121 allowing IP and MAC address mappings to be distributed in the control 122 plane by any RBridge. This APPsub-TLV appears inside the TRILL 123 GENINFO TLV in ESADI [RFC7357] but the value data structure it 124 specifies may also occur in other application contexts. Edge 125 Directory Assist Mechanisms [DirMech] makes use of this APPsub-TLV 126 for its push model and uses the value data structure it specifies in 127 its pull model. 129 An RBridge can easily know the IP/MAC address mappings of the local 130 hosts that it is attached to it via its access ports by receiving ARP 131 [RFC826] or ND [RFC4861] messages. If the RBridge has extracted the 132 sender's IP/MAC address pair from the received data packet, it may 133 save the information and use the IA APPsub-TLV to distribute it to 134 other RBridges through ESADI. Then the relevant remote RBridges 135 (normally those interested in the same Data Label as the original 136 ARP/ND messages) receive and save such mapping information also. 137 There are others ways that RBridges save IP/MAC address mappings in 138 advance, e.g. import from management system and distribution by 139 directory servers [DirMech]. 141 The examples given above shows that RBridges may have saved a host's 142 triplet of {IP address, MAC address, ingress nickname} for a given 143 Data Label (VLAN or FGL) before that host sends or receives any real 144 data packet. Note such information may or may not be a complete list 145 and may or may not exist on all RBridges. The information may be 146 possibly from different sources. RBridges can then use the Flags 147 Field in IA APPsub-TLV to identify if the source is a directory 148 server or local observation by the sender. Different confidence level 149 may also be used to indicate the reliability of the mapping 150 information. 152 3 Handling ARP/ND Messages 154 A native frame that is an ARP [RFC826] message is detected by its 155 Ethertype of 0x0806. A native frame that is an ND [RFC4861] is 156 detected by being one of five different ICMPv6 packet types. ARP/ND 157 is commonly used on a link to (1) query for the MAC address 158 corresponding to an IPv4 or IPv6 address, (2) test if an IPv4/IPv6 159 address is already in use, or (3) to announce the new or updated info 160 on any of IPv4/IPv6 address, MAC address, and/or point of attachment. 162 To simplify the text, we use the following terms in this section. 164 1) IP address - indicated protocol address that is normally an IPv4 165 address in ARP or an IPv6 address in ND. 167 2) sender's IP/MAC address - sender protocol/hardware address in 168 ARP, source IP address and source link-layer address in ND 170 3) target's IP/MAC address - target protocol/hardware address in 171 ARP, target address and target link-layer address in ND 173 When an ingress RBridge receives an ARP/ND message, it can perform 174 the steps described in the sub-sections below. 176 3.1 Get Sender's IP/MAC Mapping Information for Non-zero IP 178 If the sender's MAC has not been saved by the ingress RBridge before, 179 populate the information of sender's IP/MAC in its ARP table; 181 else if the sender's MAC has been saved before but with a different 182 IP address mapped, the RBridge should verify if a duplicate IP 183 address has already been in use. The RBridge may use different 184 strategies to do so, for example, ask an authoritative entity like 185 directory servers or encapsulate and unicast the ARP/ND message to 186 the location where it believes a duplicate address is in use. 188 The ingress RBridge may use the IA APPsub-TLV [IA] with the Local 189 flag set in ESADI [RFC7357] to distribute any new or updated IP/MAC 190 information obtained in this step. If a push directory server is 191 used, such information can be distributed as per [DirMech]. 193 3.2 Determine How to Reply to ARP/ND 195 a) If the message is a generic ARP/ND request and the ingress RBridge 196 knows the target's IP address, the ingress RBridge may decide to take 197 one or a combination of the following actions: 199 a.1. Send an ARP/ND response directly to the querier, with the 200 target's MAC address, as believed by the ingress RBridge. 202 a.2. Encapsulate the ARP/ND request to the target's Designated 203 RBridge, and have the egress RBridge for the target forward the 204 query to the target. This behavior has the advantage that a 205 response to the request is authoritative. If the request does not 206 reach the target, then the querier does not get a response. 208 a.3. Block ARP/ND requests that occur for some time after a request 209 to the same target has been launched, and then respond to the 210 querier when the response to the recently-launched query to that 211 target is received. 213 a.4. Pull the most up-to-date records if a pull directory server is 214 available [DirMech] and reply to the querier. 216 a.5. Flood the request as per [RFC6325]. 218 b) If the message is a generic ARP request and the ingress RBridge 219 does not know target's IP address, the ingress RBridge may take one 220 of the following actions. 222 b.1. Flood the message as per [RFC6325]. 224 b.2. Use directory server to pull the information [DirMech] and 225 reply to the querier. 227 b.3. Drop the message. 229 c) If the message is a gratuitous ARP which can be identified by the 230 same sender's and target's "protocol" address fields or an 231 Unsolicited Neighbor Advertisements [RFC4861] in ND: 233 The RBridge may use an IA APPsub-TLV [IA] with the Local flag set to 234 distribute the sender's MAC and IP mapping information. When one or 235 more directory servers are deployed and complete Push Directory 236 information is used by all the TRILL switches in the Data Label, a 237 gratuitous ARP or unsolicited NA SHOULD be discarded rather than 238 ingressed. Otherwise, they are either ingressed and flooded as per 239 [RFC6325] or discarded depending on local policy. 241 d) If the message is a Address Probe ARP Query [RFC5227] which can be 242 identified by the sender's protocol (IPv4) address field being zero 243 and the target's protocol address field being the IPv4 address to be 244 tested or a Neighbor Solicitation for DAD (Duplicate Address 245 Detection) which has the unspecified source address [RFC4862]: it 246 should be handled as the generic ARP message as in a) and b). 248 It should be noted in the case of secure neighbor discovery (SEND) 249 [RFC3971], cryptography might prevent local reply by the ingress 250 RBridge, since the RBridge would not be able to sign the response 251 with the target's private key. 253 It is not essential that all RBridges use the same strategy for which 254 option to select for a particular ARP/ND query. It is up to the 255 implementation. 257 3.3 Determine How to Handle the ARP/ND Response 259 If the ingress RBridge R1 decides to unicast the ARP/ND request to 260 the target's egress RBridge R2 as discussed in subsection 3.2 item a) 261 or to flood the request as per [RFC6325], then R2 decapsulates the 262 query, and initiate an ARP/ND query on the target's link. When/if the 263 target responds, R2 encapsulates and unicasts the response to R1, 264 which decapsulates the response and sends it to the querier. R2 265 should initiates a link state update to inform all the other RBridges 266 of the target's location, layer 3 address, and layer 2 address, in 267 addition to forwarding the reply to the querier. The update message 268 can be carried by an IA APPsub-TLV [IA] with the Local flag set in 269 ESADI [RFC7357] or as per [DirMech] if push directory server is in 270 use. 272 4 Handling RARP (Reverse Address Resolution Protocol) Messages 274 RARP [RFC903] uses the same packet format as ARP but a different 275 Ethertype (0x8035) and opcode values. Its use is similar to the 276 generic ARP Request/Response as described in 3.2 a) and b). The 277 difference is that it is intended to query for the target "protocol" 278 address corresponding to the target "hardware" address provided. It 279 should be handled by doing a local cache or directory server lookup 280 on the target "hardware" address provided to find a mapping to the 281 desired "protocol" address. Normally, it is used to look up a MAC 282 address to find the corresponding IP address. 284 5 Security Considerations 286 ARP and ND messages can be easily forged. Therefore the learning of 287 MAC/IP addresses from them should not be considered as reliable. 288 RBridge can use the confidence level in IA APPsub-TLV information 289 received via ESADI or pull directory retrievals to determine the 290 reliability of MAC/IP address mapping. (ESADI information can be 291 secured as provide in [RFC7357] and pull directory information can be 292 secured as provide in [DirMech].) It is up to the implementation to 293 decide if an RBridge should distribute the IP and MAC address 294 mappings received from local native ARP/ND messages to other RBridges 295 in the same Data Label. 297 The ingress RBridge should also rate limit the ARP/ND queries for the 298 same target to be injected into the TRILL campus to prevent possible 299 denial of service attacks. 301 The ingress RBridge should also rate limit the ARP/ND queries for the 302 same target to be injected to the TRILL campus prevent the possible 303 attack. 305 6 IANA Considerations 307 No IANA action is required. RFC Editor: please delete this section 308 before publication. 310 7 References 312 7.1 Normative References 314 [RFC826] Plummer, D., "An Ethernet Address Resolution Protocol", RFC 315 826, November 1982. 317 [RFC903] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A 318 Reverse Address Resolution Protocol", STD 38, RFC 903, 319 June 1984 321 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 322 Requirement Levels", BCP 14, RFC 2119, March 1997. 324 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 325 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 326 September 2007. 328 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 329 Address Autoconfiguration", RFC 4862, September 2007. 331 [RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 332 Systems", RFC 6165, April 2011. 334 [RFC6325] Perlman, R., et.al. "RBridge: Base Protocol 335 Specification", RFC 6325, July 2011. 337 [RFC6439] Eastlake, D. et.al., "RBridge: Appointed Forwarder", RFC 338 6439, November 2011. 340 [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and 341 D. Dutt, "Transparent Interconnection of Lots of Links 342 (TRILL): Fine-Grained Labeling", RFC 7172, May 2014, 343 . 345 7.2 Informative References 347 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 348 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 350 [RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, 351 July 2008. 353 [RFC7067] Dunbar, L., Eastlake 3rd, D., Perlman, R., and I. 354 Gashinsky, "Directory Assistance Problem and High-Level 355 Design Proposal", RFC 7067, November 2013. 357 [IA] Eastlake, D., Li Y., R. Perlman, "TRILL: Interface Addresses 358 APPsub-TLV", draft-eastlake-trill-ia-appsubtlv, work in 359 progress. 361 [DirMech] Dunbar, L., Eastlake 3rd, D., Perlman, R., I. Gashinsky. 362 and Li Y., TRILL: Edge Directory Assist Mechanisms", 363 draft-ietf-trill-directory-assist-mechanisms, work in 364 progress. 366 Authors' Addresses 368 Yizhou Li 369 Huawei Technologies 370 101 Software Avenue, 371 Nanjing 210012 372 China 374 Phone: +86-25-56625375 375 EMail: liyizhou@huawei.com 377 Donald Eastlake 378 Huawei R&D USA 379 155 Beaver Street 380 Milford, MA 01757 USA 382 Phone: +1-508-333-2270 383 Email: d3e3e3@gmail.com 385 Linda Dunbar 386 Huawei Technologies 387 5430 Legacy Drive, Suite #175 388 Plano, TX 75024, USA 390 Phone: +1-469-277-5840 391 EMail: ldunbar@huawei.com 393 Radia Perlman 394 EMC 395 2010 256th Avenue NE, #200 396 Bellevue, WA 98007 397 USA 398 Email: Radia@alum.mit.edu 400 Igor Gashinsky 401 Yahoo 402 45 West 18th Street 6th floor 403 New York, NY 10011 USA 405 EMail: igor@yahoo-inc.com