Network Working Group J. Schoenwaelder Request for Comments: 4789 International University Bremen Obsoletes: 1089 T. Jeffree Updates: 3417 Consultant Category: Standards Track November 2006
Simple Network Management Protocol (SNMP) over IEEE 802 Networks
Status of This Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2006).
Abstract
This document specifies how Simple Network Management Protocol (SNMP) messages can be transmitted directly over IEEE 802 networks.
This document specifies how Simple Network Management Protocol (SNMP) messages can be transmitted directly over IEEE 802 networks. For a detailed overview of the documents that describe the Internet- Standard management framework, please refer to section 7 of RFC 3410 [RFC3410]. This document supplements the standard SNMP transport mappings defined in RFC 3417 [RFC3417].
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
Send comments to <ietfmibs@ops.ietf.org>." DESCRIPTION "This MIB module defines the SNMP over IEEE 802 transport mapping.
Copyright (C) The IETF Trust (2006). This version of this MIB module is part of RFC 4789; see the RFC itself for full legal notices." REVISION "200611210000Z" DESCRIPTION "The initial version, published as RFC 4789." ::= { snmpModules 21 }
snmpIeee802Domain OBJECT-IDENTITY STATUS current DESCRIPTION "The SNMP over IEEE 802 networks transport domain. The corresponding transport address is of type MacAddress as defined in the SNMPv2-TC module (RFC 2579)." REFERENCE "RFC 2579" ::= { snmpDomains 6 } END
This is an optional transport mapping. The need to carry SNMP directly over an 802 LAN transport in order to allow for the management of simple devices was identified in applications like the Two-Port Media Access Control (MAC) Relay, which is being developed in IEEE 802.1 as project P802.1aj [802.1aj].
SNMP over IEEE 802 networks has some inherent restrictions. Using the SNMP over IEEE 802 transport mapping restricts messages to a single logical IEEE 802 LAN, bridged LAN or VLAN. Furthermore, only a single SNMP engine can be addressed on a given IEEE 802 network interface. In particular, command generators and notification receivers, as well as command responders and notification originators, must share a single transport endpoint.
SNMP messages are serialized, as described in Section 8 of RFC 3417 [RFC3417]. The resulting serialized message is shipped in the data portion of an IEEE LAN MAC frame.
Serialized SNMP messages are sent in IEEE 802.3 frames with an Ethernet type field of 33100 (hexadecimal 814C).
When serialized SNMP messages are sent in IEEE 802.3 frames (and in other IEEE 802 MAC frame types that can natively represent Ethernet type values), an Ethernet type field value of 33100 (hexadecimal 814C) MUST be used as the link layer protocol identifier. In IEEE 802 LANs that use LLC as the means of link layer protocol identification, such as IEEE 802.11 Wireless LANs, the SNAP encapsulation method described in subclause 10.5 "Encapsulation of Ethernet frames over LLC" in [IEEE802] MUST be used.
When an SNMP entity uses this transport mapping, it MUST be capable of accepting SNMP messages up to and including 484 octets in size. It is RECOMMENDED that implementations be capable of accepting messages of up to 1472 octets in size. Implementation of larger values is encouraged whenever possible.
Several core SNMP MIB modules use TDomain/TAddress pairs to identify SNMP transport endpoints. The SNMP-TARGET-MIB [RFC3413] uses TDomain/TAddress pairs to identify targets that can be used as notification receivers. TDomain/TAddress pairs are used by the NOTIFICATION-LOG-MIB [RFC3014] to record the source from which a notification was received. The ENTITY-MIB [RFC4133] uses TDomain/ TAddress pairs to provide the transport endpoint of logical entities.
The MIB module contained in this document introduces the object identifier constant snmpIeee802Domain. This constant can be assigned to an object of type TDomain to identify an SNMP over IEEE 802 endpoint, in which case the corresponding TAddress will have a value that conforms to the MacAddress textual convention. By providing these definitions, it is possible to use the generic MIB modules to refer to SNMP over IEEE 802 endpoints.
IANA made a MIB OID assignment under the snmpModules branch for the SNMP-IEEE802-TM-MIB module.
IANA assigned an OID value below snmpDomains for the transport domain. This first required the setup of a registry for OIDs under snmpDomains. At the point of this writing, the following assignments already exist:
This module does not define any management objects. Instead, it defines an OBJECT-IDENTIFIER which may be used by other MIB modules to identify an SNMP transport mapping. Meaningful security considerations can only be written in the MIB modules that define management objects. The MIB module in this document has therefore no impact on the security of the Internet.
SNMPv1 and SNMPv2c messages are not considered secure. It is recommended that the implementors consider the use of SNMPv3 messages and the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model STD 62, RFC 3414 [RFC3414] and the View-based Access Control Model STD 62, RFC 3415 [RFC3415] is recommended.
It is then a customer/user responsibility to ensure that the SNMP entity giving access to a MIB is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change) them.
The original SNMP over Ethernet definition was written by Marty Schoffstall, Chuck Davin, Mark Fedor, and Jeff Case, and published as RFC 1089 [RFC1089].
Bert Wijnen and Dan Romascanu provided guidance on many aspects of this revised specification. David Harrington provided useful comments that improved the presentation.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002.
Schoenwaelder & Jeffree Standards Track [Page 7]
RFC 4789 SNMP over IEEE 802 November 2006
[RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002.
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
[RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002.
[RFC3014] Kavasseri, R., "Notification Log MIB", RFC 3014, November 2000.
[RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)", RFC 4133, August 2005.
[RFC1089] Schoffstall, M., Davin, C., Fedor, M., and J. Case, "SNMP over Ethernet", RFC 1089, February 1989.
[802.1aj] P802.1aj/D1.4 Draft Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment 08: Two-Port Media Access Control (MAC) Relay, IEEE 802.1 Working Group, June 2006, Work in Progress.
Authors' Addresses
Juergen Schoenwaelder International University Bremen Campus Ring 1 28725 Bremen Germany
Tony Jeffree Consultant 11a Poplar Grove Sale, Cheshire, M33 3AX United Kingdom
Phone: +44-161-973-4278 EMail: tony@jeffree.co.uk
Schoenwaelder & Jeffree Standards Track [Page 8]
RFC 4789 SNMP over IEEE 802 November 2006
Full Copyright Statement
Copyright (C) The IETF Trust (2006).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.