协议分析网

　　RFC2358, in turn, is almost completely based on both the Standard Ethernet MIB, RFC1643 [21], and the Proposed Standard Ethernet MIB using the SNMPv2 SMI, RFC1650 [22], both of which were edited by Frank Kastenholz of FTP Software and produced by the Interfaces MIB Working Group. RFC2358 extends those documents by providing support for 100 Mb/sec ethernet interfaces. RFC1643 and RFC1650, in turn, are based on the Draft Standard Ethernet MIB, RFC1398 [20], also edited by Frank Kastenholz and produced by the Ethernet MIB Working Group. RFC1398, in turn, is based on the Proposed Standard Ethernet MIB, RFC1284 [18], which was edited by John Cook of Chipcom and produced by the Transmission MIB Working Group. The Ethernet MIB Working Group gathered implementation experience of the variables specified in RFC1284, documented that experience in RFC1369 [19], and used that information to develop this revised MIB. RFC1284, in turn, is based on a document written by Frank Kastenholz, then of Interlan, entitled IEEE 802.3 Layer Management Draft M compatible MIB for TCP/IP Networks [17]. This document was modestly reworked, initially by the SNMP Working Group, and then by the Transmission Working Group, to reflect the current conventions for defining objects for MIB interfaces. James Davin, of the MIT Laboratory for Computer Science, and Keith McCloghrie of Hughes LAN Systems, contributed to later drafts of this memo. Marshall Rose of Performance Systems International, Inc. converted the document into RFC1212 [3] concise format. Anil Rijsinghani of DEC contributed text that more adequately describes the TDR test. Thanks to Frank Kastenholz of Interlan and Louis Steinberg of IBM for their experimentation. 7. References [1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC2571, May 1999. [2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC1212, March 1991. [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC1215, March 1991. [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC2578, April 1999. [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC2579, April 1999. [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC2580, April 1999. [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC1157, May 1990. [9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC1901, January 1996. [10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC1906, January 1996. [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC2572, May 1999. [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC2574, May 1999. [13] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC1905, January 1996. [14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, May 1999. [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC2575, May 1999. [16] IEEE, IEEE Std 802.3, 1998 Edition: "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications" (incorporating ANSI/IEEE Std. 802.3, 1996 Edition, IEEE Std. 802.3r-1996, 802.3u-1995, 802.3x&y-1997, 802.3z-1998, and 802.3aa-1998), September 1998. [17] Kastenholz, F., "IEEE 802.3 Layer Management Draft compatible MIB for TCP/IP Networks", electronic mail message to mib- wg@nnsc.nsf.net, 9 June 1989. [18] Cook, J., "Definitions of Managed Objects for Ethernet-Like Interface Types", RFC1284, December 1991. [19] Kastenholz, F., "Implementation Notes and Experience for The Internet Ethernet MIB", RFC1369, October 1992. [20] Kastenholz, F., "Definitions of Managed Objects for the Ethernet-like Interface Types", RFC1398, January 1993. [21] Kastenholz, F., "Definitions of Managed Objects for the Ethernet-like Interface Types", STD 50, RFC1643, July 1994. [22] Kastenholz, F., "Definitions of Managed Objects for the Ethernet-like Interface Types using SMIv2", RFC1650, August 1994. [23] Flick, J. and J. Johnson, "Definitions of Managed Objects for the Ethernet-like Interface Types", RFC2358, June 1998. [24] McCloghrie, K. and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC1213, March 1991. [25] McCloghrie, K., and F. Kastenholz, "The Interfaces Group MIB using SMIv2", RFC2233, November 1997. [26] Bradner, S., "Key words for use in RFCs to Indicate Requirements Levels", BCP 14, RFC2119, March 1997. [27] Smith, A., Flick, J., deGraaf, K., Romascanu, D., McMaster, D., McCloghrie, K. and S. Roberts, "Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)", RFC2668, August 1999. [28] Flick, J., "Definitions of Object Identifiers for Identifying Ethernet Chip Sets", RFC2666, August 1999. 8. Security Considerations There are two management objects defined in this MIB that have a MAX-ACCESS clause of read-write. 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. There are a number of managed objects in this MIB that may be considered to contain sensitive information. In particular, the dot3StatsEtherChipSet object may be considered sensitive in many environments, since it would allow an intruder to obtain information about which vendor's equipment is in use on the network. Note that this object has been deprecated. However, some implementors may still choose to implement it for backwards compatability. Therefore, it may be important in some environments to control read access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. Not all versions of SNMP provide features for such a secure environment. SNMPv1 by itself is such an insecure environment. 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 (read) the objects in this MIB. It is recommended that the implementors consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC2574 [12] and the View-based Access Control Model RFC2575 [15] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to those objects only to those principals (users) that have legitimate rights to access them. 9. Authors' Addresses John Flick Hewlett-Packard Company 8000 Foothills Blvd. M/S 5557 Roseville, CA 95747-5557 Phone: +1 916 785 4018 EMail: johnf@rose.hp.com Jeffrey Johnson RedBack Networks 2570 North First Street, Suite 410 San Jose, CA, 95131, USA Phone: +1 408 571 2699 EMail: jeff@redbacknetworks.com A. Change Log A.1. Changes since RFC2358 This section enumerates changes made to RFC2358 to produce this document. (1) Section 2 has been replaced with the current SNMP Management Framework boilerplate. (2) The ifMtu mapping has been clarified. (3) The relationship between the IEEE 802.3 octet counters and the IF-MIB octet counters has been clarified. (4) REFERENCE clauses have been updated to reflect the actual IEEE 802.3 managed object that each MIB object is based on. (5) The following object DESCRIPTION clauses have been updated to reflect that they do not increment in full-duplex mode: dot3StatsSingleCollisionFrames, dot3StatsMultipleCollisionFrames, dot3StatsSQETestErrors, dot3StatsDeferredTransmissions, dot3StatsLateCollisions, dot3StatsExcessiveCollisions, dot3StatsCarrierSenseErrors, dot3CollFrequencies. (6) The following object DESCRIPTION clauses have been updated to reflect behaviour on full-duplex and 1000 Mb/s interfaces: dot3StatsAlignmentErrors, dot3StatsFCSErrors, dot3StatsSQETestErrors, dot3StatsLateCollisions, dot3StatsSymbolErrors. (7) Two new tables, dot3ControlTable and dot3PauseTable, have been added. (8) A new object, dot3StatsDuplexStatus, has been added. (9) The object groups and compliances have been restructured. (10) The dot3StatsEtherChipSet object has been deprecated. (11) The dot3ChipSets have been moved to a separate document. A.2. Changes between RFC1650 and RFC2358 This section enumerates changes made to RFC1650 to produce RFC2358. (1) The MODULE-IDENTITY has been updated to reflect the changes in the MIB. (2) A new object, dot3StatsSymbolErrors, has been added. (3) The definition of the object dot3StatsIndex has been converted to use the SMIv2 OBJECT-TYPE macro. (4) A new conformance group, etherStats100MbsGroup, has been added. (5) A new compliance statement, ether100MbsCompliance, has been added. (6) The Acknowledgements were extended to provide a more complete history of the origin of this document. (7) The discussion of ifType has been expanded. (8) A section on mapping of Interfaces MIB objects has been added. (9) A section defining the relationship of this MIB to the MAU MIB has been added. (10) A section on the mapping of IEEE 802.3 managed objects to this MIB and the Interfaces MIB has been added. (11) Converted the dot3Tests, dot3Errors, and dot3ChipSets OIDs to use the OBJECT-IDENTITY macro. (12) Added to the list of registered dot3ChipSets. (13) An intellectual property notice and copyright notice were added, as required by RFC2026. B. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFCEditor function is currently provided by the Internet Society.