doc: Add RFC documents

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]
+