idnits 2.17.1 draft-perlman-trill-rbridge-data-encoding-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 (Using the creation date from RFC6325, updated by this document, for RFC5378 checks: 2006-05-11) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 27, 2017) is 2580 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group Radia Perlman 2 INTERNET-DRAFT EMC 3 Updates: 6325 Donald Eastlake 4 Intended status: Proposed Standard Yizhou Li 5 Huawei 6 Anoop Ghanwani 7 Dell 8 Expires: September 26, 2017 March 27, 2017 10 RBridges: TRILL Link Data Optimizations 11 13 Abstract 15 TRILL (TRansparent Interconnection of Lots of Links) Data frames can 16 be encoded so as to make more efficient use of communications links 17 under certain circumstances. This document specifies two such 18 optional optimizations. One, called Compact Format, improves the 19 compactness of encoding where a TRILL link is a point-to-point 20 Ethernet link. The other, called Specific Addressing, optionally 21 decreases the burden on multi-access TRILL links for multi- 22 destination TRILL Data frames. This document updates RFC 6325. 24 Status of This Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Distribution of this document is unlimited. Comments should be sent 30 to the TRILL working group mailing list . 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 44 Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 Table of Contents 49 1. Introduction............................................3 50 1.1 Structure of This Document.............................3 51 1.2 Terminology Used in This Document......................4 53 2. TRILL Frame Formats.....................................5 54 2.1 The General TRILL Frame Format.........................5 55 2.2 Ethernet Link TRILL Data Frame General Encapsulation...6 57 3. Compact Format for Point-to-Point Ethernet Links........8 58 3.1 Conditions for Using Compact Format....................8 59 3.2 RBridge Originated and Terminated Native Frames.......10 60 3.3 Compact TRILL Data Reception and Transmission.........10 61 3.3.1 Compact TRILL Data Frame Reception..................10 62 3.3.2 Compact TRILL Data Frame Transmission...............12 63 3.4 Announcing Support for Compact Format.................12 65 4. Specific Addressing....................................13 66 4.1 Current Multi-Destination Addressing..................13 67 4.2 Specific Addressing Specification.....................13 68 4.3 Announcing Support for Specific Addressing............13 70 5. Interaction Between The Optimizations..................15 71 6. IANA Considerations....................................16 73 7. Security Considerations................................17 74 7.1 Compact Format Security Considerations................17 75 7.2 Specific Addressing Security Considerations...........17 76 7.3 Results of Frame Misinterpretation....................17 78 8. References.............................................19 79 8.1 Normative References..................................19 80 8.2 Informative References................................20 82 Authors' Addresses........................................21 84 1. Introduction 86 TRILL switches (also called RBridges (Routing Bridges)) are devices 87 that support the IETF TRILL (TRansparent Interconnection of Lots of 88 Links) protocol [RFC6325] [RFC7177] [RFC7780]. They provide 89 transparent forwarding of frames in multi-hop networks with arbitrary 90 topology and link technology using least cost paths for unicast 91 traffic, support VLANs (Virtual Local Area Networks) and 24-bit Fine 92 Grained Labels [RFC7172], and support the multipathing of both 93 unicast and multi-destination traffic. They accomplish this by use of 94 a hop count and IS-IS (Intermediate System to Intermediate System) 95 link state routing [IS-IS] [RFC7176]. 97 A link between two TRILL switches in a TRILL campus can be any of a 98 variety of technologies, ranging from a complex bridged LAN to PPP 99 [RFC6361]. In the general case under the base TRILL protocol 100 [RFC6325], a TRILL Data frame consists of an inner payload formatted 101 as an Ethernet frame, preceded by a TRILL Header, and then 102 encapsulated by a link envelope appropriate for the link technology. 104 1.1 Structure of This Document 106 Section 2 discusses General Format TRILL Data frames without the 107 enhancements specified in this document. 109 In the case where the link is a point-to-point Ethernet link, an 110 optional Compact Format is specified for TRILL Data frames that saves 111 16 bytes. Section 3 specifies that format, its processing, and the 112 conditions for its safe use. 114 In the case where a multi-destination TRILL Data frame is being 115 forwarded over a multi-access link with multiple ports connected but 116 there is only one (or perhaps a few) next hop TRILL switches of 117 interest, optional Specific Addressing allows the TRILL Data frame to 118 be link unicast. This can substantially reduce the burden that frame 119 represents if, for example, the link is a complex bridged LAN through 120 which the frame might otherwise be flooded. Section 4 specifies the 121 Specific Addressing enhancement and the conditions for its safe use. 123 Section 5 discusses potential interaction between these two 124 enhancements. The remaining Sections after Section 5 provide IANA and 125 Security Considerations, References, and the like. 127 This document updates [RFC6325]. 129 1.2 Terminology Used in This Document 131 The terminology and acronyms defined in [RFC6325] are used herein 132 with the same meaning. In particular, the terms "campus", "native 133 frame", "link", etc., are as defined [RFC6325]. 135 "Point-to-point", as used herein, means a link which appears to be an 136 isolated channel between exactly two TRILL switch ports. Such a link 137 may not include customer bridges but may include hubs/repeaters, Two 138 Port MAC Relays, Provider Bridges, Provider Back Bone Bridges 139 [802.1Q], or other technology, provided that technology is configured 140 to provide a transparent point-to-point path between the end point 141 RBridge ports. 143 References herein to "VLAN Tag" or the like are to customer VLANs (C- 144 Tags, Ethertype 0x8100). Use of S-Tags, also known as Service Tags, 145 or stacked VLAN or other tags is beyond the scope of this document 146 but is an obvious extension. 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in [RFC2119]. 152 2. TRILL Frame Formats 154 The subsections below provide a description of the general format of 155 TRILL Data frames. It then narrows in to describe the format of TRILL 156 Data frames on Ethernet links. 158 2.1 The General TRILL Frame Format 160 The general "on-the-wire" form of TRILL frames is illustrated below. 162 The Link Headers and Trailers in the formats below depend on the 163 specific link technology. The Link Header contains one or more fields 164 that distinguish TRILL Data from TRILL IS-IS. For example, over 165 Ethernet, the TRILL Data Link Header ends with the TRILL Ethertype 166 while the TRILL IS-IS frame Link Header ends with the L2-IS-IS 167 Ethertype; on the other hand, over PPP, there are no Ethertypes but 168 PPP protocol codes perform that function [RFC6361]. 170 A TRILL Data frame in transit between two neighboring RBridges is as 171 shown below: 173 +---------------+----------+----------------+---------------+ 174 | TRILL Data | TRILL | Payload | TRILL Data | 175 | Link Header | Header | Native Frame | Link Trailer | 176 +---------------+----------+----------------+---------------+ 178 Figure 1. Format of TRILL Data Frames 180 In the above diagram, the Payload Native Frame is in a restricted 181 Ethernet frame format with a VLAN or FGL [RFC7172] label but with no 182 trailing Frame Check Sequence (FCS). The payload frame format is 183 shown below, assuming the payload starts with an Ethertype (it might 184 alternatively be LLC [802-2014] encoded or some other format): 186 +-----------+------------+--------+-----------+------------ 187 | MAC Dest. | MAC Source | Label | Ethertype | ... 188 +-----------+------------+--------+-----------+------------ 190 Figure 2. Format of the Payload Frame 192 The encapsulated payload has the following fields in sequence: 194 o A 6-byte destination MAC address (Inner.MacDA) 196 o A 6-byte source MAC address (Inner.MacSA) 198 o An Inner.Label giving the VLAN ID or FGL [RFC7172], Priority, and 199 DEI (Drop Eligibility Indicator) [RFC7780] of the payload (use of 200 an S-tag or stacked tags is beyond the scope of this document but 201 is an obvious extension) 203 o The payload frame's content (which usually starts with an 204 Ethertype, such as the Ethertype for IPv4 or IPv6) 206 TRILL IS-IS frames are also sent between neighboring RBridges and 207 must be distinguished from TRILL Data frames. TRILL IS-IS frames are 208 formatted as follows and cannot use the Compact Format specified 209 herein: 211 +--------------+---------------+--------------+ 212 | TRILL IS-IS | TRILL IS-IS | TRILL IS-IS | 213 | Link Header | Payload | Link Trailer | 214 +--------------+---------------+--------------+ 216 Figure 3. TRILL IS-IS Frame 218 2.2 Ethernet Link TRILL Data Frame General Encapsulation 220 If the link between neighbor RBridges is Ethernet, then the general 221 TRILL Data frame format has the following link encapsulation: 223 Link Header: a 6-byte outer MAC destination address (Outer.MacDA) 224 followed by a 6-byte outer MAC source address (Outer.MacSA) 225 followed by an optional 4-byte outer VLAN tag Ethertype and 226 value (Outer.VLAN), and finally the 2-byte TRILL Ethertype 227 (0x22F3). Additional tags could be included after the outer MAC 228 addresses and before the TRILL Ethertype such a MACSEC 229 [802.1AE]. 231 Under the TRILL standard before this document, the Outer.MacDA 232 was required to be the unicast MAC address of the destination 233 RBridge port, if the TRILL Data frame was a unicast frame to a 234 known destination, and was required to be the All-RBridges 235 multicast address, if the TRILL Data frame was a multi- 236 destination frame. 238 +-----------+------------+- - - - - +-----------+ 239 | MAC Dest. | MAC Source | VLAN Tag | TRILL | 240 | Address | Address | if Req. | Ethertype | 241 +-----------+------------+ - - - - -+-----------+ 243 Figure 4. TRILL Data Link Header on an Ethernet Link 245 Link Trailer: the 32-bit IEEE [802.3] Frame Check Sequence (FCS). 247 In the General Format for Ethernet links, the Outer.VLAN can be 248 omitted when it is not required by VLAN sensitive equipment in the 249 link. 251 3. Compact Format for Point-to-Point Ethernet Links 253 TRILL Data frames may optionally be sent using a Compact Format that 254 compresses the headers involved if the link is a point-to-point 255 Ethernet link, Compact Format can be enabled by both RBridges on the 256 link if other conditions met as listed below. 258 The Compact Format is simple: the Outer.MacDA, Outer.MacSA, and 259 Outer.VLAN are replaced by the Inner.MacDA, Inner.MacSA, and Inner 260 Label and the Inner fields are deleted. This saves 6 + 6 + 4 or 16 261 bytes. To avoid confusion, Compact Format MUST NOT be used if the 262 Inner.MacDA is a multi-cast address assigned to TRILL 263 (01-80-C2-00-00-40 through 01-80-C2-00-00-4F). 265 Compact Format is not applicable to TRILL IS-IS frames because there 266 is no inner Ethernet header. (And, of course, Compact Format is not 267 applicable to native frames or Layer 2 Ethernet control frames since 268 those frames are not TRILL frames.) 270 +---------------------+--------+-----------+---------+---------+ 271 | Ethernet Header | TRILL | Content | Content | Link | 272 | Header from Payload | Header | Ethertype | ... | Trailer | 273 +---------------------+--------+-----------+---------+---------+ 275 Figure 5. Compact Format TRILL Data Frame 277 Compact Format is generally intended for use on point-to-point 278 Ethernet links between RBridges, a common arrangement in many LANs. 279 However, if there are any transparent devices in the apparent point- 280 to-point link, such as Provider Bridges or Provider Backbone Bridges, 281 then the use of the Compact Format will increase the MAC address 282 learning table stress on such Provider Bridges or Provider Edge Back 283 Bone bridges. 285 3.1 Conditions for Using Compact Format 287 Use of Compact Format is a hop-by-hop decision. In successive RBridge 288 to RBridge hops, a TRILL Data frame might be sent alternately in 289 Compact Format and General Format. 291 There are a number of conditions, listed below, for using Compact 292 Format TRILL Data frames. Most of these boil down to maximizing the 293 assurance that the RBridge-to-RBridge Ethernet link over which the 294 Compact Format TRILL Data frame is to be sent is really point-to- 295 point. Only the General Format for TRILL Data frames is safe to use 296 on an RBridge Ethernet port that is to a multi-access link even if 297 the ports between which it is being sent have been configured as 298 point-to-point ports. (See also the frame reception process 299 variations described in Section 3.3.1.) 301 o The RBridge Ethernet port over which Compact Format TRILL Data 302 frames are to be sent MUST be configured as an IS=IS point-to- 303 point port (see Section 4.9.1 of [RFC6325]). 305 o The RBridge port through which the Compact Format TRILL Data frame 306 is being transmitted MUST be configured to send VLAN/FGL tagged 307 frames. Otherwise the Data Label of the payload will be lost 308 (unless it just happens to be the default VLAN ID of the receiving 309 port). 311 o The RBridge port at the other end of the link MUST be announcing 312 that it supports the Compact Format. See Section 3.4. 314 o Receipt of a native frame indicates that the link is multi-access 315 and has end stations on it. These are frames that are not Layer 2 316 control frames (see Section 1.4 of [RFC6325]) and have neither an 317 Outer.MacDA in the block assigned to TRILL nor an outer payload 318 EtherType assigned to/for TRILL (currently the TRILL, L2-IS-IS, 319 and RBridge-Channel [RFC7178] EtherTypes). On receipt of such a 320 frame, the port MUST stop using Compact Format TRILL Data frames 321 for at least ten seconds, unless it is reset by management or 322 rebooted before that. 324 o The sending RBridge MUST have exactly one adjacency in the Report 325 state on the link and no other adjacencies in any state but Down 326 [RFC7177]. Thus, receipt of a TRILL IS-IS Hello frame, other than 327 one of the correct type (point-to-point or LAN) from the RBridge 328 believed to be at the other end of the link, indicates that the 329 link really isn't point-to-point or that the RBridge at the other 330 end of that link is mis-behaving. In either case, the RBridge 331 receiving such an unexpected Hello MUST stop using Compact Format 332 TRILL Data frames on that port for at least twice the holding time 333 in the unexpected Hello but not less than ten seconds, unless it 334 is reset by management or rebooted before that. This is a change 335 to [RFC6325] which states that an RBridge port configured as 336 point-to-point ignores LAN Hellos and such a port configured as 337 LAN ignores point-to-point Hellos. 339 o RBridge Ethernet ports are required to monitor ports for BPDUs 340 received (Section 4.9.3 [RFC6325]). On receipt of a customer 341 bridging BPDU at an RBridge port, the RBridge MUST stop using 342 Compact Format on that port and revert to sending General Format 343 TRILL Data frames for at least four times the Bridge Hello Time in 344 the BPDU, but not less than ten seconds, unless the port or 345 RBridge is reset by management or rebooted before that. 347 o It is RECOMMENDED that RBridge ports intending to use Compact 348 Format also use the Link Layer Discovery Protocol (LLDP) [802.1AB] 349 to provide additional assurance that the link is actually point- 350 to-point. For this use, LLDP should be run to the Nearest Customer 351 Bridge MAC address (01-80-C2-00-00-00). Receipt by an RBridge port 352 supporting LLDP of an LLDP message indicating the presence on the 353 link of a MAC Bridge, Layer 3 Router, or End Station indicates 354 that the link is not point-to-point and the RBridge MUST stop 355 using Compact Format on the port for at least twice the TTL in the 356 received LLDP frame but not less than ten second, unless the port 357 or RBridge is reset by management or rebooted before that. 359 3.2 RBridge Originated and Terminated Native Frames 361 There can be native frames originated by or intended for consumption 362 by an RBridge. Examples include SNMP over IP frames or RBridge 363 Channel frames [RFC7178]. In many cases, such internal sinks and 364 sources of native frames are treated as a virtual end-station 365 internally attached to the RBridge. Such frames are converted to 366 TRILL Data frames before being transmitted outside the originating 367 RBridge. 369 Because of the way that Compact Format TRILL Data frames are 370 recognized, particularly the change in [RFC6325], Section 4.6.2, 371 Point 3, made by Section 3.3.1 of this document, an RBridge MUST use 372 a MAC address different from the address of any of its ports as the 373 Inner.MacSA of frames it locally originates and as the Inner.MacDA it 374 expects to see in unicast TRILL Data frames that it receives and 375 decapsulates for locally processing. 377 3.3 Compact TRILL Data Reception and Transmission 379 If an RBridge's Ethernet port has Compact Format enabled, frame 380 reception and transmission are modified as described below. 382 Section 4.6 of the TRILL base protocol standard [RFC6325] provides a 383 specification of the processing of all possible types of received 384 frames. TRILL frames are any frame starting with the TRILL or L2-IS- 385 IS or RBridge-Channel Ethertype or that has an Outer.MacDA that is 386 any of the block of 16 multicast addresses assigned to TRILL 387 ([RFC6325] Section 7.2). 389 3.3.1 Compact TRILL Data Frame Reception 391 Section 4.6.2 of [RFC6325] specifies the processing of received TRILL 392 frames. A complete replacement for Section 4.6.2 of [RFC6325] that 393 supports Compact Format and incorporates the correction in Section 394 5.1.2 of [RFC7780] is provided in the quoted text below. 396 Even when Compact Format is enabled, the sender is not required to 397 compact all or any TRILL Data frames and a receiver MUST be prepared 398 for an arbitrary mix of Compact Format and General Format TRILL Data 399 frames arriving on a point-to-point link. 401 NOTE: All of the Section references in the quoted text below are 402 references to Sections in [RFC6325]. 404 "A TRILL frame either has the TRILL or L2-IS-IS Ethertype or has a 405 multicast Outer.MacDA allocated to TRILL (see Section 7.2). The 406 following tests are performed sequentially, and the first that 407 matches controls the handling of the frame:" 409 "By default a frame is classified as General Format." 411 "1. If the Ethertype is L2-IS-IS and the Outer.MacDA is either 412 All-IS-IS-RBridges or the unicast MAC address of the 413 receiving RBridge port, the frame is handled as described in 414 Section 4.6.2.1 on TRILL Control frames." 416 "2. If the Outer.MacDA is a multicast address allocated to TRILL 417 other than All-RBridges then the frame is discarded." 419 "3. If the Outer.MacDA is a unicast address other than the 420 address of the receiving Rbridge then (3a) if Compact Format 421 TRILL Data frames are disabled, the frame is discarded or 422 (3b) if Compact Format TRILL Data frames are enabled, the 423 frame is classified as compact." 425 "4. If the Ethertype is not TRILL, the frame is discarded." 427 "5. If the Version field in the TRILL Header is greater than 0, 428 the frame is discarded." 430 "6. If the hop count is 0, the frame is discarded." 432 "7. If the Outer.MacDA is multicast and the M bit is zero the 433 frame is discarded. If the Outer.MacDA is unicast and M bit 434 is one processing continues if Specific Addressing is 435 enabled. If Specific Addressing is not enabled, the frame is 436 discarded." 438 "8. If the frame has been classified as Compact Format, skip the 439 rest of this rule and go to Rule 9. By default, an RBridge 440 MUST discard General Format TRILL Data frames from a 441 Outer.MacSA that is not an adjacency on the port where the 442 frame was received. RBridges MAY be configured per port to 443 accept such frames in cases where it is known that a non- 444 peering device (such as an end-station) is configured to 445 originate general TRILL encapsulated data frames that can be 446 safely accepted." 448 "9. If a frame has been classified as a Compact Format TRILL Data 449 frame but it was received untagged, that is, without an 450 Outer.VLAN, discard the frame." 452 "10. For all subsequent processing, including Rule 11, if the 453 frame has been classified as Compact Format, all references 454 to Inner.MacDA, Inner.MacSA, or Inner.VLAN are to be 455 understood to actually refer to the Outer.MacDA, Outer.MacSA, 456 and Outer.VLAN as the frame was received." 458 "11. The Inner.MacDA is then tested. If it is the All-Egress- 459 Rbridges (also known as All-ESADI-RBridges) multicast address 460 and RBn implements the ESADI protocol, processing proceeds as 461 in Section 4.6.2.2 for TRILL ESADI frames. If it is any other 462 address or RBn does not implement ESADI, processing proceeds 463 as in Section 4.6.2.3 for TRILL Data frames." 465 3.3.2 Compact TRILL Data Frame Transmission 467 When a TRILL Data frame is being transmitted out an RBridge port, if 468 the conditions listed in Section 3 above are met, the frame MAY be 469 sent in Compact Format. 471 3.4 Announcing Support for Compact Format 473 The Compact Format option is a hop-by-hop optional Ethernet link 474 TRILL frame format and it is possible that an RBridge would support 475 it on some ports and not others depending, for example, on port 476 hardware. Therefore, if Compact Format is enabled at a port, this is 477 indicated in every Hello (Section 6) it sends out that port. 479 4. Specific Addressing 481 Specific addressing optionally enables more efficient use of some 482 types of multi-access links. 484 4.1 Current Multi-Destination Addressing 486 When multiple RBridges are connected to an Ethernet link, the base 487 TRILL protocol standard [RFC6325] requires that multi-destination 488 TRILL Data frames be sent on the Ethernet link addressed to the All- 489 RBridges multicast address. 491 If the link is a multi-access link, such as a large bridged LAN, use 492 of a multicast address may impose a significant burden, causing the 493 frame to be flooded in the bridged LAN. In addition, all or many 494 stations attached to the bridged LAN may received the frame using up 495 some of their input bandwidth. Those TRILL switches that receive the 496 frame but are not the next hop on the frame's distribution tree will 497 discard the frame due to the Reverse Path Forwarding Check. 499 4.2 Specific Addressing Specification 501 Multi-destination TRILL Data frames are sent on the distribution tree 502 identified in the TRILL Header subject to optional pruning. The 503 transmitting RBridge thus knows which next hop RBridge or RBridges on 504 the link it needs to get the frame to. 506 If the next hop RBridges on the multi-access link and the 507 transmitting RBridge all have Specific Addressing enabled, then the 508 frame MAY be link unicast to the next hop RBridge or RBridges. 510 Use of Specific Addressing is a hop-by-hop optional decision. 511 Successive TRILL Data frames received by an RBridge, even from the 512 same sending RBridge on the same distribution tree, may be 513 specifically (unicast) or multicast addressed. (The same frame is 514 never sent both ways.) In successive RBridge to RBridge hops, a 515 multi-destination TRILL Data frame might be sent alternately in 516 specifically addressed and multicast addressed form. 518 4.3 Announcing Support for Specific Addressing 520 The Specific Addressing option is a hop-by-hop optional format. It is 521 possible that an RBridge would support it on some ports and not 522 others. Therefore enablement of this option is indicated in every 523 TRILL Hello (see Section 6) sent on the port. 525 5. Interaction Between The Optimizations 527 Compact Format can only be used for TRILL Data frames on Ethernet 528 links that are point-to-point. Compact Format works under the 529 conditions specified above regardless of whether the frame is TRILL 530 unicast (M=0) or TRILL multi-destination (M=1). It sets the 531 Outer.MacDA, Outer.MacSA, and Outer.VLAN to the corresponding Inner 532 fields and removes the Inner fields. 534 Specific Addressing is only beneficial for frames that are TRILL 535 multi-destination Data frames on multi-access links. Specific 536 Addressing causes the frame to be link unicast by setting the 537 Outer.MacDA to the unicast address of a next hop RBridge. 539 Both optimizations change the Outer.MacDA from its value in the base 540 TRILL protocol and thus they conflict. Specific Addressing MUST NOT 541 be used on point-to-point Ethernet links. This avoids conflict. 543 6. IANA Considerations 545 IANA is requested to allocate two capability bits in the TRILL-PORT- 546 VER sub-TLV [RFC7176] as follows: 548 Bit Description Reference 549 ====== ============================== ================= 550 tbd1 Compact Ethernet enabled. (This document) 551 tbd2 Specific addressing enabled. (This document) 553 7. Security Considerations 555 For general TRILL protocol security considerations, see [RFC6325]. 556 See other security considerations below. 558 7.1 Compact Format Security Considerations 560 An RBridge conformant to the TRILL standard that has Compact Format 561 TRILL Data not implemented or not enabled on a port will, as part of 562 its normal procedures, discard any Compact Format TRILL Data frame it 563 receives on that port because the EtherType of the frame would be 564 TRILL but (1) if the Compact Format resulted in a unicast 565 Outer.MacDA, it would not be the address of the receiving RBridge 566 port, and (2) if the Compact Format resulted in a multicast or 567 broadcast Outer.MacDA, it would not be the All-RBridges multicast 568 address. If the RBridge port failed to discard the frame and 569 erroneously handled it as being in General Format, bad things will 570 usually happen as described in Section 7.3. 572 With a General Format TRILL Data frame, the Data Label of the data is 573 somewhat protected in the Inner Label field. With Compact Format, it 574 is put in the more exposed Outer.VLAN field. If it is stripped, 575 perhaps by an intervening bridge, and the frame arrives untagged, the 576 rules in this document require that it be discarded to avoid changing 577 the labeling of the frame to the default of the receiving RBridge 578 port. 580 7.2 Specific Addressing Security Considerations 582 It is important not to apply both Compact Format optimization and 583 Specific Addressing optimization to the same frame or else the frame 584 may be misinterpreted as described in Section 7.3. For this reasons, 585 use of Specific Addressing on point-to-point links, where it would 586 not provide an advantage anyway, is prohibited. 588 7.3 Results of Frame Misinterpretation 590 For frames that are misinterpreted due to circumstances described in 591 Sections 7.1 and 7.2, the first six bytes of the native frame content 592 will be treated as the Inner.MacDA, the next six bytes of that oontnt 593 as the Inner.MacSA, and the next four bytes as the Data Label. If the 594 Ethertype or the Data Label is not checked or some of the payload 595 data accidentally has the value of a valid tag Ethertype, the payload 596 may be delivered in the wrong VLAN violating security policy. For 597 this reason, the provisions of Sections 3 of this document should be 598 scrupulously enforced. 600 8. References 602 Normative and informative references for this document are given 603 below. 605 8.1 Normative References 607 [802.1AB] - IEEE, "IEEE Standard for Local and metropolitan area 608 networks / Station and Media Access Control Connectivity 609 Discovery", IEEE Std 802.1AB-2009, 17 September 2009. 611 [802.1Q] - IEEE, "IEEE Standard for Local and metropolitan area 612 networks / Virtual Bridged Local Area Networks", IEEE Std 613 802.1Q-2014, 2014. 615 [IS-IS] - ISO/IEC 10589:2002, Second Edition, "Intermediate System to 616 Intermediate System Intra-Domain Routing Exchange Protocol for 617 use in Conjunction with the Protocol for Providing the 618 Connectionless-mode Network Service (ISO 8473)", 2002. 620 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 621 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 622 March 1997, . 624 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 625 Ghanwani, "Routing Bridges (RBridges): Base Protocol 626 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 627 . 629 [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 630 and D. Dutt, "Transparent Interconnection of Lots of Links 631 (TRILL): Fine-Grained Labeling", RFC 7172, DOI 632 10.17487/RFC7172, May 2014, . 635 [RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, 636 D., and A. Banerjee, "Transparent Interconnection of Lots of 637 Links (TRILL) Use of IS-IS", RFC 7176, DOI 10.17487/RFC7176, 638 May 2014, . 640 [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 641 Ghanwani, A., and S. Gupta, "Transparent Interconnection of 642 Lots of Links (TRILL): Clarifications, Corrections, and 643 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 644 . 646 8.2 Informative References 648 [802-2014] - IEEE 802, "IEEE Standard for Local and Metropolitan Area 649 Networks / Overview and Architecture", 802-2014, 12 June 2014. 651 [802.1AE] - IEEE 802, "IEEE Standard for Local and metropolitan area 652 networks / Media Access Control (MAC) Security", 802.1AE-2006, 653 18 August 2006. 655 [802.3] - IEEE, "IEEE Standard for Information technology / 656 Telecommunications and information exchange between systems / 657 Local and metropolitan area networks / Specific requirements 658 Part 3: Carrier sense multiple access with collision detection 659 (CSMA/CD) access method and physical layer specifications", 660 IEEE Std 802.3-2012, 28 December 2012. 662 [RFC6361] - Carlson, J. and D. Eastlake 3rd, "PPP Transparent 663 Interconnection of Lots of Links (TRILL) Protocol Control 664 Protocol", RFC 6361, August 2011. 666 [RFC7177] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., 667 and V. Manral, "Transparent Interconnection of Lots of Links 668 (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 2014, 669 . 671 [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. 672 Ward, "Transparent Interconnection of Lots of Links (TRILL): 673 RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May 674 2014, . 676 Authors' Addresses 678 Radia Perlman 679 EMC 680 2010 256th Avenue NE, #200 681 Bellevue, WA 98007 USA 683 EMail: radia@alum.mit.edu 685 Donald E. Eastlake 3rd 686 Huawei Technologies 687 155 Beaver Street 688 Milford, MA 01757, USA 690 Phone: +1-508-333-2270 691 Email: d3e3e3@gmail.com 693 Yizhou Li 694 Huawei Technologies 695 101 Software Avenue, 696 Nanjing 210012, China 698 Phone: +86-25-56622310 699 Email: liyizhou@huawei.com 701 Anoop Ghanwani 702 Dell 703 350 Holger Way 704 San Jose, CA 95134 USA 706 Phone: +1-408-571-3500 707 Email: anoop@alumni.duke.edu 709 Copyright and IPR Provisions 711 Copyright (c) 2017 IETF Trust and the persons identified as the 712 document authors. All rights reserved. 714 This document is subject to BCP 78 and the IETF Trust's Legal 715 Provisions Relating to IETF Documents 716 (http://trustee.ietf.org/license-info) in effect on the date of 717 publication of this document. Please review these documents 718 carefully, as they describe your rights and restrictions with respect 719 to this document. Code Components extracted from this document must 720 include Simplified BSD License text as described in Section 4.e of 721 the Trust Legal Provisions and are provided without warranty as 722 described in the Simplified BSD License. The definitive version of 723 an IETF Document is that published by, or under the auspices of, the 724 IETF. Versions of IETF Documents that are published by third parties, 725 including those that are translated into other languages, should not 726 be considered to be definitive versions of IETF Documents. The 727 definitive version of these Legal Provisions is that published by, or 728 under the auspices of, the IETF. Versions of these Legal Provisions 729 that are published by third parties, including those that are 730 translated into other languages, should not be considered to be 731 definitive versions of these Legal Provisions. For the avoidance of 732 doubt, each Contributor to the IETF Standards Process licenses each 733 Contribution that he or she makes as part of the IETF Standards 734 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 735 language to the contrary, or terms, conditions or rights that differ 736 from or are inconsistent with the rights and licenses granted under 737 RFC 5378, shall have any effect and shall be null and void, whether 738 published or posted by such Contributor, or included with or in such 739 Contribution.