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