Request For Comments: 1354                                           ACC
IP Forwarding Table MIB
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.
for use with network management protocols in TCP/IP-based internets.
In particular, it defines objects for managing routes in the IP
It is proposed that the ipRouteTable defined by MIB-II (RFC 1213) be
deprecated and replaced with this table.  This adds the ability to
set or display multi-path routes, and varying routes by network
management policy.
1. The Network Management Framework ............................    1
2. Objects .....................................................    2
2.1 Format of Definitions ......................................    2
3. Overview ....................................................    3
3.1 Structure of MIB ...........................................    3
4. Definitions .................................................    4
4.1 IP Forwarding Table ........................................    4
5. Acknowledgements ............................................   11
6. References ..................................................   11
7. Security Considerations........................................ 12
8. Author's Address............................................... 12
1.  The Network Management Framework
The Internet-standard Network Management Framework consists of three
components.  They are:
RFC 1155 which defines the SMI, the mechanisms used for describing
and naming objects for the purpose of management.  RFC 1212 defines a
Baker                                                           [Page 1]
RFC 1354                IP Forwarding Table MIB                July 1992
more concise description mechanism, which is wholly consistent with
the SMI.
RFC 1156 which defines MIB-I, the core set of managed objects for the
Internet suite of protocols.  RFC 1213 defines MIB-II, an evolution
of MIB-I based on implementation experience and new operational
RFC 1157 which defines the SNMP, the protocol used for network access
to managed objects.
2.  Objects
defined using the subset of Abstract Syntax Notation One (ASN.1) [7]
defined in the SMI.  In particular, each object has a name, a syntax,
and an encoding.  The name is an object identifier, an
administratively assigned name, which specifies an object type.  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 OBJECT
DESCRIPTOR, to also refer to the object type.
The syntax of an object type defines the abstract data structure
corresponding to that object type.  The ASN.1 language is used for
this purpose.  However, the SMI [3] purposely restricts the ASN.1
constructs which may be used.  These restrictions are explicitly made
for simplicity.
The encoding of an object type is simply how that object type is
represented using the object type's syntax.  Implicitly tied to the
notion of an object type's syntax and encoding is how the object type
is represented when being transmitted on the network.
The SMI specifies the use of the basic encoding rules of ASN.1 [8],
subject to the additional requirements imposed by the SNMP.
2.1.  Format of Definitions
Section 4 contains 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 [9].
3.1.  Structure of MIB
The IP Forwarding Table is quite analogous to the older ipRoute
Table.  The principal differences are:
(1)  It is somewhat re-organized, for aesthetic reasons,
(2)  It has the Next Hop Autonomous System Number, useful
primarily to the administrators of regional networks,
(3)  It is instanced by Policy and Next Hop as well as by
ultimate destination.  Thus, multiple multipath routes
can be managed, not just a single route, along with the
circumstances under which the any given route might be
chosen.
RFC1354-MIB DEFINITIONS ::= BEGIN
Gauge, IpAddress
FROM RFC1155-SMI
mib-2, ip
FROM RFC1213-MIB
FROM RFC-1212;
--  This MIB module uses the extended OBJECT-TYPE macro as
--  defined in [9].
ipForward  OBJECT IDENTIFIER ::= { ip 24 }
ipForwardNumber OBJECT-TYPE
SYNTAX   Gauge
ACCESS   read-only
STATUS   mandatory
"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
ACCESS   not-accessible
"This entity's IP Routing table."
"RFC 1213 Section 6.6, The IP Group"
ipForwardEntry OBJECT-TYPE
SYNTAX   IpForwardEntry
"A particular route to  a  particular  destina-
tion, under a particular policy."
INDEX {
ipForwardDest,
ipForwardProto,
ipForwardPolicy,
ipForwardNextHop
::= { ipForwardTable 1 }
IpForwardEntry ::=
SEQUENCE {
ipForwardDest
IpAddress,
ipForwardMask
ipForwardPolicy
INTEGER,
ipForwardIfIndex
ipForwardType
ipForwardProto
ipForwardAge
ipForwardInfo
OBJECT IDENTIFIER,
ipForwardNextHopAS
ipForwardMetric1
ipForwardDest OBJECT-TYPE
SYNTAX   IpAddress
"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
ACCESS   read-write
"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 Ad-
dress Class.
ipForwardDest object is not equal to ipForward-
Dest."
DEFVAL { '00000000'h }      -- 0.0.0.0
-- 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   INTEGER
"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 ipForwardPro-
to 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 1 0 0  ==>   8      0 1 0 1  ==>  10
0 1 1 0  ==>  12      0 1 1 1  ==>  14
Protocols defining 'policy' otherwise must  ei-
ther define a set of values which are valid for
this  object  or  must  implement  an  integer-
instanced  policy table for which this object's
value acts as an index."
ipForwardNextHop OBJECT-TYPE
"On remote routes, the address of the next sys-
tem en route; Otherwise, 0.0.0.0."
ipForwardIfIndex OBJECT-TYPE
"The ifIndex value which identifies  the  local
interface  through  which  the next hop of this
route should be reached."
DEFVAL { 0 }
ipForwardType OBJECT-TYPE
SYNTAX   INTEGER {
other    (1), -- not specified by this MIB
invalid  (2), -- logically deleted
local    (3), -- local interface
remote   (4)  -- remote destination
"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 destina-
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 iden-
tified    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 current-
ly  in  use.  Proper interpretation of such en-
tries requires examination of the relevant  ip-
ForwardType object."
DEFVAL { invalid }
ipForwardProto OBJECT-TYPE
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
"The routing mechanism via which this route was
learned.  Inclusion of values for gateway rout-
ing protocols is not  intended  to  imply  that
hosts should support those protocols."
ipForwardAge OBJECT-TYPE
"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 }
ipForwardInfo OBJECT-TYPE
SYNTAX   OBJECT IDENTIFIER
"A reference to MIB definitions specific to the
particular  routing protocol which is responsi-
ble 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  identif-
ier, and any implementation conforming to ASN.1
and the Basic Encoding Rules must  be  able  to
generate and recognize this value."
DEFVAL  { { 0 0 } } -- 0.0
ipForwardNextHopAS OBJECT-TYPE
"The Autonomous System Number of the Next  Hop.
When  this  is  unknown  or not relevant to the
protocol indicated by ipForwardProto, zero."
::= { ipForwardEntry 10 }
ipForwardMetric1 OBJECT-TYPE
"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 }
"An alternate routing metric  for  this  route.
Baker                                                          [Page 10]
This document was produced by the Router Requirements Working Group,
of which Phil Almquist is the chair.
Chris Gunner (DEC) and Keith McCloghrie (Hughes LAN Systems) made
significant comments on it, and it is better for their input.
[1]  Cerf, V., "IAB Recommendations for the Development of Internet
Network Management Standards", RFC 1052, NRI, April 1988.
[2]  Cerf, V., "Report of the Second Ad Hoc Network Management Review
Group", RFC 1109, NRI, August 1989.
[3]  Rose M., and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based internets", RFC 1155,
Performance Systems International, Hughes LAN Systems, May 1990.
[4]  McCloghrie K., and M. Rose, "Management Information Base for
Network Management of TCP/IP-based internets", RFC 1156, Hughes
LAN Systems, Performance Systems International, May 1990.
[5]  Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
Network Management Protocol", RFC 1157, SNMP Research,
Performance Systems International, Performance Systems
International, MIT Laboratory for Computer Science, May 1990.
[6]  McCloghrie K., and M. Rose, Editors, "Management Information
Base for Network Management of TCP/IP-based internets", RFC
1213, Performance Systems International, March 1991.
[7]  Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization, International
Standard 8824, December 1987.
Specification of Basic Encoding Rules for Abstract Notation One
(ASN.1), International Organization for Standardization,
International Standard 8825, December 1987.
[9]  Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
RFC 1212, Performance Systems International, Hughes LAN Systems,
[10]  McCloghrie K., and M. Rose, Editors, "Management Information
[11]  Baker, F., and R. Coltun, "OSPF Version 2 Management Information
Base", RFC 1253, ACC, Computer Science Center, August 1991.
Advanced Computer Communications
315 Bollay Drive
Santa Barbara, CA  93117-6014
EMail: fbaker@acc.com