rfc-2006

The Definitions of Managed Objects for IP Mobility Support using SMIv2

D. Cong, M. Hamlen, C. Perkins
date1996-10 streamIETF areaint wgmobileip statusPROPOSED STANDARD pages52 canonicalhttps://www.rfc-editor.org/rfc/rfc2006 doi10.17487/RFC2006 errataview
This memo defines the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the Mobile Node, Foreign Agent and Home Agent of the Mobile IP Protocol. [STANDARDS-TRACK]

Extracted elements (27)

design-rationale §3.1

MIB management functionality is partitioned among Mobile Node, Foreign Agent, and Home Agent to mirror the architectural partition in the Mobile IP protocol itself, ensuring each managed entity only needs to implement the groups relevant to its role.

mobility, snmp

design-rationale §3.1

Object selection was deliberately constrained to items essential for fault or configuration management, excludes objects derivable from other MIBs, and limits the total count — reflecting IAB directives for focused, minimal MIB design.

mobility, snmp

interoperability-note §4

The mnAdvSequence object ranges from 0 to 0xffff (65535), but after reaching 0xffff it rolls over to 256 rather than 0, matching the Mobile IP protocol behavior that distinguishes a rollover from an agent reboot (sequence numbers 0–255 signal reboot).

mobility

normative-requirement §4 MUST

The maAdvAddress object MUST be set to either the all-systems multicast address (224.0.0.1) or the limited-broadcast address (255.255.255.255); no other values are permissible for agent advertisement destination.

mobility

normative-requirement §4 REQUIRED

The maAdvertisementGroup is mandatory for both Home Agents and Foreign Agents because all mobility agents must implement Agent Advertisement.

mobility

normative-requirement §4 REQUIRED

The mipSecAssociationGroup is mandatory for Mobile Nodes and Home Agents; Foreign Agents must implement it only if they maintain any security associations.

mobility, security

normative-requirement §4 REQUIRED

The mipSystemGroup (mipEntities, mipEnable, mipEncapsulationSupported) is the sole MANDATORY-GROUP in the compliance statement; all other groups are conditionally mandatory depending on entity type (MN, FA, or HA).

mobility, snmp

protocol-element §4

Foreign agent denial counters enumerate refusal reasons by code: reasonUnspecified (64), admProhibited (65), insufficientResource (66), mnAuthenticationFailure (67), haAuthenticationFailure (68), regLifetimeTooLong (69), poorlyFormedRequest (70), encapsulationUnavailable (72), vjCompressionUnavailable (73), and haUnreachable (80–95).

mobility

protocol-element §4

Home agent denial counters correspond to reply codes 128–136: reasonUnspecified, admProhibited, insufficientResource, mnAuthenticationFailure, faAuthenticationFailure, idMismatch, poorlyFormedRequest, tooManyBindings, unknownHA; Code 1 (haMultiBindingUnsupported) counts accepted-but-simultaneous-bindings-unsupported replies.

mobility

protocol-element §4

The faVisitorTable is the foreign agent's visitor list, indexed by the source IP address of the visitor's Registration Request, and contains home address, home agent address, granted lifetime, countdown timer, registration flags, 64-bit identification, and acceptance status per visiting mobile node.

mobility

protocol-element §4

The haCounterTable tracks per-mobile-node registration statistics at the home agent, including service requests accepted/denied, overall service time (Gauge32 in seconds since last HA reboot), timestamps of most recent accept and deny, and the most recent denial code (reasonUnspecified through unknownHA, codes 128–136).

mobility

protocol-element §4

The haMobilityBindingTable stores the home agent's mobility binding list indexed by mobile node home address and care-of address, recording the registration source address (either co-located COA or FA address), flags, 64-bit identification, granted lifetime, and remaining time.

mobility

protocol-element §4

The maAdvConfigTable provides per-interface advertisement configuration for mobility agents, including maAdvMaxRegLifetime, maAdvAddress (must be 224.0.0.1 or 255.255.255.255), maAdvMaxInterval (4..1800s), maAdvMinInterval (3..1800s), maAdvMaxAdvLifetime (4..9000s), and maAdvResponseSolicitationOnly (default false).

mobility

protocol-element §3.3

The MIB is partitioned into twelve groups: mipSystemGroup, mipSecAssociationGroup, mipSecViolationGroup, mnSystemGroup, mnDiscoveryGroup, mnRegistrationGroup, maAdvertisementGroup, faSystemGroup, faAdvertisementGroup, faRegistrationGroup, haRegistrationGroup, and haRegNodeCountersGroup, each assigned to specific Mobile IP entities (MN, FA, HA).

mobility, snmp

protocol-element §4

The mipAuthFailure NOTIFICATION-TYPE conveys mipSecViolatorAddress, mipSecRecentViolationSPI, mipSecRecentViolationIDLow, mipSecRecentViolationIDHigh, and mipSecRecentViolationReason when authentication of a Registration Request or Reply fails; implementation is optional.

mobility, security, snmp

protocol-element §4

The mipEncapsulationSupported object is a BITS type advertising which encapsulation methods the Mobile IP entity supports: ipInIp(0), gre(1), minEnc(2), other(3); a mobile entity may support multiple methods or none.

mobility

protocol-element §4

The mipSecAssocTable stores Mobility Security Associations indexed by mipSecPeerAddress (IpAddress) and mipSecSPI (Unsigned32, 0..4294967295), with per-entry attributes for algorithm type (md5 or other), algorithm mode (prefixSuffix or other), shared key (16-octet OCTET STRING), and replay method (timestamps, nonces, or other).

mobility, security, crypto

protocol-element §4

The mipSecReplayMethod per-SPI object specifies the replay-protection method in use for each Mobility Security Association entry: timestamps(2) or nonces(3), in addition to other(1).

mobility, security

protocol-element §4

The mipSecViolationTable records per-peer security violations, capturing the violator IP address, violation count, SPI of the most recent violation, violation timestamp, 64-bit identification field (split into IDLow/IDHigh), and reason code (noMobilitySecurityAssociation, badAuthenticator, badIdentifier, badSPI, missingSecurityExtension, other).

mobility, security

protocol-element §4

The mnFATable is indexed by foreign agent IP address and care-of address (COA), and is updated as advertisements are received; entries expire when the advertisement lifetime expires, and one FA may appear multiple times with different COAs.

mobility

protocol-element §4

The mnHATable lists potential home agents for the mobile node, with each entry containing the HA IP address (mnHAAddress), a flag indicating whether it is the current HA (mnCurrentHA), and a RowStatus (mnHAStatus) — setting status to 'destroy' causes the MN to deregister from that HA.

mobility

protocol-element §4

The mnRegistrationTable tracks each registration attempt indexed by agent address and COA, storing registration flags, 64-bit identification, requested/granted lifetime, countdown timer (Gauge32), send timestamp, acceptance status (TruthValue), and whether the COA is locally acquired (mnCOAIsLocal).

mobility

registry §4

RFC 2006 registers the Mobile IP MIB module as mib-2 44 (OID { mib-2 44 }), defining managed objects for the Mobile Node, Foreign Agent, and Home Agent under SMIv2.

mobility, registry, snmp

security-consideration §4

The mipSecKey object (16-octet shared secret) is read-create but always returns a zero-length value when read, preventing shared secrets from being exposed via SNMP GET operations.

mobility, security, crypto

security-consideration §6

The Mobile IP MIB affords network operators the ability to configure and control Mobile IP links; read-write and read-create objects (such as mipEnable, security association parameters, and advertisement configuration) should be protected using SNMPv2 security mechanisms to prevent unauthorized modification.

mobility, security, snmp

state-machine §4

The mnState object defines five Mobile Node states: home (connected to home network), registered (registered on foreign network), pending (awaiting registration reply), isolated (no network connectivity), and unknown (state cannot be determined).

mobility

wire-format §4

The RegistrationFlags textual convention is encoded as a BITS type with six named bits: vjCompression(0), gre(1), minEnc(2), decapsulationByMN(3), broadcastDatagram(4), and simultaneousBindings(5), corresponding to the second byte of the Mobile IP Registration Request message.

mobility