idnits 2.17.1 draft-ietf-trill-arp-optimization-07.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 97 has weird spacing: '...enience along...' -- The document date (October 21, 2016) is 2745 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 356, but not defined == Unused Reference: 'RFC7356' is defined on line 501, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 7042 (Obsoleted by RFC 9542) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). 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 IPinfusion 10 Expires: April 24, 2017 October 21, 2016 12 TRILL: ARP/ND Optimization 13 draft-ietf-trill-arp-optimization-07 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) 2016 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 ARP/ND Optimization Requirement and Solution . . . . . . . . . . 4 63 3 IP/MAC Address Mappings . . . . . . . . . . . . . . . . . . . . 5 64 4 Handling ARP/ND Messages . . . . . . . . . . . . . . . . . . . . 5 65 4.1 Get Sender's IP/MAC Mapping Information for Non-zero IP . . 6 66 4.2 Determine How to Reply to ARP/ND . . . . . . . . . . . . . . 6 67 4.3 Determine How to Handle the ARP/ND Response . . . . . . . . 8 68 5 Handling RARP (Reverse Address Resolution Protocol) Messages . . 8 69 6 Handling of DHCP messages . . . . . . . . . . . . . . . . . . . 9 70 7 Handling of Duplicate IP Addresses . . . . . . . . . . . . . . . 9 71 8 ARP/ND Cache Liveness and MAC Mobility . . . . . . . . . . . . . 10 72 9 Security Considerations . . . . . . . . . . . . . . . . . . . . 10 73 10 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11 74 11 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 11 75 12 References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 12.1 Normative References . . . . . . . . . . . . . . . . . . . 11 77 12.2 Informative References . . . . . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 80 1 Introduction 82 ARP [RFC826] and ND [RFC4861] are normally sent by broadcast and 83 multicast respectively. To reduce the burden on a TRILL campus caused 84 by these multi-destination messages, RBridges MAY implement an 85 "optimized ARP/ND response", as specified herein, when the target's 86 location is known by the ingress RBridge or can be obtained from a 87 directory. This avoids ARP/ND query and answer flooding. 89 1.1 Terminology 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 93 "OPTIONAL" in this document are to be interpreted as described in 94 [RFC2119]. 96 The acronyms and terminology in [RFC6325] are used herein. Some of 97 these are listed below for convenience along with some additions: 99 APPsub-TLV Application sub-Type-Length-Value [RFC6823] 101 ARP Address Resolution Protocol [RFC826] 103 Campus A TRILL network consisting of RBridges, links, and 104 possibly bridges bounded by end stations and IP routers [RFC6325] 106 DAD Duplicate Address Detection 108 Data Label VLAN or FGL 110 ESADI End Station Address Distribution Information [RFC7357] 112 FGL Fine-Grained Label [RFC7172] 114 IA Interface Addresses, a TRILL APPsub-TLV [RFC7961] 116 IP Internet Protocol, both IPv4 and IPv6 118 MAC Media Access Control [RFC7042] 120 ND Neighbor Discovery [RFC4861] 122 RBridge A contraction of "Routing Bridge". A device 123 implementing the TRILL protocol. 125 SEND secure neighbor discovery [RFC3971] 126 TRILL Transparent Interconnection of Lots of Links or 127 Tunneled Routing in the Link Layer [RFC6325] [RFC7780] 129 2 ARP/ND Optimization Requirement and Solution 131 IP address resolution can create significant issues in data centers 132 due to flooded packets as discussed in [RFC6820]. Such flooding can 133 be avoided by a proxy ARP/ND function on edge RBridges as described 134 in this document. 136 To support such ARP/ND optimization, edge RBridges need to know end- 137 station's IP to MAC mapping through manual configuration 138 (management), through control plane mechanisms such as directories 139 [DirMech], or through Data plane learning by snooping of messages 140 such as ARP/ND (including DHCP or gratuitous ARP_messages). 142 When all the end-stations IP/MAC address mapping is known to edge 143 RBridges or provisioned through management or learnt via control 144 plane on the edge RBridges, it should be possible to completely 145 suppress flooding of ARP/ND messages in TRILL Campus, When all end- 146 station MAC addresses are similarly known, it should be possible to 147 suppress unknown unicast by dropping any unknown unicast received at 148 an edge RBridge. 150 An ARP/ND optimization mechanism should include provisions for an 151 edge RBridge to issue an ARP/ND request to an attached end station to 152 confirm or update information and should allow an end station to 153 detect duplicate IP addresses. 155 This solution should provide an option to disable any data-plane 156 learning on a per port basis. 158 Most of the end station hosts either send DHCP messages requesting an 159 IP Address send out gratuitous ARP or RARP requests to announce 160 themselves to the network right after they come online. Thus the 161 local edge RBridge will immediately have the opportunity to snoop and 162 learn their MAC and IP addresses and distribute this information to 163 other edge RBridges through the TRILL control plane ESADI [RFC7357] 164 protocol. Once remote RBridges received this information via the 165 control plane they should add IP to MAC mapping information to their 166 ARP/ND cache along with the nickname and data label of the address 167 information. Therefore, most active IP hosts in TRILL network can be 168 learned by the edge RBridges either through local learning or 169 control-plane-based remote learning. As a result, ARP suppression can 170 vastly reduce the network flooding caused by host ARP learning 171 behavior. 173 3 IP/MAC Address Mappings 175 By default, an RBridge [RFC6325] [RFC7172] learns MAC Address and 176 Data Label (VLAN or FGL) to egress nickname mapping information from 177 TRILL data frames it receives. No IP address information is learned 178 directly from the TRILL data frame. Interface Addresses (IA) APPsub- 179 TLV [RFC7961] enhances the TRILL base protocol by allowing IP and MAC 180 address mappings to be distributed in the control plane by any 181 RBridge. This APPsub-TLV appears inside the TRILL GENINFO TLV in 182 ESADI [RFC7357] but the value data structure it specifies may also 183 occur in other application contexts. Edge Directory Assist Mechanisms 184 [DirMech] makes use of this APPsub-TLV for its push model and uses 185 the value data structure it specifies in its pull model. 187 An RBridge can easily know the IP/MAC address mappings of the local 188 end stations that it is attached to it via its access ports by 189 receiving ARP [RFC826] or ND [RFC4861] messages. If the RBridge has 190 extracted the sender's IP/MAC address pair from the received data 191 packet (either ARP or ND), it may save the information and then use 192 the IA APPsub-TLV (to link the IP and MAC addresses) to distribute it 193 to other RBridges through ESADI. Then the relevant remote RBridges 194 (normally those interested in the same Data Label as the original 195 ARP/ND messages) also receive and save such mapping information. 196 There are others ways that RBridges save IP/MAC address mappings in 197 advance, e.g. import from management system and distribution by 198 directory servers [DirMech]. 200 The examples given above show that RBridges might have saved an end 201 station's triplet of {IP address, MAC address, ingress nickname} for 202 a given Data Label (VLAN or FGL) before that end station sends or 203 receives any real data packet. Note such information might or might 204 not be a complete list and might or might not exist on all RBridges. 205 The information could possibly be from different sources. RBridges 206 can then use the Flags Field in IA APPsub-TLV to identify if the 207 source is a directory server or local observation by the sender. A 208 different confidence level may also be used to indicate the 209 reliability of the mapping information. 211 4 Handling ARP/ND Messages 213 A native frame that is an ARP [RFC826] message is detected by its 214 Ethertype of 0x0806. A native frame that is an ND [RFC4861] is 215 detected by being one of five different ICMPv6 packet types. ARP/ND 216 is commonly used on a link to (1) query for the MAC address 217 corresponding to an IPv4 or IPv6 address, (2) test if an IPv4/IPv6 218 address is already in use, or (3) to announce the new or updated info 219 on any of IPv4/IPv6 address, MAC address, and/or point of attachment. 221 To simplify the text, we use the following terms in this section. 223 1) IP address - indicated protocol address that is normally an IPv4 224 address in ARP or an IPv6 address in ND. 226 2) sender's IP/MAC address - sender IP/MAC address in ARP, source 227 IP address and source link-layer address in ND 229 3) target's IP/MAC address - target IP/MAC address in ARP, target 230 address and target link-layer address in ND 232 When an ingress RBridge receives an ARP/ND message, it can perform 233 the steps described in the sub-sections below. 235 4.1 Get Sender's IP/MAC Mapping Information for Non-zero IP 237 o If the sender's IP is not present in the ingress RBridge's ARP/ND 238 cache, populate the information of sender's IP/MAC in its ARP/ND 239 cache table. The ingress RBridge correlates its nickname and that 240 IP/MAC mapping information. Such triplet of {IP address, MAC address, 241 ingress nickname} information is saved locally and can be distributed 242 to other RBridges as explain later. 244 o Else if the sender's IP has been saved before but with a 245 different MAC address mapped or a different ingress nickname 246 associated with the same pair of IP/MAC, the RBridge SHOULD verify if 247 a duplicate IP address has already been in use or an end station has 248 changed its attaching RBridge. The RBridge may use different 249 strategies to do so. For example, the RBridge might ask an 250 authoritative entity like directory servers or it might encapsulate 251 and unicast the ARP/ND message to the location where it believes the 252 address is in use. RBridge SHOULD update the saved triplet of {IP 253 address, MAC address, ingress nickname} based on the verification. An 254 RBridge might not verify an IP address if the network manager's 255 policy is to have the network behave, for each Data Label, as if it 256 were a single link and just believe an ARP it receives. 258 The ingress RBridge MAY use the IA APPsub-TLV [RFC7961] with the 259 Local flag set in ESADI [RFC7357] to distribute any new or updated 260 triplet of {IP address, MAC address, ingress nickname} information 261 obtained in this step. If a push directory server is used, such 262 information can be distributed as per [DirMech]. 264 4.2 Determine How to Reply to ARP/ND 266 The options for an edge RBridge to handle a native ARP/ND are given 267 below. For generic ARP/ND request seeking the MAC address 268 corresponding to an IP address, if the edge RBridge knows the IP 269 address and corresponding MAC, behavior is as in item (a), otherwise 270 behavior is as in item (b). Behavior for gratuitous ARP and ND 271 Unsolicited Neighbor Advertisements [RFC4861] is given in item (c). 272 And item (d) covers handling of Address Probe ARP Query. 274 a) If the message is a generic ARP/ND request and the ingress RBridge 275 knows the target's IP address and associated MAC address, the ingress 276 RBridge MUST take one or a combination of the actions below. In the 277 case of secure neighbor discovery (SEND) [RFC3971], cryptography 278 would prevent local reply by the ingress RBridge, since the RBridge 279 would not be able to sign the response with the target's private key 280 and only action a.2 or a.5 is valid. 282 a.1. Send an ARP/ND response directly to the querier, using the 283 target's MAC address present in the ingress RBridge's ARP/ND cache 284 table. Because the edge RBridge might not have an IPv6 address, the 285 source IP address for such an ND response MUST be that of the 286 target end station. 288 a.2. Encapsulate the ARP/ND request to the target's Designated 289 RBridge, and have the egress RBridge for the target forward the 290 query to the target. This behavior has the advantage that a 291 response to the request is authoritative. If the request does not 292 reach the target, then the querier does not get a response. 294 a.3. Block ARP/ND requests that occur for some time after a request 295 to the same target has been launched, and then respond to the 296 querier when the response to the recently-launched query to that 297 target is received. 299 a.4 Reply to the querier based on directory information [DirMech] 300 such as information obtained from a pull directory server or 301 directory information that the ingress RBridge has requested to be 302 pushed to it. 304 a.5. Flood the request as per [RFC6325]. 306 (b) If the message is a generic ARP/ND request and the ingress 307 RBridge does not know target's IP address, the ingress RBridge MUST 308 take one of the following actions. In the case of secure neighbor 309 discovery (SEND) [RFC3971], cryptography would prevent local reply by 310 the ingress RBridge, since the RBridge would not be able to sign the 311 response with the target's private key and only action b.1 is valid. 313 b.1. Flood the message as per [RFC6325]. 315 b.2. Use directory server to pull the information [DirMech] and 316 reply to the querier. 318 b.3. Drop the message if the directory mechanism is used and you 319 know there should be no response (query based on an non-existent IP 320 address for example). 322 (c) If the message is a gratuitous ARP which can be identified by the 323 same sender's and target's "protocol" address fields or an 324 Unsolicited Neighbor Advertisements [RFC4861] in ND: 326 The RBridge MAY use an IA APPsub-TLV [RFC7961] with the Local flag 327 set to distribute the sender's MAC and IP mapping information. When 328 one or more directory servers are deployed and complete Push 329 Directory information is used by all the RBridges in the Data Label, 330 a gratuitous ARP or unsolicited NA SHOULD be discarded rather than 331 ingressed. Otherwise, they are either ingressed and flooded as per 332 [RFC6325] or discarded depending on local policy. 334 (d) If the message is a Address Probe ARP Query [RFC5227] which can 335 be identified by the sender's protocol (IPv4) address field being 336 zero and the target's protocol address field being the IPv4 address 337 to be tested or a Neighbor Solicitation for DAD (Duplicate Address 338 Detection) which has the unspecified source address [RFC4862]: it 339 SHOULD be handled as the generic ARP message as in (a) or (b) above. 341 It is not essential that all RBridges use the same strategy for which 342 option to select for a particular ARP/ND query. It is up to the 343 implementation. 345 4.3 Determine How to Handle the ARP/ND Response 347 If the ingress RBridge R1 decides to unicast the ARP/ND request to 348 the target's egress RBridge R2 as discussed in subsection 3.2 item a) 349 or to flood the request as per [RFC6325], then R2 decapsulates the 350 query, and initiates an ARP/ND query on the target's link. When/if 351 the target responds, R2 encapsulates and unicasts the response to R1, 352 which decapsulates the response and sends it to the querier. R2 353 SHOULD initiate a link state update to inform all the other RBridges 354 of the target's location, layer 3 address, and layer 2 address, in 355 addition to forwarding the reply to the querier. The update uses an 356 IA APPsub-TLV [IA-draft] (so the layer 3 and layer 2 addresses can be 357 linked) with the Local flag set in ESADI [RFC7357] or as per 358 [DirMech] if push directory server is in use. 360 5 Handling RARP (Reverse Address Resolution Protocol) Messages 361 RARP [RFC903] uses the same packet format as ARP but a different 362 Ethertype (0x8035) and opcode values. Its use is similar to the 363 generic ARP Request/Response as described in 3.2 a) and b). The 364 difference is that it is intended to query for the target "protocol" 365 (IP) address corresponding to the target "hardware" (MAC) address 366 provided. It SHOULD be handled by doing a local cache or directory 367 server lookup on the target "hardware" address provided to find a 368 mapping to the desired "protocol" address. Normally, it is used to 369 look up a MAC address to find the corresponding IP address. 371 6 Handling of DHCP messages 373 When a newly connected end-station exchanges messages with a DHCP 374 [RFC2131] server an edge RBridge should snoop them (mainly the 375 DHCPAck message) and store IP/MAC mapping information in its ARP/ND 376 cache and should also send the information out through the TRILL 377 control plane. 379 7 Handling of Duplicate IP Addresses 381 Duplicate IP addresses within a Data Label can occur due to an 382 attacker sending fake ARP/ND messages or due to human/configuration 383 errors. If complete directory information is available, then by 384 definition the IP location information in the directory is correct. 385 Any appearance of an IP address in a different place (different edge 386 RBridge or port) from other sources is not correct. 388 Without complete directory information, the ARP/ND optimization 389 function should support duplicate IP detection. This is critical in a 390 Data Center to stop an attacker from using ARP/ND spoofing to divert 391 traffic from its intended destination. 393 Duplicate IP addresses can be detected when an existing active 394 IP1/MAC1 mapping gets modified. Also an edge RBridge may send a query 395 to the former owner of IP called a DAD-query (Duplicate Address 396 Detection query). A DAD-query is a unicast ARP/ND message with sender 397 IP 0.0.0.0 in case of ARP (or a configurable per RBridge IP address 398 called the DAD-Query source IP) and an IPv6 Link Local Address in 399 case of ND with source MAC set to the DAD-querier RBridge's MAC. If 400 the querying RBridge does not receive an answer within a given time, 401 the new IP entry will be confirmed and activated in its ARP/ND 402 cache. 404 In the case where the former owner replies, a Duplicate Address has 405 been detected. In this case the querying RBridge SHOULD log the 406 duplicate so that the network administrator can take appropriate 407 action. 409 8 ARP/ND Cache Liveness and MAC Mobility 411 A maintenance procedure is needed for ARP/ND caching to ensure IP 412 end-stations connected to ingress RBridges are still active. 414 Some links provide a physical layer indication of link liveness. A 415 dynamic proxy-ARP/ND entry (one learned from data plane observation) 416 MUST be removed from the table if the link over which it was learned 417 fails. 419 Similarly a dynamic proxy-ARP/ND entry SHOULD be flushed out of the 420 table if the IP/MAC mapping has not been refreshed within a given 421 age-time. The entry is refreshed if an ARP or ND message is received 422 for the same IP/MAC mapping entry from any location. The IP/MAC 423 mapping information ageing timer is configurable per RBridge and 424 defaults to 3/4 of the MAC address learning Ageing Timer [RFC6325]. 426 For example end-Station "A" is connected to edge-RBridge1 (RB1) and 427 learnt as local entry on RB1. If end-Station "A" moves to some other 428 location (MAC/VM Mobility) and gets connected to egde-RBridge2 (RB2), 429 after learning on RB2's access port, RB2 advertise this entry through 430 the TRILL control-plane and it gets learnt on RB1 as a remote entry. 431 The old entry on RB1 SHOULD get replaced and all other edge-RBridges 432 with end-station service enabled for that data-label should update 433 the entry to show reachability from RB2 instead of RB1. 435 If ARP/ND entry in the cache is not refreshed, then the RBridge 436 connected to that Host MAY send periodic refresh messages (ARP/ND 437 "probes") to the owners of the dynamic Proxy-ARP/ND entries, so that 438 the entries can be refreshed before they age out. The owner of the 439 IP/MAC mapping entry would reply to the ARP/ND probe and the 440 corresponding entry age-timer resets. 442 9 Security Considerations 444 Unless Secure ND (SEND [RFC3971]) is used, ARP and ND messages can be 445 easily forged. Therefore the learning of MAC/IP addresses from ARP/ND 446 should not be considered as reliable without SEND. RBridge can use 447 the confidence level in IA APPsub-TLV information received via ESADI 448 or pull directory retrievals to determine the reliability of MAC/IP 449 address mapping. ESADI information can be secured as provide in 450 [RFC7357] and pull directory information can be secured as provide in 451 [DirMech]. The implementation decides if an RBridge will distribute 452 the IP and MAC address mappings received from local native ARP/ND 453 messages to other RBridges in the same Data Label and with what 454 confidence level. 456 The ingress RBridge SHOULD also rate limit the ARP/ND queries for the 457 same target to be injected into the TRILL campus to prevent possible 458 denial of service attacks. 460 10 IANA Considerations 462 No IANA action is required. RFC Editor: please delete this section 463 before publication. 465 11 Acknowledgments 467 The authors would like to thank Igor Gashinsky for his contributions. 469 12 References 471 12.1 Normative References 473 [RFC826] Plummer, D., "An Ethernet Address Resolution Protocol", RFC 474 826, November 1982. 476 [RFC903] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A 477 Reverse Address Resolution Protocol", STD 38, RFC 903, 478 June 1984 480 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 481 Requirement Levels", BCP 14, RFC 2119, March 1997. 483 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 484 RFC 2131, March 1997. 486 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 487 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 488 September 2007. 490 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 491 Address Autoconfiguration", RFC 4862, September 2007. 493 [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 494 Ghanwani, "Routing Bridges (RBridges): Base Protocol 495 Specification", RFC 6325, July 2011. 497 [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and 498 D. Dutt, "Transparent Interconnection of Lots of Links 499 (TRILL): Fine-Grained Labeling", RFC 7172, May 2014. 501 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 502 Scope Link State PDUs (LSPs)", RFC 7356, September 2014. 504 [RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. 505 Stokes, "Transparent Interconnection of Lots of Links 506 (TRILL): End Station Address Distribution Information 507 (ESADI) Protocol", RFC 7357, September 2014. 509 [RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 510 Ghanwani, A., and S. Gupta, "Transparent Interconnection 511 of Lots of Links (TRILL): Clarifications, Corrections, and 512 Updates", RFC 7780, February 2016. 514 [RFC7961] Eastlake 3rd, D. and L. Yizhou, "Transparent 515 Interconnection of Lots of Links (TRILL): Interface 516 Addresses APPsub-TLV", RFC 7961, August 2016. 518 [DirMech] Dunbar, L., Eastlake 3rd, D., Perlman, R., I. Gashinsky. 519 and Li Y., TRILL: Edge Directory Assist Mechanisms", 520 draft-ietf-trill-directory-assist-mechanisms, work in 521 progress. 523 12.2 Informative References 525 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 526 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 528 [RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, 529 July 2008. 531 [RFC6820] Narten, T., Karir, M., and I. Foo, "Address Resolution 532 Problems in Large Data Center Networks", RFC 6820, January 533 2013. 535 [RFC6823] Ginsberg, L., Previdi, S., and M. Shand, "Advertising 536 Generic Information in IS-IS", RFC 6823, December 2012. 538 [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and 539 IETF Protocol and Documentation Usage for IEEE 802 540 Parameters", BCP 141, RFC 7042, October 2013. 542 Authors' Addresses 544 Yizhou Li 545 Huawei Technologies 546 101 Software Avenue, 547 Nanjing 210012 548 China 550 Phone: +86-25-56625375 551 EMail: liyizhou@huawei.com 553 Donald Eastlake 554 Huawei R&D USA 555 155 Beaver Street 556 Milford, MA 01757 USA 558 Phone: +1-508-333-2270 559 EMail: d3e3e3@gmail.com 561 Linda Dunbar 562 Huawei Technologies 563 5430 Legacy Drive, Suite #175 564 Plano, TX 75024, USA 566 Phone: +1-469-277-5840 567 EMail: ldunbar@huawei.com 569 Radia Perlman 570 EMC 571 2010 256th Avenue NE, #200 572 Bellevue, WA 98007 573 USA 575 EMail: Radia@alum.mit.edu 577 Mohammed Umair 578 IPinfusion 580 Email: mohammed.umair2@gmail.com