idnits 2.17.00 (12 Aug 2021) /tmp/idnits1964/draft-ietf-trill-directory-framework-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 -- The document date (August 11, 2013) is 3198 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 6326 (Obsoleted by RFC 7176) -- Obsolete informational reference (is this intentional?): RFC 6439 (Obsoleted by RFC 8139) == Outdated reference: draft-ietf-trill-esadi has been published as RFC 7357 == Outdated reference: draft-ietf-trill-fine-labeling has been published as RFC 7172 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Linda Dunbar 2 Intended Status: Informational Donald Eastlake 3 Huawei 4 Radia Perlman 5 Intel 6 Igor Gashinsky 7 Yahoo 8 Expires: February 10, 2014 August 11, 2013 10 TRILL (Transparent Interconnection of Lots of Links): 11 Edge Directory Assistance Framework 12 14 Abstract 16 Edge TRILL (Transparent Interconnection of Lots of Links) switches 17 currently learn the mapping between MAC addresses and their egress 18 TRILL switch by observing the data packets they ingress or egress or 19 by the TRILL ESADI (End Station Address Distribution Information) 20 protocol. When an ingress TRILL switch receives a data frame whose 21 destination address (MAC&Label) that switch does not know, the data 22 frame is flooded within the frame's Data Label across the TRILL 23 campus. 25 This document describes the framework for using directory services to 26 assist edge TRILL switches in reducing multi-destination frames, 27 particularly unknown unicast frames flooding, and ARP/ND, thus 28 improving TRILL network scalability and security. 30 Status of This Memo 32 This Internet-Draft is submitted to IETF in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Distribution of this document is unlimited. Comments should be sent 36 to the TRILL working group mailing list. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF), its areas, and its working groups. Note that 40 other groups may also distribute working documents as Internet- 41 Drafts. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 49 Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html. 52 Table of Contents 54 1. Introduction............................................4 55 2. Terminology.............................................6 57 3. Impact of Massive Number of End Stations................7 58 3.1 Issues of Flooding Based Learning in Data Centers......7 59 3.2 Two Examples...........................................8 61 4. Benefits of Directory Assisted TRILL Edge...............9 63 5. Generic operation of Directory Assistance..............11 64 5.1 Information in Directory for Edge RBridges............11 65 5.2 Push Model and Requirements...........................11 66 5.3 Pull Model and Requirements...........................13 68 6. Recommendation.........................................15 70 7. Security Considerations................................15 71 8. IANA Considerations....................................17 72 9. Acknowledgements.......................................17 74 10. References............................................18 75 10.1 Normative References.................................18 76 10.2 Informative References...............................18 78 Authors' Addresses........................................19 80 1. Introduction 82 Edge TRILL (Transparent Interconnection of Lots of Links) switches 83 (devices implementing [RFC6325], also known as RBridges) currently 84 learn the mapping between destination MAC addresses and their egress 85 TRILL switch by observing data packets or by the ESADI (End Station 86 Address Distribution Information) protocol. When an ingress RBridge 87 receives a data frame for a destination address (MAC&Label) that 88 RBridge does not know, the data frame is flooded within that Data 89 Label across the TRILL campus. (Data Labels are VLANs or FGLs (Fine 90 Grained Labels [FGL]). 92 This document describes a framework for using directory services in 93 environments where such services are available, such as typical data 94 centers, to assist edge TRILL switches. This assistance can reduce 95 multi-destination frames, particularly ARP [RFC826], ND [RFC4861], 96 and unknown unicast thus improving TRILL network scalability. In 97 addition, the information provided by a directory can be more secure 98 than that learned from the data plane (see Section 7). 100 Data centers, especially Internet and/or multi-tenant data centers 101 tend to have a large number of end stations with a wide variety of 102 applications. Their networks differ from enterprise campus networks 103 in several ways that make them attractive for the use of directory 104 assistance, in particular: 106 1. Data center topology is often based on racks and rows. 107 Furthermore, guest operating system assignment to Servers, Racks, 108 and Rows is orchestrated by a Server/VM (virtual machine) 109 Management system, not done at random. So the information 110 necessary for a directory is normally available from that 111 management system. 112 2. Rapid workload shifting in data centers can accelerate the 113 frequency of the physical servers being re-loaded with different 114 applications. Sometimes, the applications loaded into one physical 115 server at different times can belong to different subnets. When a 116 VM is moved to a new location or a server is loaded with a new 117 application with different IP/MAC addresses, it is more likely 118 that the destination address of data packets sent out from those 119 VMs are unknown to their attached edge RBridges. 120 3. With server virtualization, there is an increasing trend to 121 dynamically create or delete VMs when demand for resource changes, 122 to move VMs from overloaded servers to less loaded servers, or to 123 aggregate VMs onto fewer servers when demand is light. This 124 results in the more frequent occurrence of multiple subnets on the 125 same port at the same time and a higher change rate for VMs than 126 for physical servers. 128 Both items 2 and 3 above can lead to applications in one subnet being 129 placed in different locations (racks or rows) or one rack having 130 applications belonging to different subnets. 132 2. Terminology 134 The terms "VLAN" and "Data Label" are used interchangeably with 135 "Subnet" in this document because it is common to map one subnet to 136 one VLAN or FGL. 138 Bridge: IEEE Std 802.1Q-2011 compliant device [802.1Q]. In this 139 document, Bridge is used interchangeably with Layer 2 140 switch. 142 Data label: VLAN or FGL. 144 EoR: End of Row switches in data center. Also known as 145 aggregation switches. 147 End Station: Guest OS running on a physical server or on a virtual 148 machine. An end station in this document has at least one IP 149 address and at least one MAC address and is connected to a 150 network. 152 FGL: Fine Grained Label [FGL]. 154 IS-IS: Intermediate System to Intermediate System routing protocol. 155 TRILL uses IS-IS [IS-IS] [RFC6326]. 157 RBridge: "Routing Bridge", an alternative name for a TRILL switch. 159 ToR: Top of Rack Switch in a data center. Also known as access 160 switches in some data centers. 162 TRILL: Transparent Interconnection of Lots of Links [RFC6325] 164 TRILL switch: A device implementing the TRILL protocol [RFC6325] 166 VM: Virtual Machine 168 3. Impact of Massive Number of End Stations 170 This section discusses the impact of a massive number of end stations 171 in a TRILL campus using Data Centers as an example. 173 3.1 Issues of Flooding Based Learning in Data Centers 175 It is common for Data Center networks to have multiple tiers of 176 switches, for example, one or two Access Switches for each server 177 rack (ToR), aggregation switches for some rows (or EoR switches), and 178 some core switches to interconnect the aggregation switches. Many 179 aggregation switches deployed in data centers have high port density. 180 It is not uncommon to see aggregation switches interconnecting 181 hundreds of ToR switches. 183 +-------+ +------+ 184 +/------+ | +/-----+ | 185 | Aggr11| + ----- |AggrN1| + EoR Switches 186 +---+---+/ +------+/ 187 / \ / \ 188 / \ / \ 189 +---+ +---+ +---+ +---+ 190 |T11|... |T1x| |T21| .. |T2y| ToR switches 191 +---+ +---+ +---+ +---+ 192 | | | | 193 +-|-+ +-|-+ +-|-+ +-|-+ 194 | |... | | | | .. | | 195 +---+ +---+ +---+ +---+ Server racks 196 | |... | | | | .. | | 197 +---+ +---+ +---+ +---+ 198 | |... | | | | .. | | 199 +---+ +---+ +---+ +---+ 201 Figure 1: Typical Data Center Network Design 203 The following problems could occur when TRILL is deployed in a data 204 center with large number of end stations and the end stations in one 205 subnet/Label could be placed under multiple edge RBridges: 207 - Unnecessary filling of slots in the MAC address learning table 208 of edge RBridges, e.g. RBridge T11, due to T11 receiving 209 broadcast / multicast traffic (e.g. ARP/ND, cluster multicast, 210 etc.) from end stations under other edge RBridges that are not 211 actually communicating with any end stations attached to T11. 213 - Packets being flooded across TRILL campus when their 214 destination MAC addresses are not in ingress RBridge's MAC 215 address to egress RBridge cache. 217 3.2 Two Examples 219 Consider a data center with 1,600 server racks. Each server rack has 220 at least one ToR switch. The ToR switches are further divided into 8 221 groups, with each group being connected by a set of aggregation 222 switches. There could be 4 to 8 aggregation switches in each set to 223 achieve load sharing for traffic to/from server racks. If TRILL is 224 deployed in this data center environment, let's consider the 225 following two scenarios for the TRILL campus boundary: 227 - Scenario #1: TRILL campus boundary starts at ToR switches: 229 If each server rack has one ToR, there are 1,600 edge RBridges. 230 If each rack has two ToR switches, then there will be 3,200 231 edge RBridges 233 In this scenario, the TRILL campus will have more than 1,600 234 (or 3,200) + 8*4 (or 8*8) nodes, which is a large IS-IS area. 235 Even though a mesh IS-IS area can scale up to thousands of 236 nodes, it is challenging for aggregation switches to handle IS- 237 IS link state advertisement among hundreds of parallel ports. 239 If each ToR has 40 downstream ports facing servers and each 240 server has 10 VMs, there could be 40*10 = 400 end stations 241 attached. If those end stations belong to 8 Labels then the 242 total number of MAC&Label entries learned by each edge RBridge 243 in the worst case might be 400*8 = 3,200, which is not a large 244 number. 246 - Scenario #2: TRILL campus boundary starts at the aggregation 247 switches: 249 With the same assumptions as before, the number of nodes in the 250 TRILL campus will be less than 100, and aggregation switches 251 don't have to handle IS-IS link state advisements among 252 hundreds of parallel ports. 254 However, the number of MAC&Label <-> Egress RBridge Mapping 255 entries to be learned and managed by RBridge edge node can be 256 very large. In the example above, each edge RBridge has 200 257 edge ports facing the ToR switches. If each ToR has 40 258 downstream ports facing servers and each server has 10 VMs, 259 there could be 200*40*10 = 80,000 end stations attached. If all 260 those end stations belong to 1,600 Labels (50 per Data Label) 261 and each Data Label has 200 end stations, then under the worst- 262 case scenario, the total number of MAC&Label entries to be 263 learned by each edge RBridge can be 1,600*200=320,000, which is 264 very large. 266 4. Benefits of Directory Assisted TRILL Edge 268 In some environments, particularly data centers, the assignment of 269 applications to servers, including rack and row selection, is 270 orchestrated by Server (or VM) Management System(s). That is, there 271 is a database or multiple databases that have the knowledge of where 272 each application is placed. If the application location information 273 can be fed to RBridge edge nodes, through some form of Directory 274 Service, then there is much less chance of RBridge edge nodes 275 receiving unknown MAC destination address, therefore less chance of 276 flooding. 278 Avoiding unknown unicast address flooding to the TRILL campus is 279 especially valuable in the data center environment because there is a 280 higher chance of an edge RBridge receiving packets with unknown 281 unicast destination address and broadcast / multicast messages due to 282 VM migration and servers being loaded with different applications. 283 When a VM is moved to a new location or a server is loaded with a new 284 application with a different IP/MAC addresses, it is more likely that 285 the destination address of data packets sent out from those VMs are 286 unknown to their attached edge RBridges. In addition, gratuitous ARP 287 (IPv4, [RFC826]) or Unsolicited Neighbor Advertisement (IPv6, 288 [RFC4861]) sent out from those newly migrated or activated VMs have 289 to be flooded to other edge RBridges that have VMs in the same 290 subnets. 292 The benefits of using directory assistance include: 294 - Avoid flooding unknown unicast destination address across the 295 TRILL campus. The Directory enforced MAC&Label <-> Egress 296 RBridge mapping table can determine if a data packet needs to 297 be forwarded across TRILL campus. 299 When multiple RBridge edge ports are connected, possibly via 300 bridged LANs, to end stations (servers/VMs), a directory 301 assisted edge RBridge won't need to flood unknown unicast 302 destination data frames to all ports of the edge RBridges in 303 the frame's Data Label when it ingresses a frame. It can depend 304 on the directory to tell it where the destination is. When the 305 directory doesn't have the needed information, the frames can 306 be dropped or flooded depending on the policy configured. 308 - Reduce flooding of decapsulated Ethernet frames with unknown 309 MAC destination address to a bridged LAN connected to RBridge 310 edge ports. 312 When an RBridge receives a unicast TRILL data packet whose 313 destination Nickname matches with its own, the normal procedure 314 is for the RBridge to decapsulate it and forward the 315 decapsulated Ethernet frame to the directly attached bridged 316 LAN. If the destination MAC is unknown, the RBridge floods the 317 decapsulated Ethernet frame out all ports in the fame's Data 318 Label. With directory assistance, the egress RBridge can 319 determine if the MAC destination address in a frame matches any 320 end stations attached via the bridged LAN. Frames can be 321 discarded if their destination addresses do not match. 323 - Reduce the amount of MAC&Label <-> Egress RBridge mapping 324 maintained by edge RBridges. There is no need for an edge 325 RBridge to keep MAC entries of remote end stations that don't 326 communicate with the end stations locally attached. 328 - Eliminate ARP/ND being broadcast or multicast through the TRILL 329 core. 331 - Some protection against spoofing of source addresses (see 332 Section 7). 334 5. Generic operation of Directory Assistance 336 There are two different models for Directory assistance to edge 337 RBridges: Push Model and Pull Model. The Directory Information is 338 described in Section 5.1 below while Section 5.2 discusses Push Model 339 requirements and Section 5.3 Pull Model requirements. 341 5.1 Information in Directory for Edge RBridges 343 To achieve the benefits of directory assistance for TRILL, the 344 corresponding directory server entries will need, at a minimum, the 345 following logical data structure: 347 [IP, MAC, Data Label, {list of attached RBridge nicknames}, {list of 348 interested RBridges}] 350 The {list of attached RBridges} are the edge RBridges to which the 351 host (or VM) specified by the [IP, MAC, Data Label] in the entry is 352 attached. The {list of interested RBridges} are the remote RBridges 353 that might have attached hosts that communicate with the host in this 354 entry. 356 When a host has multiple IP addresses, there will be multiple 357 entries. 359 The {list of interested RBridges} could get populated when an RBridge 360 queries for information, or information is pushed from a directory 361 server. The list is used to notify those RBridges when the host 362 (specified by the [IP, MAC, Data Label]) in the entry changes its 363 RBridge attachment. An explicit list in the directory is not needed 364 as long as the interested RBridges can be determined. 366 5.2 Push Model and Requirements 368 Under this model, Directory Server(s) push the MAC&Label <-> Egress 369 RBridge mapping for all the end stations that might communicate with 370 end stations attached to an RBridge edge node. If the packet's 371 destination address can't be found in the MAC&Label <-> Egress 372 RBridge table, the Ingress RBridge could be configured to: 374 simply drop a data packet, 376 flood it to the TRILL campus, or 378 start the pull process to get information from pull directory 379 server(s) 381 It may not be necessary that every edge RBridge gets the entire 382 mapping table for all the end stations in a campus. There are many 383 ways to narrow the full set down to a smaller set of remote end 384 stations that communicate with end stations attached to an edge 385 RBridge. A simple approach is to only push the mapping for the Data 386 Labels that have active end stations under an edge RBridge. This 387 approach can reduce the number of mapping entries being pushed. 389 However, the Push Model usually will push more entries of MAC&Label 390 <-> Egress RBridge mapping to an edge RBridges than needed. Under 391 the normal process of edge RBridge cache aging and unknown 392 destination address flooding, rarely used mapping entries would have 393 been removed. But it can be difficult for Directory Servers to 394 predict the communication patterns among applications within one Data 395 Label. Therefore, it is likely that the Directory Servers will push 396 down all the MAC&Label entries if there are end stations in the Data 397 Label attached to the edge RBridge. This is a disadvantage of the 398 Push Model compared with the Pull Model described below. 400 In the Push Model, it is necessary to have a way for an RBridge node 401 to request directory server(s) to push the mapping entries. This 402 method should at least include the Data Labels enabled on the 403 RBridge, so that directory server doesn't need to push down the 404 entire set of mapping entries for all the end stations in the campus. 405 An RBridge must be able to get mapping entries when it is initialized 406 or restarted. 408 The Push Model's detailed method and any handshake mechanism between 409 RBridge and Directory Server(s) is beyond the scope of this framework 410 document. 412 When a directory server needs to push a large number of entries to 413 edge RBridges, efficient data organization should be considered. For 414 example, with one edge RBridge nickname being associated with all 415 attached end stations' MAC addresses and Data Labels. As shown in 416 Table 1 below, to make the data more compact, a representation can be 417 used where a nickname need only occur once for a set of Labels, each 418 of which occurs only once and each of which is associated with a set 419 of multiple IP and MAC address pairs. It would be much more bulky to 420 have each IP and MAC address pair separately accompanied by its Label 421 and by the nickname of the RBridge by which it is reachable. 423 +------------+---------+--------------------------------+ 424 | Nickname1 |Label-1 | IP/MAC1, IP/MAC2, ,, IP/MACn | 425 | |-------- +--------------------------------+ 426 | |Label-2 | IP/MAC1, IP/MAC2, ,, IP/MACn | 427 | |-------- +--------------------------------+ 428 | | ...... | IP/MAC1, IP/MAC2, ,, IP/MACn | 429 +------------+-------- +--------------------------------+ 430 | Nickname2 |Label-1 | IP/MAC1, IP/MAC2, ,, IP/MACn | 431 | |-------- +--------------------------------+ 432 | |Label-2 | IP/MAC1, IP/MAC2, ,,IP/MACn | 433 | |-------- +--------------------------------+ 434 | | | IP/MAC1, IP/MAC2, ,, IP/MACn | 435 +------------+-------- +--------------------------------+ 436 | ------- |-------- +--------------------------------+ 437 | | | IP/MAC1, IP/MAC2, ,, IP/MACn | 438 +------------+-------- +--------------------------------+ 440 Table 1: Summarized table pushed down from directory 442 Whenever there is any change in MAC&Label <-> Egress RBridge mapping, 443 that can be triggered by end stations being added, moved, or de- 444 commissioned, an incremental update can be sent to the edge RBridges 445 which are impacted by the change. Therefore, something like a 446 sequence number has to be maintained by directory servers and 447 RBridges. Detailed mechanisms will be specified in a separate 448 document. 450 5.3 Pull Model and Requirements 452 Under this model, an RBridge pulls the MAC&Label <-> Egress RBridge 453 mapping entry from the directory server when its cache doesn't have 454 the entry. There are a couple of possibilities for triggering the 455 pulling process: 457 - The RBridge edge node can send a pull request whenever it 458 receives an unknown MAC destination, or 460 - The RBridge edge node can intercept all ARP/ND requests and 461 forward them or appropriate requests to the Directory Server(s) 462 that has the information on where the target end stations are 463 located. 465 The Pull Directory response could indicate that the address being 466 queried is unknown or that the requestor is administratively 467 prohibited from getting an informative response. 469 By using a Pull Directory, a frame with unknown MAC destination 470 address doesn't have to be flooded across the TRILL campus and the 471 ARP/ND requests don't have to be broadcast or multicast across the 472 TRILL campus. 474 The ingress RBridge can cache the response pulled from the directory. 475 The timer for such a cache should be short in an environment where 476 VMs move frequently. The cache timer could be configured by the 477 management system or could be sent along with the Pulled reply by the 478 directory server(s). It is important that the cached information be 479 kept consistent with the actual placement of addresses in the campus; 480 therefore, there needs to be some mechanism by which RBridges that 481 have pulled information that has not expired can be informed when 482 that information changes or becomes invalid for other reasons. 484 One advantage of the Pull Model is that edge RBridges can age out 485 MAC&Label entries if they haven't been used for a certain configured 486 period of time or a period of time provided by the Directory. 487 Therefore, each edge RBridge will only keep the entries that are 488 frequently used, so its mapping table size will be smaller. Edge 489 RBridges would query the Directory Server(s) for unknown MAC 490 destination addresses in data frames or ARP/ND and cache the 491 response. When end stations attached to remote edge RBridges rarely 492 communicate with the locally attached end stations, the corresponding 493 MAC&VLAN entries would be aged out from the RBridge's cache. 495 An RBridge waiting for a response from Directory Servers upon 496 receiving a data frame with an unknown destination address is similar 497 to an L3/L2 boundary router waiting for an ARP or ND response upon 498 receiving an IP data packet whose destination IP is not in the 499 router's IP/MAC cache table. Most deployed routers today do hold the 500 packet and send ARP/ND requests to the target upon receiving a packet 501 with destination IP not in its IP to MAC cache. When ARP/ND replies 502 are received, the router will send the data packet to the target. 503 This practice minimizes flooding when targets don't exist in the 504 subnet. 506 When the target doesn't exist in the subnet, routers generally re- 507 send an ARP/ND request a few more times before dropping the packets. 508 So, the holding time by routers to wait for an ARP/ND response, if 509 the target doesn't exist in the subnet, can be longer than the time 510 taken by the Pull Model to get IP to MAC mapping from a directory 511 server. 513 For RBridges with mapping entries being pushed from a directory 514 server, they can be configured to use the Pull Model for targets 515 which don't exist in the mapping data pushed. 517 A separate document will specify the detailed messages and mechanism 518 for RBridges to pull information from directory server(s). 520 6. Recommendation 522 TRILL should provide a directory assisted approach. This document 523 describes a basic framework for directory assistance to RBridge edge 524 nodes. More detailed mechanisms will be described in a separate 525 document or documents. 527 7. Security Considerations 529 For general TRILL security considerations, see Section 6 of 530 [RFC6325]. 532 Accurate mapping of IP addresses into MAC addresses and of MAC 533 addresses to the RBridges from which they are reachable is important 534 to the correct delivery of information. The security of specific 535 directory assisted mechanisms for delivering such information will be 536 discussed in the document or documents specifying those mechanisms. 538 Directory assisted TRILL edge can be used to substantially improve 539 the security of a TRILL campus over TRILL's default MAC address 540 learning from the data plane. Assume S is an end station attached to 541 RB1 trying to spoof a target end station T and that T is attached to 542 RB2. Perhaps S wants to steal traffic intended for T or forge traffic 543 as if it was from T. 545 With that default TRILL data plane learning as described in 546 [RFC6325], S can impersonate T or any other end station in the same 547 Data Label (VLAN or FGL [FGL]) as S and possibly other Data Labels, 548 depending on how tightly VLAN admission and Appointed Forwarders 549 [RFC6439] are configured at the port by which S is connected to RB1. 550 S can just send native frames with the forged source MAC addresses of 551 T, perhaps broadcast frames for maximum effectiveness. With this 552 technique, S will frequently receive traffic intended for T. And S 553 can easily forge traffic as being from T. 555 Such spoofing can be prevented to the extent that the network 556 RBridges (1) use trusted directory services as described above in 557 this document, (2) discard native frames received from a local end 558 station when the directory says that end stations should be remote, 559 and, (3) when appropriate, intercept ARP and ND messages and respond 560 locally. Under these circumstances, S would be limited to spoofing 561 targets on the same RBridge as the ingress RBridge for S (that is, 562 RB1 = RB2). RB1 would still need to learn which local end stations 563 were attached to which port and S could confuse RB1 by sending frames 564 with the forged source MAC address of other end stations on RB1 565 although it would also still be restricted to frames in a VLAN that 566 both would be admitted by S's port of attachment and for which that 567 port is an Appointed Forwarder. 569 Security against spoofing could be even further strengthened by 570 adding port of attachment information to the directory and discarding 571 native frames that are received on the wrong port. This would limit S 572 to spoofing targets that were on the same link as S and in a VLAN 573 admitted by the port of that link's attachment to RB1 and for which 574 that port is an Appointed Forwarder (or, if the link is multiply 575 connected, in the same way at all of the ports by which the link is 576 attached to an RBridge). 578 Even without directory services, secure ND (Secure Neighbor Discovery 579 [RFC3971]) or use of secure ESADI (as described in [ESADI]) may also 580 be helpful to security. 582 8. IANA Considerations 584 This document requires no IANA actions. RFC Editor: please delete 585 this section before publication. 587 9. Acknowledgements 589 Thanks for comments and review from the following: 591 Sam Aldrin, David Black, Charlie Kaufman, Yizhou Li, and Erik 592 Nordmark 594 The document was prepared in raw nroff. All macros used were defined 595 within the source file. 597 10. References 599 10.1 Normative References 601 As an Informational document, this draft has no Normative References. 603 10.2 Informative References 605 [802.1Q] - IEEE Std 802.1Q-2011, "IEEE Standard for Local and 606 metropolitan area networks - Virtual Bridged Local Area 607 Networks", May 2011. 609 [IS-IS] - ISO/IEC, "Intermediate system to Intermediate system 610 routeing information exchange protocol for use in conjunction 611 with the Protocol for providing the Connectionless-mode Network 612 Service (ISO 8473)", ISO/IEC 10589:2002. 614 [RFC826] - Plummer, D., "An Ethernet Address Resolution Protocol", 615 RFC 826, November 1982. 617 [RFC3971] - Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 618 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 620 [RFC4861] - Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 621 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 622 September 2007. 624 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 625 Ghanwani, "Routing Bridges (RBridges): Base Protocol 626 Specification", RFC 6325, July 2011. 628 [RFC6326] - Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A. 629 Ghanwani, "Transparent Interconnection of Lots of Links (TRILL) 630 Use of IS-IS", RFC 6326, July 2011. 632 [RFC6439] - Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. 633 Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC 634 6439, November 2011. 636 [ESADI] - H. Zhai, F. Hu, R. Perlman, D. Eastlake, O. Stokes, "TRILL: 637 ESADI Protocol", draft-ietf-trill-esadi, work in progress. 639 [FGL] - D. Eastlake, M. Zhang, P. Agarwal, R. Perlman, D. Dutt, 640 "TRILL (Transparent Interconnection of Lots of Links): Fine- 641 Grained Labeling", draft-ietf-trill-fine-labeling, in RFC 642 Editor's queue. 644 Authors' Addresses 646 Linda Dunbar 647 Huawei Technologies 648 5430 Legacy Drive, Suite #175 649 Plano, TX 75024, USA 651 Phone: +1-469-277-5840 652 Email: ldunbar@huawei.com 654 Donald Eastlake 655 Huawei Technologies 656 155 Beaver Street 657 Milford, MA 01757 USA 659 Phone: +1-508-333-2270 660 Email: d3e3e3@gmail.com 662 Radia Perlman 663 Intel Labs 664 2200 Mission College Blvd. 665 Santa Clara, CA 95054-1549 USA 667 Phone: +1-408-765-8080 668 Email: Radia@alum.mit.edu 670 Igor Gashinsky 671 Yahoo 672 45 West 18th Street 6th floor 673 New York, NY 10011 USA 675 Email: igor@yahoo-inc.com 677 Copyright, Disclaimer, and Additional IPR Provisions 679 Copyright (c) 2013 IETF Trust and the persons identified as the 680 document authors. All rights reserved. 682 This document is subject to BCP 78 and the IETF Trust's Legal 683 Provisions Relating to IETF Documents 684 (http://trustee.ietf.org/license-info) in effect on the date of 685 publication of this document. Please review these documents 686 carefully, as they describe your rights and restrictions with respect 687 to this document. Code Components extracted from this document must 688 include Simplified BSD License text as described in Section 4.e of 689 the Trust Legal Provisions and are provided without warranty as 690 described in the Simplified BSD License. The definitive version of 691 an IETF Document is that published by, or under the auspices of, the 692 IETF. Versions of IETF Documents that are published by third parties, 693 including those that are translated into other languages, should not 694 be considered to be definitive versions of IETF Documents. The 695 definitive version of these Legal Provisions is that published by, or 696 under the auspices of, the IETF. Versions of these Legal Provisions 697 that are published by third parties, including those that are 698 translated into other languages, should not be considered to be 699 definitive versions of these Legal Provisions. For the avoidance of 700 doubt, each Contributor to the IETF Standards Process licenses each 701 Contribution that he or she makes as part of the IETF Standards 702 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 703 language to the contrary, or terms, conditions or rights that differ 704 from or are inconsistent with the rights and licenses granted under 705 RFC 5378, shall have any effect and shall be null and void, whether 706 published or posted by such Contributor, or included with or in such 707 Contribution.