From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4789.txt | 507 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 507 insertions(+) create mode 100644 doc/rfc/rfc4789.txt (limited to 'doc/rfc/rfc4789.txt') 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 ." + 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] + -- cgit v1.2.3