RFC 2006 Mobile IP MIB Definition using SMIv2 October 19961. The SNMP Network Management Framework
The Internet-standard Network Management Framework presently consists
of three major components. They are:
The SMI, described in RFC 1902 [1] - the mechanisms used for
describing and naming objects for the purpose of management.
The MIB-II, STD 17, RFC 1213 [2] - the core set of managed objects
for the Internet suite of protocols.
The protocol, RFC 1157 [3] and/or RFC 1905 [4], - the protocol for
accessing managed objects.
The Framework permits new objects to be defined for the purpose of
experimentation and evaluation.
2. Objects2.1. Object Definitions
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)
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.
3. Overview3.1. Object Selection Criteria
To be consistent with IAB directives and good engineering practice,
the authors have applied some criteria to select managed objects for
the Mobile IP Protocol.
(1) Partition management functionality among the Mobile Node, Home
Agent, and Foreign Agent according to the partitioning seen in
the Mobile IP Protocol.
(2) Require that objects be essential for either fault or
configuration management.
(3) Limit the total number of objects.
Cong, Hamlen & Perkins Standards Track [Page 2]

RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996
(4) Exclude objects which are simply derivable from others in this or
other MIBs.
3.2. Structure of the Mobile IP
This section describes the basic model of Mobile IP used in
developing the Mobile IP MIB. This information should be useful to
the implementor in understanding some of the basic design decisions
of the MIB.
The Mobile IP Protocol introduces these new funtional entities:
Mobile Node
A host or router that changes its point of attachment from one
network or subnetwork to another. A mobile node may change its
location without losing connectivity and without changing its IP
address; it may continue to communicate with other Internet nodes
at any location using its (constant) IP address, assuming link-
layer connectivity to a point of attachment is available.
Home Agent
A router on a mobile node's home network which tunnels packets for
delivery to the mobile node when it is away from home, and
maintains current location information for the mobile node.
Foreign Agent
A router on a mobile node's visited network which provides routing
services to the mobile node while registered. The foreign agent
detunnels and delivers packets to the mobile node that were
tunneled by the mobile node's home agent. For datagrams sent by a
mobile node, the foreign agent may serve as a default router for
registered mobile nodes.
This document specifies the objects used in managing these entities;
namely, the Mobile Node, the Home Agent, and the Foreign Agent.
Cong, Hamlen & Perkins Standards Track [Page 3]

RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996
"A table containing all of the mobile node's potential
home agents."
::= { mnSystem 3 }
mnHAEntry OBJECT-TYPE
SYNTAX MnHAEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information for a particular Home Agent."
INDEX { mnHAAddress }
::= { mnHATable 1 }
MnHAEntry ::= SEQUENCE {
mnHAAddress IpAddress,
mnCurrentHA TruthValue,
mnHAStatus RowStatus
}
mnHAAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"IP address of mobile node's Home Agent."
::= { mnHAEntry 1 }
mnCurrentHA OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Whether this home agent is the current home agent for
the mobile node. If it is true, the mobile node is
registered with that home agent."
::= { mnHAEntry 2 }
mnHAStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The row status for this home agent entry. If the
status is set to 'createAndGo' or 'active', then the
mobile node can use mnHAAddress as a valid candidate
for a home agent. If the status is set to 'destroy',
then the mobile node should delete this row, and
deregister from that home agent."
Cong, Hamlen & Perkins Standards Track [Page 13]

RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996
SYNTAX RegistrationFlags
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Registration flags sent by the mobile node. It is the
second byte in the Mobile IP Registratation Request
message."
::= { mnRegistrationEntry 3 }
mnRegIDLow OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Low-order 32 bits of the Identification used in that
registration by the mobile node."
::= { mnRegistrationEntry 4 }
mnRegIDHigh OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"High-order 32 bits of the Identification used in that
registration by the mobile node."
::= { mnRegistrationEntry 5 }
mnRegTimeRequested OBJECT-TYPE
SYNTAX Integer32
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"If the registration is pending, then this is the
lifetime requested by the mobile node (in seconds).
If the registration has been accepted, then this is
the lifetime actually granted by the home agent in the
reply."
::= { mnRegistrationEntry 6 }
mnRegTimeRemaining OBJECT-TYPE
SYNTAX Gauge32
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of seconds remaining until this
registration expires. It has the same initial value
Cong, Hamlen & Perkins Standards Track [Page 20]

RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996
as mnRegTimeRequested and is only valid if
mnRegIsAccepted is TRUE."
::= { mnRegistrationEntry 7 }
mnRegTimeSent OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The time when the last (re-)transmission occured."
::= { mnRegistrationEntry 8 }
mnRegIsAccepted OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"true(1) if the mobile node has received a
Registration Reply indicating that service has been
accepted; false(2) otherwise. false(2) implies that
the registration is still pending."
::= { mnRegistrationEntry 9 }
mnCOAIsLocal OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Whether the COA is local to (dynamically acquired by)
the mobile node or not. If it is false(2), the COA is
an address of the foreign agent."
::= { mnRegistrationEntry 10 }
-- Mobile Node Registration Group Counters
mnRegRequestsSent OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Total number of registration requests sent by the
mobile node. This does not include deregistrations
(those with Lifetime equal to zero)."
::= { mnRegistration 2 }
mnDeRegRequestsSent OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
Cong, Hamlen & Perkins Standards Track [Page 21]

RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996
"The compliance statement for SNMPv2 entities which
implement the Mobile IP MIB."
MODULE
MANDATORY-GROUPS { mipSystemGroup }
GROUP mipSecAssociationGroup
DESCRIPTION
"This group is mandatory for Mobile IP entities (MN,
FA, and HA) which support security associations.
Mobile Nodes and Home Agents must implement this
group. Foreign Agents must implement this group if
they maintain any security associations."
GROUP mipSecViolationGroup
DESCRIPTION
"This group is mandatory for Mobile IP entities (MN,
FA, and HA) that can log security violations."
GROUP mnSystemGroup
DESCRIPTION
"This group is mandatory for mobile node."
GROUP mnDiscoveryGroup
DESCRIPTION
"This group is mandatory for mobile nodes which
implement the Agent Discovery function."
GROUP mnRegistrationGroup
DESCRIPTION
"This group is mandatory for mobile nodes."
GROUP maAdvertisementGroup
DESCRIPTION
"This group is mandatory for the mobility agents (HA
and FA) since they must implement Agent
Advertisement."
GROUP faSystemGroup
DESCRIPTION
"This group is mandatory for foreign agents."
GROUP faAdvertisementGroup
DESCRIPTION
"This group is mandatory for foreign agents."
GROUP faRegistrationGroup
DESCRIPTION
"This group is mandatory for foreign agents."
Cong, Hamlen & Perkins Standards Track [Page 44]

RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996
STATUS current
DESCRIPTION
"The notification related to security violations."
::= { mipGroups 13 }
END
5. Acknowledgments
This document was produced by the Mobile IP working group. The
editors wish to thank Bob Stewart (Cisco Systems), for his help in
converting from SNMPv1 to SNMPv2. We also want to thank Jim Solomon,
for his encouragement, patience, and help. Thanks to Fredrick Tarberg
and Fredrik Broman (KTH) for their initial efforts in defining a
Mobile IP MIB. Thanks to Frank Kastenholz (FTP Software) for his
comments on the initial MIB from KTH. Thanks to Gerald Maguire (KTH)
for his comments on the first version of this MIB. Thanks to Mike
Roels (Motorola) for his help in testing this MIB.
6. Security Considerations
The Mobile IP MIB affords the network operator the ability to
configure and control the Mobile IP links of a particular system,
including the Mobile IP authentication protocols, and shared secret
key. 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 MIB Groups. By providing Agent Capability
Statements, the implementor of the MIB may elect not to
implement these groups.
(2) The MIB allows the manager station to create the security
association for Mobile IP entities. However, the agent should
always return 0 length octet string when the manager station
retrieves the shared security key in the mipSecAssocTable. In
this way, the Mobile IP entities can prevent the key leaking
from SNMP GET, GET-NEXT, or GET-BULK requests.
(3) The MIB defines a trap for Mobile IP entities to send a
notification to the manager station if there is a security
violation. In this way, the operator can notice the source of
an intruder.
(4) The MIB also defines a table to log the security violations
in the Mobile IP entities. The manager station can retrieve
this log to analyze the security violation instances in the
Cong, Hamlen & Perkins Standards Track [Page 49]