Movatterモバイル変換


[0]ホーム

URL:


[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]

PROPOSED STANDARD
Network Working Group                                      F. KastenholzRequest for Comments: 1473                            FTP Software, Inc.                                                               June 1993The Definitions of Managed Objects forthe IP Network Control Protocol ofthe Point-to-Point ProtocolStatus of this Memo   This RFC specifies an IAB standards track protocol for the Internet   community, and requests discussion and suggestions for improvements.   Please refer to the current edition of the "IAB Official Protocol   Standards" for the standardization state and status of this protocol.   Distribution of this memo is unlimited.Abstract   This memo defines a portion of the Management Information Base (MIB)   for use with network management protocols in TCP/IP-based internets.   In particular, it describes managed objects used for managing the IP   Network Control Protocol on subnetwork interfaces using the family of   Point-to-Point Protocols [8, 9, 10, 11, & 12].Table of Contents1. The Network Management Framework ......................12. Objects ...............................................22.1 Format of Definitions ................................23. Overview ..............................................23.1 Object Selection Criteria ............................23.2 Structure of the PPP .................................23.3 MIB Groups ...........................................34. Definitions ...........................................45. Acknowledgements ......................................86. Security Considerations ...............................87. References ............................................88. Author's Address ......................................91.  The Network Management Framework   The Internet-standard Network Management Framework consists of three   components.  They are:      STD 16/RFC 1155 which defines the SMI, the mechanisms used for      describing and naming objects for the purpose of management.  STD      16/RFC 1212 defines a more concise description mechanism, which isKastenholz                                                      [Page 1]

RFC 1473                       PPP/IP MIB                      June 1993      wholly consistent with the SMI.      STD 17/RFC 1213 which defines MIB-II, the core set of managed      objects for the Internet suite of protocols.      STD 15/RFC 1157 which defines the SNMP, the protocol used for      network access to managed objects.   The Framework permits new objects to be defined for the purpose of   experimentation and evaluation.2.  Objects   Managed objects are accessed via a virtual information store, termed   the Management Information Base or MIB.  Objects in the MIB are   defined using the subset of Abstract Syntax Notation One (ASN.1) [3]   defined in the SMI.  In particular, each object type is named by an   OBJECT IDENTIFIER, an administratively assigned name.  The object   type together with an object instance serves to uniquely identify a   specific instantiation of the object.  For human convenience, we   often use a textual string, termed the descriptor, to refer to the   object type.2.1.  Format of DefinitionsSection 4 contains the specification of all object types contained in   this MIB module.  The object types are defined using the conventions   defined in the SMI, as amended by the extensions specified in [5,6].3.  Overview3.1.  Object Selection Criteria   To be consistent with IAB directives and good engineering practice,   an explicit attempt was made to keep this MIB as simple as possible.   This was accomplished by applying the following criteria to objects   proposed for inclusion:      (1)  Require objects be essential for either fault or           configuration management.  In particular, objects for           which the sole purpose was to debug implementations were           explicitly excluded from the MIB.      (2)  Consider evidence of current use and/or utility.      (3)  Limit the total number of objects.      (4)  Exclude objects which are simply derivable from others inKastenholz                                                      [Page 2]

RFC 1473                       PPP/IP MIB                      June 1993           this or other MIBs.3.2.  Structure of the PPP   This section describes the basic model of PPP used in developing the   PPP MIB. This information should be useful to the implementor in   understanding some of the basic design decisions of the MIB.   The PPP is not one single protocol but a large family of protocols.   Each of these is, in itself, a fairly complex protocol.  The PPP   protocols may be divided into three rough categories:   Control Protocols      The Control Protocols are used to control the operation of the      PPP. The Control Protocols include the Link Control Protocol      (LCP), the Password Authentication Protocol (PAP), the Link      Quality Report (LQR), and the Challenge Handshake Authentication      Protocol (CHAP).   Network Protocols      The Network Protocols are used to move the network traffic over      the PPP interface.  A Network Protocol encapsulates the datagrams      of a specific higher-layer protocol that is using the PPP as a      data link.  Note that within the context of PPP, the term "Network      Protocol" does not imply an OSI Layer-3 protocol; for instance,      there is a Bridging network protocol.   Network Control Protocols (NCPs)      The NCPs are used to control the operation of the Network      Protocols. Generally, each Network Protocol has its own Network      Control Protocol; thus, the IP Network Protocol has its IP Control      Protocol, the Bridging Network Protocol has its Bridging Network      Control Protocol and so on.   This document specifies the objects used in managing one of these   protocols, namely the IP Network Control Protocol.3.3.  MIB Groups   Objects in this MIB are arranged into several MIB groups.  Each group   is organized as a set of related objects.   These groups are the basic unit of conformance: if the semantics of a   group are applicable to an implementation then all objects in the   group must be implemented.   The PPP MIB is organized into several MIB Groups, including, but not   limited to, the following groups:Kastenholz                                                      [Page 3]

RFC 1473                       PPP/IP MIB                      June 1993          o The PPP Link Group          o The PPP LQR Group          o The PPP LQR Extensions Group          o The PPP IP Group          o The PPP Bridge Group          o The PPP Security Group   This document specifies the following group:   The PPP IP Group      The PPP IP Group contains configuration, status, and control      variables that apply to the operation of IP over PPP.      Implementation of this group is mandatory for all implementations      of PPP that support IP over PPP.4.  Definitions          PPP-IP-NCP-MIB DEFINITIONS ::= BEGIN          IMPORTS               Counter                    FROMRFC1155-SMI               ifIndex                    FROMRFC1213-MIB               OBJECT-TYPE                    FROMRFC-1212               ppp                    FROM PPP-LCP-MIB;               -- The PPP IP Group.               -- Implementation of this group is mandatory for all               -- PPP implementations that support operating IP over PPP.               pppIp OBJECT IDENTIFIER ::= { ppp 3 }          pppIpTable   OBJECT-TYPE               SYNTAX    SEQUENCE OF PppIpEntry               ACCESS    not-accessible               STATUS    mandatory               DESCRIPTION                         "Table containing the IP parameters and                         statistics for the local PPP entity."               ::= { pppIp 1 }          pppIpEntry   OBJECT-TYPEKastenholz                                                      [Page 4]

RFC 1473                       PPP/IP MIB                      June 1993               SYNTAX    PppIpEntry               ACCESS    not-accessible               STATUS    mandatory               DESCRIPTION                         "IPCP status information for a particular PPP                         link."               INDEX     { ifIndex }               ::= { pppIpTable 1 }          PppIpEntry ::= SEQUENCE {               pppIpOperStatus                    INTEGER,               pppIpLocalToRemoteCompressionProtocol                    INTEGER,               pppIpRemoteToLocalCompressionProtocol                    INTEGER,               pppIpRemoteMaxSlotId                    INTEGER,               pppIpLocalMaxSlotId                    INTEGER          }          -- The following object reflect the values of the option          -- parameters used in the PPP IP Control Protocol          --   pppIpLocalToRemoteCompressionProtocol          --   pppIpRemoteToLocalCompressionProtocol          --   pppIpRemoteMaxSlotId          --   pppIpLocalMaxSlotId          -- These values are not available until after the PPP Option          -- negotiation has completed, which is indicated by the link          -- reaching the open state (i.e., pppIpOperStatus is set to          -- opened).          --          -- Therefore, when pppIpOperStatus is not opened          -- the contents of these objects is undefined. The value          -- returned when accessing the objects is an implementation          -- dependent issue.          pppIpOperStatus   OBJECT-TYPE               SYNTAX    INTEGER {opened(1), not-opened(2)}               ACCESS    read-only               STATUS    mandatory               DESCRIPTION                         "The operational status of the IP network                         protocol. If the value of this object is up                         then the finite state machine for the IPKastenholz                                                      [Page 5]

RFC 1473                       PPP/IP MIB                      June 1993                         network protocol has reached the Opened state."               ::= { pppIpEntry 1 }          pppIpLocalToRemoteCompressionProtocol   OBJECT-TYPE               SYNTAX    INTEGER {                         none(1),                         vj-tcp(2)                    }               ACCESS    read-only               STATUS    mandatory               DESCRIPTION                         "The IP compression protocol that the local                         PPP-IP entity uses when sending packets to the                         remote PPP-IP entity. The value of this object                         is meaningful only when the link has reached                         the open state (pppIpOperStatus is opened)."               ::= { pppIpEntry 2 }          pppIpRemoteToLocalCompressionProtocol   OBJECT-TYPE               SYNTAX    INTEGER {                         none(1),                         vj-tcp(2)                    }               ACCESS    read-only               STATUS    mandatory               DESCRIPTION                         "The IP compression protocol that the remote                         PPP-IP entity uses when sending packets to the                         local PPP-IP entity. The value of this object                         is meaningful only when the link has reached                         the open state (pppIpOperStatus is opened)."               ::= { pppIpEntry 3 }          pppIpRemoteMaxSlotId   OBJECT-TYPE               SYNTAX    INTEGER(0..255)               ACCESS    read-only               STATUS    mandatory               DESCRIPTION                         "The Max-Slot-Id parameter that the remote node                         has advertised and that is in use on the link.                         If vj-tcp header compression is not in use on                         the link then the value of this object shall be                         0. The value of this object is meaningful only                         when the link has reached the open state                         (pppIpOperStatus is opened)."Kastenholz                                                      [Page 6]

RFC 1473                       PPP/IP MIB                      June 1993               ::= { pppIpEntry 4 }          pppIpLocalMaxSlotId   OBJECT-TYPE               SYNTAX    INTEGER(0..255)               ACCESS    read-only               STATUS    mandatory               DESCRIPTION                         "The Max-Slot-Id parameter that the local node                         has advertised and that is in use on the link.                         If vj-tcp header compression is not in use on                         the link then the value of this object shall be                         0. The value of this object is meaningful only                         when the link has reached the open state                         (pppIpOperStatus is opened)."               ::= { pppIpEntry 5 }          --          -- The PPP IP Configuration table.          -- This is a separate table in order to facilitate          -- placing these variables in a separate MIB view.          --          pppIpConfigTable   OBJECT-TYPE               SYNTAX    SEQUENCE OF PppIpConfigEntry               ACCESS    not-accessible               STATUS    mandatory               DESCRIPTION                         "Table containing configuration variables for                         the IPCP for the local PPP entity."               ::= { pppIp 2 }          pppIpConfigEntry   OBJECT-TYPE               SYNTAX    PppIpConfigEntry               ACCESS    not-accessible               STATUS    mandatory               DESCRIPTION                         "IPCP information for a particular PPP link."               INDEX     { ifIndex }               ::= { pppIpConfigTable 1 }          PppIpConfigEntry ::= SEQUENCE {               pppIpConfigAdminStatus                    INTEGER,               pppIpConfigCompressionKastenholz                                                      [Page 7]

RFC 1473                       PPP/IP MIB                      June 1993                    INTEGER          }          pppIpConfigAdminStatus   OBJECT-TYPE               SYNTAX    INTEGER {open(1), close(2)}               ACCESS    read-write               STATUS    mandatory               DESCRIPTION                         "The immediate desired status of the IP network                         protocol. Setting this object to open will                         inject an administrative open event into the IP                         network protocol's finite state machine.                         Setting this object to close will inject an                         administrative close event into the IP network                         protocol's finite state machine."               ::= { pppIpConfigEntry 1 }          pppIpConfigCompression   OBJECT-TYPE               SYNTAX    INTEGER {                         none(1),                         vj-tcp(2)                    }               ACCESS    read-write               STATUS    mandatory               DESCRIPTION                         "If none(1) then the local node will not                         attempt to negotiate any IP Compression option.                         Otherwise, the local node will attempt to                         negotiate compression mode indicated by the                         enumerated value. Changing this object will                         have effect when the link is next restarted."               REFERENCE                         "Section 4.0, Van Jacobson TCP/IP Header                         Compression ofRFC1332."               DEFVAL    { none }               ::= { pppIpConfigEntry 2 }          END5.  Acknowledgements   This document was produced by the PPP working group.  In addition to   the working group, the author wishes to thank the following   individuals for their comments and contributions:          Bill Simpson -- DaydreamerKastenholz                                                      [Page 8]

RFC 1473                       PPP/IP MIB                      June 1993          Glenn McGregor -- Merit          Jesse Walker -- DEC          Chris Gunner -- DEC6.  Security Considerations   The PPP MIB affords the network operator the ability to configure and   control the PPP links of a particular system, including the PPP   authentication protocols. This represents a security risk.   These risks are addressed in the following manners:      (1)  All variables which represent a significant security risk           are placed in separate, optional, MIB Groups. As the MIB           Group is the quantum of implementation within a MIB, the           implementor of the MIB may elect not to implement these           groups.      (2)  The implementor may choose to implement the variables           which present a security risk so that they may not be           written, i.e., the variables are READ-ONLY. This method           still presents a security risk, and is not recommended,           in that the variables, specifically the PPP           Authentication Protocols' variables, may be easily read.      (3)  Using SNMPv2, the operator can place the variables into           MIB views which are protected in that the parties which           have access to those MIB views use authentication and           privacy protocols, or the operator may elect to make           these views not accessible to any party.  In order to           facilitate this placement, all security-related variables           are placed in separate MIB Tables. This eases the           identification of the necessary MIB View Subtree.7.  References   [1] Rose M., and K. McCloghrie, "Structure and Identification of       Management Information for TCP/IP-based internets", STD 16,RFC1155, Performance Systems International, Hughes LAN Systems, May       1990.   [2] McCloghrie K., and M. Rose, Editors, "Management Information Base       for Network Management of TCP/IP-based internets", STD 17,RFC1213, Performance Systems International, March 1991.   [3] Information processing systems - Open Systems Interconnection -       Specification of Abstract Syntax Notation One (ASN.1),       International Organization for Standardization, InternationalKastenholz                                                      [Page 9]

RFC 1473                       PPP/IP MIB                      June 1993       Standard 8824, December 1987.   [4] Information processing systems - Open Systems Interconnection -       Specification of Basic Encoding Rules for Abstract Notation One       (ASN.1), International Organization for Standardization,       International Standard 8825, December 1987.   [5] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",       STD 16,RFC 1212, Performance Systems International, Hughes LAN       Systems, March 1991.   [6] Rose, M., Editor, "A Convention for Defining Traps for use with       the SNMP",RFC 1215, Performance Systems International, March       1991.   [7] McCloghrie, K., "Extensions to the Generic-Interface MIB",RFC1229, Hughes LAN Systems, Inc., May 1991.   [8] Simpson, W., "The Point-to-Point Protocol for the Transmission of       Multi-protocol Datagrams over Point-to-Point Links,RFC 1331,       Daydreamer, May 1992.   [9] McGregor, G., "The PPP Internet Protocol Control Protocol",RFC1332, Merit, May 1992.  [10] Baker, F., "Point-to-Point Protocol Extensions for Bridging",RFC1220, ACC, April 1991.  [11] Lloyd, B., and W. Simpson, "PPP Authentication Protocols",RFC1334, L&A, Daydreamer, October 1992.  [12] Simpson, W., "PPP Link Quality Monitoring",RFC 1333, Daydreamer,       May 1992.8.  Author's Address   Frank Kastenholz   FTP Software, Inc.   2 High Street   North Andover, Mass 01845 USA   Phone: (508) 685-4000   EMail: kasten@ftp.comKastenholz                                                     [Page 10]

[8]ページ先頭

©2009-2025 Movatter.jp