summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4789.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4789.txt')
-rw-r--r--doc/rfc/rfc4789.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc4789.txt b/doc/rfc/rfc4789.txt
new file mode 100644
index 0000000..7a31074
--- /dev/null
+++ b/doc/rfc/rfc4789.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+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 obsoletes RFC 1089.
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 1.1. Key Words ..................................................2
+ 2. Definitions .....................................................3
+ 3. SNMP over IEEE 802 Networks .....................................4
+ 3.1. Serialization ..............................................4
+ 3.2. Well-known Values ..........................................4
+ 3.3. IEEE 802.3 Frame Format ....................................5
+ 4. Relationship to Other MIB Modules ...............................5
+ 5. IANA Considerations .............................................6
+ 6. Security Considerations .........................................6
+ 7. Acknowledgments .................................................7
+ 8. References ......................................................7
+ 8.1. Normative References .......................................7
+ 8.2. Informative References .....................................7
+
+
+
+
+
+
+Schoenwaelder & Jeffree Standards Track [Page 1]
+
+RFC 4789 SNMP over IEEE 802 November 2006
+
+
+1. Introduction
+
+ 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].
+
+ This document obsoletes RFC 1089.
+
+ 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].
+
+1.1. Key Words
+
+ 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].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schoenwaelder & Jeffree Standards Track [Page 2]
+
+RFC 4789 SNMP over IEEE 802 November 2006
+
+
+2. Definitions
+
+ SNMP-IEEE802-TM-MIB DEFINITIONS ::= BEGIN
+
+ IMPORTS
+ MODULE-IDENTITY, OBJECT-IDENTITY, snmpModules, snmpDomains
+ FROM SNMPv2-SMI;
+
+ snmpIeee802TmMib MODULE-IDENTITY
+ LAST-UPDATED "200611210000Z"
+ ORGANIZATION "IETF Operations and Management Area"
+ CONTACT-INFO
+ "Juergen Schoenwaelder (Editor)
+ International University Bremen
+ P.O. Box 750 561
+ 28725 Bremen, Germany
+
+ Phone: +49 421 200-3587
+ EMail: j.schoenwaelder@iu-bremen.de
+
+ 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
+
+
+
+
+
+
+
+
+
+Schoenwaelder & Jeffree Standards Track [Page 3]
+
+RFC 4789 SNMP over IEEE 802 November 2006
+
+
+3. SNMP over IEEE 802 Networks
+
+ 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.
+
+3.1. Serialization
+
+ 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.
+
+3.2. Well-known Values
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+Schoenwaelder & Jeffree Standards Track [Page 4]
+
+RFC 4789 SNMP over IEEE 802 November 2006
+
+
+3.3. IEEE 802.3 Frame Format
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Destination |
+ +- -+
+ | Ethernet |
+ +- -+
+ | Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Source |
+ +- -+
+ | Ethernet |
+ +- -+
+ | Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |1 0 0 0 0 0 0 1 0 1 0 0 1 1 0 0|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | SNMP |
+ +- -+
+ / message ... /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ (Each tic mark represents one bit.)
+
+4. Relationship to Other MIB Modules
+
+ 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.
+
+
+
+
+
+
+
+
+Schoenwaelder & Jeffree Standards Track [Page 5]
+
+RFC 4789 SNMP over IEEE 802 November 2006
+
+
+5. IANA Considerations
+
+ 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:
+
+ Prefix: iso.org.dod.internet.snmpv2.snmpDomains (1.3.6.1.6.1)
+
+ Decimal Name Description References
+ ------- ---- ----------- ----------
+ 1 snmpUDPDomain SNMP over UDP [RFC3417]
+ 2 snmpCLNSDomain SNMP over CLNS [RFC3417]
+ 3 snmpCONSDomain SNMP over CONS [RFC3417]
+ 4 snmpDDPDomain SNMP over DDP [RFC3417]
+ 5 snmpIPXDomain SNMP over IPX [RFC3417]
+
+ The following assigment has been made:
+
+ Decimal Name Description References
+ ------- ---- ----------- ----------
+ 6 snmpIeee802Domain SNMP over IEEE 802 RFC 4789
+
+ For new assignments, a specification is required as per [RFC2434].
+
+6. Security Considerations
+
+ 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.
+
+
+
+Schoenwaelder & Jeffree Standards Track [Page 6]
+
+RFC 4789 SNMP over IEEE 802 November 2006
+
+
+7. Acknowledgments
+
+ 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.
+
+8. References
+
+8.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [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.
+
+ [RFC3417] Presuhn, R., Ed., "Transport Mappings for the Simple
+ Network Management Protocol (SNMP)", STD 62, RFC 3417,
+ December 2002.
+
+ [IEEE802] "IEEE Standard for Local Area Networks: Overview and
+ Architecture", IEEE Std. 802-2001.
+
+ [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+ October 1998.
+
+8.2. Informative References
+
+ [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
+
+ Phone: +49 421 200-3587
+ EMail: j.schoenwaelder@iu-bremen.de
+
+
+ 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.
+
+
+
+
+
+
+Schoenwaelder & Jeffree Standards Track [Page 9]
+