DESCRIPTION
"A collection of objects providing per-port packet
statistics for all VLANs currently configured on this
device for high-capacity interfaces, defined as those
that have the value of the corresponding instance of
ifSpeed greater than 650,000,000 bits/second."
::= { qBridgeGroups 11 }
qBridgeLearningConstraintsGroup OBJECT-GROUP
OBJECTS {
dot1qConstraintType,
dot1qConstraintStatus
}
STATUS current
DESCRIPTION
"A collection of objects defining the Filtering Database
constraints all VLANs have with each other."
::= { qBridgeGroups 12 }
qBridgeLearningConstraintDefaultGroup OBJECT-GROUP
OBJECTS {
dot1qConstraintSetDefault,
dot1qConstraintTypeDefault
}
STATUS current
DESCRIPTION
"A collection of objects defining the default Filtering
Database constraints for VLANs that have no specific
constraints defined."
::= { qBridgeGroups 13 }
qBridgeClassificationDeviceGroup OBJECT-GROUP
OBJECTS {
dot1vProtocolGroupId,
dot1vProtocolGroupRowStatus
}
STATUS current
DESCRIPTION
"VLAN classification information for the bridge."
::= { qBridgeGroups 14 }
qBridgeClassificationPortGroup OBJECT-GROUP
OBJECTS {
dot1vProtocolPortGroupVid,
dot1vProtocolPortRowStatus
}
STATUS current
DESCRIPTION
"VLAN classification information for individual ports."
::= { qBridgeGroups 15 }
qBridgePortGroup2 OBJECT-GROUP
OBJECTS {
dot1qPvid,
dot1qPortAcceptableFrameTypes,
dot1qPortIngressFiltering,
dot1qPortGvrpStatus,
dot1qPortGvrpFailedRegistrations,
dot1qPortGvrpLastPduOrigin,
dot1qPortRestrictedVlanRegistration
}
STATUS current
DESCRIPTION
"A collection of objects providing port-level VLAN
control and status information for all ports."
::= { qBridgeGroups 16 }
-- -------------------------------------------------------------
-- compliance statements
-- -------------------------------------------------------------
qBridgeCompliance MODULE-COMPLIANCE
STATUS deprecated
DESCRIPTION
"The compliance statement for device support of Virtual
LAN Bridge services.
RFC2674 was silent about the expected persistence of the
read-write objects in this MIB module. Applications MUST
NOT assume that the values of the read-write objects are
persistent across reinitializations of the management
system and MUST NOT assume that the values are not
persistent across reinitializations of the management
system."
MODULE
MANDATORY-GROUPS {
qBridgeBaseGroup,
qBridgeVlanGroup,
qBridgeVlanStaticGroup,
qBridgePortGroup
}
GROUP qBridgeFdbUnicastGroup
DESCRIPTION
"This group is mandatory for bridges that implement
802.1Q transparent bridging."
GROUP qBridgeFdbMulticastGroup
DESCRIPTION
"This group is mandatory for bridges that implement
802.1Q transparent bridging."
GROUP qBridgeServiceRequirementsGroup
DESCRIPTION
"This group is mandatory for bridges that implement
extended filtering services. All objects must be
read-write if extended-filtering services are
enabled."
GROUP qBridgeFdbStaticGroup
DESCRIPTION
"This group is optional."
GROUP qBridgeVlanStatisticsGroup
DESCRIPTION
"This group is optional as there may be significant
implementation cost associated with its support."
GROUP qBridgeVlanStatisticsOverflowGroup
DESCRIPTION
"This group is optional as there may be significant
implementation cost associated with its support. It is most
relevant for high-capacity interfaces where the SNMP agent
supports only SNMPv1."
GROUP qBridgeVlanHCStatisticsGroup
DESCRIPTION
"This group is optional as there may be significant
implementation cost associated with its support. It is most
relevant for high-capacity interfaces."
GROUP qBridgeLearningConstraintsGroup
DESCRIPTION
"This group is mandatory for devices implementing
both Independent VLAN Learning (IVL) and Shared
VLAN Learning (SVL) modes of operation of the
filtering database, as defined by IEEE 802.1Q."
GROUP qBridgeLearningConstraintDefaultGroup
DESCRIPTION
"This group is mandatory for devices implementing
both Independent VLAN Learning (IVL) and Shared
VLAN Learning (SVL) modes of operation of the
filtering database, as defined by IEEE 802.1Q."
OBJECT dot1qPortAcceptableFrameTypes
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required as this is an optional
capability in IEEE 802.1Q."
OBJECT dot1qPortIngressFiltering
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required as this is an optional
capability in IEEE 802.1Q."
OBJECT dot1qConstraintSetDefault
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required as this is an optional
capability in IEEE 802.1Q."
OBJECT dot1qConstraintTypeDefault
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required as this is an optional
capability in IEEE 802.1Q."
::= { qBridgeCompliances 1 }
qBridgeCompliance2 MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for device support of Virtual
LAN Bridge services.
This document clarifies the persistence requirements for
the read-write objects in this MIB module. All
implementations claiming compliance to qBridgeCompliance2
MUST retain the values of those read-write objects that
specify this requirement."
MODULE
MANDATORY-GROUPS {
qBridgeBaseGroup,
qBridgeVlanGroup,
qBridgeVlanStaticGroup,
qBridgePortGroup2
}
GROUP qBridgeFdbUnicastGroup
DESCRIPTION
"This group is mandatory for bridges that implement
802.1Q transparent bridging."
GROUP qBridgeFdbMulticastGroup
DESCRIPTION
"This group is mandatory for bridges that implement
802.1Q transparent bridging."
GROUP qBridgeServiceRequirementsGroup
DESCRIPTION
"This group is mandatory for bridges that implement
extended filtering services. All objects must be
read-write if extended-filtering services are
enabled."
GROUP qBridgeFdbStaticGroup
DESCRIPTION
"This group is optional."
GROUP qBridgeVlanStatisticsGroup
DESCRIPTION
"This group is optional as there may be significant
implementation cost associated with its support."
GROUP qBridgeVlanStatisticsOverflowGroup
DESCRIPTION
"This group is optional as there may be significant
implementation cost associated with its support. It is most
relevant for high-capacity interfaces where the SNMP agent
supports only SNMPv1."
GROUP qBridgeVlanHCStatisticsGroup
DESCRIPTION
"This group is optional as there may be significant
implementation cost associated with its support. It is most
relevant for high-capacity interfaces."
GROUP qBridgeLearningConstraintsGroup
DESCRIPTION
"This group is mandatory for devices implementing
both Independent VLAN Learning (IVL) and Shared
VLAN Learning (SVL) modes of operation of the
filtering database, as defined by IEEE 802.1Q."
GROUP qBridgeLearningConstraintDefaultGroup
DESCRIPTION
"This group is mandatory for devices implementing
both Independent VLAN Learning (IVL) and Shared
VLAN Learning (SVL) modes of operation of the
filtering database, as defined by IEEE 802.1Q."
GROUP qBridgeClassificationDeviceGroup
DESCRIPTION
"This group is mandatory ONLY for devices implementing
VLAN Classification as specified in IEEE 802.1v."
GROUP qBridgeClassificationPortGroup
DESCRIPTION
"This group is mandatory ONLY for devices implementing
VLAN Classification as specified in IEEE 802.1v."
OBJECT dot1qPortAcceptableFrameTypes
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required as this is an optional
capability in IEEE 802.1Q."
OBJECT dot1qPortIngressFiltering
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required as this is an optional
capability in IEEE 802.1Q."
OBJECT dot1qConstraintSetDefault
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required as this is an optional
capability in IEEE 802.1Q."
OBJECT dot1qConstraintTypeDefault
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required as this is an optional
capability in IEEE 802.1Q."
OBJECT dot1vProtocolGroupId
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required as this is an optional
capability in IEEE 802.1v."
OBJECT dot1vProtocolGroupRowStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required as this is an optional
capability in IEEE 802.1v."
::= { qBridgeCompliances 2 }
END
6. Acknowledgements
Much of the groundwork for this document was performed by the IEEE
802.1 working group during the definition of the IEEE 802.1D updates
[802.1D] and IEEE 802.1Q [802.1Q].
The authors wish to thank the members of the Bridge Working Group,
and David Harrington, Anders SW Christensen, Andrew Smith, Paul
Langille, Anil Rijhsinghani, and Keith McCloghrie in particular for
their comments and suggestions, which improved this effort.
Editing for the final version was done by David Levi.
The new textual conventions related to VLAN-IDs were produced as a
result of a review of the use of VLAN-ID in several MIB modules.
Further investigation found that VLAN-ID objects were defined in a
few other MIB modules. The editor would like to thank all who
contributed to the discussion that resulted in these new textual
conventions. Specifically, Bert Wijnen, Les Bell, Andrew Smith, Mike
Heard, Randy Presuhn, Dan Romascanu, Eduardo Cardona, Tom Petch,
Juergen Schoenwaelder, Richard Woundy, Tony Jeffree, and William
Murwin. We also received input and feedback from IEEE confirming
that the values 0 and 4095 are not used for identifying a specific
VLAN-ID and so can be used to represent none or a wildcard (see
Appendix A).
7. Security Considerations
There are a number of management objects defined in this MIB module
with a MAX-ACCESS clause of read-write and/or read-create. Such
objects may be considered sensitive or vulnerable in some network
environments. The support for SET operations in a non-secure
environment without proper protection can have a negative effect on
network operations. These tables and objects and their
sensitivity/vulnerability are described below.
The following tables and objects in the P-BRIDGE-MIB can be
manipulated to interfere with the operation of priority classes.
This could, for example, be used to force a reinitialization of state
machines, thus causing network instability. Another possibility
would be for an attacker to override established policy on port
priorities, thus giving a user (or an attacker) unauthorized
preferential treatment.
dot1dTrafficClassesEnabled
dot1dGmrpStatus
dot1dPortPriorityTable
dot1dUserPriorityRegenTable
dot1dTrafficClassTable
dot1dPortGarpTable
dot1dPortGmrpTable
The following tables and objects in the Q-BRIDGE-MIB could be
manipulated to interfere with the operation of virtual LANs. This
could, for example, be used to force a reinitialization of state
machines to cause network instability, or changing the forwarding and
filtering policies.
dot1qGvrpStatus
dot1qForwardAllTable
dot1qStaticUnicastTable
dot1qStaticMulticastTable
dot1qVlanStaticTable
dot1qPortVlanTable
dot1qLearningConstraintsTable
dot1vProtocolGroupTable
dot1vProtocolPortTable
Some of the readable objects in this MIB module (i.e., objects with a
MAX-ACCESS other than not-accessible) may be considered sensitive or
vulnerable in some network environments. It is thus important to
control even GET and/or NOTIFY access to these objects and possibly
to even encrypt the values of these objects when sending them over
the network via SNMP. These are the tables and objects and their
sensitivity/vulnerability.
The objects dot1dDeviceCapabilities and dot1dPortCapabilitiesTable in
the P-BRIDGE-MIB could be used by an attacker to determine which
attacks might be useful to attempt against a given device.
The following read-only tables and objects in the Q-BRIDGE-MIB could
be used by an attacker to determine which attacks might be useful to
attempt against a given device, could be used by an attacker to
detect whether their attacks are being blocked or filtered, or could
be used to understand the logical topology of the network.
dot1qMaxVlanID
dot1qMaxSupportedVlans
dot1qNumVlans
dot1qFdbTable
dot1qTpFdbTable
dot1qTpGroupTable
dot1qVlanCurrentTable
dot1qPortVlanStatisticsTable
SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example by using IPSec),
even then, there is no control as to who on the secure network is
allowed to access and GET/SET (read/change/create/delete) the objects
in this MIB module.
It is RECOMMENDED that implementers consider the security features as
provided by the SNMPv3 framework (see [RFC3410], section 8),
including full support for the SNMPv3 cryptographic mechanisms (for
authentication and privacy).
Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
enable cryptographic security. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to an
instance of this MIB module is properly configured to give access to
the objects only to those principals (users) that have legitimate
rights to indeed GET or SET (change/create/delete) them.
8. Normative References
[BRIDGE-MIB] Norseth, K. and E. Bell, "Definitions of Managed Objects
for Bridges", RFC 4188, September 2005.
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Structure of Management Information Version 2 (SMIv2)",
STD 58, RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Textual Conventions for SMIv2", STD 58, RFC 2579, April
1999.
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999.
[RFC2674] Bell, E., Smith, A., Langille, P., Rijhsinghani, A., and
K. McCloghrie, "Definitions of Managed Objects for
Bridges with Traffic Classes, Multicast Filtering and
Virtual LAN Extensions", RFC 2674, August 1999.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000.
[RFC3418] Presuhn, R., "Management Information Base (MIB) for the
Simple Network Management Protocol (SNMP)", STD 62, RFC
3418, December 2002.
[802.1D] "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.
[802.1Q] ANSI/IEEE Standard 802.1Q, "IEEE Standards for Local and
Metropolitan Area Networks: Virtual Bridged Local Area
Networks", 2003.
[802.1t] IEEE 802.1t-2001, "(Amendment to IEEE Standard 802.1D)
IEEE Standard for Information technology -
Telecommunications and information exchange between
systems - Local and metropolitan area networks - Common
specifications - Part 3: Media Access Control (MAC)
Bridges: Technical and Editorial Corrections".
[802.1u] IEEE 802.1u-2001, "(Amendment to IEEE Standard 802.1Q)
IEEE Standard for Local and metropolitan area networks -
Virtual Bridged Local Area Networks - Amendment 1:
Technical and Editorial Corrections".
[802.1v] IEEE 802.1v-2001, "(Amendment to IEEE Standard 802.1Q)
IEEE Standards for Local and Metropolitan Area Networks:
Virtual Bridged Local Area Networks--Amendment 2: VLAN
Classification by Protocol and Port".
9. Informative References
[RFC1493] Decker, E., Langille, P., Rijsinghani, A. and K.
McCloghrie, "Definitions of Managed Objects for
Bridges", RFC 1493, July 1993.
[RFC4323] Patrick, M. and W. Murwin, "Data Over Cable System
Interface Specification Quality of Service Management
Information Base (DOCSIS-QOS MIB)", RFC 4323, January
2006.
[RFC4149] Kalbfleisch, C., Cole, R., and D. Romascanu, "Definition
of Managed Objects for Synthetic Sources for Performance
Monitoring Algorithms", RFC 4149, August 2005.
[RFC2613] Waterman, R., Lahaye, B., Romascanu, D., and S.
Waldbusser, "Remote Network Monitoring MIB Extensions
for Switched Networks Version 1.0", RFC 2613, June 1999.
[RFC3318] Sahita, R., Hahn, S., Chan, K., and K. McCloghrie,
"Framework Policy Information Base", RFC 3318, March
2003.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for
Internet-Standard Management Framework", RFC 3410,
December 2002.
Appendix A. Email from Tony Jeffrey from IEEE
-----Original Message-----
From: Tony Jeffree [mailto:tony@jeffree.co.uk]
Sent: Friday, 6th of June 2003 17:16
To: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Subject: RE: VLAn ID
Bert et al -
We have concluded that the use of 4095 as a wildcard is acceptable
to 802.1, and we will make any necessary changes to 802.1Q in due
course to relax the current stated restriction. However, we need
to know whether that is all that needs to be done to 802.1Q - i.e.,
is there any need to change our definitions of the managed objects
in the document (Clause 12) to reflect the interpretation of 4095
as a wildcard, or is this simply an issue for the SNMP machinery
to handle?
Regards,
Tony
Authors’ Adresses
David Levi
Nortel Networks
4655 Great America Parkway
Santa Clara, CA 95054
USA
Phone: +1 865 686 0432
EMail: dlevi@nortel.com
David Harrington
Effective Software
50 Harding Rd.
Portsmouth, NH 03801
USA
Phone: +1 603 436 8634
EMail: ietfdbh@comcast.net
Vivian Ngai
Salt lake City, UT
USA
EMail: vivian_ngai@acm.org
Les Bell
Hemel Hempstead
Herts. HP2 7YU
UK
EMail: elbell@ntlworld.com
Andrew Smith
Beijing Harbour Networks
Jiuling Building
21 North Xisanhuan Ave.
Beijing, 100089
PRC
Fax: +1 415 345 1827
EMail: ah_smith@acm.org