RFC 4292
IP Forwarding Table MIB
IP Forwarding Table MIB 🦋
okay bestie, RFC 4292 is here and it's giving standards track 👑. Brian Haberman wrote it at Johns Hopkins University, and it was published in April 2006. It obsoletes RFC 2096, so 2096 is officially retired and this one is the new main character 💅.
Table of Contents
1. Introduction ....................................................2
2. Conventions Used In This Document ...............................2
3. The Internet-Standard Management Framework ......................2
4. Overview ........................................................2
4.1. Relationship to Other MIBs .................................3
4.1.1. RFC 1213 ............................................3
4.1.2. RFC 1354 ............................................3
4.1.3. RFC 2096 ............................................3
4.1.4. RFC 2011 and 2465 ...................................3
5. Definitions .....................................................3
6. Security Considerations ........................................30
7. Changes from RFC 2096 ..........................................31
8. Normative References ...........................................32
9. Informative References .........................................32
10. Authors and Acknowledgements ..................................33Status of This Memo ✨
okay so this doc is a standards track protocol for the whole Internet community 🌍. It's also asking for discussion and suggestions for improvements. If you want to know where this protocol stands in the standardization process, check the current edition of "Internet Official Protocol Standards" (STD 1). And the distribution of this memo is unlimited, so share it with everyone 🫶.
Copyright Notice 💜
Copyright (C) The Internet Society (2006).
Abstract 🌸
this document defines a piece of the Management Information Base (MIB) that network management protocols use. the big focus is managed objects for forwarding Internet Protocol (IP) packets, and it's done in an IP version-independent way 🧚. it also obsoletes RFC 2096, which we already covered, so no need to repeat the drama 💀.
1. Introduction 🎀
so this doc defines a chunk of the MIB for managing objects that handle forwarding IP packets, and again, it works no matter which IP version you're using 💖.
heads up though, the MIB definition here does not support multiple instances for the same address family type 🙈. what it does support is one instance of the MIB per address family, and that's the move ✨.
2. Conventions Used In This Document 💅
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]. these are the official capital-letter power words, so read them as the spec intends 🔥.
3. The Internet-Standard Management Framework 🌈
if you want the full tea on the documents that describe the current Internet-Standard Management Framework, go check section 7 of RFC 3410 [RFC3410] 📚.
managed objects are accessed through a virtual information store called the Management Information Base, or MIB 🗂️. you usually reach MIB objects through the Simple Network Management Protocol (SNMP). objects in the MIB are defined using the Structure of Management Information (SMI) mechanisms. 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] ✨.
4. Overview 🦋
okay so the MIB has one current table and two current global objects 💖. here's the breakdown:
- The object inetCidrRouteNumber indicates the number of current routes. this is mainly so you don't have to read the whole table just to count them 🧮.
- The object inetCidrRouteDiscards counts the number of valid routes that were discarded from inetCidrRouteTable for any reason. this object replaces the ipRoutingDiscards and ipv6DiscardedRoutes objects 🗑️. one possible reason for discarding an entry would be to free up buffer space for other route table entries 🧹.
- The inetCidrRouteTable provides the ability to display IP version-independent multipath CIDR routes 🌟.
4.1. Relationship to Other MIBs 💜
this MIB definition has a few deprecated and obsolete tables and objects. the following subsections explain how these objects relate to other MIB modules 📜.
4.1.1. RFC 1213
the ipRouteTable object was originally defined in RFC 1213 [RFC1213]. it was then updated by ipForwardTable in RFC 1354 [RFC1354] 🌸.
4.1.2. RFC 1354
the ipForwardTable object replaced the ipRouteTable object from RFC 1213. it was then obsoleted by the ipCidrRouteTable defined in RFC 2096 [RFC2096] 💀.
RFC 1354 also introduced ipForwardNumber. this object reflects the number of entries found in ipForwardTable. it was obsoleted by ipCidrRouteNumber, which is defined in RFC 2096 🙃.
4.1.3. RFC 2096
in RFC 2096, the ipCidrRouteTable and ipCidrRouteNumber were introduced 🎉. the ipCidrRouteTable object supports multipath IP routes that have the same network number but different network masks. the number of entries in that table is reflected in ipCidrRouteNumber. these objects are now deprecated by the definitions in this MIB 🫠.
4.1.4. RFC 2011 and 2465
RFC 2011 [RFC2011] has the ipRoutingDiscards object, which counts the number of valid routes that have been removed from the ipCidrRouteTable object 🗑️. the matching ipv6DiscardedRoutes object is defined in RFC 2465 [RFC2465]. both of these are deprecated now in favor of the version-independent object inetCidrRouteDiscards, which is defined in this MIB ✨.
5. Definitions 🧚
here's the actual MIB module, copied exactly as written so every detail survives 💖. this is where the spec gets very specific, bestie, so the tiny characters matter 🔍.
IP-FORWARD-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE,
IpAddress, Integer32, Gauge32,
Counter32 FROM SNMPv2-SMI
RowStatus FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF
InterfaceIndexOrZero FROM IF-MIB
ip FROM IP-MIB
IANAipRouteProtocol FROM IANA-RTPROTO-MIB
InetAddress, InetAddressType,
InetAddressPrefixLength,
InetAutonomousSystemNumber FROM INET-ADDRESS-MIB;
ipForward MODULE-IDENTITY
LAST-UPDATED "200602010000Z"
ORGANIZATION
"IETF IPv6 Working Group
http://www.ietf.org/html.charters/ipv6-charter.html"
CONTACT-INFO
"Editor:
Brian Haberman
Johns Hopkins University - Applied Physics Laboratory
Mailstop 17-S442
11100 Johns Hopkins Road
Laurel MD, 20723-6099 USA
Phone: +1-443-778-1319
Email: brian@innovationslab.net
Send comments to <ipv6@ietf.org>"
DESCRIPTION
"The MIB module for the management of CIDR multipath IP
Routes.
Copyright (C) The Internet Society (2006). This version
of this MIB module is a part of RFC 4292; see the RFC
itself for full legal notices."
REVISION "200602010000Z"
DESCRIPTION
"IPv4/v6 version-independent revision. Minimal changes
were made to the original RFC 2096 MIB to allow easy
upgrade of existing IPv4 implementations to the
version-independent MIB. These changes include:
Adding inetCidrRouteDiscards as a replacement for the
deprecated ipRoutingDiscards and ipv6DiscardedRoutes
objects.
Adding a new conformance statement to support the
implementation of the IP Forwarding MIB in a
read-only mode.
The inetCidrRouteTable replaces the IPv4-specific
ipCidrRouteTable, its related objects, and related
conformance statements.
Published as RFC 4292."
REVISION "199609190000Z"
DESCRIPTION
"Revised to support CIDR routes.
Published as RFC 2096."
REVISION "199207022156Z"
DESCRIPTION
"Initial version, published as RFC 1354."
::= { ip 24 }
inetCidrRouteNumber OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of current inetCidrRouteTable entries that
are not invalid."
::= { ipForward 6 }
inetCidrRouteDiscards OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of valid route entries discarded from the
inetCidrRouteTable. Discarded route entries do not
appear in the inetCidrRouteTable. One possible reason
for discarding an entry would be to free-up buffer space
for other route table entries."
::= { ipForward 8 }
-- Inet CIDR Route Table
-- The Inet CIDR Route Table deprecates and replaces the
-- ipCidrRoute Table currently in the IP Forwarding Table MIB.
-- It adds IP protocol independence.
inetCidrRouteTable OBJECT-TYPE
SYNTAX SEQUENCE OF InetCidrRouteEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This entity's IP Routing table."
REFERENCE
"RFC 1213 Section 6.6, The IP Group"
::= { ipForward 7 }
inetCidrRouteEntry OBJECT-TYPE
SYNTAX InetCidrRouteEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A particular route to a particular destination, under a
particular policy (as reflected in the
inetCidrRoutePolicy object).
Dynamically created rows will survive an agent reboot.
Implementers need to be aware that if the total number
of elements (octets or sub-identifiers) in
inetCidrRouteDest, inetCidrRoutePolicy, and
inetCidrRouteNextHop exceeds 111, then OIDs of column
instances in this table will have more than 128 sub-
identifiers and cannot be accessed using SNMPv1,
SNMPv2c, or SNMPv3."
INDEX {
inetCidrRouteDestType,
inetCidrRouteDest,
inetCidrRoutePfxLen,
inetCidrRoutePolicy,
inetCidrRouteNextHopType,
inetCidrRouteNextHop
}
::= { inetCidrRouteTable 1 }
InetCidrRouteEntry ::= SEQUENCE {
inetCidrRouteDestType InetAddressType,
inetCidrRouteDest InetAddress,
inetCidrRoutePfxLen InetAddressPrefixLength,
inetCidrRoutePolicy OBJECT IDENTIFIER,
inetCidrRouteNextHopType InetAddressType,
inetCidrRouteNextHop InetAddress,
inetCidrRouteIfIndex InterfaceIndexOrZero,
inetCidrRouteType INTEGER,
inetCidrRouteProto IANAipRouteProtocol,
inetCidrRouteAge Gauge32,
inetCidrRouteNextHopAS InetAutonomousSystemNumber,
inetCidrRouteMetric1 Integer32,
inetCidrRouteMetric2 Integer32,
inetCidrRouteMetric3 Integer32,
inetCidrRouteMetric4 Integer32,
inetCidrRouteMetric5 Integer32,
inetCidrRouteStatus RowStatus
}
inetCidrRouteDestType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The type of the inetCidrRouteDest address, as defined
in the InetAddress MIB.ok bestie, that's the first chunk of the MIB 💅🎀. the definitions keep going from here, so part 2 is coming up next, and you are NOT gonna want to miss the tea 🦋✨.
okay bestie, the good stuff is all in the MIB definitions 💅 every object below is an index or a column of the route table, so I'm keeping the code exactly as written 🎀
Only those address types that may appear in an actual
routing table are allowed as values of this object."
REFERENCE "RFC 4001"
::= { inetCidrRouteEntry 1 }
inetCidrRouteDest OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The destination IP address of this route.
The type of this address is determined by the value of
the inetCidrRouteDestType object.
The values for the index objects inetCidrRouteDest and
inetCidrRoutePfxLen must be consistent. When the value
of inetCidrRouteDest (excluding the zone index, if one
is present) is x, then the bitwise logical-AND
of x with the value of the mask formed from the
corresponding index object inetCidrRoutePfxLen MUST be
equal to x. If not, then the index pair is not
consistent and an inconsistentName error must be
returned on SET or CREATE requests."
::= { inetCidrRouteEntry 2 }
inetCidrRoutePfxLen OBJECT-TYPE
SYNTAX InetAddressPrefixLength
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Indicates the number of leading one bits that form the
mask to be logical-ANDed with the destination address
before being compared to the value in the
inetCidrRouteDest field.
The values for the index objects inetCidrRouteDest and
inetCidrRoutePfxLen must be consistent. When the value
of inetCidrRouteDest (excluding the zone index, if one
is present) is x, then the bitwise logical-AND
of x with the value of the mask formed from the
corresponding index object inetCidrRoutePfxLen MUST be
equal to x. If not, then the index pair is not
consistent and an inconsistentName error must be
returned on SET or CREATE requests."
::= { inetCidrRouteEntry 3 }
inetCidrRoutePolicy OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object is an opaque object without any defined
semantics. Its purpose is to serve as an additional
index that may delineate between multiple entries to
the same destination. The value { 0 0 } shall be used
as the default value for this object."
::= { inetCidrRouteEntry 4 }
inetCidrRouteNextHopType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The type of the inetCidrRouteNextHop address, as
defined in the InetAddress MIB.
Value should be set to unknown(0) for non-remote
routes.
Only those address types that may appear in an actual
routing table are allowed as values of this object."
REFERENCE "RFC 4001"
::= { inetCidrRouteEntry 5 }
inetCidrRouteNextHop OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"On remote routes, the address of the next system en
route. For non-remote routes, a zero length string.
The type of this address is determined by the value of
the inetCidrRouteNextHopType object."
::= { inetCidrRouteEntry 6 }
inetCidrRouteIfIndex OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The ifIndex value that identifies the local interface
through which the next hop of this route should be
reached. A value of 0 is valid and represents the
scenario where no interface is specified."
::= { inetCidrRouteEntry 7 }
inetCidrRouteType OBJECT-TYPE
SYNTAX INTEGER {
other (1), -- not specified by this MIB
reject (2), -- route that discards traffic and
-- returns ICMP notification
local (3), -- local interface
remote (4), -- remote destination
blackhole(5) -- route that discards traffic
-- silently
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The type of route. Note that local(3) refers to a
route for which the next hop is the final destination;
remote(4) refers to a route for which the next hop is
not the final destination.
Routes that do not result in traffic forwarding or
rejection should not be displayed, even if the
implementation keeps them stored internally.
reject(2) refers to a route that, if matched, discards
the message as unreachable and returns a notification
(e.g., ICMP error) to the message sender. This is used
in some protocols as a means of correctly aggregating
routes.
blackhole(5) refers to a route that, if matched,
discards the message silently."
::= { inetCidrRouteEntry 8 }
inetCidrRouteProto OBJECT-TYPE
SYNTAX IANAipRouteProtocol
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The routing mechanism via which this route was learned.
Inclusion of values for gateway routing protocols is
not intended to imply that hosts should support those
protocols."
::= { inetCidrRouteEntry 9 }
inetCidrRouteAge OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of seconds since this route was last updated
or otherwise determined to be correct. Note that no
semantics of 'too old' can be implied, except through
knowledge of the routing protocol by which the route
was learned."
::= { inetCidrRouteEntry 10 }
inetCidrRouteNextHopAS OBJECT-TYPE
SYNTAX InetAutonomousSystemNumber
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The Autonomous System Number of the Next Hop. The
semantics of this object are determined by the routing-
protocol specified in the route's inetCidrRouteProto
value. When this object is unknown or not relevant, its
value should be set to zero."
DEFVAL { 0 }
::= { inetCidrRouteEntry 11 }
inetCidrRouteMetric1 OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The primary routing metric for this route. The
semantics of this metric are determined by the routing-
protocol specified in the route's inetCidrRouteProto
value. If this metric is not used, its value should be
set to -1."
DEFVAL { -1 }
::= { inetCidrRouteEntry 12 }
inetCidrRouteMetric2 OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"An alternate routing metric for this route. The
semantics of this metric are determined by the routing-
protocol specified in the route's inetCidrRouteProto
value. If this metric is not used, its value should be
set to -1."
DEFVAL { -1 }
::= { inetCidrRouteEntry 13 }
inetCidrRouteMetric3 OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"An alternate routing metric for this route. The
semantics of this metric are determined by the routing-
protocol specified in the route's inetCidrRouteProto
value. If this metric is not used, its value should be
set to -1."
DEFVAL { -1 }
::= { inetCidrRouteEntry 14 }
inetCidrRouteMetric4 OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"An alternate routing metric for this route. The
semantics of this metric are determined by the routing-
protocol specified in the route's inetCidrRouteProto
value. If this metric is not used, its value should be
set to -1."
DEFVAL { -1 }
::= { inetCidrRouteEntry 15 }
inetCidrRouteMetric5 OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"An alternate routing metric for this route. The
semantics of this metric are determined by the routing-
protocol specified in the route's inetCidrRouteProto
value. If this metric is not used, its value should be
set to -1."
DEFVAL { -1 }
::= { inetCidrRouteEntry 16 }
inetCidrRouteStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The row status variable, used according to row
installation and removal conventions.
A row entry cannot be modified when the status is
marked as active(1)."
::= { inetCidrRouteEntry 17 }
-- Conformance information
ipForwardConformance
OBJECT IDENTIFIER ::= { ipForward 5 }
ipForwardGroups
OBJECT IDENTIFIER ::= { ipForwardConformance 1 }
ipForwardCompliances
OBJECT IDENTIFIER ::= { ipForwardConformance 2 }
-- Compliance statements
ipForwardFullCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"When this MIB is implemented for read-create, the
implementation can claim full compliance.
There are a number of INDEX objects that cannot be
represented in the form of OBJECT clauses in SMIv2,
but for which there are compliance requirements,
expressed in OBJECT clause form in this description:
-- OBJECT inetCidrRouteDestType
-- SYNTAX InetAddressType (ipv4(1), ipv6(2),
-- ipv4z(3), ipv6z(4))
-- DESCRIPTION
-- This MIB requires support for global and
-- non-global ipv4 and ipv6 addresses.
--
-- OBJECT inetCidrRouteDest
-- SYNTAX InetAddress (SIZE (4 | 8 | 16 | 20))
-- DESCRIPTION
-- This MIB requires support for global and
-- non-global IPv4 and IPv6 addresses.
--
-- OBJECT inetCidrRouteNextHopType
-- SYNTAX InetAddressType (unknown(0), ipv4(1),
-- ipv6(2), ipv4z(3)
-- ipv6z(4))
-- DESCRIPTION
-- This MIB requires support for global and
-- non-global ipv4 and ipv6 addresses.
--
-- OBJECT inetCidrRouteNextHop
-- SYNTAX InetAddress (SIZE (0 | 4 | 8 | 16 | 20))
-- DESCRIPTION
-- This MIB requires support for global and
-- non-global IPv4 and IPv6 addresses.
"Okay so this part is basically the conformance checklist for the MIB, aka the "here's what you need to support to claim you're compliant" section. It's giving ✨ very organized, very iconic. 💅
MODULE -- this module
MANDATORY-GROUPS { inetForwardCidrRouteGroup }
OBJECT inetCidrRouteStatus
SYNTAX RowStatus { active(1), notInService (2) }
WRITE-SYNTAX RowStatus { active(1), notInService (2),
createAndGo(4), destroy(6) }
DESCRIPTION "Support for createAndWait is not required."
::= { ipForwardCompliances 3 }So the first compliance statement is the full read-write one 🎀. The big thing here is that createAndWait is just not on the list, and the description says so out loud. Iconic honesty, honestly. 🦋
ipForwardReadOnlyCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"When this MIB is implemented without support for read-
create (i.e., in read-only mode), the implementation can
claim read-only compliance."
MODULE -- this module
MANDATORY-GROUPS { inetForwardCidrRouteGroup }
OBJECT inetCidrRouteIfIndex
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT inetCidrRouteType
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT inetCidrRouteNextHopAS
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT inetCidrRouteMetric1
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT inetCidrRouteMetric2
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT inetCidrRouteMetric3
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT inetCidrRouteMetric4
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT inetCidrRouteMetric5
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT inetCidrRouteStatus
SYNTAX RowStatus { active(1) }
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
::= { ipForwardCompliances 4 }Now the read-only version, which is the "I'm not doing writes, bestie" flex. 🌸 Every writable object just gets read-only as its minimum access, and inetCidrRouteStatus gets trimmed down to active(1) only. Very minimalist, very clean. ✨
-- units of conformance
inetForwardCidrRouteGroup OBJECT-GROUP
OBJECTS { inetCidrRouteDiscards,
inetCidrRouteIfIndex, inetCidrRouteType,
inetCidrRouteProto, inetCidrRouteAge,
inetCidrRouteNextHopAS, inetCidrRouteMetric1,
inetCidrRouteMetric2, inetCidrRouteMetric3,
inetCidrRouteMetric4, inetCidrRouteMetric5,
inetCidrRouteStatus, inetCidrRouteNumber
}
STATUS current
DESCRIPTION
"The IP version-independent CIDR Route Table."
::= { ipForwardGroups 4 }
-- Deprecated Objects
ipCidrRouteNumber OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"The number of current ipCidrRouteTable entries that are
not invalid. This object is deprecated in favor of
inetCidrRouteNumber and the inetCidrRouteTable."
::= { ipForward 3 }So inetForwardCidrRouteGroup is the big bundle of objects, and it's the one that's mandatory for both compliance statements. Then we hit the deprecated zone 🥀, where the old ipCidrRouteNumber gets retired in favour of inetCidrRouteNumber. Glow-up era, no cap. 👑
-- IP CIDR Route Table
-- The IP CIDR Route Table obsoletes and replaces the ipRoute
-- Table current in MIB-I and MIB-II and the IP Forwarding Table.
-- It adds knowledge of the autonomous system of the next hop,
-- multiple next hops, policy routing, and Classless
-- Inter-Domain Routing.
ipCidrRouteTable OBJECT-TYPE
SYNTAX SEQUENCE OF IpCidrRouteEntry
MAX-ACCESS not-accessible
STATUS deprecated
DESCRIPTION
"This entity's IP Routing table. This table has been
deprecated in favor of the IP version neutral
inetCidrRouteTable."
REFERENCE
"RFC 1213 Section 6.6, The IP Group"
::= { ipForward 4 }
ipCidrRouteEntry OBJECT-TYPE
SYNTAX IpCidrRouteEntry
MAX-ACCESS not-accessible
STATUS deprecated
DESCRIPTION
"A particular route to a particular destination, under a
particular policy."
INDEX {
ipCidrRouteDest,
ipCidrRouteMask,
ipCidrRouteTos,
ipCidrRouteNextHop
}
::= { ipCidrRouteTable 1 }
IpCidrRouteEntry ::= SEQUENCE {
ipCidrRouteDest IpAddress,
ipCidrRouteMask IpAddress,
ipCidrRouteTos Integer32,
ipCidrRouteNextHop IpAddress,
ipCidrRouteIfIndex Integer32,
ipCidrRouteType INTEGER,
ipCidrRouteProto INTEGER,
ipCidrRouteAge Integer32,
ipCidrRouteInfo OBJECT IDENTIFIER,
ipCidrRouteNextHopAS Integer32,
ipCidrRouteMetric1 Integer32,
ipCidrRouteMetric2 Integer32,
ipCidrRouteMetric3 Integer32,
ipCidrRouteMetric4 Integer32,
ipCidrRouteMetric5 Integer32,
ipCidrRouteStatus RowStatus
}Now we get the old IP CIDR Route Table, the one that's basically the ancestor of everything. 🧚 The comment block is the real tea: it says this table replaces the old ipRoute table from MIB-I and MIB-II plus the IP Forwarding Table, and it adds next-hop AS knowledge, multiple next hops, policy routing, and CIDR. Main character energy from the start. 💜 Then the whole table gets marked deprecated, so it's retired but still on the guest list. 🌈
ipCidrRouteDest OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"The destination IP address of this route.
This object may not take a Multicast (Class D) address
value.
Any assignment (implicit or otherwise) of an instance
of this object to a value x must be rejected if the
bitwise logical-AND of x with the value of the
corresponding instance of the ipCidrRouteMask object is
not equal to x."
::= { ipCidrRouteEntry 1 }
ipCidrRouteMask OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"Indicate the mask to be logical-ANDed with the
destination address before being compared to the value
in the ipCidrRouteDest field. For those systems that
do not support arbitrary subnet masks, an agent
constructs the value of the ipCidrRouteMask by
reference to the IP Address Class.
Any assignment (implicit or otherwise) of an instance
of this object to a value x must be rejected if the
bitwise logical-AND of x with the value of the
corresponding instance of the ipCidrRouteDest object is
not equal to ipCidrRouteDest."
::= { ipCidrRouteEntry 2 }Okay the destination and mask objects are giving strict but fair 🙈. A destination can't be a Class D multicast address, and any assignment that fails the bitwise logical-AND check against the mask has to get rejected. Basically the math has to add up, or it's a no from me. 💀
-- The following convention is included for specification
-- of TOS Field contents. At this time, the Host Requirements
-- and the Router Requirements documents disagree on the width
-- of the TOS field. This mapping describes the Router
-- Requirements mapping, and leaves room to widen the TOS field
-- without impact to fielded systems.
ipCidrRouteTos OBJECT-TYPE
SYNTAX Integer32 (0..2147483647)
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"The policy specifier is the IP TOS Field. The encoding
of IP TOS is as specified by the following convention.
Zero indicates the default path if no more specific
policy applies.
+-----+-----+-----+-----+-----+-----+-----+-----+
| | | |
| PRECEDENCE | TYPE OF SERVICE | 0 |
| | | |
+-----+-----+-----+-----+-----+-----+-----+-----+
IP TOS IP TOS
Field Policy Field Policy
Contents Code Contents Code
0 0 0 0 ==> 0 0 0 0 1 ==> 2
0 0 1 0 ==> 4 0 0 1 1 ==> 6
0 1 0 0 ==> 8 0 1 0 1 ==> 10
0 1 1 0 ==> 12 0 1 1 1 ==> 14
1 0 0 0 ==> 16 1 0 0 1 ==> 18
1 0 1 0 ==> 20 1 0 1 1 ==> 22
1 1 0 0 ==> 24 1 1 0 1 ==> 26
1 1 1 0 ==> 28 1 1 1 1 ==> 30"
::= { ipCidrRouteEntry 3 }The TOS part is a bit of a drama 🎭. The two host and router docs literally disagree on how wide the TOS field is, so this sticks to the router version and leaves room to widen it later without breaking anyone's setup. Very future-proof, very "I planned ahead" energy. 🍓 The little table maps each even policy code to its bit pattern, and zero means the default path if nothing more specific applies. 🌟
ipCidrRouteNextHop OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"On remote routes, the address of the next system en
route; Otherwise, 0.0.0.0."
::= { ipCidrRouteEntry 4 }
ipCidrRouteIfIndex OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS deprecated
DESCRIPTION
"The ifIndex value that identifies the local interface
through which the next hop of this route should be
reached."
DEFVAL { 0 }
::= { ipCidrRouteEntry 5 }
ipCidrRouteType OBJECT-TYPE
SYNTAX INTEGER {
other (1), -- not specified by this MIB
reject (2), -- route that discards traffic
local (3), -- local interface
remote (4) -- remote destination
}
MAX-ACCESS read-create
STATUS deprecated
DESCRIPTION
"The type of route. Note that local(3) refers to a
route for which the next hop is the final destination;
remote(4) refers to a route for which the next hop is
not the final destination.
Routes that do not result in traffic forwarding or
rejection should not be displayed, even if the
implementation keeps them stored internally.
reject (2) refers to a route that, if matched,
discards the message as unreachable. This is used in
some protocols as a means of correctly aggregating
routes."
::= { ipCidrRouteEntry 6 }Next-hop, interface index, and route type are the "where am I going" crew 🦋. The next hop is the next system en route for remote routes, otherwise it's just 0.0.0.0. The interface index defaults to 0. And the type splits routes into four vibes: other, reject (the one that discards traffic as unreachable, which is apparently how some protocols aggregate), local (the next hop is the destination), and remote (it isn't). Routes that don't forward or reject anything shouldn't get displayed, even if they're stored internally. Not everyone gets a seat at the table. 🪑
ipCidrRouteProto OBJECT-TYPE
SYNTAX INTEGER {
other (1), -- not specified
local (2), -- local interface
netmgmt (3), -- static route
icmp (4), -- result of ICMP Redirect
-- the following are all dynamic
-- routing protocols
egp (5), -- Exterior Gateway Protocol
ggp (6), -- Gateway-Gateway Protocol
hello (7), -- FuzzBall HelloSpeak
rip (8), -- Berkeley RIP or RIP-II
isIs (9), -- Dual IS-IS
esIs (10), -- ISO 9542
ciscoIgrp (11), -- Cisco IGRP
bbnSpfIgp (12), -- BBN SPF IGP
ospf (13), -- Open Shortest Path First
bgp (14), -- Border Gateway Protocol
idpr (15), -- InterDomain Policy Routing
ciscoEigrp (16) -- Cisco EIGRP
}
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"The routing mechanism via which this route was learned.
Inclusion of values for gateway routing protocols is
not intended to imply that hosts should support those
protocols."
::= { ipCidrRouteEntry 7 }
ipCidrRouteAge OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"The number of seconds since this route was last updated
or otherwise determined to be correct. Note that no
semantics of `too old' can be implied, except through
knowledge of the routing protocol by which the route
was learned."
DEFVAL { 0 }
::= { ipCidrRouteEntry 8 }The protocol field is basically a history museum of routing protocols 🏛️, from static routes and ICMP Redirects all the way to BGP, OSPF, and the Cisco ones. Including a protocol in the list doesn't mean hosts are expected to run it, which is a very important little disclaimer, periodt. 💅 And the age field counts seconds since a route was last confirmed, but you can't infer "too old" from it unless you know the protocol it came from. Context is everything, bestie. 🫶
Okay bestie, we're deep in the MIB module now 🧚 Every object here is marked deprecated or obsolete, so the whole vibe is "this was the old way, and here's what replaced it" 💅
ipCidrRouteInfo OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-create
STATUS deprecated
DESCRIPTION
"A reference to MIB definitions specific to the
particular routing protocol that is responsible for
this route, as determined by the value specified in the
route's ipCidrRouteProto value. If this information is
not present, its value should be set to the OBJECT
IDENTIFIER { 0 0 }, which is a syntactically valid
object identifier, and any implementation conforming to
ASN.1 and the Basic Encoding Rules must be able to
generate and recognize this value."
::= { ipCidrRouteEntry 9 }
ipCidrRouteNextHopAS OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS deprecated
DESCRIPTION
"The Autonomous System Number of the Next Hop. The
semantics of this object are determined by the routing-
protocol specified in the route's ipCidrRouteProto
value. When this object is unknown or not relevant, its
value should be set to zero."
DEFVAL { 0 }
::= { ipCidrRouteEntry 10 }
ipCidrRouteMetric1 OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS deprecated
DESCRIPTION
"The primary routing metric for this route. The
semantics of this metric are determined by the routing-
protocol specified in the route's ipCidrRouteProto
value. If this metric is not used, its value should be
set to -1."
DEFVAL { -1 }
::= { ipCidrRouteEntry 11 }
ipCidrRouteMetric2 OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS deprecated
DESCRIPTION
"An alternate routing metric for this route. The
semantics of this metric are determined by the routing-
protocol specified in the route's ipCidrRouteProto
value. If this metric is not used, its value should be
set to -1."
DEFVAL { -1 }
::= { ipCidrRouteEntry 12 }
ipCidrRouteMetric3 OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS deprecated
DESCRIPTION
"An alternate routing metric for this route. The
semantics of this metric are determined by the routing-
protocol specified in the route's ipCidrRouteProto
value. If this metric is not used, its value should be
set to -1."
DEFVAL { -1 }
::= { ipCidrRouteEntry 13 }
ipCidrRouteMetric4 OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS deprecated
DESCRIPTION
"An alternate routing metric for this route. The
semantics of this metric are determined by the routing-
protocol specified in the route's ipCidrRouteProto
value. If this metric is not used, its value should be
set to -1."
DEFVAL { -1 }
::= { ipCidrRouteEntry 14 }
ipCidrRouteMetric5 OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS deprecated
DESCRIPTION
"An alternate routing metric for this route. The
semantics of this metric are determined by the routing-
protocol specified in the route's ipCidrRouteProto
value. If this metric is not used, its value should be
set to -1."
DEFVAL { -1 }
::= { ipCidrRouteEntry 15 }
ipCidrRouteStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS deprecated
DESCRIPTION
"The row status variable, used according to row
installation and removal conventions."
::= { ipCidrRouteEntry 16 }
-- compliance statements
ipForwardCompliance MODULE-COMPLIANCE
STATUS deprecated
DESCRIPTION
"The compliance statement for SNMPv2 entities that
implement the ipForward MIB.
This compliance statement has been deprecated and
replaced with ipForwardFullCompliance and
ipForwardReadOnlyCompliance."
MODULE -- this module
MANDATORY-GROUPS { ipForwardCidrRouteGroup }
::= { ipForwardCompliances 1 }
-- units of conformance
ipForwardCidrRouteGroup OBJECT-GROUP
OBJECTS { ipCidrRouteNumber,
ipCidrRouteDest, ipCidrRouteMask, ipCidrRouteTos,
ipCidrRouteNextHop, ipCidrRouteIfIndex,
ipCidrRouteType, ipCidrRouteProto, ipCidrRouteAge,
ipCidrRouteInfo,ipCidrRouteNextHopAS,
ipCidrRouteMetric1, ipCidrRouteMetric2,
ipCidrRouteMetric3, ipCidrRouteMetric4,
ipCidrRouteMetric5, ipCidrRouteStatus
}
STATUS deprecated
DESCRIPTION
"The CIDR Route Table.
This group has been deprecated and replaced with
inetForwardCidrRouteGroup."
::= { ipForwardGroups 3 }
-- Obsoleted Definitions - Objects
ipForwardNumber OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS obsolete
DESCRIPTION
"The number of current ipForwardTable entries that are
not invalid."
::= { ipForward 1 }
-- IP Forwarding Table
-- The IP Forwarding Table obsoletes and replaces the ipRoute
-- Table current in MIB-I and MIB-II. It adds knowledge of
-- the autonomous system of the next hop, multiple next hop
-- support, and policy routing support.
ipForwardTable OBJECT-TYPE
SYNTAX SEQUENCE OF IpForwardEntry
MAX-ACCESS not-accessible
STATUS obsolete
DESCRIPTION
"This entity's IP Routing table."
REFERENCE
"RFC 1213 Section 6.6, The IP Group"
::= { ipForward 2 }
ipForwardEntry OBJECT-TYPE
SYNTAX IpForwardEntry
MAX-ACCESS not-accessible
STATUS obsolete
DESCRIPTION
"A particular route to a particular destination, under a
particular policy."
INDEX {
ipForwardDest,
ipForwardProto,
ipForwardPolicy,
ipForwardNextHop
}
::= { ipForwardTable 1 }
IpForwardEntry ::= SEQUENCE {
ipForwardDest IpAddress,
ipForwardMask IpAddress,
ipForwardPolicy Integer32,
ipForwardNextHop IpAddress,
ipForwardIfIndex Integer32,
ipForwardType INTEGER,
ipForwardProto INTEGER,
ipForwardAge Integer32,
ipForwardInfo OBJECT IDENTIFIER,
ipForwardNextHopAS Integer32,
ipForwardMetric1 Integer32,
ipForwardMetric2 Integer32,
ipForwardMetric3 Integer32,
ipForwardMetric4 Integer32,
ipForwardMetric5 Integer32
}
ipForwardDest OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS obsolete
DESCRIPTION
"The destination IP address of this route. An entry
with a value of 0.0.0.0 is considered a default route.
This object may not take a Multicast (Class D) address
value.
Any assignment (implicit or otherwise) of an instance
of this object to a value x must be rejected if the
bitwise logical-AND of x with the value of the
corresponding instance of the ipForwardMask object is
not equal to x."
::= { ipForwardEntry 1 }
ipForwardMask OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-create
STATUS obsolete
DESCRIPTION
"Indicate the mask to be logical-ANDed with the
destination address before being compared to the value
in the ipForwardDest field. For those systems that do
not support arbitrary subnet masks, an agent constructs
the value of the ipForwardMask by reference to the IP
Address Class.
Any assignment (implicit or otherwise) of an instance
of this object to a value x must be rejected if the
bitwise logical-AND of x with the value of the
corresponding instance of the ipForwardDest object is
not equal to ipForwardDest."
DEFVAL { '00000000'H } -- 0.0.0.0
::= { ipForwardEntry 2 }
-- The following convention is included for specification
-- of TOS Field contents. At this time, the Host Requirements
-- and the Router Requirements documents disagree on the width
-- of the TOS field. This mapping describes the Router
-- Requirements mapping, and leaves room to widen the TOS field
-- without impact to fielded systems.
ipForwardPolicy OBJECT-TYPE
SYNTAX Integer32 (0..2147483647)
MAX-ACCESS read-only
STATUS obsolete
DESCRIPTION
"The general set of conditions that would cause
the selection of one multipath route (set of
next hops for a given destination) is referred
to as 'policy'.
Unless the mechanism indicated by ipForwardProto
specifies otherwise, the policy specifier is
the IP TOS Field. The encoding of IP TOS is as
specified by the following convention. Zero
indicates the default path if no more specific
policy applies.
+-----+-----+-----+-----+-----+-----+-----+-----+
| | | |
| PRECEDENCE | TYPE OF SERVICE | 0 |
| | | |
+-----+-----+-----+-----+-----+-----+-----+-----+
IP TOS IP TOS
Field Policy Field Policy
Contents Code Contents Code
0 0 0 0 ==> 0 0 0 0 1 ==> 2
0 0 1 0 ==> 4 0 0 1 1 ==> 6
0 1 0 0 ==> 8 0 1 0 1 ==> 10
0 1 1 0 ==> 12 0 1 1 1 ==> 14
1 0 0 0 ==> 16 1 0 0 1 ==> 18
1 0 1 0 ==> 20 1 0 1 1 ==> 22
1 1 0 0 ==> 24 1 1 0 1 ==> 26
1 1 1 0 ==> 28 1 1 1 1 ==> 30
Protocols defining 'policy' otherwise must either
define a set of values that are valid for
this object or must implement an integer-instanced
policy table for which this object's
value acts as an index."
::= { ipForwardEntry 3 }
ipForwardNextHop OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS obsolete
DESCRIPTION
"On remote routes, the address of the next system en
route; otherwise, 0.0.0.0."
::= { ipForwardEntry 4 }
ipForwardIfIndex OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS obsolete
DESCRIPTION
"The ifIndex value that identifies the local interface
through which the next hop of this route should be
reached."
DEFVAL { 0 }
::= { ipForwardEntry 5 }Okay so the MIB definitions are next, and bestie, they're the heart of the whole thing 🧚💖
ipForwardType OBJECT-TYPE
SYNTAX INTEGER {
other (1), -- not specified by this MIB
invalid (2), -- logically deleted
local (3), -- local interface
remote (4) -- remote destination
}
MAX-ACCESS read-create
STATUS obsolete
DESCRIPTION
"The type of route. Note that local(3) refers to a
route for which the next hop is the final destination;
remote(4) refers to a route for which the next hop is
not the final destination.
Setting this object to the value invalid(2) has the
effect of invalidating the corresponding entry in the
ipForwardTable object. That is, it effectively
disassociates the destination identified with said
entry from the route identified with said entry. 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. Proper
interpretation of such entries requires examination of
the relevant ipForwardType object."
DEFVAL { invalid }
::= { ipForwardEntry 6 }
ipForwardProto OBJECT-TYPE
SYNTAX INTEGER {
other (1), -- not specified
local (2), -- local interface
netmgmt (3), -- static route
icmp (4), -- result of ICMP Redirect
-- the following are all dynamic
-- routing protocols
egp (5), -- Exterior Gateway Protocol
ggp (6), -- Gateway-Gateway Protocol
hello (7), -- FuzzBall HelloSpeak
rip (8), -- Berkeley RIP or RIP-II
is-is (9), -- Dual IS-IS
es-is (10), -- ISO 9542
ciscoIgrp (11), -- Cisco IGRP
bbnSpfIgp (12), -- BBN SPF IGP
ospf (13), -- Open Shortest Path First
bgp (14), -- Border Gateway Protocol
idpr (15) -- InterDomain Policy Routing
}
MAX-ACCESS read-only
STATUS obsolete
DESCRIPTION
"The routing mechanism via which this route was learned.
Inclusion of values for gateway routing protocols is
not intended to imply that hosts should support those
protocols."
::= { ipForwardEntry 7 }
ipForwardAge OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS obsolete
DESCRIPTION
"The number of seconds since this route was last updated
or otherwise determined to be correct. Note that no
semantics of `too old' can be implied except through
knowledge of the routing protocol by which the route
was learned."
DEFVAL { 0 }
::= { ipForwardEntry 8 }
ipForwardInfo OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-create
STATUS obsolete
DESCRIPTION
"A reference to MIB definitions specific to the
particular routing protocol that is responsible for
this route, as determined by the value specified in the
route's ipForwardProto value. If this information is
not present, its value should be set to the OBJECT
IDENTIFIER { 0 0 }, which is a syntactically valid
object identifier, and any implementation conforming to
ASN.1 and the Basic Encoding Rules must be able to
generate and recognize this value."
::= { ipForwardEntry 9 }
ipForwardNextHopAS OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS obsolete
DESCRIPTION
"The Autonomous System Number of the Next Hop. When
this is unknown or not relevant to the protocol
indicated by ipForwardProto, zero."
DEFVAL { 0 }
::= { ipForwardEntry 10 }
ipForwardMetric1 OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS obsolete
DESCRIPTION
"The primary routing metric for this route. The
semantics of this metric are determined by the routing-
protocol specified in the route's ipForwardProto value.
If this metric is not used, its value should be set to
-1."
DEFVAL { -1 }
::= { ipForwardEntry 11 }
ipForwardMetric2 OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS obsolete
DESCRIPTION
"An alternate routing metric for this route. The
semantics of this metric are determined by the routing-
protocol specified in the route's ipForwardProto value.
If this metric is not used, its value should be set to
-1."
DEFVAL { -1 }
::= { ipForwardEntry 12 }
ipForwardMetric3 OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS obsolete
DESCRIPTION
"An alternate routing metric for this route. The
semantics of this metric are determined by the routing-
protocol specified in the route's ipForwardProto value.
If this metric is not used, its value should be set to
-1."
DEFVAL { -1 }
::= { ipForwardEntry 13 }
ipForwardMetric4 OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS obsolete
DESCRIPTION
"An alternate routing metric for this route. The
semantics of this metric are determined by the routing-
protocol specified in the route's ipForwardProto value.
If this metric is not used, its value should be set to
-1."
DEFVAL { -1 }
::= { ipForwardEntry 14 }
ipForwardMetric5 OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS obsolete
DESCRIPTION
"An alternate routing metric for this route. The
semantics of this metric are determined by the routing-
protocol specified in the route's ipForwardProto value.
If this metric is not used, its value should be set to
-1."
DEFVAL { -1 }
::= { ipForwardEntry 15 }
-- Obsoleted Definitions - Groups
-- compliance statements
ipForwardOldCompliance MODULE-COMPLIANCE
STATUS obsolete
DESCRIPTION
"The compliance statement for SNMP entities that
implement the ipForward MIB."
MODULE -- this module
MANDATORY-GROUPS { ipForwardMultiPathGroup }
::= { ipForwardCompliances 2 }
ipForwardMultiPathGroup OBJECT-GROUP
OBJECTS { ipForwardNumber,
ipForwardDest, ipForwardMask, ipForwardPolicy,
ipForwardNextHop, ipForwardIfIndex, ipForwardType,
ipForwardProto, ipForwardAge, ipForwardInfo,
ipForwardNextHopAS,
ipForwardMetric1, ipForwardMetric2, ipForwardMetric3,
ipForwardMetric4, ipForwardMetric5
}
STATUS obsolete
DESCRIPTION
"IP Multipath Route Table."
::= { ipForwardGroups 2 }
END6. Security Considerations 🔐✨
Okay, this part is serious, so read it properly 🫶 There are a bunch of management objects in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. These can be sensitive or vulnerable in some network environments. SET operations in a non-secure environment without proper protection can seriously mess with network operations, so be careful 🚨 These are the tables and objects, plus their sensitivity and vulnerability:
- The
inetCidrRouteTablecontains routing and forwarding information that is critical to the operation of the network node (especially routers). Allowing unauthenticated write access to this table can compromise the validity of the forwarding information.
Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects, and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects, plus their sensitivity and vulnerability:
- The
inetCidrRouteTablecontains routing and forwarding information that can be used to compromise a network.
Specifically, this table can be used to construct a map of the network in preparation for a denial-of-service attack on the network infrastructure.
- The
inetCidrRouteProtoobject identifies the routing protocols in use within a network. This information can be used to determine how a denial-of-service attack should be launched.
SNMP versions prior to SNMPv3 did not include adequate security. 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 module. 😬
It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). 🔒
Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module 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. Main character energy is locking the door, bestie. 💀
7. Changes from RFC 2096 🎀
Here's what changed from RFC 2096, and this document obsoletes RFC 2096 in the following ways 🦋
- Replaces
ipCidrRouteTablewithinetCidrRouteTable. This applies to corresponding objects and conformance statements. - Utilizes the
InetAddressTC to support IP version-independent implementations of the forwarding MIB. This gives common forwarding MIB support for IPv4 and IPv6. - Creates a
read-onlyconformance statement to support implementations that only wish to retrieve data. - Creates the
inetCidrRouteDiscardsobject to replace the deprecatedipRoutingDiscardsandipv6DiscardedRoutesobjects.
The inetCidrRouteTable keeps the logical structure of the ipCidrRouteTable so existing IPv4 implementations can upgrade to the version-independent MIB easily. That's the glow-up energy we love to see ✨🌸
8. Normative References ✨
Okay so these are the docs this one needs to read first, no cap 📚
[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. 🌸[RFC2863]McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. ✨[RFC4001]Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. 🧚[RFC4293]Routhier, S., Ed., "Management Information Base for the Internet Protocol (IP), RFC 4293, April 2006. 💜[RTPROTO]IANA, "IP Route Protocol MIB",http://www.iana.org/assignments/ianaiprouteprotocol-mib, September 2000. 🍓
9. Informative References 🌈
These ones are more like the "ooh, go read this for context" list. Not required, but lowkey super helpful 🫶
[RFC1213]McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", RFC 1213, March 1991. 👑[RFC1354]Baker, F., "IP Forwarding Table MIB", RFC 1354, July 1992. 🌸[RFC2011]McCloghrie, K., Editor, "SNMPv2 Management Information Base for the Internet Protocol using SMIv2", RFC 2011, November 1996. 💖[RFC2096]Baker, F., "IP Forwarding Table MIB", RFC 2096, January 1997. 🦋[RFC3410]Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. 🧚[RFC2465]Haskin, D. and S. Onishi, Management Information Base for IP Version 6: Textual Conventions and General Group", RFC 2465, December 1998. 🎀
10. Authors and Acknowledgements ✨
This one was based on RFC 2096 [RFC2096], so shoutout to that doc for laying the groundwork 🫶
These people wrote text for this version, or were authors on earlier versions. Iconic behavior 👑
- Fred Baker, Cisco 💅
- Bill Fenner, AT&T Research 🦋
- Brian Haberman, Johns Hopkins University - Applied Physics Laboratory 🌸
- Juergen Schoenwalder, TU Braunschweig 🎀
- Dave Thaler, Microsoft 💜
- Margaret Wasserman, Thingmagic ✨
Dario Accornero, Mark Adam, Qing Li, and Shawn Routhier reviewed the document and gave super helpful feedback. Thank you, queens 🙌
Mike Heard gave valuable feedback as the MIB Doctor for this document. Real MVP energy 🏆
Editors' Contact Information
If you have comments or questions about this document, send them here 💌
Brian Haberman Johns Hopkins University - Applied Physics Laboratory Mailstop 17-S442 11100 Johns Hopkins Road Laurel MD, 20723-6099 USA
Phone: +1-443-778-1319 EMail: brian@innovationslab.net
Full Copyright Statement
Copyright (C) The Internet Society (2006). 🌈
This document is subject to the rights, licenses and restrictions in BCP 78. Apart from what BCP 78 says, the authors keep 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 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
Okay, the IETF is not picking a side on whether any Intellectual Property Rights apply to the tech in this document, or whether you can get a license to use it. It also hasn't checked for any of those rights itself 🔍 If you want the rules on RFC documents, check out BCP 78 and BCP 79 📖
Any IPR disclosures sent to the IETF Secretariat, any promised licenses, and the results of any attempt to get a general license for implementers or users can be found in the IETF's online IPR repository at http://www.ietf.org/ipr. 🦋
The IETF also invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org. 💜
Acknowledgement
Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA). 🌸
📦 where this page comes from
- ietf: rfc4292 2006-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms