RFC 1474
The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol
RFC 1474: The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol 💖
okay bestie, this is RFC 1474, and it's giving MIB definitions for the bridge NCP on PPP links 🎀
- Request for Comments: 1474
- Network Working Group: the group this was filed under
- Author: F. Kastenholz, FTP Software, Inc. 🧚
- Date: June 1993 📅
- Category: IAB standards track protocol, per the Status of this Memo ⭐
- Obsoletes / Updates: the header doesn't list any RFC this one obsoletes or updates, so there's nothing to chase there ✨
Status of this Memo 📜
ngl this section is the "here's what this doc is" part. It's an IAB standards track protocol for the Internet community, and the authors are literally asking for discussion and suggestions for improvements 🫶 For the standardization state and status, you check the current edition of the "IAB Official Protocol Standards" (that's the source of truth 💅). And distribution of this memo is unlimited, so share it with everyone 🌈
Abstract 🦋
so this memo defines a chunk of the Management Information Base (MIB) for network management protocols in TCP/IP-based internets 💜 The specific chunk is the managed objects used to manage the bridge Network Control Protocol [10] on subnetwork interfaces that run the family of Point-to-Point Protocols 🔥
Table of Contents 🗂️
1. The Network Management Framework ...................... 1
2. Objects ............................................... 2
2.1 Format of Definitions ................................ 2
3. Overview .............................................. 2
3.1 Object Selection Criteria ............................ 2
3.2 Structure of the PPP ................................. 3
3.3 MIB Groups ........................................... 3
4. Definitions ........................................... 4
5. Acknowledgements ...................................... 13
6. Security Considerations ............................... 14
7. References ............................................ 14
8. Author's Address ...................................... 151. The Network Management Framework 🌸
okay so the Internet-standard Network Management Framework is made of three pieces, and they all work together like a little dream team ✨
- STD 16/RFC 1155: this one defines the SMI, which is the set of mechanisms used to describe and name objects for management purposes 🎀 STD 16/RFC 1212 then adds a more concise description mechanism, and it's totally consistent with the SMI 💅
- STD 17/RFC 1213: this is MIB-II, the core set of managed objects for the Internet suite of protocols 👑
- STD 15/RFC 1157: this is SNMP, the protocol you use to get network access to the managed objects 🧚
And the Framework lets people define new objects for experimentation and evaluation, so it's super flexible 🍓
2. Objects 💜
managed objects get accessed through a virtual information store called the Management Information Base, or MIB 🦋 Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) [3] that the SMI defines. Each object type gets named by an OBJECT IDENTIFIER, which is just an administratively assigned name. The object type plus an object instance together uniquely identify one specific instantiation of the object, which is honestly so precise 😭 For human convenience, people often use a textual string called the descriptor to refer to the object type 🫶
2.1. Format of Definitions 📝
Section 4 has every single object type in this MIB module. They're all defined with the conventions from the SMI, as amended by the extensions specified in [5,6] 🌈
3. Overview 🔥
3.1. Object Selection Criteria 🎯
so this is giving "keep it simple" energy. To match IAB directives and good engineering practice, they really tried to keep this MIB as lean as possible 💖 Here's how they decided what got in. Each proposed object had to pass these checks:
- Essential for fault or configuration management. Objects that only existed to debug implementations were explicitly excluded, no exceptions 🙈
- Evidence of current use and/or utility. Show me it's actually useful right now ✨
- Limit the total number of objects. Keep the list short and sweet 🍓
- Exclude derivable objects. If an object is simply derivable from others in this or other MIBs, it's out 💅
3.2. Structure of the PPP 🧚
this section is the basic model of PPP that the PPP MIB is built on. It's basically a backstage pass to the design decisions, so implementers can understand why the MIB looks the way it does 🦋
PPP isn't one single protocol. It's a whole family of them, and each one is pretty complex on its own 💜 The PPP protocols split into three rough categories:
Control Protocols 🎀 : The Control Protocols control how PPP itself operates. This includes 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 move the network traffic over the PPP interface. Each Network Protocol encapsulates the datagrams of one specific higher-layer protocol that uses PPP as its data link. Heads up: in PPP land, "Network Protocol" doesn't automatically mean an OSI Layer-3 protocol. For example, there's a Bridging network protocol, and it's not Layer 3 🙈
Network Control Protocols (NCPs) 👑 : The NCPs control how the Network Protocols operate. Usually each Network Protocol gets its own NCP, so IP has its IP Control Protocol, Bridging has its Bridging Network Control Protocol, and so on 🧚
This document specifies the objects used to manage one of these protocols, the Bridge Network Control Protocol. 🌈
3.3. MIB Groups 🍓
The objects in this MIB are sorted into several MIB groups, and each group is a set of related objects 💖
these groups are the basic unit of conformance. If the semantics of a group apply to an implementation, then all objects in that group must be implemented 🫶
The PPP MIB is organized into several MIB Groups, including but not limited to these:
- The PPP Link Group
- The PPP LQR Group
- The PPP LQR Extensions Group
- The PPP IP Group
- The PPP Bridge Group
- The PPP Security Group
This document specifies this group:
The PPP Bridge Group 🌊 : The PPP Bridge Group holds the configuration, status, and control variables that apply to how Bridging runs over PPP ✨
Implementing this group is mandatory for every PPP implementation that supports Bridging over PPP 💅
4. Definitions 💜
the actual MIB module lives here, so this is the good stuff 🔥 It's called PPP-BRIDGE-NCP-MIB, and it imports Counter, ifIndex, OBJECT-TYPE, and ppp from its neighbours 🎀
PPP-BRIDGE-NCP-MIB DEFINITIONS ::= BEGIN
IMPORTS
Counter
FROM RFC1155-SMI
ifIndex
FROM RFC1213-MIB
OBJECT-TYPE
FROM RFC-1212
ppp
FROM PPP-LCP-MIB;
pppBridge OBJECT IDENTIFIER ::= { ppp 4 }
--
-- The PPP Bridge NCP Group.
-- Implementation of this group is mandatory for all
-- PPP implementations that support MAC Bridging over
-- PPP (RFC1220).
--
-- The following object reflect the values of the option
-- parameters used in the PPP Link Control Protocol
-- pppBridgeLocalToRemoteTinygramCompression
-- pppBridgeRemoteToLocalTinygramCompression
-- pppBridgeLocalToRemoteLanId
-- pppBridgeRemoteToLocalLanId
--
-- 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. pppBridgeOperStatus is set to
-- opened).
--
-- Therefore, when pppBridgeOperStatus is not opened
-- the contents of these objects is undefined. The value
-- returned when accessing the objects is an implementation
-- dependent issue.
pppBridgeTable OBJECT-TYPE
SYNTAX SEQUENCE OF PppBridgeEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Table containing the parameters and statistics
for the local PPP entity that are related to
the operation of Bridging over the PPP."
::= { pppBridge 1 }
pppBridgeEntry OBJECT-TYPE
SYNTAX PppBridgeEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Bridging information for a particular PPP
link."
INDEX { ifIndex }
::= { pppBridgeTable 1 }
PppBridgeEntry ::= SEQUENCE {
pppBridgeOperStatus
INTEGER,
pppBridgeLocalToRemoteTinygramCompression
INTEGER,
pppBridgeRemoteToLocalTinygramCompression
INTEGER,
pppBridgeLocalToRemoteLanId
INTEGER,
pppBridgeRemoteToLocalLanId
INTEGER
}
pppBridgeOperStatus OBJECT-TYPE
SYNTAX INTEGER {opened(1), not-opened(2)}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The operational status of the Bridge network
protocol. If the value of this object is up
then the finite state machine for the Bridge
network protocol has reached the Opened state."
::= { pppBridgeEntry 1 }
pppBridgeLocalToRemoteTinygramCompression OBJECT-TYPE
SYNTAX INTEGER { false(1), true(2) }
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Indicates whether the local node will perform
Tinygram Compression when sending packets to
the remote entity. If false then the local
entity will not perform Tinygram Compression.
If true then the local entity will perform
Tinygram Compression. The value of this object
is meaningful only when the link has reached
the open state (pppBridgeOperStatus is
opened)."
REFERENCE
"Section 6.7, Tinygram Compression Option, of
RFC1220"
::= { pppBridgeEntry 2 }
pppBridgeRemoteToLocalTinygramCompression OBJECT-TYPE
SYNTAX INTEGER { false(1), true(2) }
ACCESS read-only
STATUS mandatory
DESCRIPTION
"If false(1) then the remote entity is not
expected to perform Tinygram Compression. If
true then the remote entity is expected to
perform Tinygram Compression. The value of this
object is meaningful only when the link has
reached the open state (pppBridgeOperStatus is
opened)."
REFERENCE
"Section 6.7, Tinygram Compression Option, of
RFC1220"
::= { pppBridgeEntry 3 }Okay bestie, the pppBridge tables are where things get juicy 💅 Pick up right where we left off with the LAN Identification flags.
pppBridgeLocalToRemoteLanId OBJECT-TYPE
SYNTAX INTEGER { false(1), true(2) }
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Indicates whether the local node will include
the LAN Identification field in transmitted
packets or not. If false(1) then the local node
will not transmit this field, true(2) means
that the field will be transmitted. The value
of this object is meaningful only when the link
has reached the open state (pppBridgeOperStatus
is opened)."
REFERENCE
"Section 6.8, LAN Identification Option, of
RFC1220"
::= { pppBridgeEntry 4 }
pppBridgeRemoteToLocalLanId OBJECT-TYPE
SYNTAX INTEGER { false(1), true(2) }
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Indicates whether the remote node has
indicated that it will include the LAN
Identification field in transmitted packets or
not. If false(1) then the field will not be
transmitted, if true(2) then the field will be
transmitted. The value of this object is
meaningful only when the link has reached the
open state (pppBridgeOperStatus is opened)."
REFERENCE
"Section 6.8, LAN Identification Option, of
RFC1220"
::= { pppBridgeEntry 5 }So these two are read-only flags for LAN Identification, one for each direction 👀 The local one tells you what your node is going to send, and the remote one tells you what the other side said it'll send. Both only mean anything once the link is up (aka pppBridgeOperStatus is opened), so don't go reading them early 🙈
The next chunk is the PPP Bridge Configuration table, which is basically the settings menu for bridging over PPP ✨
--
-- The PPP Bridge Configuration table
--
pppBridgeConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF PppBridgeConfigEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Table containing the parameters and statistics
for the local PPP entity that are related to
the operation of Bridging over the PPP."
::= { pppBridge 2 }
pppBridgeConfigEntry OBJECT-TYPE
SYNTAX PppBridgeConfigEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Bridging Configuration information for a
particular PPP link."
INDEX { ifIndex }
::= { pppBridgeConfigTable 1 }
PppBridgeConfigEntry ::= SEQUENCE {
pppBridgeConfigAdminStatus
INTEGER,
pppBridgeConfigTinygram
INTEGER,
pppBridgeConfigRingId
INTEGER,
pppBridgeConfigLineId
INTEGER,
pppBridgeConfigLanId
INTEGER
}Each row is keyed by ifIndex, so every PPP link gets its own bridging config 🎀 The entry itself is a bunch of columns, and we're about to meet all of them.
pppBridgeConfigAdminStatus OBJECT-TYPE
SYNTAX INTEGER { open(1), close(2) }
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The immediate desired status of the Bridging
network protocol. Setting this object to open
will inject an administrative open event into
the Bridging network protocol's finite state
machine. Setting this object to close will
inject an administrative close event into the
Bridging network protocol's finite state
machine."
::= { pppBridgeConfigEntry 1 }
pppBridgeConfigTinygram OBJECT-TYPE
SYNTAX INTEGER { false(1), true(2) }
ACCESS read-write
STATUS mandatory
DESCRIPTION
"If false then the local BNCP entity will not
initiate the Tinygram Compression Option
Negotiation. If true then the local BNCP entity
will initiate negotiation of this option."
REFERENCE
"Section 6.7, Tinygram Compression Option, of
RFC1220"
DEFVAL { true }
::= { pppBridgeConfigEntry 2 }
pppBridgeConfigRingId OBJECT-TYPE
SYNTAX INTEGER { false(1), true(2) }
ACCESS read-write
STATUS mandatory
DESCRIPTION
"If false then the local PPP Entity will not
initiate a Remote Ring Identification Option
negotiation. If true then the local PPP entity
will intiate this negotiation. This MIB object
is relevant only if the interface is for 802.5
Token Ring bridging."
REFERENCE
"Section 6.4, IEEE 802.5 Remote Ring
Identification Option, of RFC1220"
DEFVAL { false }
::= { pppBridgeConfigEntry 3 }
pppBridgeConfigLineId OBJECT-TYPE
SYNTAX INTEGER { false(1), true(2) }
ACCESS read-write
STATUS mandatory
DESCRIPTION
"If false then the local PPP Entity is not to
initiate a Line Identification Option
negotiation. If true then the local PPP entity
will intiate this negotiation. This MIB object
is relevant only if the interface is for 802.5
Token Ring bridging."
REFERENCE
"Section 6.5, IEEE 802.5 Line Identification
Option, of RFC1220"
DEFVAL { false }
::= { pppBridgeConfigEntry 4 }
pppBridgeConfigLanId OBJECT-TYPE
SYNTAX INTEGER { false(1), true(2) }
ACCESS read-write
STATUS mandatory
DESCRIPTION
"If false then the local BNCP entity will not
initiate the LAN Identification Option
Negotiation. If true then the local BNCP entity
will initiate negotiation of this option."
REFERENCE
"Section 6.8, LAN Identification Option, of
RFC1220"
DEFVAL { false }
::= { pppBridgeConfigEntry 5 }The admin status column is the big red button 🔥 Writingopenorcloseinjects an administrative event straight into the Bridging NCP's state machine, so be careful what you click.
Notice the defaults here too. Tinygram compression starts out true, and the Ring ID, Line ID and LAN ID options all start out false 🌸 The Ring and Line ID knobs only matter for 802.5 Token Ring bridging, so they're basically sleeping otherwise 😴
Next up is the PPP Bridge Media Status table, which tells you which MAC media types are switched on for the bridging NCPs, and what each side thinks about them 🦋
--
-- The PPP Bridge Media Status Table
--
pppBridgeMediaTable OBJECT-TYPE
SYNTAX SEQUENCE OF PppBridgeMediaEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Table identifying which MAC media types are
enabled for the Bridging NCPs."
::= { pppBridge 3 }
pppBridgeMediaEntry OBJECT-TYPE
SYNTAX PppBridgeMediaEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Status of a specific MAC Type for a specific
PPP Link."
INDEX { ifIndex, pppBridgeMediaMacType }
::= { pppBridgeMediaTable 1 }
PppBridgeMediaEntry ::= SEQUENCE {
pppBridgeMediaMacType
INTEGER,
pppBridgeMediaLocalStatus
INTEGER,
pppBridgeMediaRemoteStatus
INTEGER
}
pppBridgeMediaMacType OBJECT-TYPE
SYNTAX INTEGER(0..2147483647)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The MAC type for which this entry in the
pppBridgeMediaTable is providing status
information. Valid values for this object are
defined in Section 6.6 MAC Type Support
Selection of RFC1220 (Bridging Point-to-Point
Protocol)."
REFERENCE
"Section 6.6, MAC Type Support Selection, of
RFC1212."
::= { pppBridgeMediaEntry 1 }
pppBridgeMediaLocalStatus OBJECT-TYPE
SYNTAX INTEGER { accept(1), dont-accept(2) }
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Indicates whether the local PPP Bridging
Entity will accept packets of the protocol type
identified in pppBridgeMediaMacType on the PPP
link identified by ifIndex or not. If this
object is accept then any packets of the
indicated MAC type will be received and
properly processed. If this object is dont-
accept then received packets of the indicated
MAC type will not be properly processed."
REFERENCE
"Section 6.6, MAC Type Support Selection, of
RFC1212."
::= { pppBridgeMediaEntry 2 }
pppBridgeMediaRemoteStatus OBJECT-TYPE
SYNTAX INTEGER { accept(1), dont-accept(2) }
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Indicates whether the local PPP Bridging
Entity believes that the remote PPP Bridging
Entity will accept packets of the protocol type
identified in pppBridgeMediaMacType on the PPP
link identified by ifIndex or not."
REFERENCE
"Section 6.6, MAC Type Support Selection, of
RFC1212."
::= { pppBridgeMediaEntry 3 }Each row is a (ifIndex, pppBridgeMediaMacType) pair, so one link can have a whole bunch of MAC types, each with its own local and remote accept status 💜 Heads up: the pppBridgeMediaMacType description points at Section 6.6 of RFC1220, but the REFERENCE clauses say RFC1212, so the paperwork is a little mismatched there 🙃
Last stop: the PPP Bridge Media Configuration table 🧚
--
-- The PPP Bridge Media Configuration Table
--
pppBridgeMediaConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF PppBridgeMediaConfigEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Table identifying which MAC media types are
enabled for the Bridging NCPs."
::= { pppBridge 4 }
pppBridgeMediaConfigEntry OBJECT-TYPE
SYNTAX PppBridgeMediaConfigEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Status of a specific MAC Type for a specific
PPP Link."
INDEX { ifIndex, pppBridgeMediaConfigMacType }
::= { pppBridgeMediaConfigTable 1 }
PppBridgeMediaConfigEntry ::= SEQUENCE {
pppBridgeMediaConfigMacType
INTEGER,
pppBridgeMediaConfigLocalStatus
INTEGER
}This one is the config twin of the media status table, keyed the same way by ifIndex plus a MAC type. Its description and entry text are copied from the status table, so it's giving déjà vu 🌈 The entry has a MAC type column and a local status column, and that's the whole cast.
pppBridgeMediaConfigMacType OBJECT-TYPE
SYNTAX INTEGER(0..2147483647)
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The MAC type for which this entry in the
pppBridgeMediaConfigTable is providing status
information. Valid values for this object are
defined in Section 6.6 MAC Type Support
Selection of RFC1220 (Bridging Point-to-Point
Protocol)."
REFERENCE
"Section 6.6, MAC Type Support Selection, of
RFC1212."
::= { pppBridgeMediaConfigEntry 1 }
pppBridgeMediaConfigLocalStatus OBJECT-TYPE
SYNTAX INTEGER { accept(1), dont-accept(2) }
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Indicates whether the local PPP Bridging
Entity should accept packets of the protocol
type identified in pppBridgeMediaConfigMacType
on the PPP link identified by ifIndex or not.
Setting this object to the value dont-accept
has the affect of invalidating the
corresponding entry in the
pppBridgeMediaConfigTable object. It is an
implementation-specific matter as to whether
the agent removes an invalidated entry from the
table. Accordingly, management stations must be
prepared to receive tabular information from
agents that corresponds to entries not
currently in use. Changing this object will
have effect when the link is next restarted."
REFERENCE
"Section 6.6, MAC Type Support Selection, of
RFC1212."
::= { pppBridgeMediaConfigEntry 2 }
END6. Acknowledgements ✨
This document was produced by the PPP working group. Big shoutout to the whole working group, and the author also wants to thank these individuals for their comments and contributions 🫶:
- Bill Simpson -- Daydreamer 💜
- Glenn McGregor -- Merit 🌸
- Jesse Walker -- DEC 🦋
- Chris Gunner -- DEC 🎀
6. Security Considerations 🔒
okay bestie, the PPP MIB lets the network operator configure and control the PPP links of a particular system, including the PPP authentication protocols. that is a real security risk, no cap 😭 💀
these risks get handled in the following manners:
- All variables which represent a significant security risk are placed in separate, optional, MIB Groups. The MIB Group is the quantum of implementation within a MIB, so the implementor of the MIB may elect not to implement these groups. 🧚
- 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. 🙈
- 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, RFC 1155, 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, RFC 1213, Performance Systems International, March 1991.
[3] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization, International 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", RFC 1229, 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", RFC 1332, Merit, May 1992.
[10] Baker, F., "Point-to-Point Protocol Extensions for Bridging", RFC 1220, ACC, April 1991.
[11] Lloyd, B., and W. Simpson, "PPP Authentication Protocols", RFC 1334, 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.com
📦 where this page comes from
- ietf: rfc1474 1993-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms