the multicast bit is the least significant bit of the first octet
of the address.
If the system wishes to announce its MAC address, it sends the
option with its MAC address specified. When specifying a non-zero
MAC address in a Configure-Request, any inclusion of this option
in a Configure-Nak MUST be ignored.
If the implementation wishes to have a MAC address assigned, it
sends the option with a MAC address of 00-00-00-00-00-00. Systems
that have no mechanism for address assignment will Configure-
Reject the option.
A Configure-Nak MUST specify a valid IEEE 802.1 format physical
address; the multicast bit MUST be zero. It is strongly
recommended (although not mandatory) that the "locally assigned
address" bit (the second least significant bit in the first octet)
be set, indicating a locally assigned address.
A summary of the MAC-Address Option format is shown below. The
fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |MAC byte 1 |L|M| MAC byte 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC byte 3 | MAC byte 4 | MAC byte 5 | MAC byte 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
6
Length
8
MAC Byte
Six octets of MAC address in 802.1 Canonical order. For clarity,
the position of the Local Assignment (L) and Multicast (M) bits
are shown in the diagram.
5.6. Spanning-Tree-Protocol (old format)
Description
The Spanning-Tree-Protocol Configuration enables a Bridge to
remain compatible with older implementations of BCP [10]. This
configuration option is, however, incompatible with the
Management-Inline option, which enables a bridge to implement the
many protocols that IEEE now expects a bridge to be able to use.
If the peer rejects the Management-Inline configuration option, by
sending configure-reject, it must be an implementation of [10],
which is described in Appendix A. The system may optionally
terminate the negotiation or offer to negotiate in that manner.
In this case, if both bridges support a spanning tree protocol,
they MUST agree on the protocol to be supported. The old BPDU
described in Appendix A MUST be used rather than the format shown
in section 4.2 or 4.3. When the two disagree, the lower-numbered
of the two spanning tree protocols should be used. To resolve the
conflict, the system with the lower-numbered protocol SHOULD
Configure-Nak the option, suggesting its own protocol for use. If
a spanning tree protocol is not agreed upon, except for the case
in which one system does not support any spanning tree protocol,
the Bridging Control Protocol MUST NOT enter the Opened state.
Most systems will only participate in a single spanning tree
protocol. If a system wishes to participate simultaneously in
more than one spanning tree protocol, it MAY include all of the
appropriate protocol types in a single Spanning-Tree-Protocol
Configuration Option. The protocol types MUST be specified in
increasing numerical order. For the purpose of comparison during
negotiation, the protocol numbers MUST be considered to be a
single number. For instance, if System A includes protocols 01
and 03 and System B indicates protocol 03, System B should
Configure-Nak and indicate a protocol type of 03 since 0103 is
greater than 03.
By default, an implementation MUST either support the IEEE 802.1D
spanning tree or support no spanning tree protocol. An
implementation that does not support any spanning tree protocol
MUST silently discard any received IEEE 802.1D BPDU packets, and
MUST either silently discard or respond to other received BPDU
packets with an LCP Protocol-Reject packet in this case.
A summary of the Spanning-Tree-Protocol Option format is shown below.
The fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Protocol 1 | Protocol 2 | ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
7
Length
2 octets plus 1 additional octet for each protocol that will be
actively supported. Most systems will only support a single
spanning tree protocol, resulting in a length of 3.
Protocol n
Each Protocol field is one octet and indicates a desired spanning
tree protocol. Up-to-date values of the Spanning-Tree-Protocol
field are specified as PPP DLL numbers in the most recent
"Assigned Numbers" RFC[4]. Current values are assigned as
follows:
Value Protocol
0 Null (no Spanning Tree protocol supported)
1 IEEE 802.1D spanning tree
2 IEEE 802.1G extended spanning tree protocol
3 IBM Source Route Spanning tree protocol
4 DEC LANbridge 100 Spanning tree protocol
5.7. IEEE-802-Tagged-Frame
Description
This configuration option permits the implementation to indicate
support for IEEE 802 Tagged Frame. Negotiation of this option is
strongly recommended.
A device supporting IEEE 802 Tagged Frame must be willing to
support IEEE 802 Tagged Frame shown in section 4.3.
By default, IEEE 802 Tagged Frame is not supported. A system which
does not negotiate, or negotiates this option to be disabled,
should never receive a IEEE 802 Tagged Frame.
A summary of the IEEE 802 Tagged Frame Option format is shown below.
The fields are transmitted from left to right.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Enable/Disable|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
8
Length
3
Enable/Disable
If the value is 1, IEEE-802-Tagged-Frame is enabled. If the value
is 2, IEEE-802-Tagged-Frame is disabled, and MUST not send any
IEEE-802-Tagged-Frame packet.
5.8. Management-Inline
Description
The Management-Inline Configuration Option indicates that the
system is willing to receive any IEEE-defined inter-bridge
protocols, such as bridge protocol data units and GARP protocol
data units, in the frame format shown in section 4.2 or 4.3.
Old BCP [10] implementations will use the negotiation procedure
described in section 5.6. Implementations of this procedure will
use this option to indicate compliance with the new BCP and may
optionally negotiate the section 5.6 procedure, either on the same
configure-request or in response to a configure-reject, as well.
It is recommended that the configure-request only show this option
when it is relevant, and that it reply with the Spanning-Tree-
Protocol (old formatted) option if a configure-reject is received,
as in the normal case one can expect it to be the quickest
negotiation.
If a system receives a configure-request offering both
alternatives, it should accept this procedure and reject the
Spanning-Tree-Protocol (old format) option.
One can expect old BCP [10] implementations to not understand the
option and issue a configure-reject.
By default, Management-Inline is not allowed. A system which does
not negotiate, or negotiates this option to be disabled, should
never receive a Bridge Protocol data unit or GARP protocol data
unit inline.
A summary of the Management-Inline Option format is shown below.
The fields are transmitted from left to right.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
9
Length
2
6. Changes From RFC1638
This section enumerates changes made to old BCP [10] to produce this
document.
(1) Remove all LAN Identification descriptions and replace with IEEE
802.1Q VLAN descriptions.
(2) Remove LAN Identification field from frame format and I flags
from flag field.
(3) Merge the Spanning Tree BPDU frame format with Bridged traffic.
7. Security Considerations
This network control protocol compares the configurations of two
devices and seeks to negotiate an acceptable subset of their
intersection, to enable correct interoperation even in the presence
of minor configuration or implementation differences. In the event
that a major misconfiguration is detected, the negotiation will not
complete successfully, resulting in the link coming down or not
coming up. It is possible that if a bridged link comes up with a
rogue peer, network information may be learned from forwarded
multicast traffic, or denial of service attacks may be created by
closing loops that should be detected and isolated or by offering
rogue load.
Such attacks are not isolated to this NCP; any PPP NCP is subject to
attack when connecting to a foreign or compromised device. However,
no situations arise which are not common to all NCPs; any NCP that
comes up with a rogue peer is subject to snooping and other attacks.
Therefore, it is recommended that links on which this may happen
should be configured to use PPP authentication during the LCP start-
up phase.
8. Intellectual Property Notice
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can
be obtained from the IETF Secretariat."
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
9. IANA Considerations
This document proposes a total of two new BCP option numbers to be
maintained by the IANA. These options (described in Section 5.1 and
5.2) are IEEE-802-Tagged-Frame and Management-Inline. The IANA has
assigned the values 8 and 9 respectively for these option numbers.
10. Acknowledgments
This document is a product of the Point-to-Point Protocol Extensions
Working Group.
This document is based on the PPP Bridging Control Protocol, RFC1638
[10], edited by Rich Bowen of IBM and produced by the Point-to-Point
Protocol Extensions Working Group. It extends that document by
providing support for Virtual LANs as outlined in [9].
A. Spanning Tree Bridge PDU (old format)
By default, Spanning Tree BPDUs MUST be encoded with a MAC or 802.2
LLC header as described in section 4.2 or 4.3 of this document.
However, should the remote entity Configure-Reject the Management-
Inline option, thereby indicating that it is a purely RFC1638
compliant device, the local entity may subsequently encode BPDUs as
described in section 4.3 of RFC1638 provided that use of a suitable
non-NULL STP protocol across the link is successfully negotiated
using the (old) Spanning-Tree-Protocol option.
This is the Spanning Tree BPDU used in RFC1638, without any MAC or
802.2 LLC header (these being functionally equivalent to the Address,
Control, and PPP Protocol Fields). The LAN Pad and Frame Checksum
fields are likewise superfluous and absent.
The Address and Control Fields are subject to LCP Address-and-
Control-Field-Compression negotiation.
A PPP system which is configured to participate in a particular
spanning tree protocol and receives a BPDU of a different spanning
tree protocol SHOULD reject it with the LCP Protocol-Reject. A
system which is configured not to participate in any spanning tree
protocol MUST silently discard all BPDUs.
Spanning Tree Bridge PDU
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| HDLC FLAG |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address and Control | Spanning Tree Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BPDU data ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame FCS | HDLC FLAG |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address and Control
As defined by the framing in use.
Spanning Tree Protocol
Up-to-date values of the Spanning-Tree-Protocol field are
specified in the most recent "Assigned Numbers" RFC[4]. Current
values are assigned as follows:
Value (in hex) Protocol
0201 IEEE 802.1 (either 802.1D or 802.1G)
0203 IBM Source Route Bridge
0205 DEC LANbridge 100
The two versions of the IEEE 802.1 spanning tree protocol frames
can be distinguished by fields within the BPDU data.
BPDU data
As defined by the specified Spanning Tree Protocol.
B. Tinygram-Compression Pseudo-Code
PPP Transmitter:
if (ZeroPadCompressionEnabled &&
BridgedProtocolHeaderFormat == IEEE8023 &&
PacketLength == Minimum8023PacketLength) {
/*
* Remove any continuous run of zero octets preceding,
* but not including, the LAN FCS, but not extending
* into the MAC header.
*/
Set (ZeroCompressionFlag); /* Signal receiver */
if (is_Set (LAN_FCS_Present)) {
FCS = TrailingOctets (PDU, 4); /* Store FCS */
RemoveTrailingOctets (PDU, 4); /* Remove FCS */
while (PacketLength > 14 && /* Stop at MAC header or */
TrailingOctet (PDU) == 0) /* last non-zero octet */
RemoveTrailingOctets (PDU, 1);/* Remove zero octet */
Appendbuf (PDU, 4, FCS); /* Restore FCS */
}
else {
while (PacketLength > 14 && /* Stop at MAC header */
TrailingOctet (PDU) == 0) /* or last zero octet */
RemoveTrailingOctets (PDU, 1);/* Remove zero octet */
}
}
PPP Receiver:
if (ZeroCompressionFlag) { /* Flag set in header? */
/* Restoring packet to minimum 802.3 length */
Clear (ZeroCompressionFlag);
if (is_Set (LAN_FCS_Present)) {
FCS = TrailingOctets (PDU, 4); /* Store FCS */
RemoveTrailingOctets (PDU, 4); /* Remove FCS */
Appendbuf (PDU, 60 - PacketLength, zeroes);/* Add zeroes */
Appendbuf (PDU, 4, FCS); /* Restore FCS */
}
else {
Appendbuf (PDU, 60 - PacketLength, zeroes);/* Add zeroes */
}
}
References
[1] IBM, "Token-Ring Network Architecture Reference", 3rd edition,
September 1989.
[2] IEEE 802.1, "Draft Standard 802.1G: Remote MAC Bridging",
P802.1G/D7, December 30, 1992.
[3] IEEE 802.1D-1993, "Media Access Control (MAC) Bridges", ISO/IEC
15802-3:1993 ANSI/IEEE Std 802.1D, 1993 edition., July 1993.
[4] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC1700,
October 1994. See also: http://www.iana.org/numbers.html
[5] Simpson, W., "PPP LCP Extensions", RFC1570, January 1994.
[6] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
1661, July 1994.
[7] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti,
"The PPP Multilink Protocol (MP)", RFC1990, August 1996.
[8] IEEE 802.1D-1998, "Information technology - Telecommunications
and Information exchange between systems - Local and
metropolitan area networks - Common Specifications - Part 3:
Media Access Control (MAC) Bridges: Revision. This is a revision
of ISO/IEC 10038: 1993, 802.1j-1992 and 802.6k-1992. It
incorporates P802.11c, P802.1p and P802.12e." ISO/IEC 15802-3:
1998.
[9] IEEE 802.1Q, ANSI/IEEE Standard 802.1Q, "IEEE Standards for
Local and Metropolitan Area Networks: Virtual Bridged Local Area
Networks", 1998.
[10] Baker, F. and R. Bowen, "PPP Bridging Control Protocol (BCP)",
RFC1638, June 1994.
[11] Bormann, C., "The Multi-Class Extension to Multi-Link PPP", RFC
2686, September 1999.
[12] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March 1997.
Authors' Addresses
Questions about this memo can also be directed to:
Mitsuru Higashiyama
Anritsu Corporation
1800 Onna, Atsugi-shi, Kanagawa-prf., 243-8555 Japan
Phone: +81 (46) 296-6625
EMail: Mitsuru.Higashiyama@yy.anritsu.co.jp
Fred Baker
519 Lado Drive
Santa Barbara, California 93111
EMail: fred.baker@cisco.com
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.