Internet DRAFT - draft-perlman-trill-rbridge-data-encoding
draft-perlman-trill-rbridge-data-encoding
Network Working Group R. Perlman
Internet-Draft EMC
Updates: 6325 (if approved) D. Eastlake
Intended status: Standards Track Futurewei Technologies
Expires: 2 November 2023 Y. Li
Huawei Technologies
A. Ghanwani
Dell
1 May 2023
RBridges: TRILL Link Data Optimizations
draft-perlman-trill-rbridge-data-encoding-10
Abstract
TRILL (TRansparent Interconnection of Lots of Links) Data frames can
be encoded so as to make more efficient use of communications links
under certain circumstances. This document specifies two such
optional optimizations. One, called Compact Format, improves the
compactness of encoding where a TRILL link is a point-to-point
Ethernet link. The other, called Specific Addressing, optionally
decreases the burden on multi-access TRILL links for multi-
destination TRILL Data frames. This document updates RFC 6325.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 2 November 2023.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Perlman, et al. Expires 2 November 2023 [Page 1]
Internet-Draft TRILL: Link Data Optimization May 2023
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Structure of This Document . . . . . . . . . . . . . . . 3
1.2. Terminology Used in This Document . . . . . . . . . . . . 3
2. TRILL Frame Formats . . . . . . . . . . . . . . . . . . . . . 4
2.1. The General TRILL Frame Format . . . . . . . . . . . . . 4
2.2. Ethernet Link TRILL Data Frame General Encapsulation . . 5
3. Compact Format for Point-to-Point Ethernet Links . . . . . . 6
3.1. Conditions for Using Compact Format . . . . . . . . . . . 7
3.2. RBridge Originated and Terminated Native Frames . . . . . 8
3.3. Compact TRILL Data Reception and Transmission . . . . . . 9
3.3.1. Compact TRILL Data Frame Reception . . . . . . . . . 9
3.3.2. Compact TRILL Data Frame Transmission . . . . . . . . 10
3.4. Announcing Support for Compact Format . . . . . . . . . . 11
4. Specific Addressing . . . . . . . . . . . . . . . . . . . . . 11
4.1. Current Multi-Destination Addressing . . . . . . . . . . 11
4.2. Specific Addressing Specification . . . . . . . . . . . . 11
4.3. Announcing Support for Specific Addressing . . . . . . . 12
5. Interaction Between The Optimizations . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7.1. Compact Format Security Considerations . . . . . . . . . 13
7.2. Specific Addressing Security Considerations . . . . . . . 13
7.3. Results of Frame Misinterpretation . . . . . . . . . . . 13
8. Normative References . . . . . . . . . . . . . . . . . . . . 13
9. Informative References . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
TRILL switches (also called RBridges (Routing Bridges)) are devices
that support the IETF TRILL (TRansparent Interconnection of Lots of
Links) protocol [RFC6325] [RFC7177] [RFC7780]. They provide
transparent forwarding of frames in multi-hop networks with arbitrary
topology and link technology using least cost paths for unicast
traffic, support VLANs (Virtual Local Area Networks) and 24-bit Fine
Grained Labels [RFC7172], and support the multipathing of both
unicast and multi-destination traffic. They accomplish this by use
Perlman, et al. Expires 2 November 2023 [Page 2]
Internet-Draft TRILL: Link Data Optimization May 2023
of a hop count and IS-IS (Intermediate System to Intermediate System)
link state routing [IS-IS] [RFC7176].
A link between two TRILL switches in a TRILL campus can be any of a
variety of technologies, ranging from a complex bridged LAN to PPP
[RFC6361]. In the general case under the base TRILL protocol
[RFC6325], a TRILL Data frame consists of an inner payload formatted
as an Ethernet frame, preceded by a TRILL Header, and then
encapsulated by a link envelope appropriate for the link technology.
1.1. Structure of This Document
Section 2 discusses General Format TRILL Data frames without the
enhancements specified in this document.
In the case where the link is a point-to-point Ethernet link, an
optional Compact Format is specified for TRILL Data frames that saves
16 bytes. Section 3 specifies that format, its processing, and the
conditions for its safe use.
In the case where a multi-destination TRILL Data frame is being
forwarded over a multi-access link with multiple ports connected but
there is only one (or perhaps a few) next hop TRILL switches of
interest, optional Specific Addressing allows the TRILL Data frame to
be link unicast. This can substantially reduce the burden that frame
represents if, for example, the link is a complex bridged LAN through
which the frame might otherwise be flooded. Section 4 specifies the
Specific Addressing enhancement and the conditions for its safe use.
Section 5 discusses potential interaction between these two
enhancements. The remaining Sections after Section 5 provide IANA
and Security Considerations, References, and the like.
This document updates [RFC6325].
1.2. Terminology Used in This Document
The terminology and acronyms defined in [RFC6325] are used herein
with the same meaning. In particular, the terms "campus", "native
frame", "link", etc., are as defined [RFC6325].
"Point-to-point", as used herein, means a link which appears to be an
isolated channel between exactly two TRILL switch ports. Such a link
may not include customer bridges but may include hubs/repeaters, Two
Port MAC Relays, Provider Bridges, Provider Back Bone Bridges
[IEEE.802.1Q_2014], or other technology, provided that technology is
configured to provide a transparent point-to-point path between the
end point RBridge ports.
Perlman, et al. Expires 2 November 2023 [Page 3]
Internet-Draft TRILL: Link Data Optimization May 2023
References herein to "VLAN Tag" or the like are to customer VLANs (C-
Tags, Ethertype 0x8100). Use of S-Tags, also known as Service Tags,
or stacked VLAN or other tags is beyond the scope of this document
but is an obvious extension.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. TRILL Frame Formats
The subsections below provide a description of the general format of
TRILL Data frames. It then narrows in to describe the format of
TRILL Data frames on Ethernet links.
2.1. The General TRILL Frame Format
The general "on-the-wire" form of TRILL frames is illustrated below.
The Link Headers and Trailers in the formats below depend on the
specific link technology. The Link Header contains one or more
fields that distinguish TRILL Data from TRILL IS-IS. For example,
over Ethernet, the TRILL Data Link Header ends with the TRILL
Ethertype while the TRILL IS-IS frame Link Header ends with the L2-
IS-IS Ethertype; on the other hand, over PPP, there are no Ethertypes
but PPP protocol codes perform that function [RFC6361].
A TRILL Data frame in transit between two neighboring RBridges is as
shown below:
+---------------+----------+----------------+---------------+
| TRILL Data | TRILL | Payload | TRILL Data |
| Link Header | Header | Native Frame | Link Trailer |
+---------------+----------+----------------+---------------+
Figure 1: Format of TRILL Data Frames
In the above diagram, the Payload Native Frame is in a restricted
Ethernet frame format with a VLAN or FGL [RFC7172] label but with no
trailing Frame Check Sequence (FCS). The payload frame format is
shown below, assuming the payload starts with an Ethertype (it might
alternatively be LLC [IEEE802-2014] encoded or some other format):
+-----------+------------+--------+-----------+------------
| MAC Dest. | MAC Source | Label | Ethertype | ...
+-----------+------------+--------+-----------+------------
Perlman, et al. Expires 2 November 2023 [Page 4]
Internet-Draft TRILL: Link Data Optimization May 2023
Figure 2: Format of the Payload Frame
The encapsulated payload has the following fields in sequence:
* A 6-byte destination MAC address (Inner.MacDA)
* A 6-byte source MAC address (Inner.MacSA)
* An Inner.Label giving the VLAN ID or FGL [RFC7172], Priority, and
DEI (Drop Eligibility Indicator) [RFC7780] of the payload (use of
an S-tag or stacked tags is beyond the scope of this document but
is an obvious extension)
* The payload frame's content (which usually starts with an
Ethertype, such as the Ethertype for IPv4 or IPv6)
TRILL IS-IS frames are also sent between neighboring RBridges and
must be distinguished from TRILL Data frames. TRILL IS-IS frames are
formatted as follows and cannot use the Compact Format specified
herein:
+--------------+---------------+--------------+
| TRILL IS-IS | TRILL IS-IS | TRILL IS-IS |
| Link Header | Payload | Link Trailer |
+--------------+---------------+--------------+
Figure 3: TRILL IS-IS Frame
2.2. Ethernet Link TRILL Data Frame General Encapsulation
If the link between neighbor RBridges is Ethernet, then the general
TRILL Data frame format has the following link encapsulation:
Link Header: A 6-byte outer MAC destination address (Outer.MacDA)
followed by a 6-byte outer MAC source address (Outer.MacSA)
followed by an optional 4-byte outer VLAN tag Ethertype and value
(Outer.VLAN), and finally the 2-byte TRILL Ethertype (0x22F3).
Additional tags could be included after the outer MAC addresses
and before the TRILL Ethertype such a MACSEC [IEEE.802.1AE_2006].
Under the TRILL standard before this document, the Outer.MacDA was
required to be the unicast MAC address of the destination RBridge
port, if the TRILL Data frame was a unicast frame to a known
destination, and was required to be the All-RBridges multicast
address, if the TRILL Data frame was a multi- destination frame.
Perlman, et al. Expires 2 November 2023 [Page 5]
Internet-Draft TRILL: Link Data Optimization May 2023
+-----------+------------+- - - - - +-----------+
| MAC Dest. | MAC Source | VLAN Tag | TRILL |
| Address | Address | if Req. | Ethertype |
+-----------+------------+ - - - - -+-----------+
Figure 4: TRILL Data Link Header on an Ethernet Link
Link Trailer: The 32-bit IEEE [IEEE.802.3_2012] Frame Check Sequence
(FCS).
In the General Format for Ethernet links, the Outer.VLAN can be
omitted when it is not required by VLAN sensitive equipment in the
link.
3. Compact Format for Point-to-Point Ethernet Links
TRILL Data frames may optionally be sent using a Compact Format that
compresses the headers involved if the link is a point-to-point
Ethernet link, Compact Format can be enabled by both RBridges on the
link if other conditions met as listed below.
The Compact Format is simple: the Outer.MacDA, Outer.MacSA, and
Outer.VLAN are replaced by the Inner.MacDA, Inner.MacSA, and Inner
Label and the Inner fields are deleted. This saves 6 + 6 + 4 or 16
bytes. To avoid confusion, Compact Format MUST NOT be used if the
Inner.MacDA is a multi-cast address assigned to TRILL
(01-80-C2-00-00-40 through 01-80-C2-00-00-4F).
Compact Format is not applicable to TRILL IS-IS frames because there
is no inner Ethernet header. (And, of course, Compact Format is not
applicable to native frames or Layer 2 Ethernet control frames since
those frames are not TRILL frames.)
+---------------------+--------+-----------+---------+---------+
| Ethernet Header | TRILL | Content | Content | Link |
| Header from Payload | Header | Ethertype | ... | Trailer |
+---------------------+--------+-----------+---------+---------+
Figure 5: Compact Format TRILL Data Frame
Compact Format is generally intended for use on point-to-point
Ethernet links between RBridges, a common arrangement in many LANs.
However, if there are any transparent devices in the apparent point-
to-point link, such as Provider Bridges or Provider Backbone Bridges,
then the use of the Compact Format will increase the MAC address
learning table stress on such Provider Bridges or Provider Edge Back
Bone bridges.
Perlman, et al. Expires 2 November 2023 [Page 6]
Internet-Draft TRILL: Link Data Optimization May 2023
3.1. Conditions for Using Compact Format
Use of Compact Format is a hop-by-hop decision. In successive
RBridge to RBridge hops, a TRILL Data frame might be sent alternately
in Compact Format and General Format.
There are a number of conditions, listed below, for using Compact
Format TRILL Data frames. Most of these boil down to maximizing the
assurance that the RBridge-to-RBridge Ethernet link over which the
Compact Format TRILL Data frame is to be sent is really point-to-
point. Only the General Format for TRILL Data frames is safe to use
on an RBridge Ethernet port that is to a multi-access link even if
the ports between which it is being sent have been configured as
point-to-point ports. (See also the frame reception process
variations described in Section 3.3.1.)
* The RBridge Ethernet port over which Compact Format TRILL Data
frames are to be sent MUST be configured as an IS=IS point-to-
point port (see Section 4.9.1 of [RFC6325]).
* The RBridge port through which the Compact Format TRILL Data frame
is being transmitted MUST be configured to send VLAN/FGL tagged
frames. Otherwise the Data Label of the payload will be lost
(unless it just happens to be the default VLAN ID of the receiving
port).
* The RBridge port at the other end of the link MUST be announcing
that it supports the Compact Format. See Section 3.4.
* Receipt of a native frame indicates that the link is multi-access
and has end stations on it. These are frames that are not Layer 2
control frames (see Section 1.4 of [RFC6325]) and have neither an
Outer.MacDA in the block assigned to TRILL nor an outer payload
EtherType assigned to/for TRILL (currently the TRILL, L2-IS-IS,
and RBridge-Channel [RFC7178] EtherTypes). On receipt of such a
frame, the port MUST stop using Compact Format TRILL Data frames
for at least ten seconds, unless it is reset by management or
rebooted before that.
* The sending RBridge MUST have exactly one adjacency in the Report
state on the link and no other adjacencies in any state but Down
[RFC7177]. Thus, receipt of a TRILL IS-IS Hello frame, other than
one of the correct type (point-to-point or LAN) from the RBridge
believed to be at the other end of the link, indicates that the
link really isn't point-to-point or that the RBridge at the other
end of that link is mis-behaving. In either case, the RBridge
receiving such an unexpected Hello MUST stop using Compact Format
TRILL Data frames on that port for at least twice the holding time
Perlman, et al. Expires 2 November 2023 [Page 7]
Internet-Draft TRILL: Link Data Optimization May 2023
in the unexpected Hello but not less than ten seconds, unless it
is reset by management or rebooted before that. This is a change
to [RFC6325] which states that an RBridge port configured as
point-to-point ignores LAN Hellos and such a port configured as
LAN ignores point-to-point Hellos.
* RBridge Ethernet ports are required to monitor ports for BPDUs
received (Section 4.9.3 [RFC6325]). On receipt of a customer
bridging BPDU at an RBridge port, the RBridge MUST stop using
Compact Format on that port and revert to sending General Format
TRILL Data frames for at least four times the Bridge Hello Time in
the BPDU, but not less than ten seconds, unless the port or
RBridge is reset by management or rebooted before that.
* It is RECOMMENDED that RBridge ports intending to use Compact
Format also use the Link Layer Discovery Protocol (LLDP)
[IEEE.802.1AB_2009] to provide additional assurance that the link
is actually point-to-point. For this use, LLDP should be run to
the Nearest Customer Bridge MAC address (01-80-C2-00-00-00).
Receipt by an RBridge port supporting LLDP of an LLDP message
indicating the presence on the link of a MAC Bridge, Layer 3
Router, or End Station indicates that the link is not point-to-
point and the RBridge MUST stop using Compact Format on the port
for at least twice the TTL in the received LLDP frame but not less
than ten second, unless the port or RBridge is reset by management
or rebooted before that.
3.2. RBridge Originated and Terminated Native Frames
There can be native frames originated by or intended for consumption
by an RBridge. Examples include SNMP over IP frames or RBridge
Channel frames [RFC7178]. In many cases, such internal sinks and
sources of native frames are treated as a virtual end-station
internally attached to the RBridge. Such frames are converted to
TRILL Data frames before being transmitted outside the originating
RBridge.
Because of the way that Compact Format TRILL Data frames are
recognized, particularly the change in [RFC6325], Section 4.6.2,
Point 3, made by Section 3.3.1 of this document, an RBridge MUST use
a MAC address different from the address of any of its ports as the
Inner.MacSA of frames it locally originates and as the Inner.MacDA it
expects to see in unicast TRILL Data frames that it receives and
decapsulates for locally processing.
Perlman, et al. Expires 2 November 2023 [Page 8]
Internet-Draft TRILL: Link Data Optimization May 2023
3.3. Compact TRILL Data Reception and Transmission
If an RBridge's Ethernet port has Compact Format enabled, frame
reception and transmission are modified as described below.
Section 4.6 of the TRILL base protocol standard [RFC6325] provides a
specification of the processing of all possible types of received
frames. TRILL frames are any frame starting with the TRILL or L2-IS-
IS or RBridge-Channel Ethertype or that has an Outer.MacDA that is
any of the block of 16 multicast addresses assigned to TRILL
([RFC6325] Section 7.2).
3.3.1. Compact TRILL Data Frame Reception
Section 4.6.2 of [RFC6325] specifies the processing of received TRILL
frames. A complete replacement for Section 4.6.2 of [RFC6325] that
supports Compact Format and incorporates the correction in
Section 5.1.2 of [RFC7780] is provided in the quoted text below.
Even when Compact Format is enabled, the sender is not required to
compact all or any TRILL Data frames and a receiver MUST be prepared
for an arbitrary mix of Compact Format and General Format TRILL Data
frames arriving on a point-to-point link.
NOTE: All of the Section references in the quoted text below are
references to Sections in [RFC6325].
"A TRILL frame either has the TRILL or L2-IS-IS Ethertype or has a
multicast Outer.MacDA allocated to TRILL (see Section 7.2). The
following tests are performed sequentially, and the first that
matches controls the handling of the frame:"
"By default, a frame is classified as General Format."
" 1. If the Ethertype is L2-IS-IS and the Outer.MacDA is either
All-IS-IS-RBridges or the unicast MAC address of the receiving
RBridge port, the frame is handled as described in Section 4.6.2.1
on TRILL Control frames."
" 2. If the Outer.MacDA is a multicast address allocated to TRILL
other than All-RBridges then the frame is discarded."
" 3. If the Outer.MacDA is a unicast address other than the
address of the receiving Rbridge then (3a) if Compact Format TRILL
Data frames are disabled, the frame is discarded or (3b) if
Compact Format TRILL Data frames are enabled, the frame is
classified as compact."
Perlman, et al. Expires 2 November 2023 [Page 9]
Internet-Draft TRILL: Link Data Optimization May 2023
" 4. If the Ethertype is not TRILL, the frame is discarded."
" 5. If the Version field in the TRILL Header is greater than 0,
the frame is discarded."
" 6. If the hop count is 0, the frame is discarded."
" 7. If the Outer.MacDA is multicast and the M bit is zero the
frame is discarded. If the Outer.MacDA is unicast and M bit is
one processing continues if Specific Addressing is enabled. If
Specific Addressing is not enabled, the frame is discarded."
" 8. If the frame has been classified as Compact Format, skip the
rest of this rule and go to Rule 9. By default, an RBridge MUST
discard General Format TRILL Data frames from a Outer.MacSA that
is not an adjacency on the port where the frame was received.
RBridges MAY be configured per port to accept such frames in cases
where it is known that a non- peering device (such as an end-
station) is configured to originate general TRILL encapsulated
data frames that can be safely accepted."
" 9. If a frame has been classified as a Compact Format TRILL
Data frame but it was received untagged, that is, without an
Outer.VLAN, discard the frame."
"10. For all subsequent processing, including Rule 11, if the
frame has been classified as Compact Format, all references to
Inner.MacDA, Inner.MacSA, or Inner.VLAN are to be understood to
actually refer to the Outer.MacDA, Outer.MacSA, and Outer.VLAN as
the frame was received."
"11. The Inner.MacDA is then tested. If it is the All-Egress-
Rbridges (also known as All-ESADI-RBridges) multicast address and
RBn implements the ESADI protocol, processing proceeds as in
Section 4.6.2.2 for TRILL ESADI frames. If it is any other
address or RBn does not implement ESADI, processing proceeds as in
Section 4.6.2.3 for TRILL Data frames."
3.3.2. Compact TRILL Data Frame Transmission
When a TRILL Data frame is being transmitted out an RBridge port, if
the conditions listed in Section 3 above are met, the frame MAY be
sent in Compact Format.
Perlman, et al. Expires 2 November 2023 [Page 10]
Internet-Draft TRILL: Link Data Optimization May 2023
3.4. Announcing Support for Compact Format
The Compact Format option is a hop-by-hop optional Ethernet link
TRILL frame format and it is possible that an RBridge would support
it on some ports and not others depending, for example, on port
hardware. Therefore, if Compact Format is enabled at a port, this is
indicated in every Hello (Section 6) it sends out that port.
4. Specific Addressing
Specific addressing optionally enables more efficient use of some
types of multi-access links.
4.1. Current Multi-Destination Addressing
When multiple RBridges are connected to an Ethernet link, the base
TRILL protocol standard [RFC6325] requires that multi-destination
TRILL Data frames be sent on the Ethernet link addressed to the All-
RBridges multicast address.
If the link is a multi-access link, such as a large, bridged LAN, use
of a multicast address may impose a significant burden, causing the
frame to be flooded in the bridged LAN. In addition, all or many
stations attached to the bridged LAN may receive the frame using up
some of their input bandwidth. Those TRILL switches that receive the
frame but are not the next hop on the frame's distribution tree will
discard the frame due to the Reverse Path Forwarding Check.
4.2. Specific Addressing Specification
Multi-destination TRILL Data frames are sent on the distribution tree
identified in the TRILL Header subject to optional pruning. The
transmitting RBridge thus knows which next hop RBridge or RBridges on
the link it needs to get the frame to.
If the next hop RBridges on the multi-access link and the
transmitting RBridge all have Specific Addressing enabled, then the
frame MAY be link unicast to the next hop RBridge or RBridges.
Use of Specific Addressing is a hop-by-hop optional decision.
Successive TRILL Data frames received by an RBridge, even from the
same sending RBridge on the same distribution tree, may be
specifically (unicast) or multicast addressed. (The same frame is
never sent both ways.) In successive RBridge to RBridge hops, a
multi-destination TRILL Data frame might be sent alternately in
specifically addressed and multicast addressed form.
Perlman, et al. Expires 2 November 2023 [Page 11]
Internet-Draft TRILL: Link Data Optimization May 2023
4.3. Announcing Support for Specific Addressing
The Specific Addressing option is a hop-by-hop optional format. It
is possible that an RBridge would support it on some ports and not
others. Therefore, enablement of this option is indicated in every
TRILL Hello (see Section 6) sent on the port.
5. Interaction Between The Optimizations
Compact Format can only be used for TRILL Data frames on Ethernet
links that are point-to-point. Compact Format works under the
conditions specified above regardless of whether the frame is TRILL
unicast (M=0) or TRILL multi-destination (M=1). It sets the
Outer.MacDA, Outer.MacSA, and Outer.VLAN to the corresponding Inner
fields and removes the Inner fields.
Specific Addressing is only beneficial for frames that are TRILL
multi-destination Data frames on multi-access links. Specific
Addressing causes the frame to be link unicast by setting the
Outer.MacDA to the unicast address of a next hop RBridge.
Both optimizations change the Outer.MacDA from its value in the base
TRILL protocol and thus they conflict. Specific Addressing MUST NOT
be used on point-to-point Ethernet links. This avoids conflict.
6. IANA Considerations
IANA is requested to allocate two capability bits in the TRILL-PORT-
VER sub-TLV [RFC7176] as follows:
+======+==============================+=================+
| Bit | Description | Reference |
+======+==============================+=================+
| tbd1 | Compact Ethernet enabled. | (This document) |
+------+------------------------------+-----------------+
| tbd2 | Specific addressing enabled. | (This document) |
+------+------------------------------+-----------------+
Table 1
7. Security Considerations
For general TRILL protocol security considerations, see [RFC6325].
See other security considerations below.
Perlman, et al. Expires 2 November 2023 [Page 12]
Internet-Draft TRILL: Link Data Optimization May 2023
7.1. Compact Format Security Considerations
An RBridge conformant to the TRILL standard that has Compact Format
TRILL Data not implemented or not enabled on a port will, as part of
its normal procedures, discard any Compact Format TRILL Data frame it
receives on that port because the EtherType of the frame would be
TRILL but (1) if the Compact Format resulted in a unicast
Outer.MacDA, it would not be the address of the receiving RBridge
port, and (2) if the Compact Format resulted in a multicast or
broadcast Outer.MacDA, it would not be the All-RBridges multicast
address. If the RBridge port failed to discard the frame and
erroneously handled it as being in General Format, bad things will
usually happen as described in Section 7.3.
With a General Format TRILL Data frame, the Data Label of the data is
somewhat protected in the Inner Label field. With Compact Format, it
is put in the more exposed Outer.VLAN field. If it is stripped,
perhaps by an intervening bridge, and the frame arrives untagged, the
rules in this document require that it be discarded to avoid changing
the labeling of the frame to the default of the receiving RBridge
port.
7.2. Specific Addressing Security Considerations
It is important not to apply both Compact Format optimization and
Specific Addressing optimization to the same frame or else the frame
may be misinterpreted as described in Section 7.3. For this reason,
use of Specific Addressing on point-to-point links, where it would
not provide an advantage, is prohibited.
7.3. Results of Frame Misinterpretation
For frames that are misinterpreted due to circumstances described in
Sections 7.1 and 7.2, the first six bytes of the native frame content
will be treated as the Inner.MacDA, the next six bytes of that
content as the Inner.MacSA, and the next four bytes as the Data
Label. If the Ethertype or the Data Label is not checked or some of
the payload data accidentally has the value of a valid tag Ethertype,
the payload may be delivered in the wrong VLAN violating security
policy. For this reason, the provisions of Sections 3 of this
document should be scrupulously enforced.
8. Normative References
[IEEE.802.1AB_2009]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks-- Station and Media Access Control Connectivity
Discovery", IEEE 802.1AB-2009,
Perlman, et al. Expires 2 November 2023 [Page 13]
Internet-Draft TRILL: Link Data Optimization May 2023
DOI 10.1109/ieeestd.2009.5251812, 18 September 2009,
<http://ieeexplore.ieee.org/servlet/
opac?punumber=5251688>.
[IEEE.802.1Q_2014]
IEEE, "IEEE Standard for Local and metropolitan area
networks--Bridges and Bridged Networks", IEEE 802.1Q-2014,
DOI 10.1109/ieeestd.2014.6991462, 18 December 2014,
<http://ieeexplore.ieee.org/servlet/
opac?punumber=6991460>.
[IS-IS] ISO/IEC, "Intermediate System to Intermediate System
Intra-Domain Routing Exchange Protocol for use in
Conjunction with the Protocol for Providing the
Connectionless-mode Network Service (ISO 8473)", ISO/
IEC 10589:2002, 2002.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
Ghanwani, "Routing Bridges (RBridges): Base Protocol
Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011,
<https://www.rfc-editor.org/info/rfc6325>.
[RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and
D. Dutt, "Transparent Interconnection of Lots of Links
(TRILL): Fine-Grained Labeling", RFC 7172,
DOI 10.17487/RFC7172, May 2014,
<https://www.rfc-editor.org/info/rfc7172>.
[RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt,
D., and A. Banerjee, "Transparent Interconnection of Lots
of Links (TRILL) Use of IS-IS", RFC 7176,
DOI 10.17487/RFC7176, May 2014,
<https://www.rfc-editor.org/info/rfc7176>.
[RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A.,
Ghanwani, A., and S. Gupta, "Transparent Interconnection
of Lots of Links (TRILL): Clarifications, Corrections, and
Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016,
<https://www.rfc-editor.org/info/rfc7780>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Perlman, et al. Expires 2 November 2023 [Page 14]
Internet-Draft TRILL: Link Data Optimization May 2023
9. Informative References
[IEEE802-2014]
IEEE Computer Society, "IEEE Standard for Local and
Metropolitan Area Networks: Overview and Architecture",
IEEE Std 802-2014, 12 June 2014.
[IEEE.802.1AE_2006]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks: Media Access Control (MAC) Security", IEEE
802.1AE-2006, DOI 10.1109/ieeestd.2006.245590, 1 January
2001,
<http://ieeexplore.ieee.org/servlet/opac?punumber=11085>.
[IEEE.802.3_2012]
IEEE, "802.3-2012", IEEE 802.3-2012,
DOI 10.1109/ieeestd.2012.6419735, 24 January 2013,
<http://ieeexplore.ieee.org/servlet/
opac?punumber=6419733>.
[RFC6361] Carlson, J. and D. Eastlake 3rd, "PPP Transparent
Interconnection of Lots of Links (TRILL) Protocol Control
Protocol", RFC 6361, DOI 10.17487/RFC6361, August 2011,
<https://www.rfc-editor.org/info/rfc6361>.
[RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and
V. Manral, "Transparent Interconnection of Lots of Links
(TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May
2014, <https://www.rfc-editor.org/info/rfc7177>.
[RFC7178] Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D.
Ward, "Transparent Interconnection of Lots of Links
(TRILL): RBridge Channel Support", RFC 7178,
DOI 10.17487/RFC7178, May 2014,
<https://www.rfc-editor.org/info/rfc7178>.
Authors' Addresses
Radia Perlman
EMC
2010 256th Avenue NE, #200
Bellevue, Washington 98007
United States of America
Email: radia@alum.mit.edu
Perlman, et al. Expires 2 November 2023 [Page 15]
Internet-Draft TRILL: Link Data Optimization May 2023
Donald E. Eastlake, 3rd
Futurewei Technologies
2386 Panoramic Circle
Apopka, Florida 32703
United States of America
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Yizhou Li
Huawei Technologies
101 Software Avenue
Nanjing
Jiangsu, 210012
China
Phone: +86-25-56624584
Email: liyizhou@huawei.com
Anoop Ghanwani
Dell
350 Holger Way
San Jose, California 95134
United States of America
Phone: +1-408-571-3500
Email: anoop@alumni.duke.edu
Perlman, et al. Expires 2 November 2023 [Page 16]
