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/rfc2864.txt | 619 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 619 insertions(+) create mode 100644 doc/rfc/rfc2864.txt (limited to 'doc/rfc/rfc2864.txt') diff --git a/doc/rfc/rfc2864.txt b/doc/rfc/rfc2864.txt new file mode 100644 index 0000000..c8b9023 --- /dev/null +++ b/doc/rfc/rfc2864.txt @@ -0,0 +1,619 @@ + + + + + + +Network Working Group K. McCloghrie +Request for Comments: 2864 Cisco Systems +Category: Standards Track G. Hanson + ADC Telecommunications + June 2000 + + + The Inverted Stack Table Extension to the Interfaces Group MIB + +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 Internet Society (2000). All Rights Reserved. + +Table of Contents + + 1 Introduction .................................................. 1 + 2 The SNMP Network Management Framework ......................... 1 + 3 Interface Sub-Layers and the ifStackTable ..................... 3 + 4 Definitions ................................................... 4 + 5 Acknowledgements .............................................. 7 + 6 References .................................................... 7 + 7 Security Considerations ....................................... 8 + 8 Authors' Addresses ............................................ 9 + 9 Notice on Intellectual Property ............................... 10 + 10 Full Copyright Statement ..................................... 11 + +1. Introduction + + This memo defines a portion of the Management Information Base (MIB) + for use with network management protocols in the Internet community. + In particular, it describes managed objects which provide an inverted + mapping of the interface stack table used for managing network + interfaces. + +2. The SNMP Network Management Framework + + The SNMP Management Framework presently consists of five major + components: + + + + + +McCloghrie & Hanson Standards Track [Page 1] + +RFC 2864 Inverted Stack Extension MIB June 2000 + + + o An overall architecture, described in RFC 2571 [1]. + + o Mechanisms for describing and naming objects and events for the + purpose of management. The first version of this Structure of + Management Information (SMI) is called SMIv1 and described in STD + 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The + second version, called SMIv2, is described in STD 58, which + consists of RFC 2578 [5], RFC 2579 [6] and RFC 2580 [7]. + + o Message protocols for transferring management information. The + first version of the SNMP message protocol is called SNMPv1 and + described in STD 15, RFC 1157 [8]. A second version of the SNMP + message protocol, which is not an Internet standards track + protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC + 1906 [10]. The third version of the message protocol is called + SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574 + [12]. + + o Protocol operations for accessing management information. The + first set of protocol operations and associated PDU formats is + described in STD 15, RFC 1157 [8]. A second set of protocol + operations and associated PDU formats is described in RFC 1905 + [13]. + + o A set of fundamental applications described in RFC 2573 [14] and + the view-based access control mechanism described in RFC 2575 + [15]. + + A more detailed introduction to the current SNMP Management Framework + can be found in RFC 2570 [18]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. Objects in the MIB are + defined using the mechanisms defined in the SMI. + + This memo specifies a MIB module that is compliant to the SMIv2. A + MIB conforming to the SMIv1 can be produced through the appropriate + translations. The resulting translated MIB must be semantically + equivalent, except where objects or events are omitted because no + translation is possible (e.g., use of Counter64). Some machine + readable information in SMIv2 will be converted into textual + descriptions in SMIv1 during the translation process. However, this + loss of machine readable information is not considered to change the + semantics of the MIB. + + + + + + + +McCloghrie & Hanson Standards Track [Page 2] + +RFC 2864 Inverted Stack Extension MIB June 2000 + + +3. Interface Sub-Layers and the ifStackTable + + MIB-II [16] defines objects for managing network interfaces by + providing a generic interface definition together with the ability to + define media-specific extensions. The generic objects are known as + the 'interfaces' group. + + Experience in defining media-specific extensions showed the need to + distinguish between the multiple sub-layers beneath the + internetwork-layer. Consider, for example, an interface with PPP + running over an HDLC link which uses a RS232-like connector. Each of + these sub-layers has its own media-specific MIB module. + + The latest definition of the 'interfaces' group in the IF-MIB [17] + satisfies this need by having each sub-layer be represented by its + own conceptual row in the ifTable. It also defines an additional MIB + table, the ifStackTable, to identify the "superior" and "subordinate" + sub-layers through ifIndex "pointers" to the appropriate conceptual + rows in the ifTable. + + Each conceptual row in the ifStackTable represents a relationship + between two interfaces, where this relationship is that the "higher- + layer" interface runs "on top" of the "lower-layer" interface. For + example, if a PPP module operated directly over a serial interface, + the PPP module would be a "higher layer" to the serial interface, and + the serial interface would be a "lower layer" to the PPP module. + This concept of "higher-layer" and "lower-layer" is the same as + embodied in the definitions of the ifTable's packet counters. + + The ifStackTable is INDEX-ed by the ifIndex values of the two + interfaces involved in the relationship. By necessity, one of these + ifIndex values must come first, and the IF-MIB chose to have the + higher-layer interface first, and the lower-layer interface second. + Due to this, it is straight-forward for a Network Management + application to read a subset of the ifStackTable and thereby + determine the interfaces which run underneath a particular interface. + However, to determine which interfaces run on top of a particular + interface, a Network Management application has no alternative but to + read the whole table. This is very inefficient when querying a + device which has many interfaces, and many conceptual rows in its + ifStackTable. + + This MIB provides an inverted Interfaces Stack Table, the + ifInvStackTable. While it contains no additional information beyond + that already contained in the ifStackTable, the ifInvStackTable has + the ifIndex values in its INDEX clause in the reverse order, i.e., + the lower-layer interface first, and the higher-layer interface + second. As a result, the ifInvStackTable is an inverted version of + + + +McCloghrie & Hanson Standards Track [Page 3] + +RFC 2864 Inverted Stack Extension MIB June 2000 + + + the same information contained in the ifStackTable. Thus, the + ifInvStackTable provides an efficient means for a Network Management + application to read a subset of the ifStackTable and thereby + determine which interfaces run on top of a particular interface. + +4. Definitions + +IF-INVERTED-STACK-MIB DEFINITIONS ::= BEGIN + +IMPORTS + MODULE-IDENTITY, OBJECT-TYPE, mib-2 FROM SNMPv2-SMI + RowStatus FROM SNMPv2-TC + MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF + ifStackGroup2, + ifStackHigherLayer, ifStackLowerLayer FROM IF-MIB; + +ifInvertedStackMIB MODULE-IDENTITY + LAST-UPDATED "200006140000Z" + ORGANIZATION "IETF Interfaces MIB Working Group" + CONTACT-INFO + " Keith McCloghrie + Cisco Systems, Inc. + 170 West Tasman Drive + San Jose, CA 95134-1706 + US + + 408-526-5260 + kzm@cisco.com" + DESCRIPTION + "The MIB module which provides the Inverted Stack Table for + interface sub-layers." + REVISION "200006140000Z" + DESCRIPTION + "Initial revision, published as RFC 2864" + ::= { mib-2 77 } + +ifInvMIBObjects OBJECT IDENTIFIER ::= { ifInvertedStackMIB 1 } + +-- +-- The Inverted Interface Stack Group +-- + +ifInvStackTable OBJECT-TYPE + SYNTAX SEQUENCE OF IfInvStackEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table containing information on the relationships between + + + +McCloghrie & Hanson Standards Track [Page 4] + +RFC 2864 Inverted Stack Extension MIB June 2000 + + + the multiple sub-layers of network interfaces. In + particular, it contains information on which sub-layers run + 'underneath' which other sub-layers, where each sub-layer + corresponds to a conceptual row in the ifTable. For + example, when the sub-layer with ifIndex value x runs + underneath the sub-layer with ifIndex value y, then this + table contains: + + ifInvStackStatus.x.y=active + + For each ifIndex value, z, which identifies an active + interface, there are always at least two instantiated rows + in this table associated with z. For one of these rows, z + is the value of ifStackHigherLayer; for the other, z is the + value of ifStackLowerLayer. (If z is not involved in + multiplexing, then these are the only two rows associated + with z.) + + For example, two rows exist even for an interface which has + no others stacked on top or below it: + + ifInvStackStatus.z.0=active + ifInvStackStatus.0.z=active + + This table contains exactly the same number of rows as the + ifStackTable, but the rows appear in a different order." + REFERENCE + "ifStackTable of RFC 2863" + ::= { ifInvMIBObjects 1 } + +ifInvStackEntry OBJECT-TYPE + SYNTAX IfInvStackEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Information on a particular relationship between two sub- + layers, specifying that one sub-layer runs underneath the + other sub-layer. Each sub-layer corresponds to a conceptual + row in the ifTable." + INDEX { ifStackLowerLayer, ifStackHigherLayer } + ::= { ifInvStackTable 1 } + +IfInvStackEntry ::= + SEQUENCE { + ifInvStackStatus RowStatus + } + +ifInvStackStatus OBJECT-TYPE + + + +McCloghrie & Hanson Standards Track [Page 5] + +RFC 2864 Inverted Stack Extension MIB June 2000 + + + SYNTAX RowStatus + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The status of the relationship between two sub-layers. + + An instance of this object exists for each instance of the + ifStackStatus object, and vice versa. For example, if the + variable ifStackStatus.H.L exists, then the variable + ifInvStackStatus.L.H must also exist, and vice versa. In + addition, the two variables always have the same value. + + However, unlike ifStackStatus, the ifInvStackStatus object + is NOT write-able. A network management application wishing + to change a relationship between sub-layers H and L cannot + do so by modifying the value of ifInvStackStatus.L.H, but + must instead modify the value of ifStackStatus.H.L. After + the ifStackTable is modified, the change will be reflected + in this table." + ::= { ifInvStackEntry 1 } + +-- conformance information + +ifInvConformance OBJECT IDENTIFIER ::= { ifInvMIBObjects 2 } + +ifInvGroups OBJECT IDENTIFIER ::= { ifInvConformance 1 } +ifInvCompliances OBJECT IDENTIFIER ::= { ifInvConformance 2 } + +-- compliance statements + +ifInvCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for SNMP entities which provide + inverted information on the layering of network interfaces." + + MODULE -- this module + MANDATORY-GROUPS { ifInvStackGroup } + + OBJECT ifInvStackStatus + SYNTAX INTEGER { active(1) } + DESCRIPTION + "Support is only required for 'active'." + + + + + + + + +McCloghrie & Hanson Standards Track [Page 6] + +RFC 2864 Inverted Stack Extension MIB June 2000 + + + MODULE IF-MIB + MANDATORY-GROUPS { ifStackGroup2 } + + ::= { ifInvCompliances 1 } + +-- units of conformance + +ifInvStackGroup OBJECT-GROUP + OBJECTS { ifInvStackStatus } + STATUS current + DESCRIPTION + "A collection of objects providing inverted information on + the layering of MIB-II interfaces." + ::= { ifInvGroups 1 } + +END + +5. Acknowledgements + + This memo has been produced by the IETF's Interfaces MIB working- + group. + +6. References + + [1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for + Describing SNMP Management Frameworks", RFC 2571, January 1998. + + [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, + RFC 1212, March 1991. + + [4] Rose, M., "A Convention for Defining Traps for use with the + SNMP", RFC 1215, 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, RFC 2578, April 1999. + + [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, + M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, + RFC 2579, April 1999. + + [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, + M. and S. Waldbusser, "Conformance Statements for SMIv2", STD + 58, RFC 2580, April 1999. + + + +McCloghrie & Hanson Standards Track [Page 7] + +RFC 2864 Inverted Stack Extension MIB June 2000 + + + [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple + Network Management Protocol", STD 15, RFC 1157, May 1990. + + [9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. + Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, + January 1996. + + [10] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. + Waldbusser, "Transport Mappings for Version 2 of the Simple + Network Management Protocol (SNMPv2)", RFC 1906, January 1996. + + [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message + Processing and Dispatching for the Simple Network Management + Protocol (SNMP)", RFC 2572, January 1998. + + [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) + for version 3 of the Simple Network Management Protocol + (SNMPv3)", RFC 2574, January 1998. + + [13] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. + Waldbusser, "Protocol Operations for Version 2 of the Simple + Network Management Protocol (SNMPv2)", RFC 1905, January 1996. + + [14] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC + 2573, January 1998. + + [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access + Control Model (VACM) for the Simple Network Management Protocol + (SNMP)", RFC 2575, January 1998. + + [16] McCloghrie, K. and M. Rose, "Management Information Base for + Network Management of TCP/IP-based internets - MIB-II", STD 17, + RFC 1213, March 1991. + + [17] McCloghrie, K. and F. Kastenholz, "The Interface Group MIB", RFC + 2863, June 2000. + + [18] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction + to Version 3 of the Internet-standard Network Management + Framework", RFC 2570, April 1999. + +7. Security Considerations + + There are no management objects defined in this MIB that have a MAX- + ACCESS clause of read-write and/or read-create. So, if this MIB is + implemented correctly, then there is no risk that an intruder can + alter or create any management objects of this MIB via direct SNMP + SET operations. + + + +McCloghrie & Hanson Standards Track [Page 8] + +RFC 2864 Inverted Stack Extension MIB June 2000 + + + SNMPv1 by itself is not a secure 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/SET (read/change/create/delete) the objects in this MIB. + + It is recommended that the implementers consider the security + features as provided by the SNMPv3 framework. Specifically, the use + of the User-based Security Model RFC 2574 [12] and the View- based + Access Control Model RFC 2575 [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 the objects only to those principals + (users) that have legitimate rights to indeed GET or SET + (change/create/delete) them. + +8. Authors' Addresses + + Keith McCloghrie + Cisco Systems, Inc. + 170 West Tasman Drive + San Jose, CA 95134-1706 + + Phone: 408-526-5260 + EMail: kzm@cisco.com + + + Gary Hanson + ADC Telecommunications + 14375 NW Science Park Drive + Portland, Oregon, 97229 + + Phone: (800)733-5511 x6333 + EMail: gary_hanson@adc.com + + + + + + + + + + + + + + + + + +McCloghrie & Hanson Standards Track [Page 9] + +RFC 2864 Inverted Stack Extension MIB June 2000 + + +9. Notice on Intellectual Property + + The IETF takes no position regarding the validity or scope of any + intellectual property 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; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication 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 implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +McCloghrie & Hanson Standards Track [Page 10] + +RFC 2864 Inverted Stack Extension MIB June 2000 + + +10. Full Copyright Statement + + Copyright (C) The Internet Society (2000). 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 RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +McCloghrie & Hanson Standards Track [Page 11] + -- cgit v1.2.3